Running Gemini 4 Argon in Claude Code: Thinking Levels Replace Budgets

If your agent harness routes models through a gateway and your spend controls assume thinking budgets, Gemini 4 Argon will not accept that configuration: it went GA on October 13, 2026, and Google’s model documentation states that sending a legacy thinking_budget parameter returns an HTTP 400 validation error. The replacement is a set of discrete thinking levels: LOW, MEDIUM, and HIGH. Vercel’s changelog announcing the model on AI Gateway puts it plainly: “Gemini 4 Argon uses thinking levels (low, medium, and high) instead of thinking budgets.”

That one sentence carries the whole operational story. Budget-based controls let you express “spend no more than this many thinking tokens on this task class” as a number. Levels give you three positions on a dial. Any routing setup that treats reasoning spend as a continuous variable now needs a per-model migration rather than a parameter passthrough. The rest of this article is that migration: what the parameters are, what the defaults decide for you, where your cost math changes, which parts of your existing config fail silently, and what to verify before you trust any of it.

One caveat up front, because it shapes everything below. The configuration evidence here comes from vendor surfaces published at a one-day-old GA release: Vercel’s AI Gateway changelog and Google’s own model documentation. The changelog documents the harness path directly: “To use it in Claude Code, Codex, Cursor, and more, install the latest Vercel CLI and run setup” (npm i -g vercel@latest, then vercel ai-gateway setup), then “select google/gemini-4-argon in the agent.” What it does not document is how a harness’s own reasoning settings become a thinking level on this model. That mapping is the genuine unknown here, so treat harness-specific parameter behavior as something to verify, not as observed behavior.

What actually changed on October 13

Google’s model page lists Gemini 4 Argon at launch stage GA with a release date of October 13, 2026, one day before this writing. Vercel’s changelog announced the model on AI Gateway under the name google/gemini-4-argon, with a 1M-token context window accepting text, image, PDF, and video input, plus tool-calling support.

The reasoning-control change is the operationally significant part. The changelog frames the change as levels arriving “instead of thinking budgets”; Argon accepts a level. Google’s documentation is unambiguous about the boundary: “Thinking levels: Supports thinking levels LOW, MEDIUM (default), and HIGH.” The same page states that setting thinking_budget or thinking_level="MINIMAL" returns an HTTP 400 validation error.

Two details in that documentation deserve attention. First, the failure is loud, which is good news: an old config does not silently degrade, it 400s, so your error logs will find stale budget parameters quickly. Second, MINIMAL is explicitly rejected as a level value, which suggests some callers will guess at a four-level taxonomy carried over from other model families and hit the same wall. The supported set is exactly three.

This is also not a vestigial knob. Google’s model card states that the model “was trained using reinforcement learning techniques” and that the training drew on multi-step reasoning, problem-solving and theorem-proving data. A model trained to use multi-step reasoning is one where the thinking-level setting plausibly moves both quality and cost, which makes the level choice a real engineering decision rather than a leftover compatibility shim.

The parameter map

For harness operators, the practical question is which parameter name travels through your stack. Vercel’s changelog gives the two documented surfaces: “Set the thinking level with reasoning in the AI SDK or reasoning_effort in Chat Completions, and see reasoning for the other controls.” The gateway model name is google/gemini-4-argon.

Here is the mapping as the evidence supports it:

For Claude Code, Cursor, and Codex users, this is where the documentation runs out. The gateway offers more surfaces than Chat Completions: the changelog says to “Call Gemini 4 Argon through the AI SDK, the Chat Completions, Responses, and Anthropic Messages APIs, or a coding agent connected to AI Gateway.” In the changelog, level setting is documented for the AI SDK and Chat Completions only, with a pointer to “see reasoning for the other controls.” Which surface a given harness speaks, and Vercel lists Anthropic Messages among the options, determines whether any documented parameter reaches the model at all. Whether a harness passes through a user-configured effort value, overrides it, or ignores it for a non-Anthropic model is exactly the kind of thing to test with a single logged request before routing real traffic. Neither vendor page documents that mapping.

The defaults do the deciding

If you set nothing, the model sets it for you. Google’s documentation states the default thinking level is MEDIUM for the standard Gemini 4 Argon model and HIGH for the Gemini 4 Argon Cyber Permissive variant.

