Ya pagas por esos modelos: conecta tus agentes sin otra factura de API

Imagina que ya estás pagando Claude Pro, Claude Max o ChatGPT Plus. Estás montando un agente y quieres probarlo con 1 de los modelos más avanzados incluidos en tu suscripción. Sin embargo, en cuanto intentas conectar el agente mediante una API, lo habitual es que tengas que crear una cuenta de desarrollador distinta, activar el pago por token o ingresar más dinero en un agregador como OpenRouter.

Es como pagar 2 veces por el mismo experimento de desarrollo. Si ya pagas por acceder a un modelo y todavía tienes cuota disponible, ¿por qué deberías generar otra factura antes de saber siquiera si la idea funciona?

Aquí es donde entra en juego CLIProxyAPI. Permite autenticar cuentas de pago compatibles mediante OAuth y colocar el acceso válido a sus modelos CLI detrás de 1 API local y compatible. En lugar de añadir una clave de proveedor con facturación por uso a un proyecto que todavía no está terminado, puedes apuntar el agente a localhost, probarlo con modelos ya incluidos en tu plan y pasar a una API de producción únicamente cuando el experimento justifique ese coste.

Por debajo, CLIProxyAPI guarda las credenciales OAuth localmente y expone endpoints compatibles con OpenAI, Anthropic, Gemini y Codex. El proxy traduce cada petición y la dirige al proveedor elegido. Esto resulta especialmente útil para evaluar modelos: puedes llamar a los que estén disponibles en ese momento para tus cuentas y comparar cómo se comportan ante la misma tarea sin generar una factura independiente de API por token para esas pruebas.

Hay un límite importante: una suscripción no es crédito de API y CLIProxyAPI no la convierte en ilimitada. Las peticiones utilizan la ruta CLI/OAuth compatible del proveedor y consumen la cuota asociada a esa cuenta. Siguen existiendo límites de velocidad, ventanas móviles de uso, disponibilidad de modelos, restricciones regionales y condiciones del proveedor. Yo lo utilizo para mi propio desarrollo y mis pruebas, no para revender acceso, compartir una cuenta, saltarme una cuota o publicar un proxy sin autenticación.

¿Qué cuentas de pago puedo usar?

El proyecto cambia rápidamente, por lo que considero su documentación actual de proveedores la fuente fiable. Los flujos respaldados por suscripción más relevantes son:

Cuenta	Login de CLIProxyAPI	Qué utiliza
Cuenta de ChatGPT con acceso a Codex	--codex-login	Los modelos de Codex y la cuota disponibles en ese momento para el plan de ChatGPT
Cuenta Claude Pro o Max con acceso a Claude Code	--claude-login	Los modelos de Claude Code y límites de uso incluidos en el plan
Cuenta de Google Antigravity	--antigravity-login	Los modelos y la cuota disponibles en ese momento para la cuenta

No hay que dar por hecho que comprar un plan de chat para consumidores desbloquea automáticamente todos los modelos o la API de desarrollo normal del proveedor. CLIProxyAPI solo puede exponer lo que permita el canal CLI autenticado. La forma fiable de descubrir ese conjunto es iniciar sesión y consultar /v1/models.

Esto también explica la principal diferencia económica. Con una clave de API normal, la entrada, la salida, la caché y el uso de herramientas pueden generar una factura medida. Con una cuenta OAuth compatible, estas peticiones al proxy consumen la cuota válida de la suscripción. Eso puede hacer predecible el coste de pruebas cortas, pero también puede gastar la cuota que necesitaré más tarde en el cliente de programación oficial del proveedor.

El recorrido de una petición

El proxy no ejecuta un modelo en mi ordenador. La ruta completa es:

Mi cliente
  -> http://127.0.0.1:8317
  -> CLIProxyAPI selecciona la cuenta OAuth correspondiente
  -> endpoint CLI del proveedor
  -> respuesta del modelo traducida para mi cliente

Como CLIProxyAPI acepta varias formas de protocolo, un experimento compatible con OpenAI puede llamar a /v1/chat/completions o /v1/responses, mientras que los clientes compatibles con Claude pueden usar la interfaz de mensajes de Anthropic. La descripción oficial también documenta streaming, llamadas a herramientas, imágenes y enrutamiento multicuenta cuando el proveedor de origen lo permite.

