Logging Your Own Rate-Limit History (Since Claude Code Won't)
Claude Code's status line will tell you you're at 73% of your 5-hour window. What it won't tell you is whether you got there gradually over four hours, or in the ten minutes after you dumped a huge file into context. That distinction matters more than the number itself. A slow drain means you can k
Claude Code's status line will tell you you're at 73% of your 5-hour window. What it won't tell you is whether you got there gradually over four hours, or in the ten minutes after you dumped a huge file into context. That distinction matters more than the number itself.
A slow drain means you can keep working and watch it. A sharp spike means something in your workflow is burning quota fast, and you won't know what unless you were staring at the screen when it happened. The problem is structural, not a bug: the percentage Claude Code reports is a live reading with no memory.
The moment it updates, the previous value is gone. There's no file, no log, nothing to look back on after the fact. We ran into this building Estela, the open-source tool we're building to reconstruct billable hours from your coding agent sessions, so in the latest version we started keeping that history ourselves.
It's a plain local log, ~/.estela/rate-limits.jsonl, one line per sample. The sampling is deliberately sparse: at most once every 5 minutes, unless the percentage moves by at least a point or a new reset window starts - no point logging the same number forty times an hour. Entries older than 120 days get pruned automatically.
Each line stores exactly three things: the percentage, its reset time, and the Claude Code version that reported it. No session content, no file paths, no project names, and nothing leaves your machine. One limitation worth being upfront about: Claude Code's own transcripts don't carry these percentages, so there's no way to reconstruct history retroactively.
The log starts the day you update. Small related note if you rely on it: the status line only renders in Claude Code's terminal - the VS Code extension doesn't show it at all. We're not shipping an analysis view on top of this yet - that's a line we're exploring, not a feature that exists today - but the log is there now, in case you want to query it yourself before we do.
Repo, if you're curious how it's wired: github.com/jdleonruiz/estela-cli Do you track your own rate-limit usage over time, or only find out the shape of it after you've already hit the wall?