Composer 2.5：基准测试、定价与对比

Cursor 于 2026 年 5 月 18 日发布了 Composer 2.5，距 3 月份发布的 Composer 2 仅约两个月。版本间隔之短，体现了 Cursor 对自家模型线更新的速度。

Cursor 报告称，Composer 2.5 在多项编码基准上接近 Claude Opus 4.7 和 GPT-5.5。其 Token 价格也低于这些前沿模型。训练方式亦有变化：更多合成任务、更难的训练环境，以及一种在长时编码会话中针对具体错误给出反馈的方法。

本文不只把 Composer 2.5 视为一次基准更新。我将介绍它是什么、有哪些变化、基准表现如何、价格与前沿模型的对比，以及它在编码工作流中的定位。同时也会谈到其局限性——在把分数当作全部之前，有些点值得先了解。

关于本次对比中的其他模型，可参阅我们对 Claude Opus 4.7 和 GPT-5.5 的指南。

什么是 Cursor 的 Composer 2.5 模型？

Composer 2.5 是 Cursor 的 Composer 系列中最新的模型，面向在 Cursor IDE 内进行编码工作。它延续了 Composer 1、Composer 1.5 和 Composer 2 的演进。

Composer 从发布到 2.5 的时间线。图片作者自制。

这不是通用聊天机器人。Composer 2.5 针对跨文件编辑、终端命令、工具使用以及更长的编码会话进行训练。它的训练目标与评测聚焦于软件工程任务。

发布文章称，该模型在编码任务上的得分高于 Composer 2，并且在更长会话中的行为也不相同。它现在是 Cursor 模型选择器中的默认选项，但 Composer 2 仍可使用。它也仅在 Cursor 内运行：没有公共 API，没有 Hugging Face 模型卡，也无法通过其他提供方网关访问。

Composer 2.5 有哪些变化

Composer 2.5 的变化主要分为两类：编码任务表现与协作行为。前者更易量化，后者更偏质化描述，因此有必要区分 Cursor 能用数据展示的部分与更多依赖描述与体验的部分。

更长任务的表现

Composer 2.5 针对更长的编码会话：模型需要读取文件、运行终端命令、修复错误并反复迭代。这很重要，因为真实开发很少能在一个提示与一次回复内完成。

Cursor 在更难的 强化学习 环境中对该模型进行了训练。训练期间按阶段生成任务，难度随时间提升。

指令遵循与协作

发布说明还提到更可靠的指令遵循。其强调“投入校准”：模型应在困难任务上投入更多算力，避免在简单任务上过度思考。

但这里有个注意点。Cursor 指出这些行为变化“难以被现有基准很好地捕捉”。因此，这部分主要基于 Cursor 自身评估与早期用户反馈，而非公开分数。

更困难的 RL 环境

发布文章将训练变化描述为“扩大训练规模、生成更复杂的 RL 环境，并引入新的学习方法”。训练中使用的合成任务数量是 Composer 2 的 25 倍。

Cursor 如何训练 Composer 2.5

这些训练细节解释了在未更换底层架构的情况下，模型为何发生变化。Composer 2.5 与 Composer 2 使用相同的基础，但基础训练之后的工作不同。并非所有基础设施细节对读者都同等重要，但有些部分有助于理解基准分数的变化。

基于 Kimi K2.5 构建

Composer 2.5 与 Composer 2 使用相同的开源检查点：Moonshot AI 的 Kimi K2.5。Cursor 在发布文中直接指出了这一点，这很重要，因为 Composer 2 的基础模型曾引发争论。

Kimi K2.5 采用专家混合（Mixture of Experts）架构。Cursor 在其之上进行持续预训练与强化学习，并称最终模型约有 85% 的总算力投入来自基础训练之后的自有工作。

带文本反馈的针对性 RL

这是 Composer 2.5 的主要技术变化。标准 RL 会在长序列末尾给出单一奖励信号。在长时编码会话中，最终奖励可能过于嘈杂，难以指示模型到底哪里出错。

教师与学生共享一个回合。图片作者自制。

Cursor 的方法是在模型做出错误决策的点插入一段简短文字提示。例如，当模型调用了不存在的工具时，训练过程可以插入包含正确定义的工具清单作为提醒。带提示的版本充当“教师”，原始模型作为“学生”。随后通过蒸馏损失，仅在该回合将学生的行为向教师靠拢。

结果是更加针对性的训练：可以纠正单个错误，而不是把一整个长回放笼统地判定为对或错。Cursor 在 Composer 2.5 的训练中，将该方法应用于编码风格、工具使用以及模型交流等方面。

更大规模的合成数据

Composer 2.5 使用的合成任务数量是 Composer 2 的 25 倍。这些任务基于真实代码库，而非玩具示例。

Cursor 描述的一种做法是功能删除。一个代理从真实代码库和大型测试套件出发，删除部分代码与文件，同时保持项目其余部分可用。合成任务是重新实现被删除的功能，测试则提供可验证的奖励信号。

