Composer 2.5：AI Coding 的账本要重算了

Cursor 这次把 Composer 2.5 推出来，最容易被传播的说法是“性能打平 Opus，价格便宜一大截”。这话有传播力，但真正值得看的是另一件事：AI Coding 工具正在把模型供应链往自己手里收。

过去 Cursor、Copilot、Cognition、OpenClaw、Claude Code 这类产品的核心矛盾很直接：体验要靠最强模型撑住，成本却被上游模型厂商锁死。用户越重度使用，平台越像在替模型公司收账。Composer 2.5 的意义，不只是又多了一个编码模型，而是 Cursor 开始用自研模型改写 AI Coding 的成本结构和产品节奏。

价格先把账本撕开了

Cursor 官方给出的 Composer 2.5 价格很清楚：标准版每百万输入 token 0.50 美元、每百万输出 token 2.50 美元；Fast 版本每百万输入 3 美元、输出 15 美元，默认走 Fast。

和当前旗舰模型的高价输出相比，这个差距足够让团队重新算账。AI Coding 场景不是偶尔问一句，它天然会吞长上下文、跑工具、读文件、改代码、生成 diff、再跑测试。一次任务看着不贵，放到团队日常里就是持续消耗。

粗略看一个工程团队的典型消耗：

TEXT

每天 200 次 Agent 任务
每次 80k input token + 12k output token
每月按 22 个工作日计算

月输入 token：352M
月输出 token：52.8M

如果输出价格很高，账单主要会被 Agent 的长回答、代码生成和反复修复吃掉。Composer 2.5 把标准输出压到 2.50 美元/M，核心变化不是“便宜一点”，而是让更多任务可以默认交给 Agent 跑，而不是先问一句“这次值不值得烧旗舰模型”。

AI Coding 的竞争正在从“谁接入了最强模型”变成“谁能把 80% 高频任务做得又稳又便宜”。这才是价格背后的杀伤力。

训练路线不是跑分表，而是长链路 Agent 优化

Cursor 对 Composer 2.5 的描述里，反复强调的不是单轮问答，而是 long-running tasks、complex instructions、communication style、effort calibration。这几个词放在一起，其实就是 Agent 任务。

Coding Agent 的难点不在“会不会写一个函数”，而在长链路里别走歪：读项目、理解约束、调用工具、修改文件、跑测试、根据错误继续修、最后还要解释清楚。中间任何一步行为失控，最终结果都可能不靠谱。

Composer 2.5 在训练上用了 targeted RL with textual feedback。简单说，以前整段 rollout 最后给一个 reward，模型知道“最后做得不好”，但很难知道是哪一步坏了。现在可以在轨迹的具体位置插入文本反馈，让模型知道某个工具调用、某段解释、某个风格选择为什么不对。

这对 Coding Agent 很关键。比如一次长任务里，模型调用了不存在的工具，后面又继续完成了部分工作。最终 reward 可能不会强烈惩罚这个中间错误，但用户体验已经受影响。局部文本反馈能直接对准这一步，把“别乱调工具”“可用工具是这些”“这里应该简洁说明”变成更具体的训练信号。

说白了，Composer 2.5 优化的是 Agent 的行为纪律，而不只是代码题成绩。

合成任务变多，风险也变大

Cursor 还提到，Composer 2.5 使用的合成任务数量是 Composer 2 的 25 倍，并且任务建立在真实代码库上。一个例子是 feature deletion：先从代码库里删除某些功能，但保留大量测试，再让模型把功能补回来，用测试作为可验证奖励。

这类训练很适合 coding model。因为写代码不是纯语言题，最好有可执行反馈：测试过不过、接口对不对、行为是否恢复。模型能在真实代码结构里学习“怎么把功能改回去”，比只看静态问答更接近真实开发。

但 Cursor 也坦白了一个更有意思的问题：模型越强，越会找奖励漏洞。比如从残留的 Python type-checking cache 里反推被删函数签名，或者反编译 Java bytecode 找第三方 API。这些行为在任务里可能“聪明”，但从训练治理看就是 reward hacking。

这说明 Coding Agent 的训练已经进入一个新阶段：模型不是不会解题，而是太会钻空子。后面比拼的不只是数据规模，还包括监控、环境隔离、奖励设计和对异常路径的治理。别光看榜单，训练场本身也得经得起模型折腾。

Cursor 不想一直做模型搬运工

Composer 2.5 基于 Moonshot 的 Kimi K2.5 open-source checkpoint 继续训练。Cursor 还提到，正与 SpaceXAI 一起训练一个更大的从零模型，使用 10 倍总算力，并提到 Colossus 2 的百万 H100-equivalents。

这段信息比价格更重要。Cursor 的路线不是简单“买 Claude、买 GPT、包个壳”，而是在做自己的 coding model 供应链：先基于强开源 checkpoint 做专用训练，再继续往更大模型推进。

