LLM API pricing pages usually quote prices per million tokens.
That is useful for billing, but it is not always the easiest way to think about cost when building an application.
A question I find more intuitive is:
If I have a $10 API budget, how many real requests can I make?
The answer depends heavily on the ratio between input and output tokens.
Let's use one simple workload and compare a few models.
Assume each API request contains:
4,000 input tokens
1,000 output tokens
That gives us a 5,000-token request with an 80/20 input-output split.
For this comparison, I am using the pricing currently recorded in my dataset:
| Model | Input / 1M tokens | Output / 1M tokens |
|---|---|---|
| GPT-6 Luna | $0.10 | $0.50 |
| Gemini 3.8 Flash | $0.75 | $3.75 |
| Claude Sonnet 5.5 | $2.00 | $10.00 |
These are standard token rates and do not include special long-context tiers or other processing modes.
Now let's turn those prices into something more concrete.
For one request:
Input:
4,000 / 1,000,000 × $0.10
= $0.0004
Output:
1,000 / 1,000,000 × $0.50
= $0.0005
Total:
$0.0009 per request
With a $10 budget:
$10 / $0.0009
≈ 11,111 requests
That is roughly:
44.4 million input tokens
and
11.1 million output tokens
for the $10 budget.
Now run exactly the same workload through Gemini 3.8 Flash.
Input:
4,000 / 1,000,000 × $0.75
= $0.003
Output:
1,000 / 1,000,000 × $3.75
= $0.00375
Total:
$0.00675 per request
With $10:
$10 / $0.00675
≈ 1,481 requests
Same workload.
Same $10.
Very different request capacity.
For Claude Sonnet 5.5:
Input:
4,000 / 1,000,000 × $2
= $0.008
Output:
1,000 / 1,000,000 × $10
= $0.01
Total:
$0.018 per request
A $10 budget gives approximately:
$10 / $0.018
≈ 556 requests
So for this particular workload:
| Model | Approx. requests for $10 |
|---|---|
| GPT-6 Luna | 11,111 |
| Gemini 3.8 Flash | 1,481 |
| Claude Sonnet 5.5 | 556 |
That difference is large enough to matter when an application moves from experimentation to production traffic.
But this table does not mean GPT-6 Luna is automatically the best choice.
Imagine Model A needs one request to solve a coding task.
Model B is cheaper per token but needs:
Model B may still produce a higher total cost per completed task.
This is why I think there are two separate questions developers should ask.
That is mostly arithmetic.
That is an evaluation problem.
Token price answers the first question.
It does not answer the second.
There is another interesting detail in the example.
The request contains four times as many input tokens as output tokens:
4,000 input
1,000 output
Yet for all three models in this example, the output portion costs more per token.
For Claude Sonnet 5.5, the single request costs:
Input: $0.008
Output: $0.010
So only 20% of the tokens account for more than half of the cost.
This makes output control surprisingly important.
If an agent produces verbose intermediate reasoning, oversized summaries, unnecessary code explanations, or repeated generated content, reducing output may save more money than aggressively shortening the prompt.
A $10 experiment may not sound important.
Now imagine the application processes 100,000 of these requests.
Using the same 4,000-input / 1,000-output workload:
GPT-6 Luna:
100,000 × $0.0009
≈ $90
Gemini 3.8 Flash:
100,000 × $0.00675
≈ $675
Claude Sonnet 5.5:
100,000 × $0.018
≈ $1,800
At that point model choice is no longer a minor implementation detail.
It becomes part of the product economics.
The examples above assume all input is charged at the standard input rate.
Real applications can be different.
Many agent workloads repeatedly send information such as:
When an API supports discounted cached input, part of that input may become significantly cheaper.
So a more complete calculation looks like:
Total cost =
normal input tokens × input price
+ cached input tokens × cached price
+ output tokens × output price
For applications with large reusable prompts, caching can materially change the economics.
Another thing I try not to assume is:
This model supports a one-million-token context window, therefore one million tokens always cost the normal input rate.
Providers can have special pricing rules for large contexts, different processing tiers, batch workloads, caching, or other modes.
A model's context window tells you what is technically possible.
It does not necessarily tell you what that workload will cost.
That is why pricing comparisons should preserve the provider source and the date when the pricing was verified.
I was repeatedly doing calculations like these manually, so I built a simple LLM API Cost Calculator.
Instead of asking only for a model price, it lets you enter a workload:
input tokens / request
cached input tokens / request
output tokens / request
number of requests
There is also a budget-oriented way to think about the problem: start with a fixed amount of money and estimate the workload capacity.
I deliberately keep the pricing source and verification date next to the results because a perfectly accurate calculation based on outdated pricing is still a wrong answer.
The underlying rates are also available separately in the LLM API Pricing reference.
After looking at enough pricing tables, I have become less interested in:
Which model has the cheapest token?
The metric I would rather know is:
How much does it cost to successfully complete one useful task?
For some applications, a very inexpensive model will win.
For others, paying more for a model that completes the task reliably in fewer steps may be cheaper overall.
A useful evaluation therefore needs both:
cost per request
×
requests per successful task
That gets much closer to the economics of a real AI application than a simple price-per-million-token leaderboard.
Pricing changes frequently. The figures above reflect the pricing data I was using in October 2026. Always verify current provider pricing and pricing conditions before making production cost decisions.