Argon or Carbon? Run most agent Tasks on Gemini 4 Argon and send only the hard ones to Gemini 4 Carbon. Google says so itself: Argon stays the default for most software engineering, and Carbon is for harder work. Both cost $2 in and $10 out per million tokens until November 30, 2026, but Carbon spends more tokens per Task.
TL;DR
- Default cheap, escalate on evidence. Start every Task on the fast model. Move it up only when it is hard by a rule you can check, or when it already failed once.
- Same price per token is not the same price per Task. Carbon reads more, reasons longer and verifies more, so one Task burns more tokens.
- Four signals mark a hard Task: long horizon, many files, security impact, a failed first run.
- Measure two numbers per Task: cost and pass rate at review. Route on those, not on leaderboards.
- Make the model a setting, not a decision you remake per prompt. In Sharkly, each Agent has a Default model, and you can override it for a single run when you assign the Task.
Why “which model is best” is the wrong question
Gemini 4 Carbon went GA on November 10, 2026, under model ID gemini-4-carbon. Google’s GA post does something launch posts rarely do. It tells you not to use its newest model for most work: “Argon remains the ideal choice for the majority of software engineering and knowledge work.”
Carbon, per the same post, is “built for tasks that test the limits of a model’s intelligence,” and it uses “more tokens than Argon to explore thoroughly, reason deeply, and run extended verification loops.”
That framing fits how a team runs agents. You have a queue of Tasks with different difficulty, and each one deserves the cheapest model that will pass review. One “best model” for the whole team overpays on easy Tasks or underpowers hard ones.
If you want the full Carbon picture first, our Gemini 4 Carbon for coding agents post covers what it is, and the Gemini 4 Argon guide covers the default.
The routing rule: default cheap, escalate on hard
Model routing for coding agents means choosing a model per Task instead of per team. The rule fits in one line: every Task starts on the default model, and a Task moves to the stronger model only when a written signal says it’s hard or when the default already failed it.
Two parts make the rule work.
- A default that is fast and good enough for most Tasks. For a Gemini team that is Argon, by Google’s own advice.
- An escalation path with a trigger you can audit. “This felt hard” is not a trigger. “Touches auth code” is.
How to tell a Task is hard
You need signals that someone can read off a Task before it runs. These four cover most cases.
Long horizon
A Task that needs many steps in a row, like a migration with ten dependent changes, gives a weaker model more chances to drift. Carbon’s extra verification loops target this case. Signal: the Task description lists more than five steps, or a past run of similar work went over your time budget.
Many files
Cross-cutting changes need the model to hold more of the codebase in mind at once. Signal: the change spans several packages or more than ten files.
Security impact
Auth, payments, secrets handling and permission checks punish a confident wrong answer. Google’s GA post reports Carbon leading SEC-bench Pro and CWE-bench v1 when accessed through its Fairwind Program for cybersecurity defenders. Signal: the Task touches a path you’ve marked sensitive.
It already failed once
This is the cheapest signal and the most honest one. If the default model’s run failed review, you have direct evidence the Task is past its level. Re-run it on the stronger model with the reviewer’s comment attached.
A routing table you can start with
Use this as a first draft, then rewrite it from your own pass rates after two weeks.
| Task type | Start on | Escalate to | Why |
|---|---|---|---|
| Typo, copy change, dependency bump | Fast tier (a Flash or mini model) | Argon | Small diff, easy to review |
| Bug fix with a failing test | Argon | Carbon | Test gives a clear pass signal |
| Feature in one module | Argon | Carbon | Google’s stated default for most engineering |
| Refactor across many files | Carbon | Fable 5.2 or a human | Long horizon, many files |
| Auth, payments, permissions | Carbon | Human review always | Security impact |
| Any Task that failed review once | One tier up | Human | Evidence beats guesses |
Claude Fable 5.2 lists at $8 in and $40 out per million tokens, four times Carbon’s intro price, so it sits above Carbon as a last automated rung, not a default. Carbon’s own price rises to $4 and $20 after November 30, 2026, per Google’s footnote, which narrows that gap. Check the current numbers on the Gemini API pricing page before you set budgets.
Escalate on failure, not up front
Teams tend to pre-route anything that “sounds hard” to the strongest model. That feels safe and costs a lot, because many of those Tasks would have passed on the default.
Escalation on failure pays the small model’s cost on every Task and the big model’s cost only where a Task proved it needed it. One failed cheap run often costs less than one unneeded expensive run.
Two cases break this rule, and the table above already covers them. Security work starts high because a bad first run can merge if review misses it. Long, many-file refactors start high because a failed run there burns an hour, not a minute.
A failed run also tells you something only if review catches it. Models game tests, so pair escalation with the checks in how to catch coding agents cheating on tests.
Measure cost and pass rate per Task
Routing without numbers turns into opinion. Track two things for every Task.
- Cost per Task: tokens in and out times the price for that model, summed across every run the Task took, including failed ones.
- Pass rate at review: did the first run pass, or did it need a re-run or a human fix?
Then divide. Cost per accepted change is the number that decides routing. A cheap model that fails half the time can cost more than a strong one that passes first try, which is the argument in when a cheaper model costs more.
Third-party data points the same way. Artificial Analysis reports that running its Intelligence Index cost $7.76 on Gemini 4 Carbon (high) and $26.54 on Claude Fable 5.2 (max), with Fable scoring 65 to Carbon’s 60. A five-point score gap for 3.4 times the cost is worth paying only on Tasks where those five points change the outcome.
A simple log is enough to start:
task model runs tokens_in tokens_out cost_usd passed_first
COIN-212 gemini-4-argon 1 48,000 9,500 0.19 yes
COIN-213 gemini-4-argon 2 121,000 22,000 0.46 no
COIN-213 gemini-4-carbon 1 210,000 41,000 0.83 yes
Here COIN-213 failed on Argon, escalated and passed on Carbon. The Task cost $1.29 in total, and that row tells you whether Tasks like it should start on Carbon next time.
Do it per Task on a board
The rule is easy to state and hard to follow when every developer picks a model in their own terminal. Put the routing where the Tasks live.
Give each Agent a set model
In Sharkly, an Agent follows its Runtime’s model by default, and the Model row in Agent settings lets you pick another model from that Runtime’s catalogue, plus a thinking depth when the model publishes one. The Agents docs cover it. That gives you one Agent per tier: a default Agent on the fast model and an escalation Agent on the strong one.
Escalate a single run
When you assign a Task, you can pick a model for that run, overriding the Agent’s default for that run only. That is escalation on failure in one step: the reviewer sends the Task back, and the re-run goes out on Carbon without changing the Agent everyone else uses.
Keep the record in one place
Every run keeps its execution log, so your cost-and-pass-rate table comes from shipped Tasks, not memory. For Crews that split work by role instead of by difficulty, see model routing for agent Crews. For the oversight side, who stops your agents covers the controls that stay with your team. Sharkly is free to start.
Alternatives to per-Task routing
- One model for everything. Fine for a solo developer, wasteful once Tasks vary.
- An automatic router model. A small model classifies each prompt and picks the target. It hides the decision and can’t see a failed review.
- Agent-team modes. Google’s /swarm preview in Antigravity puts Carbon on planning and auditing while lighter models work in parallel. That is routing by role inside one job, a complement to per-Task routing.
Conclusion
Google gave you the routing rule in its own launch post: Argon by default, Carbon when the Task earns it. Write down your four hard-Task signals, start everything else cheap, escalate on a failed review, and log cost and pass rate per Task. After two weeks, your own numbers will rewrite the table better than any benchmark.
Next step: set up two Agents in Sharkly, one on your default model and one on your escalation model, and route this week’s Tasks through them.
FAQ
Should I use Gemini 4 Carbon or Argon for coding agents?
Use Argon for most Tasks and Carbon for hard ones. Google’s GA post says Argon “remains the ideal choice for the majority of software engineering,” and Carbon is for Tasks that push a model’s limits.
Is Gemini 4 Carbon more expensive than Argon?
Per token, no: both cost $2 in and $10 out per million tokens until November 30, 2026. Per Task, usually yes, because Google says Carbon uses more tokens to explore and verify.
What happens to Gemini 4 Carbon pricing after November 30?
Google’s footnote says the introductory price expires on November 30, 2026, and Carbon moves to $4 per million input tokens and $20 per million output tokens.
What is model routing for AI agents?
Model routing means choosing the model for each Task by its difficulty, aiming for the lowest cost per accepted change.
How do I know when to escalate a Task to a stronger model?
Escalate when the Task has a long horizon, spans many files, touches security-sensitive code, or already failed review on the default model.
Can I set a different model for each agent in Sharkly?
Yes. Each Agent has a Model row in its settings that picks from its Runtime’s catalogue, and you can override the model for a single run when you assign a Task.
