A gist published by Flamerix AI documents an undocumented behavior in Claude Code, Anthropic's coding agent: every roughly 30 seconds, for every background agent running, the tool resends that agent's entire transcript to its own model — usually Opus — and asks it to "describe your most recent action in 3-5 words." The answer only updates a status line in the agents panel; it never reaches the model's output or the user's conversation. There is no documented setting to turn it off, and the write-up says it has been on by default since Claude Code 2.1.232, released in August 2026.
The anomaly surfaced through Claude Code's own OpenTelemetry export, where grouping claude_code.api_request events by query_source showed a category called agent_summary outspending the primary conversation it was supposedly supporting. The gist attributes the detection to DRIM. In the week before a fix was installed, agent_summary accounted for 16.4% of Claude Code's own per-request cost estimate — versus 15.7% for the main conversation — and 19.7% of all API requests, about one in five; two days after the fix, both figures were zero. Of that spend, 96% ran on Opus, with an input-to-output token ratio the write-up puts at roughly 9,000:1, since each call resends a full transcript to extract a handful of words.
The write-up frames this as not isolated: it points to GitHub issue #86879, which it says collects four independent measurements putting the overhead at 18–26% of spend. Its own tracked timeline shows the share climbing from 3.5–7% in July, to 7.3% and then 11.8% after picking up version 2.1.233, to about 16% by mid-October — tracking the point at which the behavior moved from an SDK opt-in to default-on for interactive background agents.
The harder operational detail is visibility. These requests are not written to Claude Code's on-disk session logs — the gist cites issue #104358 — so only an OpenTelemetry export surfaces them; Anthropic's documentation on background token usage doesn't list the behavior, and the Agent View docs instead describe a separate, disclosed Haiku-class refresh. Any cost or audit tooling that reads session-log files rather than telemetry will undercount spend and miss that full transcripts are being resent on a timer.
There is no first-party kill switch. The documented SDK option, agentProgressSummaries, defaults to false, but the gist says the compiled bundle ORs that flag with other code paths that set it true, so the documented default changes nothing. Obvious environment variables don't help either: DISABLE_NON_ESSENTIAL_MODEL_CALLS doesn't appear in the binary at all, and CLAUDE_CODE_FORK_SUBAGENT=0 or CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 do stop the summary calls — only by disabling fork subagents or background agents entirely. The interval itself is server-controlled, clamped between 30 and 240 seconds since version 2.1.300, with no client-side value that disables it. A cheaper short mode — roughly 2,000 tokens of notes instead of the full transcript — shipped in version 2.1.310 but ships switched off.
The community workaround, no-agent-summary.js, is a Bun --preload script of about 70 lines that wraps the global setTimeout call the summary timer is armed through and refuses to arm any timer whose callback source contains a specific summarizer anchor string, leaving every other timer untouched. The author reports testing it on Linux against Claude Code versions 2.1.257 through 2.1.312, with one macOS (darwin-arm64) report confirming the same behavior; Windows is untested. The method is explicitly fragile — it matches on source text via Function.prototype.toString, so a renamed log line, a callback wrapped in fn.bind(), or a move to setInterval or a different timer API silently defeats it, which is why the write-up recommends re-running its verification steps after every Claude Code update.
For teams running Claude Code background agents against anything sensitive, the takeaway is to pull the OpenTelemetry export and check the query_source=agent_summary count before trusting either the cost dashboard or the on-disk session log, since this traffic shows up in neither.