AI SaaS: building on LLM APIs without burning cash

Why do AI features break the SaaS cost model?

Traditional SaaS has a cost structure investors love: hosting, a database, email, and people. Adding a customer costs almost nothing, so gross margin sits high and every new seat is mostly profit. An LLM feature adds a cost that scales with use, paid per token, to a provider you do not control. The customer who uses your product the most becomes the customer who costs you the most, which is the opposite of how the rest of the business works.

None of this is a reason not to build. It is a reason to know, per feature, what one operation costs, what a customer does per month, and where the plan price stops covering it. A token is a fragment of a word; a thousand tokens are in the neighborhood of 700 English words. Providers charge separately for input (your instructions, the document, the conversation so far) and output (the answer), and output is priced several times higher than input.

The second thing that changes is reliability. Models time out, return something wrong, or go down. A product built on an LLM API needs a queue, a timeout, a fallback and a way for the user to correct the result. That is ordinary engineering, but it rarely appears in the first estimate.

What does a token cost in 2026?

The table collects the models we most often put in products, with the standard tier price per million tokens as shown on the pricing pages of OpenAI, Anthropic and Google in September 2026. Cached input is what you pay for a prompt prefix the provider has already seen.

Two things matter more than which row you pick. The gap between the cheapest and the most expensive model here is fifty times on input, so routing the right task to the right model is the single largest lever. And the cached input column is a tenth of the input column across the board, which is why the section on caching below exists.

How do you compute unit economics per feature?

Take one feature, estimate tokens in and out per operation, multiply by the price, then multiply by how many operations a customer runs per month. Compare that to the plan price. Three worked examples with the table above:

• Ticket triage on gpt-5.6-luna. About 500 input tokens and 50 output tokens per ticket: $0.0001 plus $0.00006, roughly $0.00016 per ticket. A customer running 10,000 tickets a month costs about $1.60 in API fees. On a $49 plan, this feature is nearly free to serve.
• Document extraction on Claude Sonnet 5. A 4,000-token contract with a 300-token structured answer: $0.008 plus $0.003, about $0.011 per document. A customer processing 3,000 documents a month costs about $33. On a $29 plan, that customer is a loss; on a $199 plan with a 2,000-document allowance, it is fine.
• Chat over a knowledge base on Sonnet 5. Each message carries 20,000 tokens of context: $0.04 of input per message uncached, plus about $0.005 of output. A power user sending 500 messages a month costs $22.50. With the context cached, input drops to $0.004 per message and the same user costs about $4.50.

The pattern: features that read a lot and write a little are cheap. Features that carry a big context on every call are expensive until you cache. Features that generate long output, or run many calls per task, are where the margin disappears. Before you build, do this arithmetic for the heaviest user you can imagine, not the average one.

How much does prompt caching really save?

Prompt caching lets the provider reuse the part of your prompt that does not change between calls: the system instructions, the tool definitions, the examples, the document the user is asking about. On Anthropic's API, cache reads cost 0.1 times the base input price and writing to the five-minute cache costs 1.25 times, so the first call is slightly more expensive and every call after it is 90 percent cheaper on the cached part. OpenAI publishes the same shape: for its current models, cached input is a tenth of the standard rate and cache writes are 1.25 times. Google prices context caching separately per model.

The math only works when the prefix is stable and reused within the cache window. Put the unchanging content first, the user's question last, and keep the structure identical between calls. A prompt that inserts the current time at the top defeats the cache on every call.

For a chat-over-documents feature this is the difference between a plan that works and one that does not, as the third example above shows. For one-off classification of short text there is nothing to cache and the saving is zero; that feature is already cheap for other reasons.

When should you use a smaller model?

Most product tasks do not need the largest model. Classification, extraction into a fixed schema, routing, short rewrites and yes-or-no judgments run well on gpt-5.6-luna, Claude Haiku 4.5 or Gemini Flash, at a fifth to a fiftieth of the price of the top models. The way to find out is not to guess: build a test set of 200 real examples, run each candidate model, and measure accuracy against what a human would have done.

