Google announced Gemini 4 Carbon on 28 October 2026, targeting demanding software engineering and cybersecurity work while limiting initial access to selected cyber defenders.
The agent-specific claim is persistence: Google says internal teams have watched Carbon continue for days while investigating and patching difficult bugs. That is a company observation, not an independently verified production result for outside customers.
Multi-day execution is the claim to test
A long-running coding agent needs more than a strong answer to one prompt. It must keep track of attempted fixes, interpret test failures and decide when further work is justified. Spending longer on a repository is useful only if the result is correct and remains within the assignment.
Google’s Carbon announcement describes sustained work across large codebases and low-level systems. It does not provide a public, reproducible set of multi-day customer runs establishing their success rate, total cost or required human intervention.
For engineering teams, the unanswered question is not simply whether an agent can stay active. It is whether it can recover from a dead end without broadening its permissions, altering the test to manufacture success or continuing after the useful work has stopped. Those are evaluation questions, not failures AgentsCalling has observed in Carbon.
The independent coding score is not the headline intelligence score
Artificial Analysis places Carbon at 59 on its Intelligence Index v5. Its separate coding-agent evaluation also gives Carbon 59, using high reasoning in Antigravity CLI, compared with 62 for Claude Code running Opus 5.5 at maximum effort. These are two different indexes that happen to give Carbon the same rounded score.
The evaluator reports that Carbon improves substantially over earlier Gemini results but does not lead every kind of coding or knowledge work. It remains behind several rivals on AA-Briefcase, its agentic knowledge-work evaluation.
The model-and-harness combination matters. Our coverage of GitHub’s Fusion orchestration release examines a different approach to allocating model work. Benchmark comparisons should preserve their execution settings rather than treat every result as a model-only ranking.
A stronger aggregate result does not settle reliability
Artificial Analysis also found that Carbon’s hallucination-rate metric on AA-Omniscience worsened relative to Argon, despite a higher overall score on that evaluation. That is not a measurement of failed software patches, but it is a reason to avoid describing the model as uniformly more reliable.
Google separately claims improvements in alignment and unsupported assertions. Different tests measure different behavior; an internal coding assessment and a factual-knowledge benchmark need not move together. Neither establishes that every security finding or completion report can be accepted without checking its evidence.
Security scores come with an important condition
Google reports 88.2% on SEC-bench Pro, 54.8% on ExploitGym and 71.0% on CWE-bench. Its announcement says these cybersecurity evaluations ran without guardrails. They should not be presented as independently reproduced results for the restricted customer deployment.
The operational distinction is straightforward: identifying suspicious code, demonstrating that a defect matters and producing a regression-free patch are separate jobs. Teams need evidence for each stage, not a single aggregate label of “secure.”
Access and pricing do not equal a public launch
Google says access starts with a subset of cyber defenders, followed by additional trusted Fairwind partners. No general-release date is specified. The program’s existing partner membership should not be read as automatic access to Carbon.
Announced introductory pricing is $2 per million input tokens and $10 per million output tokens. Google’s footnote gives later rates of $4 and $20, without an introductory-period end date. Publishing rates does not establish public API availability.
This is separate from Google’s Connected Apps developer preview, which concerns exposing services to Google’s AI experiences. That integration announcement does not grant access to Carbon.
What AgentsCalling would test after obtaining access
Our proposed evaluation would use a disposable repository containing seeded bugs, immutable tests and explicitly forbidden files. It would record validated fixes, regressions, elapsed time, total model costs and human interventions, rather than measuring activity or generated code alone.
A second check would interrupt and resume the work, withdraw a tool permission and require approval before a simulated deployment. The question would be whether the agent preserves useful context while respecting changed boundaries. No Carbon testing has been performed by AgentsCalling.
The substantive news is a stronger candidate for sustained engineering agents, backed by independent benchmark gains but constrained by limited access. Claims of multi-day autonomous work become commercially meaningful only when successful fixes, human effort and operating limits can be measured together.
About Puneet Sharma
Puneet Sharma · Freelance Writer
Puneet Sharma is a freelance writer covering AI agents, automation and the software changing how we work. His coverage at AgentsCalling starts with the questions a reader might ask over a conversation: What does this tool actually do? Where does it fall short? And is it useful beyond the demo? His articles explore new launches, practical workflows and the trade-offs behind giving software more responsibility, with explanations that make room for readers who are still getting familiar with AI.
