Estimate Token Count per Request for LLM API Budgeting

To estimate token count per request, split your prompt and expected completion into characters, divide each by roughly 4 to get tokens, add both numbers, and multiply by your model's per-token price and your monthly request volume. The result is a budget estimate accurate to within a workable margin, not an exact invoice prediction.

Why Token Counts Drive Your LLM Bill

LLM APIs bill by the token. A token is the unit of text a model reads and writes: it can be a whole short word, part of a long word, punctuation, or a space attached to a word. Models don't see characters or words directly; they see tokens, so tokens are also the unit your invoice is written in. Every request you send has two billable parts: prompt tokens (everything you send in, including system instructions, conversation history, retrieved documents, and the user's message) and completion tokens (everything the model sends back).

The practical consequence is that cost scales with text volume, not with the number of calls. Ten short requests can cost less than one request padded with a long document. Completion tokens are typically priced higher than prompt tokens, so output length is often the biggest lever on your bill. If you want a reliable monthly estimate, you need a per-request token count for both sides of the call, and then you multiply by volume and price. That is the whole workflow this article walks through.

The Characters-to-Tokens Rule of Thumb

The widely used shortcut is that one token corresponds to roughly 4 characters of English text. Equivalently, one token is about three-quarters of a word, and 100 tokens is roughly 75 words. This is a rule of thumb, not a law: the ratio comes from how tokenizers split text, and it shifts with the content. Common words and normal prose sit close to 4 characters per token. Code, JSON, URLs, numbers, and text in non-English languages usually tokenize less efficiently, meaning fewer characters per token, so dividing by 4 can undercount them. Unusually repetitive or simple text can go the other way.

Because this is an estimate, treat the output as a range rather than a single number. A reasonable working assumption is 3.5 to 4.5 characters per token for ordinary English prose, with the lower end (more tokens) for code or structured data. If you need tighter numbers later, most providers offer a tokenizer tool that counts exactly, but for budgeting the ratio plus a safety buffer is usually enough. Write the formula as:

tokens ≈ characters / 4

and remember to round up, since partial tokens still bill as tokens.

Estimating Prompt and Completion Tokens per Request

A single API call has two token costs: the prompt tokens (everything you send — system instructions, conversation history, the user's message) and the completion tokens (everything the model generates back). Estimate each separately, because they behave differently: prompt length is something you control and can measure, while completion length is uncertain until the response arrives.

Prompt tokens. Assemble the exact text you plan to send and count its characters, then divide by your chosen ratio:

prompt_tokens ≈ total_prompt_characters / 4

Include whitespace, punctuation, and any formatting in the character count. If you send the same system prompt on every request, count it once and add it to every estimate — small prompts repeated thousands of times dominate the bill.

Completion tokens. You cannot measure what doesn't exist yet, so estimate from intent. Two practical methods:

• Cap-based: if you set a max_tokens limit, treat that as the worst case and a fraction of it (say half) as the typical case.
• Sampling-based: if you know the response type, estimate its length in characters and divide by 4. A two-sentence answer runs roughly 200–300 characters, so about 50–75 tokens. A short structured JSON reply might be 100–150 characters, so about 25–40 tokens.

State your assumption explicitly and label it an estimate — the arithmetic is only as good as the length you assume.

From Tokens to Monthly Cost: A Worked Example

Suppose your application handles 1,000 requests per day and each request sends a 600-character system prompt, a 1,400-character user message, and receives a completion you estimate at 400 characters. Assume an input price of $0.50 per million prompt tokens and an output price of $1.50 per million completion tokens (illustrative figures — check your provider's current rates).

Per request:

prompt_characters   = 600 + 1,400 = 2,000
prompt_tokens       ≈ 2,000 / 4   = 500
completion_tokens   ≈ 400 / 4     = 100

prompt_cost     = 500 / 1,000,000 × $0.50 = $0.00025
completion_cost = 100 / 1,000,000 × $1.50 = $0.00015
request_cost    = $0.00025 + $0.00015     = $0.00040

Monthly:

monthly_requests = 1,000 × 30        = 30,000
monthly_cost     = 30,000 × $0.00040 = $12.00

Note that prompt tokens account for roughly 62% of the cost here despite the lower per-token price — trimming your system prompt has visible impact.

Quick checklist before you commit the number to a budget:

1. Count characters on the exact strings sent, including system prompt and history.
2. Divide by 4, then add a 10–20% buffer for tokenizer variance.
3. Estimate completion length from max_tokens or a sampled response, not optimism.
4. Apply separate input and output prices.
5. Multiply by expected requests per month, then add buffer again for retries and failed calls.

monthly_budget ≈ (prompt_tokens × input_price + completion_tokens × output_price)
                 / 1,000,000 × requests_per_month × 1.15

## Frequently Asked Questions

### How many characters are roughly one token?

For English text, a common rule of thumb is about 4 characters per token, so 1,000 characters is roughly 250 tokens. This is an estimate, not an exact conversion: punctuation, numbers, code, and non-English languages tokenize less efficiently and can push the ratio closer to 2–3 characters per token. For budgeting, the 4:1 ratio is a reasonable starting point, but verify it against real token counts from your provider for your specific content.

### Do prompt and completion tokens cost the same?

Often not. Many LLM providers price input (prompt) tokens and output (completion) tokens at different rates, and output is frequently the more expensive of the two. Check your provider's current pricing page, then run the cost math separately for each token type rather than applying one blended rate. If your provider does charge the same rate for both, you can simplify by summing all tokens and multiplying once.

### How do I estimate completion length before calling the API?

You cannot know the exact completion length in advance, so estimate it from your use case: short answers (classifications, yes/no replies) might run tens of tokens, while paragraph-length responses run into the hundreds. A practical approach is to set and record a `max_tokens` cap per request type, then use a typical observed length below that cap for budgeting. Treat the cap as your worst-case cost and the typical length as your expected cost.

### Should I add a buffer to my token estimates?

Yes, a modest buffer is wise because the characters-to-tokens ratio varies by content and completion lengths fluctuate. A buffer of roughly 10–20% on top of your estimated token totals is a reasonable range to cover this uncertainty, and you can tune it once you compare estimates against actual usage data. Keep the buffer explicit in your spreadsheet so you can see how much of your budget is contingency rather than expected spend.

### How do I convert per-request tokens into a monthly budget?

Multiply tokens per request by requests per month to get monthly tokens, then multiply by your provider's per-token price (converting from per-million pricing if needed). For example:

monthly_cost = (prompt_tokens × requests_per_month × prompt_price) + (completion_tokens × requests_per_month × completion_price)

Run this separately for each request type or model, then sum the results and add your buffer. Recalculate whenever traffic volume, prompt design, or pricing changes.