AI costs,
explained.
Get more useful work
from your AI spend.
If you use AI to get work done, this show helps you decide what deserves your money. Models, tools and the way you use them: what they cost, what they can do, and whether the results are worth paying for.
Presented by AI voices Alex & Jordan. Alex follows the evidence; Jordan asks what it means for the person doing the work and paying the bill.
The model got cheaper.
Why didn’t the bill?
Follow one bill from a price cut to a better question.
Choose a chapter, then press play. Audio never starts automatically.
A lower price.
A higher invoice.
What changed?
A cheaper model can still produce a bigger bill. Before switching back or cutting usage, find out what moved — and whether the extra spend bought useful work.
We follow a fictional document-summary workflow from a $140 bill to an expected $70, then an actual $160. More documents and longer answers explain the charges. They don’t tell us whether those answers were useful.
A teaching case, clearly labelled. The workload, prices and outcomes are fictional. These are not current provider quotes or customer results. Alex and Jordan are AI presenters.
Where the expected saving went.
10,000 documents
600 output tokens each
Both token prices halved
Usage held constant
16,000 documents
1,200 output tokens each
$70 + $42 + $48 = $160. Price first, volume second, output length third.
Input stays at 4,000 tokens per document. Fictional input / output prices per million tokens: $2 / $10 before; $1 / $5 after. One attempt per job; no cache, retries, tool or hosting fees in this example. Model charges only. Usefulness remains unknown.
Start with one piece of work you care about.
You don’t need to audit everything. Pick one recurring job and write down what a useful result looks like.
Open cost planning worksheetsFree bill worksheet and decision log. No account required.
- 01
Define “useful” first.
Choose a quality standard before comparing costs. Compare consistent periods or the same representative inputs.
- 02
Count the job once. Keep every charge.
Include billed attempts, discarded answers and retries. A request count is not automatically a completed-job count.
- 03
Keep unknowns visible.
Divide model spend by original jobs that met your standard. If that count is missing, leave it unknown. Zero useful completions gives no finite cost per useful result. Track human review separately.
The full conversation.
AI-presented by Alex and Jordan. All case details and prices are fictional teaching assumptions.
Opening
AlexYou switch to an AI model at half the price. A month later, the bill is higher. Do you switch back?
JordanBefore I do that, tell me what I got for the extra money.
AlexWelcome to The AI Bill: Itemised. I'm Alex.
JordanAnd I'm Jordan.
AlexIf you use AI to get work done, this show helps you decide what deserves your money. We look at models, tools and the way you use them: what they cost, what they can do, and whether the results are worth paying for.
JordanToday, we're looking at a bill that went up after a price cut. We'll work out what changed, then decide what to check before cutting usage or changing models again. Because a bigger bill could mean more useful work. It could also mean you're paying for work nobody needs.
The bill on the table
AlexWe've built a fictional example so we can follow the whole bill. The numbers are invented and the calculation is in the episode notes. This isn't a customer result.
JordanWhat's the job?
AlexSummarising documents for a team. Someone sends in a document and gets back a summary. They're supposed to be able to use that summary in their work. Last month the invoice was one hundred and forty dollars. The team switches to a model whose input and output prices are both half as much. Same amount of work, same length of answer, and you'd expect seventy dollars.
JordanThen the invoice arrives.
AlexOne hundred and sixty.
JordanTwenty dollars more than before. That's annoying, but I wouldn't change a working product over that alone.
AlexNeither would I. The useful question is why the expected saving disappeared. If the team doesn't understand the change, they can't sensibly budget for the next one.
JordanSo let's see whether the work stayed the same.
What changed
AlexIt didn't. The team processed ten thousand documents before the switch. Afterward, sixteen thousand.
JordanThat could be good. More people found a use for it.
AlexIt could. And it explains part of the bill. But the new summaries also got longer. Twice as long, on average. The documents going in stayed the same size.
JordanDid somebody ask for longer summaries?
AlexWe haven't established that. We know the length changed. We don't yet know whether people wanted it.
JordanOkay. More documents, and more writing for each document. That explains how a cheaper model could produce a bigger bill. But was each summary actually cheaper?
AlexYes, in this example. Generating a thousand summaries used to cost fourteen dollars. With the new prices and longer answers, it costs ten.
JordanSo the unit cost came down. The total went up because the team did more work.
AlexAnd the longer answers used up part of the saving. If you follow the calculation in the notes, the extra documents and extra output explain the whole gap between the expected bill and the actual one. We haven't hidden a retry charge or a fee in there.
JordanThen switching back could cost more for the volume we now have.
AlexIt could. Looking only at the invoice total might push you toward the wrong decision.
Cheaper at what?
JordanThere's still something I don't like about our comparison. You said a thousand summaries cost less. Are they a thousand useful summaries?
AlexWe don't know yet.
JordanBecause I can imagine both versions of this. Maybe the longer answer includes something people were missing. Or maybe people now have to dig through twice as much text to find the point.
AlexAnd those lead to different decisions. For this team, a useful summary needs to capture the main point and the important caveat, without inventing anything. That's the standard we'd use to judge the result.
JordanThen I'd want someone to look at the summaries against that standard. I wouldn't call the extra output waste just because it's longer.
AlexNor would I call it valuable just because people generated it. The provider can charge us for an answer whether anyone uses it or not.
JordanCan the bill tell us which answers were useful?
AlexUsually not by itself. We need some evidence from the work: a review result, a completed task, or feedback from the person using the summary. If all we have is the invoice, usefulness stays unknown.
JordanSo we've answered why the money moved. We haven't answered whether it was well spent.
AlexRight. Those are separate questions. And we haven't priced human review time either. The dollar figures we've discussed are model charges, not the whole cost of running the product.
The next decision
JordanMy first instinct was to leave it alone because the increase was small. Now I'd keep the model for the moment, but check what the longer answer is doing for us.
AlexHow would you check?
JordanI'd take a small set of documents that resemble the work people actually send in. Include a few difficult ones. Run those through the current setup, then through a version that asks for a shorter summary. Keep the model and the documents the same.
AlexAnd decide what counts as a good summary before looking at which version costs less.
JordanYes. Does it capture the point? Does it keep the important caveat? Can someone use it without fixing it? If it drops an important detail, I wouldn't ship it.
AlexCount every billed attempt, too. If someone regenerates an answer, include that cost even if they discard it. Some retries succeed; some don't. Either way, they're part of what it took to finish the job.
JordanI'd also note whether the reviewer has to spend longer fixing one version. I might save on the model and create more work for a person.
AlexThat gives us a useful first test. A small sample can reveal problems; it won't tell us exactly how every production task will behave. If the shorter setup looks promising, try it on a limited share of real work and check again.
JordanAnd if the longer version is clearly more useful, keep it and budget for it. The point of the check is to make that a decision we can explain.
Try it on one piece of work
AlexYou can start this on your own stack without investigating everything at once. Pick one recurring job: answering a support question, writing a document summary, extracting information from a form. Something where you can describe a useful result.
JordanThen pick comparable periods. Don't compare a quiet week with a launch week and assume the model caused the difference. If the work changed, write that down.
AlexLook for what you spent, how many original jobs you tried to complete, and how many results met your standard. Count the original job once, even if getting it done took several model calls. Keep all of those calls in the cost.
JordanAnd if the usage dashboard only gives me requests, not completed jobs?
AlexMark the task count as missing. Ask whoever owns the workflow whether they can connect requests to jobs. You can still investigate the spend; you just can't honestly calculate cost per useful job yet.
JordanThat's a better first finding than dividing by the wrong thing.
AlexOnce you can count useful results, divide the model spend, including discarded calls, by the original jobs that produced a useful result. If none did, report that directly. Write down what you know, what's missing and the next check. You can start there even before you have enough data for a calculation.
Close
JordanBack to the opening: the model got cheaper, but the bill went up. Do we switch back?
AlexNot on that evidence alone. In our example, each summary became cheaper to generate. The team processed more documents, and longer answers consumed some of the saving. The next check is whether those answers are worth the extra output.
JordanThat's the question I'd take into a budget meeting: what useful work did we get for this spend, and what would we change next?
AlexThat's what we'll keep investigating on The AI Bill. When a model, a tool or the way you use it changes, we want you to be able to judge the tradeoff. For this episode, pick one workflow and write down what a useful result looks like. Then check whether your cost data can tell you what it takes to produce one.
JordanStart with one piece of work you actually care about. Thanks for listening.