Tiers with an included allowance price the tail without scaring buyers

The pricing meeting had two positions and both were correct. The finance lead wanted usage-based pricing, because revenue that does not track cost is a promise to lose money on some fraction of customers and chapter 5 had put a number on that fraction. The VP of sales wanted to keep the $29 seat, because in the last two quarters three deals had stalled in procurement over exactly one issue: the buyer could not put a number on the purchase order. One of them said, on a call, that he would rather pay more for a fixed amount than less for an amount he had to explain to his CFO every quarter.

Treating this as a choice between the two positions is what produces bad pricing. Both are describing real constraints — the tail is real and unbounded, and enterprise procurement genuinely cannot approve open-ended spend — and a structure exists that satisfies both, at the cost of billing machinery neither side wants to build.

Four shapes, and what each one costs you#

Every pricing model relocates the same three discomforts: who bears the risk of unexpected usage, who has to build and explain the billing, and whose forecast gets worse.

Pure usage pricing is not wrong in general, and it is wrong for this product specifically. It fits when consumption is the thing being bought and the buyer already thinks in those units, which is why it works for infrastructure and for API products sold to engineers. This product is sold to operations managers on a seat plan next to two other seat-plan tools, and asking that buyer to forecast token consumption puts a question in front of them that they cannot answer and did not want to be asked.

Flat pricing is not wrong either, up to the point where a customer can multiply their consumption without multiplying their bill. The whole argument against it is the distribution, not the concept.

Sizing the allowance so almost nobody sees it#

The design is a $29 seat that includes an allowance of task credits, pooled across the account, with priced overage beyond it — an overage being a per-unit charge that applies only to consumption above what the plan already includes. One credit is one task on this product, and the number that decides whether the structure is a change to your product or an accounting detail is the size of the allowance.

Chapter 5's distribution converts directly: at $0.19 of model cost per session, the median seat's $2.10 is about 11 sessions a month, p95's $14.00 is 74, p99's $61.00 is 321, and the $340 maximum is about 1,790.

At 150 credits the allowance is 13.6× the median seat and about 2× the p95 seat, which means the plan behaves identically to today's flat $29 for 96% of accounts. Sales keeps the motion it has, the pricing page still says $29, and the overage clause is a line in the contract that most customers will never exercise. It recovers $5,200 a month, which is 26% of total model spend and considerably more than the $6,000 of gross profit the loss-making seats were destroying.

Pooling at the account level rather than per seat matters more than it looks. It absorbs the ordinary internal variance where three power users do most of the work and twenty colleagues barely log in, which is the common and entirely legitimate pattern, so the overage line only appears when the account's consumption is genuinely out of proportion to what it bought. A per-seat allowance would generate overage invoices for customers who are collectively cheap, and every one of those is a support ticket and a renewal risk.

Overage price is set from cost, not from the headline. At $0.19 of model spend and roughly $0.05 of other variable cost per session, $0.35 a credit holds a 31% margin on incremental usage, below the 68% fleet margin so it reads as fair rather than punitive, and high enough that a customer running an unbounded batch is paying for it.

INCLUDED_PER_SEAT = 150
OVERAGE_PER_CREDIT = 0.35
SEAT_PRICE = 29.00

def invoice(seats: int, credits_used: int) -> dict:
    included = seats * INCLUDED_PER_SEAT
    overage = max(0, credits_used - included)
    base = seats * SEAT_PRICE
    return {
        "base": base,
        "included": included,
        "overage_credits": overage,
        "overage_charge": round(overage * OVERAGE_PER_CREDIT, 2),
        "total": round(base + overage * OVERAGE_PER_CREDIT, 2),
    }

print(invoice(seats=38, credits_used=14_206))
# {'base': 1102.0, 'included': 5700, 'overage_credits': 8506,
#  'overage_charge': 2977.1, 'total': 4079.1}

print(invoice(seats=62, credits_used=3_900))
# {'base': 1798.0, 'included': 9300, 'overage_credits': 0,
#  'overage_charge': 0, 'total': 1798.0}

Northwind moves from $1,102 of revenue against $2,840 of model cost to $4,079 against the same cost, which turns a 158% loss into a healthy account without anyone having a difficult conversation, because the mechanism was in the contract they signed. Callisto pays nothing extra, and that is the structure's first honest failure.

