algorithmicsuperintelligence/openevolve

Motivation Google published Google-Cloud-AI/alphaevolve-on-googlecloud — a client SDK + examples for the managed AlphaEvolve service on Gemini Enterprise / Discovery Engine. It implements the same core loop as OpenEvolve (EVOLVE-BLOCK seed + metric-returning evaluator + weighted model ensemble), but generation and the program database run server-side on Google infra, behind gcloud auth + a Gemini Enterprise Engine ID, and it's Gemini-only. OpenEvolve implements the same algorithm fully self-hosted (any OpenAI-compatible model, local vLLM, MAP-Elites diversity knobs). The two are conceptually identical but incompatible at three seams: the evaluator contract, the config schema, and the client/experiment entrypoint. Goal: first-class, bidirectional interoperability, so a user can: (A) Run any AlphaEvolve example on OpenEvolve unchanged — no GCP project, no gcloud auth, no Gemini lock-in. (B) Export an existing OpenEvolve program + config to the AlphaEvolve service and run it there di

I was reading the code, and as far I can tell the novelty checks are done in the wrong place if the evolved code is likely to take a long time to run. Problem Description: In the current implementation, the novelty check (which uses embedding similarity) runs AFTER the potentially expensive evaluation step. This means programs that would be rejected for being too similar to existing programs still get fully evaluated, wasting significant compute resources. The novelty check has TWO components: Embedding similarity check (cheap - generates embedding and compares cosine similarity) LLM novelty judgment (expensive - calls LLM to judge if code is truly novel) Current flow: Generate child program Evaluate program (expensive - runs the actual code) Add to database → Novelty check (embedding + optional LLM call) If too similar → reject Expected flow: Generate child program Novelty check (embedding + optional LLM) If passes → Evaluate program (expensive) Add to database Location of

Currently, checkpoints are saved based on checkpoint_interval (e.g., every 10 iterations), regardless of whether any improvement was made. This can be wasteful when the optimization is making slow progress. Feature Request: Add a configuration option checkpoint_on_improvement: bool that when set to True, only saves a checkpoint when a new best solution is found, rather than at fixed intervals. Possible Implementation: Config: Add checkpoint_on_improvement: bool = False to Config class in openevolve/config.py Logic: Modify checkpoint trigger in openevolve/process_parallel.py (around line 667): If checkpoint_on_improvement is True, checkpoint only when database.best_program_id == child_program.id (improvement detected) If False, use existing interval-based logic Example use case: Only save checkpoint when a new best is found checkpoint_on_improvement: true checkpoint_interval is ignored when above is true This is especially useful when: Users only care about capturing improvements

https://github.com/facebookresearch/airs-bench

https://github.com/FrontierCS/Frontier-CS