EvoX: Meta-Evolution

31.1 Overview and Motivation

All LLM-driven evolutionary systems surveyed in earlier chapters of this book share a common architectural constraint: their search strategies are either fixed at design time or parametrically adaptive, meaning they adjust pre-defined knobs such as exploration-exploitation ratios, mutation rates, or model selection weights. AlphaEvolve (Chapter 4) uses MAP-Elites with hand-tuned behavioral descriptors. OpenEvolve (Chapter 5) maintains static elite pools with fixed diversity heuristics. ShinkaEvolve (Chapter 6) applies bandit algorithms over LLM model selection. GEPA (Chapter 7) employs Pareto-frontier sampling with reflection-guided adaptation. Even AdaEvolve, from the same Berkeley lab that produced EvoX, limits itself to three-level hierarchical parameter adjustment using accumulated improvement signals.

EvoX (Liu, Agarwal et al., 2026) removes this constraint. The central observation motivating the work is threefold. First, different optimization problems require fundamentally different search strategies: packing problems benefit from iterative refinement of strong candidates, while GPU placement problems may require wholesale paradigm shifts from greedy heuristics to bin-packing formulations. Second, within a single optimization run, the optimal strategy changes over time—early stages benefit from exploration, later stages from exploitation—but the transition timing is task-dependent and cannot be predetermined. Third, parametric adaptation cannot capture qualitative shifts in search behavior. Switching from tournament selection to Pareto-frontier sampling, or from single-parent refinement to multi-parent crossover, requires changing the structure of the strategy, not its parameters.

EvoX addresses these observations by representing each search strategy as a complete Python class conforming to a defined interface, and by maintaining two coupled evolutionary processes: a fast inner loop evolving candidate solutions (one LLM call per iteration) and a slow outer loop evolving search strategies (one LLM call per stagnation event). The system is published under CC BY 4.0 and implemented within the SkyDiscover framework (github.com/skydiscover-ai/skydiscover).

31.1.1 Attribution and Lineage

EvoX was developed by a 17-person team anchored in the UC Berkeley Sky Lab, the research group responsible for foundational systems infrastructure including Apache Spark, Ray, vLLM, and Alpa. The senior authors—Ion Stoica, Matei Zaharia, Koushik Sen, Kurt Keutzer, Alvin Cheung, and Alexandros G. Dimakis—bring deep expertise in distributed systems, program analysis, neural architecture efficiency, database optimization, and generative models respectively. Ethan Boneh (Stanford University) and the Dimakis affiliation with Bespoke Labs provide cross-institutional connections. The paper was first submitted to arXiv on February 26, 2026, and revised on March 16, 2026 (arXiv:2602.23413v2).

EvoX builds directly on the SkyDiscover/AdaEvolve framework (arXiv:2602.20133) from the same lab, sharing significant author overlap and the same codebase and benchmark suite. While AdaEvolve focuses on three-level hierarchical adaptation using accumulated improvement signals, EvoX takes a fundamentally different approach: it treats the entire search strategy as an evolvable artifact rather than tuning pre-defined knobs.

31.2 Architecture

The EvoX architecture consists of two coupled control loops operating at different timescales. The inner solution-evolution loop generates and evaluates candidate solutions under the currently active search strategy. The outer meta-evolution loop monitors progress and, upon detecting stagnation, generates a replacement strategy using an LLM conditioned on the history of prior strategies and the current population state.

31.2.1 Component Overview

Component	Function	Timescale
Solution Population $D_t$	Append-only store of all evaluated candidates with scores and lineage	Grows by 1 per iteration
Search Strategy $S_k$	LLM-generated Python class implementing EvolvedProgramDatabase; governs parent selection, operator choice, and inspiration sampling via add() and sample()	Replaced on stagnation events
Solution Generator $G_{\text{sol}}$	LLM producing candidate solutions given parent, operator label, and inspiration set	Called every inner-loop iteration
Evaluator $E$	Task-specific automated scorer returning $(s, a)$ pairs	Called every inner-loop iteration
Stagnation Detector	Monitors improvement within each strategy window against threshold $\tau$	Checked after each window
Population Descriptor $\varphi(\cdot)$	Compresses population state into a statistical summary for strategy generation prompts	Computed on stagnation events
Strategy History $H$	Records all prior strategies and their performance profiles	Grows by 1 per stagnation event
Strategy Generator $G_{\text{str}}$	LLM producing new strategy implementations conditioned on $H$, $\varphi(D_t)$, and problem context	Called on stagnation events
Strategy Validator	Verifies syntactic correctness, interface conformance, and basic runtime behavior of generated strategies	Called after each strategy generation

31.2.2 The Strategy Interface Contract

The search strategy is materialized as a Python class conforming to the EvolvedProgramDatabase interface. This interface, as described in the paper and implemented in the SkyDiscover repository, defines two core methods—add() and sample()—through which the strategy controls all aspects of population management and candidate selection. The following contract definition is drawn from the paper’s description; readers should verify exact signatures and module paths against the repository.

# Paper-described interface contract (arXiv:2602.23413v2)
# Repository: github.com/skydiscover-ai/skydiscover
# Verify exact module path and signatures against the repo.

from __future__ import annotations
from typing import Dict, List, Tuple, Optional, Any
from dataclasses import dataclass


@dataclass
class EvolvedProgram:
    """A candidate program in the evolutionary population."""
    id: str                              # unique identifier
    code: str                            # program source code
    metrics: ProgramMetrics              # evaluation results
    iteration_found: int                 # creation iteration
    timestamp: float                     # wall-clock creation time
    parent_id: Optional[str]             # ID of parent program
    parent_info: Tuple[str, str]         # (operator_label, parent_id)
    metadata: Dict[str, Any]             # arbitrary metadata


