¿Claude Code sin cuota? Relés de API, conmutación por error y control de costes explicados

Cuando Claude Code dice que te quedaste sin cuota, esperar el reinicio o comprar un plan más caro no son las únicas opciones.

Si además de Claude Code usas herramientas como Codex u OpenCode, pueden pasar más cosas: cada agente necesita su propia configuración de modelo, una ruta inestable interrumpe una tarea en curso y, a fin de mes, no sabes cuántos tokens consumió realmente cada tarea.

Este artículo responde tres preguntas: cómo saber si te topas con un límite de cuota, una limitación de tasa o un error de configuración; cómo unificar el acceso a los modelos y configurar rutas de respaldo con un relay de API; y cómo verificar el uso y estimar el coste de cada sesión.

La versión corta: con una sola cuenta oficial y un uso ligero, el canal oficial suele ser más sencillo. Un relay de API vale la pena cuando necesitas acceso unificado a varios modelos, facturación centralizada o conmutación por error entre rutas upstream autorizadas.

1. Primero confirma: ¿cuota agotada, limitación de tasa o error de configuración?

Cambiar a un servicio de relay en cuanto ves “request failed” suele empeorar las cosas. Errores distintos requieren respuestas distintas.

Algunas limitaciones de tasa se recuperan en minutos; cambiar de ruta una y otra vez puede sumar más solicitudes fallidas. Lo que de verdad importa es saber cuántas rutas tienes, cuándo cambiar y si la tarea en curso puede continuar después del cambio.

2. Qué puede y qué no puede hacer un relay de API

Un relay de API se sitúa entre tus agentes y los proveedores de modelos. Los agentes envían las solicitudes al relay, y este las dirige a los modelos upstream configurados.

Suele ser bueno en cuatro cosas:

• Acceso unificado: todos los agentes comparten una misma Base URL, una misma lista de modelos y un mismo registro de uso.
• Conmutación por error: cuando se cumplen las condiciones de reintento, el tráfico pasa de la ruta actual a una de respaldo.
• Enrutado de modelos: elegir modelos según un orden de prioridad, el estado de la cuota o el tipo de tarea.
• Control de costes: ver tokens, accesos a caché, número de solicitudes y gasto en un solo lugar.

No puede crear cuota oficial de la nada, ni darle a un modelo visión, tool calls o contexto largo que no tiene. Un flujo que se corta después de empezar a emitir tampoco puede continuarse sin costuras en otro modelo.

Agrupar cuentas de suscripción de consumo, compartir cookies o usar keys de origen desconocido conlleva riesgos para la seguridad de la cuenta y frente a los términos del upstream. Antes de elegir un servicio, confirma que los modelos y el acceso a la API son legítimos y que usas rutas upstream autorizadas.

3. Gestionar varios agentes sin repetirte

Claude Code, Codex y OpenCode no comparten un mismo formato de configuración. Añade unos modelos, y las Base URLs, las API keys y los nombres de modelos acaban dispersos en varios archivos.

Conectado todo a un relay, centralizas el origen de los modelos y le das a cada agente su endpoint. El flujo habitual:

1. Crea tu propia API key en el relay y fija un límite de uso.
2. Comprueba qué protocolos, nombres de modelos y Base URL admite realmente el servicio.
3. Rellena la configuración del agente y guarda una copia del original por si hay que revertir.
4. Envía una única solicitud de prueba mínima antes de ejecutar tareas reales.
5. Verifica en la página de uso que la solicitud quedó registrada correctamente.

Para clientes que admiten variables de entorno de Anthropic, la configuración suele verse así:

export ANTHROPIC_BASE_URL="la URL del endpoint que tu servicio proporciona realmente"
export ANTHROPIC_AUTH_TOKEN="la API key que creaste tú mismo"

Los nombres de las variables, los protocolos y los esquemas de autenticación cambian de un cliente a otro; guíate por la documentación vigente de tu cliente y del relay. No confundas la dirección de un relay local con un endpoint de producción, y nunca pegues keys reales en capturas, logs o artículos públicos.

Para una prueba rápida, define las variables en una sesión de terminal independiente en lugar de escribirlas en archivos de configuración permanentes. Hazlas persistentes solo cuando todo funcione.

4. La conmutación por error no va de “acumular más cuentas”

Una conmutación de verdad responde preguntas concretas:

