[BUG] Billing API-default bug

[kghoff]

Preflight Checklist

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

What's Wrong?

Claude keeps defaulting auth to my Antropic Console API billing account instead of my claude.ai Max subscription. This has costed be hundreds of dollars in API spend, when I've had a max subcription the whole time. I know it's a bug because I've rerun /login several times and explicitly selected 'claude.ai' (pro, max subscription) and then checked via the /status (or /usage) command and it clearly keeps defaulting back to my Console API for billing, instead of my claude.ai subscription.

What Should Happen?

After running /login command, I select 'claude.ai' and then allow 'authorize' to run VS code using my claude code subscription. Then I should run /status and see that auth is through my subscription (right now it keeps defaulting to 'Anthropic API' for billing, even though I have a Max subscription).

Error Messages/Logs

Steps to Reproduce

I cannot reproduce the bug because I'm not sure if it's happening to other accounts. All I know is that my login keeps defaulting to Anthropic Console API when it should be running through my Max subscription instead.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.144

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Code uses API billing despite forceLoginMethod: claudeai setting #16489
2. [BUG] Claude Code silently uses project ANTHROPIC_API_KEY from .env instead of Max plan OAuth, causing unexpected API charges #58083
3. CLI silently uses API key instead of Max plan when ANTHROPIC_API_KEY is in environment #42680

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

[yurukusa]

This is the canonical shape of the "user intent loaded, system action diverges" failure — and the billing surface is the worst possible place for it to land, because the divergence costs real money silently. You did the right diagnostic dance (/login → select claude.ai → authorize → /status shows the wrong default) and the system still does not bind to the explicit selection.
The structural pattern, mapped to the broader cluster I've been tracking:

1. User intent is captured. You selected claude.ai at the /login prompt. The selection was acknowledged.
2. System state diverges silently. /status (or /usage) reveals the auth is routing through the Anthropic Console API for billing.
3. Recovery doesn't bind. Re-running /login reproduces step 1. The selection stage works in isolation. The persistence stage does not commit. The system silently reverts.
4. The financial cost accrues during the gap. Hundreds of dollars in API spend you didn't authorize.
   This sits alongside two recent open issues that name the same pattern at the same billing layer:

• #60096: tool failures continue to consume subscription quota.
• #60093: UI shows one thing, billing charges another (~$1,050 over three days).
  The combination — explicit user selection + silent system reversion + invoice arriving days later — is the worst-case shape for this family of failure. It's not a hallucination, not a typo, not a misread prompt. It's the system not respecting a written user choice.
  Immediate mitigations (until the bug is fixed upstream):

1. Verify before every long task. Run /status and /usage at the start of every session and after any error that might trigger a re-auth. If it shows the wrong default, refuse to run any high-cost operation until corrected.
2. Set a hard spend cap on the Anthropic Console API key. The Console dashboard has a per-key monthly spend limit; set it to a small ceiling (e.g. $10) so a silent reversion can't burn hundreds before you notice. This is the only mitigation that survives a silent reversion you don't catch.
3. Audit retroactive billing. Anthropic billing has a per-request log; if the dates of the unauthorized spend coincide with sessions where you'd selected claude.ai, file a refund request citing this issue number as the root cause. Anthropic has refunded misrouted spend in similar past cases.
4. Watch the /status output as a contract, not as a status. If it ever flips back to "Anthropic API" after you authenticated through claude.ai, treat that as a stop-condition for the session.
5. Hook-level guard. A PreToolUse hook that grep's the most recent /status output and refuses any Bash invocation (or any tool that triggers a model call) if the active auth is not the expected one. The hook is a one-screen bash script — I have a related pattern at https://github.com/yurukusa/cc-safe-setup that detects auth-state drift mid-session.
   Why this matters for the wider issue tracker:
   This is the eleventh issue I've seen this week where an explicit user choice loaded into the harness fails to bind to system behavior. The structural framework — "the rule is recognized but does not arrest the next action" — is documented at https://gist.github.com/yurukusa/b25ec5edc06ef6ec71e63d92b6e1e8ad. At the billing layer specifically, the divergence is irreversible without a refund process, which is what makes your report (and Model switched to Opus without consent or disclosure — five process failures, seven cost amplifiers, $1,050 overcharge on May 5-7 #60093, [Bug] Anthropic API Error: Rate Limited - Credit Consumed Without Review Generated #60096) the most financially serious instances of the pattern.
   Thanks for filing with the verbatim /status diagnostic and the loss figure ("hundreds of dollars"). The cost-attached forensic detail is what makes this filable as a hard bug rather than a vague "subscription not working" report.

[m13v]

I ran into this and the part that breaks down is the debugging loop itself. /login and /status both read the auth config you selected, not the billing path the server actually charged the turn to. so re-running /login and re-checking /status can keep agreeing with you while the spend still lands on the API account. the signal that doesn't lie is the subscription quota counter: if your Max 5h window and weekly quota sit flat while you're actively running Claude Code, you're billed through the Console API no matter what /status reports. watch the quota move, not the auth label.

[yurukusa]

@m13v — the "watch the quota counter, not the auth label" diagnostic is genuinely the cleanest signal here, and worth surfacing more explicitly because it bypasses the entire layer where the bug lives.

The structural reason it works: /login and /status both read from the user-intent layer (which config you selected and which the UI is willing to display). The billing path is a server-side routing layer. When the bug sits in the bridge between those two layers, every probe that reads from the user-intent layer agrees with the operator — selection acknowledged, status confirms — and the actual billing routing is a separate piece of state the operator can't read directly. Re-running /login re-affirms the user-intent layer; it doesn't reach down to the server-side routing.

The subscription quota counter is on the server-side. It moves if and only if the turn was routed through the subscription. So the test you're describing is structurally:

1. Note the current Max 5-hour window counter and the weekly counter.
2. Run Claude Code actively for a few turns (any non-trivial work that would normally consume quota).
3. Re-check both counters.

If the counters didn't move, the work was billed through the Console API regardless of what /status reports. This is a one-shot empirical answer that doesn't depend on the buggy probe.

A few additions that fit alongside this:

The same diagnostic works for the inverse case. Operators on a Max plan who expect to be on the Console API for a specific session (e.g., to use a feature gated behind API billing) can use the same counter-stillness test to verify the route. Quota counters tell the truth in both directions.

For operators tracking this across many sessions: the ~/.claude/projects/<project-id>/*.jsonl session logs record the per-turn cost telemetry locally. If you grep for sessions where costUSD is set, those turns were billed through the API; sessions where the cost field is absent (or zero) were billed through the subscription. This gives you a retrospective view across all your recent work, not just the current session.

The recovery problem you're describing is the worse half. Even with the right diagnostic, there's no operator-side mechanism to force-route to the subscription once the server has decided on the API. Re-running /login doesn't reset the routing decision; only restarting from a clean credentials state does. This is what makes the financial exposure structural rather than transient — the loop "select claude.ai → /status shows console API → /login again → /status still shows console API → keep working → hundreds of dollars later" is the exact failure mode that the read-only probes can't break out of.

This sits alongside #60096 and #60093 at the same billing layer — same pattern of user intent visible at one surface, server routing diverges silently, recovery doesn't bind. The counter-stillness test is the operational defense for all three until a server-side fix lands.

Thanks for sharpening the test — "watch the quota move, not the auth label" is the right phrasing for this.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.