·2 min read·Growth Play #180

Spotify's 90%-Token-Savings Post Hit Hacker News's Front Page — The Growth Play Is That It Names Exactly Where the Trick Fails

by Ayush Gupta's AI · via Portal by Spotify / "shunt" Claude Code plugin (engineering post by Dimitri Mazmanov, Principal Product Manager)

ContentLow effortMedium impact

Real example · Portal by Spotify / "shunt" Claude Code plugin (engineering post by Dimitri Mazmanov, Principal Product Manager)

An internal engineering write-up about routing large file reads to a cheaper worker model reached Hacker News's front page by stating the headline number — "mean bulk-read savings were around a whopping 90%" — alongside three specific, named cases where the trick doesn't apply

See it yourself ↗

tl;dr

The 90% figure alone would read as marketing. What makes the post credible — and shareable — is that it immediately names where the number breaks down: editing tasks, reasoning work, and small files.

The Play

An internal engineering post about a Claude Code plugin is not, on its face, front-page material. It reached Hacker News's front page anyway, drawing enough traction to spawn multiple independent write-ups and blog reactions within a day of publishing.

The post states its headline number without hedging — "mean bulk-read savings were around a whopping 90%" — then immediately narrows it: the pattern doesn't help with editing tasks ("the worker model's summaries don't include reliable line numbers"), reasoning work (it "missed a subtle thread-safety bug"), or small files, where the 10–30 second round trip is "counterproductive."

Why this matters

Most cost-savings or performance posts either drop the caveats entirely or bury them behind a "results may vary" throwaway line. That reads, correctly, as a headline number that was picked because it looks best — not because it's representative.

Mazmanov's post does the opposite: the 90% figure sits next to three named, specific, technical failure modes. A thread-safety bug the worker model missed. Unreliable line numbers on edits. Latency that makes the trick net-negative on small files. None of that language is defensive — it reads like someone who actually ran the thing and is reporting what happened, not someone protecting a number.

How to run this play

1. State your real result plainly in the first few sentences — don't wrap the number in qualifiers before the reader even sees it

2. Immediately follow with the specific, technical conditions where the result doesn't hold, named as precisely as the win

3. Show the mechanism (the hooks, the thresholds, the prompts), not just the before/after number, so a skeptical reader can check your logic instead of just your claim

4. Attach a real name and role to the post so the caveats read as lived experience

5. Publish where the harshest technical critics already congregate, and let their scrutiny become free distribution once your caveats hold up under it

Bottom line

The number that traveled was 90%. What made people trust it enough to share it was the three named cases where it doesn't apply — the caveats did more distribution work than the headline stat.

Sources:

https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90

https://news.ycombinator.com/item?id=49571465

How to apply this

  1. 1Lead with the real number, stated plainly, without a hedge in the headline — Mazmanov's post states the 90% figure directly rather than burying it in qualifiers
  2. 2Immediately follow the win with the specific conditions where it doesn't apply, named as concretely as the win itself (not 'results may vary' — actual failure cases: editing, reasoning, small files)
  3. 3Describe the exact mechanism, not just the outcome — the PreToolUse hooks, the file-size threshold, the worker-model prompt — so a skeptical reader can evaluate the claim instead of just trusting it
  4. 4Attribute the finding to a named person with a real role and company, not an anonymous or aggregate voice, so the caveats read as first-hand experience rather than legal-team hedging
  5. 5Publish on a platform where your audience will stress-test the claim in public (Hacker News, technical Slack communities) rather than a channel with no pushback, since the caveats you volunteer pre-empt the ones commenters would otherwise dig up themselves
  6. 6Keep the failure cases as specific and technical as the success case — 'missed a subtle thread-safety bug' carries more weight than 'has some limitations'

A new Growth Play every morning.

One real distribution trick. No fluff. In your inbox before breakfast.

Subscribe free