Gemini 4 Argon Is Generally Available: Migration Checklist

Gemini 4 Argon became generally available in the Gemini API on October 13, 2026. Google's API changelog lists it under that date as gemini-4-argon, and a post by Koray Kavukcuoglu, Google's chief AI architect, opened it the same day to paid API users, Google AI Ultra and Pro subscribers in the Gemini app, and enterprises. Google Cloud followed on October 13. The introductory price is $2 per million input tokens and $10 per million output tokens until November 30, then $4 and $20 from December 1.

If you read our September 30 record of the Argon announcement, the headline then was that almost nobody could use it. That has changed. What has not changed is the shape of the model underneath, and that shape is why a migration from Gemini 3.1 Pro needs a checklist rather than a find-and-replace on the model string.

Google's developer guide for Argon, which we fetched on October 15, lists nine migration steps from the Gemini 3.x line. Some are cheap to miss and expensive to discover in production: a non-streaming REST request now stops at 32,768 output tokens, explicit caching calls return an error instead of a discount, and sampling parameters you may have tuned for months are silently ignored. This post walks through each one, says who it bites, and ends with the checklist in the order we would run it. Plan eligibility and the three-way comparison with GPT-6.1 Sol and Claude Opus 5.5 are separate posts, linked where they belong.

Two dates matter, and they are a day apart. The Gemini API changelog entry dated October 13, 2026 announces Gemini 4 Argon as generally available under the stable model code gemini-4-argon and points to a separate page for API changes and migration. Kavukcuoglu's availability post, published the same day, lists where it can be used: the API in AI Studio and the Gemini platform for developers and enterprises, Google Antigravity for AI Ultra subscribers, and the Gemini app and AI Mode in Search for both Ultra and Pro subscribers. On October 13 Michael Gerstenhaber, a Google Cloud product vice president, wrote that Argon was available in Gemini for business and through the API in the Gemini platform, under the same model ID.

The second thing to read is the exclusion. Google's pricing page states plainly that Argon is not available on the Free tier or on the Google AI Pro plan. The second half of that sentence is about AI Studio: a Pro subscriber gets Argon in the Gemini app but not as a free API allowance. A developer who prototyped on the Free tier has to attach billing before the model ID resolves. That is a different access picture from Gemini 3.1 Pro Preview, which also had no free tier, so the practical change is small; the surprise comes from Pro subscribers who assume their plan carries over to the API.

The Fairwind Program, which was the whole story on September 30, is still there. Kavukcuoglu's post says the program expands from October 13 to hundreds of additional partners and that cyber defenders can apply on a rolling basis for a version without cyber guardrails. For everyone else, the public model carries those guardrails, and the footnote on the introductory price says it applies to the model intended for public access only.

One failure case from the first forty-eight hours is worth recording. Google Cloud's October 13 post never uses the word "generally available" or "preview"; it says Argon is available for everyone on Google Cloud. The API changelog does use GA. If your procurement process requires a GA designation on the surface you buy through, cite the API changelog, not the Cloud post, and check your own console rather than assuming both surfaces moved on the same day.

Every token price on Argon's pricing page comes in two columns: through November 30, 2026, and from December 1, 2026. The second column is exactly double the first in every row. Standard input moves from $2 to $4 per million tokens, standard output from $10 to $20, and the cached-input rate from $0.10 to $0.20. Output pricing includes thinking tokens, so a request at thinking_level: high bills every reasoning token at the output rate.

Why this matters for a migration: the introductory rate makes Argon look like a like-for-like swap for Gemini 3.1 Pro Preview, which lists $2 input and $12 output for prompts up to 200K tokens. In December it is a different tier of spend. Our post on the $2/$10 price point does the arithmetic on what a default-model budget looks like at that rate; this table is the Argon-specific part.

Three details sit outside the table. There is no long-context price tier: Gemini 3.1 Pro charged more above 200K input tokens, and Argon charges one rate across the whole window. The Contributor tier is a private, invite-only preview whose rows carry the note that data is used to improve Google's products; the other tiers say it is not. And grounding with Google Search is 5,000 free requests a month shared across Gemini 3 and newer models, then $14 per 1,000. A team that moves a search-grounded agent onto Argon does not get a fresh allowance.

The failure case is the obvious one. A budget approved in October on the $2/$10 rate is 50% short of December's bill at the same usage. If the approval cycle is monthly, write the December figure into the request now. Our frontier model price index carries both columns.

This is the change most likely to break a working pipeline, and Google's own pages do not agree with each other about it. The developer guide says a single non-streaming request returns up to 32,768 tokens, down from 65,536 on Gemini 3.x, and that a streaming request returns up to 65,536 tokens per stream. The model page says the maximum output is 65,536 by default for synchronous calls, and up to 1,048,576 with long decode. The same guide's checklist and Google's long decode guide narrow the 32K figure to non-streaming REST calls, with SDK calls at 64K per hop. OpenRouter's catalogue lists 65,536. We quote the guide's split because it is the page that explains the mechanism; if your pipeline depends on the number, test it against your own account rather than trusting either page.

The mechanism is called long decode. Input, thinking and output share one window of 1,048,576 tokens, and an output can run to that window minus the input. Each individual request stops at its cap and may return a continuation_token. The Python SDK from google-genai 2.30.1 and the JavaScript SDK from @google/genai 2.29.1 run the continuation loop automatically by default; REST calls and older SDKs stop at the cap and leave the loop to you. Google's guide also says a hop on a hard task can return empty text with a continuation token, and calls that normal.