This matters more than it looks. Under levels, the default is the middle position, and for the Cyber Permissive variant it is the top position. A team that swaps the model name into a routing table without touching reasoning config has handed reasoning spend to that default: the budget they tuned no longer governs anything, and on the permissive variant HIGH applies by omission.

The check is cheap. Before the swap, decide the level per task class explicitly and put it in the config, rather than discovering the default through the invoice.

Your cost-cap math is now wrong in two ways

The first problem is the discrete dial itself. A spend control expressed as “cap thinking at N tokens per request” has no representation in three levels. You can approximate, LOW as the floor, HIGH as the ceiling, but you cannot express the middle values your old config may have relied on, and you cannot express a hard token ceiling at all through the level parameter alone.

The second problem is structural, and it is documented rather than inferred. Google’s model page states: “4 Argon has a unified 1,048,576-token limit that includes both input and output tokens (where output includes thinking, function calls, and the final response) across all supported API surfaces.”

Read that the way a cost engineer reads it. Thinking tokens draw from the same pool as your prompt and your response. In an agent harness, where a session accumulates tool calls, file contents, and multi-turn context, the input side of that pool is already large and growing across the session. A HIGH thinking level spends from the same budget, and function calls do too. A context-window assumption like “we have 1M tokens of headroom” is now shared three ways, and the thinking share is the one you control least precisely, because a level is not a number.

The correct response is to re-derive caps from the unified limit: decide how much of the 1,048,576-token pool (Google model docs) you are willing to give a single request’s total lifetime, then treat the thinking level as a quality-and-cost posture rather than a line item. One gap to be honest about: Google’s published pages for this model include no level-by-level pricing, so what a level costs in dollars is not documented. If your spend controls are dollar-denominated, that re-derivation requires Google’s pricing page and your own measured token usage per level. Any cost comparison you read this week that does not cite independent measurement deserves skepticism.

Failures that do not announce themselves

The thinking_budget rejection fails loudly. Two other incompatibilities fail silently, and those are the dangerous ones for a config migration.

Google’s documentation states: “Sampling parameters: Custom values for sampling parameters (temperature, top_p, and top_k) are ignored.” Not rejected, not warned about, ignored. If your harness config sets temperature: 0.2 for deterministic-ish code generation, the request succeeds, the response looks normal, and your setting never happened. “It runs” is not evidence that “my config applied.”

The same page documents the caching constraint (Google model docs): “Context caching: 4 Argon supports implicit caching only (6,144-token minimum), with durable caching enabled by default. Explicit context caching isn’t supported.” If your current setup uses explicit context caching, pinning a large system prompt or repository context into a named cache to control cost and latency, that mechanism does not exist here. Implicit caching may recover some of the benefit automatically above the 6,144-token minimum per Google’s documentation, but it is the provider’s decision, not yours, and the economics of that difference cannot be evaluated without pricing data.

The audit procedure follows directly: after the swap, diff the config you intended against the config the model actually honors. For Argon, that means verifying the level took effect, accepting that sampling parameters did not, and removing explicit-caching logic rather than leaving it to fail quietly.

Output ceilings: 1M context is not 1M output

One more limit worth fixing in your head before capacity planning. The 1M-token figure is the unified context pool. What a single request can emit is much smaller: Google’s documentation caps a single synchronous request at 65,536 output tokens, or 32,768 for non-streaming direct HTTP requests.

There is an escape hatch for genuinely long generations: on the GenerateContent API, output can be extended up to 1,048,576 tokens minus input tokens using long decodes with a continuation_token (Google model docs), but long decoding is supported only in the v1beta1 API. For a gateway-routed harness on Chat Completions, the practical ceiling is the synchronous one. If your workloads include very large single-response generations, full-file rewrites, say, the v1beta1 restriction is an architecture question, not a parameter question.

The benchmark picture is already mixed

The use case driving this article is coding agents, so the natural question is whether Argon is good at the work. Independent measurements exist already, one day after launch, and the honest summary is mixed rather than uniformly favorable.

Tool calling is documented on both vendor surfaces, and Vercel’s changelog lists it as a headline capability. That establishes the mechanism exists; it says nothing about reliability over long agentic loops.

