Sign up
View stargazersSign up

[Bug]: Claude Enterprise spending budget is ignored, showing “No limits reported”#10155

openedSep 5, 2026byKKoningSanderPander

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

  1. Connect a Claude Enterprise account with an enabled USD 500 monthly spending budget.
  2. Open T3 Code's Usage account view.
  3. Compare it with the same account's Claude CLI control get_usage response. This account returns null five-hour/seven-day windows but populated rate_limits.extra_usage and rate_limits.spend objects.

Expected behavior

Show the provider-reported monthly spending budget and usage: $46.31 of $500.00 used (9.262%) in the captured example, even when rolling time-window quotas are null. Preserve currency/decimal metadata when converting amounts; do not substitute local token-cost estimates for account spending.

Actual behavior

The account view says “No limits reported”, although the provider response contains an enabled spending limit.

Impact

Minor bug or occasional failure

Enterprise users cannot see their configured spending budget or progress toward it in T3 and must check outside the app.

Version or commit

The mapper was inspected in T3 0.0.39-nightly.20260905.1287. The live provider payload below was independently captured on macOS with Claude Code 2.1.261; the local T3 version was not verified.

Environment

macOS; Claude Enterprise account authenticated through the default Claude profile and macOS Keychain.

Logs or stack traces

Sanitized excerpt from a successful CLI get_usage control response (both spending objects are nested under rate_limits):

json
1{
2 "rate_limits_available": true,
3 "rate_limits": {
4 "five_hour": null,
5 "seven_day": null,
6 "extra_usage": {
7 "is_enabled": true,
8 "monthly_limit": 50000,
9 "used_credits": 4631,
10 "utilization": 9.261999999999999,
11 "currency": "USD",
12 "decimal_places": 2,
13 "disabled_reason": null,
14 "user_disabled": false,
15 "spend_limit_reached": false
16 },
17 "spend": {
18 "used": {"amount_minor": 4631, "currency": "USD", "exponent": 2},
19 "limit": {"amount_minor": 50000, "currency": "USD", "exponent": 2},
20 "percent": 9,
21 "severity": "normal",
22 "enabled": true,
23 "disabled_reason": null
24 }
25 }
26}

decimal_places: 2 and exponent: 2 confirm that 50000 means $500.00 and 4631 means $46.31.

The diagnostic sent only this control request, without any user/model prompt:

json
1{"type":"control_request","request_id":"diagnostic-usage","request":{"subtype":"get_usage"}}

The CLI ran with stream-json input/output, session persistence disabled, hooks disabled, and no MCP servers. No model generation was requested.

Investigation

In the inspected build, claudeUsageResponseToLimits maps time-window and model-scoped utilization buckets but ignores the spending objects above. This appears to explain the empty limits display when the account exposes spending limits instead of rolling quotas.

Suggested regression coverage: this payload should yield visible account spending with the correct currency and units despite null rolling windows. If both spend and extra_usage are supported, avoid showing duplicate budgets.

Related: #6582 (closed broader subscription-usage UI request). This report concerns a concrete provider payload that the existing usage mapping drops.

Workaround

Check usage through Claude's own usage interface or the CLI control response.

JJulius MarmingeSep 5, 2026

Triage

Confirmed. This is a mapping gap in the Claude Limits path, not a failed get_usage probe.

On Claude Enterprise (and any plan that reports a spending budget instead of rolling quotas), the CLI returns rate_limits_available: true with five_hour / seven_day null and populated rate_limits.spend + rate_limits.extra_usage. T3 still shows “No limits reported.”

Why

claudeUsageResponseToLimits in apps/server/src/provider/Layers/claudeUsageLimits.ts only maps:

  • five_hour → Session
  • seven_day → Weekly
  • model_scoped[] → Weekly · {model}

It never reads spend or extra_usage. Null rolling windows are skipped, so the snapshot is { windows: [] } (success, not unavailable). limitsNotice() in packages/shared/src/usageLimits.ts then renders “No limits reported.” on web and mobile.

The capabilities probe already forwards the full rate_limits object (ClaudeProvider.ts), so the spend objects are available and then dropped.

