When Is Enough Enough in Self-Evolving LLM Systems?
Authors: Enoch Yin, Bin Liu, Zhengling Qi
Organizations: Department of Statistics, The George Washington University · Department of Statistics and Data Science, School of Management, Fudan University · Department of Decision Sciences, School of Business, The George Washington University
Self-evolving large language model (LLM) systems repeatedly propose, evaluate, and incorporate updates to prompts, skills, or other persistent artifacts. Despite their growing effectiveness, these systems typically operate under a predetermined iteration or compute budget, without a principled criterion to determine when further evolution is no longer worthwhile. This can lead to two undesirable consequences: unnecessary computation after performance has saturated and the risk of returning late updates that overfit or exploit the evaluation signal. These issues motivate us to study two fundamental questions: when should a self-evolving system stop, and what should it output once it stops? We address the first by formulating an online sequential testing problem and constructing an anytime-valid restart detector using the per-item paired evaluation outcomes already produced by self-evolving LLM systems. We address the second by formulating a change-point estimation problem and using the estimated transition to select an earlier artifact for output. The resulting procedure is plug-and-play and requires no modification of the underlying self-evolving algorithms. Across two self-evolving frameworks, three LLM model families, and five benchmarks, our method substantially reduces computation costs while maintaining comparable unseen-test performance. For example, on SearchQA with SkillOpt and DeepSeek V4 Flash, our method stops at round 4 rather than the full budget of 40, reducing token usage by 91.6% while achieving 82.43% unseen-test accuracy versus 82.00% under the full-budget run.
Figures & tables
Figure 1: A self-evolving run on SearchQA with DeepSeek V4 Flash. Performance improves during the first few rounds and then plateaus, yet the fixed-budget loop continues to round 40. Our procedure stops at round 4 and selects round 1 as the output, achieving comparable unseen-test performance while avoiding most of the subsequent computation.
Figure 2: Our stopping and output-selection Plug-and-Play module monitors paired validation outcomes from a self-evolving loop.
Figure 3: SpreadsheetBench trajectory under SkillOpt with DeepSeek V4 Flash.
Figure 4: LiveMath trajectory under SkillOpt with DeepSeek V4 Flash.
Benchmarks
SearchQA
GSM8K
OfficeQA
Stopping behavior
Validation size n
200
200
24
Full-run budget N
40
40
16
Alarm round Talarm
4
4
8
Change point ν^
2
2
5
Computation cost
Table 1: Main results for DeepSeek V4 Flash + SkillOpt with a shared detector configuration ( ε=0.01 , δ=0.05 , aGRAPA).
SearchQA
GSM8K
SkillOpt
GEPA
SkillOpt
GEPA
Stopping behavior
Alarm round Talarm
4
5
4
6
Change point ν^
2
2
2
3
Computation cost
Tokens to alarm (M)
2.18
2.36
1.21
1.79
Table 2: Robustness across self-evolving systems using DeepSeek V4 Flash and the same detector configuration. We compare SkillOpt and GEPA on the same benchmarks, reporting stopping behavior, computation cost, and unseen-test performance. GEPA token counts are estimated from metric-call counts.
DeepSeek V4 Flash
Qwen3-32B
GPT-5.6 Luna
Stopping behavior
Validation size n
200
200
200
Full-run budget N
40
40
40
Alarm round Talarm
4
12
10
Change point ν^
2
9
3
Computation cost
Table 3: Robustness across underlying models on SearchQA using SkillOpt with the same detector configuration. The detector adapts its stopping time to different evolution dynamics while reducing computation and retaining comparable unseen-test performance.
Appendix figures & tables5 assets
Supplementary material from the paper’s appendix.
Appendix
DeepSeek
Qwen
Luna
Stopping behavior
Validation size n
200
200
200
Full-run budget N
40
40
40
Alarm round Talarm
4
8
4
Change point ν^
2
2
2
Computation cost
Appendix
Table 4: Robustness across underlying models on GSM8K using SkillOpt with the same detector configuration.
System
Benchmark
Model
mix
aGRAPA
SkillOpt
SearchQA ( n=200 )
DeepSeek V4 Flash
5/2
4/2
SearchQA ( n=200 )
Qwen3-32B
12/9
12/9
SearchQA ( n=200 )
GPT-5.6 Luna
11/3
10/3
SearchQA ( n=100 )
DeepSeek V4 Flash
10/4
6/4
GSM8K ( n=200 )
DeepSeek V4 Flash
5/2
4/2
GSM8K ( n=200 )
Qwen3-32B
9/2
8/2
Appendix
Table 5: Alarm / ν^ for a single configuration ( ε=0.01 , δ=0.05 ) across SkillOpt and GEPA settings. “mix” denotes the fixed mixture with Λ={0.1,0.2,0.4} , and “aGRAPA” denotes the adaptive growth-optimal plug-in.
SearchQA
GSM8K
n=200
n=100
n=200
n=100
Stopping behavior
Full-run budget N
40
40
40
40
Alarm round Talarm
4
6
4
5
Change point ν^
2
4
2
2
Computation cost
Appendix
Table 6: Sensitivity to validation-set size using SkillOpt with DeepSeek V4 Flash and the same detector configuration. Smaller validation sets provide less evidence per round and therefore lead to slightly later stopping, while substantial computation is still saved and unseen-test performance remains comparable.
ε\δ
0.01
0.05
0.10
0.002
10/2
4/2
4/2
0.005
5/2
4/2
4/2
0.01
4/2
4/2
3/2
0.02
4/2
3/2
3/2
0.05
3/2
3/2
3/2
Appendix
Table 7: Sensitivity of the alarm round Talarm and estimated change point ν^ to (ε,δ) . Each entry reports Talarm/ν^ ; “–” indicates that no alarm is raised within the evolution horizon.
Figure 5: Evolution trajectories under SkillOpt with DeepSeek V4 Flash on SearchQA, GSM8K, and OfficeQA. The red dashed line marks Talarm , the purple star marks ν^ , and the gray dotted line denotes the full evolution budget.