Google Launches Gemini 4 Carbon: Its Strongest Model Goes to Defenders First

On October 28, 2026, Google announced Gemini 4 Carbon, the second frontier model in the Gemini 4 generation, just two weeks after Argon. Google describes it plainly: its strongest model yet, built for cybersecurity defense and for long, multi-step tasks. Here is the most important sentence up front: ordinary users cannot use it yet. The first people to get it are a small, vetted group of cyber defenders. Developers, businesses, and consumers will have to wait, and Google has given no date.

That ordering is itself the news. For the past year, frontier launches have mostly followed one script: publish the scores, open the API, and let everyone try it. This time Google reversed it. The scores are public, but the door is only slightly open, and only to defenders. The reason is not hard to guess. Carbon's three best skills — finding vulnerabilities, checking whether they can be exploited, and fixing them — are tools in a defender's hands and weapons in an attacker's hands. Google says it is taking part in the U.S. government's voluntary pre-release testing process, and that it will gather feedback and keep working on safeguards before widening access. That posture deserves credit, but be clear about what it does and does not solve: it slows down the release of risk, it does not remove the dual-use problem at the heart of the model.

Read the numbers, then read their limits

Google's scorecard is genuinely eye-catching. Carbon scores 59 on the newly updated Artificial Analysis Intelligence Index v5.0, ranking first. On three external cybersecurity benchmarks it reports 88.2% on SEC-bench Pro for finding real vulnerabilities, 54.8% on ExploitGym for exploitation, and 71.0% on CWE-bench for patching to the root cause — and Google notes explicitly that these three were evaluated without guardrails. In web development, Carbon jumps 89 points over Argon on WebDev Arena to land fourth. On internal benchmarks, its success rate for generating secure code more than doubles Argon's, and Google says its Chrome team found Carbon more than ten times better than another lab's large frontier model at producing high-quality patches.

Those numbers need to be read in three layers. The first layer is external benchmarks, which are relatively comparable, but different benchmarks ask different questions and score differently, so 88.2% and 54.8% cannot be directly compared with each other. The second layer is Google's own internal tests — the doubled secure-code rate, the Chrome team's tenfold claim — which come without full public reproduction details and should be treated as vendor figures. The third layer is composite rankings like the Intelligence Index, which blend many results into one score; ranking first overall does not mean first on every dimension. Indeed, independent commentary at launch noted that Carbon does not lead on the independent coding-agent index. The fair reading is this: Carbon has posted persuasive results on the cybersecurity track, but whether it is the strongest model overall still awaits independent testing and real-world use.

What it is actually good at: work that takes days

Beyond security, Carbon's other selling point is long-horizon work. Google says its internal teams have run Carbon for days, pushing through dead ends on complex engineering problems such as root-causing and patching subtle bugs across large codebases and low-level systems. For people doing vibe coding, that description matters more than any score. In everyday development, the most time-consuming part is usually not writing the first version of the code, but fixing bugs: vague error messages, a cause sitting three files away, one fix creating another problem. A model that can keep going without giving up fits that pain point in theory.

In practice, there are three traps. First, long tasks cost more: the longer it runs, the more you pay, and if it goes off track midway, everything after that is waste. Second, a model saying it "persisted for days" does not mean every step was right; without human checks along the way, you can receive a polished-looking delivery with new problems buried inside. Third, Google's examples come from its own teams in its own environment. Your codebase's structure, test coverage, and documentation are nothing like Google's internal setup, so some discount on performance is the likely outcome. For most developers, then, Carbon is currently a signpost of where things are heading, not a tool you can pick up tomorrow.

The safety claims, taken one by one

Google made several specific safety and alignment claims that are worth recording individually, because they can be checked against later. First, it tightened training against shortcut-taking: successful cheating on Terminal-Bench 4.0 fell to 0.0%, with cheating attempts down to 0.4%, while overall accuracy improved. Second, in internal testing, unsupported claims fell by about half compared with Argon: the model puts methodological caveats directly into its deliverable, or lists blocked actions together with what is still required, instead of fabricating a tidy answer. Third, in multi-step tasks, overreach fell 26% and under-service fell 29% — it is less likely to act beyond its brief, and less likely to stop halfway. Fourth, on Gray Swan's indirect prompt injection benchmark, Carbon reached a 0.0% attack success rate, resisting every evaluated attempt.