Una instalación local completa con Docker

Prefiero Docker en este caso porque aísla el binario y sus actualizaciones y, al mismo tiempo, deja claras las 2 piezas de estado persistente: config.yaml y auths/.

1. Crear un directorio de trabajo

mkdir -p cliproxyapi/auths
cd cliproxyapi

También creo un .gitignore:

auths/
logs/
.env

Aunque este directorio solo sirva para una prueba local, excluir auths/ es una segunda línea de defensa útil.

2. Crear config.yaml

host: "0.0.0.0"
port: 8317

auth-dir: "~/.cli-proxy-api"

api-keys:
  - "sustituye-esto-por-una-clave-local-larga-y-aleatoria"

remote-management:
  allow-remote: false
  secret-key: ""

debug: false
logging-to-file: false

0.0.0.0 es necesario dentro del contenedor para que Docker pueda redirigir tráfico al proceso. El archivo Compose del siguiente paso solo lo publica en la interfaz de loopback del host. Hay que sustituir la clave de ejemplo por un valor largo y aleatorio; es el bearer token que usarán los clientes locales.

La referencia de configuración incluye muchas más opciones, como reintentos, enrutamiento de cuentas, mapeos de modelos y gestión remota. Yo empiezo por la configuración mínima y añado únicamente lo necesario.

3. Crear compose.yaml

services:
  cli-proxy-api:
    image: eceasy/cli-proxy-api:latest
    container_name: cli-proxy-api
    ports:
      - "127.0.0.1:8317:8317"
      - "127.0.0.1:1455:1455"
      - "127.0.0.1:54545:54545"
      - "127.0.0.1:51121:51121"
    volumes:
      - ./config.yaml:/CLIProxyAPI/config.yaml:ro
      - ./auths:/root/.cli-proxy-api
    restart: unless-stopped

El puerto 8317 corresponde a la API. Los demás reciben callbacks OAuth: 1455 para Codex, 54545 para Claude y 51121 para Antigravity. Vincular cada puerto publicado a 127.0.0.1 mantiene el servicio fuera de la red local. El Compose oficial del proyecto expone puertos de proveedores y directorios persistentes adicionales; esta versión reducida es suficiente para los flujos del artículo.

Para entornos repetibles o compartidos fijaría una versión de la imagen que hubiese revisado en vez de usar latest. Tampoco montaría el socket de Docker ni activaría el modo privilegiado; este proxy no necesita ninguna de las 2 cosas.

4. Arrancar el proxy

docker compose up -d
docker compose logs --tail=50 cli-proxy-api

El servidor debería escuchar en el puerto 8317. Si termina inmediatamente, primero compruebo que config.yaml existe, contiene YAML válido y Docker puede leerlo.

5. Autenticar una cuenta de pago

Para una cuenta de ChatGPT con acceso a Codex:

docker compose exec cli-proxy-api \
  /CLIProxyAPI/CLIProxyAPI --no-browser --codex-login

Para una cuenta Claude Pro o Max:

docker compose exec cli-proxy-api \
  /CLIProxyAPI/CLIProxyAPI --no-browser --claude-login

Para Antigravity:

docker compose exec cli-proxy-api \
  /CLIProxyAPI/CLIProxyAPI --no-browser --antigravity-login

El comando imprime una URL. La abro en un navegador, inicio sesión directamente con el proveedor, apruebo la petición OAuth y espero a que termine el callback. --no-browser es importante dentro de Docker porque el contenedor no puede abrir por sí mismo el navegador de mi escritorio. La guía Docker Compose del proyecto usa el mismo patrón de login.

Después de un login correcto aparece un archivo de credenciales dentro de ./auths. No abro, copio ni versiono su contenido. Para añadir otra cuenta compatible repito el comando de login correspondiente; CLIProxyAPI admite enrutamiento multicuenta, pero empiezo con 1 cuenta para que sea sencillo entender el comportamiento de la cuota.

6. Descubrir los modelos que exponen realmente mis cuentas

curl --fail --silent --show-error \
  http://127.0.0.1:8317/v1/models \
  -H "Authorization: Bearer sustituye-esto-por-una-clave-local-larga-y-aleatoria"

Esta respuesta es más fiable que el nombre de un modelo copiado de un tutorial antiguo. Los proveedores añaden, renombran, restringen y retiran modelos. Elijo un id exacto devuelto por mi propio proxy.

