Reddit 社区：Kimi K2.7 Code 与 K2.6/K2.5 的选型边界

测试环境

• 文章作者主动澄清：这是基于 Kimi/Moonshot 官方页面的文档拆解，不是 hands-on benchmark。

• 比较对象：K2.7 Code、K2.6、K2.5 与 Moonshot V1；没有统一任务集和运行日志。

输入/配置

• 作者的建议是：严肃仓库工作、长上下文代码、调试和 Agent 编码优先尝试 K2.7 Code；通用 Agent/多模态选 K2.6；预算敏感的普通任务选 K2.5。

• 文章还建议重复上下文启用缓存，并保持 prompt/output 紧凑，因为输出 token 更贵。

结果数据

• 文中记录的官方 API 价格：K2.7 Code 缓存输入/未命中输入/输出为 $0.19/$0.95/$4.00 每百万 token；K2.6 为 $0.16/$0.95/$4.00；K2.5 为 $0.10/$0.60/$3.00。

• 作者没有提供模型运行分数，也明确表示希望收集真实日常使用反馈。

结论

这篇帖子可复用的价值是建立模型分工假设，而不是证明 K2.7 Code 在现实任务中必胜：编码专用模型承担仓库任务，K2.6 处理泛用多模态 Agent，K2.5 负责低成本普通工作，并用缓存控制重复上下文成本。

局限

• 全文是官方文档的二次整理；价格和能力描述应回看 Kimi 原文。

• “K2.7 Code 更适合完整仓库”是选型建议，没有实测通过率、延迟或错误样本。

• 不能把“输出 token 更贵”解释为所有 provider 的统一账单规则。

复现步骤

1. 选择同一个 brownfield 仓库，定义修 bug、跨文件改造、文档总结三类任务。

2. 按帖子建议分别路由 K2.7 Code、K2.6、K2.5，记录缓存命中、输出 token、任务完成和人工修订量。

3. 对 K2.7 Code 保留 thinking 与工具上下文，比较关闭或错误配置时的接口失败。

4. 用至少三次重复运行验证模型分工是否稳定。

原始证据与数据

• 作者把文章定位为“docs-based breakdown”，并列出 K2.7 Code 的编码专用定位与三档价格。

• 文章提出的四档路由是“严重代码任务 / 通用 Agent / 预算敏感任务 / 简单文本”，属于社区假设。

来源摘录或观察（仅做合规短引）

• 作者明确表示“looking for real user feedback”，因此本文不把其选型建议包装成 benchmark。