LLMs Can Design Near-Optimal OR Algorithms | AI Research

What the paper is about

We ask whether large language models (LLMs) can design effective algorithms for well-specified operations research (OR) problems. We study inventory control, queueing network control, and assortment optimization. We evaluate two levels of LLM use: at level 1, the model receives one problem instance and returns a solution for that instance; at level 2, it receives only the problem class description and broad parameter ranges, and returns an algorithm that maps instance parameters to solutions. Human input is minimal: we give one untuned prompt that describes the problem, and the model has access to a Python sandbox tool with a fixed compute budget. The strongest model we test, gpt-5.6-sol, matches or outperforms the best existing method on almost all evaluated instances. This holds even at level 2, where the returned algorithm is fixed before seeing the evaluation instances. Performance also improves sharply across models released less than eight months apart, suggesting that this capability is moving quickly. Thus, for the well-specified operations problems we study, a single untuned LLM query can already produce algorithms competitive with specialized methods. These results suggest that frontier LLMs can be a serious empirical baseline for algorithm design in well-specified OR problems.

What it covers

LLMs Can Design Near-Optimal OR Algorithms Jackie Baek † † thanks: Stern School of Business, New York University, [email protected] Abstract We ask whether large language models (LLMs) can design effective algorithms for well-specified operations research (OR) problems. We study inventory control, queueing network control, and assortment optimization. We evaluate two levels of LLM use: at level 1, the model receives one problem instance and returns a solution for that instance; at level 2, it receives only the problem class description and broad parameter ranges, and returns an algorithm that maps instance parameters to solutions. Human input is minimal: we give one untuned prompt that describes the problem, and the model has access to a Python sandbox tool with a fixed compute budget. The strongest model we test, gpt-5.6-sol , matches or outperforms the best existing method on almost all evaluated instances. This holds even at level 2, where the returned algorithm is fixed before seeing the evaluation instances. Performance also improves sharply across models released less than eight months apart, suggesting that this capability is moving quickly. Thus, for the well-specified operations problems we study, a single untuned LLM query can already produce algorithms competitive with specialized methods. These results suggest that frontier LLMs can be a serious empirical baseline for algorithm design in well-specified OR problems. 1 Introduction Operations research (OR) has a long tradition of developing specialized algorithms for specific operational problems. Inventory control, queueing network control, assortment optimization, routing, and revenue management each have their own models, structural results, approximation methods, and computational heuristics. These algorithms are usually designed by researchers who use problem-specific knowledge to exploit the structure of a particular model or application domain. Large language models (LLMs) are a new technology with broad capabilities. They can write code ( Chen et al., 2021 ) , solve long-standing open math problems ( OpenAI, 2026 ) , and propose procedures across many domains ( Romera-Paredes et al., 2024 ) . This raises a natural question: How good are LLMs at designing algorithms for operations problems? Answering this question can help clarify how LLMs may change the division of work in operations research. Solving a real operations problem involves many steps, including formulation, algorithm design, implementation, validation, and deployment. Each step requires different kinds of expertise and judgment. We isolate the algorithm-design step and ask whether a general-purpose model can produce high-performing algorithms. We study this question experimentally on settings where the problem is mathematically well specified but exact optimization is difficult. Given a formal description of the problem, we ask an LLM either to produce a solution for a particular instance or to design an algorithm that maps instance parameters to solutions. We use the LLM in a simple one-query protocol: we provide one prompt that states the problem and the output format, without doing any prompt tuning or providing hints about the structure of a good solution. We study three canonical OR domains with long literatures: inventory control, queueing network control, and assortment optimization. For inventory, we use the instances evaluated by Gijsbrechts et al. (2022) : lost-sales systems with deterministic and stochastic lead times, dual sourcing, and multi-echelon distribution. For queueing, we use the multiclass queueing-network instances of Dai and Gluzman (2022) : criss-cross networks, the N-model, and extended six-class reentrant-line networks. For assortment, we use the hard benchmark instances of Guo et al. (2025) : mixed-MNL, nested-logit, and constrained mixed-MNL choice models. Together, these benchmarks give 34 inventory instances, 13 queueing instances, and 3,393 assortment instances. A common feature of the source papers is that they use these instances to compare modern deep learning or reinforcement-learning approaches with classical methods. We use an LLM in two ways, differing in where it enters the algorithm-design process:

