Anthropic Cost Tracking: Build a Claude Usage Logger in Python Anthropic cost tracking is a small wrapper around your Claude API calls that records, for every single request, how many fresh input tokens you sent, how many tokens you paid to write into the prompt cache, how many you read back from it, how many output tokens the model produced, and what that request cost under the rates you configure. Put it between your code and the Anthropic client, log one line per call to a file, and the next time a number on the Claude Console looks wrong, you can point at the exact feature, user, or prompt that produced it. If you already built the OpenAI version of this wrapper , this is its Claude twin — the same sixty-line shape, but the usage object it reads is different in exactly the way that makes Claude bills confusing. That difference is the whole reason this tutorial exists. OpenAI reports one prompt-token count and tells you how many of those tokens were cached. Claude reports three se...

Cache Write Pricing: The Surcharge You Pay Before Prompt Caching Saves You Anything Prompt caching is sold as a 90% discount, and the discount is real — but it is the second price on the bill, not the first. Before a single cached token is read back at the cheap rate, the provider charges you to write the cache, at 1.25 times the normal input price for a short-lived cache and two to two-and-a-half times for a long-lived one. If the cached prompt is never read again, or only after the cache has expired, you paid more than if you had never turned caching on at all. The discount is real. So is the entry fee. Caching has two prices, not one Every caching story quotes the read price: cached tokens at a tenth, or a twentieth, of the standard input rate. Almost nobody quotes the write price — it sits in a different column of the pricing page. The first time you send a prompt, the provider processes it at the normal input rate and stores the result — and that storage step is billed separat...

Reasoning Tokens: The Invisible Output Tokens Eating Your OpenAI Bill Here is the direct answer: when you call one of OpenAI's reasoning models, the model thinks before it answers, and that thinking is billed as output tokens — even though you never see a single one of those tokens. OpenAI's own reasoning guide says it plainly: reasoning tokens are not visible via the API, they still occupy space in the model's context window, and they are billed as output tokens. If your bill for a reasoning model looks far too high for the short answers you received, this is almost certainly why. You were not charged for the answer. You were charged for the thinking that produced it, at the most expensive rate on the price list. The bill that does not add up OpenAI's reasoning guide contains a small usage example that explains more about real bills than most pricing pages do. A request sends 75 input tokens and gets back 1,186 output tokens. That already looks odd for a short answ...

AI API Pricing Is Broken: Per-Token Billing Charges You for the Wrong Thing Per-token pricing is the wrong unit for AI APIs. It charges you for effort, not for results — for every token a model burns on the way to an answer, including the tokens you never see, the retries that failed, and the words a rambling answer didn't need. The fix is not a cheaper token. It is a different unit: price per finished task, not per token spent getting there. That sounds like a small accounting complaint. It isn't. The unit you pay by decides what you optimise for, what you fear, and what your provider is rewarded for. Right now, all three point the wrong way. You pay for the journey, not the arrival Think of a taxi ride. You pay for arriving, with the meter as a rough proxy for distance. Now imagine a taxi that charged per turn of the wheels — extra when the driver took a wrong turn, circled the block, or sat thinking at a junction with the engine running. That is how an AI API bill works...

Stop One User From Eating Your AI Budget: Build a Per-User Spending Guard in Python Logging tells you what happened. It does not stop anything. Our last tutorial built a logging wrapper that records every call's price — and that wrapper is the right first step, because you cannot control spending you cannot see. But sooner or later every developer with a public-facing AI feature hits the next problem: one user, one script, or one runaway loop spends in a weekend what the rest of your users spend in a month, and you only find out from the invoice. This tutorial builds the second half: a spending guard that sits in front of your API calls and refuses a call before it is made, when the user behind it is already over budget. It is about two hundred lines of Python, it uses only the standard library, and it stores its data in a small SQLite file you can inspect with any database tool. There is no new service to run, no dashboard to learn, and no pricing data to trust: you supply the ...