Definitions

Definitions

Where the cost goes

Results

1. Cost per resolved task, not cost per call, is the number to manage.
2. The margin lever differs by product: resolution rate for support in my model, model tokens for research.
3. No price structure is best; each moves risk between vendor and customer.

Design rules

• Measure cost per task and per resolved task from traces, split by model, tools, infrastructure and credits.
• Define "resolved" precisely before you price on it, and have a dispute path.
• Set the floor from cost and the ceiling from customer value, then price between them.
• Model your customer distribution, especially the heavy tail, before choosing seat pricing.
• Use caps and quotas (Level 11 module 7) so one customer cannot turn a flat price into a loss.
• Offer included usage plus overage when customers want predictable bills.
• Re-run the numbers whenever model prices, caching or resolution rates change.
• Watch the failure and escalation mix, not only token spend.
• Show customers their usage so billing is explainable.
• Recompute any cost figure you copy; the arithmetic is easy to get wrong.

Interview questions, with the follow-ups

Common mistakes

• Pricing on cost per call or per token and ignoring failures.
• Flat seat pricing with unbounded usage.
• Averaging across customers and missing the heavy tail.
• Using vendor list prices from memory; they change often.
• Not counting retries, tool costs, or failures in cost.
• Outcome pricing without a definition of the outcome.
• No per-customer margin tracking.
• Optimising for escalation rate because it lowers the vendor's cost.
• Copying a cost figure without recomputing it.
• Setting a price once and never revisiting it.

What the example does not do

• Every input is assumed. There is no real traffic, price list or customer data.
• Customers are random draws, not a real distribution; real usage has seasonality, growth and churn.
• No demand model: I did not model willingness to pay, discounting, negotiation or how price changes usage.
• Complexity affects cost and resolution through one invented exponent (-0.3).
• Failure credits and the human task cost are single numbers; reality varies by customer and contract.
• No fixed costs: engineering, evaluation, compliance, sales and support are excluded, so gross margin overstates profit.
• No competitor, tax, currency or contract terms.
• Optional real experiment (I did not run this): export a month of real traces and billing, compute cost per task, per resolved task and margin per customer, and compare with this module's model to see which assumption was most wrong.

For the curious Resolution rate moves the margin more than token price

A 20 percent drop in the agent resolution rate cut the blended margin by 27.5 points in the one-at-a-time test. Vendor cost per agent-resolved task was $1.50 at 35 percent resolution and $0.10 at 75. With each price list tuned to a 60 percent margin on 200 simulated customers, per seat put 10 percent of customers at a negative margin and per task 1.5 percent. Every input is assumed.

What you must be able to say (one page)

• Unit economics start with the unit. For an agent product the unit is a task (a ticket, a report, a pull request), and the number that matters is cost per successful outcome, not cost per model call. Failed and escalated tasks still cost something, so cost per resolved task = cost per task divided by the share the agent resolved. Say this in interviews: "How do you keep cost per resolved task under control?" (Level 11 interview question).
• Cost per task has parts: model tokens (input, output, cached input at a discount), tools and APIs, infrastructure, and credits or support for failures. Level 11 module 5 gives the model-side levers (routing, caching, caps).
• Whose cost is it? In my support example (all inputs assumed) escalated tasks are handled by the customer's own team, so the vendor's cost is the agent run plus credits for failed tasks; the customer's saving is the human work avoided. In my model: model spend $0.062 per task (about $0.108 without prefix caching), tools $0.010, infrastructure $0.005, credits $0.150; total $0.227 per task, $0.41 per agent-resolved task, against customer value of about $2.20 per task (55 percent resolved by the agent x a $4 human task).
• The cost structure depends on the product. The same arithmetic for a research task (2.3 million input tokens, 30,000 output, $0.50 of search per run, assumed) gives $4.73 per task, 77 percent of it model tokens, and $5.91 per resolved task, so caching, routing and per-run caps decide the margin there; in the support example model tokens were only 27 percent and failures and resolution rate mattered more.
• Resolution rate is the biggest lever in my support model. Vendor cost per agent-resolved task: $1.50 at 35 percent resolution, $0.84 at 45, $0.41 at 55, $0.12 at 65, $0.10 at 75. In a one-at-a-time sensitivity test (+20 percent on one input, task pricing at $0.60, base gross margin 63 percent): agent resolution rate down 20 percent cut margin by 27.5 points, model price up 20 percent cut it by 2.2 points, tokens per task up 20 percent by 2.2, failure credit up 20 percent by 4.7. An oddity of my model: a higher escalation rate raised the vendor's margin (+13.5 points), because an escalation is cheaper for the vendor than a failure; it lowers the customer's value, so do not optimise for it.
• Four common price structures, compared on 200 simulated customers (heavy-tailed usage: median 412 tasks a month, p90 2,460, max 7,150), each price list tuned to the same 60 percent blended gross margin: per seat put 10 percent of customers at negative margin (p10 customer margin 7 percent; customers paid $0.46 to $5.78 per resolved task, p10 to p90); per task 1.5 percent negative (p10 30 percent; $0.87 to $1.18); per resolved task 5.5 percent negative (p10 17 percent; every customer paid $0.99); platform fee plus overage 4.5 percent negative (p10 21 percent; $0.61 to $6.97).
• How to read that: per seat is simple but exposes you to heavy users and overcharges light ones per outcome; per task tracks cost but charges for failures; per resolved task aligns incentives but needs a shared definition of "resolved" and moves failure risk to the vendor; a platform fee with included usage and overage gives predictable bills and protects against the tail. Real price decisions also depend on competitors, willingness to pay and sales motion, which I did not model.
• Price between a floor and a ceiling. The floor is cost divided by (1 minus target margin): $0.227 per task at 60 percent margin is $0.57 per task in my model ($11.81 for the research task). The ceiling is the customer's value, here about $2.20 per task. Re-check when model prices, caching or resolution rates change.
• Instrument cost per task from day one. Track tokens, cost and duration for every model call, to enable budget controls and find optimisation opportunities.
• Pricing changes behaviour. With usage-based billing, users are less likely to regenerate responses out of idle curiosity than with a flat subscription, so usage meters change the signals you collect.
• A caution about copied numbers. A worked cost example I read reports 1,695,384 tokens analysing 1,795 companies and says that at $0.15 and $0.60 per million tokens this is about $56.39. By its own formula, tokens x rate / 1,000,000, I get about $0.25 to $1.02. I could not reconcile the two (there may be context I did not see). Always recompute cost arithmetic yourself.
• Honest limits: every price, token count, rate and customer in my example is assumed; nothing here is a market price or a benchmark.