What's Actually Eating Your LLM Bill? Four Suspects to Check First

The invoice arrives and it is bigger than last month. Traffic grew a little. The bill grew a lot.

The usual reaction is "we need a cheaper model." Sometimes that is right. More often, the money is leaking somewhere nobody is looking, and swapping models just moves the leak.

So here is this Friday's question: when your LLM bill jumps, which of these is the real culprit on your team?

My lean: C and D are the silent ones. A and B show up the moment you look at a single request. C and D only show up when you look at the whole workflow.

Input tokens are cheap per token, but you pay for them on every single request. A 6,000-token system prompt that never changes is 6,000 tokens billed on call one and on call one million.

On most provider price sheets, output tokens cost several times more than input tokens. A model that "helpfully" writes 600 words when the UI shows 2 sentences is burning the most expensive tokens you buy.

This is the one that hides. A single user action can fan out into:

Each step looks reasonable in isolation. The total is a multiple of what you budgeted.

Tracing tools make this visible. Langfuse token and cost tracking attributes cost per trace and per span, and LiteLLM cost tracking gives spend per key, team, or model if you route through its proxy.

Many production calls are boring: classify this, extract these fields, route this ticket. Those rarely need the biggest model you have access to.

OpenAI's latency optimization guide makes a related point: fewer tokens, fewer requests, and smaller models where possible help both speed and spend.

Nine times out of ten, the fix is not a new vendor. It is a cap, a cache-friendly prompt order, or a smaller model on the routine path.

When your LLM bill jumped, what was it really?

A) Long prompts, B) Verbose outputs, C) Retries and agent loops, or D) The wrong model tier?

Drop your letter in the comments — and if it was something else entirely, I would love to hear it.