An Agentic Framework with LLMs for Solving Complex Vehicle Routing Problems
Authors: Ni Zhang
Zhiguang Cao
Jianan Zhou
Cong Zhang
Yew-Soon Ong
Venue: ICLR 2026 Poster (2026)
Keywords: Vehicle Routing Problems
Agent
LLM
Primary area: optimization
TL;DR: We propose a fully automation LLM agent for solving complex vehicle routing problem

Abstract: Complex vehicle routing problems (VRPs) remain a fundamental challenge, demanding substantial expert effort for intent interpretation and algorithm design. While large language models (LLMs) offer a promising path toward automation, current approaches still rely on external intervention, which restrict autonomy and often lead to execution errors and low solution feasibility. To address these challenges, we propose an Agentic Framework with LLMs (AFL) for solving complex vehicle routing problems, achieving full automation from problem instance to solution. AFL directly extracts knowledge from raw inputs and enables self-contained code generation without handcrafted modules or external solvers. To improve trustworthiness, AFL decomposes the overall pipeline into three manageable subtasks and employs four specialized agents whose coordinated interactions enforce cross-functional consistency and logical soundness. Extensive experiments on 60 complex VRPs, ranging from standard benchmarks to practical variants, validate the effectiveness and generality of our framework, showing comparable performance against meticulously designed algorithms. Notably, it substantially outperforms existing LLM-based baselines in both code reliability and solution feasibility, achieving rates close to 100% on the evaluated benchmarks.

Published as a conference paper at ICLR 2026
AN AGENTIC FRAMEWORK WITH LLMs FOR SOLVING COMPLEX VEHICLE ROUTING PROBLEMS
Ni Zhang', Zhiguang Cao',; Jianan Zhou², Cong Zhang?, Yew-Soon Ong²
School of Computing and Information Systems, Singapore Management University. Singapore
2 College of Computing and Data Science, Nanyang Technological University, Singapore ni. zhang. 2025@phd2eee @0hdcs smu, edu. sd, zgcao@amu. edu. .g j fianan004@e ntu. sg, cong. zhang928gmail com, asysongentu. edu.
ABSTRACT
Complex vehicle routing problems (VRPs) remain fundamental challenge, de- manding substantial expert effort for intent interpretation and algorithm design. While large language models (LLLMs) offer promising path toward automation, current approaches still rely on external intervention, which restrict autonomy and often lead to execution errors and low solution feasibility. To address these chal- lenges, we propose an Agentic Framework with LLMs (AFL) for solving com- plex vehicle routing problems, achieving full automation from problem instance to solution. AFL directly extracts knowledge from raw inputs and enables self- contained code generation without handerafted modules or external solvers. To improve trustworthiness, AFL decomposes the overall pipeline into three man- ageable subtasks and employs four specialized agents whose coordinated interac- tions enforce cross- coss-functional consistency and logical soundness. Extensive ex- periments on 60 complex VRPs, ranging from standard benchmarks to practical variants, validate the effectiveness and generality of our framework, showing parable performance against meticulously designed algorithms. Notably, it sub- stantially outperforms existing LLM-based baselines in both code reliability and solution feasibility, achieving rates close to 100% on the evaluated benchmarks.
INTRODUCTION
Vehicle routing problems (VRPs) are fundamental industrial and commercial applications such as logistics (Bochtis & Sørensen 2010 Konstantakopoulos et al. (022) and transportation (Cattaruzzal
ct al. 2017: 2017)ZZang et al.J 2022). yet they remain challenging to solve due to their diverse variants
with intricate woal-world constraints. Traditional approaches (Furnon & Perron| |Hllggaun, [2017] Vidal 2022; Wouda al., 2024) often require substantial expert effort, either translate problem statements into mathematical formulations or to design specialized algorithms. Although recent neural solvers (Kool et al.) 2018 Kwon et al. (020) alleviate the dependence on domain knowledge, complex VRPs.
they still require a certain degree of manual adaptation to address
More recently, large language models (LLMs) (Zhao et al. 2023). with their strong natural language understanding and code generation capabilities (Ma et al. 2026), may offer promising avenue for automation, reducing reliance on manual effort and enabling flexible solver development across diverse VRP variants. Some early attempts (Yang al., 2024 Liu et al. 2024b) directly prompt LLMs to generate solutions but fall short in terms of solution optimality and reasibility. Other approaches Ekooerr--Paredes as a proxy for addressing challenges in VRP optimization, which can be broadly categorized into two directions. The first direction centers on evolving basic heuristics tailored for conventional VRPs, with representative examples including EoH (Liu et al., (024a) and ReEvo (Ye et al. (024). In contrast, the second direction emphasizes developing general frameworks capable of handling diverse VRP variants, making it more practical and application-orientie
al. 2024) explore the use of L.MSs to generate programming code
Early research efforts have started to address this challenging second direction. Their workflow gen- erally comprises two phases: frumework-design, in which the architecture and generation strategy
"corespponiing author

---

Published as a conference paper at ICLR 2026
Table Comparison of representative LL.M-based approaches for VRPs.
ARS
DRoC
SGE
AFL (This Work)
et al. 2025a
Jiang et al.
2025b
[klassov et al.
2024
Complex VRPs
/
X
Self- S
X
Full Automation
High Trustworthiness"
LLMs produce complete code withou relying on handcrafted modules or external solvers during framework-destee
The entire workflow proceeds from raw input to final solution without human intervention during framework- Achieving high code reliability and solution feastbility (e.g. 95%)..
and framework-executtine in which the resulting framework is deployed to solve diverse problem instances. ARS (Li et al. 2025a) constructs constraint-checking functions by retrieving and adapting templates from a predefined constraint library. while DRoC (Jang et al.] -aggeeee-e generation (RAG) strategy to produce code that invokes OR- Tools (Furnon& & Perron) for problem solving. Although both ARS and DRoC can handle complex VRPs, these module-level generation methods are self-contained, depending handcrafted code modules or externa solvers during Kramwwork-desipe and not fully automated, as they still require human involvement to extract instance-specific information during framework-cxeeuttin.. This dependence may introduce misalignment between --M-eeeeerteed code and external systems, which can result in execution errors and reduced solution feasibility. In contrast, SGE (Iklassov et al. 2024) achieves self-containment but is limited to relatively simple problems like the Traveling Salesman Problem (TSP), as it lacks effective mechanisms for handling complex constraints and fails to provide full automation or reliable code and solution validity. In this paper, summarized in Table D we address these limitations by proposing a general framework collaborative LLM- empowered agents that can tackle complex VRPs with celf-containment, full automation, and high trustworthiness in both code and solutions.
are specified (see Section 3
20236) employs
We introduce Agentic Framework with LLMs (AFL) that solves complex VRPs end-to-end, from problem instance to solution. Specifically, it derives domain knowledge directly from instance inputs and leverages this knowledge guide code generation. To enhance the feasibility and relia- bility of the generated code and the resulting VRP solutions under complex constraints, the pipeline decomposed into three tractable subtasks: problem description, code generation, and solution derivation, each handled by multiple LLM agents tailored to their tasks. In total, we design four specialized agents, including generation agent, judgment agent, revision agent, and error analysis agent, collaborating to ensure cross funstffuntiioal consistency, logical soundness, and constraint satis- faction. The overview of AFL presented in Fig. I follows.
Our main contributions are summarized as
1) Conceptually, we position LLMs as knowledgeable developers of self-contained frameworks for solving complex VRPs, achieving full automation from problem instance solution without reliance on handerafted modules or external solvers.
2) Methodologically, we propose AFL, an agentic LLM framework that decomposes the inherently intractable pipeline into three manageable subtasks and employs four specialized agents to col- laboratively enhance trustworthiness in both code and solutions.
3) Experimentally, we evaluate AFL on 60 VRPs, comprising 48 representative VRPs from the literature, 8 complex electric VRPs from practical scenarios, and classical VRPs in broader settings. Extensive results demonstrate the effectiveness and generality of our framework, show- ing competitive performance against carefully tailored algorithms while delivering superior code reliability and solution feasibility compared to existing -aseed approaches.
2 PRELIMINARIES
The VRP is fundamental combinatorial optimization task. It seeks a set of minimum-cost routes that allow a fleet of vehicles to serve geographically distributed customers while satisfying practi- cal constraints such vehicle capacity, route length, customer time windows. Classic variants include the Capacitated VRP (CVRP), where each vehicle has fixed capacity limit; the VRP with Time Windows (VRPTW), where every customer must be served within specific time interval: and
2

---

Published as a conference paper at ICLR 2026
Table 2: Constraint descriptions and corresponding VRPI.ib-format fields.
Constraint
VRPLib Field
Description
CAPACITY
Each vehicle has maximum load capacity, and each customer is associated with demand that must be sutisfied without exceeding this capacity.
Capacity (C)
DEMAND SECTION
DEMAND,SECTION
DISTANCE LIMIT
Each vehicle route constrained by maximum travel distance, and the total distance of any route must not exceed this limit.
Duration Limit (L)
TIME WINDOW SECTION
Each customer must be served within a specified time interval, and service times must be included in the schedule to maintain feasibility.
Time Windows (TW)
TERVICE.TIME.SECIOON
Vehicles may not be required to return to the depot after serving their assigned customers, relaxing the standard closed-routs rouut assumption.
Open Route (O)
FUEL CAPACITY
Flectric vehicles constrained by limited hattery capacity: they consume energy during travel and refuel at rocharging stations.
FUEL CONSUMPTION RATE
Electric Vehicle (E)
REFUEL RATE
STATION SECTION
DEPOT SECTION
Multiple depots are defined, allowing vehicles start and/or end at different depots, enabling flexible re- source allocation across regions.
Multi Depot (MD)
DEMAND_SECTION
Each route includes both deliveries (linehauls) and pickups (backhauls), where pickups occur after all deliveries.
Backhaul (B)
DEMAND-SECTION
Linehaul and backhaul customers appear in mixed order within the same route.
Mixture Backhaul (MB)
the Electric VRP (EVRP), which incorporates battery capacity and recharging requirements. These formulations capture diverse real-world delivery, ride-sharing, and service-dispatch applications. A detailed introduction to each variant considered in this paper is provided Appendix B
To represent benchmark instances in consistent way, we adopt the VRPLIB format (Uchoa et al., 2017). a plain-text specification similar to TSPLIB (Reinelt 1991). A VRPLIB file begins with general information such as the instance name and optional comment, followed by key sections specifying the problem type, edge weight type, dimension, and the coordinates of each location. Additional sections may cover parameters such vehicle capacity, customer demands (with positive values for linchaul and negative for backhaul), distance limits, depot IDs, time windows, service times, and energy-related data for electric vehicles (e.g., fuel capacity, consumption rate, refueling rate, and charging station locations).
The mapping between constraints and their corresponding VRPLIB fields is summarized in Table 2, with further details on each field provided in Table X in the Appendix. Our AFL directly takes VRPL.B-formee instances as input. We also evaluate AFT. JSON and CSV formats to demonstrate its robustness to different data representations. The results are reported in Section C.11 and Table 17
3 METHODOL.OGY
In this section, we introduce AFL, an agentic LLM framework for solving complex VRPs by struc- turing the pipeline into three subtasks: problem description, code generation, and solution deriva- tion. Within these subtasks, specialized agents, including the generation agent judgment agent (JA), revision agent (RA), and error analysis agent ( (EAA), collaborate to fulfill their respective roles, ultimately enhancing the trustworthiness of both the generated code and the derived solutions under the constraints of the given problem instance.
The overview of AFL is presented in Fig. [ Specifically, given a VRP instance G, the system first generates problem description D(G) through the collaborative operation of the GA, JA. and RA. This problem description is then used to query the buffer which stores previously tested problem codes, to check whether relevant code has been previously stored. If such code exists, the workflow proceeds directly to the solution derivation stage. Otherwise, the GA progressively generates the required functions one by one, while the JA and RA iteratively evaluate and refine the code until it
3

---

Published as a conference paper at ICLR 2026
Subtask I: Problem Description
Subtask 3: Solution Derivation
Descrition Generation
Descriptio Iudgement Revisioo
Cole Excratio
& tii desenption night
ist
Jurgeaicet Ageet
Hingy why?
12502
HOKE rocas JECRIS
Coniideriaa doe dacriptor patgrent, laad reviss descliption
Pydeo
00
Enroc Analysis
Besurtption
Goneration
Gives prebken descrittion codo. and omnn wiy does this omnx oces and how can wshval?
Instance
Agent
Subtask 2: Code Generation
OO Anslyis Apeat
Generatio
Error Analyds
Dearippica
Clantiako
Facad innalddotr syinsmn/.... firctin
Code Revisios
Imllanee
O
000 Julgrment Agual
Oijistrs
Cads
Agost
Code
Problem Diseriptioo
Ageat
Julgeneni
True
lnense Store l'nal Code
fucotioe
False
code zeplain
Enerptie
Claske
Apost
sadgement, noad
zevin cede.
Judgemant and Sugrestio
Justprment
Agpsi
suggestias.
lagel
Dhepa
Codi
Probless Description
Figure Overview an agentic framework with L.LMs for solving complex VRPs.
meets all requirements and constraints. Once complete implementation is produced, it is executed to derive a solution. If execution errors occur, the EAA diagnoses their causes and provides explana- tions and suggestions, which the RA and JA use revise the code. This iterative process continues until the code passes validation and produces a feasible solution. Finally, the corresponding problem description and code stored in the buffer for future reuse. Examples of the agents' prompts and outputs for each subtask are provided in Appendix D In the following, we present each specialized agent and pipeline stage in detail.
3.1 SPECIALIZED AGENT
Generation Agents (GA) are responsible for producing descriptions and code. In the problem description subtask, they generate a description D(G) for the input VRPLib-format instance G. the code generation subtask, they generate function code C(G, D(G), P(J)) in end-to-end manner, guided by the instance, the generated description, and the specific prompts P(S) associated with function f. The resulting description and code are then forwarded to the JA for evaluation.
Judgment Agents (JA) evaluate the validity of the generated description and code. In the problem description subtask. they verify whether D(G) aligns with the instance context. In the code gen- eration and solution derivation subtasks, they further assess whether the generated or revised code satisfies the prompt requirements and is free from syntactic and logical errors. If the judgment is positive, the description or code is accepted and the process advances to the next step. Otherwise, the JA provides explanations of identified issues along with suggestions for resolution by the RA.
Revision Agents (RA) refine both the description and the code. Description revision is guided by the JA's feedback and the instance context, while code revision additionally leverages the previously generated description. After each revision, the updated description or code is returned to the JA for re-evaluation, and this process continues until a positive judgment is reached.
Error Analysis Agents (EAA) operate exclusively in the solution derivation subtask, where they analyze the causes of errors during code execution and provide suggestions for resolving them. The analysis is then passed to the RA for code revision.
3.2 SUBTASK 1: PROBLEM DESCRIPTION
Description Generation. Given VRPLib-formal instance G, our framework automatically extracts domain knowledge from the instance context without human intervention, offering userndfie interface for problem setup. The VRPLib format widely adopted benchmark specification for VRPs, defining essential elements such the problem type, number of nodes, node coordinates,
4

---

Published as a conference paper at ICLR 2026
depot ID. and various constraint- parameters, summarized in Table 2 Based this, the
GA generates the problem description for the given instance D(g) = {P... S. K X, Y. Z}. A detailed example is provided in Appendix D.1 Here, define the components of ((g) follows:
1) P specifies the type of problem (e.g., CVRP, VRPTW, ECVRPTW). It is inferred from the prob- lem type and the constraint-relaeed parameters defined in the instance context, and it determines the name of the generated code file (c.g., CVRP.py).
2) S denotes the textual description of the instance's problem type. It is provided to the code generation subtask to inform the agents about the problem definition.
3) K represents the set of constraints along with their explanations. These derived from the constraint-related parameters and problem type specified in the instance context. In addition, K includes visit and depot constraints, which supplementary requirements automatically analyzed and inferred by the GA. Within the code generation subtask, K guides the agents in embedding these constraints into function design, thereby enhancing the solution feasibility.
4) X denotes the required input for solving the given instance. In the code generation subtask, it specifies the information that must be read from the instance and enforces consistency by requir- ing input variable names to match those in X, thereby reducing potential errors. For example, in CVRP, X includes node coordinates, depot ID, customer demands, and vehicle capacity.
5) Y refers the expected output. For instance, in CVRP, the solver should produce a set of vehicle routes, each starting and ending at the depot, visiting every customer exactly once, ensuring that no vehicle route exceeds capacity and that all demands are satisfied. Moreover, the returned route should represent the best feasible solution among the candidates.
6) Z represents the objective function, such as minimizing the total travel distance, which is further used in constructing the cost function code.
Description Judgment and Revision. After the GA generates the above problem description D(G), the JA evaluates its correctness. The evaluation checks: (i) whether any component of D(g) con- flicts with the instance, (ii) whether the components are internally consistent, and (iii) whether the input definition is properly specified in the instance context. a conflict is detected, the instance context serves as the reference standard. If no issues found, the output is set to TRUE, the prob- lem description subtask terminates, and the process advances to the next code generation subtask. Otherwise, the output set to FALSE, accompanied by explanations of the negative judgment and suggestions for the RA to make correction. The RA then revises D(G) based on the JA's feedback and the instance context. The revised description returned to the JA for revevaluation, and this iter- ative process continues until the JA confirms that D(G) is correct. This iterative procedure improves the accuracy DG)), as demonstrated by the ablation study in Section[4.5] The problem description subtask provides the essential information required for code generation and enforces unified naming conventions and constraints, which must remain consistent throughout the entire pipeline.
3.3 SUBTASK 2: CODE GENERATION
We adopt a unified destroy-insertt heuristic for solving VRPs, as it offers greater flexibility than others and can handle complex, practical problem variants. The code generation subtask consists of interdependent functions: read_ur, distance, cost, initial, destroy, insert, validate, and main, which together form a complete VRP solver. Generating the full solver code, however, is challenging, as requires maintaining consistency across multiple functions while satisfying all requirements. To address this, the GA produces the functions sequentially, with each building upon the previously generated code to ensure correctness and reduce the burden on the LLM. In addition, the JA and RA iteratively refine the code by correcting unmet requirements, syntactic errors, and logical inconsistencies after each function is generated. We describe each step in detail below.
Code Generation. The code structure of the problem-solving workflow is shown in Fig. 2 We specify the role of each function to provide a structured foundation for guiding the GA in generat- ing the corresponding code. Note that these functions are executed only in the solution derivation subtask and are fixed by the EAA if any runtime errors occur. First, read_arp parses a VRPLib- format instance file into a structured dictionary containing all required fields specified by the input X E D(G), ensuring that each variable in X is accurately extracted from the instance context g. Next, distance computes the distance matrix from the node coordinates. initial constructs
5

