A single AI API request can cost less than a cent and still turn into a four-figure monthly bill.
That sounds contradictory until you stop looking at the price of one request and start looking at the workload behind it.
AI providers usually make pricing look simple:
input tokens cost X per million
output tokens cost Y per million
Those numbers are useful.
But they are not your actual product cost.
To estimate that, you also need to know how many tokens each request uses, how much the model generates, how often the request runs, whether one user action triggers multiple model calls, and how that usage scales over a month.
That is where the interesting math starts.
The price per million tokens is only one variable
A basic AI API cost calculation looks like this:
Input cost =
monthly input tokens / 1,000,000
x input price per million tokens
Output cost =
monthly output tokens / 1,000,000
x output price per million tokens
Monthly API cost =
input cost + output cost
The formula is simple.
Estimating the numbers that go into it is not.
Imagine an AI feature that uses:
1,500 input tokens per request
300 output tokens per request
10,000 requests per day
30 active days per month
That becomes:
450 million input tokens per month
90 million output tokens per month
Now assume, purely as an example, that the model costs:
$1.50 per million input tokens
$6.00 per million output tokens
The monthly calculation becomes:
Input:
450 x $1.50 = $675
Output:
90 x $6.00 = $540
Total:
$1,215 per month
The individual request still looks extremely cheap.
It costs about:
$0.00405
Less than half a cent.
But 300,000 of those requests are no longer a rounding error.
This is why "cost per request" and "cost to operate the product" are two very different questions.
Output tokens deserve more attention than they usually get
One common mistake is treating all tokens as if they cost the same.
They often do not.
Input and output pricing can be different, sometimes significantly so.
That means two applications with the same total token usage can have different economics.
A classification task might send a large amount of context to the model but return only a few tokens.
A writing assistant might generate hundreds or thousands of tokens every time it runs.
A coding agent may repeatedly read context and produce substantial outputs across several model calls.
So asking:
"How many tokens does this feature use?"
is not enough.
A better question is:
"How many input tokens and output tokens does a typical completed task use?"
That distinction becomes increasingly important as usage grows.
Long prompts quietly multiply the bill
Large prompts do not necessarily feel expensive during development.
You add:
system instructions
previous conversation history
retrieved documents
tool descriptions
examples
user context
application metadata
Each addition may seem small.
But if the same context is sent thousands of times per day, every extra token participates in the multiplication.
Return to the earlier example.
Instead of 1,500 input tokens, imagine the average request grows to 5,000.
The output remains 300 tokens.
At the same illustrative prices and request volume:
Monthly input tokens:
5,000 x 10,000 x 30
= 1.5 billion tokens
Input cost:
1,500 x $1.50
= $2,250
Output cost:
90 x $6.00
= $540
Total:
$2,790 per month
The product did not gain more users.
The model did not become more expensive.
Only the average prompt became larger.
Monthly API cost increased from $1,215 to $2,790.
That is why context management is not only a latency or model-quality problem.
It is also an economic problem.
User actions and API requests are not always the same thing
This becomes even more important with AI agents and multi-step workflows.
A user might click one button.
Behind that button, your application might:
classify the request
retrieve information
call a reasoning model
call another model with retrieved context
evaluate the result
retry a failed step
From the user's perspective, one thing happened.
From the billing system's perspective, several model calls happened.
If one user action generates six model requests, estimating cost from user actions alone can underestimate usage dramatically.
For agentic systems, the useful unit is often not:
cost per message
but:
cost per completed workflow
That forces you to count everything that actually happens behind the interface.
Request volume is where tiny costs become real costs
Suppose a request costs only $0.002.
At different volumes:
1,000 requests = $2
10,000 requests = $20
100,000 requests = $200
1,000,000 requests = $2,000
There is nothing inherently bad about that.
A $2,000 API bill could be extremely profitable if those requests support enough revenue.
The point is not that AI APIs are expensive.
The point is that unit price without volume tells you almost nothing about the economics of the product.
You need both.
Caching can change the equation
Some AI APIs offer lower pricing for eligible cached input.
That can matter when your application repeatedly sends the same large blocks of context, such as:
stable system prompts
repeated instructions
shared reference material
long reusable prefixes
But caching should be modeled rather than assumed.
Not every token will necessarily qualify.
Not every request will produce a cache hit.
And application behavior can change how much reusable context you actually have.
A useful cost estimate therefore separates normal input from discounted cached input instead of assuming that the entire prompt receives the cheapest possible rate.
Estimate scenarios, not one perfect number
Before shipping an AI feature, I would avoid trying to predict one exact monthly bill.
Instead, model at least three scenarios.
Low usage
What happens if adoption is slower than expected?
This gives you the initial operating floor.
Expected usage
Use the workload you realistically think the product will reach.
This becomes your planning case.
High usage
What happens if usage is much stronger than expected?
This is where expensive architectural assumptions become visible.
You can do the same with token usage:
Short prompt
Typical prompt
Heavy prompt
and output length:
Short response
Typical response
Long response
A range is often more useful than false precision.
The variables worth knowing before you ship
For a basic estimate, you should know or approximate:
Average input tokens per request
Average output tokens per request
Requests per day
Active days per month
Current input price per million tokens
Current output price per million tokens
Cached input share, if relevant
For more complex applications, also consider:
Model calls per completed task
Retry frequency
Different models inside the same workflow
Traffic growth
Background or scheduled AI jobs
You do not need perfect production data before launch.
You need assumptions that are explicit enough to test.
That is much better than looking at "$X per million tokens" and hoping the monthly bill stays small.
Calculate your own workload
I built an AI API Cost Calculator on UsefulAtlas for exactly this type of estimation.
Instead of baking model prices into the tool, you can enter the current input and output prices from the provider you are considering and combine them with your own workload assumptions.
That makes it useful for chatbots, AI features, agents, batch jobs and other API-based workflows.
Run your own numbers here:
https://usefulatlas.com/calculators/ai-api-cost-calculator/
Free to use. No account needed.
The important question is not whether an AI request costs a fraction of a cent.
It is what happens when your real application starts making thousands, hundreds of thousands, or millions of them.
Top comments (0)