9router : un routeur local pour relier vos outils de code à 40 fournisseurs de modèles

Le problème visé : les quotas qui expirent et les changements de fournisseur à la main

Le README énumère cinq irritants : les quotas d'abonnement non consommés qui expirent chaque mois, les limites de débit qui coupent une session en cours, les sorties d'outils (git diff, grep, ls) qui consomment des tokens, le coût des API facturées à l'usage, et le passage manuel d'un fournisseur à l'autre. C'est une description honnête du quotidien de quelqu'un qui paie deux ou trois abonnements et les épuise à des moments imprévisibles. La cible est donc un développeur individuel, pas une plateforme d'équipe. Le projet parle de Claude Code, Codex, Cursor, Cline, Copilot, Gemini, OpenCode et Antigravity, autrement dit des clients qui acceptent tous un endpoint compatible OpenAI. Si votre outil ne permet pas de changer l'URL de base, 9router ne peut rien pour vous.

Un proxy local qui réécrit les requêtes avant de les distribuer

L'architecture tient en un schéma : votre CLI envoie ses requêtes à http://localhost:20128/v1, 9router applique trois traitements, puis transmet au fournisseur choisi. Les traitements annoncés sont la compression des tool_result par un composant appelé RTK, la traduction de format entre OpenAI et Claude, et le suivi des quotas avec rafraîchissement automatique des jetons. Le routage se fait par paliers : abonnement d'abord, puis fournisseurs peu chers cités à 0,6 dollar et 0,2 dollar par million de tokens, puis paliers gratuits. Le README présente le résultat comme une continuité de service. C'est le point à examiner de près : une bascule automatique signifie qu'une requête peut atterrir sur un modèle différent de celui que vous croyez interroger. Le champ Model du client, par exemple kr/claude-sonnet-4.5, désigne une route, pas un modèle unique. Pour du code où la qualité de génération varie fortement d'un modèle à l'autre, cette opacité est un vrai compromis, pas un détail.

Installation et configuration : deux chemins, une différence de support

Le chemin recommandé passe par npm : npm install -g 9router puis la commande 9router, le tableau de bord s'ouvrant sur http://localhost:20128. Le second chemin est l'exécution depuis les sources, et le README précise que le paquet de ce dépôt est privé sous le nom 9router-app, ce qui fait de l'exécution locale le mode attendu pour le développement. Les commandes données sont cp .env.example .env, npm install, puis PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev. En production, le README indique npm run build suivi de PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start. Côté client, trois valeurs suffisent : l'endpoint http://localhost:20128/v1, une clé API à copier depuis le tableau de bord, et un identifiant de modèle. Notez que la variable NEXT_PUBLIC_BASE_URL est préfixée NEXT_PUBLIC, donc exposée au navigateur : si vous placez 9router derrière un reverse proxy, c'est cette valeur qu'il faut aligner, pas seulement PORT. Cette distinction entre paquet npm et sources privées mérite d'être vérifiée avant de bâtir un déploiement d'équipe dessus.

Le tableau de bord comme unique source de vérité, et ce que cela implique

La connexion d'un fournisseur se fait dans le tableau de bord, pas dans un fichier. Le README cite Kiro AI, présenté comme environ 50 crédits mensuels gratuits couvrant Claude 4.5, GLM-5 et MiniMax, et OpenCode Free, décrit comme sans authentification. La clé API utilisée par vos CLI est également copiée depuis cette interface. Il n'existe donc pas, d'après le matériel fourni, de fichier de configuration versionnable décrivant les routes, les paliers et les priorités. Pour un poste de développeur, c'est acceptable. Pour une équipe qui veut reproduire le même routage sur cinq machines, cela veut dire reconfigurer à la main ou sauvegarder l'état de l'application. Le README ne documente ni schéma de configuration, ni export, ni fichier de routes. C'est la limite structurelle la plus visible du projet.

RTK et la promesse de 20 à 40 pour cent de tokens en moins

Le README annonce une réduction de 20 à 40 pour cent des tokens par requête grâce à la compression automatique du contenu des tool_result, et le slogan du dépôt parle de 20 à 40 pour cent d'économies. Aucune méthode de mesure n'est donnée : ni jeu de test, ni protocole, ni détail sur ce qui est supprimé. Un tool_result contient souvent des éléments dont le modèle a besoin pour raisonner, par exemple un diff partiel ou une sortie de test tronquée. La compression peut donc dégrader silencieusement la qualité des réponses sur les tâches qui dépendent de ces détails. Le fait que les notes de version de v0.5.18 mentionnent le suivi des tokens mis en cache suggère que le comptage a évolué récemment, ce qui rend les chiffres du README difficiles à situer dans le temps. Traitez le pourcentage comme une affirmation marketing tant que vous ne l'avez pas mesuré sur vos propres requêtes.

L'alternative : un proxy générique comme LiteLLM

LiteLLM résout une partie du même problème, exposer une API compatible OpenAI devant de nombreux fournisseurs, mais avec une approche opposée. La configuration y est déclarative, dans un fichier YAML versionnable, avec des règles de routage, de retry et de budget explicites. 9router mise sur une interface graphique et des paliers prédéfinis. La différence pratique est nette : avec LiteLLM vous décrivez vous-même la politique de bascule et vous la relisez en revue de code ; avec 9router vous la subissez via le tableau de bord. En contrepartie, LiteLLM ne propose pas d'équivalent annoncé à RTK pour la compression des sorties d'outils, et son installation demande plus de travail initial. Si votre besoin principal est de réduire la facture de tokens sur des sessions d'agent, 9router attaque un angle que LiteLLM ne couvre pas. Si votre besoin est un routage auditable, l'ordre s'inverse.

Maintenance, licence et coût réel de la gratuité

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation et la modification, y compris commerciale, à condition de conserver la mention de copyright. Le paquet npm porte le même identifiant de licence d'après le badge du README, mais vérifiez la correspondance avec le fichier LICENSE avant toute redistribution. Le rythme de publication est soutenu : v0.5.18 début juillet 2026, v0.5.20 quelques jours plus tard, v0.5.35 le 16 juillet, avec des ajouts de fournisseurs, un sélecteur de niveau de réflexion et des traductions. Cette cadence a un revers : les versions mineures s'enchaînent vite, et rien dans le matériel fourni n'indique une politique de compatibilité entre versions. Un déploiement figé sur une version ancienne risque de casser quand un fournisseur modifie son API. Enfin, la gratuité repose sur des paliers tiers : crédits Kiro, Vertex, OpenCode Free. Ces offres ne sont pas contrôlées par le projet et peuvent disparaître. Le coût réel de 9router n'est pas l'argent, c'est le temps passé à suivre les mises à jour et à vérifier que la route gratuite répond encore.

Conclusion éditoriale

9router convient à un développeur qui utilise déjà plusieurs CLI de code et veut centraliser les clés, suivre les quotas et compresser les sorties d'outils sans modifier ses habitudes. Il ne convient pas à une équipe qui a besoin d'un routage versionné, testé et documenté au-delà du README, ni à un usage en production critique : la bascule automatique vers des paliers gratuits dépend de fournisseurs tiers dont les conditions peuvent changer sans préavis. Avant d'adopter, vérifiez deux points précis dans le dépôt : le contenu du fichier .env.example pour les variables attendues, et la licence du paquet publié sur npm, qui doit correspondre au fichier LICENSE du dépôt.

Sources officielles

1. decolua/9router on GitHub
2. License: MIT
3. Project website
4. README
5. Releases