class EvolvedProgramDatabase(BaseDatabase):
    """Search strategy interface governing candidate selection
    and variation in the evolutionary loop.

    The strategy reads population state from self.programs
    (inherited from BaseDatabase) and controls how new
    candidates enter the population via add() and how
    parents/operators/inspiration are selected via sample().
    """

    # Inherited from BaseDatabase (read-only access)
    programs: Dict[str, EvolvedProgram]   # all stored programs
    DIVERGE_LABEL: str                     # structural variation constant
    REFINE_LABEL: str                      # local refinement constant

    def get(self, program_id: str) -> EvolvedProgram:
        """Retrieve a program by ID."""
        ...

    def add(self, program: EvolvedProgram) -> None:
        """Add an evaluated program to the population.
        The strategy controls internal organization — elite sets,
        diversity archives, Pareto frontiers, or custom structures."""
        ...

    def sample(self) -> Tuple[
        Dict[str, EvolvedProgram],   # parent_dict: label → parent
        List[EvolvedProgram],         # inspiration_set
    ]:
        """Select parent, variation operator, and inspiration.

        Returns a two-element tuple:
          parent_dict — a single-entry dict mapping an operator
            label to the selected parent program. The label is
            one of:
              ""              → free-form variation
              REFINE_LABEL    → local, structure-preserving edits
              DIVERGE_LABEL   → structural, exploratory changes
          inspiration_set — a list of programs providing
            complementary context to the solution LLM.
        """
        ...

Key design point: the strategy reads the global population through self.programs (inherited from BaseDatabase) and may maintain additional internal state such as elite archives, operator statistics, or diversity indices. The sample() method takes no arguments—it accesses population state internally—and returns a (parent_dict, inspiration_set) tuple. The single key in parent_dict encodes the operator label, and its value is the selected parent. This convention is used consistently throughout the rest of this chapter.

Each candidate’s parent_info tuple records which variation operator was applied, enabling strategies to reason about which operators are effective for which types of parents.

31.3 Core Algorithms

31.3.1 Formal Problem Statement

EvoX formalizes LLM-driven optimization as two coupled optimization problems. The following notation is used consistently throughout this chapter:

Symbol	Meaning
$T$	Total solution-evaluation budget (fixed at 100 in all experiments)
$W$	Minimum iterations per strategy window before stagnation is checked
$\tau$	Stagnation threshold (fixed per run; paper does not report the value or sensitivity analysis)
$K$	Number of strategy-evolution events in a run (observed range: 5–15)
$D_t$	Solution population after $t$ evaluations (append-only dictionary)
$S_k$	The $k$-th search strategy (an EvolvedProgramDatabase instance)
$H$	Strategy history: list of (strategy, performance-record) pairs
$\varphi(\cdot)$	Population descriptor function compressing $D_t$ into a statistical summary
$G_{\text{sol}}$	Solution-generation LLM
$G_{\text{str}}$	Strategy-generation LLM
$E$	Task-specific evaluator returning (score, artifacts)

The inner optimization seeks to maximize the best score in the solution population under a fixed evaluation budget $T$:

where $x$ is the candidate code, $s$ is the scalar evaluation score, and $a$ represents auxiliary artifacts.

The outer optimization seeks the sequence of search strategies $S_0, S_1, \ldots, S_K$ that maximizes the final best score:

The constraint $K \leq T/W$ enforces the evaluation budget: each strategy must run for at least $W$ iterations before stagnation is assessed.

31.3.2 Two-Level Evolution Algorithm

The following pseudocode presents the complete EvoX algorithm adapted from Algorithm 1 of arXiv:2602.23413v2. The sample() call and return type match the canonical interface defined in Section 31.2.2.

# Algorithm pseudocode adapted from arXiv:2602.23413v2, Algorithm 1.
# Written in Python syntax for clarity; not a repository excerpt.

from __future__ import annotations

