Prompt Size Analyser

Ask someone what their prompt costs and they will quote you the length of the instruction they wrote. The instruction is rarely the expensive part. On a typical tool-using assistant the four components come out in roughly the opposite order from intuition: retrieved context first, tool schemas second, system prompt third, and the user’s actual question a distant fourth.

Tool schemas are the reliable surprise. They are serialised into every request in full — names, descriptions, every property, every enum value, every nested object — and they are sent whether or not the model ends up calling anything. Ten tools with thorough descriptions can be two thousand tokens of fixed overhead on a call whose user message is twelve. The fix is not usually to write worse descriptions but to send fewer tools: route to a subset based on the request, and the fixed cost drops proportionally.

The reason to split the prompt up before optimising it is that effort should go where the tokens are. A 20% cut to a component holding 5% of the prompt saves 1%; the same cut to the component holding 60% saves 12%. The trim field above exists to make that comparison concrete before you spend an afternoon rewriting the wrong thing. And if the largest part turns out to be stable across calls — a long system prompt, a fixed tool list — the better move is caching it rather than shortening it, because a cache read costs a fraction of a fresh one and loses nothing.