Check the 60% figure first, because it is the one number in the guide that demonstrates the mechanism instead of asserting it. Concierge's system prompt went from 3,100 tokens to 380 after a retrieval step replaced hardcoded policy text, and the guide calls that a 60% reduction for a 10-turn thread [13]. Per call it is an 88% cut. The session-level number works out because the static prompt is resent on every turn: 10 x 2,720 removed tokens is 27,200, against a 45,300-token baseline for the ticket, which is 60.0% [1].
That division is the argument. Provider APIs are stateless, so each call carries the whole history, and the model's own prior outputs come back as billable input on later steps [6]. Summed over N steps the input volume compounds quadratically [7]. A token deleted from static context is deleted N times; a token the model emits early is purchased N times.
So price the emission. At a baseline of $3 per million input tokens and $15 per million output [5], a token generated on turn 1 of a 10-turn ticket is billed once at output rates and then resent as input on nine later calls: 15 + (9 x 3) = $42 per million, 2.8x its sticker price [3]. Output is nominally 5x input at that baseline, the top of the 4-5x spread the guide cites [2] [4]. Re-billing is the bigger multiplier.
The absolute totals are claims about someone else's workload. 45,300 input tokens per Concierge ticket and 150,000 per 15-step Pathfinder run [8] [9] come to roughly 14 cents and 45 cents of input at the baseline rate [5]. For those to transfer, your static context, your per-step payload and your step count all have to match theirs, and the guide says outright that Pathfinder's step increment was 4x Concierge's [10]. The shape of the curve is the portable part.
The two fixes diverge because the workloads do. Concierge is a latency-sensitive synchronous support agent, so it got retrieval: 2-3 relevant policy snippets per ticket [2] [13]. Pathfinder ingests CI logs asynchronously, so it got LLMLingua-2 at rate=0.33 with Error, Exception, Failed, Traceback and FATAL pinned as force_tokens, cutting incoming observation size 3X with no reported loss of debugging accuracy [15] [14]. 1/0.33 is 3.03, so the configured rate is the reported result [6].
Neither fix touches the worst case. A stuck tool-use loop that reaches 30 steps consumes 570,000 tokens in one run, about $1.71 of input [11] [5]. That is 3.8x the 15-step figure for twice the steps, close to what squaring the step ratio predicts [4]. Compression scales the curve down by a constant; only a step ceiling changes its degree.
The compressor call is wrapped in try/except and falls back to the raw or truncated log when compression fails [16]. That is the right default, and it means a compressor outage lands on the invoice instead of the pager, which is also why nobody will notice it for a month. Worth noting: the checkpoint is llmlingua-2-xlm-roberta-large-meetingbank [15], a meeting-transcript model aimed at CI logs, which is presumably why the error keywords are pinned by hand.
The retry path is the same tax in a worse form. Prose instructions to "return JSON" produced malformed output, and each parse failure triggered a synchronous retry that resent the accumulated context [17]. At step nine, a schema violation buys the entire history again.