def evox_two_level_evolution(
    budget_T: int,              # total evaluation iterations (100)
    window_W: int,              # min iterations per strategy window
    stagnation_tau: float,      # stagnation threshold τ
    evaluator_E,                # task-specific scorer
    solution_generator_G_sol,   # LLM for candidate generation
    strategy_generator_G_str,   # LLM for strategy generation
    population_descriptor_phi,  # population summarizer φ(·)
    strategy_validator,         # Valid(S) function
    problem_description: str,   # downstream problem context
    max_retries: int,           # retry limit for strategy generation
) -> EvolvedProgram:

    # Initialize with empty population and simple random strategy
    S_k = make_initial_random_strategy()  # S_0
    D: dict[str, EvolvedProgram] = {}     # global append-only population
    H: list[tuple] = []                    # strategy history
    t = 0

    while t < budget_T:
        # ──── SOLUTION EVOLUTION (Inner Loop, W iterations) ────
        best_before = max(
            (p.metrics.combined_score for p in D.values()),
            default=float("-inf"),
        )

        for _ in range(window_W):
            if t >= budget_T:
                break

            # Strategy selects parent, operator, and inspiration
            # via the canonical interface (Section 31.2.2).
            parent_dict, inspiration_set = S_k.sample()

            # Unpack: the single key is the operator label,
            # the value is the selected parent.
            operator_label = next(iter(parent_dict))
            x_par = parent_dict[operator_label]

            # Solution LLM generates candidate
            x_prime = solution_generator_G_sol(
                parent=x_par,
                operator=operator_label,
                inspiration_set=inspiration_set,
            )

            # Evaluate candidate
            score, artifacts = evaluator_E(x_prime)

            # Wrap in EvolvedProgram and add to both the
            # strategy's internal state and global population.
            program = EvolvedProgram(
                code=x_prime,
                score=score,
                artifacts=artifacts,
                parent_info=(operator_label, x_par.id if x_par else ""),
                iteration_found=t,
            )
            S_k.add(program)       # strategy controls internal org
            D[program.id] = program  # global append-only store
            t += 1

        # ──── STAGNATION DETECTION ────
        best_after = max(
            (p.metrics.combined_score for p in D.values()),
            default=float("-inf"),
        )
        delta = best_after - best_before

        if delta < stagnation_tau:
            # ──── META-EVOLUTION (Outer Loop) ────
            perf_record = compute_performance_record(S_k)
            H.append((S_k, perf_record))

            S_new = None
            for _ in range(max_retries):
                S_candidate = strategy_generator_G_str(
                    history=H,
                    population_state=population_descriptor_phi(D),
                    problem_context=problem_description,
                )
                if strategy_validator(S_candidate):
                    S_new = S_candidate
                    break
            if S_new is not None:
                S_k = S_new   # deploy new strategy
            # else: retain current strategy (graceful degradation)

    # Return best program found
    return max(D.values(), key=lambda p: p.metrics.combined_score)

Relationship between D and S_k: The global population D is the append-only record of every evaluated candidate. The strategy S_k also receives each program via S_k.add(program), updating its own internal data structures (elite archives, operator statistics, etc.) inherited through self.programs from BaseDatabase. When a strategy is replaced after stagnation, the new strategy S_{k+1} starts with the full self.programs dictionary (all programs evaluated so far) but with fresh internal state (e.g., a new elite archive). The paper does not detail the exact handoff mechanism; readers should verify the implementation in the repository.

31.3.3 Stagnation Detection and Meta-Evolution Overhead

Stagnation is the trigger mechanism that couples the two evolutionary loops. After each strategy window of $W$ iterations, the system computes the improvement in the best score:

Stagnation is triggered if and only if $\Delta_k < \tau$, where $\tau$ is a fixed threshold. This event-driven design avoids unnecessary strategy churn during productive phases and concentrates meta-evolution effort on moments where the current strategy has exhausted its potential.

Overhead accounting. Each stagnation event produces one strategy-generation LLM call (plus additional calls for validation retries if the first candidate fails). The paper reports that $K$ typically ranges from 5 to 15 across the evaluated tasks in a $T = 100$ run:

If most strategy candidates pass validation on the first attempt ($R_k \approx 1$), the overhead is approximately $K/T$. The paper characterizes this as “approximately 6% additional LLM calls” beyond the $T = 100$ solution-generation calls, which is consistent with a median of $K \approx 6$ strategy events per run. The full observed range of $K = 5\text{--}15$ implies an overhead range of 5–15%. The paper does not separately report the distribution of retry attempts $R_k$ or the overall validation failure rate, so the 6% figure should be understood as an approximate characterization of the typical case, not an exact measurement accounting for all retry costs.

Most strategy evolution events occur in the first half of the run, as the system discovers effective strategies that sustain progress without triggering stagnation.

31.3.4 Variation Operator System

EvoX defines three variation operators that govern the type of modification the solution LLM applies. At problem initialization, a lightweight LLM generates task-specific prompts for each operator label:

Operator	Label	Scope	Example (Circle Packing)
Free-form	"" (empty)	Unconstrained exploration	Any modification the LLM deems promising
Local Refinement	REFINE_LABEL	Structure-preserving, fine-grained	Adjust individual circle positions by small deltas
Structural Variation	DIVERGE_LABEL	Coarse-grained redesign	Redesign packing strategy entirely—different algorithms or constraint relaxation

The search strategy's intelligence lies in choosing when to apply each operator based on population state. This operator selection is itself a property of the evolved strategy code, not a fixed system-level policy.

31.3.5 Strategy Validation and Execution Safety

Generated strategies undergo multi-stage validation before deployment. The paper describes a four-step pipeline: syntactic compilation, class existence verification, interface conformance checking, and runtime testing with mock data. Invalid strategies are discarded and regenerated up to a retry limit. If no valid replacement is found, the current strategy is retained—ensuring graceful degradation.

# Algorithm pseudocode for strategy validation.
# Adapted from arXiv:2602.23413v2, Component Breakdown section.
# Not a verbatim repository excerpt — verify against the repo
# for exact implementation details and any additional safety measures.

def is_valid_strategy(strategy_code: str) -> bool:
    """Validate a generated search strategy through four stages."""

    # Stage 1: Syntactic validity
    try:
        compile(strategy_code, "<strategy>", "exec")
    except SyntaxError:
        return False

    # Stage 2: Execute code to define class in isolated namespace
    namespace: dict = {}
    exec(strategy_code, namespace)  # ⚠ see safety note below
    if "EvolvedProgramDatabase" not in namespace:
        return False

    # Stage 3: Interface conformance
    cls = namespace["EvolvedProgramDatabase"]
    if not (hasattr(cls, "add") and hasattr(cls, "sample")):
        return False

    # Stage 4: Runtime test with mock data
    try:
        instance = cls()
        instance.add(mock_program)
        parent_dict, inspiration = instance.sample()
        assert isinstance(parent_dict, dict)
        assert isinstance(inspiration, list)
    except Exception:
        return False

    return True

