Gemini 4 Argon: One 1M-Token Budget, a Continuation Protocol, and a Scorecard That Doesn't Win Everywhere

Google shipped Gemini 4 Argon today, October 13, as the first model in the Gemini 4 family. It is generally available in the Gemini API, AI Studio, Gemini for business, Antigravity, and the Gemini app. Launch pricing is $2 per million input tokens and $10 per million output tokens, with cached input 95% off. After November 30 the price doubles to $4 and $20.

Most of the launch post is customer stories. The parts I care about as someone who runs agent workloads and the infrastructure under them are in two other places: the model card, which has the head-to-head numbers, and the developer guide, which quietly changes the API contract in ways that will break existing harnesses. This post is about those two documents.

What the model card actually says

The architecture section is short. Argon is a large sparse mixture-of-experts transformer with native text, vision, and audio input, trained on TPUs with JAX and Pathways. Google says it is a new model, not a fine-tune of an earlier Gemini. There is no parameter count, no active-parameter count, and no expert count. Knowledge cutoff is March 2026.

Inputs are text, images, audio, video, and PDF. Output is text only. There is no image or audio generation and no Live API support.

The benchmark table compares Argon against GPT-6 Astra, Claude Fable 5.1, and Claude Opus 5.5. All numbers below are Google's, run under Google's published methodology, not independent runs.

Where Argon leads:

Where it trails:

CWE-bench v1 is a tie with GPT-6 Astra at 68.0%.

Two things stand out. First, the long-context number is the real outlier. A 12-point F1 gap on graph traversal between 256k and 1M tokens is much bigger than any of the coding deltas, and it lines up with the product decision to make 1M tokens the headline limit. If your workload is "load a large repo or a pile of documents and reason across all of it," this is the row to test first.

Second, the coding story is split. Argon is ahead on DeepSWE but nine to ten points behind on FrontierSWE v2 and Terminal-bench 4.0. Terminal-bench is the closest of these to what a shell-driving agent does all day, so I would not swap a terminal agent over on the strength of the launch post alone. Run your own traces.

The API contract changed

This is the part that will bite people. Argon replaces separate input and output limits with a single unified budget of 1,048,576 tokens. Input, thinking tokens, function calls, and the final answer all draw from it.

A single request still stops at 65,536 output tokens on a streaming call, or 32,768 on a non-streaming direct HTTP call. To go further you use what Google calls long decode. You set max_output_tokens above that cap, the server returns finish_reason=CONTINUATION with an encrypted continuation_token, and you resend the original request with the token attached. Generation picks up where it left off. You repeat until finish_reason is STOP.

The rules around that loop are strict:

• You resend the original contents, system_instruction, and tools every time. You do not append the partial output to the conversation or send a "please continue" prompt.
• A segment can spend its whole token allowance on thinking and return an empty text part. You keep looping anyway.
• Long decode works only on the v1beta1 endpoint of GenerateContent. It does not work on v1, on the Interactions API, or through the OpenAI-compatible Chat Completions layer. Older SDKs can't follow the token either. Python needs google-genai 2.30.1 or later.
• Each request has a 20-minute time limit.

Several other parameters changed behavior too. thinking_budget and the MINIMAL thinking level now return HTTP 400 instead of being mapped to something close. temperature, top_p, and top_k are silently ignored. frequency_penalty, presence_penalty, and candidate_count return 400. Prefilled model turns are rejected, and a history that ends on a model turn fails validation. Thinking is controlled only with LOW, MEDIUM (the default), or HIGH.

Explicit context caching is gone. Implicit caching kicks in automatically for shared prefixes of 6,144 tokens or more, with durable caching on by default, so static content needs to sit at the front of the prompt.

If you run an eval harness or agent framework that sets temperature=0 and a thinking budget, both will do something different on Argon. One is ignored and the other is a hard error. That's a migration task, not a model-ID swap.

What long decode costs

The developer guide is upfront that each continuation request re-prefills the original prompt plus everything decoded so far. That gets billed as input, discounted by the implicit cache if the requests land back to back within the 15 to 20 minute cache window.

Here is a back-of-envelope example using Google's published prices. It's my arithmetic, not a measured bill. Take a 100,000-token prompt and a 256,000-token output on streaming segments of 65,536:

• Four segments. The re-prefill inputs are about 100K, 166K, 231K, and 297K tokens, roughly 793K input tokens in total.
• If everything after the first request hits the cache, that's about $0.20 for the first prefill plus about $0.07 for the cached re-prefills, at launch pricing.
• The 256K output tokens cost about $2.56.

That comes to roughly $2.80 per call at launch pricing and roughly $5.70 after November 30. The output dominates. The cache discount does a lot of work, though: if your continuation loop stalls past the cache TTL, the re-prefill is billed at full input price and the input share jumps several times over.

There's also an accounting trap for anyone building agents. In the Python SDK, prompt_token_count grows across continuation requests because of the re-prefill. If your harness uses that field to decide when to compact context, it will compact too early. Google says to read initial_prompt_token_count instead and to wait until the whole long decode finishes before compacting.

Google's own guidance is that long decode is for hard math, proofs, the hardest coding tasks, and eval harnesses that would otherwise cut answers off. It isn't for chat, for tool-calling agents that take many short turns, or for anything latency-sensitive, since a long decode can run for minutes. For a tool-heavy agent the unified budget is the bigger concern, because every large tool result and every thinking trace shrinks the room left in a 1M window.

The systems claims worth checking

Two items in the launch post are directly checkable, and both are performance-engineering claims.

Google says Argon helped get a 2.85x end-to-end inference speedup for Gemma 4 E2B on an A100 under vLLM, from about 37,900 to over 108,000 tokens per second, with token parity, and that the changes went upstream as pull requests covering attention tuning and speculative decoding. It also says Argon optimizations cut in-memory session prep time by 40% for long sessions and cold imports by 21% in google/adk-python. Those are Google's numbers, but they point at public code. That's a better test of a coding model than a benchmark row, and I plan to read the diffs.

How I'd approach it

I'd test Argon first on long-context retrieval and repository-scale reasoning, where its lead is largest. I'd hold off on moving terminal-driving agents until I had my own comparison against whatever is running today. Before pointing any harness at it, I'd audit for thinking_budget, sampling parameters, prefilled turns, and explicit cache calls, because the failure modes range from a silent behavior change to a 400 on every request. Budget for the price doubling on December 1 as well.

What Google hasn't published is just as useful to know. There's no parameter count, no active-expert count, and no serving-hardware detail beyond "trained on TPUs." For a sparse MoE at this scale, those are the numbers that would tell us why the 1M-token window holds up as well as GraphWalks suggests. Until they show up, the useful public artifacts are the developer guide and the upstream pull requests.

Anpoo Sivanadi, Staff Software Engineer