Output tokens usually drive the bill faster than people expect, but the real answer is simpler: your cost is whatever the model charges for input plus output, and the ratio between them decides how painful a long completion gets. If you want to predict spend, stop thinking in prompts and start thinking in token mix.
Why input and output are not the same cost
Most developers think of a request as one blob of text, but pricing splits it into at least two buckets: what you send in, and what the model sends back. Those buckets often have very different prices, and that difference is where surprises come from.
For example, gpt-4o is priced at $2.5 input and $10 output per 1M tokens. That means output is 4x more expensive than input. claude-sonnet-4-5 is $3 input and $15 output per 1M tokens, which is 5x. gemini-2.5-pro is $1.25 input and $10 output per 1M tokens, an 8x gap. When you see a model with a big output premium, long answers are where the budget goes to die.
There’s a second wrinkle: many agent workflows are input-heavy before they become output-heavy. Tool traces, code context, file contents, and repeated system instructions all inflate the input side. So the cheapest-looking request can still get expensive if you keep stuffing context into it.
The math: a worked example with real tokens
Here’s the formula you actually want:
cost = (input_tokens / 1,000,000) * input_price + (output_tokens / 1,000,000) * output_priceLet’s use gpt-4o-mini, priced at $0.15 input and $0.6 output per 1M tokens. Say your app sends 120,000 input tokens and gets back 30,000 output tokens in a day.
Input cost = 120,000 / 1,000,000 * 0.15 = 0.018
Output cost = 30,000 / 1,000,000 * 0.6 = 0.018
Total cost = 0.018 + 0.018 = $0.036That looks tiny, which is exactly why teams underestimate scale. Now multiply the same pattern by 1,000 requests and you’re at $36. If your output doubles to 60,000 tokens per day, the output side becomes $0.036 by itself, and your total jumps to $0.054. Same model, same app, just a different answer length.
Now compare that with claude-opus-4-1, priced at $15 input and $75 output per 1M tokens. With the same 120,000 input and 30,000 output tokens:
Input cost = 120,000 / 1,000,000 * 15 = 1.8
Output cost = 30,000 / 1,000,000 * 75 = 2.25
Total cost = 4.05That’s the same token count, but a completely different bill. The model choice matters, yet the input to output mix still decides how steep the bill climbs.
A small comparison of how pricing shape changes behavior
Here’s the practical difference between a few models from the facts we have:
| Model | Input price per 1M | Output price per 1M | Output vs input |
|---|---|---|---|
| gpt-4o-mini | $0.15 | $0.6 | 4x |
| gpt-4o | $2.5 | $10 | 4x |
| claude-sonnet-4-5 | $3 | $15 | 5x |
| gemini-2.5-pro | $1.25 | $10 | 8x |
That last row is the one to watch. When output is 8x the input price, verbosity is expensive. A model can be efficient on prompts and still punish you if your agent likes to narrate every step, dump chain-of-thought style text, or produce oversized explanations.
If you want to see the broader market shape, the AI Cost Index gives you a blended view of frontier and budget baskets. The current frontier basket is $4.64 per 1M tokens, while the budget basket is $0.74 per 1M tokens, both blended 3:1 input:output. That blended number is useful, but it can hide how much output-heavy workloads diverge from the average.
What actually drives your bill in real apps
There are four common patterns that push cost up, and only one of them is obvious at first glance.
- Long prompts, especially when you resend the same instructions or context on every turn.
- Long answers, which are usually more expensive than the prompt because output rates are higher.
- Agent loops, where the model calls tools, reflects, retries, and emits more text than a single chat response.
- Model switching, where a cheap first pass is followed by a much pricier rerank, rewrite, or finalization step.
The hidden trap is that developers often optimize only the prompt. That helps, but if your app asks for long explanations, verbose diffs, or multi-step reasoning summaries, the output side can dominate anyway. In other words, trimming 20% off the input does not matter much if the model keeps generating 2x more output than you expected.
This is also why comparing models only by input price is misleading. A model with a low input rate but a steep output rate can still be expensive for chatty use cases. For a more complete market snapshot, the live model price list is the place to inspect actual per-model pricing instead of guessing.
How to keep output from quietly eating your budget
You do not need to make your app terse. You need to make it intentional.
- Cap answer length where you can. If a task only needs a patch, don’t ask for a novel.
- Separate analysis from user-facing output. Let the model think internally or in tool calls, but keep the final response compact.
- Use cheaper models for verbose tasks. A high-output workflow on a budget model can be cheaper than a short answer on a premium one.
- Watch repeated context. If the same system prompt or project context is being re-sent every turn, you are paying for it every turn.
- Measure by task, not by request. One request can be cheap and still fail, then trigger a retry that doubles the spend.
The useful metric is not “how many tokens did I send.” It is “how much did I pay to finish the job successfully.” That’s the number that matters when you’re shipping an agent, a coding assistant, or any workflow that can spin through multiple turns.
If you care about the value side of that equation, the value-for-money view is a better lens than raw price alone. A cheap model that takes three tries can cost more than a pricier model that finishes once.
How to track this in your own stack
To see whether input or output is driving your bill, you need per-request token breakdowns, not just a monthly invoice. That is exactly what MyTokenTracker records: cost, input/output/cache/reasoning tokens, latency, and success, broken down by provider, model, platform, and use-case.
The fastest way to try it is npx mytokentracker. It reads the usage logs coding agents already keep locally and prints a 30-day cost table at API prices, with usage data staying on your machine. If you want a dashboard, create a free account and run npx mytokentracker init, which uploads only daily totals per agent and model, never prompts, code, or file names.
It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code, and more. For setup details, use the install docs at /install.
If you are comparing your own numbers against community patterns, the open data and the public AI Cost Index are useful reference points. You can also inspect the broader community discussion in the community data if you want to see how other developers are actually spending.
FAQ
Is input or output usually more expensive?
Output is usually more expensive per token, often by a lot. In the prices we have here, the output rate is 4x to 8x the input rate depending on the model. That means long answers, retries, and verbose agent behavior can cost more than the prompt itself.
Should I optimize prompts or outputs first?
Optimize both, but start with the biggest leak. If your app sends huge context on every turn, trim the prompt. If your model keeps generating long explanations or repeated summaries, cap or restructure the output. The right fix depends on which side of the formula is larger.
Why do blended prices hide the real problem?
Blended prices are useful for quick comparisons, but they average away the shape of your workload. A 3:1 input:output blend can look fine on paper while a chatty agent with long completions burns much more than the blend suggests. That is why per-request token breakdowns matter.
If you want to see your own input and output split instead of guessing, run npx mytokentracker and check the 30-day table.