The benchmark numbers need their provenance attached every time they appear. BenchLM’s model page reports DeepSWE at 77.9% and AutomationBench at 51.3% for Gemini 4 Argon. Both of those task-level scores are attributed to Google’s own Gemini 4 Argon evaluation methodology, not independent testing. The same page gives the model an overall score of 81.23/100 and a rank of #6 out of 935 models, per BenchLM, and flags that score as conservative because it covers only 31 of 628 benchmarks in its catalog (BenchLM).

The independent agentic results on BenchLM’s model page include one that cuts against the vendor story: FrontierSWE v2 at 55.0%, attributed to Proximal’s FrontierSWE v2 leaderboard. Google’s own model card shows that 55.0% trailing GPT-6 Astra at 65.5% and Claude Opus 5.5 at 62.3%. CWE-bench v1 stands at 68.0% via Collinear’s leaderboard (BenchLM’s model page). Artificial Analysis contributes AA AutomationBench at 77.5%, per BenchLM’s model page, well above Google’s 51.3% figure for the same-named benchmark, and AA Terminal-Bench 4.0 at 57.1% (BenchLM). Scores from different harnesses of the same benchmark are not directly comparable, which is exactly why provenance matters.

None of the sources cited here document an evaluation of Argon inside a Claude Code-style harness workflow, the routing this article is about. Leaderboard numbers are a reason to put the model on your evaluation list, not a reason to route production traffic to it.

A pre-switch checklist that outlives this model

The specific facts above are perishable; defaults, caps, and benchmark numbers will age. The migration pattern is durable, because the budget-to-level shift is one instance of a broader truth: reasoning control is becoming model-specific configuration, and a gateway model swap is a config migration, not a drop-in change. For this swap, and for the next one:

1. Map the reasoning parameter before the model name. For Argon: reasoning in the AI SDK, reasoning_effort on Chat Completions, values low/medium/high. Confirm your harness actually passes the parameter through a gateway hop with one logged request.
2. Set the level explicitly; never inherit the default. Argon defaults to MEDIUM, and the Cyber Permissive variant defaults to HIGH. Defaults differ per model and will differ per model family.
3. Test what happens to legacy parameters. Argon rejects thinking_budget with HTTP 400 (Google model docs). Loud rejection is the friendly case; find out which case you are in before routing traffic.
4. Re-derive cost caps against the token-pool semantics. Here, thinking, function calls, and the response share one 1,048,576-token pool with input (Google model docs). Check whether thinking tokens are billed, and at what rate, from Google’s pricing page.
5. Audit for silently ignored config. Argon ignores custom temperature, top_p, and top_k, and supports implicit caching only. Diff intended config against honored config.
6. Check output ceilings, not just context size. 65,536 synchronous output tokens; long decodes only on v1beta1 (Google model docs).
7. Weight benchmarks by provenance. Vendor-methodology scores (DeepSWE 77.9%, AutomationBench 51.3%, per BenchLM’s model page) are a starting signal, and the independent entries on the same page, FrontierSWE v2 at 55.0% and CWE-bench v1 at 68.0% (BenchLM), are the ones to study closest. Run your own evaluation on your task distribution before committing.

Step seven is where I would apply the most discipline, because the model is one day old and the configuration work is due now. My recommendation: do the migration work, the parameter map, the explicit level, the config audit, on workloads where a reasoning-quality miss is recoverable, and hold production-critical routing until independent evaluations of harness workflows exist or your own harness-level tests fill the gap. The config migration is documented well enough to execute today. Whether Argon deserves the traffic is documented only at the benchmark level, and the benchmarks disagree with each other.

Frequently Asked Questions

What is the default thinking level for Gemini 4 Argon?

Google’s documentation states the default thinking level is MEDIUM for the standard Gemini 4 Argon model and HIGH for the Gemini 4 Argon Cyber Permissive variant.

What happens if you send a thinking_budget parameter to Gemini 4 Argon?

Google’s model documentation states that sending a legacy thinking_budget parameter returns an HTTP 400 validation error.

What is the maximum output for a single synchronous request to Gemini 4 Argon?

Google’s documentation caps a single synchronous request at 65,536 output tokens, or 32,768 for non-streaming direct HTTP requests.