GrandCode: Achieving Grandmaster Level in Competitive Programming via Agentic Reinforcement Learning
Paper: arXiv:2604.02721 Code: deepreinforce-ai/codeforces Code reference:
main@47e2e93d(2026-04-01)
1. Motivation (研究动机)
现有 AI 编程系统的缺口
Competitive programming 仍然是代码生成里最难的实战场景之一：模型不仅要读懂长题面、隐藏约束、样例和图示，还要在严格时间与内存限制下产出能通过 hidden tests 的高效程序。论文把这个问题放在 Codeforces live contest 上，而不是离线 benchmark 上，原因是 live contest 同时考验四件事：解题正确性、算法复杂度、提交时间、以及只拿到有限 judge feedback 时的在线修正能力。
作者指出，已有强系统仍没有稳定在 live contest 中超过最强人类选手：AlphaCode 约为 Codeforces rating 1300、AlphaCode2 达到约 85th percentile，OpenAI o3 进入全球第 175 名；Gemini 3 Deep Think 曾达到第 8 名，但不是在 live competition 条件下完成。GrandCode 要解决的不是“能不能生成一段代码”这个窄问题，而是“能不能在真实竞赛窗口内，通过 agentic reasoning、verification、test generation 和 online adaptation，稳定赢过 legendary grandmasters”。
论文要解决的具体问题
GrandCode 的目标是构建一个面向竞赛编程的 multi-agent RL system：主 solver 负责推理和代码生成，hypothesis model 先提出结构性 conjecture，summarization model 压缩超长 thinking trace，test-case generator 主动制造 adversarial edge cases，并用 post-training RL 与 test-time RL 把这些模块接成闭环。
这件事值得研究的核心原因是：如果一个 AI 系统能在 live Codeforces 中稳定超过顶级人类，那么它说明 code agent 已经不仅是“离线 benchmark 解题器”，而是具备了接近真实工程 agent 的循环能力：理解问题、提出假设、生成候选实现、构造反例、吸收反馈、快速再优化。这个能力可迁移到更广泛的软件工程 agent：debugging、optimization、formal-ish verification、online patch search 等。
Figure 1 解读：这张图展示 GrandCode 参与的三场 Codeforces live contests 的 standings overview。论文强调 GrandCode 在 Round 1087、1088、1089 中都获得第一，并且都是最先完成全部题目的参赛者。这里的关键不是单题 pass，而是完整 contest-level scoring：提交越早分数越高，且错误提交会带来惩罚；因此它直接衡量系统在实时约束下的综合 agent 能力。
2. Idea (核心思想)
GrandCode 的核心 insight 是：顶级竞赛编程不能只靠一个大模型直接生成最终代码，而要把“假设提出—小规模验证—候选解生成—对抗测试—judge feedback—在线更新”做成可学习的 agentic loop。真正的创新点在于把这个 loop 作为 RL 对象来优化，并针对 multi-stage rollout 的 delayed rewards 与 off-policy drift 设计 Agentic GRPO。
与 AlphaCode / AlphaCode2 这类更偏向大规模采样、排序、筛选的系统相比，GrandCode 的差异在于它不是只把验证当成后处理，而是把 hypothesis model、summary model、test generator、main solver 都纳入训练与 test-time adaptation。与普通 GRPO / post-training RL 相比，Agentic GRPO 不等待最终 reward 才更新整个 trajectory，而是在中间 stage reward 可用时立即给 credit，再用 delayed correction 修正早期 stage 对最终结果的边际贡献。
这使得系统能同时处理两种困难：一是长链路 agent rollout 里 reward 很晚才出现，训练效率低且 off-policy 严重；二是真实竞赛中 hidden tests 不可见，必须靠自生成 adversarial tests 和有限在线反馈来逼近真实 judge。
3. Method (方法)
3.1 Overall framework：post-training + live-contest test-time RL
GrandCode 由三个 learned policies 和一个测试生成模块组成：
πmain：主 solver，生成 reasoning traces 与最终 C++ code。πhypothesis：提出中间 conjectures、结构性质或数学刻画，并先在小规模实例上验证。πsummary：压缩很长的 thinking trace，使 hard problems 的推理和 RL 训练仍然可处理。- Test-case generation：生成 adversarial tests、solution-attack tests 和 large-size stress cases，用来在提交前挑战候选程序。
系统分两大阶段。第一阶段是 post-training，包括 noisy competitive-programming data 上的 continued pretraining、基于高质量 (question, thinking, solution) triples 的 SFT、以及 multi-component RL。第二阶段是 test-time / live-contest solving：先用 difficulty classifier 把题目分成 Level 1–5；简单题走 direct generation 并行采样，难题进入 online test-time RL，使用验证反馈快速适配当前题目。
Figure 2 解读：左侧是 post-training pipeline：继续训练 noisy data，SFT 学习高质量推理，分别训练 πmain、πhypothesis、πsummary，再做 multi-component RL。右侧是 live contest pipeline：difficulty classifier 决定是否直接生成；如果 direct generation 不足，系统进入 test-time RL loop，持续生成、验证、重新采样，直到接受候选解并提交。图中最重要的是把“训练时的模块协作”和“测试时的在线反馈”连接起来，而不是把 test generator 当成一次性过滤器。
直觉上，GrandCode 能工作的原因是：竞赛题的失败通常不是语言模型完全不会写代码，而是某个关键结构假设、边界条件、复杂度判断或图示理解错了。把 hypothesis 和 adversarial tests 提前显式化，相当于让模型在真正提交前不断自造“反例压力”；再用 RL 学会哪些假设、摘要和候选实现最终更可能通过 hidden judge。
3.2 Agentic GRPO：Immediate Reward + Delayed Correction
普通 GRPO 会把完整 trajectory 的所有 token 都用最终 reward 更新，而 GrandCode 的 rollout 是 multi-stage： 如果每个 stage 都要等待最终 judge-like reward，训练会很慢；但如果只用 intermediate reward，又可能忽略早期决策对最终成功的贡献。因此 Agentic GRPO 把每个 stage 的更新拆成两步。
Immediate Reward. 对第 个 stage，在 个 rollouts 内按当前 stage reward 归一化： 对应的 clipped GRPO loss 为： 其中 这里的 behavior policy version 可以随 token 变化，因为 asynchronous pipeline training 里 sampling 与 training 并行，旧 token 可能由不同版本的 policy 生成。
Delayed Correction. 当最终 reward 出现后，对更早 stage 定义 correction： 再对 correction 做 group normalization，并用更保守的 clipping range 更新旧 stage： Appendix C 进一步解释：Agentic GRPO 的 immediate signal 与 delayed correction 在未归一化时可分解为最终 advantage，但二者分别用自己的 和 归一化，因此不等同于普通 GRPO 的单一 normalization。这不是 bug，而是让“当前 stage 质量”和“未来 marginal contribution”都有自己的尺度，避免某一类信号方差过大而压制另一类。
import torch
import torch.nn.functional as F
def agentic_grpo_stage_update(logp_new, logp_beh, reward_t, eps=0.2):
"""Paper-level sketch of immediate reward update for one rollout stage."""
advantage = (reward_t - reward_t.mean()) / (reward_t.std(unbiased=False) + 1e-6)
ratio = torch.exp(logp_new - logp_beh)
clipped = torch.clamp(ratio, 1.0 - eps, 1.0 + eps)
token_loss = -torch.minimum(ratio * advantage[:, None], clipped * advantage[:, None])
return token_loss.mean()
def agentic_grpo_delayed_correction(logp_current, logp_beh, reward_final, reward_t, eps2=0.1):
"""Paper-level sketch of delayed correction after the final reward arrives."""
delta = reward_final - reward_t
corr_advantage = (delta - delta.mean()) / (delta.std(unbiased=False) + 1e-6)
ratio = torch.exp(logp_current - logp_beh)
clipped = torch.clamp(ratio, 1.0 - eps2, 1.0 + eps2)
token_loss = -torch.minimum(ratio * corr_advantage[:, None], clipped * corr_advantage[:, None])
return token_loss.mean()论文公式与 released code 实现差异：官方 deepreinforce-ai/codeforces 仓库在 main@47e2e93d 只发布了三场 Codeforces 的 C++ submitted solutions，没有发布 Agentic GRPO、pipeline-RL、test-case generation、hypothesis model、summarizer 或训练配置代码；因此以上 pseudocode 是严格依据论文公式的 paper-level sketch，不是从 released training implementation 反推得到。
3.3 Test-case generation：difference-driven tests + solution attack
真实 Codeforces 的 hidden tests 不可见，所以 GrandCode 必须在提交前构造自己的高强度测试集。论文把 test generation 分成两类。
Difference-driven test generation. 给定训练/搜索中采样到的多个候选解，系统提示 Claude、GPT、DeepSeek V3、Kimi 2.5 等模型生成可能触发 corner cases 的输入。此时不把候选解直接给 LLM，而是让 generator-validator 框架先筛选或 refine 测试。随后把测试跑在所有候选解上：如果某个输入让不同候选解产生不同输出，就保留该测试，并把“可能触发的边界条件”反馈给 LLM，继续生成同类测试。
Solution attack. 当训练集中有 gold solution 时，系统把 gold solution 和 candidate solution 同时给 LLM，让它分析差异、定位潜在 bug、提出能区分两者的 edge cases。每个生成测试都实际执行，只有确实能区分 gold/candidate 行为的测试才被保留。作者还用这些 verified adversarial examples 继续 fine-tune 一个 Qwen-3.5-27B test generator。
def build_adversarial_tests(problem, candidate_solutions, llm_generators, validator, gold=None):
"""Paper-level sketch of GrandCode's adversarial test construction."""
test_pool = set(problem.public_tests)
for _ in range(problem.test_generation_rounds):
proposals = []
for llm in llm_generators:
proposals += llm.generate_corner_cases(problem, hints=None)
proposals = validator.filter_or_refine(problem, proposals)
for test in proposals:
outputs = [run_cpp(sol, test) for sol in candidate_solutions]
if len(set(outputs)) > 1:
test_pool.add(test)
edge_hint = llm_generators[0].describe_trigger(problem, test, outputs)
proposals += llm_generators[0].generate_similar_cases(problem, edge_hint)
if gold is not None:
for sol in candidate_solutions:
attacked = llm_generators[0].attack_solution(problem, gold, sol)
for test in attacked:
if run_cpp(gold, test) != run_cpp(sol, test):
test_pool.add(test)
return test_pool在 50 个真实 Codeforces problems 上，base test suite 的通过数是 42/50；加入 difference-driven generation + solution attack 后变成 48/50；再利用 submission feedback 做 continued online generation 后达到 50/50。这说明 test generator 不是锦上添花，而是把“看起来通过自测”的候选代码推向真实 hidden judge 的关键桥梁。
3.4 Hypothesis generation：先验证结构性 conjecture，再进入 solution synthesis
Hypothesis generation 是解题 workflow 的第一步。模型先提出中间 claims、结构性质或紧凑数学刻画，比如“这题本质上是 dynamic programming”或“输入图满足某种结构”。这些 hypothesis 不直接信任，而是在小规模 random instances 上用 brute-force solver 验证；如果 mismatch，就修正 hypothesis，直到所有小规模测试一致后才注入主 solver 的 prompt。
Figure 3 解读：图中以一个 compact characterization 为例，πhypothesis 先提出形如 的假设；系统生成小规模实例，用 brute-force 枚举所有 tuples 计算精确答案，再比较 hypothesis output 与 brute-force output。红色路径表示 mismatch 后回到 hypothesis revision，绿色路径表示通过验证后进入 solution synthesis。这等价于把“先想一个关键性质”变成可检验的中间状态。
def verify_and_refine_hypothesis(problem, hypothesis_model, brute_force_solver, max_rounds=8):
"""Paper-level sketch of hypothesis proposal with small-scale verification."""
history = []
hypothesis = hypothesis_model.propose(problem, history=history)
for _ in range(max_rounds):
small_tests = generate_small_random_instances(problem)
failures = []
for test in small_tests:
exact = brute_force_solver(test)
predicted = evaluate_hypothesis(hypothesis, test)
if predicted != exact:
failures.append((test, predicted, exact))
if not failures:
return hypothesis
history.append({"hypothesis": hypothesis, "failures": failures})
hypothesis = hypothesis_model.revise(problem, history=history)
return None论文还允许调用 symbolic tools：如果子问题可被翻译成 symbolic form，可查询 Wolfram Alpha；对于 integer sequence，也会把结果送到 OEIS，若查到 pattern / formula / structural hint，就放入后续 solving prompt。
3.5 Continued training、SFT 与 summarization model
GrandCode 以 Qwen 3.5 作为 foundation model。continued training 使用 TACO、LeetCode、USACO、CodeContests、IOI 以及爬取的 online problems 作为 seed，再由 Gemini 3.1 Pro 扩展成更大的 corpus，并用 Claude 4.6 与 Gemini 3.1 生成 detailed thinking processes。为了让模型熟悉 hypothesis-conditioned solving，20% 的 continued-pretraining examples 被随机改造成带 πhypothesis 的 prompt。
SFT 阶段只使用有 reference solutions 的非合成题。对于较容易题，作者从 Gemini 3.1 Pro、Claude Opus 4.6、GPT-5.4、GLM 4.5、Kimi K2.5、DeepSeek V3.2 多次采样 reasoning trace 和 solution；如果生成解等价于 gold solution，或者效率可比/更好，就保留对应 thinking trace。对于更难题，简单 matching 不够，论文为每个 hard (x,y) 生成 个候选 reasoning contexts ，再用长度归一化 score 选择：
第一项偏好能让 post-trained model 解释出目标 reasoning 和 solution 的 context；第二项要求 context 本身仍然能预测原问题，防止 reasoning trace 退化成直接泄漏答案。
Hard problems 的 thinking trace 可能超过 100K tokens，因此论文训练独立的 πsummary。给定长 trace ，拆成 chunks ，progressive summary state 满足：
Stage 1 用局部 RL 训练 summary step，使 summary 既能保留后续推理和 final answer 所需的信息，也能重建当前 chunk：
Stage 2 再对完整 progressive chain 做 end-to-end GRPO，用 normalized final answer likelihood（如 ）作为 terminal reward。Stage 3 把 πsummary 接入 πmain 的全局 RL pipeline。
def train_progressive_summarizer(summary_policy, chunks, answer, grpo_update):
"""Paper-level sketch of two-stage summarizer training."""
states = []
prev_summary = None
local_rewards = []
for chunk in chunks:
summary = summary_policy.sample(prev_summary, chunk)
preserve_future = score_future_likelihood(summary, chunks, answer)
reconstruct_chunk = score_reconstruction(summary, chunk)
local_rewards.append(preserve_future + reconstruct_chunk)
states.append(summary)
prev_summary = summary
grpo_update(summary_policy, trajectories=states, rewards=local_rewards)
final_reward = normalized_logprob_answer(answer, context=states[-1])
grpo_update(summary_policy, trajectories=states, rewards=[final_reward])
return states[-1]3.6 Multi-component RL orchestration
最终 RL 阶段同时优化 πmain、πhypothesis、πsummary。作者选择分模块而非单一大 policy，有三个理由：小 auxiliary models 更省算力；它们已通过前序阶段初始化，不需要从零学；模块化让错误来源更可诊断，避免 summary 差和 solver 差混在一个 terminal reward 里。
πmain 的 code reward 分三层：executability、correctness、efficiency。Appendix B 形式化为：如果程序 不能编译/执行，或 correctness check 失败，则 ；否则对每个 efficiency test case 比较 brute-force solver 与候选程序运行时间，取平均 speedup。如果 timeout，单个 test case 的 efficiency score 设为 0.1。
对 πhypothesis，先用验证测试集 定义局部 reward：
若 hypothesis 通过所有测试，再比较带 hypothesis 的 solver 平均分 与无 hypothesis 的平均分 ：
这让 πhypothesis 不只学会“局部正确”，还要学会提出能真正提高 downstream solution quality 的假设。πsummary 只在长 reasoning sequence 触发，训练中随 curriculum 向 harder problems 转移逐步提高触发频率；当 summary-conditioned rollout 产生最终程序 时，πsummary 使用和 πmain 相同的 final rollout score 。
3.7 RL infrastructure：asynchronous training、pipelined CP 与 batching
为了处理长 reasoning trace 与异步 rollout，GrandCode 把 Agentic GRPO 与 pipeline-RL 结合。对于过旧的 off-policy tokens，使用 staleness weight： 这和 Agentic GRPO 互补：intermediate rewards 因为很快被用来更新，不太受 staleness 影响；delayed correction 如果到达太晚，就可能被 drop。
GrandCode 的 foundation architecture 包含 DeltaNet + softmax attention mixture。由于 DeltaNet 是 linear recurrent operator，标准 context parallelism 会被 recurrent state 的顺序依赖限制。论文提出 pipelined CP：在 DeltaNet phase 中让多个 micro-batches staggered through CP ranks，softmax attention phase 再同步 all-to-all。4 个 CP ranks + 4 个 micro-batches 的代表性设置整体 utilization 约 90.3%；micro-batches 增至 16 时 overall efficiency 约 97%。
Figure 5 解读：图中上半部分是 3 个 DeltaNet layers 在 4 个 CP ranks 与 4 个 micro-batches 上的 staggered pipeline，灰色三角表示 startup/drain bubbles；下半部分是 softmax attention 层，需要 synchronized all-to-all。核心意义是：GrandCode 的 hard-problem reasoning 很长，若不解决 long-context training 的吞吐问题，Agentic GRPO 的多轮 rollout 会被训练系统瓶颈吞掉。
3.8 Test-time RL：从 average reward 平滑过渡到 best-of-N
Post-training RL 的目标是提高跨问题的平均能力：
Test-time RL 的目标不同：对当前单个题目，只需要找到一个最好的可提交解，更接近 best-of-N：
直接只保留 best rollout 会让 reward 过稀疏，所以论文采用 rank-based relaxation。将 个 rollouts 的 reward 排序为 ，优化：
当 时退化为 average reward；随着 增大，权重集中到 top-ranked rollouts，逐步逼近 best-of-N。Test-time 阶段只优化 LoRA 参数，不更新全模型；πhypothesis 和 πsummary 固定，只更新 πmain。系统还维护一个 global summary of search history，记录哪些策略尝试过、哪些有效、哪些失败，并把它喂给后续 rollouts。
def rank_weighted_test_time_rl(policy_lora, problem, verifier, lam_schedule):
"""Paper-level sketch of GrandCode's rank-smoothed test-time RL."""
history_summary = ""
best_solution, best_reward = None, float("-inf")
for lam in lam_schedule:
rollouts = policy_lora.sample_batch(problem, context=history_summary)
rewards = torch.tensor([verifier.score(r.code) for r in rollouts], dtype=torch.float32)
order = torch.argsort(rewards, descending=True)
ranks = torch.arange(1, len(rollouts) + 1, dtype=torch.float32)
weights = torch.softmax(-lam * ranks, dim=0)
objective = (weights * rewards[order]).sum()
policy_lora.update_with_policy_gradient([rollouts[i] for i in order], objective)
top = order[0].item()
if rewards[top].item() > best_reward:
best_solution, best_reward = rollouts[top].code, rewards[top].item()
history_summary = summarize_search(history_summary, rollouts, rewards)
if verifier.ready_to_submit(best_solution):
break
return best_solution3.9 Multimodal problem solving
许多 Codeforces 题面包含图示。论文指出，把图像转成文字描述再输入模型显著差于直接 multimodal processing，因为很多空间结构很难被 faithful textual description 捕捉。GrandCode 因此遵循 Qwen 的 native multimodal input protocol 处理带图题。
Figure 4 解读：这组例子展示了题面图像中包含的空间关系、箭头、局部结构和 grid 状态。作者用它解释为什么 text-only conversion 会失败：文字摘要很容易丢失“哪个元素连到哪个元素”“黑白格如何变化”这类关系，而这些关系正是竞赛题推理所需的约束。
Figure 9 解读：这是 Round 1088 Problem G Toothless 的样例图示，展示三个 test panels 中 grid 在 moves 前后的变化。论文用它作为 multimodal contest problem 的具体例子：题面并不只是文本约束，还包含需要视觉理解的状态变化；如果 agent 只依赖 OCR 或人工转写式描述，可能错过 move validity 与目标状态之间的结构关系。
3.10 Released code inspection and mapping
Code reference:
main@47e2e93d(2026-04-01) — pseudocode and mapping based on this public commit where applicable
官方仓库是 deepreinforce-ai/codeforces。我检查的 main@47e2e93d 包含 22 个 C++ 文件，分别对应 GrandCode 在 Round 1087、1088、1089 中提交的 accepted/contest solutions；仓库没有 README、训练脚本、Agentic GRPO 实现、test generator、hypothesis/summarization policy、LoRA test-time RL 或 launch configs。因此本 note 对 paper method 的伪代码来自论文公式与描述；released code 只能作为“最终提交代码证据”，不能作为训练实现证据。
| Paper Concept | Source File | Key Class/Function |
|---|---|---|
| Round 1087 final submitted solutions | codeforces-round-1087-div2/A.cpp–F.cpp | C++ main() per problem |
| Round 1088 final submitted solutions | codeforces-round-1088-div1-div2/A.cpp–H.cpp | C++ main() per problem; includes more complex implementations such as E.cpp with custom fast input / solver structs |
| Round 1089 final submitted solutions | codeforces-round-1089-div2/A.cpp–F.cpp | C++ main() per problem |
| Appendix D submitted-code examples | codeforces-round-1089-div2/A.cpp, codeforces-round-1088-div1-div2/E.cpp, codeforces-round-1088-div1-div2/F.cpp | Matches paper appendix examples at solution-code level |
| Agentic GRPO training loop | Not released in this repo | No source file available |
| Test-case generator / solution attack | Not released in this repo | No source file available |
| Hypothesis generation and summarization policies | Not released in this repo | No source file available |
| Test-time RL / LoRA adaptation | Not released in this repo | No source file available |
Released repo file inventory checked at main@47e2e93d: codeforces-round-1087-div2/A.cpp, codeforces-round-1087-div2/B.cpp, codeforces-round-1087-div2/C.cpp, codeforces-round-1087-div2/D.cpp, codeforces-round-1087-div2/E.cpp, codeforces-round-1087-div2/F.cpp; codeforces-round-1088-div1-div2/A.cpp, codeforces-round-1088-div1-div2/B.cpp, codeforces-round-1088-div1-div2/C1.cpp, codeforces-round-1088-div1-div2/C2.cpp, codeforces-round-1088-div1-div2/D.cpp, codeforces-round-1088-div1-div2/E.cpp, codeforces-round-1088-div1-div2/F.cpp, codeforces-round-1088-div1-div2/G.cpp, codeforces-round-1088-div1-div2/H.cpp; codeforces-round-1089-div2/A.cpp, codeforces-round-1089-div2/B.cpp, codeforces-round-1089-div2/C1.cpp, codeforces-round-1089-div2/C2.cpp, codeforces-round-1089-div2/D.cpp, codeforces-round-1089-div2/E.cpp, codeforces-round-1089-div2/F.cpp.
4. Experimental Setup (实验设置)
Evaluation setting and datasets
论文使用三类 evaluation settings：
| Setting | Scale / source | Purpose |
|---|---|---|
| Live Codeforces contests | Round 1087 Div.2, Round 1088 Div.1+2, Round 1089 Div.2 | 检验真实竞赛条件下的 ranking、score、finish time |
| Codeforces test-case generation evaluation | 50 real Codeforces problems | 用真实 Codeforces judge 判断 generated tests 是否足以筛出 hidden-test failures |
| Internal benchmark | 100 questions, five difficulty categories equally distributed | 比较 frontier models、post-training / SFT / RL / test-time RL 阶段增益 |
| Hypothesis generation evaluation | 200-problem evaluation set | 衡量 πhypothesis 的 pass@1 / pass@5 |
Training data 包括 TACO、LeetCode、USACO、CodeContests、IOI，以及额外 crawled online problems；continued training 时用 Gemini 3.1 Pro 扩展 seed set，并用 Claude 4.6 / Gemini 3.1 生成 detailed thinking processes。SFT 阶段只保留有 reference solutions 的非合成题，并通过 solution matching 与 hard-problem context scoring 选择高质量 thinking traces。
Baselines and compared models
论文比较的 baseline / reference systems 包括 AlphaCode、AlphaCode2、OpenAI o3、Gemini 3 Deep Think 作为 historical context；在 100-question benchmark 表 3 中直接评估 Gemini 3.1 Pro、Claude Opus 4.6、GPT-5.4、Kimi K2.5、DeepSeek V3.2、Qwen 3.5-397B。训练阶段 ablation 以 Qwen 3.5-397B 为 base，再逐步加入 continued training、SFT、summary、full RL、test-time RL。
Metrics
- Codeforces score：按 Codeforces contest scoring；早提交分数更高，错误尝试有小惩罚。论文报告 与 。
- Accept Rate：100-problem benchmark 中最终 accepted 的比例。
- Level 5 Solved：最难 Level 5 problems 的 solved count，分母为 20。
- Weighted Score (0–100)：五个 difficulty levels 分别赋权 1–5 后归一化的得分。
- Pass@1 / Pass@5：hypothesis generation 在 200-problem set 上一次/五次采样中通过验证的概率。
- Test-case pass count：50 个 Codeforces problems 中，candidate solution 通过 generated tests 后也通过 hidden official tests 的数量。
Training and systems configuration
- Foundation model：Qwen 3.5 / Qwen 3.5-397B；summarizer 从 Qwen-3.5-27B 开始训练；test generator 也 fine-tune Qwen-3.5-27B。
- Data generation models：Gemini 3.1 Pro、Claude 4.6、Claude Opus 4.6、GPT-5.4、GLM 4.5、Kimi K2.5、DeepSeek V3.2 等用于生成 reasoning traces、candidate solutions 或 adversarial tests。
- Difficulty routing：轻量 classifier 将任务分为 Level 1–5。
- Test-time adaptation：只优化
πmain的 LoRA 参数；πhypothesis与πsummary固定。 - Systems details：
πmain放在 dedicated distributed GPU mesh；πhypothesis和πsummary是 smaller dense models，异步服务在 separate small GPU pools；code execution、brute-force checking、test generation 使用 CPU sandbox pool。论文未详细说明 GPU 型号、GPU 数量、learning rate、batch size、总训练 steps 或 LoRA rank。 - Released code caveat：官方 GitHub 没有 launch script / experiment config；因此 training-config numbers 不能从代码中核验，note 只记录论文明确给出的设置。
5. Experimental Results (实验结果)
Live Codeforces results
GrandCode 在三场 live contests 中均排名第一，并且最早完成全部题目：
| Round | Div. | Date | ID | Finish time | ||
|---|---|---|---|---|---|---|
| 1087 | 2 | Mar. 21, 2026 | averyjones1 | 9269 | 8334 | 00:51:11 |
| 1088 | 1+2 | Mar. 28, 2026 | yokeko | 16511 | 15008 | 01:40:35 |
| 1089 | 2 | Mar. 29, 2026 | Vortex1 | 11596 | 9506 | 00:56:43 |
低于 ，因为论文为了遵守/规避 Codeforces 对 suspected AI-generated content 的审查风险，会等人类参赛者接近完成后再提交完整版本。作者认为 multiple-submission penalty 影响较小，因为所有题目最多四次提交内解决，且 Codeforces 的多次尝试惩罚相对早提交分数较小。
Test-case generation results
| Stage | Passed | Total |
|---|---|---|
| Base test suite | 42 | 50 |
| After difference-driven generation + solution attack | 48 | 50 |
| After submission feedback + continued online generation | 50 | 50 |
结果说明：只靠 base tests 会漏掉 8/50 个 hidden-judge failures；difference-driven tests 与 solution attack 能额外筛出 6 个；最后对剩余失败用真实 submission feedback 继续在线生成 tests，达到 50/50。这个结果支撑了论文的核心判断：competitive programming agent 的关键瓶颈不是单次生成，而是能否主动构造高价值反例。
Hypothesis generation results
| Model for Hypothesis Gen | pass@1 | pass@5 |
|---|---|---|
| Qwen-3.5-27B | 34% | 44% |
| +SFT | 45% | 52% |
| +SFT+RL | 52% | 57% |
在 200-problem evaluation set 上，SFT 让 pass@1 从 34% 提到 45%，pass@5 从 44% 提到 52%；继续用 GRPO 做 RL 后，pass@1 提到 52%，pass@5 提到 57%。这说明 πhypothesis 不是简单 prompt trick，而是一个可通过 verified hypotheses 数据和 RL 持续改进的独立模块。
Frontier model benchmark results
| Model | Accept Rate | Level 5 Solved | Weighted Score (0–100) |
|---|---|---|---|
| Gemini 3.1 Pro | 75% | 7/20 | 64.3 |
| Claude Opus 4.6 | 73% | 8/20 | 63.7 |
| GPT-5.4 | 72% | 7/20 | 63.0 |
| Kimi K2.5 | 65% | 5/20 | 53.3 |
| DeepSeek V3.2 | 65% | 4/20 | 52.7 |
| Qwen 3.5-397B | 64% | 4/20 | 52.3 |
这个表的作用是给 GrandCode 的训练起点定标：frontier proprietary models 在该 benchmark 上大约 70%–75% accept rate，但 Level 5 仍明显困难。
Continued training / SFT / summary ablation
| Model / Stage | Accept Rate | Level 5 Solved | Weighted Score (0–100) |
|---|---|---|---|
| Qwen 3.5-397B | 64% | 4/20 | 52.2 |
| +continue training | 71% | 6/20 | 61.0 |
| +continue training + SFT | 73% | 7/20 | 62.5 |
| +continue training + SFT + summary | 72% | 7/20 | 61.7 |
Continued training 是最大增益来源：accept rate 从 64% 到 71%，weighted score 从 52.2 到 61.0。SFT 继续带来小幅增益到 73% / 62.5。加入 summary 后该 100-problem benchmark 上略降到 72% / 61.7；论文没有把它解释为 summary 无用，而是强调 hard questions 的超长 trace 需要 summary 才能让后续 RL 和 inference 可计算。
Full RL and test-time RL results
| Stage | Accept Rate | Level 5 Solved | Weighted Score (0–100) |
|---|---|---|---|
| Post-training | 72% | 7/20 | 61.7 |
| Full RL training | 81% | 13/20 | 72.3 |
| After test-time RL | 85% | 15/20 | 73.5 |
Full RL training 带来最大后期提升：accept rate 从 72% 到 81%，Level 5 solved 从 7/20 到 13/20。Test-time RL 进一步把 accept rate 提到 85%，Level 5 solved 提到 15/20，说明 online adaptation 对最难题尤其有效。
Pipelined CP efficiency
| Micro-batches | DeltaNet Efficiency | Overall Efficiency | Bubble Overhead |
|---|---|---|---|
| 2 | 67% | 87% | 13% |
| 4 | 80% | 90.3% | 9.7% |
| 8 | 89% | 94% | ~6% |
| 16 | 94% | 97% | ~3% |
| large |
这组结果说明系统工程优化对 GrandCode 不是外围细节：若 long-context RL 的吞吐不够，multi-agent rollout 和 delayed correction 的训练成本会失控。
Limitations and caveats
- 论文没有发布完整训练 / inference / RL infrastructure 代码；官方 GitHub 只包含最终提交的 C++ solutions，因此方法实现无法从 released code 复现。
- 关键训练超参（GPU 型号/数量、LR、batch size、训练步数、LoRA rank 等）论文未详细说明。
- Summary module 在 100-problem ablation 中带来轻微指标下降，说明 summary 的计算必要性和 benchmark-level accuracy 之间存在 trade-off。
- Codeforces live contest 涉及 AI content policy，论文采用延迟提交 joint setup；因此 更保守，但也意味着成绩解释需要区分 separate / joint 两种分数。
整体结论是：GrandCode 的成绩主要来自 agentic RL + verification + online adaptation 的组合，而不是某一个单独模型或单次采样策略。论文最有价值的贡献是把竞赛编程解题过程拆成可验证、可奖励、可在线优化的多模块闭环，并提出 Agentic GRPO 来处理这个闭环中 unavoidable 的 delayed reward 与 off-policy drift。