September 11, 2026
WHY A “CHEAP” MODEL CAN BECOME AN EXPENSIVE SYSTEM

You already know how to pick a model for the job and how to keep its context focused. Now comes the question every real builder eventually faces: what does this actually cost when real people use it every day?
A model that looks cheap on a pricing page can still produce an expensive system. Not because anyone lied to you, but because the price per token was never the whole bill. The number of tokens per request, the number of requests per task, the number of tasks per day, and the number of users all multiply together.
The price tag is small. The multiplication is large.
AI APIs usually charge by the million tokens, split into input and output. A typical listing looks like this: $0.50 per million input tokens, $2.00 per million output tokens. That sounds like almost nothing — until an agent runs hundreds of requests a day.
Think of it like a taxi meter. The per-mile rate matters, but the total fare depends on how far you ride and how many people are riding every day. One short ride is cheap. A fleet of taxis running all day is a business expense.
The operating formula is simple:
Cost per request
× requests per day
× active users
× ~30 days
= monthly model bill
Every lesson in this class comes back to that formula. Learn it once and you can sanity-check any AI feature before you ship it.
What you are actually paying for
A request is rarely just “words in, words out.” Here are the line items that show up on a real bill:
Input tokens. Everything the model reads: your system instructions, the user’s message, attached files, retrieved context, and — in a continuing conversation — the earlier turns. Long chats and big file attachments make input the dominant cost.
Output tokens. Everything the model writes. Output almost always costs more per token than input, often 2–4× more. A model that writes long, rambling answers costs more than a model that writes short, precise ones, even at the same listed price.
Cached input tokens. Many providers discount input that repeats from a recent request — for example, the same system prompt or the same project files. Cached input can cost a fraction of fresh input. This is one reason the clean context habits from Class 09 pay off in money, not just quality: stable, reusable context files cache well.
Reasoning tokens. Reasoning models do extra internal work before answering. That thinking shows up as tokens you pay for, even when you never see the full chain. A hard reasoning task can use far more reasoning tokens than final answer tokens.
Image, audio, and video tokens. Non-text inputs are converted into tokens too. A screenshot, a voice note, or a generated image is typically priced per image, per minute, or per million media tokens — separately from text. Screenshot analysis and voiceovers belong in your estimate when your feature uses them.
Tool-loop tokens. This is the one beginners miss. A coding agent does not make one request and stop. It reads files, runs a command, reads the output, revises, and tries again. Each step is another model call with more accumulated context. Ten loop steps can easily cost ten times what a single chat answer would cost.
| Cost source | What drives it up | Where you have seen it |
|---|---|---|
| Input tokens | Long files, long chats, pasted logs | Class 09 context backpack |
| Output tokens | Verbose answers, large code rewrites | Class 08 model choice |
| Cached input | Stable prompts and context files keep it low | Class 09 handoffs |
| Reasoning tokens | Hard problems, reasoning models thinking longer | Class 08 reasoning models |
| Image / audio | Screenshots, voice, generated media | Class 08 specialized models |
| Tool loops | Agent retries, file reads, terminal output | Class 07 agent loop, Class 10 routing |
Why agents cost more than chats
Compare two ways to get the same result:
A chat answer: one request, a few thousand input tokens, a few hundred output tokens. Pennies or less.
An agent task: the agent reads four files, runs the tests, reads a failure log, edits two files, re-runs the tests, and summarizes. That is six to ten requests, each carrying more context than the last, plus output at every step.
Neither is wrong. The agent does far more useful work. But you cannot budget an agent feature with chat math. If your ByeBuy-style product lets users ask an agent to “research this company” or “fix this page,” each task is a small batch of requests, not one.
A useful habit: estimate cost per task completed, not cost per single API call. Watch one real task, count the requests, then multiply.
See the price before you pay it
This is where OpenRouter earns its place from Class 10. OpenRouter lists input price, output price, and context length beside each model, on one page, in one currency. You can compare a fast inexpensive model against a strong reasoning model in seconds, before routing a single request.
Provider pages change often, so treat any specific dollar figure as a snapshot — check OpenRouter models for live numbers. But the gap is structural: in 2026 a US flagship lists around $3–$5 input / $15–$25 output per million, Meta's Muse Spark 1.3 lists ~$1.25 / $4.25 (or ~$0.10 / $0.20 on its contributor tier), while DeepSeek V4 Flash lists ~$0.14–$0.22 / $0.28–$0.66 and Qwen/GLM efficient routes sit in the same low band. Same task shape, 10–25x difference in sticker price — which is exactly why Class 11 insists on testing Chinese-family and Meta models for routine work instead of defaulting to ChatGPT or Claude for everything. The durable skill is reading the price table itself: find input price, output price, cached price if offered, and context length, then ask "how many requests like mine, how often?"
The cost waterfall: one request to a monthly bill
Here is how a small number becomes a real bill. Read it top to bottom — each row multiplies the one above.
| Stage | Example | Math |
|---|---|---|
| One agent step | 4,000 input + 1,000 output tokens at ~$1 / $4 per million | ~$0.008 |
| One finished task (6 steps) | 6 steps with growing context | ~$0.06 |
| One user for one day (10 tasks) | Power user researching and editing | ~$0.60 |
| 100 users for one day | Small private beta | ~$60 |
| 100 users for 30 days | The monthly bill | ~$1,800 |
Change any assumption and the bottom line moves fast. That is the point. A half-cent request is not automatically cheap when it runs 60 times per task, 10 times a day, across 100 people. Run your own numbers before you promise “AI included free.”
Practical exercise: calculate rough monthly spend
Finish line: three short estimates you could defend in a team discussion.
Use the formula at the top of this lesson. Round freely — the goal is order of magnitude, not accounting precision.
1. Support bot. Cost per request $0.004. Average 5 requests per user per day. 200 active users. What is the rough monthly bill? 2. Coding helper. Cost per finished task $0.06. Average 3 tasks per user per day. 20 active users. What is the rough monthly bill? 3. Your project. Pick one feature you actually want. Guess cost per request, requests per task, tasks per day, and users. What is the rough monthly bill — and which assumption matters most?
Verify quickly: double your requests-per-task assumption. Does the feature still make sense? If doubling one guess breaks the budget, that guess is the one to measure first with a real test.
Common failure mode: estimating with one perfect request. Real agents retry. Count the retries, the file reads, and the follow-up question — then estimate.
Check your understanding
1. What six cost sources can appear in a single AI feature? 2. Why do output tokens usually matter more than the same number of input tokens? 3. Why does a coding-agent task cost more than a single chat answer for the same question? 4. What does the formula cost per request × requests per day × users tell you that a pricing page alone does not? 5. Where would you look to compare model prices before routing requests?
ARTICLE DISCUSSION
JOIN THE
CONVERSATION.
Got a question, a take, or a better way to do this? Log in and leave a comment.
