Gemini 4 Argon: $2/$10 Intro Pricing and the Chrome Refactor Behind the Launch

Separating the verifiable from the vendor claim

What you can check: the availability date, the surfaces it ships on, the pricing, and the engineering results Google lists item by item in its own blog post. The Vals Index ranking is Google's own statement. The index measures model performance across finance, coding, legal and tax work, so you can go read how it is constructed, but how much "first place" is worth depends on whether you trust the weighting.

The positioning is unusually specific. Google describes Argon as a frontier model for complex workflows across real-world software engineering, enterprise knowledge work and cybersecurity defence, aimed at long-horizon work that needs deep reasoning and structural precision, including code migrations and frontier research. The operative phrase is long-horizon, not faster. That distinction decides how you should use it.

There is one pricing detail people skim past. The $2 and $10 numbers are introductory, and Google states the eventual rates are $4 and $20. So any cost model you build today has to carry both bands. The 95% cached-input discount is the only part of that sheet that genuinely changes an architecture decision.

# The model id is not something to guess. List what your project can actually call
# before you wire anything, then read the model id off the list.
from google import genai

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

for m in client.models.list():
    print(m.name, m.supported_actions)

# Once you have the id, a long-horizon call looks like this. Argon is described as a
# reasoning-first model, so give it room and give it a budget you can explain.
MODEL_ID = "REPLACE_WITH_ID_FROM_MODELS_LIST"

resp = client.models.generate_content(
    model=MODEL_ID,
    contents=(
        "Refactor src/billing into a hexagonal layout behind the existing HTTP "
        "handlers. Do not change public behaviour. List every file you touch."
    ),
    config={
        "temperature": 0.2,
        "max_output_tokens": 65536,
        "system_instruction": (
            "You are working inside a repository you cannot fully see. Before any "
            "edit, state the invariant you are preserving and the command that will "
            "prove it still holds."
        ),
    },
)
print(resp.usage_metadata)
print(resp.text[:2000])

Cache hit rate is the economics of long-horizon work

Cost structure on long-horizon work looks nothing like a chat box. A refactor loop might re-read the same 400,000 tokens of context on every pass and write 60,000 tokens each time. A cold run costs $1.40. With 360,000 of those input tokens cached it costs $0.44. At list price the same run costs $0.88. One task, three prices, a factor of three.

At this price point caching is not an optimisation, it is the switch that decides whether you can run overnight. I have seen plenty of agent pipelines rebuild the entire system prompt and code context on every request, break the cache, and then act surprised at the invoice. Prefix stability is the prerequisite, and prefix stability means you stop shuffling the prompt structure.

One more thing: $10 output against $2 input is a 5x ratio. On this model, making the model talk less is a direct cost lever. Google's own post mentions Argon answers more directly with less hedging, does not repeat itself and skips clichés. That is not just a UX note. At a 5x output premium it is a cost feature.

# Pricing is published as introductory. Model both bands or your budget review
# will be wrong the moment the rates move.
INPUT_INTRO, OUTPUT_INTRO = 2.0, 10.0     # USD per 1M tokens
INPUT_LIST,  OUTPUT_LIST  = 4.0, 20.0     # Google states these are the eventual rates
CACHE_DISCOUNT = 0.95                      # cached input is 95% off

def cost(in_tokens, out_tokens, cached_tokens=0, intro=True):
    pin, pout = (INPUT_INTRO, OUTPUT_INTRO) if intro else (INPUT_LIST, OUTPUT_LIST)
    fresh = in_tokens - cached_tokens
    return (
        fresh / 1e6 * pin
        + cached_tokens / 1e6 * pin * (1 - CACHE_DISCOUNT)
        + out_tokens / 1e6 * pout
    )

# A refactor loop that reads 400k tokens of context three times and writes 60k.
cold = cost(400_000, 60_000)
warm = cost(400_000, 60_000, cached_tokens=360_000)
print(f"cold run  ${cold:.3f}")   # 1.400
print(f"warm run  ${warm:.3f}")   # 0.440
print(f"list-price warm run ${cost(400_000, 60_000, 360_000, intro=False):.3f}")  # 0.880

# Caching is not a micro-optimisation on long-horizon work. It is the difference
# between a loop you can afford to run overnight and one you cannot.

The Chrome refactor: what came out of six million lines

The first case study is Chrome. Argon helped the team separate core webpage handling from a roughly 6 million line legacy folder of browser features inside Chromium's 40 million line codebase, piping multiple clean changes at a time and completing an architectural refactor across hundreds of files. Google's framing is months of work in weeks.

The user-visible consequence is concrete: live webpages can move fluidly between tabs, side panels and floating windows without reloading, which eliminates an entire category of browser crashes. This is a good specimen of long-horizon work, because it is not one committable task. It is hundreds of commits that must not fight each other.

I am not going to repeat months-to-weeks without asking what the denominator was. But the reusable method is obvious: write the invariants down as executable contracts, and re-run them every time you accept a batch. The snippet below fingerprints contracts by exit code and output hash rather than comparing diffs.

# Long-horizon refactors fail in a specific way: the code still compiles, the tests
# still pass, and the public behaviour changed anyway. Compare behaviour, not diffs.
import json, subprocess, hashlib

