为什么 Codex 的输出只有输入的 3.7%？六个工具的输入输出比实测
基于 Vibe Usage 真实聚合数据，对比六个 AI 编程工具的输出/输入 token 比例。这个被忽略的比值，其实是判断一个工具「读得多还是写得多」的最直接信号，也直接影响你的账单结构。
AI 编程工具里有个几乎没人看、但特别能说明问题的数字：输出 token 占输入 token 的比例。Codex 这个值只有 3.7%，Gemini CLI 却有 27%。同样是写代码的工具，差了七倍。这篇用 Vibe Usage 的真实聚合数据讲这个比值意味着什么。
直接给结论：这个比值越低，说明工具越「读多写少」——它花大量 token 把上下文塞给模型，模型只回一小段。这通常意味着更重的 agent 行为，也意味着你的账单几乎全压在输入上。
六个工具的输出/输入比（30 天）
| 工具 | 输出 / 输入 | 读写画像 |
|---|---|---|
| OpenCode | 1.3% | 极度读多写少 |
| Codex | 3.7% | 读多写少 |
| Claude Code | 6.4% | 偏读 |
| openclaw | 19% | 读写较均衡 |
| Hermes | 2.3% | 读多写少 |
| Gemini CLI | 27% | 写出占比最高 |
把 Codex（3.7%）和 Gemini CLI（27%）放一起看最清楚。不是 Gemini 更「啰嗦」，是 Codex 把巨量上下文反复喂进模型、每次只取一小段回复——典型的重 agent 模式。OpenCode 的 1.3% 更极端，几乎是「纯检索式」用法。
这个比值为什么值钱
因为它直接告诉你账单压在哪。输入 token 是 AI 编程账单的主体（全站输入占 93%、输出只占 6%，这个结构我们在 这期消耗月报 里拆过）。
一个工具输出/输入比只有 3.7%，意味着你想省钱，盯着「让模型少生成点」基本没用——省的是那 6% 里的零头。真正的杠杆在输入侧：少塞无关上下文、别频繁清 session 把缓存打没。方向性的方法见 真正有效的省 token 方法。
一个常见误判
很多人觉得「输出少 = 工具高效」。不一定。输出少可能是因为它把活儿干得精准，也可能是因为它把一整个仓库反复读了十遍才回你一句话——后者输入巨大，输出比自然低，但这恰恰是最烧钱的模式。
所以单看比值不够，要和总消耗一起看：Codex 既是输出比最低（3.7%）、又是总消耗最高（约 730 亿）的工具，这两个数放一起，画像就很清楚了——它不是省，是把成本全堆在输入侧。这也是为什么我一直说选工具别只看「好不好用」，要看 Claude Code vs Codex vs OpenCode 的实测消耗对比。
怎么看自己的比值
你自己的输出/输入比，是判断用法健不健康的快速体检。比值异常低且总量大，基本可以确定上下文管理有问题。
打开 Vibe Usage 看自己的输入输出结构，它把输入、输出分开统计，你自己算一下比值，对照上面这张表，就知道自己更像 Codex 那种重读模式，还是 Gemini 那种均衡模式。我自己那个比值偏低，回头一查，是某个 MCP 每轮都在往上下文里塞一大坨没用的东西——找到就删了，账单立刻轻。
我的观点很明确：输出/输入比不是用来排工具优劣的，是用来照自己用法的镜子。镜子照出来难看，改的是你怎么用，不是换工具。