Contribution Margin for AI Features: One Formula, Three Public Test Cases

Microsoft's Intelligent Cloud segment kept about 44 cents of gross profit on each new dollar of revenue it added in fiscal 2026, against 58 cents on the average dollar. That gap is what an AI-heavy product mix looks like in a filing. Contribution margin is the number that tells you whether your own AI feature can be given away inside a bundle, and most product teams have never calculated it.

Contribution margin for AI features, defined

Contribution margin for an AI feature is the revenue that feature brings in, minus every cost that rises when one more user or one more request arrives. For a token-backed product, those costs are model tokens, retrieval, evaluation, human review and payment fees. If the result is negative at your heaviest users, the feature cannot be bundled at a flat price.

Contribution margin is an old management accounting tool. It splits costs into variable costs, which move with volume, and fixed costs, which do not. What is left after variable costs is the amount each unit contributes toward covering the fixed base and then profit.

Classic SaaS rarely needed it at feature level. Serving one more user of a reporting dashboard cost close to nothing, so gross margin and contribution margin told the same story. Every request now carries a bill, and the bill scales with how hard the user leans on the feature.

Why gross margin answers a different question

Gross margin is a company-level reporting figure. It subtracts cost of revenue, which mixes fixed items like support staff and amortised software with variable items like hosting. It also depends on classification choices that differ between companies, a problem covered in the analysis of how vendors report AI cost of goods sold.

Contribution margin is a decision figure. It is calculated for one feature, one plan or one customer segment, and it ignores costs that would exist whether or not the feature shipped.

What counts as variable in a token-backed product

A cost is variable if doubling usage roughly doubles it. Model tokens pass that test cleanly. So do vector database queries billed per read, reranking calls, per-request evaluation sampling and payment processing on usage charges.

Human review is the line teams most often leave out. If a person checks a share of outputs, and that share is fixed, review cost scales with volume exactly like tokens do. Engineering salaries, model fine-tuning runs and the platform team are fixed over the decision window, so they stay out.

The contribution margin formula for token-backed products

Write it per user per month, because that is the unit your price is quoted in.

Contribution margin = (R − T − V − H − F) ÷ R

R is revenue attributable to the feature. T is token cost. V is other variable infrastructure, such as retrieval and evaluation. H is human review. F is payment and platform fees.

The token cost line, built from list prices

Token cost is requests multiplied by tokens per request multiplied by price, calculated separately for input and output. Output tokens usually cost five times input on current Claude models. Anthropic lists Sonnet 5.5 at $2 per million input tokens and $10 per million output tokens, with cache hits on that model billed at one twentieth of the input price.

A feature that resends the same system prompt and retrieved documents on every request pays mostly for repeated input. Caching that context can cut the input bill by more than half, a mechanism set out in the breakdown of Claude plans and API rates.

The three costs teams forget

The first is retries. Agents that call tools, fail and try again can burn two or three times the tokens of a clean run. Measure tokens per completed task, not tokens per call.

The second is the newer tokeniser. Anthropic's own pricing documentation says Claude 4.7 and later models produce about 30% more tokens for the same text. A per-token price cut can be partly absorbed by a per-text token increase.

The third is the free allocation. Any credits you include in a base plan are cost with no attributable revenue. They belong in the formula with R set to zero, and that is where most bundling mistakes hide.

A worked contribution margin example: the $20 add-on

The inputs below are illustrative, chosen to be plausible for a support-summary feature. Only the token prices come from a source.

Assume an add-on priced at $20 per user per month. A typical user makes 400 requests a month. Each request sends 6,000 input tokens of instructions and retrieved context and receives 800 output tokens, on Sonnet 5.5.

Without caching, input costs 2.4 million tokens at $2, or $4.80. Output costs 320,000 tokens at $10, or $3.20. Token cost is $8.00 per user. Add $1.50 for retrieval, evaluation sampling and review, and $0.60 for a 3% payment fee. Contribution is $9.90, a 49.5% contribution margin.

Now assume 70% of input tokens are served from cache at $0.10 per million. Cached input costs $0.17 and uncached input costs $1.44, so total input falls from $4.80 to $1.61. Token cost drops to $4.81.

