Cut your LLM bill by 30 to 70%

The scene is almost always the same: you open your provider's dashboard, the curve is climbing, and no one on the team can say why. Your user count hasn't moved, but the bill has. When I audit these products, I'm not hunting for a magic rate or a cheaper vendor. I'm hunting for the tokens you pay for and no one ever reads. They hide in the same two or three places every time, and cutting them takes no migration and no rebuild.

Why is my AI bill climbing when usage is flat?

Because an LLM's cost doesn't track your number of users, it tracks the number of tokens you make it read and write on every call. And that volume swells on its own, release after release. Three causes come back in nearly every engagement: useless context resent on every call (a full history, a whole document, instructions piled up over months), the most expensive model wired in everywhere by default when part of the work doesn't need it, and answers regenerated identically when they already existed. None of the three shows up on the invoice: it gives you a total, never a reason. That's why I start by reading the bill line by line instead of cutting at random.

Where do you start to get back in control?

With measurement, before any optimization. Until you know where each euro goes, every change is a bet. So I break the spend down along a few simple axes, and the culprit jumps out fast: a handful of calls concentrates most of the budget. That's where you work first, not on whatever is most visible.

• By feature: which part of the product burns money, and whether it earns it.
• By model: what the premium model actually costs you, call by call.
• By call type: what's a simple, repetitive task and what genuinely needs power.
• Input versus output: how much of your tokens go to the context you send, rather than to what the model produces.
• Share of duplicates: how many calls ask the same question with the same data.

Is caching really the first lever?

Yes, and it's most often where I start, because the gain is immediate and invisible to the user. In production, a large share of calls are near-duplicates: the same question, the same data, the same answer, regenerated at full price. Caching the answer on identical inputs removes that waste without changing anything for your users, often within a few days.

There are two caches to tell apart. The first stores the full answer when the input is identical: ideal for recurring questions or screens that reload the same data. The second, offered by the main providers, keeps the stable part of your prompt in memory (long instructions, a reference document) so it isn't billed at full price on every call. Both drop in without touching your business logic.

Do you really need the most expensive model everywhere?

No, and this is the second big lever. Routing each request to the cheapest model capable of handling it is enough in most cases. Classification, field extraction, reformatting, intent detection: these tasks don't need the most powerful model, they need one that's good enough, and that one costs a fraction of the price. The reflex of sending everything to the best model is comfortable, it's rarely justified. To decide which task deserves which model, you make the call case by case, not once and for all.

• To a small model: classify, extract fields, reformat briefly, detect intent, triage.
• To the big model: multi-step reasoning, long-form writing, code, high-stakes ambiguous cases.
• The rule: you keep the cheapest model that passes your tests on the task, and that's the one that handles it.

What's left to cut once caching and routing are in place?

The fat in the prompt itself. It's the least spectacular work and often the most profitable, because it goes after what you pay on every call, no exception.

• Cut the dead context: everything the model never reads still costs money. A full history, a whole document sent for three useful lines, instructions piled up and never cleaned out.
• Favor short instructions and targeted examples over long directives: two good examples often beat a wall of rules, and cost less on every call.
• Group bulk processing into batches when latency allows: most providers bill batch processing at a reduced rate.

Does cutting the bill risk the quality?

It's the first question I get, and the answer is a method: I cut nothing without running it through the same tests before and after. Every change (a cache, a lighter model, a shortened prompt) is validated on a set of real cases. If the measured quality drops, the change doesn't ship. What falls isn't accuracy, it's the spend on what wasn't adding anything. Without that measurement, you don't cut a bill, you move it to a quality problem you'll discover later. That's exactly why I measure quality continuously instead of trusting an impression.

How much can I expect to save, and how fast?

Taken together, these levers bring a bill down by 30 to 70% on most of the products I audit, at equal quality. The first gains usually land within two to three weeks, because caching and routing are quick to set up and pay off right away. The rest is hygiene work that keeps paying afterward, call after call. The range is wide because it hinges on one thing: how much waste is already in place. The more a product has grown without being cleaned up, the bigger the margin to recover.

I never cut a bill by degrading quality. I cut it by no longer paying for what adds nothing.

Cutting an LLM bill isn't a matter of negotiation or migration, it's a matter of measurement and discipline: seeing where the money goes, cutting what is never read, saving the most expensive model for the tasks that earn it. That's exactly the work of an optimization audit. If your bill is climbing and you can't say why, a first conversation is often enough to spot the two or three items to cut first, with no commitment: let's talk.