Un seul modèle côté client : la passerelle répartit automatiquement
Retirez le choix du modèle de l’interface — le client expose un seul nom de modèle, la planification tourne sur le modèle fort et l’exécution atterrit sur le modèle économique, répartis sur le saut que la requête faisait déjà.
Ce dont la communauté se plaint réellement
« Chacun a un modèle différent dans ses réglages et le même prompt donne un résultat différent pour deux personnes », « la question la plus fréquente la première semaine est quel modèle choisir », « retirer un modèle signifie modifier des variables d’environnement sur chaque machine de développeur. » Le choix du modèle a été confié aux personnes les moins informées pour le faire : elles ne voient pas leurs propres dépenses et n’ont aucun moyen de savoir si cette requête mérite le modèle fort.
Basculez tout le monde sur un modèle bon marché et le travail se dégrade — confiez la planification et le jugement architectural à un petit modèle et les reprises coûtent plus que les économies. La séparation qui compte vraiment est ce que fait cette requête, planification ou exécution, et le client ne l’a jamais dit à la passerelle.
Comment GateLLM procède
Le client garde un seul nom de modèle ; un mappage fourre-tout (de "*") sur la passerelle normalise le nom que le client demande, de sorte que modifier ses réglages personnels ne change plus où la requête atterrit. Il ne reste plus rien à expliquer sur le choix du modèle.
Le signal de répartition est déjà dans la conversation : le mode plan de Claude Code injecte Plan mode is active à l’entrée et Exited Plan Mode à la sortie. Un script d’emplacement avant scanne en arrière depuis le dernier message, prend le dernier marqueur vu pour déterminer l’état courant, puis appelle context.useModel() pour changer le routage. La décision est une comparaison de positions dans une chaîne — aucun appel de classification séparé, aucun saut réseau supplémentaire.
La répartition doit vivre dans l’emplacement avant : l’emplacement après voit le corps amont traduit et ne peut pas lire les marqueurs injectés par le client, et useModel en emplacement après ne bascule qu’au sein du même protocole, alors que passer du plan à l’exécution est un changement de route entre modèles. Les règles request_payload (prompt_cache_key et compagnie) doivent être configurées sur les deux modèles : le modèle d’entrée garde les siennes pendant la planification, celles du modèle cible s’appliquent une fois la bascule faite.
5 leviers qui portent réellement
- Nom d’entrée unique : le client expose un seul nom de modèle et un mappage fourre-tout « de * » normalise chaque nom demandé en un seul modèle d’atterrissage
- Répartition automatique : un script d’emplacement avant prend le dernier marqueur en scannant en arrière — le marqueur d’entrée reste dans l’historique pour toujours, donc une vérification « contient » lit l’état comme mode plan de façon permanente
- Garde de protocole : le script vérifie d’abord context.sourceProtocol et sort tôt pour le trafic non Anthropic, de sorte qu’un modèle d’entrée servant plusieurs clients n’est jamais mal routé
- Observable : une étiquette SW dans la colonne modèle des journaux marque une bascule de script et MM un mappage d’identité ; les statistiques et la facturation imputent selon le nom final du modèle, donc chaque décision de répartition est auditable
- Zéro déploiement client : les changements de configuration ne nécessitent aucune modification par machine et les mappages se rechargent à chaud (seule exception : le plafond de tas du script SCRIPT_MEMORY_LIMIT_MB, qui exige un redémarrage)