Gemini 4 Carbon vs Argon: API Access, Pricing and Code

Gemini 4 Carbon is Google's newest frontier model, announced on 28 October 2026, and a lot of developers are now asking the same three things: can I call it, what will it cost, and should I wait for it or build on Gemini 4 Argon? The short answer is that you can't call Carbon from the Gemini API yet, it will launch at the same introductory price as Argon, and Argon is available today. In this guide I go through what Google has actually published, how Carbon and Argon compare on Google's own numbers, what a typical task costs before and after Argon's intro pricing ends on 30 November, and how to write your code so that moving to Carbon later is a config change plus an eval run.

What Google announced on 28 October

Google's Gemini 4 Carbon announcement calls it "our strongest model with state-of-the-art cybersecurity and long horizon capabilities". The post builds on Gemini 4 Argon, which launched two weeks earlier on 13 October.

The main points for developers:

• Carbon is aimed at long-horizon engineering work. Google says it has run for days on tasks like root-causing bugs across large codebases.
• Most of the headline results are about security: finding vulnerabilities, checking whether they can be exploited, and writing the patch.
• Pricing at launch matches Argon's introductory price: $2 per million input tokens, $10 per million output tokens, and cached input at 95% off. A footnote says $4 input and $20 output per million apply after the introductory period. No end date for Carbon's intro period is given.

Who can use Gemini 4 Carbon right now

Not most of us. According to the announcement, Carbon is going to "a subset of cyber defenders" starting the week of 28 October. Google will then phase access to more trusted partners through its Fairwind Program, and only after more feedback and guardrail work will it reach "developers, businesses, and consumers via our product surfaces as soon as possible". There is no date for either step.

The Gemini API docs agree. On 30 October the models page lists one Gemini 4 model, Gemini 4 Argon (gemini-4-argon). Carbon does not appear on the models page, the pricing page, the release notes or the Interactions API list of supported models. Google has not published a Carbon model ID, so I won't guess one, and you shouldn't hardcode one either.

Gemini 4 Carbon vs Argon: what Google's numbers say

Every figure below is from Google's two announcement posts or the Argon docs. They are vendor-reported, several come from internal benchmarks, and Google notes the external security benchmarks for Carbon were run without guardrails. Treat them as direction, not as a result for your workload.

Carbon is the same family pushed further on long agent runs, security work and honesty. If you build a coding agent, a code review bot or anything near vulnerability work, test Carbon the day you get access. For a chatbot, document extraction or a support assistant, Argon is already plenty, and the Argon docs suggest starting at the default medium thinking level.

Where Claude Opus 5.5 fits

People search "Gemini 4 Carbon vs Opus 5.5", but Google's post does not compare Carbon with Opus 5.5 by name. Its only cross-vendor claims are the leaderboard ranks above and a Chrome team report that Carbon did "more than 10X better than another lab's large frontier model" on patch quality, without naming the model.

What I can compare is list price. Anthropic lists Claude Opus 5.5 at $4 input and $20 output per million tokens, with cache reads at $0.20, a 1M context window and 128K max output. That matches Argon's price from 1 December and Carbon's announced post-intro price, so per-token price is a wash. The real difference is how many tokens each model spends on your task, which only your own eval shows. I covered how Opus 5.5 differs from Sonnet 5.5 in my Claude 5.5 migration post.

Is there a Gemini 4 Pro?

No. On 30 October the Gemini API models page lists Gemini 4 Argon as the only Gemini 4 model. The newest model with "Pro" in the name is Gemini 3.1 Pro, still a preview (gemini-3.1-pro-preview). The confusion probably comes from the Gemini app: Argon is available there to Google AI Ultra and Pro subscribers, and Pro is a subscription plan, not a model.

Gemini 4 Carbon price and Argon price, before and after 1 December

Here is Argon's standard paid-tier pricing from the pricing page. Carbon's announced launch price is the same.

Two details change the maths. Thinking tokens are billed as output, so a higher thinking_level costs more. And Argon does not support explicit context caching; it uses implicit caching, which applies to prompts of at least 4,096 tokens and gives 95% off on cache hits.

Cost per task: a worked example

Two jobs I see often in client work:

Task A, a code review step in an agent. 40,000 input tokens, of which 30,000 are a repeated system prompt and repo context that hit the implicit cache, 10,000 uncached, and 6,000 output tokens including thinking.

• Until 30 Nov: 10,000 x $2/1M = $0.0200, plus 30,000 x $0.10/1M = $0.0030, plus 6,000 x $10/1M = $0.0600. Total $0.0830.
• From 1 Dec: 10,000 x $4/1M = $0.0400, plus 30,000 x $0.20/1M = $0.0060, plus 6,000 x $20/1M = $0.1200. Total $0.1660.

Task B, a support reply. 3,000 input tokens (under 4,096, so no implicit caching) and 800 output tokens.

• Until 30 Nov: 3,000 x $2/1M = $0.0060, plus 800 x $10/1M = $0.0080. Total $0.0140.
• From 1 Dec: 3,000 x $4/1M = $0.0120, plus 800 x $20/1M = $0.0160. Total $0.0280.

The Opus column uses the same token counts only to show that list prices match. In practice each model uses a different number of thinking and output tokens, and Anthropic also bills cache writes, so measure your real token usage. If you want the method in more detail, I wrote it up in LLM API pricing compared by cost per task.

Build on Argon today with the Interactions API

Google's docs recommend the Interactions API for new projects, and the Argon guide uses it in every example. I tested the code below against google-genai 2.34.0 for Python and @google/genai 2.32.0 for TypeScript, both released on 29 October (Python release, JS release). The model ID comes from GEMINI_MODEL, and a 403 or 404 on the configured model falls back to Argon.

Python

import os

