Gemini 4 Argon Ties Opus 5.5 — But Costs 50% More Per Task

Gemini 4 Argon is here. Google describes it as a sparse mixture-of-experts model built on an entirely new architecture, not a fine-tune of an older model. On Cursor's coding benchmark, it's essentially tied with Claude Opus 5.5: 52.8% vs. 52.5% under default settings. But one counterintuitive data point stands out: Argon's per-million-token price is only half of Opus's, yet its bill for completing the same task is about 50% higher. The logic behind this deserves a fresh look from every team building agents on APIs.

What Argon Is: A New Architecture and Three API Changes

Argon is Google's first Gemini 4-series model, with a context window of roughly one million tokens. Google hasn't disclosed the parameter count, only that it uses a sparse mixture-of-experts architecture. Pricing is currently $2 per million input tokens and $10 per million output tokens — the same tier as Sonnet 5.5 and GPT 6.1. On December 1, prices rise to $4.20, aligning with Opus.

Three API design decisions matter most to developers. First, input, thinking, and output share the roughly one-million-token budget. A normal call returns at most about 65K tokens; with background mode enabled, the server keeps going in 64K chunks, pushing a single response up to nearly a million tokens — at the cost of latency, since hard prompts may take several minutes. Second, thinking is always on, with low, medium, and high levels (medium by default), the temperature parameter is ignored, and thinking tokens are billed as output. Google explicitly warns that it may consume more budget on thinking than older models. Third, explicit caching is gone, so agent code that relies on creating caches must be reworked. In its place is implicit caching: as long as requests share a prefix, cached input gets a 95% discount.

A sparse mixture-of-experts (MoE) architecture is built around "compute only what you need": the model contains a large number of expert subnetworks, but each forward pass activates only a small subset (usually via top-k routing). Total parameter count can therefore be huge while per-inference compute is far lower than a dense model of the same size. This is exactly what lets Argon maintain usable latency at million-token context. Sparsity also brings engineering challenges — expert parallelism requires cross-device communication, and uneven routing can overload some experts. Meanwhile, "total parameters" and "active parameters" mean different things: the former affects memory footprint, the latter determines inference compute, so you can't compare models on total parameter count alone.

Implicit prompt caching and the explicit caching mentioned above are two different engineering paths. Explicit caching requires developers to create cache objects and manage their lifecycle and TTL — fine-grained control, but tightly coupled code. Implicit caching has the server automatically detect identical prefixes at the start of a request and apply the discount on a hit, with no code changes needed. The tradeoff: the prefix must match token for token — any dynamic content in the system prompt (timestamps, usernames, random IDs) appearing in the prefix invalidates everything after it. That's why the article stresses "if cached tokens are always zero, fix your prompt prefix first," and why one tester saw invalidation multiply costs several times over.

Google's Self-Report and One Independent Reproduction

Among Google's examples, the most practical is pointing Argon at its own ADK Python agent (roughly 200K lines of code). Argon ran unattended for 11 hours and proposed six optimizations; two were adopted and shipped, cutting long-session setup time by about 40%, while the other four were rejected in human review.

Independent testing tells another side. Developer Paddo replayed six real changes on a production monorepo, running each model 20 times and scoring with the original tests. Argon passed all 16 of its runs; Opus passed 13, and Argon never broke a previously passing test. But on token consumption, Argon produced 2.8x the output tokens of Opus, with a bill of $58 vs. $46. Cursor's observation is similar: about 2.7x the tokens for the same score. Results aren't consistent, though — Theo (T3.gg) reported that in real coding it "hallucinates badly about how systems work," while coding agent Klein said Argon uses about 30% fewer tokens than Claude models.

"Reasoning tokens" are the internal reasoning a model generates before giving its final answer. They aren't shown to users directly, but in API billing they usually count on the output side, since they consume the same decoding compute. Thinking levels (low/medium/high) essentially cap the length of the reasoning chain: higher levels mean more self-checking and backtracking, which is pure waste on simple tasks but can be decisive on hard ones. This explains an apparent contradiction in the article — on the same problem, a higher level scores better but costs more, and "keep the lowest level that passes" is the standard way to trade pass rate for cost. Also, thinking always being on and temperature being ignored means sampling randomness is compressed, so variance across repeated runs on the same input shrinks — something that directly affects scoring stability when reproducing tests.

Rankings Depend on Who's Testing: No Single Winner

In its launch table, Google runs Argon at the highest thinking level while mixing lab data and public leaderboards for other models — and omits Sonnet 5.5 and GPT 6.1, which are currently priced the same as Argon. Independent leaderboards fill those gaps: Val's AI, running Terminal Bench 4 under a unified agent, gives Argon 57.6, Opus 65.2, and Sonnet 64.1; Proximal's Frontier SWE, with 20 hours per task, gives Argon 55 and Astra 65.5. But Argon ranks first on Val's Index of Professional Work, and Artificial Analysis rates it on par with GPT 6 Astra. The conclusion is scenario-dependent: Argon leads on long calls and knowledge work, Claude dominates terminal-style benchmarks, and Astra leads Frontier SWE.

Don't Compare Price Per Token — Compare Cost Per Merged PR

The genuinely actionable advice is to switch metrics: stop comparing price per token and start comparing "cost per merged fix." Concretely, pick 5 to 10 PRs your team has already merged, replay each on a clean snapshot, and score with the tests submitted alongside the fix. Run Argon at low, medium, and high levels, and keep the lowest level that passes — which is also Google's own recommendation. Record pass rate, output tokens, and cached tokens. If cached tokens are always zero, fix your prompt prefix first; one tester saw prefix invalidation inflate costs more than sixfold. Finally, run the same PRs against your current model and finish the comparison before the December 1 price increase.

Argon is a genuine frontier model, and million-token output is something new. But the sticker price is per token, and the bill is per task.

One-line Summary

Gemini 4 Argon matches Opus 5.5 on performance, but higher token consumption makes its cost per task 50% higher.

Paragraph Summary

Google releases Gemini 4 Argon on a new sparse MoE architecture with roughly one-million-token context, nearly tying Claude Opus 5.5 on Cursor's coding benchmark (52.8% vs. 52.5%). Yet Argon, at half the per-million-token price, bills about 50% more to complete the same task, because output token consumption is 2.7 to 2.8x higher. Three key API changes: input, thinking, and output share a million-token budget with background chunked mode; thinking is always on, has three levels, is billed as output, and ignores temperature; explicit caching is removed in favor of implicit prefix caching with a 95% discount on hits. Independent tests show higher pass rates but bigger bills, and rankings depend heavily on the tester: Claude leads terminal benchmarks, Astra leads Frontier SWE. The article recommends teams adopt "cost per merged PR" as their metric and complete their own PR replays before the December 1 price increase.