We use cookies for analytics and personalized ads. We use cookies for basic analytics and, where we show ads, to personalize them. Privacy PolicyRead our Privacy Policy.
Estimate Fable 5.1, Opus 5, Sonnet 5, or Haiku 4.5, model your real cache-hit rate plus actual cache-write cost, and layer on the Batch API discount — all in one Claude token calculator.
This tool exists because "tokens" in Claude get used to mean two different things. On the Claude API, a token is a billing unit — input tokens, output tokens, and cache tokens each carry their own rate, and this calculator turns those into a real dollar-per-request and dollar-per-month number for any of the four current Claude models. On Claude.ai's Pro and Max plans, "how many tokens do I have left" instead means a usage allowance that resets on a rolling window, not a per-token API bill. Whichever question brought you here, the sections below cover both: what a Claude token actually is, how Claude API pricing is structured for each model, and how Claude Pro's usage limits work differently from API billing.
Count Tokens LocallyRequest cost = cache-miss input + cache-read input + output — plus a cache write if this call creates a new cache entry, and half of all of that on the Batch API. Most calculators quote only the headline input/output rate. This one models the three levers that actually move a Claude bill in production, together in one place.
Set your request shape once — all four models update instantly below.
Sonnet 5 is priced at $2 / $10 per million tokens, permanently. Anthropic cancelled the increase to $3 / $15 that was originally planned for 1 Sep 2026 — the introductory rate is now the standard rate, not a temporary window.
How much of your input matches a prefix already sitting in the prompt cache — system prompt, tool schemas, a long document, or earlier turns.
At this request shape, Haiku is about 80% cheaper than Opus ($81.13 vs $405.63 per month). Worth paying up for Opus or Fable only where an evaluation shows Haiku or Sonnet genuinely falling short on this task.
Same request shape as above, sorted cheapest to priciest.
Covers standard text input, cache reads/writes at the toggles set above, and generated output only — not tool-use system-prompt overhead or images.
A token is the unit Claude actually reads and writes in — not a word, and not a character. Anthropic's tokenizer breaks text into sub-word pieces, so a single English word can be one token or several depending on how common it is, and the same is true in reverse for punctuation, whitespace, and code syntax. Every Claude model prices its work in these tokens, split into two directions:
Everything sent to Claude on a call — the system prompt, the conversation history, any documents, tool definitions, and the user's message. Input tokens are what a Claude token calculator counts first, because on a long-context workflow they usually dominate the bill.
Everything Claude generates in response, including any extended-thinking reasoning tokens that never reach the visible answer. Output is priced well above input on every Claude tier, so a small number of unusually long responses can dominate a monthly bill even when most requests look cheap.
As a rough rule of thumb, one token is close to four characters or three-quarters of a word in English — but that ratio drifts for other languages, dense code, and structured data, and it changed again with the newer tokenizer that Claude 4.7 and later models — including Sonnet 5 and Fable 5.1 — use, which can produce roughly 30% more tokens for identical text than older Claude models. That's exactly why a hard production limit should be checked against Anthropic's official token-counting endpoint for the specific model in use, rather than assumed from an older model's count or a generic word-count estimate.
Begin with the least expensive model that might plausibly pass your evaluation, and move up only when the result is measurably better for the specific task — not because a newer or larger name feels safer to default to.
A document review request can include a system prompt, the source document, a rubric, prior turns, tool definitions, and a long answer — measure each piece separately before deciding whether the whole document belongs in every call.
New content processed at the standard input rate — anything that doesn't match a live cache entry, including the first time any prompt is ever sent.
Example: A document-review agent that pastes a different 40-page report on every call gets no caching benefit at all, no matter how similar the prompts look structurally.
Trap: Assuming a prompt 'looks cacheable' is the same as it actually matching a live entry — a single upstream edit to a shared system prompt invalidates the match for everyone using it.
The portion of input matching a previously written cache entry, billed at roughly a tenth of standard input — the single largest lever most teams underuse.
Example: A coding agent with a fixed 8,000-token repository summary can push most of that context into cache-read pricing across a long session.
Trap: Not accounting for the 5-minute default TTL — a cache entry that goes cold between calls has to be rewritten, paying the write premium again.
Creating a new cacheable entry costs more than standard input, not less: 1.25x for a 5-minute entry, 2x for a 1-hour entry. It's an upfront cost that only pays off across enough subsequent reads.
Example: Writing a 1-hour cache entry for a 20,000-token system prompt costs double on that first call, but pays back quickly if dozens of requests read it within the hour.
Trap: Treating caching as pure savings and forgetting the write premium exists — a workload with very few repeat reads can end up more expensive with caching turned on.
Output is priced well above input on every Claude tier, and thinking-mode reasoning tokens count as output the same as the visible answer.
Example: A 1,200-token document summary on Opus costs more from output alone than the 45,000-token source document would on Haiku.
Trap: Leaving output length uncapped, so a small share of unusually long responses ends up dominating the average monthly bill.
Send routine classification and extraction to Haiku, keep Sonnet as the general default, and reserve Fable or Opus for requests that prove they need it.
Prompt caching helps when the same large instructions or documents appear across requests — include the write cost and TTL choice in the business case, not just the read discount.
The Batch API's flat 50% discount can change the economics of evaluations, classification runs, and offline document processing that don't need an immediate response.
"How many tokens do I have left on Claude?" usually means one of two very different questions, and mixing them up leads to the wrong answer either way.
A flat subscription with a usage allowance that resets on a rolling window, not a per-token invoice. Anthropic doesn't publish an exact token count for this allowance because it scales with which model you're chatting with and how long your conversation has grown — a single long chat with a large model consumes the allowance faster than several short ones.
To check how much of your Claude Pro allowance is left, look at the usage indicator inside the Claude.ai app itself — this calculator, and every third-party tool like it, has no visibility into a Claude.ai account's remaining usage. Anthropic's support site is the accurate source for current plan limits.
Pay-as-you-go billing in USD per million tokens, metered exactly, with no rolling allowance to run out of — a request either fits your account's rate limit or it doesn't, and every token is billed at the published per-model rate.
This is the system the calculator above models: set an input/output shape and monthly request volume, and it prices that exactly against Haiku 4.5, Sonnet 5, Opus 5, and Fable 5.1's current published rates.
If you're building a product or an internal tool on top of Claude, the API and its per-token pricing above is the relevant system. If you're a Claude.ai subscriber wondering why a conversation slowed down or got capped, that's the Pro or Max usage allowance, and the fix is checking the in-app usage indicator or Anthropic's own support documentation rather than a token calculator.
A support triage system sends a fixed 900-token classification rubric plus a 600-token ticket on every call, generating a 200-token category and summary on Haiku 4.5. The rubric hits the cache about 65% of the time across a shift, with no cache write modeled and no Batch discount, running 80,000 times a month.
Switching this same shape to Sonnet 5 would run roughly $259.60/month — about double Haiku's cost, for a task a fixed-rubric classifier rarely needs the extra capability for. That gap is the entire argument for routing by difficulty rather than defaulting every request to the more capable model.
Keep the source document separate from the expected answer in your estimate. If the document rarely changes, evaluate prompt caching instead of resending it at the ordinary input rate on every call.
Repository context, tool results, patches, and conversation history accumulate quickly across a session. Summarizing stale turns and sending only the files the next step genuinely needs keeps input cost from growing unbounded.
An agent that loops through tools can multiply both input context and output far faster than a single chat request — budget for the full loop, not just the opening prompt.
Anthropic's Fast Mode offers premium-speed inference on top-tier models at a higher per-token rate than standard throughput — a genuinely different tradeoff from tier or caching choices.
Drop the calculator into your own docs or internal wiki with a single iframe. The embedded version keeps a small credit link back to Apex Tech Journal.
<iframe
src="https://apextechjournal.com/embed/claude-token-calculator?ref=widget"
width="100%"
height="440"
style="border:0;border-radius:12px;"
loading="lazy"
title="Claude Token Calculator by Apex Tech Journal"
></iframe>