El cambio de Provider con CC Switch resuelve un problema real: cuando un mismo equipo usa servicios oficiales, APIs de terceros y modelos locales, modificar manualmente varios clientes deja errores con facilidad. Primero haz funcionar un Provider y añade interfaces locales y rutas de respaldo de forma gradual.
Establece primero un único Provider
En CC Switch selecciona la herramienta destino, como Claude Code o Codex, añade un Provider y configura solo una Base URL, API key y modelo. Guarda, reinicia completamente terminal y cliente, y ejecuta una solicitud sencilla para confirmar que responde el nuevo Provider.
Antes de que funcione, no actives a la vez proxies, sincronización, varios alias y fallback. Demasiadas variables eliminan la capacidad de diagnosticar.
Conecta una API local compatible con OpenAI
Que Ollama, LM Studio, vLLM y servicios similares puedan conectarse depende de que expongan una interfaz compatible con el cliente y de que el Provider admita Base URL y nombre de modelo personalizados. Comprueba:
- Que el servicio escucha en una dirección accesible desde el equipo actual.
- Que el modelo coincide con el nombre realmente expuesto por el servicio.
- Si el servicio local necesita key o solo acepta solicitudes locales.
- Que contexto, concurrencia y VRAM bastan para trabajo real.
Para elegir y conectar una API local, consulta usar APIs de modelos locales con Codex; para LM Studio, consulta API compatible con OpenAI de LM Studio.
Estrategia práctica para varios Providers
- Desarrollo diario: prioriza un Provider estable y de coste predecible.
- Tareas largas o revisión importante: cambia manualmente a un modelo más potente, sin depender de reemplazos automáticos ocultos.
- Modelos locales: úsalos en pasos fijos de bajo riesgo, privados u offline.
- Ante fallos: revisa salud y cuota antes de cambiar; no reintentes continuamente consumiendo límites.
Si quieres reunir prioridades ascendentes y fallback bajo un endpoint, combina CC Switch con 9Router: CC Switch gestiona clientes y 9Router gestiona el enrutamiento.
Resumen
Lo importante no es cuántas direcciones puedes introducir, sino verificar cada cambio. Conserva una configuración única verificable, reinicia clientes, confirma nombres de modelo y solo después amplía a modelos locales y varios Providers.
Qué debe contener una entrada Provider
Da a cada Provider una entrada clara con propósito, endpoint, regla de nombres de modelos, autenticación y fecha de verificación. Nombres como «respaldo» o «API nueva» no bastan: semanas después no sabrás si sirve para revisión de código, herramientas o si aún tiene cuota.
| Campo | Función |
|---|---|
| Nombre visible | Distinguir Providers oficiales, de equipo, locales y de prueba |
| Base URL | Registrar la dirección raíz de la API compatible |
| Nombre de modelo | Evitar confundir alias del cliente con nombres del servicio |
| Origen de key | Registrar solo ubicación o cuenta, nunca un secreto del repositorio |
| Uso previsto | Desarrollo diario, tareas largas, pruebas offline, etc. |
Qué validar antes y después de cambiar
Antes del cambio registra Provider y modelo actuales y conserva una tarea de prueba sin cambios de archivos. Después verifica que la salida procede del modelo esperado, que las llamadas a herramientas siguen funcionando, que el proyecto conserva permisos correctos y que los fallos muestran un error claro. Si el nuevo Provider es incompatible, podrás volver de inmediato a una configuración conocida.
Para servicios locales compatibles con OpenAI, confirma la dirección de escucha además de la Base URL. Si solo se usa en el mismo equipo, vincúlalo a loopback cuando sea posible, en lugar de exponerlo a la LAN. Evalúa autenticación y firewall por separado antes de permitir otros dispositivos.
Riesgos de desajuste entre nombre y capacidad del modelo
Compatibilidad de API no significa capacidades idénticas. Un servicio puede aceptar chat pero no herramientas, imágenes, contexto largo o streaming requerido por el cliente. Prueba el flujo real; no migres todo solo porque diga «OpenAI compatible».
Si la salida se vuelve muy breve, falla el formato de llamadas a herramientas o el contexto se llena rápido, revisa capacidad del modelo, versión del servicio y límite de contexto, no solo la key. Para problemas de memoria y KV cache de vLLM, consulta diagnóstico de vLLM KV Cache.
Coste y observabilidad
El cambio de Provider también necesita límites de coste. Registra qué Provider usa por defecto cada tipo de tarea, si los fallos reintentan automáticamente y cuánto se guardan los registros. En modelos locales, incluye tiempo de ejecución, electricidad y mantenimiento humano; comparar solo el precio de API es incompleto.
FAQ: ¿Por qué sigue usándose el modelo anterior tras cambiar?
Las causas comunes son una terminal antigua abierta, una variable de proyecto que sobrescribe, un alias no actualizado o una sesión en caché. Crea una sesión nueva, reinicia el cliente y revisa los registros de solicitudes.
FAQ: ¿Puedo importar todas las API keys?
Importa solo las cuentas necesarias y de confianza. Las herramientas de gestión y las carpetas sincronizadas son objetivos valiosos; comprueba cifrado, control de acceso y revocación antes de activar sincronización.