大规模合成训练也带来风险。Cursor 记录了 Composer 2.5 找到捷径的情况，包括从 Python 类型检查缓存中恢复被删除的信息，以及反编译 Java 字节码以重建外部 API。公司表示通过监控工具捕捉到了这些现象，但也承认在这种规模上进行训练需要“更加谨慎”。

基础设施变更

在基础设施方面，Cursor 在持续预训练中使用了 Sharded Muon 与双网格 HSDP。这些变化降低了在大型 GPU 集群上训练的部分成本与时间。

Composer 2.5 基准结果：Terminal-Bench、SWE-Bench 与 CursorBench

基准测试很有用，但并不展示全貌。我会把它们视为对比的起点，而非对日常使用体验的最终判定。

Cursor 在三个基准上评估了 Composer 2.5：

SWE-Bench Multilingual 测试模型是否能在多种编程语言的真实 GitHub 问题上给出解决方案。每个任务向模型提供一个仓库与问题陈述，然后检查补丁是否通过相应测试。

Terminal-Bench 2.0 衡量 AI 代理在真实终端工作流中的操作能力：检查文件、运行命令、调试失败，并通过多步完成任务。

CursorBench v3.1 是 Cursor 的私有内部基准。它基于真实的 Cursor 会话，从含糊的、多文件任务中评估代理，包括代码库理解、缺陷发现、规划与代码评审。局限在于 CursorBench 无法被外部研究者核验或复现，且分数应在相同评测版本内比较。

在过度解读这些数字之前，有一条重要注意。跨模型的基准对比并不总是完全可比。不同的评测设置与投入强度会影响分数，且 Cursor 指出 Opus 4.7 与 GPT-5.5 在公开评测中使用了自报告分数。请将这些结果视为方向性对比，而非在完全相同条件下的直接测试。

后续来自 Artificial Analysis 的外部基准也给出了相近的方向，尽管其使用了不同的基准组合。Composer 2.5 在 Artificial Analysis Coding Agent Index 上得分为 62，落后于最大投入的 Claude Opus 4.7（66）与 xhigh 推理的 GPT-5.5（65）。

我更关注成本差距：Artificial Analysis 估算 Composer 2.5 的 Standard 为每个任务 $0.07、Fast 为 $0.44，而 Opus 4.7 max 为 $4.10、GPT-5.5 xhigh 为 $4.82。

Composer 2.5 vs. Composer 2 vs. Composer 1.5：分数如何对比

Composer 家族在短时间内发布了三个版本。Composer 1.5 于 2026 年 2 月发布，Composer 2 于 3 月发布，Composer 2.5 于 5 月发布。每一版都在训练方法上有所不同。

Composer 2.5 对比 Composer 2

从 2 到 2.5 的提升在 Terminal-Bench 2.0 上最明显：分数从 61.7% 提升到 69.3%；在 SWE-Bench Multilingual 上从 73.7% 提升到 79.8%。CursorBench 的增幅较小，且评测版本从 v3 变为 v3.1，因此该对比不那么直接。

更大的区别在训练流水线。Composer 2 在 Kimi K2.5 上引入了持续预训练。Composer 2.5 保持该基础，并加入了针对性文本反馈、25 倍的合成任务与基础设施改动。Standard 价格保持不变。

Composer 2.5 对比 Composer 1.5

Composer 1.5 在与 Composer 1 相同的预训练模型上，将强化学习规模再扩大 20 倍。它引入了自适应思考与自我摘要，使模型在会话较长时可以压缩自身上下文。

从 Composer 1.5 到 2.5，在各项基准上的差距都很大。价格也有所下降：Composer 1.5 的输入每百万 Token 定价为 $3.50、输出为 $17.50，大约是 Composer 2.5 Standard 的 7 倍。

实践中的变化

总体来看，模式较清晰：每代版本都在长会话与指令遵循方面改变了行为，而 Composer 2 与 2.5 降低了长时代理会话的成本。

Composer 2.5 vs. Claude Opus 4.7 vs. GPT-5.5：基准、价格与权衡

这可能是许多读者首先关心的对比。Composer 2.5 在部分编码基准上与其他模型分数接近、Token 定价低于下列前沿模型，同时存在明确的取舍。

基准对比

GPT-5.5 在 Terminal-Bench 2.0 上以 82.7% 领先，约比 Composer 2.5 高 13 个点。对于高度依赖终端操作的工作，这一差距很重要。

Claude Opus 4.7 在 SWE-Bench Multilingual 上略高于 Composer 2.5（80.5% 对 79.8%），差距不足 1 个点。在 CursorBench 上，Composer 2.5 的 63.2% 高于 Opus 4.7 的默认设置（61.6%），但低于其最大投入（64.8%）。GPT-5.5 在 xhigh 下也达到了 64.3%，默认为 59.2%。

这些模型的定位并不相同。Opus 4.7 与 GPT-5.5 是更通用的前沿模型；Composer 2.5 是仅在 Cursor 内运行的编码模型。尽管在部分编码任务上的分数接近，但产品边界不同。

