Gemini 4 Hydrogen 四档 thinking：高分与低账单之间，开发团队该怎么选

封面：Google 官方发布主视觉。图片来源。

Gemini 4 Hydrogen 的四档 thinking 并没有四张不同的 API 单价表。Google 将 high 设为默认档，另提供 low、medium 和 xhigh；按 2026 年 11 月 16 日查阅的价目，标准调用每百万输入 token 为 $1.50、每百万输出 token 为 $7.50，输出计费包含 thinking。对开发团队，真正要选的不是「哪档单价最低」，而是一项任务在什么档位下能被验收，以及需要多少时间、token、重试与人工复核。独立评测给了选择起点，却还没有替你的代码库做出选择。

想象一条日常编程任务：agent 先读报错和相关文件，调用工具定位问题，修改两处代码，跑测试，再根据失败信息重试。这个场景是为了拆解成本的假设，不是我们已经跑过的 Hydrogen 实测。假如每一步都固定用最深的推理，容易把简单检索也变成昂贵的等待；假如一律用最低档，后面的返工又可能吞掉省下的调用费。要看清这笔账，必须先拆开厂商发布数据、独立评测和本地任务记录，不能把三者合成一句「更强也更便宜」。

先把试验顺序写成一张小表。这是根据验收条件制定的比较假设，不是对 Hydrogen 已完成测试后的生产配置推荐；表里的每一行都要能被你自己的任务结果推翻。

把“内容能不能自动核对”放在第一列很重要：只检查 JSON 格式、不检查字段含义，并没有证明错误容易发现。对于越权操作、不可逆写入等任务，先限定工具权限和人工批准条件；更高档位本身不能成为安全理由。第一轮如果没有稳定差异，就继续保留对照，不急于按一次漂亮结果修改所有请求的默认值。

Hydrogen 把 high 设为默认，改变的是每一步的工作量

Google 在 11 月 12 日发布公告中将 Hydrogen 定位为 agent 工作流的“daily driver”，强调日常编码与多步骤任务，并于 11 月 13 日更新公告。这不是说它已经证明适合所有代码任务，而是说明 Google 希望开发者在哪些工作里尝试它。官方给出的 low、medium、high (default)、xhigh 四档，把原先常被当作模型固定属性的「想多久」变成了请求配置的一部分。

在一次对话里，档位看起来只是一个参数；在编程 agent 里，它可能参与每个步骤。搜文件、读几行配置、设计修改、解释测试失败并不是同一种判断。档位高低首先关系到模型在特定测试上的表现和生成过程消耗的资源，接着才通过输出量、任务完成率、工具往返与重试次数影响账单。官方定价并没有规定 xhigh 每个 token 更贵，也没有承诺 low 每项成功任务更便宜。

团队有两个常见的错误起点。第一个是看见 high 默认，就把默认当成经过自己任务验证的最优；第二个是只看每百万 token 价格，就以为四档没有成本差异。前者把厂商的通用设置当作本地结论，后者把一张价目表误当成完整任务的发票。较稳妥的做法是：high 作为对照组，其他三档必须靠同一批任务的结果决定用途。如果一项任务没有可写清楚的验收标准，先补验收条件，再争论档位。

四档分数可以帮你设计试验，不能替你预测补丁成功率

独立机构 Artificial Analysis 在 2026 年 11 月 12 日更新的 Intelligence Index中，给 Hydrogen 的四档成绩分别为：low 27、medium 41、high 51、xhigh 54，版本为 v5.0.1。这个跨度足够告诉团队：不能只试一档，就宣布模型整体表现如何。它并不告诉你某个项目里 low 有 27% 的成功率，或 xhigh 比 high 多解决 3% 的 issue。指数是多个评测组合后的得分，任务、工具、停止条件与代码库都不等于你手里的工作。

