There is real usage volume.
The feature is live or close to a rollout where today’s cost structure will materially scale.
All services
Reducing LLM costs
The AI bill grows faster than the usage. There are usually three reasons.
An AWS bill can be broken down until you know which service in which account produces which cost. A bill for inference knows one total and a number of tokens. That is why it often grows without anyone being able to say why: which use case, which user, which operation. I make that visible and implement the first lever along with it.
AWS Certified Generative AI Developer – ProfessionalFinOpsCost per operationEntry 2,400 €
What you get
- Cost per operation, per user and per use case, instead of a monthly total
- The three most expensive paths named, with their share of the bill
- A list of levers with estimated effect and effort, in order
- One lever of your choice implemented directly, up to eight hours, not just recommended
- Measurement that keeps running, so the next increase gets noticed
- Quotas and warning thresholds, so one outlier does not become a monthly bill
Scope & working together
Read access to the billing is enough for the analysis. The measurement is a code change and is built into the application together with your team, and so is the first lever.
Remote from Germany. Straight with me, no agency in between.
The starting point
Nobody measures what an operation costs.
With infrastructure the cost question is solved. There is a cost report, there are cost centres and tags on the resources, and anyone who wants to can drill down to the single instance. With inference there is a bill with one total and a number of tokens. What caused those tokens is not in there, and in the application itself it is usually not recorded either.
So the first answer to rising cost is almost always the same: a cheaper model. Sometimes that helps, and sometimes it degrades the result far enough that the rework costs more than the saving. Without measurement it is a coin toss. The real drivers sit elsewhere, and they are duller: a context that grows with every tool call and is paid for again each time. The same question that a hundred users ask a day and that gets answered fresh a hundred times. A retry that sends the whole request again on every failure.
The method is therefore the same as with AWS: measure first, then act. The only difference is that with inference the measurement is not there, it has to be built in. That is the smaller part of the work and the part that lasts longest.
Does any of this sound familiar?- The bill rises faster than the number of users.
- Nobody can say what a single operation costs.
- Every task runs on the largest model, because it came out best in the trials.
- The context grows with every tool call, and all of it is billed again.
- The same questions get answered fresh every day and paid for every time.
- A single user or one faulty run can double the monthly bill.
Who this is for
For AI owners who need cost per transaction, not merely a monthly invoice.
For CTOs, AI leads and product owners with a productive or fast-growing LLM feature. Usage and spend rise while tokens, models and context cannot be attributed to business activity.
Quality cannot be optimized away.
Routing, context and caching must be tested against output quality, not just token price.
You need controllable unit economics.
Cost should be visible by user, feature or transaction so product decisions use reliable numbers.
What I do
What happens along the way
01
Build in the measurement
Every request records use case, model, input and output tokens and cost, tied to user and operation. Without this step every further statement is a guess, which is why it comes at the start and not at the end.
02
Find the most expensive paths
Almost always a few paths cause the largest part of the bill, and they are rarely the ones you would expect. Only once they are named is the discussion about models worth having.
03
The model to fit the task
Classifying, extracting and summarizing do not need a model that also solves hard problems. Where quality holds, the work is moved across, and that is shown rather than claimed: with an evaluation against real cases. That evaluation is a track of its own, with test cases and quality thresholds, and therefore not part of the entry package.
04
Context and repetition
Prompt caching for the fixed part, context cut back to what is needed, targeted retrieval instead of passing everything along, response lengths capped. These are the levers without loss of quality, and therefore the first ones.
05
Quotas and warning thresholds
Quotas per user and per use case, with warning thresholds on top. A faulty run should be able to cost money, but not an unlimited amount and not unnoticed. A hard cap that turns requests away reaches into the request path, so it sits on the list as a lever of its own rather than being built in on the side.
06
What applies afterwards
The measurement stays, with a short report that gets read in everyday work. That way the next increase shows up while it is still small.
Do you know what one operation costs in your AI application?
Send me the rough monthly total and the use case. You get an assessment of where the levers are, before you commission anything.
How it runs
How this runs
Four steps in ten working days. After the second you know where the money goes.
STEP 01
A 30 minute conversation
Which application, which provider, which order of magnitude. After that I tell you whether the effort pays off. Below a few hundred euros a month it usually does not, and then I say so.
STEP 02
Measurement and analysis
The recording is built in and runs along for a few days. After that it is there in black and white which use case, which path and which user accounts for which share of the bill.
STEP 03
Levers in order
Every lever with its estimated effect, effort and risk to quality. You decide which one comes first. In my experience the first two are the ones without loss of quality.
STEP 04
One lever implemented
One item from the list, chosen by you, is implemented together with your team and measured again, up to eight hours of implementation. So at the end there is not only a report but the same figure before and after, measured on the same operation.
Entry offer
Cost picture and first lever. Fixed price 2,400 €
Fixed price. Further levers are quoted by scope afterwards, before they start.
Not a report but a measured number: after ten working days you know where the money goes, and for the lever that was implemented the before and after sit side by side, on the same operation.
What you get
- Per request measurement built in: use case, model, tokens, cost, user
- Analysis after a few days of running: the three most expensive paths with their share
- A list of levers in order, with estimated effect, effort and risk
- One lever from it implemented together and measured again, up to eight hours of implementation. You pick which
- Quotas and warning thresholds set up
- The measurement stays with you and keeps running
What you do not get
- No change of provider as part of the fixed price, that is a project of its own
- No fine-tuning of a model, the starting point is usually too early for that
- No implementation of the remaining levers and none beyond those eight hours, both are quoted by scope afterwards
- No evaluation track with test cases and quality thresholds. If the first lever is to be a change of model, I quote that separately
- No hard cap in the request path as part of the fixed price, that sits on the list as a lever of its own
- No assessment of whether the use case is permissible under data protection law
- No ongoing support without an agreement of its own
- Read access to the provider billing and to the places in the code where models are called
- The option to build the measurement in, together with your team
- For several services or more than about ten call sites the scope is agreed beforehand
- What is produced sits in your code and belongs to you
- Fixed price, regardless of how long I need
- The ten working days are counted from the day the measurement runs in your environment
- The lever that was implemented is measured again over the three working days after the switch, after that the measurement keeps running without me
- Price net, plus VAT
- Below a monthly bill of a few hundred euros I decline beforehand. The effort does not pay off then
The outcome
What is different afterwards
The bill has a breakdown
Use case, user, path. That makes cost something to discuss like any other line item, instead of a total to marvel at.
Model choice has a reason
Where a smaller model is enough, that is shown on real cases. Where it is not, likewise. Either beats a hunch.
An outlier stays an outlier
Quotas and warning thresholds make sure a faulty run shows up the same day and not in next month’s invoice.
The measurement stays
It belongs to you, keeps running and makes the next rise in cost explainable, without someone having to come in from outside.
Technologies I use
Technologies I use
Providers
- Amazon Bedrock
- Anthropic API
- OpenAI
- Azure OpenAI
Measurement
- OpenTelemetry
- CloudWatch
- Cost per operation
- Token counting
Levers
- Prompt caching
- Model routing
- Batch processing
- Response lengths
Retrieval
- RAG
- Embeddings
- Vector database
- Retrieval instead of context
Quality
- LLM evaluation
- Test cases
- Quality thresholds
Limits
- Quotas
- AWS Budgets
- Warning thresholds
FinOps
- Cost and Usage Report
- Cost centres
- Tagging
Languages
- Python
- TypeScript
- Golang
- PHP 8
Who you are talking to
Directly with me as a freelancer. No agency in between.
I am Tim Rutte. More than 20 years in software development. Today I bring AWS bills down and build AI systems. This is where the two meet. You talk to the person who touches your code, from the first call to the handover.
- 20+years in software development
- 50+successful projects
- 2003working remotely since then
Common questions
Common questions about inference cost
Is it not enough to switch to a cheaper model?
Sometimes. Without measurement it is a coin toss: if the smaller model gets it wrong more often, you pay the saving back in rework, only in a place where it never appears on a bill. That is why the measurement comes first and the model choice after it, shown on real cases.
We use Amazon Bedrock. Are the costs not visible there?
You see cost per model, with application inference profiles per tag as well, and since recently per IAM user and role too. What you do not see is the use case, the end user of your application and the individual operation. Exactly that mapping is created in the application, not in the billing, and it is the first step.
How much can typically be saved?
An honest answer: it depends on how much has been measured so far. Where nobody has looked yet, prompt caching and context discipline are often the largest items, and neither of them costs quality. I do not name a percentage upfront, because without your figures it would be made up.
What does reducing LLM costs cost?
The entry package costs 2,400 euros net at a fixed price and covers the measurement, the analysis, the list of levers and the implementation of one lever of your choice, up to eight hours. Further levers are quoted by scope afterwards. If your bill is only a few hundred euros a month, I decline before you commission anything.
Does this make the quality worse?
Not the first levers: prompt caching changes nothing about the result, a shorter context usually does not either, capped response lengths are a setting. Quality only comes into play with a change of model. Nothing is switched there without an evaluation against real cases, and that is a track of its own, with test cases and quality thresholds. It therefore does not belong in the fixed price and is quoted separately.
Does this apply to agents with many tool calls as well?
There in particular. With an agent the context grows with every step, and every step pays again for everything that happened before it. Tools that answer concisely, and intermediate results that are summarized rather than dragged along, are the largest levers here.
Do we have to expose our code for this?
No. The work happens in your environment, with your access. What I need is read access to the places where models are called, and the option to build the measurement in there.
We are only just building an agent. Is this the right page?
It depends on where you stand. If the application is running and the bill is the problem, you are in the right place: what gets measured is what you already operate. If the agent still has to be connected to your systems, that belongs on /en/services/mcp-server-development/. Quotas per user and bounded response sizes are part of the plan there from the start, instead of being retrofitted later.
Do you also do this for the AWS bill as a whole?
Yes, that is a service of its own with its own entry package. If both coincide, which is often the case with AI systems on AWS, say so in the first conversation and we cut it to size together, rather than building the same measurement twice.
Other services
What else I help with.
AI in production
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreMCP server development
MCP servers that hold up in production: the identity of the user instead of a shared technical account, tools with limits, a complete audit trail and a cost cap per use case.
Learn moreReducing AWS costs
I find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn more