LLM feature unit economics for SaaS

Shipping an LLM feature is easy. Shipping one that does not quietly destroy gross margin takes unit economics. This guide is a practitioner framework for SaaS teams — formulas, guardrails, and kill criteria — without pretending your margins will match a keynote slide.

Related: token estimator, retry budget, cost control for teams, agent token overhead.

Define the unit

Pick a customer-valuable unit, not an API call:

• Draft generated and accepted
• Ticket auto-resolved without human touch
• Repo PR opened that passes CI
• Search answer clicked with positive feedback

If you cannot name the unit, you are optimizing tokens, not a business.

Call it U. Everything below is per U or per account-month containing some Us.

Core formula

variable_cost_per_U = llm_token_cost + other_inference + pass-through APIs + payment_fees_alloc

contribution_per_U = revenue_attrib_per_U - variable_cost_per_U - human_review_cost_per_U

llm_token_cost should use vendor usage, adjusted for retries and agent steps — not a blog heuristic alone. Build it with the token estimator and calibrate.

Include:

• Input + output tokens × dated rates
• Retry multiplier
• Tool-calling overhead
• Embeddings / rerankers / guardrail models
• Average human minutes × loaded engineer/support cost when review is required

Revenue attribution (be honest)

Options, from cleanest to messiest:

1. Metered add-on priced per U
2. Pack of credits sold explicitly for LLM features
3. Feature gated on a higher plan — use incremental ARPU, not all of plan revenue
4. “Strategic” free feature — then contribution can be negative by design; cap usage

Never assign 100% of subscription revenue to a single chatbot unless Finance agrees in writing.

Margin guardrails

Example policy (tune to your business):

• Launch if median contribution_per_U > target (e.g. > 60% of revenue_attrib_per_U)
• Alert if p90 token cost per U > 2× median for a week
• Hard-cap daily token $ per tenant
• Kill or redesign if contribution negative for 2 consecutive months without a written growth hypothesis

Gross margin impact at company level:

ΔGM ≈ sum over features( revenue_attrib - variable_costs )

LLM line items should appear in the same monthly review as hosting and payment fees.

Pricing patterns that match costs

Pattern	Fits when	Watch-outs
Included soft cap + fair use	Low variance cost/U	Abusive tenants
Hard credits	Spiky agent usage	UX friction
Separate Pro seat	Heavy IDE/agent seats	Shadow IT
Outcome-based	Clear U and measurement	Disputes on “success”

Align pricing with the variance of your cost distribution, not only the mean.

Spreadsheet tabs you actually need

1. Rates — dated vendor prices
2. Traffic — U volume, tokens p50/p90, retries, steps
3. Cost — $ per U scenarios (base / incident / abuse)
4. Revenue — attribution method
5. Guardrails — caps, alerts, owners
6. Decision log — launch / iterate / kill

Keep tab 2 fed by product analytics, not optimism.

When to kill or redesign

Strong signals:

• Human review cost dominates and does not trend down
• Abuse drives p95 cost without revenue
• Model bills grow faster than attributable ARPU after prompt freeze
• Support burden from wrong answers exceeds contribution

Redesign levers before kill: smaller models, fewer agent steps, caching, retrieve-less RAG, stricter tool allowlists, charge for overage.

Stakeholder one-pager

Executives rarely need token theology. Give them:

1. Definition of U
2. Median and p90 $ per U
3. Revenue attribution method
4. Margin vs target
5. Caps and kill switch owner
6. Review date

Link deeper docs: cost control, rate limits.

Anti-patterns

• “AI will pay for itself in engagement” with no meter
• Using list prices from memory in board slides
• Ignoring review labor
• No per-tenant caps on a shared key
• Celebrating call volume as a success metric

Practical next steps

1. Choose U for your top LLM feature this week.
2. Fill the estimator with p90 traces, not demos.
3. Write contribution_per_U on the feature RFC.
4. Add a daily $ cap and an owner.
5. Schedule a 30-day margin review.

Unit economics will not make the model smarter. They will stop you from scaling a feature that only looked cheap in a screenshot.

Worked mini-example (placeholders)

Feature U = accepted email draft.

• Median tokens: 1.5K in + 0.5K out → $0.002 /U at your rates
• Retries + repair: ×1.07 → $0.00214
• Human edit 45 seconds on 30% of drafts → labor $0.01 /U average
• Add-on charges $0.05 /U

Contribution ≈ 0.05 - 0.00214 - 0.01 = $0.03786 /U before other COGS. If drafts are “free” on a $20 plan and heavy users generate 2,000 / month, you need plan packaging or caps — the math shows why.