Skip to content
Spotify's 'Portal' Slashed AI Token Costs 90% by Optimizing I/O, Not Prompt Engineering

Spotify's 'Portal' Slashed AI Token Costs 90% by Optimizing I/O, Not Prompt Engineering

6 min read LLM Optimization

Spotify's 'Portal' tool dramatically cut Claude AI token usage by 90% for developers. The core insight: most AI coding agent token usage is for I/O operations, not complex reasoning. This approach demonstrates that optimizing input/output streams is key to significant cost savings and efficiency....

Subscribe to listen
audio-thumbnail
Spotify's 'Portal' Slashed AI Token Costs 90% by Optimizing I/O, Not Prompt Engineering
0:00
/0
Clinical Summary
Diagnosis

High token costs occur when frontier models like Claude are wasted on I/O grunt work—such as scanning large files or generating boilerplate—instead of high-level reasoning.

Prescription
  • Intercept Calls: Implement PreToolUse hooks at the tool-call layer to block large file reads before they consume expensive context window tokens.
  • Route I/O Tasks: Offload bulk reading, pattern matching, and file generation to cheaper worker models like Gemini 2.5 Flash.
  • Reserve Reasoning: Save expensive frontier models exclusively for architectural decisions, complex debugging, and surgical codebase edits.
Side Effects

Delegating tasks introduces ephemeral runtime network latency (10-30 seconds), and cheaper models lack the reasoning depth required for surgical edits or spotting subtle concurrency bugs.

Script

Spotify just cut their AI coding agent bill by ninety percent.

They didn't do it with prompt engineering, model distillation, or negotiating a volume discount.

They did it by stopping Claude from reading files. That's the whole insight. The rest is plumbing.

The Problem: Paying Genius Rates for Grunt Work

Here's the problem that engineering teams are already hitting. Most of what an AI agent does in a large codebase isn't reasoning. It's I/O.

Reading five files to answer one question about a single method. Generating a test file that follows the exact same pattern as the twenty tests sitting right next to it. Updating documentation after a meeting. Thousands of tokens spent, and almost none of it requires a frontier model.

You're paying genius rates for grunt work.

And you're not alone. A quarter of engineering leaders already burn two hundred to five hundred dollars per developer per month on tokens. Some are well past two thousand. The tooling pays for itself, but only if you stop feeding frontier models work that doesn't need them.

The Solution: A Routing Layer for Agents

Spotify's team built a routing layer inside Portal, their internal agent platform. They created two declarative modes:

  • bulk-reader
  • code-writer

Both run on Gemini 2.5 Flash, a cheap worker model, through something called AiKA Modes.

Think of a mode as a Lambda function for agents. You define the instructions, pick the model, set the temperature, and attach MCP tools. No servers to manage. No API keys to juggle. Callable from the Portal CLI or API. Public modes can be shared across a company. Private ones stay on your team. Fork a public mode and your version takes precedence automatically. No configuration needed.

Then they wrote a Claude Code plugin named Shunt. It sits at the tool-call layer and intercepts reads before they happen.

How It Works

Shunt registers two PreToolUse hooks. The first checks every Read call. If the file exceeds three hundred fifty lines, the hook blocks the read and tells Claude to use the bulk-reader skill instead.

The second hook catches bash commands like cat, head, tail, or less on large files. Piped commands pass through, because those are already targeted reads and the expensive model should handle them. The threshold is configurable via an environment variable. You can set it to five hundred lines or whatever fits your repo.

Under the hood, two bash scripts wrap the Portal CLI. The bulk-read script takes a question and a list of paths, wraps each file in XML tags for clear boundaries, and sends them to the bulk-reader mode. The code-write script takes a spec, a reference file, and an optional target path. It strips markdown fences from the output and can write straight to disk.

Claude calls these scripts with named arguments and the scripts handle the request, invocation, error unwrapping, and token reporting.

