OpenEvolve
The most advanced open-source evolutionary coding agent turns your LLMs into autonomous code optimizers that discover breakthrough algorithms.
- Source repo
- algorithmicsuperintelligence/openevolve
- Stars
- ★ 7.6k
- Last updated
- 5d ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 40/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformClaude Code · OpenAI API
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- GPU kernel developers seeking automated optimization for specific hardware, e.g., achieving 2.8x speedup on Apple Silicon.
- Not a fit if
- Users who want a ready-made tool without tuning system messages
- Budget-limited teams running many iterations on costly models like o3
- Source review
- 40/100 · Major gaps 8 safety controls not found
What does this agent do, and when should you use it?
OpenEvolve is an open-source library for automatically improving code through evolutionary algorithms. It implements MAP-Elites quality-diversity optimization and island-based evolution, leveraging multiple LLMs to generate new programs. Core components include an evolutionary engine, an evaluator interface, a database for population management, and visualization tools. Users can run evolution via CLI or Python API, with seed settings for reproducibility and extensive configuration options. It supports multiple programming languages (Python, Rust, Metal shaders) and demonstrates results across domains like GPU kernel optimization and algorithmic discovery.
OpenEvolve evolves code iteratively. It starts with an initial program, uses an LLM ensemble to generate mutated versions, evaluates them with user-supplied evaluator functions, and manages the population in a database. It uses MAP-Elites to organize programs by feature dimensions and island migration to maintain diversity. Artifact feedback (e.g., errors, warnings) informs future generations. The entry points include run_evolution and evolve_function Python APIs, and the openevolve-run.py CLI. Configuration is YAML-based, allowing multiple LLM providers (OpenAI-compatible endpoints, Claude Code CLI). The output is improved program code and performance metrics.
- GPU kernel developers seeking automated optimization for specific hardware, e.g., achieving 2.8x speedup on Apple Silicon.
- Researchers discovering new algorithms or mathematical structures, like achieving state-of-the-art circle packing results.
- Scientists automating tedious tuning of complex algorithms like adaptive sort or signal processing filters.
- Competitive programmers exploring multiple solution strategies for multi-objective problems.
- Engineers optimizing prompts for LLMs, using OpenEvolve to evolve prompts for improved accuracy.
- Developers needing to evolve code across multiple languages, including Python, Rust, and Metal shaders.
How do you install or deploy this agent?
Requires Python 3.10+ and an LLM API key (e.g., Google Gemini or OpenAI). Install via pip: pip install openevolve. Set the environment variable OPENAI_API_KEY (for Gemini, use the same variable). Optionally, install Docker for containerized runs (see docker pull ghcr.io/algorithmicsuperintelligence/openevolve:latest) or Claude Code CLI (npm install -g @anthropic-ai/claude-code).
How do you use this agent?
Quick start: Install, set OPENAI_API_KEY, and run an example: python openevolve-run.py examples/function_minimization/initial_program.py examples/function_minimization/evaluator.py --config examples/function_minimization/config.yaml --iterations 50. Or use the Python API: from openevolve import run_evolution; result = run_evolution(initial_program='...', evaluator=lambda path: {'score': ...}, iterations=100). Configure LLM providers by editing config.yaml (e.g., llm.api_base and llm.model).
What are this agent's strengths and limitations?
- Uses MAP-Elites and island models to prevent premature convergence and maintain diversity.
- Supports multiple LLM providers (OpenAI, Gemini, Claude Code, local models) for flexible integration.
- Provides full reproducibility with seed settings (default seed=42), ideal for research.
- Includes a visualizer and checkpoint system for real-time monitoring and analysis.
- Demonstrated success: GPU kernel optimization (2.8x speedup), state-of-the-art circle packing.
- Costs vary by LLM provider; advanced models can be expensive per iteration (e.g., o3 at $0.15-0.60).
- Requires LLM API keys, which adds dependency (though Claude Code CLI offers an alternative with OAuth).
- Crafting effective system messages is crucial and may require iterative tuning, which is not trivial.
- Performance may depend on problem complexity and evaluator quality; configuration needs adjustment.
- Benchmarks and achievements are from examples and may not generalize to all domains.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| OpenEvolve This agent | 40 · Major gaps | CLIFree + model costs | ★ 7.6k | 5d ago | Python | Claude Code · OpenAI API |
| OpenAlpha Evolve | 41 · Major gaps | CLIFree + model costs | ★ 1.1k | 1y ago | Python | OpenAI API · Claude API |
| Hello-Agents | 54 · Major gaps | Web appFree + model costs | ★ 84k | 5d ago | Python | OpenAI API |
| Lagent Lightweight Agent Framework | 43 · Major gaps | Library / SDKFree + model costs | ★ 2.3k | 6mo ago | Python | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: the repository provides no permission model, user confirmation mechanism, data flow transparency, sensitive data handling, dependency security audit, external effects control, rollback mechanism, or source attribution. All trust-related criteria are unmet, hence all scores are 0.
Evidence shows: README and configuration examples are largely consistent in functionality, but there are inconsistencies, such as README claiming 'fully deterministic' while config allows random templates and temperature settings, and no detailed explanation of determinism guarantees. Dependency availability: pyproject.toml lists dependencies but lacks version pinning or integrity checks, and the integration test workflow installs math-verify additionally, indicating incomplete dependency management. Failure messages: test scripts provide basic error output, but no user-facing troubleshooting guide.
Evidence shows: README identifies target audiences (performance optimization, algorithm discovery, etc.) and multiple use cases, with several examples. Capability boundaries: README describes configurable constraints (e.g., 'MUST NOT CHANGE' in system messages), but lacks comprehensive capability boundary documentation. Trigger precision: provides configuration examples and system message guidance, but no detailed trigger conditions. Environment fit: supports multiple LLM providers and local models, but lacks detailed configuration guides for all environments.
Evidence shows: README provides clear information architecture including quick start, examples, configuration. Installation instructions are detailed, covering PyPI, development install, and Docker. Naming stability: project name and main APIs are consistent in docs. Examples and FAQ: multiple examples provided, but no FAQ section. Known limitations: not explicitly listed. License: Apache-2.0, but no copyright holder information. Versioning: pyproject.toml uses dynamic version, but no CHANGELOG. Maintenance responsibility: author info only lists 'codelion', no maintainer contact or contribution guide.
Evidence shows: Output usability: provides library API and CLI, with output examples. Marginal value: claims 2-3x speedups and SOTA results, but no independent verification. Cost-benefit: provides cost estimates, but no actual benchmark data.
Evidence shows: Performance claims in README (e.g., 2-3x speedups, SOTA) lack traceable benchmarks or paper citations. Cross-source corroboration: relies solely on internal repository evidence, no external validation. Fact-inference separation: README mixes inferences (e.g., 'breakthrough optimizations') with facts (e.g., examples) without clear distinction.
- Not found in source: least-privilege scopingGrant only what the task needs: a dedicated account or read-only token, scoped to specific directories and repos.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: data-flow disclosureWatch which external services it contacts (proxy or firewall logs) and keep sensitive data out until you know where it goes.
- Not found in source: sensitive-data handlingUse dedicated, low-privilege, revocable API keys — never production credentials — and keep secrets out of logs.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Not found in source: disclosed external effectsEstablish which external systems it writes to, sends to or changes, and verify with test accounts or repos before production.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- Not found in source: verifiable attributionInstall from the official repo or registry and check the publisher and URL to avoid look-alike packages.
- Performance claims (e.g., 2-3x speedups, SOTA) lack verifiable benchmarks or paper citations; treat with caution.
- Dependency management is incomplete, without version pinning, and integration tests install math-verify additionally, potentially affecting reproducibility.
- No explicit permission model or security audit is provided; assess risks yourself when using as an Agent framework.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Highlights - Pluggable island selection and population strategies (#493): an optional island selector plus decision-returning hooks for admission, MAP-Elites cell replacement, archive membership, eviction and migration. ProgramDatabase validates the decisions and still owns every mutation. Default behaviour is unchanged. - LLM token usage tracking (#490): prompt_tokens, completion_tokens and total_tokens are captured from OpenAI-compatible responses, carried back from workers, stored in program metadata and prompt logs, and reported per iteration and as a run total. …View on GitHub ↗ -
Release notes excerpt
Bug fixes Booleans in metrics are flags, not scores. bool is a subclass of int, so a naive isinstance(value, (int, float)) check silently treated True/False as 1.0/0.0. OpenEvolve's own evaluator emits timeout: True as a metric, so this was not a hypothetical input. - Fitness math (utils/metrics_utils.py) — the significant one. When an evaluation timed out, evaluator.py returns {"error": 0.0, "timeout": True}, which safe_numeric_average scored as 0.5 — handing a program that failed outright a mid-range fitness and letting it compete for survival in the …View on GitHub ↗ -
Release notes excerpt
Bug fixes - llm.provider was silently dropped (#472): LLMConfig propagates shared settings to each per-model LLMModelConfig via a shared_config dict, but that dict omitted provider. Every model kept provider=None, so LLMEnsemble routed them all to the OpenAI backend regardless of the config — a config with provider: claude_code crashed with a missing-OPENAI_API_KEY error, making examples/claude_code_quickstart unusable. An explicit per-model provider still takes precedence. Features …View on GitHub ↗
FAQ
How much does it cost to run OpenEvolve?
Must I use a specific LLM?
What if evolution gets stuck?
num_diverse_programs or migration intervals.How can I measure success?
combined_score or metric average, or track convergence, diversity coverage, and efficiency via the visualizer.