今天，我们正式发布 SWE-1.7，这是迄今为止我们训练出的能力最强的模型。它以更低的成本达到了前沿水平的智能，推动了成本-性能帕累托曲线的进步。
SWE-1.7 是我们强化学习（RL）流程全面改进的成果：包括更优的基础设施、更稳定的训练、更高质量的数据，以及针对长周期任务的新技术。由于 SWE-1.7 是基于已经过广泛强化学习后训练的 Kimi K2.7 基础模型训练的，我们自身训练带来的巨大额外增益挑战了“后训练天花板”这一观点，并表明强化学习可以将能力推至远超此前认知的水平。
查看各模型在 FrontierCode 排行榜上的排名
在 Cognition，我们一直在制定和完善优秀智能体软件工程的原则，无论是在评估方面（通过 FrontierCode1、2），还是在训练方面（通过 SWE-1.7）。我们的模型特别针对更长周期的异步任务进行了优化，这是高质量软件工程的重要组成部分。
SWE-1.7 即日起可通过 Cerebras 在 Devin（Web、桌面和 CLI）中使用，吞吐量达 1000 TPS。我们鼓励您亲自尝试！
| 基准测试 | SWE-1.7 | Kimi K2.7 Code | GPT-5.5 | Opus 4.8 | Opus 4.7 | GLM-5.2 | Composer 2.5 | SWE-1.6 |
|---|---|---|---|---|---|---|---|---|
| FrontierCode 1.1 Main | 42.3% | 30.1% | 43.0% | 46.5% | 38.5% | 24.5% | 25.6% | 9.4% |
| Terminal-Bench 2.1 | 81.5% | 72.7% | 84.2% | 86.9% | 83.0% | 81.0% | 76.0% | 39.7% |
| SWE-Bench Multilingual | 77.8% | 73.5% | 76.8% | 84.4% | 80.5% | 74.5% | 71.6% | 58.3% |
本文的其余部分将介绍我们如何训练 SWE-1.7：包括模型背后的基础设施、算法和数据工作。我们将重点介绍四个重要的组成部分。
- 保持熵并稳定训练：长时间的强化学习运行面临两个具有挑战性的问题：熵坍缩，以及由于训练和推理之间的数值漂移导致的不稳定性。我们追查并解决了每个问题的成因，这使得训练能够在早期运行停滞的地方继续取得显著进步。
- 多集群训练与容错：强化学习并不需要其所有推理计算都在一个集群中完成。我们在横跨三大洲的集群上进行训练，通过对象存储传输权重更新，并构建了容错机制，使得硬件故障永远不会中断运行。
- 策划高质量数据：我们构建了一个广泛的数据质量流水线，通过自动化执行测试来运行每个任务，过滤掉学习信号低的任务，并对任务进行加固以防止奖励破解。
- 面向长周期任务的自我压缩：模型学会总结自身工作状态，并从该总结中恢复执行，从而将任务周期扩展到原始上下文窗口之外。我们使用交替长度惩罚机制，在保证正确性的前提下激励简洁的输出。
最后，我们分享一些关于模型因我们的训练设置而获得的、有趣行为倾向的观察，例如谨慎探索和简洁推理。
保持熵与稳定训练
我们发现训练稳定性是规模化下实现可预测改进的关键因素。
在使用异步 RL3 进行训练时，我们遇到的最棘手问题之一是推理与训练之间的 KL 散度不匹配4，因为训练器策略通常不同于采样策略。过去，为了纠正这一点（尽管规模较小），我们使用了重要性采样5和量化感知训练，用于 NVFP4 + 专家路由回放6,7中的低精度推演。
在此，我们介绍在更大规模下变得更为重要的额外干预措施。
我们发现 top-p 采样8对于防止熵崩溃9,10有显著贡献。熵崩溃是指一个强大的模型在几百步内停止探索，奖励陷入停滞。
极低概率的 token 通常是已偏离轨道或超出分布范围的轨迹的一部分。这些轨迹很可能产生低奖励，而 softmax 函数的特性会导致这些 token 使 token 概率分布变得尖锐。实际上，假设我们有三个 token，分别对应 logits 和概率，其中 token 3 是一个导致低奖励的低概率 token。如果我们采样了 token 3，其 logprob 相对于 logits 的梯度为：
并且对 logits 的策略梯度更新为 ，其中 是采样 token 的优势值。由于该轨迹获得的奖励较低，并且更新
在这些更新中，低概率 token 会受到惩罚，而高概率 token 的增长幅度更大。因此，采样会进一步拉大原本占主导地位的 token 的领先优势，使分布更加尖锐，并降低熵值。Top- 采样从一开始就阻止这些低概率 token 被采样并用作优化目标！
这种保持熵值的效果使得 top- 采样在我们的 rollout 中备受青睐。但简单实现 top- 显然会加剧训练与推理之间的不匹配——训练器计算所有 token 的概率分布，而 rollout 则从 top- 子集中采样，因此两者的分布差异更大，导致经过少量步骤后模型就会崩溃。为此，我们实现了采样分布重放机制，即在 rollout 时记录可供采样的保留 token 集合，并在训练器中利用这些掩码重新归一化概率。通过这一修正，我们运行的熵值在训练过程中基本保持恒定，且推理-训练分布差异也保持在可控范围内。
使用 top-p 采样重放的另一个有趣结果是，它仅针对概率低于阈值的 token。概率高于阈值的 token，其保留集大小为 1，因此重新归一化后的概率分布恒为 1，梯度被清零。我们通过实验发现，模型采样的 token 中有很大一部分概率高于标准 top-p 阈值，因此它们被排除在整体梯度计算之外。这降低了梯度噪声，使优化算法能够专注于轨迹中高学习信号的 token。
我们还发现使用 Muon 优化器并消除训练器中的非确定性操作能带来额外收益。
多集群训练
Cognition 是一家快速发展的研究实验室，正进入一个高度受限于算力的成熟领域。我们的目标是训练万亿参数级别的模型，但如今，在单一网络架构上拥有 10k 到 100k 芯片的大型集群是稀缺资源。相比之下，如果能够正确组合使用，全球各地的小型集群则非常充裕。
在这种设置下，强化学习的结构对我们有利。强化学习天然地可以跨多个集群分解。只有训练器必须位于单个高带宽集群上。负责生成轨迹数据的推理引擎是自包含的，它们可以在任何地方运行，除了当前权重之外不需要任何东西。
我们投资建设了利用这一特性的基础设施。我们的强化学习训练横跨三大洲的四个数据中心，将我们自身跨多个集群的 GPU 与来自 Fireworks 等推理服务商提供的额外算力相结合。其结果是，我们能够将强化学习训练的规模扩展到远超任何单个集群所能允许的程度。
这种设置的核心挑战在于，在每次优化器步骤之后，让所有推理引擎都能及时更新训练器的权重。我们希望这些权重更新能够快速完成，以减少轨迹数据的陈旧性，从而能够使用更激进的学习率进行训练。
简单地将完整模型从一个集群广播到另一个集群会既慢又低效。取而代之的是，每经过 K 个梯度步骤，我们计算并发送当前权重与先前权重之间的压缩权重增量，这将每次传输的数据量减少了超过 99%13。
我们并非将权重直接从训练器流式传输到每个推理集群，而是使用云对象存储来维护权重版本的单一真实来源。在训练器上传新的权重增量后，推理引擎几乎可以在不中断推理的情况下完成更新。每个训练任务在每个涉及的集群中都有一个权重控制器，负责管理该任务的权重版本生命周期。权重控制器轮询对象存储以获取新的清单文件，这些文件由训练器在每次更新后写入。当发现新的增量时，它会指示工作节点下载各自的分片，然后通过树形广播方式在本地磁盘间进行复制。同一个对象存储还负责将路由矩阵和 top-p 掩码从推理引擎传回训练器。
每个推理引擎在继续处理轨迹的同时，将增量预取到 CPU 内存中。只有当增量完全就绪后，引擎才会短暂暂停，就地应用该增量。正在处理中的轨迹可以直接在新权重上继续运行，其 KV 缓存保持不变。
采用这种方法，一个 1T 参数模型的跨洲际权重更新，端到端可在 1–2 分钟内完成。此过程异步进行，除更新时 3–4 秒的推理暂停外，不会阻塞训练或推理。
容错机制
在大规模系统中，硬件故障持续发生，而每次故障都全局重启会使长时间运行变得不可行。我们的架构根据故障发生位置——推理引擎或训练器——采用不同的处理方式。
推理侧的故障在架构上成本较低。引擎是自包含的，除当前权重外不持有任何状态，因此一个引擎宕机仅损失其正在处理的会话。我们使用 NVIDIA Dynamo 管理引擎生命周期并路由推理：每个智能体沙箱拥有自己的代理，记录输入和输出的 token，因此如果某个副本宕机，我们不会丢失完整的轨迹，Dynamo 会将其重新路由到另一个工作节点。当 Dynamo 在健康节点上重新调度该副本时，我们的权重控制器会从对象存储加载最新的检查点，并从该检查点版本重放一系列增量。
训练器是故障成本最高的地方：它是唯一紧密耦合的组件，一个节点宕机就会拖慢整个集群。为了快速恢复，每个节点在每一步都会异步检查点到本地磁盘，并将其分片复制到对等节点，因此宕机节点的状态可在数秒内从副本重建。如果容量仍然不足，运行会按整个数据并行副本的规模缩减，待节点恢复后再重新扩展。在此过程中，推理管线保持热状态。训练器重启后，一个缓冲策略会选择使用哪些累积的推理结果，并防止中断期间训练-推理吞吐量不平衡带来的偏差。
面向长周期任务的智能自压缩
从一开始，我们构建 Devin 就是为了完成异步、长时间运行的任务。SWE-1.7 直接在 Devin 的框架内进行训练，因此我们自然希望在自己的模型上训练更长时间跨度的任务。这带来了两个挑战。首先，任务展开（rollout）的时长可能远超原始上下文窗口的限制。其次，正如 DeepSeek R1 所展示的，在推理任务上应用强化学习往往会产生越来越长的响应，但我们希望模型在推理时保持高效，仅在处理困难任务时才进行详细阐述。
我们通过训练自我压缩（self-compaction）和交替长度惩罚（alternating length penalty）来解决这些问题。
- 当智能体接近上下文限制时，我们要求它总结自己的工作状态，然后让它从自己编写的摘要中恢复运行。在训练过程中，模型同时学习（1）编写信息更丰富、更简洁的摘要，以及（2）更好地利用和基于此类摘要进行工作。我们最初在 Kevin15 中引入了这种方法的一个版本，当时我们将其用于内核优化任务的探索。通过自我压缩，我们在 SWE-1.7 训练运行期间的展开（rollout）时长可达六小时。
- 我们并非在整个训练过程中统一应用长度惩罚，而是采用一种交替策略。在无约束阶段，模型仅针对任务成功进行优化。在预算阶段，我们会惩罚那些超出我们加权成本函数（该函数包含 token 数量、轮次以及工具调用所花费的总时间）中特定预算的解决方案。通过这种结构，模型能力范围内的任务响应长度会趋于压缩，而困难任务上的长程行为则得以保留。
数据质量
数据是决定我们模型学习哪些能力和技能的核心因素。因此，我们确保用于训练的数据经过校准且具有足够的难度，并抑制不良行为，以保持模型良好的对齐。我们主要关注以下几个方面：
- 验证器质量：任务的验证器可能在两个方向上出错：接受错误的解决方案（误报）或拒绝正确的解决方案（漏报）。我们设计了全面的质量保证流程，以最大限度地减少训练中误报和漏报的出现。
- 难度：在模型总能解决或总是失败的任务上，我们观察不到任何有意义的学习信号。因此，我们精心筛选了模型仅能低概率解决的训练数据，这既能产生真实的学习信号，同时又能推动模型智能的提升。
- 作弊检测与防范：我们采用了多种防御措施来应对不同形式的作弊行为。例如，我们对沙箱环境进行了网络限制，并移除了其中的 git 历史记录和参考工件。我们还把评分路径与智能体本身隔离开来。此外，我们采用了程序化检查来捕获已知的漏洞利用特征。最后，为了确保激励措施得当，我们对任何存在作弊尝试的轨迹（无论是否成功）都给予 0 奖励。
结果：模型行为
由于进行了大量的强化学习，SWE-1.7 表现出与其基础模型 Kimi K2.7 Code 显著不同的行为。首先，它比 K2.7 或其他前沿开源模型更加对齐且值得信赖。我们在随附的博文《衡量开源衍生模型的可信度》中对此进行了详细阐述。
我们在 SWE-1.7 中注意到的另一个行为差异是思维链的压缩。与 Kimi-K2.7-Code 相比，SWE-1.7 的首次思维链中功能词占比（作为语法“粘合剂”的词汇比例）要低得多，且平均每句话的单词数也几乎减少了一半。我们认为这直接受到了我们交替长度惩罚中的预算阶段的影响。我们在下面的下拉菜单中提供了几个压缩思维链的示例。
我们观察到的另一个主要行为差异是，SWE-1.7 在行动前对代码库的探索要彻底得多，这可以从模型执行的工具调用次数、文件读取次数和搜索次数中看出。
这一点在缺陷修复中体现得最为明显。一份缺陷报告通常描述一个主要症状，但底层问题往往影响更广的范围。与 Kimi-K2.7-Code 相比，SWE-1.7 更倾向于调查缺陷的根本原因，并考虑边界情况、假设性场景、对抗性输入以及超出明确要求的其他需求。通过其增强的代码库探索能力，SWE-1.7 在理解需要做出的具体设计决策方面也做得更好。此外，我们观察到 SWE-1.7 倾向于通过实验和试探（例如编写小型 Python 脚本）来解决语义歧义，而不是进行猜测。
我们认为这些行为直接源于我们为剔除数据中的假阳性和假阴性而采取的广泛质量保证措施，这迫使我们的模型提出更完整、端到端的解决方案。我们认为 SWE-1.7 增强的尽职调查能力直接转化为在各种基准测试上的更高性能。我们在下面的下拉菜单中附上了一些示例轨迹。
额外的思考会带来变更范围略微增加的代价。如 FrontierCode1 所述，一个好的解决方案只修改所需的最少文件集，而不触及无关代码或引入不必要的重构。由于 SWE-1.7 进行了更多推理，它也会做更多事情：编写额外的测试用例，并触及比任务本身简单要求更多的文件。我们注意到，整个行业的模型都存在这一趋势：随着推理能力的提升，模型所触及的文件范围也在扩大。这是我们期待改进的一个方面。
评估方法
- 所有模型均在最大推理能力下进行评估。
- Terminal-Bench 2.1：我们在自己的内部评估框架上进行评估，Anthropic 模型使用 Claude Code，OpenAI 模型使用 Codex，其他模型使用 Devin CLI，超时时间设置为 4 小时。
- SWE-Bench Multilingual：我们尽可能使用自行报告的数据，否则使用 Devin CLI 进行评估。
- FrontierCode 1.1：请参阅我们的博客文章。
参考文献
- [1]E. Lu, B. Pan, D. Birlikci, S. Lee, R. Wang, R. Choudhury, F. Ma, TC Qin, C. Baronio, 和 S. Alberti, "Introducing FrontierCode," 2026年6月. cognition.com/blog/frontier-code
- [2]E. Lu, B. Pan, F. Ma, A. Lombardi, D. Birlikci, S. Lee, R. Wang, R. Choudhury, TC Qin, C. Baronio, J. Teo, J. H. Lee, 和 S. Alberti, "FrontierCode 1.1," 2026年7月7日. cognition.com/blog/frontier-code-1.1
- [3]A. Piché 等人, "PipelineRL: Faster On-policy Reinforcement Learning for Long Sequence Generation," arXiv:2509.19128, 2025.
- [4]F. Yao 等人, "Your Efficient RL Framework Secretly Brings You Off-Policy RL Training," 2025. fengyao.notion.site/off-policy-rl
- [5]B. Pan, C. Baronio, A. Tam, P. Marsella, M. Jain, D. Chiu, Swyx, 和 S. Alberti, "Introducing SWE-grep and SWE-grep-mini: RL for Multi-Turn, Fast Context Retrieval," 2025. cognition.com/blog/swe-grep
- [6]"Stabilizing MoE Reinforcement Learning by Aligning Training and Inference Routers" (Rollout Routing Replay, R3), arXiv:2510.11370, 2025.
- [7]C. Baronio, B. Pan, S. Lee, E. Lu, S. Cao, R. Choudhury, A. Zweiger, R. Wang, G. Chang, 和 S. Alberti, "An Early Preview of SWE-1.6 and Research Update," 2026年3月. cognition.com/blog/swe-1-6-preview
- [8]A. Holtzman 等人, "The Curious Case of Neural Text Degeneration," arXiv:1904.09751, 2019.
- [9]G. Cui 等人, "The Entropy Mechanism of Reinforcement Learning for Reasoning Language Models," arXiv:2505.22617, 2025. arxiv.org/abs/2505.22617
- [10]S. Yu 等人, "DAPO: An Open-Source LLM Reinforcement Learning System at Scale," arXiv:2503.14476, 2025. arxiv.org/abs/2503.14476
- [11]DeepSeek-AI, "DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models," arXiv:2512.02556, 2025. arxiv.org/abs/2512.02556
- [12]K. Jordan 等人, "Muon: An optimizer for hidden layers in neural networks," 2024. kellerjordan.github.io/posts/muon — 另见 J. Liu 等人, "Muon is Scalable for LLM Training," arXiv:2502.16982, 2025.
- [13]Fireworks AI, "Frontier RL Is Cheaper Than You Think," 2026. fireworks.ai/blog/frontier-rl-is-cheaper-than-you-think
- [14]DeepSeek-AI, "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning," arXiv:2501.12948, 2025. arxiv.org/abs/2501.12948
- [15]C. Baronio、P. Marsella、B. Pan 与 S. Alberti，《Kevin-32B：面向 CUDA 内核编写的多轮强化学习》，2025 年。cognition.com/blog/kevin-32b
- [16]月之暗面团队，《Kimi K2.5：视觉智能体智能》，arXiv:2602.02276，2026 年 2 月。arxiv.org/abs/2602.02276
- [17]Terminal-Bench 团队，《Terminal-Bench：面向终端环境中 AI 智能体的基准测试》，2025 年。tbench.ai
- [18]J. Yang 等人，《SWE-smith：面向软件工程智能体的数据规模化》，arXiv:2504.21798，2025 年。arxiv.org/abs/2504.21798（SWE-bench Multilingual：swebench.com/multilingual）
Today, we’re launching SWE-1.7, the most capable model we’ve trained so far. It reaches frontier-level intelligence at a much lower cost, advancing the cost-performance Pareto curve.
SWE-1.7 is the result of broad improvements across our RL pipeline: better infrastructure, more stable training, higher-quality data, and new techniques for long-horizon tasks. Since SWE-1.7 was trained from a Kimi K2.7 base, which had already undergone extensive RL post-training, the large additional gains from our own training challenge the idea of a ‘post-training ceiling’ and suggest that RL can push capabilities much further than previously believed.
See how models rank on the FrontierCode leaderboard
At Cognition, we have been formulating and refining principles for good agentic software engineering both in evaluation, with FrontierCode1,2, and now in training, with SWE-1.7. Our model is particularly optimized for longer-horizon asynchronous tasks, an important component of high-quality software engineering.
SWE-1.7 is available today in Devin (Web, Desktop, and CLI) via Cerebras at 1000 TPS. We encourage you to try it for yourself!
| Benchmark | SWE-1.7 | Kimi K2.7 Code | GPT-5.5 | Opus 4.8 | Opus 4.7 | GLM-5.2 | Composer 2.5 | SWE-1.6 |
|---|---|---|---|---|---|---|---|---|
| FrontierCode 1.1 Main | 42.3% | 30.1% | 43.0% | 46.5% | 38.5% | 24.5% | 25.6% | 9.4% |
| Terminal-Bench 2.1 | 81.5% | 72.7% | 84.2% | 86.9% | 83.0% | 81.0% | 76.0% | 39.7% |
| SWE-Bench Multilingual | 77.8% | 73.5% | 76.8% | 84.4% | 80.5% | 74.5% | 71.6% | 58.3% |
The rest of this post covers how we trained SWE-1.7: the infrastructure, algorithms, and data work behind our model. We cover four important components that stand out.
- Preserving entropy and stabilizing training: Long RL runs face two challenging problems: entropy collapse, and instability due to numerical drift between training and inference. We hunted down and addressed causes of each, which enabled training to keep improving well past where earlier runs stalled.
- Multi-cluster training and fault tolerance: RL doesn’t need all of its inference compute in one cluster. We trained on clusters across three continents, shipped weight updates through object storage, and built fault tolerance so that hardware failures never stalled the run.
- Curating high-quality data: We built an extensive data-quality pipeline that runs each task through automated execution tests, filters out tasks with low learning signal, and hardens tasks to prevent reward-hacking.
- Self-compaction for long-horizon tasks: The model learns to summarize its working state and resume from the summary, extending task horizons past the raw context window. We use an alternating length penalty to incentivize concise output without sacrificing correctness.
Finally, we conclude by sharing some observations on interesting behavioral tendencies, such as careful exploration and concise reasoning, that the model acquired as a result of our training setup.
Preserving Entropy and Stabilizing Training
We found training stability to be a key contributor to predictable improvement at scale.
When training with asynchronous RL3, one of the most problematic issues we encountered was the KL divergence mismatch between inference and training4, since the trainer policy is usually different from the sampling policy. In the past, to correct for this (albeit at smaller scale), we used importance-sampling5 and quantization-aware training for low-precision rollouts in NVFP4 + experts routing replay6,7.
Here we present additional interventions that become more important at larger scale.
We find that top-p sampling8 contributes significantly to staving off entropy collapse9,10, where a strong model stops exploring and reward plateaus within a few hundred steps.
Very low probability tokens are often part of trajectories that have gone off track or out of distribution. These trajectories are likely to produce low reward, and properties of the softmax function lead to these tokens sharpening the token probability distribution. Indeed, suppose we have three tokens with logits and probabilities , where token 3 is a low probability token that leads to low reward. If we sample token 3, the gradient of its logprob with respect to the logits is:
and the policy gradient update to the logits is , where is the advantage of the sampled token. Since this trajectory earns low reward, and the updates are
In these updates, is penalized, and grows more than . Sampling therefore widens the lead of the already-dominant token, sharpening the distribution and decreasing entropy. Top- sampling prevents these low probability tokens from being sampled and used as optimization targets in the first place!
This entropy-preservation effect makes top- sampling desirable in our rollouts. But naively implementing top- clearly increases the training-inference mismatch — the trainer computes probabilities as a selection from all tokens, while rollouts sample from the top- subset, so the distributions have higher divergence, leading to collapse after a small number of steps. Thus, we implement sampling distribution replay11, where we record a kept-set of tokens available for sampling at rollout time, and renormalize probabilities with those masks in the trainer. With this fix, our run’s entropy stays roughly constant over the course of training and inference-training divergence stays bounded.
Another interesting result of using top-p sampling replay is a targeting of only tokens with . Tokens with probability above the threshold have a keepset of size 1, so their renormalized probability distribution is a constant 1, and gradients are zeroed out. We found empirically that a large fraction of the tokens sampled by the model are above standard top-p thresholds, so they are excluded from the overall gradient computation. This reduces gradient noise and lets the optimization algorithm focus on the high-learning signal tokens in the trajectory.
We also find benefits from using the Muon optimizer12 and eliminating non-deterministic operations in the trainer.
Multi-cluster Training
Cognition is a fast-growing research lab entering an established landscape that is heavily compute-constrained. We aim to train trillion-parameter models, but today, large clusters with 10-100k chips on a single network fabric are a scarce resource. In contrast, smaller clusters around the world are abundant, if used together correctly.
In this setting, the structure of RL works in our favor. RL decomposes naturally across multiple clusters. Only the trainer must live on a single high-bandwidth cluster. The inference engines that generate rollouts are self-contained. They can run anywhere and need nothing but the current weights.
We invested in infrastructure that makes use of this property. Our RL training spans four datacenters across three continents, combining our own GPUs across multiple clusters with additional compute from inference providers like Fireworks. The result is that we can scale RL training far beyond what any single cluster would allow.
The central challenge in this setup is keeping all inference engines up to date with the trainer weights after each optimizer step. We want these weight updates to be fast to reduce staleness of trajectories so we can train with more aggressive learning rates.
Naively broadcasting the full model from one cluster to another would be slow and inefficient. Instead, every K gradient steps, we compute and send a compressed weight delta between the current and previous weights, reducing the size of each transfer by over 99%13.
Rather than streaming the weights directly from the trainer to every inference cluster, we use cloud object storage to maintain a single source of truth for weight versions. After the trainer uploads a new weight delta, the inference engines can be updated with almost no inference downtime. Each training run has a weight controller in each involved cluster that manages the run’s weight version lifecycle. The weight controller polls object storage for new manifests, which the trainer writes after each update. When it finds a new delta, it instructs workers to download their shards, which are then replicated across local disks using a tree broadcast. The same object storage also carries routing matrices and top-p masks from the inference engines back to the trainer.
Each inference engine prefetches the delta into CPU memory while continuing to serve trajectories. Only once the delta is fully staged does the engine briefly pause to apply it in-place. Trajectories that are in-flight can simply continue on the new weights with their KV cache intact.
With this approach, cross-continental weight updates for a 1T parameter model complete in 1–2 minutes end-to-end. This happens asynchronously and blocks neither training nor inference beyond 3–4 seconds of inference pause at update.
Fault Tolerance
At large scale, hardware failures occur continuously, and globally restarting on each failure makes long runs infeasible. Our architecture handles this differently depending on where the failure occurs — the inference engines or the trainer.
Failures on the inference side are cheap by construction. Engines are self-contained and hold no state beyond the current weights, so a dead engine costs only its in-flight sessions. We use NVIDIA Dynamo to manage the engine lifecycles and route inference: each agent sandbox has its own proxy that records tokens in and out, so if a replica goes down, we don’t lose the full trajectory, and Dynamo reroutes it to a different worker. When Dynamo reschedules the replica on healthy nodes, our weight controller loads the most recent checkpoint from object storage and replays a series of deltas from the checkpointed version.
The trainer is the one place where a failure is expensive: it’s the single tightly-coupled component, where one dead node stalls the whole cluster. To make recovery fast, each node checkpoints asynchronously to local disk every step and replicates its shards to peers, so a dead node’s state is rebuilt from replicas in seconds. If capacity is still missing, the run shrinks by whole data-parallel replicas and regrows once nodes return. Throughout this process, the rollout pipeline remains warm. After the trainer restarts, a buffer policy selects which accumulated rollouts to use and prevents bias from any imbalance in training-inference throughput during the interruption.
Intelligent Self-Compaction for Long-Horizon Tasks
From the start, we built Devin for completing asynchronous, long-running tasks. SWE-1.7 is trained directly in the Devin harness, so naturally we want to train our own model on longer horizon tasks. This introduces two challenges. First, rollouts can extend far beyond the raw context window. Second, as shown by DeepSeek R114, RL on reasoning tasks tends to produce progressively longer responses, but we want the model to be efficient in its reasoning and only elaborate on difficult tasks.
We address these issues with training for self-compaction and an alternating length penalty.
- When an agent approaches the context limit, we ask it to summarize its working state, and we resume it from its self-authored summary. During training, the model simultaneously learns (1) to write more informative, succinct summaries, and (2) to better work from and leverage such summaries. We first introduced a version of this approach in Kevin15, where we explored it for kernel optimization tasks. With self-compaction, our rollouts during the SWE-1.7 training run reach up to six hours in duration.
- Rather than applying a length penalty uniformly throughout training, we use an alternating strategy16. In unconstrained phases, the model optimizes only for task success. In budget phases, we penalize solutions that exceed a certain budget of our weighted cost function that includes tokens, turns and total time spent in tool calls. With this structure, response length tends to compress on tasks within the model’s ability, while long-horizon behavior on hard tasks is preserved.
Data Quality
Data is the core determining factor in what capabilities and skills our model learns. As such, we ensured that the data we trained on was calibrated and sufficiently difficult, and disincentivized undesirable behaviors to keep the model well-aligned. We focused most on the following aspects:
- Verifier quality: A task’s verifier can be wrong in two directions: accepting incorrect solutions (false positives) or rejecting valid ones (false negatives). We devised extensive quality-assurance pipelines to minimize observations of false positives and false negatives in our training.
- Difficulty: On tasks where the model always solves or always fails, we don’t observe any meaningful learning signal. Instead, we curated training data that the model only solves a low fraction of the time, which generates real learning signal while at the same time pushes model intelligence.
- Cheating detection and prevention: We employed a variety of defenses against different forms of cheating. For instance, we network-restricted our sandboxes and stripped them of git history and reference artifacts. We also isolated the grading path from the agent itself. In addition, we employed programmatic checks to catch known exploit signatures. Finally, to ensure proper incentives, we assigned reward 0 to trajectories with any instance of cheating attempts, regardless of whether they succeeded.
Results: Model Behaviors
Due to extensive RL, SWE-1.7 exhibits noticeably different behavior from Kimi K2.7 Code, its base model. Firstly, it is significantly more aligned and trustworthy than K2.7 or other frontier open-source models. We expand on this extensively in our companion blog post, Measuring the Trustworthiness of Open-Source-Derived Models.
One behavioral difference we noticed in SWE-1.7 is condensed chain-of-thought. Compared to Kimi-K2.7-Code, SWE-1.7’s first chain-of-thought has a much lower function-word ratio (fraction of words that serve as grammatical “glue”) and nearly half the average number of words per sentence. We think this was influenced directly by the budget phases in our alternating length penalty. We’ve included a couple of examples of condensed chain-of-thought in the dropdown below.
The other major behavioral difference we observed is that SWE-1.7 explores the codebase much more thoroughly before acting, as you can see in the number of tool calls, file reads, and searches the model executes.
This shows up most clearly in bug-fixes. A bug report typically describes one primary symptom, but the underlying issue often affects a larger surface area. SWE-1.7 is much more likely to investigate the root cause of the bug and consider edge cases, hypotheticals, adversarial inputs, and beyond-the-ask requirements than Kimi-K2.7-Code. Through its enhanced codebase exploration, SWE-1.7 also does a much better job understanding the exact design decisions that need to be made. In addition, we’ve observed that SWE-1.7 tends to settle ambiguous semantics by experimenting and probing, for example by writing small Python scripts, rather than guessing.
We believe these behaviors arise directly from the extensive quality-assurance measures we took to strip out false positives and false negatives in our data, forcing our model to come up with more complete, end-to-end solutions. We think that SWE-1.7’s increased due-diligence directly translates to higher performance on various benchmarks. We’ve attached a couple of example trajectories in the dropdown below.
The extra thinking comes at a small cost in increased change scope. As described in FrontierCode1, a good solution modifies only the minimal set of files needed, without touching unrelated code or introducing unnecessary refactors. Since SWE-1.7 reasons more, it also does more: writing additional test cases and touching more files than the task naively requires. We’ve noticed this trend consistently in models across the industry: as reasoning increases, the scope of files that the model touches also expands. This is an axis we’re excited to improve on.
Evaluation Methodology
- All models are evaluated under their maximum reasoning effort.
- Terminal-Bench 2.117: we evaluate on our own internal evaluation framework, using Claude Code for Anthropic models, Codex for OpenAI models, and Devin CLI for other models, with timeout=4h.
- SWE-Bench Multilingual18: we use self-reported numbers when available and evaluate on Devin CLI otherwise.
- FrontierCode 1.1: see our blog post2.
References
- [1]E. Lu, B. Pan, D. Birlikci, S. Lee, R. Wang, R. Choudhury, F. Ma, TC Qin, C. Baronio, and S. Alberti, "Introducing FrontierCode," June 2026. cognition.com/blog/frontier-code
- [2]E. Lu, B. Pan, F. Ma, A. Lombardi, D. Birlikci, S. Lee, R. Wang, R. Choudhury, TC Qin, C. Baronio, J. Teo, J. H. Lee, and S. Alberti, "FrontierCode 1.1," July 7, 2026. cognition.com/blog/frontier-code-1.1
- [3]A. Piché et al., "PipelineRL: Faster On-policy Reinforcement Learning for Long Sequence Generation," arXiv:2509.19128, 2025.
- [4]F. Yao et al., "Your Efficient RL Framework Secretly Brings You Off-Policy RL Training," 2025. fengyao.notion.site/off-policy-rl
- [5]B. Pan, C. Baronio, A. Tam, P. Marsella, M. Jain, D. Chiu, Swyx, and S. Alberti, "Introducing SWE-grep and SWE-grep-mini: RL for Multi-Turn, Fast Context Retrieval," 2025. cognition.com/blog/swe-grep
- [6]"Stabilizing MoE Reinforcement Learning by Aligning Training and Inference Routers" (Rollout Routing Replay, R3), arXiv:2510.11370, 2025.
- [7]C. Baronio, B. Pan, S. Lee, E. Lu, S. Cao, R. Choudhury, A. Zweiger, R. Wang, G. Chang, and S. Alberti, "An Early Preview of SWE-1.6 and Research Update," March 2026. cognition.com/blog/swe-1-6-preview
- [8]A. Holtzman et al., "The Curious Case of Neural Text Degeneration," arXiv:1904.09751, 2019.
- [9]G. Cui et al., "The Entropy Mechanism of Reinforcement Learning for Reasoning Language Models," arXiv:2505.22617, 2025. arxiv.org/abs/2505.22617
- [10]S. Yu et al., "DAPO: An Open-Source LLM Reinforcement Learning System at Scale," arXiv:2503.14476, 2025. arxiv.org/abs/2503.14476
- [11]DeepSeek-AI, "DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models," arXiv:2512.02556, 2025. arxiv.org/abs/2512.02556
- [12]K. Jordan et al., "Muon: An optimizer for hidden layers in neural networks," 2024. kellerjordan.github.io/posts/muon — see also J. Liu et al., "Muon is Scalable for LLM Training," arXiv:2502.16982, 2025.
- [13]Fireworks AI, "Frontier RL Is Cheaper Than You Think," 2026. fireworks.ai/blog/frontier-rl-is-cheaper-than-you-think
- [14]DeepSeek-AI, "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning," arXiv:2501.12948, 2025. arxiv.org/abs/2501.12948
- [15]C. Baronio, P. Marsella, B. Pan, and S. Alberti, "Kevin-32B: Multi-Turn RL for Writing CUDA Kernels," 2025. cognition.com/blog/kevin-32b
- [16]Kimi Team, "Kimi K2.5: Visual agentic intelligence," arXiv:2602.02276, Feb. 2026. arxiv.org/abs/2602.02276
- [17]The Terminal-Bench Team, "Terminal-Bench: A Benchmark for AI Agents in Terminal Environments," 2025. tbench.ai
- [18]J. Yang et al., "SWE-smith: Scaling Data for Software Engineering Agents," arXiv:2504.21798, 2025. arxiv.org/abs/2504.21798 (SWE-bench Multilingual: swebench.com/multilingual)