AI feature token cost: budget it before it eats your margin
Traditional SaaS runs 80% gross margin; AI-native products sit near 52%. The gap is token cost. Here is how we budget AI features so margins hold.
Token cost is the variable inference bill your product pays every time a user triggers an AI feature, and it is the line item that quietly turns an 80% software margin into a 50% one. A classic SaaS feature is build once, serve forever: the marginal cost of the ten-thousandth user is close to nothing. An AI feature is the opposite. Every call runs the model again, burns compute, and attaches a real cost to that single transaction. Budget the feature as if it were software and the margin drains away without one line of the P&L looking wrong.
This is not a rounding error. Traditional SaaS settled at 80% to 90% gross margin over the last decade. ICONIQ's January 2026 snapshot put the average AI product gross margin at 52%, up from 41% in 2024 but still far below the software ceiling. Bessemer's State of AI placed LLM-native companies near 65%. a16z partner Martin Casado has described the old 70% to 80% software margin as a kind of business gravity that AI breaks, because inference is a variable cost that scales with every use, not a fixed cost you amortize across a growing base.
Why AI features behave like infrastructure, not software
The mental model that fails is treating an AI call like a database read. A database read is effectively free at the margin. A model call is metered, like electricity. In 2026 the meter reads roughly like this: Claude Sonnet 4.6 costs 3 dollars per million input tokens and 15 dollars per million output tokens, Opus 4.8 costs 5 and 25, Haiku 4.5 costs 1 and 5. OpenAI's GPT-5.5 sits at 5 dollars input and 30 output. Those are cents-per-call numbers that feel invisible in a demo and then compound into your largest cost of goods once real users arrive. The unit that matters is not the per-token price. It is how many tokens one useful action consumes, multiplied by how often your heaviest users perform it.
Why raising the price does not fix it
The reflex is to charge more. It does not work, because the cost is not spread evenly. Usage patterns across 2026 show the top 10% of users consuming close to 90% of the inference. A flat 29-dollar plan is profitable on a casual user and deeply unprofitable on a power user running the feature all day. When GitHub Copilot moved every plan to usage-based credits in mid-2026, some heavy users watched bills jump from 29 dollars toward 750. Cursor cut its request allowance at the same price point. Developers named the shift the tokenpocalypse. A bigger flat price still loses money on the heaviest tenth and prices out the ninety percent who barely touch the feature. You cannot flat-rate a cost that behaves like a utility.
How to budget an AI feature before you ship it
The work happens before launch, not after the first surprising invoice. Four moves carry most of the result.
Measure cost per action, not cost per user
Pick the smallest unit of value your feature delivers: one summarized thread, one generated draft, one answered question. Count the tokens it actually consumes end to end, including the system prompt, retrieved context, conversation history, and output. Multiply by the model's input and output rates. Now you have a cost per action you can defend. A single grounded answer with a 10,000-token context and a 700-token reply on Sonnet 4.6 costs about 4 cents. That number, not a vague monthly estimate, is what you design pricing and limits around.
Route each task to the cheapest model that clears the bar
The price spread between a frontier model and a small one runs 5x or more. Most production traffic does not need the frontier model. Classification, extraction, short rewrites, and routing decisions run fine on Haiku-class models at a fifth of the cost. Reserve the expensive model for genuinely hard reasoning. Sending everything to the top model is the single most common way teams overpay, and model routing is usually the largest lever they have.
Cache the parts that repeat
Most AI calls resend the same system prompt and the same retrieved context on every turn. Prompt caching stops you paying full price for that repetition: Anthropic discounts cached input by up to 90%, and OpenAI caches automatically at a 50% discount. Semantic caching goes further by serving near-identical questions from a store instead of the model, and production systems commonly divert 20% to 45% of traffic that way. Batch processing, for anything that does not need to be real time, is another 50% off. Stacked, caching and routing routinely cut a production inference bill by 47% to 80%.
Cap the worst case
Every AI feature needs a ceiling. Set a per-user token or request budget, degrade gracefully when it is hit (a smaller model, a shorter context, a queue), and make the cap a product decision rather than an accident discovered on the invoice. The rule we hold to: never ship an AI feature priced below the cost of its worst-case user unless you have deliberately chosen to subsidize that tier and know exactly how long you can afford to.
How to price around a variable cost
Once you know cost per action, pricing follows. Flat-rate survives only when the worst-case user still fits inside the price, which is rare for anything usage-heavy. Usage-based pricing aligns revenue with cost but adds friction and unpredictability for the buyer. The common resolution in 2026 is a hybrid: a base subscription that covers a generous allowance of actions, then metered credits above it. That keeps the casual user on a simple plan, charges the power user for the load they create, and protects the margin at both ends. Whatever model you choose, the billing layer has to meter usage accurately, which is a build decision worth making early rather than retrofitting under pressure.
What this looks like in practice
Take a support assistant inside a B2B tool. Each answer carries a 4,000-token system prompt, 6,000 tokens of retrieved knowledge, and a 700-token reply. On Sonnet 4.6 that is roughly 4 cents per answer. A power user asking 30 questions a day across 20 working days generates 600 answers, about 24 dollars of inference in a month. On a 29-dollar plan, that one feature consumes 83% of the revenue before any other cost. A casual user asking 20 questions all month costs 80 cents. Same feature, a 30x spread.
Now apply the budget. Cache the 9,500-token static prefix at a 90% discount and only the fresh input and output pay full rate, dropping the cost per answer to roughly 1.4 cents. The power user's monthly inference falls from 24 dollars to about 8.40, a 65% cut with no change to what the user sees. Route the simplest questions to a Haiku-class model and it falls further. The feature that looked margin-negative on a flat plan is now comfortably inside it, and the same discipline told you exactly where to set the usage cap. That is the whole point: token cost is not a reason to avoid AI features. It is a number to design around, and the teams that measure it before launch keep the margin the ones that guess lose.
Sources
Frequently asked questions
What does an AI feature actually cost per user per month in 2026?
It depends entirely on tokens consumed per action and how often the user acts, not on the per-token price alone. A grounded answer with a 10,000-token context and a 700-token reply on Claude Sonnet 4.6 runs about 4 cents. A power user doing 600 of those a month generates around 24 dollars of inference; a casual user doing 20 costs under a dollar. The spread between the two, often 30x, is why a single monthly average is misleading. Measure the heaviest realistic user, not the average one.
Should I price my AI feature as flat-rate or usage-based?
Flat-rate is safe only when your worst-case user still fits inside the price, which is rare for anything usage-heavy. Pure usage-based aligns cost with revenue but adds friction and unpredictable bills for the buyer. Most teams in 2026 land on a hybrid: a base subscription with a generous action allowance, then metered credits above it. That keeps casual users on a simple plan and makes power users pay for the load they create, protecting margin at both ends.
How much can caching and model routing realistically save?
Stacked correctly, they cut a production inference bill by 47% to 80%. Prompt caching discounts repeated input by up to 90% on Anthropic and 50% automatically on OpenAI. Semantic caching serves 20% to 45% of near-identical traffic without hitting the model at all. Model routing exploits a 5x-plus price spread by sending routine work to a small model and reserving the frontier model for hard tasks. Routing is usually the single largest lever, and it changes nothing the user can see.
Related articles
Studio
Start a project.
One partner for the whole build. Faster delivery, a modern stack, lower cost.