同一来源的 模型发布评估页给出 xhigh 14.8 分钟/评测任务、$3.16/评测任务，high 为 8.4 分钟/评测任务。这些是该机构页面在后续查阅时的测量/估算，不是 Google 承诺的服务时延，也不是一次 API 请求的固定账单。Google 发布时的官方速度图，high 大约 6 分钟、xhigh 大约 13 分钟；它与后续独立页面是不同取数时点及呈现条件，不能拿图为 8.4/14.8 分钟背书，也无法据此判定哪边「变慢了」。尤其不能给所有 agent 请求预填同一个等待时间。

Google 在公告中另引一组 Terminal-Bench 4.1：Hydrogen 57%，Gemini 3.8 Flash 18.2%。按 Google 的评估方法，前者是 high 档、mini-swe-agent vision harness、每项任务五次取平均的 cheating-adjusted 结果。这是 Google 自报的特定测试对照，不是 Artificial Analysis 四档指数的直接复测。更不能把表格说成全面领先：同一官方总览中 Hydrogen 在 Terminal-Bench 4.1 为 57.0%，表列另一模型为 63.9%；在 Terminal-Bench-Science 0.1 为 51.4%，表列最高值为 59.9%。两组数字分别可以提出问题——「新的 agent 模型是否值得测试」与「不同档位在多项能力测试上差多少」——不能加在一张表里算收益率，更不能说「我们跑出来 57%」。

对开发团队更有用的，是把这一组公开结果翻译成待回答的问题：medium 是否已经足够处理带有明确单测的常规改动？high 相对 medium 增加的质量能否减少人工退回？xhigh 在复杂、审查昂贵的改动上，是否真能挽回额外时间？这些问句都需要自己的任务样本。别把综合能力曲线当成你们仓库的接受率曲线。

高一档的价值，取决于错误在哪里被发现

还是看那条假设的编码任务。若 agent 提交一个小补丁，CI 很快指出失败，团队只需检查短 diff，失败便相对容易发现。即使第一轮没有通过，重试的成本仍能被明确记录。另一种任务是修改跨模块的权限边界：测试可能全部通过，但隐藏副作用要由审阅者逐条发现。两者都叫「写代码」，失败代价却不是一个量级。低档在前者可能值得试，在后者可能连候选资格都没有。这是编辑上的条件性判断，不是 Hydrogen 已被证明在两类任务里分别胜出的实测。

把代价拆成三层，讨论才不会抽象。模型费用是输入、输出、缓存命中等 token 计价；等待费用是结果晚到影响工程节奏，包括排队和工具执行；错误费用是测试失败后的重试、审查和漏检。官方价格只写清第一层的部分费率，独立评测只观察了其测试中的部分时间与结果。后两层需要你自己记录。一个档位若输出较长，账单可能增加；若少了一次失败重跑，整项任务又可能更省。没有本地数据时，两条方向都只能写成假设。

这也解释为什么「高分档」和「生产默认档」不是同一个问题。xhigh 在独立综合指数上高于 high，但要做高成本验证：是否在你真正关心的失败类型上提升？是否引入更长等待？能否让人类审核更短而不是更累？如果回答不了，把所有任务都升到 xhigh 不是谨慎，而是把不确定性搬进账单。反过来，为了少付输出费把风险任务直接降到 low，也只是把成本藏在人工补救里。

团队可先按可验证性分层，而不是按任务名分层。单元测试能覆盖的修改、带明确 schema 的资料抽取、需要专家判断的架构选择，分别规定什么算成功以及哪类错误会被检测到。对于「可自动检错、失败可安全重试」的一组，low 或 medium 才有足够清晰的实验条件；对于「错误发现困难、返工昂贵」的一组，high 起步并纳入 xhigh 对照更有意义。没有可靠评估的部分，不要用更深的 thinking 当成安全机制。

百万 token 是输入与输出共享预算，不是普通请求能输出百万

