Gemini 4 Argon: strong scores, uneven coding results

Google announced Gemini 4 Argon on 30 September 2026, and its coding results give me reasons to test it rather than switch immediately. Argon leads Google’s DeepSWE comparison but trails Astra and Opus on other coding tests. The launch also raises the output limit to one million tokens, with access starting through a restricted cyberdefense program. [1] [2]

What do the Gemini 4 Argon coding benchmarks show?

Argon wins the DeepSWE comparison, but Google’s own launch table shows that the lead changes with the coding task. I would put it on a shortlist for repository work without treating it as the automatic replacement for Astra or Opus. The three rows below explain why. [2]

On DeepSWE v1.1, Argon reaches 77.9%, ahead of Astra at 74.1% and Opus 5.5 at 74.2%. That is a useful result for software work. But FrontierSWE v2 puts Astra at 65.5% against Argon’s 55.0%, while Terminal-bench 4.0 puts Opus at 66.4% against Argon’s 57.4%. These are percentage-point gaps of 10.5 and 9.0, calculated from the published scores. [2]

The difference matters because “best at coding” is too broad a conclusion for this table. Fixing a bounded problem and completing a long assignment can demand different things from an agent. The results suggest that the task should determine the model I test first, which is the same practical distinction I make in why AI benchmarks miss model quality.

Argon’s stronger results also extend beyond coding. Google lists 51.3% for Argon at High on AutomationBench, compared with 41.4% for Astra at Max and 42.5% for Opus 5.5 at Max with default fallbacks. In Zapier’s evaluation, a refused step is routed to the provider’s default fallback model. That makes automated workflows worth investigating, but a result on that benchmark does not erase the weaknesses visible in the coding rows. [2] [11]

Why do the coding benchmarks disagree?

The benchmarks measure different work, and Google’s comparison also combines results obtained through different evaluation methods. The model is only part of the system being scored: its instructions, tools and time budget can change the outcome. Google’s evaluation report provides the details needed to read the launch table. [3]

For DeepSWE, Google evaluated Argon using the mini-swe agent harness, the software that gives the model its tools and runs the task. Its competitor figures come from the benchmark leaderboard or the vendors’ system cards. Google generally reports its own scores using the highest thinking level, with pass@1 measuring success in one attempt and no majority vote across parallel answers. That general rule has exceptions, so it cannot be applied to every row. [3]

DeepSWE’s test quality also deserves attention. In its 7 September 2026 audit, Epoch AI found errors in at least 23 of the benchmark’s 113 tasks, where valid solutions could be marked as failures. That audit does not establish that Argon’s score is wrong, but it gives me a reason to treat the precise gap with care rather than assume every task was a dependable test. [10]

FrontierSWE is an important exception. Proximal’s public leaderboard reports the average of five trials on each of 34 tasks, with up to 20 hours per trial in its proximus agent environment. It also shows the worst and best trial results. This is a different measurement from a single-attempt pass rate, and its longer runs make it useful when the question is whether an agent can keep working on a demanding assignment. [4]

There is also an independent check on the broader capability claim. In the 1 October snapshot of Intelligence Index v4.3.2, Artificial Analysis gives Argon at High a rounded score of 53, matching Astra at Max. Opus 5.5’s Max configuration with default fallback scores 58. The settings differ, and the index combines ten evaluations, mainly in English text, rather than reporting a percentage of repository tasks completed. This gives me another reason to test Argon while keeping the individual coding results in view. [5] [7] [8]

This is why I care about the complete evaluation setup when comparing Claude and Codex on large features. If one run gets more time or different tools, the result may still be useful, but it answers a different question from changing only the model.

Does Gemini 4 Argon have a million-token context window?

The million-token announcement concerns output. Google says Argon raises the output limit from 64,000 to one million tokens, allowing much longer generated responses. That sentence establishes how much the model can produce; it does not announce a new input context window. [1]

The distinction is practical. A context window limits the material a model can work with in a request, while the output ceiling limits how much it can generate. Longer output could help when an assignment requires substantial code or a detailed report, but it does not by itself establish how much of a repository can be supplied as input.

The new ceiling is roughly 15.6 times the previous 64,000-token limit. That is a calculation from Google’s figures, not a claim that a task runs 15.6 times longer or becomes equally more reliable. An output allowance tells me where generation has to stop, not whether all the material before that point will be worth keeping.

My first interest would be work that previously stopped before producing a complete result. I would keep context management for coding agents in place, because a larger generation budget gives me no reason to remove the instructions and repository information that make the task understandable. The evaluation would still end with a reviewable change, not a target token count.

Who can use Gemini 4 Argon at launch?

Access starts with trusted cyberdefenders in Google’s Fairwind program. Google says broader availability will follow, beginning with paid API customers and Google AI Ultra subscribers, but the announcement gives no date for that next stage. As of 1 October 2026, this is a staged release rather than general access for developers. [1]

Google DeepMind describes Fairwind as an early-access program for approved organizations doing defensive security and research. Its partners can include governments and organizations responsible for critical infrastructure, with access controls and restrictions on how the models may be used. The program is a separate route to approved access, so an ordinary paid account does not establish eligibility for the initial Argon rollout. [6]

The launch’s cyber emphasis has a benchmark behind it. Google’s table lists 68.0% for Argon on CWE-bench v1, equal to Astra and just above Opus 5.5 at 67.0%. CWE-bench tests vulnerability auditing and patching, with Argon running in Antigravity, Astra in Codex and Opus in Claude Code. These scores compare models with their agent tooling, so they support a strong result for the tested Argon system rather than an isolated model advantage. [2] [9]

For a developer choosing tools today, the access restriction matters as much as a promising score. I can prepare a comparison task, but a rollout announcement is not something I can already substitute into a production workflow. I would wait for the documented access route and model configuration before changing an integration.

How much will Gemini 4 Argon cost?

Google’s announced introductory API rates are $2 per million input tokens and $10 per million output tokens. After the introductory period, they rise to $4 and $20. Cached input receives a 95% discount. These are announced rates for the forthcoming broader rollout; Google does not specify the length of the introductory period. [1]

The eventual standard token rates are twice the introductory rates, so I would budget recurring work using $4 and $20. For a hypothetical request with 100,000 uncached input tokens and 10,000 output tokens, the published rates give $0.30 during the introduction and $0.60 afterward. Those are token-charge calculations, not measured task costs.

The million-token output ceiling also makes the output side of the bill easier to notice. Generating one million billed output tokens would cost $10 at the introductory rate or $20 afterward, before input charges. The model does not need to reach that ceiling for every request. I would set a generation budget for the task instead of treating the largest allowed response as the preferred response.

This is the distinction behind GPT-6.1 Sol’s lower measured task cost: a per-token rate and the cost of completed work are different measurements. Argon’s price becomes more useful once an evaluation records the tokens needed to produce an accepted result.

What would I test when broader access opens?

I would test a task long enough to expose the differences between the coding benchmarks, then measure the work needed to accept the result. Argon’s DeepSWE score earns it that test; its weaker FrontierSWE and Terminal-bench results tell me to watch sustained execution rather than judge it from the opening answer.

The comparison would start from the same repository commit, with the same instructions, tools and acceptance checks. I would include a bounded bug fix and a larger change that requires several steps, repeat the runs, and keep failures in the results. Review time would matter alongside API cost, because a cheap patch that needs extensive repair is not cheap completed work.

I would also separate completion from volume. A longer answer is helpful if it delivers the missing part of the assignment; it becomes another review burden if it adds unrelated code. The question I want Argon to answer is whether it can finish the larger change with fewer corrections at the standard price. That is the comparison I would prepare while access expands.