Claude Pacer: a menu-bar that says if your Claude session will last till reset

What happened

Good, I now have all the concrete facts from the README. Let me write the article.

---

Claude Pacer: a menu-bar that says if your Claude session will last till reset

A developer going by dkremsa published Claude Pacer, a small open-source macOS menu-bar application that answers one specific question: at the speed you are currently using Claude, will your subscription hold out until the next reset? The project lives at github.com/dkremsa/claude-pacer and is licensed under MIT. It surfaced on Hacker News with one point and one comment.

How it works

This piece explains what Claude Pacer does, how its pace calculation works, what the tool requires to run, and whether it is worth a builder's attention. It is aimed at developers and teams on Claude Pro, Max, or Team plans who run Claude Code heavily enough that hitting a rate limit mid-week is a real operational risk.

What happened

Developer dkremsa released Claude Pacer, a macOS menu-bar tool that shows a single projected number — the percentage of your Claude subscription limit you will have consumed by reset time if you keep using it at your current rate. The headline number is the worst of three tracked windows: the five-hour session, the week, and a Fable-specific week. A sample display from the README shows "Week 16% used, 133 at reset" alongside advice to use Fable about 58% less and an API-equivalent cost estimate of $62 for the day and $410 for the week. Those figures come from actual usage data, not invented defaults.

The tool is published under an MIT license, requires macOS 13 or later, Node 18 or later, Xcode Command Line Tools, and an active Claude Code login. It can be installed via a Homebrew tap at dkremsa/tap/claude-pacer or cloned directly from the repository and built with a single shell script. The compiled application lands in /Applications and a launchd agent runs in the background, polling usage every ten minutes and surviving reboots without user intervention.

Why it matters

How it works

Claude Pacer separates into two parts: a Node script called pacer.mjs with no external dependencies, and a single Swift file that renders the menu-bar icon and dropdown. The Node script calls the same /usage endpoint that Claude Code's built-in usage command reads, then projects forward using the formula "projected = used percentage divided by the fraction of the window already elapsed." For the five-hour session window it uses only the last 45 minutes of data rather than the full session average, because session usage is bursty and a whole-session average lags too far behind reality. The worst projected figure across all windows becomes the menu-bar headline.

Per-model weights — how much Opus, Sonnet, or Fable usage actually counts against the shared limit — are not published by Anthropic. Pacer estimates them by joining the official usage percentage Anthropic does expose with local Claude Code transcript data and fitting the weights from the combined dataset. Until enough data accumulates it falls back to API price ratios as a proxy. The output is written to ~/.claude/pacer/status.json every ten minutes, with fields for pace, level, advice, an array of windows, cost, and fit, making it readable by any other tool that knows where to look.

Why it matters

Who is affected

The percentage-used figure that most monitoring tools show is missing context: 16% used sounds safe until you realize you are only 10% of the way through the week. Claude Pacer reframes the same data as a trajectory rather than a snapshot. The color coding reinforces this: green for projections at or below 80, amber from 81 to 100, red above 100. Notifications fire when the pace crosses 100, when it drops back below, and when any individual window passes 90 percent, so a developer who is deep in a coding session gets an interrupt before running dry rather than discovering the limit after the fact.

The API-equivalent cost line — $62 on the day, $410 on the week in the README's example — gives teams a concrete way to assess whether a flat subscription is cheaper than pay-per-token usage for their workload. That figure is derived from your actual model mix, weighted by the same fitted coefficients the pace calculation uses. Nothing is sent off the machine: the tool reads local files and the Anthropic usage endpoint, then does all arithmetic locally.

Who is affected

Claude Pacer is relevant to anyone on a Claude Pro, Max, or Team plan who uses Claude Code as a primary development tool. The README explicitly states it works on those three plan types and covers Claude only. Developers running long autonomous coding sessions with Fable — the model that appears in the sample output with its own tracked weekly window — are the most exposed to unexpected limits, since Fable usage is counted separately and the tool surfaces that as a distinct advisory. Teams that share a subscription and have variable daily load across members are similarly at risk of running one member's aggressive usage into another's blocked afternoon.

What to watch next

Builders integrating Claude Code into CI pipelines or automated agents face a different version of the same problem: a pipeline that hits a limit at 2 a.m. produces a confusing failure rather than a clear rate-limit error. Claude Pacer's status.json output, refreshed every ten minutes, is machine-readable, which means a pipeline or a sidecar health-check script can query it without spawning an additional process or making any external API calls.

What to watch next

The most fragile assumption in the current design is the per-model weight estimation. Pacer fits those weights from a combination of Anthropic's opaque usage percentage and local transcript data, with API price ratios as a prior when the dataset is thin. If Anthropic changes how it counts model usage against the shared limit — or introduces a new model that does not yet appear in the transcript logs — those weights will be wrong until enough new data accumulates to refit them. A builder deploying this tool in a team context should verify the fitted weights against known usage spikes before trusting the advice it generates.

The second thing to watch is whether Anthropic exposes a richer usage API. Right now Pacer reverse-engineers limit weights because the public endpoint only returns an aggregate percentage. If Anthropic publishes per-model quota data — as several HN commenters on similar projects have requested — the transcript-fitting step becomes unnecessary and the projections become more reliable without any code changes in Pacer itself. The repository has three commits as of publication and no open issues or pull requests, so the pace of external contribution is something potential adopters should weigh before building hard dependencies on it.