模型规格容易在这里制造第二种错觉。Gemini API 的 Hydrogen 模型文档写的是 1,048,576 token 的 unified input and output context window：输入与输出共用的上下文预算。相同文档把默认同步请求的最大输出标为 65,536 token；在 long decode 条件下，才写到最高 1,048,576 token 的输出。不能把统一窗口直接改写成「日常 API 请求能返回百万 token」，也不能把 long decode 视为每个接入层已实现、每个场景都稳定可用的普通档位。

为什么这个边界和成本文章有关？编程 agent 的历史会增长。第一次请求可能只发任务说明与少数文件；第二次带上工具回显；第三次包含测试失败、修复建议和旧的调用记录。即使工程师嘴上说「同一任务的一次执行」，API 看见的是多次、长度不同的请求。若历史在每轮累积，旧输入可能一遍遍进入新的计费范围；若请求接近统一窗口，给输出留的空间也要计算。打算靠「把整个仓库塞进去」避免检索步骤的团队，仍须检查单次预算、输出上限、裁剪策略与工具日志，而不是看见 1M 就忽略这些约束。

这不是说应该一概缩短上下文。需要逐文件交叉检查时，较长输入可能减少漏读；无关的重复日志则可能既占预算又污染判断。保留哪些文件、何时压缩历史，本身应成为任务评估的一部分。Google 的 官方基准总览图能说明厂商在哪些测试里主张了提升；它不能告诉你历史截断后的编程 agent 还剩多少有效上下文。

用可复核的算例，看清单次调用与整项任务

按 Google 的 Gemini API 价格页，Hydrogen 标准档每百万未缓存输入 $1.50、输出 $7.50；Batch/Flex 对应 $0.75、$3.75。隐式缓存命中的输入则是标准 $0.075、Batch $0.0375，每百万 token。这里的缓存价格只适用于实际命中的那部分，不代表每次带相同提示词都会命中；模型文档还标明支持隐式缓存，不支持显式缓存。价格页没有在这一行列出一笔可拿来相加的显式缓存存储费。

为避免把比例说成实测，设一个纯算术假设：某次调用用 20 万未缓存输入 token、2 万输出 token，没有其他费用。标准价为 0.2 × $1.50 + 0.02 × $7.50 = $0.45。如果恰好有 15 万输入 token 实际命中隐式缓存，其余 5 万仍按普通输入计，且输出量不变，才是 0.15 × $0.075 + 0.05 × $1.50 + 0.02 × $7.50 = $0.23625。如果改成 Batch 且仍假设 20 万输入都未缓存、2 万输出，算术价是 0.2 × $0.75 + 0.02 × $3.75 = $0.225。三个数没有把任务完成率或 Batch 的运行条件等同起来；输入结构、实际缓存命中与可用服务档不同，实际账单便不同。

这张表不是三种买法在同等时效、同等结果下的生产对比。Batch 是否满足某项工作的交付时间，缓存是否能命中，乃至 thinking 档位是否改变输出长度，都被算例固定在假设中。它只展示计算规则，不证明谁最优。把 $0.225 当作「任务完成成本」会漏掉同一任务中下一轮读文件和修错的请求，也会漏掉搜索 grounding、外部工具、失败重试与人工审核等可能独立发生的代价。

再加一个刻意简单的多轮示范：假设同一项任务连续三次调用，未缓存输入分别是 20 万、25 万、30 万 token，每次输出 2 万。全部按标准价时，合计输入 75 万、输出 6 万，token 金额为 0.75 × $1.50 + 0.06 × $7.50 = $1.575，而只拿第一轮报价仍是 $0.45。这个 $1.575 不是 Hydrogen 的平均任务费用；这些输入量只是用于展示「多轮累积」的构造值。哪一轮能命中缓存、上下文是否经过压缩、任务是否提前成功，都要以请求使用量记录来确认。

Carbon 的今日价不能当作全年比较基准

