A 5-hour window tracker is mostly a countdown problem, not a percent problem

It is a server-side cap that bills your prompts against the last 5 hours of activity, weighted by model class, attachments, and tool calls. The endpoint /api/organizations/{org_uuid}/usage on claude.ai returns it as a five_hour object with two fields: utilization (a float between 0 and 1, sometimes 0 and 100 depending on the bucket) and resets_at (an ISO 8601 timestamp pointing at the moment the oldest weighted message in the window will age out). A 'tracker' is anything that polls that JSON and turns it into something you can glance at without opening the Settings page.

Because the percent on its own is half information. 92 percent with a reset four minutes away is a coffee break. 92 percent with a reset four hours away is a switch-to-Sonnet-or-stop decision. The Settings page reduces resets_at to a binary 'usage will reset at HH:MM' string. A tracker has to render both axes (how full, and how long until empty) so you can pick the right remediation in under a second. The countdown is what makes the page-on-the-toolbar tracker more useful than the page on claude.ai.

extension/popup.js lines 17 to 27. The function fmtResets parses the ISO string, subtracts Date.now(), and bands the result. <=0ms returns 'now'. <1 hour returns Math.round(diff / 60000) plus 'm'. 1 to 48 hours returns Math.round(h) plus 'h'. >=48 hours returns Math.round(h / 24) plus 'd'. Three thresholds, four output shapes. The 1-hour boundary is the place where '60m' would feel coarse next to '1h'. The 48-hour boundary is where '50h' starts to feel less readable than '2d'. The bands are picked for one-glance legibility on a 6-character toolbar surface.

Because the 5-hour window is rolling. resets_at is computed off the oldest weighted prompt still inside the 5-hour boundary; as soon as you fire another big prompt, that boundary slides forward and the timestamp changes. A static countdown would lie within minutes. background.js sets POLL_MINUTES = 1, registers a chrome.alarms tick on install and on startup, and calls refresh() on every fire. The cadence is fixed: no exponential backoff, no on-focus poll, no jitter. One minute, every minute, while the browser is awake.

Two surfaces. The toolbar badge shows one number, the rounded percent on the worst five_hour bucket across every org you belong to, with a green/orange/red color band at <80 / >=80 / >=100 thresholds. Click the icon and the popup renders one row per account (email, percent, bar, countdown). The label format is '<bucket-name> · <countdown>' assembled in popup.js line 33: `${label} · ${resets}`. So '5-hour · 22m' or '5-hour · 3h' or '5-hour · now' depending on which band fmtResets fell into.

Three reasons. First, the popup row is narrow (the extension popup is a fixed 320 pixel surface) and 1h 47m 12s eats horizontal space. Second, anything finer than minute precision flickers as the second ticks; the user reads a flicker as 'something is wrong'. Third, a single-unit label compresses to the part you need to plan around: when you see '3h' you do not need the minutes to know your refactor session is over for the afternoon. The design choice is precision proportional to the action the user will take, not to the resolution of the underlying timestamp.

Yes, the same fmtResets function runs on every bucket the popup row renders: five_hour, seven_day, seven_day_sonnet, seven_day_opus when present. seven_day buckets land in the days band almost always, so you typically see '7d · 5d' or '7d Opus · 4d'. The algorithm does not care which bucket; it just receives an ISO timestamp and returns the band. That is intentional. The cap shape is changing on Anthropic's side fast enough that hardcoding bucket-specific countdown logic would be an immediate footgun.

Yes. resets_at can be a few seconds or even a few minutes in the past at the moment you read it, because the server's clock and the prompt-aging logic do not always tick on the same edge. fmtResets line 22 returns 'now' for any non-positive diff, which covers that small leading window. The next refresh, 60 seconds later, will pick up the new resets_at the server has computed against the next-oldest weighted prompt and the countdown will jump forward to a real value. This is also why the popup feels briefly stuck after a reset: the server has not yet recomputed the boundary.

Yes. fmtResets uses Date.now() as the reference, which reads the local OS clock. If you have skewed your clock by an hour to test something, the countdown will be off by an hour. The percent is unaffected because it comes straight from the server. There is no NTP step inside the tracker. In practice machines stay close enough to true time that this never matters, but it is the one place the countdown depends on something other than the server payload.