Gemini 4 Argon Is Open to Developers, and the Launch Price Has an Expiry Date

Read the terms before the benchmarks

Three things are settled. The paid tier of the Gemini API is generally available. Google AI Ultra subscribers can reach Argon through Antigravity. And launch pricing is $2 in, $10 out, doubling after November 30, 2026.

If you are scoping a migration that runs across a quarter boundary, your October invoice and your January invoice are not the same shape. I write the date next to the rate, because "we priced it at launch rates" is the sentence that causes trouble in Q1.

A plain example. A month of migration work: 40M input tokens from repo context replayed per file batch, 4M output tokens for rewritten files and explanations. That is $120 at launch rates and $240 after the change. The number is small, but it scales linearly, and long projects are long.

# The launch terms matter more than the benchmark chart, so start there.
# From the Google announcement dated October 13, 2026:
#
#   paid tier of the Gemini API       -> generally available
#   Google AI Ultra subscribers       -> available in the Antigravity agent IDE
#   list price at launch              -> $2.00 / 1M input, $10.00 / 1M output
#   that price is scheduled to double -> after November 30, 2026
#
# Two numbers, one deadline. If you are budgeting a long migration project,
# the January invoice is not the same shape as the October invoice.
# Write the date down next to the rate, because "we priced it at launch rates"
# is the sentence that gets people in trouble in Q1.

python3 - <<'PY'
launch_in, launch_out = 2.00, 10.00
later_in, later_out = launch_in * 2, launch_out * 2

def cost(mtok_in, mtok_out, rin, rout):
    return round(mtok_in * rin + mtok_out * rout, 2)

# A plausible month of code migration work:
# 40M input tokens (repo context, repeated per file batch)
# 4M output tokens (rewritten files, explanations)
for label, rin, rout in (("launch", launch_in, launch_out), ("after Nov 30", later_in, later_out)):
    print(f"{label:14s} ${cost(40, 4, rin, rout):>8,.2f}")
PY

# Output:
#   launch         $  120.00
#   after Nov 30   $  240.00
#
# Double the output tokens relative to input and the gap widens fast, because
# output is five times the price of input. That ratio is the whole story of
# how this model should be used.

The real cost variable is the output share, not the rate

Output costs five times what input costs. That matters more than the headline rate, because it decides which shape of task this model belongs on.

Hold total volume at 50M tokens and change only the mix. Read-heavy at 10% output lands near $65. Balanced at 30% output lands near $250. Write-heavy at 70% output lands near $825. Same model, same price list, 12x difference in the bill.

So my split is boring and deliberate: Argon goes where the output is small and the judgement is hard — reading a diff, planning a migration, triaging a failing test, judging what an old module actually depends on. Bulk code generation goes to a cheaper model plus a compiler, which wins on both axes.

# Here is the part the pricing table hides: output is 5x input.
# $2.00 in, $10.00 out. Any workflow that generates more than it reads
# is paying for the expensive direction.

python3 - <<'PY'
rin, rout = 2.00, 10.00      # launch rates, USD per 1M tokens
ratio = rout / rin
print(f"output:input price ratio = {ratio:.1f}x")

# Compare two shapes of the same job at equal total token volume.
# Shape A: read a lot, answer briefly (classify, route, review a diff)
# Shape B: read little, generate a lot (write a whole module)
total_mtok = 50
for name, share_out in (("read-heavy (10% out)", 0.10), ("balanced (30% out)", 0.30),
                        ("write-heavy (70% out)", 0.70)):
    mout = total_mtok * share_out
    min_ = total_mtok - mout
    print(f"{name:22s} in={min_:.0f}M out={mout:.0f}M -> ${min_*rin + mout*rout:,.2f}")

# Same 50M tokens, 5.6x difference in bill. Model choice is only half the
# decision; the input/output mix is the other half, and you control it.
PY

# Practical rule: use Argon where the output is small and the judgement is hard.
# Diff review, migration planning, test triage. Not for bulk code generation,
# where a cheaper model plus a compiler will beat it on both axes.

A million-token window is not a free buffet

Long context invites a specific mistake: parking 800K tokens of repository context in a conversation and then having a twenty-turn conversation on top of it. You paid for turn one. You keep paying for turns two through twenty.

The arithmetic is blunt. An 800K-token conversation carried for 12 turns bills close to 11.7M input tokens, about $23. Compact to 50K after the first turn and the same session costs under a dollar. The number that surprises people is never the first call. It is the tenth.

What compaction should keep, for a migration job: the target API contract, verbatim, one page. The list of files already converted with commit hashes. The failure patterns hit so far, one line each. Everything else is re-readable from the repository, and you should not pay to keep it warm.

# The million-token context is the feature people will abuse. Context is not
# free even when it fits: every token you send on turn 1 is billed again if
# you keep it in the conversation for turns 2-20.

python3 - <<'PY'
rin = 2.00
ctx_mtok = 0.8          # 800K tokens of repo context, fits fine
turns = 12
growing = sum((ctx_mtok + 0.02 * t) for t in range(turns))
reset_once = ctx_mtok + sum((0.05 + 0.02 * t) for t in range(turns))

print(f"keep full context for {turns} turns : {growing:6.2f}M in  = ${growing*rin:8,.2f}")
print(f"compact to 50K after turn 1        : {reset_once:6.2f}M in  = ${reset_once*rin:8,.2f}")