---

Published as a conference paper at ICLR 2026
solution using greedy strategy that respects constraints in K. The feasibility of the solution is verified by validate. cost evaluates the objective value of a given solution according to the objective function Z. To enable iterative improvement, destroy removes subset of customers and Algorithm
from the current solution, following the strategy described in Appendix C.2 Then, the insert function reinserts the removed customers into feasible positions while minimizing the additional cost. If no fea- sible insertion exists, a new vehicle is assigned to serve these cus- tomers in compliance with constraints in K. At each improve- ment step, the feasibility of the resulting solution is verified by
simulated annealing
read vrp
distance
cost
volidale to ensure that every constraint in K is satisfied. In the event of a constraint violation, the function must raise an error, thereby aiding the EAA in debugging. Finally, main orches- trates the entire workflow, encompassing initialization, iterative improvement, and overall solution management, illustrated in Fig. 2 In the initialization phase, an initial feasible solution is generated, while in the improvement phase (T steps in total), the solution is iteratively refined through destruction, insertion, vali- dation, and cost evaluation, with new solutions accepted accord- ing to the simulated annealing criterion (see Appendix C.3
initial
validate
validate
insert
cost
destroy
Initialization
Improvement
Figure 2: Code structure.
Code Judgment and Revision. For each function generated by the GA, the JA assesses the correctness of the code produced thus far, checking compliance with the requirements and detecting any syntactic or logical errors. If issues are identified, the RA revises the code based on the JA's feedback and the instance context. The revised code is then returned to the JA for re-evaluation, and this process is repeated until the JA delivers a positive judgment. By validating and correcting each code segment before generating the next function, this mechanism reduces the burden on subsequent code generation and revision, improves efficiency, and enhances the reliability of the final solver implementation. Moreover, constraint considerations throughout the code generation process. The generated code is repeatedly checked to ensure that all constraints in K are properly incorporated. This iterative enforcement helps the final solver produce solutions feasible with respect to the instance constraints.
enforced
3.4 SUBTASK 3: SOLUTION DERIVATION
The functions produced in the code generation subtask is not always executable, as constructing full VRP solver is highly complex. Bugs may arise for several reasons: some stem from syn- tactic errors, others from logical flaws, and still others from unmet requirements, such as failing to incorporate certain constraints. Although we have designed strategies such enforcing con- straint considerations during code generation, guarantecing the correctness of -LM--enerated code remains non-trivial. To address this challenge and enhance the trustworthiness of the generated VRP solver, we leverage an EAA to identify the cause of errors and provide explanations along with sug- gestions for correction. Similar the code generation subtask, the RA then modifies the code based on this feedback, after which the JA evaluates the revision. If the code remains unsatisfactory. the RA further adjusts according to the JA's feedback, and this process repeats until the JA delivers positive judgment. The revised code is then re-executed to obtain a feasible solution. Eventually, the model stores the problem description D(G) together with the corresponding generated code in the buffer. If the same problem is encountered again, the framework can directly reuse the stored code, thereby improving efficiency and avoiding redundant computation.
EXPERIMENT
We first evaluate AFL against traditional and neural approaches on 48 standard benchmarks incorpo- rating common constraints such as capacity (C), duration limit (L), time window (TW), open route (O), multi depot (MD), backhaul (B), and mixture backhaul (MB), which are widely used to assess traditional algorithms. We then extend the evaluation to practical electric (E) VRPs, which re- main challenging for traditional solvers. Next, we benchmark AFL against LLM--bsed approaches, assessing code reliability, solution feasibility, and overall performance. We also conduct ablation studies examine the effectiveness of our agentic design. In addition, we report comparisons under

---

Published as a conference paper at ICLR 2026
Table 3: Comparison results on standard benchmarks. More results shown in Table T1
B-50
n-100
n=50
n-100
Cap
Time
Gap (%)
Time
Cap (%6
Time
Gap (%)
Time (ma)
BGGS-P VRP
10.37
10.40
15.62
20,80
10.59
10.40
15.77
20.80
OR-Tools
10.57
1.91
10.40
16.28
4.18
20,80
10.83
2.34
10.40
16:47
5.30
20,80
RF-POMO
10.51
1.31
0.03
15.91
1.83
0.12
CVRPL
10.75
1.52
0.02
16.11
2.17
0.10
AFL (7-500)
10.89
5.01
0.18
16.66
6.66
0.32
11.36
7.18
0.33
17.36
10.08
1.03
AFL (7-2000)
10,70
3.18
0.46
16.22
3.84
1.02
11.25
6.23
1.13
17.03
7.99
7.35
AFL (T-10000)
10.59
2.12
2.10
15.99
2.38
4.38
11.18
5.57
6.93
16.84
6.79
25.48
VRR
16.03
10:10
25.42
20.80
6.51
10.10
9.73
20.80
OR-Tools
16.08
0.35
10.40
25.81
1.51
20,80
6.55
0.69
10:40
10:00
2.73
20,80
RF-POMO
CVRPTW
16.37
2.09
0.02
26.34
3.58
0.12
OCVRE
6.70
2.90
0.02
10.18
4.66
0.10
AFL (7-500)
16.49
2.57
0.59
26.60
4.64
2.15
6.79
4.30
0.31
10.37
6.58
0.4
AFL (T=2200)
16.28
1.56
2.26
26.02
2.36
8.92
6.69
2.76
0.66
10.11
3.91
1.16
AFL (T=10000)
16.19
0.99
9.31
25.79
1.46
38:45
6.64
2.00
2:20
9.99
2.67
5.52
VRP
16.36
10,40
25.76
20.80
6.51
10.40
9.72
20.80
OR-Taals
16.44
1.90
2.79
20:80
RE-OOMO
CVRPLIT
OCVRF
AFL (T-500)
17.07
4.34
27.60
0.43
1.03
(7-2200))
1.21
AFL (T=1000))
35.33
5.65
16.27
BGS-PyVRP
10.51
10.40
OR-Toals
10.52
0.08
10.40
17.03
0.58
20,80
OCVVRPLI LTW
10.40
0.73
20.80
OCV8PPW
RE-POMO
10.66
1.38
0.02
17.39
2.72
0,12
10:66
1.38
0.02
17.39
2.73
0.12
AFL (T=500)
10.64
1.24
0.67
17.36
2.54
0.75
10.74
2.12
1,05
17.61
3:63
AFL (7=22001)
10.57
0.57
2,86
17.14
1.24
10.63
10.64
1.24
3,76
17.32
2.30
16.75
AFL (T=10000))
10.55
0.38
11.15
17.04
0.65
49.05
10.58
0.67
17.27
17.19
1.54
70.31
HRP-PyVRP
9.69
10.40
14.38
20,80
10.19
10.40
14.78
20.80
OR-Taels
9.80
1.16
10.40
14,93
3.85
20.80
10,33
1.39
10.40
15.43
4.34
20.80
RE-POMO
CVRPP
10.00
3.17
0.02
15.02
4.47
0.10
CVRPPL
10.59
3.91
0.02
15.63
5.70
0,10
AFL (T=500)
10.24
5.68
2.62
15.18
7.65
5.56
10.87
6.67
0.31
16.18
9.47
2.15
AFL. (7-2000)))
10.09
4.13
6.51
15.07
4,80
14.47
10.64
4.42
3:31
15.71
6.29
4,80
AFL (7-10000))
9.95
2.27
31,54
14.74
2.50
70,99
10.52
3.24
11.08
15.41
4.26
20.10 10.18
HGS-PyVRP
18:29
10.40
29.47
20,80
6.90
10.40
10:34
20.80
OR-Tools
18.37
0.38
10.40
29.95
1.60
20.80
6.93
0.21
10.40
10.58
2.32
20.80
RE-POMO
CVRPRTTN
18.60
1.67
0.02
30.34
2.96
0.12
OCVRRF
7.09
0.02
10.84
4.82
0.12
AFL (T=500)
19.06
4.21
0.99
31.50
6.89
3.75
7.57
9.71
0.72
11.67
12,86
3.50
AFL. (7-20000)
2.64
16.30
AFL. (7-10000)
1.75
30.17
2.38
70.69
7.30
7.97
HGS-PyVRP
20:80
OR-Tools
CVRPPRLTT TW
18.42
- JCVRPALTT TW OCYRPHL
RE-POMO
AFL (7=500)
1.05
4.57
AFL. (7-2000)
18.87
2.78
2.53
5.75
7.05
4.02
3.68
8.72
AFL. (7-10000)
18.78
2.29
20.19
23.50
76.06
HGS-PyVRP
11.67
10.40
19.16
20,80
11.67
10.40
20.80
OR-Tuuls
RPATW
11.68
0.11
10.10
19,30
0.76
20.80
11.68
0.11
10.10
19.31
0.77
20.80
RE-POMO
11.80
1.15
1.000
19.61
2.34
0.12
11.81
1.16
1.00
19.61
2.34
0.13
AFL, (7=550)
11.80
1.11
0.68
19.67
2.66
1.95
11.81
1.20
0.57
19.67
2,66
4.65
AFL (T-2000)
11.73
0.51
2.26
19.41
1.30
15.71
11.75
0.69
4.92
19.41
1.30
18.15
AFL (7-10000)
11.71
0.34
26.32
19.29
0.68
83.60
11.71
0.34
10.75
19.29
0.68
39.73
Note: term oby. denotes the objective value, gap represents relative gap respect to HGS.PyVRR time indicates nuntime. For all three metrics, lower values are better. Bold numbers highlight our cases where the gap from the SOTA within 3%, which is considered acceptable given that our framework fully automated and self contained.
different prompt strategies in the main text. We further evaluate AFL's robustness across different LLM backbones, and these results are presented Section C.10 and Table C.9 the Appendix. Finally, we evaluate 4 additional open benchmarks, including TSP, ATSP, ACVRP, and SOP, to demonstrate the broad applicability of our framework. All experiments were conducted via the Ope- nAI API using GPT-4.1 (OpenAl 2024) server equipped with an AMD 7702P CPU and 64 GB of RAM, without GPU acceleration. All results shown below are derived using the same heuristic for the same variant given instance. This setting is more practical for real-world ap- plications and significantly reduces code-generen senleeegeerttionnnn overhead. The code and dataset is available at https: httbt//tt.t...... thub. com/ ZHANG- NT/AFL.
7

---

Published as a conference paper at ICLR 2026
Table 4: Comparison results practical benchmarks.
Instrnness
Large Instances
Instances
Large Instanoes
(Sbj.
Gap (98)
(m1)
Cbj.
Cap (5)
Time
Ott
Cap (16)
Time
(ib).
Gap (58
Time (m))
AC0
270.68
0.00
0.23
1384.15 15
0.00
341.74
952.07
0.00
7.92
Greedy
DEVRP
309.63
14.39
0.05
1407.97
1.72
0.13
BOCVRP ECVEPL
714.34
109.03
0,06
7298.83
566.63
0.20
AFL (2-500)
266.21
-1.65
0.18
1145.51
-17.24
0.26
276.95
-18.96
0.18
885.15
-7.03
0.43
AFL (7=2000)
264.21
-2.39
0.24
1100.11
-20.52
0.54
276.94
-18.96
0.25
866.87
-8.95
1.22
AFL (2-10000)
263.33
-2.72
0.51
1045.74
-24.45
2.19
276.94
-18.96
11.53
$61.05
-9.56
4.95
ACO
523.88
0.00
0.25
1129.67
0,00
7,00
179.30
0,000
1122
796.97
0.00
6.81
Greddy
ECVRPLTW ECVRPTW
579.88
17.29
0.06
1868.64
65.41
0.22
197.03
9.89
0.06
866.02
8.66
0.20
AHL (2-500))
306.50
-5.37
0.18
110114
166.76
632.73
20.61
AEL (7=2000)
300.95
-7.68
1071.22
628.34
-21.16
AFL 17-0000
-7.30
1044,63
623.36
10.82
AGO
419.85
0.00
0.44
2842.17
204.87
739.24
10.50
Greedy
434.29
3.44
0.09
3039.87 57
6,96
0.34
EOCVILL
221.34
8.04
0.08
896.97 92
18.13
0.30
AEL (7=500)
368.36
-7.50
0.21
2729.73
33.96
0.50
173.43
-15.35
0.21
726.34
-4.33
0.54
AFL (2--000)
386.84
-7.56
0.330
2612.33
-S007
1.54
172.90
-15.61
0.36
693.71
-X.63
1.50
AEL (2=10000
381.84
-9.05
0.87
2527.87
11.06
7,07
172.33
-15.79
1.12
669.43
-11.8
9.29
ACO
223.91
0.00
0.39
1139.12
0,00
11.98
205.77
0,00
27.55
1184,88
0.00
14.12
NOCVRPTW
Groady
241.22
7.73
0.088
1219.73
7,08
0.33
BOCVEP
222.99
8.32
1.10
1230,85
3.91
0.37
ADL (7-500)
183.26
-18.15
0.19
856.13
-24.84
0.43
181.74
-11.68
0.20
785,53
-3368
0.48
AFL. (7-2000)
-18.22
0.34
$35.03
-26.70
181.43
777,02
17-1000))
182.88
-18.32
4.1 COMPARISON ON STANDARD BENCHMARK
We compare AFL with the traditional solvers HGS (implemented in PyVRP) Vidal 2022 Wouda ct al. 2024) and OR-Tools (Furnon & Perron), as well as the neural solver RF-POMO (errto et a 2025b). The experimental settings and testing data follow [Berto et al. 2025b). including 1,000 instances for each problem. Note that our objective is not to surpass SOTA solvers on conventional VRPs, which reflect decades of expert esfort, but develop a fully automated and self-contained framework for tackling complex VRPs. Therefore, in the comparison shown in Table 3 we regard 3% relative gap with respect to SOTA solvers as an acceptable criterion. We report the results of AFL after 500, 2,000, and 10,000 iterations of solution improvement. The runtime of AFL is measured as the sum of the problem description and solution derivation phases. The code generation phase, analogous to the training phase of a neural solver, is excluded, since once the solver code is produced, it can be reused across instances without incurring repeated generation overhead, and the runtime analysis of code generation phase is shown in Section C.4 in Appendix. Results are partly shown in Table with the rest provided in Table IT in the Appendix due to space limitations.
AFL automatically generates a complete VRP solver without any manual intervention. As shown in Table 3 it achieves a relative gap within 3% of the SOTA HGS on most benchmark prob- lems, demonstrating competitive performance. It is worth noting that the reported runtimes exhibit stochastic variation: more complex problems do not necessarily result in longer execution times. For example, the runtime OCVRPL is shorter than that CVRPL. This variability arises from the LLM-based code generation process, where the model may occasionally produce implementations (e.g., sorting) with higher algorithmic complexity, leading to longer runtimes.
4.2 COMPARISON ON PRACTICAL BENCHMARK
Traditional solvers like HGS (Vidal 2022 Wouda et aL. 2024) and OR- OR-Tools (Furnon & Perron are inherently constrained by their internal implementations and cannot be directly adapted to new problem settings without substantial modifications to the core codebase, whereas AFL can natu- rally accommodate practical VRPs. To demonstrate this, we conduct experiments on a widely used benchmark for ECVRPTW (Schneider et al.) 2014), representative variant of the electric vehicle routing problem (EVRP). Specifically, the dataset contains 36 small instances with 5, 10, and 15 customers, well as 56 large instances with 100 customers. To further assess generality, we extend this benchmark to 7 additional EVRP variants, namely ECVRP, ECVRPL, EOVRPL, EOCVRP, FOCVRPTW, ECVRPLIW, and FOCVRPLTW, enabling a more comprehensive evaluation across
8

---

