[BUG] Anomalous cache read token consumption with agent-based workflows (19.5M tokens for a single fullstack feature)

Resolved 💬 3 comments Opened Mar 27, 2026 by innovajm Closed Jun 1, 2026

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?

Cache read token consumption is anomalously high when running agent-based workflows. A complete fullstack feature consumes 73% of the 5-hour Pro session quota, with 19,493,663 cache read tokens recorded. This started a few days ago with no changes to my setup. Equivalent API cost for one feature: ~$8.99, which is unsustainable for a Pro plan user.Token data for full fullstack feature:

Input: 6,481 | Output: 57,234 | Cache create: 603,669 | Cache read: 19,493,663
Pro quota consumed: 73%

Context management:

/clear executed before starting the workflow
Custom agents used: backend-developer, frontend-developer, code-reviewer
All agents defined in .claude/agents/

What Should Happen?

Cache read tokens for a complete fullstack feature should be in the 1-3M range.

Error Messages/Logs

Steps to Reproduce

Claude Pro plan, Claude Code v2.1.85, WSL Ubuntu 24, off-peak hours
Run /clear to start with a clean session
Execute a fullstack feature workflow in sequence:

/explore <feature>
/backend:enrich-us <feature> and /frontend:enrich-us <feature>
/validate-contracts <feature>
/backend:plan <feature> and /frontend:plan <feature>
/backend:develop <feature> and /frontend:develop <feature>
/sync-contracts
/backend:verify <feature> and /frontend:verify <feature>
@code-reviewer

Check token consumption with ccusage or /context
Observe cache read tokens in the 15-20M range and 70%+ quota consumption for a single feature

Additional context:
The setup has been heavily optimized for token efficiency (reduced CLAUDE.md from ~160 to ~35 lines, agents with isolated context windows, no redundant context loading). Despite this optimization, consumption is anomalous and appears to have started a few days ago without any changes on my end. The issue occurs during off-peak hours where double capacity is expected.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.85

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