Claude Token Pricing Will Finally Make Sense After This

You've looked up Claude's prices, two dollars per million tokens in and ten dollars per million out, and you still can't say what your app will cost. So let's watch one real request. Ana runs a small coffee shop, Kettle & Bean, and her support assistant runs on Claude Sonnet 5.5. A customer, Priya, typed seventeen words. The request carried 1,781 tokens, and at API prices it cost zero point eight seven cents.

./ask --chat priya "Hi, my House Blend bag arrived torn and half the beans spilled. Order KB-20417. Can you help?"Hi there,

I'm so sorry your House Blend arrived torn with half the beans spilled. That's not the experience we want for you.

For order KB-20417, I can offer you either a free replacement bag or a full refund, whichever you prefer. There's no need to send the damaged bag back.

Just let me know which option you'd like, and if you'd like a replacement, whether you want it whole bean or ground (espresso, drip, or French press).

The Kettle & Bean team

turn 1: tokens in 1,781 (new 2 · cache write 1,779 · cache read 0) · out 154 · $0.0087

Three messages later, the conversation was longer, and the request cost a third as much. Stranger still, the feature that saves money made that first message cost more. By the end, you'll know why, and how to estimate a bill before you build anything.

You're not alone in this. On Hacker News, a developer building on Claude's API asked how anyone predicts costs before building: output length seems unknowable, and caching may or may not kick in. Both have answers, and you can work them out from four numbers.

So what is a token? Claude doesn't read letters or whole words. A tokenizer cuts your text into small pieces: a short word, part of a longer word, a number, a symbol, a space. The model reads those pieces and writes its answer as new ones. The price list counts both.

Before we count, take a guess: how many tokens is the shop's name, Kettle & Bean? Our tokens tool measures it, as Claude sees it inside a sentence. 8. A long word like unbelievably is 5, a seven-digit number 3, and a short line of code 8. Symbols and spaces count too.

./tokens "Hello" "Kettle & Bean" "unbelievably" "1234567" "def total(price, qty):""Hello"                    3 tokens
"Kettle & Bean"            8 tokens
"unbelievably"             5 tokens
"1234567"                  3 tokens
"def total(price, qty):"   8 tokens

Now the whole handbook Ana wrote for her assistant: 566 words came to 1,220 tokens. That's about two tokens per word, in our test. Don't lean on a rule of thumb, though. Anthropic says newer Claude models use a newer tokenizer that turns the same text into about thirty percent more tokens than older ones. So count your own text.

So why did Priya's seventeen words become 1,781 tokens? Because her message isn't all that gets sent. At the bottom is her message. Above it, Ana's whole handbook. And on top, the instructions of the tool sending it: our demo goes through Claude Code, which adds its own. Your own app would send its own instructions instead.

Here are the measurements. Priya's message: 38 tokens. The handbook: 1,220. And a nearly empty request still carries 546 tokens: almost all Claude Code's, about twenty from our counter's own prompt. Leave those twenty out, and the parts add up to the 1,781 on the bill, within a few tokens.

./tokens "Hi, my House Blend bag arrived torn and half the beans spilled. Order KB-20417. Can you help?""Hi, my House Blend bag arrived torn and half the beans spilled. Order KB-20417. Can you help?"  38 tokens

./tokens --file handbook.mdhandbook.md: 566 words, 3027 characters, 1220 tokens