The existing mapper test includes a disabled extra_usage object and does not assert it is mapped. That matches this miss. #9507 also noted live Claude get_usage windows were not verified when the Limits tab shipped.

In the captured payload, decimal_places: 2 / exponent: 2 mean 50000 → $500.00 and 4631 → $46.31. extra_usage.utilization is 9.262; spend.percent is the rounded 9. These are provider-reported account credits, not Usage → Cost token estimates.

Not a duplicate of #6582 / #5539 (those shipped the Limits view). This is a follow-up for an Enterprise spend-only payload that view still ignores.

Suggested fix

  1. Map an enabled spending budget to a monthly window even when session/weekly are null.
  2. Prefer spend when enabled; otherwise extra_usage when is_enabled. Do not show both — they are the same budget here.
  3. Convert minor units with exponent / decimal_places. Do not substitute local token-cost estimates.
  4. Use used/limit (or extra_usage.utilization) for percent so 9.262% is not collapsed to spend.percent’s 9.
  5. Keep rolling windows when they exist; spend is additive.
  6. Add a regression fixture with this payload: it must not produce an empty Limits notice.

The window contract (packages/contracts/src/providerUsageLimits.ts) is percent-only today, and the UI rounds usedPercent. Mapping a monthly ~9% bar would already beat the empty state. Showing “$46.31 of $500.00 used (9.262%)” needs optional used/limit/currency on the window (or a formatted label) plus a small Limits-row change.

Accepting as a minor bug. Workaround until then: Claude’s own usage UI or the CLI get_usage control response.

TTonybynMp4Sep 13, 2026
Synced from GitHub

Hey! I have a similar "no limits" result on a Claude Team seat, but from a different cause, so I thought i'd mention it here rather than open an issue for such a similar gap.

My account never reaches the mapper this issue describes. get_usage answers rate_limits_available: false for it, both before and after live API traffic, so claudeUsageResponseToLimits returns unavailable: { reason: "unsupported" } and the view renders "This account has no subscription limits". No spend or extra_usage object appears at all. Meanwhile claude.ai reports 75% session and 73% weekly for the same account at the same moment, so the numbers exist, they just are not in that response.

They arrive on the streamed rate_limit_event instead, under an undocumented unifiedWindows key, with no top-level utilization:

json
1"rate_limit_info": {
2 "status": "allowed", "resetsAt": 1789236000, "rateLimitType": "five_hour",
3 "overageStatus": "rejected", "overageDisabledReason": "org_level_disabled",
4 "isUsingOverage": false,
5 "unifiedWindows": {
6 "five_hour": { "utilization": 0.85, "resetsAt": 1789236000 },
7 "seven_day": { "utilization": 0.74, "resetsAt": 1789405200 }
8 }
9}

unifiedWindows is absent from the SDK typings we pin (@anthropic-ai/claude-agent-sdk@0.3.269) and I could not find it documented anywhere upstream. Captured with Claude Code 2.1.x on Linux, org-level overage disabled, organizationType: claude_team.

Two things in T3 dropped this data. claudeRateLimitEventToUpdate returned undefined whenever the top-level utilization was missing, which is every event this account emits. Even past that, applyUsageLimitsUpdate latched on the unsupported snapshot and discarded the update.

I opened #11482 which fixes both. It does not touch the spend-budget mapping this issue is originally about. The two paths are independent: yours has rate_limits_available: true with populated spend, mine has rate_limits_available: false with nothing. Both land on the same empty view, which is probably why they read as one bug.

LLancySep 20, 2026

I'd like to work on this. My understanding is that the Claude limits mapper should treat a response with null five_hour/seven_day but populated rate_limits.spend/extra_usage as a spend budget instead of reporting "No limits reported", with a unit test covering that shape. Is it available for me to take?

JJulius Marminge21d ago

The empty-limits symptom is fixed on current main by fd8dd51654. The mapper now reads the spending fields in your captured response and produces one “Monthly spend” row at 9.262%, even when rolling quotas are null. This is covered by a regression fixture; we could not reproduce with an Enterprise account. The fix reports percentage utilization; it does not yet display the dollar amounts.