Quota guard pauses capture on seven_day_overage_included "rejected" even though the request succeeded (15.3.0) #5182

Activity

1. thedotmack commented on Oct 29, 2026

   

   thedotmack

   on Oct 29, 2026

   Owner

   More actions

   Thanks @beckman55, confirmed on main. providerRejection in src/services/worker/RateLimitStore.ts:512-516 treats status: 'rejected' on any window as exhaustion, including seven_day_overage_included, so ClaudeProvider.ts:582-596 aborts the session even when the observer's own request succeeded. That contradicts the window's own contract comment (RateLimitStore.ts:49-59): only the provider refusing the observer's request should stop it on that bucket.

   The fix is to ignore a rejected status on seven_day_overage_included unless the request itself was refused, with a test that feeds a successful response carrying that header. Happy to help land a PR if you or anyone wants to take it.
2. beckman55 commented on Oct 29, 2026

   

   beckman55

   on Oct 29, 2026

   Last edited by beckman55

   Author

   More actions

   Thanks for confirming. Here's a patch against main (342dfe0) you can commit as-is. If you want to keep attribution, add this trailer to the commit:

   Co-authored-by: beckman55 <11038775+beckman55@users.noreply.github.com>
   

   Change: providerRejection skips seven_day_overage_included. That window's headers ride on every response of an account with the bucket, so a rejected status there can arrive on a request that succeeded. A request the provider actually refuses still pauses capture through the existing paths: quota-limit prose → ResponseProcessor (quota:observer_text), or a thrown quota error → ClaudeProvider (quota:unknown:quota_exhausted). Every other window's rejected handling is unchanged.

   Tests: replaces aborts on a rejected overage-included weekly window (it asserted the buggy behavior) with:

   • a rejected overage-included snapshot from a successful response → { abort: false } (fails on main, passes with the patch)
   • a rejected overage-included window next to a rejected seven_day → still aborts on seven_day

   All 14 test files that reference the quota guard / RateLimitStore: 364 pass, 0 fail. tsc --noEmit is clean.

   Apply with git apply 5182.patch:

   5182.patch

   diff --git a/src/services/worker/RateLimitStore.ts b/src/services/worker/RateLimitStore.ts
   index 3743ef48a..dd70f18fc 100644
   --- a/src/services/worker/RateLimitStore.ts
   +++ b/src/services/worker/RateLimitStore.ts
   @@ -54,8 +54,9 @@ export type RateLimitWindow =
       * whatever model the request used, so the figure (and any warning the CLI
       * derives from it) is not evidence that the observer draws on it. Above 1
       * it is usage that legitimately ran past the cap, not a refusal. Only the
   -   * provider refusing the observer's own request (`rejected`) stops the
   -   * observer on it.
   +   * provider refusing the observer's own request stops the observer on it;
   +   * a `rejected` status in the headers of a response that succeeded does
   +   * not (#5182).
       */
      | 'seven_day_overage_included'
      | 'overage';
   @@ -508,8 +509,15 @@ export function shouldAbortForQuota(
     * The provider has already declared the bucket exhausted: status='rejected',
     * or overageStatus='rejected' on the overage window. Stop regardless of
     * whether utilization is reported.
   + *
   + * `seven_day_overage_included` is the exception: its headers ride on every
   + * response of an account with the bucket, so a `rejected` status there can
   + * arrive on a request that succeeded (#5182). A request the provider actually
   + * refused comes back as quota-limit prose or a thrown quota error, and those
   + * paths pause the generator themselves.
     */
    function providerRejection(window: RateLimitWindow, entry: RateLimitEntry): QuotaDecision | undefined {
   +  if (window === 'seven_day_overage_included') return undefined;
      const isRejected =
        entry.status === 'rejected' ||
        (window === 'overage' && entry.overageStatus === 'rejected');
   diff --git a/tests/worker/rate-limit-store.test.ts b/tests/worker/rate-limit-store.test.ts
   index dcc6ac439..20fafe7c8 100644
   --- a/tests/worker/rate-limit-store.test.ts
   +++ b/tests/worker/rate-limit-store.test.ts
   @@ -176,15 +176,34 @@ describe('shouldAbortForQuota — cli/oauth auth', () => {
        expect(shouldAbortForQuota(cliAuth, store, FIXED_NOW)).toEqual({ abort: false });
      });
    
   -  it('aborts on a rejected overage-included weekly window', () => {
   +  // The overage-included headers ride on every response, so `rejected` there
   +  // can arrive on a request that succeeded. A real refusal comes back as
   +  // quota-limit prose or a thrown quota error, which pause on their own (#5182).
   +  it('does not abort on a rejected overage-included status from a successful response', () => {
        store.set({
          rateLimitType: 'seven_day_overage_included',
          status: 'rejected',
   +      utilization: 1.05,
          resetsAt: FIXED_NOW + 24 * 60 * 60 * 1000,
        });
   +    expect(store.getMostRecentByWindow().seven_day_overage_included?.status).toBe('rejected');
   +    expect(shouldAbortForQuota(cliAuth, store, FIXED_NOW)).toEqual({ abort: false });
   +  });
   +
   +  it('still aborts on a rejected window the observer draws on next to a rejected overage-included one', () => {
   +    store.set({
   +      rateLimitType: 'seven_day_overage_included',
   +      status: 'rejected',
   +      resetsAt: FIXED_NOW + 24 * 60 * 60 * 1000,
   +    });
   +    store.set({
   +      rateLimitType: 'seven_day',
   +      status: 'rejected',
   +      resetsAt: FIXED_NOW + 2 * 24 * 60 * 60 * 1000,
   +    });
        const decision = shouldAbortForQuota(cliAuth, store, FIXED_NOW);
        expect(decision.abort).toBe(true);
   -    expect(decision.window).toBe('seven_day_overage_included');
   +    expect(decision.window).toBe('seven_day');
      });
    
      it('does not abort on inactive overage at 100% utilization', () => {
3. parveen0029

   added a commit that references this issue on Oct 30, 2026

   fix(worker): exclude seven_day_overage_included from quota guard hard…

   ...

   4f27721
4. MohamedFBoussaid commented on Oct 30, 2026

   

   MohamedFBoussaid

   on Oct 30, 2026

   More actions

   Same false positive on the plain overage window in 15.7.0, on an account without extra usage enabled.

   Environment

   • claude-mem 15.7.0 (worker on macOS), CLAUDE_MEM_PROVIDER=claude, CLAUDE_MEM_CLAUDE_AUTH_METHOD=cli (subscription, OAuth token from the credential store)
   • Extra usage is not enabled on the account, so the overage window always reports rejected

   Evidence (worker log, three consecutive probes)

   20:21:53.217 [SDK] [session-1561] ← Response received (1534 chars) {promptNumber=23} <observation>
   20:21:53.299 [SDK] Aborting session for quota guard: quota:overage rejected by provider {window=overage, authMethod=Claude Code OAuth token ...}
   20:21:53.832 [SESSION] [session-1561] Generator paused for quota; preserving buffered work {pendingCount=87}
   
   20:52:47.319 [SESSION] Primary quota cooldown elapsed; probing primary {primary=claude}
   20:52:51.269 [SDK] [session-1561] ← Response received (98 chars) {promptNumber=29}
   20:52:51.327 [SDK] Aborting session for quota guard: quota:overage rejected by provider {window=overage ...}
   
   21:23:51.720 [SDK] [session-1561] ← Response received (81 chars) {promptNumber=29}
   21:23:51.788 [SDK] Aborting session for quota guard: quota:overage rejected by provider {window=overage ...}
   

   Every probe succeeds, then the guard re-arms a 30-minute cooldown. quota-cooldown.json shows "window": "overage", "auth": "subscription", and the user-facing message reads "Claude rejected the request because its extra-usage usage allowance is exhausted." Meanwhile the main CLI session on the same account keeps working on its normal allowance.

   Where it comes from in 15.7.0

   providerRejection aborts on e.status === "rejected" for any window, and additionally on t === "overage" && e.overageStatus === "rejected". For an account without extra usage, the overage bucket is permanently rejected, so the guard can never clear on its own.

   History on this install

   Before 15.5.0 the only window that ever paused capture here was seven_day (22 occurrences, all genuine). quota:overage rejected appears only from 15.5.0 onwards (7 occurrences, all against a successful response).

   Suggested rule

   Treat a rejected status on overage (and seven_day_overage_included, as in the fix discussed above) as informational only. The observer should pause on these buckets only when its own request was actually refused by the provider.

   Workaround that works

   CLAUDE_MEM_QUOTA_FALLBACK_PROVIDER=openrouter (or gemini) routes capture through the fallback while the cooldown is active, and the buffered observations drain.