Spotify's Portal slashed Claude Code tokens by 90%. Here's how.

You are choosing between letting your Claude Code bill keep climbing as your codebase grows, or building a middle layer that manages what actually gets sent to the model, because right now every tool call, every file read, and every turn of conversation history is getting re-transmitted in full on each request. That is the fork a Spotify engineer describes in a recent write-up, and the number attached to the fix is large enough to warrant a closer look before anyone rushes to replicate it.

The number: 90 percent, and what changes if it is really 45

The headline claim from the Spotify engineering post is a 90 percent reduction in token usage after routing Claude Code through Portal. That is not a marginal optimization. It is the difference between a coding session costing a dollar and costing a dime, at Claude Code's current per-token rates.

Here is why the exact figure matters more than it looks like it should. At 90 percent, this stops being a nice-to-have and becomes a rearchitecture of how coding agents should be built by default, because the savings compound across every session, every developer, every day. At 45 percent, the same idea is still worth doing, but it moves from "obviously required" to "worth the engineering time if you already have someone who can build it." The gap between those two numbers is the gap between a company-wide mandate and a side project someone champions for a quarter and then maintains alone.

One data point from one engineer's workflow does not settle which of those two worlds we are in. The post describes real sessions and real metrics, but it is a sample size of one codebase, one usage pattern, and one person's sense of what counted as a fair before-and-after comparison.

Why context-heavy coding agents burn tokens in the first place

The mechanism behind the token bloat is not exotic, and it is worth naming plainly because many teams evaluating tools like this skip straight to the fix without understanding the problem. Claude Code, like most agentic coding tools, is stateless between API calls in the sense that matters for billing: every turn resends the full conversation history, every file it has read, every tool output it has generated, because the model has no persistent memory of its own. The context window is the only memory it has, and that window gets retransmitted, tokenized, and billed again each time you ask a follow-up question.

A session that starts by reading a 400-line file, running a test, and reading three more files does not pay for those reads once. It pays for them again on turn two, again on turn three, and again on turn ten, because the entire transcript rides along with every new prompt. This is not a flaw specific to Claude. It is how the request-response API model works across every major coding assistant, including GitHub Copilot and Cursor, and it is exactly why prompt caching exists as a pricing category in the first place. Anthropic's own pricing structure for models like Claude Fable 5 treats cache reads as a nearly free tier compared to base output, which only makes sense if the industry has already accepted that resending the same context over and over is the default failure mode, not an edge case.

Portal's approach, as described in the source post, is to sit between the agent and the model and decide what actually needs to travel with each request. Stable context, repo structure, prior tool outputs that have not changed, gets treated as something to reference rather than resend in full. That is a caching and deduplication problem dressed up as a token-usage problem, and once you see it that way, the 90 percent figure becomes plausible rather than magical. It is not that Portal makes Claude smarter. It is that Portal stops Claude from being billed to re-read its own homework.

Three reasons to be skeptical of the 90 percent claim

Here is the argument for not building your own Portal, and it deserves the full weight of a section rather than a caveat at the end.

First, this is a self-reported case study from one engineer, published on a company engineering blog, describing their own tool applied to their own workflow. That is not a controlled benchmark. There is no comparison against a baseline that other teams could reproduce, no breakdown of how the 90 percent was measured across session length, task type, or codebase size. Engineering blogs are written to showcase wins, and a number this clean, round, and favorable should be read with the same skepticism you would apply to a vendor's own benchmark of its own product, even when the vendor is an internal team with nothing to sell.

Second, token savings are not the same as cost savings once you account for what it took to build and maintain Portal. Someone had to design the interception layer, decide what context is safe to omit, handle the cases where trimmed context caused the model to make a wrong assumption about a file it thought it already knew, and keep the whole thing working as Claude Code itself gets updated. That is ongoing engineering time, and engineering time is the most expensive line item in any AI tooling budget, more expensive than the token bill it is meant to reduce. A team that saves 90 percent on tokens but spends two engineers a quarter maintaining the layer that produces that saving has not obviously come out ahead.

Third, and this is the part the headline skips entirely: aggressive context trimming introduces a failure mode that is worse than a high token bill, which is the agent confidently acting on stale or incomplete context because the layer decided a file "hadn't changed" when it had. Nobody notices a token savings until they notice a bug that shipped because the coding agent was working from a cached assumption instead of the current state of the repository. The Spotify post reports the savings. It does not report the failure rate of decisions made on trimmed context, and that is the number that actually determines whether this is safe to adopt broadly.

None of this means Portal is a bad idea. It means the 90 percent number describes a benefit, not a verdict, and the two are not the same thing.

What to do with this before your next sprint

If your Claude Code token bill is a real line item and not a rounding error, the earliest useful step is not building a Portal clone. It is pulling your own token logs for the last two weeks and identifying whether the waste looks like Spotify's, meaning repeated resends of stable context, or whether it looks like something else entirely, meaning long single-turn tasks with large files that no amount of caching will shrink. That audit takes an afternoon, not a sprint, and it tells you whether this pattern applies to your workflow before you commit engineering time to replicating someone else's fix for a problem you have not confirmed you have. Once you have that baseline, the next sprint cycle is a reasonable point to prototype a caching layer, because by then you will know whether you are solving your actual bottleneck or someone else's.

For teams comparing coding agents more broadly, it is worth reading how token economics differ across tools before assuming the fix generalizes, starting with Cursor versus GitHub Copilot and the broader context on running large models locally if the goal is cutting API spend rather than routing around it.