By ByteBot
Spotify Engineering published a post this week claiming their internal Claude Code plugin cut token usage 90% on a Java monorepo — and it hit Hacker News front page this morning, triggering the predictable debate. The plugin, called shunt, intercepts expensive file reads before they reach Claude and delegates the I/O work to Gemini 2.5 Flash. The idea: Claude handles the thinking, a cheaper model handles the reading. The 90% figure is real. Whether it applies to your workload is a different question.
How the Shunt Plugin Works
Shunt is a Claude Code plugin built on top of Spotify’s internal Portal platform, but the core mechanism is standard Claude Code infrastructure: PreToolUse hooks. Two hooks do the routing. The first, check-file-size, fires on every Read call. If a file exceeds 350 lines — configurable via SHUNT_MIN_LINES — the hook blocks the read and tells Claude to use the /bulk-reader skill instead. The second, check-bash-read, catches large file commands like cat, head, and tail. According to Spotify’s engineering blog post, mean bulk-read savings hit around 90% across their Java monorepo testing.
The delegation runs three layers. The hook layer intercepts. A bash wrapper calls the Portal CLI, which runs a Gemini 2.5 Flash mode at temperature 0.2 that returns structured bullets — no prose. Claude gets the summary, not the raw file. The third layer is a skill markdown file that tells Claude when and how to hand off work, with graceful fallback if routing is missed.
The genuinely interesting part is code-writer mode. When generating boilerplate, the output goes straight to disk without Claude ever seeing the generated code. Claude issues the instruction, Flash writes the file. That’s a meaningful architectural difference from simply routing subagents to a cheaper model — the expensive model’s context window is never loaded with content it doesn’t need. The full source is available in spotify/portal-ai-plugins on GitHub.
The Honest Math on That Claude Code Token Usage Claim
Here’s where the Hacker News discussion got interesting. “Saving 90% of input tokens is not the same as saving 90% of tokens, because output is wildly more expensive,” one commenter noted. They’re right. Claude Sonnet 5 currently prices input at $2 per million tokens and output at $10 per million — a 5x gap. If your session generates significantly more output than it reads, the savings collapse fast.
Run the math on a typical code-generation session: $100 in output, $30 in input. Saving 90% of that input ($27) drops the total from $130 to $103 — a 21% reduction, not 90%. The 90% claim holds for workloads dominated by bulk reads: exploring an unfamiliar Java monorepo, understanding a large dependency graph, summarizing hundreds of config files. For sessions that primarily generate code and explanations, the output side dominates and the savings shrink accordingly. Full pricing details are on the Claude API pricing page.
Spotify’s own results come from a Java monorepo context — exactly the read-heavy scenario where the math works. That’s an honest disclosure buried in the article. The headline could have been more precise, but the technique itself isn’t wrong.
Related: Cursor /multitask: Parallel Agents and the Cost You’re Not Tracking
What HN Got Right, and What It Missed
The skeptics who called this “standard multi-model setup” have a point — model routing to cheaper subagents has been standard practice for months. Most production Claude Code setups already use CLAUDE_CODE_SUBAGENT_MODEL=haiku to route exploration agents to Haiku automatically. However, that approach and shunt solve different problems.
CLAUDE_CODE_SUBAGENT_MODEL routes which model processes a task. It does not prevent file content from loading into the orchestrator’s context window first. Shunt intercepts before the read happens. The full file never enters any context. For a 10,000-line Java class, that difference is the entire point. The commenters who dismissed this as “not novel” were comparing it to the wrong thing.
The thread’s other valid objection: there are no accuracy benchmarks. The article discloses that the Flash model missed a subtle thread-safety bug that Claude caught with full context. How often that happens at scale is unspecified. For a production setup, that’s the number worth knowing.
When to Run Shunt, When to Skip It
Shunt is worth trying if your Claude Code sessions are dominated by bulk reads across many large files — Java monorepos, large Python services, legacy codebases where codebase exploration is the expensive phase. The 350-line default threshold means small scripts and configs pass through to Claude unchanged.
Skip it for debugging sessions where Claude needs full context to catch subtle bugs. Skip it for latency-sensitive interactive workflows — delegation adds 10 to 30 seconds per round trip, and Portal caps invocations at 30 seconds. Skip it if your sessions are already output-heavy; the math won’t move your bill enough to matter.
Key Takeaways
- Shunt works by blocking large file reads at the PreToolUse hook layer, before content enters Claude’s context — this is different from
CLAUDE_CODE_SUBAGENT_MODELrouting, which doesn’t prevent file content from loading - The 90% savings figure is real for read-dominated workloads like Java monorepo exploration; for output-heavy sessions, expect 20–30% at most
- Code-writer mode is the genuinely novel part: generated boilerplate goes straight to disk without Claude ever seeing it
- Missing from the article: accuracy benchmarks — the disclosed thread-safety bug miss is a red flag for debugging workflows
- The PreToolUse hook pattern works in any Claude Code project; adapting the approach doesn’t require Spotify’s Portal infrastructure