Published as a conference paper at ICLR 2026
Table 5: RER and SR.
Table 6: Gap comparison on benchmark instances.
RER
SR f
TSPLB
CVRPLIb
CVRPL
500--1000
500-1000
50
SGE
94.1%
5.9%
SGB
099.5915
287.534
660. 30%
DRoC
82.4%
17.6%
DRoC.
4.22%
8.35%
6.00%
8.31%
ReEvo
5.15%
9.13%
14.78%
5.77%
14,80%
198116
AFL
0%
100%
1.28%
2.68%
2.98%
1.93%
5.20%
5.57%
6.79%
diverse and challenging problem settings. Given the intrinsic difficulty of these problems and the lack of directly applicable advanced solvers, we adopt ACO and Greedy as baselines, as both are widely recognized ficxible heuristics for complex VRPs. For ACO, the number of improvement steps is fixed at 500. The results in Table 4 demonstrate the consistent effectiveness of AFL. Al- though ACO is executed with 500 improvement steps, our framework attains better objective values in shorter runtimes. These empirical findings highlight the superiority of AFL complex and practical VRPs, where traditional solvers often face limitations.
4.3 COMPARISON WITH LLM-BASEE SOLVER
We compare AFL in trustworthiness and performance with representative LLM-based approaches for diverse VRPs (above 16 variants plus TSP), namely SGE (Iklassov et al. 2024) and DRoC (Jiang et al. 2025b). while excluding ARS (Li et al. 2025a) due the unavailability of its source code.
To assess trustworthiness, we report the Runtime Error Rate (RER), which measures the percentage of generated code that executes with errors, and the Success Rate (SR), which measures the percent- age of generated code that produces feasible solutions. As summarized in Table [ and detailed in Appendix C.6 SGE is limited solving only TSP, attaining an RER of 94. % and an SR of 5.9%. DRoC extends to TSP. CVRP, and VRPI. with an RER 82.4% and an SR of 17.6 7..6. In contrast, AFL successfully handles all 17 tested VRP variants, reaching 0% RER and 100% SR, highlighting its superior code reliability and solution feasibility.
To assess performance, we further evaluate AFL the problem classes (i.e., TSP, CVRP, and CVRPL) solvable by SGE and DRoC. Specifically, we conduct experiments on TSPLib (Reineli 1991 real-world TSP benchmark containing 50 instances with sizes ranging from 50 to 1,000 customers, and on CVRPLib (Uchoa et al.) (017)) real-world CVRP benchmark containing 100 instances with sizes ranging from 100 to 1,000 customers. We further report the results of ReEvo (Ye
et al. 2024) on TSPLib and CVRPLib .i., both TSP and CVRP are solved in the original paper, to provide a broader assessment. For CVRPL, we adopt the same benchmark setting as in Section 4.1 The results are shown in Table 6 where gaps for TSPLib and CVRPLib their best-known solutions, while CVRPL gaps are measured against HGS. DRoC is able to solve CVRPLib instances only with fewer than 500 customers within the 10-hour time limit. Across all evaluated benchmarks, AFL consistently outperforms both SGE, DRoC, and ReEvo.
reported relative to
4.4 COMPARISON WITH PROMOTING STRATEGY
To evaluate the effectiveness of our model, we compare AFL with several classical prompting strategics, including standard prompting (Brown et al. 2020). self-refine (Madaan et al., 2023), self-debug (Chen et al. (023),, ) self-verification (Weng et al. 2022). and thain-of-thought (CoT) D
prompting (Wei et (022). Table presents the results, where the gaps are measured with re- spect to HGS-PyVRI. All strategies employ the same step-by-step function generation process for fair comparison. The results show that AFL achieves the lowest runtime error rate and the highest success rate, well the best overall solution quality.
4.5 ABLATION STUDY
To study the necessity of the judgement agent (JA) and revision agent (RA), we run ablation ex- periments by removing them from AFL. The results shown in Fig. 3 Without JA and RA, the framework frequently produces incorrect problem descriptions and invalid code. With RA included, the framework becomes more robust, yielding more accurate problem descriptions and executable

---

Published as a conference paper at ICLR 2026
Accuracy Descriptions Standard Benchmark?
Accuracy of Descriptions on Benchmark
60
40
RodgamatteRoutee
Roudtion
C100
VSPL.
VRPTH
VARTT
OURF,
OURPTW
OUBETW
DCU80
CVPP:
EVRPTW
DOYAP
DUSSEW COVAN
COVASTW touSHEW
Problom Typc
Problom Typc
Gap Standard Benchmark (sm50)
Gap (%5 on Standard Benchmark: (n=100)
40
Judeamen- Rectiion
Jedpemenn-Zaxiiin
13
10-
Problem Spp
Protier Type
Figure 3: Ablation studies on the JA and RA.
code. With both JA and RA, the accuracy of problem description reaches almost 100%, and the framework produces reliable code and feasible solutions. This improvement arises because these agents ensures that all operator requirements are adequately considered during the code generation. These results verify our agentic design, showing that JA and RA are crucial for maintaining accurate problem descriptions and ensuring the trustworthiness of the generated code and derived solutions.
4.6 BROAD APPLICABILITY
We further evaluate AFL four additional open benchmarks: TSP, ATSP, ACVRP, and SOP. Re- sults for TSP are presented in T ATSP and ACVRP capture asymmetric routing, which fre- quently arises in real-world applications, while SOP introduces precedence-constrainee path plan- ning, another realistic and challenging setting. All three variants are formulated using non-Euclidean distance metries. Specifically, the ATSP benchmark (Johnson McGeoch (997) contains 18 stances ranging from 17 to 443 nodes. The ACVRP dataset (Helsgaun (017) provides 120 capacity- constrained cases with asymmetric distance matrices covering 16 to 200 customers. The SOP bench- mark (Renaud et al. 1996) includes 39 precedence-constrainee 380 nodes. Experimental results for ATSP, ACVRP, and SOP are presented in Table [3] Table [4] and Table in the Appendix, respectively. By achieving competitive performance across these di- verse datasets, AFL demonstrates broad applicability. indicating that our framework has the potential to be extended to wider range of problem variants.
instances with sizes between 9 and
CONCLUSION
This paper introduces AFL., an agentic LLLM-based framework for solving complex vehicle routing problems (VRPs). Unlike prior approaches that depend on human intervention or predefined mod- ules, AFL achieves self-containment and full automation by extracting domain knowledge directly from raw inputs and generating executable code and feasible solutions end-to-end. By decomposing the pipeline into three tractable subtasks and coordinating four specialized agents, AFL substan- tially improves code reliability and solution feasibility. Extensive experiments on 60 standard and practical VRP variants demonstrate the effectiveness, applicability, and trustworthiness of AFL.
The main limitation lies in performance, which do not yet surpass of-te-o-thhe-rr solvers specifically designed for well-studied problems such as CVRP, a trade-off we consider acceptable given AFL's automation and generality. As future work, we plan to incorporate strategies such as evolutionary search to guide code generation and further enhance both code quality and search efficiency. Overall, our work highlights the potential of agentic LLMs as a general and trustworthy paradigm for solving complex combinatorial optimization problems with minimal domain knowledge, paving the way for more autonomous and adaptive optimization frameworks and democratizing access to advanced optimization techniques for non-expert users.
10

---

Published as a conference paper at ICLR 2026
ACKNOWLEDGMENTS AND DISCLOSURE OF FUNDING
This research is supported by the National Research Foundation, Singapore under the Al Singapore Programme (AISG Award No: AISG3-RP-2022-033, AISG3-RPPGV-222-0017)
REFERENCES
Irwan Bello, Hieu Pham, Quoe V. Le, Mohammad Norouzi, and Samy Bengio. Neural combinatorial optimization with reinforcement learning. In ICLR Workshop Track, 2017.
Federico Berto, Chuanbo Hua, Junyoung Park, Laurin Luttmann, Yining Ma, Fanchen Bu, Jiarui Wang, Haoran Ye, Minsu Kim, Sanghyeok Choi, Nayeli Gast Zepeda, André Hottung, Jianan Zhou, Jieyi Bi, Yu Hu, Fei Liu, Hyeonah Kim, Jiwoo Son, Haeyeon Kim, Davide Angioni. Wouter Kool, Zhiguang Cao. Jie Zhang, Kijung Shin, Cathy Wu. Sungsoo Ahn, Guojie Song. Changhyun Kwon, Lin Xie. and Jinkyoo Park. RL4CO: an Extensive Reinforcement Learning for Com- binatorial Optimization Benchmark. In Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining, 2025a.
Federico Berto, Chuanbo Hua, Nayeli Gast Zepeda, André Hottung, Niels Wouda, Leon Lan, Juny- oung Park, Kevin Tierney, and Jinkyoo Park. RouteFinder: Towards foundation models for vehicle routing problems. Transactions on Machine Learning Research, 2025b. ISSN 2835-8856.
Jieyi Bi, Yining Ma, Jianan Zhou, Wen Song, Zhiguang Cao, Yaoxin Wu, and Jie Zhang. Learning to handle complex constraints for vehicle routing problems. In Advances in Neural Information Processing Systems, 2024.
DD Bochtis and Claus G Sørensen. The vehicle routing problem in field logistics: Part ii Biosystems engineering, 105(2):1800-))) 180-188, 2010.
Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. Language models are few-shot learners. Advances in neural information processing systems, 33:1877-1901,, 2020.
Diego Cattaruzza, Nabil Absi, Dominique Feillet, and Jesús Gonzâlez-Feliu. Vehicle routing prob- lems for city logistics. EURO Journal on Transportation and Logistics, 6(1):51-79, 2017.
Shengkai Chen, Zhiguang Cao, Jianan Zhou, Yaoxin Wu, Senthilnath Jayavelu, Zhuoyi Lin, Xiaoli Li, and Shili Xiang. Dragon: Lim-driven decomposition and reconstruction agents for large-scale combinatorial optimization. In International Conference Autonomous Agents and Multiagent Systems, 2026.
Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. Teaching large language models to self-debug. arXiv preprint arX1v:2304.05/28, 2023.
Pham Vu Tuan Dat, Long Doan, and Huynh Thi Thanh Binh. HSEvo: Elevating automatic heuristic design with diversity-drive harmony search and genetic algorithm using llms. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 39, pp. 26931-26933 2025.
Darko Drakulic, Sofia Michel, Florian Mai, Arnaud Sors, and Jean-Mare Andreoli. BQ-NCO: Bisimulation quotienting for efficient neural combinatorial optimization. Advances in Neural Information Processing Systems, 36:77416-77429 2023.
Vincent Furnon and Laurent Perron. OR-lools routing library. URL httts:://dveelpperrt im zat on http/rottiingg
goog 1 e.
Chengrui Gao, Haopu Shang, Ke Xue, Dong Li, and Chao Qian. Towards generalizable neural solvers for vehicle routing problems via ensemble with transferrable local policy. In Proceedings the Thirty-Third International Joint Conference Artificial Intelligence, pp. 6914 6922, 2024.
Keld Helsgaun. An extension of the lin-kerighann-helsee helsgaun TSP solver for constrained traveling salesman and vehicle routing problems. Roskilde: Roskilde University, pp. 24-50, 2017.
11

---

Published as a conference paper at ICLR 2026
André Hottung and Kevin Tiemny. Neural large neighborhood search for routing problems. Artificial Intelligence, 313: 513:103786, 2022.
Zangir Iklassov, Yali Du, Farkhad Akimov, and Martin Takac. Self-guiding exploration for com- binatorial problems. Advances Neural Information Processing Systems, 077110559--13001, 2024.
Xia Jiang, Yaoxin Wu, Minshuo Li, Zhiguang Cao, and Yingqian Zhang. Large language models as end-to-end combinatorial optimization solvers. In The Thirty-mimth Annual Conference Neural Information Processing Systems, 2025a. URL htt.::ttts///tttt //arxi/// org/abs////ooooooooo.oto.oo...ar abs 2509, 16855
Xia Jiang, Yaoxin Wu, Chenhao Zhang, and Yingqian Zhang. DRoC: Flevating large language models for complex vehicle routing via decomposed retrieval of constraints. In 13th international Conference Learning Representations, 2025b.
David $ Johnson and Lyle A McGeoch. The traveling salesman problem: case study in local optimization. Local search combinatorial optimization, 1(1):215-110, 1997.
Chaitanya Joshi, Quentin Cappart, Louis-Martin Rousseau, and Thomas Laurent. Learning TSP requires rethinking generalization. In International Conference on Principles and Practice of Constraint Programming. 2021.
Chaitanya K Joshi, Quentin Cappart, Louis-Martin Rousseau, and Thomas Laurent. Learning the travelling salesperson problem requires rethinking generalization. Constraints, 27(1):70-98, 2022.
Grigorios D Konstantakopoulos, Sotiris P Gayialis, and Evripidis P Kechagias. Vehicle routing problem and related algorithms for logistics distribution: literature review and classification. Operational research, 22(3):2033-200 2062, 2022.
Wouter Kool, Herke van Hoof, and Max Welling Attention, learn to solve routing problems! In International Conference on Learning Representations, 2018.
Yeong-Dae Kwon, Jinho Choo, Byoungjip Kim, Iljoo Yoon, Youngjune Gwon, and Seungjai Min. POMO: Policy optimization with multiple optima for reinforcement learning. In Advances in Neural Information Processing Systems, volume 33, pp. 81-81998, 2020.
Kai Li, Fei Liu, Zhenkun Wang, Xialiang Tong, Xiongwei Han, Mingxuan Yuan, and Qingfu Zhang. ARS: Automatic routing solver with large language models. arXiv preprint arXiv:2502. 15359, 2025a.
Sirui Li, Zhongxia Yan, and Cathy Wu. Learning to delegate for large-scale vehicle routing. In Advances in Neural Information Processing Systems, volume 34, pp. 26198-26211, 2021.
Tianyou Li, Haijun Zou, Jiayuan Wu, and Zaiwen Wen. Lmask: Learn to solve constrained routing problems with lazy masking. arXiv preprint arXiv:2505.1793: 2025b.
Zhuoyi Lin, Yaoxin Wu. Bangjian Zhou, Zhiguang Cao, Wen Song. Yingqian Zhang, and Senthilnath Jayavelu. Cross-problem learning for solving vehicle routing problems. In Inter- national Joins Conference on Artificial Intelligence, 2024.
Fei Liu, Xialiang Tong, Mingxuan Yuan, Xi Lin, Fu Luo, Zhenkun Wang, Zhichao Lu, and Qingfu Zhang. Evolution of heuristics: Towards efficient automatic algorithm design using large language model. In 41st International Conference Machine Learning (ICML 2024), pp. 32201-322233 ML Research Press, 2024a.
Shengeai Liu, Caishun Chen, Xinghua Qu, Ke Tang, and Yew-Soon Ong. Large language models as evolutionary optimizers. In 2024 IEEE Congress on Evolutionary Computation (CEC), pp. 1-8. IEEE, 2024b.
Fu Luo, Xi Lin, Fei Liu, Qingfu Zhang, and Zhenkun Wang. Neural combinatorial optimization with heavy decoder: Toward large scale generalization. In NewrlPS, 2023.
12

---

Published as a conference paper at ICLR 2026
Yining Ma, Zhiguang Cao, and Yeow Meng Chee. Learning to search feasible and infeasible gions of routing problems with flexible neural k-opt. Advances in Neural Information Processing Systems, (00449555-495777 2023.
Zeyuan Ma, Yue-Jiao Gong, Hongshu Guo, Jiacheng Chen, Yining Ma, Zhiguang Cao, and Jun Zhang. Llamoco: Instruction tuning of large language models for optimization code generation. IEEE Transactions on Evolutionary Computation, 2026.
Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et Self-refine: Iterative refinement 2023.
with self-feedback. Advances in Neural Information Processing Systems,
OpenAl. Gpt-4 technical report. httpes//arxtt..or//a////33333332 2025-09-18.
2024. Accessed:
Wenbin Ouyang, Sirui Li, Yining Ma, and Cathy Wu. Learning to segment for capacitated vehicle routing problems. arXiv preprint arXiv:2507.01037, 2025.
Wenzheng Pan, Hao Xiong, Jiale Ma, Wentao Zhao, Yang Li, and Junchi Yan. UniCO: On uni- fied combinatorial optimization via problem reduction to matrix-encoded general TSP. In The Thirteenth International Conference on Learning Represenlations, 2025.
Gerhard Reinelt. TSPLIB-A traveling salesman problem library. ORSA journal on computing, (4):376-384, 1991.
Jacques Renaud, Fayez F Boctor, and Gilbert Laporte. A fast composite heuristic for the symmetric traveling salesman problem. INFORMS Journal on computing, 8(2):134-144 1996.
Bernardino Romera-Paredes, Mohammadamin Barekatain, Alexander Novikov, Matej Balog, M Pawan Kumar, Emilien Dupont, Francisco JR Ruiz, Jordan S Ellenberg, Pengming Wang, Omar Fawzi, et al. Mathematical discoveries from program search with large language models. Nature, 625(7995) 2024.
Michael Schneider, Andreas Stenger, and Dominik Goeke. The electric vehicle-routing problem with time windows and recharging stations. Transportation science, 48(4):500-53) 520000552220200 2014.
Zhiqing Sun and Yiming Yang. Difusco: Graph-based diffusion solvers for combinatorial optimiza- tion. Advances in neural information processing systems, 36:3706-3733 -7310, 2023.
Eduardo Uchoa, Diego Pecin, Artur Pessoa, Marcus Poggi, Thibaut Vidal, and Anand Subramanian. New benchmark instances for the capacitated vehicle routing problem. European Journal of Operational Research, 257(3):845-855 2017.
Thibaut Vidal. Hybrid genetic search for the CVRP: Open-source implementation and swap* neigh- borhood. Computers Operations Research, 140:105643, 2022.
Oriol Vinyals, Meire Fortunato, and Navdeep Jaitly. Pointer networks. In NeurlPS, volume 28, 2015.
Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc Le, Denny Zhou, et al. Chain-of-thoughh prompting elicits reasoning in large language models. Advances in neural information processing systems, 35:24824-24837, 2022.
Yixuan Weng, Minjun Zhu, Fei Xia, Bin Li, Shizhu He, Shengping Liu, Bin Sun, Kang Liu, and Jun Zhao. Large language models are better reasoners with self-verification. arXiv preprint arXiv:2212.09561 2022.
Niels A Wouda, Leon Lan, and Wouter Kool. PyVRP: A high-performance VRP solver package. INFORMS Journal on Computing, 36(4):943-955, 2024.
Yaoxin Wu, Wen Song, Zhiguang Cao, Jie Zhang, and Andrew Lim. Learning improvement heuris- tics for solving routing problems. IEEE transactions on neural networks and learning systems, 3300)55057-5069 2021.
13

---

Published as a conference paper at ICLR 2026
Chengrun Yang. Xuezhi Wang, Yifeng Lu, Hanxiao Liu, Quoe V Le. Denny Zhou, and Xinyun Chen. Large language models as optimizers. In International Conference on Learning Representations, 2024.
Haoran Ye. Jiarui Wang, Zhiguang Cao, Federico Berto, Chuanbo Hua, Haeyeon Kim, Jinkyoo Park, and Guojie Song. ReEvo: Large language models as hyper-heuristies with reflective evolution. Advances in neural information processing systems, 37:43571-43600 2024.
Haifei Zhang, Hongwei Ge, Jinlong Yang, and Yubing Tong. Review of vehicle routing problems:
Models, classification and solving algorithms. Archives of Computational Methods in Engineer- ing, 29(1):195-22) 2022.
Ni Zhang and Zhiguang Cao. Hybrid-balance gflownet for solving vehicle routing problems. In Advances in Neural Information Processing Systems, 2025.
Wayne Xin Zhao, Kun Zhou, Junyi Li, Tianyi Tang, Xiaolei Wang, Yupeng Hou, Yingqian Min, Beichen Zhang, Junjie Zhang, Zican Dong, et al. A survey of large language models. arXiv preprint arXiv:2303. 18223, 2023.
Zhi Zheng, Zhuoliang Xie, Zhenkun Wang, and Bryan Hooi. Monte carlo tree search for com- prehensive exploration in Ilm- automatic heuristic design. In Forty-second International Conference on Machine Learning, 2025.
Jianan Zhou, Yaoxin Wu, Wen Song, Zhiguang Cao, and Jie Zhang. Towards omni-generalizable neural methods for vehicle routing problems. In International Conference Machine Learning, pp. 42769-42789, 2023.
Jianan Zhou, Zhiguang Cao. Yaoxin Wu, Wen Song, Yining Ma, Jie Zhang, and Xu Chi. MV- MoF: Multi-task vehicle routing solver with mixture-of-experts. International Conference on Machine Learning, pp. 61804-61 61244. PMIR, 2024.
Jianghan Zhu, Yaoxin Wu, Zhuoyi Lin, Zhengyuan Zhang, Haiyan Yin, Zhiguang Cao, Senthilnath Jayavelu, and Xiaoli Li. Bridging synthetic and real routing problems via Ilm guided instance generation and progressive adaptation. In AAAI, 2026.
14

