Renunțarea la cc-switch: Pentru a gestiona mai mulți furnizori de Claude Code, de fapt este nevoie doar de un script

Pentru cineva care are nevoie să comute frecvent între furnizorii de API pentru modelul de mare dimensiune Claude Code, gestionarea și comutarea convenabilă a API-urilor este o necesitate absolută.

În primul rând, de ce este nevoie de mai mulți furnizori de API?

Există două motive principale:

1. Probleme legate de concurența apelurilor și limitele de utilizare; este obișnuit să rulezi mai multe instanțe Claude Code simultan, iar dacă toate sarcinile rulează pe același furnizor, există riscul de a întâmpina blocaje.

2. Mai multe modele au puncte forte diferite; dacă un model A nu reușește să rezolve o problemă, poți încerca cu modelul B. Sau poți folosi A pentru scriere și B pentru revizuirea codului.

Pentru o perioadă de timp, am folosit cc-switch, un software gratuit și open-source destul de bun. Nu doar că gestionează mai mulți furnizori, dar are și funcții pentru gestionarea skill-urilor, MCP-urilor și prompt-urilor. În plus, suportă nu doar Claude Code, ci și Codex, Gemini, OpenCode.

Dar problema lui tocmai este că oferă prea multe funcții, iar acestea continuă să crească. Cred că mulți oameni care dezvoltă produse au dificultăți în a refuza să satisfacă diversele nevoi ale diferitelor persoane, făcând produsul din ce în ce mai complex; iar utilizatorii instrumentelor tind să prefere cât mai multe funcții, chiar dacă nu le folosesc acum, ar putea avea nevoie de ele în viitor.

Filosofia mea a fost întotdeauna „Mai puțin înseamnă mai mult”. Pentru a suporta atât de multe instrumente, unele aspecte au devenit complexe. Eu folosesc doar CC, așadar aceste funcții și complexitate nu au valoare pentru mine, devenind mai degrabă o povară.

cc-switch își gestionează propriul fișier de configurare, iar atunci când mai mulți furnizori trebuie să partajeze configurații, trebuie să mențină o configurație generală separată. El scrie frecvent în .claude/settings.json , iar aici apar adesea probleme, în special atunci când se comută frecvent între furnizori.

O altă problemă este că, atunci când pornești mai multe instanțe CC cu diferiți furnizori simultan, apar și aici dificultăți (cel puțin în experiența mea, comutarea incompletă duce adesea la eșecul solicitărilor). Dacă folosești funcția sa de proxy, atunci toate instanțele trebuie să comute împreună, fără posibilitatea de a alege furnizori diferiți pentru instanțe diferite.

Necesitățile mele sunt simple:

• Configurația să fie menținută unitar (doar o singură copie)

• Să pot folosi furnizori diferiți în instanțe CC diferite.

Bazat pe acest obiectiv, implementarea este simplă: stochează configurația unitară în fișierul utilizatorului settings.json. Modificarea furnizorului înseamnă de fapt schimbarea acelor variabile de mediu ale CC; un script shell poate rezolva asta, așa că am creat propriul instrument folosind CC, scriind un script numit ccs, care acceptă un parametru opțional -p pentru a specifica furnizorul.

Astfel, pot face:

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

Mergând mai departe, pot crea alias-uri, astfel încât să pot porni Claude Code cu un furnizor specific direct folosind mm, ark.

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

Apoi, combinând cu zellij, pot gestiona cu ușurință mai multe instanțe CC cu furnizori diferiți.

Este simplu, ușor de întreținut și permite deschiderea mai multor instanțe cu furnizori specificați la alegere.

Iată cum arată în practică.