AlphaEvolve vs Darwin Gödel Machine vs OpenEvolve

Choose the target before the tool

Use the AlphaEvolve research as a reference for program search guided by automated scores. Study Darwin Gödel Machine when the object of search is the coding agent itself. Consider OpenEvolve when you want an open implementation of an AlphaEvolve-inspired workflow that you can inspect and adapt.

This is a methods comparison based on the linked primary sources, checked in September 2026. It is not a head-to-head benchmark, a current pricing comparison, or a claim of feature parity. We have not run these three systems on a shared task in this guide.

AlphaEvolve: when the program has a measurable score

DeepMind's AlphaEvolve description pairs language-model proposals with automated evaluation and an evolutionary archive. This fits tasks where correctness and quality can be checked programmatically. The evaluator is a major part of the system, not a final proofreading step.

For your own project, ask whether the task has a reliable objective. A matrix routine can be checked against reference outputs and timed. A broad request such as “make my research more creative” needs a much more careful evaluation design before search scores become useful.

• AlphaEvolve system description

Darwin Gödel Machine: when the agent is the candidate

Darwin Gödel Machine explores changes to a coding agent and keeps an archive of agents from which future variants can be created. The research uses empirical evaluation, rather than requiring a mathematical proof that each self-modification will help.

That distinction changes the unit you must preserve. A candidate is not just an answer file. It includes the agent's code and tool behavior. If your question is whether an improved file editor helps later code changes, save each editor version and the tasks on which it was tested.

The published work also reports reward-hacking failures. Treat that as a design requirement for your replication: a candidate must not control its own evidence of success.

• Darwin Gödel Machine methods and failure cases

OpenEvolve: an inspectable starting implementation

OpenEvolve is an open-source project inspired by AlphaEvolve. Its repository is a starting point for inspecting how candidate programs, evaluation, and search configuration fit together. Open-source availability does not make a run free: inference and candidate execution can still incur costs.

Pin a repository commit before beginning an experiment. Read the evaluator interface and start with a toy objective whose correct answer you already know. Check that malformed candidates, timeouts, missing scores, and failed runs are handled as failures.

Do not assume published AlphaEvolve results transfer to OpenEvolve. Models, prompts, data, evaluator code, compute budgets, and search rules can all differ. A reproduction claim needs an explicit account of those differences.

• OpenEvolve source and setup documentation

A fair comparison uses the same budget

Our suggested comparison begins with a fixed task set and a trivial baseline. Use the same model where possible, the same input data, and the same total execution and inference budget. If one method needs different models or tools, record that as a confound instead of burying it in a headline.

Measure valid candidates, wall time, cost, and held-out task quality. Include crashes and unsuccessful proposals in the budget. A system that finds one great answer after discarding thousands of paid failures should not be compared with another system's single attempt.

Reserve a final dataset that never enters prompts or selection. Repeatedly selecting methods based on the final score consumes that holdout. Where tasks are noisy, repeat runs and show the spread instead of ranking methods on a tiny numerical difference.

method,code_commit,model_id,evaluator_commit,task_split
seed,proposal_count,valid_candidates,wall_seconds
inference_cost,execution_cost,held_out_score,failures

When a simpler search is the right answer

If the only changing values are learning rate, batch size, or a few numeric parameters, a parameter search may be easier to interpret than generated code. A manual baseline or random search is worth keeping even when you use an agent.

Generated code search earns its complexity when structural changes are part of the hypothesis. Agent evolution earns another layer when you want to improve the system that proposes those changes. Keep that escalation explicit so a small experiment does not turn into an unbounded infrastructure project.

Whichever method you choose, preserve the same evidence bundle: candidate, parent, evaluator, environment, score, and cost. Those records make a failed run useful and a successful one reproducible.

Keep the search separate from its infrastructure

Meshia is a workspace and compute layer, not a claim to reproduce any of these research results. Use a persistent workspace to keep code, candidate records, and outputs together.