[BUG] Weekly + Fable scoped meters deplete 1.7-5x faster since Aug 17 reset on Max 20x; OAuth token carried rateLimitTier default_claude_max_5x

Related: #79773, #65678, #69430, #52135, #54714 — but **not upgrade-related**. My account has been Max 20x for months with no plan change, so this is not limited to mid-cycle upgrades.

## What's Wrong?

Since the weekly window reset on **2026-08-17 05:00 CDT**, both of my weekly meters are depleting far faster per token than in the four preceding weeks, against a below-median workload.

**Fable scoped meter (`weekly_scoped`)** — all figures deduped by `requestId` from `~/.claude/projects/**/*.jsonl`, with Fable filtered on the `message.model` field:

| week starting (CDT) | Fable requests | Fable cache_read | ever blocked from Fable? |
|---|---|---|---|
| 2026-07-20 | 2,192 | 633,534,178 | no |
| 2026-07-27 | 1,660 | 600,401,256 | no |
| 2026-08-03 | 1,799 | 647,047,147 | no |
| 2026-08-10 | 1,422 | 582,975,002 | no |
| **2026-08-17** | **77** | **19,128,570** | **16% consumed** |

Four consecutive weeks at 583–647M cache-read tokens without ever being blocked, then 19.1M reads 16%. Applying the current rate to those prior weeks yields **490–840%** depending on which measured rate is used — impossible under any of them.

**General meter (`weekly_all`) is also affected:**

```
last week: 2,851M cache_read = 100% of cap -> 28.5M per 1%
this week: 214M cache_read = 13% -> 16.5M per 1%
=> at least 1.7x faster per token
```

**Controlled measurements the same day, at small context** (rules out any long-context effect; the >200k surcharge was removed 2026-03-13 anyway):

```
78k-context subagent: 1,602,345 cache_read -> exactly 1 percentage point
154k-context session: 3,860,926 cache_read -> exactly 2 percentage points
```

Today was a **below-median** workload: 214M cache_read versus a 303M median day over the preceding six weeks.

### Possibly related: OAuth token carried the wrong rate-limit tier

My Claude Code credential (macOS keychain, service `Claude Code-credentials`) carried:

```
rateLimitTier: default_claude_max_5x
```

while `/api/oauth/profile` returned:

```
organization.rate_limit_tier: default_claude_max_20x
organization.subscription_status: active
```

Logging out and back in reissued the token as `default_claude_max_20x`, so the two now agree. **The token can carry a tier that disagrees with the organization's entitlement with no upgrade involved.**

**Important caveat:** correcting the tier did **not** fix the metering. A 702,407-token Fable burn immediately after re-authenticating still moved the scoped meter a **full percentage point** (~0.70M/point), versus 1.20–1.60M/point before. So either the corrected tier does not propagate to the meter, or the tier claim is cosmetic and the depletion has a different cause. Reporting both because the mismatch is objectively real and reproducible, but I can't claim it as the cause.

## What Should Happen?

Weekly and scoped meters should deplete at a rate consistent with the account's actual entitlement and with prior weeks' behaviour for the same workload. Four weeks at ~600M Fable cache-read tokens per week without being blocked, followed by 19.1M consuming 16%, is a ~5x change in metering with no corresponding change in usage.

The OAuth token's `rateLimitTier` should also match the organization's `rate_limit_tier`.

## Error Messages/Logs

```
Raw /api/oauth/usage (2026-08-17):

{"kind":"session","group":"session","percent":5,"is_active":true}
{"kind":"weekly_all","group":"weekly","percent":14,"resets_at":"2026-08-24T10:00:00Z","is_active":false}
{"kind":"weekly_scoped","group":"weekly","percent":16,"resets_at":"2026-08-24T10:00:01Z",
"scope":{"model":{"id":null,"display_name":"Fable"}},"is_active":false}

Keychain credential BEFORE re-login: rateLimitTier: default_claude_max_5x
Keychain credential AFTER re-login: rateLimitTier: default_claude_max_20x
/api/oauth/profile (both times): organization.rate_limit_tier: default_claude_max_20x
```

No error messages are produced — the meters simply advance faster than the token counts justify.

## Steps to Reproduce

1. Read the current scoped meter:
```bash
TOKEN=$(security find-generic-password -s "Claude Code-credentials" -w \
| python3 -c 'import sys,json; print(json.load(sys.stdin)["claudeAiOauth"]["accessToken"])')
curl -s https://api.anthropic.com/api/oauth/usage \
-H "Authorization: Bearer $TOKEN" -H "anthropic-beta: oauth-2025-04-20" | python3 -m json.tool
```
2. Run a bounded Fable workload at small context (I used a subagent doing ~20–25 tool calls at ~78k context).
3. Measure the exact tokens consumed from the session transcript, **deduplicating by `requestId`** — streaming emits ~2.6 records per API call, so raw record counts overstate usage ~2.6x:
```python
# per assistant record with message.usage, keyed by requestId
# sum cache_read_input_tokens / cache_creation_input_tokens / output_tokens
```
4. Re-read the meter and divide tokens by the change in percentage points.

Observed: **~0.7–1.6M cache_read tokens per percentage point.** Compare against prior weeks, where ~600M cache_read tokens per week never exhausted the same meter (which implies ≥5.8M per point).

To check the tier mismatch specifically:
```bash
security find-generic-password -s "Claude Code-credentials" -w \
| python3 -c 'import sys,json; print(json.load(sys.stdin)["claudeAiOauth"]["rateLimitTier"])'
# compare against organization.rate_limit_tier from /api/oauth/profile
```

## Claude Model

Fable 5 (`claude-fable-5`) for the scoped meter measurements; Opus 5 for the general meter. Both meters affected.

## Is this a regression?

Yes — the four preceding weekly windows metered consistently; the change appeared at the 2026-08-17 reset.

## Last Working Version

Not version-linked as far as I can tell — the change coincided with the weekly window reset rather than a Claude Code upgrade. Metering was normal through the window ending 2026-08-17 05:00 CDT.

## Claude Code Version

2.1.233 (Claude Code)

## Platform

Claude subscription (Claude Max 20x)

## Operating System

macOS 26.5.1 (build 25F80)

## Terminal/Shell

Ghostty / zsh

## Additional Information

Ruled out locally before filing:

- Hidden or concurrent Fable sessions — verified machine-wide across all transcripts
- `requestId` double-counting — `iterations` arrays reconcile to 0.998x of top-level usage
- Server-side tool use — `server_tool_use.web_search_requests` / `web_fetch_requests` all zero
- Prompt-cache misses — 96.07% cache hit rate last week
- Extra-usage credits — `extra_usage.is_enabled: false`
- Long-context surcharge — removed 2026-03-13, and the small-context measurements above are well under any threshold
- Opus/Sonnet/Haiku counting against the scoped meter — 45M of Opus moved the Fable meter 0 points

The meter itself behaves correctly otherwise: it responds promptly, is not a rolling window, and held flat across 27 minutes of zero Fable traffic while the 5-hour meter advanced on Opus work.

Happy to provide per-week and per-day token counts, the raw `/api/oauth/usage` responses, or re-run any measurement.

Start by running the documented curl requests to /api/oauth/usage and /api/oauth/profile, then inspect ~/.claude/projects/**/*.jsonl with requestId deduplication. Compare token totals with percentage changes for the weekly_scoped and weekly_all meters, and verify the credential's rateLimitTier against the organization response. Done means the metering discrepancy and tier mismatch have a confirmed cause and reproducible validation.

索引モデルが issue の本文から書いたものです。