[Bug]: Inactive weekly_scoped (Fable) limits are still dropped after #8088, hiding real per-account Fable usage from the pool

Open
  • Is something wrong?
#8,110 3 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
authentication, backend

Research direction

Start in src/providers/quota/anthropic-usage-windows.ts, especially the anthropicUsageBuckets handling of is_active and already-represented windows. Compare its output with the issue’s Anthropic usage examples, including inactive session, weekly_all, and weekly_scoped rows. Done when all reported quota windows remain available for display and routing without breaking scoped-limit handling; verify with the account quota command and relevant tests.

Written by the indexing model from the issue text.

Description

account-pool bug
Client or integration

OpenCodex dashboard

Area

Authentication and account pool

Summary

Update: the shared-meter half of this (session / weekly_all) is fixed by #8088, merged to dev after 2.96.0 shipped. #8088 deliberately keeps weekly_scoped (Fable/Opus/Sonnet) rows active-only, and that remaining part is what this issue asks to change: an inactive Fable row still carries real usage (12% and 6% on two of my accounts) and is still hidden from the dashboard and from routing. The original report follows.

After a recent update, the Anthropic account rows on the dashboard (and ocx account list anthropic --quota) show only one quota window per account. The five-hour, weekly and Fable windows are no longer shown together, even though /api/oauth/usage still reports all three with real usage.

The cause is how is_active is read. Anthropic sets is_active: true on the limit that is currently binding for the account (one per account in every response I captured), not on "limits that apply to this account". anthropicUsageBuckets in src/providers/quota/anthropic-usage-windows.ts drops every is_active: false entry (line 40) and, because the window is already marked represented, also skips the legacy five_hour / seven_day duplicate. The non-binding windows therefore disappear.

Expected: all windows that the usage endpoint reports are shown and available to routing; is_active only marks which one is binding. The Claude Code guide says "only active model-specific weekly limits affect that model family", so the inactive filter appears to be meant for scoped family limits, but the code applies it to session and weekly_all as well.

This matters beyond display. Managing a multi-account pool needs every window for every account: with the filter, a Fable-exhausted account hides its 76% weekly usage, and the active account hides its own Fable usage, so the per-account quota the router reads is incomplete.

Reproduction
  1. Enable the Anthropic OAuth account pool with several Max accounts, some of which have exhausted the Fable weekly limit.
  2. Run ocx account list anthropic --quota --refresh --json.
  3. Compare each account's quota with a direct GET https://api.anthropic.com/api/oauth/usage for the same token.

Observed in 2.96.0 (8 accounts): each non-active account returns only one of fiveHourPercent, weeklyPercent, or a Fable customWindows entry. For example, an account whose usage response has session 0%, weekly_all 76% and Fable 100% shows only customWindows: [{label: "Fable", percent: 100}].

Usage-endpoint limits for that account (redacted):

[
  {"kind": "session", "group": "session", "percent": 0, "severity": "normal", "resets_at": null, "scope": null, "is_active": false},
  {"kind": "weekly_all", "group": "weekly", "percent": 76, "severity": "warning", "resets_at": "2026-11-03T11:00:00.301462+00:00", "scope": null, "is_active": false},
  {"kind": "weekly_scoped", "group": "weekly", "percent": 100, "severity": "critical", "resets_at": "2026-11-03T11:00:00.301646+00:00", "scope": {"model": {"id": null, "display_name": "Fable"}, "surface": null}, "is_active": true}
]

The same response also carries "seven_day": {"utilization": 76.0, ...}, which is ignored because weekly_all is already represented.

For the currently active account the binding limit is weekly_all (40%, is_active: true); session (17%) and Fable (12%) are is_active: false. Its dashboard row shows five-hour only because the response headers of served requests fill it in; the Fable 12% is not shown at all.

Local fix that resolves it (verified: all 8 accounts now show five-hour, weekly and Fable after ocx restart):

-    if (row.is_active === false) continue;
-    if (row.is_active !== undefined && row.is_active !== true) { familyEnumeration = false; continue; }
+    if (row.is_active !== undefined && typeof row.is_active !== "boolean") { familyEnumeration = false; continue; }

If routing should still treat a non-binding scoped limit differently, that decision could read is_active from the bucket row instead of dropping the window before display and routing see it.

Version

2.96.0

Operating system

Windows 11

Provider and model

anthropic (OAuth account pool) / claude-fable-5-1

Checks
  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
19h 31m
Merged PRs (30d)
676

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.