What Is LLM Token Cost? Tokens, Pricing & Math Explained

LLM token cost is the price you pay for the text an AI model reads and generates, measured in tokens rather than words or characters. Every request to a large language model API is billed based on two numbers: how many tokens you send in (the prompt) and how many tokens the model sends back (the completion). Multiply each by its per-token rate, add them together, and that's your cost for a single API call.

If you're trying to understand why your API bill looks the way it does, or you're trying to estimate costs before shipping a feature, this comes down to three things: what a token actually is, how providers price input versus output differently, and how to calculate real-world costs for your specific use case.

What a Token Actually Is

A token is a chunk of text, not a word. Most tokenizers split text into pieces that average around 4 characters or roughly ¾ of a word in English. So "hello world" is 2 tokens, but "internationalization" might be 4-5 tokens depending on the tokenizer.

Rough rules of thumb:

• 1 token ≈ 4 characters in English text
• 100 tokens ≈ 75 words
• 1,000 tokens ≈ 750 words (roughly 1.5 pages of standard text)

Code, non-English languages, and text with lots of punctuation or special characters tend to tokenize less efficiently — meaning more tokens for the same amount of "content." A JSON blob with heavy nesting can cost noticeably more tokens than plain prose of the same length.

Why Input and Output Are Priced Differently

Almost every LLM provider charges different rates for input tokens (what you send) versus output tokens (what the model generates). Output is typically 3-5x more expensive than input, because generating text requires more compute per token than processing it.

This has direct implications for how you design prompts:

• A long system prompt with detailed instructions costs less per token than the model's response to it
• Asking a model to "be concise" or setting a lower max_tokens limit has an outsized effect on cost, since output tokens carry the premium
• Techniques like prompt caching (where a static system prompt is reused across calls) can meaningfully cut input costs on repeated requests

Calculating Token Cost for a Real Request

Here's the actual math. Say a model charges $3 per million input tokens and $15 per million output tokens (typical mid-tier pricing shape):

Prompt: 500 tokens
Completion: 800 tokens

Input cost  = 500 / 1,000,000 * $3  = $0.0015
Output cost = 800 / 1,000,000 * $15 = $0.0120
Total       = $0.0135 per request

That looks tiny until you multiply it by volume. At 50,000 requests a month with this profile, you're looking at ~$675/month just in token costs — before any infrastructure, hosting, or engineering time.

A simple way to estimate costs for a new feature:

1. Draft a realistic prompt (including system instructions, few-shot examples, and typical user input)
2. Count tokens using the provider's tokenizer or an estimate (chars ÷ 4)
3. Estimate a typical output length based on your use case
4. Multiply by expected request volume for a month
5. Add a 20-30% buffer for retries, longer-than-expected responses, and edge cases

What Drives Token Cost Up in Practice

A few patterns quietly inflate token spend:

• Long conversation history. Chat-based apps that resend the full conversation on every turn pay for the same tokens repeatedly. A 20-turn conversation can cost far more in cumulative input tokens than the sum of the individual messages suggests.
• Verbose system prompts. Detailed instructions and few-shot examples are useful but get billed on every single call unless cached.
• Uncapped output. Without a max_tokens limit, models can generate longer responses than necessary, especially for open-ended prompts.
• Retries and error handling. Failed or malformed responses that trigger automatic retries double- or triple-count tokens for that interaction.
• Tool use and function calling. Each round-trip in an agentic loop — tool call, tool result, model reasoning — adds tokens on every hop.

Managing Token Cost Without Sacrificing Quality

A few practical levers:

• Trim conversation history. Summarize older turns instead of resending them verbatim.
• Set explicit max_tokens. Don't rely on the model to self-limit output length.
• Use caching where available. Reusing a static system prompt or context block avoids repaying for identical input.
• Pick the right model for the task. Smaller, cheaper models are often sufficient for classification, extraction, or short-form tasks; reserve larger models for complex reasoning.
• Monitor per-request cost, not just monthly totals. Aggregate spend hides which specific endpoints or prompts are expensive.

If you're already working with Claude and want a straightforward way to track this, SubToAPI turns your existing Claude access into an HTTPS API with usage metadata returned on every response, so you can see exact token counts per call instead of estimating after the fact. Check the pricing page or read the quickstart to see how request-level accounting works in practice.

Token Cost vs. Total Cost

Token cost is the per-call price of using an LLM, but it's not your only cost. Total cost of running an LLM-powered feature also includes:

• API infrastructure or middleware (routing, retries, logging)
• Engineering time spent on prompt tuning and monitoring
• Storage and latency costs from caching layers
• Team/seat costs if using a managed platform with multiple users

Token cost is usually the largest line item at meaningful scale, which is why understanding it in isolation — separate from subscription or platform fees — matters for budgeting and for deciding whether to build in-house or use a managed API layer.

questions

Is LLM token cost the same as API cost? Token cost is the core component of API cost — the per-token rate multiplied by usage. Total API cost may also include platform fees, seat licenses, or infrastructure costs layered on top of raw token pricing.

Why does output cost more than input per token? Generating text requires the model to run inference sequentially, token by token, which is more compute-intensive than processing (reading) input tokens in parallel. Providers typically price output 3-5x higher than input as a result.

How can I estimate token cost before building a feature? Draft a realistic prompt and expected response, count tokens with the provider's tokenizer (or estimate ~4 characters per token), multiply by the per-token rate, then scale by expected monthly request volume plus a buffer for retries.