HeurEvo: Agentic Evolution of Hybrid Solver-Augmented Heuristics for Time-Critical Mathematical Optimization

• Prior automated heuristic design often changes components within fixed procedures, while solver-oriented work tunes configurations without changing the solver’s overall procedure, leaving complete hybrid-algorithm design underexplored.The stated open question is how agents can jointly evolve algorithm composition and implementation within a fixed execution-time budget.Source: §1 · pp. 1–2
• HeurEvo jointly evolves algorithm plans, executable implementations, and reusable components, with planning, coding, component updates, and execution feedback coordinated across islands.The planner selects and orders components and allocates runtime; the coder implements plans, and the component evolver refines the shared pool using accumulated experience.Source: §1 · p. 2
• With a two-minute budget, mean gaps were −2.22% on synthetic training instances and −1.45% on held-out tests versus Gurobi’s 48-hour incumbents, outperforming them on eight training and seven test tasks.The paper also reports improvements on four of six MIPLIB-NL training problems and numerically better objectives than reported references on several nonlinear geometry problems.Source: §1 · p. 2
• Ablations support adaptive plan review and component evolution, while HeurEvo with AdaEvolve refinement reports numerically better objectives than references on several nonlinear geometry problems.On the illustrated orienteering instance, greedy construction and large neighborhood search precede selected-subproblem solving, polishing, and cleanup; the resulting gap is lower than the illustrated AdaEvolve and ReEvo (ACO) programs.Source: §1 · pp. 2–3, Figure 1 · p. 3

Island-based evolutionary program search

• Island-based program-search frameworks use execution feedback and population-based evolution; OpenEvolve combines MAP-Elites, exploratory and elite parent sampling, and migration, while AdaEvolve and EvoX add adaptive search controls or co-evolved search policies.Examples include FunSearch, AlphaEvolve (Novikov et al., 2025), OpenEvolve, AdaEvolve (Cemri et al., 2026), and EvoX (Liu et al., 2026).Source: §2 · p. 3

• HeurEvo explicitly represents a hybrid algorithm as heuristic and solver components composed into an ordered plan, while code evolution separately refines implementation and component evolution updates reusable building blocks.The plan can specify subgoals and allocate shared runtime across its steps.Source: §2 · pp. 3–4

Automatic Heuristic Design for Optimization Problems

• LLM-based heuristic methods range from evolving single heuristics to jointly evolving interacting components, but operate within predefined algorithmic roles or solver structures; whole-program methods leave composition implicit.Examples include ReEvo (Ye et al., 2024), MILP-Evo (Nie et al., 2026), MOTIF, MuEvo (Lv et al., 2026), and ATLAS (Yazdani et al., 2026).Source: §2 · p. 3

3.1 PROBLEM FORMULATION AND HYBRID ALGORITHM COMPOSITION

• A plan orders reusable heuristic or solver components and assigns each a subgoal, implementation guidance, and time budget; executable code passes intermediate results between steps under the total runtime limit.Code evolution can change implementation guidance and step allocations, while changes to the ordered components or subgoals require plan evolution.Source: §3.1 · p. 4

3.2 OUR PLAN-CODE-COMPONENT CO-EVOLUTION FRAMEWORK

• HeurEvo jointly evolves algorithmic plans, executable code, and reusable components, separating changes to algorithm structure from changes to step implementations.Component evolution revises descriptions, adds absent components, or removes persistently ineffective ones; code evolution preserves the plan’s ordered steps.Source: §3.2 · pp. 5–6
• Each plan-conditioned island has its own active code population and plan-specific feedback, while islands share a component library and archive of evaluated programs.The workflow uses UCB to select an island; interpreter feedback guides code refinement, plan revision, and component-library updates.Source: §3.2 · pp. 5–6, Figure 2 · p. 5

3.3 ISLAND-BASED EVOLUTION PROCEDURE

• UCB allocates search across islands using recent rewards and visit counts, while a plateau threshold determines whether an island continues code refinement or reviews its plan.Rewards are positive for improvements to an island’s best solution, with larger rewards for closing a greater fraction of its gap to the global best.Source: §3.3 · p. 6
• With a fixed plan, code refinement preserves selected components and ordered subgoals; when progress stalls, plan review proposes a revised composition and starts a new population.Previous-plan programs remain available as inspiration but are no longer eligible as parents after plan revision.Source: §3.3 · pp. 6–7
• Component evolution uses experience across islands to refine the shared component pool, but does not directly change any island’s current plan.Plan changes occur through plan review.Source: §3.3 · p. 7

