Repository navigation
[Bug]: Usage page limit names go out of sync after renaming provider instances #24038
Description
Area
apps/web, packages/shared
Steps to reproduce
- Have two or more instances of the same driver (here: Claude), each with its own account and a usage-limits reading.
- Rename the instances in Settings → Providers.
- Open the Usage page and look at the Limits section.
Not yet reduced to a deterministic repro: reported from a live setup, not reproduced from a clean state.
Expected behavior
Limit bars and tooltips use the current instance names, the same ones Settings → Providers and the model picker show.
Actual behavior
The Limits bars show names that no longer match the real instance names. In the report, the Claude card shows the bars Claude 1 and C1 (Session, Weekly and Weekly · Fable rows) while the instances are named differently in Settings.
Impact
Minor bug or occasional failure. The numbers are right, but with several accounts of one provider the labels no longer say which account is which.
Environment
macOS, two Claude instances across two environments. App version not recorded. Code read against main @ d7a8d6f.
Suspected area (unverified)
Not confirmed by a debugger or a test. Places worth checking first:
packages/shared/src/usageLimits.tscollectLimitAccounts: when accounts merge,displayName: previous.displayName ?? next.displayNamekeeps the first-seen name, even if the fresher read carries the new one.- The name is also stamped on the server snapshot when the instance is created (
withInstanceIdentityinapps/server/src/provider/Drivers/ClaudeDriver.ts). Check that a rename reachesserverConfig.providerswithout a restart. - The notice text builds its own copy of the name (
provider.displayName?.trim() || String(provider.driver)inusageLimits.ts), so check that path too.
Workaround
Not found. A server restart might refresh the names (untested).
Screenshot to attach: Usage page, Claude card with Claude 1 and C1 bars.
Activity
luke2x commentedon Oct 23, 2026
Note
Written by gpt 6.1 sol on behalf of Luke
I investigated this on current main (
66ee628e08) before attempting a fix. Two temporary regression cases passed without production changes: distinct Claude accounts across two environments immediately showed renamed labels even when the quota timestamps stayed unchanged; matching accounts across environments merged once, retained the first environment’s current alias, and used the fresher quota reading. All 40 tests in that focused run passed.collectLimitAccountsrebuilds its map on each call, so the first-name preference can choose between different current aliases for the same account, but does not by itself retain a name from a previous call. I haven’t reproduced the reported stale-name behavior and haven’t changed that preference speculatively.Could you share the exact app versions, the instance names in each environment, which environments are selected on Usage, and whether the mismatch persists with only the renamed environment selected? It would also help to know whether the entries represent the same account/workspace across environments. Please omit credentials, account emails, machine names, and private paths; neutral labels are enough.
andras-gyarmati commentedon Nov 6, 2026
Note
Written by Claude Opus 5.5 on behalf of Andras
answering @luke2x's questions above, i hit this today and can reproduce it
ClaudePersonal 1and gave it an accent colour. on the Linux environment the Claude instance was never touched, so it kept the default nameClaudeand no colourClaudein the default colour and the provider icon kept the initialsCLinstead ofC1, while Settings → Providers and the model picker showedClaudePersonal 1. instances that exist on only one environment showed their new name right awayso the name isnt kept from an earlier read, it comes from the other environment: when the same account merges,
collectLimitAccountstakesprevious.displayName ?? next.displayName(same foraccentColor), and the Linux instance reports the defaultClaude, so whichever environment comes first wins and the rename never shows. giving the Linux instance the same name and colour fixed the bars straight away. maybe the merge could prefer a name the user set over the driver defaultjuliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Not run in the app: Usage → Limits needs a real Claude usage reading, which needs first-party Claude OAuth, and no VM has it. Reproduced in a unit test on origin/main @ 3c68642: in packages/shared/src/usageLimits.test.ts ('pools' block) I added 'names one account seen on two environments by the instance the user renamed'. It builds two environments that both report the same Claude login (same email). env-a's instance keeps the default displayName 'Claude' with no accent colour; env-b's instance is renamed 'ClaudePersonal 1' with an accent colour. collectLimitAccounts returns one merged account, as expected, but its displayName is 'Claude' instead of 'ClaudePersonal 1' (the test fails with that diff). The other 69 tests in the file pass. This matches the second commenter's live report on 0.1.8-nightly.20261106: macOS instance renamed, Linux instance untouched, 'All environments' selected, merged bars show 'Claude' / 'CL'. They found that giving both instances the same name fixed it.
Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.