{"course":{"slug":"agents-and-automation","title":"Agents and Automation","url":"https://addaly.com/learn/agents-and-automation","level":"intermediate","track":"build"},"lesson":{"slug":"the-bill-and-who-reads-it","title":"What it costs, and where the cost hides","url":"https://addaly.com/learn/agents-and-automation/the-bill-and-who-reads-it","position":67,"of":72,"minutes":9,"answer":"Transcript growth dominates the bill, so the same task done in twice as many steps costs about four times as much, which is why shortening the chain beats every other optimisation.","keyIdea":"Transcript growth dominates the bill, so the same task done in twice as many steps costs about four times as much, which is why shortening the chain beats every other optimisation."},"body":{"format":"markdown","text":"## Do the arithmetic once, properly\n\nTake a real service: 12,000 runs a month, each averaging six steps. Because every step resends the growing transcript, a run sends about 18,000 input tokens in total and produces 900 output tokens.\n\nSuppose input costs 50 pence per million tokens and output £2 per million; rates change constantly, so treat these as an illustration and substitute your provider's current numbers.\n\n- Input: 12,000 × 18,000 = 216 million tokens → about £108\n- Output: 12,000 × 900 = 10.8 million tokens → about £22\n\nSo roughly £130 a month, and against even a few hours of human time that is trivially worth it. Now double the steps. The transcript at each turn grows too, so total input roughly quadruples: about £400 for input (3.7 times). **Twice the steps is around four times the cost**, and that single relationship explains most surprising bills.\n\nIt is also why the advice throughout this course is to shorten the chain rather than reach for a cheaper model. Halving the steps beats a 40 per cent cheaper model, and it usually improves reliability at the same time.\n\n> Figure: Where a month's model spend actually went. Bars (£ in one month): Production runs, the number anybody budgeted 130; Evaluation suite, running on every commit 74; Shadow mode, still switched on after the rollout 61; One developer iterating on a 40,000-token fixture 38; Duplicate webhook deliveries 22. The service costs a hundred and thirty pounds a month and the invoice says three hundred and twenty-five. One API key per automation per environment produces this breakdown at no cost, and it cannot be reconstructed six months later.\n\n## The three drivers, in order\n\n**Transcript growth.** Long runs, big tool results, whole documents pasted into context. Fixing one chatty tool that returns a thousand lines on every call is frequently the largest single saving available.\n\n**Retries.** A failure that retries three times costs four runs. A retry storm during a provider incident can cost more in an afternoon than the service does in a month, which is why the budget cap belongs in code and not in a spreadsheet.\n\n**Runs that should not have happened.** Duplicate webhook deliveries, a scheduler firing twice, a development loop left running over a weekend, a test suite pointed at production credentials. Every team has one of these stories, and the cause is always an absent cap rather than an absent intention.\n\n## Where cost hides\n\nYour evaluation suite, if it runs on every commit. Shadow mode, which is pure cost by design. The development environment, where somebody is iterating on a prompt against a 40,000-token fixture. Embedding backfills after a model change. And the long tail of documents ten times larger than the median, which contribute far more than their share of the volume.\n\nMeasure them separately, because a bill you cannot decompose is a bill you cannot act on.\n\n## Make the bill readable\n\n**One API key per automation, per environment.** Providers report spend per key, so this single decision converts an opaque monthly total into a line-item breakdown at no cost. Do it before you need it; retrofitting keys after six months means six months of unattributable history.\n\nThen record the cost per run in your own trace store, and put cost per *outcome* on the dashboard: not \"£130 a month\" but \"9 pence per resolved ticket, against roughly £6 for a human touch\". The second version is the one that survives a budget review, and it is the one that tells you honestly when an automation is not worth it.\n\n## Enforce a budget in code\n\nA soft alarm at 60 per cent of the monthly allowance and a hard stop at 100, checked in the runner. Per-tenant caps if one customer can drive your volume. And a per-minute spend ceiling as well as a per-month one, because a parallel job can produce a month's budget in an hour and a monthly cap will notice far too late.\n\nThis is the same principle as budgets and stopping rules: anything you need guaranteed goes in the harness. A cost policy that exists only in a document is a cost policy that will be discovered to have failed on an invoice.\n\n## The three levers, in order\n\n1. **Shorten the chain.** Fewer steps, smaller observations, handles instead of blobs. Biggest return, and it improves reliability too.\n2. **Cache.** Keep the prompt prefix stable so provider caching applies, and cache your own deterministic tool results.\n3. **Right-size the model.** Use a small model for classification and routing sub-steps, keep the large one for the step that needs it. Measure rather than assume; on narrow tasks the gap is often smaller than the price difference.\n\nAnd a closing honesty: pre-build cost estimates are routinely two to three times low, because nobody models retries, the long tail of large inputs, or the evaluation runs. Estimate, then double it, then measure the first month against the estimate: that comparison is how you get good at the next one."},"check":{"question":"A team doubles the number of steps in an agent run (same model, same prices) and their bill roughly quadruples. Why?","options":[{"text":"Output tokens grow with the number of steps, and output is priced several times higher than input.","correct":false,"tempting":"Output is more expensive per token, but it is a small fraction of the volume here; the growth is on the input side."},{"text":"The whole transcript is re-sent on every step, so twice as many steps means each is also roughly twice as large.","correct":true},{"text":"Longer runs exceed the provider’s cache window, so caching stops applying partway through.","correct":false,"tempting":"Cache expiry can add cost, but it would produce a step change at a threshold rather than a smooth quadrupling."},{"text":"More steps mean more retries, and retries are the dominant cost in long runs.","correct":false,"tempting":"Retries do multiply cost, but they scale with the failure rate rather than automatically with step count."}]},"prev":{"slug":"proving-the-value","title":"Did it actually help, and how would you know","url":"https://addaly.com/learn/agents-and-automation/proving-the-value"},"next":{"slug":"when-people-route-around-it","title":"When people quietly work around it","url":"https://addaly.com/learn/agents-and-automation/when-people-route-around-it"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'What it costs, and where the cost hides', in Agents and Automation. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/agents-and-automation/the-bill-and-who-reads-it (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"What it costs, and where the cost hides","courseTitle":"Agents and Automation","module":{"index":8,"slug":"living-with-it","title":"The year after it ships"},"answer":null,"keyIdea":"Transcript growth dominates the bill, so the same task done in twice as many steps costs about four times as much, which is why shortening the chain beats every other optimisation.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"bars","unit":"£ in one month","title":"Where a month’s model spend actually went","series":[{"label":"Production runs, the number anybody budgeted","value":130,"highlight":true},{"label":"Evaluation suite, running on every commit","value":74},{"label":"Shadow mode, still switched on after the rollout","value":61},{"label":"One developer iterating on a 40,000-token fixture","value":38},{"label":"Duplicate webhook deliveries","value":22}],"caption":"The service costs a hundred and thirty pounds a month and the invoice says three hundred and twenty-five. One API key per automation per environment produces this breakdown at no cost, and it cannot be reconstructed six months later."},"alt":"Figure: Where a month’s model spend actually went. Bars (£ in one month): Production runs, the number anybody budgeted 130; Evaluation suite, running on every commit 74; Shadow mode, still switched on after the rollout 61; One developer iterating on a 40,000-token fixture 38; Duplicate webhook deliveries 22. The service costs a hundred and thirty pounds a month and the invoice says three hundred and twenty-five. One API key per automation per environment produces this breakdown at no cost, and it cannot be reconstructed six months later."}},"blocks":[{"t":"h2","id":"do-the-arithmetic-once-properly","runs":[{"text":"Do the arithmetic once, properly"}]},{"t":"p","runs":[{"text":"Take a real service: 12,000 runs a month, each averaging six steps. Because every step resends the growing transcript, a run sends about 18,000 input tokens in total and produces 900 output tokens."}]},{"t":"p","runs":[{"text":"Suppose input costs 50 pence per million tokens and output £2 per million; rates change constantly, so treat these as an illustration and substitute your provider’s current numbers."}]},{"t":"ul","items":[[{"text":"Input: 12,000 × 18,000 = 216 million tokens → about £108"}],[{"text":"Output: 12,000 × 900 = 10.8 million tokens → about £22"}]]},{"t":"p","runs":[{"text":"So roughly £130 a month, and against even a few hours of human time that is trivially worth it. Now double the steps. The transcript at each turn grows too, so total input roughly quadruples: about £400 for input (3.7 times). "},{"text":"Twice the steps is around four times the cost","b":true},{"text":", and that single relationship explains most surprising bills."}]},{"t":"p","runs":[{"text":"It is also why the advice throughout this course is to shorten the chain rather than reach for a cheaper model. Halving the steps beats a 40 per cent cheaper model, and it usually improves reliability at the same time."}]},{"t":"h2","id":"the-three-drivers-in-order","runs":[{"text":"The three drivers, in order"}]},{"t":"p","runs":[{"text":"Transcript growth.","b":true},{"text":" Long runs, big tool results, whole documents pasted into context. Fixing one chatty tool that returns a thousand lines on every call is frequently the largest single saving available."}]},{"t":"p","runs":[{"text":"Retries.","b":true},{"text":" A failure that retries three times costs four runs. A retry storm during a provider incident can cost more in an afternoon than the service does in a month, which is why the budget cap belongs in code and not in a spreadsheet."}]},{"t":"p","runs":[{"text":"Runs that should not have happened.","b":true},{"text":" Duplicate webhook deliveries, a scheduler firing twice, a development loop left running over a weekend, a test suite pointed at production credentials. Every team has one of these stories, and the cause is always an absent cap rather than an absent intention."}]},{"t":"h2","id":"where-cost-hides","runs":[{"text":"Where cost hides"}]},{"t":"p","runs":[{"text":"Your evaluation suite, if it runs on every commit. Shadow mode, which is pure cost by design. The development environment, where somebody is iterating on a prompt against a 40,000-token fixture. Embedding backfills after a model change. And the long tail of documents ten times larger than the median, which contribute far more than their share of the volume."}]},{"t":"p","runs":[{"text":"Measure them separately, because a bill you cannot decompose is a bill you cannot act on."}]},{"t":"h2","id":"make-the-bill-readable","runs":[{"text":"Make the bill readable"}]},{"t":"p","runs":[{"text":"One API key per automation, per environment.","b":true},{"text":" Providers report spend per key, so this single decision converts an opaque monthly total into a line-item breakdown at no cost. Do it before you need it; retrofitting keys after six months means six months of unattributable history."}]},{"t":"p","runs":[{"text":"Then record the cost per run in your own trace store, and put cost per "},{"text":"outcome","i":true},{"text":" on the dashboard: not “£130 a month” but “9 pence per resolved ticket, against roughly £6 for a human touch”. The second version is the one that survives a budget review, and it is the one that tells you honestly when an automation is not worth it."}]},{"t":"h2","id":"enforce-a-budget-in-code","runs":[{"text":"Enforce a budget in code"}]},{"t":"p","runs":[{"text":"A soft alarm at 60 per cent of the monthly allowance and a hard stop at 100, checked in the runner. Per-tenant caps if one customer can drive your volume. And a per-minute spend ceiling as well as a per-month one, because a parallel job can produce a month’s budget in an hour and a monthly cap will notice far too late."}]},{"t":"p","runs":[{"text":"This is the same principle as budgets and stopping rules: anything you need guaranteed goes in the harness. A cost policy that exists only in a document is a cost policy that will be discovered to have failed on an invoice."}]},{"t":"h2","id":"the-three-levers-in-order","runs":[{"text":"The three levers, in order"}]},{"t":"ol","start":1,"items":[[{"text":"Shorten the chain.","b":true},{"text":" Fewer steps, smaller observations, handles instead of blobs. Biggest return, and it improves reliability too."}],[{"text":"Cache.","b":true},{"text":" Keep the prompt prefix stable so provider caching applies, and cache your own deterministic tool results."}],[{"text":"Right-size the model.","b":true},{"text":" Use a small model for classification and routing sub-steps, keep the large one for the step that needs it. Measure rather than assume; on narrow tasks the gap is often smaller than the price difference."}]]},{"t":"p","runs":[{"text":"And a closing honesty: pre-build cost estimates are routinely two to three times low, because nobody models retries, the long tail of large inputs, or the evaluation runs. Estimate, then double it, then measure the first month against the estimate: that comparison is how you get good at the next one."}]}],"check":{"question":[{"text":"A team doubles the number of steps in an agent run (same model, same prices) and their bill roughly quadruples. Why?"}],"options":[{"text":[{"text":"Output tokens grow with the number of steps, and output is priced several times higher than input."}],"correct":false,"tempting":[{"text":"Output is more expensive per token, but it is a small fraction of the volume here; the growth is on the input side."}]},{"text":[{"text":"The whole transcript is re-sent on every step, so twice as many steps means each is also roughly twice as large."}],"correct":true,"tempting":null},{"text":[{"text":"Longer runs exceed the provider’s cache window, so caching stops applying partway through."}],"correct":false,"tempting":[{"text":"Cache expiry can add cost, but it would produce a step change at a threshold rather than a smooth quadrupling."}]},{"text":[{"text":"More steps mean more retries, and retries are the dominant cost in long runs."}],"correct":false,"tempting":[{"text":"Retries do multiply cost, but they scale with the failure rate rather than automatically with step count."}]}],"order":[2,0,1,3],"why":null},"prev":{"slug":"proving-the-value","title":"Did it actually help, and how would you know","minutes":9},"next":{"slug":"when-people-route-around-it","title":"When people quietly work around it","minutes":9}}}