If these hold up, they are real progress, and the second point may matter most for programming: fewer fabrications and more honest admissions of ignorance are worth more than a few extra benchmark points. But the same caveat applies throughout: these are Google's internal tests and its chosen benchmarks, with evaluation setups, prompts, and scoring criteria set by Google itself. A perfect score on an injection benchmark does not equal immunity in the wild, where attack techniques always outnumber benchmark cases. Treat these as encouraging signals, not as problems already solved.

The price is set; the people are not in yet

On pricing, Google has shown its hand: Carbon launches at the same introductory price as Argon, $2 per million input tokens and $10 per million output tokens, with cached input at 95% off. Third-party coverage adds that the price will rise to $4 and $20 after the introductory period. Google's own post states only the launch introductory price, without giving the post-introductory price or the length of the introductory period, so the higher figures must be labeled as third-party reporting, not an official commitment.

The strategy is interesting: set the price first, hold back the people. The implied message is that Google would rather anchor cost expectations than argue about "when can I use it." At the introductory price, Carbon looks like a bargain — same price as Argon, stronger capability. At the post-introductory price, it sits at top-tier rates, and whether it is worth it will depend on its success rate on your tasks. Anyone budgeting should plan around the higher price and treat the introductory rate as an early-stage discount, not the basis for a long-term cost model.

Judgment for developers: no need to chase it, but watch three things

For the vast majority of developers and vibe coders, the pragmatic approach to Carbon right now is simple: no need to chase it, and no need to feel anxious about not having it. What you should actually watch are three things. First, the pace of widening access: who the next Fairwind Program partners are, when a developer API opens, whether there is a public waitlist. That tells you more than any benchmark about when you can really use it. Second, independent evaluation: results from third parties on real codebases and real vulnerability-fixing tasks, especially on your own kind of work. Third, how the security capability ships as a product: whether it arrives through the Gemini API directly, or first inside Google Cloud security products. That decides whether small teams get any benefit at all.

There is also a longer-term judgment. Two frontier models in two weeks suggests Google has built a loop in which models help its researchers advance research faster. Google's own line — researchers and models "working hand in hand" — is not empty rhetoric. It means iteration may keep accelerating. That is good news, and a warning: workflows, prompts, and cost models tuned for one model may need rework within months. Do not treat any single model as permanent infrastructure. Treat it as a tool that will be replaced, and keep your workflow portable.

Compared with Argon: stronger where, and not where

Carbon builds on Argon, and Google says so itself: Argon launched two weeks earlier, and Carbon pushes several directions forward at once. Web development output quality improved, reflected in the 89-point WebDev Arena gain; scientific tasks and multimodal understanding were also mentioned; cybersecurity defense improved the most, with all three benchmarks setting new records for Google; alignment and honesty improved, with unsupported claims roughly halved and both overreach and under-service down. Added together, Carbon is clearly the stronger model — but "stronger" is not "dominant in every dimension."

Where it is not yet proven, the original post itself leaves clues. First, the top ranking comes from the just-updated v5.0 of the Intelligence Index; when a ranking changes its methodology, cross-version comparisons need care, and the 59 cannot simply be lined up against older scores. Second, Google published no context window, reasoning tiers, latency, or real API performance for Carbon — exactly the hard numbers developers care most about when choosing a model. A model that scores well on benchmarks is not automatically as good in long conversations, large repositories, and multi-file changes. Third, with access limited to a small defender cohort, outside developers have not yet stress-tested it at scale, and real-world failure cases have not yet surfaced. The evaluation sample is heavily skewed toward the vendor's own labs. In short, Carbon's strength is currently official strength; independent verification is still on its way.

A practical comparison framework for anyone choosing a model is this: do not ask "is Carbon the strongest," ask "is it the most reliable on my task." If your task is finding vulnerabilities, reviewing code, or fixing security issues, Carbon's three security benchmarks at least earn it a place on the shortlist, pending hands-on testing once it opens up. If your task is everyday feature work, interface changes, or prototyping, the WebDev Arena result and long-horizon ability are equally worth noting, and equally in need of testing. If cost matters, the gap between introductory and post-introductory pricing is a calculation you must do, not a first impression to accept. Model selection is never ranking selection; it is task selection.

Defenders first: caution, or privilege?

