How to budget and cap LLM costs in a SaaS product

The model bill is a pricing decision

Most software costs almost nothing per extra use. An AI feature does not work that way. Every generation, chat turn or summary is a call to a model that charges by the token, so the heaviest user of a flat-price plan can cost more than they pay. The fix is not a cheaper model. It is pricing and engineering the feature so its cost is known per use, capped per customer and stopped before it can hurt you.

The steps below are the ones we follow when we ship AI features, including in products of our own. The numbers in the examples are illustrative. Yours will differ, but the method does not.

Step 1: measure the cost of a unit of work

Token prices are the wrong unit to plan with. A price per million input and output tokens tells you almost nothing about what a customer will cost you. What matters is how many tokens one piece of user work consumes, including the system prompt, the retrieved context, tool calls and any retries.

So measure tasks, with real prompts on realistic inputs, and log the cost of every call during a pilot. Suppose the measurement for a document assistant comes back like this:

• Drafting a document from a request: US$0.10.
• One follow-up turn refining that draft: US$0.06.
• A document worked end to end, one draft and five follow-ups: US$0.40.

Two things stand out. Follow-up turns are not cheap, because each one sends the whole conversation back as context. And the realistic unit is the worked document, not the single call. Pricing on the cost of the first draft alone would underestimate real use by four times.

Re-measure whenever the prompt, the model or the typical input size changes. These numbers drift.

Step 2: sell an allowance in money, not in requests

Once you know the cost per task, you can decide what each plan includes. The common shortcut is a request quota, such as 100 generations a month. It is easy to explain and wrong in both directions. A short question and a long generation count the same, so the quota is either too generous for heavy tasks or too tight for light ones.

Include model usage measured in money instead. In the example above, an allowance of US$20 a month covers about 50 fully worked documents, or 200 bare drafts. Offer a higher plan that differs mainly in the allowance, so a heavy user has an obvious upgrade rather than a support ticket. A free trial gets a small allowance of its own, so a trial can never cost more than you decided it may.

Check the margin at full use, not average use. Take the plan price, subtract the payment provider’s fee, the full allowance and your other running costs per customer. If a customer who spends the entire allowance loses you money, the plan is wrong before the first sale.

This works because providers report the real cost of each call. OpenRouter, for example, returns the amount charged with every response. Summing that number is more accurate than keeping your own price table, which goes stale the day a provider changes its prices.

Step 3: decide what happens at the limit

When the allowance is spent, something has to give. A rule that holds up:

• New AI runs are refused with a clear message and the date the allowance resets, the first of the next month (UTC).
• Everything else keeps working. Users can read, edit and export the work they already have.
• A run already in progress always finishes. Its cost is already being incurred, and cutting it off would throw away paid work.

A calendar month for everyone is simpler to explain than a reset on each subscription’s anniversary, and it makes support conversations short. Do not degrade quietly to a weaker model when the allowance runs out. The output gets worse, the user does not know why, and they blame the product.

Step 4: bound the overshoot

There is a catch in “a run already in progress finishes”. You only know a run’s cost when it ends. If a user can start ten runs at once with one cent left, all ten finish, and the allowance is a suggestion.

Two rules handle it:

• A check before every run that the allowance is not already spent.
• A small limit on runs in flight per person, such as two. A month can end slightly over the allowance, but never by more than that many runs.

The in-flight count has to be safe against races. Two requests arriving at the same moment must not both see “one run in progress” and both start. Record the run as started before counting, so a second request sees the first, and ignore stale records left by runs that crashed.

Step 5: stop paying for work nobody receives

The quiet leaks in an AI feature are not big prompts. They are calls whose results never reach a user.

• Timeouts. Serverless functions have a maximum duration. If the platform kills the function mid-run, the model may already have charged you and you never record it. Give the AI work its own deadline comfortably before the platform’s limit, so it can stop cleanly, report a timeout and record what was spent.
• Failed runs. Record the cost when a run fails, not only when it succeeds. Failures cost money too, and leaving them out makes the allowance look more generous than it is.
• Retries. Validate model output and retry once with the validation errors as feedback, then stop. Unlimited retries on a confused model are the fastest way to spend a month’s budget on one task.
• Accidental double calls. Trigger AI work from a user’s action, never from something that can fire twice on its own, such as a page re-rendering. And skip the call entirely when you already know the result cannot be used, for example when the system it would be sent to is not connected.

Step 6: put a hard stop outside the app

Everything above lives in your code, and code has bugs. A wrong loop, a leaked key or a configuration change that switches to a pricier model can spend money faster than any allowance check will notice.

So set limits where your code cannot override them:

• One API key per environment, each with its own monthly spending limit at the provider or gateway. Development keys get a small limit.
• A model allowlist on each key, so only the model you priced for can be called.
• An alert at 70% of the limit, sent to a person, not a dashboard.

The production limit is an emergency stop, not the billing mechanism. When it is reached every AI call fails for every customer, so keep it above the sum of all customer allowances and raise it as you sign customers.

Levers when the margin is too thin

If the measured cost does not fit the price you can charge, there are several levers before raising the price:

• Send less context. Retrieval that selects the relevant records beats pasting everything. Context size is usually the largest cost driver.
• Cache repeated prompt parts. As of October 2026, Anthropic lists cached input reads at a twentieth of the normal input price. Long, stable system prompts benefit most.
• Batch work that can wait. Anthropic lists a 50% discount for batch processing, which suits overnight reports and bulk imports.
• Use a smaller model where it is good enough. Classification, extraction and routing steps rarely need the largest model. Within one provider’s line-up, list prices vary by an order of magnitude or more between the smallest and largest models, so match the model to the step.

Measure output quality before and after each change. A cheaper call that needs a retry, or a person to fix its output, costs more than the call it replaced. This is the same discipline we describe in why AI pilots stall before production: evaluation is what lets you change the model without guessing.

A checklist before you launch

• You know the model cost of one complete unit of user work, measured on realistic inputs.
• Every plan has an allowance in money, and the plan still makes money when a customer spends all of it.
• The product says what happens at the limit, and the non-AI features keep working.
• The overshoot is bounded by a limit on runs in flight.
• Cost is recorded for failed and timed-out runs, retries are capped, and nothing calls the model twice by accident.
• Each environment has its own key, spending limit, model allowlist and alert.

Where we sit

We build AI features into existing products and own them through production, which includes the unglamorous part: metering, limits and the margin math above. If you are pricing an AI feature, or one is already costing more than it earns, bring the numbers you have. If our build vs buy guide points you to an off-the-shelf tool instead, we will say so. The initial consultation is free, and we reply within 24 hours.