[BUG] Issue: Session (5hr) usage limit exhausted within minutes on a lightweight document-edit task

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?

The 5-hour session usage limit is being exhausted in approximately 3–10 minutes on tasks involving minimal work — specifically, inserting a set of already-written review comments into a plain markdown document (no code review, no analysis performed by Claude). This happened immediately after a full window reset, with no /compact ever run in the session. It was reproduced twice in a row under identical conditions: full reset confirmed via the reset countdown, fresh session, same type of lightweight task, limit hit again within minutes. A later occurrence hit the limit in under 3 minutes with almost no visible work done.

What Should Happen?

A lightweight, mechanical document-edit task should consume a proportionally small fraction of the 5-hour Pro plan usage window, not the entire window within minutes. Usage consumption should scale with the actual work performed. The /usage "what's contributing to your limits" breakdown should reflect the task actually requested, rather than attributing 100% of usage to long-context sessions when the session itself was short-lived and freshly started.

Error Messages/Logs

`/usage` output:

Plan: Claude Pro
Session (5hr): 100% — Resets in 4h
Weekly (7 day): 31% — Resets in 6d

What's contributing to your limits usage (Day):
100% of your usage was at >150k context
"Longer sessions are more expensive even when cached. /compact mid-task, /clear when switching to new tasks."


`/context` output captured from one of the affected sessions:

claude-opus-5[1m] — 425.9k / 1.0M tokens (43%)

System prompt:     3.7k   (0.4%)
System tools:      25.1k  (2.5%)
MCP tools:         8.3k   (0.8%)
Custom agents:      2.7k   (0.3%)
Memory files:       6.5k   (0.6%)
Skills:             6.0k   (0.6%)
Messages:          391.2k  (39.1%)
Free space:        556.6k  (55.7%)

`Messages` (391.2k) is roughly 60x the combined size of all fixed overhead categories (system prompt + system tools + MCP tools + custom agents + memory files + skills ≈ 6.5k), despite the task being a small, mechanical document edit.

Steps to Reproduce

Open Claude Code (VS Code extension, inside a Devcontainer) on a Claude Pro plan, model claude-opus-5 / claude-opus-5[1m].

1. Start a fresh session (no /compact run in this session).
2. Request a simple task: insert a set of pre-written review comments into an existing plain markdown document.
3. Observe the 5-hour session usage limit reached within approximately 3–10 minutes.
4. Wait for the full reset window to elapse (confirm via the reset countdown, not assumed).
5. Repeat steps 2–4 with a similarly small task — limit reached again within a similar timeframe.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

vscode extension: v2.1.227

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

• Environment: Claude Pro plan; Claude Code VS Code extension + Devcontainer; models observed: claude-opus-5 and claude-opus-5[1m]; custom CLAUDE_CONFIG_DIR in use (non-default .claude-iglobal).
• Ruled out during investigation: parallel/multiple terminal sessions (confirmed single window only); carried-over quota from a previous window (full reset confirmed before each retry); the Opus model itself as sole cause (many prior Opus sessions of comparable or larger scope completed normally without issue); document format overhead (file is plain markdown, not .docx/.pdf); an explicit hook that triggers a subagent (none found in project or global settings).
• One of the affected sessions was found to have executed a large amount of unrelated infrastructure work not requested by the user — filed separately as a related issue, since it may be a contributing cause to this session's abnormal usage consumption, but represents a distinct failure mode (instruction-following, not usage accounting).