[Bug] Agent sessions retain context indefinitely, violating framework rules and consuming 51% of weekly quota in one day

Status Open
Reported on v2.1.285
Maintainer reply None cached
Activity 0 comments · opened Oct 5, 2026

Bug Description
Title: Multi-session Claude Code setup burned 51% of a weekly Max plan in one day. Root cause: an agent session kept ~780k tokens of context alive for three days, violating rules that were already written in the project's own framework. Summary Over the weekend of Oct 3-4, 2026, I ran four Claude Code sessions in parallel (one local, three cloud) plus a coordinator session to write and review product specs for a Next.js/Convex project. Weekly plan usage went from 41% at 10:13 to 92% at 22:00 the same day. Output for that spend: 47 specs approved out of 98 planned. I measured the cause afterwards from the sessions' own result events, and it was not "a lot of work". It was context that never got released. Measured data (from the session transcripts' result events, usage and modelUsage fields) - Session A (document writer, lived ~3 days without /clear): ~780,000 tokens of context re-sent on every tool call. Lifetime cache reads: 6,054 million tokens on Opus 5.5 plus 660 million on Sonnet 5.5. Output: 22 million tokens, 9.5 million of them thinking. List-price equivalent: about $2,290. - One single turn in that session, whose task was to transcribe two one-line decisions into two markdown files, cost 9.9 million tokens read across 13 tool steps. - Session B (started fresh that same day, same repo, same tools): ~340,000 tokens of context, 24 million tokens read in total for a full day of analysis work. List-price equivalent: about $12. - 90% of all reading happened on Opus, including purely mechanical tasks (merges, recounts, transcriptions), because subagents inherit the parent model when model is not set explicitly. What makes this worse The project's methodology (Fractik, in docs/fractik/) already stated, verbatim: - "The chat is disposable. Each session loads a small context package, does one thing, writes the result to disk and is discarded." - "Clear at every work-unit boundary and every gate boundary. The context must contain exactly one unit of work." Anti-pattern #2: "Not clearing between specs." - "Do not load the 8 documents in full. Minimal context package: CLAUDE.md, the spec, its tests, the referenced architecture sections." - "Sonnet for implementation and mechanical work; the strong model only for review and contracts." The agents had these instructions in context and did not follow them. Nothing in the tool enforced them, and nothing surfaced the problem until I asked a coordinator session to read the usage events by hand, 12 hours in. Why the agent behavior was unreasonable A human engineer with a 600 KB architecture doc, a 544 KB test inventory and a 165 KB amendment would read the relevant sections and keep notes. The sessions read the files in full, repeatedly, across subagents, and kept every byte in context for days. Common sense would have been: summarize what the task needs, work from the summary, close the session when the unit of work is done. The state files needed to do exactly that already existed in the repo. What I would like Claude Code to do 1. Show context size per session continuously (tokens re-sent per call), not just a usage percentage after the fact, and surface it in the cloud session list and in /status. 2. A configurable context budget per session (e.g. warn at 150k, block new tool calls at 250k until the user compacts or closes). A hook event on crossing the threshold would be enough for teams to enforce it. 3. Never let a subagent inherit an expensive model silently. Either require model on the Agent tool or print the effective model on every spawn. 4. Warn (or allow a built-in deny) when Read is called on a file larger than ~100 KB without offset/limit, and when Bash cats such a file without a filter. 5. Per-session and per-subagent cost attribution in the UI, so a coordinator can see which session is burning the budget without parsing JSON events. 6. Document how cache reads are weighted against the weekly limit. I could not tell whether 6 billion cache-read tokens counted at 10% or at 100%. 7. When a project's CLAUDE.md or framework docs contain an explicit "clear between work units" rule, the model should honor it or say why it is not. Silently ignoring a project's own operating rules is the failure here, more than any single expensive read. Impact A full weekend, roughly 51% of a Max weekly plan, for work that under the project's own rules should have taken a few hours. I now have to hand the project to a second developer's account to continue. I have written the enforcement (hooks, context packaging script, per-unit measurement) into the project myself, but these are things the tool should make visible and controllable by default.

Environment Info

  • Platform: darwin
  • Terminal: Apple_Terminal
  • Version: 2.1.285
  • Feedback ID: 278f6790-75bf-468c-a7e1-8e8b787246dc

Errors

[]

View original on GitHub ↗