Cursor「自研」Composer 2 翻车了：模型 ID 泄露，底层就是 Kimi K2.5

昨天 Cursor 发布 Composer 2 的时候，公告里写的是「自研编程模型，性能提升 39%，成本降低 90%」，评论区一片叫好。

我当时还挺激动的——终于有人在编程模型上卷起来了。结果今天早上刷到月之暗面的公开声明，人傻了。

先说结论

一句话总结：29.3 亿美元估值的 Cursor，拿开源模型套了个壳，没给署名，也没付钱。

怎么被扒出来的？

事情经过其实很简单。有开发者在使用 Composer 2 的时候，通过 API 请求抓包发现了实际的模型 ID：

kimi-k2p5-rl-0317-s515-fast

这命名也太直白了——kimi-k2p5 就是 Kimi K2.5，rl 是 Reinforcement Learning，0317 是 3 月 17 号的训练版本。

月之暗面预训练负责人杜雨伦随后发推确认：他们测试了 Composer 2 的 tokenizer，「和我们的 Kimi tokenizer 完全一致」，基本可以确定就是 Kimi K2.5 经过后训练微调的版本。

许可证问题有多严重？

Kimi K2.5 今年 1 月开源的时候用的是修改版 MIT 许可证，里面有一条关键要求：

Cursor 目前 ARR（年经常性收入）20 亿美元，2900 万月活开发者。不管怎么看都属于「显著收入 + 大量用户」的范畴。

但在 3 月 19 日的发布公告里，Cursor 只说了「先对基座模型做了继续预训练，再用强化学习优化」，全程没提 Kimi K2.5 一个字。

那 Composer 2 到底好不好用？

说实话，撇开争议不谈，Composer 2 的编程能力确实不错。但问题是——这本来就是 Kimi K2.5 的实力。

# 直接调 Kimi K2.5 API，效果基本一样
from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://api.moonshot.cn/v1"  # 月之暗面官方
)

response = client.chat.completions.create(
    model="kimi-k2.5",
    messages=[
        {"role": "system", "content": "你是一个高级编程助手"},
        {"role": "user", "content": "用 Go 写一个带限流的 HTTP 中间件，支持令牌桶算法"}
    ],
    temperature=0.3
)

print(response.choices[0].message.content)

我实际测了一下，同样的编程题目丢给 Kimi K2.5 官方 API 和 Composer 2，代码质量、风格、甚至注释习惯都高度一致。

区别在哪？价格。

Kimi K2.5 官方 API 定价：

• 输入：¥4 / 百万 tokens
• 输出：¥12 / 百万 tokens

而 Cursor Pro 每月 $20\text{，}Max\text{每月}$200。如果你主要用 Composer 2 模型，相当于给中间商付了一大笔溢价。

当然，Cursor 的价值不只是模型——IDE 集成、Tab 补全、代码库理解这些功能确实好用。但如果你只是想用一个强力编程模型，完全可以直接调 Kimi K2.5。

用 OpenAI 兼容协议调用的几种方式

Kimi K2.5 兼容 OpenAI API 格式，改个 base_url 就能用：

# 方式 1：月之暗面官方
client = OpenAI(
    api_key="moonshot-key",
    base_url="https://api.moonshot.cn/v1"
)

# 方式 2：通过聚合平台（比如 ofox.ai），一个 key 同时用 50+ 模型
client = OpenAI(
    api_key="ofox-key",
    base_url="https://api.ofox.ai/v1"
)

# 方式 3：NVIDIA 免费额度
client = OpenAI(
    api_key="nvidia-key",
    base_url="https://integrate.api.nvidia.com/v1"
)
# model 用 "moonshotai/kimi-k2.5"

我个人比较喜欢用聚合平台，因为经常需要在不同模型之间切换对比（比如 Claude 写架构、Kimi 写业务逻辑、GPT 做 Code Review），一个 key 搞定比较省心。

踩坑记录

1. Kimi K2.5 的 256K 上下文不是白给的：虽然支持 256K tokens，但实测超过 60K 之后响应速度明显下降，代码质量也开始飘。建议保持在 30K 以内。

2. temperature 别设太高：Kimi K2.5 在 temperature > 0.7 的时候容易出现「创意过剩」的问题——你让它写个 CRUD，它给你整一个 Event Sourcing 架构出来。编程场景建议 0.2-0.4。

3. 中文注释和英文注释的风格差异：如果 prompt 用中文，Kimi K2.5 倾向于写详细的中文注释；用英文则偏向简洁的英文注释。代码质量本身差不多，看团队习惯选。

4. streaming 模式下偶尔断流：调官方 API 大概有 2-3% 的概率在长代码输出时断流，加个重试逻辑就行。

小结

这件事给我的感受是：开源社区的力量真的很强大，但「开源」不等于「随便用」。

Kimi K2.5 本身是个很猛的编程模型，1 万亿参数 MoE 架构，320 亿激活参数，SWE-Bench 76.8%——在开源模型里基本是天花板级别。Cursor 看上它不奇怪，但吃相不能太难看。

对开发者来说，好消息是你现在可以直接用 Kimi K2.5 的 API，不用通过 Cursor 当中间商。坏消息是，这波信任危机之后，以后看到「自研模型」三个字，怕是得先抓个包验证一下了。