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

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):

{
  "rate_limits_available": true,
  "rate_limits": {
    "five_hour": null,
    "seven_day": null,
    "extra_usage": {
      "is_enabled": true,
      "monthly_limit": 50000,
      "used_credits": 4631,
      "utilization": 9.261999999999999,
      "currency": "USD",
      "decimal_places": 2,
      "disabled_reason": null,
      "user_disabled": false,
      "spend_limit_reached": false
    },
    "spend": {
      "used": {"amount_minor": 4631, "currency": "USD", "exponent": 2},
      "limit": {"amount_minor": 50000, "currency": "USD", "exponent": 2},
      "percent": 9,
      "severity": "normal",
      "enabled": true,
      "disabled_reason": null
    }
  }
}

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:

{"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.

Start in packages/contracts or packages/shared by locating claudeUsageResponseToLimits, then inspect how its result reaches T3 Code’s Usage account view. Add regression coverage using the provided payload with null five-hour and seven-day windows and populated rate_limits.extra_usage and rate_limits.spend. Done means the view reports $46.31 of $500.00 used with USD metadata and does not duplicate supported spending limits.