---

Published as a conference paper at ICLR 2026
APPENDIX
Related Work
16
A.I MI. VRPs
16
A.2 LLM for VRPs
16
Problem Statement
17
C Supplementary Methodology and Experimental Details
24
C.I VRPLib Component
24
C.2 Destroy Strategy
................................
24
Simulated Annealing Criterion
C.4 Code Generation Time Analysis
26
C.5 Comparison on 48 Standard Benchmark
26
C.6 Details of Comparison of Code Reliability and Solution Feasibility
26
C.7 Comparison on ATSP Benckmark
27
C.8 Comparison on ACVRP Benckmark
27
C.9 Comparison on SOP Benckmark
29
C.10 AFL's Sensitivity to Different LLMs
29
C.11 Experiment on Different Input Format
.e..............................
29
C.12 Experiment on Large CVRP Instances
30
Examples of Prompts and Outputs
D.1 Subtask 1: Problem Description
31
D.1.1 Generation Agent(GA)
................................
D.1.2 Judgment Agent (JA)
33
D.1.3 Revision Agents (RA)
34
D.2 Subtask 2: Code Generation
36
D.2.1
Generation Agent (GA)
36
D.2.2 Judgment Agent (JA)
38
D.2.3 Revision Agent (RA)
40
D.3 Subtask 3: Solution Derivation
40
D.3.1 Error Analysis Agents (EAA)
40
The Use of Large Language Models
41
15

---

Published as a conference paper at ICLR 2026
A RELATED WORK
A.1 ML FOR VRPS
Existing neural approaches to solving VRPs generally follow directions: learning construct and learning to improve them. In the construction paradigm, a model either directly generates a fea- 2017) or produces probability heatmap (Joshi al.) Sun & Yang 2023) from which a solution is sampled. AM (Kool et al. 2018) first introduces attention mechanisms for VRPs, and POMO (Kwon et al. 2020) subsequently exploits multiple op- tima to enhance solution quality, inspiring series of extensions and refinements (Drakulic et al.)
sible solution (Vinyals et al. 2015 Bello
202T
2023
Luo et al. 2023: Berto et al. 2025a Zhang & Caol 2025). Recently, increasing attention has been devoted to improving generalization (Joshi et al.
2022] Zhou et al. 2023 Gao et al.) 2024) and scalability (Li et al. 202T, Ouyang et al. 2025). addressing complex constraints (Bi et al.
2024
Li ct al. (025b). and handling multiple VRP variants within single framework (Zhou al,
2024 Berto ct al. 2025b Pan et al., 2025). As a representative work. [Lin et al. (2024) propose a pross--robblem learning framework for VRPs, leveraging a pre-trained Transformer backbone and modular architecture to enable scalable and transferable adaptation to complex variants. However, these efforts still fall short of practical deployment. In the improvement paradigm, an initial solution is iteratively refined using learned local-search (Wu et al. 2021 Ma et al. 2023) or destroy-repair strategies (Hottung & Tierney 2022) to progressively reduce cost and enhance solution quality.
A.2 LLM FOR VRPs
One line of work uses LLMs to directly generate improve VRP solutions. For example, OPRO (Yang et al. 2024) attempts to construct solutions outright with an LLM, LEMA (Liu et al. 2024b) leverages the LLM to perform the genetic search itself, and Jiang et al. (2025)) finetune
L.M to construct in the end to end manner. However, they fall short in terms of solution quality and feasibility. A notable work in this line is DRAGON (Chen et al., 2026), a pioneering study provid- ing the first compelling evidence that LLM-based agents can directly generate high-quality solutions for large-scale COPs, marking significant advance in LLM-driven decision-making. Another line of research applies LLMs to generate code for VRPs, which can be broadly categorized into two directions; evolving basic heuristics for conventional VRPs and developing general frameworks for complex VRPs.
In evolving basic heuristics, LLMs are employed to iteratively evolve a simple or existing heuristic within fixed templates or established solvers for conventional VRPs. Early work such as EOH (Liu al. 2024a) adopts a population- based framework with fixed templates for heuristic evolution. ReEvo (Ye et al. 2024) further combines evolutionary search with LLM reflections to provide ver-
bal feedback and enhance search efficiency. More recently, HSEvo (Dat et al., 2025) and MCTS-
AHD (Zheng et al. 2025) have advanced this line of research. Zhu al. (2026) uses evolution framework to bridge synthetic and real routing problems. However, these approaches remain tai- lored to specific problems, limiting their generality across VRP variants with practical constraints.
In developing general frameworks, LLMs are leveraged as knowledgeable developers to generate function modules with distinct roles, enabling the framework to address diverse and complex VRPs. In ARS (Li et a 2025a) and DRoC (Jiang et al. 2025b). LLMS generate specific functions to adapt frameworks different variants, typically relying on handerafted modules external solvers. However, aligning LLM-ggnnrated code with these components remains challenging. In ARS, the integration between the LLM and the base algorithm is weak: the handcraft improvement opera- tor and the constraint validation functions generated by the LLM are decoupled, and feasibility can only be verified after optimization, often leading to infeasible solutions. In DRoC, the LLM pro- duces code that invokes OR-Tools without genuine knowledge of its internals, relying instead on external retrieval, which may undermine code reliability and reduce solution feasibility, In contrast, SGE (Iklassov et al.) 2024) eliminates the need for predefined modules solvers by directly gen- erating code end-to-end. However, due to the inherent complexity of full code generation and the absence of effective constrainthhandling mechanisms, its applicability is restricted to TSP. Moreover, it still depends on handcrafted extraction of instance information (c.g., inputs and constraints). and its overall performance remains uncompetitive.
16

---

Published as a conference paper at ICLR 2026
Table 7: Constraint composition of VRP variants.
VRP Varient
Capacity
(C)
Open Route
(0)
Backhaul (B)
Mixed Backhaul
(MB)
Daration Limit
(L)
Time Windows (TW)
Malti depot (MD)
Electric Vehicle
(B)
CVRP
OCYRP
CVRPR
CVRPTW
OCVRPTW
OCYRPB
OCVRPL
CVRPBTW
CVRPLTW
OCVRPBL
OCVRPETW
CVRPBLTW
OCVRPBITW
CVRPMB
OCVRPMB
CVRPMBIW
OCYRPMBTW
CYRFMBLTW
OCVRPMBLTW
MDCVRP
MDCVRPB
MDCVRRL
MDCVRPTW
MDOCVRPB
MDOCVRPTW
MDOCVRPBL
MDOCVRPBTW
MIOCCVPPETW
MDCVRFMBL
MDOCVREMB
MDOCVRPMBL
MDCVRPMBLTW
MIDOUVPMMBUTW
ECVRP
ECVRPL
BOCYRP
ECVRPLIW
BOCVRPL
EOCVRPTW
EOCVRPLIW
this paper, we address these limitations by proposing a general framework of collaborative LLM- empowered agents that can tackle complex VRPs with self-containment, full automation, and high trustworthiness in both code and solutions.
B PROBLEM STATEMENT
The connections between different VRP variants and their associated constraints are illustrated in We further provide detailed descriptions of several representative variants as follows.
Table 7
1. CVRP
Problem Type: CVRP.
Description: The Capacitated Vehicle Routing Problem (CVRP) involves determining op- timal routes for fleet of vehicles to deliver goods to a set of customers while minimizing total distance traveled and ensuring that vehicle capacity
exceeded.
Constraints: Capacity the total demand on any route cannot exceed vehicle capacity. Visit each customer is visited exactly once. Depot - every route starts and ends at the depot.
17

---

Published as a conference paper at ICLR 2026
Input: depot, node_coordinates, demands, capacity.
Output: A set of vehicle routes, each beginning and ending at the depot, visiting every customer exactly once while respecting capacity constraints.
Objective:
Minimize the total travel distance.
2. CVRPL
Problem Type: CVRPL.
Description:
The Capacitated Vehicle Routing Problem with a Distance Limit (CVRPL) involves optimizing routes for fleet of vehicles with a fixed capacity, ensuring deliveries are made while adhering constraint on the maximum route distance, while all routes must start and end common depot.
Capacity vehicles have limited capacity for carrying goods. Distance Limit the total travel distance of each route must not exceed the specified maximum. Visit each customer is visited exactly once. Depot all routes must start and end at the fixed depot.
Constraints:
Input: depot, node coordinates, demands, capacity, distance limil.
Output: A set of feasible vehicle routes, each beginning and ending at the depot, vis- iting every customer exactly once while respecting both capacity and maximum-distanee constraints.
Objective:
Minimize the total travel distance.
CVRPTW
Problem Type: CVRPTW.
Description:
The problem is about optimizing delivery routes for fleet of vehicles to serve set customers, considering time windows and vehicle capacity constraints. Each customer must be visited within specific time frame and vehicles have limited capacity for deliveries.
Capacity vehicles have limited capacity for deliveries. Time Windows customers must be served within specified time intervals. Visit every customer is visited exactly once. Depot every route starts and ends the depot.
Constraints:
Input:
depot, mode_coordinates. demands, capacity, service_times timewinndws
Output: A set of vehicle routes, each beginning and ending the depot, visiting every customer exactly once while satisfying vehicle capacity and customer time-window con- straints.
Objective:
Minimize the total travel distance.
OCVRP
Problem Type: OCVRP.
Description: The Open Capacitated Vehicle Routing Problem (OCVRP) involves deter- mining the optimal routes for a fleet vehicles with limited capacity that start at depot and must deliver goods to set of customers without the obligation return to the depot.
Capacity vehicles have limited capacity. Open Route vehicles are not required to return to the depot after completing service. Visit each customer may only be visited once. Depot every route must start at the depot.
Constraints:
Input: depot. node coordinates, demands, capacity.
Output: set of open vehicle routes, each starting at the depot and ending at a customer location, visiting every customer exactly once while satisfying the vehiele-capacity straint.
Objective:
Minimize the total travel distance.
5. CVRPLTW
18

---

Published as a conference paper at ICLR 2026
Problem Type: CVRPLTW.
Description:
The problem is Capacitated Vehicle Routing Problem with Distance Limit and Time Windows (CVRPLTW), where a fleet of vehicles tasked with delivering goods to set of customers, each with specific demand and time windows, while respecting the vehicles' capacity and route limitations.
Capacity - vehicles have limited capacity. Distance Limil - each route has maximum distance. Time Windows customers must be served within specified time intervals. Visit - every customer is visited exactly once. Depot - every route starts and ends at the depot.
Constraints:
Input: depot, node_coordinater demands, capacity, service time timewwindow,, dis- tance limit.
Output: set of feasible vehicle routes, each beginning and ending at the depot, visiting every customer exactly once while satisfying capacity, distance-limit, and time-window constraints.
Objective:
Minimize the total travel distance.
6. OCVRPL
Problem Type: OCVRPL.
The problem is variant of the Open Capacitated Vehicle Routing Problem with Distance Limit (OCVRPL). where vehicles must deliver goods to various customers while adhering to a capacity limitation and a maximum route distance, without the require- ment to return to a depot.
Description:
Capacity vehicles have limited capacity for the amount of goods they can transport. Distance Limit each route has a maximum distance that vehicles must not exceed. Open Route vehicles do not return the depot after their delivery routes. Visit each customer is visited only once. Depot routes must start at the depot, specifically at the designated location.
Constraints:
Input:
depot, node coordinates, demands, capacity, distance limit.
set of open vehicle routes, each starting at the depot and ending at a customer location, visiting every customer exactly once while satisfying capacity and distance-limir constraints.
Output:
Objective:
Minimize the total travel distance.
7. OCVRPTW
Problem Type: OCVRPTW.
Description: The Open Capacitated Vehicle Routing Problem with Time Windows (OCVRPTW) involves determining optimal routes for fleet of vehicles with limited pacity that service a set of customers with specific time windows, without the requirement for vehicles to return to the depot after completing their deliveries.
Capacity the total demand on any route cannot exceed vehicle capacity. Time Windows customers must be served within specified time intervals. Open Route vehicles do return to the depot. Visit each customer may only be visited once. Depot every route must start at the depot.
Constraints:
Input: depot, node coordiiatessss.... demands, capacity, service time- windows.
Output: A set of feasible open vehicle routes, each starting at the depot and ending at a customer location, visiting every customer exactly once while satisfying capacity, service- time, and time-window constraints.
Objective: Minimize the total travel distance.
OCVRPLTW
Problem Type: OCVRPLTW.
19

---

Published as a conference paper at ICLR 2026
Description: The Open Capacitated Vehicle Routing Problem with Distance Limit and Time Windows (OCVRPLTW) requires planning optimal routes for a fleet vehicles with limited carrying capacity to serve customers within specified time windows, while each route must also satisfy a maximum travel-distance limit and vehicles are not required to return to the depot after their final delivery.
Constraints: Capacity the total demand on any route cannot exceed vehicle capacity. Distance Limit each route's s total travel distance must not exceed the specified maximum. Time Windows customers must be served within their given time intervals. Open Route vehicles do not return to the depot after completing service. Visit - each customer is visited exactly once. Depot every route must start at the depot.
Input: depot, node_coordinates, demands, capacity, service time_windows, dis- tance limit.
A set of feasible open vehicle routes, each starting the depot and ending at a customer location, visiting every customer exactly once while satisfying capacity, time- window, and distance-limin constraints.
Output:
Objective: Minimize the total travel distance.
9. ECVRP
Problem Type: ECVRP.
Description: Electric Capacitated Vehicle Routing Problem (ECVRP) involves determin- ing optimal routes for a fleet of electric vehicles serve set of customer demands, con- sidering vehicle load capacity and battery (fuel) constraints, where recharging is available at designated charging stations. Each route starts and ends the depot and each customer is to be visited exactly once.
Electricity Each vehicle has a limited battery, consumes energy propor- tional to distance, and may recharge only at designated charging stations, with charging time affecting feasibilityy. Capacity - Each vehicle has maximum load capacity. Depot Each route must start and end at the depot. Visit Each customer must be visited exactly once.
Constraints:
Input: depot, node coordinates, demands, capacity. fuel capacity. fuel consumption rate, refuel rate, stations.
A set of feasible vehicle routes, each starting and ending at the depot, visiting each customer exactly once, specifying the visiting order and any charging station stops, such that vehicle capacity and battery constraints are satisfied.
Output:
Objective:
Minimize the total travel distance.
10. ECVRPL
Problem Type: ECVRPL.
Description: Electric Vehicle Capacitated Vehicle Routing Problem with distance limit: find the set of routes for electric vehicles, starting and ending at the depot, that serve all customers without exceeding vehicle capacity, electric fuel capacity, and an explicit route distance limit. Electricity is managed with fuel consumption, battery recharging at stations, and recharging time affects route scheduling.
Electricity electric vehicles have limited battery, fuel consumption rate, designated charging stations, and recharging time which constrain feasible routes. Capacity vehicles have a maximum load they can carry at one time. Distance Limit eeach route cannot exceed a maximum distance. Visit - each customer is visited exactly once. Depot - all routes must start and end at the depot.
Constraints:
Input: depot, mude_coordinater demands, capacity, Eistancelimil _appcciyy fuel.consumption-aate rate, stations.
Output: set of vehicle routes, each starting and ending the depot, visiting every tomer exactly once while satisfying capacity, distance- and electric-vehicks energy constraints, including recharging stops if required.
20

