Rate-Limit-Infos stecken bereits in den Logs von Claude Code

When Claude Code hits a rate limit, it doesn't just show you a banner and move on. It writes the full rate-limit response into your own session transcript — which window got hit, and exactly when it resets. Most people never look at that line again.

We ran into this building estela plan, a command that tells you whether your Claude subscription (Pro, Max 5x, Max 20x) actually fits how you work. The obvious way to answer that is to start sampling your usage percentage going forward — which is what we shipped first, in 0.2.4: the status line already reports a 5-hour and a 7-day percentage, so we log it locally every few minutes. But that only gives you data from the day you installed it.

The real question — has this plan been blocking me — needs history, and we assumed there was none to recover.

Every time a request comes back as a 429, or Claude Code marks it rejected, it writes a quotaLimits block into the JSONL transcript: the window type ( five_hour or seven_day ) and the timestamp it resets at. That's an official record from the tool itself, sitting on disk since before we wrote a single line of estela plan. So the hard part wasn't finding the data. It was reading it safely.

A month of transcripts can run into hundreds of megabytes, across dozens of files that keep growing while Claude Code is running. Re-parsing everything on every check was never going to work, so the scanner keeps a byte offset per file and only reads what's new since last time. The detail that actually mattered: it never trusts the last line of what it just read.

It cuts at the last complete newline and remembers that exact byte position, so a line that's half-written when we read it gets picked up whole on the next pass, instead of failing to parse, or worse, parsing a truncated JSON object into garbage. Matching is intentionally narrow: it only even attempts to parse a line if it contains the literal string quotaLimits, then checks that the window type is one of the two valid values, the reset timestamp is a real number, and the status actually indicates a block. Anything else, a malformed or partial line, is skipped, not guessed at.

The plan prices and session multipliers Anthropic publishes are hardcoded in one small file, on purpose, with the exact date they were last checked against claude.com/pricing next to them. If that date is more than 90 days old, estela plan says so instead of quietly showing a number that might not be true anymore. Anthropic doesn't publish how the weekly limit compares across plans at all, so that comparison is simply left out rather than estimated.

Before you build a new logging layer on top of a tool, it's worth checking what that tool already wrote down when it failed. In this case, the monitoring we thought we had to start from zero already existed, as a side effect of Claude Code just doing its job honestly when it rejected a request. estela plan is open source, part of the Estela CLI: github.com/jdleonruiz/estela-cli Have you found a case where the tool you were trying to monitor had already logged exactly what you needed?