So this is just delegating certain work to dumber models? I certainly wouldn't use Gemini 2.5 Flash (!!?) for code writing as suggested.
I've never had an issue with Codex or Claude reading massive files, they're really good at precise greps.
jampa 2 hours ago [-]
> I've never had an issue with Codex or Claude reading massive files
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".
bensyverson 2 hours ago [-]
Yes, this makes little sense. It looks like it's a way to avoid having Claude read or write your code.
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!
shubhamjain 54 minutes ago [-]
> So this is just delegating certain work to dumber models? I certainly wouldn't use Gemini 2.5 Flash (!!?) for code writing as suggested.
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.
3 hours ago [-]
14u2c 2 hours ago [-]
This does seem to just be a subagents implementation.
jnwatson 3 hours ago [-]
It cuts token usage because they are using a different service with a different token budget for the reader/code writer tasks.
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.
CaveTech 6 minutes ago [-]
You can also use hooks to force the use of subagents for this. The stack here is entirely unnecessary
faangguyindia 55 minutes ago [-]
It doesn't work well in practice.
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?
klodolph 43 minutes ago [-]
> Try it yourself, use a big model like Opus or Sol to implement everything by first making a plan using plan mode.
When I do this, I can have it use cheap subagents with models like Luna to read the relevant files.
MPSimmons 21 minutes ago [-]
Do you have the cheap models summarize the files? How do they get the relevant information to the bigger models?
skybrian 45 minutes ago [-]
Maybe not, but I like to review the plan anyway so that I'm less surprised by what it actually did.
Banditoz 2 hours ago [-]
Oh dear, why does this website override scrolling behavior?
orliesaurus 2 hours ago [-]
glad im not the only one that enabled screen reader mode to scan the article for some goodies
gruez 2 hours ago [-]
>The benchmarks
>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.
gilmtz 1 hours ago [-]
> The worker model found surface-level patterns but missed a subtle thread-safety bug in my testing. Claude spotted it in seconds once given the right context.
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.
FelineStateMach 2 hours ago [-]
I sometimes get jumpscaped at the thought of older or less proven models used in enterprise settings. I understand the devex ergonomics argument; I'm not a fan of profiles concepts typically if trodding into delegation.
ryuuseijin 2 hours ago [-]
Here is another technique to save tokens: allow the model to read a skeleton of the source code before reading the code, to give it an index into the code so it can read targeted chunks.
There is a tool that uses ripgrep and treesitter that does this [1], adapted from the maki coding agent.
Aider pioneered this with the "repo map" which works tremendously well.
tolugenius 3 hours ago [-]
Isn't this a somewhat standard multi-model setup? there's nothing ground breaking here, just delegate claude to plan -> smaller model for implementation.
cute_boi 2 hours ago [-]
STOP hijacking my scroll. I don't know why chrome even allow such behavior?
And, I can't believe this is from official spotify.... What a joke.
avazhi 1 hours ago [-]
Dang, not even Spotify care enough to not write AI slop articles.
We’re fucked.
blehn 31 minutes ago [-]
To be fair, Spotify was a slop factory long before LLMs started doing it
fif7y 3 hours ago [-]
[flagged]
BottieZimmie 3 hours ago [-]
[flagged]
Buoylog 2 hours ago [-]
[flagged]
tetrisgm 3 hours ago [-]
This is just offshoring but for models
Rendered at 03:47:36 GMT+0000 (Coordinated Universal Time) with Vercel.
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".
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!
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.
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.
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.
There is a tool that uses ripgrep and treesitter that does this [1], adapted from the maki coding agent.
[1]: https://github.com/ninjaxtools/treesitter-index
And, I can't believe this is from official spotify.... What a joke.
We’re fucked.