7. Enviar una petición de prueba pequeña

Sustituyo ID_DE_MODELO_DE_V1_MODELS por 1 de esos IDs:

curl --fail --silent --show-error \
  http://127.0.0.1:8317/v1/chat/completions \
  -H "Authorization: Bearer sustituye-esto-por-una-clave-local-larga-y-aleatoria" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ID_DE_MODELO_DE_V1_MODELS",
    "messages": [
      {"role": "user", "content": "Devuelve únicamente la palabra listo."}
    ]
  }'

Mantengo la primera petición muy pequeña. Verifica autenticación, enrutamiento, traducción de protocolo y disponibilidad del modelo sin gastar una parte relevante de la cuota. Si un modelo no acepta el formato Chat Completions, uso el protocolo compatible documentado para ese modelo o configuro un cliente que admita la interfaz Responses o Anthropic.

8. Conectar un cliente real

Para una herramienta compatible con OpenAI, los valores suelen ser:

Base URL: http://127.0.0.1:8317/v1
API key:  sustituye-esto-por-una-clave-local-larga-y-aleatoria
Model:    un ID exacto devuelto por /v1/models

Por ejemplo, la guía de OpenCode apunta su proveedor OpenAI a esa URL base. CLIProxyAPI también documenta configuraciones específicas para Codex y Claude Code. Prefiero un perfil de cliente independiente llamado cliproxyapi para no cambiar por accidente a una API normal de desarrollador.

9. Operar y detener el servicio

docker compose logs -f cli-proxy-api
docker compose pull
docker compose up -d
docker compose down

down elimina el contenedor y la red, pero conserva config.yaml y auths/ porque están montados desde el host. Borrar auths/ es diferente: elimina las credenciales OAuth guardadas localmente y obliga a iniciar sesión de nuevo.

Cómo comparo modelos sin malgastar la cuota

Uso un conjunto de pruebas pequeño y fijo en lugar de conversaciones improvisadas. Cada modelo recibe el mismo prompt, contexto, definiciones de herramientas y restricciones de salida. Registro corrección, latencia, fiabilidad de llamadas a herramientas y si la respuesta respetó el formato solicitado. También ejecuto la prueba en una conversación nueva, porque una sesión larga de un agente puede hacer injusta la comparación y consumir bastante más cuota.

El enfoque basado en suscripción encaja bien para:

• Probar un modelo antes de elegirlo como opción predeterminada de un agente.
• Comprobar si 2 modelos resuelven de manera distinta la misma tarea de un repositorio.
• Probar compatibilidad de protocolo, streaming o llamadas a herramientas.
• Ejecutar experimentos personales ocasionales con un coste de suscripción predecible.

No encaja bien con tráfico de producción, servicios públicos, pruebas de carga ni situaciones que necesiten disponibilidad contractual y capacidad estable por petición. En esos casos uso la API de desarrollo compatible del proveedor y presupuesto su coste por token de la manera habitual.

Lista de comprobación para resolver problemas

Si /v1/models devuelve 401, compruebo que el bearer token coincida con api-keys en config.yaml; no es el token OAuth del proveedor. Si no devuelve modelos útiles, repito el login OAuth correspondiente y reviso los logs del contenedor. Si falla el callback del navegador, compruebo que el puerto correcto esté publicado y que otro proceso local no lo esté utilizando.

Si las peticiones llegan al proxy pero el proveedor las rechaza, pruebo 1 ID exacto devuelto por /v1/models, actualizo la imagen del contenedor y repito la prueba con la petición más pequeña posible. También reviso el panel del plan del proveedor, porque iniciar sesión mediante OAuth correctamente no garantiza que quede cuota disponible.

Por último, mantengo el servicio en local. Si realmente necesito acceso remoto, lo coloco detrás de TLS, autenticación fuerte, un firewall y una red privada en vez de cambiar la vinculación del puerto a 0.0.0.0 y confiar en que la clave de API local sea suficiente.

CLIProxyAPI es útil porque separa el cliente del login del proveedor. Puedo evaluar los modelos ya incluidos en suscripciones compatibles mediante 1 interfaz local consistente, entender sus límites reales y pasar a APIs de pago por uso únicamente cuando el experimento se convierta en una carga de producción.

Gracias por leerme, Hack the Planet!