Gemini 4 Carbon: limited access, launch pricing and the evidence behind its security claims

What Google announced, and who gets access

Google announced Gemini 4 Carbon on October 28, 2026, for cybersecurity and long-running engineering tasks. The company says internal teams have used it on problems lasting days.

Access begins with selected cyber defenders, then additional trusted partners through Google’s Fairwind Program. Broader developer, business and consumer availability is planned; the announcement does not provide a general release date.

For a team choosing a tool this week, that distinction matters. An announced model can influence an evaluation shortlist without becoming an available dependency. Confirm your organization’s access before attaching it to a delivery commitment.

Public record: Google — Gemini 4 Carbon announcement, October 28, 2026

Introductory pricing has a later step-up

Google lists introductory rates of $2 per million input tokens and $10 per million output tokens, with cached input discounted 95%. Its footnote lists subsequent rates of $4 input and $20 output. The post does not specify when the introductory period ends.

Budget a trial using both sets of rates. Also record the complete run, including repeated attempts and the time a reviewer spends checking the patch. A token rate cannot tell you the cost of an accepted fix when the number of attempts is still unknown.

Public record: Google — Gemini 4 Carbon announcement, October 28, 2026

The headline security scores measure different jobs

Google DeepMind’s model page lists Carbon at 88.2% on SEC-bench Pro, 54.8% on ExploitGym and 71.0% on CWE-bench. Those figures concern vulnerability finding, exploitation and patching respectively; they are not interchangeable measures of security.

The practical implication is to separate the output you need. A developer investigating a bug needs a reproducible explanation. A reviewer approving a repair needs evidence that the vulnerable behavior is removed without damaging intended behavior. Success at one stage should not silently stand in for the next.

Promptwire has not independently reproduced Carbon’s results. The numbers here are presented as published by Google, with the accompanying methodology used to interpret their scope.

Public record: Google DeepMind — Gemini model performance table

What the evaluation report changes about the comparison

DeepMind’s methodology says results generally use the highest thinking settings and single-attempt scoring unless otherwise noted. It identifies SEC-bench Pro and ExploitGym as self-computed evaluations; CWE-bench results come from Collinear AI’s public leaderboard.

For SEC-bench Pro, Google describes a 183-task JavaScript-engine split from May 2026, using its Antigravity harness and averaging three independent attempts per task. ExploitGym uses a setup without internet access and with mitigations off. Google’s launch post explicitly says the external cybersecurity benchmarks were evaluated without guardrails.

Those conditions make a broad claim such as “it will secure our codebase” too large for the evidence. A benchmark can establish performance on its defined tasks while leaving questions about another language, an unfamiliar repository or a deployed system unanswered.

Comparisons also need the surrounding workflow: model settings, available tools, time limits and acceptance criteria. Changing those alongside the model can change the result. Read a score as an observation under stated conditions, then decide how closely those conditions resemble your work.

Public record: Google DeepMind — Carbon evaluation methodology (PDF) · Google — Gemini 4 Carbon announcement, October 28, 2026

A defensible first trial ends with evidence

For a team admitted to the rollout, start with an isolated copy of a repository it owns and one previously resolved defect. Keep the known repair out of the model’s working material. Ask for a diagnosis, a proposed patch and a focused regression test.

Have a reviewer inspect whether the test fails on the original code and passes after the change. Then check that the test exercises the reported defect rather than merely matching the implementation. Run the project’s relevant existing checks and inspect the diff for unrelated changes.

Record failed attempts, unsupported assertions and places where a person had to intervene. If the agent reports that a check passed, retain the actual check output. If it cannot run a check, the final report should make that gap visible.

This is a proposed evaluation, not a report of testing Carbon. The useful outcome is a repair a reviewer can explain and accept, with evidence connecting the original problem to the final behavior. Google’s release gives eligible teams a new candidate for that process; it does not remove the process.