Gemini 4 Argon Architecture: 1M Context & Benchmarks

Most long-context models sell you a large input window and hand back a small output. The Gemini 4 Argon architecture replaces that asymmetry with one pool: 1,048,576 tokens shared by the prompt, the model's internal reasoning, and the text it generates [1]. Google published the model card on 13 October 2026, two weeks after the 30 September announcement that put the model in the hands of vetted cyber defenders first.

For infrastructure teams, the interesting question is not whether the window is bigger than a competitor's. It is what a single shared budget does to retries, to context caching, and to the shape of an agent pipeline. What follows is the Gemini 4 Argon architecture as Google documents it, then the parts that cost money.

What the model card actually states

The published card is short, and it is the only primary description of the gemini 4 argon architecture that Google releases.

Argon is a large-scale sparse mixture-of-experts transformer with native support for text, vision and audio inputs. Sparse routing means a subset of experts handles each token, which is how a model of this size keeps per-token compute within a serving budget. Google does not publish the expert count or parameter totals, so any figure you see quoted elsewhere is an estimate rather than a disclosure.

It is not a fine-tune. The card states plainly that Argon is not a modification or a fine-tune of a prior model [2], which matters when you are deciding whether last quarter's prompt work transfers. Behavioural patterns generally do, but token budgets and failure modes do not.

Training used reinforcement learning over multi-step reasoning, problem-solving and theorem-proving data, on TPUs with JAX and Pathways. That is the mechanism behind the long-decode behaviour: the model was trained to keep working inside one trajectory rather than to answer in a single hop.

The card also lists the channels where the model ships: the Gemini app, the API, AI Studio, Gemini for business, Antigravity, and AI Mode. Live API and image generation are explicitly not supported, which rules Argon out for realtime voice work and for any pipeline expecting it to emit images.

One budget, three phases, one hard constraint

The unified window is the design decision everything else follows from.

Total pool: 1,048,576 tokens
┌────────────────────┬──────────────────────┬─────────────────────────┐
│ input context      │ hidden thinking      │ output (long decode)    │
│ repo, specs, PDFs  │ reasoning tokens     │ code, audits, prose     │
└────────────────────┴──────────────────────┴─────────────────────────┘

Older long-context models accepted a million tokens of input and capped output at 65,536. Argon's synchronous default is still 65,536 output tokens, but the cap is no longer structural. With background execution and max_output_tokens set above 65,536, the model produces a response in hops of up to 64K tokens, each continuing where the previous one stopped, up to the remainder of the window [3]. You poll or stream the interaction and join the model_output steps to reconstruct the answer.

Two consequences follow, and both are easy to miss in a proof of concept.

Long decode requires background: true. A request with background: false stops at 65,536 tokens, and the API returns a 400 if you ask for more. Pipelines built around a synchronous HTTP call cannot use the feature at all, which is why the gateway pattern later in this article matters more than it looks.

The model will not hit a length target. The documentation lists this as a limitation: Argon does not follow token-count or word-count instructions. If your pipeline depends on "write exactly 800 words", that pipeline needs a different model or a post-processing step.

Thinking levels, and the parameters that no longer exist

Argon exposes three thinking levels. medium is the default, and the level governs how much internal reasoning happens before any visible token is emitted.

Google does not publish latency figures per level, and any number you read is somebody's benchmark on their own prompt. Measure yours: run the same twenty tasks at all three levels and compare accepted output, not just wall-clock time.

The migration detail that breaks code is subtler. temperature, top_p and top_k are ignored if you send them [4]. Code that relied on temperature for deterministic extraction now needs structured output and a validation step instead. That is a code change, not a config change, and it belongs in the estimate.

{
  "model": "gemini-4-argon",
  "input": "Audit this middleware for race conditions.",
  "generation_config": { "thinking_level": "high", "max_output_tokens": 65536 }
}

Benchmarks, with the caveats attached

