evolve-design

Define a measurable scoring criterion, write a simple working seed candidate, build an evaluator that scores it, then launch a run with create_evolve_run. The search rewrites the candidate dozens of times and keeps versions that score higher on held-out gate shards.

PUCT ranks candidates by a PUCT score over a flat tree, while OpenEvolve uses MAP-Elites islands with ring migration and diversity-based cells. Both share the same four-step design flow and four scoring modes; only candidate ranking and selection differ.

Use dataset_metric when cases have known answers and a metric to optimize, test_gate when correctness is pinned by tests, custom_script for simulations or heuristics with no natural table, and llm_judge only when quality requires a model's reading, such as prose.

The probe scores a deliberately broken candidate alongside the seed; refusal means the evaluator cannot tell them apart. Fix it by adding harder cases, making the rubric more mechanical, or weakening an overly strong starting point, then call create_evolve_run again.

Skip it for a single fix, a refactor, or questions about existing code, where one direct edit suffices. It also fails when no measurable criterion can separate a good candidate from a bad one, since the search has no signal to climb.

Expansions must be at least four times the worker count or the tree stays flat. Use 4-6 for a known defect, 12-20 for swapping approaches or restructuring, and 20 or more when writing something from scratch.