Gemini 4 Argon is public: the uses Google reports on day one, and the price that doubles on December 1

Gemini 4 Argon became callable on October 13. The changelog lists gemini-4-argon as generally available, and Google’s announcement arrived with a long list of things the model has already done. Two weeks ago I wrote that the defender build is not the one you will call. Now there is one you can call, with a price that has an end date.

This is a list of the uses Google reports, with where each one comes from. Reported below means a Google post says it happened and I am relaying it. I have not called the model, and none of these runs can be reproduced exactly from what Google published. Before the list, the terms, because several of them are in the docs and not in the announcement.

Who can call Gemini 4 Argon, and on which plan?

Anyone on the paid tier of the Gemini API, and nobody on the free one. The pricing page, which covers API access, says Argon “is not available on the Free tier or on the Google AI Pro plan.” The plans split by surface:

So a Pro subscription lets you chat with Argon and includes no developer access. Building on it takes the paid API tier or Ultra. The last row is the split from the October 1 post, and it is still there: the announcement invites defenders to apply for “access to Argon without cyber guardrails on a rolling basis.”

What does Gemini 4 Argon cost before and after December 1?

$2 per million input tokens and $10 per million output through November 30, 2026, then $4 and $20 starting December 1. On October 1 the introductory rate had no end date. Now it has one, seven weeks out.

Two details the table hides. Thinking tokens are billed as output. And caching is implicit only: the migration page says explicit caching “is not supported on Gemini 4 Argon”, and that the implicit discount applies to prompts of at least 4,096 tokens. The 95% discount depends on a cache hit you cannot request.

The December rate is Opus 5.5’s list price. Anything you move to Argon for the price is a move you re-decide in seven weeks.

What does a long Gemini 4 Argon output cost once long decode re-sends the input?

More than the output rate times the output, because each continuation is billed as a new request over everything so far. The headline limit is “1M unified”: input, thinking and output share one window of 1,048,576 tokens. On the Interactions API a synchronous request still stops at 65,536 output tokens, and per the long-decode page asking for more with background execution off returns a 400. Going past that is long decode: a background run, generated in hops of 65,536 tokens. The same page lists client-side continuation on the GenerateContent API as a separate route, which I leave out here.

Each hop sends your prompt plus everything generated so far back to the model as input, so the same tokens are counted again in every later hop.

Google’s worked example is a 1,000-token prompt that produces 200,000 tokens of thinking and output. It takes four hops, with inputs of 1,000, 66,536, 132,072 and 197,608 tokens. The usage field reports the sum:

total_input_tokens is the sum of every hop's input, not the size of your context.

That sum is 397,216 tokens for a context the same page puts at about 201,000. The docs say the repeated input is discounted 95% by implicit caching, and that you pay for every hop, “including hops that contain only thinking.” Cancelled and failed runs are billed for the work completed.

The arithmetic on that example, mine and not a measured bill: the 200,000 generated tokens cost $2.00 at the introductory rate. The 397,216 input tokens cost about $0.04 if the first hop is billed in full and every later hop’s input gets the cached rate, which is the behavior Google documents. They would cost about $0.79 with no cache hits at all. I include that second figure as a ceiling. So with a small prompt the re-sent input lands somewhere between a rounding error and 40% on top of the output charge.

A big prompt changes the picture. Put a 300,000-token prompt in front of the same output, assume the same four hops, and the summed input is about 1.59 million tokens: roughly $0.73 on the documented behavior, $0.60 of it the prompt’s first uncached pass, and $3.19 at the ceiling, against the same $2.00 of output. All of it doubles on December 1.

Google describes the discount on repeated hop input as automatic and gives no miss rate. I have not run a long decode, so I cannot add one. The number to log is total_input_tokens next to the cached count on your own first run.

What changes in a Gemini 4 Argon request compared with earlier Gemini models?

Five things to check, all from the migration page. The first two change behavior without an error:

• temperature, top_p and top_k are ignored if you send them.
• max_output_tokens is a total for thinking and output together. Google says to raise any limit under 32K to at least 32,768, because Argon can spend more of it on thinking than earlier models did. Per the long-decode page, a run that hits the limit while still thinking can come back with empty text.
• Thinking has three levels, low, medium and high, with medium the default. The page recommends running your evaluation at all three and taking the lowest that passes.
• Client timeouts should be at least 15 minutes, or the request should run in the background.
• Explicit caching calls are not supported, as above.

One more fact for the eval: the model card gives a knowledge cutoff of March 2026.

What did Gemini 4 Argon’s overnight run on Google’s Agent Development Kit ship?

Two of six proposed optimizations. This is the one reported use that publishes its own review record, which is why it comes first. Reported, by three Google Cloud authors on the Google Developers Blog.

The target was google/adk-python, the Agent Development Kit (ADK): roughly 205,000 lines, nearly 800 source files, nearly 17,000 unit tests. A first round of about two hours ran with no repository instructions and missed maintainer conventions, including a change to a public JSON schema. The second round ran unattended for 11 hours, read 12 guideline files before touching code, and proposed six optimizations across 32 files.