---

Published as a conference paper at ICLR 2026
Objeetiie: Minimize the total travel distance.
11. ECVRPTW
Problem Type: ECVRPTW.
Description: the Electric Capacitated Vehicle Routing Problem with Time Windows (ECVRPTW) constructs least-cost routes for a fleet of electric vehicles, each starting and ending at the depot, to serve all customers exactly once within specified time windows, considering both vehicle load capacity and electric battery (fuel) constraints; vehicles may recharge designated charging stations, and service each customer takes a specified time.
Constraints: Electricity - Electric vehicles have limited battery capacity, consume energy proportional to travel distance, may recharge at specified stations, and recharging duration depends on refuel rate. Time Windows Customers must be served within predetermined time intervals. Capacity Each vehicle has limited load capacity. Visit Each customer is visited exactly once. Depot - Every route must start and end at the depot.
Input:
depot, code_dcord,sates, demands, capacity, service_times time_windows, fapecctpy fotieelcossmptiinn.oo
refuel stations.
Output: A set of feasible vehicle routes, each starting and ending at the depot, visiting every customer exactly once while satisfying capacity, time window, and electric-vehicle energy constraints, including necessary recharging stops.
Objective: Minimize the total travel distance.
12. EOCVRP
Problem Type: EOCVRP.
Description: the Blectric Open Capacitated Vehicle Routing Problem plans routes for fleet of electric vehicles, where each vehicle starts at the depot, serves customer demands, may recharge at designated charging stations, does not need return the depot (open route), and respects vehicle capacity and battery limits. Each customer is visited exactly once.
Constraints: Electricity vehicles have limited battery capacity, consume energy with travel, and may recharge at stations, considering recharging time. Capacity - vehicle loads cannot exceed their capacity. Open Route vehicles not required to return to the depot. Distance Limit - each route has a maximum allowed travel distance. Visit - each customer must be visited exactly once. Depot each route starts at the depot.
Input:
depot, node.coordinates, demands, capacity, distance_limit fuel-capacity, fuel.consumption-Juuee refuel_raee, stations.
a set of feasible open vehicle routes starting at the depot, each serving subset of customers exactly once, possibly using charging stations, and ending at any node, such that all routes meet capacity, battery, and problem constraints
Output:
Objective: Minimize the total travel distance.
13. ECVRPLTW
Problem Type: ECVRPLTW.
Description: Electric Capacitated Vehicle Routing Problem with Time Windows (ECVRPTW) involves designing routes for a fleet of electric vehicles to deliver goods to customers, respecting vehicle capacity limits, electric battery/range constraints, maximum route distance, and customer-specift time windows. Each customer must be visited ex- actly once, and all routes must start and end at the depot. Vehicles may need to recharge at designated stations as part of their routes.
Constraints: Electricity electric vehicles have limited battery (fuel) capacity, must recharge at stations as needed, and recharging consumes time. Capacity - each vehicle has limited payload capacity. Distance Limit each route has maximum distance. Time Windows customers must be served within given time intervals. Visit each customer can be visited only once. Depot each route must start and end the depot.
21

---

Published as a conference paper at ICLR 2026
Input:
depot, hodeecoordinatee demands, capacity, service service-times, time-windows, dis- refuel_rate, stations.
tance Jimit, tunceJiiit,fuel.ccpa htwpritiiniillppppootooooooooooo fouel..onsumpiinn.rra.
A set of feasible vehicle routes, each represented as an ordered list nodes (cus- tomers, stations, and depot), with associated service start times and charging operations, where each route starts and ends at the depot, all customers are visited exactly once within their time windows, and all constraints capacity, time window, fuel, route length, and recharging are satisfied.
Output:
Objective:
Minimize the total travel distance.
14. EOCVRPI.
Problem Type: EOCVRPI.
the Electric Vehicle Open Capacitated Vehicle Routing Problem involves electric vehicles with limited load and battery capacity, serving customers starting from the depot without needing to return (open route). Vehicles can recharge at charging stations, and each customer is visited at most once.".
Description:
Electricity Vehicles have a limited electric battery, consumed proportion- ally to travel; vehicles may recharge at designated stations. Capacity Vehicles have a maximum load they can carry. Open Route Vehicles do need to return to the depot after serving customers. Distance Limit Each route has a maximum allowable distance. Visit Each customer is visited at most once. Depot Routes start at the depot..
Constraints:
Input: depot, node_coordinates, demands, capacity, distance fuel-capacity, consuuponn rate, refu stations.
Output: A set of feasible open vehicle routes starting from the depot, where each route serves subset of customers, may include recharging stops at stations as needed, and sat- isfies all capacity, distance, fuel, and visit constraints, ensuring each customer is visited at most once.
Objective: Minimize the total travel distance.
15. EOCVRPTW
Problem Type: EOCVRPTW.
Electric Open Capacitated Vehicle Routing Problem with Time Windows: The goal is to design minimum-cost routes for fleet of electric vehicles that start from a depot, serve each customer exactly once within specified time windows, while observ- ing vehicle capacity, electric battery limitations (with possible recharging at stations), and vehicles are not required to return to the depot.
Description:
Electricity Vehicles have limited battery, consume energy with distance, and may recharge at designated stations. Capacity Each vehicle has fixed carrying capacity. Time Windows Customers must be serviced within specific time intervals. Open Route Vehicles do not return to the depot after serving customers. Visit Each customer must be visited exactly once. Depot - Routes start from the depot.
Constraints:
Input:
depot, node coordinates, demands, capacity, Servicettimes time windows, capaciiycy ftw.uuueo.oosmmptionnntltl refuel_rate, stations.
Output: set of feasible vehicle routes where each route starts at the depot, visits each cus- tomer exactly once within their specified time windows and service times, respects vehicle capacity and battery constraints with possible recharging at stations, and does not return to the depot.
Objective: Minimize the total travel distance.
16. EOCVRPLTW
Problem Type: EOCVRPLTW.
Description:
Electric Open Capacitated Vehicle Routing Problem with Distance Limit and Time Windows. In this problem, a fleet of electric vehicles with limited cargo and battery
22

---

Published as a conference paper at ICLR 2026
capacity must serve customers, each within specified distance limit and time windows. Vehicles start at the depot but do not return (open routes), must visit each customer exactly once, can recharge only at designated charging stations, and each route has maximum allowable distance.
Electricity Electric vehicles have limited battery (fuel) capacity, fuel con- sumed proportionally to distance, can recharge at charging stations, and recharging takes time. Capacity Vehieles have limited cargo capacity. Distance Limit Each route has maximum allowed distance. Time Windows Service each customer must begin within its given time interval. Open Route Vehicles do not return to depot after serving cus- tomers. Visit - Each customer must be visited exactly once. Depot every route must start at the depot.
Constraints:
Input: depot, node coordinates, demands, capacity, service times, time windows dis- tance limit, -apaciity foencityyfuulllc.e civeslsssumttinnnr refuel stations.
Output: A set of feasible open vehicle routes, each starting at the depot, visiting every customer exactly once within their specified time windows, not exceeding vehicle cargo capacity, route distance limits, or battery constraints (with recharging at stations as needed), and ensuring vehicles do not return the depot.
Objective:
Minimize the total travel distance.
17. TSP
Problem Type: TSP.
Description: The Symmetric Traveling Salesman Problem to find the shortest possible route that visits each node (drilling location) exactly once and returns to the starting point, typically used for optimizing routes such as drilling or circuit board manufacturing.
Constraints: Visit each node (location) must be visited exactly once.
Input: mode_coordinatee.
Output: A single closed tour that begins and ends at one node and visits every node exactly once.
Objective: Minimize the total travel distance.
18. ATSP
Problem Type: ATSP.
Description: The Asymmetric Traveling Salesman Problem (ATSP) generalizes the clas- sical TSP by allowing the travel cost from node node differ from the cost from to i. The goal is to find the shortest Hamiltonian cycle that visits every node exactly once and returns the starting node when edge weights direction-dependent.
Constraints: Visit each node must be visited exactly once. Depot the tour must start and end the same node. Asymmetry travel costs or distances are not necessarily symmetric.
Input: edge_ peeriix
Output: A single directed Hamiltonian cycle that begins and ends at one node and visits every node exactly once while respecting the asymmetric cost structure.
Objective: Minimize the total travel cost.
19. ACVRP
Problem Type: ACVRP.
Asymmetric Capacitated Vehicle Routing Problem (ACVRP): fleet of ve- hicles with limited carrying capacity must start and end at a central depot and serve every customer exactly once, while accounting for direction-dependee
Description:
travel costs.
Constraints: Capacity the total demand on any route cannot exceed the vehicle capacity. Asymmetry travel costs between two nodes not necessarily equal in both directions. Visit each customer is visited exactly once. Depot - every route must start and end at the depot.
23

---

Published as a conference paper at ICLR 2026
Input: depot, edge.weight.marris demands, capacity.
Output: A set of vehicle routes, each starting and ending at the depot, visiting every customer exactly once while satisfying vehicle-capacity constraints and accounting for direction-dependent travel costs.
Objective:
Minimize the total travel cost.
20. SOP
Problem Type: SOP.
Description: The Sequential Ordering Problem (SOP) is to find a minimum-cost Hamil- tonian path that visits each node exactly once and respects given precedence constraints (some nodes must be visited before others), subject to forbidden arcs.
Constraints: Precedence Certain nodes must visited before others, according to the instance's precedence relations. Forbidden Arcs Some node-to-node connections are in- feasible and cannot be used. Visit each node is visited exactly once (Hamiltonian path).
Input: edge weight matrix, precedence constraints, constraints,forbidder ares.
Output: minimum-cost Hamiltonian path visiting each node exactly once that satisfies all precedence constraints and forbidden arc constraints.
Objective: Minimize the total travel cost of the path.
C SUPPLEMENTARY METHODOLOGY AND EXPERIMENTAL DETAILS
C.I VRPLIB COMPONENT
Table summarizes the main components of a VRPLIB instance file, presenting each required or optional field along with its description and an illustrative example. The "VRPLib Field" column lists the standard sections of a vehicle-routing problem instance (e.g., NAME/COMMENT, TYPE, DIMENSION). The Description column explains the meaning of each section, while the Example column provides typical syntax drawn from sample instance (for example, TYPE CVRP, CA- PACITY 200), showing the exact formatting used in VRPLIB files.
C.2 DESTROY STRATEGY
As the algorithm shown in Algorithm Given a solution S, distance matrix Dis, and ratio p. the algorithm first determines the number of nodes 7ym remove. A random customer is sampled, and candidate list L formed by sorting all customers by distance to c. Iteratively, a candidate u is selected, and if its route has not been destroyed, contiguous subsequence Q including is randomly chosen and removed. The subsequence Q is added to the removed set R, and the corresponding route is updated and marked destroyed. This process continues until 74m customers are removed, yielding the residual solution S' and the removed set R.
C.3 SIMULATED ANNEALING CRITERION
The Simulated Annealing (SA) criterion is stochastic acceptance rule inspired by the physical annealing process, where a material is gradually cooled to reach low-energy crystalline state. In VRPs scenarios, it provides mechanism escape local minima by occasionally accepting solutions that are worse than the current one.
Given a current solution with cost Exurrent and a candidate solution with cost Enew, the move is accepted if Enew < Ecurrenti otherwise it is accepted with probability
Enew
Ecurrent
P exp
T
where temperature parameter that decreases according to a cooling schedule. our imple- mentation, 7' is defined as
T iteration step +1
10
where iteration denotes the total number of iterations and step is the current iteration index.
24

---

Published as a conference paper at ICLR 2026
Table Main sections of VRPLIB instance file with descriptions and example.
VRPLib Field
Description
Example
NAME / COMMENT
Optional. Includes the instance name op- tional comments that provide additional context for APL understand the related problem.
NAME A-n32-k5 COMMENT 32-node Capacitated Vehicle Routing Problem instance.
TYPE
Optional. Specifies the declared problem type (e.g., CVRP, VRPTW, EVRP), serving only as a reference for constraint extraction; the actual problem characteristics must be determined from the complete instance.
TYPE CVRP
DIMENSION
Required. Total number of nodes including DIMENSION 33 both customers and depot(s).
EDGE WEIGHT TYPE
Required. Specifies how inter-node distances are given: metric (e.g.. BUC 2D) or an ex- plicit matrix.
EDGE
WEIGHTT TYPE EUC
2D
NODE COORD SECTION
Required. Lists coordinates of cach node (lypically planar Euclidean).
NODE COORD SECTION:
45 68
2 37 52
DEMAND SECTION
Required instances with capacity (C)
D.MAND SECTTON;
constraint. Specifies the demand of each cus- tomer node, typically measured weight or quantity units, where positive values denote linehaul customers (delivery) and negative values denote backhaul customers (pickup).
-10
CAPACITY
Required for capacity-constrained (C) prob- lems. Defines the maximum load (c.g.. weight or volume) each vehicle can carry.
CAPACITY 200
DEPOT SECTION
Required for instances with depot constraint. Identifies the depot node(s) where vehicles start and optionally end their routes.
DEPOT SECTION:
-1
DISTANCE LIMIT'
Required for instances with open route (O) constraint. Specifies the maximum travel dis-
DISTANCE LIMIT 500
tance allowed for each route.
TIME WINDOW SECTION
Required for instances with time window (TW) constraint. Provides earliest and latest allowable arrival times for each customer.
TIME WINDOW SECTION:
100
20 80
SERVICE TIME SECTION
Required for instances with time window SERVICE TIME SECTION: (TW) constraint. Service time required at each customer node; combined with travel 15
10
time satisfy tine-window constraints.
FUEL CAPACITY
Required for instances with electric vehicle (E) constraint. Maximum energy or hattery capacity for each vehicle in electric-vehicle routing problems.
FUEL CAPACITY 300
FUEL CONSUMPTION RATE
Required for instances with electric vehicle (E) constraint. Energy consumed per dis- 1.0
FUEL CONSUMPTION RATE
unit.
REFUEL RATE
Required for instances with electric vehicle (E) constraint. Charging refueling rate per
REFUEL RATE 2.0
time unit at stations.
STATION SECTION
Required instances with electric vehicle
STATION SECTION:
(E) constraint, Identifies charging refuel-
ing station nodes where vehicles can refucl. 35
25

---

