An invoice is a total, not an explanation
There is a moment in every AI programme where finance asks a question engineering cannot answer. The invoice says the number. Nobody can say which feature earned it, which tenant consumed it, or how much of it was spent on attempts that failed. That gap is not an accounting problem and it is not a pricing problem. It is an observability problem, and it is the only one in this course where the business consequence is visible on a spreadsheet before it is visible to a user.
c / p derivation that converts a success rate into a cost multiplier, what happens when you compose it with the published 4x and 15x agent token multipliers, the caching economics with break-even and the four traps that silently delete your discount, the tokenizer change that raises your bill by roughly 30% at an identical posted price, and the three places an attribution key can live - only one of which is enforced.
Verified and primary: the caching multipliers and break-even language, the minimum-prefix and invalidation behaviour, the input_tokens accounting, the 4x and 15x token multipliers, the ~30% tokenizer change, and every line item in the table further down. All read from vendor documentation on 2026-08-13.
Derived, not published: the E[cost per success] = c / p table and the ~25x composition that follows from it. That is arithmetic performed on this page, clearly labelled as such wherever it appears. It is sound and it is not a statistic anyone measured.
Cost per call moves the wrong way 13 min live
This is the single most valuable idea in the leader track, and it is a sign error rather than a magnitude error. If you set a cost-per-call target, you have built an incentive that fights your reliability work, and it will do that quietly, in a review meeting, using numbers that are all completely correct.
The mechanism is worth saying in one sentence you can repeat in a budget meeting: short cheap failures leave the denominator. Any fix that stops attempts abandoning early - a retry path that works, a loop that terminates properly, a tool that stops erroring - removes cheap attempts from your average and replaces them with full-price successful ones. Average cost per call goes up. Cost per unit of delivered work goes down. A team measured on the first number learns to leave the bug in.
The derivation, and it is a derivation
If c is the mean cost of one attempt and p is the probability that an attempt succeeds, then in expectation you pay for 1 / p attempts per success, so E[cost per success] = c / p. That is all it is - a line of arithmetic, not a finding. It is on this page because the numbers it produces are much larger than people expect and because it converts an engineering conversation into a finance one.
Task success rate p | Cost per success, as a multiple of cost per attempt | What it means in a budget conversation |
|---|---|---|
| 95% | 1.05x | Failures are a rounding error. Optimise the model and the prompt |
| 80% | 1.25x | A quarter of your spend is buying nothing. Noticeable, tolerable |
| 60% | 1.67x | Two thirds of a second run, on average, before anything ships. Reliability is now your cost lever |
| 40% | 2.50x | You are paying two and a half times list price for delivered work |
| 25% | 4.00x | Three of every four dollars are spent on attempts nobody can use |
Now compose that derivation with two numbers somebody actually measured, and the leader-track punchline arrives.
Read the bottom line of that figure carefully, because it makes the table optimistic rather than pessimistic. The c / p arithmetic assumes a failed attempt costs the same as a successful one. In agent systems it usually costs more: the failure modes that dominate are loops, repeated steps, retries and timeouts, all of which burn tokens for longer before giving up. So the real ratio at 60% success is worse than 1.67x, and the honest way to present the ~25x number is as a floor with a wide error bar rather than as an estimate.
LiveAttribute at the task level, not the call level4 min▶
A task is what the user asked for and what you charge for. A call is an implementation detail that your engineers can change ten times this quarter. If your unit of cost is the call, then every architectural improvement looks like a cost regression and every architectural regression looks like a saving.
This is also where a real telemetry trap lives, and it is builder session b4's territory: in the agent conventions, token attribution double-counts by design. The invoke_agent span carries aggregate token usage and each child inference span carries its own. Sum across depths and you inflate your own cost figures, then spend a week explaining a variance that you created. Sum at one level only.
The metrics worth asking your team to emit, each sliced by tenant, feature and model: cost_per_task_attempt, task_success_rate, cost_per_successful_task, cost_per_failed_task, tokens_per_task, cache_hit_rate, retries_per_task, steps_per_task. Note the fourth one. Cost per failed task is the number that tells you whether your failures are cheap and fast or expensive and stubborn, and it is the one nobody thinks to ask for.
The discount that quietly is not applied 22 min live
Prompt caching is the largest single lever on an AI bill and the most fragile. The pricing is simple enough to fit in three lines. The four ways it silently stops working are the reason your spend chart has a step change in it that nobody can explain, and three of the four return no error at all.
Everything about caching economics follows from the asymmetry in that figure. The write costs more than an uncached request and the read costs almost nothing, so caching is a bet that the read will happen. When the bet pays you get a 10x discount on the cached portion. When it does not, you have paid a 25% or 100% premium for the privilege of trying. Nothing in your telemetry announces which of the two occurred unless you put the token quartet on the span.
Trap four is the one to take back to your team today, because it is not a cost bug, it is a measurement bug that makes every other cost investigation unreliable. A dashboard reading input_tokens on a request that reuses a 200k cached document reports 50 tokens instead of roughly 200,050. Under-reporting by a factor of about four thousand on your highest-volume request pattern is enough to make token-per-request charts, per-tenant attribution and capacity forecasts all quietly wrong in the same direction.
LiveThe tokenizer trap: a 30% increase at an identical posted price5 min▶
Claude 4.7 and later models use a newer tokenizer, and the documentation states plainly that it produces approximately 30% more tokens for the same text. Sit with what that means for a migration decision. You move to a newer model at an identical posted dollars-per-token price, your traffic does not change by a single request, and your bill goes up by roughly 30%.
Now the observability point, which is the reason this belongs in this course rather than in a procurement deck. Your dollars-per-token chart looks perfectly fine, because the price per token really did not change. The chart that moves is tokens per request - and most teams do not have that chart, because tokens per request feels like an engineering detail rather than a financial one. If your only cost telemetry is the invoice and a price list, this change is undetectable until the month closes, and then it is indistinguishable from a usage increase.
It also breaks anything you threshold on token counts. Alerts on tokens per request, context-window headroom warnings, per-tenant token quotas and truncation-risk monitors all shift by about 30% for a reason that is not a bug and will not appear in any changelog you own.
Self-studyLine items that never appear on a token dashboard4 min read▶
All figures below were read from vendor documentation on 2026-08-13 and every one of them should be re-verified before you quote it internally.
| Line item | What it costs | Why it surprises people |
|---|---|---|
| Batch API | 50% off input and output, and it stacks with caching. 24-hour expiry, and expired requests are unbilled | The largest uncontroversial discount available. Observed batch cache hit rates run 30-98%, so the two discounts compound unpredictably |
| Web search | $10 per 1,000 searches, and results count as input tokens again on subsequent turns | You pay for the search once and for its results on every following turn of the conversation |
| Web fetch | Tokens only, but roughly 125,000 tokens for a 500 kB research PDF | One unbounded fetch can consume a context window, which is a quality incident and a cost incident at once |
| Code execution | 1,550 free container-hours per organisation per month, then $0.05 per hour - and it is billed even if never called when files are attached | A cost you incur by configuration rather than by use, which no per-call attribution model will find |
| Geographic routing | inference_geo: "us" applies 1.1x on every token category | A compliance decision made by one team appears as a 10% cost increase owned by another |
| Tool-use overhead | 286-804 tokens per request depending on model and tool_choice setting | It is invisible in your own prompt text, so your token estimates are low by a fixed amount on every single request |
The pattern across all six: none of them are visible in the prompt your engineers wrote, several are billed by configuration rather than by use, and every one of them lands on a shared invoice with no feature or tenant attached.
Every price on this page carries the date 2026-08-13, and here is the reason stated by a vendor about itself: the Anthropic pricing page's own footnote records that a planned Sonnet 5 increase to $3/$15 on 1 September 2026 "will not occur". A published, dated, scheduled price change was cancelled. Any internal document that quotes a model price without a date is already wrong or shortly will be, and the same holds for the multipliers, the free tiers and the minimum prefix sizes on this page.
Where the key can actually live 7 min live
Attribution has exactly three places to put the key, and they trade off along the same axis every time: the more enforced a boundary is, the coarser it is. Choosing one is a real architectural decision, not a tooling preference, and most teams need two of the three.
The distinction that matters in a governance conversation is between enforced and reported. A workspace with its own spend and rate limits will stop a runaway loop from spending another product's budget, because the provider refuses the request. A tenant.id span attribute will tell you afterwards, beautifully, exactly which tenant's budget got consumed by someone else's bug. Both are worth having and only one of them is a control.
Approve the fix, or reject it ◐ 8 min · in pairs
Commit to a decision before you discuss it, and notice what your instinct does with the first number you are shown. That instinct is the thing this drill is trying to change.
An engineer wants two weeks to fix the retry path in your document-analysis agent. Their write-up says: task success rate goes from about 60% to about 80%, average cost per call rises about 21%, monthly spend rises from $28k to $34k. Your quarterly commitment to finance was to hold cost per call flat. Your product lead has been asking for two weeks of that engineer's time for a feature.
Decide, alone, in one line. Approve or reject. Then write down which number you used to decide, and whether you would have decided differently if the write-up had led with cost per successful task instead of cost per call.
Do the arithmetic on the delivered work. At 60% success, 100 attempts deliver 60 finished tasks. At 80% they deliver 80. Work out the change in cost per finished task and say the two verdicts out loud in the same sentence: cost per call up 21%, cost per successful task down. One of those is the sentence finance was actually asking about.
Find the commitment error. The promise to hold cost per call flat was made in good faith and it is the actual obstacle here. Draft the one-paragraph renegotiation: what you would commit to instead, and what evidence you would show monthly to prove it. Note that the replacement commitment requires telemetry you may not have yet.
Now the version with teeth. Suppose the same two weeks would instead cap runaway loops, cutting cost per call by 15% while task success drops from 60% to 52% because runs that used to succeed on step nine now stop at step five. Cost per call improves. Does anything else? This is the same trap with its sign reversed, and it is the one that gets approved.
The unexplained step change ◐ 7 min · in pairs
A cost investigation with four plausible causes, three of which return no error. Your job is to order the questions, not to guess the answer.
Input-token spend on your customer-support assistant rose 34% between Tuesday and Wednesday. Request volume is flat. Your dollars-per-token figures are unchanged. In the same week the team shipped a new tool for order lookups, switched the system prompt to include the current timestamp for freshness, moved to a newer model at an identical posted price, and enabled streaming so answers feel faster.
Write down the four hypotheses the four changes suggest, and mark which of them would produce an error, a warning, or any log line at all. You should end up with a very short list in the first column and a long one in the third.
Name the one measurement that separates most of them. One chart splits the tokenizer story from the cache-invalidation story immediately, and almost nobody has it on a wall. Say which chart, and say why the dollars-per-token view cannot do it.
Reason through the streaming change. Explain to a sceptical colleague how making answers feel faster could raise the input bill. If your explanation does not mention where the TTL clock starts, try again.
Decide what you fund. You can have one of: a per-request token chart broken down into the cache quartet, an alert on cache hit rate step changes, or a per-tenant cost attribution project. Pick one, name the incident class it would not have caught, and say who you would tell about that gap before it happens.
Try it yourself - this week ◐ 45-60 min total
- Ask for cost per successful task, once, for one feature. Not per call. If nobody can produce it, you have found the gap this session is about, and the reason is almost always that success is not recorded anywhere as a fact - which makes it an instrumentation ticket rather than a finance request.
- Ask for cost per failed task alongside it. This is the number that tells you whether your failures are cheap and fast or expensive and stubborn, and it decides whether reliability work is a cost lever for you or merely a quality one.
- Check whether you log the quartet. Cache creation tokens, cache read tokens,
input_tokens, and their sum. If your dashboard readsinput_tokensalone and you cache long documents, your token numbers are under-reporting by up to about 4000x on your most important request pattern. - Find your cache hit rate and plot it as a line. Then look for step changes and line them up against your deploy history. A drop that coincides with a deploy is almost always a tool definition change or a prefix that started varying, and both are invisible in any error log.
- Do the tokenizer check. If you have migrated to a Claude 4.7 or later model, compare tokens per request before and after at fixed traffic. A step of roughly 30% is expected behaviour, not a bug, and it should be written down somewhere before someone spends a week hunting it.
- Write the c/p line for your own system. One line: at our current success rate of p, every dollar of delivered work costs
1/pdollars of spend. Put the number in the next roadmap conversation and watch how differently reliability work gets discussed when it has a currency attached.
Official sources covered
Every price, multiplier and mechanism on this page was read from primary vendor documentation on 2026-08-13 and is catalogued in this course's source map. The arithmetic built on top of them is labelled as arithmetic. This page covers:
input_tokens counting only tokens after the last breakpointPart 2 · three of the four return no error at allinference_geo: "us" at 1.1x, tool-use overhead of 286-804 tokens per requestSelf-study · all read 2026-08-13, all to be re-verifiedE[cost per success] = c / p and the 1.05x / 1.25x / 1.67x / 2.50x / 4.00x table, plus the ~25x composition with the 15x multiplierPart 1 · a DERIVATION performed on this page, not a published statistic. Sound arithmetic, nobody's measurementinvoke_agent and its child inference spansNamed here · the full trap and the fix are builder session b4Three honesty flags to carry out of the room. The 4x and 15x multipliers describe one production system - Anthropic's own Research feature, circa 2025 - and are a well-documented order-of-magnitude data point rather than a law of agent design. The c / p table and the ~25x composition are arithmetic performed here, and the composition is a floor rather than an estimate, because failed attempts typically cost more than successful ones. And every price, free tier and multiplier above carries the date 2026-08-13 for a documented reason: a scheduled, published price change for 1 September 2026 was subsequently cancelled by the same page that announced it.
Three questions before you go 🎯 ◐ 90 seconds
1 · A fix raises average cost per call by 21% and lowers cost per successful task by 9%. What is going on, and what do you do?
This is the sign error at the heart of the session. Attempts that used to bail out early were cheap, and they were dragging the average down while delivering nothing. Fixing that path replaces cheap failures with full-price successes: the average per call rises, the cost per unit of delivered work falls. A team measured on cost per call learns, entirely rationally, to leave the bug in. The trap also runs in reverse - capping runaway loops can lower cost per call while raising cost per successful task, and that version usually gets approved.
2 · You migrate to a Claude 4.7 or later model at an identical posted price. Traffic is unchanged. What happens, and which chart shows it?
The price per token really did not change, which is exactly why this is an observability problem rather than a procurement one. Your dollars-per-token dashboard stays flat and correct while the bill grows by about a third. The signal lives in tokens per request, a chart most teams treat as an engineering detail and therefore do not have. It also shifts everything you threshold on token counts - context-headroom warnings, per-tenant quotas, truncation-risk monitors - by roughly 30%, for a reason that is documented behaviour rather than a bug.
3 · Your cost dashboard reads input_tokens. A common request reuses a 200k-token cached document and adds a 50-token question. What is your dashboard telling you?
This one is not a cost bug, it is a measurement bug, and it contaminates every cost investigation you run afterwards. Under-reporting your highest-volume request pattern by a factor of roughly four thousand makes tokens-per-request charts, per-tenant attribution and capacity forecasts all wrong in the same direction, with no error anywhere to indicate it. The cached tokens are billed - at 0.1x on a read - they are simply accounted for in different fields. Log all four numbers or none of them mean anything.
Leader session 4 cheat sheet · pin this
E[cost per success] = c / p. 95% gives 1.05x, 80% gives 1.25x, 60% gives 1.67x, 40% gives 2.50x, 25% gives 4.00x. Arithmetic performed here, not a published statistic.input_tokens counts only after the last breakpoint - roughly 4000x under-report on a 200k cached document.