Repository navigation
[Bug]: Claude usage view renders stale snapshot first (28%→0% flip), drops unifiedWindows-only rate events, duplicates same account across machines #17488
Description
Build: T3-Code nightly (AppImage), linux, claude 2.1.x
Setup: two boxes, same Claude Pro subscription and auth token, claudeAgent_stock instance.
Repro 1 — stale-first flip:
- Hit Claude session rate limit (warning received).
- Open usage view.
- Bars show Session 28% left, Weekly 94% left for ~1s, then flip to Session 0% left, Weekly 92% left.
The second reading is correct. The first is stale and misleading.
Evidence: the on-disk provider cache (caches/claudeAgent_stock.json, checkedAt shortly before opening) holds five_hour.usedPercent: 72 (= 28% left) and seven_day.usedPercent: 6 (= 94% left) — exactly the first render. The second render matches the fresh probe.
Suspected cause (from built bundles, nightly 20261009):
- Capabilities probe (usage) is cached with a 5-minute TTL (
CAPABILITIES_PROBE_TTL); the view renders the disk snapshot first, then the background probe lands ~1s later. - The server notes a deliberate trade-off: a successful probe "replaces the published windows outright, including any runtime update that landed while it was running." A slow probe can clobber the fresh
rate_limit_eventmerge (applyUsageLimitsUpdate). - The rate-event mapper requires top-level
utilizationand ignores events otherwise. Currentallowedevents inlogs/provider/events.*.logcarry onlyunifiedWindows(e.g.five_hour.utilizationwithout a top-level field), so live updates are dropped; only warning-shaped events update.
Expected: never present a stale snapshot as live (show refreshing/stale state with checkedAt age), apply unifiedWindows from all rate events, and make probe-vs-event reconciliation freshest-wins per window instead of outright replace.
Repro 2 — same account side by side:
- With both boxes online, usage showed the same subscription twice, side by side.
- Later it showed once.
Suspected cause (client ChatGptUsageButton merge/group helpers):
- Merge key is
driver:email-lower, elsedriver:credential:fingerprint, elseenv:instanceId. Same email merges; missing email (probe pending/failed) falls back to per-env keys, producing duplicates. - Grouped windows average
usedPercentacross co-grouped accounts. For one account seen twice this is wrong; freshestcheckedAtshould win.
Expected: stable single row per account once identity resolves; freshest-wins instead of average for identical accounts.
Activity
khibroxe commentedon Oct 9, 2026
I can confirm the
unifiedWindows-only part on macOS: T3 Code Nightly 0.0.46-nightly.20261009.2873, Claude Code CLI 2.1.295, and Claude Pro.Every
allowedevent in my provider logs has this shape, about 1,400 of them across my threads:{ "type": "rate_limit_event", "rate_limit_info": { "status": "allowed", "resetsAt": 1791579000, "rateLimitType": "five_hour", "overageStatus": "rejected", "overageDisabledReason": "org_level_disabled", "isUsingOverage": false, "unifiedWindows": { "five_hour": { "utilization": 0.5, "resetsAt": 1791579000 }, "seven_day": { "utilization": 0.26, "resetsAt": 1792072800 } } } }claudeRateLimitEventToUpdatereturns early ontypeof info.utilization !== "number", soonUsageLimitsnever fires. Here the startup probe also getsrate_limits: null(#15364), so these events are the only source of Claude limits, and they are all dropped. Reading eachunifiedWindowsentry (scaled by 100) when the top-levelutilizationis missing would fix this case.mattesick commentedon Oct 11, 2026
Additional report for the same-account-across-machines part of this issue.
@maria-rcks, this is related to your merged PR #17711, which keeps Personal and Team workspaces separate for one email while still merging the same workspace across environments. The problem here is two computers signed into the same Claude Team login and workspace.
Reproduction
The two supplied screenshots show the following tooltips:
Actual behavior
The same Team quota occupies two Work bars and contributes two 20% shares, totaling 40% of the displayed pool, even though there is only one underlying Team quota. This distorts the overall remaining percentage and reset contribution.
The screenshots also show both Work bars at 99% in Weekly · Fable, with the same reset countdown. The Claude cards show Session 80% left, Weekly 14% left, and Weekly · Fable 81% left. These are screenshot observations, not an independently reproduced test.
Expected behavior
Count one provider account and workspace once in the pool, even when it is signed in on several computers. Both computer names can remain available as login sources for that one quota. Keep genuinely different Personal and Team workspaces separate, as intended by #17711. Deduplicate before calculating account weights, total remaining quota, and reset contributions.
Please check whether the two computers are reporting different or missing workspace identities and whether differing server versions affect the merge. I have not established the root cause or that #17711 caused a regression.
Environment and evidence
Reported on October 11, 2026. The reporting Mac has T3 Code Nightly
0.0.46-nightly.20261011.2980installed and runs macOS15.7.4. The other computer's version and OS were not verified.Two screenshots were supplied with this report. Their relevant values are transcribed above. The images themselves are not attached here because the available GitHub browser session is signed out.