Usage tracker

Why this stays entirely in your browser

Log your usage manually as you go, or paste the usage block Claude's API returns with every response, and this tool tracks burn rate, a projected month-end spend, and a read on your cache-hit ratio over time. Everything you enter is kept in your browser's local storage — nothing you type or paste here is transmitted anywhere. That's not a caveat tacked onto the feature list; it's the actual design constraint the tool was built around. A usage tracker that asks you to send your request volume and spend to a third-party server to track it "privately" has already failed at the one thing that made tracking it worth doing yourself in the first place.

What burn rate and projection actually catch

A single request's cost tells you almost nothing about whether your monthly spend is on track — a burn-rate view does. Logging usage over even a few days lets this tool project where the month lands at the current rate, which surfaces problems while there's still time to act on them: a prompt that grew unnoticed over several iterations, a retry loop quietly multiplying request volume, a model swap that changed the per-token rate without anyone re-checking the bill. Waiting for the actual invoice to notice any of these means the spend already happened.

Reading your own cache-hit ratio

If you've enabled prompt caching, the usage block your requests return already contains what you need to know whether it's working: how many tokens came from a cache read versus how many were billed as a fresh, standard read. Pasted in here over a run of requests, this tool turns that into a hit ratio over time rather than a one-off number from a single response — which matters because a cache that worked on your first few requests can silently stop working later if something in your request pattern changed, and a single response's usage block won't show you that trend.

What a falling hit ratio usually means

A cache-hit ratio that starts strong and then drifts down over a session is rarely random. The most common causes are a prefix that grew past a TTL window between requests, a piece of dynamic content — a timestamp, a session id, a request id — that quietly ended up earlier in the prompt than intended, or a switch in which model is handling requests, since caches don't carry across models. If your tracked ratio here doesn't match what you expected from your setup, that's the order worth checking them in.

Pairing this with the rest of the site

A tracker tells you what already happened; the prompt-caching savings calculator tells you what should happen for your request pattern before you build it. Run a pattern through that tool first, then use this one to confirm the real numbers match what you designed for.