Short answer, first screen: your AI wrapper's gross margin is (price − real token COGS) ÷ price, where real token COGS is the tokens you actually buy per billed unit — not the tokens the customer sees. Those two numbers are rarely close. A single model call on a $2/$10 model might cost $0.018, so a founder eyeballs a $0.50 price and declares a 96% margin. The real cost of delivering that one task — after the tool loop, the retries, and the context you re-send on every call — is closer to $0.07. The margin is real, but it's 86%, not 96%, and on the wrong pricing model that ten-point gap is the difference between a business and a hobby.

This is the calculation nobody does until a vendor raises prices. Anthropic just told public markets it runs an ~85% gross margin — which means the price you buy tokens at already keeps most of the dollar for your vendor, and the era of below-cost promotional token pricing is on a clock. Your headroom starts lower than theirs and is likely to shrink. Here's how to find out where you actually stand, in one page.

The four taxes between "one call" and "one task"#

The reason your spreadsheet lies is that it costs the nominal call — one request, happy path — when what you ship is a completed task. Four things stack in between:

  1. The loop tax. An agent or tool-using flow makes several model calls per task: plan, call a tool, read the result, call again, answer. Three to six calls per "task" is ordinary. Your COGS multiplies by the call count.
  2. The context tax. Every one of those calls re-sends your system prompt, instructions, and conversation history. A 2,000-token system prompt sent on six calls is 12,000 input tokens the user never typed. Caching helps — but only if you've turned it on and your prompt prefix is stable.
  3. The failure tax. Retries on timeouts, rejected or malformed generations you regenerate, calls that error after burning input tokens. You pay for tokens that produced nothing. Budget 10–25% on top, measured from your own logs.
  4. The off-product tax. Evals, demos, the free tier, and abuse all consume tokens no customer is billed for. Amortize them across your billed units, because that's where they actually land on the P&L.

Stack those and the naive estimate commonly lands 3–5× low. That multiplier, not the per-token rate, is what you were missing.

A worked example (illustrative)#

Say a task is ~4,000 input + 1,000 output tokens, on a model at $2 / $10 per million:

At a per-task price of $0.50, that's a gross margin of (0.50 − 0.07) ÷ 0.50 = 86%. Healthy. Now change nothing but the pricing model.

At a $20/month flat seat:

Nothing about your cost per task changed. The pricing model changed who your margin depends on. Metered pricing passes the cost through and keeps margin flat. Flat-seat pricing makes your gross margin a function of your usage distribution — and LLM tokens are the first variable cost in modern SaaS big enough to make an "unlimited" plan structurally lose money on its tail. (This is the same mechanism behind why agent costs scale quadratically: the heavy user isn't 10× the light one, they're 10× compounded through the loop.)

The number to carry out of this#

Compute token COGS as a share of your price, because that single ratio tells you your exposure:

That's why this isn't a finance-team chore for later. Measure cost per completed task, not per call, do it from production traces, and re-run it at standard API rates rather than today's introductory ones. The vendor already knows its margin to the basis point — it just showed the number to the market. The only question is whether you know yours before the price moves.