Portal by Spotify cut my Claude Code token usage by 90%
Billet d'ingénierie de Spotify publié le 3 septembre 2026 sur engineering.atspotify.com (~1 600 mots, neuf sections, deux manifestes YAML, quatre exemples de ligne de commande), signé Dimitri Mazmanov, Principal Product Manager.
Dimitri Mazmanov, Principal Product Manager chez Spotify, publie le 3 septembre 2026 sur le blog d'ingénierie de l'entreprise le récit d'un montage qui réduirait de 90 % sa consommation de tokens dans Claude Code. Son constat de départ : l'essentiel de ce qu'un agent de codage fait pour lui n'est pas du raisonnement mais de l'entrée-sortie — lire cinq fichiers pour répondre à une question sur une méthode, générer un fichier de test identique aux vingt voisins. Ce travail est envoyé à un modèle de pointe surqualifié, alors qu'un modèle bon marché le traiterait aussi bien.
La solution repose sur les AiKA Modes de Portal by Spotify : des agents déclaratifs exécutés sur un runtime éphémère, définis par des instructions, un modèle, des paramètres et des outils MCP, sans infrastructure ni clés d'API à gérer. L'auteur crée deux modes publics tournant sur Gemini 2.5 Flash. Le premier, bulk-reader, lit un lot de fichiers et répond en puces structurées. Le second, code-writer, génère du code à partir d'une spécification et d'un fichier de référence dont il doit reproduire les conventions.
Most of what an AI coding agent does for me isn't thinking. It's I/O
— Dimitri Mazmanov , engineering.atspotify.com
Le routage est assuré par un plugin Claude Code appelé shunt, après l'échec d'une première version fondée sur des règles écrites dans CLAUDE.md, que le modèle pouvait ignorer et qu'il fallait recopier par projet. Le plugin empile trois couches. Des hooks PreToolUse bloquent les lectures de fichiers dépassant un seuil de lignes configurable, ainsi que les commandes cat, head ou tail sur de gros fichiers ; les lectures ciblées passent. Des scripts bash enveloppent les appels à la CLI Portal, construisent la requête et remontent l'usage de tokens. Des fichiers de skill indiquent à Claude quand et comment appeler ces scripts. Le corpus transite vers le modèle secondaire sans jamais entrer dans le contexte de Claude, qui ne voit pas non plus le code généré, écrit directement sur disque.
Les mesures sont présentées comme une moyenne d'environ 90 % d'économie sur quatre scénarios testés contre un monorepo Java, l'auteur reconnaissant que le scénario de génération se mesure mal. Une section détaille ce qui ne fonctionne pas : l'édition n'est pas délégable faute de numéros de ligne fiables, le raisonnement non plus — le modèle secondaire a manqué un bug de thread-safety que Claude a vu immédiatement —, et chaque délégation coûte dix à trente secondes de latence, ce qui la rend contre-productive sur les petits fichiers.
L'auteur conclut que l'économie de tokens n'est qu'un point de départ : l'intérêt réel des modes est de transformer le routage de modèles en problème de configuration plutôt que d'ingénierie système.
À retenir
L'intuition de départ est un partage de charge, pas une optimisation de prompt. Lire des fichiers et générer du code répétitif consomme des tokens sans mobiliser de raisonnement ; ces tâches partent à un modèle bon marché, le modèle principal garde les problèmes qui demandent du jugement.
Ce qui est économisé n'est pas seulement le prix, c'est l'occupation du contexte. Le corpus lu est envoyé au modèle secondaire et ne rentre jamais dans la fenêtre de Claude ; une relance sur les mêmes fichiers ne recharge donc rien côté principal. Même mécanique que la délégation à des sous-agents dans [[willison-fable-judgement-delegation-subagents-2026-07-03]].
Un mode = un agent déclaratif. nom, description, instructions, modèle, visibility, resourceLimits, tags. Runtime éphémère, rien de stocké côté serveur, aucune clé d'API à gérer. Résolution par nom, insensible à la casse, avec préséance perso → équipe → public : forker un mode public suffit à le surcharger sans configuration.
Les règles dans CLAUDE.md n'ont pas tenu. Première version du routage : un bloc d'instructions que Claude lisait et suivait parfois. Deux défauts nommés — advisory, not enforced, et à recopier dans chaque projet. C'est l'argument qui fait passer aux hooks, portes dures indépendantes de la décision du modèle.
Le seuil est le paramètre de réglage central.check-file-size bloque les Read au-delà de 350 lignes par défaut ; check-bash-read intercepte cat, head, tail, less, more. Les lectures ciblées (offset/limit) et les commandes pipées passent. Sous le seuil, la latence de délégation coûte plus qu'elle ne rapporte.
La dégradation gracieuse est le point d'architecture. Trois couches : le hook bloque, le script exécute, la skill explique. Si Claude ignore la skill, le hook bloque quand même — le contrat n'est pas confié au modèle.
Deux instructions de mode font le gros du travail.Output only the code évite les fences markdown et la prose que le principal devrait reparser ; un fichier de référence obligatoire pour code-writer évite du code hors contexte. Même logique de cadrage que les skills décrites dans [[shihipar-claude-code-lessons-building-skills-2026-06-03]].
⚠️ Le chiffre du titre est auto-déclaré et non reproductible en l'état : moyenne sur quatre scénarios d'un monorepo Java, sans protocole, sans volumes absolus, sans comparaison à un modèle principal utilisé avec des lectures ciblées. L'auteur admet que le scénario code-write est plus difficile à mesurer, et le coût du modèle secondaire n'est pas retranché.
Les trois limites revendiquées cadrent le périmètre. pas d'édition déléguée (numéros de ligne du résumé non fiables), pas de raisonnement délégué (débogage, décisions d'architecture et code critique explicitement exclus du routage), latence de 10 à 30 s par aller-retour avec un plafond Portal à 30 s qui force à découper les grosses générations.
La conclusion opérationnelle porte sur les modes, pas sur le plugin. réutilisables entre projets, partageables (les deux modes sont publics), composables (doc-writer, reviewer, translator cités comme extensions possibles) et découplés du routage — changer de modèle de travail ne change pas le plugin. Cette séparation empaquetage / exécution est celle que formalise [[google-agent-plugins-packaging-skills-mcp-2026-08-06]].
Installation.claude plugin marketplace add spotify/portal-ai-plugins, puis les plugins portal (la CLI) et shunt (le routage), puis /portal:setup pour l'authentification contre une instance Portal. Le montage suppose donc une instance Portal avec le plugin AiKA activé — il n'est pas transposable tel quel hors d'une organisation qui l'exploite.
Les chiffres de cadrage viennent de l'extérieur du billet et ne sont pas sourcés. coûts de codage IA dépassant le salaire moyen d'un développeur d'ici 2028, un quart des responsables d'ingénierie à 200-500 $ par développeur et par mois, certains au-delà de 2 000 $. À traiter comme ordre de grandeur, à rapprocher des mesures par équipe de [[patel-block-buzz-teams-tokens-benchmarks-2026-08-06]].
Chiffres clés
latence de 10 à 30 secondes par délégation, plafond Portal de 30 secondes