Unofficial. Not affiliated with or endorsed by Anthropic. QuotaLens uses undocumented claude.ai endpoints and only observes: it cannot raise, extend, or bypass a limit.
Claude Pro and Max meter usage in five-hour session windows, with a weekly limit on top. The in-app view shows you the current state: how much of the window remains, when it resets. What it doesn’t show you is history.
When a session window ended unexpectedly, I had no way to tell which hour the usage was heaviest, whether a particular kind of work was consistently expensive, or whether the pattern was predictable enough to plan around. The snapshot told me where I was. It couldn’t tell me how I got there or what the trajectory looked like.
I use Claude Code heavily — for platform engineering work, for drafting, for working through architecture decisions. When the window ends mid-task, the options are to stop or to wait for the reset. Neither is a problem when I can see it coming. Both are disruptive when I can’t.
What I wanted
The thing I wanted was simple: a local record of my quota over time. Not sent anywhere, not stored in a service I don’t control — just a SQLite file on my own machine that accumulated the series the in-app view threw away.
With the series, the questions become answerable: burn rate over the current window, forecast for when the window will exhaust at the current rate, a weekly table that translates the abstract limit into something plannable.
I also wanted a dashboard that led with the question I actually opened it to ask: “will this window run out before it resets, and when?” Not a chart I had to interpret — a direct answer with the reasoning behind it.
What I built
QuotaLens polls your Claude account every minute and writes each reading to a local SQLite file. The data is yours — readable, queryable, exportable. Nothing is sent anywhere except the request to your own Claude account, and an optional status-page check you can turn off (details below).
The dashboard answers the burn-rate question directly: headroom percentage, countdown to reset, burn rate for the current window. There’s a weekly budget table that converts the abstract quota into “full sessions remaining at your typical session cost” — a number that’s easier to plan against than a percentage.
For integrations: there’s a Prometheus /metrics endpoint and CSV/JSON export if you want to pull it into existing monitoring. There’s a burn-rate webhook — one POST when the rate crosses a configurable threshold, one when it falls back — that feeds ntfy, Slack, Discord, Pushover, and Home Assistant out of the box.
Privacy was a hard constraint from the start. QuotaLens binds loopback only. The session cookie stays in the OS keychain, never in a file or a log line. The only outbound traffic beyond your own Claude account is one plain GET per vendor status page every five minutes — no identifier, no cookie — and that’s configurable off.
Why open source
I built it for my own workflow. Once it was stable enough that it solved the problem reliably, open source was the obvious choice. The tool is only valuable if it works on your setup, and that means the code needs to be readable — both so you can trust it’s doing what it says, and so it can work on configurations I haven’t tested.
It’s MIT licensed. v1.0 is on PyPI: pipx install quotalens. macOS, Linux, and Windows are tested in CI on Python 3.11 and 3.13.
- Site and install guide: quotalens.com
- Source: github.com/amitshcc/quotalens
What it doesn’t do
QuotaLens is an observer. It reads the quota state. It can’t raise the limit, extend the window, or bypass a constraint. And because it uses undocumented endpoints, the interface can change without notice — that’s the tradeoff of building on something unofficial.
The tool solves a narrow problem: making a quota observable that wasn’t observable before. If that problem is one you have, it’s worth trying. If you want something that affects the limit itself, that’s not what this is.
QuotaLens is unofficial and not affiliated with or endorsed by Anthropic.