In the worked example in this guide, the model bill is 11% of what the AI feature really costs to run. The roadmap only had room for that 11%.
AI unit economics is the cost and revenue of one unit of work your AI feature completes. The unit that matters is the task, not the token or the API (Application Programming Interface) call, and the number to manage is cost per successful task: everything it costs to serve a task, including model calls, retrieval, retries, checks and human review, divided by the share of tasks that actually succeed. A task is one finished piece of work, such as a drafted support reply or a summarised contract.
If you only remember one line from this guide, make it this: a failed task still costs money, so the price of an AI feature is set by its cost per successful task, not by the price list of the model underneath it.
Five questions product managers ask (quick answers)
- What is the unit of cost for an AI feature? The task: one finished piece of work for a user. Tokens and model calls are inputs to a task, not the thing a customer buys.
- What goes into cost per task? Model calls (input and output tokens), retrieval and reranking, retries, quality checks, logging, and any human review or escalation.
- Why do agents cost more than their step count suggests? Each step usually re-sends a growing context, so cost can rise faster than the number of steps. In the example below, a 20-step run costs 18.8 times a 3-step run.
- Should I price an AI feature flat, by usage or by outcome? Flat seats are simple but subsidise heavy users. Usage and outcome pricing track cost but are harder to sell. Decide from the cost of your heaviest users, not your average user.
- What should I do first? Run 20 real tasks end to end, log every cost, and build one spreadsheet. An hour of work gives you a number you can defend in the budget meeting.
A scene you will recognise
This is an illustrative scenario, not a real company. A product manager at a software company pitches an AI reply assistant for the support team. The slide says: "About 1.5 cents per ticket." The number is right. It is the model bill for one clean pass through the draft.
Then the feature meets reality. Some drafts fail a quality check and run again. A search step has to find the policy passages each draft needs. One draft in five goes to a person for review before it is sent. One ticket in five is not resolved even so. When finance adds it all up, a ticket costs closer to 14 cents to serve, and a ticket that is actually resolved costs closer to 17 cents.
Nobody changed the model. The slide counted the cheapest line. The sections below show how to count the rest, before the budget meeting rather than after it.
Three habits sink AI feature budgets: costing the model call instead of the task, averaging over users instead of looking at the heavy ones, and treating human review as free.
Why this question is suddenly everywhere
On 26 October 2026 Anthropic announced that it had filed a registration statement on Form S-1 with the US Securities and Exchange Commission for a proposed initial public offering. The prospectus is a public document, and one passage in it matters to anyone shipping an AI feature. It says the company's primary revenue model is what it calls pay-for-intelligence: customers pay for usage, which is metered in tokens and priced according to the model selected.
The same passage reports that consumption-based revenue was $13.1 billion, or 80% of total revenue, in the six months ended 30 June 2026, with subscriptions at $3.2 billion, or 20%. It also gives consumption-based revenue as 75% of total revenue in 2024 and 83% in 2025, and says the company expects it to remain the substantial majority of total revenue.
The prospectus also says that the model a customer uses and the volume of usage are the primary drivers of customer spend, and that customers often route individual tasks to different models along a curve of capability, cost and speed. That is the unit-economics problem in one sentence: your cost follows the model you choose and how much work you send it.
What the filing does not tell you is how to price your own product, what your margin should be, or whether anyone should buy shares in anything. This guide takes no view on the offering. A revenue mix dominated by large API customers says little about a feature with a few thousand users, so treat it as evidence that usage-based cost is normal, not as a benchmark. The filing is linked at the end, and the figures above come from it.
The wider point holds without the news. When a feature's cost scales with usage, the finance question changes from "what does this cost per month?" to "what does it cost each time someone uses it, and who pays for that?" That is the unit-economics question, and product managers who can answer it get budgets approved faster.
Four units that get mixed up
| Unit | What it is | Why it misleads |
|---|---|---|
| Token | A chunk of text the model reads or writes, roughly three-quarters of an English word. Providers usually price input and output tokens separately, and output tokens usually cost more per token. | It is the supplier's price list, not your cost |
| Request (API call) | One call to the model | A feature often makes several calls for one piece of work |
| Task | One finished piece of work for a user: a drafted reply, a summarised contract, a completed research brief | This is the right unit for cost, because it matches what the user experiences |
| Successful task (outcome) | A task that met your quality bar and needed no rework | This is the right unit for pricing and margin, because failures still cost money |
One India-specific point on tokens. Text in Indian languages often needs more tokens per word than English, and how many more depends on the tokenizer of the model you use. If your support queue mixes Hindi and English, test a sample of real tickets with your provider's tokenizer before you assume the English cost per ticket holds.
Worked example 1: cost per task, line by line
The prices in this example are illustrative round numbers, chosen so the arithmetic is easy to follow: $1.00 per million input tokens and $5.00 per million output tokens. They are not any provider's price list. Real prices differ by model, change over time, and many providers discount cached input and batch work, so put your own current prices into your own sheet.
The assistant drafts replies to support tickets. Each ticket goes through three model calls: classify the ticket, draft a reply from retrieved policy passages, and run a quality check on the draft. The other assumptions are:
- 15% of drafts fail the check and repeat the draft and check steps once.
- Retrieval and reranking cost $0.002 per task, counting a share of the search infrastructure.
- 20% of drafts are reviewed by a person for 2 minutes, at $18 an hour fully loaded, so each review costs $0.60.
- 80% of tasks end resolved. The other 20% need follow-up.
| Line | Assumption | Cost per task |
|---|---|---|
| 1. Classify the ticket | 1,200 input tokens + 100 output tokens | $0.00170 |
| 2. Draft the reply | 6,000 input tokens (ticket, five passages, history, instructions) + 400 output tokens | $0.00800 |
| 3. Quality check | 3,000 input tokens + 150 output tokens | $0.00375 |
| One clean pass | Lines 1 to 3 | $0.01345 |
| 4. Retries | 15% of tasks repeat lines 2 and 3 | $0.00176 |
| The model bill | Lines 1 to 4 | $0.01521 |
| 5. Retrieval and reranking | Search infrastructure share | $0.00200 |
| Automated cost | Lines 1 to 5 | $0.01721 |
| 6. Human review | 20% of tasks × $0.60 per review | $0.12000 |
| Cost to serve one task | Lines 1 to 6 | $0.13721 |
Read the table from the bottom. The model bill of $0.01521 is 11% of the $0.13721 it costs to serve a task, so the full cost is about nine times the number on the pitch slide. Human review alone is 87% of the total.
Now divide by success. If 80% of tasks end resolved, the cost per successful task is $0.13721 ÷ 0.80, which is about $0.17. If the feature is priced at $0.50 per resolved ticket, the gross margin per successful task is ($0.50 − $0.1715) ÷ $0.50, about 66%. Change the success rate to 60% and the same cost per task becomes $0.23 per successful task and a margin near 54%. The quality of the feature is a cost input, not only a satisfaction metric.
The lever that matters is not the one on the pitch slide
Suppose the model provider halves its price. The model bill falls by about $0.0076 and the cost to serve falls from $0.1372 to $0.1296, a 5.5% saving. Now suppose the team proves the drafts are good enough to cut the review rate from 20% to 10%. The cost to serve falls by $0.06, to $0.0772, a 44% saving. In this example, halving the review rate does about eight times more for cost than halving the model price.
That is only legitimate if quality holds on the drafts that no longer get reviewed. Cutting review without an evaluation that shows quality holds is how a cost saving becomes an incident. It is also a reminder that the evaluation harness is part of the cost model, not a separate project. For more on measuring value rather than just cost, see Measuring AI ROI.
If the person reviewing the draft is your customer's employee, not yours, the review cost sits with them. It still belongs in the model, because it is part of the value they get and the reason they will or will not renew.
Worked example 2: agent costs grow faster than the number of steps
An agent works in a loop: call the model, run a tool, add the result to the context, call the model again. Unless the provider caches the repeated part, each call pays again for everything already in the context. So the input tokens do not grow with the number of steps. They grow faster than that.
The assumptions here are simple. The first call carries 4,000 tokens. Each step adds 1,500 tokens of tool results to the context that is re-sent on the next call. Each step writes 300 output tokens. There is no caching, and the prices are the same illustrative ones as above.
| Steps in the run | Input tokens over the run | Output tokens | Cost per run | Compared with 3 steps |
|---|---|---|---|---|
| 3 | 16,500 | 900 | $0.0210 | 1.0× |
| 10 | 107,500 | 3,000 | $0.1225 | 5.8× the cost for 3.3× the steps |
| 20 | 365,000 | 6,000 | $0.3950 | 18.8× the cost for 6.7× the steps |
Now put that inside a price. Say the plan is a flat $30 per seat per month and a heavy user runs 100 research tasks a month. At 10 steps a task the cost is $12.25 and the seat earns a 59% margin. At 20 steps a task the cost is $39.50 and the seat loses $9.50, a margin of −32%. The break-even volume is about 245 tasks a month for 10-step tasks and about 76 for 20-step tasks.
Caching repeated context, trimming what each step carries, and capping the number of steps can all bend this curve. They are worth doing, and each is something to measure, not assume. The point of the example is that the average user and the heavy user can sit on opposite sides of break-even, and a flat price hides it. For background on how agents and loops behave, see What Are AI Agents? and Loop Engineering.
What hides in the cost to serve
- Retrieval and indexing. Search infrastructure, the embedding of every document, the cost of re-embedding when documents change, and reranker calls. The pipeline is described in the complete builder's guide to RAG (Retrieval-Augmented Generation) architectures.
- Quality checks and evaluation. A second model that grades the first one, run on live traffic, and test sets that run before every release.
- Retries and fallbacks. Malformed outputs, timeouts, tool errors, and escalation to a stronger and more expensive model.
- Human review and escalation. Usually the largest line when it exists, as the first example shows.
- Context bloat. Long system prompts and full chat history re-sent on every call.
- Language mix. More tokens per word in some languages, which raises the cost per task for those users.
- Logging, monitoring and support. Storage, dashboards, and the engineer who is paged when the bill spikes.
- Fixed costs. The team's time. It does not belong in cost per task, but it belongs in the business case.
- Currency. Many API providers bill in US dollars. If you charge in rupees, the exchange rate is a margin input. Check the currency on your own invoice.
Pricing an AI feature: seats, usage or outcomes
| Model | How it works | It works when | Watch for |
|---|---|---|---|
| Flat seat | A fixed fee per user per month | Usage is fairly even, or capped | Heavy users cost more than they pay, as in example 2 |
| Seat plus allowance | The seat includes a number of tasks; extra tasks are billed | A minority of users drive most of the cost | Customers dislike surprise bills, so show usage in the product |
| Usage-based | The customer pays per task or per credit | Cost varies a lot by user and buyers accept metering | Bill shock, and the buyer cannot forecast spend |
| Outcome-based | The customer pays per resolved ticket, qualified lead or similar | You can define and verify the outcome | Disputes about what counts, and you carry the cost of failures |
Whichever model you choose, set the price from the heavy-user cost, not the average. The 95th percentile of cost per user is where the pricing risk sits.
Five numbers to put in the PRD (Product Requirements Document)
- Cost per task at p50 and p95. p50 is the median task and p95 is the cost that 95% of tasks stay under. Write both. The p95 is the number that breaks plans.
- Success rate, defined before launch. What counts as a success, measured on a test set and on sampled live tasks.
- Cost per successful task. Cost per task divided by the success rate.
- Gross margin per successful task at the target price. (Price − cost per successful task) ÷ price.
- Break-even volume per user per month on the chosen plan. Plan price ÷ cost per task.
Add a stop-loss rule next to them: if p95 cost per task or margin per successful task is worse than a stated limit for two weeks in a row, the team re-scopes or switches the plan, in a decision made in advance rather than during an incident. The Kill It or Keep It test is a good companion for the harder question of whether the task should be automated at all.
A spreadsheet in one hour
- Pick 20 real tasks from logs or a pilot. Include hard ones, not only clean ones.
- Run each end to end with logging on. For every step record the model, input tokens, output tokens, retrieval calls, retries, whether a person touched it, and the outcome.
- Take token prices from your provider's current price page and keep them in one cell, so you can change them in one place.
- Add human time at a fully loaded hourly cost.
- Compute cost per task, success rate and cost per successful task. Then sort tasks by cost and read the three most expensive. They often explain most of the gap between p50 and p95.
- Add a sensitivity table that moves the model price, the review rate and the step count by 50% each way.
- Share the sheet with finance and engineering before the roadmap meeting, and keep it as the starting point for the real dashboard.
Levers that cut cost, and what to check first
| Lever | What it does | What to check before you ship it |
|---|---|---|
| Route easy tasks to a smaller model | Pays less per token on the easy slice | Quality on that slice, and how often the router is wrong |
| Trim the context | Fewer input tokens: shorter instructions, no stale history | Answer quality on your test questions |
| Cache repeated context | Many providers discount repeated input | Cache hit rate, and how long the cache lives |
| Cap steps and set stop rules | Stops runaway loops | The share of tasks that hit the cap and fail |
| Batch non-urgent work | Many providers discount asynchronous batch jobs | Whether the turnaround is acceptable to users |
| Fix the cause of retries | Fewer repeated calls | Retry rate before and after |
| Lower the human review rate | The biggest lever in example 1 | An evaluation showing quality holds on the drafts that skip review |
Every lever trades something against quality, so measure quality on a fixed test set before and after each change. Track cost per successful task, not cost per task, otherwise a cheaper and worse feature looks like a win.
When the numbers go wrong: symptom, cause, fix
| Symptom | Likely cause | Fix |
|---|---|---|
| The bill is far above the forecast | The forecast used the average, and heavy users or long agent runs dominate | Forecast with p95, add step caps and plan allowances |
| Margin looked fine in the demo and is thin in production | The demo had no retries, no review and short context | Cost 20 real tasks, hard ones included |
| Cost per task fell but complaints rose | A cost cut lowered quality | Re-run the evaluation and manage cost per successful task |
| Tickets in some languages cost more | More tokens per word for that language | Measure cost by language and test alternative models or tokenizers |
| One customer drives a large share of spend | A flat plan with no allowance | Add an allowance, a tier or usage billing |
Brief your coding agent to log cost per task
Do not estimate from the price list once the feature runs. Ask your coding agent to instrument it. You supply the prices and the definition of success, because an agent will invent easy ones. The agent supplies the plumbing.
Add per-task cost logging to this feature. 1. Wrap every model call so it records: task_id, step name, model, input_tokens, output_tokens, latency, and whether it was a retry. 2. Record retrieval calls and reranker calls per task_id. 3. Record whether a person reviewed or edited the output, and the review time in seconds. 4. Record the outcome field: success, failure or escalated, using the definition in SUCCESS.md. 5. Read prices from prices.json (I will fill it in). Never hard-code a price. 6. Write one JSON line per task to costs.jsonl. 7. Add a script report.py that prints p50 and p95 cost per task, success rate, cost per successful task, and the five most expensive tasks. 8. Add a test with three fake tasks that checks the arithmetic. Do not change any prompt or model setting.
Read the first 20 lines of costs.jsonl yourself before you trust the report. Check that retries are counted, that the review time is real, and that a failed task is not silently dropped.
When to re-scope, re-price or stop
If cost per successful task at p95 is higher than what the customer will pay, you have four honest options. Narrow the task to the slice where the economics work. Change the model mix or the context to cut the cost. Change the plan, with an allowance or usage billing. Or stop, and spend the budget elsewhere. Stopping is a fine outcome when the numbers say so, and the cheapest time to learn it is before launch. The decision test for whether AI should do the task at all is in Kill It or Keep It, and the wider practice of building AI into products is covered in AI-Native Product Development and AI for Product Managers.
Frequently asked questions
What is AI unit economics?
It is the cost and revenue of one unit of work that an AI feature completes. For most features that unit is a task, such as a drafted reply, and the key figure is cost per successful task: total cost to serve divided by the share of tasks that succeed.
What is cost per task for an AI feature?
It is the sum of everything needed to complete one task: the input and output tokens of every model call, retrieval and reranking, retries, quality checks, logging, and any human review or escalation. It is almost always larger than the model bill alone.
Why is cost per token not enough?
Cost per token is the supplier's price, not your cost. A task can involve several model calls, retries, search and human review, and some tasks fail. Tokens are one input to the cost of a task, and a cheaper token does not help if the task needs more tokens, more retries or more review.
What is cost to serve for an AI feature?
It is the cost of delivering the feature to a user each time it is used: model usage, retrieval, checks, retries, human review, infrastructure and support. It excludes fixed costs such as the team's time, which belong in the business case instead.
What is a good gross margin for an AI feature?
There is no standard I can verify, and published rules of thumb mostly come from vendors and disagree with each other, so this guide does not quote one. Set a floor from your own plan: what you charge, what the heaviest users cost, and how much the team must keep for support and improvement.
How do AI agents change the cost?
An agent makes several model calls per task, and each call usually re-sends a growing context. Cost therefore tends to rise faster than the step count unless the provider caches repeated context. In the illustrative example, 20 steps cost 18.8 times a 3-step run. Cap steps, trim context and measure the real curve.
Should I charge flat, by usage or by outcome?
Flat seats are simple but subsidise heavy users. A seat with an allowance protects margin without a surprise bill. Usage pricing tracks cost but makes spend hard to forecast for the buyer. Outcome pricing aligns incentives but needs an outcome you can define and verify. Choose from the cost of your 95th-percentile user.
How can I reduce the cost of an AI feature without hurting quality?
Route easy tasks to a smaller model, trim the context, cache repeated input, cap steps, batch non-urgent work, fix the causes of retries, and lower the review rate only where an evaluation shows quality holds. Test each change on a fixed set of real tasks and track cost per successful task.
How do I estimate the cost before I build?
Take 20 real tasks, walk each one through the steps you plan to build, count the tokens and calls, add retrieval and human time, and compute cost per task and per successful task. Then move the main assumptions by 50% each way to see what the plan can survive. Replace the estimate with logged data as soon as a prototype runs.
Does a model provider's public filing tell me what to charge?
No. The filing in question describes how one company earns revenue: customers pay for usage, metered in tokens and priced by the model they select. It does not set a price for your product, and nothing in this guide is investment advice.
Learn to build and cost these systems with us
To follow this series as each post publishes, join the Garage Labs community. If you are a product manager, senior PM, product lead or product owner with 5+ years of experience, the Applied AI Practitioner Program is a 12-week, build-first programme with live sessions and build labs. Modelling AI unit economics and building a defensible business case is one of its stated outcomes, alongside builds such as an AI product copilot, a grounded RAG (Retrieval-Augmented Generation) knowledge assistant with citations, an autonomous research agent and an evaluation harness with measured before-and-after quality gains. It does not teach product management fundamentals, so it suits people who already have them. See the programme page for the current schedule and details.
Found this useful? Share it with someone who needs it. Visit garagelabstech.com and follow Sumit Kumar Singh for more on LinkedIn.
Sources and further reading
- Anthropic, PBC, Form S-1 registration statement, section "How We Generate Revenue" (filed October 2026)
- Anthropic, Anthropic files S-1 with the SEC for proposed initial public offering (26 October 2026)
- CNBC, news coverage of the filing (26 October 2026), for context
- Your own model provider's current pricing page and invoice. Prices, discounts and billing currency change, and every price in this guide's worked examples is illustrative.