同一官方价目里还列着 Gemini 4 Carbon。截至 2026 年 11 月 30 日，它的标准输入/输出价格为每百万 token $2/$10；从 12 月 1 日起列价变成 $4/$20。Batch/Flex 则由 $1/$5 变为 $2/$10。这里有明确时限：如果拿限期的 $2/$10 跟 Hydrogen 的 $1.50/$7.50 比较，却把结论写成未来长期的价格排序，计算虽然准确，时间条件却错了。

即便日期写对，单价也只是选择的一半。高复杂度任务上，如果模型 A 的一次成本高些但更容易通过验收，完整任务可能比模型 B 省；相反，简单重复任务未必需要更贵的替代。本文没有跑 Hydrogen 对 Carbon 的同题代码库对照，因此不做「谁完成任务更便宜」的胜负判断。Google 官方价格也不是任何第三方服务的结算承诺；实际供应渠道与套餐要看相应的公开报价，不能把厂商促销移植成本站长期价。

这一时点的另一条价格纪律是：不要把缓存价格当成强制折扣。隐式缓存是否命中，由请求内容、前缀、调用路径等实际条件决定。静态说明或多轮共同指令可能成为候选，但变动的工具结果无法凭文章推断命中。任何以 $0.075 算出「至少省多少」的方案，都应先有实际命中 token 记录；没有记录，就先按未缓存价预估，再把命中当观察结果，而不是预算承诺。

一套小样本对照，怎样避免把 benchmark 当采购结论

不需要一次性测遍所有工程工作。先选有代表性的、能够安全复现的任务组，明确日志和隐私边界：例如带单测的小修复、需要跨文件推理的修改、工具调用较多的排障。任务必须能在隔离环境重放，避免一个档位先修改仓库、另一个档位在被改过的状态上作答。对每项任务事先写下验收标准：测试通过只是必要条件还是充分条件？审阅者要检查哪些语义变化？超过多长等待或发生几次错误调用就停止？这些是建议的实验设计，不是本文的已完成测评。

保留同一环境与输入条件，记录 thinking_level、输入与输出 token、实际缓存命中量、API 返回到首个可用结果的时间、工具往返次数、失败重试、人工接受或退回的原因。评估时还要把「没有产生候选修改」和「产生了修改却被审阅拒绝」分开：前者可能与工具、上下文或超时有关，后者才涉及代码质量；混成失败总数，档位原因会被掩盖。测试集应保留不同难度与文件规模，不要只挑模型已经擅长的短题。还要为人工审阅记录明确的时间窗口：如果第一档在上午得到审核、第二档隔天才轮到审核，所谓「总耗时」反映的就不只是模型。无法控制排队时间时，至少分开记录模型返回、自动测试结束和最终签收三个时点，避免把人的日程误算成推理档位的性能。哪怕最后选择默认 high，也要能回答它赢在哪里。若 high 比 medium 输出更长却没有增加通过率，值得回看任务难度；若 xhigh 在少数难题上明显减少人工返工，可以只对该类任务试行。没看到本地数据前，这些都是判断规则，不是结果。

两类对照应当分开。第一类是同一模型四档之间的配置实验，找每类任务的合格门槛。第二类才是与其他模型的选型实验，还要对齐时点、提示词、工具、缓存计费和验收。把 Google 的 Terminal-Bench 4.1 柱形图、Artificial Analysis v5.0.1 的综合指数和 Carbon 的限期价放在一张表里，用一个「性价比分」排序，看似全面，实则每一列的实验对象都不同。公开数据应帮助决定优先测试什么，而不是替代测试。

最终判断并不复杂：Hydrogen 有明确的四档、稳定的模型 ID、统一的百万级上下文预算和公开费率；Google 模型规格与 Artificial Analysis 的评估结果都足以支持一次有设计的试用。现在不能确定的，是你的 agent 在不同档位的通过率、重试开销、缓存命中，以及 long decode 在具体接入路径上的实现。先用 high 建立基线，再让低档证明自己省的是成功任务的总成本，让 xhigh 证明自己挽回的是值得等待的错误。没有这些证据，就不要把发布当天的一张分数图升级成生产默认值。