Mathematical exploration and discovery at scale

ABSTRACT. AlphaEvolve, introduced in [224], is a generic evolutionary coding agent that combines the generative capabilities of LLMs with automated evaluation in an iterative evolutionary framework that proposes, tests, and refines algorithmic solutions to challenging scientific and practical problems. In this paper we showcase AlphaEvolve as a tool for autonomously discovering novel mathematical constructions and advancing our understanding of longstanding open problems. To demonstrate its breadth, we considered a list of 67 problems spanning mathematical analysis, combinatorics, geometry, and number theory. The system rediscovered the best known solutions in most of the cases and discovered improved solutions in several. In some instances, AlphaEvolve is also able to generalize results for a finite number of input values into a formula valid for all input values. Furthermore, we are able to combine this methodology with Deep Think [149] and AlphaProof [148] in a broader framework where the additional proof-assistants and reasoning systems provide automated proof generation and further mathematical insights. These results demonstrate that large language model-guided evolutionary search can autonomously discover mathematical constructions that complement human intuition, at times matching or even improving the best known results, highlighting the potential for significant new ways of interaction between mathematicians and AI systems. We present AlphaEvolve as a powerful tool for mathematical discovery, capable of exploring vast search spaces to solve complex optimization problems at scale, often with significantly reduced requirements on preparation and computation time.

Introduction. The landscape of mathematical discovery has been fundamentally transformed by the emergence of computational tools that can autonomously explore mathematical spaces and generate novel constructions [56, 120, 242, 291]. AlphaEvolve (see [224]) represents a step in this evolution, demonstrating that large language models, when combined with evolutionary computation and rigorous automated evaluation, can discover explicit constructions that either match or improve upon the best-known bounds to long-standing mathematical problems, at large scales.

AlphaEvolve is not a general-purpose solver for all types of mathematical problems; it was primarily designed to attack problems in which a key objective is to construct a complex mathematical object that satisfies good quantitative properties, such as obeying a certain inequality with a good numerical constant. In this followup paper, we report on our experiments testing the performance of AlphaEvolve on a wide variety of such problems, primarily in the areas of analysis, combinatorics, and geometry. In many cases, the constructions provided by AlphaEvolve were not merely numerical in nature, but can be interpreted and generalized by human mathematicians, by other tools such as Deep Think, and even by AlphaEvolve itself. AlphaEvolve was not able to match or exceed previous results in all cases, and some of the individual improvements it was able to achieve could likely also have been matched by more traditional computational or theoretical methods performed by human experts. However, in contrast to such methods, we have found that AlphaEvolve can be readily scaled up to study large classes of problems at a time, without requiring extensive expert supervision for each new problem. This demonstrates that evolutionary computational approaches can systematically explore the space of mathematical objects in ways that complement traditional techniques, thus helping answer questions about the relationship between computational search and mathematical existence proofs.

We have also seen that in many cases, besides the scaling, in order to get AlphaEvolve to output comparable results to the literature and in contrast to traditional ways of doing mathematics, very little overhead is needed: on average the usual preparation time for the setup of a problem using AlphaEvolve took only up to a few hours. We expect that without prior knowledge, information or code, an equivalent traditional setup would typically take significantly longer. This has led us to use the term constructive mathematics at scale.

A crucial mathematical insight underlying AlphaEvolve’s effectiveness is its ability to operate across multiple levels of abstraction simultaneously. The system can optimize not just the specific parameters of a mathematical construction, but also the algorithmic strategy for discovering such constructions. This meta-level evolution represents a new form of recursion where the optimization process itself becomes the object of optimization. For example, AlphaEvolve might evolve a program that uses a set of heuristics, a SAT solver, a second order method without convergence guarantee, or combinations of them. This hierarchical approach is particularly evident in AlphaEvolve’s treatment of complex mathematical problems (suggested by the user), where the system often discovers specialized search heuristics for different phases of the optimization process. Early-stage heuristics excel at making large improvements from random or simple initial states, while later-stage heuristics focus on fine-tuning near-optimal configurations. This emergent specialization mirrors the intuitive approaches employed by human mathematicians.

Related work. 1.1. Comparison with [224]. The white paper [224] introduced AlphaEvolve and highlighted its general broad applicability, including to mathematics and including some details of our results. In this follow-up paper we expand on the list of considered mathematical problems in terms of their breadth, hardness, and importance, and we now give full details for all of them. The problems below are arranged in no particular order. For reasons of space, we do not attempt to exhaustively survey the history of each of the problems listed here, and refer the reader to the references provided for each problem for a more in-depth discussion of known results.