Execution safety limitations. A critical observation is that this validation pipeline uses Python’s exec() to run LLM-generated code directly in the host process. The four-stage pipeline catches syntactic errors and interface violations, but it does not constitute a security sandbox. Specifically:

• No process or container isolation. The paper does not describe any sandboxing, containerization, or restricted execution environment for generated strategy code. The exec() call runs in the same Python process with full access to the file system, network, and system resources.
• No import restrictions. Generated strategies can import arbitrary Python modules. While the structured prompt instructs the LLM to preserve existing imports, there is no enforcement mechanism preventing additional imports.
• No resource limits. There are no documented timeouts, memory caps, or CPU limits on strategy execution. A strategy with an infinite loop in sample() or add() would hang the entire system.
• Semantic bugs undetected. The validation catches interface-level failures but cannot detect degenerate strategies—for instance, a strategy that always selects the same parent, or one that discards high-scoring candidates from its internal archive.

These limitations are consistent with EvoX’s status as a research prototype operating in a controlled evaluation environment where the LLM backbone is a commercial API producing generally well-formed code. For production deployment or adversarial settings, additional isolation measures—subprocess execution, container sandboxing, import whitelisting, and execution timeouts—would be necessary. The retry-on-failure mechanism (up to max_retries attempts) introduces additional uncharacterized LLM cost when validation fails.

31.3.6 Strategy Evolution Dynamics

The paper characterizes a typical progression through four phases during a 100-iteration run. Phase 1 (iterations 0–20): an initial random sampling strategy is deployed; the population accumulates diverse candidates, and the first stagnation event typically occurs within 10–20 iterations. Phase 2 (iterations 20–50): multiple strategy evolution events occur in rapid succession, with strategies becoming progressively more sophisticated—transitioning from random selection to fitness-proportional or elite-based selection. Phase 3 (iterations 50–80): strategy evolution events become less frequent as effective strategies are retained for longer windows. Phase 4 (iterations 80–100): few or no strategy evolution events occur; the current strategy produces diminishing but non-zero improvements.

The paper illustrates this dynamic with a signal processing case study. A fixed MAP-Elites strategy achieves rapid early improvement but stagnates around score 0.62 by iteration 60. EvoX’s evolved strategy shows slower initial progress but achieves discrete performance breakthroughs after strategy evolution events at iterations ~15 and ~55, ultimately reaching 0.74—a 19% improvement over the fixed strategy’s plateau.

31.4 Search Strategy as Code: The Key Abstraction

The most distinctive aspect of EvoX is its representation of search strategies as executable Python classes. This section examines the expressiveness this enables and how strategies evolve in practice.

31.4.1 From Simple to Sophisticated

The paper provides illustrative examples of strategies at different stages of meta-evolution. The initial strategy $S_0$ is typically a simple random sampler. After several meta-evolution steps, the LLM generates strategies incorporating UCB1-based operator selection, elite/diversity archives, operator success tracking, and stagnation-responsive scheduling. These are not incremental parameter changes—they represent qualitative architectural shifts.

The following example demonstrates the range of algorithmic patterns that emerge through meta-evolution, adapted from the paper’s illustration of generated strategies (Section 11.2). This is not a repository excerpt.

# Illustrative example: sophisticated strategy after meta-evolution.
# Adapted from arXiv:2602.23413v2, Section 11.2 strategy examples.
# NOT a repository excerpt — this is a pedagogical illustration of
# the patterns the paper reports observing in generated strategies.

from __future__ import annotations
import math
import random
from typing import Dict, List, Tuple


class EvolvedProgramDatabase(BaseDatabase):
    """Adaptive strategy with UCB1 operator selection,
    elite archive, and success-rate tracking.

    Demonstrates patterns reported by the paper: the LLM
    generates strategies incorporating new data structures,
    selection mechanisms, and feedback loops that were not
    predefined in the system architecture.
    """

    def __init__(self) -> None:
        super().__init__()
        self.elite_archive: Dict[str, EvolvedProgram] = {}
        self.operator_successes: Dict[str, int] = {
            "": 0, "REFINE": 0, "DIVERGE": 0,
        }
        self.operator_attempts: Dict[str, int] = {
            "": 1, "REFINE": 1, "DIVERGE": 1,
        }

    def add(self, program: EvolvedProgram) -> None:
        self.programs[program.id] = program
        score = program.metrics.combined_score
        if not isinstance(score, (int, float)):
            return

        # Credit operator that produced improvement
        if self.elite_archive:
            best = max(
                p.metrics.combined_score
                for p in self.elite_archive.values()
                if isinstance(p.metrics.combined_score, (int, float))
            )
            if score > best:
                label = program.parent_info[0]
                if label in self.operator_successes:
                    self.operator_successes[label] += 1

        # Maintain top-K elite archive
        self.elite_archive[program.id] = program
        if len(self.elite_archive) > 10:
            worst_id = min(
                self.elite_archive,
                key=lambda k: self.elite_archive[k].metrics.combined_score,
            )
            del self.elite_archive[worst_id]

    def sample(self) -> Tuple[Dict[str, EvolvedProgram], List[EvolvedProgram]]:
        if not self.programs:
            return {"": None}, []

        # UCB1-based operator selection
        total = sum(self.operator_attempts.values())
        ucb_scores: Dict[str, float] = {}
        for op in ("", self.REFINE_LABEL, self.DIVERGE_LABEL):
            key = op if op else ""
            n_k = self.operator_attempts.get(key, 1)
            exploit = self.operator_successes.get(key, 0) / n_k
            explore = math.sqrt(2.0 * math.log(total) / n_k)
            ucb_scores[op] = exploit + explore
        label = max(ucb_scores, key=ucb_scores.get)
        self.operator_attempts[label if label else ""] += 1

        # Elite-biased parent selection (70% elite, 30% random)
        if random.random() < 0.7 and self.elite_archive:
            parent = random.choice(list(self.elite_archive.values()))
        else:
            parent = random.choice(list(self.programs.values()))

        # Diverse inspiration from non-elite programs
        non_elite = [
            p for p in self.programs.values()
            if p.id not in self.elite_archive
        ]
        inspiration = random.sample(non_elite, min(3, len(non_elite)))

        return {label: parent}, inspiration