# The number that surprises people is not the first call, it is the tenth.
# A 800K-token conversation replayed 12 times bills like 9.5M tokens.
# Compaction is not an optimisation, it is the difference between a project
# that fits its budget and one that gets shut off mid-migration.
PY

# What compaction should preserve for a migration job:
#   1. the target-API contract (one page, verbatim)
#   2. the list of files already converted, with commit hashes
#   3. the failure patterns hit so far, one line each
# Everything else is re-readable from the repo. Do not pay to keep it warm.

Same 50M tokens, different input/output mix, 12x difference in the bill.

In migration work the expensive part is irreproducibility

Across a thousand files, the thing that blows up is almost never model pricing. It is the question of which files were converted, by what, and whether the run can resume.

I keep a manifest where every file records three things: source hash, status, and the exact model id used. Resume skips a file only when the source hash still matches. That looks backwards until you hit the afternoon where a half-migrated file has been marked done and nobody notices for a week.

Two properties have to exist before you spend the first dollar: rerunnable, so a killed run restarts without re-paying for finished work, and auditable, so every changed file has a hash, a model and a date. Without both, a cheaper model is not cheaper. It just fails in a different shape.

# The trap that actually costs money in migration work is not price, it is
# non-determinism across a thousand files. You need a manifest that proves
# what was converted by whom, and a way to resume without redoing it.

import json, hashlib, pathlib

MANIFEST = pathlib.Path(".migration/manifest.jsonl")

def fingerprint(path):
    return hashlib.sha256(pathlib.Path(path).read_bytes()).hexdigest()[:16]

def done_set():
    if not MANIFEST.exists():
        return set()
    seen = set()
    for line in MANIFEST.read_text().splitlines():
        if line.strip():
            rec = json.loads(line)
            if rec.get("status") == "ok":
                seen.add((rec["path"], rec["src_hash"]))
    return seen

def record(path, status, model, notes=""):
    rec = {"path": str(path), "src_hash": fingerprint(path), "status": status,
           "model": model, "notes": notes}
    MANIFEST.parent.mkdir(parents=True, exist_ok=True)
    with MANIFEST.open("a") as f:
        f.write(json.dumps(rec) + "\n")

# Resume logic: a file is skippable only if the source hash still matches.
# Editing a converted file invalidates its record on purpose, because a
# re-run must not silently accept a half-migrated file.
skip = done_set()
todo = [p for p in pathlib.Path("src").rglob("*.java")
        if (str(p), fingerprint(p)) not in skip]
print(f"skip={len(skip)} todo={len(todo)}")

# Two properties worth having before you spend anything:
#   - rerunnable: killed mid-run, restart costs nothing already paid for
#   - auditable: every converted file has a hash, a model id and a date
# Without these, a cheaper model is not cheaper. It just fails differently.

A pre-flight list that beats a benchmark chart

Six things. Convert the deadline into a real date in your own timezone instead of trusting memory. Pin the exact model identifier in code rather than a moving alias, and record which id you actually called next to every result row. Prove your output-token share before you commit, because that is the biggest lever you control. Set ceilings — max output tokens, max turns, a hard daily spend limit — because an agent that can loop can loop on a premium model. Agree on the fallback model and its acceptance test now, not when a rate change forces the decision. Keep a ledger.

One more thing worth reading in the original post rather than a summary: Google frames this as a frontier model for cybersecurity defence, and Argon was earlier available through a restricted defender programme before the general developer release. If your workload touches security analysis, the access path differs from the plain API tier.

My own read: launch pricing is a subsidy for early adopters, not a permanent rate. So the useful question is not whether Argon is worth two dollars per million. It is which part of your backlog only Argon can do, and what that part is worth before November 30. If you can answer that, move. If you cannot, get the pipeline, logs and fallback working on a cheap model first.

#!/usr/bin/env bash
# Pre-flight for anyone about to move a real workload onto launch pricing.
# Run this before the first paid batch, not after the invoice.
set -uo pipefail

echo "== 1. what is the deadline in your timezone =="
# Nov 30 2026 pricing change. Use a real date command, not memory.
date -u -v+35d 2>/dev/null || date -u -d "+35 days" 2>/dev/null || echo "check the announcement date yourself"

echo "== 2. pin the model id, do not trust an alias =="
# An alias like a moving 'latest' tag can repoint under you mid-project.
# Record the exact identifier you called, next to every result row.
grep -R "gemini-4-argon" --include=*.py --include=*.ts . 2>/dev/null | head -5 || echo "nothing pinned yet"

echo "== 3. prove the output mix before you commit =="
# The single biggest cost lever is output token share. Log it per request.
echo "required log fields: model, input_tokens, output_tokens, cached_tokens, task_id"

echo "== 4. cap the blast radius =="
# Per-run spend ceiling. An agent that can loop can also loop on a premium model.
echo "set: max_output_tokens, max_turns, and a hard daily spend limit in the console"

echo "== 5. agree on the fallback model now =="
# Decide the cheaper model and the acceptance test BEFORE a rate change forces it.
echo "fallback model: ______   acceptance test: ______   owner: ______"

echo "== 6. keep the receipts =="
mkdir -p .migration/receipts
echo "ledger -> .migration/receipts/\$(date +%Y%m%d)-batch.jsonl"

The cost in migration work is irreproducibility: manifest, hashes, resumability.