./tokens --overheada near-empty request: 546 tokens in (Claude Code's own instructions, ~20 of them ours)

Why send the handbook every time? Because the model remembers nothing between requests. Each request has to carry everything the model needs: the instructions, the handbook, and the conversation so far. And the API counts every one of those tokens, every time.

Tokens in and tokens out have different prices. On Sonnet 5.5, input is two dollars per million tokens, output is ten: five times more. One reason: the model reads your whole input in one go, but writes its answer one token at a time, and every new token is another pass through the model.

Look at Priya's second message. The answer was 348 tokens, a small slice of the 1,958 going in. Most of that input was read cheaply from a cache, which we'll come to. But our bill tool shows that output was 63 percent of what the request cost. Long answers are where the money goes.

./bill sonnet-5.5 4 478 1476 348new input         4 x $ 2.00 per million = $0.00001
cache write     478 x $ 4.00 per million = $0.00191
cache read    1,476 x $ 0.10 per million = $0.00015
output          348 x $10.00 per million = $0.00348
total on sonnet-5.5:                       $0.00555
with no caching:                           $0.00740

So output is the first thing to control. Ask for short answers: Ana's handbook tells the assistant to stay under a hundred and twenty words. Set max_tokens, a hard cap on the answer in every API request. And if you turn on extended thinking, the thinking tokens are billed as output too.

Now the conversation. Priya's second message can't go alone, because the model wouldn't know what she means by a replacement. So Ana's app sends the handbook, her first message, the first answer, and then the new message. The third request carries all of that again, plus one more turn. Every message re-sends the whole chat.

Here are Priya's next three messages, each with its bill line. Tokens in: 1,958, 2,338, 2,483. Up every turn, because every turn carries all the turns before it.

./ask --chat priya "A replacement, please. Could you make it Night Owl instead?"Happy to pass that along. Swapping to a different coffee than the one that was damaged isn't something I can confirm myself, so a person from the shop will reply within one working day to confirm the Night Owl replacement for order KB-20417.

To save time, please tell me whether you'd like it whole bean or ground (espresso, drip, or French press), and I'll include that in your request.

The Kettle & Bean team

turn 2: tokens in 1,958 (new 4 · cache write 478 · cache read 1,476) · out 348 · $0.0055

./ask --chat priya "Thanks! Also, do you ship to Canada? My sister lives in Toronto."Yes, we ship to Canada! It's a $12 flat rate, and delivery takes 5 to 10 working days. If there are any customs fees, the customer pays those. You'll get a tracking number by email once the order ships.

Just so I can pass along your replacement request, would you like the Night Owl whole bean or ground (espresso, drip, or French press)?

The Kettle & Bean team

turn 3: tokens in 2,338 (new 4 · cache write 380 · cache read 1,954) · out 129 · $0.0030

./ask --chat priya "Great. How do subscriptions work?"Subscriptions are simple:

- Any of our coffees can be a subscription, delivered every 2, 3 or 4 weeks.
- Subscribers save 10% on every bag and get free shipping within the United States.
- You can skip, pause or cancel any time from your account page, up to two days before the next roast.

Since your sister is in Toronto, I'd note that the free shipping applies to U.S. orders. A person from the shop can confirm how a subscription would work for Canada, and I can pass that question along if you'd like.

Also, don't forget to let me know whole bean or ground for your Night Owl replacement.

The Kettle & Bean team

turn 4: tokens in 2,483 (new 4 · cache write 145 · cache read 2,334) · out 212 · $0.0029

Message one carried 1,781 tokens; message four, 2,483. Without anything else, every message would cost more than the one before. A long chat, or an agent that makes dozens of requests for one job, gets expensive this way. Yet the bill went down. Here's why.

Look at what repeats. Every request starts the same way: the same instructions, the same handbook, the same chat so far. Only the end is new. Prompt caching lets the API keep that repeated start, the prefix, for a while. When the next request begins with the exact same prefix, the API reads it from the cache, at a fraction of the price.

There's a twist: the cache has its own prices. Writing to it costs more than plain input: a quarter more for the default five-minute cache, or double for a one-hour cache, which is the kind Claude Code asks for. Reading from it is cheap: for Sonnet 5.5, a twentieth of the input price, ten cents per million tokens.

So a bill line splits the input three ways. Here's message four. New: 4 tokens at the plain price. Cache write: 145 tokens, the newest turn, saved for next time. Cache read: 2,334 tokens, everything that came before, at the cheap rate.

Our bill tool prices message four both ways. With caching: zero point two nine cents. Without it, the same tokens at plain prices: zero point seven one cents. Caching cut this request by 59 percent.

./bill sonnet-5.5 4 145 2334 212new input         4 x $ 2.00 per million = $0.00001
cache write     145 x $ 4.00 per million = $0.00058
cache read    2,334 x $ 0.10 per million = $0.00023
output          212 x $10.00 per million = $0.00212
total on sonnet-5.5:                       $0.00294
with no caching:                           $0.00709

And now the strange part from the start. Message one found an empty cache, so all 1,779 of its tokens were written to it, at double the input price. With caching, it cost zero point eight seven cents. Without caching, it would have cost zero point five one cents. Caching only pays when something reads what you wrote. Here, from message two on, it did.

./bill sonnet-5.5 2 1779 0 154new input         2 x $ 2.00 per million = $0.00000
cache write   1,779 x $ 4.00 per million = $0.00712
cache read        0 x $ 0.10 per million = $0.00000
output          154 x $10.00 per million = $0.00154
total on sonnet-5.5:                       $0.00866
with no caching:                           $0.00510

Real products lean on this. Anthropic's own write-up on prompt caching names Notion, which was adding it to Notion AI. In Anthropic's test, a ten-turn chat with a long system prompt cost fifty-three percent less. Our four-message chat saved 59 percent on its last message.

One more thing the cache does. A different customer starts a brand new chat and asks if the shop ships to Canada. Cache read: 1,260 tokens, on her very first message. The cache isn't tied to one conversation. Any request that starts with the same instructions and handbook can read them, so every customer shares one copy.

./ask "Do you ship to Canada?"Yes, we do ship to Canada! Here's how it works:

- **Cost:** $12 flat rate
- **Delivery time:** 5 to 10 working days
- **Customs:** Any customs fees are paid by the customer
- **Tracking:** You'll get a tracking number by email as soon as your order ships

Coffee ships within two days of roasting, so it arrives fresh. Let us know if you'd like help choosing a blend!

The Kettle & Bean team

tokens in 1,753 (new 2 · cache write 491 · cache read 1,260) · out 157 · $0.0037

Three rules decide whether you get those reads. The cache lasts five minutes by default, and each read restarts the clock. On these models, a prefix shorter than 512 tokens isn't cached at all. And the prefix must match exactly, so put whatever changes, like the date or the user's name, at the end, not the top.

Caching isn't the only way to save. The biggest saving is the model. Say Ana's assistant answers six thousand first messages like Priya's in a month. On Sonnet 5.5 that's about thirty-one dollars, on Opus 5.5 about sixty-one dollars, and on Haiku 5.5, one dollar fifty-three. Try the smallest model that does the job well.

Second lever: wait. The Batch API takes a pile of requests and answers them within twenty-four hours, at half price. The same month on Sonnet drops from about thirty-one dollars to about fifteen dollars. Useless for a live chat, but right for jobs that can wait, like sorting yesterday's emails overnight.

./bill --month 6000 sonnet-5.5 1781 1546,000 requests on sonnet-5.5, 1,781 tokens in and 154 out each:
  standard    $   30.61
  Batch API   $   15.31   (half price, answers within 24 hours)

Third, watch very long prompts. Sonnet and Opus 5.5 charge the same price all the way to a million tokens. Haiku 5.5 doesn't: once a prompt passes a hundred thousand tokens, that request pays five times the price, for input and output alike.

So here's how to estimate before you build. Count your fixed instructions once. Add a typical message and a typical answer. Add the history each turn carries. Price the repeated part at the cache rate. Then multiply by how many you expect. Our token counter and cost calculator, with every command, are linked in the description.

Ana's real numbers: Priya's whole four-message chat cost two point zero two cents. At one thousand five hundred chats like hers a month, that's about thirty dollars. Without caching, about thirty-eight dollars. Now you can answer that Hacker News question for your own app: the output and the caching are just two more numbers in the sum.

To recap. You pay for every token in and out, and output costs five times more. Every request re-sends everything, so chats grow. Caching makes the repeated part cheap, after one write that costs extra.

If your next Claude bill makes more sense now, subscribing helps a small channel make the next one.

Every token count and price here came from a real run on our own laptop. Thanks for watching Cloud Explainers.

Sources

• Claude API pricing (models, cache writes and reads, Batch API, long context)
• Prompt caching (lifetime, 1-hour cache, minimum length, prefix matching)
• Token counting (newer tokenizer, about 30% more tokens)
• Prompt caching with Claude (Notion, multi-turn test)
• The Hacker News question about estimating API costs
• Claude pricing page