Abandonner cc-switch : Gérer plusieurs fournisseurs de Claude Code ne nécessite en réalité qu'un seul script

Pour une personne qui a souvent besoin de changer de fournisseur d'API pour le grand modèle Claude Code, une gestion et une commutation pratiques des API sont une nécessité absolue.

Tout d'abord, pourquoi avoir besoin de plusieurs fournisseurs d'API ?

Il y a principalement deux raisons :

1. Les problèmes de concurrence d'appels et de quotas, il est courant d'ouvrir plusieurs instances de Claude Code, et si toutes exécutent des tâches avec un seul fournisseur, cela peut facilement entraîner des blocages.

2. Les différents modèles ont chacun leurs points forts ; si l'un ne fonctionne pas, on peut essayer un autre. Ou bien, l'un écrit le code et l'autre fait la revue de code.

Pendant un certain temps, j'ai utilisé cc-switch, un logiciel libre et gratuit plutôt bon. Il permet non seulement de gérer plusieurs fournisseurs, mais aussi de gérer les compétences, les MCP, les invites, etc. De plus, il ne prend pas seulement en charge Claude Code, mais aussi Codex, Gemini, OpenCode.

Mais son problème réside précisément dans le fait qu'il offre trop de fonctionnalités, et elles ne cessent d'augmenter. Je pense que beaucoup de personnes qui développent des produits ont du mal à résister à la tentation de satisfaire les divers besoins de chacun, rendant ainsi le produit de plus en plus complexe ; et les utilisateurs d'outils aiment toujours avoir le plus de fonctionnalités possible, même si elles ne sont pas utiles maintenant, elles pourraient l'être à l'avenir.

Ma philosophie a toujours été « Less is more ». Pour prendre en charge autant d'outils, certaines choses deviennent compliquées ; comme je n'utilise que CC, ces fonctionnalités et cette complexité n'ont aucune valeur et deviennent plutôt un fardeau.

cc-switch gère lui-même les fichiers de configuration, et lorsqu'il faut partager des configurations entre plusieurs fournisseurs, il doit maintenir séparément une configuration générale. Il écrit souvent dans .claude/settings.json , ce qui peut causer des problèmes, surtout lors de changements fréquents de fournisseur.

Un autre problème est que lancer plusieurs instances de CC avec différents fournisseurs simultanément pose également des difficultés (du moins, de mon expérience, cela peut facilement entraîner des échecs de requêtes dus à une commutation incomplète). Si on utilise sa fonction de proxy, on ne peut alors changer que tous ensemble, sans pouvoir choisir différents fournisseurs pour différentes instances.

Mes besoins sont assez simples :

• Configuration maintenue de manière unifiée (une seule copie)

• Pouvoir utiliser différents fournisseurs pour différentes instances de CC.

Sur cette base, la mise en œuvre est simple : stocker la configuration unifiée dans le fichier utilisateur settings.json . Changer de fournisseur revient essentiellement à modifier ces variables d'environnement de CC, ce qu'un script shell peut résoudre. J'ai donc créé ma propre solution en utilisant CC, en écrivant un script appelé ccs, qui prend en charge un paramètre optionnel -p pour spécifier le fournisseur.

Ainsi, je peux faire :

ccs -p glm 
ccs -p minimax
ccs -p kimi
ccs -p ark

En allant plus loin, en créant des alias, on peut directement lancer Claude Code avec un fournisseur spécifique en utilisant mm, ark .

alias mm="ccs -p minimax"
alias ark="ccs -p ark"

Puis, en combinant avec zellij, on peut facilement gérer plusieurs instances de CC avec différents fournisseurs.

C'est à la fois simple, facile à maintenir, et permet de lancer plusieurs instances avec des fournisseurs spécifiés à volonté.

Voici à quoi ressemble le quotidien.