from google import genai
from google.genai.interactions import Interaction

# The model is configuration, not code. Switching to Carbon later means
# changing GEMINI_MODEL, after the eval gate below passes.
MODEL = os.environ.get("GEMINI_MODEL", "gemini-4-argon")
FALLBACK_MODEL = os.environ.get("GEMINI_FALLBACK_MODEL", "gemini-4-argon")
THINKING_LEVEL = os.environ.get("GEMINI_THINKING_LEVEL", "medium")  # low | medium | high

client = genai.Client()  # reads GEMINI_API_KEY from the environment


def ask(prompt: str, model: str = MODEL) -> str:
    try:
        result = client.interactions.create(
            model=model,
            input=prompt,
            store=False,  # Interactions API stores requests by default
            generation_config={
                "thinking_level": THINKING_LEVEL,
                "max_output_tokens": 32768,
            },
        )
    except Exception as e:
        # Interactions errors carry status_code; older SDK errors use code.
        status = getattr(e, "status_code", None) or getattr(e, "code", None)
        # 403/404 usually means this project cannot use the model yet.
        if status in (403, 404) and model != FALLBACK_MODEL:
            return ask(prompt, FALLBACK_MODEL)
        raise
    if not isinstance(result, Interaction):
        raise TypeError("expected a non-streaming interaction")
    return result.output_text or ""

One thing I found while testing against a local mock server: in 2.34.0, a 404 from client.interactions raises a NotFoundError with a status_code attribute, not google.genai.errors.ClientError. A plain except errors.ClientError would miss it, so the code reads the status generically.

TypeScript

import { GoogleGenAI } from "@google/genai";

// The model is configuration, not code.
const MODEL = process.env.GEMINI_MODEL ?? "gemini-4-argon";
const FALLBACK_MODEL = process.env.GEMINI_FALLBACK_MODEL ?? "gemini-4-argon";
const THINKING_LEVEL = (process.env.GEMINI_THINKING_LEVEL ?? "medium") as
  | "low"
  | "medium"
  | "high";

export const client = new GoogleGenAI({}); // reads GEMINI_API_KEY

function httpStatus(err: unknown): number | undefined {
  const e = err as { status?: unknown; status_code?: unknown };
  const s = e.status_code ?? e.status;
  return typeof s === "number" ? s : undefined;
}

export async function ask(prompt: string, model = MODEL): Promise<string> {
  try {
    const interaction = await client.interactions.create({
      model,
      input: prompt,
      store: false, // Interactions API stores requests by default
      generation_config: {
        thinking_level: THINKING_LEVEL,
        max_output_tokens: 32768,
      },
    });
    return interaction.output_text ?? "";
  } catch (err) {
    const status = httpStatus(err);
    // 403/404 usually means this project cannot use the model yet.
    if ((status === 403 || status === 404) && model !== FALLBACK_MODEL) {
      return ask(prompt, FALLBACK_MODEL);
    }
    throw err;
  }
}

What changes when you move an existing app to Argon

From Google's Argon migration checklist:

• Set max_output_tokens to at least 32,768. Argon can spend more of the limit on thinking than earlier models.
• Test low, medium and high thinking levels and keep the lowest one that passes your quality bar.
• Remove cachedContents and caches.create calls. Explicit caching is not supported on Argon.
• Drop temperature, top_p and top_k. Argon ignores them.
• Raise HTTP timeouts to at least 15 minutes, or use background execution, because hard prompts can take several minutes.
• For outputs over 64K tokens, use background: true with max_output_tokens above 65,536.

Make the model a config value, then gate the switch

When Carbon reaches the API, I don't want the switch to be a code change. With the setup above it is two environment variables: GEMINI_MODEL set to whatever ID Google publishes, and GEMINI_FALLBACK_MODEL=gemini-4-argon. The part people skip is checking that the new model is actually better on your own prompts before you flip it in production. A small eval gate does that:

import json
import sys
from collections.abc import Callable

from gemini_client import ask

# Each case: a prompt plus a check your current model already passes.
Case = tuple[str, Callable[[str], bool]]

CASES: list[Case] = [
    (
        'Return only JSON: {"total": <sum of 120.50 and 79.50>}',
        lambda out: json.loads(out.strip().strip("`").removeprefix("json")).get("total") == 200,
    ),
    (
        "Which HTTP status code means Too Many Requests? Answer with the number only.",
        lambda out: out.strip() == "429",
    ),
]


def pass_rate(model: str) -> float:
    passed = 0
    for prompt, check in CASES:
        try:
            passed += check(ask(prompt, model=model))
        except Exception:
            pass  # a crash or bad JSON counts as a fail
    return passed / len(CASES)


if __name__ == "__main__":
    baseline, candidate = sys.argv[1], sys.argv[2]
    base, cand = pass_rate(baseline), pass_rate(candidate)
    print(f"{baseline}: {base:.0%}  {candidate}: {cand:.0%}")
    sys.exit(0 if cand >= base else 1)  # non-zero exit blocks the config change

Run it in CI as python eval_gate.py gemini-4-argon <new-model-id> and only change GEMINI_MODEL if it exits 0. Two cases are only a start. I aim for 20 to 50 cases from real traffic, plus a cost check from each interaction's usage numbers, since a model that passes more cases but burns three times the thinking tokens may not be worth it.

What I would do this week

• Build new Gemini features on gemini-4-argon through the Interactions API, with the model ID in config.
• Set store explicitly on every request and decide whether you need server-side state.
• Re-run your cost estimate at $4 / $20 per million tokens before 1 December.
• Move batch-friendly jobs to Batch or Flex.
• Write 20 or more eval cases from real traffic now, so the Carbon switch is a test run, not a guess.
• Watch the Gemini API release notes for a Carbon model ID, and don't hardcode one until it appears there.