Classic software barely gets more expensive per user when that user uses it more. AI features are different: every request to a language model costs money, growing with the length of the input, the length of the output and the chosen model. Your most engaged customers are therefore also your most expensive. A SaaS product that bundles AI features into a flat fee without managing this dynamic risks making exactly its most successful accounts unprofitable.
Where the costs actually arise
Most providers bill per token, separately for input and output, with output tokens usually costing more. The cost driver is therefore rarely the user's short question but everything the product sends along automatically: a long system prompt, conversation history, documents from a search, format examples. A chat that resends the entire history with every message gets more expensive each round without the answers getting better.
Then there are costs no price list shows: retries after errors, requests abandoned because users stop waiting, and background jobs that process more content than necessary. Without measuring these, all you see at the end of the month is a total bill with no idea which feature caused it.
Measure before you optimise
The most important step is mundane: log every model request with workspace, feature, model, input and output tokens, and outcome. Only this data shows which features are expensive, which customers consume far more than average, and whether optimisations work. For SaaS, attribution per workspace is decisive because it underpins quotas, pricing tiers and the question whether an account is profitable.
Thresholds with alerts help too: when a single workspace consumes unusually much in a short time, when a feature suddenly needs twice the tokens per request after a release, or when a bug triggers a retry loop. Without monitoring, such outliers often surface only on the invoice.
The technical levers
The most effective lever is choosing the model per task. Not every feature needs the most capable model. Classifying, extracting, short summaries or reformatting into a fixed structure often work just as well with smaller, cheaper models. Large models pay off for complex reasoning, long documents or delicate wording. Assigning a model per feature, checked against a small set of test cases, usually saves more than any fine-tuning of details.
The second lever is context. Conversation histories can be shortened or summarised, search results limited to the truly relevant passages, system prompts stripped of repetition. Many providers also offer prompt caching: recurring opening parts of a request, such as a long system prompt or reference document, are cached and billed at a lower rate. For this to work, the stable part must come first and must not change between requests.
Third: limits. A maximum answer length per feature stops a model from rambling where two sentences suffice. For tasks nobody waits on — nightly analyses, bulk processing — several providers offer batch interfaces at reduced prices. And identical requests with identical results need not go to the model twice; your own result cache is often the simplest saving of all.
Pricing models that fit the cost structure
Technical optimisation alone is not enough if the pricing promises unlimited use. Quotas per tier that are visible in the product work well: users see what they have used and can top up. Alternatively, credits that cost different amounts for differently priced features work too. Honesty matters: a quota that only becomes visible when the limit is suddenly hit creates frustration and support tickets.
For B2B customers a clearly defined fair-use rule is often more acceptable than a hard limit, as long as the boundary is understandable and upgrading is easy. Anyone selling AI as the core of a product should build expected model costs per customer into the pricing rather than treating them as overhead.
Typical mistakes
Three patterns are most common. First, the same large model is used everywhere because it worked best in the prototype. Second, context grows uncontrolled because each new feature adds more information to the prompt. Third, costs are not attributed to customers, so nobody knows whether the most expensive accounts are also the most profitable. All three can be fixed, but only once measurement is in place.
What this means for DACH SaaS
For providers in the German-speaking region there is also the question of where models run. Processing in the EU or via cloud platforms with European regions is a requirement for many B2B customers, but may mean different prices and a different model range than a provider's direct API. This trade-off belongs in the same decision as cost planning, because switching provider or region later takes effort.
A pragmatic start
If you run an AI feature today, start with three steps: introduce metering per request and workspace, check for each feature whether a smaller model suffices, and make quotas visible in your pricing. Finer optimisations such as caching strategies pay off only after that. Innopulse runs its own SaaS products with AI features and helps DACH companies build this control in from the start.