Side note: PLEASE DONT hijack scroll. Its just a bad bad thing to do. Please dont.
solenoid0937
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.
show comments
jnwatson
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.
show comments
Banditoz
Oh dear, why does this website override scrolling behavior?
show comments
faangguyindia
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?
show comments
gruez
>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.
show comments
tolugenius
Isn't this a somewhat standard multi-model setup? there's nothing ground breaking here, just delegate claude to plan -> smaller model for implementation.
show comments
FelineStateMach
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
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.
Side note: PLEASE DONT hijack scroll. Its just a bad bad thing to do. Please dont.
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.
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.
Oh dear, why does this website override scrolling behavior?
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?
>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.
Isn't this a somewhat standard multi-model setup? there's nothing ground breaking here, just delegate claude to plan -> smaller model for implementation.
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.
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.
[1]: https://github.com/ninjaxtools/treesitter-index
This is just offshoring but for models
Dang, not even Spotify care enough to not write AI slop articles.
We’re fucked.
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.