[BUG] ~71% of a weekly budget consumed by Fable on an account active <24h with every model set to Opus 5 and zero Fable invocation paths — phantom usage or cross-account carry-over

Summary

An account I have been logged into for under 24 hours reports 17% of its weekly Fable-only limit consumed — with every model explicitly set to Opus 5, and no Fable invocation path active anywhere on the machine.

★ And Fable consumption counts against the overall weekly limit. The same panel shows 24% of All models used. So of my entire weekly budget, roughly 17 of 24 points — about 71% — were consumed by a model that never ran on this account. Approximately 7 points remain attributable to everything I actually did.

This is not a reporting curiosity. It took the capacity. I am now constrained to a lower tier for the rest of the week because the majority of my weekly allowance was spent by something I cannot find, cannot trace, and did not invoke.

Either usage is being attributed to a model that never ran, or usage from a different account is being attributed to this one after an account switch. Both are serious; I cannot distinguish them from the client, which is itself the problem.

What the usage screen shows

Current session      100% used   (resets in 2h 13m)
Weekly — All models   24% used   (resets Mon 5:59 AM)
Weekly — Fable only   17% used   (resets Mon 5:59 AM)

What I verified before filing

Configuration — no Fable anywhere:

• Project settings.json → "model": "claude-opus-5"
• User settings.json → "model": "sonnet"
• settings.local.json → no model key
• Agent definitions → no agent specifies Fable; the repo's own agent-authoring doc explicitly states Fable is not a valid frontmatter value

I set everything to Opus 5 deliberately when I switched to this account and checked it in each location.

Invocation paths — exactly one exists, and it is disabled:

• A single script in the repo hardcodes a Fable model id and passes it via --model on a CLI invocation. It is the only file in the entire repository containing that string (verified by repo-wide search across .py, .ps1, .bat).
• Its scheduled task is Disabled.
• Its last run was three days ago — and that run occurred while I was logged into a different account, so it cannot have billed this one.

Logs — no trace:

• No log written in the last 18 hours records a Fable invocation.
• The only files containing the string are a lock guard, a git backup log, and an audit log — all incidental matches, none an invocation record.

Timeline

• All week: logged into a different account. Not logged into this one at all.
• ~21:00–22:00 last night: switched to this account, out of usage on the other.
• On switching: set every model surface to Opus 5 and verified each one.
• Under 24 hours later: 17% of this account's weekly Fable limit is consumed.

★ LIVE CONFIRMATION — it is still accruing, and every running session reports a different model

Two hours after the reading above, without changing anything:

Weekly — All models   24%  ->  38%   (+14)
Weekly — Fable        17%  ->  29%   (+12)

12 of the 14 new points are Fable — roughly 86% of everything consumed in that window. This is not stale accounting from an account switch. It is accruing in real time.

I then enumerated every running Claude Code process: seven claude.exe sessions, none with --model on its command line (all inherit settings, which are Opus 5 / Sonnet).

I opened each of the seven and ran /model. Every one reports Opus or Sonnet. None reports Fable.

So, simultaneously and verifiably:

• Every session reports Opus or Sonnet.
• Every configuration surface specifies Opus 5 / Sonnet.
• The repository contains zero active Fable invocation paths.
• Fable is being billed, continuously, and is consuming the majority of the weekly budget.

This appears to be the same defect as #84028, where the CLI and the mobile app report different models for the same live session. That issue framed the mismatch as an observability problem. This shows the mismatch has a price: the model displayed and the model billed are not the same, and the customer is charged for the one they cannot see.

The two possibilities, both bad

1. Phantom attribution. Usage recorded against a model that did not run on this account. Every configuration and code path says Fable was never requested here.

2. Cross-account carry-over on switch. Usage accrued on the prior account being attributed to the account switched to. This would explain the number precisely — the prior account did run Fable work this week — and it would mean account switching corrupts usage accounting.

I cannot tell these apart from the client, because nothing in the product reports what consumed a tier.

Why this is hard to dismiss

Fable is the most expensive tier available to me. 17% of a weekly budget disappeared on an account that has never requested it, and there is no surface anywhere that would let me find out what spent it. I only discovered the discrepancy because I happened to open the usage screen; I found the single Fable-capable script by grepping my own repository.

This compounds an already-filed defect (#84028) where the CLI and mobile app report different models for the same live session. Between the two, there is no reliable way for a paying customer to determine which model ran, or what any given session cost.

What would resolve this

1. Per-invocation usage attribution. Show what consumed a tier: session id, timestamp, invoking surface (interactive / -p / scheduled / background), and requested model. This alone converts "17% vanished" into a five-second answer.
2. Confirm or rule out cross-account carry-over on switch. If usage can migrate between accounts at switch time, that is a billing-integrity bug independent of everything above.
3. Log the model actually served, not merely the model requested — so a mismatch is detectable from the client.

Environment

• Claude Code 2.1.223, Windows 11
• Multiple accounts; single machine; switched accounts ~12 hours before observing this
• Screenshot of the usage panel available on request