A large prompt leaves Gemini 4 Argon less room to finish the job. Google's newly available model shares one 1,048,576-token window between input, internal reasoning and the answer, and reaching its advertised output ceiling takes multiple API requests. For developers testing long coding runs, Google's technical specifications mean checking the client before comparing models.
Google opened Argon globally on October 13 through its paid Gemini API and enterprise platform. Google AI Ultra subscribers get access in Antigravity, while both Pro and Ultra subscribers can use it in the Gemini app and AI Mode in Search. These are different routes into the model: a consumer subscription doesn't establish that your existing API integration can handle a long generation.
The rollout follows Google's September 30 announcement, when access began with selected cybersecurity defenders in its Fairwind Program. That announcement set introductory prices at $2 per million input tokens and $10 per million output tokens, with a 95% discount on cached input. Its footnote says prices become $4 and $20 after the introductory period. The announcement gives no expiry date.
A million tokens is a shared budget
The model specification describes the same combined window across GenerateContent, the Interactions API and the OpenAI-compatible Chat Completions API. Input consumes capacity that would otherwise be available for thinking and output. If a request brings 800,000 input tokens, subtraction leaves at most 248,576 tokens for the rest of that generation. That's a capacity calculation, not a prediction of how much the model will use.
A single request has a smaller ceiling: 65,536 thinking and output tokens, or 32,768 for non-streaming direct HTTP requests, according to the developer guide. GenerateContent can extend a generation through continuation requests. Long-decode support for the Interactions API is still described as coming soon, and the guide says the OpenAI compatibility layer cannot retrieve these long completions.
For a team using a common compatibility endpoint to swap models, that limitation deserves a test before any comparison. Google's specification lists Chat Completions as supported, but directs extended generation to GenerateContent. Basic compatibility and access to the full generation budget are separate integration questions.
The client has to follow the unfinished generation
When Argon reaches a request's segment limit before completing, the API returns finish_reason=CONTINUATION and a continuation token. Google's guide instructs custom clients to resend the original prompt, system instructions and tools with that token. Appending the partial answer and asking the model to continue is the wrong protocol. A segment can contain only thinking, with no visible answer, so empty text alone isn't a reason to stop.
The Python SDK's version 2.30.1 implementation shows how Google handles this. Automatic continuation is enabled by default. The SDK repeatedly calls the generation endpoint with the original contents and updated configuration, then merges the responses. Its streaming implementation follows subsequent segments while exposing their chunks through one stream.
An SDK upgrade can therefore change a test result. A wrapper that returns the first segment can score an unfinished attempt as the model's final answer. The SDK code also exposes automatic_continuation=False for callers who want one request at a time. Teams should record which behavior they tested rather than comparing the two settings under the same model label.
For Python clients, Google's migration instructions require version 2.30.1 or later for automatic long decodes:
pip install --upgrade "google-genai>=2.30.1"
The SDK implementation performs the continuation loop inside its generation methods. Applications wrapping those methods should preserve the final completion status when passing a result to another service, so a caller can distinguish a finished response from a segment.
Structured output crosses this boundary too. Google's continuation helper merges the segment responses and reparses the completed result when a response schema is configured. If you're building a custom client, validating a half-finished JSON document would test the checkpoint rather than the completed generation. Schema checks belong after the pieces have been assembled.
Migration changes more than the model name
Google's migration table lists requests that will now fail. The thinking_budget parameter and thinking_level="MINIMAL" return HTTP 400 errors. The supported thinking levels are LOW, MEDIUM and HIGH. Custom temperature, top-p and top-k values are ignored, so retaining those settings in a configuration file doesn't mean they still control generation.
Explicit context caching also goes away. The migration guide tells developers to remove cached-content references and put stable material at the start of prompts for implicit caching, which has a 6,144-token minimum. It says every processed token is billed, including thinking and internal tool instructions and function declarations when using grounding. Google Search grounding remains billed per query.
At the announced introductory output rate, 100,000 billed output tokens cost $1. After the introductory period, they cost $2. Those calculations exclude input and other charges. A higher generation ceiling gives a difficult task more room, but a price per million tokens doesn't tell you the price of a completed, reviewed fix.
Long runs also change how usage counters should be read. The developer guide says continuation requests process the prompt and previous generated tokens again, so cumulative prompt-token counts grow across segments. It warns against using that counter to trigger context compaction. The initial prompt count measures something different from the total billed input across a completed run.
Google's own results point to different winners
Argon leads some coding tests and trails on others in Google's published comparison table. It scores 77.9% on DeepSWE v1.1, ahead of the listed GPT-6 Astra, Claude Fable 5.1 and Claude Opus 5.5 results. On FrontierSWE v2, Argon's 55.0% trails all three. Its 57.4% on Terminal-Bench 4.0 is also below each of those models.
The evaluation methodology explains why the table needs careful reading. Google generally evaluates Argon at the highest thinking setting and reports single-attempt results unless otherwise specified. Its DeepSWE score is self-computed with a mini-swe agent harness. Rival scores come from a mixture of public leaderboards and provider system cards. The scores therefore reflect several evaluation setups, with different harnesses and sources.
Other tests have their own conditions. Google's methodology document says PostTrainBench runs used a ten-hour budget on one NVIDIA H100, while its Terminal-Bench Science evaluation extended verifier timeouts sixfold to address timeout issues. An evaluation runner determines how much work gets attempted and checked. For a developer choosing a model, documenting continuation support and runtime limits is part of making a result reproducible.
Google also separates its GraphWalks evaluation into shorter and longer context subsets: 650 problems up to 128,000 tokens and 200 between 256,000 and one million. That tests work inside long inputs. It doesn't establish whether a particular application will benefit from spending hundreds of thousands of tokens generating a solution.
An overnight run still needed maintainers
Google's ADK engineering account supplies a more concrete example than a leaderboard. Argon worked for 11 hours on a Python repository of roughly 205,000 lines, proposed six optimizations and ran 16,892 unit tests. Maintainers shipped two optimizations after review and rejected four.
One rejected event cache improved a synthetic benchmark by 17% but could return stale data if Python reused a memory address. Another proposal depended on a private OpenTelemetry attribute. The engineering post also reports that removing imports passed the public test suite yet broke 25 internal test targets. More time to inspect a repository produced useful proposals alongside changes the maintainers couldn't accept.
The ADK report limits the session-copy gains to its in-memory session service. Database-backed stores deserialize their data instead, so their read times don't change through this optimization. That detail gives readers a way to judge whether the result applies to their deployment. A percentage improvement in one storage path can't be assigned to every agent using the framework.
The merged ADK commit makes the accepted work inspectable. It filters session events before copying them and defers imports until use. Its benchmark records a 158-turn run falling from 65.6 seconds to 56.1 seconds, a 14% reduction. New-process time to the first model request stayed essentially flat, from 3.07 to 3.09 seconds. The test used an instant model and tools to isolate framework overhead, so those figures don't measure faster Argon inference.
As public users begin running Argon on their own repositories, watch for reports that include the client version, generation budget and review outcome. Google's ADK commit already gives one useful reporting standard: show the change that survived review and measure the work it actually saves.