Lëreni cc-switch: Për të menaxhuar shumë furnizues të Claude Code, në fakt duhet vetëm një skript

Për dikë që shpesh duhet të kalojë midis furnizuesve të API-së së modelit të madh Claude Code, menaxhimi dhe kalimi i lehtë i API-së është një nevojë e domosdoshme.

Së pari, pse duhen shumë furnizues API?

Kryesisht për dy arsye:

1. Problemi i thirrjeve të njëkohshme dhe kuotave, hapja e shumë instancave të Claude Code është e zakonshme; nëse të gjitha po ekzekutojnë detyra duke përdorur vetëm një furnizues, është e lehtë të ndeshesh në pengesa.

2. Disa modele kanë përkatësisht përparësitë e tyre; nëse A nuk funksionon për një problem, mund të provosh B. Ose A shkruan, dhe B bën Code Review.

Për një kohë kam përdorur cc-switch, i cili është një softuer i mirë falas dhe me burim të hapur. Jo vetëm që menaxhon shumë furnizues, por ka edhe funksione për menaxhimin e aftësive, mcp, dhe prompteve. Për më tepër, nuk mbështet vetëm Claude Code, por edhe codex, Gemini, OpenCode.

Por problemi i tij është pikërisht se ofron shumë funksione, dhe gjithnjë po shtohen më shumë. Unë mendoj se shumë njerëz që bëjnë produkte e kanë të vështirë të refuzojnë plotësimin e nevojave të ndryshme të njerëzve të ndryshëm, dhe pastaj e bëjnë produktin gjithnjë e më kompleks; dhe përdoruesit e mjeteve gjithashtu pëlqejnë që funksionet të jenë sa më shumë, edhe nëse nuk përdoren tani, mund të jenë të dobishme në të ardhmen.

Filozofia që unë ndiej është gjithmonë "Më pak është më shumë". Për të mbështetur kaq shumë mjete, disa gjëra janë bërë më komplekse; unë përdor vetëm CC, kështu që këto funksione dhe kompleksiteti nuk kanë vlerë, por në vend të kësaj janë bërë një barrë.

cc-switch menaxhon vetë skedarët e konfigurimit; kur shumë furnizues duan të ndajnë konfigurimin, ai duhet të menaxhojë veçmas një konfigurim të përgjithshëm. Ai vetë shpesh shkruan në .claude/settings.json , ku shpesh shfaqen probleme, veçanërisht kur kaloni shpesh midis furnizuesve.

Një problem tjetër është nisja e shumë instancave të CC me furnizues të ndryshëm njëkohësisht, edhe kjo ka probleme (të paktën kur e kam përdorur unë, kalimi jo i plotë shkakton dështim të kërkesave). Nëse përdoret funksioni i proxy-së së tij, atëherë mund të kaloni vetëm së bashku dhe nuk mund të zgjidhni furnizues të ndryshëm në instanca të ndryshme.

Nevojat e mia janë gjithashtu të thjeshta:

• Konfigurimi të menaxhohet në mënyrë të unifikuar (vetëm një kopje)

• Instanca të ndryshme të CC mund të përdorin furnizues të ndryshëm.

Bazuar në këtë qëllim, zbatimi është gjithashtu i thjeshtë: ruani konfigurimin e unifikuar në skedarin e përdoruesit settings.json . Ndryshimi i furnizuesit në thelb ndryshon ato variablat e mjedisit të CC, gjë që mund të zgjidhet me një skript shell, kështu që unë vetë bëra një rrotë me CC dhe shkrova një skript ccs, i cili mbështet një parametër opsional -p për të specifikuar furnizuesin.

Kështu mund të bëj:

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

Më tej, duke krijuar alias, mund të aktivizoj direkt Claude Code me furnizuesin e specifikuar duke përdorur mm、ark .

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

Pastaj, duke kombinuar me zellij, menaxhoni lehtësisht shumë CC me furnizues të ndryshëm.

E thjeshtë, e lehtë për t'u mirëmbajtur, dhe mund të hapni shumë instanca me furnizues të specifikuar sipas dëshirës.

Jeta e përditshme është kështu.