OptiHive: LLM-Based Optimization Solver

• OptiHive is an LLM-based framework that generates candidate optimization solvers from natural language descriptions and selects the most reliable via ensemble inference.
• It employs batched generation with rigorous filtering and latent statistical modeling to address hard and soft failure modes in autogenerated solvers.
• Empirical evaluations demonstrate significant improvements in feasibility and optimality on challenging problems such as multi-depot vehicle routing and weighted set cover.

OptiHive is an LLM-based framework for generating executable solvers for optimization problems from natural-language descriptions without iterative self-correction. It treats solver construction as an ensemble selection problem under uncertainty: a single batched LLM query generates candidate solvers, problem instances, and validation tests; unusable components are filtered out; and a latent statistical model infers which solver is most reliable despite noisy generated evidence. In the reported experiments, this design substantially improves both feasibility and optimality on difficult optimization families, including challenging variants of the Multi-Depot Vehicle Routing Problem and the Weighted Set Cover Problem (Bouscary et al., 4 Aug 2025).

1. Problem setting and design rationale

OptiHive addresses a specific failure mode of LLM-based optimization pipelines: natural-language problem descriptions can be translated into code, but the resulting solvers are often unreliable. The paper distinguishes two classes of failure. Hard failures occur when a generated solver, instance, or test does not compile or execute. Soft failures occur when the code runs but the solver is wrong, suboptimal, or evaluated by unreliable self-generated checks (Bouscary et al., 4 Aug 2025).

The framework is positioned against iterative repair systems that repeatedly generate, critique, and revise a single candidate. According to the paper, such systems add latency, can become trapped in repetitive error patterns, and often rely on the LLM’s own judgment about its outputs. OptiHive replaces that pattern with a non-iterative alternative: generate many independent candidates once, deterministically remove unusable combinations, and then infer the best solver statistically rather than by trusting self-critique (Bouscary et al., 4 Aug 2025).

This design implies a different epistemic stance toward generated artifacts. Solvers, instances, and tests are all treated as potentially noisy. The central claim is therefore not that LLM-generated tests are trustworthy, but that their aggregate behavior contains enough signal to support principled solver selection when modeled explicitly (Bouscary et al., 4 Aug 2025).

2. Batched generation, execution, and interpretability filtering

The end-to-end pipeline begins with a single batched LLM query. From the problem description and input/output format, OptiHive asks the model once to generate three independent sets: candidate solvers $\bar S$, candidate problem instances $\bar I$, and candidate validity tests $\bar T$. Each solver takes an instance and returns an optimization report; the generated instances include feasible, infeasible, or random cases; and the tests check whether a candidate solution is feasible and whether its objective value is correct (Bouscary et al., 4 Aug 2025).

Execution is exhaustive over the generated pool. For every $(s,i)\in\bar S\times\bar I$, the framework records whether solver $s$ reports a solution on instance $i$:

$$r_{s,i} = \begin{cases} 1 & \text{if solver } s \text{ reports a solution} \ 0 & \text{otherwise.} \end{cases}$$

If $r_{s,i}=1$, every test $t\in\bar T$ is run on the produced solution, yielding a Boolean outcome $r_{s,i,t}$ for each solver–instance–test triple (Bouscary et al., 4 Aug 2025).

Interpretability is enforced through a filtering stage formalized as a MILP. A triple $\bar I$0 is considered interpretable only if the solver and instance compile, execution succeeds, the solver returns a recognizable report, and the test executes without error and produces a Boolean result. Let $\bar I$1 denote the set of non-interpretable triples. OptiHive solves:

$\bar I$2

subject to

$\bar I$3

with binary decision variables indicating whether a solver, instance, or test is retained. After solving, the retained sets

$\bar I$4

have the property that every triple in $\bar I$5 is interpretable (Bouscary et al., 4 Aug 2025).

The filtering stage has two roles. First, it removes syntactically or semantically broken components. Second, it guarantees that the surviving solver–instance–test combinations can be analyzed without hidden execution failures, which is the paper’s basis for claiming fully interpretable outputs (Bouscary et al., 4 Aug 2025).

3. Latent statistical model for solver quality

After filtering, OptiHive still does not assume that observed reports and test outcomes are ground truth. Instead, it introduces latent variables for instance feasibility and solver-output feasibility. For each instance $\bar I$6,

$\bar I$7

and for each solver–instance pair $\bar I$8 with $\bar I$9,

$\bar T$0

These variables are unobserved and inferred from the solver reports and aggregated test outcomes (Bouscary et al., 4 Aug 2025).