1.2. AI and Mathematical Discovery. The emergence of artificial intelligence as a transformative force in mathematical discovery has marked a paradigm shift in how we approach some of mathematics’ most challenging problems. Recent breakthroughs [87, 165, 97, 77, 296, 6, 271, 295] have demonstrated AI’s capability to assist mathematicians. AlphaGeometry solved 25 out of 30 Olympiad geometry problems within standard time limits [287]. AlphaProof and AlphaGeometry 2 [148] achieved silver-medal performance at the 2024 International Mathematical Olympiad followed by a gold-medal performance of an advanced Gemini Deep Think framework at the 2025 International Mathematical Olympiad [149]. See [297] for a gold-medal performance by a model from OpenAI. Beyond competition performance, AI has begun making genuine mathematical discoveries, as demonstrated by FunSearch [242], discovering new solutions to the cap set problem and more effective binpacking algorithms (see also [100]), or PatternBoost [56] disproving a 30-year old conjecture (see also [291]), or precursors such as Graffiti [119] generating conjectures. Other instances of AI helping mathematicians are for example [70, 283, 302, 301], in the context of finding formal and informal proofs of mathematical statements. While AlphaEvolve is geared more towards exploration and discovery, we have been able to pipeline it with other systems in a way that allows us not only to explore but also to combine our findings with a mathematically rigorous proof as well as a formalization of it.

Method. 1.3. Evolving Algorithms to Find Constructions. At its core, AlphaEvolve is a sophisticated search algorithm. To understand its design, it is helpful to start with a familiar idea: local search. To solve a problem like finding a graph on 50 vertices with no triangles and no cycles of length four, and the maximum number of edges, a standard approach would be to start with a random graph, and then iteratively make small changes (e.g., adding or removing an edge) that improve its score (in this case, the edge count, penalized for any triangles or four-cycles). We keep ‘hill-climbing’ until we can no longer improve.

The first key idea, inherited from AlphaEvolve’s predecessor, FunSearch [242] (see Table 1 for a head to head comparison) and its reimplementation [100], is to perform this local search not in the space of graphs, but in the space of Python programs that generate graphs. We start with a simple program, then use a large language model (LLM) to generate many similar but slightly different programs (‘mutations’). We score each program by running it and evaluating the graph it produces. It is natural to wonder why this approach would be beneficial. An LLM call is usually vastly more expensive than adding an edge or evaluating a graph, so this way we can often explore thousands or even millions of times fewer candidates than with standard local search methods. Many ‘nice’ mathematical objects, like the optimal Hoffman-Singleton graph for the aforementioned problem [142], have short, elegant descriptions as code. Moreover even if there is only one optimal construction for a problem, there can be many different, natural programs that generate it. Conversely, the countless ‘ugly’ graphs that are local optima might not correspond to any simple program. Searching in program space might act as a powerful prior for simplicity and structure, helping us navigate away from messy local maxima towards elegant, often optimal, solutions. In the case where the optimal solution does not admit a simple description, even by a program, and the best way to find it is via heuristic methods, we have found that AlphaEvolve excels at this task as well.

Still, for problems where the scoring function is cheap to compute, the sheer brute-force advantage of traditional methods can be hard to overcome. Our proposed solution to this problem is as follows. Instead of evolving programs that directly generate a construction, AlphaEvolve evolves programs that search for a construction. This is what we refer to as the search mode of AlphaEvolve, and it was the standard mode we used for all the problems where the goal was to find good constructions, and we did not care about their interpretability and generalizability.

Each program in AlphaEvolve’s population is a search heuristic. It is given a fixed time budget (say, 100 seconds) and tasked with finding the best possible construction within that time. The score of the heuristic is the score of the best object it finds. This resolves the speed disparity: a single, slow LLM call to generate a new search heuristic can trigger a massive cheap computation, where that heuristic explores millions of candidate constructions on its own.

We emphasize that the search does not have to start from scratch each time. Instead, a new heuristic is evaluated on its ability to improve the best construction found so far. We are thus evolving a population of ‘improver’ functions. This creates a dynamic, adaptive search process. In the beginning, heuristics that perform broad, exploratory searches might be favored. As we get closer to a good solution, heuristics that perform clever, problem-specific refinements might take over. The final result is often a sequence of specialized heuristics that, when chained together, produce a state-of-the-art construction. The downside is a potential loss of interpretability in the search process, but the final object it discovers remains a well-defined mathematical entity for us to study. This addition seems to be particularly useful for more difficult problems, where a single search function may not be able to discover a good solution by itself.

Discussion. To better understand the behavior and sensitivities of AlphaEvolve, we conducted a series of meta-analyses and ablation studies. These experiments are designed to answer practical questions about the method: How do computational resources affect the search? What is the role of the underlying LLM? What are the typical costs involved? For consistency, many of these experiments use the autocorrelation inequality (Problem 6.2) as a testbed, as it provides a clean, fast-to-evaluate objective.

