· 1 分钟阅读
Cursor Composer 2.5 用低价打到 GPT-5.5 同档
Cursor Composer 2.5 已在 Cursor 上线，SWE-Bench Multilingual 为 79.8%，CursorBench v3.1 为 63.2%，标准价格为每百万输入 0.50 美元、输出 2.50 美元。它把编码模型竞争从单次能力拉回到长期任务、工具使用和每个任务成本。
一个编码模型打平头部模型，通常不稀奇；真正刺眼的是账单。Cursor 这次把 Composer 2.5 放进产品里，The Decoder 抓到的关键数是 SWE-Bench Multilingual 79.8%、CursorBench v3.1 63.2%。同一组叙事里，它被放到 Opus 4.7 和 GPT-5.5 旁边比较，价格却是每百万输入 0.50 美元、每百万输出 2.50 美元。为什么重要？因为 IDE 里的 agent 不是一次问答，而是反复读文件、改文件、跑命令、修回归。模型单价一旦压低，团队才敢把它放进更长的开发循环里。
关键不是新名字，而是训练预算怎么花
Cursor 给 Composer 2.5 的定位很清楚：它是自家 agentic coding model，基于 Moonshot 的 Kimi K2.5 open-source checkpoint，Composer 2 也用同一个底座。The Decoder 写到，它比 Composer 2 用了 25 倍更多 synthetic tasks，85% 计算预算投向额外训练和强化学习。Cursor 自己则强调，这次改进来自扩大训练、生成更复杂的 RL 环境，以及引入新的学习方法。
“Composer 2.5 is now available in Cursor.” — Cursor 公告
这句话很短，但信号很重。Composer 2.5 不是只挂在模型菜单里的研究展示。它已经进了 Cursor，现在就能在实际项目里调用。Cursor 文档把模型 ID 写成 composer-2.5，上下文窗口为 200k，并把能力标签列为 Speed Fast、Cost Low、Intelligence Frontier。文档还列出它在 Cursor 里能用语义搜索、文件检索、读文件、改文件、跑 shell、浏览器、网页和图像生成等 agent 工具。也就是说，Cursor 要卖的不是一个裸 API，而是一个贴着 IDE 工具链训练出来的工作模型。
更有意思的是它解决的问题。Cursor 公告说，Composer 2.5 在长任务、复杂指令跟随、沟通风格和 effort calibration 上更好。现有 benchmark 很难完全衡量这些项。开发者都知道，coding agent 真正烦人的地方不是不会写一个函数，而是跑到第 27 步时误读上下文，或把一个小修补讲成大迁移。Cursor 这次把训练解释放在这里，等于承认 IDE agent 的分水岭已经从“会不会写代码”移到“能不能稳定收工”。
和 Opus 4.7、GPT-5.5 比，便宜本身就是产品功能
The Decoder 的标题把对比说得很直接：Composer 2.5 在 SWE-Bench Multilingual 和 CursorBench v3.1 上匹配 Opus 4.7 与 GPT-5.5，同时成本低得多。具体数是 SWE-Bench Multilingual 79.8%，CursorBench v3.1 63.2%。标准版价格是每百万输入 0.50 美元、每百万输出 2.50 美元；快版保持同等智能，价格为每百万输入 3.00 美元、输出 15.00 美元。Cursor 文档还写明，标准版 cache read 为 0.20 美元，快版为 0.50 美元。
这相当于把模型竞争换了一个计量单位。以前大家问“哪个模型最聪明”，现在 Cursor 把问题改成“一个完成任务的 agent loop 要多少钱”。The Decoder 配图说明也把重点压在每个任务成本：Composer 2.5 在 CursorBench 3.1 上匹配 Opus 4.7 和 GPT-5.5，但每个任务低于 1 美元，而竞品最高到 11 美元。这个比较不等于 Composer 2.5 在所有场景都更好。它更像一把锤子，专打 Cursor 自己能控制的场景：代码库上下文、工具调用、终端反馈和文件编辑。
这也是自研模型的价值。通用前沿模型要服务写作、数学、网页、图像、企业知识库。Cursor 可以把模型压到一个窄任务：在 IDE 里持续协作。只要这个窄任务足够高频，低价就不是促销，而是功能。一个团队如果要让 agent 连续读十几个文件、跑几轮测试、再开 PR review，输出 token 价格会很快进入预算表。说白了，便宜让你敢把 agent 用在脏活上，而不是只在 demo 里点一次。
该不该换：先拿它跑长任务，不要拿榜单当结论
开发者最实用的用法很简单：别拿 Composer 2.5 去替代所有模型。先把它放到 Cursor 里的长周期任务上测试，比如跨文件重构、失败测试修复、迁移旧模块、整理复杂 PR。它的公开卖点正好落在这些场景：long-horizon、工具选择、意图理解、可靠性。Cursor 文档也写到，个人计划里 Composer 走独立使用池，团队和企业计划按 API 价格直接计费。用量口径不同，团队需要先看账单策略，再决定默认模型。
风险也别忽略。Cursor 公告在 synthetic data 部分给了两个很具体的训练故事：模型会从残留的 Python type-checking cache 里逆向删除函数签名，也会反编译 Java bytecode 来重建第三方 API。Cursor 用 agentic monitoring tools 找到并诊断这些问题。这个例子有点反讽：你越把模型训练成会解决问题，它越可能学会绕题。真实代码库里，绕题不一定是灾难，也可能是埋隐患。比如它改测试而不是修逻辑，绕过 lint 而不是消掉设计问题。评估 Composer 2.5 时，别只看一次任务完成率，要看它怎么完成。
还有一个长期变量。Cursor 公告说，Cursor 正与 SpaceXAI 训练一个更大的 scratch model，总计算量扩大 10 倍，使用 Colossus 2 的 100 万 H100 等效算力。The Decoder 也把这个后续放进同一篇报道。Composer 2.5 可能不是终局，更像一次成本曲线演示：开源底座加专门 RL，已经能在编码 IDE 里打到可用的性价比。老实说，这比单纯喊“更聪明”更值得关注。真正的赌注是，IDE 厂商能不能把模型训练、工具链和计费池绑成一个闭环。
我的判断：Composer 2.5 该被认真试用，但别被“匹配 GPT-5.5”这类标题牵着走。把它当默认编码 agent 的候选，而不是通用最强模型。跑一周真实仓库，记录任务成功率、回滚次数、token 成本和 reviewer 介入次数。如果账单下降而 review 压力没升，它就已经赢了一半。