• Level 1: the LLM is given a single instance with its numeric parameters, and returns a solution to that instance.

• Level 2: the LLM is given a problem class and broad parameter ranges. It returns an algorithm that maps instance parameters to solutions, and that algorithm is then run on every evaluation instance in the class. The returned algorithm is asked to produce each instance-specific solution within 30 seconds. For example, in assortment optimization, a level-1 query outputs one assortment for one specified choice model, whereas a level-2 query outputs an algorithm that maps choice-model parameters to an assortment. Level 2 is closer to the standard notion of algorithm design; we also test level 1 because it is a strong and natural benchmark. The methods developed in the papers whose instances we use are level-1 methods: their policies are trained separately for each instance ( Gijsbrechts et al., 2022 ; Dai and Gluzman, 2022 ; Guo et al., 2025 ) . For most evaluated instances, level 1 cannot rely on exhaustive enumeration due to the large solution space. We evaluate four LLMs that span two providers and less than eight months of public release dates: gpt-5.1 , gpt-5.4 , and gpt-5.6-sol from OpenAI, and claude-fable-5 from Anthropic. 1 1 1 The public release dates are November 12, 2025 for gpt-5.1 , March 5, 2026 for gpt-5.4 , June 9, 2026 for claude-fable-5 (with access restored on July 1, 2026 after a temporary suspension), and July 9, 2026 for gpt-5.6-sol , based on the providers’ public release notes. All code, prompts, and the complete run records (every LLM query with its reasoning summaries, executed code, outputs, and token usage) are publicly available. 2 2 2 https://anonymous.4open.science/r/llm-or-algorithms-F9F2 . 1.1 Main findings Level 1 Level 2 Problem class Best existing methods n n Gain No worse Gain No worse (%) (%) (%) (%) Inventory (cost) Lost sales, deterministic lead time exact DP ( ℓ ≤ 4 \ell\leq 4 ); tuned capped base stock; mixed strategy 19 +1.32 100 +1.27 94.7 Lost sales, stochastic lead time tuned capped base stock 7 +1.55 85.7 +0.60 100 Dual sourcing exact DP 6 +0.04 100 +0.01 100 Multi-echelon distribution tuned constant order-up-to 2 +22.78 100 +11.21 100 Queueing (cost) Criss-cross exact DP 6 +0.00 100 +0.00 100 N-model exact DP 1 -0.19 0.0 -0.17 0.0 Extended six-class PPO trained per instance ( Dai and Gluzman, 2022 ) 6 +5.50 66.7 +5.00 83.3 Assortment (revenue) MMNL NN + local search; ADXOpt 628 ∗ +0.00 100 +0.00 100 Nested logit LP policy of Kunnumkal (2023) ; ADXOpt; NN + local search 971 ∗ -1.27 87.5 -1.24 87.4 Constrained MMNL conic MIP; NN + local search 1794 ∗ +0.00 100 +0.00 100 ∗ Level 2 is evaluated on every instance of the class; level 1 needs one query per instance and is evaluated on a stratified subset of 72 instances for MMNL, 48 instances for Nested logit, 36 instances for Constrained MMNL. Table 1 : Summary of gpt-5.6-sol ’s results against the best-performing method on that instance among those reported by the source paper. Gain is the mean relative cost reduction (inventory and queueing) or revenue gain (assortment) over that method, in percent; positive means the LLM is better. No worse is the share of instances on which the LLM is within 0.1 % 0.1% of or better than it. The second column lists every method that is strictly the best on at least one instance of the class, and methods that tie the best on every instance. Level 1 uses one query per instance; level 2 uses one algorithm per class, evaluated on every instance. Table 1 summarizes the results for the strongest model, gpt-5.6-sol , across all ten problem classes and both levels. Each entry compares the LLM with the best existing method for that instance : in each domain, the best of the methods reported by the source paper on that instance, including the exact optimum where available. gpt-5.6-sol matches or beats the best existing method on nearly every instance. Across the ten classes in Table 1 , gpt-5.6-sol has mean performance no worse than the best existing method in eight classes at both levels. At each level, it is no worse on every instance in six classes. This is a demanding comparison: the comparator is chosen instance by instance from the existing methods, including exact dynamic programs or exact solvers where available. Inventory and queueing are uniformly strong. The LLM improves on the best existing method on average in all four inventory classes; in queueing, it matches the DP-computed optimum on the criss-cross instances, is within 0.2 % 0.2% of optimal on the N-model, and beats the per-instance PPO comparator on most reentrant-line instances. In assortment, it matches the optimum on all MMNL instances and the best known value on all constrained-MMNL instances. Nested logit is the main exception: the LLM matches the near-optimal LP policy of Kunnumkal (2023) on 87 % 87% of instances but loses on a difficult tail, with mean revenue 1.2 % 1.2% lower. Level 2 works well for structurally specified classes. Level-2 algorithms often perform nearly as well as level-1 solutions, even though they are written from only a problem-class description and broad parameter ranges. Across the ten classes in Table 1 , level 2 has mean performance no worse than the best existing method in eight classes and matches it on every instance in six classes. Thus, the LLM is not only solving isolated instances: a single untuned query can produce reusable algorithmic structure for a class of instances. The generated algorithms have recognizable structure. The level-2 algorithms often use ideas from the OR literature. In inventory, the strongest algorithm generalizes a capped base-stock policy, using a projected inventory statistic rather than the raw inventory position. In assortment, the strongest solvers combine small exact routines, greedy and relaxation-based starts, and local improvement. In queueing, the returned policies use familiar dynamic-control ideas, including dynamic programming on small state spaces and pressure-based scheduling rules on larger networks. This makes the outputs different from black-box learned policies (e.g., deep RL-based methods) or generic solver calls: they are inspectable algorithms whose steps can be explained, modified, and potentially improved. Figure 1 : Preview of the inventory results on deterministic lost-sales instances (lower is better). Each dot is one instance, plotted as the percentage increase in cost relative to the best existing method on that instance (the best tuned benchmark policy, or the exact optimum on the six short-lead-time instances); negative values mean the LLM policy has lower cost. The vertical bar marks the median, and each panel reports its worst instance. Level 1 uses one query per instance; level 2 uses one returned algorithm for the whole deterministic-lead-time family. Dots above + 25 % +25% are clipped and shown at the right edge. Performance improves with stronger models. The four models we evaluate were released within eight months of one another, yet their performance differs substantially, especially at level 2. Figure 1 gives a preview of this pattern for deterministic lost-sales inventory: each dot is one instance, showing the cost of the LLM policy relative to the best existing method on that instance, for all four models at both levels. In the figure, gpt-5.1 has significantly higher costs than the benchmark on most instances, while gpt-5.4 is much closer but still leaves visible gaps, especially at level 2. This suggests that LLM algorithm-design capability is moving quickly, and that frontier LLMs are becoming a natural empirical baseline for hard OR problems. 1.2 Implications and limitations Implications for OR research. These experiments take a step toward understanding where LLMs may fit in the OR pipeline. In the well-specified benchmark problems we study, a strong LLM can already perform part of the algorithm-design step. In settings where this works, algorithm design becomes much cheaper, which may shift attention toward parts of the pipeline the model does not address, such as formulation, validation, and deployment. These results do not imply that LLMs replace algorithmic research. The generated algorithms often resemble variants and combinations of known algorithmic structures. We cannot run the counterfactual of evaluating a model trained without this literature, so we do not know how much of the performance depends on it. Whether LLMs can design equally strong algorithms for problem classes without an established algorithmic literature is an open question. What our results do show is that, in domains with well-specified models and rich algorithmic traditions, current LLMs can produce high-performing and interpretable algorithms from a minimal prompt. Empirical evidence and contamination. Our evidence is empirical and limited to three OR settings: inventory control, queueing network control, and assortment optimization. A natural next step is to test the same framework on a wider range of operations problems. We also cannot rule out that benchmark-specific information, such as instances, solutions, or performance comparisons, appeared in model training. In Section 6.2 , we partly address this concern by evaluating the level-2 algorithms on new parameter values and generated instances outside the main benchmarks. Lastly, our results are empirical: we do not prove approximation guarantees, and we do not know how robust the LLM-generated algorithms are outside the instance families we test. The queueing experiments also show that level-2 performance depends on how the problem class is defined: a class that is too broad can lead the model to return a generic policy that fails on some subclasses. Roadmap. The next subsection reviews the related literature. Section 2 gives the shared experimental setup and protocol used for all three domains. Section 3 presents the inventory experiments, Section 4 presents the queueing experiments, and Section 5 presents the assortment experiments. Section 6 checks whether the main results survive removing sandbox compute, extend to new instances, and are stable across repeated LLM queries. Section 7 concludes. 1.3 Related Work LLMs for operations research and operational decision-making. A growing literature studies LLMs in operational decision-making. We organize these works by where the LLM enters the decision pipeline: formulation, supplying model inputs, designing the solution, and making the decision. Our work is related to the third stage and touches the fourth. Surveys of the area span these stages and emphasize reliability, modeling errors, and tool use ( Wang and Li, 2025 ; Simchi-Levi et al., 2026 ) . 1. Formulating the model. One stream treats formulation as a translation problem: given natural-language problem statements, LLMs produce optimization models, solver code, or model files ( Ramamonjison et al., 2023 ; AhmadiTeshnizi et al., 2024 ; Huang et al., 2025 ; Zhou et al., 2025 ) . Other work builds benchmarks, training data, and search procedures for the same formulation task ( Astorga et al., 2025 ; Huang et al., 2024 ; Yang et al., 2025 ; Jiang et al., 2024 ; Zhang et al., 2024 ) . A second group studies messier, more realistic settings in which the model is built, repaired, or specified interactively rather than translated from a clean problem statement ( Xiao et al., 2024 ; Li et al., 2023 ; Ao et al., 2026 ; Drossman et al., 2026 ; Lawless et al., 2024 ; Liang et al., 2026 ) . 2. Constructing model inputs. A second stream uses LLMs to construct or elicit the primitives an optimization model needs after the model class has been chosen. Baek et al. (2026a) use LLM-generated personas to build distributions for sample-average approximation, Huang and Wang (2026) use LLM-powered virtual populations for demand simulation and pricing, and Duan et al. (2025) study human–LLM clarification of inventory-control inputs. Our experiment deliberately removes these first two stages. The optimization problem is already specified in precise mathematical terms, so we do not test formulation. Every parameter is known exactly and stated in the prompt, so we do not test data generation. 3. Designing the solution method. A third stream uses LLMs to design solution methods rather than to formulate models, supply inputs, or make a single decision. Our paper belongs in this stream: at level 2, the model returns a reusable algorithm that maps future instance parameters to decisions. Zhang et al. (2026) use an LLM to generate basis functions for recourse decision rules in stochastic optimization; relative to that work, we leave the choice of algorithmic structure to the model rather than enriching a fixed decision-rule class. Other work embeds the LLM in an iterative algorithm-discovery loop. In inventory, Huang et al. (2026) use evolutionary search for white-box policies, and related systems repeatedly generate, evaluate, and revise code or heuristic ideas ( Romera-Paredes et al., 2024 ; Liu et al., 2024 ; Ye et al., 2024 ; van Stein and Bäck, 2025 ; Zheng et al., 2025 ; Google DeepMind, 2025 ; Yang et al., 2024 ) ; see Liu et al. (2026) for a survey. Our goal is different from these works; we do not try to optimize the scaffold around the LLM. Instead, we ask how well a frontier LLM performs under a simple single-query protocol: the same prompt structure, sandbox, and compute budget are used across problem classes. A related line uses LLMs inside generic MILP solvers. Lawless et al. (2025) configure cutting-plane separators from a problem description and solver documentation, while other work uses LLM-guided search to generate cuts, large-neighborhood-search rules, or branching policies ( Yazdani et al., 2025 ; Ye et al., 2025 ; Hou et al., 2026 ) . These papers use LLMs to choose or generate components inside established solver pipelines, such as branch-and-cut or large-neighborhood search. 4. Direct decision-making. A fourth stream places the LLM directly in the decision seat and measures its actions in inventory, retail, economic, pricing, and supply-chain environments ( Baek et al., 2026b ; Liu et al., 2025 ; Zhao et al., 2025 ; Tanlamai et al., 2026 ; Cohen and Hage-Youssef, 2026 ; Ahmed et al., 2026 ; Long et al., 2025 ) . Related work studies LLM exploration in bandit and economic environments whose specification the model must learn through interaction ( Krishnamurthy et al., 2024 ; Fish et al., 2025 ) . Our level-1 experiments are related, especially in assortment, where the model returns a decision rather than a reusable procedure. The key difference is that, in much of the existing work, the LLM still has room for subjective judgment about formulation: what objective to pursue and which constraints matter. In our setting, we give the LLM the full mathematical specification and all parameters, and test only the quality of the resulting decision against existing algorithms. General methods for OR algorithm design. Before LLMs, the main general-purpose alternative to problem-specific algorithm design was machine learning and reinforcement learning. This literature has produced learned policies and value-function approximations for inventory control ( Van Roy et al., 1997 ; Gijsbrechts et al., 2022 ; Temizöz et al., 2025 ; Xie et al., 2026 ; Alvo et al., 2023 ; Harsha et al., 2025 ) , queueing control ( Moallemi et al., 2008 ; Shah et al., 2020 ; Qu et al., 2020 ; Liu et al., 2022 ; Wei et al., 2023 ; Dai and Gluzman, 2022 ; Chen et al., 2024 ) , and assortment optimization and routing ( Wang et al., 2023 ; Aouad and Désir, 2025 ; Li et al., 2026 ; Bello et al., 2017 ; Kool et al., 2019 ) . These methods ask a question close to ours: how much problem-specific input is needed to obtain a competitive algorithm? Existing ML/RL approaches typically require a simulator, a policy class, and substantial tuning, and they usually produce black-box policies or value functions. Our level-2 artifacts are executable algorithms written in code, so their logic can be inspected, diagnosed, and modified. Benchmarks and baselines. Our experiments use published benchmark families in inventory control, queueing-network scheduling, and assortment optimization. This follows recent calls for more systematic empirical benchmarking in stochastic OR: Dong et al. (2026) argue for evaluating algorithms on structured instance families, using reusable simulators, shared baselines, and explicit protocols rather than isolated numerical examples. Recent benchmarks for LLM-driven algorithm design, such as CO-Bench ( Sun et al., 2026 ) and HeuriGym ( Chen et al., 2026 ) , also ask LLM agents to write reusable algorithms. The inventory benchmark covers problem classes where exact dynamic programming is quickly intractable. In lost-sales inventory, the optimal policy depends on the full vector of outstanding orders, so the state space grows exponentially in the lead time and exact dynamic programming is out of reach beyond short lead times ( Zipkin, 2008b ; Zipkin, 2008a ) . This has led to specialized policy families, including myopic, base-stock, constant-order, and capped base-stock policies ( Huh et al., 2009 ; Goldberg et al., 2016 ; Xin, 2021 ; Xin, 2026 ) , which are the inventory benchmarks we evaluate against. Dual sourcing has a similar pipeline-state dependence ( Veeraraghavan and Scheller-Wolf, 2008 ) , and no tractable optimal policy is known for multi-echelon distribution; these difficulties motivate the deep reinforcement-learning benchmark of Gijsbrechts et al. (2022) . The queueing benchmark covers multiclass networks in which scheduling decisions determine which compatible queues receive service after each arrival or service completion. Exact dynamic programming is available for the small criss-cross and N-model instances, but becomes infeasible for the larger reentrant-line networks because the state is the full vector of queue lengths. This motivates comparisons with structured scheduling rules and per-instance-trained reinforcement learning policies in Dai and Gluzman (2022) . The same reentrant-line instances also appear in QGym ( Chen et al., 2024 ) ; in Section C.3 , we report a finite-horizon cross-check against QGym’s reported RL controllers. The assortment benchmark plays the same role in a setting where tractability depends sharply on the choice model. The multinomial logit model has strong structure ( Talluri and van Ryzin, 2004 ) , but assortment optimization under the mixed multinomial logit model is NP-hard even without constraints ( Bront et al., 2009 ; Rusmevichientong et al., 2014 ) , and general linear constraints add another source of difficulty. For nested logit, the problem is polynomially solvable when the nest exponent parameters are at most one ( Davis et al., 2014 ; Gallego and Topaloglu, 2014 ) , but NP-hard once they exceed one ( Davis et al., 2014 ; Kunnumkal, 2023 ) . The benchmark instances we use have nest exponent parameters in [ 2 , 3 ] [2,3] and per-nest cardinality constraints, placing them in the hard regime. We use the hard-instance benchmark of Guo et al. (2025) , which was designed to stress standard assortment heuristics. 2 Setup We begin by setting up the framework used throughout the experiments: a problem class, its instances, and the feasible solutions for each instance ( Section 2.1 ). We then formalize the different granularities at which an LLM can be queried to solve such problems ( Section 2.2 ). 2.1 Problem Classes and Instances A problem class is a tuple C = ( Θ , 𝒳 , R ) C=(\Theta,\mathcal{X},R) . Here Θ \Theta is a parameter space, and a problem instance is a specific parameter θ ∈ Θ \theta\in\Theta . For each instance, 𝒳 ⁡ ( θ ) \mathcal{X}(\theta) is the set of feasible solutions, and R ⁡ ( θ , x ) R(\theta,x) is a deterministic reward function for solution x ∈ 𝒳 ⁡ ( θ ) x\in\mathcal{X}(\theta) on instance θ \theta . An instance may contain randomness, such as demand realizations or customer choices; R R folds this randomness into a single deterministic quantity, for example through an expectation or a long-run average. The elements of 𝒳 ⁡ ( θ ) \mathcal{X}(\theta) may be simple or structured objects, and this is the only distinction we need between single-shot and sequential problems. In a single-shot problem, the solution is a single choice, such as an assortment. In a sequential problem, the decision-maker observes a state and acts repeatedly, so a solution is a policy that selects an action at each state, 𝒳 ⁡ ( θ ) = { π : 𝒮 → 𝒜 } \mathcal{X}(\theta);=;{,\pi:\mathcal{S}\to\mathcal{A},} , where 𝒮 \mathcal{S} and 𝒜 \mathcal{A} are the state and action spaces. We illustrate the primitives with two examples. Example 1 (Inventory control with lost sales) . The problem class C C is single-product lost-sales inventory control. An instance is θ = ( F , ℓ , h , p , c , q ¯ ) , \theta;=;(F,\ell,h,p,c,\bar{q}), where F F is the demand distribution, ℓ \ell is the deterministic lead time, h h is the holding cost, p p is the lost-sales penalty, c c is the unit ordering cost, and q ¯ \bar{q} is the maximum order quantity. The problem is sequential. The state is on-hand inventory together with the pipeline of outstanding orders, s = ( I , q 1 , … , q ℓ − 1 ) ∈ 𝒮 s=(I,q_{1},\ldots,q_{\ell-1})\in\mathcal{S} , and an action is an order quantity a ∈ 𝒜 = { 0 , 1 , … , q ¯ } a\in\mathcal{A}={0,1,\ldots,\bar{q}} . Thus the feasible-solution set 𝒳 ⁡ ( θ ) \mathcal{X}(\theta) is the policy space { π : 𝒮 → 𝒜 } {\pi:\mathcal{S}\to\mathcal{A}} . Each period, the order placed ℓ \ell periods earlier arrives, a new order is placed, demand d t ∼ F d_{t}\sim F is realized, and unmet demand is lost. Writing I t I_{t} for on-hand inventory after arrivals, the reward of a policy is the negative long-run average cost, R ( θ , π ) = − lim T → ∞ 1 T 𝔼 [ ∑ t = 1 T h ( I t − d t ) + + p ( d t − I t ) + + c a t ] , R(\theta,\pi);=;-\lim_{T\to\infty}\frac{1}{T},\mathbb{E}!\left[,\sum_{t=1}^{T}h,(I_{t}-d_{t})^{+}+p,(d_{t}-I_{t})^{+}+c,a_{t}\right], where a t a_{t} is the order placed in period t t . Example 2 (Assortment optimization under MMNL) . The problem class C C is assortment optimization under the mixed multinomial logit (MMNL) choice model with a cardinality cap. An instance is θ = ( m , n , ω , u , v 0 , r , k ) , \theta;=;(m,n,\omega,u,v_{0},r,k), where m m is the number of customer segments with weights ω ∈ Δ m \omega\in\Delta_{m} , n n is the number of products, u ∈ ℝ ≥ 0 m × n u\in\mathbb{R}{\geq 0}^{m\times n} are utilities, v 0 ∈ ℝ > 0 m v{0}\in\mathbb{R}{>0}^{m} are outside-option weights, r ∈ ℝ ≥ 0 n r\in\mathbb{R}{\geq 0}^{n} are prices, and k k is a cardinality cap. The problem is single-shot, and the solution space is 𝒳 ⁡ ( θ ) = { S ⊆ [ n ] : | S | ≤ k } \mathcal{X}(\theta)={S\subseteq[n]:|S|\leq k} . The reward is expected revenue: a customer in segment j j offered assortment S S buys product i ∈ S i\in S with probability u j ​ i / ( v 0 ​ j + ∑ i ′ ∈ S u j ​ i ′ ) u_{ji}/(v_{0j}+\sum_{i^{\prime}\in S}u_{ji^{\prime}}) , so R ⁡ ( θ , S ) = ∑ j = 1 m ω j ​ ∑ i ∈ S r i ​ u j ​ i v 0 ​ j + ∑ i ∈ S u j ​ i . R(\theta,S);=;\sum_{j=1}^{m}\omega_{j},\frac{\sum_{i\in S}r_{i},u_{ji}}{v_{0j}+\sum_{i\in S}u_{ji}}. How broad to make a problem class is itself a modeling choice. In Example 2 we defined the class as assortment optimization under MMNL, so an instance with a different choice model belongs to a different class. One could instead define the broader class of assortment optimization under an arbitrary choice model; that class contains the one in Example 2 . We use this flexibility in the queueing experiments by trying two definitions of level 2: a primary definition with fixed queueing-network structures, and a broader problem class definition that allows arbitrary multiclass networks up to the same size range. 2.2 Levels of LLM invocation class C C instance θ \theta solution x x returns algorithm σ \sigma LLM ( C ) (C) σ ⁡ ( θ ) \sigma(\theta) x x returns solution x x LLM ( θ ) (\theta) x x Level 2 Level 1 single-shot (assortment): x x is the offered set of products. sequential (inventory, queueing): x x is a policy, a mapping from the state to an action. Figure 2 : A level is the point in the chain at which the LLM is queried. Level 2 is queried once per class and returns an algorithm that serves every instance; level 1 is queried once per instance and returns a solution for that instance alone. A problem class induces a chain of objects, shown in Figure 2 , and an LLM can be inserted at different points in this chain. We call the choice of insertion point the level of invocation :

• Level 1. The LLM is queried once per instance: it receives θ \theta and returns a solution x ∈ 𝒳 ⁡ ( θ ) x\in\mathcal{X}(\theta) .

• Level 2. The LLM is queried once per class: it receives a description of C C and returns an algorithm σ \sigma , executable code that maps any instance θ \theta of the class to a solution σ ⁡ ( θ ) ∈ 𝒳 ⁡ ( θ ) \sigma(\theta)\in\mathcal{X}(\theta) . We use artifact for the concrete code returned by one LLM query. This applies at both levels: a level-1 artifact implements one instance-specific solution, while a level-2 artifact implements a reusable algorithm. These are the two levels our experiments use. For sequential problems the chain runs one step further, since a solution is a policy and the decision-maker