Google Announces Gemini 4 Carbon: Coding, Cybersecurity and Restricted Access

Google [announced Gemini 4 Carbon on October 28](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon/), describing gains in coding, sustained engineering work and cybersecurity. The company calls it its strongest model. Its reported results are not independent sAIgnals tests.

An announcement with a staged rollout

The first cohort comprises selected cyber defenders, with additional trusted partners to follow through Fairwind. Broader developer, business and consumer access is planned; the announcement gives **no general-release date**. [Source: Google announcement](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon/)

Fairwind is a reviewed access program, prioritizing organizations such as governments, critical-infrastructure operators and core technology platforms. Google directs applicants to their Cloud account team. Its program page still describes Argon, so it should not be read as confirmation that every existing Fairwind participant already has Carbon. [Source: Fairwind scope and application process](https://deepmind.google/fairwind-program/)

Announced pricing

Google lists introductory rates of **$2 per million input tokens and $10 per million output tokens**, with cached input discounted by 95%. After the introductory period, rates become **$4 and $20** respectively. The announcement supplies no end date for that period. These are announced prices, not evidence of unrestricted API access. [Source: pricing and footnote](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon/)

What coding teams can prepare now

The practical next step is an evaluation plan rather than a production migration. When eligible access arrives, compare Carbon with your current agent on the same repository snapshots, issue descriptions and acceptance tests. Suggested tasks include tracing a regression across modules, drafting a narrowly scoped patch and checking whether that patch fixes the original failure.

Record accepted changes, reviewer corrections, elapsed time and total billed usage. Keep vulnerability testing within systems you own or are authorized to assess. A strong benchmark result is a reason to investigate a tool; it does not tell you how much supervision your repository will need.

For teams outside the initial cohort, track the official model catalog and future access announcements before choosing an API identifier or committing to a rollout date. Avoid building an integration around an inferred model name.