[BUG]: Usage telemetry/accounting is globally inconsistent (Opus-heavy usage not reflected; Sonnet exhaustion is a symptom)

The usage telemetry appears globally inconsistent across the dashboard (all models), and does not match my real usage pattern — especially Opus, which is my primary model.

The most visible symptom is Sonnet reaching 100% (exhausted), but the core issue is broader: the overall weekly consumption shown (and the distribution by model) does not reflect my actual activity.

Plan / Subscription

Max plan – target: ≤ $200/month

Problem

The usage dashboard is reporting weekly consumption levels that are incompatible with my observed usage, including:

• Overall weekly usage (all models) appearing inflated or inconsistent
• Opus consumption (my primary model) not reflecting my real interaction volume
• Model attribution and weekly exhaustion behavior that does not match my baseline pattern

In short: this is not “a Sonnet telemetry bug”. It looks like a general usage accounting / attribution issue.

Evidence (screenshot)

• Current session: 1% used
• Current week (all models): 88% used
• Current week (Sonnet only): 100% used (EXHAUSTED)

<img width="507" height="327" alt="Image" src="https://github.com/user-attachments/assets/b8d12e63-7e34-4710-9f37-a7e5e02565ab" />

Declared Usage Pattern (baseline)

• Primary model: Opus (~90% of all interactions)
• Sonnet: only via subagents (Task tool with model="sonnet" or haiku)
• Direct Sonnet prompts: none

Observed Anomalies

1. Total weekly usage appears inconsistent with real activity (possible inflation or incorrect accounting)
2. Opus usage does not reflect actual usage volume (under-counting and/or misclassification)
3. Sonnet reaches 100% exhausted even though Sonnet is used only minimally (likely misattribution, but not the whole story)
4. Weekly consumption appears to keep accumulating even during periods of no active usage

History / Regression

This did not occur in previous weeks.
The current behavior is inconsistent with my established Max plan usage history.

Impact

• Subagents (Task tool) cannot run due to Sonnet exhaustion
• Overall usage/cost visibility becomes unreliable
• Performance evaluation and troubleshooting become compromised
• Potential billing/quota discrepancy risk if the accounting is wrong

Request

Please investigate the entire usage accounting pipeline for the current week:

1. Audit consumption logs per model and total for this account (current week)
2. Validate model attribution logic (Opus vs Sonnet vs Haiku) end-to-end
3. Check for telemetry / tagging / aggregation issues (incorrect labeling or duplication)
4. Confirm whether usage can be registered without active user interaction (background/session artifacts)
5. Provide a breakdown explaining why the dashboard shows:

• 88% total weekly usage
• 100% Sonnet exhausted
• while my real usage remains Opus-heavy

Environment

• Product: Claude Code CLI (latest)
• Platform: darwin
• Terminal: cursor
• Version: 2.1.19
• Timezone: America/Sao_Paulo
• Report date: 2026-01-25
• Reset schedule:

• Sonnet resets Jan 27 @ 1:00 AM
• All models reset Jan 29 @ 12:00 PM
• Feedback ID: 922f09e4-a816-4820-b6b7-a1543441fb20

Additional CLI Errors Observed (possibly unrelated)

[{"error":"Error: ENOENT: no such file or directory, scandir '/Library/Application Support/ClaudeCode/.claude/skills'\n    at readdirSync (unknown)\n    at <anonymous> (/$bunfs/root/claude:12:1903)\n    at mW (/$bunfs/root/claude:11:35435)\n    at readdirSync (/$bunfs/root/claude:12:1864)\n    at ILR (/$bunfs/root/claude:2215:380)\n    at ILR (/$bunfs/root/claude:2215:1350)\n    at <anonymous> (/$bunfs/root/claude:2215:4440)\n    at <anonymous> (/$bunfs/root/claude:2215:5171)\n    at A (/$bunfs/root/claude:11:7259)\n    at FZ8 (/$bunfs/root/claude:4862:4342)","timestamp":"2026-01-25T18:43:49.779Z"},{"error":"Error: ENOENT: no such file or directory, scandir '~/.claude/skills'\n    at readdirSync (unknown)\n    at <anonymous> (/$bunfs/root/claude:12:1903)\n    at mW (/$bunfs/root/claude:11:35435)\n    at readdirSync (/$bunfs/root/claude:12:1864)\n    at ILR (/$bunfs/root/claude:2215:380)\n    at ILR (/$bunfs/root/claude:2215:1350)\n    at <anonymous> (/$bunfs/root/claude:2215:4483)\n    at <anonymous> (/$bunfs/root/claude:2215:5171)\n    at A (/$bunfs/root/claude:11:7259)\n    at FZ8 (/$bunfs/root/claude:4862:4342)","timestamp":"2026-01-25T18:43:49.779Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for ~/.local/share/claude/versions/2.1.19 (expected in multi-process scenarios)\n    at BUR (/$bunfs/root/claude:4003:2091)\n    at YkA (/$bunfs/root/claude:4003:1202)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-01-25T18:43:49.811Z"},{"error":"SyntaxError: JSON Parse error: Property name must be a string literal\n    at <parse> (:0)\n    at parse (unknown)\n    at <anonymous> (/$bunfs/root/claude:69:708)\n    at A (/$bunfs/root/claude:11:7259)\n    at EX8 (/$bunfs/root/claude:4307:5876)\n    at async SmB (/$bunfs/root/claude:4307:8662)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-01-25T18:43:50.591Z"}]