LLM Cost Estimation: A Practical Method for Budgeting Spend

LLM cost estimation is the process of predicting how much you'll spend on a language model before or while building a feature, so you can budget correctly and avoid surprises on your invoice. The core method is simple: estimate token volume, multiply by per-token pricing, then adjust for real-world factors like retries, system prompts, and usage growth. The hard part isn't the math — it's getting the inputs right.

This article walks through a repeatable estimation process you can apply to any feature, with worked examples and the assumptions people most often get wrong.

The Basic Formula

Every LLM cost estimate starts from the same equation:

cost = (input_tokens × input_price) + (output_tokens × output_price)

Most providers price input and output tokens differently, and output tokens are usually 3–5x more expensive per token. That asymmetry matters more than people expect — a feature that generates long responses can cost far more than one with long prompts but short answers.

To estimate total cost for a feature, you need:

1. Tokens per request (input and output separately)
2. Requests per day/month
3. Price per token for input and output
4. A growth or peak multiplier for realistic planning

Get any one of these wrong by 2x and your whole estimate is off by 2x — so it's worth spending real time on each.

Step 1: Estimate Tokens Per Request

Don't guess. Take 10–20 real or realistic prompts for your feature and count tokens using the model's tokenizer (or a rough rule: 1 token ≈ 4 characters of English text). Include everything that actually gets sent:

• The user's message
• Your system prompt
• Any injected context (RAG chunks, chat history, tool definitions)
• Few-shot examples, if you use them

System prompts and RAG context are the most commonly forgotten costs. A 50-token user question sitting behind a 600-token system prompt and 800 tokens of retrieved context is really a ~1,450-token input, not a 50-token one.

For output, look at actual response lengths from testing, not the theoretical maximum. If you cap max_tokens at 1000 but responses average 250, estimate on the average — but keep the cap in mind as your worst case for cost ceilings.

Step 2: Estimate Request Volume

This is usually the biggest source of error in cost estimates, because it depends on adoption, not engineering. A few ways to ground it:

• Existing feature analogs: if you're adding AI to a search bar, use current search volume as a proxy.
• Seat-based estimates: for internal tools, estimate requests per user per day and multiply by expected active users.
• Funnel-based estimates: for consumer features, estimate conversion from page views or sessions to feature usage.

Always produce a range, not a single number — a low, expected, and high case. Volume estimates for new features are frequently wrong by 3–10x in the first few months, so build your plan around the range, not the midpoint.

Step 3: Apply Real-World Multipliers

Raw token math underestimates actual spend. Account for:

• Retries and errors: failed requests that get retried still consume tokens. Add 5–15% depending on how aggressive your retry logic is.
• Streaming cancellations: users who cancel mid-stream still generate partial output tokens you're billed for.
• Multi-turn context growth: in chat-style features, each turn resends prior conversation history, so token cost per turn grows through a session. Estimate the average conversation length, not just a single turn.
• Tool use round-trips: if the model calls tools and receives results back, each round-trip adds input tokens for the tool output and often another output generation. Two or three tool calls can double or triple a request's real cost versus a single-turn estimate.

A reasonable rule of thumb: take your raw token-math estimate and multiply by 1.3–1.6 to get a realistic production number, depending on how conversational and tool-heavy the feature is.

Worked Example

Say you're estimating a support-chat feature:

• System prompt + tool definitions: 900 tokens
• Average user message: 60 tokens
• Retrieved context: 500 tokens
• Average output: 300 tokens
• Average conversation length: 3 turns, with history resent each turn

Input tokens per conversation ≈ 900 + 500 + (60×3) + (300×2, prior outputs resent) = 3,080 Output tokens per conversation ≈ 300 × 3 = 900

At a blended rate (adjust to your provider's actual pricing) of $3/million input tokens and $15/million output tokens:

input cost  = 3,080 / 1,000,000 × $3  = $0.00924
output cost = 900   / 1,000,000 × $15 = $0.0135
total per conversation ≈ $0.023

At 5,000 conversations/month: ~€110/month in raw model cost (currency-adjusted), before your ~1.4x real-world multiplier — so budget closer to €150.

Where Estimates Break Down

The most common estimation mistakes:

• Forgetting system prompt and tool-definition overhead, which is fixed per request regardless of user input length.
• Using max output length instead of average, which overstates cost, or using average instead of peak, which understates worst-case bills.
• Ignoring conversation history growth in multi-turn features — cost per turn is not constant.
• Not separating input and output pricing when doing quick mental math, since the ratio between them varies a lot by model.

If you're building on top of an API layer like SubToAPI, usage metadata returned with each response (token counts, model used) makes it much easier to replace estimates with actual measured numbers within days of shipping — check /docs/messages for the response format. That's the fastest way to correct an estimate: ship to a small cohort, measure real token usage for a week, then re-run your volume math with real numbers instead of assumptions.

questions

What's the fastest way to estimate LLM costs for a new feature? Count tokens on 10–20 realistic prompts (including system prompt and context), multiply by expected monthly volume and per-token pricing, then apply a 1.3–1.6x multiplier for retries, multi-turn history, and tool calls.

Why do LLM cost estimates end up too low in production? The usual causes are ignoring system prompt/context overhead, using average instead of realistic peak output length, and not accounting for conversation history growing token counts on every turn.

Should I estimate cost per request or cost per user? Both. Cost per request tells you unit economics; cost per active user (requests/user × cost/request) tells you whether the feature is financially viable at your expected user base, which is usually the number that matters for budgeting.