Abandonando cc-switch: Para gestionar múltiples proveedores de Claude Code, en realidad solo necesitas un script

Para alguien que necesita cambiar frecuentemente entre proveedores de API del modelo Claude Code, una gestión y cambio cómodos de la API son una necesidad básica.

Primero, ¿por qué se necesitan múltiples proveedores de API?

Principalmente hay dos razones:

1. Problemas de concurrencia de llamadas y límites de cuota. Es común ejecutar múltiples instancias de Claude Code; si todas ejecutan tareas usando solo un proveedor, es fácil toparse con límites.

2. Los diferentes modelos tienen sus propias fortalezas. Si uno no funciona para un problema, puedes probar con otro. O usar A para escribir y B para revisar el código.

Durante un tiempo, utilicé cc-switch, un buen software gratuito y de código abierto. No solo gestiona múltiples proveedores, sino que también maneja habilidades, MCP, prompts, etc. Además, no solo es compatible con Claude Code, sino también con Codex, Gemini y OpenCode.

Pero su problema es precisamente que ofrece demasiadas funciones, y cada vez más. Creo que a muchos desarrolladores les cuesta resistirse a satisfacer las diversas necesidades de diferentes personas, haciendo el producto cada vez más complejo; y los usuarios de herramientas siempre prefieren más funciones, aunque no las usen ahora, podrían necesitarlas en el futuro.

Mi filosofía siempre ha sido «Menos es más». Para admitir tantas herramientas, algunas cosas se vuelven complejas. Yo solo uso CC, por lo que estas funciones y complejidad no tienen valor y, en cambio, se convierten en una carga.

cc-switch mantiene su propio archivo de configuración. Cuando múltiples proveedores necesitan compartir configuraciones, requiere mantener una configuración general por separado. A menudo escribe en .claude/settings.json , lo que puede causar problemas, especialmente al cambiar frecuentemente entre proveedores.

Otro problema es que al iniciar múltiples instancias de CC con diferentes proveedores simultáneamente, también surgen inconvenientes (al menos en mi experiencia, los cambios incompletos pueden causar fallos en las solicitudes). Si usas su función de proxy, solo puedes cambiar todos juntos y no seleccionar diferentes proveedores para distintas instancias.

Mis necesidades son simples:

• Configuración mantenida de manera unificada (solo una copia)

• Poder usar diferentes proveedores en distintas instancias de CC.

Basándome en este objetivo, la implementación es sencilla: almacenar la configuración unificada en el archivo settings.json del usuario. Cambiar el proveedor básicamente significa modificar esas variables de entorno de CC, lo que se puede resolver con un script de shell. Así que creé mi propia solución usando CC, escribiendo un script llamado ccs que admite un parámetro opcional -p para especificar el proveedor.

Entonces puedo hacer:

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

Yendo un paso más allá, creando alias, puedo iniciar Claude Code con un proveedor específico directamente usando mm, ark.

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

Luego, combinándolo con zellij, gestiono fácilmente múltiples instancias de CC con diferentes proveedores.

Es simple, fácil de mantener y permite abrir múltiples instancias con proveedores arbitrarios.

Así es mi día a día.