[BUG] Opus subagents are being billed as Fable usage

<img width="829" height="615" alt="Image" src="https://github.com/user-attachments/assets/ccf91c9a-55dd-4de0-bdac-6882a2363baa" />
<br>
Same is happening with me and mine is even crazier it is using sonnet and haiku as subagents with opus to spawn them but some how my fable usage keeps on increasing and i hit 100% of session limit in 30 - 50 mins. I have even not yet tried Fable.

Im not really that smart or into this field at all and i know nothing about coding and just use claude but my usage just went to 100% on my first prompt because my fable also expired. This has been happening all week to, it would automaticly jump to 40%, 60%, etc. So weird.

Independent corroboration, and a clean before/after: closed a Fable session at 94% weekly usage, deliberately started a fresh session on Opus (not Fable) with a handoff doc so no Fable model was involved — and Fable-specific usage climbed to 97% anyway. Two exact percentage readings bracketing a period with no Fable session running at all. Matches the pattern described above exactly. This is also feeding into a usage-reset request on #67506, since it's one more data point on top of an already-documented burn-rate anomaly on that account.

Update — the escalation continues: 94% → 97% → now 99%, and this time with no Fable session open at all

Following directly from the last edit: after closing the Fable session at 94% and running Opus instead (which brought Fable-specific usage to 97% with no Fable model active), usage has now climbed to 99% with no Fable agents or sessions open whatsoever — not Fable, not the Opus session that preceded it, nothing currently running that the account holder is aware of.

If accurate, this is a step beyond #73597 (Opus subagents billed as Fable usage): that bug at least involves a model actually executing. A meter climbing with literally nothing running would mean the usage number is disconnected from actual activity entirely, not just mis-attributed to the wrong model. Flagging this as what it looks like from the outside, while being upfront that it needs verification (a stray background process still alive somewhere is a more likely explanation than a metering bug with zero cause, and that's actively being checked) — but three consecutive climbing readings (94/97/99) across decreasing and now allegedly zero Fable activity is a pattern worth someone with billing-pipeline visibility actually looking at directly, not just chalking up to normal drift.

I observe the same behavior, but I'm using Linux:

  Diagnostics
  ├ Currently running: native (2.1.150)
  ├ Commit: 28d4819e0f0a
  ├ Platform: linux-x64
  ├ Path: ~/.local/share/claude/versions/2.1.150
  ├ Config install method: global
  └ Search: OK (bundled)

Fable is being reported as used, but never used Fable. not using web/desktop/app, only Claude Code:

❯ /usage

───────────────────────────────────────────────────────────────────────────────────────────────────────
  Settings  Status   Config   Usage   Stats

  Session

  Total cost:            $3538.86
  Total duration (API):  1d 18h 53m
  Total duration (wall): 23d 16h 11m
  Total code changes:    77682 lines added, 21993 lines removed
  Usage by model:
       claude-opus-4-7:  389.8k input, 8.4m output, 6.0b cache read, 47.8m cache write ($3531.69)
      claude-haiku-4-5:  193.6k input, 186.1k output, 20.0m cache read, 1.7m cache write, 4 web
  search ($5.26)
     claude-sonnet-4-6:  59 input, 31.4k output, 2.0m cache read, 223.8k cache write ($1.91)

  Current session
                                                     0% used

  Current week (all models)
  ██████████████████████████████████████████████████ 100% used

But in the end, billing reports:

<img width="730" height="125" alt="Image" src="https://github.com/user-attachments/assets/3d52b36d-68d6-40cd-a399-f40f2da7b4bb" />

It has been going on for weeks, no answer from support, extra-usage consumed too ...

Bumping this to avoid automatic closure

Adding a second data point with token-level numbers, since I have a fairly clean case: ~62 hours with provably zero Fable calls, during which the Fable weekly bar climbed from 86% to 96%.

Environment: Claude Code v2.1.220, Windows 11, Max plan. Session model opus; heavy subagent and workflow use throughout the window.

Observed bars (Claude mobile, Usage screen):

• Current session: 0% used
• Weekly / All models: 57% used
• Weekly / Fable only: 96% used

Measured usage for the current weekly window, parsed directly from every *.jsonl under ~/.claude (tokens = output + input + cache_creation + cache_read):

