Spotify measured a 90% cut in bulk-read tokens by sending large file reads to a cheaper model

Image: Spotify Engineering
Why it mattersMost agent spending goes on reading code rather than writing it, so routing file reads to a small model cuts cost without changing which model does the reasoning.
Spotify published a write-up on 3 September describing a Claude Code plugin that intercepts large file reads and hands them to a cheaper model. Dimitri Mazmanov, a principal product manager at the company, reports mean savings of around 90% on bulk reads, measured across four scenarios in a Java monorepo.
The idea is narrow. When an agent answers a question that needs several large files, it pulls every line of those files into the context of a frontier model. Mazmanov describes that as feeding the work to a model that is "wildly overqualified" for it. The plugin catches those reads first.
Where the line sits
The default threshold is 350 lines. Files above it are shunted to a worker model, files below it are read normally, and the cutoff is configurable through an environment variable. Mazmanov gives the reason for having a floor at all: below it, the overhead of delegating costs more than the delegation saves.
Two modes handle the work, and both run on Gemini 2.5 Flash in the published examples, though the model field accepts anything configured in a Portal instance. The bulk-reader reads the files and returns structured bullets answering the question. The code-writer handles tests, config scaffolding and type stubs, the cases where the output follows a pattern already present in the repository.
Three things it does not do
The post is specific about the limits, which is the part worth reading. Editing is out, because the summaries the worker returns do not carry reliable line numbers. Reasoning is out, because the smaller models miss subtle bugs. And there is a latency cost: responses typically take 10 to 30 seconds, and Portal stops a single invocation at 30 seconds.
The 90% figure covers bulk reads only. Spotify says the code-write saving is harder to put a number on, because in that case the agent both reads the reference files and produces the output as expensive output tokens, so the two effects are mixed together.
The shunt plugin is Apache-2.0 and sits in the spotify/portal-ai-plugins repository, which had 71 stars when checked. The bulk-reader and code-writer modes are public rather than internal, and a team can fork the public bulk-reader and have its own version take precedence.
The measurement is Spotify's own, taken on Spotify's own monorepo, and the company says so. Four scenarios on one Java codebase is a starting point rather than a general result.
Still, the split it draws is the useful one. Reading code and reasoning about code are separate jobs that a single agent quietly merges, and only one of them needs an expensive model. A team that wants to check this does not need the plugin: measure what share of a normal session's input tokens came from file reads over a few hundred lines. If that share is large, the saving is available whatever tool captures it, and the cost of trying is a latency budget rather than a rewrite.
The trade is stated plainly enough to plan around. Ten to thirty seconds per delegated read is real time, paid on every large file, in exchange for tokens that were being spent to move text rather than to think about it.
Source
Portal by Spotify cut my Claude Code token usage by 90%, Spotify Engineering, 3 September 2026.
Source: Spotify Engineering
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually shipping with them. Short, and only when there is something worth reading.
