H
pending
Spotify Open-Sourced shunt: A Claude Code Plugin That Routes I/O Work to Cheaper Models — and Enforces It
Grounded / Real
Inflated / Uruttu
Original Content
Spotify open-sourced a Claude Code setup that can cut bulk-read token usage by ~90%.
And the interesting part isn't the model.
It's the architecture.
Most coding agents waste expensive tokens on I/O-heavy work:
→ Reading 5 large files to answer 1 question
→ Scanning dozens of existing tests before generating 1 similar test
→ Copying boilerplate patterns into the context
→ Repeating information the main model doesn't actually need to reason about
Spotify's solution:
Don't make the expensive model do everything.
They built a Claude Code plugin called shunt that routes predictable, I/O-heavy tasks to cheaper worker models.
1️⃣ Bulk-reader
A cheaper model reads the large files and returns a structured summary.
Claude gets the answer, not thousands of lines of source code.
2️⃣ Code-writer
Give the worker:
→ A specification
→ A reference file
→ The expected output
It generates the boilerplate and can write it directly to disk.
Claude doesn't need to consume all those output tokens either.
3️⃣ The clever part: Hooks
Spotify initially put these rules in CLAUDE.md.
Problem?
They're just instructions.
Claude can ignore them.
So shunt adds a hard gate:
If Claude tries to fully read a file above a configurable threshold (350 lines by default), the hook blocks it and redirects Claude to the bulk-reader.
Targeted reads still work.
That's the important architectural lesson:
Don't just tell an AI agent how to behave.
Put enforcement around expensive behavior.
Spotify's benchmark on a 162K-line Java monorepo reported:
• 82% savings — single large file
• 94% savings — source + test pair
• 94% savings — multi-file analysis
• ~90% mean savings across bulk-read scenarios
There are tradeoffs.
❌ Don't delegate debugging
❌ Don't delegate architectural decisions
❌ Don't delegate precise editing
❌ Small files may not be worth the extra latency
But for repetitive I/O?
Use a cheap model as the worker. Keep the expensive model focused on reasoning.
This pattern goes way beyond Claude Code.
It's essentially:
Frontier model = reasoning
Cheap model = I/O + boilerplate
Hooks = enforcement
That's a much more interesting future for AI coding agents than simply throwing a bigger context window at the problem.
Spotify's plugin is open source.
Link in comments 👇
Source: Spotify Engineering + Spotify's portal-ai-plugins repository.
We're building 1% with AI - a community for people who want to go beyond simply using AI.
We share practical AI workflows, tools, experiments, and ideas for builders, developers, founders & students.
Follow 1% With AI if you want to learn how the 1% are actually using AI to build and work differently.
Most people use AI.
1% use it to think, build and work differently.
And the interesting part isn't the model.
It's the architecture.
Most coding agents waste expensive tokens on I/O-heavy work:
→ Reading 5 large files to answer 1 question
→ Scanning dozens of existing tests before generating 1 similar test
→ Copying boilerplate patterns into the context
→ Repeating information the main model doesn't actually need to reason about
Spotify's solution:
Don't make the expensive model do everything.
They built a Claude Code plugin called shunt that routes predictable, I/O-heavy tasks to cheaper worker models.
1️⃣ Bulk-reader
A cheaper model reads the large files and returns a structured summary.
Claude gets the answer, not thousands of lines of source code.
2️⃣ Code-writer
Give the worker:
→ A specification
→ A reference file
→ The expected output
It generates the boilerplate and can write it directly to disk.
Claude doesn't need to consume all those output tokens either.
3️⃣ The clever part: Hooks
Spotify initially put these rules in CLAUDE.md.
Problem?
They're just instructions.
Claude can ignore them.
So shunt adds a hard gate:
If Claude tries to fully read a file above a configurable threshold (350 lines by default), the hook blocks it and redirects Claude to the bulk-reader.
Targeted reads still work.
That's the important architectural lesson:
Don't just tell an AI agent how to behave.
Put enforcement around expensive behavior.
Spotify's benchmark on a 162K-line Java monorepo reported:
• 82% savings — single large file
• 94% savings — source + test pair
• 94% savings — multi-file analysis
• ~90% mean savings across bulk-read scenarios
There are tradeoffs.
❌ Don't delegate debugging
❌ Don't delegate architectural decisions
❌ Don't delegate precise editing
❌ Small files may not be worth the extra latency
But for repetitive I/O?
Use a cheap model as the worker. Keep the expensive model focused on reasoning.
This pattern goes way beyond Claude Code.
It's essentially:
Frontier model = reasoning
Cheap model = I/O + boilerplate
Hooks = enforcement
That's a much more interesting future for AI coding agents than simply throwing a bigger context window at the problem.
Spotify's plugin is open source.
Link in comments 👇
Source: Spotify Engineering + Spotify's portal-ai-plugins repository.
We're building 1% with AI - a community for people who want to go beyond simply using AI.
We share practical AI workflows, tools, experiments, and ideas for builders, developers, founders & students.
Follow 1% With AI if you want to learn how the 1% are actually using AI to build and work differently.
Most people use AI.
1% use it to think, build and work differently.
Validated Content
- Spotify open-sourced this; it's called shunt, lives in
spotify/portal-ai-plugins— confirmed. Published by Spotify Engineering (Dimitri Mazmanov, Principal PM), Sept 3, 2026, with the plugin on GitHub under the Spotify org. - Three-layer architecture: hooks → scripts → skills — confirmed exactly. Hooks fire on
Read/Bashtool calls before they execute; scripts (bulk-read,code-write) wrap Portal CLI calls; skills tell Claude when/how to invoke them. - Bulk-reader / code-writer modes, cheap worker model (Gemini 2.5 Flash in Spotify's example) — confirmed, matches the source article's exact mode definitions.
- CLAUDE.md instructions were tried first and failed because they're advisory, not enforced — confirmed directly from Spotify's own writeup: "The rules were advisory, not enforced. Claude could ignore them."
- 350-line default threshold,
SHUNT_MIN_LINESenv var, targeted reads pass through — confirmed exactly from the plugin's README. - Benchmark numbers (82%, 94%, 94%, ~90% mean, 162K-line Java monorepo) — confirmed precisely. Independent third-party analysis of the same benchmark data breaks it down as: a 4,014-line file → 82% reduction; a 7,408-line source+test pair → 94%; a 1,281-line multi-file task → 94%; producing the reported ~90% mean. These are Spotify's own published project measurements, not an independent audit — worth knowing, though the post doesn't misrepresent this (it just doesn't caveat it, see below).
- "Don't delegate debugging / architectural decisions / editing" — confirmed. Spotify's article explicitly states you can't delegate editing (no reliable line numbers from summaries) or reasoning (the worker missed a subtle thread-safety bug Claude caught).
- Small files not worth the latency — confirmed; Spotify notes each delegation round-trip takes 10–30 seconds, which is why the line threshold exists.
One nuance the post doesn't flag: these are Spotify's own self-reported project benchmarks against their own monorepo, not an independent third-party audit — several outside write-ups explicitly note this distinction ("project measurements published with the plugin, not an independent benchmark or a universal discount"). The post presents the numbers as settled fact without that caveat, which is a minor omission rather than an inaccuracy.