| Model | Execution context | Calls | Tokens |
|---|---|---:|---:|
| Opus 5 | main session | 1,034 | 240,803,761 |
| Opus 5 | subagents + workflow agents | 1,528 | 126,041,103 |
| Fable 5 | main session | 145 | 24,145,755 |
| | | | 390,990,619 |

Fable is 6.2% of all tokens consumed this window, yet its bar reads 96%. The last Fable request on this machine was ~62 hours before the screenshot; a full sweep of every transcript on disk confirms zero Fable calls since.

Reconciliation. Taking Fable as burning ~2x Opus per token, plus the documented 50%-of-weekly Fable cap:

• All-models bar at 57% → implied weekly limit ≈ 728M units
• Fable cap (50% of that) ≈ 364M units
• Fable actually consumed: 24,145,755 tokens × 2 = 48.3M units
• Expected Fable bar: 13.3%. Observed: 96%. Discrepancy: 82.7 percentage points.

For the 96% reading to be internally consistent with the 57% all-models reading, Fable would have to burn ~81x Opus per token. That contradicts both the documented "uses them faster" framing and the ~2x figure.

The mismatch is robust to accounting assumptions — excluding cache reads entirely, Fable is still only 4.1% of consumption against a 96% bar.

Why this looks like the subagent attribution issue specifically. Closing the gap requires ~301M unexplained Fable units, which is ~150.6M Opus tokens billed at Fable's rate. My Opus subagent + workflow volume for this window is 126,041,103 tokens — roughly 84% of exactly that quantity. Both the order of magnitude and the direction match the report above.

I can't prove attribution from the client side; I only have local transcripts, not the server-side ledger. But the two bars are mutually inconsistent under any plausible weighting, and the residual lines up closely with subagent volume, which is consistent with Opus subagent usage being metered against the Fable quota.

Happy to provide the per-hour breakdown or the parsing script if useful.

Follow-up to my comment above. I ran a controlled reproduction with a measured input, which I think is the strongest evidence in this thread so far.

Environment unchanged: Claude Code v2.1.220, Windows 11, Max plan, session model opus, no subagent model override (no ANTHROPIC_* env vars at user or machine scope, no subagent model key in any settings file).

---

Controlled reproduction

Before: Fable weekly bar at 96%, all-models bar at 57%. Screenshotted.

Input: four concurrent Opus 5 research subagents. Measured directly from the transcripts on disk:

| Context | Calls | Tokens (output + input + cache_creation + cache_read) |
|---|---:|---:|
| Opus 5 subagents | 108 | 37,203,637 |
| Opus 5 main session | 32 | 6,637,796 |
| Fable 5 | 0 | 0 |

Zero Fable requests during the run, and zero in the ~62 hours preceding it.

After: Fable weekly bar at 100%.

Pure Opus subagent work moved a Fable quota by at least 4 percentage points. The bar clipped at 100%, so the true magnitude may be larger — 4 points is a lower bound, not a measurement.

Note the implied weight is below 1:1 against raw token count (4% of the cap on 37.2M tokens), which suggests cache-read tokens are discounted in limit accounting rather than counted at full rate. That doesn't change the direction of the finding.

---

Enforcement behaviour at 100% differs from #73870

Unlike the report in anthropics/claude-code#73870, hitting 100% Fable did not block Opus work on this account:

• A subsequent Opus 5 subagent (14 tool uses, 44,692 tokens, 165s) completed normally. No error, no stop_reason: "refusal", no fallback to another model, no usage-credits prompt.
• /model fable was also accepted at 100% and saved without complaint. Caveat: the model was switched back before any inference request was issued on Fable, so this shows the selection is not gated — it does not establish whether a Fable request would have succeeded.

