Gi opp cc-switch: Å administrere flere Claude Code-leverandører krever egentlig bare ett skript
For noen som ofte må bytte mellom ulike leverandører av Claude Code-stormodell-API, er praktisk administrasjon og bytting av API et absolutt behov.
Først, hvorfor trenger man flere API-leverandører?
Det er hovedsakelig to grunner:
Problemer med samtidige kall og kvoter. Det er dagligdags å kjøre flere Claude Code-forekomster, og hvis alle oppgaver kjører hos bare én leverandør, er det lett å støte på begrensninger.
De ulike modellene har sine spesialiteter. Hvis A ikke klarer et problem, kan man prøve B. Eller la A skrive kode, og la B gjøre Code Review.
I en periode brukte jeg cc-switch, som er et bra gratis åpen kildekode-program. Det kan ikke bare administrere flere leverandører, men også ferdigheter, mcp, og prompts. Dessuten støtter det ikke bare Claude Code, men også codex, Gemini, og OpenCode.

Men problemet er nettopp at det tilbyr for mange funksjoner, og de blir stadig flere. Jeg tror mange produktutviklere har vanskelig for å si nei til å tilfredsstille ulike folks behov, og dermed gjøre produktet mer og mer komplekst; og brukerne liker også alltid at funksjoner er 'jo flere, jo bedre' – kanskje trenger man dem i fremtiden selv om man ikke trenger dem nå.
Min filosofi har alltid vært «Mindre er mer». For å støtte så mange verktøy har noen ting blitt mer kompliserte. Jeg bruker bare CC, så disse funksjonene og kompleksiteten har ingen verdi for meg, og blir i stedet en byrde.
cc-switch vedlikeholder sin egen konfigurasjonsfil. Når flere leverandører må dele konfigurasjon, må den vedlikeholde en separat felleskonfigurasjon. Den skriver ofte til .claude/settings.json, og det oppstår ofte problemer her, spesielt når man bytter leverandør hyppig.
Et annet problem er å starte flere CC-forekomster med forskjellige leverandører samtidig – også dette er et problem (i hvert fall når jeg brukte det, kunne byttet ofte være ufullstendig og føre til feilende forespørsler). Hvis man bruker proxy-funksjonen, må alle byttes sammen, og man kan ikke velge forskjellige leverandører i forskjellige forekomster.
Mine behov er enkle:
Konfigurasjon vedlikeholdes samlet (bare én versjon)
Mulighet til å bruke forskjellige leverandører i forskjellige CC-forekomster.
Basert på dette målet er implementeringen også enkel: lagre felleskonfigurasjon i brukerens settings.json. Å endre leverandør handler egentlig om å endre de miljøvariablene CC bruker, noe et shell-skript kan løse. Så jeg lagde mitt eget hjul med CC og skrev et ccs-skript som støtter et valgfritt -p-parameter for å spesifisere leverandør.
Dermed kan jeg:
ccs -p glm
ccs -p minimax
ccs -p kimi
ccs -p arkOg videre, ved å opprette alias, kan jeg direkte starte Claude Code med en spesifikk leverandør ved å bruke mm, ark.
alias mm="ccs -p minimax"
alias ark="ccs -p ark"Og deretter, kombinert med zellij, enkelt administrere flere CC med forskjellige leverandører.
Det er enkelt, lett å vedlikeholde, og man kan starte flere forekomster med valgfri leverandør.
Hverdagen ser slik ut.






