[FEATURE] Expose /usage and /context data in statusLine JSON

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/8464
2. https://github.com/anthropics/claude-code/issues/12510
3. https://github.com/anthropics/claude-code/issues/11535

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I think it's not a duplicate : it create a request for both feature, the should expose more data

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Additional Context: Why remaining_percentage Doesn't Match the Red Warning

I've done deep research into Claude Code's source (cli.js v2.1.7, verified in v2.1.9) and found a critical limitation that affects anyone trying to predict when the context warning/auto-compact will trigger.

The Discrepancy

The statusline's remaining_percentage and the red warning banner use different token calculations:

| Display | Tokens Counted | Denominator |
|---------|----------------|-------------|
| Statusline (remaining_percentage) | INPUT only | 200,000 |
| Red Warning Banner | INPUT + OUTPUT | ~123,000 (auto-compact limit) |

Source Code Evidence

Statusline calculation (Tw7) - INPUT only:

let B = A.input_tokens + A.cache_creation_input_tokens + A.cache_read_input_tokens,
    G = Math.round(B / Q * 100);  // Q = 200000
return { used: Z, remaining: 100 - Z }

Warning calculation (uSA) - INPUT + OUTPUT:

return A.input_tokens + 
       (A.cache_creation_input_tokens ?? 0) + 
       (A.cache_read_input_tokens ?? 0) + 
       A.output_tokens  // ← NOT in statusline!

Why This Matters

In a code-generation-heavy session:

Input tokens:    20,000  (statusline counts this)
Output tokens:   83,000  (statusline IGNORES this)
─────────────────────────
Total:          103,000  (warning counts this)

Statusline:  100 - (20,000 / 200,000 × 100) = 90% remaining
Warning:     103,000 >= (123,000 - 20,000) → TRIGGERS!

Result: The red warning appears while statusline still shows 90% remaining. Users are blindsided because output tokens aren't visible.

Current Workaround Limitations

The statusline JSON exposes:

• total_output_tokens - session-cumulative (doesn't reset on /compact)
• remaining_percentage - per-conversation, but INPUT-only

Neither allows exact replication of the warning calculation.

Proposed Addition

Add per-conversation output tokens to the statusline JSON:

{
  "context_window": {
    "remaining_percentage": 90,
    "conversation_output_tokens": 83000,
    "effective_remaining_percentage": 16
  }
}

The data already exists internally (via HKA() → uSA()), it just needs to be exposed.

This would allow statusline scripts to accurately predict when /compact will be forced, rather than being surprised when the warning appears at "90% remaining."

?

Enthusiastically +1'ing this — this is the single biggest gap in the statusLine API right now.

I've built a custom statusLine script that squeezes every bit of available data out of the JSON payload (context window %, session tokens, cumulative tokens, model name, cost). I've pushed the current API to its absolute limit — and hit the wall hard when I tried to add quota visibility.

Why this matters so much

For Max/Pro subscribers, the most critical operational question is: "How many messages do I have left before I hit the rate limit?" — and today there is literally zero way to answer this programmatically. We get a surprise wall mid-task. That's not just inconvenient — it's actively destructive when you're deep in a multi-agent workflow (GSD, agent teams, etc.) where a sudden rate limit can cascade-fail an entire orchestration chain.

What I tried (and why it can't work today)

1. Parsing /usage output — Not available outside the REPL; no file, no env var, no hook.
2. Self-tracking via hooks — I can count tokens per session by logging statusLine calls to a file and computing rolling totals. But this gives me approximate self-tracked usage, not actual Anthropic quota data. It drifts, it doesn't know about other sessions, and it can't tell me the reset window.
3. Watching for rate limit errors — Reactive, not proactive. By the time you see the error, your workflow is already broken.

Proposed JSON extension (building on OP's excellent spec)

{
  "quota": {
    "plan": "max",
    "messages_used": 3,
    "messages_limit": 5,
    "window_hours": 6,
    "reset_at": "2026-02-19T18:00:00Z",
    "weekly_used_percent": 42.0
  },
  "context": {
    "used_tokens": 78000,
    "max_tokens": 200000,
    "free_percent": 61.0
  }
}

The context object is actually already partially available (context_window.used_percentage exists in the current JSON), but quota is completely missing. Even a minimal version — just messages_remaining and reset_at — would be transformative.

The community signal is clear

There are 11+ open issues requesting this same data in various forms (#9617, #13585, #15844, #18243, #22428, #22731, #25891, #26108, #26219, and more). This isn't a niche request — it's the most consistently requested statusLine enhancement across the entire issue tracker.

Would love to see this prioritized. The data already exists internally (the /usage command computes it) — exposing it to statusLine would unlock an entire ecosystem of custom dashboards, auto-pause scripts, and workflow-aware quota management.

I have done some workarounds based on cozempic and claude mem... aparently this is not a good business to Anthopic

https://github.com/cassiodias/rekall-hook/

@min-hinthar re: "zero way to answer this programmatically" -- there's actually a workaround now via the OAuth usage API. I built claude-lens that queries this endpoint in the background and shows 5h/7d remaining percentages plus a pace delta (whether you're burning faster or slower than expected given time remaining in the window). Async refresh with 5min TTL so the statusline never blocks.

~150 lines of Bash + jq, no runtime dependencies. Not a replacement for native support -- would love to see @renchris's proposed quota object in the JSON -- but it works today.

I'm trying to do some of the my side project and get myself into the same issue.

The most extreme case — line 118, a 4,807-character gap analysis document:

{
  "type": "assistant",
  "message": {
    "model": "claude-opus-4-6",
    "content": [
      {
        "type": "text",
        "text": "\n\nBased on the codebase exploration, here's the gap analysis...\n\n## Gap Analysis: SDK → automator-server Integration\n\n### What automator..."
        // ← 4,807 characters, ~1,374 tokens
      }
    ],
    "usage": {
      "input_tokens": 3,
      "cache_creation_input_tokens": 1632,
      "cache_read_input_tokens": 102744,
      "output_tokens": 2   // ← reported as 2 tokens. SO WRONG!!!.
    }
  }
}

Why This Happens?
My guts said claude code writes JSONL records in real time as the API streams. The usage object is populated from the API response metadata which arrives before the full output stream completes. By the time the complete text content is flushed into the record's content array, the usage.output_tokens value has already been written — capturing only what had been counted at that early moment. Claude Team should take it more seriously as IT WILL HAVE BIG IMPACT on any feature depends on usage metrics.

Built a partial workaround for the quota side of this while a proper statusLine solution ships.

A local proxy intercepts Claude Code's API traffic and captures the \^Gnthropic-ratelimit-unified-*\ response headers on every inference call, writing a one-line snapshot to \~/.claude/usage-status.md\. Pair it with a \UserPromptSubmit\ hook and the current 5h/7d utilisation gets injected into every prompt automatically — same effect as having it in the statusLine JSON, just via a different route.

https://github.com/InertiaUK/claude-quota-proxy