# The model got cheaper. Why didn't the bill? Companion notes for The AI Bill: Itemised, Episode 1. Produced 3 November 2026. Presented by AI voices Alex and Jordan. All workload data and prices below are hypothetical teaching inputs; no customer or provider result is claimed. ## The show The AI Bill helps people who use AI decide which models, tools and ways of working deliver useful results for their money. ## This episode A price cut does not tell you what the next bill will be. Follow a fictional document-summary workflow to separate price, volume and output length. Then decide what evidence you need before changing a model or restricting usage. The larger bill in this example does not establish waste. Generation per summary is cheaper, while the usefulness of the new summaries remains unmeasured. ## The example, precisely Each original job is one document summary. For the headline comparison, each job has one billed attempt, with no cache, reasoning, tool, hosting or other fees. Input length is unchanged. All input is fresh, and output is a separate charged category. No real model is being compared. | Input | Before | After | |---|---:|---:| | Original jobs | 10,000 | 16,000 | | Billed attempts per job | 1 | 1 | | Input tokens per attempt | 4,000 | 4,000 | | Output tokens per attempt | 600 | 1,200 | | Hypothetical input price / million tokens | $2 | $1 | | Hypothetical output price / million tokens | $10 | $5 | | Model token cost per 1,000 summaries generated | $14 | $10 | | Model token cost in period | $140 | $160 | Calculation per attempt: `(input tokens × input price + output tokens × output price) / 1,000,000` Before: `(4,000 × $2 + 600 × $10) / 1,000,000 = $0.014`. After: `(4,000 × $1 + 1,200 × $5) / 1,000,000 = $0.010`. Period costs: `10,000 × $0.014 = $140`; `16,000 × $0.010 = $160`. ### Where the expected saving went This bridge applies price first, volume second and output length third. Keeping the order explicit allocates their interaction once, without double counting. Other bridge orders can allocate the interaction differently while reconciling to the same bill. | Step | Cost | Change | |---|---:|---:| | Before | $140 | — | | New prices, old usage | $70 | −$70 | | New prices and 16,000 jobs, old output length | $112 | +$42 | | New prices, new job count and longer output | $160 | +$48 | The $90 gap between $70 expected and $160 actual is $42 + $48. The actual bill is $20 above the original bill. The script does not claim the model caused adoption to rise, or that longer output was wanted. Both require evidence outside this invented calculation. ### What we cannot conclude We have not established the new acceptance rate, value to users, reviewer effort, latency, reliability or total operating cost. Therefore the script does not report a measured cost per useful result or recommend reverting the model. The existing calculator's separate fictional worked example may contain illustrative acceptance inputs. Those inputs are teaching assumptions, not additional evidence about this episode's case. For your own analysis, leave them unknown until you have a consistent definition and observations. ## One action to take Pick one recurring AI workflow and write a sentence defining a useful result. Then compare consistent periods or the same representative inputs. Record: 1. Spend attributable to that workflow, including every billed attempt and known relevant fees. 2. Original jobs attempted, counted once each; model requests are not automatically jobs. 3. Jobs that meet the same quality standard after any retries. Each successful job counts once. 4. Missing fields, changes in the mix of work and separate operational observations such as review effort. If useful-job counts are missing, keep the result unknown. A provider export may explain the charges without explaining the work accomplished. Zero useful completions does not produce a finite cost per useful completion. For a first test, use a small set of representative documents, including difficult ones. Compare current output with an explicitly shorter output using the same model and inputs. Define quality before comparing cost. Count all calls, failures and regeneration costs. A promising small sample should lead to a limited monitored trial, not an assumed production saving. ## Use this on your own workflow Open the [listener tools](/listener-tools) for the editable calculator, bill worksheet and decision log. Start with the worksheet when information is missing. The calculator has a separate fictional worked example; its acceptance inputs are not evidence about this episode. [Listen to the episode and read the transcript](/podcast), or [download the MP3](/podcast/episode-01.mp3). The episode should remain understandable without opening the calculator. ## Source and assumption ledger | Item | Basis | Status | |---|---|---| | The 140 / 70 / 160 example | Owner-supplied `02-pilot-script.md`, reconciled with the companion calculator | Hypothetical; arithmetic recalculated | | Token lengths and rates | Owner-supplied teaching inputs | Fictional; not vendor quotes | | Show promise | Owner's mission direction and latest request to distinguish podcast value from episode value | Editorial positioning | | Original quality findings | Full review of both supplied scripts and an independent editorial pass | Original text review; generated audio separately checked by transcription and technical analysis. No audience test | | Caching correction to original v2 | [Claude prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), [OpenAI prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching), checked 3 November 2026 | Current primary sources; no detailed caching claim in v3 | | Runtime | 8 minutes 42 seconds including music; 1,366 script words | Measured final audio | No interview, founder anecdote, real-world acceptance rate, measured saving or model-quality benchmark is fabricated for the revised episode.