Days 1 and 2. Usage review
Which models you use, for which tasks, with how many tokens and at what cost. The starting point is your invoices, the provider dashboard and your application logs.
LLM cost audit
Pay for the big model only when it matters.
I look at which models your product calls, for which tasks, and what each one costs. Then I install a router in your code that sends simple requests to cheaper models and keeps the expensive ones for the hard cases.
- Timeline
- One week
- Price
- Fixed and in writing
- Delivery
- Code, tests and docs
- Where
- In your repository
Who it is for
Teams with an LLM in production.
- You run agents, a chatbot or a voice bot that real users talk to.
- Your OpenAI, Anthropic or other provider bill grows every month and it is unclear which part of the product drives it.
- Almost every request goes to the same model, even though many of them are simple.
Before and after
Every request, to the right model.
The real split comes from your data, not from this drawing.
Before
After
The week
What happens each day.
Five working days from the moment access is in place. Every step leaves something you can review.
Day 3. Written proposal
Which tasks can move to a cheaper model, what saving your data supports and what risk each change carries. If the saving is not worth it, you find out here, before anything is installed.
Days 4 and 5. Router and tests
The router goes into a branch of your repository. Tests compare the cheap model's answers with the expensive model's answers on your real cases.
Handover. Docs and walkthrough
How to configure it, how to measure the saving and how to switch it off with a configuration change.
What you get
Usage report
Spend per model and per task, with the source data and the maths in plain view.
Router in your code
Configurable per task and switchable off with a configuration change.
Quality tests
A task only moves to the cheap model if it passes the comparison on your cases.
Cost log
Cost per request and per model, so the saving can be checked after delivery.
Documentation
So your team can maintain and tune the router without depending on me.
What I need from you
- Read access to the provider's billing dashboard, or a usage export.
- A sample of real requests, anonymised if it contains personal data.
- Access to a branch of the repository where the model calls live.
- Someone on your team to review and approve the change.
The decision layer
Fast, cheap routing decisions.
If choosing the model costs almost as much as the answer, the saving disappears. Several models are now built for this job. The best known is Jev, from TypeSafe AI, which takes 70 to 500 ms to return a typed decision, according to its maker.
If you would rather not add another provider, a small model from the provider you already use, or a set of rules, can make the decision. We choose together and it goes in writing.
Price
A fixed figure, before work starts.
The price depends on the number of flows, providers and environments. It is agreed in writing together with scope and timeline, before anything is touched.
First conversation
Fifteen minutes to see which provider you use, what you spend and whether a router makes sense for you.
Written proposal
Scope, timeline and a fixed price. No open-ended hours and no costs that appear later.
If the saving is not worth it
The review in the first days shows it before anything is installed, and we decide in writing whether to continue, reduce the scope or stop.
Questions
What usually comes up first.
Request
Tell me about your case in one minute.
With these details I can tell you, before we talk, whether a router makes sense for your product. I reply personally.
Next step
Tell me what it is costing you.
If you received an email from me, a reply is enough. Otherwise, write to this address with the provider you use and what you pay per month, even a rough figure. If you would rather talk it through, ask for a 15-minute call and I will suggest times.