Research-backed calculator guide

AI Feature Break-Even Price: Calculate the Minimum Charge Before Target Margin

Calculate an AI feature break-even price from token usage, non-token COGS, fixed-cost allocation, usage percentiles, and a target gross margin.

What the price should include

Start by defining the unit you are pricing. It might be one active account per month, one document processed, one resolved support ticket, one agent run, or a bundle of credits. The unit must match the customer-facing meter. If you price per seat but most cost is generated by documents or runs, a single seat average can conceal an unprofitable power user.

Then map the cost of one unit. A practical feature-level cost stack contains five layers:

1. Model usage. Count input and output tokens, including retrieved context, tool instructions, and any retry or fallback calls. Apply the correct provider price to each unit. Treat cache reads, cache writes, batch discounts, regional uplifts, and service tiers as separate assumptions.
2. Non-token variable COGS. Include embeddings, reranking, vector queries, web search, file processing, image or audio calls, network egress, and per-request infrastructure. These are estimates unless you have a vendor quote or an invoice line.
3. Support and review. If some requests require human review, moderation, quality checks, or customer support, allocate that cost per account or per successful action. Do not bury it in a vague “overhead” percentage when it is driven by usage.
4. Allocated fixed cost. Allocate a defensible share of always-on engineering, hosting minimums, observability, and operations. A $2,000 monthly platform cost spread across 1,000 active accounts is $2 per account. State the denominator and period.
5. Commercial exclusions. Payment processing, sales commissions, tax, refunds, discounts, chargebacks, and customer-acquisition cost may sit outside feature COGS. Decide whether your margin is gross margin on delivery or contribution margin after selling costs. Do not mix definitions.

The provider pages are useful rate-card references, but they are not a substitute for your usage log. OpenAI lists different rates for input, output, cached input, and tools; Anthropic distinguishes cache writes and cache hits; and Google publishes model and tool prices with effective-date windows. ^{[1] [2] [3]} Record the rate-card date beside each assumption. Prices, model availability, and billing rules can change.

A percentile-based AI feature pricing formula

Use at least three usage views rather than one average:

• P50 or typical account: useful for adoption and onboarding decisions.
• P95 or high-usage account: useful for setting an included allowance that does not lose money on the customers most likely to test the limits.
• P99 or stress case: useful for overage policy, abuse controls, and enterprise exceptions.

For a usage percentile q, calculate:

variable COGS(q) = requests(q) × cost per request + other usage-linked costs(q)

fully loaded cost(q) = variable COGS(q) + allocated fixed cost per account

break-even price(q) = fully loaded cost(q)

target price(q) = fully loaded cost(q) / (1 - target margin)

The variable-cost term should use the actual request shape for that percentile. A heavy account may send longer prompts, retrieve more chunks, trigger more tool calls, and retry more often. If you only multiply an average token count by an average request count, you are calculating an average account, not a p95 floor.

The margin formula is sensitive near 100%. At 70% margin, divide cost by 0.30. At 80%, divide by 0.20. At 90%, divide by 0.10. A small cost underestimate therefore creates a much larger price-floor error at a high target margin.

Worked cost example

Assume a US-dollar monthly feature plan. The following is an illustrative estimate, not a quote for your product. The model-rate inputs use the $2 per 1 million input tokens and $10 per 1 million output tokens shown for one OpenAI model row on the checked documentation page; verify the current row and model before using it in a launch decision. ^[1] Retrieval, infrastructure, and review figures are explicit estimates.

The feature serves 1,000 monthly active paying accounts. A p50 account makes 20 requests per month, a p95 account makes 80, and a p99 account makes 160. Each request uses 6,000 input tokens and 1,500 output tokens. Non-token estimates total $0.008 per request: $0.004 for retrieval and reranking, $0.003 for application infrastructure and network, and $0.001 for review or support allocation. The feature also has $2,000 per month in fixed platform cost allocated across those 1,000 accounts, or $2.00 per account.

This table makes the decision visible. A $5 plan may cover the p95 feature cost only barely, before payment fees, discounts, taxes, refunds, and acquisition costs. A $24 price is what this particular p95 cost requires for an 80% gross-margin target. It is not a market recommendation, and it does not mean every account should be charged $24.

The same calculation gives a p50 fully loaded cost of $0.70 + $2.00 = $2.70. At 80% margin, its target price is $13.50. The p99 fully loaded cost is $5.60 + $2.00 = $7.60, producing a $38.00 target price at the same margin. That spread is the reason a single average can be dangerous: an apparently healthy $13.50 price for a typical account leaves a p99 account far below the intended margin.

Turning the floor into a plan

A plan can use the p50 or p75 cost for an included allowance only when the allowance is explicit and the overage policy protects the higher percentiles. In the example, suppose a $24 monthly plan includes 80 requests. The marginal cost is $0.035 per request. At an 80% target margin, a cost-based overage price is:

$0.035 / (1 - 0.80) = $0.175, or about $0.18 per extra request.

That overage rate is a starting calculation, not a final price. You may round it for billing simplicity, add a minimum bundle, or charge by a value unit such as a completed document. The plan should also have a hard usage guardrail, because an unbounded retry loop or a malformed integration can turn a normal account into a cost incident.

