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

Pour une personne qui doit fréquemment changer de fournisseur d'API pour le grand modèle Claude Code, une gestion et une commutation pratiques des API sont un besoin essentiel.

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 pour un problème, on peut essayer un autre. Ou bien utiliser A pour écrire et B pour la revue de code.

Pendant un certain temps, j'ai utilisé cc-switch, un logiciel libre et gratuit de qualité. Il permet non seulement de gérer plusieurs fournisseurs, mais aussi de gérer les compétences, MCP, les invites, etc. De plus, il prend en charge non seulement 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 de s'ajouter. Je pense que beaucoup de concepteurs de produits ont du mal à résister à la tentation de satisfaire les divers besoins des utilisateurs, ce qui rend le produit de plus en plus complexe ; et les utilisateurs aiment toujours avoir plus de fonctionnalités, 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 ses fichiers de configuration, et lorsqu'il faut partager des configurations entre plusieurs fournisseurs, il doit maintenir une configuration générale séparément. 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 entraîner des échecs de requêtes dus à des commutations incomplètes). Si on utilise sa fonction de proxy, on ne peut 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 (un seul fichier)

• 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 . Modifier le fournisseur revient essentiellement à changer les variables d'environnement de CC, ce qu'un script shell peut résoudre. J'ai donc créé ma propre solution avec CC, en écrivant un script appelé ccs, qui prend 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, je peux directement lancer Claude Code avec un fournisseur spécifique en utilisant mm, ark .

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

Ensuite, en combinant avec zellij, il est facile de gérer plusieurs instances de CC avec différents fournisseurs.

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

Voici à quoi ressemble mon quotidien.