Gemini 4 Carbon: Google Frontier Model for Long-Horizon Coding and Security

Google announced Gemini 4 Carbon on October 28, 2026, describing it as its strongest frontier model to date, with particular emphasis on cybersecurity and long-horizon capabilities. The announcement positions Carbon as an advance over Gemini 4 Argon, announced roughly two weeks earlier.

The central product claim is persistence: Carbon is designed to continue through complex, multi-step engineering work, including tracing subtle defects across large codebases and producing fixes. Google says internal teams have observed it working on tasks over periods of days. That is a vendor-reported capability claim, not a public, independently reproducible guarantee of unattended operation.

Carbon is not yet a generally available developer model. Google says the initial rollout is to a subset of cyber defenders, with access expanding through the Fairwind Program while safeguards are evaluated. Developers, businesses, and consumers are described as future audiences.

Carbon builds on Argon rather than appearing as an unrelated model family. Google emphasizes improvements in coding, agentic tasks, scientific work, full-stack web development, multimodal understanding, and cyber defense.

Google additionally claims that Carbon more than doubles Argon’s success rate at generating secure code in internal evaluations. That is an internal result; the public announcement does not provide the full test set, sample size, scoring protocol, or confidence intervals needed for an independent reproduction.

The most consequential design target is sustained work across many steps. In a long-running engineering task, an agent must understand a repository, form a hypothesis, inspect relevant files, run tests, interpret failures, revise its approach, and verify the final patch. A model can be strong at isolated code generation yet fail when it must preserve state and make progress after several dead ends.

Google says Carbon is designed to persist through such dead ends and has been observed internally working for days on complex tasks. This should be interpreted as a claim about the model within an agentic environment—not proof that the model alone autonomously completes arbitrary projects. Tool reliability, sandbox design, repository context, test quality, checkpointing, and human review remain essential.

For an engineering evaluation, measure task completion, verified patch correctness, regression rate, tool-call success, recovery after failed commands, time-to-resolution, and human intervention frequency. A final answer that says “fixed” is not sufficient; the agent must demonstrate that the tests and independent checks pass.

Google frames Carbon around three linked defensive stages: discovering vulnerabilities, validating whether a finding is real and exploitable, and fixing the underlying cause. The distinction matters because a high volume of plausible findings can overwhelm security teams if precision is low, while a patch that hides a symptom without fixing the root cause can leave the system exposed.

Google reports 88.2% on SEC-bench Pro for vulnerability discovery, 54.8% on ExploitGym for validation, and 71.0% on CWE-bench for remediation. Google describes these as external benchmark results evaluated without guardrails. These figures should not be read as proof that Carbon is safe to run against arbitrary production systems or that benchmark performance directly predicts real-world security outcomes.

A practical defensive workflow should keep authorization and scope explicit, run analysis in isolated environments, require evidence for each finding, validate fixes with tests and review, and record provenance from discovery through remediation. Human security review remains important, especially for high-impact systems.

Google’s Gemini 4 model comparison page lists Carbon at 59 on Artificial Analysis Intelligence Index v5.0, 70.4% on Vals Index v2.2, 9.6% on SWE-sweep, 61.2% on FrontierSWE 2, and 65.2% on Terminal-Bench 4.0 (Artificial Analysis). It reports 77.4% on Agents’ Last Exam v1.1, 81.5% on OSWorld-2.1, 53.9% on AutomationBench, 72.5% on Chartography, and 96.2 F1 on GraphWalks for the 256K-to-1M-token BFS setting.

Benchmark scores depend on model configuration, prompting, tool harness, budget, dataset version, and scoring rules. Google’s public methodology page should be read alongside the headline results. Independent replication and real-world operational evaluation are still necessary.

Google says Carbon builds on Argon’s layered safety stack, including model training, real-time misuse defenses, prompt-injection resilience, and chain-of-thought monitoring. The announcement highlights several internal safety improvements: successful cheating on Terminal-Bench 4.0 reportedly fell to 0.0%, with attempts to cheat at 0.4%; high-severity misalignment alerts in internal live coding environments reportedly fell by almost 80%; unsupported claims were reduced by approximately half compared with Argon.

Google also reports a 0.0% attack success rate on the Gray Swan Indirect Prompt Injection benchmark, compared with 0.7% for Argon. This means no attacks succeeded in the evaluated test set; it does not prove immunity to prompt injection. Results are bounded by the benchmark’s attack coverage and evaluation conditions.