Published as a conference paper at ICLR 2026
Algorithm Destroy Strategy
Input: solution S (set of routes), distance matrix Dis, ratio p
2: Output: removed nodes R, destroyed solution 8"
3: R t S' <S, fym + [|C|-pl
C: set of customers D random sample center > sort candidate list by distance to c
4: Uniform(C)
5: L + sort(C, Dis(c,))
6: while |R] 7oym and L + 0 do
7: u +- nnxxt( <- route (u, S")
8:
if r already destroyed then
9: continue
10: end if
11: Q < subseq u)
> random select contiguous subsequence including update by excluding Q and extend with Q
1-r\Q.1 RUQ
13:
end while
return (R)
Table 9: Gap comparison across different prompting strategies.
VRELTW
OVRPTW
OVRELTWW
30
100
50
100
30
100
50
100
50
100
100
30
100
50
100
Sunsand
11.768
17.4258
5.115
K.10%
10.005
15.755
4.59%
7.389
14,9995
33.509
Seli-Reiine
8.3%
5.15%
12.129
6.79%
13,00%
Sali-heeg
17.425
5.11
K100%
10
775
4.5%%
7
14,9955
33,509
63.79%
915
12.57%
14.37%
Soli-eeniicaiion
7615
6.00%
8.995
17:045
7,378
10.919
56.445
875
600055
8515
6.6%%
7.18%
10.00%
2,87%
6.6%%
1.445
2.54%
2.12%
Note: indicutes where runnuble code feusible solution could obtained.
C.4 CODE GENERATION TIME ANALYSIS
At first, we provide the runtime breakdown during testing phrase in Table 10 These results, as noted Lines 350-351, measure the combined runtime for Problem Description and Solution Derivation over 1,000 test instances using the already generated codes.
detailed runtime breakdown of solver generation phase for the three subtasks: Problem Descrip- tion, Code Generation, and Solution Derivation, across eight representative VRP variants, are shown in Table TO These results reflect the time required to generate executable solver code and obtain feasible solution for single instance, where the generated code be reused in the same VRP variant. As shown in Table 10 the code can be generated within approximately 30 minutes, which notably shorter than the time typically required for human expert design, highlighting the model's strong efficiency in producing high-quality, executable, and feasible solver code within short time.
In the Figure. we explore the trade-off between solution quality and different number of solution refinement iterations.
C.5 COMPARISON ON 48 STANDARD BENCHIARK
The results of the all 48 standard VRP variants are presented in Table 11 derived from 1,000 in- stances with 100 nodes each. AFL achieves results within 3% of the SOTA baseline HGS-PyVRP in most problem settings.
C.6 DETAILS OF COMPARISON OF CODE RELIABILITY AND SOLUTION FEASIBILITY
Runtime Error Rate (RER). Let Vere be the number of generated programs that terminate with a runtime failure. The Runtime Error Rate calculated
RER = Var x 100%,
where is the total number of generated programs across all VRP variants. A high RER indicates large proportion of solutions that fail to execute due logical flaws, syntax mistakes.
26

---

Published as a conference paper at ICLR 2026
Table 10: Runtime Analysis Across Testing Phase and Solver Generation Phase.
Phase
Component
CVRP
CVRPL
CVRPTW
OCVRP
CVRPLIW
OCYRPL
OCYRPTW
OCVRPLIW
Testing
Problem Description
0.10
0.12
6.11
0.10
0.15
0.17
0.15
0.20
Solution Derivation
2.10
6.93
9.31
2.20
8.90
5.65
11.15
17.27
Problem Description
0.10
0.13
0.12
0.10
0.16
0.16
0.15
0.20
Solver Generation
Code Generation
12:28
12.88
18.38
23.94
27,43
28.20
24.85
30.50
Solution Derivation
0.003
1.08
0.009
0.005
1.10
1.21
0.010
1.42
Different VSP Problems
CyAPL
CX1PTW
CYARTW
DAARTW
0CW97
acvern
ACVARITW
1000
T //uumbor of morovement torationst
4000
5202
8000
22000
Time of Testinng Dslasetim)
10.0
15.0
Figure 4: Comparison of solution quality across (a) different numbers of improvement iterations T and (b) different testing time, evaluated over multiple VRP variants.
Success Rate (SR). Denote by Vsuce the number of generated programs that successfully produce an feasible solution for the target VRP instance. The Success Rate is given by
Vance 100%.
SR
This metric measures the percentage of generated programs that both execute without errors and produce solution feasible with respect to the constraints of the input instance.
Table 12 compares the code reliability and solution feasibility of three solvers, SGE, DRoC, and AFL, across a broad range of VRP variants. Because SGE and DRoC can generate runtime-error- free code only for relatively simple problems where the constraints are easy to satisfy, SGE succeeds solely on TSP, while DRoC performs reliably TSP, CVRP, and CVRPL, producing code that both compiles correctly and passes feasibility checks. In contrast, our model AFL consistently produces executable code and achieves fcasibility verification across all listed variants. In this table, a v indicates that the solver achieves both Code Reliability and Solution Feasibility, whereas a x denotes failure meet one both of these criteria.
C.7 COMPARISON ON ATSP BENCKMARK
We evaluate our model on the ATSP benchmark (Johnson McGeoch 1997). which contains 18 instances with optimal solutions ranging from 17 to 443 nodes, to assess its applicability. The Asymmetric Traveling Salesman Problem (ATSP) is a variant of the classical TSP in which the distance from customer to customer ý may differ from the distance from customer to customer i, making the problem more challenging and representative real-world routing scenarios such as one-way street networks asymmetric transportation costs. The results, presented in Table 13 show that our model achieves consistently favorable performance on this task.
C.8 COMPARISON ON ACVRP BENCKMARK
We further evaluate our model on the ACVRP benchmark (Helsgaun, 2017), which provides 120 capacity-constranned instances with asymmetric distance matrices and customer sizes ranging from 16 to 200. The Asymmetric Capacitated Vehicle Routing Problem (ACVRP) extends the classical VRP by allowing the travel cost from location to j to differ from that of the reverse direction, while also imposing vehicle-capacity constraints. This combination of asymmetric travel costs and capac- ity limits makes ACVRP a challenging and practical testbed, reflecting real distribution networks where one-way streets differing traffic conditions create directional cost differences. The results,
27

---

Published as a conference paper at ICLR 2026
Table 11: Comparison results on 48 standard 100-node benchmark instances.
Obj.
Gap(S)
Obj
Gap(58
Gape()
Obj.
Gap(
Obj.
Gap(5e)
Obj.
Gap(5))
CVRP
CVRPL
CVRPTW
OCVRP
CVRPLTW
OCVRPL
HRP
13.62
15.77
25,42
9:73
25.76
9.72
OR-Tools
16.28
4.18
16.47
5.30
25.81
1.51
10.00
2.75
26.26
1,90
10.00
2.79
RE-POMO
AFL (T=500)
16.66
6.66
17.36
10.08
26.60
4.64
10.37
6.58
27.60
7.14
10.37
6,68
AFL (T-2000)
16.22
3.84
17.03
7.99
26.02
2.36
10.11
3.91
26.96
4.66
10.15
4.42
AFL.(T-1000)
15.99
2.38
16.84
6.79
25.79
1.46
9.99
2.67
26.56
3.11
9.99
2.78
OCVRETW
OCVRPPIWW
CVRPB
CVRPBL
CVRPBTW
OCVRPS
HGS--PVRR
16.93
16.93
14.78
10:34
OR-Tools
17.03
0.58
17.02
0.73
14,93
3.85
15.43
4.34
29.95
1.60
10.58
2.32
RE-POMO
17.39
2.72
17.39
2.73
15,02
4.47
15.63
5.70
30.34
2.96
10.84
4.82
AFL(7-500)
17.36
2,34
17.61
4.02
15.48
7.65
16.18
9:47
31.50
6.89
11.67
12.86
AFL
17.14
1.24
17.32
2.30
15.07
4.80
15.71
6.29
30.63
3.94
11.34
9.67
(T=1000)
17.04
CVRPBLTW
OCVRPBL
OCVRPBTW
OCVRPBLTW
MDCVRP
MDCVRPL
HGS-PPVRP
29.03
10.34
19,16
19.16
11.89
11.90
OR-Tools
29.83
2.77
10.58
2.36
19,30
0.76
19.31
0.77
15.52
5.27
12.52
5.24
RE-POMO
30.80
3.28
10.84
4.83
19.61
2.34
19.61
2.34
15.11
30.10
16.25
37.19
19.67
AFL (T-2000)
30.64
5.55
10.72
3.68
19.41
1.30
19.41
1,30
12.56
5.63
12.54
5.38
AFL. (7=1000))
30.33
4.48
10.58
2.32
19.29
0.68
19.29
0.68
12.39
4.21
12.36
3.87
MDCVRPTW
MDDCVRP
MDCVRFELTW
MDOCVRPL
MDOCVRPTW
MDOCVRPLIW
HGS-PyVRP
19.33
7.97
19.35
7.97
13,00
13.00
OR-Tools
19.62
1.55
RF-POMO
26.60
38.16
10.23
28.52
27.04
40.22
10.23
28.55
17.54
35.43
17.54
35.43
AFL
20.33
5.17
8.35
4.77
20.91
8.06
8.36
4.89
13.28
2.12
13.28
2.15
AFL (T-2000)
19.83
2.69
8.21
3.01
20.52
6.05
8.20
2.97
13.14
1.05
13.14
1.08
(T=1100)000)
19.61
MDCVRPB
MDCVRPBL
MDCVRPBTW
MDOCVRPB
MDOCCRPBLL
HGV-PPVVP
11.64
11.68
22.03
8.69
22,06
8.69
OR-Tools
12.22
5.01
12.22
4.62
22,40
1.69
8.87
2.33
22,43
1,70
8.87
2.13
RE-POMO
15:11
30.10
15.71
34.80
30,46
38 80
10.88
25.48
30.97
41.00
10.89
25.49
AFL(T=500)
12.54
7.73
12.81
9.67
23.49
6.27
9.03
3.91
23.56
6.80
9:03
3.91
(T'2000)
12:47
AFL (T=1000)
12.18
4.63
12.26
4.97
22,57
2
8.84
1.73
22,85
3.58
8.83
1.61
MDOCVRPETW
MDDCCRPBLITW
CVRPMB
CVRPMBL
CVRPMBTW
OCVRPMB
HGS-PPyRRP
12.96
12.96
13.54
13.78
25.51
9:01
OR-Tools
1449
11.79
14.19
11.79
14,93
10.27
15.42
11.90
29.97
17:48
10.59
17.54
RE-POMO
15.29
10.84
AFL (T-500)
13.40
3.40
13.22
2.01
14.81
9.38
14.62
6.09
27.38
7.33
9.38
4.11
AFL (T-2000)
13.26
2.31
13.09
1.00
14.38
6.20
14.18
2.90
26.71
4.70
9.23
2.43
AFL
13.20
1.85
13.04
0.62
14.17
4.65
13.91
0.94
26.40
3.49
9.14
1.43
CYRPMBLTW
OCVRPMBL
OCVRPMBTW
OCVRPMBLTW
MDCVRPMB
MDCVRPMBL
HGS-PyVRP
OR-Tools
30.45
17.36
10.59
17.54
13.78
19.31
13.78
12.22
14.37
12.23
14.23
RE-POMO
28.89
11.89
10.84
20:32
18.62
9.72
18.62
9.71
15.09
41.78
15:37
44.05
AFL (T=500)
27.46
6.23
9.37
4.00
17.40
2.53
17.39
2.47
11.62
8,50
11.45
6.91
(T=2000)
26.62
2,98
9.23
2.45
17.17
1.18
17.18
1.24
11.29
5.71
11.17
1.30
(T=1000)
MICCVPMMRTW
MDOCVRPMM
MDCVRREIT
MDOCVRPMBIL
MDDCVRPMBBTW
MIXCCVRPMBBLJW
HGS-PyVRP
19.29
7.66
19.35
7.66
12.96
12.96
OR-Tools
22.39
16.12
8.88
15.83
19.66
1.58
8.87
15.78
14.49
11.79
14.49
11.79
RE-POMO
28.68
49.27
10.90
42.41
27.04
40.22
10.90
42.37
18.69
44.70
18.69
44.69
(T-500)
6.89
7.89
AFI. (T-2000))))
20.12
4.30
7,80
1.83
20.52
6.05
7.80
1.82
13.26
2.31
13.09
1.00
AFL (T=
19.89
3.11
7.74
1.04
20.28
4.81
7.75
1.17
13.20
1.85
13.04
0.62
Note: Oby. demotes the objective value, and Gapr represents the relative gap watt. HGS PyVRP. Lower values indicate betier performance, Bold numhers denate cases where the gop from SOTA is within 35,, which considened acceprahle for fully automated and self-contained framewori..
summarized in Table 14 demonstrate that our model maintains strong code reliability and solution feasibility across all ACVRP instances.
28

---

Published as a conference paper at ICLR 2026
Table 12: Comparison of Code Reliability and Solution Feasibility.
Solver
TSP
CVRP
VRPL
VRPTW
OVRP
VRPLTW OVRPL OVRPTW OVRPLTW
SGE
DRoC
X
X
X
AFL
Solver
ECVRP
ECVRPI.
ECVRPTW
FOCVRP ECVRPLTW FOCVRPI. FOCVRPTW ROCVRPLTW
SGE
x
X
K
DRoC
X
AFL
Table 13: Comparison of AFL and Greedy on ATSP benchmark.
Instance
ft53
ft70
ftv33
ftv35
ftv:88
ftv44
ftv47
ftv55
ftv64
Best
6905
38673
1286
1473
1530
1613
1776
1608
1839
Greedy Obj.
8816
43524
1637
1817
1765
1898
2353
2163
2262
Greedy Gap (%)
27.68
27.29
23.35
15.36
17.67
32.49
34.51
23.00
AFI. Obj.
7480
39519
1340
1500
1570
1657
1790
1630
1882
AFL Gap (%)
8.33
2.19
4.20
1.83
2.61
2.73
0.79
1.37
2.34
Instance
ftv70
ftv
kro124p
p43
rbg323
rbg358
rbg4403
rbg443
ry48p
Best
1950
2755
36233)
5620
1326
1163
2465
2720
14422
Greedy Obj.
2359
1794
3552
16215
Greedy Gap (%)
20.97
41.09
24.46
1,21
31.37
54.26
44.10
42.50
12.43
AFL Obj.
2031
2964
37987
5620
1358
1172
2510
2780
14958
AFL Gap (%)
7.59
4.85
0.00
2.41
0.77
1.83
3.72
C.9 COMPARISON ON SOP BENCKMARK
also evaluate our model on SOP benchmark (Renaud et al. 1996). which contains 39 in- stances with optimal solutions and sizes ranging from 9 to 380 nodes. The Sequential Ordering Problem (SOP) a generalization of the Traveling Salesman Problem that introduces precedence constraints, requiring certain nodes to be visited before others. This added ordering requirement captures practical scenarios such as production sequencing and logistics scheduling, where tasks must follow specified order. The results, presented Table [5] show that our model effectively handles these precedence constraints while maintaining high solution quality.
C.10 AFL's SENSITIVITY TO DIFFERENT LLMS
We tested AFL with two additional LLMs: Claude-Sonie 2onude--0omee:4-025555//1/1 14 and GPT-4o. The results are shown in Table C.9 These experiments help us understand how different LLMs affect AFL's performance and stability.
Solution Quality. From the results, we see that the strength of the LLM does influence solution quality. More powerful models generate more accurate and complete heuristics, which leads to better objective values. In our tests, the overall performance ranking is: Claude-Sonnet-4 > GPT- 4.1 GPT-4o. Although the final performance changes with different LLMSs, AFI. improves how well each model implements the required heuristics. As shown in Table 9 both the standard prompt and alternative prompt strategies, showing that AFL can reliably boost a model's ability to produce working heuristics.
AFL performs better than
Code Reliability. Most importantly, code reliability stays stable across all LLMs. No matter which model use, AFL always generates executable code and feasible solutions. This shows that the multi-agent design keeps the whole pipeline stable even when the LLM is not very strong, proving that framework is robust and widely applicable.
C.11 EXPERIMENT ON DIFFERENT INPUT FORMAT
As VRPLIB is the standard format in the VRP domain, we further evaluated AFL on JSON and CSV inputs assess its robustness to alternative data representations commonly used in industrial
29

---

