Gemini 4 Hydrogen keeps API rates flat across a million-token context

Gemini 4 Hydrogen brings a relatively simple pricing promise to Google's expanding model family: the API rate stays flat across its million-token context window. Developers can send a longer working history without crossing into a separate long-context price tier, although the number of tokens processed still determines the bill.

Google's November 12 introduction positions Hydrogen for everyday coding and agent workflows. Alongside direct access, the company is integrating it into Antigravity's Orchestrator, which can move work between models. That pairing matters more than a single leaderboard position: a cheaper model is useful when it can finish the routine work and hand off the difficult part without forcing the user to restart the assignment.

Flat pricing is not a flat bill

The announced standard API rates are $1.50 per million input tokens and $7.50 per million output tokens. Holding those rates constant across the context window removes one threshold from budgeting. It does not make a million-token prompt cost the same as a short request, and it does not make output free.

As simple arithmetic, 100,000 input tokens and 10,000 output tokens would cost $0.225 at those rates, before other applicable services or pricing adjustments. The example describes a chosen workload, not a measured average task. A workflow that repeatedly resends material or generates substantially more output can have a different cost even when the model's rate is unchanged.

This is a useful contrast with Carbon's introductory pricing period, where the calendar changes the published rate. With Hydrogen, Google's announcement emphasizes a consistent rate across context length. Neither arrangement substitutes for measuring the tokens a particular application actually uses.

More reasoning is a choice

Hydrogen exposes low, medium, high and xhigh thinking levels, with high as the default. These settings give a developer another way to trade response effort against latency and expenditure. They do not certify that every request needs the maximum setting, or that a shorter reasoning budget will preserve accuracy on a difficult task.

The practical distinction is between a repetitive, well-defined transformation and a problem with dependencies that must be checked. Those tasks can share an interface while needing different amounts of reasoning. A default is where evaluation starts, not a universal instruction to spend the same effort on every operation.

Google's model catalogue separately documents supported modalities and model endpoints. Applications should use those operational limits when implementing a workflow rather than treating the launch's broad “million-token” description as permission for any combination of input and output.

Orchestrator changes the unit of work

In Antigravity's announcement, Orchestrator can hand work between Hydrogen and the larger Gemini models as the assignment develops. The paid-tier distinction remains important: the available model mix differs between Pro and Ultra. Access to a model in one product is not a promise of the same controls or allowance in every Gemini interface.

A handoff is valuable when it preserves useful progress. If an agent has already located the relevant files and established a reproducible failure, a more capable model should not need to rediscover that context. Equally, sending every step to the larger model would weaken the efficiency argument. The design opportunity lies in deciding which parts actually need escalation.

That is an architectural promise, not an independent measurement of success on a reader's repository. Hydrogen's clearest confirmed change today is the combination of a consistent context-price rule and explicit routes into larger-model workflows. For teams choosing from the AI model catalogue, the meaningful saving will be the cost of a finished, checked task—not the cheapest first response.