Tmux + Fable : une méthode concrète pour réduire la facture de tokens de 35 %

Tout part d'une douleur familière : faire tourner le modèle le plus puissant pour chaque tâche épuise le quota cloud en quelques jours. La cause est simple : les modèles de pointe sont performants mais tout aussi chers et lents ; router chaque petite correction par eux gonfle la facture. La solution n'est pas d'abandonner le modèle, mais de changer la division du travail.

La formule tient en une phrase : Fable 5 planifie, Sonnet 5 exécute. Comme présenté dans la vidéo, Sonnet 5 coûte environ un cinquième du niveau de Fable 5 tout en performant comme le meilleur modèle d'il y a quelques mois. La qualité de planification reste élevée pendant que la facture baisse.

Deux schémas officiels sont décrits côté Claude Code. Premièrement, Sonnet 5 agit comme exécuteur principal et appelle Fable 5 comme conseiller en cas de blocage. Deuxièmement, Fable 5 agit comme orchestrateur, construit le plan et ouvre des sessions de travail sur le modèle plus petit pour l'exécution. La comparaison de l'équipe Devin favorise la seconde voie.

La raison tient à l'économie du cache : un modèle conseiller doit relire tout l'historique de l'agent principal, ce qui signifie une entrée fraîche coûteuse. Le schéma en travailleurs déclenche au contraire un contexte en cache, et une lecture de cache coûte environ un dixième d'une entrée fraîche. C'est pourquoi la configuration en orchestrateur tourne moins cher.

La distinction clé ici est entre acolyte persistant et sous-agent à usage unique. Un sous-agent classique se ferme une fois terminé, et une demande de correction le rouvre avec un contexte nul, si bien que les mêmes choses sont réécrites. Une session d'acolyte persistante conserve l'historique : l'agent principal envoie des messages de suivi dans la même session ; l'historique arrive depuis le cache, donc c'est à la fois bon marché et puissant. Les équipes d'agents plus l'outil send-message dans Claude Code font exactement cela.

Étape d'implémentation une : ajouter une règle de délégation au fichier CLAUDE.md. La règle dit que vous êtes le coordinateur, que la conception, la planification et la revue restent avec vous ; confier l'exécution aux travailleurs Sonnet ; les travailleurs n'ouvrent jamais d'agents imbriqués ; pour un travail complexe, écrire d'abord une spécification figée dans le dossier de la tâche. Dans la vidéo, une application de to-do est commandée ainsi : des questions sont posées, le plan est clarifié, la spécification atterrit dans un fichier, l'exécution part vers une session Sonnet, et le résultat arrive visiblement plus vite qu'en tournant sur Fable.

Étape d'implémentation deux : le pont Codex. Une fois le plugin Codex installé et les plugins rechargés, une session Codex peut démarrer depuis l'intérieur de Claude Code ; les commandes rescue, review, result, cancel et transfer sont prêtes à l'emploi. La commande resume envoie des messages de suivi dans la même session Codex. Dans la vidéo, l'interface de to-do d'abord écrite par Claude Code reçoit une passe Codex et l'aspect change visiblement.

Étape d'implémentation trois : le pont universel tmux. Tmux est un multiplexeur de terminal ; il ouvre plusieurs terminaux persistants et contrôle chacun par commande. Trois commandes suffisent : split-window -h ouvre un nouveau volet à droite, send-keys -t tape du texte plus Entrée dans la cible, capture-pane -p -t relit ce volet. N'importe quel agent que vous utilisez comme un humain, y compris Gemini CLI, devient un travailleur sous l'agent principal.

La pièce manquante est la notification de fin : comment le travailleur réveille-t-il l'agent principal. Côté tmux, la réponse est la commande wait-for ; le travailleur signale avec wait-for -S à la fin pendant que le côté principal attend. La compétence agent teams ouverte dans la vidéo encapsule ce schéma : ouvrir une session, envoyer un message, attendre la fin, lire le résultat. Dans la démo, Codex écrit une blague, un agent Pi la relit, Haiku vérifie la grammaire ; tout tourne en parallèle et le texte final revient à l'agent principal.

Pour ceux qui veulent une option toute prête, Orca et Herd sont passés en revue. Ils offrent la même orchestration avec une interface : sessions de travailleurs apparaissant à droite, vue hiérarchique à gauche, kanban plus suivi des tokens. Le présentateur a retenu Orca comme pilote quotidien ; open source et gratuit est le plus. Voie tmux scriptée ou interface packagée, la logique est identique : le cerveau coûteux planifie, des mains moins chères exécutent.