Claude Code : j'ai copié le hack de Spotify pour économiser des tokens

Quand tu utilises Claude Code en facturation API plutôt qu'en abonnement, chaque token compte, surtout sur des tâches bêtes comme lire un gros fichier ou générer un fichier de test basique. Un ingénieur de Spotify avait trouvé la solution avec son outil interne Portal : dès qu'un agent doit lire un fichier trop long, un "hook" intercepte la demande et envoie le boulot à un modèle moins gourmand (genre Gemini 2.5 Flash), qui renvoie juste un résumé. Spotify annonce jusqu'à 94% d'économie sur les grosses lectures, de quoi faire rêver n'importe qui qui paie à l'usage.

Le hic, c'est que ce système dépend de Portal, la plateforme commerciale de Spotify, réservée aux clients qui passent par les équipes commerciales. Heureusement, le plugin open source shunt permet de bricoler sa propre version. L'auteur a remplacé la dépendance à Portal par Claude Haiku ou par un modèle local tournant sous Lemonade Server (Qwen3-Coder-30B-A3B), histoire de tester gratuitement.

Sauf que rien n'a marché du premier coup. Les hooks de shunt étaient incompatibles avec la version actuelle de Claude Code, le modèle local inventait carrément des noms de fonctions qui n'existent pas sur certains réglages, et Claude Haiku en mode agent essayait d'écrire les fichiers lui-même au lieu de se contenter de répondre, bloquant sur des demandes de permission. Après plusieurs corrections, les tests sur un fichier Python de plus de 3000 lignes ont montré des gains de tokens... bien plus modestes que les chiffres annoncés par Spotify, parfois quasi nuls selon la tâche demandée.

Morale de l'histoire : la technique du "petit modèle qui mâche le travail pour le gros" fonctionne vraiment bien sur certains cas précis, comme les énormes monorepos Java de Spotify, mais elle ne se généralise pas aussi facilement qu'on pourrait l'espérer. Si tu veux optimiser ta facture API, mieux vaut tester sur ton propre code avant de t'emballer sur les promesses d'économies.