Published as a conference paper at ICLR 2026
Table 14: Comparison of AFI. and Greedy on 120 ACVRP instances.
Irolance
X40-000-1
A-C-1052
A-C-10011
A-C-100:4
A-C-1055
A-C-13645
A-C-100-1
1-C-005
A-C-1009
A40-100-10
A-C-100-2
(ee [X]
213
1722
1550
1273
1315
15:0)
1:30
1227
2353
1992
2007
Groedy Cap (96)
42.92
57.4
74.77
77.80
46.00
58.07
72.12
55.06
$1.07
58.00
26.83
Cup (%)
7.00
9,41
31.36
11.33
8.52
13.45
Tresiio
1-1200011
A-6-190-1
SarO
2701
1821
Gresly Cup
27:35
25.38
30.53
AFL Gap 96)
340
16.56
14.24
26.11
28,99
0.00
9.54
16.69
16.44
19.06
35.63
41.51
Instanee
A-0-150-5
4-6-150.6
A- A-0-159-2
A-G-150-8
A-G-1509
A-G-150-10
A-G-150-11
A-G-159-12
A-G-159-13
A-0-150-1
A A-0-150-15
A-G-159-16
1201
1118
111
107
1591
100
1157
118T
1019
108)
1099
Geady Gipp (9)
19.8
91.11
51
130.1
100.09
72.33
70.13
125 13
Gap 196
30.30
25,37
1315
36.33
15.35
23.85
27.46
Indancs
A-0:19317
A-C-150-1 15015
A-0-150-19
A-C-150-35
X-0:200:1
A-C3002
A-0-20033
A-C-300-
A-2:200:5
3-05500-5
A-C-203-
A-G-2003
Tear
1253
Groedy Cup
56.80
200.74
7.51
64.22
134.5
92.03
105.5
AFL (ap (9)
0.00
18.09
38.10
5.01
10.99
18.73
15.55
27.59
17.18
17.58
26.94
0.09
Isaasse
K4-200
A-E-00511 II A4C-99111
140-00113
A-1--0--11
A-1-30--1
934-300-15
A40-20015
A4--00-16
A-G-100-
Iiee (k)
1718
KT6
101N
1087
1916
130
-10
831
1831
1738
1053
Guady Gap
100.11
26.33
11699
172.11
165-13
251H
6540
94-1
56.66
Eap
Instenpe
A-0-4-1
A-T.4.3
A.0.43
A.1-4.4
A-014-3
A-144-6
A-0.4-7
A-1-4.3
A-0.4.9
A-1-4.10
A.C-4:11
A-0-4.12
Bost Obj.
1671
1108
1927
992
1447
1251
1142
1023
1826
1150
1523
1521
Gready Gap (96)
75.10
42.60
54.93
93.16
74.91
78.02
109.8
90.32
35.32
140.35
42.88
111.35
APL (%)
20.35
10.74
0.00
5.53
19.42
42.15
23,82
41.61
10.46
27.65
19.63
25.33
Insiance
A-U-4-13
A-U-4-14
A-0-4-15
A-054-16
4-0.4-17
A-U-4-18
A-U54-19
0-0.4.3
6-U
A-U-62
A-U-5.3
A-U-6-1
Best Obj
2055
1716
1250
993
825
1986
1622
1453
1203
911
1452
819
Graady %)
12.12
82.81
94.57
44.12
87.27
14.44
70.28
53.68
64.23
66.81
$7.08
17.75
AFL (sp
13.74
14.34
35.74
9.05
24.97
6.70
8.45
9.02
26.22
12.27
7.71
28.94
A-1-a-5
A-1-6-5
A-1-5-7
A-11-69
A-1-6-10
A-C-6-11
A-1-6-12
A-1-6-13
A-1-5-14
A-1-6-15
A-U-0-16
Bost Ohl
1086
9X0
1016
816
1111
144
1341
Greddy Gap (%)
90.98
133.64
92.03
215.11
93.88
262.62
101.87
92.53
64.12
88:22
172.71
283.38
APL Gap (%)
6.72
19,00
8.17
36,86
13.42
32.11
96.15
29.52
26.04
27.96
12.23
43.35
Inwance Olo).
A-U-6-17
A-U-6-18
X-U-6-19
X-U-6-20
X-0-8-1
A-U3322
A-U33-
A-U-84
A-U-8.
A-0-8-6
A-0-8-7
A-U-8-8
1363
1193
1069
98T
Gready Gup (%)
98.05
40.34
102.51
47.52
121.10
1791.31
62.14
116.23
127.63
AFL Gup (%)
0.00
1.41
41.16
18.71
36.70
29.23
32.18
31,89
26.20
17.77
52.93
27.93
Esttacee
A.U.5-9
A.L.TTT
A. A.L:8:11
A-1-8-12
U-U.3:13
A-0.1.14
A-U.3-13
A-U-3-16
A.U.3:17
A-U-4.18
18
1.
A-U.$-20
Bes
1298
216
300
827
1081
1378
682
591
1298
1015
Greedy Gup
53.51
73.46
116.5
187.50
81.58
125.64
250.59
72.41
164.43
45.61
93.00
133.02
29.50
26,07
15.20
0000
35,08
14.09
Table 15: Comparison of AFL and Greedy on SOP instances.
Instance
ESC12
ESC25
ESC47
ESC63
ESC78
br17.10
br17.12
ft53.1
ft53.2
ft53.3
Best Obj.
1675
1681
1288
62
18230
55
7531
8062
10262
Greedy Gap (%)
21.43
99.88
198.37
22.58
100.00
43.64
43.64
38.15
56.98
47.41
AFL Gap (%)
3.16
12.14
84.32
0.00
0.00
5.45
5.45
5.11
1.28
12.45
Instance
ft53.4
ft70.1
ft70.2
ft70.3
R170.4
kro124p.1
kro 124.2
k2p.24p.3
kro124p.4
p43.1
Best Obj.
14425
39313
40419
42535
53530
39420
41336
49499
76103
28140
Greedy Gap (%)
28.59
17.16
19.64
22.41
100.00
33.37
39.64
56.10
29.33
5.29
AFL Gap (%)
0.93
4.16
4.89
7.03
0.88
8.66
10.29
7.28
1.69
0.23
Instance
p43.2
p43.3
p43.4
prob42
prob100
rbg048a
rbg050c
rbg109a
rbg150a
rhg 174a
Best Obj.
28480
28835
83005
243
1163
351
467
1038
1750
2033
Greedy Gap (%)
4.37
8.69
2.70
88.48
184.69
44.16
21.63
39.02
23.89
20.22
AFL. Gap (%)
0.02
0.99
0.05
30.45
94.41
6.55
0.64
0.77
0.46
0.00
Instance
rbg253a
rbg323a
rbg341a
rbg358a
rbg378a
ry48p.1
ry48p.2
ry48p.3
ry48p.4
Best Ohj.
2950
3140
2568
2545
2816
15805
16074
19490
31446
Greedy Gap (%)
20.61
28.41
47.43
61.49
45.92
42.32
30.09
40.29
30.94
AFL Gap (%)
0.00
1.21
3.08
2.67
2.66
5.90
6.07
12.72
0.73
pipelines and benchmark integrations. As shown in Table 17 the model consistently maintains strong performance and solution feasibility across different input formats.
C.12 EXPERIMENT ON LARGE CVRP INSTANCES
AFL is capable of handling extremely large VRP instances. Our current approach generates a general-purpose heuristic from small instance (e.g.. 50-node instance, which can be obtained by trimming the data of the target instance and serves as a minimal example containing all relevant information such constraints, problem characteristics, and format specifications). The generated solver is then applied to large-scale cases. As shown in Table [8] AFL achieves competitive perfor- mance CVRPLib-XXX (Gao et al. 2024) with more than 16,000 customers.
30

---

Published as a conference paper at ICLR 2026
Table 16: Comparison results different L.M..
R=50
100
n=
1=100
Objj
(%)
(6)
Time (m)
Obj
Gup (%)
Time (m)
Obj.
Cup (%)
Time (m)
Obj.
Gap (1)
Time (m)
HGS-PyVRP
10.37
10.40
15.62
20.50
10.59
10.40
15.77
20.80
DCVRPLIW OCVRPL OCVRP CVRPL
5.52
Clunde 4
10.54
1.65
15,90
1.79
5.12
3,02
6.85
16.44
4.25
25.79
GPT
10.59
2.12
2.10
15.99
2.38
4.38
11,18
5.57
6,33
16.84
6.79
25,48
HGS- PRPP
OCVRPTN CYRPLTW CVRPTW
16.03
10.40
25:42
20.90
6.51
10.40
9.73
20.80
GPT
16.45
2,62
12.62
26.88
5.74
25.44
6.87
5.53
3.07
10.36
6.47
7.38
Clande
26.19
33.78
4.1
0.99
25.79
38.45
6.64
2.00
2.67
5.52
HGS-PyVRP
16.36
10,40
25.76
20.50
6.51
10:40
9.72
20.80
GPT to
16.79
2.63
8.54
26.81
4.08
35.48
6.81
4.61
7.13
10.33
6.28
13:42
Clande 4
16.55
1.16
7.32
26.50
2.87
30.94
6.59
1.23
7.43
9.91
1.95
16.59
9.99
2.78
HGS-PyVRP
10.51
10.40
16.93
20.50
10.51
10.40
16.93
20,80
GPT 40
10.91
3.81
11.89
17.68
4.43
27.39
10.88
3.52
11.29
17.66
4.31
58.89
Clande 4
10.63
1.14
14.89
17:24
1.83
35.95
10.64
1.24
12.23
17.26
1.95
62.24
GPT4.1
10.55
0.38
11.15
17.04
49.05
10.58
0.67
17.27
17.19
1.54
70.31
Table 17: Combined Results on JSON and CSV Format Inputs.
n-50
n=100
D-50
n=100
Olg
Gap (%)
Time (m)
Gap (9)
Time (m)
City
Gop (%)
Time (m)
Gap (3k)
Time (m)
2.99
4.99
CVRP
CVRPL
CSV
10.69
3.09
2,61
16.40
4.99
5.50
10.75
1,51
4.73
16.31
3.42
20.72
ISON
CVRP
TW
16:26
1.43
12.97
26.17
2.95
21.22
26.11
OCVRP
6.71
3.07
2.07
10:02
5.04
5.38
JSON
CYRPI.
16.03
1.65
26.52
2.95
31.64
OCVRP
6.73
3.38
6.78
10.26
5.56
16.46
CSV
16.61
1.52
8.99
26.48
2.80
32.10
6.71
3,07
7.96
10.11
4.01
18.24
OCVRP
17.19
55.47
OCVRP
17.15
82.31
CSV
TW
17.25
LTW
69.19
During code generation, also enforce practical constraint: during solution derivation, the algo- rithm must execute within 10 seconds for the given instance. If this limit is exceeded, the system triggers a timeout, then the Revision Agent (RA) and Error Analysis Agent (EAA) are trigered to refine the algorithm for improved efficiency. We will add clarifications of this mechanism in the revised manuscript. Looking ahead, we will further enhance efficiency by exploring oujti-objective evolutionary strategies to evolve the generated algorithms, jointly optimizing both performance and computational efficiency.
D EXAMPLES OF PROMPTS AND OUTPUTS
D.1 SUBTASK 1: PROBLEM DESCRIPTION
In the problem description subtask, we divide the GA's work into two sequential phases to reduce its cognitive load and improve overall accuracy. In the first phase, the agent generates the description, constraints, and the specific problem type. In the second phase, it produces the input specification, expected output, and the optimization objective. After these two phases are completed, the JA evaluates the entire draft for consistency and correctness, and the RA subsequently refines each component as needed.
D.1.1 GENERATION AGENT(GA)
Prompt 1:
We need solve VRP instance. will provide you with the instance. Please analyze carefully. First, give concise description of the problem type in [ ], explaining what the problem is about.
31

---

Published as a conference paper at ICLR 2026
Table 18: Performance of AFL on CVRPLib-XXI.
Gap(
L1(3k)
L2(4k)
A1(6k)
A2(7k)
G1(10k)
G2(IK)
BI(1KK) B2(16k)
POMO
75.30
78.16
112.27
159.22
LEHD
14.04
26.30
18.90
26.40
27.23
38.45
35.94
40.76
Our
8.12
13:34
8.60
13.62
8.02
14.85
7.01
16.56
Second, identify its constraints and list them clearly in numbered format (1), 2), 3), ... within []. For each constraint, write both the abbreviation (if any) and a short explanation (e.g.. 'Capacity (C): vehicles have limited capacity."). Do not include instance-specific details like the exact number of nodes, vehicles, or capacity values.
When analyzing, be as comprehensive possible: consider not only the common constraints but also more general ones, such as whether each customer can be visited multiple times, whether all routes must start and end at a depot, other structural constraints that might apply. You may refer to the following typical constraint categories as guidance, but you are not limited to them:
Electricity (E): electric vehicles are subject fuel constraints. Each vehicle has a limited fuel capacity, fuel is consumed proportionally the distance traveled related fuel consumption rate, and vehicles must recharge at designated charging stations when necessary. Recharging consumes time related the refuel rate and remaining fuel.
Capacity (C): vehicles have limited capacity.
Open Route (O): vehicles do not return to the depot.
Backhaul (B): vehicles must handle linchaul (deliveries) first, then backhaul (pickups).
Mixed (M): vehicles may mix deliveries and pickups in the same route.
Duration Limit (L): each route a maximum distance or time limit.
Time Windows (TW): customers must be served within specified time intervals.
Multi-depot (MD): there are multiple depots.
Visit constraint (V): each customer may only be visited once.
Depot constraint (D): routes must start and end at the depot.
Finally, write the standard problem type abbreviation (e.g., TSP, CVRP, CVRPL, VRPTW, PDP, OVRP, MDVRP, ECVRP) enclosed in"
Check again whether the constraints fit the specific name; the Visit constraint should be present.
Output exactly three lines in this order:
1) [problem description]
2) [constraints]
3) "specific name"
Below is the .vrp instance content: <vrp text>
Output 1:
1) [The Capacitated Vehicle Routing Problem (CVRP) involves determining optimal routes for a flect of vehicles to deliver goods to set of customers while minimizing total distance traveled and ensuring that vehicle capacity is not exceeded.]
32

---

Published as a conference paper at ICLR 2026
2) [1) Capacity (C): the total demand on any route cannot exceed vehicle capacity. 2) Visit (V): each customer is visited exactly once. 3) Depot (D); every route starts and ends at the depot.]
3) "CVRP"
Prompt 2:
We need design an algorithm for the following VRP instance. The details of the instance are: <Output1>.
Based on this description and the instance contents, please specify:
First, list the essential input elements an algorithm would require from the instance. Element names must not contain spaces; use underscores instead.
Second, describe precisely what the algorithm should output (e.g., a best feasible set of vehicle routes that satisfy all listed constraints).
Third, describe clearly the optimization objective (e.g., minimize total travel distance, minimize fleet size, minimize lateness).
Important: Each the three answers (input, output, objective) must be enclosed in [] as shown. Do not include instance-specific details like the exact number of nodes, vehicles, capacity values. Also verify that every listed input actually provided by the instance content.
Output exactly three lines in this order:
4) [input]
5) [output]
6) [objective]
Below is the .vrp instance content: <vrp text>
Output 2:
4) [depot, node coordinates, demands, vehicle capacity]
5) [A of vehicle routes, each beginning and ending at the depot, visiting every customer exactly once while respecting capacity constraints.]
6) Minimiiee the total travel distance.]
D.1.2 JUDGMENT AGENT (JA)
Prompt:
You are a VRP expert. will give you:
1) The original .vpp file content
2) GPT's first answer (problem description + constraints + specific name)
3) GPT's second answer (input, output, objective)
Your task to judge correctness:
For the first answer: check whether the problem description, listed constraints, and specific name are consistent with .vrp file contents. Specifically, check for contradictions in the follow- ing pairs:
problem description vs. vrp file
33

---

Published as a conference paper at ICLR 2026
constraints vs. .vp file
specific name vs. .rp file
problem description vs. constraints
problem description vs. specific name
constraints vs. specific name
any contradictions exist, treat the .vrp file as the ground truth and mark as incorrect. everything is consistent, mark it as correct. Check again whether the constraints fit the specific name and problem description. If correct, return "True' with a short explanation. If wrong, return' Felurn'False' with a short explanation.
For the second answer: check if input, output, and optimization objective are valid and con- sistent with the VRP instance and the constraints. Input must correspond only elements explicitly defined in the instance file. Every input listed must be directly obtainable from the instance. Input element names must not contain spaces; use underscores Output must clearly describe feasible vehicle routes respecting all constraints. The optimization objective must align with VRP goals.
If any contradictions exist, treat the .rp file as the ground truth and mark it incorrect. If everything is consistent, mark it as correct. correct, return 'True' with short explanation. wrong, return 'False' with short explanation.
Output format must be exactly lines:
1) rightl:
True/False
jud1: explanation
3) right2: True/False
4) jud2: explanation
Here is the VRP file: <vrp_text>
Here GPT's first answer:
1>
Here is GPT's second answer: sproblen_desariptionn
Output:
1) rightl: True
2) judl: The first answer accurately reflects the .rp file, providing clear problem description and consistent constraints (Capacity, Visit, Depot) along with the correct specific name, with contradictions.
3) right2: False
4) jud2: The second answer includes input objective elements that are not fully supported by the CVRP instance spriccecsseciicllll...... it omits capacity from the input-so so it is not fully consistent with the file's available data and constraints.
D.1.3 REVISION AGENTS (RA)
The formats of Output 1 and Output are identical to those in Section D.I.I
Prompt 1:
34

---

Published as a conference paper at ICLR 2026
We need solve VRP instance. carefully.
will provide you with the instance. Please analyze
Step Give a concise description of the problem type explaining what the problem is about.
Step 2: Identify its constraints and list them clearly in numbered format (1), 2), 3), ...) within [] For each constraint, write both the abbreviation (if any) and a short explanation (e.g., 'Capacity (C): vehicles have limited capacity."). Do not include instance-specific details like the exact number of nodes, vehicles, or capacity values. Consider whether customers may be visited once or multiple times, and whether all routes must start/end at a depot (unless open routes are specified).
Reference constraint categories (not exhaustive):
Electricity (BB: electric vehicles are subject to fuel constraints. Each vehicle has a limited fuel capacity, fuel is consumed proportionally to the distance traveled related to fuel consumption rate, and vehicles must recharge at designated charging stations when necessary. Recharging consumes time related to the refuel rate and remaining fuel.
Capacity (C): vehicles have limited capacity.
Open Route (O): vehicles do not return to the depot.
Backhaul (B): deliveries first, then pickups.
Mixed (M): deliverics and pickups can mixed.
Distance Limit (L): each route has maximum distance or time limit.
Time Windows (TW): customers must be served within specific time intervals.
Multi-depot (MD): multiple depots instead of one.
Visit constraint (V): whether each customer can be visited only once.
Depot constraint (D): routes must start and end at the depot.
Step Write the standard problem type abbreviation (e.g.. TSP, CVRP, CVRPL) enclosed in Ensure the abbreviation is consistent with the constraints.
Check again that the constraints fit the specific name, and include the Visit constraint.
Here is your previous answer: <ans>
However, there were some issues identified: <jud>
Now, please correct your answer strictly according to the rules above.
Output format (exactly three lines):
1) [problem description]
2) [constraints]
3) "specific name"
Below is the .vrp instance content: <vrp text>
Prompt 2:
We need design an algorithm for the following VRP instance. The details of the instance are: <Output 1>.
Based on this description and the instance contents, please provide:
35

---

Published as a conference paper at ICLR 2026
Step List the essential elements an algorithm would require from the instance, and the list must include depot.
Step Describe precisely what the algorithm should output (e.g., set of feasible vehicle routes that satisfy all listed constraints).
Step Describe clearly the optimization objective (e.g., minimize total travel distance, mini- mize fleet size, minimize lateness).
Important rules:
Each of the three answers (input, output, objective) must be enclosed in exactly as shown.
Do not include instance-specific details like the exact number nodes, vehicles, capacity values.
Step element names must not contain spaces; use underscores instead.
Here is your previous answer: <ans>
Issues identified in that answer: <jud>
Now, please correct your answer strictly according to the rules above.
Final output format (exactly three lines):
4) [input]
5) [output]
6) [objective]
Below is the .vrp instance content: <vrp_text>
D.2 SUBTASK 2: CODE GENERATION
D.2.1
GENERATION AGENT (GA)
Prompt (Partly):
Here is the code you generated before (for reference, please improve or extend needed): <code>
We are working on VRP problem instance:
Problem description: <probl em de_desc>
Constraints: <constraints>
Specific name:
Input definition: <input_def>
Output definition: <eutput_def>
Optimization objective: <objective>
Important rules:
You are given the raw .vrp file content for context.
Do not hardcode any instance-specific details such as the number of nodes, vehicle count, or node coordinates.
Any functions generated must be general-purpose and reusable for any VRP instance.
Task: Generate Python function named exactly 'read vrp(path: str)":
36