Giving defenders first access can be defended as responsible release, or criticized as handing the strongest tool to a select few first. Both readings have merit, and the deciding factor is execution detail. Google says "a subset of cyber defenders" — a subset, not all defenders — without publishing its selection criteria. It also says it will "gradually phase access to additional trusted partners through our Fairwind Program," without spelling out what counts as trusted, where to apply, or how long the queue is. For small security teams and independent developers, the practical question is blunt: do I count as a trusted partner, where do I apply, and how long do I wait?

There is a trend worth watching here. If frontier security capability stays for a long time with a few large institutions and contracted partners, the gap between attackers and defenders does not necessarily shrink — it changes shape. Large companies get dedicated models, dedicated support, and dedicated feedback channels; small teams wait for the public version, by which time attackers may already have similar capability through other channels. Google's participation in the U.S. government's voluntary pre-release testing process points in the right direction, but a voluntary process has limited force, and the scope and openness of its results are unclear. The real test is not what was said on launch day, but what happens over the next few months: whether the widening schedule holds, whether productized security capability reaches small teams, and whether independent evaluators get the same testing conditions.

There is another angle that often gets missed: the better models get at finding and fixing vulnerabilities, the more the software industry's handling of "security debt" may change. In the past, finding flaws relied on manual audits and scanners, and fixing them depended on scheduling. In the future, a model may catch a whole class of problems before code is submitted, or hand over a patch directly. That is good for developers, but it raises a new responsibility question: if a model-generated patch introduces a new problem, who is responsible? If a model misses a flaw it should have caught, can the team catch it? These questions do not disappear as models get stronger; they get more important precisely because everyone relies on the model more. The stronger the tool, the less excusable it is to skip human review.

What you can prepare now, instead of just waiting

Before Carbon actually opens up, developers can already do several useful things. First, fix your own security baseline: dependency scanning, secret management, least privilege, test coverage. These are fundamentals no model replaces; a model can only add on top of them, not make up for their absence. Second, prepare your own evaluation tasks: pick three to five real bugs and security issues you have actually faced, note the symptoms, the investigation, and the correct fix, and use the same set to test Carbon when it opens. Conclusions drawn that way will mean something to you, instead of being dictated by a leaderboard. Third, do the cost math: budget at the post-introductory price, estimate token use for your own workload, and do not discover on launch day that your cost model does not add up.

For vibe coders, there is one more specific piece of advice: do not treat Carbon as a magic tool that finishes whole projects for you, and do not treat it as irrelevant news either. Its long-horizon and security abilities point to the same shift in working style: humans set direction, models run long tasks, humans review results, models fix again. In that loop, human value is not in writing every line of code, but in defining clearly what needs doing, judging whether results are right, and knowing when to stop. Start practicing that style now — write requirements more clearly, list acceptance criteria up front, write tests first — so that when stronger models arrive, you can actually make use of them. If you stay in "write whatever comes to mind" mode, even the strongest model will only hand you code that looks runnable but falls apart under scrutiny.

Watch the product, not just the model

There is a distance between a model announcement and a shipped product that is often underestimated. Google's post ends by saying it looks forward to seeing how the first defender cohort uses the model, and to bringing Carbon to developers, businesses, and consumers soon — but "soon" has no date, and the product form is not specified. It could appear in the Gemini API first, or be integrated into Google Cloud security products and Wiz scanning flows first, or open in a small invited test. Different orders mean different things to different people: security teams care whether it enters their scanning pipeline, independent developers care when the API opens and what it really costs, and ordinary users care whether Gemini chat gets better. None of those questions were answered on launch day.

So the right way to track Carbon is not to refresh leaderboards daily, but to watch for verifiable milestones: whether the Fairwind Program announces new partners, whether a Carbon model identifier appears in Gemini API documentation, whether Google Cloud security products announce integration, and whether the first independent evaluations produce reproducible results on real tasks. Each milestone moves Carbon one step from "news" toward "tool." Until then, everything about what it will change is judgment, not fact. Keeping judgment and fact separate — in writing and in reading — is the most basic and most easily forgotten skill for following this kind of launch.

One last blunt point: Carbon's launch pattern is becoming the new normal for frontier models. A small trusted group first, feedback gathered, access widened gradually, scores first and product later. The next time you see a launch like this, ask three questions: who can use it, when is it my turn, and under what conditions were the scores measured. If those three cannot be answered, even the brightest leaderboard is only half a story. Carbon's half is already worth paying attention to. The other half will only count once it actually reaches developers' hands.