Code review rejected four. One was a cache built on a weak reference that could return stale data across sessions, for a 17% gain that showed up only on a synthetic benchmark. One read a private OpenTelemetry attribute that a minor upgrade could break. Two added complexity without moving the end-to-end number. The two that shipped: filtering in-memory session history before copying it, and lazy-loading heavy packages. The post reports about 40% less session-preparation overhead in long sessions and a 21% faster import google.adk.

The run passed all 16,892 open-source tests, and one of its changes still broke 25 internal Google test targets that patched the attributes it removed. The authors list their own caveats. The 40% applies to the in-memory session service only. The benchmark used an instant model and instant tools, so it measures framework overhead. Time from a new process to the first model request stayed flat. The post gives no token count and no cost.

Their summary:

That division of labor is why the workflow worked: the agent explores, the maintainer subtracts.

Which other Gemini 4 Argon uses does Google report?

Six more with enough detail to describe. All six are Google teams reporting on themselves, and none publishes a review record the way the ADK post does.

1. Splitting a Chrome legacy folder. The announcement says Argon helped separate core webpage handling out of a roughly 6-million-line legacy folder inside a 40-million-line codebase, “months of work in weeks.” No count of changes or of what was reverted.
2. Halving the CPU of YouTube’s comments frontend. The Antigravity post says redundant emoji rendering made up nearly 45% of server overhead, and that 12 optimizations followed, with server comment-load latency down 30 ms.
3. Closing a bug backlog. From 134 open reports, Argon closed 97 as stale or duplicate in under three hours, “with documented commit proof”, and sorted the other 37 by owner. Same post.
4. Fortran to Rust. A legacy Fortran codebase rewritten in Rust with a reported 1.8x performance gain. The post names neither the codebase nor its size.
5. An access-control audit. Four critical security bugs found in access-control changes, in code where, per the post, two earlier frontier models “concluded there were zero security holes.” The models are not named, and neither is the build that ran the audit.
6. Finance workflows. Across 80 workflows over seven business days, 15.5 hours of human direction produced about 335 “human-equivalent hours” of validated output. The unit is Google’s.

The same post reports adoption figures I would not count as cases: over 100,000 monthly users of Argon inside Alphabet’s internal Antigravity, agentic code up 35% and post-submit rollbacks down 30% over four weeks.

What do Gemini 4 Argon’s reported uses have in common?

All seven happened inside Google. Where a review step is described at all, a person cut the result afterward, and only the ADK post documents that step. The others cover implementation, triage, an audit and finance work, and say little about who checked the output. The announcement adds a few named outside parties, among them Wiz, Isomorphic Labs and Gamow Labs. Those are still relayed by Google in a launch post.

Two things are missing from every case: what it cost, and which thinking level it ran at. Only the ADK post says how much of the output was thrown away, and it also publishes its prompts, its benchmark method and the merged commit. A reader pricing an 11-hour run has the per-token rates above and no token count to multiply them by.

The ADK ratio is the most useful number in the launch material because it is unflattering. If two of six is what Google’s own maintainers accept from an overnight run on a codebase with 17,000 tests and written guidelines, then review capacity is the first thing to size, before tokens. One run is not a rate, but it is the only one Google published with the rejections counted. The 25 failed internal targets make the same point from the other side: a green public test suite did not cover what the change broke.

Is the public Gemini 4 Argon the build in the benchmark table?

Google does not say, and the model card now shows safeguards on the public side. Its frontier-safety section says Google “cannot rule out” that Argon reaches the cybersecurity threshold in its Frontier Safety Framework and is “applying safeguards” to bring the risk below it. Outside Google, the unguarded build stays with Fairwind partners. The card also reports unjustified refusals down 9.6 percentage points against Gemini 3.1 Pro. That is a comparison with the previous model. It does not tell you how often the public build declines security-adjacent work that the defender build would do.

My October 1 point about the cyber rows stands as written: CWE-bench at 68% describes a model, and the question is still which build. What you can do now is count the refusals on your own tasks.

Whichever build ran it, the table also has rows Google did not lead with. On Terminal-bench 4.0 Argon scores 57.4% against Opus 5.5 at 66.4%, and on FrontierSWE v2 55.0% against GPT-6 Astra at 65.5%. It leads DeepSWE v1.1 at 77.9%, and the 256K-to-1M GraphWalks row at 84.2% against 71.8% for GPT-6 Astra.

Should you test Gemini 4 Argon before the price changes?

Yes, if you already have the eval, and the test is cheaper now than it will be in December. I have not run it, so this is a reading of the docs.

On October 1 I said to build the eval before access so that day one is a model ID swap. Day one has arrived, and the swap has more in it than the ID: sampling parameters that are silently ignored, an output budget that Argon can spend more of on thinking, a timeout to raise. Run the eval at all three thinking levels, as Google suggests, and log input tokens per request, since on long outputs that number stops matching your context size.

Treat the introductory price as a discount on testing. The decision to move a workload should be priced at $4 and $20, because that is what it will cost for most of its life. I pin model versions and fix the metrics in advance so a change is attributable. A price with an end date is a change you can put in the calendar today.

On which seat to try it in, I have only the argument from August: the more agentic model fit the reviewer’s seat better than the worker’s in my setup. Google’s best-documented case is the other shape, a long-running worker with a human reviewer behind it. I have not run Argon in either seat. The ADK post suggests what to measure if you do: of what it proposes overnight, the share your reviewer keeps.