Service 05 / 06
Most AI bills are an expensive model doing cheap work.
The gap between a frontier model and a fast small one is routinely thirty to sixty times per token, and a large share of what flows through the expensive one is work the cheap one does identically. Finding that share, moving it, and proving nothing got worse is the whole job.
What I build
- A breakdown of what each feature actually costs you to run
- Small models for small jobs, big ones only where they earn it
- Caching for the questions you get asked again and again
- Limits on agents, which is where bills quietly explode
What you get
The same product for a fraction of the spend, and the numbers showing which change did it.
Good fit ifyour AI bill is growing faster than your usage is.
Where does the money actually go?
Almost never where the team assumes. The default that writes most AI invoices is "route everything through the best model we can afford, because the best model is the safest choice", which is true, and also thirty to sixty times the price per token of a fast small model.
Look inside a month of real traffic and the same cheap work keeps appearing:
- Routing: "which of five things is this?" A classification a small model gets right essentially every time.
- Extraction: pulling a name, a date, an order number out of a message.
- Reformatting: JSON in, slightly different JSON out.
- Repeats: the same question asked hundreds of times, paid for in full every time.
- Agent loops: the single largest source of surprise bills, because cost scales with steps and nobody set a ceiling on steps.
Will quality drop?
That is the right question, and the only defensible answer is to measure rather than to promise. Before anything moves, the current behaviour becomes a test set drawn from your own traffic; after it moves, the same set runs again. A change that saves money and loses answers is a change we do not ship.
The reason this usually works is that model choice is a per-task decision that most systems make once, globally. Small models are not worse at everything: they are worse at some things, and identical at many, and nobody had checked which was which.
What a model bake-off actually finds
Something specific to your prompts, which is why generic leaderboards do not settle it. Running that exercise on this site's own chat agent measured first-token latency of around half a second on the fastest candidate against roughly two seconds on a stronger reasoning model, with a quality difference that mattered on some prompt shapes and vanished on others.
That is the shape of every one of these engagements: a small number of measurements on your traffic, which turn a vague "use less AI" argument into a list of specific routes with specific price tags.
The ceiling belongs in the code
Cost control that lives in a monthly invoice review is not control, it is grief with a delay. What actually works is a ledger that attributes spend to features and accounts as it happens, and hard limits that refuse work at the boundary rather than sending a surprise at the end of the month.
This site runs exactly that on itself, because a practice that sells cost engineering and cannot show its own numbers is asking to be taken on faith.
Questions people ask
- How much can we realistically save?
- It depends entirely on how much of your traffic is cheap work currently being served by an expensive model, which is measurable in an afternoon and not guessable from outside. The first deliverable is that breakdown (what each feature costs you to run) because it is also what tells you whether the rest of the work is worth commissioning.
- Will our users notice?
- On the routes that move, usually not: that is the criterion for moving them. Quality is pinned with a test set taken from your own traffic before any change, and a route that fails it stays on the model it was on.
- We already use a small model. Is there anything left?
- Frequently yes, because model choice is only one of the levers. Caching repeated questions, cutting prompt bloat that rides along on every call, and putting ceilings on agent loops all reduce spend without changing the model at all, and agent loops in particular are where bills grow fastest.
- How do you measure what each feature costs?
- By recording usage and price per call against the feature and the account that caused it, so cost becomes a queryable number rather than a monthly total. Most systems can be instrumented for this without meaningful changes to how they work, and it is the prerequisite for every other decision here.
- Is this a one-off project or ongoing?
- The useful shape is a one-off analysis and set of changes, plus the instrumentation that lets your team see it happening afterwards. Ongoing retainers for cost work tend to describe a system that was never given visibility of its own spending.