The transformation from a simple random strategy to this UCB1-based adaptive strategy illustrates the power of meta-evolution. The LLM generates qualitatively different strategy architectures—including new data structures (elite archive), new selection mechanisms (UCB1), and new feedback loops (operator success tracking)—none of which were predefined in the system.

31.4.2 Design Space of Generated Strategies

The strategy-as-code paradigm opens a rich design space that the LLM explores during meta-evolution. The paper reports observing elements from multiple algorithmic families in generated strategies:

Strategy Element	Observed Patterns	Traditional Analogy
Parent selection	Tournament, fitness-proportional, rank-based, elite-only, Pareto-aware	Genetic algorithm selection operators
Inspiration selection	Diversity-maximizing, structurally dissimilar, score-complementary	Crossover partner selection
Operator scheduling	UCB1 bandit, epsilon-greedy, fixed ratio, stagnation-responsive	Adaptive operator selection
Population management	Elite archives, diversity archives, age-based pruning, sliding windows	MAP-Elites, NSGA-II, generational GA
Internal state tracking	Improvement histories, operator success rates, lineage graphs	Fitness landscape analysis

The fundamental distinction from all prior systems is that these patterns emerge through LLM-driven meta-evolution rather than being predefined in the system architecture. A UCB1 bandit over operators with Pareto-aware parent selection cannot be expressed as a point in a predefined parameter space—it requires structural innovation.

31.5 LLM Integration and Prompt Architecture

31.5.1 Dual-Role LLM Usage

EvoX uses LLMs in two fundamentally different modes. As a solution generator, the LLM operates as a standard mutation operator: given a parent candidate, a variation operator label, and an optional inspiration set, it produces a modified candidate solution. As a strategy generator, the LLM operates as a meta-programmer: given the history of prior strategies, their performance profiles, and the current population state, it generates a complete Python class implementing the EvolvedProgramDatabase interface.

The paper evaluates both GPT-5 and Gemini-3.0-Pro as backbone models, using the same model for both roles in each experiment. The system also employs a lightweight model for one-time operator instantiation at problem initialization.

31.5.2 Strategy Evolution Prompt

The strategy evolution prompt is the most important component of EvoX’s prompt architecture. As reported in the paper, it consists of a system message defining the optimization context and the EvolvedProgramDatabase interface contract (including self.programs, self.get(), self.DIVERGE_LABEL, self.REFINE_LABEL, and the add()/sample() method requirements). The user message contains four sections: (1) the downstream problem context, (2) the search window definition and current population state via descriptor $\varphi(D_t)$, (3) the strategy history with prior strategies and their performance metrics, and (4) the generation instruction. A constraints block mandates that evaluation metrics are read-only, all imports are preserved, all variables have safe defaults, and type validation is performed before arithmetic on metrics.

The population descriptor $\varphi(D_t)$ serves as a critical compression mechanism. Rather than including all $t$ programs in the prompt (which would exceed context limits), it summarizes the population’s statistical properties. While the paper does not fully specify $\varphi$, the prompt structure indicates it includes: population size, score distribution (best, median, worst, standard deviation), iteration range, operator distribution (counts of free-form, refine, and diverge children), and recent improvement trajectory. This reduces context length from $O(t \times \text{code\_size})$ to a fixed-size summary.

31.6 Key Results

EvoX is evaluated across approximately 200 optimization tasks organized into mathematical optimization (8 tasks), systems performance optimization (6 tasks from ADRS-Bench), algorithmic problems (172 from FrontierCS + 10 from ALE-Bench-Lite), and ARC-AGI-2 abstract reasoning. All open AI frameworks are evaluated under a fixed budget of 100 solution-evaluation iterations per task. Results are reported as best-of-3-runs with GPT-5 as the backbone unless otherwise noted.

31.6.1 Mathematical Optimization

Task	Dir.	Human	AlphaEvolve†	OpenEvolve	GEPA	ShinkaEvolve	EvoX
Circle Packing	↑	2.634	2.635	2.541	2.629	2.508	2.636
Circle Packing Rect	↑	2.364	2.366	2.276	2.354	2.358	2.360
Heilbronn Convex	↑	0.0306	0.0309	0.0267	0.0269	0.0256	0.0272
Heilbronn Triangle	↑	0.0360	0.0365	0.0283	0.0332	0.0338	0.0339
MinMaxMinDist (16,2)	↓	12.89	12.89	13.00	12.95	12.98	12.89
MinMaxMinDist (14,3)	↓	4.17	4.17	4.46	4.17	4.17	4.18
Autocorrelation	↓	1.4581	1.4557	1.4610	1.4758	1.4614	1.4609
Signal Processing	↑	—	—	0.6219	0.7057	0.5328	0.6898

