Google has put Gemini 4 Hydrogen, a faster and cheaper sibling of its strongest models, into Search for all users, into the Gemini app and into its developer tools. Its most useful lesson is about how AI work gets divided between a model that does the routine steps and a model that handles the hard ones.
## A job usually gets hard in the middle The clearest case is Antigravity, Google's coding tool, which now has an option called Orchestrator. The older way to save money is a router that reads your first request, guesses how hard the job is, and sends the whole thing to the cheapest model it thinks can cope. That breaks on long jobs, because the hard part tends to appear after the work has started: a file nobody mentioned, or two instructions that conflict.
Orchestrator moves in both directions. The strong model Carbon starts by exploring and planning. Hydrogen takes over to write the changes and run the tests. If Hydrogen hits trouble, it hands the job back, Carbon looks at the current state and fixes the plan, and Hydrogen carries on. Orchestrator with Carbon is only for Google AI Ultra subscribers; Orchestrator with the Argon model is also open to paid Google AI Pro subscribers.
The saving is real but smaller than the price list suggests. Hydrogen's output costs $7.50 per million tokens, against $20 for Carbon from December 1, so work done entirely by Hydrogen would be about 60% cheaper. The measured saving was 24%, because Carbon still does the planning and the repairs. That is the number to expect from a good handoff: about a quarter, with almost no loss in results.
## You will meet it without choosing it Most people will not open a coding tool, but they will meet the same logic. In the free Gemini app, Hydrogen is used when the app decides a question suits it, and free Gemini already keeps its hardest work for paid plans.
Search is the bigger case. In Search, Hydrogen splits a question into several searches at once and brings up sites people had not found before. For a shop owner, that suggests a page that answers one narrow part of a customer's long question has a better chance of showing up than before. A page about repairing one specific model of coffee machine can now answer part of a question that also asks about delivery times and warranty.
## The same split fits your own recurring jobs Orchestrator is a coding-tool feature for now, but nothing about the pattern is specific to code. Picture an accounts team at a hospital group that matches 3,000 bank lines to invoices every month. Nearly all of them are routine: one payment, one invoice. A fast model can clear those. When a payment covers two invoices, or a refund arrives before its credit note, it stops and passes the case to a stronger model, which works out the treatment and writes a rule so the next one is routine.
If the stronger model needs to look at 100 of the 3,000 lines, a person reviews 100 cases instead of 3,000. I would estimate that turns a two-day job into a morning.
So when you set up a recurring job for an AI tool, write the stop rule first: which cases it must pass up, to a stronger model or to you. For the invoice job it is one line: if a payment does not match exactly one invoice, stop and ask.