[BUG] TaskOutput deprecation note causes agents to Read full sub-agent conversation history, triggering autocompact thrashing
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?
When a background local_agent task completes, the TaskOutput tool's deprecation message instructs the agent to Read the task's .output file directly:
DEPRECATED: Prefer using the Read tool on the task's output file path instead.
Background tasks return their output file path in the tool result, and you receive
a <task-notification> with the same path when the task completes — Read that file directly.
This guidance does not distinguish between task types. For local_bash tasks, the .output file contains stdout/stderr — reading it is appropriate.
For local_agent tasks, however, the .output file contains the full raw conversation history JSON of the sub-agent, which can be 80K+ characters.
The Agent tool already returns a summarized result directly when the task completes. But following the deprecation note, the agent reads the .output file anyway — injecting the entire sub-agent conversation dump into the main agent's context window. When multiple sub-agents run in the same session, this causes rapid context saturation and triggers autocompact thrashing.
What Should Happen?
The deprecation guidance should distinguish between task types:
- local_bash tasks: Reading the .output file is appropriate — it contains command stdout/stderr.
- local_agent tasks: The Agent tool result already contains the sub-agent's summarized output. The agent should not Read the .output file — it
contains the full conversation history JSON and will inflate the context unnecessarily.
Suggested fix to the TaskOutput prompt:
DEPRECATED: Prefer using the Read tool on the task's output file path instead.
- For bash tasks: Read the output file path to get stdout/stderr.
- For agent tasks: use the Agent tool result directly. Do NOT Read the .output file —
it contains the full sub-agent conversation history and will overflow your context window.
Error Messages/Logs
SDK AssistantMessage carries error=invalid_request | text_len=257
SDK API error (fatal): error=invalid_request |
raw={'content': [TextBlock(text='Autocompact is thrashing: the context refilled to the limit
within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output
is likely too large for the context window. Try reading in smaller chunks, or use /clear to
start fresh.')]}
The oversized Read that triggered the issue:
tool_call Read | input: {'file_path': '/tmp/claude-1000/.../tasks/aa8bd3ced112e5ae5.output'}
tool_result Read | ok | output: {"parentUuid":null,"isSidechain":true,"promptId":"747dfb10...",
"type":"user","message":{"role":"user","content":"In the repo at ... <- 87,286 chars
Comparison — Agent tool result vs .output file:
Agent tool return value : 4,087 chars (summarized result, appropriate)
.output file via Read : 87,286 chars (full conversation history JSON, 21x larger)
3 compacts each saving ~167K tokens, all triggered within the same turn:
SDK compact triggered: count=1 pre_tokens=167199 tokens_saved=167199 text=SDK auto compact
SDK compact triggered: count=2 pre_tokens=167883 tokens_saved=167883 text=SDK auto compact
SDK compact triggered: count=3 pre_tokens=167202 tokens_saved=167202 text=SDK auto compactSteps to Reproduce
- Use Claude Code (v2.1.92) with a long-running agent session.
- Launch a sub-agent using the Agent tool with run_in_background: true.
- When task_notification fires, observe the main agent immediately calling Read on the path /tmp/claude-1000/.../tasks/<task_id>.output.
- The file read returns the full sub-agent conversation history JSON (~87K chars per sub-agent).
- With 3+ sub-agents in one session, context fills to the 800K token compact threshold.
- After 3 consecutive compacts where context refills within a few turns each time, the SDK raises invalid_request: Autocompact is thrashing.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.92
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
10 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
It's not quite the same as these issues.
Affected since April 6 — two separate incidents, 74:1 and 175:1 input/output ratios, $21.69 consumed, account driven negative. Support ticket 215473797766657 open with no human response after 15+ hours. This has shut down my commercial operation for two days. No communication received from Anthropic about this known issue despite it apparently existing since March 23.
To everyone affected in this thread — Anthropic announced Project Glasswing today on LinkedIn, a $100M initiative to secure the world's critical software, partnering with Apple, Microsoft, Google and Amazon.
The announcement is here:
https://www.linkedin.com/posts/anthropicresearch_introducing-project-glasswing-an-urgent-activity-7447353390273114112-xy5y?utm_source=share&utm_medium=member_desktop&rcm=ACoAAGG3uFcBnFLDeZ6TCa348wNOzETNVMi5HyE
I've been documenting my case publicly in the comments — two days offline, 74:1 and 175:1 token ratios, $21.69 consumed, ticket 215473797766657 unanswered for 24+ hours. Video evidence of idle credit drain is now also posted.
If you've been affected and want Anthropic to hear real commercial impact — not just GitHub comments but on their most visible public announcement of the year — share your experience there. Your own words, your own case, your own experience.
We've done their debugging for them. The least they can do is answer us on the day they announce they're securing the world's critical software.
Not asking anyone to pile on — just making sure people know where the conversation is happening today.
New data point — bug confirmed firing on a manually disabled key
Adding to this thread as the behaviour has escalated beyond runaway sessions.
April 8, 2026 — Usage dashboard for key NEW_040626:
This is the fourth token spike on this account in three days. Previous ratios were 74:1 (Incident 1), 175:1 (Incident 2), and a platform authentication incident (Incident 3, Apr 7 14:32-15:12 UTC). Each incident has worsened.
The disabled-key consumption cannot be explained by #44703's TaskOutput deprecation loop alone — that requires an active session to trigger. This suggests either:
Support ticket 215473797766657 — no human response in 72+ hours. Flagging here in the hope of engineering visibility.
Happy to provide console screenshots or usage export data if useful.
<img width="1661" height="808" alt="Image" src="https://github.com/user-attachments/assets/76c2006e-5d45-434b-9104-0250d1c718f4" />
Critical update — hourly breakdown confirms server-side origin
Drilling into the 03:00 UTC hour on April 8 reveals the following:
Token usage chart (Image 1):
Rate Limit + Caching chart (Image 2) — this is the critical data:
A 100% cache rate coinciding precisely with the token spike means Anthropic's caching infrastructure delivered a massive cached context payload — 864,077 tokens — to this key in a single burst at 3:10 AM UTC.
This cannot be client-side. The key was disabled. There was no user session. No code was running.
Anthropics own caching infrastructure made calls against a disabled key at 3:10 AM UTC and billed the account holder for them.
This is no longer a bug report. This is a platform billing event originating from Anthropic's own infrastructure, charged to a manually disabled key, with zero user involvement.
Support ticket 215473797766657 — 72+ hours — zero human response.
Screenshots attached. Export data available on request.
<img width="1917" height="926" alt="Image" src="https://github.com/user-attachments/assets/17e2d280-f4f7-4a62-a6d2-814373b077f8" />
<img width="1919" height="635" alt="Image" src="https://github.com/user-attachments/assets/67ad9e41-1474-4f84-bf61-f69d6c9428f9" />
Independent expert validation — cache re-read mechanism identified
Following my earlier comments on the disabled-key drain, a Senior Cybersecurity and GRC Lead (ITIL v3 Expert) who has independently built a dashboard specifically to detect Anthropic billing anomalies (https://github.com/fgrosswig/claude-usage-dashboard) has provided the following technical explanation:
His assessment of the pattern across multiple affected accounts:
This provides an independent technical explanation for the 100% cache rate spike observed on my disabled key at 3:10 AM UTC April 8. The caching system is re-reading cached contexts repeatedly when interrupted, billing the full token count on each re-read rather than serving cached content at reduced cost. This explains:
A Sankey chart mapping expected vs actual token delivery is in development by the same researcher and will provide further independent evidence.
This is no longer a single-account billing dispute. This is a systemic platform billing integrity issue confirmed by independent technical analysis.
Support ticket 215473797766657 — now 96+ hours — zero human response.
v2.1.94 — New 'API Usage Billing' header — technical questions for engineers
Posting this as a technical observation following today's update to v2.1.94.
The CLI startup header now reads:
'API Usage Billing' has never appeared in this header before. Confirmed via grep across all historical session logs on my system:
This label appears for the first time in v2.1.94, released today with no changelog and no release notes.
Technical questions for anyone who can answer:
For context — this is the same account that recorded 864,077 tokens IN / 1,792 tokens OUT on a manually disabled key at 3:10 AM UTC April 8 with no active session. The 1M context aggressive loading on v2.1.94 startup may be related to the broader token inflation pattern documented in this thread.
Support ticket 215473797766657 — 96+ hours — no human response.
Screenshots available.
Closed as completed with no fix confirmation, no engineer comment, no explanation of the billing mode change in v2.1.94, and no response to the four technical questions posted today. Support ticket 215473797766657 remains unanswered at 96+ hours. Closing an issue is not the same as fixing it.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.