• ¿Qué errores admiten reintento y cuáles deben fallar de inmediato?
• Cuando la ruta actual cae, ¿en qué orden se eligen las de respaldo?
• ¿Una sesión conserva su modelo y su ruta, evitando incompatibilidades de contexto o de formato de razonamiento?
• ¿Qué pasa cuando el flujo se rompe después de que ya se envió contenido al cliente?
• ¿Pueden los reintentos generar solicitudes duplicadas y cargos extra?

Estrategias de enrutado habituales:

• Principal/respaldo: preferir la ruta principal; cambiar cuando se cumplen las condiciones.
• Round-robin: repartir las solicitudes en rotación entre las rutas disponibles.
• Menor uso: preferir la ruta con el uso actual más bajo.
• Planificación por ventana de cuota: organizar las rutas según la cuota restante y las horas de reinicio.
• Intención de la tarea: enviar la programación compleja a modelos más potentes y las ediciones pequeñas a otros más rápidos y baratos.

Para tareas largas, más rutas no significa más estabilidad. Lo que importa es una gestión de errores explícita, el soporte de tu protocolo y de tus tool calls, y un registro de solicitudes trazable.

5. Calcular cuánto costó cada tarea

El control de costes debe al menos separar tokens de entrada, tokens de salida, lecturas y escrituras de caché y tokens de razonamiento, e indicar la fuente de precios y el momento del recuento.

Supón que una tarea consume 1 millón de tokens de entrada y 100 000 tokens de salida, con la entrada a X por millón de tokens y la salida a Y por millón. Sin contar caché ni otros cargos, la estimación es:

coste = (100 ÷ 100) × X + (10 ÷ 100) × Y

Al cotejar una factura real, confirma además:

• si la entrada y la salida tienen precios unitarios distintos;
• si las lecturas y escrituras de caché se facturan aparte;
• si los tokens de razonamiento cuentan como salida;
• cómo se facturan las solicitudes fallidas y los reintentos automáticos;
• si hay comisiones de servicio, diferenciales de cambio o multiplicadores de modelo;
• si la página muestra los cargos reales o una estimación a precios de lista.

Las suscripciones y la facturación por uso de la API son sistemas contables distintos. El “coste de sesión” que muestra un relay no es necesariamente el dinero que sale de tu banco por esa tarea. Poder exportar los registros y revisarlos línea por línea vale más que un único saldo global.

6. Siete puntos a revisar antes de elegir un servicio de relay

1. Compatibilidad real de modelos y protocolos. Ve más allá del nombre: confirma que el streaming, los tool calls, la visión, los parámetros de razonamiento y la longitud de contexto cubren tus tareas.

2. Precios que puedas recalcular. Una tabla de precios completa cubre entrada, salida, caché, multiplicadores, comisiones de servicio y reglas de reembolso — no solo “hasta X % de descuento”.

3. Gestión de fallos transparente. Comprueba qué errores se reintentan, dónde está el límite de conmutación y si existe una página de estado con historial de mantenimiento.

4. Conservación de solicitudes y logs. Revisa qué se guarda — prompts, respuestas, IPs, keys, logs de solicitudes — durante cuánto tiempo y quién puede acceder.

5. Límites y revocación de keys. Prefiere servicios con keys independientes, topes de cuota, permisos de modelos por key y revocación en cualquier momento.

6. Uso verificable. Lo ideal es consultar los registros por modelo, key, sesión y solicitud, y poder exportarlos.

7. Alguien a quien acudir cuando algo falla. Los términos del servicio, la entidad operadora, los canales de soporte, los avisos de mantenimiento y los procesos de reembolso deberían ser fáciles de encontrar.

Esto pesa más que “el más barato de la red”, “nunca te bloquean” o “absolutamente estable”. Las promesas que no puedes verificar no deberían decidir por ti.

7. Cuándo no necesitas un relay en absoluto

Si usas un solo agente con una sola cuenta oficial, tienes cuota de sobra y nunca llamas a varios modelos, la conexión directa elimina una pieza intermedia.

Si solo sufres limitaciones de tasa breves y ocasionales, revisar la hora de reinicio y el estado del servicio puede resolverlo.

El valor de un relay de API está en reducir el coste de gestionar varios modelos, herramientas y rutas. Que te compense depende de tu volumen de llamadas, tus exigencias de estabilidad, la sensibilidad de tus datos y de que el proveedor sepa explicar con claridad sus precios y sus registros de ejecución.

Antes de comprometerte, prueba con un saldo pequeño y un proyecto poco sensible: logra pasar una solicitud mínima, concilia una factura y simula la caída de la ruta principal. Cuando las tres cosas cuadren, ya puedes usarlo en trabajo real.