AI Model Guides
Gemini 4 Carbon: What Google’s Cybersecurity Frontier Model Actually Means
An evidence-led guide to Gemini 4 Carbon: its announced capabilities, cybersecurity benchmarks, safety claims, pricing, restricted rollout, and a practical evaluation plan.

Gemini 4 Carbon is Google’s newly announced frontier model for long-horizon engineering and cybersecurity work. Google says it improves on Gemini 4 Argon in vulnerability discovery, exploit validation, root-cause patching, agentic coding, and resistance to prompt injection. The important qualification is access: as of October 29, 2026, Carbon is being released first to a subset of cyber defenders and trusted partners through the Fairwind Program. It is not yet a generally available Gemini API model.
This distinction changes how the announcement should be read. The public evidence is a combination of Google’s announcement, a Google DeepMind evaluation page, and selected external leaderboards. The model itself is not yet available for an independent developer test. Google’s benchmark numbers are useful signals, but they are not the same as a neutral, reproducible production evaluation.
Research reviewed October 29, 2026. Benchmark results and safety figures attributed to Google are reported claims; 01Router has not independently run Carbon.
Table of contents
- Gemini 4 Carbon at a glance
- What Carbon is designed to do
- Cybersecurity performance: detection, validation, remediation
- How to read the benchmark table
- Safety, honesty, and prompt-injection resistance
- Pricing, availability, and the missing developer details
- What Carbon could change for engineering teams
- A practical evaluation plan for when access opens
- Limitations and open questions
- Frequently asked questions
- Sources
Gemini 4 Carbon at a glance
| Question | Evidence-led answer |
|---|---|
| What is it? | A Gemini 4 frontier model aimed at long-horizon engineering, agentic coding, science, multimodal work, and cybersecurity defense. |
| Who announced it? | Google DeepMind, in a post dated October 28, 2026. |
| What is the main positioning? | A model that can persist through difficult, multi-step work and help defenders find, validate, and patch vulnerabilities. |
| Is it generally available? | No. Google says the initial rollout is to selected cyber defenders and trusted partners through Fairwind. |
| What are the headline security results? | Google reports 88.2% on SEC-bench Pro, 54.8% on ExploitGym, and 71.0% on CWE-bench. |
| What is the introductory price? | Google says the planned price is $2 per million input tokens and $10 per million output tokens, with cached input 95% below the input price. |
| Is there a public model ID? | Google’s Carbon announcement does not publish a developer model ID or a general API launch date. Do not assume the Argon endpoint works for Carbon. |
The short conclusion is this: Carbon looks most consequential as a security and engineering research release, not yet as a model that ordinary teams can select in production. The value proposition depends on whether its additional persistence and cyber capability survive real repositories, real tool permissions, real review, and real safety controls.
What Carbon is designed to do
Google describes Carbon as a successor built on Gemini 4 Argon. The target is not simply better chat quality. It is sustained work across many cycles: inspect a large codebase, form hypotheses, run tools, hit dead ends, revise the plan, implement a change, and verify the result. Google says its internal teams have seen Carbon run for days on subtle bugs across large codebases and low-level systems. That is an internal observation, not a guarantee that every deployment will maintain a useful task state for days.

The phrase long-horizon matters because agent quality is often limited by the whole trajectory rather than the first answer. A model can write a plausible patch quickly but still fail when it must reconcile contradictory evidence, preserve an undocumented invariant, or recover from a tool error. Carbon’s announced direction is to make the trajectory more persistent and more reliable. Teams should measure that as end-to-end task completion, not as a shorter response or a higher single-turn score.
Google also reports a +89 Elo-point improvement for Carbon on WebDev Arena, placing it at #4 with a score of 1768. Arena scores are comparative and can change as the participant pool and evaluation process change. They should be treated as a directional signal for web-development artifacts, not as a substitute for an acceptance test in your own stack.
Cybersecurity performance: detection, validation, remediation
Carbon’s differentiator is the full defensive lifecycle. Google reports results across three stages:
- Detection: SEC-bench Pro measures whether a system can find real vulnerabilities embedded in software. Google reports Carbon at 88.2%.
- Validation: ExploitGym asks whether a suspected weakness can be demonstrated in a controlled benchmark environment. Google reports 54.8%.
- Remediation: CWE-bench evaluates whether the root cause can be fixed in code. Google reports 71.0%.

