LLM token counting and API cost estimation: a 2026 developer's guide

Why "just count characters" doesn't work

Every LLM prices per token, not per character or word. A token is roughly a sub-word chunk produced by the model's tokenizer: common words like the are one token, uncommon words like tokenization split into 2-3, emoji and non-Latin scripts often take 3-6 each.

Rough averages:

• GPT-4o / GPT-4o mini: ~4 characters per token for English prose. Code and JSON run denser (~3.5). Chinese, Japanese, Korean run much sparser (~1.5).
• Claude (Opus, Sonnet, Haiku): ~3.6 characters per token. Anthropic's tokenizer is different from OpenAI's — the same prompt won't have the same token count on both.
• Gemini 2.0: closer to GPT at ~4 chars/token, but Google measures cost in tokens and characters for some endpoints. Read the pricing page carefully.

A 5,000-word blog post is roughly 6,500 tokens on GPT-4o and 7,200 on Claude. Ballpark is fine for cost estimation; if you need exact counts, run the model's real tokenizer.

The cost math you actually need

Two multipliers matter:

1. Input token price × input tokens. Every call sends the whole conversation history and system prompt — this scales with context length.
2. Output token price × output tokens. Usually 3-5x more expensive than input. Long answers dominate cost on any model.

For example, on Claude Sonnet 4 (~$3 in, $15 out per million tokens): a 2,000-token prompt with a 500-token response costs (2000 × $3 + 500 × $15) / 1M = $0.0135. Multiply by traffic — 100K calls per day and you're at $1,350/day.

Use LLM Token Counter to run the math per-model and per-call before shipping. It shows the 1K and 1M-call totals so a demo doesn't quietly become a $10K/month invoice.

Prompt caching changes everything

Both OpenAI and Anthropic now offer prompt caching — the same system prompt or long context, sent repeatedly, is charged at ~10% of the input price after the first call. Two rules to get the discount:

1. Put static content first. Cache lookup is prefix-based — anything after your first dynamic character isn't cached.
2. Keep the prefix stable. A timestamp injected into the system message breaks the cache every request.

If you're building a RAG app or a chatbot with a long system prompt, prompt caching cuts input cost by 90%. The math above assumes no caching — with caching, real-world cost is often half the estimate.

Structured output has its own pricing wrinkle

When you use OpenAI's structured output or Anthropic's tool use with a JSON schema, the schema itself is sent as part of the prompt on every call. A large schema (dozens of fields, nested objects) can add 500-2,000 tokens per request. That's usually cheap enough to ignore, but it's real cost.

Two mitigations:

• Keep schemas minimal. Only include the fields you actually need in the response.
• Cache the schema. Put it in the cached prefix along with your system prompt.

Building a schema from an example JSON payload is a common part of this workflow — JSON Schema Generator infers a valid draft-2020-12 schema from a sample in one paste.

Context window vs practical context

Claude and Gemini advertise 200K and 2M token windows. That doesn't mean you should fill them.

Two reasons:

1. Cost scales linearly with input tokens. A 200K-context prompt on Claude Opus costs $3 per call before you get the response. That's not sustainable at any real traffic.
2. Accuracy degrades with context length. All frontier models show "lost in the middle" behavior — facts buried in the middle of a long context are recalled worse than facts at the start or end. Aim for the smallest useful context.

Use retrieval (RAG) to send only the top-k relevant chunks rather than the whole knowledge base. Rule of thumb: aim for under 10K tokens per call for consistent quality and predictable cost.

Streaming doesn't change the bill

A common misconception: streaming responses (SSE) reduce cost. They don't — you still pay for every token generated. Streaming reduces perceived latency (users see tokens as they arrive) and gives you a way to cancel early if the response is going off-track, saving cost on aborted calls.

The debugging workflow

The pattern that works:

1. Paste your full prompt (system + user + any context) into LLM Token Counter.
2. Pick the model you're targeting — token counts and prices differ by 2-5x across models.
3. Estimate output length — usually you have a rough sense (a JSON response, a paragraph, a code block).
4. Multiply by expected traffic — the tool shows 1K and 1M call totals. Anything alarming at 1K calls will explode at 1M.
5. Iterate on the prompt — shorten the system message, trim examples, offload context to RAG.

A 30% shorter system prompt is a 30% cheaper input token bill on every call, forever. Prompt engineering is cost engineering.

Related workflows

• JSON Formatter — for pretty-printing structured LLM outputs.
• JSON Schema Generator — for building tool/function schemas.
• Regex Tester — for extracting fields from unstructured LLM responses.