---

Published as a conference paper at ICLR 2026
The function must read a .vp file and parse its content strictly according the items listed in the Input definition.
Every element mentioned in the Input definition must be parsed and included. No additional fields may be added, and no required fields may be omitted.
The function must return a dictionary where:
Keys exactly match the names in the Input definition, using underscores "-" instead of spaces.
Each value is returned as list, even if it contains only single element.
A section may end with "-1", "EOF", the beginning of another section header (lines in all caps ending with ".SECTIONN") and the function must handle all of these cases.
The implementation must be seneral-purposee do hardcode any specifc details.
Output format requirement:
Return only valid Python code inside single code block marked " "python with no extra text, explanations, or comments outside the code block.
If previous code is provided, include it (or improved version) together with the newly gener- ated function in the final output.
Ensure that all necessary import statements required for the code run are included the top of the code block.
Output (Partly):
import re
import math
import random
import copy
import argparse
import sys
def read_vrp (path: str):
with open (path, (r') as f:
lines readd ines ()
node_cooré_dict ()
demand dict {}
12
depot_ids ids []
13
dimension None
14
capacity None
in_node_coord_scctiie in_demand_section False in in_depot_section False for line in lines:
False
16
17
18
line line.strip() if not line line "EOF";
continue
22
if line staessttattwithh ('IMENSIIO"""
23
dimension - int (re. search (r' (1d+)) line) group (1))
continue
if sinesstart CAPACITYY);
26
capacity float (re. ((x line) groopp (1)
continue
if 1ine "NODE_COOM 3
29
Truc
30
iil_demand_secttion = False
in oenccttt__sccion False
continue
if 1ine DDEMAND SOOMAND_SECTIONE
37

---

Published as a conference paper at ICLR 2026
in nodencee__ce coord section False in_demand_section True
36
in_depot_section Falsc
37
continue
if 1ine == -
Lin_node_coord_sette
False
40
in in False
41
in_cepot_section True
42
continue
if in node_ coorddoeetiooon
tokens dine.split. ()
45
icx int (tokens [0]]
46
x float (tokens [1])
float (tokens [2]]
node cevee_cord_diicee [idx]
[x, yl
49
elif in
50
tokens = splt ()
icx = int (tokens
float (1])
demand_dict
54
elif in_depot_sectionn val - int (1ine)
55
56
if val == -1:
continue
58
cepot iisidddpppp append (val)
59
if not depot_ids:
60
raise ValueError (' Depot informatien missing in vRP file.')
if dimension is None:
raise ValueError D'MMENSION missing in VRP file.')
63
if capacity None:
64
raise ValueError('
( CAPACITY missing in VRP file.')
65
all_ids = sorted boodd__cordd_iccee
if len (all_ids) != dimension:
67
raise ValueError P'rrsed node_coord length does not match DIMENSTON.'")
68
if len (demand_dict) !- dimension:
raise Valuekrror Parsed demand_dict length does not match DIMENSION.")
70
depot id depot_ids idsl0]
71
if depot_ic id not in
72
raise ValueError ('Dero id not present in node coord dict.') customer_iás [nid for nid in all_ids if nid != depot_id] node_id_list [depot_id] sorted ccstomerrso node_coordinatee
74
35
[node_coord_dict [nid] for nid in node_id_list demands = [demand_dict [nid] for nid in nids_id_list]
76
return {
" "depot": [depot_id],
79
"node_ "onde__corrinatee" node_coordinates,
80
"demanas": demands,
Sachiclle_cpacityy Icapacity]
Listing 1: Example route feasibility check
D.2.2 JUDGMENT AGENT (JA)
Prompt (Partly):
You are a strict Python code reviewer and VRP expert.
Here is the generated Python code: <code>
We are working on VRP problem instance:
38

---

Published as a conference paper at ICLR 2026
Problem description: <problem_dees desc>
Constraints: <constraints>
Specific name: <specific_name>
Input definition: <input_def>
Output definition: <output_def>
Optimization objective: <objective>
Evaluation rules:
Only evaluate the given code snippet. Ignore any other functions or unrelated context.
Check if the code has syntax errors or logical bugs that would prevent execution. For 'read vrp":
Ensure it extracts exactly the elements listed in the Input definition.
No additional fields may added, and no required fields may be omitted.
Verify that each extracted element is explicitly available in the provided .vrp file content.
Do not assume fabricate values not present in the file.
A section may end with -1, EOF, or the beginning of another section header (e.g., lines in all caps ending with SECTION); must handle all of these situations.
Confirm that the function returns all required fields in dictionary format, and each value must be returned as list (array); keys must match the Input definition exactly, using underscores. instead of spaces.
The function 'read_vrp' must be contained in the code.
Use the provided .vrp file content the only ground truth for evaluation. Do not invent or assume data that not present in the instance.
Below is the .vp instance content: <vrp_text>
Assume that the VRP file provides all elements in <input_deff
Assume that this code is only for <specific_nane <problem_desc>,
Assume that node IDs preserve the exact order given in the input .vrp file, are unique, and contain no duplicates.
Your task:
If the code is fully correct (no syntax errors, no logical bugs, all constraints satisfied, and fully consistent with the VRP rules), return rightl: True and provide a brief explanation.
If the code has any issues (syntax bugs, logical errors, constraint violations, inconsistent nam- ing, wrong input/output handling, or deviations from the specification), return rightl: False and explain why. If wrong, must also provide clear and concrete suggestions for how to fix or improve the code.
Important formatting rule: For easier parsing, the explanation suggestions must be written plain text on single line, without using any line breaks ((n) or additional colons except the ones required in right: and jud:.
Output format must be exactly lines:
right: True/False
jud: explanation and suggestions
Output:
39

---

Published as a conference paper at ICLR 2026
right: False
jud: The code is invalid because the returned dictionary key "nodd.ccooddiatt" does not match the required Input definition key "node coordinates"; rename the key to "node coordinates" to ensure consistency with the specified input definition.
D.2.3 REVISION AGENT (RA)
Prompt:
Here is the code you generated before: <prev_code>
are working on VRP problem instance.
Problem description: sproblem_desoo
Constraints: <constraints>
Specific name: <specific_name:
Input definition: <input_def>
Output definition: <output_def>
Optimization objective: <objective>
Important rules:
You are given the raw .vrp file content below for context.
Do not hardcode any instance-specific details such as number of nodes, vehicle count, or node coordinates.
The functions you generate must be general-purpose and reusable for any VRP instance.
Below the .vrp instance content (for context only): <vrp_text>
The code you generated previously has the following issues and revised suggestions: <jud>
Please correct the code according the issues above, without changing the number of functions, their names, or their signatures.
Output format requirement: Return only valid Python code inside single code block: 'python
*.y with no extra text, explanations, or comments outside the code
block.
The output format is identical to that deseribed in Sec. D.2.1
D.3
SUBTASK 3: SOLUTION DERIVATION
D.3.1
ERROR ANALYSIS AGENTS (EAA)
Prompt:
You strict Python code reviewer and VRP expert.
We are working on VRP problem instance.
Problem description: <problem_ddeeeeeeeeeeeppppppeepe desc>
Constraints: <constraints>
Specific name: <specific_name
Input definition: <input_def>
40

---

Published as a conference paper at ICLR 2026
Output definition: <output_def>
Optimization objective: <objective
The code was generated using the following rules: <all rules in generation code>
Use the provided vrp file content as the only ground truth for analysis. Do not invent or assume data that is present in the instance.
Below the .vrp instance content: <vrp_text>
The code execution failed and produced the following error message: cerror_mag"
Your task: Analyse the error message and explain why the error happened. Provide clear and concrete suggestions for how to fix improve the code.
Formatting rule: For easier parsing, your explanation and suggestions must be written strictly in plain text single line, without using any line breaks ((n) or additional colons except the required jud: prefix.
Output format must be exactly line:
1) jud: explanation and suggestions
Output:
jud:
The error occurred because the algorithm timed out while generating routes for the CVRP instance, indicating that the current implementations of the initial and insert functions have excessively high computational complexity; to fix this, simplify the construction strategy in initial by reducing unnecessary nested loops, and in insert replace exhaustive cost evaluations with a priority queue or incremental cost update to lower overall runtime.
The JA and RA are identical to those described in Section D.2.2 and Section D.2.3
E THE USE OF LARGE LANGUAGE MODELS
In this study, large language models (LLMs) are not merely tools for polishing text but an integral component of the proposed framework. They serve as autonomous agents within our framework, while the core ideas and the manuscript itself were conceived, prepared, and finalized by the authors.
41


Reviews:
[{"review_id": "YCnBUJc2BI", "reviewer": "Reviewer_QnWc", "summary": "This paper proposes an LLM-based agent framework (AFL) for end-to-end solving of the Vehicle Routing Problem (VRP). The framework proceeds from the original VRPLIB instance to executable solver code and feasible solutions, without requiring manually written modules or external solvers. The entire workflow is decomposed into three subtasks: problem description, code generation, and solution derivation, executed by four dedicated agents: a Generating Agent (GA), a Judging Agent (JA), a Revising Agent (RA), and an Error Analysis Agent (EAA). These agents iteratively generate, inspect, and repair code under instance-specific constraints. At the core of the system lies a unified destroy (insert improvement heuristic), combined with simulated annealing for solution acceptance and rigorous constraint verification (capacity, time windows, and energy).\n\nExperimental results show that AFL achieves 0% runtime error rate (RER) and 100% success rate (SR) across 17 VRP variants, and produces objective values competitive with traditional solvers and state-of-the-art LLM baselines such as SGE and DRoC.", "questions": "Please See Weaknesses", "limitations": "", "rating": 4, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "(1) The paper cleanly explains the three subtasks and the four roles (GA/JA/RA/EAA) and how they interact (including buffer reuse and EAA-driven debugging loops). In addition, the overview figure and tables mapping constraints to VRPLIB fields aid comprehension.\n\n(2) The proposed multi-agent, verification-centric code generation framework substantially reduces execution failures in LLM-based systems. It demonstrates strong reliability and scalability across a wide range of VRP variants, suggesting that the approach could serve as a promising blueprint for extending agentic LLM frameworks to other combinatorial optimization domains.", "weaknesses": "(1) Although the paper reports objective gaps (e.g., compared to the best-known or HGS reference algorithms), a more detailed runtime analysis, including per-stage timing breakdowns and hardware/memory configurations, would clarify the computational footprint and reproducibility of AFL.\n\n(2) AFL relies on standardized VRPLIB input and Euclidean coordinates. Its robustness to schema variations (e.g., non-VRPLIB formats), data noise or missing fields, and non-Euclidean or network-based distance metrics remains unclear.\n\n(3) The experimental comparisons primarily focus on SGE and DRoC (and reference classical solvers via gap reports). Given AFL’s agentic architecture, it would be beneficial to include an additional baseline that leverages tool-augmented debugging or unit-test generation within a single-agent setup, in order to isolate the specific impact of the multi-agent design.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "3Gsv7HmuJR", "reviewer": "Reviewer_9utD", "summary": "This manuscript proposes an Agentic Framework with LLMs (AFL) for solving complex VRPs with full automation and self-containment. AFL decomposes the VRP-solving pipeline into three subtasks and employs four specialized agents to ensure cross-functional consistency and logical soundness. The framework directly extracts domain knowledge from VRPLib-format raw inputs, generates executable code without handcrafted modules, and derives feasible solutions. Extensive experiments on 20 VRP variants demonstrate that the performance of AFL is comparable to state-of-the-art solvers and significant outperformance over existing LLM-based baselines.", "questions": "Do you plan to integrate more advanced heuristic strategies (e.g., evolutionary search) to narrow the performance gap with specialized SOTA solvers? If so, how to ensure the framework remains automated and generalizable?\n\nCan AFL perform on extremely large VRP instances (e.g., 5000+ customers)? If not, are there any constraints? if so, are there any  optimization strategies to improve computational efficiency?\n\nHave you tested AFL with different LLMs (e.g., GPT-4o, Claude 3)? How do variations in LLM capabilities affect the framework's code reliability and solution quality?\n\nCan AFL be extended to handle dynamic VRPs (e.g., real-time customer additions, traffic condition changes)? If yes, what modifications are needed to the current agentic pipeline?", "limitations": "", "rating": 6, "confidence": 2, "soundness": 2, "presentation": 3, "contribution": 3, "strengths": "AFL achieves end-to-end automation from raw VRP instances to solutions by decomposing the pipeline into manageable subtasks and leveraging specialized agents. This eliminates human intervention and external solver dependencies, addressing key limitations of prior LLM-based approaches.\n\nAFL is validated on 20 diverse VRP variants, including standard benchmarks (CVRP, VRPTW), practical electric VRPs (ECVRP, ECVRPTW), and other combinatorial problems (ATSP, ACVRP, SOP). It consistently delivers competitive performance, demonstrating broad applicability to complex real-world routing scenarios.", "weaknesses": "While AFL achieves competitive performance, it still lags behind state-of-the-art solvers (e.g., HGS-PyVRP)\n\nThe performance of AFL heavily relies on the LLM's ability to generate accurate problem descriptions and code. Potential biases or inaccuracies in LLM outputs may propagate through the pipeline, affecting the final solution quality.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "iHn4wodo3Q", "reviewer": "Reviewer_KZcf", "summary": "This paper proposes a novel framework named AFL (Agentic Framework with LLMs), which aims to fully automate the solving of complex Vehicle Routing Problems (VRPs) using Large Language Models (LLMs). It decomposes the complex solving pipeline into three subtasks: problem description, code generation, and solution derivation. It also introduces four specialized LLM Agents—Generation, Critique, Revision, and Error Analysis—to collaborate, significantly improving the reliability of the generated code and the feasibility of the final solution.", "questions": "see in weakness", "limitations": "", "rating": 6, "confidence": 2, "soundness": 3, "presentation": 2, "contribution": 2, "strengths": "1. AFL achieves full end-to-end automation, from the VRP instance file to the final solution, without requiring human intervention during execution or relying on external solvers or predefined code libraries.\n2. Decomposing the complex task and introducing multiple collaborating LLM Agents with specialized roles (Generation, Critique, Revision, Error Analysis) is an effective strategy for enhancing the reliability of LLMs in complex programming and reasoning tasks. This approach is generalizable and could potentially be applied to other optimization problems.\n3. The experiments not only include standard VRPs but also specifically test complex variants more common in real-world scenarios, such as Electric VRPs (EVRPs) with multiple combined constraints, demonstrating the framework's effectiveness and generality in handling complex constraints.", "weaknesses": "1. It is highly dependent on the powerful code generation, comprehension, and reasoning capabilities of the LLM used (GPT-4.1). How the framework performs on less capable, open-source LLMs, and its sensitivity to different LLMs, warrants further investigation.\n2. Excessive time consumption is a potential issue, as shown in Table 3. How do the authors view this trade-off of sacrificing time for accuracy? In scenarios requiring rapid feedback, is this algorithm still viable?\n\nSince I am not an expert in this field,  I don't know if the novelty of this kind of prompt engineering paper is sufficient.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "RkzJb7F3DM", "reviewer": "Reviewer_KgjX", "summary": "This paper proposes a self-contained, LLM-driven framework for solving complex vehicle routing problems (VRPs). The framework is evaluated on 20 VRP variants, demonstrating its effectiveness and generality.", "questions": "Check Weakness Section.", "limitations": "", "rating": 4, "confidence": 4, "soundness": 3, "presentation": 2, "contribution": 2, "strengths": "1. The idea of designing a self-contained framework powered by LLMs to fully automate the process of solving VRPs is promising.\n2. The framework aims to generalize across various VRP formulations, which is an ambitious and potentially impactful direction.", "weaknesses": "1. The paper states that its goal is not to surpass state-of-the-art (SOTA) solvers on conventional VRPs, but rather to develop an automated and self-contained framework for handling complex VRPs. However, prior works such as [1, 2] have already demonstrated that LLMs can automatically design heuristics that achieve or even surpass SOTA performance. Compared with those works, the main novelty of this paper appears to lie in increasing automation by accepting natural language task descriptions as input. While this is an interesting step toward fully automated problem solving, it is not entirely clear how significant this improvement is in practice. Given the current framework design, I am not convinced that the heuristics generated by the proposed method would outperform those produced in [1, 2].\n2. In Tables 3 and 4, the paper reports results on eight VRPs. However, it is unclear whether the same generated heuristic is used across all problem instances of a given VRP type, or if a separate heuristic is generated for each instance. This distinction is important for assessing the generalization capability of the approach. The authors report performance under different numbers of iterations but do not provide the computational cost or runtime associated with these iterations. Such information is necessary to properly interpret the trade-off between performance and efficiency.\n3. In Table 6, the paper presents results on different benchmarks with varying numbers of nodes. It is again unclear whether the same heuristic method is reused or newly generated for each benchmark setting. Clarification on this point is needed to understand how the proposed method scales and generalizes.\n\n# References\n[1] ReEvo: Large Language Models as Hyper-Heuristics with Reflective Evolution\n\n[2] Generalizable Heuristic Generation Through Large Language Models with Meta-Optimization", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)