Guide · Dubai · MENA

Reduce LLM API costs: how to stop AI features from eating your margins

A SaaS founder builds toward 80 to 90 percent gross margins, because that number sets the valuation multiple, the runway math, and what an investor expects at each stage. An AI feature can break that number fast: each request carries a variable cost that scales with usage instead of shrinking toward zero. I have sat with founders staring at an API bill that grew faster than their user count, asking why no one raised this at the scoping stage. The team scoped the feature without pricing the model calls behind it.

Run the math before you ship, not after the first invoice. Take your heaviest single user's expected monthly requests, multiply by the average tokens per request, and price that against the model you plan to call. Compare the result to what that user pays you. If a support-plan customer on your cheapest tier can trigger inference cost that rivals their subscription price, the price is wrong, and the gap will show up the month the feature gets adopted widely.

The five levers, in founder terms

Cost control on an AI feature comes down to five moves, and you rarely need all five on day one.

1. Model routing. Most requests do not need your most capable model. Classify requests by difficulty and send the easy majority to a smaller, cheaper model, reserving the expensive one for cases that need it. On most features, a large share of traffic is simple enough for a smaller model to handle well.
2. Prompt caching. When a request reuses a long system prompt or a fixed set of instructions, caching that portion lowers the cost of each call that follows. Features with a stable prompt and high call volume see the largest gains here.
3. Batching. Group requests that do not need an instant response and send them together instead of one at a time. Background jobs, overnight summaries, and bulk classification all fit this pattern, and batched pricing on most providers runs well below live-call pricing.
4. Context compaction. Long conversation histories or large retrieved documents inflate the cost of each subsequent call. Summarize or trim what you pass back into the model instead of appending the full history each time.
5. Tighter outputs. A verbose system prompt produces verbose answers, and you pay for the tokens the model writes as well as the ones it reads. Asking for a shorter, more structured response often costs less and serves the user better.

Treat these as a checklist to run through in order, not a menu to pick from at random. Model routing and prompt caching tend to return the most for the least engineering effort, so start there.

Measure cost per user and per action from day one

Most teams do not instrument AI cost until the bill forces the conversation. Tag each model call with the user ID, the feature, and the action that triggered it, then push that into whatever dashboard your team already checks daily. Two numbers matter more than the rest: cost per active user per month, and cost per completed action. The second one tells you whether a feature is getting cheaper or more expensive as you tune it, which the first number alone will not show you.

Once you have those numbers, you can price the feature from evidence instead of guesswork. A founder without data guesses at a price and hopes it covers the API bill. A founder with cost-per-action data sets a price with a known margin, adjusts a specific lever when the margin slips, and defends the number to an investor who asks how the unit economics work.

When a cost problem is a scoping problem

On more than one client build, the team came to me convinced they had a cost problem that turned out to be a scoping problem. A feature called the largest available model for a job a smaller one could handle without a quality drop, because no one had tested whether the smaller model's output held up. Run that test before you accept the larger model's price as fixed. Score both models against the same evaluation set for the specific task, not a general benchmark, and decide from that gap instead of reaching for the best model out of habit.

This pattern repeats often enough that I now ask it as the first question on any cost review: is this expensive because the task demands it, or because no one checked whether a cheaper model would do the job.

Pricing that recoups inference cost instead of hiding it

A flat subscription tier hides variable AI cost inside a fixed price, and that works only as long as usage stays predictable. The moment a feature gets adopted, the flat tier starts losing money on your heaviest users, the ones you most want to keep. Usage-based pricing on the AI feature itself, or a hybrid model with a flat base plus metered usage past a threshold, keeps your margin intact as adoption grows, instead of shrinking as usage increases.

The trade-off is a harder pricing conversation with customers who prefer the certainty of a flat number. Set a generous included allowance so the metered part only applies to heavy use, and most customers will not notice the difference.

The cost review worksheet

Before a client build ships an AI feature, I run a short cost review with the founder. Copy it for your own team:

• What is the cost-per-request ceiling this feature needs to stay under, given the price the user pays?
• Which of the five levers above have not been tried yet?
• Does the heaviest expected user break the model, or the margin?
• Is the model choice tested against a smaller alternative, or assumed?
• Does the pricing plan recoup variable cost, or absorb it?

Answer these before launch, and revisit them each time usage jumps. A feature that looks margin-safe at a hundred users can look different at ten thousand. Run the review again and catch the gap before it shows up as an unexpected bill.

FAQ

How can I reduce LLM API costs without hurting quality? Start with model routing and prompt caching. Both cut cost without touching the model's output quality, because you are changing which model handles a request or how much of the prompt gets reprocessed, not the reasoning itself. Test any downgrade against an evaluation set before you roll it out.

What is a normal gross margin for a SaaS product with AI features? Founders without AI features often target 80 to 90 percent gross margin. AI features introduce a variable cost that classic SaaS infrastructure does not carry, so the target needs a feature-specific floor rather than one blanket number across the whole product. Set that floor before launch, using the levers above to hit it.

Does prompt caching actually save meaningful money? On features with a long, stable system prompt and frequent calls, yes, often a large share of the per-request cost. On features where every prompt differs and gets called once, caching saves little, so check your feature's traffic pattern before you invest engineering time in it.

Should I build cost instrumentation before or after launch? Before. Instrumentation added after a cost surprise is instrumentation added under pressure, and it gets scoped down to whatever answers this month's question instead of the dashboard the team needs. Tag each call at build time. It costs almost nothing to add then and a lot to retrofit later.

Book a call

If an AI feature is scoped but the unit economics are not, book an intro call before you ship it. For weekly writing on AI and product from zero, read the Scalable newsletter.