Abandonando cc-switch: Para gerenciar múltiplos fornecedores do Claude Code, na verdade só é necessário um script

Para alguém que frequentemente precisa alternar entre provedores de API do modelo Claude Code, um gerenciamento e alternância convenientes da API são uma necessidade básica.

Primeiro, por que são necessários múltiplos provedores de API?

Existem principalmente duas razões:

1. Questões de concorrência de chamadas e limites de uso. É comum executar várias instâncias do Claude Code; se todas estiverem executando tarefas usando apenas um provedor, é fácil atingir limites.

2. Os diferentes modelos têm seus pontos fortes. Se um não resolver um problema, pode-se tentar outro. Ou usar um para escrever e outro para fazer revisão de código.

Por um tempo, usei o cc-switch, que é um bom software gratuito e de código aberto. Ele não apenas gerencia múltiplos provedores, mas também tem funções para gerenciar habilidades, MCP e prompts. Além disso, ele suporta não apenas Claude Code, mas também Codex, Gemini e OpenCode.

Mas seu problema é exatamente que ele oferece muitas funcionalidades, e elas continuam aumentando. Acho que muitas pessoas que desenvolvem produtos têm dificuldade em resistir a atender às diversas necessidades de diferentes usuários, tornando o produto cada vez mais complexo; e os usuários de ferramentas sempre gostam de mais e mais funcionalidades, mesmo que não usem agora, podem usar no futuro.

Minha filosofia sempre foi "Menos é mais". Para suportar tantas ferramentas, algumas coisas se tornaram complexas. Eu só uso o CC, então essas funcionalidades e complexidades não têm valor para mim, tornando-se um fardo.

O cc-switch mantém seu próprio arquivo de configuração. Quando múltiplos provedores precisam compartilhar configurações, ele precisa manter uma configuração comum separadamente. Ele frequentemente escreve no .claude/settings.json , onde problemas frequentemente ocorrem, especialmente ao alternar entre provedores com frequência.

Outro problema é iniciar múltiplas instâncias do CC com provedores diferentes simultaneamente; isso também apresenta problemas (pelo menos quando eu usava, a alternância incompleta frequentemente causava falhas nas requisições). Se usar sua funcionalidade de proxy, só é possível alternar todos juntos, não sendo possível escolher provedores diferentes para instâncias diferentes.

Minhas necessidades são simples:

• Configuração mantida de forma unificada (apenas um arquivo)

• Poder usar provedores diferentes em diferentes instâncias do CC.

Com base nesse objetivo, a implementação é simples: armazenar a configuração unificada no settings.json do usuário. Alterar o provedor basicamente significa mudar aquelas variáveis de ambiente do CC, o que pode ser resolvido com um script shell. Então, usei o CC para reinventar a roda, criando um script chamado ccs, que suporta um parâmetro opcional -p para especificar o provedor.

Assim, posso fazer:

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

Indo além, criei aliases para usar mm, ark diretamente e iniciar o Claude Code com o provedor especificado.

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

E então, combinando com o zellij, gerencio facilmente múltiplos CCs com provedores diferentes.

É simples, fácil de manter e permite abrir múltiplas instâncias com provedores especificados livremente.

É assim no dia a dia.