3.1. The Trade-off Between Speed of Discovery and Evaluation Cost. A key parameter in any AlphaEvolve run is the amount of parallel computation used (e.g., the number of CPU threads). Intuitively, more parallelism should lead to faster discoveries. We investigated this by running Problem 6.2 with varying numbers of parallel threads (from 2 up to 20).

Our findings (see Figure 1), while noisy, seem to align with this expected trade-off. Increasing the number of parallel threads significantly accelerated the time-to-discovery. Runs with 20 threads consistently surpassed the state-of-the-art bound much faster than those with 2 threads. However, this speed comes at a higher total cost. Since each thread operates semi-independently and makes its own calls to the LLM to generate new heuristics, doubling the threads roughly doubles the rate of LLM queries. Even though the threads communicate with each other and build upon each other’s best constructions, achieving the result faster requires a greater total number of LLM calls. The optimal strategy depends on the researcher’s priority: for rapid exploration, high parallelism is effective; for minimizing direct costs, fewer threads over a longer period is the more economical choice.

3.2. The Role of Model Choice: Large vs. Cheap LLMs. AlphaEvolve’s performance is fundamentally tied to the LLM used for generating code mutations. We compared the effectiveness of a high-performance LLM We observed that the more capable LLM tends to produce higher-quality suggestions (see Figure 2), often leading to better scores with fewer evolutionary steps. However, the most effective strategy was not always to use the most powerful model exclusively. For this simple autocorrelation problem, the most cost-effective strategy to beat the literature bound was to use the cheapest model across many runs. The total LLM cost for this was remarkably low: a few USD. However, for the more difficult problem of Nikodym sets (see Problem 6.1), the cheap model was not able to get the most elaborate constructions.

We also observed that an experiment using only high-end models can sometimes perform worse than a run that occasionally used cheaper models as well. One explanation for this is that different models might suggest very different approaches, and even though a worse model generally suggests lower quality ideas, it does add variance. This suggests a potential benefit to injecting a degree of randomness or “naive creativity” into the evolutionary process. We suspect that for problems requiring deeper mathematical insight, the value of the smarter LLM would become more pronounced, but for many optimization landscapes, diversity from cheaper models is a powerful and economical tool.

Conclusion. Our exploration of AlphaEvolve has yielded several key insights, which are summarized below. We have found that the selection of the verifier is a critical component that significantly influences the system’s performance and the quality of the discovered results. For example, sometimes the optimizer will be drawn more towards more stable (trivial) solutions which we want to avoid. Designing a clever verifier that avoids this behavior is key to discover new results.

Similarly, employing continuous (as opposed to discrete) loss functions proved to be a more effective strategy for guiding the evolutionary search process in some cases. For example, for Problem 6.54 we could have designed our scoring function as the number of touching cylinders of any given configuration (or −∞if the configuration is illegal). By looking at a continuous scoring function depending on the distances led to a more successful and faster optimization process.

During our experiments, we also observed a “cheating phenomenon”, where the system would find loopholes or exploit artifacts (leaky verifier when approximating global constraints such as positivity by discrete versions of them, unreliable LLM queries to cheap models, etc.) in the problem setup rather than genuine solutions, highlighting the need for carefully designed and robust evaluation environments.

Another important component is the advice given in the prompt and the experience of the prompter. We have found that we got better at knowing how to prompt AlphaEvolve the more we tried. For example, prompting as in our search mode versus trying to find the construction directly resulted in more efficient programs and much better results in the former case. Moreover, in the hands of a user who is a subject expert in the particular problem that is being attempted, AlphaEvolve has always performed much better than in the hands of another user who is not a subject expert: we have found that the advice one gives to AlphaEvolve in the prompt has a significant impact on the quality of the final construction.

Limitations. 1.6. Limitations. We would also like to point out that while AlphaEvolve excels at problems that can be clearly formulated as the optimization of a smooth score function that is possible to ‘hill-climbing’ on, it sometimes struggles otherwise. In particular, we have encountered several instances where AlphaEvolve failed to attain an optimal or close to optimal result. We also report these cases below. In general, we have found AlphaEvolve most effective when applied at a large scale across a broad portfolio of loosely related problems such as, for example, packing problems or Sendov’s conjecture and its variants.

In Section 6, we will detail the new mathematical results discovered with this approach, along with all the examples we found where AlphaEvolve did not manage to find the previously best known construction. We hope that this work will not only provide new insights into these specific problems but also inspire other scientists to explore how these tools can be adapted to their own areas of research.