Portal by Spotify cut my Claude Code token usage by 90%(engineering.atspotify.com) |
Portal by Spotify cut my Claude Code token usage by 90%(engineering.atspotify.com) |
One is strictly a performance optimization, the other is a speed/quality tradeoff. It might well be a very good one, but it’s a tradeoff nevertheless. The framing is misleading.
fable already calls subagents (hoping not opus), so i don't really see the gain here
And, I can't believe this is from official spotify.... What a joke.
If you think a cheap model is smart enough to filter information to give to your expensive model, you can save some money. If you think your cheap model is smart enough to format your expensive output, you can save some money.
In practice, this didn't work well until Qwen 3.8.
Qwen 3.6 and (abliterated) Gemma 4 were almost there but still making mistakes.
> The modes are the load-bearing piece:
lol
And it's just the execution, I'm not even going to comment on the idea itself, as it's even worse.
How this slop-post landed on the front page...?
Right?
Rules for thee...
Wasn't the AI promise to save costs? So it was a lie.
Measuring productivity is, of course, a hard problem and I'm going to leave this completely out of this comment.
imagine working at these shitty companies with their shitty wrapper tooling.
not X, but Y... so this is very likely Opus 5 text, given timing and how it reads. has all the marks of it, one being very weird wording which makes it so hard to read the text.
> modes are the load-bearing piece:
Okay, this write-up is filled with Claudisms.
I've never had an issue with Codex or Claude reading massive files, they're really good at precise greps.
Reading files isn't a problem they want to solve. The idea seems to be using a cheaper model to "scout" for the intended code, instead of an expensive one that reads all the things (and spends more tokens / thinks about them).
I think this might be useful because Opus 5 especially tends to over-read. So this looks like an "LLM Bloom filter", telling "hey this is the code you might want to read".
There’s an added benefit that the manager’s focus on strategy and task decomposition before actually handling the user’s prompted task directly seems to be a very good way to interact with Claude’s Fable safeguards, and I haven’t had any refusals doing this.
And while I haven’t ran any numbers, I can get orders of magnitude more out of my claude subscription doing this, especially with deepseek-v4-flash being as good as it is for as cheap as it is.
The community edition was open sourced when the creator got hired by OpenAI a few months ago.
very good way to put it.
Why not, though? I started using OpenCode + GitHub Copilot, but I burned through my Claude Sonnet quota in just three days. I switched to GPT-5.4-mini, which uses far fewer tokens, and it’s often just as good as Sonnet. I think optimizing token usage is a good exercise. We often assume a model will be terrible, when it really isn’t.
“Often” doesn’t sound great. If the smaller model fails then I just wasted a lot of time and tokens.
And why stop at 90%? I have this one weird trick to reduce Claude Code token use by 100%: use a different harness and model!
The app would start using it for exploration tasks, and then as it improved it became the default for writing code and tests too. You can change it of course, but I find it does a pretty decent job if you have a large model directing it.
The parent model of course checks the work, but most of the time the handoff is good enough that no edits are needed.
It's also pretty fast and cheap, firing off a bunch of sub-agents to explore different parts of the codebase is a regular occurrence for the way I work.
On top of that, saving 90% of input tokens != saving 90% "of tokens", output is wildly more expensive.
[1] especially if it's a really old model like Gemini 2.5!
I'm personally skeptical of optimizing for minimal token consumption, the closer to a vanilla setup I am the more confident I feel I'm always getting the best performance out of my models.
Just look at how JetBrains measured rtk and found that while an individual call saves tokens, agents on average perform *more* turns and use *more* tokens to accomplish one task[1]
[1] https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-...
15 seconds.
Incredible stuff.
Never been happier listening to music ATM.
"But it adds motion" was the classic reply.
There is nothing wrong with art. It is a great thing, I hope to see more art in the world. However, if the goal is sharing information, which is supposedly the goal of a fairly large number of websites, art needs to be secondary to sharing that information. And then those things that add motion, whatever: you're adding art and harming the real purpose.
I found no problem scrolling. Either Firefox on Android doesn't support whatever trickery they are doing, or they reverted it.
Ublock on Firefox mobile seems to keep scrolling unfucked on this page for me. (Designer/"dev" of this page still sucks wet hobo socks.)
You can also just delegate this to subagents with Claude Code (though you have a more limited choice of models unless you swap the cheaper models via OpenRouter).
I'm OK using a dumb model as a smart grep, but the whole point of using the frontier models is using their intelligence for the hard stuff like coding.
Basically I run in luna high or extra high continuously with a terra subworker dedicated to planning and difficult research questions. Then I end with a final review in Terra or Sol depending how big the feature is.
Try it yourself, use a big model like Opus or Sol to implement everything by first making a plan using plan mode.
Then try distributing the task to a cheaper models like Luna Max or Gemini Flash 3.8.
During planning, the big model already reads the relevant files in context, while giving a smaller model a slice of work itself requires the big model to reason about the task distribution, review, etc.
So do you really save on tokens?
When I do this, I can have it use cheap subagents with models like Luna to read the relevant files.
>Tested against a Java monorepo across four scenarios, measuring tokens Claude would consume reading files directly vs. consuming the bulk-reader's summary or writing code via the code-writer. Mean bulk-read savings were around a whopping 90%.
>The code-write scenario is harder to measure in tokens because without shunt, Claude both reads the reference files and generates the output as expensive output tokens. With shunt, the code goes straight to disk, Claude never sees it.
So nothing about accuracy or actual performance? At least run against DeepSWE bench or something.
So the actual performance was bad.
It might be an acceptable trade off tho. If token costs become prohibitive, then using a meat engineer to actually debug could be cheaper.
In codex I don’t see this behaviour despite having added the instructions to do so to my agents file. I also let that agents file be reviewed by Sol to come up with the right phrasing but no luck so far.
(fully vibe coded)
> If Claude needs to make edits based on the analysis, it still has to read the specific section directly.
Yeah iirc the sysprompt tells it that it must always (re-)read a file before editing it. I noticed this because I customized Claude Code to just read all source at startup (if the project was only a few thousand lines of code). And it would still read the stuff it had already read! Because the system prompt explicitly told it to...
There is a tool that uses ripgrep and treesitter that does this [1], adapted from the maki coding agent.
We’re fucked.
Next sentence was also an AI juxtaposition. Done.
> The modes are the load-bearing piece:
Why do people write like LLMs? Maybe they delegate all the work to a LLM and don't have the time or the will to edit the copy. How about telling another LLMs to replace at least the most common LLM patterns with something human looking?
I'm fairly confident this is just LLM writing the majority, possibly tweaked by a human.
Opening line is a form of, "It's not X, it's Y": ".. isn't thinking. It's I/O".
Then the start of the second paragraph is that weird breathless kind of writing:
> Reading five files to answer a question about one method. Generating a test file that follows the exact same pattern as the twenty test files next to it.
More "It's not X, it's Y": The seat license isn't what hurts, it's the tokens.
The softly pressed insistence that AI is worth it, really: "The tooling pays for itself but only if..."
Eg. On opencode there's explorer subgagent that we can set to use lower level model. Many people even use haiku level model for this.
- listing modes - this gate, other gate - canonical stuff etc.
would've been nice if Claude produces such output now and then. with 4 agents doing my stuff on a daily basis, I feel like vomiting at some point, not mere nausea, but disgust. damn Codex seems to fare better at this imho.
curiously I've tried many times to instruct it to not produce this nonsense, but _deus ex machina_ always finds a way around it. wonder if these "instructions" are actually treated as restrictions, rather than... mere obstacles. like - you can try to plumb a river, it always finds its way around plumbing.
You kids don't get it, it's not about the tokens, it's about the principle of the thing. No self-respecting real programmer would accept the loss of even a few tokens over programmatic efficiency and cleverness.
The comment above shows this type of people don't understand it. Yet they are the ones getting hired due to formal qualification. Those who do are at the intersection of design, engineering and computer science. The latter give you enough experience to understand the culture to recreate familiar _look and feel_.
- Write ~1 paragraph of developer instructions (AGENTS.md): Use subagents for tasks that can be decomposed, worked on in parallel, or delegated. Describe common examples. I put a reference to a "how to use subagents" skill for more details. The "skill" isnt' always read (as subagents arent always useful) which saves some tokens. But you pay the once-per-session read-skill cost when its relevant.
- Describe how to use subagents in ~1 page or less (SKILLS.md): use them for sub tasks. select model size/quality based on task ambiguity, scope, unbounded work, or conflicting requirements. Use reasoning effort for complexity, interdependence, or ambiguous success criteria. How to evaluate complexity & common subtask examples across the spectrum. give tasks a relevant name like "model-family_version_reasoning-effort_task-description" so you can actually understand what theyre doing by name.
- in dev instructions (SKILLS.md) provide a table of agent names (low complexity summarizer, bounded implementation, complex implementation), model+effort (gpt-5.6-luna medium, gpt-5.6-luna high, gpt-5.6-sol medium), and short description of 2-3 task "types" for each.
- Explain they can use "default" or specify their own custom model settings if needed.
- Define your list of subagent profiles in ~/.codex/agents/ which matches names (low_complexity_summarizer.toml) from previous. In each you'll need to set model, reasoning, and `developer_instructions` that describe *how* to do a task, *not what* to do.
Details to know: - IMO subgent profiles are "task centric" because `developer_instructions` are required. You can't just specify model & reasoning, you also have to give valid developer_instructions that will be merged in to every session/prompt. I address this by defining a few different agents for tasks that are commonly encounted like summarization, synthesis, planning, implementation, etc. The different agent profiles (~2-5 per category) will "scale" the model + reasoning based on the complexity and ambiguity. This work pretty well in practice. And you don't need to over due it, the harness/agent can still launch a "custom" profile that uses the parent sessions developer instructions.
- You need to use agent profiles with codex because "v2" models (terra & sol) can't launch "v1" models (luna). There are a couple of code paths to avoid this, the agent profile is the simplest.
Anyways, write you skill & subagent profiles and it basically "just works".This is a Claudism, right? I feel like I never saw "gated" used this way before it.
This should have been the entirety of TFA.
as someone on the internet once said, it's good that no-one at Spotify realised that people would buy the subscription much faster if it was a crying baby soundbite playing every time instead of an advertisement
Related: https://bedrocknews.com/article/technology/2026/apr/11/ai-im... and https://www.headphonesty.com/2025/01/spotify-ghost-artists-c...
Just skip Spotify at all.
I’ve noticed sometimes my wife puts on a playlist and it’s almost like weird covers or remixes I can’t quite put my finger on. Like it has a melody of a real song but the style / tempo / vocals are changed.
The app was done in 2011. They could make a massive improvement across the board with a single git reset --hard command.
And no, the problems you described are not there.
On my Windows 11 laptop it takes about 2sec to start and basically any song starts in less than a second.
Maybe it's Apple making Spotify crappy on Mac to promote iTunes?
I wonder if the macOS build has a bunch of static libraries it has to load first.
So fable and opus use opus to explore. Sonnet uses sonnet.
I replaced my built in explore agent with one hardcoded to sonnet low effort.
That property would be very useful here, but I don't see how it would be achievable using LLMs.
And I'm sure their prompt whisperers are proud of their work.
More specifically, I'm talking about tapping the '...' on a track for the options menu. That should be latency-free, and used to be.
Though I agree it should be.