Claude API Token Cost Per Request Explained

Every Claude API request costs money based on two numbers: how many tokens you send (input) and how many tokens Claude generates back (output). The total cost of a single request is (input tokens ÷ 1,000,000 × input price) + (output tokens ÷ 1,000,000 × output price). Input and output tokens are billed at different rates, output is always more expensive per token, and that asymmetry is the single most important thing to understand before you estimate costs for any real workload.

This article breaks down exactly what counts as a token, how pricing differs by model, how to calculate the cost of a specific request before and after you send it, and where hidden token costs sneak into your bill.

What actually counts as a token

A token is roughly 3-4 characters of English text, not a word. Claude's tokenizer splits text into subword pieces, so "subtoapi" might become two or three tokens while "the" is one. Numbers, punctuation, and whitespace all consume tokens too. As a rough rule of thumb:

• 1 token ≈ 0.75 words in English
• 100 tokens ≈ 75 words
• 1,000 tokens ≈ a page of single-spaced text

Code, JSON, and non-English text tokenize less efficiently than plain English prose, often 1.3-1.5x more tokens for the same character count. If your requests are mostly structured data (logs, JSON payloads, code diffs), budget for higher token counts than a word-count estimate would suggest.

What counts as input vs output tokens

Input tokens include everything you send in a request:

• The system prompt
• All prior messages in the conversation history (every turn, every time)
• Any documents, PDFs, or images attached
• Tool definitions and tool results you pass back in

Output tokens are only what Claude generates in its response, including any tool-use JSON it produces. The critical detail that trips people up: in multi-turn conversations, you resend the entire history on every request, so your input token count grows with every turn even if the new message is one sentence. A 10-turn conversation with 2,000 tokens of accumulated history costs you 2,000 input tokens on turn 11 even if you only typed "yes, continue."

How to calculate the cost of a request

The formula is simple once you have token counts and the per-model rate:

cost = (input_tokens / 1_000_000) * input_price_per_million
     + (output_tokens / 1_000_000) * output_price_per_million

Example: a request with 3,000 input tokens and 500 output tokens against a model priced at $3 per million input tokens and $15 per million output tokens:

input_cost  = (3000 / 1_000_000) * 3   = $0.009
output_cost = (500 / 1_000_000) * 15   = $0.0075
total       = $0.0165

That's under two cents, but it compounds fast. Run that same shape of request 10,000 times a month and you're at $165/month just for one feature. The lesson: estimate per-request cost early, then multiply by realistic monthly volume before you ship.

Where token counts come from in practice

You don't have to guess. Every Claude API response includes usage metadata with exact input and output token counts for that specific request, so you can log real costs instead of estimating them. If you're building on top of Claude through SubToAPI, this usage data is surfaced per request in the dashboard and in the API response itself, which makes it straightforward to track cost per endpoint, per customer, or per feature without building your own token-counting logic. See the docs on messages for the exact response shape.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 500,
    "messages": [{"role": "user", "content": "Summarize this ticket in two sentences."}]
  }'

The response includes a usage object with input_tokens and output_tokens. Multiply those by your model's published rates and you have the exact cost of that one call — no estimation required.

Factors that inflate cost per request

A few patterns consistently drive token costs higher than developers expect:

• Long system prompts repeated on every call. A 1,500-token system prompt sent on 50,000 requests/month is 75 million input tokens before a single user message is counted.
• Unbounded conversation history. Without trimming or summarizing old turns, input tokens grow linearly with conversation length.
• Verbose tool schemas and tool results. Returning large JSON blobs from tool calls adds directly to input tokens on the next turn. See tool use for schema design that keeps payloads lean.
• max_tokens set too high. You're not charged for tokens you don't generate, but a model with no natural stopping point and a high max_tokens ceiling can run longer (and cost more) than a tightly scoped prompt.
• Streaming vs non-streaming doesn't change total token cost — it's the same input/output tokens either way — but streaming (see streaming docs) improves perceived latency, which matters for UX even though it's billing-neutral.

Practical ways to control per-request cost

• Trim or summarize conversation history instead of resending full transcripts indefinitely.
• Keep system prompts as short as the task allows; move rarely-needed instructions into examples only when relevant.
• Set max_tokens close to what the task actually needs rather than a generous default.
• Log usage data from every response and aggregate it by feature or customer so you catch cost regressions before they show up on an invoice.
• If you're prototyping or running a small team, check pricing for a flat per-seat plan (Solo at €9, Team at €19/seat, Scale at €49/seat) so you're budgeting predictably instead of purely on usage. Start with a free trial at signup to see real token usage on your own workload before committing.

Understanding cost per request isn't about memorizing a price sheet — it's about knowing which parts of your prompt structure (history, system prompt, tool payloads) scale with usage and which don't. Once you're logging real input_tokens and output_tokens per call, cost stops being a guess and becomes a number you can actually optimize.

Questions

Does Claude charge the same price for input and output tokens? No. Output tokens are consistently priced higher than input tokens, often 4-5x, because generation is more compute-intensive than processing input. Always estimate the two separately.

Why did my cost per request go up without changing my prompt? Most likely conversation history growth. If you resend full chat history each turn, input tokens — and therefore cost — increase every turn even when your new message is short.

How do I know the exact token count before sending a request? You can estimate with a tokenizer library, but the only exact count comes back in the response usage field after the call completes. Log it to track real costs over time rather than relying on estimates.