Build the Token Unit-Economics Model for Your Feature

Workflow area: AI Product Economics · Tier: Advanced · Hands-on time: ~40 minutes

Software PMs inherited an assumption: marginal cost is roughly zero, so more usage is always good. AI features break that inheritance — every generation burns tokens, heavy users can be unprofitable users, and a viral spike can be a margin incident. The unit-economics model is a small spreadsheet with outsized authority: it decides pricing conversations (pb-47), justifies routing work (pb-45), and turns "the AI feature is expensive" from a feeling into three numbers. Build it before finance builds a worse one about you.

When to use — and when not to

• Use it before pricing or packaging decisionspb-47 consumes this model; pricing without it is guessing with confidence.
• Use it when the feature approaches GAbeta economics are noise; GA needs a per-user, per-month cost figure with a distribution, not just a mean.
• Use it when leadership asks "what does this cost us?"arriving with the model, its stress tests, and the margin sentence is the difference between owning the narrative and receiving one.
• Skip the precision theater at prototype stagea one-line estimate (typical tokens × price × guessed volume) is enough to sanity-check a prototype; the full model earns its keep at real traffic.
• Skip it for negligible-cost featuresa once-a-week, short-output feature on a cheap model may round to zero; verify with the one-liner and move on.

The recipe

1. 1.

   Get real token numbers, not estimates. From Langfuse traces, LiteLLM gateway logs, or provider dashboards, pull two weeks of production (or beta) data: input tokens and output tokens per interaction — as a distribution (p50, p90, p99), not a mean. Input includes what teams forget: system prompt, retrieval context, conversation history re-sent every turn. A chat feature's input cost often grows quadratically with conversation length because history is resent — the trace data shows this; guesses never do.

2. 2.

   Build the sheet with five blocks. In Google Sheets: (1) per-interaction cost = p50 and p90 input tokens × input price + output tokens × output price (prices per million, in a cell you can change, dated); (2) interactions per user per month by segment — light, median, power (p99 user); (3) cost per user per month per segment; (4) blended cost across your actual segment mix; (5) margin view — revenue per user (or allocated revenue for a bundled feature) minus blended cost. Keep every assumption in a labeled cell, never inline in formulas.

3. 3.

   Stress-test with AI as your CFO rehearsal. Paste the model:

   Copy

   You are a skeptical CFO reviewing an AI feature's unit economics.
   Model: [PASTE THE SHEET — assumptions, per-segment costs, margin]
   Pricing context: [WHAT USERS PAY / WHICH PLAN BUNDLES THIS]
   
   1. Recompute my blended cost per user and flag any arithmetic or
      unit errors (tokens vs millions, monthly vs annual).
   2. Stress-test: input price +50%, output price 2×, power-user
      share doubles, median usage 3×, provider deprecates our model
      and the successor costs 40% more. Show margin per scenario.
   3. Identify my three most fragile assumptions and what data would
      firm each up.
   4. Give me the one-sentence gross-margin truth I should tell my
      leadership team, including the ugliest scenario.
   

   Sample output fragment:

   Copy

   Fragile assumption #1: interactions/user for power segment is
   drawn from beta users who self-selected as enthusiasts — GA power
   users could be 2-3× heavier. At 3× usage your top decile costs
   $11.40/user/mo against $9 allocated revenue: negative margin
   concentrated in your most engaged users.
   One-sentence truth: "Feature margin is healthy at median usage
   (~82%) but the top decile is at or below breakeven, so pricing
   needs a usage lever before we scale acquisition."
   

4. 4.

   Add the two curves that change decisions. First, margin versus usage percentile — where does a user become unprofitable? That percentile is pb-47's fair-use line. Second, cost versus time under your growth forecast — the month the feature's absolute spend crosses a threshold finance cares about is the month you'll be asked about it; know it first.

5. 5.

   Publish the one-pager and set the refresh. One page: cost per user by segment, blended margin, the breakeven percentile, the worst stress scenario, and the three fragile assumptions. Re-pull token data monthly (prices and prompts both drift), and re-run on any model or prompt change that alters token counts — a "small prompt improvement" that doubles context is a margin event this sheet catches.

Make it yours

• Cost-per-successful-outcome variant: divide spend by pb-41's successful outcomes instead of interactions — a feature whose cost per interaction falls while cost per success rises is getting cheaper at failing, and only this variant shows it.
• Caching and batching levers: add rows modeling prompt-caching discounts (repeated system prompt and context) and batch-API rates for async work — for long-context features these are frequently 30-50% of spend, and the sheet makes the engineering case for you.
• Multi-model routing input: if pb-45's routing ships, split block (1) by route tier with the observed traffic mix — the sheet then shows exactly what the router saves per month, which is the number that defends its maintenance cost.

Quality check

• Token counts are measured distributionsp50/p90/p99 from traces, including system prompt, context, and resent history; a mean from a guess fails the audit.
• Prices are dated and cell-isolatedprovider prices change; the sheet shows when they were pulled and updates in one cell.
• Power users are modeled separatelythe margin story lives in the tail; a blended-only model hides your unprofitable decile.
• Stress scenarios include model deprecationforced migration to a differently-priced successor is a when, not an if.
• The output is a sentence, not a sheetyou can state the margin truth, its ugliest scenario, and the breakeven percentile without opening the file.