The two causes of your token bill

Originally published on the Sieve blog . Sieve is an open-source (Apache 2.0) context-reduction proxy — I work on it, and I've tried to keep this post about the problem rather than the tool. If you run an LLM agent for real work, the bill is the part nobody warned you about. It starts small, it grows with use, and the worst of it is invisible — most of what you pay for on any given turn is text the model has already seen, or text you never meant to send. There's a temptation to treat this as one problem with one fix. It isn't. An agent's token bill has two distinct causes, and they need two genuinely different kinds of tool. This post is about telling them apart — because once you can, the question stops being "which tool wins" and becomes "which of my two problems am I looking at right now." The bill is mostly things you didn't choose Start with where the tokens actually go, because it's rarely where people assume. When your agent calls a tool, the model doesn't just pay for your request — it pays for the machinery of asking. Anthropic's own pricing documentation spells this out: the tools parameter alone adds hundreds of tokens of schema to every request, the bash tool adds a fixed overhead, and a single web fetch pulls the fetched page straight into your context — "Average web page (10 kB): ~2,500 tokens... Research paper PDF (500 kB): ~125,000 tokens". A tool result you glance at once and never need again can cost more than the entire conversation around it. Now add the part that repeats. On every turn, a typical agent re-sends its system prompt, its full tool catalogue, its persona, and the conversation so far. The variable part of the request — what you actually typed — is often the smallest thing in the payload. The fixed overhead, multiplied across every turn of a long session, is the bill. So the cost has two shapes, and they're not the same shape: Verbose machine output — JSON tool results, logs, search dumps, fetched pages, code listings. Big, one-off, an