LLM Cost Calculator: How to Estimate API Spend

An LLM cost calculator estimates how much you'll pay to run a large language model based on the number of tokens you send and receive, multiplied by the provider's per-token price. If you're searching for one, you're probably trying to answer one of two questions: "how much will this feature cost me at scale?" or "why is my bill higher than I expected?" Both come down to the same math, and once you understand it, you can build your own estimate in a spreadsheet in five minutes — no third-party tool required.

This article walks through the formula, the variables that actually move your bill, and how to turn a rough estimate into a reliable forecast before you ship a product feature that calls an LLM on every user request.

The Core Formula

Every LLM cost calculation boils down to this:

cost = (input_tokens / 1,000,000) × input_price_per_million
     + (output_tokens / 1,000,000) × output_price_per_million

Most providers, including Anthropic, price input and output tokens separately, and output tokens are almost always more expensive — often 4–5x the input rate. That asymmetry matters more than people expect, because a chat feature that returns long, detailed answers can cost far more than one that returns short confirmations, even if the prompts are similar length.

To estimate a monthly bill, you need three numbers:

• Average input tokens per request (system prompt + user message + any retrieved context)
• Average output tokens per request (the model's response)
• Requests per month (or per day, multiplied out)

Multiply those together with the per-token rates and you have a working estimate.

Estimating Token Counts

Tokens aren't words. As a rough rule of thumb, one token is about 4 characters of English text, or roughly ¾ of a word. So a 500-word prompt is close to 650–700 tokens. This is a rough estimate — for anything precise you should tokenize a sample of your real prompts using a tokenizer library rather than guessing.

For a chat application, don't forget:

• The system prompt is sent on every single request, not just the first one, unless you're using prompt caching.
• Conversation history grows the input token count with every turn if you're not trimming it.
• Tool definitions and results count as input tokens too, and can be surprisingly large if you're passing verbose JSON schemas.

This is where a lot of cost estimates go wrong: people calculate based on the user's visible message and ignore the system prompt, history, and tool schema overhead that's silently riding along on every call.

A Worked Example

Say you're building a support assistant:

• System prompt + context: 800 input tokens
• Average user message: 50 tokens
• Average response: 300 output tokens
• 20,000 requests per month

input_tokens_total  = 20,000 × 850  = 17,000,000
output_tokens_total = 20,000 × 300  = 6,000,000

Plug those into the formula with your provider's per-million rates and you get a monthly figure. Run the same math with a longer system prompt (say, 2,000 tokens for a heavily-instructed agent) and the bill can jump 40–50% without a single extra user request — which is exactly the kind of thing a spreadsheet catches and a gut estimate misses.

Factors That Change the Number

A few variables consistently move estimates more than people expect:

1. Conversation length. If you resend full history on each turn, a 10-turn conversation can cost 5–10x a single-turn request, since every prior message gets re-sent as input tokens.
2. Streaming vs. non-streaming. Streaming doesn't change token cost — it changes perceived latency, not the bill.
3. Tool use. Each tool call round-trip adds both the tool definition (input) and the tool result (input again, on the next turn) to your token count.
4. Retries and errors. Failed requests that get retried still consume tokens on the failed attempt if it reached the model before failing downstream.
5. Model choice. Larger, more capable models generally cost more per token but may need fewer retries or shorter prompts to get a usable answer — so raw per-token price isn't the whole story.

Turning Estimates Into Real Numbers

A spreadsheet gets you a forecast. What you actually need in production is per-request visibility so you can tell if your estimate was right — and catch the moment it stops being right, because a prompt template change or a new feature can quietly double your average token count.

This is one of the practical reasons teams route their Claude usage through SubToAPI: every request made with a sub_live_ application key returns usage metadata alongside the response, so you can track actual input/output token counts per call instead of estimating blind. That data is what turns a one-time cost calculator exercise into an ongoing cost model you can trust. See the Messages API docs for the response fields, or the quickstart to get a key running in a few minutes.

If you're managing this across a team, seat-based visibility also matters — each teammate's usage rolls up in one dashboard rather than getting lost across individual accounts, which is covered on the pricing page.

A Simple Way to Model Your Own Costs

If you want a repeatable process rather than a one-off calculation:

• Log real input/output token counts for a sample of production requests (or use response metadata if your provider returns it).
• Compute the average per request, separately for input and output.
• Multiply by expected monthly volume using the formula above.
• Re-run the calculation whenever you change your system prompt, add a tool, or extend conversation memory — these are the changes most likely to move your bill without you noticing.

A calculator is only useful if it's based on your actual prompt shape, not a generic assumption. Two apps with the same request volume can have wildly different bills depending on system prompt length and how much conversation history gets resent.

questions

Do input and output tokens cost the same? No. Output tokens are typically priced at 4–5x the rate of input tokens, so response length affects cost more than prompt length in most applications.

Does streaming reduce LLM costs? No. Streaming changes how the response is delivered (token by token vs. all at once) but the total token count — and therefore the cost — is the same either way.

How can I track real token usage instead of estimating it? Use a provider or gateway that returns usage metadata with each API response. SubToAPI includes token counts in every request made through its Messages API, which lets you compare actual usage against your cost estimates over time.