Gemini 4 Hydrogen：快速执行，模型路由

1. 专注于反复修改代码和测试

Gemini 4 Hydrogen 专注于编写代码、探索代码仓库、测试等需要反复执行的任务。Carbon 和 Argon 负责需要深度推理的问题，而 Hydrogen 则独立处理日常开发，或与这两个模型协同执行。

据公司公布的数据，在决定模型求解深度的默认推理级别下，Hydrogen 完成任务的速度是 Gemini 3.8 Flash 的 2.5倍，在衡量编程任务表现的 Terminal-Bench 4.1 中得分为 57%，高于 3.8 Flash 的 18.2%。公司还表示，凭猜测编造的说法减少了 5倍以上。

探索代码仓库时，它不会逐一读取文件，而是将文件读取和搜索工具调用打包并行处理。谷歌表示，即使工具调用失败或搜索结果为空，也已改进模型调整下一步行动的能力。

2. 在任务过程中切换判断模型和执行模型

Antigravity 的 Orchestrator 不同于仅根据首个请求就为整个任务固定一个模型的方式。Carbon 可以先以只读方式查看依赖并制定计划，再由 Hydrogen 修改代码、更新软件包并测试。如果 Hydrogen 遇到阻碍，Carbon 就会审视当前状态、重新规划，再交回执行。

据公司公布的数据，在 Terminal-Bench 4.0 中，Orchestrator 实现了接近 Carbon 的任务成功率，同时比 Carbon 平均减少 24% 的配额用量，任务完成速度提高 19%。不过，Antigravity 博客将同一结果的基准测试版本标为 Terminal-Bench 4.1，与此不同。

使用 Orchestrator 可减少用户在每个步骤手动切换模型的麻烦，并根据长任务的进展划分判断与执行。希望直接控制角色的开发者可用 Antigravity SDK 组合 Carbon 和 Hydrogen，也可让 Carbon 担任协调者，让 Hydrogen 智能体并行处理编程与验证。

3. 根据推理深度调节速度和成本

Hydrogen 提供四种推理级别。对于轻量对话或重视短时间处理量的场景，可以选择较低级别；对于复杂编程或工具使用，可以从默认的高级别开始。最高级别适用于默认级别无法解决的困难多步骤任务。

让快速执行模型负责重复任务，可以减少高阶推理模型的用量。另一方面，提高推理级别会增加令牌用量和等待时间，推理令牌也计入输出费用。谷歌建议按任务评估后，选择满足质量要求的最低级别。

付费层级对整个上下文窗口采用统一单价，上下文窗口指对话中可容纳的信息范围。缓存命中输入可复用已保存的输入，处理价格更低，因此在重复输入较多的任务中，是否复用输入也会影响成本。

表：Hydrogen 付费层级的令牌费用

条件：Gemini 4 Hydrogen，适用于整个 1M 上下文窗口的付费标准价格，缓存输入价格适用于隐式缓存命中时

单位：美元/100万令牌

4. 从免费 API 到订阅制自动切换均有提供

Google AI Studio 和 Gemini API 的免费及付费层级均可使用，开发者也可在 Android Studio 中进行构建。企业用户可通过 Gemini for business 使用。

在 Antigravity 中，付费 Google AI Pro 和 Ultra 订阅用户可选择 Hydrogen 作为独立模型。Orchestrator 开始向 Ultra 订阅用户提供 Carbon 和 Argon 选项，向 Pro 订阅用户提供 Argon 选项。

5. 现有应用应先检查默认推理设置与输出大小

输入、推理和输出共享最大 1,048,576 令牌的统一窗口。等待请求结束才返回的同步响应最多为 65,536 令牌，更长输出可在提高输出上限后使用后台执行，或通过继续生成功能获取。

从 3.8 Flash 迁移后，默认推理级别由 medium 变为 high。以下是谷歌的示例，不作额外设置，以默认级别请求生成交互式网页应用。

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-4-hydrogen",
    input="Build an interactive single-file HTML token bucket rate-limiter simulator with live sliders for burst size and request traffic."
)

print(interaction.output_text)

Hydrogen 的核心不仅是快速独立执行，还在于在复杂开发任务中，将判断模型和执行模型衔接到同一会话内。