Everyone checks traffic first when the invoice jumps.
Traffic's rarely the actual cause. What usually is: an agent loop that doesn't close cleanly, so it reloads context it already had — quietly, repeatedly, for every unhandled exception in the chain.
By the time it shows up on the bill, it's already cost you weeks of it.
Open-sourced the guard we use to kill this at the source, before it hits checkout friction: https://github.com/koniJang/max-token-saver-light
If your stack has the same pattern and you want it mapped exactly — not guessed at — the async audit is `$39, 24 hours, no calls: https://contra.com/s/Xs7WYN7c-llm-token-leak-and-checkout-friction-audit-24h-async?r=trs_research.
Same pattern here. The tell was never the bill — it was tokens-per-session climbing while sessions-per-user stayed flat. Traffic hides it: more users, more cost, looks normal. Break cost down by session count and you isolate the loop in an afternoon. We also cap context reloads per turn, which is where these things usually burn: retrying the full history on every exception instead of the failed step.
Spot on. That hidden creep in tokens-per-session while traffic looks flat is exactly where the backend bleeds. Isolating the loop by session count instead of retrying full history on every exception changes everything.
We actually build async ops systems specifically to plug these exact multi-agent token leaks and checkout friction (The Dead Zone). If your stack ever runs into similar edge cases and you want a quick 24-hour trace on your buffer, feel free to check my profile or profile links. Appreciate you sharing this!