LLM Cost Per Token: What You're Really Paying For

LLM Cost Per Token: What You're Really Paying For

LLM cost per token is the price a provider charges for each unit of text processed by a model, typically measured in dollars or euros per million tokens. A token is roughly 4 characters or ¾ of a word in English, so a 1,000-word document is around 1,300–1,500 tokens. Providers almost always price input tokens (what you send) and output tokens (what the model generates) separately, with output usually costing 2–5x more than input.

If you're trying to figure out what an LLM feature will actually cost you in production, the per-token rate is only the starting point. The real number depends on your prompt length, how much context you carry across turns, whether you're streaming, and how many retries or tool calls happen behind the scenes. This article breaks down how per-token pricing actually works and how to estimate it accurately.

How Per-Token Pricing Works

Every major LLM provider (Anthropic, OpenAI, Google) bills based on tokens consumed, not requests made. The pricing structure typically looks like this:

• Input tokens: everything in your prompt — system instructions, user message, conversation history, retrieved documents, tool definitions.
• Output tokens: everything the model generates in response, including tool calls and reasoning if the model does any.
• Cached tokens (where supported): repeated context, like a long system prompt, billed at a reduced rate on subsequent calls.

Rates are usually quoted per million tokens (per MTok) because per-token prices are fractions of a cent. A model might cost $3 per MTok input and $15 per MTok output. That asymmetry matters: a chatbot that writes long, detailed answers will cost far more than one that answers tersely, even with identical input.

Why the "Per Token" Number Is Misleading on Its Own

Two applications hitting the same model at the same published rate can have wildly different bills. The per-token price doesn't tell you:

How much context you're sending on every call. If you re-send the full conversation history each turn (which most chat implementations do, since these models are stateless), a 20-turn conversation costs far more per turn than the first one, because the input keeps growing.

How verbose the model's output is. Two prompts asking for "a summary" can produce a two-sentence answer or a 500-word essay depending on phrasing. Output tokens usually dominate the bill for generative tasks.

Whether you're using tools or multi-step agents. Each tool call round-trip is a separate model invocation with its own input and output tokens. An agent that calls three tools before answering can burn 4x the tokens of a single-shot response.

Retry and error-handling overhead. Rate limit backoffs, malformed JSON retries, and speculative multi-model fallbacks all add token consumption that never shows up in the advertised per-token price.

A Practical Way to Estimate Real Cost

Instead of multiplying "expected requests × average tokens × price," instrument your actual usage. Most LLM APIs return token counts in the response metadata, so you can log real numbers instead of guessing.

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4-5",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Summarize this support ticket." }]
  })
});

const data = await response.json();
console.log(data.usage);
// { input_tokens: 142, output_tokens: 87 }

Log input_tokens and output_tokens per request, tag them by feature or endpoint, and you get a real cost breakdown by use case instead of a theoretical average. This is the single most useful thing you can do before scaling any LLM feature — it turns "we think this costs X" into "this endpoint costs $Y per 1,000 calls, and 80% of that is output tokens from long-form summaries."

Where the Bill Actually Goes Up

In practice, three patterns drive cost overruns that per-token pricing alone doesn't warn you about:

1. Unbounded conversation history. If you never truncate or summarize old turns, input token cost grows linearly with conversation length. A 50-turn support chat can cost 10x what the first turn cost.
2. Over-provisioned max_tokens. Setting a generous max_tokens doesn't cost anything by itself, but combined with verbose prompting it invites longer completions than needed.
3. Redundant system prompts. Sending a large system prompt or tool schema on every call adds up fast across high-volume endpoints. Prompt caching, where available, mitigates this.

Managing Token Cost at the API Layer

Once you're past the "is this even worth building" stage, the operational question becomes: how do you keep token spend visible and controlled without building your own metering system? Teams running Claude in production often use SubToAPI to turn their existing Claude access into a standard HTTPS API with per-key usage metadata, so every request's token consumption is visible without custom instrumentation. That's useful specifically because per-token pricing only becomes meaningful when you can see it broken down by team, feature, or environment — see the quickstart for how request and response shapes work, and the messages docs for the full usage object.

For teams issuing separate keys per environment or per product surface, that visibility replaces spreadsheet-based cost estimation with actual per-key numbers.

Questions

Is cost per token the same across all LLM providers? No. Rates vary significantly by provider and model tier, and input/output pricing ratios differ too. Always check current published rates rather than relying on cached numbers, since providers adjust pricing as models improve.

Does a longer context window cost more per token? The per-token rate itself doesn't change with context window size, but a larger window enables you to send more tokens per request, which increases total cost even though the unit price stays fixed.

How do I reduce LLM cost per token in production? You can't change the provider's rate, but you can reduce total spend by trimming conversation history, using prompt caching for repeated context, capping max_tokens appropriately, and choosing smaller models for tasks that don't need top-tier reasoning.