The solver noise model assigns each solver $\bar T$1 three parameters: $\bar T$2, the false positive rate on infeasible instances; $\bar T$3, the false negative rate on feasible instances; and $\bar T$4, the probability that a reported solution is actually feasible given that the instance is feasible and the solver returned a report. The corresponding conditional probabilities are

$\bar T$5

$\bar T$6

$\bar T$7

$\bar T$8

This separates three distinct failure modes: falsely claiming feasibility, missing feasible cases, and returning infeasible solutions even when a feasible instance exists (Bouscary et al., 4 Aug 2025).

Test outcomes are modeled with a Beta-Binomial rather than an independent Bernoulli family. For a solver–instance pair with $\bar T$9, OptiHive aggregates test results as

$(s,i)\in\bar S\times\bar I$0

Conditioned on feasibility, the count $(s,i)\in\bar S\times\bar I$1 follows one of two Beta-Binomial distributions:

$(s,i)\in\bar S\times\bar I$2

$(s,i)\in\bar S\times\bar I$3

The stated rationale is that tests are not independent and some solutions are intrinsically harder to validate than others (Bouscary et al., 4 Aug 2025).

Parameter estimation is performed with EM. Denoting the full parameter set by

$(s,i)\in\bar S\times\bar I$4

the update is

$(s,i)\in\bar S\times\bar I$5

This alternates between estimating latent feasibility variables and updating solver/test parameters, yielding posterior estimates of solver reliability and solution quality (Bouscary et al., 4 Aug 2025).

4. Solver selection criterion and uncertainty quantification

The inferred latent model is used to score solvers rather than merely to estimate pass rates. For each solver $(s,i)\in\bar S\times\bar I$6, the paper defines $(s,i)\in\bar S\times\bar I$7 as the expected objective value over feasible reported solutions:

$(s,i)\in\bar S\times\bar I$8

where $(s,i)\in\bar S\times\bar I$9 is the reported objective value (Bouscary et al., 4 Aug 2025).

Selection then proceeds by scalarizing three quantities: expected objective quality when the solver succeeds, penalties for misses on feasible instances, and penalties for false feasibility or infeasible reporting. Default penalties are set to about

$s$0

where $s$1 is the maximum absolute objective value observed. The chosen solver is the minimizer of the scalarized score over the retained set $s$2 (Bouscary et al., 4 Aug 2025).

This procedure is significant because it does not collapse evaluation to a single observed pass/fail statistic. The same solver can be penalized differently depending on whether it tends to miss feasible instances, incorrectly report feasibility on infeasible instances, or return poor objectives on genuinely feasible instances. A plausible implication is that OptiHive’s uncertainty quantification is not merely diagnostic; it is part of the selection mechanism itself (Bouscary et al., 4 Aug 2025).

The paper also notes a Pareto-front view of the same decision problem. Solvers can first be organized by estimated error rates and objective values, after which final selection can be made either by a priori preferences or by scalarized minimization. This suggests that the framework can support different operational tradeoffs without changing the underlying inference model (Bouscary et al., 4 Aug 2025).

5. Empirical evaluation and ablation findings

The reported experimental setup generates 100 solvers, 100 instances, and 100 tests per problem, precomputes all interpretable solver–instance and solver–instance–test outputs, and repeats the selection process 10,000 times with random sampling. The LLMs used are gpt-4.1-nano, gpt-4.1-mini, and o3, with temperature 0.7; EM iterations are capped at 100; and the runtime of filtering and inference is reported as under 1 second, negligible relative to LLM generation (Bouscary et al., 4 Aug 2025).

Evaluation is conducted on two optimization families. The first is the Multi-Depot Vehicle Routing Problem in two variants: DCMDVRP and MDVRP+OBS. The second is the Weighted Set Cover Problem in three variants: K-robust WSCP, Probabilistic WSCP, and Time-dependent WSCP. The obstacle-rich MDVRP+OBS and the time-dependent WSCP are presented as the hardest cases because they require multi-step algorithmic reasoning that LLM-generated code handles poorly in a single shot (Bouscary et al., 4 Aug 2025).

Variant	Feasibility, baseline $s$3 OptiHive	Optimality, baseline $s$4 OptiHive
DCMDVRP	43% $s$5 98.74%	40% $s$6 97.03%
MDVRP+OBS	35% $s$7 99.88%	5% $s$8 92.1%
Time-dependent WSCP	12% $s$9 74.5%	3% $i$0 64.1%

The most prominent result is the improvement on MDVRP+OBS, where optimality rises from 5% to 92.1%. For the hardest WSCP variant, optimality rises from 3% to 64.1%, and the paper remarks that perfect selection with 50 solvers would yield 78.2% optimality, so OptiHive recovers a large fraction of the oracle gap (Bouscary et al., 4 Aug 2025).