When a hook fires, the heavy lifting goes to the worker model. The bulk-reader returns structured bullets with exact names, types, and line numbers. No greetings. No prose. No markdown fences.

That last part matters. Without an explicit instruction to output only bullets, the worker wraps everything in explanatory prose that Claude then has to parse through. That wastes tokens and time.

Every delegation is one shot. The invocation is ephemeral. Nothing is stored server-side. Re-sending the files on a follow-up is cheap where it counts, because the corpus goes to the worker model and never enters Claude's context window.

For writing, the code-writer mode takes a spec and a reference file. It matches naming, style, and conventions exactly. The output goes straight to disk.

Claude never sees the generated code. That matters because generated output tokens are expensive too. Without Shunt, Claude both reads the reference files and generates the output as expensive tokens. With Shunt, the cheap model does both and the code bypasses Claude entirely.

The Results: A 90% Cost Reduction

Tested across a Java monorepo in four scenarios, mean savings on bulk reads were around ninety percent. Not ten. Not forty. Ninety.

Picture this. It's Thursday afternoon. You're tracing a bug through a monorepo. You need to know which methods call the database across Service.java, Handler.java, DAO.java, and maybe eight more files.

Without routing, Claude reads every file into its expensive context window. A few hundred thousand tokens later, you have an answer.

With the bulk-reader, those files go to Gemini Flash. It returns bullets. Claude consumes maybe twenty thousand tokens of summary. The difference is your ninety percent.

The Limitations

But this isn't magic. Each delegation is a network round trip. Portal invokes the worker on an ephemeral runtime. Responses typically take ten to thirty seconds. Portal caps a single invocation at thirty seconds, so very large generations need to be split into smaller calls.

For small files, the overhead costs more than it saves. That's why the line threshold exists. Below it, Claude reads directly. The system degrades gracefully. Even if Claude ignores the skill description, the hook still blocks the expensive read.

There are also hard limits on what you can delegate. You can't delegate editing. The cheap model's summaries don't include reliable line numbers. If Claude needs to make a surgical change, it still has to read the specific section directly. The hooks allow targeted reads with offset and limit for exactly this reason.

Delegation saves tokens on understanding, not on modification.

You can't delegate reasoning either. In Spotify's testing, Gemini Flash caught surface-level patterns but missed a subtle thread-safety bug. Claude spotted it immediately once given the right context. Debugging, architectural decisions, and safety-critical code stay on the expensive model. The routing explicitly excludes them.

Who Is This For?

So who is this actually for?

You should try this pattern today if:

  • You're already burning serious money on tokens.
  • You work in a large codebase where agents constantly scan across files.
  • You can tolerate a ten-to-thirty-second pause in exchange for a ninety percent discount.

You should wait if:

  • Your codebase is small.
  • Your monthly API bill is under fifty dollars.
  • You mostly do precise editing rather than broad exploration.

You should ignore it if you're not already using an agent-heavy workflow. This isn't a reason to start one. It's an optimization for teams already feeling the burn.

Availability and The Core Pattern

A word on availability. Portal is Spotify's internal platform. The Shunt plugin and the modes are open-sourced, but they delegate through Portal's CLI and actions registry. You install the plugins from the marketplace, run setup to authenticate against your Portal instance, and you're off.

But if you don't have Portal running, you can't use this today.

For most of us, this is a reference architecture, not a download. And that's perfectly fine. The valuable part isn't the brand name. It's the design pattern.

  • Enforce routing at the tool-call layer, not in a system prompt that the model can ignore.
  • Use cheap models for summarization and pattern matching.
  • Reserve frontier models for reasoning and review.

Decouple the routing decision from the worker so you can swap models later without touching the plugin.

If your team is spending five hundred dollars a month per developer on tokens, this logic pays for itself quickly. If you're not feeling that pain yet, don't invent it.

Optimize when the bill hurts, not before.

This is TAKEYOURPILLS DOT TECH. Go ship something.

References

/