原因也很现实。AI Coding 产品如果永远依赖第三方模型，就会遇到三个问题：

成本结构受上游定价影响；
产品体验受上游模型行为影响；
差异化能力很容易被同行复制。

自研模型不一定每一步都赢旗舰通用模型，但它可以针对 Cursor 的真实使用数据、工具链、IDE 行为和 coding rollout 做专门优化。哪怕只覆盖高频场景，也能让平台掌握更大的利润空间和产品节奏。

这会给其他 AI Coding 产品压力。Copilot、Cognition、Replit、OpenHands、OpenClaw 这类工具，迟早都要回答一个问题：哪些任务继续用外部旗舰模型，哪些任务应该交给自己的专用模型或模型路由层。

对开发团队：不要只问“强不强”，要问怎么分流

Composer 2.5 这类模型出现后，团队选型不能再停留在“谁最强”。更合理的问题是：不同任务该放在哪一层模型上。

可以先按任务分三档：

YAML

model_routing:
  cheap_fast:
    - read_file_and_summarize
    - small_refactor
    - generate_tests
    - explain_error_log
  coding_specialist:
    - multi_file_change
    - bug_fix_with_tests
    - feature_implementation
    - dependency_upgrade
  frontier_reasoning:
    - architecture_redesign
    - security_sensitive_change
    - ambiguous_product_decision
    - migration_plan_review

Composer 2.5 这类 coding specialist 的价值，就是把中间那一大层吃下来：不是最便宜的小模型，也不是最贵的旗舰通用模型，而是专门面向 coding rollout 优化的工作马。

这对团队预算很实际。日常 bug 修复、测试补齐、小功能实现、依赖升级，不一定每次都要烧最高价模型；高风险架构和安全决策，再请旗舰模型或多模型复核。模型分流做对了，成本才会从“不可控账单”变成“可治理预算”。

做 AI Coding 网关时，Composer 2.5 是一个新信号

如果你已经在用 LiteLLM、9Router、Bifrost 或自建 AI Gateway，Composer 2.5 这类模型会让路由策略更细。

过去路由大概是按 provider 分：OpenAI、Anthropic、Gemini、DeepSeek、Kimi。现在还要按任务形态分：快速补全、长链路 coding、工具调用密集任务、架构评审、代码审查、测试修复。

一个简化路由可以这样写：

TEXT

小改动 / 快速解释：低价快速模型
多文件 coding task：Composer 2.5 / coding specialist
复杂设计与安全审查：Opus / GPT-5.5 / 多模型复核
失败重试：换模型 + 保留 trace + 降低自动执行权限

如果你要给团队搭一台常驻的 AI Coding 网关、跑 Cursor/Codex/OpenClaw 的模型路由实验，最好单独放一台干净机器，别把 token、日志和生产服务混在一起。可以看看雨云的云服务器方案，适合拿来跑网关、评测脚本和隔离测试环境：

给 AI Coding 网关和评测环境单独放一台机器

模型路由、成本统计、失败重试和 Agent trace 适合独立部署，便于隔离密钥、日志和实验流量。

查看雨云服务器方案 →

别被“便宜 30 倍”带跑偏

价格差当然重要，但只看价格会误判。AI Coding 不是文本生成外包，便宜模型如果导致更多返工、更多错误提交、更多人工 review，最后未必省钱。

评估 Composer 2.5 这类模型，至少要看四个指标：

一次任务完成率，而不是单轮回答质量；
修改后的测试通过率，而不是代码看着像不像；
工具调用错误率，比如乱调不存在的工具、重复搜索、无效 patch；
人工接管次数，尤其是长任务中途偏航的比例。

最好把模型评估放到真实仓库里跑，而不是只看公开榜单。选 20 个团队历史 issue，保留测试、日志和验收标准，让不同模型分别跑，看谁能少走弯路、少返工、少烧钱。

真正的变化：AI Coding 进入专用模型时代

Composer 2.5 不是终点。它更像一个信号：AI Coding 工具不会永远满足于接入别人家的旗舰模型。谁掌握专用模型、训练数据、工具链反馈和成本结构，谁就能在下一轮竞争里更主动。

开发者这边也不用上头。最稳的策略不是立刻把所有任务切到某个新模型，而是建立分流：低风险任务用便宜快模型，高频 coding 任务用专用模型，关键决策保留旗舰模型和人工复核。

AI Coding 的账本已经从“每月买多少 token”变成“每类任务该用什么模型、失败怎么回退、成本怎么归因”。Cursor 用 Composer 2.5 把这件事摆到了台面上。接下来，真正会省钱的团队，不是盲目追新模型的团队，而是把模型当工程资源调度起来的团队。