[BUG] 5-minute session exhaustion on Max plan using v2.1.87 with Claude in Chrome

Resolved 💬 5 comments Opened Apr 9, 2026 by hc-7000 Closed May 23, 2026

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?

I am experiencing catastrophic session exhaustion on a Max plan, hitting usage limits in as little as 5 minutes of light work. This is a distinct data point from the existing reports because I am running v2.1.87, not v2.1.88 or v2.1.89 where the suspected client-side regression was introduced.

This strongly suggests the token drain is server-side, not caused by the client binary regression identified in recent versions.

Session History (April 9, 2026)

| Session | Duration before limit hit |
|---|---|
| Previous sessions (baseline) | ~4h 30m – 4h 58m (normal) |
| Session 1 (yesterday evening, CET) | ~30 minutes |
| Session 2 (this morning, CET) | ~30 minutes |
| Session 3 (this morning, CET) | ~5 minutes |

The 5-minute exhaustion occurred at approximately 08:00–10:00 CET (02:00–04:00 PT) — well outside US peak hours (5am–11am PT), so peak-hour throttling does not explain this.

Work Performed During 5-Minute Session

The session that exhausted in 5 minutes consisted of:

  • A few JavaScript tool executions in the browser
  • Scrolling and screenshots
  • One bash command appending CSS to a file + Drupal cache rebuild via SSH
  • Two page navigations
  • Claude's own analysis text between steps

This is routine, lightweight Drupal CSS debugging work. There were no large file uploads, no extended thinking, no long document processing, no automated loops. The full session transcript is available and confirms minimal actual work was performed between the two limit triggers.

Why v2.1.87 Matters

I am pinned to v2.1.87 because it is the last version that supports the Claude in Chrome integration (with socket fix). Upgrading is not an option without losing that functionality.

Since v2.1.87 predates the suspected client-side regression in v2.1.88/2.1.89, and the drain is still occurring, this data point indicates the root cause is not solely a client binary bug. The server-side token accounting or quota calculation is misbehaving independently of the client version.

Related Issues

  • #41930 — Critical: Widespread abnormal usage limit drain since March 23, 2026
  • #41788 — Max 20 plan exhausted within ~70 minutes after reset
  • #38335 — Claude Max plan session limits exhausted abnormally fast since March 23

Ask

Please investigate whether the server-side quota calculation is correctly accounting for actual token usage, independent of the client version. A 5-minute exhaustion on a Max account performing lightweight browser automation work is not explainable by any legitimate token accounting.

What Should Happen?

A Max plan session should last approximately 4–5 hours of normal interactive work, consistent with Anthropic's published limits and my own baseline usage prior to March 23, 2026. Lightweight browser automation tasks — JavaScript execution, screenshots, SSH commands, page navigation — should consume a small and proportional fraction of the session quota. A 5-minute exhaustion on this class of work is not consistent with any reasonable token accounting for a Max plan subscription.

Error Messages/Logs

Steps to Reproduce

This issue may not be directly reproducible as it appears to be server-side. However, the conditions present during the affected sessions were:

Max plan subscription, Claude Code v2.1.87 with Claude in Chrome active
Continuing an existing project session (not a fresh conversation)
Performing lightweight browser automation — JavaScript tool executions, scrolling, screenshots, one SSH command with cache rebuild, page navigations
No large file uploads, no extended thinking, no automated loops

The same work pattern ran normally for 4h 30m–4h 58m in previous sessions on the same setup, ruling out the task type as the cause. The degradation appeared suddenly on April 9, 2026, with three consecutive windows exhausting in 30 min, 30 min, and 5 min respectively.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.87

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