Where this bites: any pipeline that pinned max_output_tokens above 32,768 on a non-streaming call and expected a single long document back. On Argon that request returns part of the document with a token, and code written for Gemini 3.1 Pro treats the partial as complete. A report generator, a long translation, a codebase-wide refactor: each of those is a place the old assumption lived. The fix is one of three: upgrade the SDK so continuation is automatic, switch to streaming for the higher per-request cap, or write the loop and check for the token on every response.

One rule to keep in mind: max_output_tokens covers thinking and output across every continuation request, not per hop. Set it for the whole job.

Gemini 3.x offered two kinds of context caching. Explicit caching let you create a cache object with caches.create, reference it by name, and pay a storage fee per hour; implicit caching happened automatically on repeated prefixes. Argon drops the first. Google's guide says cachedContents and caches.create are not supported and return an error, and tells you to remove any cached_content set in the request config. The pricing page says the same in a footnote on every Argon tier: implicit caching only.

What remains is generous in one way and opaque in another. Implicit caching is on by default for prompts of at least 4,096 tokens, and a cache hit is billed at 95% off the input rate, which is the $0.10 figure in the pricing table. You do not control when it fires. A team that built its cost model on explicit caches with known hit rates loses that certainty and gains a cheaper hit when the prefix happens to match.

For comparison, Gemini 3.1 Pro Preview still lists explicit caching with a storage charge of $4.50 per million tokens per hour. If a workload leaned on that, there is no Argon equivalent, and the right move is to restructure the prompt so the stable prefix comes first and exceeds 4,096 tokens.

Four parameters stop doing anything. Google's guide marks temperature, top_p, top_k and candidate_count as deprecated on Argon and says that if provided they are ignored. Not rejected: ignored. A request with temperature: 0 succeeds and samples however Argon samples. That is a different design choice from Anthropic, whose Opus 5.5 returns a 400 on a non-default temperature, and it is the quieter failure of the two. Our census of which models still accept temperature tracks this across vendors.

Reasoning depth moves to a named level. thinking_level takes low, medium or high, and medium is the default. The older thinking_budget still works, mapping to the nearest level and returning a warning. Google's advice is to test your workload at low, medium and high directly. Our inference: because budgets map to the nearest level, a budget of a few hundred tokens and one of several thousand may land on the same level.

The example that shows why this matters: a classification pipeline tuned to temperature: 0.1 for consistency, moved to Argon by changing the model string. Nothing errors. The outputs vary more than before, and the first anyone knows is a drift in downstream metrics a week later. The remedy is boring and necessary: run your eval set at each thinking_level with sampling parameters removed, and pick the level on measured consistency.

Three small items from the guide, each with a hard failure attached. First, timeouts: Google says to set HTTP client timeouts to at least 20 minutes per call. A high-thinking, long-decode request can legitimately run that long, and a default 60-second timeout in a serverless function turns a working request into a retry storm. Second, thought signatures: in multi-turn and function-calling requests, the full conversation history including thought signatures has to be passed back. Drop them and the model loses its reasoning state between turns.

Third, the resume rule. To continue a long decode, you send the original request with the latest continuation token and a higher max_output_tokens. Google's guide states that if you do not raise the limit, the request returns 400 INVALID_ARGUMENT. To start over instead, send the original request with a higher limit and no token. A loop that retries with the same limit will fail on every iteration and look like an outage.

Everything above assumes you chose to migrate. Some teams did not choose and migrated anyway. In our October 15 capture of OpenRouter's catalogue, the alias ~google/gemini-pro-latest points at google/gemini-4-argon; on October 13 it pointed at google/gemini-3.1-pro-preview. Anyone calling that alias through OpenRouter moved onto Argon without a code change, and inherited the 32K non-streaming cap, the ignored sampling parameters and the implicit-only caching above. Google's own changelog lists no gemini-pro-latest change in October; the last alias entry on it is January 21, 2026. This is an OpenRouter observation, not a Google one.

The example is the one we keep writing about in our alias and retirement ledger: a "latest" pointer is a promise that the vendor will change your model for you. The failure case is a pipeline whose outputs got shorter and more variable overnight with no deploy and no error. Pin the dated ID. Argon has one stable code, so pinning is simply writing gemini-4-argon rather than an alias.

A related note on the OpenRouter route itself: it lists Argon at $2 and $10 with a 65,536 completion limit, matching Google's model page rather than the guide's 32K non-streaming figure. Treat the catalogue number as metadata, not as a tested guarantee.

Google's guide ends with its own checklist. Ours reorders it by where the damage is, so the silent failures come before the loud ones. Loud failures (an explicit-caching error, a 400 on resume) announce themselves in staging. Silent ones (ignored temperature, a truncated output treated as complete, a doubled bill) do not.

Two posts carry the questions this one deliberately leaves out. Whether your Google plan includes Argon at all, and at what daily limit, is in our plan-by-plan check. How Argon lines up against GPT-6.1 Sol and Claude Opus 5.5 on price, limits and the benchmarks all three labs published is in the three-way comparison. If the migration touches a production agent and you want a second pair of hands on the eval runs, that is work our AI transformation team does.