最近在 LINUX DO 看到一个很有意思的帖子:有人把不同 AI Coding Plan 统一换算成“每 1 亿 Token 大概要花多少人民币”,并假设 99% 输入、1% 输出、95% 输入缓存命中率 来做横向比较。
这个思路很实用,因为它终于把“月费多少钱”转换成了更接近开发者实际消耗的指标。但如果直接把榜单当成结论,又很容易掉进另一个坑:
AI Coding 的成本并不是一个固定的“每亿 Token 单价”,而是由输入、缓存输入、输出三种 Token 的比例共同决定。
尤其是 2026 年之后,Coding Agent 越来越依赖长上下文、仓库快照、工具调用、子代理和自动化任务,缓存命中率已经从一个“优化指标”变成了真正影响账单的核心变量。
一、社区为什么开始用“每亿 Token”比较 Coding Plan
传统订阅价格很难直接比较。
一个套餐写着 20 美元/月,另一个写着 100 元/月,看起来后者更便宜,但实际可能存在:
- 周限额不同;
- 高峰期限流策略不同;
- 不同模型消耗倍率不同;
- 缓存 Token 是否单独计价;
- 输出 Token 的价格远高于输入;
- Agent 工具调用和长任务会显著增加上下文重放;
- 套餐额度并不一定等价于公开 API 的 Token 数量。
所以把它们统一换算为“完成相同 Token 工作量需要多少钱”,至少提供了一个可以讨论的共同坐标。
LINUX DO 这次讨论里最有价值的并不是具体排名,而是楼里很快有人指出:95% 缓存命中率只适用于很特定的长对话/高复用场景,一旦缓存率降低,排名可能完全改变。
这其实就是 Coding Agent 成本分析最关键的一点。
二、Codex 已经明确进入 Token 费率时代
OpenAI 当前的 Codex 费率说明已经不再使用“平均每条消息消耗多少”作为核心计量方式,而是直接拆成三类:
| Token 类型 | GPT-5.6 Sol | GPT-5.6 Terra |
|---|---|---|
| 输入 Token | 125 credits / 1M | 62.5 credits / 1M |
| 缓存输入 Token | 12.5 credits / 1M | 6.25 credits / 1M |
| 输出 Token | 750 credits / 1M | 375 credits / 1M |
OpenAI 在现行 Codex Rate Card 中说明,这套基于 Token 的费率已经覆盖大多数 Plus、Pro、Business 和 Enterprise 等套餐;2026 年 4 月起,Codex 的主要计量逻辑也从“按消息估算”转向了输入、缓存输入与输出 Token 的直接映射。
最直观的结论是:
同一个模型里,输出 Token 的 credit 消耗可能是普通输入的 6 倍,而缓存输入只有普通输入的约 1/10。
因此,“我每天用了多少 Token”这个数字本身其实不够。
你真正需要知道的是:
总成本 ≈ 普通输入 × 输入单价 + 缓存输入 × 缓存单价 + 输出 × 输出单价三、为什么 95% Cache Hit 会让数字看起来特别漂亮
假设一次 Coding Agent 工作总共消耗 100M Token,其中:
- 99M 是输入;
- 1M 是输出;
- 输入里的 95% 可以命中缓存。
那么 99M 输入中真正按“完整输入价格”计算的只有约 4.95M,剩余约 94.05M 都走便宜得多的缓存费率。
这会让平均 Token 成本被大幅拉低。
但现实中的项目未必一直处在这种理想状态。
场景 A:长期维护同一个仓库
如果 Agent 每次都反复读取类似的:
- AGENTS.md;
- package.json;
- 同一批核心源码;
- 系统提示;
- 固定工具定义;
- 近期会话上下文;
那么高缓存命中率是有可能的。
这种工作流对 Prompt Cache 非常友好。
场景 B:每天切不同仓库
如果你不断在多个项目之间跳转:
前端项目 → Python 后端 → Rust 工具 → 新仓库 → 临时脚本上下文复用下降,普通输入占比就会增加。
此时用“95% 缓存”估算,很可能严重低估成本。
场景 C:大量 Reviewer / Subagent 并行
多 Agent 并不天然省 Token。
如果主 Agent 把完整仓库上下文复制给 5 个 Subagent,而每个代理又重新读取一遍资料,那么“看上去是并行提效”,底层却可能产生大量重复输入。
真正高效的方式应该是:
主 Agent 只给子代理完成任务所需的最小上下文,并让结果以结构化摘要返回。
这也是为什么 Harness Engineering 和 Context Engineering 现在越来越重要。
四、输出比例比很多人想象中更危险
Coding Agent 的输出并不只是最终回复。
可能还包括:
- 大段 diff;
- 测试分析;
- 编译错误解释;
- 子代理报告;
- 长 Chain-of-Thought 对应的计费推理输出(具体取决于产品计量方式);
- 多轮代码重写;
- Reviewer 对每个文件逐条点评。
如果一个工作流从“99% 输入 + 1% 输出”变成“90% 输入 + 10% 输出”,由于输出单价通常明显更高,最终成本并不会只增加 9%。
这也是为什么我不建议简单用一个固定的“元/亿 Token”去判断套餐值不值。
五、真正值得做的是一个三变量成本模型
比排行榜更实用的方式,是给自己记录三个参数:
I = 普通输入比例C = 缓存输入比例O = 输出比例
I + C + O = 100%然后分别代入对应模型的费率。
例如可以给自己的工作流建立三套 Profile:
| Profile | 普通输入 | 缓存输入 | 输出 | 典型场景 |
|---|---|---|---|---|
| 高缓存维护 | 5% | 94% | 1% | 长期维护同一仓库 |
| 普通开发 | 25% | 70% | 5% | 多文件开发 + 调试 |
| 重输出 Agent | 35% | 50% | 15% | 多 Agent、长报告、复杂 Review |
再拿不同 Coding Plan 做比较,结果会比单一排行榜可靠得多。
六、怎么主动提高缓存命中率
如果你的服务端支持 Prompt Cache,可以从工程侧主动优化。
1. 稳定 Prompt 前缀
系统提示、工具定义、项目规则不要每轮随机重排。
相同前缀越稳定,越容易复用缓存。
2. 把稳定规则和动态任务分开
例如:
稳定区:- 项目结构- AGENTS.md- 编码规范- 工具声明
动态区:- 当前 Issue- 当前 diff- 本轮测试日志不要每次把整个 Prompt 重新拼成完全不同的顺序。
3. 控制无意义的上下文膨胀
自动化 Agent 很容易出现:
读取文件 → 总结 → 再读取 → 再总结 → 把总结重新喂给另一个 Agent这会制造大量“看起来有工作、实际上重复”的 Token。
4. 给 Subagent 最小权限、最小上下文
不要默认把完整父会话复制过去。
让 Explorer 只负责搜索,让 Reviewer 只看 diff,让 Verifier 只接收验收目标和测试结果,通常会比“所有 Agent 都知道一切”便宜得多,也更稳定。
七、Coding Plan 到底该怎么选
我的判断是,2026 年选 AI Coding 服务,至少要同时看四个维度:
1. 模型能力
便宜但反复返工,最终可能更贵。
2. Token 结构
输入、缓存输入、输出分别怎么计费,比宣传页上的“超大额度”更重要。
3. Harness 质量
同一个模型放在不同 Agent Harness 里,工具调用成功率、上下文压缩、自动验证和重试策略可能完全不同。
4. 你的真实工作负载
一个每天维护同一 Monorepo 的开发者,和一个每天接触几十个陌生仓库的 Agent 平台,成本曲线完全不是一回事。
八、从“模型价格战”进入“上下文效率战”
过去大家比较模型,喜欢看:
输入多少钱 / 1M Token输出多少钱 / 1M Token但 Agent 时代更值得关注的是:
一次任务需要重复读取多少上下文?缓存能命中多少?为了完成任务要重试多少次?Subagent 会复制多少无关信息?最终真正通过测试需要多少轮?所以我更愿意把未来 AI Coding 的性价比理解成:
模型能力 × Harness 效率 × 缓存复用率 ÷ 完成任务的总 Token 成本。
这比“谁每亿 Token 最便宜”更接近真实开发。
社区排行榜非常适合作为第一步,但下一步应该是让成本模型真正进入自己的 Coding Agent 工作流:记录 Cache Hit、输入输出比例、失败重试和任务完成率。
等这些指标都能被量化以后,我们比较的才不只是“哪个套餐便宜”,而是:
哪个系统能用最少的有效 Token,把代码真正做对。
参考资料
- LINUX DO:各家 Plan 每 1 亿 Token 消耗 RMB(2026-08-14)
https://linux.do/t/topic/2756196 - OpenAI:Codex Rate Card(现行 Token-based pricing)
https://help.openai.com/en/articles/20001106 - OpenAI 中文帮助中心:Codex 费率表
https://help.openai.com/zh-hans-cn/articles/20001106 - 智谱 AI:GLM Coding Plan 套餐概览
https://docs.bigmodel.cn/cn/coding-plan/overview
如果这篇文章对你有帮助,欢迎分享给更多人!
部分信息可能已经过时