Settings → Usage shows a monthly percentage that never blocks, while a separate 7-day rolling limit blocks at 100% with no warning #97

Summary

Two different usage mechanisms are surfaced with almost the same wording, and the one users can see does not correspond to the one that blocks them.

• Settings -> Usage -> Organization Usage shows a calendar-month percentage. Per App settings this is explicitly "informational, not a real-time usage limit. Reaching it never blocks usage or changes billing."
• Rate Limits are three independent rolling windows (5-hour / 7-day / 30-day). Per Individual Plans: "You need headroom in all three to send a request."

A user can therefore read a low monthly percentage and still be blocked by the 7-day window - and neither documented alerting path targets that window.

Observed behavior

On a Teams org seat (docs say each seat includes Pro Rate Limits), the month figure in Settings -> Usage read ~23% in the morning. About 2.5 hours later the CLI rejected requests:

402 {"detail":"You've reached your weekly standard usage limit (resets in 4 days).
     Switch to Droid Core or enable Extra Usage to continue.",
     "status":402,"title":"Payment Required","displayToUser":true}

The router then fell back to Droid Core and 19 seconds later returned:

402 {"detail":"You've reached your weekly Droid Core usage limit (resets in 4 days).
     Reload Extra Usage credits or wait for your limits to reset.",
     "status":402,"title":"Payment Required","displayToUser":true}

Local session records (~/.factory/sessions/**/*.settings.json, inclusiveTokenUsage.factoryCredits) totalled ~17.2M credits across the window, of which only ~80K were consumed during those 2.5 hours (about 0.47%). So the jump from 23% to blocked was not caused by a burst of usage in that interval.

Notably, if 17.2M credits is 23% of the 30-day cap, the implied 30-day cap is ~74.8M - about 4.35x the 7-day cap, versus the 30/7 ratio of 4.29. That is consistent with the caps scaling with window length, i.e. the same consumption reads ~23% on the 30-day bar while already being ~100% on the 7-day bar.

Why this is a UX/docs gap rather than a usage dispute

1. The monthly figure a user naturally watches is documented as non-blocking, so it cannot warn about an imminent block.
2. The 7-day window that does block is not prominently surfaced in that same view.
3. Neither alerting path covers the 7-day window either:
   • disableUsageLimitAlerts fires at 80% / 100% of the monthly cap.
   • disableWeeklyUsageSummary is described in Settings as covering users "at or above 80% of their monthly credit cap" - and only reaches Managers and Owners.
4. No documentation page states the actual cap values for the three windows, so a user cannot self-check whether 23% is near a boundary.

Steps to reproduce (as far as user-side is possible)

1. On a Teams seat, consume a large amount of Standard credits early in a 7-day window (e.g. two heavy days on a high-multiplier model with high reasoning effort).
2. Open Settings -> Usage and note the monthly percentage - it can still be low.
3. Continue working until the 7-day window fills.
4. Requests fail with the 402 above even though the visible monthly percentage is far from 100%.

Because the caps are server-side and not exposed anywhere locally (~/.factory/settings.json contains only UI preferences; there is no allowance / quota / usedRatio cache anywhere under ~/.factory), a user cannot verify their own headroom.

Expected behavior (any of these would help)

1. Surface all three rolling windows together wherever usage is shown, labeled with their window (5-hour / 7-day / 30-day), instead of a single monthly percentage.
2. Name the window in the block message and in the UI, so "you are blocked by the 7-day window" is distinguishable from "your month is at 23%".
3. Add an alert tied to the 7-day (and 5-hour) window, not only the monthly cap - so a user is warned before work is interrupted.
4. Document the cap values for the three windows per plan, or expose them via the API to the user, so headroom is checkable.
5. If the usage view intentionally falls back to a cached figure when api.factory.ai is unreachable, indicate staleness in the UI (see below).

Related observation: possible stale reading during API unreachability

During the period when the low percentage was read, the client could not resolve api.factory.ai:

2026-11-12T00:48Z   getaddrinfo ENOTFOUND api.factory.ai  (x3)
2026-11-12T01:25Z   getaddrinfo ENOTFOUND api.factory.ai  (x4)
2026-11-12T01:25:55Z [SettingsManager] Organization policy request failed in transport
2026-11-12T01:27:18Z WorkOS token refresh failed transiently

If the Usage view serves a cached value in that state, showing it as current would compound the confusion. Worth confirming whether staleness is tracked.

Related changelog entries that may be relevant

• v0.247.0 - "Usage totals for retries - Usage totals now count every billed model attempt, including ones that were retried or refused." The sequence above produced 9 consecutive failed/rejected route attempts in ~19 seconds; if refused attempts are metered, that is worth stating explicitly.
• v0.246.0 - "Credits in usage notices - The high-cost model notice and limits modal now describe usage in credits instead of tokens." Local records store factoryCredits, so confirming that the percentage and the 402 decision use the same unit would help.
• v1.4.0 - "Usage bar label alignment - Bars in a usage list now share one start and length instead of shifting per row." Suggests the usage UI had rendering issues in this area recently.

Environment

• Droid CLI: 1.7.0 (droid --version)
• Factory Desktop: 1.8.0, auto-updated to 1.9.0 during the session
• OS: Windows 10.0.19045 x64
• Plan: Teams organization seat (not BYOK, no custom proxy)
• Model at time of block: claude-opus-5-5, reasoning effort max

Account identifiers (organization ID, user ID, session IDs) intentionally omitted from this public issue; happy to provide them privately via support@factory.com.

Impact

Work stopped mid-task with no prior warning, and the one usage number visible in the product pointed at a different window than the one that blocked. Any Teams/Pro user doing heavy work in a short period can hit this without ever seeing an approaching limit.

Thanks - I am not disputing the consumption itself (the two heavy days look plausible). The gap is that the number shown to me and the limit enforced on me are different windows, and nothing documented warns about the enforcing one.