The Enforceable Half

The most interesting line in Spotify's write-up isn't the 90%.

It's the part where they admit they could only enforce half of their own rule.

Quick background, in case you missed it. Spotify open-sourced a Claude Code plugin called shunt. The premise is that most of what a coding agent does all day isn't thinking, it's reading files and writing boilerplate. So shunt intercepts that work and hands it to a cheap model instead of a frontier one. Dimitri Mazmanov, who wrote it up for Spotify Engineering, measured a mean 90% token saving on bulk reads in a 162,000-line Java monorepo. 82% on a single 4,014-line file. 94% on a source and test pair. (Basia Kubicka surfaced this one on LinkedIn, which is where I picked it up.)

Real result. But "Spotify cut their token bill by 90%" is a different claim than the one they made, and you should keep the two apart. The 90% is on bulk reads. Your bill depends entirely on how much of your workload is bulk reads. They also note 10 to 30 seconds of overhead per delegation, which makes the whole thing counterproductive on small files.

Anyway, the cost number is the least useful thing in the post.

The short version

Spotify's shunt plugin routes an agent's bulk file reads and boilerplate writes to a cheap model and measured a mean 90% token saving on bulk reads, with 10 to 30 seconds of overhead per delegation. The first version put the routing rule in CLAUDE.md and Claude ignored it, so they replaced advice with hooks that block reads over 350 lines. The finding worth keeping is that only the read path could be gated. Writing boilerplate is a judgment call, and a judgment cannot be enforced at a gate without doing the reasoning the gate was built to avoid. The rule under the rule: you can enforce what is observable at a chokepoint and decidable without the agent's reasoning, and everything else is advisory no matter how it is worded. And routing to a cheap tier is a trust decision disguised as a cost decision. Record which tier produced each fact.

Here's what I'd actually take from it. Their first version put routing rules in CLAUDE.md. Claude read them. Claude ignored them. So they threw out the advice and replaced it with a hook that blocks any read over 350 lines, plus a second hook that catches cat, head, tail, less, and more doing the same thing sideways.

Suggesting the rule didn't work. Enforcing it did. Fine, we've all learned that one by now.

You can gate an input. You can't gate a judgment.

Now the part I keep coming back to.

shunt has two delegation paths. bulk-reader, for reading files. code-writer, for generating boilerplate. The read path sits behind a hard gate. The write path doesn't. Their own README says it "relies on Claude recognizing when to use it," which is a polite way of saying it's a suggestion, and we just established what happens to those.

That's not an oversight. It's the shape of the problem.

A file read is observable before it happens. The hook sees a path and a line count and decides, no interpretation required. Writing boilerplate isn't like that. Whether a given piece of work is boilerplate or actual design is a judgment call, and you can't make that call at the gate without doing the exact thinking you were trying to avoid paying for.

So the rule underneath the rule: you can enforce something when the decision is visible at a chokepoint and doesn't require the agent's reasoning to make. Everything else stays advisory no matter how firmly you word it.

Three questions before you write a rule for an agent:

1. Is it observable at a chokepoint every call already passes through?
2. Can you decide it without the agent's reasoning?
3. If you get it wrong, is it cheap to reverse?

Two yeses and you can build a gate. Otherwise you're writing documentation and calling it governance.

That third question is the same one I put at the center of the harness argument last week. The gate that matters is never how confident the model is. It's how bad it is if the model is wrong and whether you can take it back. Spotify's read hook passes that test trivially: a blocked read costs you thirty seconds. A blocked design decision would cost you the design.

Where the gate goes

If you're building on someone else's agent runtime, you're stuck with shunt's architecture. Hooks, scripts, skills. Three layers, exactly one of them hard, because you're patching from the outside and the outside is all you've got.

If you own the runtime, you shouldn't be building a shunt at all.

Every model call in my own product already passes through a proxy, because that's where credentials get injected at call time. That proxy is the chokepoint. Routing policy belongs there, evaluated server-side as data, per tenant. No advisory half. No plugin. No markdown file politely asking the agent to behave.

The general version: your enforcement point should be somewhere calls already pass through for some other reason. Credential injection, egress filtering, audit logging, pick one. If you have to construct a new chokepoint just to enforce a rule, that's a good signal you're dealing with a preference and not a rule.

The bill nobody priced

One more thing, and I think this is the part that gets skipped.

Their cheap model missed a subtle thread-safety bug the expensive one caught in seconds. Most people read that as a caveat about code review, and for a coding agent that's roughly right. It's a bug. You find it later. Annoying, survivable.

But routing to a cheap tier isn't only a coding-agent move. The same logic lands on ingestion, summarization, extraction, anything that produces facts a system then keeps. And a fact produced by a cheap model is a different quality of fact than one produced by a frontier model, which is a different quality again from one a human confirmed.

Store all three at the same confidence and you've quietly turned a cost decision into a trust decision.

The fix isn't to stop routing. Route aggressively, it's real money, and for anyone running hosted multi-tenant AI it's not an expense line, it's gross margin. Just record which tier produced each fact and let that feed how much the system trusts it downstream. Cheap models are good at volume and bad at authority. Those should be two settings, not one. It's the same reason I argued that written context is rented: the record of where a fact came from and what happened when it was acted on is the part that compounds, and a cost-routing layer that throws it away is spending the moat to save the bill.

Same on verification. A cheap verifier can flag anything it likes. It should never be able to clear something that's expensive to undo.

Pick one thing this week. Take the rule you're most confident your agents are following, and go check whether anything actually stops them. Not whether it's written down clearly. Whether anything stops them.

If nothing does, you have a preference. That's allowed. Just know which one you're holding.

Sources: Dimitri Mazmanov, "Portal by Spotify cut my Claude Code token usage by 90%," Spotify Engineering (Sept 3, 2026) · shunt plugin README, spotify/portal-ai-plugins

This one belongs to the running argument on Enterprise AI Agents: what matters is what each completed outcome costs, and a routing layer that cuts the cost without recording what it did to the quality has only measured half of that.

Related answer: When can you actually enforce a rule on an AI agent?