Gemini 4 Carbon and Hydrogen work best as a pair: Carbon plans, Hydrogen builds. Give a planner Agent on Carbon the Task, let it write sub-tasks with acceptance checks, hand those to worker and verifier Agents on Hydrogen, and route anything that fails twice back to the planner. You pay frontier rates only for the turns that need frontier judgment.
Why pair Gemini 4 Carbon and Hydrogen at all
Google shipped Gemini 4 Hydrogen on November 12, 2026, and called it the “daily driver for agentic workflows.” Two days earlier, on November 10, the Gemini API changelog listed Gemini 4 Carbon as generally available. So for the first time this month, you can put Google’s strongest model and its fast execution model behind the same Task.
Google’s own pitch for Hydrogen leans on that pairing. The launch post says Carbon can act as the coordinator while Hydrogen powers “worker and verifier agents to build and test changes simultaneously across isolated workspaces.” The Gemini API guide puts it more plainly: have Carbon plan interfaces or resolve hard roadblocks, then delegate code edits, parallel subagent tasks and test runs to Hydrogen.
That’s an orchestration pattern, not a model feature, and you can build it on your own board today. If you want the board to hold the pattern rather than a script on one laptop, Sharkly is where the Tasks, Agents and reviews live.
What Google’s Orchestrator does, in one paragraph
Orchestrator is a model option inside Google Antigravity that switches between a planner (Carbon or Argon) and Hydrogen within one conversation. Per the Antigravity docs, the planner starts with a read-only phase, writes a plan with explicit re-planning triggers, and hands execution to Hydrogen. Hydrogen hands control back when it hits friction.
The docs name three friction signals worth stealing:
- A verification step that fails twice.
- An interface that behaves differently than the plan expected.
- A design choice the plan didn’t settle.
Google reports that on Terminal-Bench, Orchestrator reached near-Carbon task success while using 24% less quota and finishing 19% faster on average. Google’s two posts disagree on the benchmark version (the launch post says 4.0, the Antigravity post says 4.1), so cite it as Terminal-Bench until Google reconciles them.
Orchestrator keeps a single agent in your conversation, runs a fixed configuration with no thinking-level control, and in its Carbon form is listed for Google AI Ultra only. A team board spreads the same split across several Agents, with the plan and hand-offs visible to everyone.
The cost case: Gemini 4 Hydrogen vs Carbon pricing
Token prices from the Gemini API pricing page, read November 13, 2026:
| Model | API model id | Input / 1M | Output / 1M | Free tier |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
$2.00 through Nov 30, then $4.00 | $10.00 through Nov 30, then $20.00 | No |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
$1.50 | $7.50 | Yes, rate-limited |
Read the dates before you build a budget around this. Until November 30, Hydrogen is only 25% cheaper per token than Carbon. From December 1, it’s 62.5% cheaper. Both figures are our arithmetic on Google’s list prices.
Here’s what that means for one run, also our arithmetic. Take a worker turn that reads 200k tokens and writes 40k (output includes thinking tokens). On Carbon after December 1, that’s $0.80 + $0.80 = $1.60. On Hydrogen, it’s $0.30 + $0.30 = $0.60. Run that 30 times a day across a Sprint and the gap stops being a rounding error.
Per-token price understates the difference. Google says Carbon “spends more thinking tokens per turn to test hypotheses and verify edge cases,” and output pricing includes thinking. So the same edit on Carbon likely bills more output tokens as well as a higher rate. Google publishes no per-task cost figure for the pair, so measure it on your own repository before you quote a saving.
Speed is the other half: Google reports Hydrogen finishes tasks 2.5x faster than Gemini 3.8 Flash at its default high level.
Split work across your agent team: roles that map to models
A planner/worker split is a written division of labor: one Agent owns the plan and the hard calls, cheaper Agents own the execution, and a verifier checks the result before a person sees it. Each role gets the model whose cost and depth fit the job.
| Role | Model | Thinking level | Owns |
|---|---|---|---|
| Planner | gemini-4-carbon |
default medium, high for hard Tasks |
Reading the codebase, writing sub-tasks with acceptance checks, re-planning |
| Worker (1 to n) | gemini-4-hydrogen |
high (default) |
Edits, package updates, tests, one sub-task each |
| Verifier | gemini-4-hydrogen |
high, xhigh for risky diffs |
Running checks against the planner’s acceptance criteria |
| Person | n/a | n/a | Approving the plan for big Tasks, accepting the result |
Two details from Google’s docs shape this table. Carbon and Argon default to medium and cap at high, while Hydrogen defaults to high and adds xhigh. And Google warns that xhigh raises latency and token use and “can cause overthinking on simpler prompts.” Keep xhigh for the verifier on diffs that touch auth, payments or data migrations.
What should the planner write?
The planner’s output is the contract for everyone downstream. A good plan has one sub-task per independent change, a file scope for each, the command that proves it works, and the condition that sends it back. If a worker can’t tell when it’s done, the plan isn’t finished.
When does work go back to the planner?
Copy Google’s trigger list and make it explicit. A worker returns a sub-task when its check fails twice, when an interface doesn’t match the plan, or when it needs a design decision. It returns with the log, the diff so far and the question. It never retries silently on a bigger model, because that hides the cost of the cheap tier inside the bill of the expensive one.
Set it up in Sharkly
In Sharkly, an Agent is an AI teammate that runs through a Runtime on a connected Computer, and a Crew is a group of Agents and People coordinated by one leader Agent. That maps onto the planner/worker split with no glue code. The planner is the Crew leader; the workers and verifier are Crew members.
Each Agent carries its own Runtime and Default model, as in the panel above (that one runs Claude Code). For this setup, give each Agent a Runtime that can reach the Gemini API, such as Gemini CLI, and set the model per Agent: Carbon on the planner, Hydrogen on the rest. If the model list doesn’t show the new ids yet, set the model in the Runtime’s own configuration. Gemini CLI also reads a GEMINI_MODEL environment variable, per its configuration reference, and Agents accept per-Agent environment variables.
Then write the coordination rules into the Crew instructions:
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
Assign the Task to the Crew. Execution is leader-first, per the Crews docs: the leader reads the Task and Crew instructions, then mentions members for specific contributions, and their results come back into the same Task. Use temporary working directories so each worker gets its own worktree. Turn on the Crew’s shared Task directory only when sub-tasks must build on each other’s local changes in order.
Blocked work stays visible: failed or blocked runs land in the Inbox, and an Agent waiting on a person surfaces in the sidebar’s Task Chats. That’s where the dashed arrow lands when the planner can’t repair the plan.
Advanced techniques
Use the API’s model switching for one long Task. Google’s docs say you can route planning turns to gemini-4-carbon and execution turns to gemini-4-hydrogen in one multi-turn session with previous_interaction_id, with no schema changes. That’s Orchestrator’s trick in your own code, useful inside a single Agent run.
Mind the hop sizes. Hydrogen returns up to 65,536 tokens per non-streaming hop, while Carbon and Argon return 32,768 per non-streaming REST hop. Keep long generation, like test suites and migration specs, on the worker side.
Drop explicit caching on Hydrogen. Hydrogen doesn’t support explicit context caching. Implicit caching runs on prompts of at least 4,096 tokens and discounts cached input by 95%, so keep the shared repository context at the start of each worker prompt.
Alternatives to a planner/worker split
- Hydrogen alone. Google’s docs recommend it for package upgrades, deduplication, scaffolding, unit tests for well-defined functions and docs. No planner needed.
- Carbon alone. For distributed-system design, race conditions or multi-repo migrations, where every step needs depth.
- Orchestrator in Antigravity. One person, one conversation, automatic hand-offs, on the plans that include it.
- A static router. Classify the Task up front and send it to one model. Google argues this breaks down on long runs, where difficulty changes mid-Task. We covered the up-front version in routing agent Tasks with the Gemini Decisions API.
Real-world use cases
Issue triage at volume. Google’s own Antigravity SDK demo pairs Hydrogen agents for triage and coding with a Carbon agent for refactors, new feature work and security checks. On a board, that’s a Hydrogen Agent on the intake queue and a Carbon leader on anything labelled refactor or security.
A feature split into parallel sub-tasks. The planner splits an API change into schema, handler and client updates; three workers run them in separate worktrees; the verifier runs the contract tests.
Conclusion
Carbon plans, Hydrogen builds, and a person accepts. The pricing makes the split worth it from December 1, the friction triggers keep cheap failures from turning into expensive retries, and the board keeps every hand-off on the Task where the team can see it. For the wider pattern, read what AI agent orchestration is and our model routing rule for Crews.
Your next step: connect one Computer to Sharkly, create a planner Agent on Carbon and one worker on Hydrogen, put them in a Crew with the instructions above, and assign it a Task you’d normally give a person for an afternoon. Sharkly has a Free plan, so the only cost of the test is the Gemini tokens.
FAQ
What is the difference between Gemini 4 Carbon and Hydrogen?
Carbon is Google’s strongest frontier model, built for long-horizon reasoning and hard architecture, debugging and security work. Hydrogen is the fast, efficient Gemini 4 model for everyday coding and agent execution. Carbon defaults to medium thinking and caps at high; Hydrogen defaults to high and adds xhigh.
Is Gemini 4 Hydrogen cheaper than Carbon?
Yes. Hydrogen is $1.50 per 1M input tokens and $7.50 per 1M output. Carbon is $2 and $10 through November 30, 2026, then $4 and $20 from December 1. Hydrogen also has a rate-limited free tier on the Gemini API; Carbon doesn’t.
Should the verifier run on Carbon instead of Hydrogen?
Not by default. Google positions Hydrogen for parallel worker and verifier agents. Use xhigh on the verifier for risky diffs, and escalate the Task to the Carbon planner only when a check fails twice.
Does Sharkly pick the model for each Task?
No. You set the model per Agent through its Runtime, and the Crew instructions decide which Agent gets which part of the Task. Sharkly holds the Task, the runs, the hand-offs and the review.
