How did Spotify cut Claude Code token usage by 90%?

By intercepting large file reads before they happen and routing them to a cheaper worker model that reads the file in its own disposable context and returns only an answer. Hooks fire before every tool call: one blocks reads over a line threshold, 350 by default, and another routes code generation so output goes straight to disk without passing through the expensive model. Reported mean savings on bulk-read scenarios were around 90%, measured across four scenarios against a Java monorepo.

Why did instructions fail where blocking worked?

They tried rules as instructions first and it did not hold. Both engineers and the model found ways around soft guidance. A hard block at the routing layer worked because compliance stopped being a decision anyone could make. The general lesson is that any constraint you need enforced on an agent belongs in the architecture rather than the instructions.

What cannot be delegated to a cheaper model?

Editing, because the worker model summaries do not carry reliable line numbers, so precise edits still require the expensive model to read that section directly. And reasoning: the published example is a thread-safety bug the cheaper model missed, returning a summary that looked complete while being silent about what mattered. Each delegation also adds 10 to 30 seconds of latency.

Will the 90% saving apply to other teams?

Unlikely at that magnitude. The measurement is self-reported and shaped by one codebase: a Java monorepo with large files and repeated patterns, which is close to the best case for the technique. A codebase of small files with little repetition has less to route out of the context window. The mechanism generalizes, the percentage is a property of that workload.

Spotify's 90% Token Cut: Why Soft Rules Don't Hold

What did Spotify actually do? A principal product manager on their platform team published a Claude Code plugin that intercepts large file reads before they happen and hands them to a cheaper model, which reads the file in its own throwaway context and returns only an answer. Reported mean savings on bulk-read scenarios: around 90%, measured across 4 scenarios against a Java monorepo.

The number got the attention. The mechanism is the part worth keeping, and it is not a cost trick. It is a statement about where agent spend actually goes.

The finding under the number

Most of what an agent spends context on is tool output the expensive model never needed to see. It opens 5 files to answer a question about 1. It generates a boilerplate file as expensive output tokens, streaming every line through a frontier model, when the file could have been written to disk by something cheaper and never entered the transcript at all.

Stated that way it sounds obvious. It was not being fixed, because the natural place to look for savings is the prompt, and the savings were not in the prompt. They were in the moment before tool output enters the conversation.

The setup uses hooks that fire before every tool call. One checks file size and blocks any read over a threshold, 350 lines by default, redirecting it to the cheaper worker. Another routes code generation so the output goes straight to disk. In the write case the saving is structural rather than proportional: the expensive model never sees the generated code, so the cost is issuing the delegation rather than streaming a file.

The part that transfers is not the plugin

They tried the reasonable thing first. Rules as instructions. Tell the agent not to read whole files, describe when to delegate, put it in the guidance. It did not hold. Both engineers and the model found their way around soft rules, which is what soft rules are for.

What worked was a hard block at the routing layer. Not discouraged. Not suggested against. Blocked, at a level where compliance is not a decision anybody gets to make.

That is the transferable finding, and it generalizes past token costs. Any constraint you actually need enforced on an agent has to live in the architecture rather than the instructions, because instructions are advisory to a system that is optimizing for something else. This is the same reason permissions beat personas when you design an agent team, which I went through in Agent Teams for a Product Org.

What does not delegate

The write-up is unusually honest about its own limits, which is rare enough in this genre to be worth noting.

Editing does not delegate. The worker model's summaries do not carry reliable line numbers, so anything that needs a precise edit still requires the expensive model to read that section directly. Delegation buys understanding, not modification.

Reasoning does not delegate either, and the example given is a thread-safety bug the cheaper model missed. That is the failure mode of this whole pattern in one sentence: the worker returns a summary that is fluent, complete-looking, and silent about the thing that mattered. Nothing errors.

And it costs time. Each delegation adds 10 to 30 seconds. Whether that trade is worth it depends entirely on whether the person waiting is billing for the wait.

Does the 90% transfer to you

Probably not at that size, and the author does not claim otherwise. The measurement is self-reported and shaped by one codebase: a Java monorepo with large files and repeated patterns, where a 400-line config and a 380-line test fixture are unremarkable. That is close to the best case for this technique.

A codebase of small files and little repetition has less to shunt out of the window, and the ceiling drops accordingly. Which is the right way to read any published efficiency number. The mechanism generalizes. The percentage is a property of somebody else's workload.

Why a product person should care about a token bill

Because this is the internal version of a problem that is about to be the external one. The author cites a share of engineering leaders already spending several hundred dollars per developer per month on tokens, some well past that, and argues the trajectory puts AI coding costs on a collision course with developer salaries.

Treat the exact figures as one person's read of the market. The direction is not really in dispute, and it changes what a product decision is. When inference is the cost of goods, a feature that reads more context than it needs is not a UX choice, it is a margin decision made by someone who did not know they were making one. The same arithmetic decides what a free tier can be, which I worked through in The Free Tier Meets the Inference Bill.

The useful question after reading this is not which plugin to install. It is which of your tool calls are putting output into an expensive context window that nothing downstream ever needed, and whether anyone on your team has ever counted.