Google's announcement reports four numbers, all vendor-run. They are worth citing precisely because they are the only figures with a primary source.

On DeepSWE v1.1, which measures long-horizon software engineering, Argon scores 77.9%. On CWE-bench v1, which measures vulnerability remediation, it ties for first at 68% [5]. On LVBench, long video understanding, it reports 91.7%. On Zapier's AutomationBench, which tests end-to-end execution across business functions, Argon ranks first at 51.3%.

Read the shape of that set rather than the ranking. Three of the four measure multi-step work with a verifiable end state, which is the workload the model was built for. None of them measures cost per completed task, and none measures how often a long decode has to be thrown away because the plan was wrong at token 40,000. Those are the numbers that decide whether the gemini 4 argon architecture fits your pipeline, and you can only get them from your own traces.

The 51.3% on AutomationBench deserves a second look for a different reason. It is a first place, and it is also a little over half. Benchmarks in this category are hard, and a leader at 51% is a leader in a field where nobody has solved the problem.

Token economics before 1 December

Argon launched on introductory pricing, and the schedule is public [6].

Two details matter more than the headline doubling.

First, thinking tokens bill as output. A high run that spends 30,000 tokens deliberating and 2,000 answering costs like a 32,000-token output, at output rates. That is the real reason to reserve high for work that needs it.

Second, caching is implicit only. Explicit cache creation is not supported on Argon, and implicit caching applies to prompts of at least 4,096 tokens, discounting cached input by 95%. You cannot pin a cache and forget it; you get the discount by keeping the prefix identical across calls. Same system prompt, same tool list, same ordering, every time.

Run the arithmetic on your own workload, because the answer is sensitive to the cache hit rate. Take a 400,000-token repository reviewed twice an hour, 48 times a day, at the December input rate of $4 per million:

• No cache hits: 48 × 0.4M × $4.00 = $76.80 per day, about $2,300 a month in input alone.

• Full cache hits after the first call: 48 × 0.4M × $0.20 = $3.84 per day, about $115 a month.

The gap between those two numbers is a gateway configuration, not a model choice. It is also the argument for putting a proxy in front of the API rather than calling it from application code, where nobody owns the prefix.

The gateway and the sandbox

Two pieces of infrastructure make Argon usable in an engineering organisation.

The gateway sits between your agents and the API. It enforces a stable prompt prefix so caching works, applies per-project token ceilings so a loop cannot run all night, and routes routine work to low or to a cheaper model while reserving high for the hard cases. It also gives you one place to log token counts, which is the only reliable way to see a cost regression before finance does. If you are already tracking cloud spend per workload, FinOps practice transfers directly; the unit is tokens instead of vCPU-hours.

The sandbox is not optional. Argon writes shell commands, installs packages and edits files, which is the point. Running that output on a host with your credentials is how a model mistake becomes an incident. Execute in throwaway containers or microVMs on dedicated capacity, with no default egress, no cloud metadata endpoint reachable, and no production database credentials in the environment. A cloud hosting or AI agent hosting box that exists only to run untrusted code is cheaper than the alternative.

Two operational settings are easy to forget. Client timeouts need to be 15 minutes or longer for hard prompts, or the connection dies before the answer arrives. And conversation state should be kept server-side with previous_interaction_id rather than replayed by the client, which also keeps the cacheable prefix intact.

A short pre-rollout checklist

Five things to settle before Argon reaches a production pipeline.

Confirm the call path is asynchronous. If the code path assumes one request and one response, long decode is unavailable and the 65,536-token ceiling stands.

Measure the cache hit rate on a realistic prompt. Below 50%, the December price change doubles a bill you have not yet measured.

Decide which nodes genuinely need high thinking. Most extraction and formatting work does not, and the difference in cost is not marginal.

Check for temperature, top_p and top_k in existing request builders. They are ignored now, so any determinism they were providing has to come from schema validation.

Verify the sandbox has no route to the host, to cloud metadata, or to production networks. Then verify it again after the first autoscaling change.