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. Problemas 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 encontrar limitações.

2. Os diferentes modelos têm seus pontos fortes. Se um problema não for resolvido pelo modelo A, pode-se tentar o modelo B. Ou usar A para escrever e B para fazer a 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 só gerencia múltiplos provedores, mas também tem funções para gerenciar habilidades, MCPs e prompts. Além disso, ele suporta não apenas o 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 recusar atender às diversas necessidades de diferentes usuários, acabando por tornar o produto cada vez mais complexo; e os usuários de ferramentas sempre preferem mais funcionalidades, mesmo que não as usem agora, podem precisar no futuro.

Minha filosofia sempre foi "Menos é mais". Para suportar tantas ferramentas, algumas coisas se tornaram complexas. Como só uso o CC, 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 grava no arquivo .claude/settings.json, o que pode causar problemas, especialmente ao alternar entre provedores com frequência.

Outro problema é iniciar múltiplas instâncias do CC com diferentes provedores simultaneamente. Isso também pode ser problemático (pelo menos quando eu usava, a alternância incompleta frequentemente causava falhas nas requisições). Se a funcionalidade de proxy for usada, só é possível alternar todos juntos, não sendo possível escolher provedores diferentes para instâncias distintas.

Minhas necessidades são simples:

• Manter a configuração de forma unificada (apenas um arquivo)

• Permitir que diferentes instâncias do CC usem provedores diferentes.

Com base nesse objetivo, a implementação é simples: armazenar a configuração unificada no arquivo settings.json do usuário. Alterar o provedor basicamente significa modificar aquelas variáveis de ambiente do CC, o que pode ser resolvido com um script shell. Então, usei o CC para criar minha própria solução, escrevendo 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 diretamente mm, ark 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 diferentes provedores.

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

No dia a dia, é assim.