4.1 EXPERIMENTAL SETUP

• The evaluation covers 11 synthetic tasks, six MIPLIB-NL-derived problems, and four nonlinear geometry families, with 200 generated programs and a two-minute evaluation limit per instance.Synthetic evaluation uses five training, two validation, and four held-out test instances per task; MIPLIB reports training results only.Source: §4.1 · p. 7

4.2 MAIN RESULTS

• −2.22% training and −1.45% test mean gaps: HeurEvo outperforms Gurobi’s 48-hour solutions on 8 of 11 synthetic training problem classes and 7 of 11 test classes.Its mean training gap remains lowest through subsequent search, and it attains best or tied-best training gaps on five representative classes among full-coverage program-evolution baselines.Source: §4.2 · pp. 7–8, Table 2 · p. 8, Table 3 · p. 8
• HeurEvo achieves better training objectives than AdaEvolve on four of six MIPLIB-derived problems, while AdaEvolve does better on the other two.Relative to AdaEvolve, HeurEvo reduces the objective by 10.70% on comp12-2idx, 3.60% on graphdraw-grafo2, and 4.71% on graphdraw-mainerd; it increases the objective by 0.80% on opm2-z12-s8.Source: §4.2 · p. 8, Table 4 · p. 8
• HeurEvo followed by AdaEvolve refinement improves on standalone AdaEvolve in all eight selected nonlinear configurations and is numerically better than listed references in five.The reference comparisons are limited to reported precision and do not establish improvement over an unrounded solution.Source: §4.2 · pp. 8–9, Table 5 · p. 9

4.3 ABLATION STUDIES

• Combining adaptive plan review with component evolution yields the best mean training, validation, and test gaps: −2.22%, −2.22%, and −1.45%, respectively.Compared with adaptive plan review alone, the combined method lowers training and test gaps by 0.87 and 1.24 percentage points, respectively.Source: §4.3 · p. 9
• Five distinct initial plans generated from the full component library achieve the lowest training gap, −2.22%, improving on the three tested alternatives by 0.91, 0.46, and 0.81 percentage points.The comparison supports both initial-plan diversity and access to the full component library.Source: §4.3 · p. 9, Table 7 · p. 9

5 CONCLUSION

• With a two-minute execution budget, evolved heuristics outperform Gurobi’s 48-hour solutions on seven of eleven synthetic tasks and report additional gains on MIPLIB and nonlinear problems.The conclusion also reports comparisons with several competitive LLM-based evolution baselines.Source: §5 · p. 9
• HeurEvo jointly evolves algorithmic structure, implementation, and reusable components through execution feedback, using plan-conditioned islands and adaptive plan review.The framework also maintains a shared component library.Source: §5 · p. 9
• The conclusion identifies joint evolution of algorithmic structure and implementation, rather than isolated heuristic-component optimization, as valuable for agentic heuristic design.Source: §5 · p. 9

AI USE STATEMENT

• LLMs were used in experiments, to polish the initial manuscript draft, and to generate code for constructing optimization instances.Source: AI USE STATEMENT · p. 10
• Authors reviewed revised text, and human-written evaluators checked generated instances against experimental assumptions and requirements.Source: AI USE STATEMENT · p. 10
• Coding agents assisted with implementation, which human experts reviewed; the authors take full responsibility for the manuscript and research artifacts.Source: AI USE STATEMENT · p. 10

A ADDITIONAL EXPERIMENTS

• Each generated program runs single-threaded on one CPU core with a 120-second per-instance limit, and evolution is capped at 200 programs.Gurobi 13.0.2 is the only permitted optimization solver; Table A8 lists default hyperparameters and ablation variations.Source: A ADDITIONAL EXPERIMENTS · p. 14, Table A8 · p. 14

A.1 STANDARD SYNTHETIC PROBLEMS

• Sparse task coverage prevents EoH, ReEvo, and RefineEvo from running all 11 tasks, so they are excluded from the mean-gap comparison.OpenEvolve is also excluded from the test mean for OP because its evaluation coverage is incomplete.Source: §A.1 · pp. 14–15
• HeurEvo’s mean gaps are −2.22% on training and −1.45% on test, versus AdaEvolve’s −0.15% and +0.91%, respectively.The full training and test results appear in Tables A9 and A10.Source: §A.1 · p. 15, Table A9 · p. 15, Table A10 · p. 15

