How to estimate LLM costs before you build

The most common LLM cost surprise isn't a price change — it's a team shipping a feature without ever running the arithmetic first. Estimating cost before you build takes about ten minutes and needs no code: you're modeling a per-request token shape and a request volume, then multiplying. Here's the method, in order.

1. Estimate input tokens per request

Add up everything that goes into the prompt: the system instruction, any retrieved context or documents, tool definitions if the model can call tools, and the user's actual message. As a rough rule, English text runs about four characters per token, but don't guess for anything that matters — paste a representative prompt into the token counter and read the real count. Long context (a full document, a large tool schema set) is very often the biggest line item here, not the user's message.

2. Estimate output tokens per request

This is the harder number to get right, because it depends on what the model actually does, not what you asked it. A short chat reply might be 100-300 tokens. A structured extraction task might be a few hundred. An agentic task that writes code, calls tools, and reasons through multiple steps can run into the thousands per request — and output tokens are priced higher than input on every model in this dataset, so getting this number wrong skews the whole estimate. If you have any working prototype, measure the real output length instead of guessing.

3. Pick two or three candidate models, not one

Resist locking in a model before you've compared it against at least one cheaper and one more capable alternative. Capability and price rarely move together in a straight line — a mid-tier model from one provider sometimes beats a flagship from another on both axes for a specific task.

4. Multiply by real volume

Cost per request times requests per day times roughly 30.44 gives a monthly figure. Use your actual expected volume, not a round number that sounds achievable — if you're launching a new feature, estimate against a realistic adoption curve for month one and month three separately, since the cost that kills a budget is usually the one nobody modeled past launch week.

5. Check caching and batch eligibility before finalizing

• Does your prompt reuse a static prefix across requests? If yes, model the cached rate, not just standard input — see prompt caching cost savings explained.
• Does the workload need a synchronous response? If no, model the batch rate instead — see batch API discounts, when to use them.
• Recompute the monthly total with whichever discounts actually apply to your architecture, not the theoretical maximum discount.

The calculator runs steps 3 through 5 for you across every current model at once — enter your token shape and volume, and compare candidates side by side without redoing the math per model.

Common mistakes that skew an estimate

• Estimating from the shortest example prompt you can think of instead of a realistic average across real usage.
• Forgetting that a system prompt, tool definitions and conversation history are all input tokens too, not just the user's latest message.
• Assuming output length scales linearly with input length — it usually doesn't, and agentic or reasoning-heavy tasks can generate far more output than a similarly-sized simple prompt.
• Modeling launch-day traffic instead of month-three traffic, and being surprised when a successful feature costs more once people actually use it.
• Picking a model once and never revisiting the choice as usage patterns — or provider pricing — change.

Build in a review checkpoint

An estimate made before launch is a snapshot, not a guarantee — real usage patterns and prompt lengths drift once actual users are involved, and provider pricing itself changes on its own schedule. Revisit the estimate against real spend within the first month, not at the annual budget review.

The cheapest way to keep an estimate honest going forward is to actually log real usage as it happens, rather than re-estimating from scratch every quarter. Recording input tokens, output tokens and model choice per request as you go gives you a trend line instead of a guess — and once you have that trend line, spotting a cost regression (a prompt that quietly grew, a model that got repriced) is a matter of glancing at a dashboard instead of redoing the whole exercise.