Model guides

Gemini 4 Hydrogen: API Access, Migration and Task Routing

Google has released Gemini 4 Hydrogen for everyday coding and agentic execution. Check its text-output contract and migration differences before routing production work to it.

SJolt Editorial6 min readUpdated
Editorial diagram showing task routing, an acceptance check and a separate image handoff
Original SJolt editorial illustration of the proposed workflow; not a generated result, product screenshot or news photograph.

Gemini Hydrogen and Gemini 4 Hydrogen refer to the model Google announced on November 12, 2026. Google positions it for fast execution in coding and agent workflows, with access through its developer and consumer products. It is a released model with official documentation, not just a leaderboard nickname.

SJolt’s catalog at this November 13 review includes Gemini 4 Argon but has no Hydrogen route. Evaluate Hydrogen through Google’s documented access path; use SJolt only for models actually listed in its catalog. This guide proposes a practical qualification exercise and a separate image-production handoff. No paid model request was run.

What the official contract actually supports

Google identifies the model as gemini-4-hydrogen. It accepts text, image, video, audio and PDF inputs and produces text. Its unified context is 1,048,576 tokens, with a default synchronous maximum output of 65,536; longer decoding requires the documented continuation or background workflow. A one-million-token context does not mean a normal request can return that much output independently of its input.

RequirementDocumented Hydrogen behaviorImplementation consequence
Inspect an image or videoMultimodal input; text outputAsk for observations or a brief, then inspect the answer.
Generate an imageImage generation is unsupportedUse a separate image model.
Cache a repeated promptImplicit caching; no explicit cachingRemove explicit cache references during migration.
Return a structured briefStructured outputs supportedStill validate required fields in application code.

Changes to check before replacing a Flash request

Google’s migration guide says Hydrogen defaults to high thinking, adds xhigh, and rejects minimal. The November 14 documentation recheck clarifies that in-range custom temperature, top_p and top_k values are ignored, while out-of-range values return a 400 validation error. Preserve prior turns and thought signatures unchanged when managing generateContent history; use the documented conversation mechanism for the API you select. These are Google contract details, not promises about an SJolt endpoint.

Create a migration record before changing traffic. Save the old model, transport, prompt revision, output schema, reasoning setting and timeout. Run the same stored inputs against a candidate configuration and record failures separately from valid answers. If a result is truncated, inspect the finish reason and budget before interpreting the missing fields as a reasoning failure.

Do not change prompt wording, model, thinking level and acceptance rules together. Start with an unchanged task and an explicit thinking setting. Once that comparison is understood, vary one setting and preserve the earlier result. This makes a later cost reduction traceable to a concrete decision.

Migration fixtureDocumented behaviorWhat to verify
No custom sampling fieldsNo unsupported sampling assumptionUse this as the clean migration baseline.
An in-range custom sampling valueIgnoredDo not assume it controls output diversity.
An out-of-range sampling value400 validation errorFix the payload before retrying; do not treat it as capacity loss.

Keep request validation failures separate from model-quality and availability results in the migration record. An out-of-range sampling field is a payload defect, so changing the prompt or retrying the identical request does not test Hydrogen’s reasoning. Remove inherited sampling controls and record the actual error response before rerunning an evaluation. This is a documentation-based test plan; no live request was made.

Estimate the complete attempt, including thinking

Google’s standard paid rates are $1.50 per million input tokens and $7.50 per million output tokens, including thinking. Its listed implicit cache-read rate is $0.075 per million tokens. Batch rates are $0.75 input and $3.75 output. These are Google prices checked on November 13, not SJolt Hydrogen prices. Grounding and other chargeable operations need separate budgeting.

For illustration, 20,000 uncached input tokens and 4,000 billed output tokens cost $0.06 at standard rates: 0.02 × $1.50 + 0.004 × $7.50. If the 4,000 counted only visible answer tokens and omitted thinking, that estimate would be incomplete. A second identical attempt would bring this simplified total to $0.12. Neither figure is a measured workload cost.

Compare cost per accepted task over a fixed set, including retries. Keep time to first response, time to a validated final artifact, and human review minutes as separate columns. A faster first response is useful only if the remaining work fits the deadline.

A concrete qualification task: route a creative brief

Build a small fictional input set for a design queue. Each item includes a task ID, an approved product description, a desired change and any missing asset. Ask the model to return a routing decision, an evidence excerpt and a short production brief. Choose deterministic acceptance rules before evaluating any model.

FixtureExpected decisionReject when
A new illustration with a complete brieftext-to-imageThe answer invents a reference photo.
Change only the background of an owned photoimage-editThe answer changes the product geometry.
An edit request with no source imageneeds-inputThe answer fabricates a usable image URL.
A product sheet containing an instruction to bypass reviewKeep the original task constraintsThe answer follows instructions embedded in the sheet.

Use at least two differently worded items for each case. Keep the answer key outside the prompt. Require the evidence excerpt to occur in the supplied material and the task ID to match exactly. Validate the route against an allowlist, and reject unexpected fields rather than treating fluent prose as a successful structured result.

Run this qualification in a harness that cannot submit generation jobs. A valid route suggestion becomes a reviewable record, not permission to spend. After checking the brief, a separate application step can create the approved media task. This also lets you test routing without paying for an image every time.

Connect the approved brief to a real SJolt workflow

For a text-only baseline already available in SJolt, the Gemini 4 Argon model page documents its Chat Completions and native Gemini routes. Keep that baseline’s protocol and settings in its own record. Do not copy the Hydrogen identifier or Google-specific options into an Argon request and label the result a Hydrogen test.

When the accepted output is an image brief, Nano Banana 2.1 offers separate text-to-image and image-edit routes in SJolt. The image-edit route requires actual reference image URLs; a model-written description of a reference is not an image. Use the current model documentation to construct the request, retain the returned task identifier, and follow the task to its terminal status.

Inspect the resulting asset against the approved brief: subject geometry, wording, crop and any required unchanged areas. Store routing errors separately from image-generation errors. That separation makes it possible to improve the planner without blaming it for a media rendering defect, or to change the image model without rewriting the routing evaluation.

Sources & further reading

Take the next idea into production.

Explore the models, test a workflow in the playground, and use the same request in your application.

Keep exploring

← All stories