Claude Code ignores standing rule to delegate lightweight ops to Haiku subagent — $110+ overcharge in a single session due to cascading context bloat

Resolved 💬 2 comments Opened May 11, 2026 by ns-gops Closed Jun 10, 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?

Environment:

  • Claude Code version: 2.1.128
  • Model: claude-sonnet-4-6 (us.anthropic.claude-sonnet-4-6)
  • Platform: Linux / AWS Bedrock

---
Standing rule established 2026-05-08:

A feedback memory file was committed on 2026-05-08 19:51 UTC, commit 3e734d3182bb11403dfa12e7ba35c07703e7b7c6, repo
github.com/ns-gops/claude-memory-dp2:

▎ Before any lightweight operation, delegate to the quick-tasks subagent (Haiku) rather than doing it inline on the main model.

Covered task types explicitly listed: file reads, grep/search, git queries, Confluence/Wiki page fetch and section extraction, JSON config lookups,
log parsing, build output scanning.

This rule was loaded into context at the start of every session. The model acknowledged it when challenged — but did not follow it across multiple
sessions from 2026-05-08 through 2026-05-11.

---
What happened:

All of the following were performed inline on Sonnet 4.6 despite the rule:

  • 10+ Confluence wiki page fetches (full HTML bodies, ~100KB+ each)
  • 15+ file reads and regex operations on HTML content
  • git log/diff/status queries, JSON config reads, log parsing

None were delegated to the Haiku subagent. [15/1949]

---
Why this is a two-level failure:

Level 1 — Wrong model per operation: Each op costs ~12× more on Sonnet than Haiku.

Level 2 — Cascading context bloat: By running ops inline, each result (100KB+ wiki HTML bodies etc.) accumulated in the main session context. Every
subsequent tool call then re-read that entire context at Sonnet rates. Haiku subagents run in isolated contexts — they complete and disappear,
nothing accumulates in the main session. Following the rule would have prevented the context bloat entirely.

---
Actual measured cost (from /usage, single session, ~8h active use):

┌───────────────────┬────────┬────────┬────────────┬─────────────┬─────────┐
│ Model │ Input │ Output │ Cache Read │ Cache Write │ Cost │
├───────────────────┼────────┼────────┼────────────┼─────────────┼─────────┤
│ claude-sonnet-4-6 │ 131.2k │ 1.3M │ 199.4M │ 11.2M │ $122.27 │
├───────────────────┼────────┼────────┼────────────┼─────────────┼─────────┤
│ claude-haiku-4-5 │ 241.3k │ 91.2k │ 6.4M │ 438.6k │ $1.89 │
└───────────────────┴────────┴────────┴────────────┴─────────────┴─────────┘

The 199.4M Sonnet cache read tokens are the smoking gun — that is context bloat from inline mechanical reads, not reasoning work. At Sonnet
cache-read rate ($0.30/MTok) vs Haiku ($0.03/MTok), that's 10× overcharge on cache reads alone (~$59 just in cache reads).

Estimated cost if the standing rule had been followed: ~$10–15 for the full session.

Estimated overcharge: ~$110+

This pattern repeated across ~5 sessions from 2026-05-08 to 2026-05-11.

---
Proof:

  • Git commit 3e734d3 in github.com/ns-gops/claude-memory-dp2 — tamper-evident timestamp, predates all affected sessions
  • /usage output screenshot showing $122.27 Sonnet vs $1.89 Haiku in same session
  • AWS Bedrock Cost Explorer showing daily Sonnet spend 2026-05-08 to 2026-05-11

Request: Refund or credit for the cost difference between actual Sonnet charges and what Haiku would have cost for the mechanical ops across
affected sessions.

What Should Happen?

Claude should have used the Haiku based rule to do what I had asked it to - see proof from claude session itself
The context bloat in cache seems to have repeated itself over and over again -- per claude's analysis as well.

ALl together I am being over charged here way too much

Error Messages/Logs

None

Steps to Reproduce

Not sure what steps to give u folks

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.128

Platform

AWS Bedrock

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Warp

Additional Information

This seems to be systemic - claude seems to ignore specific rules told to be followed

View original on GitHub ↗

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