By Tsuky 
Google's newest AI model presents an unusual deployment dilemma. Gemini 4 Carbon is particularly capable at identifying software vulnerabilities and determining whether those flaws can be exploited. Those skills are valuable for security teams, but they also explain why the company is restricting initial access.
Carbon arrives only two weeks after Gemini 4 Argon. Google describes substantial improvements in coding, long-horizon agentic work and cybersecurity, alongside changes intended to make the model more reliable when operating autonomously.
Its most prominent general result comes from Artificial Analysis Intelligence Index v5.0, where Carbon scores 59 points against Argon's 50. That places Carbon first on the published version of the index, although the lead is narrow and does not extend to every individual benchmark.
Cybersecurity performance covers three distinct tasks
Google highlights vulnerability discovery, exploit validation and software patching as the central strengths of Carbon.
The model scores 88.2% on SEC-bench Pro, which evaluates the ability to identify security vulnerabilities in real software. Argon achieved 83.4% in Google's comparison.
That improvement matters, but the benchmark result should not be interpreted as a guarantee that Carbon will discover the same proportion of vulnerabilities across arbitrary enterprise codebases.
Real applications include different architectures, dependencies and deployment conditions. Security problems may also depend on environmental behavior that cannot be represented completely by a standardized evaluation.
Carbon reaches 54.8% on ExploitGym, up from Argon's 42.0%. This test examines whether a model can validate the practical exploitability of a vulnerability under the benchmark's conditions.
The difference between discovering a possible flaw and verifying a security risk is significant. Some reported vulnerabilities are difficult to exploit, while others depend on specific configurations or permissions.
On CWE-bench, Carbon scores 71.0%, compared with 68.0% for Argon. The benchmark focuses on producing functioning software patches rather than merely identifying potential problems.
Google also reports more than twice Argon's success rate in generating secure code on selected internal tests. The company notes that its external cybersecurity benchmark results were obtained without the model's guardrails enabled.
These evaluations measure related but different abilities. They should not be combined into a single claim about overall software security.
Long-running engineering tasks are becoming a priority
Carbon is designed to persist through complicated software engineering problems. According to Google, internal teams have observed the model working for days while investigating difficult bugs, exploring unsuccessful approaches and attempting corrections across substantial codebases.
Running for several days is not inherently an achievement. The important question is whether the agent can make progress without wasting resources, violating instructions or incorrectly declaring that the task has been completed.
Google's benchmark results suggest improvement in several relevant areas. Carbon reaches 65.2% on Terminal-Bench 4.0, compared with Argon's 57.1%. On FrontierSWE 2, its score rises from 55.0% to 61.2%.
SWE-sweep increases from 4.3% to 9.6%. That represents a substantial relative gain, while the absolute score illustrates how difficult some long-horizon engineering evaluations remain.
The operational challenge for developers is maintaining the integrity of the entire process. An agent needs to interpret project requirements, work with existing dependencies, run relevant checks and identify failed attempts without silently changing the original task.
Google says Carbon improves at surfacing missing evidence and acknowledging incomplete work. Those claims are based partly on internal development environments rather than a broad public deployment.
Prompt injection resistance receives greater emphasis
An autonomous coding agent may encounter untrusted information in websites, repositories, documents and tool responses. Some of that content can include instructions designed to redirect the agent away from the legitimate user's objective.
These indirect prompt injection attacks are particularly relevant when an AI system can execute code, modify files or interact with external services.
Google reports a 0.0% successful attack rate for Carbon on Gray Swan's Indirect Prompt Injection benchmark, compared with 0.7% for Argon.
The result applies to the evaluated attacks and testing conditions. It does not establish that Carbon is immune to all possible prompt injection strategies or future attacks.
Google also claims an approximately 80% reduction in high-severity misalignment alerts during internal coding tasks. Unsupported claims reportedly occur about half as often as with Argon.
The company says successful cheating on Terminal-Bench 4.0 fell to 0.0%, with attempted cheating reduced to 0.4%.
Such measurements are different from ordinary task accuracy. They address whether a model follows the intended process, reports its limitations and avoids manipulating an evaluation rather than genuinely solving the underlying problem.
Carbon leads one overall index, not every evaluation
Carbon's score of 59 on Artificial Analysis Intelligence Index v5.0 places it ahead of Claude Opus 5.5 at 58 and GPT-6 Astra at 57 in Google's published comparison.
However, some specialized evaluations produce different rankings. Claude Opus 5.5 scores 87.2% on the selected OSWorld-2.1 offline benchmark, compared with Carbon's 81.5%.
GPT-6 Astra also remains ahead on FrontierSWE 2 in the comparison table. Carbon's improvements therefore do not amount to a universal performance advantage.
Google reports 70.4% on Vals Index v2.2, up from 69.2% for Argon. On WebDev Arena, Carbon gains 89 Elo points and reaches fourth place with a reported score of approximately 1,768 at the time of the announcement.
The company has not yet published a complete Carbon API specification equivalent to the existing Argon documentation. Its context limits, maximum output and final supported capabilities should not automatically be assumed to match those of the earlier model.
Why the rollout begins with trusted security teams
Carbon is not generally available through public developer or consumer products at announcement.
Google plans to provide access first to a limited group of cybersecurity defenders, then gradually extend availability to trusted partners through its Fairwind Program.
The company is also participating in the U.S. government's voluntary pre-release testing process and says it will continue refining security safeguards before expanding access.
The staged approach reflects the model's dual-use capabilities. The ability to validate an exploit can help defenders prioritize urgent software fixes, but similar capabilities can also be misused outside authorized security work.
Google has not announced a general availability date for Carbon in Gemini, Google AI Studio or public APIs. Developers should not interpret the announcement as confirmation that the model can already be selected in those products.
API pricing is announced before public access
Google plans to introduce Carbon at $2 per million input tokens and $10 per million output tokens. Cached input tokens will receive a 95% discount against the ordinary input rate.
After the introductory period, the announced rates rise to $4 per million input tokens and $20 per million output tokens. Google has not specified when the promotional pricing period will end.
These prices describe the intended commercial offering, not an API already accessible to every developer.
For long-running software agents, token rates alone provide an incomplete view of operating expenses. An agent may issue repeated model calls, run tests and revisit failed approaches before a task is finished.
A meaningful cost comparison will need to account for completed tasks, total execution time, tool usage and the tokens consumed throughout the workflow.
A model that is more capable on a benchmark does not necessarily produce the lowest cost per successful engineering task. Performance, reliability and resource consumption all need to be evaluated together.
For now, Google has confirmed the benchmark results it is publishing, its intended pricing and the initial restricted rollout. Public API specifications, general availability and independently observed long-term operating costs remain unresolved.