Spotify engineer reports a 90% cut in Claude Code read tokens by sending file reads to a cheaper model

Dimitri Mazmanov, a principal product manager at Spotify, published a write-up on 3 September describing how he cut the tokens Claude Code spends reading files. The technique intercepts large reads before they reach the expensive model and hands them to a cheaper one. He reports mean savings on those bulk reads of around 90%.

The number comes from his own testing, described in the post as a Java monorepo tested across four scenarios. The comparison measures the tokens Claude would consume reading files directly against the tokens it consumes reading a summary produced by the smaller model instead.

How the interception works

Three pieces do the work, all of them outside the model. A Claude Code PreToolUse hook watches file reads and blocks any file longer than a configurable line threshold, which defaults to 350 lines. The blocked read is redirected to what he calls bulk-reader mode, which runs on Portal, Spotify's internal platform for declarative agents on ephemeral runtimes. In the examples in the post, the worker doing the reading is Gemini 2.5 Flash.

The premise is that reading is not the part you are paying a frontier model for. A summary of a long file, produced by a cheap model, costs a fraction of the raw file and is usually enough for the agent to decide what to do next.

What the author says it cannot do

The post is specific about the limits, and they matter more than the headline figure.

Editing cannot be delegated, because the summaries do not carry reliable line numbers. Reasoning and debugging cannot be delegated either. Each delegation adds latency of roughly 10 to 30 seconds, and Portal caps a single invocation at 30 seconds, so a call that runs long is cut off rather than finished slowly. On small files the overhead costs more than the saving, which makes the line threshold the setting that decides whether the whole arrangement pays for itself.

Portal itself is internal. Running this as described needs access to a Portal instance and its CLI, so the post is a description of a pattern rather than something a reader outside Spotify can install today.

For scale, the post states that a quarter of engineering leaders already spend $200 to $500 per developer per month on tokens, and that some are well past $2,000. That figure is Spotify's own framing of the problem it set out to solve, and the post does not name a survey behind it.

The idea generalises past the specific tooling. Most agent harnesses now expose a hook at the point a tool call is made, which is the seam where a read can be caught and sent somewhere cheaper. Nothing in the approach depends on Portal, on Gemini, or on Java. What it depends on is accepting a summary in place of the file, and the honest cost of that trade is the one the author names: the agent can no longer edit what it only read in summary.

That trade is worth measuring on your own repository before adopting it, because the saving scales with how much of your agent's context is long files it barely uses, and that ratio differs sharply between a monorepo and a small service.

Source

Portal by Spotify cut my Claude Code token usage by 90%, Spotify Engineering, 3 September 2026.