Contribution rises to $13.09, a 65.5% margin. One engineering decision moved the margin by 16 points, which is why I would fund prompt and context caching work before I funded a pricing review. The calculation ignores cache write charges, which are billed at a premium, so treat 65.5% as a ceiling for these inputs.

The power user problem

Averages hide the user who breaks the model. Take a user who makes 2,000 requests a month, five times the typical figure. Token cost with caching becomes $24.05 and review and retrieval scale to $7.50.

That user costs $32.15 against $20 of revenue. Contribution is negative $12.15. If one user in ten looks like this, the plan's blended margin falls sharply, and a flat price quietly becomes a subsidy from light users to heavy ones. This is the mechanism behind why falling token prices have not produced falling AI bills.

Run the sheet twice: once at median usage and once at the 90th percentile. The second run is the one that decides your pricing model.

Salesforce: what $0.10 per action has to cover

Salesforce publishes the revenue side of an AI feature more clearly than almost anyone. Flex Credits sell at $500 per 100,000, and one standard Agentforce action consumes 20 credits, or $0.10, according to the company's May 2025 pricing announcement. Conversation pricing at $2 per conversation remains available alongside it.

That gives R per action. What Salesforce does not publish is T. It does not say which models serve an action, how many tokens a typical action consumes, or what it pays its model suppliers. So the only honest exercise is a sensitivity table, not an estimate.

Assume an action uses 8,000 input tokens and 600 output tokens at list price, with no caching. On Sonnet 5.5, token cost is $0.022, leaving 78% of the $0.10 before any other cost. On Opus 5.5, at $4 and $20 per million, it is $0.044, leaving 56%. On Fable 5.1, at $10 and $50, it is $0.11, and the action loses money before retrieval or review.

The lesson is not about Salesforce, whose real costs are unknown and almost certainly below list. It is that a fixed per-action price makes model routing a margin decision. The pricing history behind those numbers is covered in the analysis of Agentforce's per-conversation pricing math.

One more line matters for bundling. The same announcement says customers on Enterprise Edition or above can get 100,000 Flex Credits for $0 with Salesforce Foundations. In this formula, that allocation is 5,000 actions with R set to zero, a deliberate acquisition cost rather than a product margin.

What the 10-Q does show

Salesforce's 10-Q for the quarter to 31 July 2026 gives the company-level direction. Subscription and support cost of revenues was $2,021 million against $1,645 million a year earlier, up 22.9%. Subscription and support revenue rose 11.7%, to $10,820 million. Total gross margin slipped from 78.1% to 76.7% on our arithmetic.

Part of that is accounting, not compute. Amortisation of acquired intangibles inside cost of revenues rose from $150 million to $234 million, and stock-based compensation from $126 million to $147 million. Strip both out and cost of revenues still grew about 15%, against total revenue growth of about 11%.

The income statement does not attribute that gap to Agentforce, to model costs or to anything else. You can read that the cost base of the subscription business is growing faster than its revenue, which is consistent with token-backed features scaling and is not proof of it.

Anthropic: a 44% estimate is your supplier's margin, not yours

The second public case runs the formula from the other side. If you build on a model API, your T is your model supplier's R. Their margin decides how much room they have to cut your price, and how much pressure they are under to raise it.

Anthropic has not published an audited gross margin. In a Morningstar interview published on 3 September 2026, PitchBook senior analyst Harrison Rolfes said he had estimated Anthropic's gross margin at about 44%. He also said that to sustain commitments running to 2030 and beyond, it would need something closer to 70%.

Treat the 44% as directional. It is one analyst's reconstruction from public data, and the analyst said himself that Anthropic's cost to serve is not known from outside. The leaked draft accounts discussed in the reconciliation of Anthropic's reported S-1 losses did not settle it either, because compute was not split between cost of revenue and research.

Putting the supplier margin into your sheet

Here is the arithmetic that makes the estimate useful. At a 44% gross margin, each dollar of API revenue costs the supplier about 56 cents to serve. If that supplier wanted 70% with unchanged serving costs, the same tokens would need to sell for about $1.87, roughly 87% more than today.