定价对比

与前沿模型相比，成本差异最为明显。

Composer 2.5 Standard 的每 Token 定价约为 Opus 4.7 与 GPT-5.5 的十分之一。Fast 版本的定价也低于任一前沿模型的标准档位。

以上价格截至 2026 年 5 月有效，在据此对比前，请查看 Cursor 的模型定价、Anthropic 的 Opus 定价与 OpenAI 的 API 定价。

还有一点常被忽略：与 Composer 2 Fast 相比，Composer 2.5 Fast 的定价翻倍。Standard 价位不变，但默认是 Fast，因此升级可能仍会提高部分用户的成本。

您该选择哪种模型？

选择取决于您更看重成本、终端工作，还是更深度的规划：

• Composer 2.5 适合在 Cursor 内的日常编码，尤其是跨文件编辑、重构、调试，以及对成本敏感的代理会话。
• GPT-5.5 适合最看重终端表现的任务。
• Claude Opus 4.7 适合需要细致推理、架构规划或 100 万 Token 上下文窗口的任务。

我会从数字中得出这样的结论：Composer 2.5 覆盖常规编码工作，而前沿模型在更广泛的推理或更高的终端分数方面仍有用武之地。

Composer 2.5 Standard 与 Fast：速度、价格及使用场景

与 Composer 2 一样，Cursor 将 Composer 2.5 以两个变体发布。根据 Cursor 的说法，两者共享相同的底层智能。差异主要在响应速度与成本。

Cursor 模型选择器（Composer 已选中）。图片作者自制。

Fast 为默认选项，输入每百万 Token $3.00、输出每百万 Token $15.00。它适用于对时延敏感的交互式会话。Standard 分别为 $0.50 与 $2.50，更适合后台任务或不那么依赖即时反馈的长时代理循环。

Composer 2.5 用量计入 Cursor 的“Auto + Composer”用量池，与用于 Claude 与 GPT 等外部模型的 API 用量池分开。Cursor 还在发布后一周提供了双倍用量。

Composer 2.5 的局限与注意点

注意点主要在于访问方式、基准测试与训练风险。这些并不使 Composer 2.5 显得特殊，但会影响我们对 Cursor 相关主张的信任权重。

仅可在 Cursor 中使用。 如前所述，Composer 2.5 没有公共 API。若您的工作流依赖从脚本或流水线调用模型，Composer 2.5 并不适用。

CursorBench 非独立。 如基准部分所述，CursorBench v3.1 为 Cursor 内部基准。其方法论未完全公开，外部研究者也无法复现其任务。

基准设置的可变性。 Cursor 图表中前沿模型的分数并非在相同方式下测得。请将这些对比视为方向性而非定论。

训练过程中的奖励黑客。 Cursor 披露了模型在合成任务中通过投机取巧取胜的案例，而非按常规解题。这是该规模 RL 的内在风险，即便监控能捕捉到明显情况。

投入校准尚未验证。 Cursor 关于沟通风格与投入校准的说法未有基准数据支撑，如前文所述，外部难以验证。

何时选择 Composer 2.5

这取决于任务类型。我更愿意把 Composer 2.5 看作面向已在 Cursor 内工作的用户的编码模型，而不是通用的模型选择。

如果您大部分时间都在 Cursor 内编码且关注 Token 成本，Composer 2.5 Standard 是该系列中价格最低的选择，适用于上述编辑、重构、调试与长会话等工作。

如果更在意响应速度，Composer 2.5 Fast 是默认选项。

如果任务需要更广泛的推理、更大的上下文窗口，或在特定领域拥有更高的基准分数，Claude Opus 4.7 或 GPT-5.5 可能更合适。

可以这样理解：Composer 2.5 处理上述常规编码工作，而前沿模型适合需要更广泛推理或更高终端分数的任务。这样更贴近实际，而非在所有情境下推荐单一模型。

结语

Composer 2.5 容易被当作“基准测试”的故事来阅读，但我认为更有价值的是其发展方向。Cursor 不只是把前沿模型装进编辑器，而是在围绕其代理已在做的工作来打造模型线：跨文件编辑、终端步骤、更长会话与从错误中恢复。

如前所述，权衡在于 Composer 2.5 的刻意“窄化”。它并不能替代 Claude Opus 4.7 或 GPT-5.5 作为通用模型；如果您需要在 Cursor 之外的 API，它也帮不上忙。但在 Cursor 内部，这种聚焦正是意义所在。相较前沿模型，它运行成本更低，针对编码任务进行调优，并贴近这些任务发生的产品层。

接下来要看的，是 Cursor 想掌握多少环节。公司称正与 SpaceXAI 合作，从零开始训练一个更大的模型，使用 10 倍的总算力与 Colossus 2 基础设施。尚无发布时间，因此可供分析的内容不多。但整体方向已相当明确：Cursor 正从“善用模型”走向“更深入自建模型栈”。