A.2 MIPLIB-DERIVED PROBLEMS

• HeurEvo finishes graphdraw-grafo2 at 82003.10 versus AdaEvolve’s 85061.30, while AdaEvolve finishes comp21-2idx at 100.40 versus HeurEvo’s 103.20 and sct32 at −3.01 versus HeurEvo’s near −2.77.Figure 4 plots mean objectives over generated programs, averaged across five training seeds.Source: §A.2 · pp. 15–16, Figure 4 · p. 16
• HeurEvo gains an advantage within the first few dozen programs on comp12-2idx, graphdraw-mainerd, and opm2-z12-s8, but late improvements can change final rankings.On graphdraw-grafo2, HeurEvo finishes lower after late-stage gains despite AdaEvolve leading during the middle of training.Source: §A.2 · pp. 15–16

A.3 NON-LINEAR GEOMETRY PROBLEMS

• Across 14 nonlinear task-size configurations, HeurEvo has better objectives than AdaEvolve in 11, ties one, and performs worse in two.It improves on all three rectangle-packing and all four distance-ratio configurations, plus four of five hexagon-packing configurations; for hexagon packing at n = 16, the 1.812 × 10^-7 improvement leaves the objective slightly above the reported reference.Source: §A.3 · p. 16

A.4 FULL ABLATION RESULTS ON SYNTHETIC PROBLEMS

• Across all 11 synthetic tasks, HeurEvo achieves the lowest gap on five tasks in each split, leading on C-CVRP, U-CVRP, TSP, and PFSS in both training and testing.Tables A12 and A13 report training and test gaps, respectively.Source: §A.4 · p. 16, Table A12 · p. 17, Table A13 · p. 17
• HeurEvo outperforms Adaptive plan only on nine tasks and Component only on eight tasks in each split.Compared with Always-plan + component, it achieves lower gaps on seven training tasks and six test tasks.Source: §A.4 · p. 16
• The full-task comparisons support combining adaptive plan review with component evolution for both training performance and generalization.Source: §A.4 · p. 16

A.5 ISLAND INITIALIZATION ABLATIONS

• With five islands, HeurEvo’s distinct initial plans improve on Shared plan on seven validation tasks and lower test gaps on U-CVRP, OP, and RCPS.For OP, the test gap decreases from +3.85% to −1.94%; Tables A14 and A15 report validation and test gaps.Source: §A.5 · p. 18, Table A14 · p. 18, Table A15 · p. 18
• Compared with Single island, Shared plan lowers test gaps on six tasks, including U-CVRP, which improves from +2.09% to −2.96%.The island count is increased while the shared initial plan is retained.Source: §A.5 · p. 18
• Although individual tasks favor different configurations, the results support both multiple islands and diversity in their initial plans.Source: §A.5 · p. 18

B.1 DATASET COMPOSITION

• The collections comprise 11 synthetic tasks spanning 10 mathematical families and six MIPLIB-derived tasks across four application domains.Source: §B.1 · p. 19
• Synthetic tasks use seeds 0–4 for training, 5–6 for validation, and 7–10 for testing; MIPLIB experiments use five training instances per task.Instances include natural-language descriptions, CSV inputs, an initial Gurobi formulation, and a task-specific validator.Source: §B.1 · p. 19
• Synthetic and MIPLIB fitness compares a program’s verified feasible-solution objective with a fixed Gurobi 48-hour bound, not its best feasible solution.For minimization the bound is a lower bound; for maximization it is an upper bound.Source: §B.1 · p. 19
• Nonlinear fitness transforms the objective by optimization direction and uses one training instance per configuration; these scores differ from reported signed gaps.Source: §B.1 · p. 19

B.2 SYNTHETIC PROBLEMS

• Synthetic task sizes are fixed, although realized edge counts, precedence counts, and demand-derived fleet sizes can vary across instances.Reported numerical ranges cover all 11 stored instances per task; coordinates are stored to six decimal places for TSP, both CVRP configurations, and orienteering.Source: §B.2 · p. 20
• Decap placement seeds yield essentially the same optimization model, so its nominal split does not measure generalization to substantively different instances.Source: §B.2 · p. 20

B.3 MIPLIB-DERIVED PROBLEMS

• The six MIPLIB-derived tasks are selected base problems that Gurobi did not certify optimal within two hours during initial screening, with five training instances each.The tasks cover course scheduling, graph drawing, mining-project selection, and PCB assembly-line configuration.Source: §B.3 · p. 22

