Browser automation in near-1M-token sessions silently burns extreme token volume (~43M cache-read tokens / 5 min) with no warning

Summary

Browser automation (claude-in-chrome MCP computer tool) running inside a long-lived session with near-maximum context (~800k–1M tokens) silently multiplies per-action cost by an order of magnitude. Three sessions on my machine each consumed a large fraction of my plan's usage allowance in minutes, and from the user's point of view it looked like the model "went berserk." Nothing in the UI warned that each click/screenshot round-trip was re-reading ~1M tokens of context.

I analyzed my local session transcripts (~/.claude/projects/**/*.jsonl) to reconstruct what happened. Data below.

Environment

• Claude Code desktop app on Windows 11 Pro (10.0.26200)
• Models involved: claude-opus-4-8 and claude-fable-5 (mixed within sessions)
• Tooling: claude-in-chrome MCP (computer screenshot/click actions)
• Max-tier subscription

What the transcripts show

Three sessions spiked on the evening of 2026-07-11 (times UTC). All three were multi-day sessions that had accumulated very large contexts, then started browser-automation work:

| Session (prefix) | Peak 5-min window (UTC) | computer calls in window | Max per-msg cache_read_input_tokens | Cache reads in 5 min |
|---|---|---|---|---|
| 0c8a1688 | 2026-07-11 21:15 | 63 in ~20 min | 992,004 | ~43.5M |
| 18d636fd | 2026-07-11 22:20 | 48 in ~30 min | 887,239 | ~28.9M |
| 354fada2 | 2026-07-11 04:40 | 34 in ~25 min | 765,545 | ~27.9M |

Session 0c8a1688 totals (2026-07-07 → 2026-07-13, ~1,928 assistant messages): 2.72M output tokens, 18.3M cache-write tokens, 844M cache-read tokens.

Two compounding factors:

1. Every browser action re-reads the full context. 47 tool round-trips in 5 minutes × ~925k tokens context = ~43M cache-read tokens in 5 minutes. Screenshots also grow the context quickly and permanently.
2. Model switching mid-session thrashes the prompt cache. Sessions mixed claude-opus-4-8 and claude-fable-5. Since the cache is per-model, each switch forced a full ~1M-token cache re-write at the 1.25× write premium. I observed 5-minute windows with 2.3M–2.9M cache_creation_input_tokens from only 6–7 messages.

Why this is a problem

Individually, every charge is working as documented (cache reads ~0.1×, writes 1.25×, per-model caches). But the composition — high-frequency tool loops × near-full context — produces burn rates the user has no visibility into. A single "set the filter on this page" request can cost 20× more in a 950k-token session than in a fresh one, and the UI gives no signal before or during.

Suggested improvements (any of these would have saved me)

• Warn (or require confirmation) when starting browser-automation / computer-use loops in a session above some context threshold (e.g. >200k tokens).
• Surface a live burn-rate indicator when per-turn cache_read_input_tokens is very high, or when a 5-minute window exceeds a sanity threshold.
• Warn on mid-session model switches in large-context sessions that the prompt cache will be fully re-written.
• Consider auto-suggesting /compact (or a fresh session) before entering a screenshot-heavy tool loop.

Happy to provide sanitized transcript excerpts or run diagnostics if useful.