This framing is more useful than calling Carbon a “hacking model.” A defender needs to prioritize findings, establish whether risk is real, and produce a patch that does not create a second vulnerability. At the same time, the announcement says these external security evaluations were run without guardrails. A benchmark score therefore does not tell an organization what Carbon will be allowed to do in a controlled product deployment, nor does it answer whether the deployment can prevent misuse.
Security teams should separate four questions:
- Can the model identify a genuine issue rather than a pattern that merely looks suspicious?
- Can it prove exploitability without receiving unnecessary access to live systems?
- Can it generate a patch that preserves behavior and passes independent tests?
- Can the surrounding agent safely constrain tools, secrets, network access, and data movement?
The last question is an application property. A capable model does not make an unsafe harness safe by itself.
How to read the benchmark table
Google DeepMind’s public comparison table places Carbon alongside Argon, GPT-6 Astra, Claude Opus 5.5, and Claude Fable 5.1 across general capability, agentic coding, computer use, knowledge work, multimodal understanding, long context, science, and cybersecurity. The table reports Carbon at 59 on Artificial Analysis Intelligence Index v5.0, 61.2% on FrontierSWE 2, 65.2% on Terminal-Bench 4.0, 81.5% on the offline OSWorld 2.1 subset, 96.2% on the 256k-to-1M GraphWalks subset, and 80.0% on RiemannBench. The same table reports the security scores above.

These numbers require context. Google’s methodology says Carbon and Argon results are generally pass@1, with no majority voting or parallel test-time compute unless noted. The models were evaluated through different harnesses and, for non-Gemini systems, many comparison values come from provider-reported results. Some Carbon scores are self-computed, while other values come from public leaderboards. Google also notes that the GraphWalks long-context subset covers problems with context lengths from 256,000 to 1 million tokens; that is an evaluation slice, not a published promise that every Carbon interface has a one-million-token limit.
The correct interpretation is “strong performance under a stated methodology,” not “the model is universally best.” A benchmark can reveal capability, but it cannot fully reveal cost, latency, tool reliability, data governance, or how often a model should ask for human approval.
Safety, honesty, and prompt-injection resistance
Google says Carbon builds on Argon’s layered safety stack, including training, real-time misuse defenses, prompt-injection resilience, and chain-of-thought monitoring. The announcement reports several internal or benchmark findings:
- successful cheating on Terminal-Bench 4.0 fell to 0.0%, while attempted cheating fell to 0.4%;
- high-severity misalignment alerts in Google’s live coding environments fell by almost 80%;
- unsupported claims were cut by approximately 2x versus Argon in internal testing;
- overreach fell by 26% and under-service by 29% in the reported internal comparison;
- Carbon recorded a 0.0% attack-success rate on the evaluated Gray Swan Indirect Prompt Injection benchmark.

These are encouraging claims, but several limitations matter. Internal alerts depend on Google’s definitions and sampling. A 0.0% result can mean no attacks succeeded in the evaluated sample; it does not prove resistance to every future attack. And the announcement does not provide enough detail for a reader to reproduce every internal result.
For production use, prompt-injection resistance should be tested at the system boundary. Put untrusted text in issue bodies, documents, web pages, source comments, images, and tool output. Then verify whether the agent keeps its instruction hierarchy, refuses unsafe tool calls, protects secrets, and asks for approval when the evidence is ambiguous. Treat model-level safety as one layer in a defense-in-depth design.
Pricing, availability, and the missing developer details
Google says Carbon will launch at the same introductory price as Argon: $2 per million input tokens and $10 per million output tokens, with cached input tokens priced at a 95% discount relative to the input price. After the introductory period, the announcement says the price will become $4 per million input tokens and $20 per million output tokens. It does not give a Carbon-specific end date in the announcement.

