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

Status Open

Maintainer reply None cached

Activity 3 comments · opened Jul 14, 2026

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:

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.
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.

View original on GitHub ↗

3 Comments

fnr414-droid · 3 months ago

This was happening on the last weekend all along. Today in a very brief visual iteration of 180k tokens consumed, cache read skyrocketed to 26million tokens.

kcarriedo · 3 months ago

The multiplier effect you measured (each MCP tool call re-reading ~1M tokens of context) is a predictable consequence of how context works in long-lived sessions, but the "no warning" part is the actual failure mode worth fixing.

The math on your specific case: at ~800k-1M tokens of context, every screenshot/click roundtrip is a near-full-context read whether or not that history is relevant to the current action. The browser automation tool has no way to declare "I only need the last N exchanges, not the full 1M-token history." That's not a browser automation problem - it's a session scoping problem that just becomes visible first in MCP-heavy workloads.

Two things that would help:

Pre-flight context check before tool-heavy tasks. If the session is above some threshold (say 500k tokens), display the current context size and an estimate of per-action cost before the first MCP tool use. This is entirely implementable client-side.

Per-tool-type context budget declaration. Let the user (or the tool manifest) declare a max context window for a given tool category. When the session exceeds it, either compact first or warn + require explicit override.

The transcript analysis you did (reconstructing from ~/.claude/projects/**/*.jsonl) is the right approach for post-hoc diagnosis, but it should be surfaced in-session before you've burned the budget. The data is all there - it's just not shown until it's too late.

webby-box · 1 month ago

browser clicks inside a near-1M-token session silently multiply per-action cost — each screenshot round-trip re-reads the whole pile.

trim or fork before computer tool work. long-lived sessions + browser automation without a context reset is how 43M cache-read tokens happen in five minutes.