Evidence at a glance
Capability and access are moving at different speeds
Google DeepMind introduced Gemini 4 Carbon as a frontier model for long-horizon agentic coding and cyber defense. It is the second Gemini 4 model after Argon. Google says internal teams have run Carbon for days on single tasks, including tracing and repairing subtle bugs in large codebases and working on low-level systems. The model was also tuned for full-stack web development and multimodal understanding.
This is not a routine API launch for every developer. Initial access is limited to vetted cyber defenders, and Carbon runs only on Google-hosted infrastructure. There are no open weights, self-hosted deployments, or quantized variants, and Google has not disclosed its parameter count or context window. For an enterprise, raw capability is only part of the equation: access, data handling, and fit with existing tools also determine whether the model can be used in practice.
The benchmarks show strengths, but not across the board
Across the 17 comparisons Google published, Carbon leads Argon, GPT-6 Astra, Opus 5.5, and Fable 5.1 on 15. It scores 59 on the updated Artificial Analysis Intelligence Index, placing first, and reaches 65.2% on Terminal-Bench 4.0, ahead of Opus 5.5 at 59.6%. The gap is particularly large on a long-context task: Carbon scores 96.2% on GraphWalks, compared with 84.2% for Argon and 71.8% for GPT-6 Astra.
Those results do not amount to a clean sweep. Carbon scores 61.2% on FrontierSWE, behind GPT-6 Astra at 65.5%, and 81.5% on OSWorld-2.1, below Opus 5.5 at 87.2%. Google says Carbon ran at its highest thinking setting and rivals at their highest available reasoning settings, while most rival figures were self-reported by their providers. Benchmarks indicate relative performance on selected tasks; on their own, they do not establish how closely those tasks resemble an engineering team’s production work.
The defense lifecycle makes the model useful—and harder to evaluate
Google presents Carbon’s cyber capability as a lifecycle: find a vulnerability, validate whether it can be exploited, and then produce a patch. It reports 88.2% on SEC-bench Pro, versus 85.4% for GPT-6 Astra; 54.8% on ExploitGym, versus 42.4% for GPT-6 Astra and 34.5% for Opus 5.5; and 71.0% on Collinear’s CWE-bench, compared with 68.0% for both Argon and GPT-6 Astra. Google also says internal tests found Carbon more than twice as successful as Argon at generating secure code, and that the Chrome team found it over ten times better than another lab’s model at producing high-quality patches.
Those figures need to be read alongside their test conditions. Google computed the SEC-bench Pro and ExploitGym results itself using its Antigravity harness, and mitigations were turned off for ExploitGym; the cyber benchmarks were evaluated without guardrails. The material does not provide the full method or comparison model behind the Chrome team’s claim, so it cannot be treated as an independent head-to-head evaluation. Completing an exploit task in a controlled benchmark and safely assisting defense in production are related, but distinct, capabilities.
Deployment decisions should start with task boundaries
Carbon’s proposition is that a model can do more than answer a single prompt: it can keep working through a longer engineering loop, handle dead ends, and produce code or patches. For teams analyzing large codebases, reproducing vulnerabilities, or reviewing fixes, that persistence may matter more than a score on a single-turn task. Google also reports a score of 1769 and a fourth-place ranking for Carbon on WebDev Arena, but this remains a signal from a particular evaluation setting, not a substitute for a team’s own code-quality and regression tests.
For now, technical leaders should treat Carbon as something to evaluate under controlled conditions. Start with authorized defensive tasks whose outcomes can be reviewed, test whether recommendations are reproducible and auditable, and only then consider expanding use. Keep the permission boundaries for vulnerability discovery, exploit validation, and patch generation distinct, and assess what hosted deployment means for code and security data. If a team cannot obtain access or place the model in an auditable workflow, a high benchmark score will not by itself become usable capability.