If customers resist the resulting price, there are only a few honest levers: reduce request volume, shrink context, route simple work to a cheaper model, improve cache hits, constrain tool calls, change the unit of value, or accept a lower target margin knowingly. Do not solve the problem by silently changing the denominator from p95 accounts to all registered users. Registered users who never invoke the feature do not fund the requests generated by active power users.

For a broader monthly operating view, connect this feature model to the AI Agent Cost Calculator. Use the AI API invoice reconciliation calculator to replace estimated usage with billed rows after launch. If incident response and evaluation work are material, the AI observability ROI calculator can help decide whether that operating cost is justified by avoided losses. The AI agent development cost estimator is useful for separating build cost from recurring feature COGS; do not mix one-time implementation spend into a monthly price floor without stating an amortization period.

Common mistakes that distort the break-even price

Using only the model invoice. Token spend is often the most visible line, but retrieval, reranking, storage, moderation, support, and infrastructure can dominate a feature with short prompts. Keep each component visible.

Mixing token units. A rate of $2 per 1 million tokens is not $2 per 1,000 tokens. Normalize every price and usage assumption before multiplying. Label dollars, tokens, requests, minutes, documents, and accounts in the worksheet.

Applying margin to the wrong base. An 80% gross-margin target means cost is 20% of price, so price equals cost divided by 0.20. Multiplying cost by 1.80 is a markup, not an 80% margin.

Treating a vendor price as permanent. Rate cards change. OpenAI's page separates standard, cached, tool, and processing modes. Anthropic documents cache-write and cache-hit multipliers. Google publishes changes that take effect on stated dates. ^{[1] [2] [3]} Snapshot the date, model, region, tier, and discount used in your calculation.

Ignoring retries and fallbacks. If 8% of requests retry once, expected request volume is not simply the user-visible request count. Add the retry factor or measure billed attempts. The same applies to model fallbacks, safety checks, and human review.

Calling the result a market price. Break-even answers whether the cost model covers delivery. It does not measure willingness to pay, competitive positioning, perceived value, conversion, churn, or sales friction. Those are separate tests.

FAQ

What is the difference between break-even price and target-margin price?

Break-even price covers the modeled cost and produces 0% gross margin. Target-margin price adds the required headroom by dividing cost by one minus the target margin. If cost is $4.80, break-even is $4.80; an 80% target-margin price is $24.00. A markup calculation such as $4.80 × 1.8 would not produce an 80% margin.

Should I use average usage or p95 usage for AI feature pricing?

Use both, but for different decisions. Average or p50 usage helps forecast adoption and revenue. P95 is a stronger basis for an included allowance and a margin-safe plan floor when high-usage customers are material. P99 is a stress test for overages, abuse, and enterprise contracts. If your pricing is intentionally designed around a lower percentile, state the trade-off and add a control for accounts above it.

Do cached tokens reduce the AI feature break-even price?

They can reduce the input-cost component when the cache actually hits and the provider bills a lower cache-read rate. They do not automatically make the whole request cheap. Include cache writes, cache storage, cache invalidation, misses, and the unchanged output, retrieval, tool, and infrastructure costs. Anthropic documents separate cache-write and cache-hit units, while OpenAI lists cached input and cache-write prices separately. ^{[1] [2]}

Should payment processing be included in the break-even price?

Include it when your decision is contribution margin after payment costs. Exclude it only when you clearly label the result as feature gross-margin COGS. A percentage fee and a fixed transaction fee can matter on low-priced plans, especially when the AI feature is sold as a small add-on. Never compare a price floor that excludes payment fees with a margin target that assumes they were included.

What if the target-margin price is higher than the market will accept?

Treat that as a product and packaging signal, not a reason to hide costs. Recheck the usage distribution, token counts, retry rate, and fixed-cost allocation first. Then test cheaper routing, context reduction, caching, usage caps, credit bundles, overages, or outcome-based units. If the economics still fail, launch at a consciously lower margin or do not include the feature in that plan. The calculator cannot decide willingness to pay for you.

How often should I recalculate an AI feature price floor?

Recalculate when the model, provider, region, billing mode, prompt shape, retrieval index, cache behavior, retry rate, or customer mix changes. A monthly review is a reasonable operating cadence for an active feature, with an immediate review after a provider price change or a usage spike. Keep the checked date and source URL beside every vendor-rate assumption so the next review can identify what moved.

Limitations and assumptions

This method assumes a stable billing unit, a reasonably measured usage distribution, and a defensible allocation of fixed cost. It does not forecast demand, conversion, churn, tax, accounting treatment, revenue recognition, customer-acquisition cost, or the value delivered to a customer. It also does not replace an invoice reconciliation. Vendor pages describe published rates, while your effective rate may differ because of contracts, credits, discounts, minimums, region, batch mode, or marketplace billing.

The worked example is intentionally transparent rather than universal. Its $2 and $10 per million token rates are dated vendor-rate inputs from the cited OpenAI page as checked on 2026-11-02; retrieval, infrastructure, review, request counts, token counts, and the $2 fixed allocation are estimates for demonstration. Replace them with your own logs, invoices, and contract terms before publishing a price. The useful output is not one magic number. It is a traceable floor that shows which assumption would have to change for the plan to remain viable.