EliteTable Makes LLMs Evolve Controller Code: Gains in 6 of 6 Tasks

The authors of preprint arXiv:2610.12536 describe EliteTable, a program search algorithm in which a large language model writes and refines executable control policies on its own. The experiment covered six Gymnasium tasks. Each search ran for ten generations with 50 candidate slots, and every task got ten independent runs. The outcome is mixed: median candidate scores rose between the first and last generation on all six tasks, but on new episodes the gain held up in only some of them.

How EliteTable works

At its core is a table of fixed capacity. It stores the best solutions found so far, meaning programs that have already scored high in the environment. The table serves as context for the LLM. The model draws examples from it and works in three modes: it proposes a new solution, edits an existing one, or merges several into one (a remix).

The scheme resembles evolutionary search, with the language model playing the role of mutation and crossover and the bounded table handling selection. The search produces not neural network weights but policy code. You can read it, verify it, and run it like any ordinary program. For control tasks, that is a strong argument in the approach's favor.

What the six tasks showed

Here is the picture based on the numbers in the abstract:

• Search budget: 10 generations × 50 candidate slots, or up to 500 candidates per run.
• Repeatability: 10 independently initialized searches for each of the 6 tasks.
• Median candidate scores rose between the first and last generation in 6 of 6 tasks.
• Median search scores of the selected winners rose in 5 of 6 tasks.
• On CartPole-v1, the selected winner hit the search-score ceiling in the first generation of all ten runs.
• On held-out episodes, all ten paired final results improved in 4 of 6 tasks.
• BipedalWalker-v3 and CarRacing-v3 improved but did not reach the target values set for the report.

CartPole-v1 shows that the task is too easy to tell strong methods from weak ones: the ceiling is reached immediately, and after that the search proves nothing. BipedalWalker-v3 and CarRacing-v3 are far more informative. These are hard environments, and progress shows up there, but it fell short of the stated targets.

Where results diverge from expectations

Acrobot-v1 looks weakest. In six of the ten searches, the result on held-out episodes got worse, and the median paired change was negative. That suggests a winner selected by search score may have overfit to the specific search episodes and failed to generalize to new ones. This is the classic problem of selecting on a noisy metric, and the table of elite solutions, judging by the data, does not solve it.

The main caveat comes from the abstract itself. The authors write that assessing EliteTable's relative effectiveness and the contribution of individual components requires comparisons and ablations. No such data exists yet. It is unknown how much better the method is than plain random program search, generation without the table, or other LLM-based search methods. It is also unclear which of the three modes (proposal, edit, remix) delivers most of the gain. The work documents improvement over the course of the search and partial transfer of the gain to new episodes, but it does not prove the method's superiority.

For practitioners, the takeaway is this. The idea of keeping a compact table of the best programs and asking an LLM to rewrite them looks workable for synthesizing control code, especially where a readable policy matters. But if you plan to apply the approach to your own tasks, evaluate winners only on held-out episodes, not on the search score. Use several independent runs, and do not trust medians without a paired comparison. Until the authors publish baseline comparisons and ablations, it is reasonable to treat EliteTable as an interesting hypothesis, not a ready-made tool.