[BUG] Inconsistent usage-credit behavior between Claude Code terminal and web chat (Max 20x): CC accumulates cost but does not debit credits

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single report
• [x] I am using the latest version of Claude Code

Summary

On a single Max 20x account, usage-credit consumption behaves differently
between two interactive surfaces, in the same week, with the weekly
"all models" limit at 100%:

• Web chat (claude.ai, Opus 4.8): consumes usage credits normally — balance

drops and triggers auto-recharges.

• Claude Code (terminal): /usage shows ~$531 of consumption and the footer

reads "Now using usage credits", but the usage-credit balance does NOT
decrease and no matching charge appears.

Environment

• Plan: Max 20x (individual)
• Claude Code version: 2.1.173
• Surface A: claude.ai web chat — model Opus 4.8
• Surface B: Claude Code in terminal (remote server, SSH + tmux); session

started in Fable 5 (1M context), auto-switched to Opus 4.8 mid-session by
safety measures

• Timezone: America/Sao_Paulo

Limit state at time of report (same account)

• Current session: 55% used
• Weekly "all models": 100% used (resets Jun 13, 5am)
• Weekly "Sonnet only": 0% used
• Usage-credit balance: R$27.18, auto-recharge ON (recharge to R$30 at R$20)
• Claude Code /usage shows the line: "Included in your plan limits until

Jun 22, then switch to usage credits to continue."

<img width="952" height="1003" alt="Image" src="https://github.com/user-attachments/assets/30d4c70c-52e4-4216-8427-6935b45f9f17" />

Claude Code /usage (live session)

• Total cost (gross meter): $531.42 over ~14h API time
• By model: Fable 5 $433.69, Opus 4.8 $96.90, Haiku 4.5 $0.84
• Footer: "Now using usage credits" / "/rc active"

<img width="949" height="955" alt="Image" src="https://github.com/user-attachments/assets/e1ebfb80-80a9-4cd0-934b-3a8a52c1dfa6" />

Observed behavior

• Web chat reduces the credit balance and generates auto-recharge invoices

(multiple, all "Paid", line item "Auto recharge extra usage, Individual plan").

• Claude Code does NOT appear to reduce the credit balance, despite the footer

declaring "Now using usage credits" and /usage accumulating cost.

<img width="949" height="955" alt="Image" src="https://github.com/user-attachments/assets/c46376d4-d8be-4ec1-a5fa-77ae20ad72f1" />
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/26220904-0ab4-41cb-84f1-dff9dbac00ad" />

Expected behavior

For two interactive surfaces on the same account, usage-credit accounting
should be consistent. If a surface declares "Now using usage credits" and
accumulates billable consumption beyond the included limit, that consumption
should reduce the credit balance — or be transparently covered, and then NOT
declare "using usage credits". One surface debiting credits while the other
declares credit use but does not debit is inconsistent.

Possible expected explanation (asking for confirmation)

This may be intended rather than a defect: if the "Included until Jun 22"
grant applies to the Claude Code surface but not to interactive web chat,
CC would run covered (no debit) while web chat overflows to credits. If so,
please confirm — and consider surfacing the distinction in the UI, because
"Now using usage credits" plus a non-moving balance is confusing.

Deciding signal

Whether the Claude Code /usage top line currently reads "Included until
Jun 22" (→ coverage, expected) or "Now using usage credits" with a balance
that does not move after CC activity (→ inconsistent).

What Should Happen?

On the same account, usage-credit accounting should be consistent across
interactive surfaces. If Claude Code declares "Now using usage credits" and
/usage accumulates billable cost, that consumption should be reflected in the
credit balance (visible after a manual page refresh) — just as web chat
consumption is. Alternatively, if the Claude Code surface is covered by a
separate grant (e.g. "Included until Jun 22") and should NOT consume credits,
the session footer should NOT display "Now using usage credits". The declared
billing state and the actual balance movement must be consistent.

Error Messages/Logs

Steps to Reproduce

1. Be on a Max 20x plan with usage credits enabled and a non-zero balance.
2. Reach 100% on the weekly "All models" limit.
3. Open claude.ai → Settings → Billing, press F5 to refresh, record the exact credit balance and take a timestamped screenshot.
4. Use only Claude Code for ~10 minutes of real work (no web chat open in parallel). Confirm the session footer shows "Now using usage credits" and that /usage is metering growing cost.
5. Return to Settings → Billing, press F5 again, record the balance and take a timestamped screenshot.
6. Observe: the balance is unchanged despite Claude Code having metered consumption and declared credit usage.
7. For contrast: send a few messages in the claude.ai web chat, press F5 on Billing — observe that the balance does decrease and triggers an auto-recharge.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.173

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Session setup

This Claude Code session was started via a single SSH command that opened
tmux and launched Claude Code in one line:

ssh -t user@server tmux new -A -s egac \; send-keys "claude" Enter

After ~6h, the local SSH connection dropped. The tmux session remained alive
on the remote server (confirmed via ps aux: PID 804764, user ccv3, 151min
CPU time as of reconnect). The session is also visible and interactive in the
claude.ai web UI and the Claude Code mobile app.

Background agents stuck for 16h+

At time of report, the claude.ai web UI showed 3 tasks under "Em execução"
(In Progress) with runtimes of 16h 24min, 10h 57min, and 2h 12min. These
agents appear to have completed their work (the session was at the final
verification gate) but the UI never transitioned them to "Concluído". The
session was continuing to accumulate cost ($531 → $545 between two /usage
readings ~20min apart) despite appearing to be at a terminal gate.

This may be relevant: a long-running detached session with stuck background
agents could affect how the billing surface is attributed — credits may be
debited to the tmux/server context rather than the interactive web surface,
which would explain why the web Billing page does not reflect the consumption.