Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Portal by Spotify cut my Claude Code token usage by 90%

engineering.atspotify.com

Post reply on HN
Print view View original

11–20 of 169 posts

Re: Portal by Spotify cut my Claude Code token usage by 90%

#11

Post by 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.

Re: Portal by Spotify cut my Claude Code token usage by 90%

#12

Post by 14u2c »

solenoid0937 wrote: post #2

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.

This does seem to just be a subagents implementation.

Re: Portal by Spotify cut my Claude Code token usage by 90%

#17

Post by 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.

[1]: https://github.com/ninjaxtools/treesitter-index

Re: Portal by Spotify cut my Claude Code token usage by 90%

#18

Post by jampa »

solenoid0937 wrote: post #2

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.

> 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".

Re: Portal by Spotify cut my Claude Code token usage by 90%

#19

Post by chr15m »

ryuuseijin wrote: post #17

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

Aider pioneered this with the "repo map" which works tremendously well.

Re: Portal by Spotify cut my Claude Code token usage by 90%

#20

Post by gilmtz »

gruez wrote: post #11

>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 outpu…

> 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.

Post reply on HN