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

Para alguien que necesita cambiar frecuentemente entre proveedores de API del modelo Claude Code, una gestión y cambio convenientes 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 un solo proveedor, es fácil encontrarse con límites.

2. Los diferentes modelos tienen sus propias fortalezas. Si uno no funciona para un problema, se puede 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 usuarios, 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 a veces causa 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 presenta fallos (al menos en mi experiencia, los cambios incompletos pueden causar errores en las solicitudes). Si se usa su función de proxy, solo se puede cambiar todo a la vez, sin poder seleccionar diferentes proveedores en distintas instancias.

Mis necesidades son simples:

• Configuración mantenida de manera unificada (solo un archivo).

• 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 de 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 específicos libremente.

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