Source: arXiv:2602.23413v2, mathematics results (GPT-5 backbone, best-of-3-runs). Bold indicates the best value among all shown methods for each row. † AlphaEvolve results are taken from its original publication, not reproduced within the SkyDiscover framework under the same 100-iteration budget or infrastructure; AlphaEvolve likely used substantially more iterations on internal Google compute. Direct comparison is therefore approximate.

Interpretation. Among the three reproduced open baselines (OpenEvolve, GEPA, ShinkaEvolve) evaluated under the matched 100-iteration budget, EvoX achieves the best score on 6 of 8 mathematical tasks. The two exceptions are MinMaxMinDist (14,3), where GEPA and ShinkaEvolve tie at 4.17 while EvoX achieves 4.18 (higher is worse), and Signal Processing, where GEPA leads with 0.7057 versus EvoX’s 0.6898. When including AlphaEvolve’s original-paper results (which are not budget-matched), AlphaEvolve leads on Circle Packing Rect, both Heilbronn variants, and Autocorrelation.

31.6.2 Systems Performance Optimization

Task	Dir.	Human	OpenEvolve	GEPA	ShinkaEvolve	EvoX
EPLB	↑	0.1265	0.1272	0.1445	0.1272	0.1453
PRISM (GPU Placement)	↑	21.89	26.23	26.23	26.26	30.52
LLM-SQL	↑	0.692	0.716	0.713	0.713	0.730
Cloudcast	↓	626.24	729.80	645.72	812.74	637.14
Transaction Scheduling	↑	2724.8	4237.3	3984.1	4329.0	4347.83
Telemetry	↑	0.8222	0.9515	0.9477	0.9515	0.9520

Source: arXiv:2602.23413v2, systems results (GPT-5 backbone, best-of-3-runs). Bold indicates the best value for each row. AlphaEvolve is not shown because the original publication does not report ADRS-Bench results.

EvoX achieves the best score among all AI methods on all 6 systems tasks. The most dramatic result is GPU placement (PRISM), where EvoX achieves 30.52 throughput vs. 21.89 human best—a 39.4% improvement. The paper attributes this to the meta-evolution loop discovering that initial greedy placement strategies plateau, then generating a strategy that reformulates the problem as bin-packing assignment. On Cloudcast, the human-designed baseline (626.24) still outperforms EvoX’s GPT-5 result (637.14), though the Gemini-3.0-Pro backbone achieves 623.69 (see Section 31.6.4).

31.6.3 Competitive Programming and Abstract Reasoning

On FrontierCS (172 problems spanning optimization, constructive, and interactive tasks), EvoX achieves a median score of 75.5 compared to 56.2 for the best baseline—a 34.3% improvement. This result is reported by the paper as median across all 172 tasks, best-of-3 runs per task, with OpenEvolve, GEPA, and ShinkaEvolve as baselines under the same 100-iteration budget. This consistent advantage across diverse problems suggests meta-evolution provides a robust, domain-agnostic improvement mechanism.

On ARC-AGI-2 abstract reasoning tasks under a matched 30-iteration budget:

Backbone Model	OpenEvolve	EvoX	Delta
GPT-5	41%	48%	+7pp
Gemini-3.0-Pro	45%	51%	+6pp

The ARC-AGI results are notable because these tasks assume strict train-test separation rather than iterative adaptation. The authors note that the improvement may partially reflect better prompt construction through strategy evolution rather than better optimization per se.

31.6.4 Backbone Model Comparison

EvoX maintains its advantages when switching to Gemini-3.0-Pro. The signal processing task with Gemini-3.0-Pro shows EvoX’s largest relative gain: 0.7429 vs. 0.5049 for ShinkaEvolve (47.1% improvement). The paper attributes this to the multi-objective nature of the task, where the meta-evolution loop discovers strategies that explicitly sample candidates along different Pareto trade-off objectives. The Cloudcast task also benefits from the Gemini backbone, with EvoX achieving 623.69 (improving on the GPT-5 result of 637.14 and beating the human baseline of 626.24).

31.6.5 Win Rate Summary and Evidence Quality

The paper reports a pairwise win rate of 96% for EvoX across the 14 math and systems tasks when compared against each open AI baseline individually. The precise computation method for this statistic is not fully specified in the paper; based on the reported tables, it appears to be computed as the fraction of (task, baseline) pairs where EvoX achieves a strictly better score, across all tasks and all open baselines evaluated under the 100-iteration budget.

At the task level, EvoX’s performance among the three reproduced open baselines (OpenEvolve, GEPA, ShinkaEvolve) on the 14 math and systems tasks breaks down as follows:

Domain	Tasks	EvoX Best	EvoX Not Best
Mathematical optimization	8	6	2 (Signal Processing: GEPA leads; MinMaxMinDist 14,3: GEPA/ShinkaEvolve tie)
Systems optimization	6	6	0
Total	14	12	2

Important caveats for cross-system comparison:

• All open AI frameworks (OpenEvolve, GEPA, ShinkaEvolve, EvoX) are evaluated under a matched 100-iteration budget using the SkyDiscover evaluation harness, making these comparisons methodologically clean.
• AlphaEvolve results are taken from its original publication (which likely used substantially more iterations on internal Google infrastructure with Gemini models) and are not reproduced under the same conditions. Direct comparison with AlphaEvolve is therefore approximate.
• Results are best-of-3-runs; the paper does not report mean scores or variance across runs for most tasks, limiting assessment of statistical significance for narrow margins (e.g., EvoX 1.4609 vs. OpenEvolve 1.4610 on Autocorrelation).
• The 100-iteration budget may disadvantage methods designed for longer runs.