The announcement says Carbon reduced overreach by 26% and under-service by 29% in internal evaluation. These measures are useful only when their definitions, denominators, and test distributions are understood. Treat them as company-reported indicators, not universal probabilities of safe behavior.

At announcement, Carbon is being made available to a subset of cyber defenders and then gradually to trusted partners through Google’s Fairwind Program. Google says it is participating in the U.S. government’s voluntary pre-release model-testing process and will continue iterating on safeguards before broader access.

The announced introductory API price is $2 per million input tokens and$10 per million output tokens, with cached input tokens discounted by 95% relative to input pricing. Google says the standard price after the introductory period will be $4 per million input tokens and$20 per million output tokens. The announcement does not provide a firm public date for general availability or a confirmed end date for the introductory price.

Do not assume that a public Gemini app, Google AI Studio, or general Gemini API account can call Carbon today. Access is gated during the initial rollout; verify current availability and model identifiers in Google’s official developer documentation before designing an integration.

A meaningful evaluation should test the complete agent system, not just a prompt-response pair. Use a representative codebase and a fixed set of issues with known ground truth. Include bugs that require tracing dependencies, reading tests, understanding configuration, and making changes across files.

Track whether the model identifies the true root cause, produces a minimal patch, passes existing tests, adds useful regression tests, and avoids unrelated modifications. Record the number of tool calls, failed tool calls, recovery attempts, elapsed time, token usage, and human interventions. For security tasks, separately measure finding precision, validated exploitability in an authorized sandbox, patch correctness, and regression risk.

For long-horizon tasks, preserve task state and tool logs so that a run can be replayed. Test interruption, context recovery, tool outages, conflicting repository instructions, and prompt injection in untrusted files. Compare Carbon with Argon and other models under the same harness, budget, tools, and scoring protocol. A single leaderboard score cannot substitute for this operational evaluation.

Carbon’s headline results do not mean it is generally available, universally superior, or safe for unsupervised use. The most impressive cybersecurity benchmark results in Google’s announcement were evaluated without guardrails, while real deployments must account for authorization, misuse controls, false positives, and the consequences of incorrect changes.

The long-horizon claim also depends on the surrounding agent infrastructure. A model that can reason across many steps still needs durable state, reliable tool execution, test environments, permission boundaries, and clear stop conditions. In security workflows, keep the model inside explicitly authorized environments and require independent validation before applying changes.

Finally, distinguish Google’s internal results from external benchmark results and independent evaluations. The announcement gives useful directional evidence, but it does not publish enough detail to reproduce every internal claim.

Gemini 4 Carbon signals Google’s push toward frontier models that can sustain complex engineering workflows and participate in defensive security across discovery, validation, and remediation. The reported benchmark profile is strong, especially on SEC-bench Pro, ExploitGym, and CWE-bench, while the rollout strategy reflects the sensitivity of high-capability cyber tools.

For AI engineers, the most important question is not whether Carbon tops a benchmark. It is whether it can reliably complete long-running tasks with verifiable outputs, recover from tool failures, respect authorization boundaries, and reduce the total cost of engineering work. Until broad access and independent evaluations arrive, treat Carbon as a promising but gated frontier model whose public claims should be tested against real workflows.

A useful next step is to evaluate Gemini 4 Carbon as a complete engineering system rather than as a standalone model. The model, tools, permissions, sandbox, repository context, test harness, and review process all shape the result.

• Separate discovery, validation, and remediation. SEC-bench Pro, ExploitGym, and CWE-bench test different parts of the security lifecycle; a strong score on one should not be treated as evidence of equal performance on the others.
• Reproduce the setup before comparing results. Record the model version, prompt, tool harness, time or token budget, number of attempts, dataset version, and pass@k rule. Without those details, leaderboard comparisons can be directionally useful but not fully apples-to-apples.
• Treat prompt-injection resistance as an operating property, not a permanent model guarantee. Test untrusted README files, issue descriptions, dependencies, generated logs, and web content inside an isolated environment, and keep secrets and write permissions outside the agent’s default reach.
• Require an evidence chain for security work: finding → reproduction in an authorized sandbox → minimal patch → regression test → independent review. This is especially important because the most impressive Carbon security figures are company-reported or evaluated under bounded conditions.
• Measure the economics of verification, not only token price. A cheaper or faster first pass can become more expensive if it increases false positives, review time, rollback risk, or the number of failed tool calls.
• Watch for the next evidence release: broader access, independent replications, public run details, and longitudinal results on real repositories will tell us more about Carbon’s practical value than a single launch-day benchmark table.