Current LLM agent benchmarks, which predominantly focus on binary pass/fail tasks such as code generation or search-based question answering, often neglect the value of real-world engineering that is often captured through the iterative optimization of feasible designs. To this end, we introduce Frontier-Eng, a human-verified benchmark for generative optimization -- an iterative propose-execute-evaluate loop in which an agent generates candidate artifacts, receives executable verifier feedback, and revises them under a fixed interaction budget -- spanning 47 tasks across five broad engineering categories. Unlike previous suites, Frontier-Eng tasks are grounded in industrial-grade simulators and verifiers that provide continuous reward signals and enforce hard feasibility constraints under constrained budgets. We evaluate eight frontier language models using representative search frameworks, finding that while GPT 5.4 achieves the most robust performance, the benchmark remains challenging for all models. Our analysis suggests a dual power-law decay in improvement frequency (∼ 1/iteration) and magnitude (∼ 1/improvement count). We further show that although width improves parallelism and diversity, depth remains crucial for hard-won improvements under a fixed budget. Frontier-Eng establishes a new standard for assessing the capacity of AI agents to integrate domain knowledge with executable feedback to solve complex, open-ended engineering problems.
Figures & tables
Figure 1: Overview of Frontier-Eng. Top: We contrast binary-reward agent benchmarks (search/coding with pass–fail style outcomes) against generative optimization , where an agent repeatedly proposes code edits, receives verifier feedback, and improves under a fixed interaction budget. Bottom left: Frontier-Eng covers 47 tasks across five engineering categories, spanning heterogeneous artifact types, objective structures, and simulator families. Bottom right: The integration pipeline enforces read-only evaluators, isolated execution, feasibility validation, and verifier-parsed scoring, so gains must come from genuine solution improvement rather than reward hacking.
Figure 2: Method and benchmark composition overview of Frontier-Eng. The figure summarizes the unified task interface τ=(C,x0,E) , the iterative propose–evaluate–improve loop under a fixed budget, and the benchmark-level aggregation pipeline for cross-task comparison; it also shows the data composition of the benchmark, which contains 47 tasks organized into five engineering categories.
Figure 3: Case study under openevolve for SustainableDataCenterControl . The figure illustrates how policies evolve from the contributor baseline through repeated propose–evaluate–improve iterations under a fixed verifier and budget. It highlights representative optimization trajectories and final outcomes across model families, emphasizing three practical signals: improvement speed in early iterations, achievable feasible gain over baseline, and stability of late-stage refinements.
Task
Opus
Qwen
Seed
GPT
OSS
GLM
DS
Grok
Gemini
Aerodynamics / CarAerodynamicsSensing
8
⋆ 2
8
4
6
5
⋆ 2
8
⋆ 2
Astrodynamics / MannedLunarLanding
4
8.5
6
2
5
⋆ 1
3
8.5
7
ComputerSystems / MallocLab
⋆ 1
8
7
9
4.5
2
4.5
3
6
Cryptographic / AES-128
4
9
8
⋆ 1
3
7
2
5
6
Cryptographic / SHA-256
4
8
5
⋆ 1
2
6
9
3
7
Cryptographic / SHA3-256
5
7
3
⋆ 1
2
4
6
9
8
Table 2: Within-task rank comparison of nine foundation models on the full 47-task set under openevolve (100 iterations, same initial programs, same frozen verifiers), with gpt-5.4 replaced by its retest results under the same protocol. Header abbreviations are unified as: Opus = claude-opus-4.6 , Qwen = qwen3-coder-next , Seed = seed-2.0-pro , GPT = gpt-5.4 , OSS = gpt-oss-120b , GLM = glm-5 , DS = deepseek-v3.2 , Grok = grok-4.20 , Gemini = gemini-3.1-pro-preview . Rank 1 denotes the best model on that task; ties receive average ranks. Bold with a superscript star marks the best (lowest) rank in each row. The Average row reports mean within-task rank over all 47 tasks (lower is better).
Figure 4: Aggregate diagnostics of nine models on all 47 tasks under openevolve , after replacing gpt-5.4 with the retest results. Left: Dolan–Moré performance profile (higher and more left-shifted curves indicate better performance). Ratios are computed on per-task translated scores (see Section 2.4 ): α=1.0 means a model attains the task-best translated score (including ties), while α=1.1 means the translated score is at least 1/1.1≈90.9% of the translated best. Under this definition, gpt-5.4 is best on 24/47 tasks ( 51.1% ), and is within the 1.1 near-best band on 33/47 tasks ( 70.2% ). Right: Win rate over baseline (fraction of tasks for which the model’s best score exceeds the initial score).
Framework
Opus Rank
OSS Rank
Opus Wins
OSS Wins
Ties
abmcts
⋆ 1.43
1.55
⋆ 26
20
1
openevolve
⋆ 1.28
1.64
⋆ 30
13
4
shinkaevolve
⋆ 1.28
1.62
⋆ 29
13
5
Table 3: Average ranks, wins, and ties of the two models under the three search frameworks on all tasks. We use Opus = claude-opus-4.6 and OSS = gpt-oss-120b . A win is counted when one model’s best score is strictly higher on a task; ties are listed separately. For rank aggregation, each task assigns rank 1 to the better model and rank 2 to the other model, while ties assign rank 1 to both models. Bold with ⋆ marks the better model in each row (lower is better for ranks; higher is better for wins).
Model + Framework
gain(%)
early-share
last-improve
best-updates
plateau
Opus + abmcts
61.6
0.89
0.53
4.0
0.65
Opus + openevolve
⋆ 73.3
0.97
⋆ 0.70
5.5
0.51
Opus + shinkaevolve
72.9
0.95
0.44
4.0
0.62
OSS + abmcts
50.4
⋆ 0.99
0.30
3.0
0.72
OSS + openevolve
58.9
⋆ 0.99
0.53
⋆ 6.0
0.57
OSS + shinkaevolve
68.3
0.89
0.64
5.0
⋆ 0.45
Table 4: Trajectory tendency statistics for each model–framework combination, with Opus = claude-opus-4.6 and OSS = gpt-oss-120b . Metrics are defined as: gain (median baseline-relative improvement), early-share (fraction of total improvement achieved in the first quarter), last-improve (normalized step index of the final improvement; larger is later), best-updates (count of running-best updates), and plateau (longest no-improvement fraction). Bold with ⋆ marks the best value in each metric column (higher is better for gain, early-share, last-improve, and best-updates; lower is better for plateau).
Figure 5: Dual −1 power-law decay in improvement dynamics across 47 tasks (GPT-OSS-120B, OpenEvolve , 500 iterations). (a) Histogram of improvement events by iteration; dashed line is a ∝t−1 fit ( R2=0.84 ). (b) Median normalized improvement magnitude by improvement rank k within each task’s trajectory; dashed line is a ∝k−1 fit, showing that improvement size shrinks with ordinal rank just as improvement frequency shrinks with iteration.
Figure 6: Normalized best-of- n score across depth and width configurations (GPT-OSS-120B, OpenEvolve ). Each cell shows the mean normalized score for n chains each run to depth d . Scores are normalized per task by the maximum across all configurations. Red borders mark n×d=256 : scores decrease with n , showing depth dominates width.
Benchmark
Interactive env.
Hard constraints
Exec. verifier
Cross- domain
Best-found under budget
Engineering QA benchmarks
Transportation systems ( Syed and others, 2024 )
×
×
×
×
×
Control engineering ( Kevian and others, 2024 )
×
×
×
×
×
EEE-Bench ( Li et al., 2024 )
×
×
×
×
×
CIRCUIT ( Skelic et al., 2025 )
×
×
×
×
×
Open-world agent benchmarks
Table 5: Selected adjacent benchmarks and the comparison dimensions used to position Frontier-Eng. ✓ , × , and ✓ denote that a property is fully present, absent, or partially present (e.g., for some tasks or only indirectly emphasized). “Hard constraints” refers to explicit valid/invalid conditions beyond answer accuracy alone. “Best-found under budget” refers to evaluation by the best feasible solution found within a fixed interaction budget.
Appendix figures & tables6 assets
Supplementary material from the paper’s appendix.
Appendix
Task
Best Combination
Final Score
Runner-up Combination
Final Score
MallocLab
Claude + OpenEvolve
97.00
Claude + ShinkaEvolve
97.00
BatteryFastChargingProfile
Claude + OpenEvolve
120.80
Claude + ABMCTS
113.53
InventoryOptimization_general_meio
Claude + OpenEvolve
0.9929
Claude + ShinkaEvolve
0.9694
SHA3-256
Claude + OpenEvolve
28.90
GPT-OSS + ABMCTS
24.42
Appendix
Table 6: Final-score comparison across models and frameworks for the four focus cases.
Figure 7: Running-best staircase plots for MallocLab .
Figure 8: Running-best staircase plots for BatteryFastChargingProfile .
Figure 9: Running-best staircase plots for InventoryOptimization_general_meio .
Figure 10: Running-best staircase plots for SHA3-256 .
Task
Baseline
Claude
DeepSeek
Gemini
GLM
GPT-5.4
Grok
Qwen
Seed
GPT-OSS
Aerodynamics_CarAerodynamicsSensing
0.9617
0.9624
0.9632
0.9632
0.9628
0.96307
0.9624
0.9632
0.9624
0.9625
Astrodynamics_MannedLunarLanding
4577.437
6027.3126
6079.2455
4674.9462
6839.0331
6660.94
4577.437
4577.437
4733.0435
5589.881
ComputerSystems_MallocLab
28
96
53
48
86
28
57
32
38
53
Cryptographic_AES-128
7.5209
11.8617
12.4591
10.2396
7.9669
39.825
10.8615
5.5501
7.9481
12.1639
Cryptographic_SHA-256
9.8274
16.7955
9.718
9.942
15.1655
26.3405
17.2504
9.8475
15.2838
20.4245
Cryptographic_SHA3-256
16.0932
17.4003
17.0749
16.2255
17.5778
37.4451
16.0594
16.5292
18.3478
19.5513
Appendix
Table 7: Raw per-task scores underlying the Experiment 1 model comparison in Section 3.1 (Table 2 ).
Large Language Model (LLM) agents are increasingly applied to engineering design tasks, yet existing evaluation frameworks do not adequately address multi-agent systems that combine simulation, retrieval, and manufacturing preparation. We introduce a benchmark suite with three evaluation dimensions: (1) a workflow benchmark with seven prompt styles targeting distinct cognitive demands-including direct tool use, semantic disambiguation, conditional branching, and working-memory tasks; (2) a Retrieval-Augmented Generation (RAG) benchmark with gated scoring isolating retrieval contributions to parameter selection; and (3) an High Performance Computing (HPC) benchmark evaluating end-to-end ML training orchestration on a SLURM cluster. Alongside the benchmark we present EngiAI, a Multi-Agent System (MAS) reference implementation built on LangGraph that operationalizes the benchmark by coordinating seven specialized agents through a supervisor architecture, unifying topology optimization, document retrieval, HPC job orchestration, and 3D printer control. Across four LLM backends and two EngiBench problems, proprietary models achieve 96-97% average task completion on Beams2D, while open-source 4B-parameter models reach 55-78%, with clear generational improvement. Conditional branching proves most challenging, with task completion dropping to 20-53% for the conditional style on Photonics2D. RAG gating confirms near-perfect retrieval-augmented scores (about 1.0) versus near-zero without retrieval, validating the evaluation design. On HPC orchestration, one model completes all pipeline steps in 100% of runs while another drops to 50%, revealing that multi-step instruction following degrades over long-running workflows.
Generative optimization uses large language models (LLMs) to iteratively improve artifacts (such as code, workflows or prompts) using execution feedback. It is a promising approach to building self-improving agents, yet in practice remains brittle: despite active research, only 9% of surveyed agents used any automated optimization. We argue that this brittleness arises because, to set up a learning loop, an engineer must make ``hidden'' design choices: What can the optimizer edit and what is the "right" learning evidence to provide at each update? We investigate three factors that affect most applications: the starting artifact, the credit horizon for execution traces, and batching trials and errors into learning evidence. Through case studies in MLAgentBench, Atari, and BigBench Extra Hard, we find that these design decisions can determine whether generative optimization succeeds, yet they are rarely made explicit in prior work. Different starting artifacts determine which solutions are reachable in MLAgentBench, truncated traces can still improve Atari agents, and larger minibatches do not monotonically improve generalization on BBEH. We conclude that the lack of a simple, universal way to set up learning loops across domains is a major hurdle for productionization and adoption. We provide practical guidance for making these choices.
Frontier language models now score above 90% on popular knowledge benchmarks and are increasingly deployed as agents that carry out multi-hour professional work. Yet no existing benchmark tests whether they can perform the real-world, economically valuable work of a professional physical engineer, such as modelling physics and legal code requirements across a multi-format project corpus, optimising material and installation costs, and issuing 2D/3D engineering design packages that a licensed reviewer would sign off on. Existing engineering benchmarks focus on textbook question answering, isolated tool calls or self-contained toy design problems. As a result, most of these benchmarks are already saturated by leading agents and solving them is far away from delivering real engineering design. We introduce PLE, a benchmark of 85 long-horizon, agentic tasks in professional physical engineering consisting of electrical, civil, structural and mechanical engineering, where solving a task means completing a realistic, billable engineering deliverable. PLE combines two complementary curation paths. Expert-Authored tasks are created end to end by practising engineers from a professional data provider's expert pool. Co-Authored tasks start from problem statements written by practising engineers; an adversarial Creator-Solver agent pipeline constructs each task's realistic project environment, executable grader and reference deliverables before sending them to expert engineers for validation and difficulty intensification. We evaluate a variety of frontier LLMs under seven publicly available agent harnesses. Even the strongest configuration reaches a mean score of only 50.6%, while spending 27M tokens and 63 minutes per task on average, demonstrating the substantial gap between current agents and autonomous physical engineering design.