That is a scenario, not a prediction. Serving costs per token have historically fallen, and Rolfes himself argued Anthropic can grow out of falling prices through volume. But it changes how you should treat row 6 of the sheet. I would add a second token price column at 1.5 times list and check whether the feature still clears your margin floor. If it does not, your pricing depends on a supplier decision you do not control.

Microsoft: the incremental margin on AI-heavy cloud revenue

Microsoft is the third case and the most useful, because it discloses enough to calculate an incremental margin. That is the closest thing a public filing offers to contribution margin on new business.

Microsoft Cloud gross margin was 69% in fiscal 2025 and 66% in fiscal 2026, falling every quarter from 68% to 65%, according to the company's fiscal fourth quarter metrics. Microsoft Cloud revenue grew from $168.9 billion to $214.4 billion over the same period.

The company has said why. In its second quarter commentary, Microsoft wrote that Microsoft Cloud gross margin percentage decreased to 67% "driven by continued investments in AI infrastructure and growing AI product usage," partly offset by efficiency gains in Azure and Microsoft 365 Commercial cloud.

Microsoft Cloud margins are rounded, so use the Intelligent Cloud segment instead. It reports exact revenue and cost of revenue. Revenue rose from $106,265 million to $137,791 million. Cost of revenue rose from $40,171 million to $57,876 million.

The segment's gross margin therefore fell from 62.2% to 58.0%. The segment added $31,526 million of revenue and $17,705 million of cost, so the new revenue carried a 43.8% margin. That is the AI-heavy mix, as close as a filing gets to showing it.

Two cautions apply. Cost of revenue includes depreciation on data centres, which behaves more like a fixed cost over a year than tokens do. And Intelligent Cloud contains more than AI. Even so, a 14-point gap between average and incremental margin at the largest software company in the world is a fair warning for anyone pricing AI features off their historical margin.

Bundle or meter: the contribution margin decision rule

The point of the formula is a decision. Here is the rule I would use. Bundle an AI feature into a flat price only if contribution margin stays positive at the 90th percentile of usage, using list token prices and a 1.5 times price stress. If it fails any of those three tests, meter it, cap it or charge for it separately.

A bundled feature has no R of its own, so its contribution margin is negative by definition unless it moves another number. The honest version of the bundling case says which number: lower churn, higher seat expansion or a higher plan price.

The trade-offs between flat bundles and usage meters are set out at length in the comparison of bundling and metering for AI features.

Some features should be bundled at a loss. A feature that is cheap at the median, used lightly by most customers and central to why they buy can be a rational acquisition cost. Salesforce's free Flex Credit allocation is that logic made explicit.

The test is whether you chose the loss or discovered it. A deliberate subsidy has a budget, a cap and an owner. An accidental one has a power user nobody has looked at.

Where this argument is weakest

The framework is sound and the public evidence is thin. None of these companies discloses a feature-level contribution margin, so every public figure here is a proxy for the thing the formula actually needs.

The worked example is illustrative by construction. Real request counts and token sizes vary by an order of magnitude between products, and the 65.5% result would move a long way with different inputs.

The case that contribution margin misleads

Contribution margin can push a team toward the wrong product decision. It treats fixed costs as irrelevant, but an AI feature often needs a dedicated evaluation and safety team whose cost is fixed only until usage forces it to grow. Over a two-year horizon, very little is fixed.

It also ignores option value. A feature with negative contribution today might be the one that justifies a price increase next year. Microsoft's falling cloud margin may turn out to be the cost of a position worth far more than the margin points it gave up.

My view is that both objections argue for running the formula, not skipping it. A team that knows its feature loses money at the 90th percentile and ships it anyway has made a strategy decision. A team that never ran the numbers has made a pricing error.

Frequently asked questions

Where to start

Pull one number from your product logs this week: requests per user per month at the 90th percentile for your most-used AI feature.

Then put it into row 2 of the sheet above with your real token sizes and list prices. If contribution comes out negative, you have found the conversation your next pricing review should start with, before a renewal forces it.

Related reading