[BUG] Abnormal Session Limit Drain Since Opus 4.8 Rollout (May 28, 2026) — VSCode Extension, Pro Plan, Windows

Preflight Checklist

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

What's Wrong?

Since the Opus 4.8 rollout on May 28, 2026, the 5-hour session limit on Claude Pro is being exhausted after 1–2 prompts, compared to the previous behavior of sustaining 2–3 hours of active coding with the same workload.
Observed Behavior (Post May 28)

Resumed a coding session from the previous day (same VSCode chat context).
Single prompt consumed approximately 60% of the session limit.
Switched to Claude Sonnet 4.6 to conserve usage.
A small React UI change (minor component update) consumed the remaining ~40%, hitting 100% and triggering the usage limit immediately.
Total productive prompts before hitting the limit: 2.

What Should Happen?

Normal coding sessions on the same project (C# backend + React frontend) lasted 2–3 hours without hitting the session limit.
Both Opus and Sonnet models behaved within expected usage bounds.
Workload, prompt complexity, and project size are unchanged.

Error Messages/Logs

//

Steps to Reproduce

Open an existing long-running VSCode Claude Code chat session (multi-day).
Send one coding-related prompt (e.g., a feature request or bug fix for a C# / React project).
Observe session limit indicator jump to ~60%.
Switch to Sonnet and send one small UI change prompt.
Session limit reaches 100% immediately.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Before 4.8 Release

Claude Code Version

2.1.158

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

The jump from normal usage to limit-exhaustion in 2 prompts is not explained by conversation history length alone, as the same long-running session was used for days prior without this behavior.
The issue coincides exactly with the May 28, 2026 Opus 4.8 release and the simultaneous Claude Design shared-pool change — making it unclear whether this is a token-counting regression, a cache invalidation issue, or a side effect of the shared usage pool rollout.
Similar abnormal drain patterns were previously reported in #38335 and #41930 following the March 23 quota changes. This appears to be a recurrence tied to the May 28 rollout.
support.claude.ai is currently unreachable (DNS_PROBE_POSSIBLE) as of May 30, 2026, making it impossible to file a support ticket through the official channel.