As of this review, Google says Carbon is available first to a subset of cyber defenders and will expand to trusted partners through Fairwind. Developers, businesses, and consumers are told to wait for product-surface access. The public Gemini API documentation currently lists Gemini 4 Argon, not Carbon, as the stable Gemini 4 API model. That means teams should not budget Carbon as if it were already selectable through a normal API call.
The missing details are themselves decision-relevant: a public model identifier, API quotas, context and output limits for the developer interface, regional availability, data-retention terms, safety settings, and an independent model card. Re-check Google’s developer documentation before building an integration. A model announcement is not an API contract.
For teams comparing providers, begin with the live catalog in 01Router Gateway, then confirm the exact model identifier, pricing unit, caching behavior, and provider terms before sending production traffic. Use the 01Router documentation to plan routing and fallbacks, and compare the total operating cost on the pricing page. These links describe 01Router entry points; they do not imply that Carbon is currently available through 01Router.
What Carbon could change for engineering teams
If access opens, Carbon may be most useful in jobs where the model’s cost is small compared with the cost of slow investigation or missed defects:
Security triage. A model can help cluster findings, trace a suspicious data flow, propose a minimal reproduction, and draft a patch for a human-reviewed queue. Keep production credentials, destructive tools, and unsandboxed network access out of the default loop.
Large repository maintenance. Long-horizon agents may be a fit for dependency migrations, compiler fixes, cross-module refactors, and tests that require repeated repository exploration. Start with a bounded branch and a disposable environment.
Secure code generation. Carbon’s reported security results make it worth testing against a fixed suite of vulnerable and corrected examples. Measure whether the patch fixes the root cause, preserves functionality, and avoids introducing new findings.
Research and multimodal work. Google includes science, mathematics, computer use, and multimodal understanding in its evaluation scope. For high-stakes domains, keep expert review and provenance requirements explicit; a strong benchmark does not replace qualified judgment.
A practical evaluation plan for when access opens
- Create a frozen task set. Mix ordinary engineering work, security fixes, long-context investigation, and deliberately adversarial inputs. Hold out some tasks so prompts are not tuned to the test set.
- Define acceptance before execution. Require tests, security scans, a human-readable change summary, and evidence for every external claim. Decide which actions need approval.
- Keep the harness constant. Compare Carbon with a baseline using the same repository snapshot, tools, permissions, prompt structure, time budget, and reviewer rubric.
- Run repeated trials. Record success rate, retries, tool failures, elapsed time, input and output tokens, reviewer interventions, and rollback rate. One successful demo is not a distribution.
- Measure cost per accepted task. Include failed attempts, cache behavior, tool costs, human review, and the price after any introductory period. A cheaper token price does not necessarily produce a cheaper completed task.
- Test the security boundary. Include prompt injection, malicious issue text, poisoned documentation, secret exfiltration attempts, and requests to widen permissions. Verify the agent and the harness together.
- Publish a decision record. State where Carbon wins, where it loses, what access it receives, and which tasks remain human-led. Revisit the result when the model, endpoint, or pricing changes.
Limitations and open questions
Carbon’s announcement is timely, but it is not a full independent evaluation. The model is initially restricted, many numbers are provider-reported or self-computed, and the public materials do not yet give developers a complete integration contract. The security scores are particularly easy to overread because they were evaluated without guardrails and may not map directly to a constrained enterprise deployment.
There is also a difference between capability and responsibility. A model that can find a vulnerability may increase defensive capacity, but it can also lower the cost of offensive experimentation. Access controls, audit logs, sandboxing, approval gates, secret isolation, and incident response remain necessary. The safest adoption plan treats Carbon as a powerful component inside a controlled workflow rather than an autonomous security authority.
Bottom line: Gemini 4 Carbon is a significant Google announcement with unusually strong reported cybersecurity results and a clear focus on persistent agentic work. The most defensible conclusion today is not that Carbon has already won the model market. It is that Google has raised the bar for evaluating frontier agents on the complete security lifecycle—and that real teams should wait for public access, then test the entire system against their own acceptance and safety criteria.
Frequently asked questions
What is Gemini 4 Carbon?
Gemini 4 Carbon is a Google DeepMind frontier model announced on October 28, 2026. Google positions it for long-horizon engineering, agentic coding, multimodal and scientific work, and cybersecurity defense.
When will Gemini 4 Carbon be released?
Google has started a restricted rollout to a subset of cyber defenders and trusted partners through the Fairwind Program. The announcement does not provide a general developer or consumer release date.
Is Gemini 4 Carbon available through the Gemini API?
Not generally, based on the public materials reviewed on October 29, 2026. Google’s current developer model documentation lists Gemini 4 Argon as the stable Gemini 4 API model. Verify the live documentation before integrating.
How much will Gemini 4 Carbon cost?
Google says the planned introductory price is $2 per million input tokens and $10 per million output tokens, with cached input tokens 95% below the input price. After the introductory period, the announcement says $4 per million input tokens and $20 per million output tokens will apply.
What are Gemini 4 Carbon’s cybersecurity benchmarks?
Google reports 88.2% on SEC-bench Pro, 54.8% on ExploitGym, and 71.0% on CWE-bench. The figures represent different parts of the defensive lifecycle and should not be treated as a single security score.
Does Gemini 4 Carbon replace security engineers?
No. A model can accelerate investigation and patch drafting, but security decisions require controlled access, independent verification, human accountability, and an operational response process.
Sources
- Google DeepMind: Introducing Gemini 4 Carbon
- Google DeepMind: Gemini model performance table
- Google DeepMind: Gemini 4 Carbon evaluation methodology
- Google AI for Developers: Gemini API models
- Google AI for Developers: What’s new in Gemini 4 Argon