What Are Tokens? How to Estimate LLM API Cost (Worked Example)

If you use a language model through an API, you’re billed in tokens. Understanding what a token is — and how input and output tokens are priced — is the difference between a confident budget and a surprise invoice. This guide explains tokens, gives you the cost formula, and walks through a full estimate.

About the numbers: model prices change often and differ by provider. Every price in this article is a hypothetical example chosen to make the arithmetic easy to follow. Use your provider’s current pricing page for real figures.

What is a token?

A token is a chunk of text that the model reads or writes as one unit. Models don’t see letters or whole words; a tokenizer splits text into pieces from a fixed vocabulary. Common words are often a single token, while rare words, names, numbers and code get split into several.

For example, a sentence like “Tokenization isn’t magic.” might be split into pieces such as Token, ization, isn, 't, magic, . — the exact split depends on the tokenizer.

Useful rules of thumb for English prose:

• 1 token ≈ 4 characters
• 1 token ≈ ¾ of a word, so 1,000 tokens ≈ 750 words
• A dense page of text is very roughly 500–700 tokens

These are approximations. Important caveats:

• Different providers use different tokenizers, so the same text can produce different token counts on different models.
• Many non-English languages use more tokens per word than English, sometimes significantly more.
• Code, JSON, URLs and numbers often tokenize less efficiently than prose.

For anything you’ll budget against, count tokens with the provider’s own tokenizer or token-counting endpoint, and read the usage field returned with each API response — that’s the number you’re billed on.

Input tokens vs output tokens

Almost every API prices these separately:

• Input tokens (also “prompt tokens”): everything you send — system prompt, instructions, examples, retrieved documents, conversation history, tool definitions, and the user’s message.
• Output tokens (“completion tokens”): everything the model generates.

Output tokens are typically priced higher than input tokens, often several times higher. Prices are usually quoted per million tokens (sometimes per thousand).

Tokens people forget to count

• Conversation history. In a chat, the whole history is usually sent again on every turn. Turn 10 costs far more input than turn 1.
• Tool and function definitions. Their schemas are part of the input.
• Reasoning tokens. Some models generate internal reasoning before the visible answer. Where this applies, those tokens are generally billed as output even if you don’t see all of them — check your provider’s docs.
• Images and files. These are converted to tokens too, by provider-specific rules.
• Retries. Failed or regenerated requests still cost tokens.

The cost formula

cost_per_request = (input_tokens  / 1,000,000) × input_price_per_1M
                 + (output_tokens / 1,000,000) × output_price_per_1M

monthly_cost     = cost_per_request × requests_per_day × 30

That’s it. The hard part isn’t the arithmetic; it’s estimating realistic token counts.

Worked example: a support assistant

Imagine a customer-support assistant that answers questions using retrieved help-center articles.

Step 1: Estimate tokens per request

Measure a sample of real or realistic requests rather than guessing. Suppose a typical request looks like this:

Component	Tokens
System prompt and instructions	800
Retrieved help articles	1,500
Conversation history (average)	600
User’s new message	100
Total input	3,000
Model’s answer (output)	400

Step 2: Apply prices (hypothetical)

Say we’re comparing two made-up models:

• Model L (larger): $2.00 per 1M input tokens, $8.00 per 1M output tokens
• Model S (smaller): $0.25 per 1M input tokens, $1.00 per 1M output tokens

For Model L:

input:  3,000 / 1,000,000 × $2.00 = $0.0060
output:   400 / 1,000,000 × $8.00 = $0.0032
total per request                 = $0.0092

For Model S:

input:  3,000 / 1,000,000 × $0.25 = $0.00075
output:   400 / 1,000,000 × $1.00 = $0.00040
total per request                 = $0.00115

Step 3: Scale to volume

At 5,000 requests per day:

Hypothetical model	Per request	Per day	Per month (30 d)
Model L	$0.00920	$46.00	$1,380.00
Model S	$0.00115	$5.75	$172.50

A fraction of a cent per request becomes a meaningful monthly line item at volume — and the gap between the two models is eight-fold. Whether Model S is good enough is a quality question you answer with an evaluation on your own examples, not with the price table.

Step 4: Add a safety margin

Real traffic is lumpy. Some conversations run long, some users paste whole documents, and some requests get retried. A sensible budget uses something like your 90th-percentile request size rather than the average, or adds an explicit buffer on top of the average estimate.

A tiny calculator you can reuse

def llm_cost(input_tokens, output_tokens, in_price_per_1m, out_price_per_1m,
             requests_per_day=1, days=30):
    per_request = (input_tokens / 1_000_000) * in_price_per_1m \
                + (output_tokens / 1_000_000) * out_price_per_1m
    return {
        "per_request": per_request,
        "per_day": per_request * requests_per_day,
        "per_month": per_request * requests_per_day * days,
    }

# Hypothetical prices — replace with your provider's current rates
print(llm_cost(3000, 400, 2.00, 8.00, requests_per_day=5000))
# {'per_request': 0.0092, 'per_day': 46.0, 'per_month': 1380.0}

Floating-point output may show a few extra decimal places; round for display.

Where your estimate can go wrong

• Using word counts instead of token counts. Fine for a first guess, risky for a budget.
• Ignoring history growth in multi-turn chats.
• Forgetting output length variance. If you don’t set a maximum output length, a few very long answers can skew costs.
• Stale prices. Re-check the pricing page whenever you re-estimate — and note the date you checked.
• Missing discounts. Prompt caching and batch processing can change the math considerably. See how to cut LLM API costs.

Key takeaways

1. Tokens are the billing unit; roughly 750 English words per 1,000 tokens, but measure with the real tokenizer.
2. Input and output are priced separately, and output is usually pricier.
3. Cost per request × volume is simple arithmetic — the work is in estimating realistic token counts.
4. Always label which prices you used and when you checked them.

Doing this by hand for several models at once is tedious. MaximumAI’s cost calculator will let you enter token volumes once and see per-request and monthly costs across models side by side.