The ablation studies identify asymmetries among the three generated component types. Increasing the number of candidate solvers is reported as the strongest driver of performance, especially on hard problems, because solver diversity raises the probability of sampling at least one optimal solver. Diverse instances are described as critical for distinguishing optimal, near-optimal, and subtly flawed solvers. Additional tests help, but their benefit saturates relatively quickly once major failure modes are covered (Bouscary et al., 4 Aug 2025).

A further ablation degrades one component type at a time by generating it with a weaker model. The system remains robust, but on the time-dependent WSCP poorer instances or poorer tests are substantially more damaging. The paper identifies this as evidence for a key assumption: tests are usually easier to generate and more reliable than solvers, but that assumption weakens on temporally structured optimization tasks (Bouscary et al., 4 Aug 2025).

6. Relation to adjacent “hive” frameworks and broader significance

OptiHive belongs to a larger cluster of recent systems that use hive or swarm metaphors, but its technical objective is distinct. “The Society of HiveMind” formulates multi-agent orchestration as optimization over communication DAGs among foundation models, using REINFORCE, genetic algorithms, or task-conditioned graph prediction to improve collective reasoning. It is therefore a framework for optimizing inter-agent communication topology rather than for selecting executable optimization solvers from generated artifacts (Mamie et al., 7 Mar 2025).

“Hive” in “From An LLM Swarm To A PDDL-Empowered HIVE” is instead a model-selection and planning engine. It uses a Capability Knowledge Graph $i$1, PDDL domains and actions, prompt-driven task parsing, and execution-time snippet retrieval to plan chains of atomic actions across multiple models under user constraints. Its focus is multi-modal task planning and explainable execution rather than solver induction for formal optimization tasks (Vyas et al., 2024).

DeepHive addresses yet another problem: automated discovery of swarm-based optimization policies through multi-agent reinforcement learning with PPO. There, the learned object is a swarm-update policy for expensive black-box optimization, shared across agents and trained on benchmark functions. In that sense, DeepHive is closer to optimizer design in the classical metaheuristic sense, whereas OptiHive is closer to code-based solver synthesis and ensemble selection (Ikponmwoba et al., 2023).

The hive metaphor also appears in precision-apiculture research, but with a different referent. COMB is a compact, open-source, modular mechatronic platform for controlled sensing and localized actuation inside observation hives, including an XY positioning stage, a sealed Movable Access Window, and interchangeable payloads such as a dance/signaling module, comb scanner, and electromagnetic wing actuator (Kedia et al., 4 Apr 2026). STAG-CN treats an apiary as a sensor graph and predicts disease onset from inter-hive dependencies (Kang, 15 Mar 2026). Those systems are materially or biologically hive-centered, whereas OptiHive uses the metaphor for collective selection under uncertainty.

A common misconception is therefore to treat all “Hive” or “OptiHive-style” systems as variants of the same architecture. The cited literature instead shows several non-equivalent families: solver ensemble selection (Bouscary et al., 4 Aug 2025), multi-agent communication-topology optimization (Mamie et al., 7 Mar 2025), PDDL-backed multi-model planning (Vyas et al., 2024), learned swarm-control policies (Ikponmwoba et al., 2023), and in-hive robotic or sensing infrastructures (Kedia et al., 4 Apr 2026, Kang, 15 Mar 2026). Their overlap is conceptual rather than architectural.

7. Limitations, assumptions, and implications

The paper states several explicit limitations. OptiHive requires that the sampled pool contain at least one correct solver; if the LLM never produces a good solver, the framework cannot recover one. Its effectiveness also depends on the diversity of generated instances, because homogeneous instances provide weak signal for the latent model. A further assumption is that tests are easier to generate than solvers; the time-dependent WSCP demonstrates that this assumption can break down. Finally, deterministic low-temperature sampling may fail to generate valid candidates, whereas higher temperature improves diversity (Bouscary et al., 4 Aug 2025).

These limitations define the boundary of the method. OptiHive is not a universal substitute for better base-model code generation. It is a selection-and-inference procedure layered on top of noisy generation, and its guarantees are therefore conditional on the quality and diversity of the generated candidate pool (Bouscary et al., 4 Aug 2025).

Within those limits, the framework contributes a specific methodological shift in LLM-based optimization: away from repeated self-repair and toward parallel generation plus latent inference. Its significance lies in the claim that high-quality solver selection can be achieved without trusting self-critique, without serial repair loops, and with explicit uncertainty modeling over both generated tests and generated instances. In the hardest reported benchmark, that shift corresponds to an increase in optimality from 5% to 92.1%, which is the paper’s clearest quantitative statement of the approach’s effect (Bouscary et al., 4 Aug 2025).