Gemini 4 Carbon: 59 Points and a $2/$10 Intro Price
Gemini 4 Carbon: 59 Points and a $2/$10 Intro Price
The line I keep coming back to in Google's Carbon announcement is the pricing footnote: the introductory rates will eventually double. A model can look attractive on launch day and produce a very different budget later. That matters especially when the pitch is work that keeps running for hours or days.
Google announced Gemini 4 Carbon on October 28, 2026. Access begins with selected cyber defenders; a general consumer release date is not given. It also tops an independent intelligence index. Those are useful facts, but they answer different questions: capability, availability and the cost of actually finishing a job.
Who can use Gemini 4 Carbon right now?
Google is expanding access through its Fairwind Program. DeepMind describes that program as early access for trusted, high-priority defenders, including governments, healthcare providers and telecommunications services. This is a selected-access path. Paying for a Gemini subscription is not, by itself, evidence that Carbon is in your model picker.
For an ordinary developer, the practical next step is to check the actual model list and account entitlement before changing an integration. An announcement can arrive before a public endpoint. I would keep a production migration conditional on a callable model, documented limits and a small reproducible acceptance test. The launch post does not settle those details for every reader.
What does its 59-point score actually establish?
Artificial Analysis lists Gemini 4 Carbon (High) at 59 on Intelligence Index v5.0. Claude Opus 5.5 reaches 58 at Max and 57 at Xhigh, both with Default Fallback. This is independently evaluated evidence. The index combines nine evaluations, so the result is broader than one coding puzzle.
A one-point index lead does not mean a one-percent improvement on your repository. It also does not say how often a patch survives review or how much human cleanup it needs. The useful reading is that Carbon deserves a serious evaluation when access arrives. A decision to replace an existing workflow needs task-level evidence.
Keep the version number attached when comparing old coverage. A score from a different index version is not automatically on the same scale. That is particularly easy to miss when a launch headline compresses a detailed evaluation into a single ranking.
Where do the engineering gains become uneven?
The evaluation methodology supplied with Carbon is more useful here than the headline. Google generally uses the highest thinking settings. Results mix Google-computed measurements, provider reports and benchmark leaderboards. Its OSWorld result uses an 82-task offline subset and the best of three single-attempt runs for Gemini. Treat the table as a documented comparison, with different protocols across rows.
For security work, Google reports 88.2% on SEC-bench Pro, 54.8% on ExploitGym and 71.0% on CWE-bench. The launch says these cyber evaluations were run without guardrails. They cover discovery, exploitation validation and patching respectively; they are not a single end-to-end success rate.
My reading is that a team should pick the bottleneck it actually has. Finding a bug, demonstrating its impact and landing a safe repair need different evidence. Multiplying those three benchmark percentages would produce a neat-looking number with no valid connection to an actual repair pipeline.
What would a real engineering job cost?
The announced introductory rates are $2 per million input tokens and $10 per million output tokens. The later rates are $4 and $20. Google does not name the introductory end date in this announcement. Cached input receives a 95% input-price discount; at the introductory rate that calculates to $0.10 per million cached input tokens.
Here is a budget exercise, not observed Carbon usage. Count every billable token across the entire run, including retries and whatever reasoning tokens the eventual billing rules charge. Then apply the relevant rates. The examples below cover uncached token charges only; tools, infrastructure and taxes are outside the calculation.
| Illustrative total tokens | Introductory | After introduction |
|---|---|---|
| 100K input + 20K output | $0.40 | $0.80 |
| 1M input + 200K output | $4.00 | $8.00 |
| 1M input + 1M output | $12.00 | $24.00 |
Caching changes the arithmetic, but the discount applies to cached input rather than the whole bill. In the first example, assume 80% of the 100K input tokens are valid cache hits. The token charge becomes 0.02 × $2 + 0.08 × $0.10 + 0.02 × $10 = $0.248. That saves $0.152, or 38%, before any separate cache-storage charge. It does not cut the complete bill by 95%.
The bigger question is what counts as done. Suppose 100 attempts each use the first example’s tokens: that is $40 at introductory rates. If 80 repairs are accepted, token cost is $0.50 per accepted repair. If only 50 are accepted, it is $0.80. Those acceptance counts are hypothetical. They show why a low token price cannot settle the economics without a reliable success measure.
My take
Carbon’s independent index lead makes it worth watching. The engineering and security results give a clearer reason to test it on difficult repair work than to pay more merely for a new model name. The selected rollout also means there is time to prepare a useful comparison rather than infer product readiness from a launch table.
My proposed pilot would start with a frozen set of previously resolved issues, hidden reference fixes and identical tool permissions. Give each model the same stopping rules. Record whether the patch passes a meaningful regression test, whether reviewers accept it, total billable usage and review minutes. Include failed and abandoned attempts in the denominator. This is a test plan, not a claim that I have run Carbon.
For a long-running agent, I would also inspect what happened after a dead end: did it change approach, keep an evidence trail and stop when it needed a human decision? A polished final message is weak evidence if the saved patch or test logs disagree. These checks tell a reader more about useful autonomy than the duration of a demo.
Our earlier Gemini 4 Argon article covers the preceding access discussion. For Carbon, the next useful update is public availability plus a reproducible comparison of accepted results and review time. That is the evidence I would want before making a production migration.
Sources checked October 29, 2026, KST. No hands-on Carbon test was performed.
Written by Open Source Factory. Benchmark conditions and access can change; use the dated source links when evaluating a purchase or migration.
Comments
Post a Comment