31.7 Comparative Analysis

The following table, synthesized from the paper’s comparative analysis, positions EvoX within the landscape of LLM-driven evolutionary systems:

System	Year	Strategy Type	Adaptation Mechanism	Strategy Expressiveness
FunSearch	2023	Fixed (best-shot sampling)	None	N/A (static)
AlphaEvolve	2025	MAP-Elites with fixed ratios	None (hand-tuned)	Low
OpenEvolve	2025	Static elite + diversity	None (hand-tuned)	Low
ShinkaEvolve	2025	Islands + bandit LLM selection	Parametric (model selection)	Medium
GEPA	2026	Pareto-frontier + reflection	Parametric (reflection-guided)	Medium
AdaEvolve	2026	Three-level hierarchical	Parametric (bandit + meta-LLM)	Medium
ThetaEvolve	2026	Fixed strategy + RL generator	Model adaptation (RL fine-tuning)	Low
EvoX	2026	LLM-generated Python classes	Structural (full strategy evolution)	High (arbitrary code)

The fundamental distinction is that prior systems adapt parameters of a fixed strategy architecture (e.g., bandit weights, exploration-exploitation ratios, model selection probabilities), while EvoX adapts the architecture itself by generating complete strategy implementations as code. This enables qualitative shifts—from tournament selection to Pareto-frontier sampling, or from single-parent refinement to multi-parent crossover—that parametric methods cannot express. Whether this theoretical expressiveness advantage is the primary driver of EvoX’s empirical gains remains an open question, since the paper does not include ablations isolating the contribution of structural versus parametric adaptation.

31.7.1 Relationship to AdaEvolve

Both EvoX and AdaEvolve (Chapter 28) come from the same Berkeley lab and share the SkyDiscover framework. Their stagnation detection mechanisms differ substantially:

Aspect	EvoX	AdaEvolve
Signal type	Raw improvement $\Delta$	Scale-invariant accumulated improvement (EMA)
Threshold	Fixed $\tau$	Adaptive (percentile-based)
Response	Generate new strategy (structural)	Adjust bandit weights (parametric)
Expressiveness	Full strategy replacement	Three-level parameter adjustment

31.8 Implementation Details and Cost Analysis

31.8.1 Software and Infrastructure

EvoX is implemented as a first-class algorithm backend within the SkyDiscover framework. The codebase is available at github.com/skydiscover-ai/skydiscover and includes the full benchmark suite (~200 tasks), automated evaluators, and baseline implementations for OpenEvolve, GEPA, and ShinkaEvolve. The paper is published under CC BY 4.0. Readers seeking to verify the interface definitions, validation logic, and strategy-generation prompts described in this chapter should consult the repository directly; this chapter describes the paper’s design rather than auditing the repository at a specific commit.

The primary language is Python. LLM inference is API-based (OpenAI for GPT-5, Google AI for Gemini-3.0-Pro), so no local GPU is required for the evolutionary search itself. Some benchmark evaluators in ADRS-Bench may require specific hardware configurations for evaluation.

31.8.2 Cost Estimates

Under the fixed 100-iteration budget, a typical EvoX run makes approximately 105–115 LLM calls per task: 100 solution-generation calls plus 5–15 strategy-generation calls (with additional retry calls for failed validations not separately quantified). Assuming typical prompt/response lengths for code-generation tasks and April 2026 API list pricing:

Model	Est. Cost per Task	Est. Total (200 tasks, 3 runs)	Assumptions
GPT-5	~$5–15	~$3,000–9,000	~$10/1M input tokens, ~$30/1M output tokens
Gemini-3.0-Pro	~$2.50–7.50	~$1,500–4,500	~$5/1M input tokens, ~$15/1M output tokens

These ranges reflect uncertainty in prompt/response lengths, which vary by task complexity. Actual costs depend on API pricing at time of execution and the exact token counts per call, which the paper does not report.

31.8.3 Memory and Scalability

The solution population $D_t$ is append-only and grows linearly with evaluation budget. For 100-iteration runs, the paper estimates total memory at ~1–15 MB (100 programs + 5–15 strategy history entries + active strategy state). The population descriptor $\varphi(\cdot)$ provides critical context compression for strategy generation prompts, reducing information from $O(T \times \text{code\_size})$ to a fixed statistical summary.

The paper does not discuss checkpointing or state persistence, consistent with the moderate wall-clock time of individual runs under the 100-iteration budget.

31.8.4 Reproducibility Assessment

Aspect	Status	Notes
Paper	Open access (CC BY 4.0)	arXiv:2602.23413v2
Code	Open source	github.com/skydiscover-ai/skydiscover
Benchmark suite	Included (~200 tasks)	Shipped with framework
Baseline implementations	Included	OpenEvolve, GEPA, ShinkaEvolve backends
Evaluation harness	Included	Automated evaluators for all benchmarks
LLM access required	Commercial APIs	GPT-5 (OpenAI), Gemini-3.0-Pro (Google)

Reproducibility concerns: Both GPT-5 and Gemini-3.0-Pro produce stochastic outputs; exact reproduction requires matching API versions and sampling parameters. The paper reports best-of-3-runs to mitigate this but does not report mean or variance, limiting assessment of result stability for narrow margins. AlphaEvolve results are taken from its original publication, not reproduced under the same infrastructure—AlphaEvolve likely ran for significantly more iterations on internal Google compute. The fixed 100-iteration budget is fair for cross-method comparison among open frameworks but may disadvantage methods designed for longer runs.

