Gemini 4 Carbon: Who Can Use Google's New Cyber Model

On October 28, 2026, Google announced Gemini 4 Carbon and called it its strongest model, with cybersecurity and long-horizon engineering as the headline capabilities. The same announcement says access starts with a subset of cyber defenders and widens through Google DeepMind's Fairwind Program. There is no general-availability date, no API model identifier and no list of regions. If you run a security team, the useful question is not what Carbon scores. It is whether you can get it, and what to use until you can.

This post separates three things the launch coverage tends to blur: what Google actually announced, who can obtain the model under the rules Google publishes, and what the announced numbers mean given that every one of them is Google's own measurement. It then sets out what a security team can do with models that are generally available today.

The pattern is not new. Google's previous flagship, Gemini 4 Argon, followed the same route from vetted defenders to general availability, and we tracked it in our Gemini 4 Argon price and availability post. Across the industry, the vetting programmes that gate cyber models are catalogued in our ledger of every cyber-model vetting programme. Carbon is the latest entry in that pattern, not an exception to it.

The announcement is a Google blog post dated October 28, 2026 with a byline from Koray Kavukcuoglu, Google DeepMind's senior vice president and Google's chief AI architect. Its headline sentence describes Gemini 4 Carbon as Google's strongest model, with state-of-the-art cybersecurity and long-horizon capabilities. The post positions Carbon for sustained agentic work: long engineering tasks that run for days, full-stack web development, and the defensive security lifecycle of finding, exploiting and patching vulnerabilities.

The post does not state a context window, a list of input and output modalities, a model identifier for the API, or a list of supported regions. That matters for planning. A model you cannot name in a request body is not a model you can write a migration ticket for. Our Argon migration checklist exists because Argon eventually got all of those things. Carbon has none of them yet.

The failure case here is the obvious one. A team reads the benchmark table, budgets at the announced price, and schedules a cut-over for November. Nothing in Google's text supports that schedule. The only dated commitment is that access for a subset of cyber defenders starts in the week of the announcement.

Google's post describes three audiences in sequence. First, a subset of cyber defenders, starting the week of October 28. Second, additional trusted partners, reached gradually through the Fairwind Program. Third, developers, businesses and consumers through Google's product surfaces, with the timing given only as soon as possible. The post adds that Google is engaged in the United States government's voluntary process for pre-release model testing, and that it is still gathering feedback and iterating on guardrails before the wider release.

Read that as a sequence with one open gate. The first cohort is chosen by Google. The second is chosen through an application process with published criteria. The third has no mechanism at all yet. A developer waiting for Carbon in the Gemini API is in the third group, and nothing on the page lets them move up.

The Fairwind Program page on the Google DeepMind site is the only published route into the second cohort, so it is worth reading closely. The page describes the programme as giving trusted partners a head start against cyber threats, and names the kinds of organisation it is for: governments and national cyber authorities, critical-infrastructure operators in healthcare, telecoms, energy and finance, and core technology platforms. It says Google works with more than 650 partners worldwide and lists security vendors and consultancies among them.

Applications are vetted. The page says every applicant is checked for a proven record of ethical operations and research, with background checks covering security history and conduct. The application route is to contact your Google Cloud account team; organisations without one are pointed at Google Cloud's getting-started documentation. No processing time is promised beyond answering as soon as Google can.

The conditions matter as much as the eligibility. Permitted dual-use work is limited to authorised threat simulation, reverse engineering and malware analysis for defensive or academic purposes, and the page states plainly that creating malware is not permitted. Partners must use user-level authentication, phishing-resistant multi-factor authentication and access controls, restrict model use to internal security, incident-response or penetration-testing teams, track employee use, and never share or resell access. As retrieved on November 5, 2026, the page describes what partners receive in terms of Gemini 4 Argon and the CodeMender code-security agent; Carbon's phased arrival through the same programme is stated in the launch post, not yet on the Fairwind page.

One failure case is common enough to name. A mid-sized software company with a two-person security team reads “core technology platforms”, applies, and hears nothing. The programme's own examples are national authorities, critical-infrastructure operators and large security vendors. If your organisation is not of that kind, plan on the general release rather than the programme.