Choosing the unit you meter#

Callisto's 3,900 sessions sit comfortably inside their 9,300-credit allowance while costing $0.36 each, nearly double the fleet median, because their workflow attaches whole contracts. A credit defined as one session is blind to that, so the allowance does not protect against the oversized-context mechanism from chapter 6 at all.

The unit has to correlate with cost and be comprehensible to the buyer, and those pull in opposite directions. Tokens correlate almost perfectly and are unforecastable by an operations manager. Sessions are perfectly comprehensible and correlate only with one of the three cost mechanisms. The workable middle is a credit defined by a published conversion — one credit per task up to 20,000 input tokens, then one additional credit per further 20,000 — which keeps the ordinary case at one credit per task and makes the expensive case cost proportionally more, without asking anyone to think in tokens. Under that definition Callisto's 46,000-token sessions cost three credits each, 11,700 credits against a 9,300 allowance, and $840 of overage appears on an account that is genuinely more expensive to serve.

That conversion is also the point at which the pricing page has to explain itself, and there is a real limit to how much explanation a pricing page can carry before it starts costing deals. Two rules is usually the ceiling.

Metering you are willing to defend on an invoice#

The moment a number appears on an invoice it stops being telemetry and acquires obligations that analytics pipelines are not built for. A dropped event in a usage dashboard is a rounding error; a dropped event in a billing meter is revenue you never recognise, and a duplicated event is a charge a customer will dispute and win. The counter has to be written idempotently, keyed on the session identifier, in the same transaction that records the session, so that a retried request or a replayed queue message cannot bill twice.

It also has to reconcile. Run a monthly comparison between credits billed and the provider's own usage report for the same period, and expect a gap of a percent or two from sessions that errored after the meter incremented; investigate anything larger, because a systematic divergence means one of the two systems is wrong and you do not yet know which. Keep the raw session-level records for the full dispute window, typically a year, because the first serious overage invoice will arrive back with a request to see the underlying detail and "our dashboard says so" is not an answer.

Two operational habits keep disputes rare. Show the customer their consumption in the product, updated daily, on the same page as their plan, so the number on the invoice is one they have already seen. And write the credit policy before you need it — what happens when a customer's integration misfires, how much you will forgive, and who can approve it — because deciding that during an angry call produces inconsistent outcomes that then become precedent.

What to recommend, and what to do about the accounts you already have#

Given the $29 seat with median $2.10, p95 $14.00, p99 $61.00 and a $340 maximum, the recommendation is to keep the headline price and the seat model, add a pooled allowance of 150 credits per seat with $0.35 overage and the token-based conversion, and pair it with three things that are not pricing. A per-request token cap stops a single pathological request; per-key rate limits stop a runaway integration from producing a five-figure surprise for both sides; and a committed-volume plan gives accounts like Northwind, whose consumption is planned and legitimate, a way to buy what they actually need at a discount rather than through an overage line they will resent.

Rolling it out matters as much as designing it. New contracts take the new structure immediately. Existing customers get grandfathered — kept on the terms they already signed — with a dated notice, usually one renewal cycle, and the seven accounts the chapter 6 query surfaces get an individual conversation before any automated invoice reaches them, because the first overage bill a customer receives should never be a surprise. Instrument the allowance before you bill on it: run it in shadow mode for two months, meaning the meter counts credits and the invoice ignores them, show customers their consumption in the product, and send the 80%-of-allowance notification from the start. Enterprise buyers tolerate paying more, and they do not tolerate finding out after the fact.

The structure still has an edge it does not cover. An allowance bounds your exposure per account only if there is a cap or a hard limit behind it, and a customer whose integration goes wrong can accumulate a $40,000 overage in a weekend that they will dispute and you will mostly credit. A cap at 3× the included allowance for a first breach, with an alert to the account team, costs a little revenue in exchange for never having that argument.

None of this is a permanent settlement, because both sides of the ratio move. The allowance is sized against a cost per session of $0.19, and that number is a function of model prices that have historically fallen fast and unevenly. A structure that is correct at today's rates has to be re-derived when the rates change, and a large enough change alters more than the arithmetic.