Отказ от cc-switch: Управлението на множество доставчици на Claude Code всъщност се нуждае само от един скрипт

За човек, който често трябва да превключва между доставчици на API за големия модел Claude Code, удобното управление и превключване на API е наложителна нужда.

Първо, защо са необходими множество доставчици на API?

Има две основни причини:

1. Проблеми с едновременните извиквания и лимитите. Отварянето на множество инстанции на Claude Code е обичайно, ако всички задачи се изпълняват само с един доставчик, лесно се срещат ограничения.

2. Няколкото модели имат различни силни страни. Ако модел А не работи за даден проблем, може да се опита с модел Б. Или А да пише код, а Б да прави преглед на кода.

В течение на известно време използвах cc-switch, което е добър безплатен софтуер с отворен код. Той не само управлява множество доставчици, но има и функции за управление на умения, MCP, подкани. Освен това поддържа не само Claude Code, но и codex, Gemini, OpenCode.

Но проблемът му е точно, че предлага твърде много функции, които стават все повече. Мисля, че много хора, които създават продукти, трудно отказват да задоволят различните нужди на различни хора, и така продуктът става все по-сложен; а потребителите на инструменти винаги предпочитат повече функции, дори ако не ги използват сега, може да им потрябват в бъдеще.

Моята философия винаги е била „По-малко е повече“. За да поддържа толкова много инструменти, някои неща стават сложни. Аз използвам само CC, така че тези функции и сложност нямат стойност за мен, а вместо това се превръщат в тежест.

cc-switch сам поддържа конфигурационни файлове. Когато множество доставчици трябва да споделят конфигурация, той трябва да поддържа отделна обща конфигурация. Той самият често записва в .claude/settings.json , където често възникват проблеми, особено при често превключване на доставчици.

Друг проблем е, че ако се стартират множество инстанции на CC с различни доставчици едновременно, това също създава проблеми (поне по време на моето използване, превключването не винаги е пълно, което води до неуспешни заявки). Ако се използва неговата прокси функция, тогава всичко се превключва заедно и не може да се избере различен доставчик за различни инстанции.

Моите нужди също са прости:

• Единна поддръжка на конфигурацията (само една версия)

• Различни инстанции на CC да могат да използват различни доставчици.

Въз основа на тази цел реализацията е проста: да се съхранява една конфигурация в потребителския settings.json . Промяната на доставчика всъщност означава промяна на няколко променливи на средата на CC, което може да се реши с един shell скрипт. Затова аз самият създадох свое решение с CC, написах скрипт ccs, който поддържа незадължителен параметър -p за указване на доставчик.

Така мога да правя:

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

Идвайки по-нататък, създавам псевдоними, така че директно с mm, ark мога да стартирам Claude Code с определен доставчик.

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

След това, в комбинация с zellij, лесно се управляват множество CC с различни доставчици.

Това е едновременно просто, лесно за поддръжка и позволява произволно стартиране на множество инстанции с различни доставчици.

Ето как изглежда ежедневието.