In this article 5 sections

Google made Gemini 4 Argon generally available on October 13 with a unified context window of 1,048,576 tokens. Input, internal thinking, tool calls, and visible output draw from that one budget. The model can also continue one response beyond the usual 64K output boundary through a feature called long decode. (Gemini API release notes) (Argon guide)

The important implementation detail is that a million-token response is not one model call. With the Interactions API, Google runs a background job that generates as many as 64K tokens per hop, carries the growing prefix into the next hop, and records every hop as a model_output step under one interaction ID. The job can run for up to 24 hours. (Long decode)

This changes the integration contract. A request that used to live inside one HTTP exchange can now outlast a connection, cross several billable inference calls, and finish with multiple output fragments. Treating it as a larger synchronous call will produce the wrong timeout, retry, usage, and assembly behavior.

One response is now a durable job

Long decode is explicit. A background interaction needs max_output_tokens above 65,536 and stored state. Without that configuration, output still stops at 65,536 tokens. A foreground request that asks for more returns an error.

The client then polls or reconnects to the interaction and joins its ordered model_output steps. That sounds simple, but it creates several states an ordinary response wrapper may not represent: queued, in progress, completed, incomplete, cancelled, and failed. A dropped stream does not prove that the model stopped, and starting a fresh request after a client timeout can create duplicate work instead of resuming the existing interaction.

A release gate should exercise the whole lifecycle:

  1. Persist the interaction ID before returning control to a worker or user interface.
  2. Reconnect after an intentional network break and prove that output fragments are assembled once and in order.
  3. Distinguish a terminal answer from an interaction that consumed its budget while still thinking. Google documents an incomplete result with empty text as one possible outcome.
  4. Test cancellation at several hop boundaries and record work completed before cancellation.
  5. Put a wall-clock and token ceiling on each eligible task class rather than exposing the 1M maximum as a default.

This is not the preferred path for every agent. Google’s own guide says chat, summarization, classification, extraction, latency-sensitive requests, and agents that make many short tool turns should normally stay below the single-hop limit. Long decode is aimed at unusually hard reasoning, coding, science, and proof tasks that need one extended generation.

The usage counter is not the context size

Long decode also changes how token telemetry should be interpreted. Each hop sends the original prompt plus everything generated so far back to the model. Google’s worked example starts with a 1,000-token prompt and produces 200,000 tokens across four hops. The interaction reports about 397,216 total input tokens even though the final context contains about 201,000 tokens.

The difference is repeated input. Google applies a 95 percent implicit-cache discount to the repeated prefix during the introductory pricing period, but the tokens still appear in cumulative usage. Completed work is billed even when an interaction is later cancelled or fails. (Long decode)

Do not trigger context compaction from total_input_tokens. For this API, that field sums input across hops. Estimate the live context from the prompt plus total thought and output tokens, and use the cumulative counters for cost. During streaming, read the latest cumulative usage value rather than adding every event again.

The same distinction belongs in an evaluation record. Capture at least task success, terminal status, hop count, live-context size, cumulative cached and uncached input, thought tokens, visible output, wall time, and total cost. Then vary thinking_level and max_output_tokens independently. Lowering the output ceiling does not make the model reason more concisely; it can simply cut the work off.

Argon’s model card reinforces the need for workload tests rather than a single provider ranking. Google reports leading results on some knowledge-work and long-context benchmarks, while other listed models lead on FrontierSWE, Terminal-Bench, Terminal-Bench Science, and the tested OSWorld subset. These are provider-published evaluations, not evidence that long decode improves a particular production task. (Model card)

Application watch: Orange separated reusable agents from trusted tools

LangChain published a case study on October 13 describing Orange Business’s Live Intelligence platform, deployed across 120,000 Orange employees and adopted by more than 150 customers. The account is vendor-authored and provides no controlled quality or productivity result, so those adoption figures should not be read as proof of effectiveness. (Orange Business case study)

The architecture is still useful. Orange keeps an Agent Registry for reusable, versioned agents and prompts, and a separate MCP Registry for approved tools and connectors. Prompt versions can differ by environment. Evaluation also has three layers: retrieval quality, agent behavior, and production traces covering latency, cost, failures, feedback, and escalations.

That separation prevents a convenient agent definition from silently granting access to every available tool. It also gives a long-running interaction a place in the operating model: the agent version explains intended behavior, the tool registry defines reachable capabilities, and the trace records what the job actually consumed and did. The missing evidence is outcome quality by workflow and version, which Orange says it plans to extend through online evaluation.

Stay Sharp: compress by failure, not fluency

A larger window does not remove the need to decide what belongs in it. Agent Context Optimization, presented at ICML 2026, improves a compressor by comparing trajectories where full context succeeds with trajectories where compressed context fails. A capable model analyzes what information was lost and revises the natural-language compression guideline. The optimized compressor can then be distilled into a smaller model. (ACON)

Across AppWorld, OfficeBench, and multi-objective question answering, the authors report 26 to 54 percent lower peak token use while maintaining or improving performance against their compression baselines. Distilled compressors retained more than 95 percent of the larger compressor’s accuracy, and smaller agent models improved by as much as 46 percent in the reported settings. Those are benchmark results, not a guarantee for an enterprise workflow.

The reusable method is the contrastive test:

  • keep the uncompressed trajectory as the reference;
  • run the same task with the candidate compression policy;
  • isolate cases where only the compressed run fails;
  • identify the missing identifier, constraint, observation, or causal dependency;
  • update the policy and rerun untouched tasks.

This tests whether a summary preserves decision state, not whether it sounds complete. Long decode adds more room for reasoning, while compression decides which evidence survives long enough to inform that reasoning. They solve different problems and need separate gates.

Watch next

  • Independent measurements of long-decode task success, tail latency, cancellations, and total billed input across hop counts.
  • Framework support that exposes interaction IDs, cumulative usage, and incomplete terminal states without flattening them into a normal response.
  • Outcome and regression data from Orange Business by agent, prompt, tool-policy, and workflow version.