OpenAlpha Evolve
Evolve Python algorithms through LLM-generated code, testing, selection, and iterative refinement.
- Source repo
- shyamsaktawat/OpenAlpha_Evolve
- Stars
- ★ 1.1k
- Last updated
- 1y ago
- License
- MIT
- Primary language
- Python
- FA score
- 41/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformOpenAI API · Claude API
- You'll need
- Typical use
- An algorithms researcher exploring candidate implementations for a problem such as Dijkstra's algorithm under explicit input-output tests.
- Main limitation
- Executing generated code requires local Docker, with Docker Desktop or Docker Engine installed and running.
- Source review
- 41/100 · Major gaps 3 safety controls not found
What does this agent do, and when should you use it?
OpenAlpha Evolve is an open-source framework for automatically discovering and iteratively improving Python algorithms, inspired by DeepMind's AlphaEvolve research. Its architecture includes PromptDesignerAgent, CodeGeneratorAgent, EvaluatorAgent, DatabaseAgent, SelectionControllerAgent, and TaskManagerAgent. Users define a target function, permitted imports, and tests in YAML or with TaskDefinition, then the system evolves candidate programs across generations. Generated code is syntax-checked and executed against task examples in Docker containers for scoring. The repository offers both a command-line run path and a Gradio interface for defining tasks and starting evolution interactively.
A user supplies a YAML task containing task_id, task_description, function_name, allowed_imports, and tests. PromptDesignerAgent creates initial, mutation, and bug-fix prompts; CodeGeneratorAgent calls a model through LiteLLM to produce Python code and attempts to apply received diffs to parent code. EvaluatorAgent checks Python syntax, runs the program in a temporary isolated environment, and calculates fitness from test correctness, runtime, and potential additional metrics. DatabaseAgent records code, fitness, generation, and lineage; SelectionControllerAgent chooses parents and survivors; TaskManagerAgent repeats the evolutionary loop for the configured generations. Outputs include evolved Python candidates, evaluation results, and logs, with alpha_evolve.log as the documented default log file.
- An algorithms researcher exploring candidate implementations for a problem such as Dijkstra's algorithm under explicit input-output tests.
- A Python developer who wants to specify a function, allowed imports, and edge-case tests in YAML, then iterate on generated implementations.
- An experimenter studying how LLM-produced programs change in fitness through mutation, diff-based fixes, and selection.
- A prototype team that needs generated Python code syntax-checked and functionally tested in a Docker-isolated execution environment.
- A developer who wants to define a custom task through a Gradio UI and run the evolutionary process interactively.
How do you install or deploy this agent?
Prerequisites are Python 3.10+, pip, Git, and a running Docker installation. Run:
git clone https://github.com/shyamsaktawat/OpenAlpha_Evolve.git
cd OpenAlpha_Evolve
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
cp .env_example .envConfigure credentials for the selected model provider in .env. Google can use GOOGLE_APPLICATION_CREDENTIALS or GEMINI_API_KEY; the documentation also gives OPENAI_API_KEY, ANTHROPIC_API_KEY, and COHERE_API_KEY as examples. Provider access is handled through LiteLLM.
How do you use this agent?
Run the documented shortest-path example with:
python -m main examples/shortest_path.yamlThe system runs its evolutionary loop and writes logs to the terminal and, by default, alpha_evolve.log. For the web interface, run:
python app.pyOpen the local URL displayed by Gradio, define a task, and start an evolution run.
What are this agent's strengths and limitations?
- Separates prompt design, generation, evaluation, storage, selection, and orchestration into dedicated agents that can be extended or replaced.
- Supports initial generation, diff-based mutation, and diff-based bug fixing, enabling targeted changes to parent programs.
- Evaluates candidates with syntax checks, test execution, and fitness scoring instead of returning code text alone.
- Documents a multi-provider path through LiteLLM, including OpenAI, Anthropic, and Google, rather than a single-model interface.
- Executing generated code requires local Docker, with Docker Desktop or Docker Engine installed and running.
- Code generation requires credentials for a model provider; usage and costs depend on the provider chosen.
- The project is explicitly experimental: generated code may be suboptimal, incorrect, or insecure and requires review and testing before production use.
- DatabaseAgent is currently in-memory; the source does not document persistent storage, recovery, or multi-user deployment.
- The setup text names .env.example while the copy command uses .env_example, so adopters need to verify the repository's actual filename.
How does this agent compare with similar options?
The project explicitly presents itself as an open-source regeneration of core ideas inspired by DeepMind's AlphaEvolve, intended to make those concepts more accessible for experimentation and learning. The source does not document feature parity, performance comparisons, or deployment comparisons with AlphaEvolve.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| OpenAlpha Evolve This agent | 41 · Major gaps | ★ 1.1k | 1y ago | Python | OpenAI API · Claude API |
| OpenEvolve | 40 · Major gaps | ★ 7.4k | 2mo ago | Python | Claude Code · OpenAI API |
| CaveAgent | 62 · Some gaps | ★ 202 | 8d ago | Python | OpenAI API · Claude API |
| KodeAgent | 43 · Major gaps | ★ 40 | 1mo ago | Python | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence: Code execution uses Docker container isolation, network disabled by default, timeout mechanism, reflecting least privilege (1). No user confirmation mechanism found (0). Data flow transparency: README describes data flow but lacks detailed logs or visualization (1). Sensitive data handling: .env stores API keys but no encryption or protection mentioned (1). Dependency security: requirements.txt not pinned, no vulnerability scanning (0). External effects: Docker execution may have external impact but not clearly stated (1). Rollback: No rollback mechanism mentioned (0). Source attribution: README mentions inspiration but no specific citations (1).
Self-consistency: README consistent with code structure, tests match description (2). Dependency availability: Dependencies listed but not pinned, affecting reproducibility (1). Failure messages: Tests cover error scenarios, messages clear (2).
Audience and scenarios: README targets researchers and developers, multiple use cases (2). Capability boundaries: No clear limitations stated (1). Trigger precision: Task definition via YAML or Python, but no precise trigger control (1). Environment fit: Docker and virtualenv setup provided, but OS differences not addressed (2).
Information architecture: README well-structured with TOC and project structure (2). Install notes: Detailed installation steps (2). Naming stability: No naming conventions or API stability mentioned (1). Examples and FAQ: Example task provided, no FAQ (2). Known limitations: Disclaimer present but not detailed (1). License: MIT license clear (2). Versioning and changelog: No version or changelog (0). Maintenance responsibility: No clear maintainer or contribution guidelines (1).
Output usability: Generated code and evaluation results have clear format (2). Marginal value: Provides evolutionary algorithm framework, unique value (2). Cost benefit: No discussion of runtime costs or resource usage (1).
Claim traceability: README claims features but no evidence (1). Cross-source corroboration: No external validation (1). Fact-inference separation: README mixes facts and vision, not clearly separated (1).
- 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: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- Dependencies are not pinned, which may introduce incompatibilities or security vulnerabilities.
- API keys are stored in .env file; ensure proper protection.
- Docker execution environment is isolated, but be aware of container escape risks.
- No versioning or changelog provided, making updates hard to track.