Spending Someone Else's Budget

## The two costs are not the same cost Picture a service that summarises documents members of the public upload. Anyone can submit a file; the pipeline extracts its content, splits it into units, summarises each unit with a model call, aggregates the partial summaries, and sometimes runs a further pass to check the aggregate against the source. A person reads the result at the end. There are two costs in that sentence and they are borne by different people. - **The submitter's cost** is one upload: some bandwidth and a single HTTP request. It does not scale with what happens afterwards. - **The operator's cost** is every model call the pipeline makes because of that upload, plus the retries, plus whatever capacity those calls occupied while other work waited. When someone chooses a submission specifically because of how much downstream work it becomes, they are trading their cheap unit against the operator's expensive one. Consumption is the objective, not a side effect of some other attack. ## What the cap is actually scoped to A per-request token cap is a correct, well-implemented control and it does exactly what it says: it refuses a single model call whose input plus output would exceed a bound. It is enforced per call. It has no view of how many calls exist, which submission they belong to, or who caused them. A pipeline can make two hundred calls for one upload and every one of them can be under the cap, because being under the cap is a property of a call and the cost is a property of the set. The same is true of a per-request wall clock. A timeout that kills any single call after a fixed number of seconds bounds the latency of that call. It does not bound the elapsed time of a submission, because the submission is a sequence of calls and the timeout resets on each one. Both controls answer the question *is this request too big?* Neither answers *how many requests did one accepted submission become, and who chose that number?* This is the specific wrong answer an interviewer is listening for. Somebody says "we cap tokens per request, so cost is bounded" and stops. The follow-up is always the same: bounded per what? ## Where the multiplier comes from The count of derived calls is a function of the ingest stage's definition of a unit, and that definition usually reads properties of the submitted artefact: how many pages, sheets, sections or embedded objects it contains, how deeply structures nest, how many parts an extractor emits. A submitter who is choosing what to send is choosing those properties. Then the loop adds its own multipliers on top: a second pass over the partial results, a verification pass, and a regeneration whenever a stage's output fails the next stage's expectations. Each of those turns one unit into more than one call. Notice that none of this requires the submission to say anything. There is no instruction for a model to obey, no directive span, nothing a content screen would score as suspicious. The lever is structural, and it is the reason this family survives in deployments where the wording-level checks are good. ## Reading the evidence correctly A few directions are easy to get backwards: - Every call passing the cap proves that no single call was oversized. It proves nothing about the number of calls. - No private data being reached proves the read path was not exercised. It does not mean nothing was spent, and spend is the payoff here. - A retry that produced a discarded answer still cost input and output tokens. Work thrown away is work billed. - One measured submission cost is one sample from a probabilistic pipeline. Retry counts vary between runs, so a single number is a data point, not the method's cost. ## Where it stops working The method depends on the derived work being a function of attacker-chosen input, and on the marginal cost landing on somebody other than the submitter. If the number of units a submission may become stops depending on what was submitted, the multiplier disappears from that stage — though it can reappear at the next one, or simply move to the count of submissions if submitting stays free. And if the marginal cost of a submission is borne by whoever made it, the asymmetry that made the method worth building is gone; what remains is capacity planning. One last distinction worth having ready: this is not a network flood. Nobody is saturating a link or filling a connection table. The resource being drawn down is inference capacity and the bill attached to it, which is why the finding is argued in terms of cost and queueing rather than packets. The published GenAI risk lists give unbounded consumption its own entry precisely because it does not look like the other items.