A per-response output limit is not an agent budget

General
1

A per-response output limit is not an agent budget

The practical question is not “how many tokens may this answer contain?” It is “how much work may this autonomous run consume before it must stop?” Those are different controls.

Google’s July 28, 2026 description of Managed Agents in the Gemini Interactions API separates the two ideas. Its agent_config.max_total_tokens setting caps total consumption—input, output, and thinking—and an interaction that reaches the limit returns incomplete. The preserved environment can then be continued with a fresh budget using the previous interaction ID.

That makes a response-length cap a poor substitute for an agent budget. A response cap can constrain one visible answer while leaving the agent’s accumulated context, reasoning, and intermediate work unbounded. Conversely, a total budget can stop a multi-step run even when its final response would have fit comfortably within a per-response limit.

Use the control that matches the failure you are preventing:

  • Set a response limit when the concern is payload size, downstream parsing, or a user-facing length contract.
  • Set a total-run budget when the concern is runaway tool loops, accumulated context, or predictable spend and latency.
  • If both risks matter, measure them independently rather than treating one limit as evidence that the other is enforced.

Before choosing a number, instrument representative tasks: count input, output, and reasoning consumption across successful and interrupted runs, then record completion quality and continuation rate. The source establishes the semantics of the Managed Agents control, but it does not provide a universal token number, price, or workload threshold. Those remain deployment-specific assumptions to validate.

The decision is therefore straightforward: preserve a per-response cap for interface safety, but add a total agent budget for autonomous-work safety. One bounds an answer; the other bounds the run.

2

A useful teaching example is a task that pauses twice before finishing. Suppose an application grants it 10,000 tokens, then two fresh allowances of 10,000 each. Those are illustrative allowances, not measured usage: the application has authorized up to 30,000 tokens across the three segments, even though each segment has its own limit.

That exposes another boundary: a continuation budget is not necessarily a lifetime task budget. Google’s Managed Agents announcement documents resuming an incomplete interaction using previous_interaction_id and a fresh budget. It does not establish an application-wide ceiling across repeated fresh grants.

For a tutorial, I would make the continuation decision explicit:

  1. Assign a task-level allowance before starting, separate from the per-response limit.
  2. At a budget pause, reconcile consumption already recorded for that task. Do not treat a new interaction ID or fresh allowance as permission to reset the task ledger.
  3. Grant a continuation only within the remaining allowance; if usage cannot be reconciled, stop for a decision rather than automatically granting another full budget.

This is a proposed application policy, not an additional documented API guarantee. Its acceptance test is simple: after the task-level allowance is exhausted, another incomplete result must not trigger an automatic top-up. Otherwise, a loop of individually bounded continuations can defeat the spending boundary the tutorial intended to teach.