How do you estimate LLM cost before you build?
We estimate LLM cost before we build by estimating the tokens per request, multiplying by the price per token, then multiplying by our expected volume.
In this blog, we will learn about how to estimate LLM cost before you build. We will see how to forecast your token spend with simple math, so you know the bill before writing any code.
We will cover the following:
Why estimate cost before building
What drives the cost?
Step 1: Estimate tokens per request
Step 2: Multiply by the price per token
Step 3: Multiply by your volume
Do not forget the hidden extras
A full worked example
How to lower the estimate
I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.
I teach AI and Machine Learning at Outcome School.
Let’s get started.
Why estimate cost before building
Many teams build an app first and only check the cost later, when the bill arrives. Sometimes it is a surprise, and the app is not affordable to run.
Estimating cost before building avoids this. With simple math, we can forecast the bill and decide, upfront, whether the app makes sense and which model to use.
Build first, check cost later -> nasty surprise
Estimate cost first -> plan and choose wisely, no surpriseLet’s see what drives the cost, then do the math.
What drives the cost?
LLM cost is based on tokens, the small pieces of text the model reads and writes. We pay for two kinds:
Input tokens: everything we send (the prompt, instructions, and any context).
Output tokens: everything the model writes back.
Cost is driven by tokens:
input tokens (what we send) + output tokens (what it writes)The more tokens flow in and out, the higher the cost. So to estimate the bill, we estimate the tokens. Let’s do it in three steps. First, per request.
Step 1: Estimate tokens per request
The first step is to estimate how many tokens one typical request uses, both input and output.
For one request, estimate:
input tokens: prompt + instructions + any context (say, 500)
output tokens: the model's answer (say, 300)
total per request: 800 tokensWe guess the size of a typical request: how much we send, and how much the model writes back. A rough guide is that 1 token is about 4 characters of English, or about 0.75 words. So a 300-word answer is roughly 400 tokens. We estimate both parts for one request. This is Step 1. Now, let’s bring in the price.
Step 2: Multiply by the price per token
The second step is to multiply the tokens by the model’s price. Providers charge a price per million tokens, and output usually costs more than input.
Example prices (made up, for understanding):
input: $0.50 per 1,000,000 tokens
output: $1.50 per 1,000,000 tokens
Cost of one request (500 input + 300 output):
input: 500 / 1,000,000 x $0.50 = $0.00025
output: 300 / 1,000,000 x $1.50 = $0.00045
total per request: $0.0007We apply the model’s price to our token estimate. Notice output is priced higher, so a chatty model that writes long answers costs more. This gives us the cost of a single request. This is Step 2. Now, let’s scale it up.
Step 3: Multiply by your volume
The third step is to multiply the per-request cost by how many requests we expect. This gives the total bill.
Cost per request: $0.0007
Expected volume: 1,000,000 requests per month
|
↓
monthly cost: $0.0007 x 1,000,000 = $700 per monthWe multiply the small per-request cost by our expected traffic. A tiny cost per request adds up fast at scale. Now we have a real forecast of the monthly bill. This is Step 3. But we must not forget some extras. Let’s cover them.
Do not forget the hidden extras
A naive estimate misses some things that raise the real cost. Include these.
Retries. If a request fails or the agent loops, it may run more than once.
RAG context. If we attach retrieved documents, the input tokens grow a lot.
System prompts. Long instructions sent every time add up.
Multi-step agents. An agent makes many model calls per task, not one.
Add for:
retries | RAG context | long system prompts | multi-step agent callsThe real cost is often higher than a simple one-call estimate, because of context, retries, and multi-step agents. So we adjust our estimate upward to be safe. This keeps our forecast realistic. Now, let’s do a full example.
A full worked example
Learning by example is the best way to learn. Let’s estimate an agent app.
The app is an agent that makes 5 model calls per task.
Per call: 800 input + 300 output tokens (including RAG context).
Tokens per task: 5 calls x (800 + 300) = 5,500 tokens
Prices: input $0.50/M, output $1.50/M
Per task cost:
input: 5 x 800 = 4,000 tokens -> 4,000/1M x $0.50 = $0.002
output: 5 x 300 = 1,500 tokens -> 1,500/1M x $1.50 = $0.00225
total per task: $0.00425
Volume: 100,000 tasks per month
Monthly cost: $0.00425 x 100,000 = $425 per monthHere, we can see a realistic forecast. Because it is an agent with 5 calls per task, the cost is 5 times a single call. Now we know, before building, that this app costs about $425 a month at this volume. Now, let’s see how to lower it if needed.
How to lower the estimate
If the estimate is too high, we can reduce it before building.
Use a cheaper model for the easy parts of the task.
Shorten the output, since output tokens cost more.
Trim the input, sending only the context that is truly needed.
Cache repeated answers, so we do not pay to generate the same thing twice.
Reduce the number of steps in an agent.
Cheaper model + shorter output + trimmed input + caching + fewer steps
= a lower billOnce we see the estimate, we have clear ways to bring it down. It is far easier to plan these before building than to fix a high bill after launch.
Now we must have understood how to estimate LLM cost before we build.
© 2026 Outcome School
A1502, DGH, SECTOR 62, Gurugram, Haryana, India - 122001