So on this account the fault presents as metering/attribution, not enforcement. The quota is consumed by work that never touched the model, but nothing is blocked. That may be a version difference (v2.1.220 here vs v2.1.198 in #73870), a platform difference (Windows vs macOS), or the two faults may be independent.

---

On the burn multiplier

The 2x figure used in my earlier reconciliation is now confirmed against published pricing rather than inferred: Fable 5 at $10/$50 per MTok against Opus 5 at $5/$25 — exactly 2x. The 82.7-percentage-point discrepancy in my previous comment rests on that number.

---

Summary

A measured 37.2M-token Opus-only subagent load, with zero Fable calls before or during, moved the Fable weekly quota from 96% to 100%. Before/after readings, per-context token counts, and the null Fable count are all directly measured rather than reconstructed. Happy to share the parsing script or the per-hour breakdown.

Resolving the open caveat from my previous comment.

I noted that /model fable was accepted at 100% but that this did not establish whether a Fable request would actually succeed, because I switched back before issuing one. I have now tested it: a basic request on Fable 5 at 100% quota is refused, reporting weekly Fable usage exhausted.

So enforcement is active and model-specific:

| At 100% Fable quota | Result |
|---|---|
| /model fable selection | Accepted, saved without complaint |
| Fable 5 inference request | Refused — weekly Fable usage exhausted |
| Opus 5 subagent request | Succeeds normally (14 tool uses, 44,692 tokens, no error or fallback) |

This is worth correcting in one respect: the quota state is not a display artifact. It is real and it is enforced. The fault is in attribution — Opus subagent tokens are consumed against the Fable quota — and the enforcement then correctly applies to a quota that was wrongly exhausted.

Net effect on this account: Opus work is unaffected, and Fable 5 is unavailable until the weekly reset despite my having made zero Fable requests in the period that exhausted it.

This also partially reconciles with anthropics/claude-code#73870. That reporter was blocked from Opus by a Fable limit; here only Fable is blocked. Same underlying misattribution, different enforcement surface — possibly a version difference (v2.1.220 here vs v2.1.198 there).

Adding a macOS / Max 20x data point with a complete local and second-machine transcript audit.

Environment

• Claude Code 2.1.220
• macOS 26.5.2 (arm64)
• VS Code extension and CLI
• Max 20x plan using claude.ai OAuth
• Weekly reset: Jul 31, 2026 at 5:00 PM PDT (2026-08-01T00:00:00Z)

Account meters at the audit snapshot

• Current session: 3%
• Weekly, all models: 52%
• Weekly, Fable: 100%

Every locally recorded request after that reset, deduplicated by request/message ID

| Served model in transcript | Calls | Cache-inclusive input tokens | Output tokens |
|---|---:|---:|---:|
| claude-sonnet-4-6 | 134 | 4,734,385 | 122,612 |
| claude-opus-5 | 67 | 14,094,168 | 103,185 |
| claude-haiku-4-5-20251001 | 6 | 150,350 | 3,561 |
| claude-fable-5 | 0 | 0 | 0 |

Cross-reset consistency check using the same deduplication method

| Weekly reset window (PDT) | Deduplicated Fable calls | Cache-inclusive Fable input | Observed Fable meter outcome |
|---|---:|---:|---|
| Jul 10, 5 PM → Jul 17, 5 PM | 1,663 | 366,013,522 | Did not reach 100% |
| Jul 17, 5 PM → Jul 24, 5 PM | 1,580 | 405,515,022 | Did not reach 100% |
| Jul 24, 5 PM → Jul 31, 5 PM | 68 | 15,098,282 | Reached 100% |
| Jul 31, 5 PM → audit snapshot | 0 | 0 | Reached 100% |

Method: scanned 1,559 ~/.claude/projects/**/*.jsonl files and deduplicated 17,321 historical request/message IDs. Duplicate assistant records with the same request/message ID were collapsed, retaining the maximal final usage record when streamed copies differed. The Mac mini used by the same workflow was audited separately and also recorded 0 Fable requests after the reset. The last locally recorded Fable request on either audited machine was 2026-07-25T02:04:44Z, nearly seven days before the current reset.

I understand local transcripts cannot observe server-side-only Claude surfaces. That is the point of this report: the account-level Fable meter reached 100%, but neither audited Claude Code installation contains a corresponding Fable request. This is consistent with the other reports in this thread that Opus/Sonnet work is being attributed to the Fable quota or that the Fable meter is disconnected from the served-model records.

Please compare the server-side usage ledger against the served message.model, product surface, and authorization/session identifier. The account identifiers, support ticket number, and security-sensitive details are being provided privately through Anthropic Support, not in this public issue.

<img width="1600" height="900" alt="Image" src="https://github.com/user-attachments/assets/22cf76e8-61fe-47a8-99f9-15c885344a04" />