Every LLM pricing conversation happens in dollars per million tokens. Claude Fable 5.1 at $10 in and $50 out reads as expensive. GPT-6 Luna at $0.10 and $0.50 reads as cheap. The 100x spread between them fuels a permanent argument about whether frontier pricing is sustainable, whether the cheap models are subsidized, and whether anyone can afford to build on this stuff.
The argument is real. The unit is wrong. Nobody ships a million tokens. You ship a triaged ticket, a summarized document, a reviewed pull request. Price those instead and the conversation changes shape entirely, because at task granularity the absolute numbers are so small that the famous 100x spread often decides nothing, and the things that do decide your bill are hiding somewhere else.
The Arithmetic Nobody Does
A task shape is two numbers: tokens in, tokens out. The cost of a task is those two numbers against the model's two rates:
task cost = (input_tokens x input_rate + output_tokens x output_rate) / 1,000,000That is the whole formula. Here it is applied to five common shapes, using list prices I verify by hand against provider pricing pages (last full pass October 7, 2026, live in the price tracker):
| Task shape (in / out) | GPT-6 Luna | Haiku 4.5 | Sonnet 5.5 | Fable 5.1 |
|---|---|---|---|---|
| Ticket triage (500 / 10) | $0.00006 | $0.00055 | $0.0011 | $0.0055 |
| Chat turn (2,000 / 400) | $0.0004 | $0.004 | $0.008 | $0.04 |
| 30-page doc summary (20,000 / 1,000) | $0.0025 | $0.025 | $0.05 | $0.25 |
| PR review (30,000 / 2,500) | $0.00425 | $0.0425 | $0.085 | $0.425 |
| Agent session (300,000 / 12,000) | $0.036 | $0.36 | $0.72 | $3.60 |
Sit with the first row. A support ticket gets read, categorized, and routed for six thousandths of a cent on Luna. A dollar buys roughly eighteen thousand of them. Even on Fable 5.1, the most expensive model on the table, the same triage costs about half a cent, and a full pull request review, thirty thousand tokens of diff and context in, a detailed review out, costs about 43 cents. The model everyone calls unaffordable will read your PR for less than the cost of the coffee the human reviewer needed first.
This is the part of the current pricing discourse that the per-million framing hides. Tokens look expensive. Tasks are cheap, and they are cheap on every row and in every column of that table.
So Why Is Your Bill Terrifying
Because the rates are fixed and the shape is not. Every scary LLM bill I have been asked to look at was a shape problem wearing a pricing costume. Three shapes do most of the damage.
Input bloat. Input is the dominant term in almost every real shape: half the cost of a chat turn, 70 percent of the PR review, over 90 percent of the ticket triage. And input is where teams are least disciplined, because adding context never breaks a demo. The whole wiki goes into the system prompt, the full conversation history rides along on every call, and a task that needed 3,000 tokens of context ships with 30,000. That is a 10x cost multiplier available to anyone who will sit down and budget the context window like it costs money. It does.
Agent accumulation. The agent row says 300,000 tokens in, and that is not one giant request. It is forty steps, each one re-reading the growing transcript: tool calls, tool results, and every previous step's reasoning. Naive accumulation grows roughly with the square of the step count, which is how an agent session becomes 150 chat turns in a trench coat. If you run agents, your task shape is a function of your loop design, and a compaction strategy is worth more than any model discount.
Silent multipliers. A retry on schema failure doubles a task. A judge pass adds a task on top of every task. A three-way fan-out with a vote triples the base rate before you start. None of these are wrong, some are exactly right, but each one multiplies the shape, and most teams discover them in the invoice rather than the design review.
The common thread: the levers that move your bill 10x live in the shape column, not the model column. Which also means the list prices above are a ceiling. Prompt caching turns the repeated part of your input into reads at a tenth of the rate, and batch APIs on the major providers run at half price for anything that can wait. A disciplined shape plus a cached prefix routinely beats a model downgrade, with zero quality risk.
The Order of Operations
When the bill becomes a conversation, the instinct is to shop models first. That is backwards. The order that works:
1. Measure the shape you actually have. Not the shape you designed. Export your usage data and look at the real input/output split per model, the cache hit rate you are actually getting, and which workload dominates. The bill analyzer does this in the browser from a provider usage export, and the number it shows for cache opportunity is usually the single largest line item on the table.
2. Fix the shape. Trim the context to what the task needs, stabilize the prefix so the cache hits, cap the agent loop and compact its history. This step is where the order-of-magnitude savings are, and it requires no vendor conversation and no quality regression testing.
3. Then shop the rate. With a clean shape, the tracker's cost-per-task column makes the comparison honest: pick your shape, sort by what the task costs. Moving a workload from Sonnet to Luna is a 20x cut. Whether you can take it is a quality question, not a pricing question, and that brings up the trap at the bottom of the funnel.
When the Expensive Model Is the Cheap One
The table above prices an attempt. Your business pays for a completion. The real unit cost is:
cost per completed task = task cost / success rate + failure rate x cost of the failure pathAnd the failure path has humans in it. An escalated ticket, a re-review, a customer who got a wrong answer and churned: pick any of these and the cost dwarfs every number in the model columns. Put even a deliberately low value on the failure path, say 50 cents of human attention, and a model that fails 5 percent more often adds two and a half cents of expected cost per task. That single assumption swamps the entire fee gap between Luna at $0.0004 and Sonnet at $0.008 three times over. The cheap model has to be nearly as good to be cheap at all, and for shapes where quality gaps are real, the expensive model wins the total-cost math while losing every per-token comparison.
The catch is the phrase "fails 5 percent more often." You do not know that number unless you measure it, and measuring it is harder than it looks: at 50 eval cases, your success-rate estimate carries a margin around 15 points, which is wider than most of the differences that decide these trades. This is exactly the territory of evals that tell the truth, and the sample size calculator will tell you how many cases your comparison actually needs before the routing decision is evidence rather than vibes.
The Caveats, Stated
Three things keep the table honest. First, these are list prices with no caching, no batch, and no negotiated discounts, so treat each cell as a ceiling for its shape. Second, long-context surcharges exist: the GPT-6 line doubles the input rate past 272K tokens in a single request, and parts of the Gemini line do the same past 200K. The agent row models tokens accumulated across many calls at base rates, not one giant request. Third, prices move. The table in this essay is dated, and the live version is hand-verified with a changelog, a feed that fires only when a price changes, and a JSON endpoint you can hit from a terminal: curl -s https://alexryan.tech/api/prices.json.
Ask for the Shape
The models are priced in tokens because that is what providers can meter. Your business runs in tasks, and the gap between those two units is where most bad AI budget decisions live. So when someone quotes dollars per million at you, in either direction, ask for the shape. A vendor claiming 90 percent cheaper: cheaper on which term, at what shape, at what success rate? A stakeholder claiming the API is too expensive to scale: expensive relative to which failure path?
The teams that get this right carry two numbers into every model decision: what a completed task costs, and what a failed one costs. Everything else on the pricing page is an input to those two numbers, not a substitute for them.
FAQ
How do you calculate LLM cost per task?
Input tokens times the input rate, plus output tokens times the output rate, divided by a million. A task shape is just those two token counts. At list price the result is a ceiling: caching and batch only bring it down.
How much does an LLM API call actually cost?
At October 2026 list prices: a ticket triage runs from six thousandths of a cent to about half a cent depending on model. A chat turn, a twenty-fifth of a cent to four cents. A full PR review tops out around 43 cents on the priciest model tracked.
Why is my LLM bill so high if cost per task is tiny?
Rates are fixed, shape is unbounded. Input bloat, agent loops that re-read the transcript every step, and silent multipliers like retries and judge passes grow the shape. Fix the shape before shopping models.
Is a more expensive LLM ever cheaper overall?
Often. Cost per completed task is task cost divided by success rate plus the failure path, and failure paths involve humans. A pricier model that cuts escalations can win easily. Only measured success rates settle it.