B.3.1 GENERATING MIPLIB TRAINING INSTANCES

• Five training instances are generated for each of six reconstructed base problems, with variable counts unchanged and selected relationships or coefficients varied.Seed0 retains the base data; seed1–seed4 vary selected data while preserving task-specific structures.Source: §B.3.1 · p. 23
• Timetabling perturbations preserve course and capacity keys while changing unavailability, selected conflict pairs, lecture-count/minimum-day assignments, and capacity-penalty weights.Unavailable periods retain each course’s total count, and conflict changes use degree-preserving swaps.Source: §B.3.1 · p. 24
• Graph drawing preserves entity data, placement windows, sizes, edge count, degree sequence, and edge weight while recomputing edge-distance coefficients.Mining-project selection retains dependency arcs and resource capacities but perturbs values and costs, which can change the feasible set; PCB assembly jitters designated numeric columns while retaining identifiers, categorical flags, table structure, and scalar parameters.Source: §B.3.1 · p. 24
• All 30 training instances receive VALID feasibility and objective-consistency checks, but these checks do not certify optimality.Timetabling guards are screening conditions rather than feasibility guarantees; proven-infeasible draws are resampled, and seeds, perturbations, attempts, and check results are recorded.Source: §B.3.1 · p. 24

B.3.2 MIPLIB MODEL SIZES

• Each of the six MIPLIB-derived problems has the same variable count across its 11 instances, while constraint counts may vary.Table B19 reports pre-presolve formulation sizes for 11 synthetic and six MIPLIB-derived tasks, with general constraints separate from linear constraints.Source: §B.3.2 · p. 24, Table B19 · p. 24

B.4 NONLINEAR GEOMETRY BENCHMARKS

• The problems are drawn from Berthold et al. (2026b), revisiting settings studied in AlphaEvolve (Georgiev et al., 2025; Novikov et al., 2025), and use Berthold et al.’s nonlinear formulations.The authors wrote their own natural-language descriptions and mathematical formulation files, and evolve heuristics separately for each problem–size configuration.Source: §B.4 · p. 25
• The benchmark collection includes circle packing, distance-ratio optimization, and hexagon packing, each defined by a distinct geometric objective and constraint setting.Circle packing maximizes summed radii; distance-ratio optimization minimizes the maximum-to-minimum pairwise-distance ratio; hexagon packing minimizes the container side length.Source: §B.4 · p. 25
• The collection contains 14 fixed configurations, with n denoting the number of geometric objects and d the point-configuration dimension.These configurations have no separate training, validation, and test instances; their seed directories identify problem sizes, and they are additional to the 151 instances reported in Table B16.Source: §B.4 · pp. 25–26, Table B20 · p. 25

C.2 AGENT DESCRIPTION

• The Component Proposer supplies 10–20 distinct high-level components, while the Component Improver uses contribution histories and Interpreter feedback to refine or remove eligible components.The Coder implements plan steps in order and reports step outcomes and cumulative runtime; the Debugger repairs or regenerates failed programs, which are evaluated again.Source: §C.2 · pp. 27–28
• Ordinary code evolution preserves ordered subgoals and selected components while revising implementations; the Plan Improver can instead add, remove, replace, or reorder steps.The Code Improver may revise algorithms, data structures, runtime allocations, and adjacent-step interactions, or deactivate a step; plan proposals provide annotations and time allocations for the Coder.Source: §C.2 · pp. 27–28
• The Interpreter analyzes code and execution feedback without seeing optimization solutions, producing change summaries plus code-, plan-, and component-level reports.Its reports track measured outcomes and implementation directions, assess step usefulness and runtime allocation, and consolidate lessons and proposed operations for each used component.Source: §C.2 · p. 28

C.3 INITIALIZATION

• Initialization builds a component library, creates K plans and validated island seeds, then performs W local code-improvement visits per island before global scheduling.Component descriptions stay unchanged during these initial visits; seed generation continues until validation succeeds, while failed bounded child debugging yields no child or reward.Source: §C.3 · pp. 28–29

C.4 EVOLUTION

