Method Shortcut: Component-by-Component Comparison

This chapter is the index to every design decision an LLM-powered evolutionary system has to make. Where Chapter 67 — Comprehensive Methods Catalog gives the long-form algorithmic reference for each method, and Chapter 65 — Comparative Architecture Analysis compares systems layer-by-layer, this chapter inverts the view: for each design dimension, it enumerates the variants observed in the surveyed systems, shows which systems use which, and tells you — under which conditions — each variant tends to pay off.

71.0.1   Methodological Note: What This Taxonomy Is and Is Not

Before the tables, three caveats the reader should keep in mind throughout.

The fifteen dimensions are not strictly orthogonal. Several concepts naturally span more than one table. The most conspicuous overlaps:

• MAP-Elites is simultaneously a search strategy (§71.1), an archive structure (§71.2), a parent-sampling rule (§71.3), and a diversity mechanism (§71.5). We place each facet in the table it most directly constrains: the high-level decision to run a QD loop belongs to §71.1; the cellular archive data structure to §71.2; the "random cell, then champion" draw to §71.3; the behavioural-descriptor rationale to §71.5.
• Bandits appear in parent selection (§71.3), model routing (§71.8), operator selection (§71.11), and budget allocation (§71.12). Each table lists only bandit uses specific to that decision; the same bandit algorithm (UCB1, Thompson) can reappear across tables.
• Reflection crosses mutation (§71.4, "reflect-then-mutate"), memory (§71.10), meta-adaptation (§71.11, prompt evolution), and failure handling (§71.14, reflective repair). We list it in every table where it is the defining design choice for that row.
• Skills archives appear in population structure (§71.2), prompt co-evolution (§71.9), and memory (§71.10); the same data structure, viewed through three different lenses.

Placement rule. Where a concept could belong to more than one table, we place it in the table whose question it most directly answers — "What shape is the search?" for §71.1, "How are candidates stored?" for §71.2, "How is the next parent drawn?" for §71.3, and so on. Cross-references in the commentary flag the siblings.

Evidence asymmetry. Not every "When to pick" recommendation rests on controlled ablations. Some dimensions (cascade evaluation, sandboxing, line-level diff mutation) are backed by multiple within-system ablations; others (e.g., crossover value, optimal bandit family, memory retrieval strategies) are under-evidenced and reflect practitioner rule-of-thumb. §71.16 summarises which claims are well-supported and which are working hypotheses.

71.0.2   Source-Type Tags for "Used by"

Every "Used by" attribution carries a one-letter tag distinguishing how the evidence was obtained. This lets readers audit claims at a glance and weight them accordingly.

