编码工具实测:同模型也有不同令牌开销
作者报告了三款编码 CLI 的 44 次运行,涵盖不同 MCP 工具数量的启动测试及小游戏生成,并用无头浏览器检查游戏。相同 Opus 5.5 下两款工具报告的令牌开销差异明显,但解读时需区分缓存读取、统计口径和有限任务范围。
AI 深度解读
同一个 Claude Opus 5.5,放进不同的编程 CLI,消耗的 token 能差多少?作者做了 44 次运行:在同一项小游戏任务中,Antigravity CLI 报告的输入 token 比 Claude Code 少 68% 至 88%,完成时间也短了 27%。
这组测试值得看的地方,是它把「模型能力」和「工具包装」拆开了一点:系统指令、工具定义、缓存统计,都可能影响你看到的消耗。但样本只有一台机器、一天、一道题,省 token 也不能直接等同于代码更好。
同一个模型,为什么还要比较不同 CLI
作者在 Windows 11 上,于 2026-10-22 依次运行测试,每次使用独立的空文件夹。四种配置分别是:
- Claude Code 2.1.295,搭配 Opus 5.5,使用 Max plan。
- Codex CLI 0.162,搭配 gpt-6-luna,使用 ChatGPT plan。
- Antigravity CLI 1.4.5,分别搭配 Gemini 4 Argon 和 Claude Opus 5.5,使用个人 Google 账号。
其中最有解释力的是两组 Opus 5.5:模型名称相同,外围工具不同,更容易观察 CLI 自身带来的差异。Codex 和 Gemini 的结果可以作为参照,但同时更换了模型,不能把差距全部归因于工具。
测试分两部分。启动测试只要求回复「OK」,分别挂载 0、1、10、30 个模拟 MCP 工具,每种配置跑 2 次。开发测试要求在一个 index.html 中实现打砖块游戏,包含 2 个关卡、计分和 3 条命,推理强度设为 medium,每种配置跑 3 次。
这些任务合计 44 次运行,token 数据全部取自各 CLI 的 JSON 输出。
少了 68% 至 88%,究竟省在哪里
同样使用 Opus 5.5,Antigravity 的输入 token 少了 68% 至 88%,输出 token 少了 40%,完成时间短了 27%。Claude Code 生成的游戏更长,代码行数对比为 451 行和 236 行。
输入差距为什么是区间?因为 Antigravity 分别报告 input_tokens 和 cache_read_tokens,文档没有解释两者是否重叠。在 Opus 测试中,缓存读取为 15,381,输入为 9,822,前者比后者还大,无法解释为后者的子集。
作者于是保留两种口径:只算报告的输入,少 88%;把输入与缓存读取相加,少 68%。
这个区间首先反映统计口径的不确定性,不能当成多次实验的波动范围。
作者认为,启动时的大量 token 来自工具自己的指令和工具定义,这些内容会随请求再次发送。不过,原文没有给出完整的启动结果表,也没有逐项拆解输入来源,因此还不能精确判断到底是哪部分贡献最大。
MCP 的结果也有意思:Antigravity 加入第 1 个工具就增加约 280 至 460 token,之后再加 29 个,增量却很小。作者据此推测,四种配置现在似乎都会在实际使用时才加载工具的完整定义。这里是根据现象推断加载机制,并非已经验证内部实现。
游戏都能玩,为什么还不能直接宣布胜负
作者检查了全部 12 个游戏:打碎砖块后分数增加,可以进入第 2 关,生命值也能按 3、2、1、0 递减。自动检查没能读出其中两个 Codex 游戏的分数,作者随后手动确认,两者都能计分。
这说明四种配置都完成了这道题的基本功能,但没有证明它们在代码维护性、交互体验或复杂需求上水平相同。代码更短不自动代表更好,代码更长也不自动代表更完整。
价格同样需要分开看。Claude Code 按 API 价格为每次运行估算了 $0.37;Antigravity 和 Codex 在订阅模式下没有显示价格。这里不能据此计算真实账单节省,更不能把「没有显示价格」理解成零成本。
作者还明确承认,无法看到 Antigravity 在 claude-opus-5-5-medium 这个名称背后如何配置 Opus 5.5。即使模型名称一致,隐藏配置是否完全相同,仍然没有答案。
我的判断
我认同这次测试提出的问题:挑选 AI 编程工具时,外围 CLI 的开销值得单独测量。 同一个任务,系统提示、工具加载和上下文组织都可能影响输入量与等待时间。
但「编程工具和模型同样重要」是作者的判断,这组实验不足以量化两者各占多少。它没有覆盖真实仓库中的多轮修改,也没有提供更多任务、机器和日期的重复验证。68% 至 88% 应当保留为这次实验的结果,不能推广成日常开发的固定收益。
相较于只看 token 数,我更看重功能验收、完成时间和人工返工量一起比较。作者做了游戏功能检查,这是有价值的一步;对于一般团队,后续还需要拿自己的任务补测。
原文另称,Google 于 2026 年 6 月 18 日停止向个人账号提供 Gemini CLI,并将用户转向 Antigravity CLI(agy)。这是作者提供的迁移信息,本文没有独立核实,不能仅凭这次跑分决定迁移。
能拿来做什么
- 比较日常 AI 编程 CLI 时,先固定模型和任务,再比较工具;把 Codex 的 gpt-6-luna 与 Opus 5.5 混在一起,只能比较整套方案。
- 做前端生成任务的小型评测时,可以沿用单文件游戏的方法,提前写好计分、关卡和生命值验收条件,并对自动检查失败的项目人工复核。
- 记录消耗时,分别保存输入、输出和缓存读取字段,同时记录完成时间;字段含义没确认前,保留多种统计口径。
- 准备精简 MCP 配置时,先测试工具数量对启动输入的实际影响,再决定是否删减。按需加载存在时,工具数量未必与 token 消耗线性增长。