• Each global round selects an island using pre-round UCB statistics, with recent normalized progress rewarding visits and an exploration term favoring under-visited islands.A validated child’s reward reflects its gain over the island incumbent relative to that island’s pre-update gap to the global incumbent; invalid visits update statistics once with zero reward and improvement.Source: §C.4 · pp. 29–30
• When an island meets the plateau criterion, a plan proposal starts a new generation only after its seed validates; failure preserves the old plan and resumes ordinary code improvement.A successful restart installs the seed as incumbent, resets discounted generation statistics but not cumulative visit counts, and schedules W consecutive local visits.Source: §C.4 · pp. 30, 32
• Each evolution visit selects eligible programs, generates a plan-aware child, validates or debugs it, and compares the final validated child with its selected parent.Rejected versions are not inserted, and an unrepaired child receives no normal parent–child performance interpretation.Source: §C.4 · p. 33
• Database updates use pre-evaluation incumbents; failed visits fabricate no fitness or insertion, discount prior positive reward, and do not end the local visit block.The interpreter compares against the sampled parent, whereas scheduling measures progress against the island incumbent; validated children and their feedback and measurements are recorded in the database.Source: §C.4 · p. 33
• Existing components are reviewed only when active, used by the selected plan, and supported by observations; revision clears that component’s history, while removal is deferred in stored plans.Local visits proceed sequentially with updated state, and component review yields the library for subsequent rounds.Source: §C.4 · pp. 33–34

C.5 COMPONENT CONTRIBUTION AND REVIEW

• Step contributions normalize progress against historical first-step performance, whole-program improvement, or the better of final fitness and the pre-evaluation global incumbent.Lower contribution increases review probability without requiring revision; one observation under the current description is enough for eligibility, and revised components start with cleared histories.Source: §C.5 · pp. 34–35

D PROMPT TEMPLATES

• The prompt templates share task context and reporting requirements while filling placeholders with task-specific details, plans, and evaluation feedback.The appendix provides templates for initial solver generation and plan-aware code evolution.Source: D PROMPT TEMPLATES · p. 35

D.1 TASK CONTEXT AND SUBSTITUTION FIELDS

• Task context includes the problem description, runtime parameters, data schema, mathematical model, and reference Gurobi code, which is authoritative over conflicting prose.CSV rows are not embedded; generated programs must read them and parse runtime parameters, which may vary across executions. Prompt fields also provide plans, scoring, feedback, program history, and guidance.Source: §D.1 · p. 36

D.2 SHARED INTERMEDIATE-REPORT CONTRACT

• Programs must print a complete solution report after every plan step and at termination, repeating the current best report when a step does not improve it.Each step block follows plan order and is followed by cumulative wall-clock output time; the final report is mandatory even when it duplicates the last step.Source: §D.2 · pp. 36–37

D.3 INITIAL PROGRAM GENERATION

• Initial generation must implement every required plan operation, use Gurobi as the only optimization backend, and preserve the validated plan’s runtime semantics.Complete steps run to their stopping rule; budget-controlled work must spend its shared budget on useful strategy work without overrunning, and hybrid steps execute the complete portion before budgeting the bounded portion.Source: §D.3 · pp. 37–39
• A final `remaining time` step uses one shared start time to compute its budget, charges setup and reporting to that budget, and skips only bounded improvement work when time runs out.The solver limit must be based on time remaining at the call, after model construction, while reserving time for extraction and the required report.Source: §D.3 · p. 39
• Generated programs must faithfully implement every required annotation and execute every plan step in order, unconditionally, with substantive operations and the best feasible incumbent passed forward when applicable.Fallbacks must preserve required work when preferred inputs or solver results are unavailable; gurobipy is the sole mathematical optimization backend.Source: §D.3 · pp. 39–41

D.4 PLAN-AWARE CODE EVOLUTION

• Code evolution keeps each step’s identity, strategy, and subgoal fixed, but permits implementation changes within the same strategy family and runtime edits, including dropping a step via a zero-second estimate.Steps cannot be added, deleted, renumbered, reordered, or merged; annotations must match the revised code.Source: §D.4 · pp. 43–44
• Runtime estimates represent C for complete-algorithm steps, B for budget-controlled steps, and C + B for hybrid steps; the final budget-controlled step may instead use `remaining time`.For steps with execution output, derive runtime from differences between cumulative times; prefer measurements to inherited predictions and recalibrate reimplemented steps against measured work.Source: §D.4 · pp. 44–45
• Only B is allocatable: keep numeric estimates within the runtime allowance, direct time toward improving steps, reduce or drop stagnant ones, and leave unusable remainder unspent.A `remaining time` estimate instead gives the final step the allowance left after elapsed time, clamped at zero; the program must not enforce a global deadline.Source: §D.4 · pp. 44–46