The feature launched. People like it. Then the first full month’s invoice from the AI provider arrived and it was three times what the developer estimated, and nobody can tell you which part of the feature spent the money. Or the opposite: the bill is small, but you have no idea whether it will stay small when volume doubles, so you are nervous about promoting the thing that works.
Both are the same problem. Usage-billed software is new to most businesses. You are used to subscriptions: a fixed number every month. A language model bills by the amount of text in and out, per request, and a feature that costs pennies at a hundred requests a day costs real money at ten thousand, or at a hundred if it is built carelessly. The good news is that LLM cost optimization is mostly a set of plain engineering habits, most of which also make the feature faster.
By the end of this article you will know how the bill is actually computed, the eight habits that keep it low, what a healthy monthly cost report looks like, and how to tell whether your developer or vendor has done any of it.
What this actually is
A large language model (an LLM, the system behind Claude, GPT-class models, and Gemini; explained plainly in What Is an LLM? A Plain Explanation for Business Owners) is billed by tokens, which are units of text roughly three quarters of a word long. Every request has two parts that cost money: the input (everything you send, including your instructions, any documents, and the conversation so far) and the output (what the model writes back). Output tokens are priced several times higher than input tokens. Bigger, smarter models cost more per token than smaller ones, often by a factor of ten or more between the tiers.
So the bill is: number of requests, times the tokens per request, times the price per token for the model used. Three levers. Every technique below moves one of them. The general shape of AI costs for a business, including subscriptions and the hidden human costs, is in AI Cost for Small Business, What It Really Costs to Run in 2026; this article is about the usage bill specifically, once the feature is live.
The business analogy is a metered utility with a twist: the meter runs faster for a heavier appliance, and you are charged for what goes in and what comes out. Nobody runs every appliance on the industrial circuit. Nobody leaves the tap running while looking for a bucket. Cost control is the same habits.
The eight habits that keep the bill low
1. Measure cost per unit of work, not per month
Before anything else, make the software record, for every request, which feature made it, which model was used, how many input and output tokens, and the resulting cost at the current price. Store it in your own database. Then report cost per unit of business work: per ticket classified, per document extracted, per conversation handled.
A monthly total tells you nothing. “Classification costs a fifth of a cent per ticket and drafting costs four cents per reply” tells you where to look and what doubling volume costs. In the systems we build, this measurement is in place before the first feature ships, and it is the same log that answers “why did it say that” (How to Add AI to Existing Software Without Breaking It). If your vendor cannot give you cost per unit, they do not know either.
2. Cheap model first, expensive model on escalation
Every provider sells a ladder of models. The small ones handle classification, extraction, routing, and short summaries at a fraction of the price of the large ones. The habit is to route each request to the cheapest model that does the job, and to escalate only the requests that need more.
Concretely: a small model classifies the ticket and answers the simple ones. If it marks itself unsure, or the ticket matches a “hard” category, the request is sent again to the mid-tier model. Only a genuinely complex case reaches the top tier. Because most business traffic is routine, most of it stays on the cheap model, and the average cost per request drops sharply while quality on the hard cases stays high. This needs the provider behind one door in your code with the model as a setting (Choosing an LLM Provider for Your Business in 2026), and you only know the cheap model is good enough because you tested it on your own examples (AI Evaluation and Evals: Testing an AI Feature Before Launch).
3. Cache the part that does not change
Most requests carry a large fixed part (your instructions, your examples, your policy text) and a small variable part (this ticket, this question). Providers now offer prompt caching: if the fixed part is identical and arranged at the front of the request, repeated sends of it are billed at a large discount, in some cases most of the way to free. Your developer has to structure requests so the stable part comes first and the variable part last, and has to keep the stable part byte-for-byte identical between requests.
Separately, cache your own results. If a hundred customers ask the same question about shipping, answer it once and serve the stored answer, with a time limit so policy changes flow through. Caching is the cheapest win available and it is skipped constantly because nobody measured the fixed part.
4. Keep prompts as short as they need to be, and no shorter
Every token in your instructions is paid for on every request. Prune the parts that do not change the output: throat-clearing, repeated rules, ten examples where three would do, the entire policy manual when two sections are relevant. Retrieve the relevant passages instead of sending everything.
But do not cut the rules and examples that make the output correct. A prompt that is too short produces wrong answers that a person then has to fix, and the person is far more expensive than the tokens. Keep what is load-bearing, cut what is decoration, and measure the effect on your test set before shipping the shorter version.
5. Limit the output
Output tokens cost the most, so control how many you buy. Ask for the shortest form that does the job: a label rather than a paragraph, three lines rather than a page, a structured answer with fixed fields rather than prose. Set a hard maximum on output length in the request so a runaway answer stops at the limit. For a classification feature, the output should be a handful of tokens; if it is two hundred, something is wrong and it is costing you forty times what it should.
6. Batch what is not urgent
Some work does not need an answer in seconds: nightly summaries, re-processing a backlog, tagging last year’s records, weekly reports. Providers offer a batch mode where you submit a large set of requests and get the results within hours instead of seconds, at a substantial discount, often around half price. Check the current pricing page for the exact terms. Move every non-interactive job to batch. It is the same output for less money and it keeps the bulk work from competing with live traffic for your rate limits.
7. Set spending caps and rate limits before you need them
Every major provider lets you set a monthly spending cap and alerts at thresholds. Set both on day one, a little above what you expect. The failure this prevents is common: a bug that retries in a loop, a script left running, a feature that suddenly gets ten times the traffic. Without a cap, you learn from the invoice. With a cap, the feature stops and you learn from an alert.
Inside your software, rate-limit each feature too. A support assistant that will answer any number of questions from one visitor is an open invitation to a bored teenager or a scraper to run up your bill. Cap requests per user per hour, and require a login or a light check before the expensive features.
8. Stream when a person is waiting, and know it does not save money
Streaming means the model’s answer appears word by word as it is written, instead of all at once after a pause. It does not reduce tokens or cost. It reduces perceived waiting, and it lets you cut off a bad answer early rather than paying for all of it. Use it for interactive features, not background work. It belongs in a cost article because a feature that feels slow gets abandoned, and an abandoned feature is the most expensive kind.
The monthly cost report
The habit that ties this together is a one-page report, generated automatically from your own log on the first of the month. It shows, per feature: number of requests, cost, cost per unit of work, which models handled what share, the cache hit rate, how many requests escalated to a bigger model, and the change from last month. Two lines at the bottom: total spend against the cap, and the three most expensive individual requests, which are almost always bugs or abuse.
An owner can read that page in five minutes and know whether the bill is healthy. A developer can read it and know where to look. If nobody can produce it, the cost is not under control, whatever the total is this month.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: a regional logistics broker with forty-five staff and an internal system that handles quotes, bookings, and a steady flow of emails from carriers and shippers. Six months ago they added three AI features: classifying every inbound email, extracting shipment details from the ones that are quote requests, and drafting replies. Everyone uses them.
What was wrong: all three features ran on the same top-tier model, hard-coded, with the entire company rate card and forty example emails in every prompt. Drafts were allowed to run to any length. A nightly job re-summarised every open booking whether it had changed or not. The bill was several times the estimate and rising with volume, and the owner was about to switch the features off.
What gets built:
- Per-request cost logging by feature, and a monthly report page.
- Classification moved to a small model after a test on four hundred labelled emails showed it matched the human labels nearly as often as the large one. Extraction moved to the mid-tier model. Drafting stays on the mid-tier model with escalation to the top tier only for a short list of complex account types.
- Prompts restructured with the fixed part first for caching, the rate card replaced by retrieval of the three relevant rates, and the examples cut from forty to five with no measured loss.
- Output limits on every feature; classification returns a label and a confidence and nothing else.
- The nightly summary moved to batch mode and changed to run only on bookings that changed that day.
- A spending cap and alert set on the provider account, and a per-user hourly limit on drafting.
What changes: the bill drops to a small fraction of what it was, most of it now in drafting, where the value is. Volume grows over the following quarter and the bill grows roughly in proportion, which is the point: it is predictable. One month the report shows a single request that cost more than a day’s normal usage, a bug in a retry loop, caught by the cap before it mattered.
What it costs to run
Nothing on this list costs money to run; it is all developer time once and habit thereafter. The measurement log lives in your existing database. Caching, routing, output limits, and batching are configuration and code. The report is a page generated from the log.
For scale: a business with a few thousand requests a month across classification, extraction, and drafting, using tiered models and caching, typically lands in the tens of dollars a month, with heavier document work reaching a couple of hundred. Built carelessly on a single top-tier model with bloated prompts, the same features can cost several times that. Check each provider’s current pricing page; prices fall regularly.
The mistakes we see most
- One model for everything. The top tier classifying tickets that a small model handles for a tenth of the price.
- The whole manual in every prompt. Thousands of tokens of policy on every request when three retrieved paragraphs would do.
- No cache structure. The fixed part of the prompt rebuilt slightly differently each time, so caching never triggers.
- Unlimited output. A summary feature that writes essays because nobody set a maximum.
- No spending cap. A retry loop runs for a weekend and the invoice is the first anyone hears.
- A monthly total and nothing else. Nobody knows which feature spent the money, so nobody can fix it.
When to bring in help
If your AI runs inside an off-the-shelf product with a subscription, most of this is the vendor’s problem and your job is to read their terms for usage overages. On an automation platform like n8n or Make, you can apply several habits yourself: pick the small model for simple steps, shorten prompts, set output limits, and set the spending cap on the provider account.
Once the features live in your own software, you need a developer to build the per-request cost log, the model routing, the cache-friendly prompt structure, the batch jobs, and the report. It is a few days of work on a well-built system and it usually pays for itself within a month or two on any feature with real volume. If your developer or vendor cannot show you cost per unit of work, that is the first thing to ask for.
Levelbrook builds this for businesses: cost logged per request, cheap model first with escalation, caching and batching where they apply, caps set, and a monthly report you can read in five minutes. Fixed price from a written scope, everything runs in accounts you own, and the form below is how a conversation starts.