The pattern that works is routing. A small model handles the request; when it reports low confidence, or the task type is one you know it fails, the call escalates to a larger model. Ten percent of requests escalating to a model ten times the price still leaves the blended cost at about twice the cheap model, not ten times.

One rule that saves more than any model choice: use a model only where a rule cannot do the job. Validating an email, calculating a total, matching a keyword. Deterministic code is free, predictable and testable. The model earns its keep where the rule runs out.

What about batch and off-peak processing?

Both OpenAI and Anthropic sell batch processing at half the standard price. OpenAI's Batch API takes a file of requests and returns results within 24 hours, often faster, with a separate and larger rate limit. Anthropic's pricing page lists the same 50 percent saving for batch. Google publishes batch and flex tiers at half the standard rate for its Flash models.

The features that fit are the ones nobody is waiting on: nightly reports, backfilling classifications over old data, enriching records, generating summaries for a digest. A product that runs everything synchronously because that is how the demo worked leaves half its API budget on the table.

How do you keep one customer from eating your margin?

Everything above lowers the average cost. This section is about the outlier, because the outlier is who breaks the plan. Five mechanisms, all of which need to exist in the first version:

• Metering per tenant. Record input tokens, output tokens, model and computed cost for every call, tagged with the customer, the feature and the day. This is the dataset that tells you what your real cost per plan is and which customers are out of line. If your database is multi-tenant, the meter lives on the same tenant key.
• Quotas per plan. Each plan includes an allowance of operations or credits. Hitting the limit either stops the feature with a clear message or moves the customer to paid credits. A plan with unlimited AI on it is a plan with an unbounded cost.
• Hard limits per call. Cap input length, cap output tokens, set a timeout. A user pasting a 300-page PDF into a summarizer should get a polite refusal or a chunked job, not a $4 API call.
• A cost alert. A daily check that compares the day's API spend against expectation and pings someone when it is off. Provider dashboards show this after the fact; the alert shows it before the invoice.
• A kill switch per feature. The ability to disable one AI feature for one customer, or for everyone, without a deploy. When a provider misbehaves or a customer finds an expensive loop, you want a toggle, not an emergency release.

What should the pricing page look like?

Three shapes work. An allowance inside the subscription (the plan includes 500 generations a month) is the simplest to explain and the easiest to check: the API cost of the full allowance must fit under the plan price with room to spare, as if every customer used all of it. Paid credit packs on top absorb the heavy users and turn a cost into revenue. Pure usage pricing suits an API product or large accounts and requires metering you would stake an invoice on.

Whatever the shape, subscriptions need billing that handles failed cards, mid-cycle upgrades and credit top-ups; our guide to SaaS billing with Stripe subscriptions covers that state machine. And the cost of building the product around the AI feature, tenants, roles, admin and all, is in our guide to SaaS development cost.

The short answer

AI features are affordable when three things are true: the task reads more than it writes, the stable part of the prompt is cached, and the customer's usage is metered and capped by plan. Under those conditions, the API bill for most product features is cents per customer per month at 2026 prices, and the expensive cases are the ones you chose to price separately.

If you want the arithmetic done for your product, tell us the feature and the volume you expect. VTA builds SaaS products with the metering, the quotas and the caching in the first version, replies the same day and returns a written scope, a fixed price and a delivery date within 24 hours. If the honest answer is that a rule and a spreadsheet cover it, that is what you will hear.

The detail on the work itself

• SaaS development →

  Metering, quotas and caching in the first version, alongside tenants, roles and billing.

• MVP development →

  The smaller fixed-scope option for validating one AI feature before the full product.

Frequently asked questions

Keep reading

• SaaS development cost in 2026: what US startups actually pay →

  Public price bands for building a SaaS product, the recurring costs nobody puts in the quote, and the five decisions that move a build from five figures to six.

• Multi-tenant SaaS architecture explained for founders →

  What multi-tenant means, the three ways to separate customer data, how row-level security works in Postgres, and the decisions that are expensive to reverse.

• MVP vs full product: the scope that survives 100 users →

  What breaks between the first and the hundredth user, which shortcuts are safe in an MVP, which ones become debt, and how to contract the second phase.