Gemini 4 Carbon finds bugs at 88% and patches at 71%. Price that gap into your threat model

Google released Gemini 4 Carbon on October 28, and the two numbers I keep staring at sit next to each other on the announcement page: 88.2% on SEC-bench Pro, which measures finding vulnerabilities, and 71.0% on CWE-bench, which measures patching them at the root cause. Add 54.8% on ExploitGym, a new state of the art for turning a bug into a working exploit, and you get a model that looks better at discovery than at repair. You cannot use it yet unless Google decides you are a defender.

What Google actually shipped

Carbon builds on Gemini 4 Argon, which launched two weeks earlier (I covered that gated rollout in Gemini 4 Argon: 77.9% on DeepSWE, but only for cyber defenders). Koray Kavukcuoglu's post calls it Google's "strongest model with state-of-the-art cybersecurity and long horizon capabilities" and says internal teams have run it for days on root-causing and patching bugs across large codebases. It ranks first on the Artificial Analysis Intelligence Index v5.0 with a score of 59. Google also reports a 0.0% attack success rate on the Gray Swan indirect prompt injection benchmark, versus 0.7% for Argon, and a claim from the Chrome team that Carbon produced high-quality patches more than 10x better than an unnamed frontier model from another lab.

Access is narrow. Carbon goes first to a subset of cyber defenders, then to more trusted partners through the Fairwind Program, while Google takes part in the U.S. government's voluntary pre-release testing. If you run security for a power utility or a national cyber authority, you sit in the queue Fairwind prioritizes, next to governments and core technology platforms. Getting in means going through your Google Cloud account team, a background check and an ethics review, and then only internal security, incident response or penetration testing teams may touch the model, behind phishing-resistant MFA, with no resale. That rules out plugging it into the coding assistant your whole engineering org already uses. When I read the Fairwind page it still described access to Argon, so expect the paperwork to lag the model.

Pricing copies Argon, including the part I would plan around. At launch you pay $2 per million input tokens and $10 per million output tokens, with cached input 95% off. After an introductory period that has no published end date, both rates double to $4 and $20. If you approve a nightly scan of your monorepo on launch prices, the same job costs twice as much on a date Google has not announced, so I would build the business case on $4 and $20.

The independent read is more mixed

Artificial Analysis confirms the 59 and the first place, with leads in 4 of its 9 evaluations. The same write-up holds the less flattering parts. On its Coding Agent Index, Claude Code with Claude Opus 5.5 scores 62 against Carbon's 59. Carbon's hallucination rate rose from 4% on Argon to 11%, still the second lowest in their table but almost three times its own predecessor. On cost, Carbon used 123k output tokens and $7.76 per index task at standard pricing, against $10.04 for Opus 5.5 at max effort.

The hallucination number is the one I would watch in security work. A vulnerability report that is wrong 11% of the time is a triage cost, and in a security queue triage is the expensive part.

Why the find versus patch gap is the real story

Strictly, 88.2 and 71.0 come from different benchmarks with different difficulty, so subtracting them is a framing and not a measurement. The direction still matches what I see in practice. Finding a bug needs one correct observation. Patching it needs the right fix, in the right layer, with no regression, accepted by a maintainer who has other work.

A model that finds bugs faster than your team can merge fixes turns your backlog into the attack surface.

Here is the practical consequence. Assume that a model like Carbon, or the next public model trained the same way, reaches attackers within a year; Google's own phased rollout implies it expects this class of capability to spread. Your exposure then stops being "does a vulnerability exist" and becomes "how long does a known one stay open". Mean time to remediate becomes the security metric that matters, and most teams I work with do not measure it per repository.

The table is my reasoning, not Google's data, but it shows where the asymmetry lands: discovery gets cheap for everyone, while patching still waits on your review queue and your release train.

What I would change in a secure SDLC this quarter

First, measure the time from report to merged fix for every service, and treat anything over 30 days on an internet-facing component as an incident in progress. Second, cut the dependency tree, because every transitive package is one more place a model can look and one more fix you cannot ship yourself. Third, budget review capacity for machine-found reports now. When access widens, the inflow will arrive in bursts, and an 11% hallucination rate means someone has to reproduce each finding before an engineer touches code.

I wrote about how the labs gate these models in every frontier lab now has a gated cyber model. Gating buys months. The remediation pipeline is what you build with them.

If you qualify for Fairwind, apply through your Cloud account team and point Carbon at your own repositories first. Track fixes merged per week, and ignore findings per week, which is the number every vendor dashboard will show you.