The tightened Claude plan has seven reset clocks. You are probably watching the wrong one.

Pull /api/organizations/{org_uuid}/usage right now. For every field where utilization is close to 100, read the resets_at ISO timestamp next to it. That is your real wait time. The block is being enforced by whichever of the seven buckets crossed 100 first, and only that bucket's resets_at matters. ClaudeMeter prints it in the menu bar as, for example, '5-hour 98% -> resets Fri Apr 24 18:14 (in 37m)'. If the gating bucket is five_hour your wait is measured in minutes, not days, regardless of where the weekly bar sits.

You cannot tell from a single HTTP 429. The server does not name the bucket in the response body. You have to read /api/organizations/{org_uuid}/usage a moment before or after and find the field where utilization >= 100. In practice that is five_hour, seven_day, seven_day_sonnet, or seven_day_opus. The less common ones (seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) gate different traffic paths. ClaudeMeter names all seven as distinct Option<Window> fields in src/models.rs lines 18-28 so you can see which ceiling you hit.

Because the buckets are rolling, not calendar-aligned. resets_at is computed as 'the moment this window's oldest chargeable usage falls out of the window', which is a different wall-clock time for every bucket and every account. Two Pro users at the same utilization can have different five_hour resets_at values because their charging histories differ. That is why ClaudeMeter's format.rs prints the delta in '(in 2d 4h)' form next to each bucket: a single 'resets on Sunday' line would be wrong for almost everyone.

In /src/models.rs, the Window struct is the shape of every rolling bucket: { utilization: f64, resets_at: Option<DateTime<Utc>> }. Every one of the seven fields (five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) deserializes into a Window, so each has its own resets_at. The CLI formatter at src/format.rs lines 75-98 prints a separate 'resets Mon Apr 28 14:30 (in 2d 4h)' per bucket. The extension UI at extension/popup.js uses fmtResets to render the same value inline as '5-hour · 30m' on each bar.

No. The field's semantics are unchanged. What changed after 2026-03-26 is the rate at which utilization climbs against a fixed workload during weekday peak hours, which makes five_hour reach 100 faster and therefore resets_at on five_hour becomes the active countdown far more often than it used to be. Before the tightening, seven_day was the common gate. After, five_hour is the gate on heavy weekday afternoons. Same field, different bucket showing up as the blocker.

Yes. Paste your claude.ai session cookie into curl, hit /api/organizations/{org_uuid}/usage, and every Window-shaped field in the response will contain a resets_at ISO timestamp. ClaudeMeter just polls that endpoint every 60 seconds and formats the delta for you. The extension uses credentials: 'include' so no cookie paste is needed. The menu bar binary uses Chrome Safe Storage via keychain. Either route, same field.

Yes. In the Rust struct it is Option<DateTime<Utc>>, and the extension checks fmtResets(w?.resets_at) returns an empty string when the field is absent. Treat null as 'not currently windowed' for that bucket. In practice we see it null for per-model buckets when the account has not used that model in the current window. Once you start using the model, a resets_at appears on the next poll.

Because in a tight window you need minute resolution and in a calm week you don't. extension/popup.js fmtResets uses: below 1 hour show '37m', below 48 hours show '14h', otherwise show '3d'. The CLI format.rs format_window does the same partition via chrono's num_days and num_hours. The point is to surface the resolution that matters for planning the next action, not an academic timestamp.

Yes, trivially, if five_hour is at 100. The server rate-limits on the first bucket to cross the ceiling. seven_day at 78 tells you nothing about the five_hour curve during a weekday peak hour. This is the single most common 'but I still had quota left' confusion since the tightening. Reading only the weekly bar and assuming it is authoritative is what every pre-tightening guide tells you to do. Post-tightening, it is often wrong.

It slides forward. Because the window is rolling, every new message shifts the window's right edge, which shifts resets_at for that bucket. Sampling once a minute is enough to catch the drift. If you sampled once an hour the resets_at you saw at 14:00 would already be stale by 14:05 in a heavy session. A 60-second cadence matches the precision the field is returned at.