31.9 Learning and Adaptation

31.9.1 Three-Level Within-Run Learning

EvoX implements learning at three timescales within a single run:

Timescale	What is Learned	Mechanism
Per-iteration	Solution population expands	Append to $D_t$
Per-window	Operator effectiveness (within strategy)	Strategy-internal tracking (e.g., UCB1)
Per-stagnation	Strategy architecture	Meta-evolution conditioned on $H$

31.9.2 No Explicit Cross-Run or Cross-Task Transfer

EvoX does not implement cross-run or cross-task learning. Each optimization run starts with an empty population, a simple initial strategy (random sampling), and an empty strategy history. The authors emphasize this as a strength: EvoX achieves strong performance without warm-starting, pre-trained strategy models, or cross-task transfer. The LLM backbone provides implicit cross-task knowledge through its training on evolutionary algorithm literature, common optimization heuristics, and code generation capabilities.

The paper notes a natural extension: seeding $H$ with strategies that worked well on similar problems would create meta-meta-learning—learning about strategy evolution across tasks. This is not implemented in the current system.

31.10 Limitations and Discussion

31.10.1 Methodological Limitations

Fixed stagnation threshold. The threshold $\tau$ is fixed rather than adaptive. Unlike AdaEvolve’s scale-invariant accumulated improvement signal, EvoX’s raw improvement comparison means the threshold must be calibrated per-task or set to a small universal value. The paper does not report the value of $\tau$ used in experiments, sensitivity analysis for $\tau$, or the value of window size $W$. This absence leaves open the question of how robust the system is to threshold and window-size misspecification. A $\tau$ that is too small would trigger excessive strategy churn; one that is too large would delay beneficial strategy replacements.

No formal convergence guarantees. The paper acknowledges that arbitrary Python code generation by an LLM is not amenable to standard convergence analysis. The only formal guarantee is monotonicity of the best score (since the population is append-only). The quality of generated strategies depends entirely on the LLM’s capabilities, which are difficult to characterize theoretically.

Strategy validation limitations. The four-stage validation pipeline catches syntactic errors and interface violations, but cannot detect semantic bugs (e.g., a strategy that technically conforms to the interface but implements degenerate selection logic such as always choosing the same parent). The retry-on-failure mechanism introduces additional uncharacterized LLM cost. As discussed in Section 31.3.5, the validation pipeline also lacks security sandboxing.

Missing ablations. The paper does not report systematic ablations isolating the contribution of individual meta-evolution components. Specifically, the following design choices remain unablated:

• Strategy history conditioning: Does conditioning on $H$ improve strategy quality, or would unconditional generation perform equally well?
• Population descriptor design: How sensitive are results to the specific fields included in $\varphi(D_t)$?
• Stagnation trigger vs. periodic replacement: Would replacing strategies on a fixed schedule (e.g., every $W$ iterations regardless of progress) perform comparably?
• Validation retry policy: How often does the first candidate fail, and what fraction of meta-evolution budget is consumed by retries?

Without these ablations, it is difficult to attribute the empirical gains to any specific component of the meta-evolution design. The strong performance could be driven primarily by the structural expressiveness of code-level strategies, primarily by the history-conditioned generation, or by some combination.

31.10.2 Evaluation Limitations

Cross-system comparison fairness. The 100-iteration budget is applied uniformly across open AI frameworks, which is methodologically clean for that comparison. However, AlphaEvolve results are taken from its original publication without budget parity, making direct comparison approximate. The paper is transparent about this limitation.

LLM version dependence. Results are reported with GPT-5 and Gemini-3.0-Pro, which are specific model versions that may not remain available. The system’s performance is fundamentally coupled to the LLM’s ability to generate valid, effective Python classes—a capability that varies across model families and versions.

Statistical reporting. Results are reported as best-of-3-runs rather than mean with confidence intervals. For tasks where the margin between EvoX and the next baseline is narrow (e.g., Autocorrelation: EvoX 1.4609 vs. OpenEvolve 1.4610, a difference of 0.0001), best-of-3 reporting may not establish a reliable performance difference.

31.10.3 Scope Constraints

EvoX requires all solutions to be expressible as executable code with automated scoring. It does not support continuous optimization directly (no gradient computation), real-time adaptation, multi-agent coordination, or hardware-in-the-loop experiments. These are fundamental scope choices, not bugs, but they limit applicability to domains where code-based representation and automated evaluation are feasible.

31.10.4 Broader Implications

The principle of meta-evolution—subjecting the search process itself to evolutionary pressure—has implications beyond LLM-driven optimization. The approach is applicable to any iterative search process where: (1) the search strategy can be expressed as executable code, (2) an LLM can generate valid strategy implementations, (3) strategy effectiveness can be measured by downstream progress, and (4) the optimal strategy is non-stationary. The paper suggests potential applications in AutoML, reinforcement learning exploration, compiler optimization pass ordering, and database query planning.

A more provocative implication is the separation of meta-cognitive capability from domain capability. EvoX demonstrates that an LLM need not be an expert in the target domain to produce effective search strategies for it—the meta-evolution process discovers domain-appropriate strategies through trial and error, using the LLM primarily as a code generator rather than a domain oracle. However, this interpretation should be tempered: the LLM’s pre-training on evolutionary algorithm literature and optimization heuristics likely provides substantial implicit domain knowledge that bootstraps strategy generation.

31.11 Architecture Comparison: Fixed, Parametric, and Structural Adaptation

31.12 Summary