The concurrency parameter controls how many programs are generated and evaluated
simultaneously. This parameter is the most impactful runtime hyperparameter.
How concurrency affects search
n = 1(Sequential chain): Generate one program, wait for evaluation, and then generate the next. Each generation sees the previous result, creating a chain of incremental improvements that zooms in on a local optimum. This approach results in the slowest throughput but the most focused exploitation. Use this mode to intentionally converge on a specific region.n = 3-12(Sweet spot): This is the most widely used range in practice, balancing exploration and exploitation. Multiple programs are in flight simultaneously, so some generations don't see the latest results, introducing natural diversity. The evolutionary database maintains enough throughput for healthy population dynamics.n = 13-30(High exploration): Many programs run in parallel. Most generations don't see each other's results. This mode is useful for highly non-convex problems with many local optima where broad exploration matters more than deep exploitation.n = 23-30(Throttled; avoid): Exceeding 30 parallel generators throttles the LLM backend. Requests queue up, increasing latency per generation. Unless you have a dedicated quota, stay less than 30.
Recommendations
The following recommendations serve as a starting point for configuring concurrency and parallelism for AlphaEvolve.
| Problem Type | Concurrency | Rationale |
|---|---|---|
| Well-understood, tuning known approach | 3–5 | Focused exploitation |
| General optimization, unknown landscape | 8–12 | Balanced exploration/exploitation |
| Highly non-convex, many local optima | 15–25 | Broad exploration |
| Intentional local optimum zoom-in | 1 | Sequential chain |
Start with concurrency=10 and adjust based on the following indicators:
Score plateau: Increase concurrency to escape local optima.
Many failing evaluations: Decrease concurrency to reduce wasted compute.
Slow evaluations (greater than 5 minutes): Higher concurrency keeps the evaluation pipeline busy.
Fast evaluations (lesser than 10 seconds): Lower concurrency allows successive generations to build directly on each other's results.