Claude Code user estimates subagent prompt caching raised spend by 8%

• farono's Reddit writeup parsed about 95 Claude Code sessions, 1,800 subagents, and 6.8B input tokens, then estimated subagent prompt caching made subagent prompt cost about 14% too high and total spend about 8% high.
• farono's cache analysis blamed cache writes, not extra model work: repeated static context was billed at cache-write rates instead of cache-read rates because volatile prompt pieces sat before reusable blocks and parent caches expired during child waits.
• rohanpaul_ai's pxpipe breakdown described a separate cost hack: render dense Claude Code context into PNG pages, where a 1928×1928 image costs about 4,761 vision tokens and can hold roughly 92K characters.
• gabriberton's caveat argued standard vision embeddings cannot carry high compression reliably, while torchcompiled's KV-cache note pointed out the extra engineering cost of converting already-generated text back into image-prefill context.
• dzhng's workflow post and simonw's note show the other live pattern: keep the expensive model in the planner, reviewer, or orchestrator seat, then delegate implementation to cheaper subagents.

farono's GitHub issue includes the local transcript parser behind the cache estimate. pxpipe ships the PNG-context proxy. DeepSeek-OCR is the research-flavored version of the same optical compression idea, reporting about 97% OCR accuracy below 10x compression and about 60% at 20x. simonw's note turns the same cost pressure into a model-routing pattern inside Claude Code.

farono measured Claude Code's local API logs across about two weeks of heavy nested-subagent use. The claim was billing-specific: the same context was being charged at cache-write rates instead of cache-read rates.

The reported sample:

• Sessions: about 95
• Subagents: about 1,800
• Input tokens: 6.8B
• Subagent prompt cost: about 14% too high
• Total spend: about 8% too high
• Typical subagent cold start: about 37K tokens
• Actual task text inside that cold start: about 950 tokens, or roughly 3%

The expensive part was the other 97%: system prompt, tool definitions, project rules, and other boilerplate that was nearly identical across same-type subagents.

farono split the waste into two structural misses, both visible in the Reddit writeup.

1. Subagent startup: each subagent resent about 30K tokens of static context. A 5-minute prefix cache expired between siblings, and volatile fields such as date, cwd, git branch, and injected reminders appeared early enough to invalidate the reusable prefix.
2. Parent wait: the parent agent blocked while a child ran. When the child took more than 5 minutes, the parent's cache expired, so the parent rewrote its full context when the child returned.

The parent-wait pattern was not a theoretical corner case. farono said 96% of observed parent cache deaths were real expirations clustered just past the 5-minute line.

The naive fix was worse in farono's model. Giving subagents a 1-hour cache increased cost by 8.6%, because 98% of cache reuse happened within about 34 seconds and the longer TTL mostly converted cheap short-lived writes into expensive long-lived writes.

The modeled fixes were narrower:

• 1-hour TTL right before dispatching a child: about 6% lower spend
• 1-hour TTL on the identical per-type static prefix, plus moving dynamic content after it: about 7.6% lower spend
• Same static-prefix change on cold starts: about 88% cheaper cold starts
• Default 5-minute TTL on the conversation tail: retained, because that part churned and was reread quickly

The underlying primitive is Anthropic's cache breakpoint API in Anthropic's prompt caching docs. farono's point was placement: which bytes get the long TTL mattered more than making every cache live longer.

pxpipe attacks the same cost surface from a different angle. It renders dense request-side text into PNG pages, then sends those pages as image blocks so the model reads the context through vision.

The reported packing math:

• One 1928×1928 image: about 4,761 vision tokens
• Dense page capacity: roughly 92K characters
• Target content: code blocks, logs, tool output, old chat turns, system prompts, and tool docs
• Untouched side: model output remains normal text

kimmonismus's comparison framed pxpipe as a local infrastructure hack, while DeepSeek treated optical compression as a model and architecture problem. The tradeoff is exactness: IDs, hashes, names, strings, and code details can survive semantically while failing byte-for-byte.

giffmana's CLIPPO reference pointed back to CLIPPO, a Google Research paper that rendered text as images and processed images and text through one vision-style encoder.

DeepSeek-OCR pushed the idea toward long-context compression. Its summary describes optical 2D mapping, a DeepEncoder core, and a decoder based on DeepSeek3B-MoE-A570M, with accuracy falling as compression rises.

borisdayma's VLM experiment said he had started a related experiment where the entire text prefix became an image, adapted from a CapPa codebase with text data only. borisdayma's follow-up described the intended effect as replacing text prefill with an image-only prefix.

The strongest objections were about where the compressed information enters the model.

• gabriberton's reply said LLMs could not handle much compression when visual features were passed as standard vision embeddings to the first layer.
• the same reply said higher compression would require injecting information into deeper layers.
• anderslie's objection expected a perception hit when the model attended to encoded image text instead of direct text tokens.
• torchcompiled's note separated user-provided text from generated text: generated text already occupies the KV cache, so converting it into images after generation would require removing that KV segment, rendering it, and prefilling again.

That makes pxpipe most plausible for bulky background context, not exact-string retrieval or frictionless replacement of all long-context memory.

The second cost pattern was not compression. It was role assignment across models.

dzhng's post used Fable-5 as planner, orchestrator, and reviewer, with Codex doing implementation work. dzhng's quota reply said an unoptimized flow could burn through a $200 Max plan in about 16 hours, while the split workflow looked roughly 5 to 10x cheaper on sparse early data.

The screenshot attached to dzhng's post attributed usage to three patterns:

• 100% from subagent-heavy sessions
• 88% from sessions active for 8+ hours
• 88% from sessions above 150K context

simonw's note described a lighter version: tell Fable to use its own judgment to choose an appropriate lower-power model in a subagent. theo's setup put the routing into CLAUDE.md, used Fable on high effort, treated xhigh as token hungry, and sent computer use or codebase analysis to other models.

GergelyOrosz's repost added the human check on the planner-coder-judge loop: when asked how errors were handled, the answer in the embedded thread was, "I read the code."

The cache discussion landed during a busy Claude Code agent release train. Claude Code's CHANGELOG.md lists 2.1.199 fixes for partial streaming output, subagent partial work after rate limits or server errors, and API errors being reported to the parent instead of marked successful.

2.1.200 changed the default permission mode to Manual across CLI, VS Code, JetBrains, and help output. It also made AskUserQuestion stop auto-continuing by default, fixed several background-session failure modes, and clarified that Grep is ripgrep-based.

The prompt surface kept moving too. the 2.1.199 metadata post reported prompt tokens up 9,972, or 20.6%, while the 2.1.200 metadata post reported another 4,817 prompt tokens, or 8.3%, with prompt files down by 3.