Chapter pointers of the form (Ch##) route to the survey chapter that documents the system. Where a system is flagged [I] or [B], readers should not treat the row as reproducible evidence, only as a design-space observation.

71.0   Method ID Index

The short codes in the Ch67 column throughout this chapter (e.g. M1, S4, P2, B1) are references into Chapter 67 — Comprehensive Methods Catalog, which contains the formal specification, pseudocode, and trade-offs for every method. Each ID in the table below is a clickable anchor that jumps to the matching subsection in Ch67. Ch67's section numbering follows the pattern #s67-<family>-<index> where <family> is the family's ordinal inside Ch67 (3 for Mutation, 4 for Crossover, 5 for Selection, 6 for Evaluation, 7 for Population, 8 for Islands, 9 for Bandits). Use this as the single index for the thirty-four methods across the seven families.

Shorthand for the rest of this chapter. In the per-dimension tables below, the Ch67 column lists the IDs that apply to each variant. When you see an unfamiliar code — say B3 in §71.3 — scroll back to this index and click it to jump to the formal definition in Ch67. A dash (—) in the Ch67 column means the variant is described only in Ch67's surrounding prose or does not yet have a catalogued method ID.

71.1   Search Strategy

The top-level shape of the search. Most downstream choices are constrained by this decision, though several dimensions (mutation, evaluation, sandboxing) remain largely independent.

71.2   Population Structure

How candidates are stored and organised. Distinct from the search strategy: a FunSearch-lineage EA can in principle be paired with any of these archives, although in practice certain pairs dominate (see §71.16).

71.3   Parent Selection & Sampling

How the next parent is drawn from whatever archive you chose in §71.2.

71.4   Change Operators (Mutation)

How the LLM turns a parent into a child. Empirically the single largest source of inter-system variation.

71.5   Diversity & Novelty Machinery

How the system avoids collapsing onto a single idiom.

71.6   Evaluation & Fitness Assessment

How a candidate is scored. The cost and fidelity of this step tends to dominate the overall budget.

71.7   LLM Orchestration

How many LLMs are involved and how they are wired together.

71.8   Model Selection & Routing

Given a model pool, which model is called for a given operation?

71.9   Prompt Engineering & Co-Evolution

Who writes the prompts, and do they evolve?

71.10   Memory, Learning Logs & Skills

What the system remembers between iterations — and how memory is read back into the mutator.

71.11   Meta-Level Adaptation & Self-Improvement

Which parts of the system can evolve themselves?

71.12   Cost & Budget Management

How the system decides when to stop spending and where to spend next.

71.13   Sandboxing & Safety

A safety requirement rather than a tuning choice: any system executing LLM-generated code needs isolation. The question is how much.

71.14   Failure Handling & Repair

What happens when a candidate crashes, loops, or fails its evaluator?

71.15   Evaluator Types

The full space of fitness functions. The choice is dictated by the problem rather than by the search strategy.

71.16   Cross-Cutting Meta-Analysis

The fifteen tables above enumerate what can be done. This section asks the synthesis questions the reviewer is entitled to: which variants are actually common, which combinations recur together, which dimensions are strongly coupled, and where do the surveyed systems genuinely disagree? The quantitative claims below are coarse counts over the sixty-one surveyed systems; treat them as directional rather than inferential.

71.16.1   Variant Frequency (Directional)

Frequencies are bucketed because not every system exposes every dimension and not every codebase was audited at the same depth. Dominant = seen in a clear majority of the surveyed systems exposing this dimension; common = seen in roughly a third to half; niche = seen in under ten systems; rare = seen in one to three and usually experimental.

71.16.2   Recurring Combinations (Co-Occurrence)

Five combinations recur so often that they effectively define recognisable styles of LLM-powered evolution:

1. FunSearch-lineage stack. Single-pop or island EA (§71.1) + flat elitism (§71.2) + tournament or power-law rank (§71.3) + line-level diff + full rewrite + error-repair (§71.4) + cascade evaluator (§71.6) + container sandbox (§71.13) + learning log (§71.10). Examples: OpenEvolve, AlphaEvolve, ShinkaEvolve, LLM4AD.
2. Quality-diversity stack. MAP-Elites search (§71.1) + grid archive (§71.2) + cell sampling (§71.3) + behavioural-descriptor novelty (§71.5) + cascade evaluator (§71.6). Examples: AlphaEvolve QD mode, GEPA variants.
3. Reflection-heavy agent stack. Reflect-then-mutate (§71.4) + proposer+critic orchestration (§71.7) + prompt populations or skill prompts (§71.9) + embedded log or skills archive (§71.10) + reflective repair (§71.14) + LLM-as-judge or hybrid evaluator (§71.15). Examples: GEPA, GEPA Skills, RetroAgent, EvoSkill.
4. Tree-search stack. MCTS/AB-MCTS (§71.1) + UCB1 or Thompson selection (§71.3) + per-node fitness (§71.6). Examples: AB-MCTS, TreeQuest, Arcgentica, ALE-Agent.
5. Self-modification stack. Harness evolution + self-modifying code (§71.11) + instruction co-evolution (§71.9) + lessons library (§71.10) + reflective repair (§71.14). Examples: Darwin Gödel Machine, Darwinian Evolver, NeoSigma.

ASCII co-occurrence sketch (row = representative system, column = style; ● = strong alignment, ○ = partial):

                         FunSearch  QD   Reflect  Tree  Self-mod
OpenEvolve                  ●        ○    ·        ·     ·
AlphaEvolve                 ●        ●    ·        ·     ·
ShinkaEvolve                ●        ○    ○        ·     ·
LLM4AD                      ●        ·    ·        ·     ·
GEPA                        ○        ○    ●        ·     ·
GEPA Skills                 ·        ·    ●        ·     ·
RetroAgent                  ·        ·    ●        ·     ○
AB-MCTS / TreeQuest         ·        ·    ·        ●     ·
Arcgentica                  ·        ·    ·        ●     ·
ALE-Agent                   ·        ·    ·        ●     ·
Darwin Gödel Machine        ·        ·    ○        ·     ●
NeoSigma                    ·        ·    ○        ·     ●
EvoSkill                    ·        ·    ●        ·     ○

71.16.3   Strongly Coupled Dimensions

Some dimensional choices are nearly forced by prior ones. The couplings below are observed as structural regularities, not proven causal dependencies:

• Cascade evaluator ↔ tiered population ↔ cost-tier routing. Choosing a cascade in §71.6 implies candidates live at different refinement stages (§71.2) and that cheap vs. strong models run at different stages (§71.8). AlphaEvolve and ShinkaEvolve show all three.
• MAP-Elites grid ↔ cell sampling ↔ behavioural descriptor. Choosing a QD archive (§71.2) effectively fixes the selection rule (§71.3) and the diversity mechanism (§71.5).
• Skills archive ↔ prompt-populations ↔ skill-prompt retrieval. When §71.2 is a skills archive, §71.9 almost always includes some form of prompt-level retrieval, and §71.10 an embedded log.
• Island model ↔ adaptive spawning ↔ heterogeneous islands. Within the island family, systems that ablate migration topology tend to also vary island configurations and operator mixes.
• Reflect-then-mutate ↔ learning log ↔ reflective repair. Reflection machinery is rarely worthwhile unless the log retains lessons and failures feed back into prompts.
• Self-modifying code ↔ instruction co-evolution ↔ lessons library. Gödelian self-modification almost always appears together with prompt/skill co-evolution and an explicit lessons archive.

Conversely, several dimensions are decoupled in practice: sandboxing choices (§71.13) are largely orthogonal to everything else, and mutation operator choice (§71.4) is surprisingly independent of search strategy (§71.1) — line-level diff appears in single-pop EAs, island EAs, and QD systems alike.

71.16.4   Where the Surveyed Systems Genuinely Disagree

On several questions the field does not (yet) speak with one voice. These are the most instructive points for a practitioner deciding what to build:

• Does crossover help? ShinkaEvolve and LLM4AD use two-parent crossover; FunSearch and OpenEvolve's default mode omit it. No cross-system controlled study settles whether the LLM genuinely mixes parents or is merely inspired by seeing two candidates at once.
• Reflection vs. cheap rerolls. GEPA, EurekaClaw, and RetroAgent spend tokens on reflection before each mutation; AlphaEvolve and OpenEvolve largely prefer to generate more cheap diffs and let selection sort them out. Both stacks produce state-of-the-art results on different task families.
• Static vs. evolving prompts. FunSearch and OpenEvolve freeze the prompt; GEPA, Darwin Gödel Machine, and AutoAgent evolve it. The freeze camp cites reproducibility; the evolving camp cites long-run adaptation.
• Self-modifying code. Darwin Gödel Machine and NeoSigma allow the system to rewrite itself; the rest of the field keeps the harness frozen. The disagreement is as much about safety posture as about efficiency.
• Memory format. Text logs (AlphaEvolve, ShinkaEvolve) vs. embedded logs (Omni-SimpleMem, RetroAgent) vs. knowledge graphs (OmniScientist, Zochi). No published ablation cleanly compares them at matched budget.
• Diversity via archive shape vs. fitness penalty. MAP-Elites enforces diversity structurally; EurekaClaw and GEPA enforce it via an explicit fitness term. The trade-off between the two has not been systematically benchmarked.

71.16.5   Which Claims in This Chapter Are Well-Supported?

Not all "When to pick" recommendations rest on the same evidence base. A rough tier list:

• Well-supported (multiple within-system ablations across different teams): cascade evaluation beats single-stage whenever stage cost varies >10×; sandboxing is mandatory for code execution; error-repair as a fallback operator is near-universal because its absence produces visible failure modes.
• Moderately supported (one or two published ablations, or consistent anecdotal reports): tournament > fitness-proportionate as a default; cost-tier routing saves budget on multi-provider pools; line-level diff dominates on mature candidates while full rewrite dominates on early exploration.
• Weakly supported (practitioner consensus, little controlled evidence): crossover helps in large diverse archives; reflective repair is worth its cost on expensive evaluators; knowledge graphs pay off in research agents; power-law rank > uniform on long archives.
• Under-evidenced (claims that appear in the literature but have not been cleanly ablated): MAP-Elites vs. island EAs on code-synthesis tasks; optimal bandit family (UCB1 vs. Thompson vs. EXP3) for operator selection; whether embedded-log retrieval measurably outperforms text-log retrieval at matched budget; whether self-modifying systems converge faster than frozen-harness systems on any benchmark.

Readers designing a new system should weight the recommendations accordingly. The cross-cutting dimensions most likely to move the needle on realistic research budgets are, on current evidence, evaluator cascade design, mutation operator pool (including error-repair), and cost-tier model routing. Everything else is a secondary tuning knob whose impact depends strongly on problem structure.