def fingerprint(cmd: str) -> str:
    out = subprocess.run(cmd, shell=True, capture_output=True, text=True)
    payload = {"rc": out.returncode, "stdout": out.stdout.strip()}
    return hashlib.sha256(json.dumps(payload, sort_keys=True).encode()).hexdigest()[:16]

CONTRACTS = {
    "cli_help":      "python -m billing --help",
    "http_openapi":  "curl -s localhost:8080/openapi.json",
    "sample_invoice": "python -m billing quote --sku A-1 --qty 3",
}

def verify(baseline: dict) -> dict:
    report = {}
    for name, cmd in CONTRACTS.items():
        now = fingerprint(cmd)
        report[name] = {"match": now == baseline[name], "now": now}
    report["all_match"] = all(v["match"] for v in report.values() if isinstance(v, dict))
    return report

baseline = {name: fingerprint(cmd) for name, cmd in CONTRACTS.items()}
print(json.dumps(verify(baseline), indent=2))
# Run this before the agent starts and after every accepted batch of changes.
# "Months of work in weeks" is only good news if the contracts still match.

A six million line legacy folder, broken into hundreds of commits that do not fight each other.

ADK and xTB: one paragraph of intent, a rulebook, and a night

The second case study is closer to native agent usage. The Agent Development Kit team handed Argon a .agents/skills rulebook plus a one-paragraph goal, eliminate framework overhead without breaking existing apps, and let it work autonomously overnight. The changes are now live in google/adk-python: in-memory session preparation time in long sessions dropped 40% and cold imports got 21% faster.

The third is xTB, one of the most-cited open source quantum chemistry packages. After Argon work in Antigravity, molecular structure prediction is up to 2.3x faster and conformer search 1.8x faster, with the changes merged upstream into the official xTB repository.

Both cases share the same input shape: not "optimise this code", but a rulebook, a measurable goal, and a boundary that must not break. That is the only autonomous pattern I have found reliable in my own pipelines. The single most important line in the rulebook is that a change must be measurable, and that the agent stops and reports when it cannot measure.

# The overnight pattern Google described for its own ADK codebase: hand the agent a
# rulebook plus one paragraph of intent, let it work, then review what it produced.
# The rulebook is the part that makes autonomy survivable.
import json, pathlib

RULES = pathlib.Path(".agents/skills/performance.md")
GOAL = (
    "Cut in-memory session preparation time for long sessions without breaking "
    "any existing application. Benchmark before and after. Do not change public APIs."
)

def build_task(goal: str, rules: str) -> str:
    return f"""## Rules (non-negotiable)
{rules}

## Goal
{goal}

## Deliverables
1. A benchmark script that reproduces the baseline on demand.
2. Each change as a separate commit with the measurement it moved.
3. A list of anything you chose not to change, and why.
"""

task = build_task(GOAL, RULES.read_text())
pathlib.Path(".agents/task.md").write_text(task)
print(json.dumps({"task_chars": len(task), "rules_chars": len(RULES.read_text())}))

# Two guardrails worth adding on day one: a hard token/time budget, and a rule that
# the agent must stop and report when a change cannot be measured.

How much weight to give Google's own numbers

Google says internal teams using Argon in Antigravity increased agentic code submissions by more than 35% while reducing code rollbacks by nearly a third. Those two numbers are given together and that matters. More submissions alone is a dangerous claim, fewer rollbacks alone is a suspicious one, and only both together describe shipping more without shipping worse.

The number I trust most is buried in the Gemma paragraph: using Argon with vLLM on an A100 delivered a 2.85x end-to-end inference speedup on Gemma 4 E2B, from about 37,900 to over 108,000 tokens per second, with 100% token parity and zero quality drop, in days rather than months. What is worth copying is not the 2.85. It is 100% token parity as an acceptance condition.

So the gate I set for migration work is: record a baseline, re-run the same fixed corpus, compare failure counts and output-size drift, and require both to pass. Fixed corpus is the important part. You cannot let the set of files the agent happened to touch define the scope of your verification.

# A migration gate for "we moved a lot of files and it still works". Run it on a
# fixed corpus, not on whatever the agent happened to touch.
import subprocess, statistics

def run_suite(entry: str, corpus: list[str]) -> dict:
    lat, failures = [], 0
    for case in corpus:
        p = subprocess.run([entry, case], capture_output=True)
        if p.returncode != 0:
            failures += 1
        lat.append(len(p.stdout))
    return {"failures": failures, "out_bytes_median": statistics.median(lat)}

def gate(before: dict, after: dict, allowed_new_failures=0, max_size_drift=0.10):
    drift = abs(after["out_bytes_median"] - before["out_bytes_median"]) / max(1, before["out_bytes_median"])
    return {
        "no_new_failures": after["failures"] <= before["failures"] + allowed_new_failures,
        "output_stable": drift <= max_size_drift,
        "ship": after["failures"] <= before["failures"] + allowed_new_failures and drift <= max_size_drift,
    }

before = run_suite("./bin/render", [f"cases/{i}.html" for i in range(200)])
after  = run_suite("./bin/render", [f"cases/{i}.html" for i in range(200)])
print(gate(before, after))
# Google reports a 2.85x inference speedup on Gemma 4 E2B with 100% token parity.
# Parity is the claim worth copying into your own process, not the multiplier.

Copy the acceptance condition, not the multiplier.