Engineering & AI SaaS
Spotify Cut Claude Code Token Costs 90% With a Two-Model Router (2026)
A Spotify engineering post went semi-viral this week for a claim that sounds too clean: route the boring parts of a Claude Code session to a cheap model and cut token spend by 90%. It's not a trick, it's a config change, and the same team was refreshingly upfront about what it breaks. Here's the mechanism, the honest failure modes, and how to steal the idea without Spotify's internal platform, plus where a directory like SaaSCity fits into a week this news-heavy.

Contents (9)
- Why a 90% number on token usage is worth your attention this week
- What Portal and AiKA Modes actually are
- The shunt plugin: how routing gets enforced instead of just suggested
- What "90%" actually measured
- What doesn't work, and why the honesty here is the actual story
- What a solo founder can copy today, with or without Portal
- What to route and what to keep on the frontier model
- Where SaaSCity fits into a week like this
- The thing worth watching next
A team at Spotify found out its AI coding assistant was spending most of its expensive thinking budget on reading files it didn't need to think about. So they built a bouncer for it.
That's the whole idea, and it's the reason "Portal by Spotify cut my Claude Code token usage by 90%" spent September 3-4, 2026 climbing the Hacker News front page — 168 points, roughly 80 comments, plenty of them arguing about whether the number is real. It is real, with real caveats the author didn't hide, and it points at a bigger problem than one team's token bill.
Quick disclosure since you're on a startup directory's blog: SaaSCity is a free, human-reviewed directory with a live city map where builders list their products. I write about engineering trends like this one because they change what a solo developer can afford to build, and token costs are squarely one of those. Nothing in this post is sponsored by Spotify or Google. More on where SaaSCity fits near the bottom.
Why a 90% number on token usage is worth your attention this week
Here's the context that makes this land: token spend on AI coding tools is turning into a real budget line, not a rounding error.
Gartner's research, covered by DevOps.com on June 30, 2026, found that roughly a quarter of technology leaders already spend $200 to $500 per developer per month on AI coding tokens, and about 6% report spending more than $2,000 per developer monthly. Gartner's headline prediction is blunter: by 2028, spending on AI coding agents is on track to surpass the average software developer's salary. Read that twice. The tool could cost more than the person using it.
Spotify's own post leans on the same numbers to set up its argument, and the framing is worth stealing even if you ignore everything else in the piece: most of what a coding agent burns tokens on is not thinking. It's I/O. Claude reads five files to answer a question about one method. It generates a test file that's structurally identical to the twenty sitting right next to it in the same directory. A frontier model is wildly overqualified for that kind of work, the same way you wouldn't hire a senior architect to alphabetize a filing cabinet. Routing that work to something cheap isn't a compromise on quality. It's just correctly sized.
What Portal and AiKA Modes actually are
Portal is Spotify's internal developer platform, the same lineage as Xirp, the multi-agent runner Spotify open-beta'd in August 2026. The piece of Portal that matters here is something Spotify calls AiKA Modes: declarative agents that run on an ephemeral runtime. The author's own comparison is the clearest explanation — think AWS Lambda, but for agents. You write instructions, pick a model, set a temperature, optionally attach MCP tools, and Portal handles spinning it up and tearing it down. No server to babysit, no infrastructure to own.
The post ships two of these modes as public, reusable examples, both configured identically underneath:
| Mode | What it does | Worker model | Temperature | When to use it |
|---|---|---|---|---|
| bulk-reader | Reads the files you point it at and answers your question in concise, structured bullets, no greetings, no prose, no preamble | gemini-2.5-flash | 0.2 | Understanding what a batch of files does before deciding whether to touch them |
| code-writer | Generates code from a spec plus a reference file, matching the reference's existing patterns exactly, output only, no markdown fences, no explanation | gemini-2.5-flash | 0.2 | Boilerplate that already has twenty near-identical siblings in the codebase |
Both modes are public and shareable inside AiKA, meaning any team using Portal can reuse them without rebuilding the prompt from scratch. That reusability detail matters more than it looks — it's the difference between "one engineer found a clever trick" and "the org has a repeatable lever."
The shunt plugin: how routing gets enforced instead of just suggested
A mode is useless if Claude never calls it. That's the actual engineering problem the post solves, and it does it with a small, install-and-go Claude Code plugin called shunt, public on GitHub under spotify/portal-ai-plugins on an Apache-2.0 license. Install is three commands:
claude plugin marketplace add spotify/portal-ai-plugins
claude plugin install portal@portal
claude plugin install shunt@portal
Then /portal:setup in a fresh Claude Code session. The design is three layers, and each one covers for the layer below it failing:
Layer 1, hooks. A PreToolUse hook called check-file-size intercepts Claude's own Read tool and blocks any call on a file over 350 lines by default, configurable through SHUNT_MIN_LINES. A second hook, check-bash-read, catches the same move when someone tries to dodge the Read tool entirely with cat, head, tail, less, or more on a large file. It's specific about what counts, too: a piped command like cat file | grep pattern still goes through untouched, because that's already a targeted read, not a dump of the whole file into context.
Layer 2, scripts. Bash wrappers around the Portal CLI do the actual delegation: bulk-read --question "..." --paths file1.java file2.java for the reader mode, code-write --spec "..." --reference existing-file.java --target new-file.java for the writer. Each call is one-shot and ephemeral. Nothing gets stored server-side between invocations.
Layer 3, skills. Markdown files whose descriptions teach Claude when and how to reach for the scripts in the first place. This is the layer that makes the system self-driving rather than something a developer has to remember to invoke manually.
The part worth noticing is that the system degrades gracefully. If Claude ignores the skill and tries to read the big file anyway, the Layer 1 hook still blocks it. The enforcement doesn't depend on the model behaving well — it depends on the hook, which is a much safer thing to depend on.
What "90%" actually measured
Spotify tested this against a real Java monorepo across four scenarios, comparing tokens Claude would consume reading files directly against tokens spent consuming the bulk-reader's summary, plus a code-generation scenario measuring the same tradeoff for writing rather than reading. Mean savings on the bulk-read scenarios landed around 90%. In the code-write scenario, the win is structural rather than just numeric — Claude never sees the generated code at all. It goes straight from the worker model to disk, so the token cost of "generating this file" drops to whatever it costs Claude to issue the delegation call, not the cost of streaming an entire file through a frontier model's context window.
That number is a real measurement, not a marketing round-up. It's also a number tied tightly to one codebase's shape: lots of large files, lots of repeated patterns, the kind of monorepo where a 400-line config file and a 380-line test fixture are unremarkable. Your mileage depends on how much of your own codebase looks like that versus how much of it is small, dense, and load-bearing.
What doesn't work, and why the honesty here is the actual story
Most vendor posts about a cost-cutting trick stop right after the good number. Spotify's didn't, and that's the part that made the Hacker News thread interesting instead of dismissive.
Three limits, stated plainly in the source:
You can't delegate edits. A worker model's summary doesn't reliably carry line numbers. If Claude needs to change something based on what the cheap model found, it still has to go back and do a targeted read with offset and limit before touching the file. Delegation buys you understanding, not editing rights.
You can't delegate reasoning. The concrete example is a thread-safety bug. The worker model scanned the code and reported the surface-level patterns. It missed the bug entirely. Claude caught it in seconds once it looked at the same code directly. That's not a tuning problem you fix with a better prompt. It's the actual capability gap between a fast, cheap model and a frontier one, and it's exactly why the pattern excludes debugging, architectural decisions, and anything safety-critical from the routing table.
Latency adds up. Every delegation is a network round-trip, typically 10 to 30 seconds, and Portal caps a single invocation at 30 seconds, so a large generation has to be split rather than crammed into one call. Below a certain file size, the overhead of delegating exceeds whatever tokens you'd have saved by doing it yourself. The threshold exists because the pattern has a floor, not because more routing is always better.
The Hacker News crowd pushed on all of this, and some of the pushback was fair — several commenters pointed out that farming grunt work to a subagent running a cheaper model isn't a new idea in agentic coding harnesses generally, and a few called the post itself AI-flavored in its prose. Worth knowing before you cite it as gospel. What the skeptics didn't manage to knock down is the mechanism: the hooks-plus-scripts-plus-skills enforcement is a genuinely clean way to make routing stick instead of hoping the model remembers to use it.
What a solo founder can copy today, with or without Portal
Here's the part that matters if you're paying for Claude Code out of your own pocket instead of an engineering budget line. You don't need Spotify's platform. You need the pattern underneath it, and the pattern is three ideas:
- Classify the task before it hits the frontier model. Is this I/O — reading, summarizing, generating from an obvious template — or is it reasoning — debugging, deciding, editing something specific? That single question is the whole routing table.
- Enforce it with a hook, not a habit. A
PreToolUsehook that blocks large reads is a few lines of shell script. It doesn't rely on remembering to route work correctly every single time, which is the failure mode of "just be disciplined about it." - Send the I/O work to whatever's cheapest. Gemini 2.5 Flash is what Spotify picked; there are other cheap, fast options out there, and the choice matters less than the habit of having one at all.
And you don't even have to build the enforcement layer from scratch — the shunt plugin and both example modes are public and free on GitHub right now, install-and-go for anyone running Claude Code, no Spotify employment required.
This is the same underlying instinct as Headroom's context-compression approach to cutting agent token costs by 60-95% and shadcn/improve's split between expensive audits and cheap execution — three different teams landing on the same conclusion from different angles: a frontier model's context window is the most expensive real estate in your stack, and most of what gets shoved into it doesn't need to be there. If you haven't looked at what Claude Code actually costs across its plans recently, this is a good week to check, because the routing pattern only pays off if you know your current baseline to compare against.
What to route and what to keep on the frontier model
| Delegate to a cheap model | Keep on the frontier model |
|---|---|
| Reading files to answer "what does this do" | Debugging why something is actually broken |
| Summarizing a batch of similar files | Any decision about architecture or design |
| Boilerplate matching an existing pattern | Precise edits that need exact line numbers |
| Generating a test file from twenty siblings | Safety-critical or concurrency-sensitive code |
| Config or schema generation from a template | Anything where a subtle miss is expensive to catch late |
Where SaaSCity fits into a week like this
If you're a small tool that shipped something genuinely useful the same week Spotify's post ate the front page, good luck getting noticed. That's not a complaint about this specific story — it's just how attention works when a big-name engineering blog has a clean number and a viral headline. It's also exactly the gap a directory is built to sit in.
SaaSCity is a free, human-reviewed startup directory with a live city map. Every submission gets checked by an actual person, and every listing gets a permanent page plus a building on the map. Add the SaaSCity badge to your own site and you get a dofollow backlink — the domain sits at DR 59 at our last Ahrefs refresh — plus a slot in the next Monday launch batch. Want to skip the badge and go live inside 24 hours instead? Quick Pass is $19.99. Premium at $99.99 adds a written launch post from our team with three dofollow links.
None of that depends on whether Spotify's number holds up under scrutiny or whether the next viral engineering post is about your stack instead of Google's. That's the actual point: distribution you control beats distribution you were hoping to borrow from someone else's news cycle.
The thing worth watching next
Ignore the 90% headline for a second and watch a different number instead: how many teams start shipping their own version of the routing table before the end of the year. The mechanism here isn't exotic — a hook, a cheap model's API key, a skill file telling the frontier model when to step back. If this pattern is as generalizable as Spotify's own honesty about its limits suggests, the interesting story in six months won't be "one team saved 90%." It'll be everyone's Claude Code bill quietly getting smaller while nobody wrote a blog post about it.
Get your SaaS in front of founders
List your product on the SaaSCity live city map - a permanent listing, real discovery, and a backlink from a high-DR directory. Free to start; upgrade for a dofollow link and a building on the map.