Google's post states that Carbon will launch at the same introductory price as Argon: $2 per million input tokens and $10 per million output tokens, with cached input priced at 95% off the input rate. After the introductory period, the post says $4 per million input tokens and $20 per million output tokens will apply. No end date for Carbon's introductory period is given.

Two things follow. First, the announced rate is a statement about the eventual general release, since the cohort that can use Carbon this week is a hand-picked set of defenders and the post says nothing about how they are billed. Second, the full rate is double the introductory rate on both input and output, so any budget built on $2 and $10 is a budget for a promotional window of unknown length. For Argon, Google did publish an end date for the introductory period, November 30, 2026, as we recorded in our Argon pricing post. For Carbon, treat the end date as unknown.

The failure case for pricing is reading the cache discount as a permanent feature. Google ties the 95% figure to the introductory price sentence and says nothing about cached input at the $4 rate. A workload that depends on cheap cache reads, such as an agent re-reading a large codebase on every turn, should be costed both ways until Google publishes the full-rate table. Our frontier model API price index will carry a Carbon row only once a public price page exists.

The announcement carries a long list of results. Every one of them is a figure Google published about its own model, and the post notes that the external benchmarks were evaluated without guardrails, meaning the model readers eventually get may behave differently on the same tasks. Several are also comparisons with Google's own previous model, Argon, which tells you about the generation step and nothing about the field. The table keeps the figures Google states and labels each by what it compares.

Two further claims deserve their own caveat. Google says its Chrome team reported Carbon performing more than ten times better than another lab's large frontier model when generating high-quality patches. The other model is unnamed, the task set is internal, and the multiplier has no denominator a reader can check. Google also reports that Carbon reduced successful cheating on Terminal-Bench 4.0 to 0.0%, cut unsupported claims by roughly half relative to Argon, and reduced high-severity misalignment alerts in internal live coding environments by almost 80%. These are behavioural claims about Google's own systems, measured by Google. The right way to use any of them is as a hypothesis to test on your own tasks once you can run the model, not as a procurement fact. For how to read a vendor's agent benchmark claims generally, our evaluate-before-you-adopt guide sets out the method.

Google gives its reasons in the announcement rather than leaving them to inference, and it is worth keeping to those reasons rather than adding our own. The post describes the approach to rollout as deliberate, says Google is still gathering feedback and iterating on guardrails before wider release, and notes its participation in the United States government's voluntary pre-release testing process. The closing section frames the trade-off directly.

The mechanism Google describes is a feedback loop: an initial cohort of defenders uses the model, Google watches how it is used, and the guardrails are adjusted before the next cohort. The benchmark note that external results were measured without guardrails fits the same picture. The model being evaluated and the model being released are separated by a layer of controls that is still being tuned.

For a reader this means two concrete things. The capability figures describe an upper bound that the released product may not reach on offensive-style tasks, because the guardrails are designed to reduce exactly that. And the timeline is contingent on a process Google does not control entirely, since it involves an external testing programme. Neither is a criticism. Both are reasons not to put a date on your own plan. Across labs, the same structure appears with different names, which is why our OpenAI cyber-defence qualification post reads so much like this one.

The practical answer is that the generally available model is Gemini 4 Argon, which reached general availability in the Gemini API on October 13, 2026 by our record, and that Fairwind partners already receive Argon together with the CodeMender code-security agent and zero data retention when accessed as a managed model on Gemini Enterprise. Google's own pricing for Carbon is explicitly “the same introductory price as Argon”, so a workload costed on Argon today is costed for Carbon tomorrow.

That makes the preparation work the same regardless of when Carbon arrives. Build the evaluation set from your own findings: real vulnerabilities your team has triaged, with known-good patches, so that a new model's claimed patching rate can be checked against cases you understand. Wire the model behind an interface your tools already call, so the change from Argon to Carbon is a string in a configuration file. And decide now which tasks you will not hand to a model at all, because the vetting conditions Google imposes on partners are a reasonable floor for your own policy.

The failure case is the one Google's own guardrail note warns about. A team evaluates an unguarded benchmark score, assumes the released model will match it on red-team tasks, and finds the model declines or under-performs on the work it was bought for. Evaluating on Argon now, with guardrails in place, gives a realistic baseline that the Carbon release can then be measured against.

If you want help building that evaluation and routing layer before the next frontier model lands, it is part of what our AI transformation engagements cover.