Ejecuta Goose sobre un endpoint personalizado compatible con OpenAI.

Respuesta rápida: mantén el proveedor openai, anula el host.

Goose incluye una ruta documentada de endpoint personalizado: mantén GOOSE_PROVIDER en openai y anula a dónde apunta ese proveedor. OPENAI_HOST reemplaza el host por defecto api.openai.com, OPENAI_API_KEY autentica, y GOOSE_MODEL elige el modelo por id exacto. La ruta de la petición es independiente: OPENAI_BASE_PATH por defecto es v1/chat/completions y normalmente no necesita cambios. Presta atención a la forma con cuidado, porque es la inversa de la mayoría de las herramientas de esta clase: OPENAI_HOST toma el host desnudo, https://api.apisrouter.com, sin el sufijo /v1. La parte /v1/chat/completions vive en OPENAI_BASE_PATH. Añadir /v1 al host duplica la ruta y produce 404 que parecen un gateway roto.

export GOOSE_PROVIDER=openai
export OPENAI_HOST=https://api.apisrouter.com   # bare host, no /v1
export OPENAI_API_KEY=sk-APIsRouter-...
export GOOSE_MODEL=claude-sonnet-4-6

goose session

Cómo habla Goose con su proveedor.

Goose (block en GitHub, unas 51K estrellas) es un agente de ingeniería autónomo de Block que planifica tareas, edita archivos, ejecuta comandos de shell e impulsa extensiones basadas en MCP. Todo eso descansa sobre una sola conversación de modelo: cada paso del bucle es una petición a /v1/chat/completions con definiciones de herramientas adjuntas, así que la configuración del proveedor decide dónde corre todo el agente. La configuración está en capas. La ruta interactiva es goose configure, que para el proveedor openai pide la clave de API y un host personalizado opcional, y luego escribe ajustes no secretos como GOOSE_PROVIDER y GOOSE_MODEL en ~/.config/goose/config.yaml; la app de escritorio expone los mismos ajustes de proveedor por su interfaz. Los secretos se gestionan aparte: las claves van al llavero del sistema o vienen de variables de entorno, y una clave pegada directamente en config.yaml se ignora en vez de leerse. Las variables de entorno anulan el archivo, que es lo que hace que la ruta de entorno de arriba funcione en todas partes, desde la shell de un portátil hasta un runner de CI. Como Goose pasa GOOSE_MODEL como una cadena simple, el id puede ser cualquiera que sirva el endpoint detrás de OPENAI_HOST: un id de Claude hoy, un id de Kimi o Qwen mañana, a una variable de distancia.

La ruta declarativa: un archivo de proveedor personalizado.

Más allá de la anulación de entorno, la documentación actual de Goose también describe proveedores personalizados declarativos: un archivo JSON colocado en ~/.config/goose/custom_providers/ (directorio de configuración específico de la plataforma en Windows) que registra un proveedor con nombre junto a los integrados. El archivo declara el motor (openai para endpoints de chat-completions), qué variable de entorno guarda la clave, la URL del endpoint, y los modelos que ofrece el proveedor. Presta atención a la convención de URL aquí, porque cambia otra vez: a diferencia de OPENAI_HOST, el base_url del proveedor personalizado es la URL de petición completa incluyendo la ruta, https://api.apisrouter.com/v1/chat/completions. Cada entrada de models lleva un context_limit para que Goose sepa la ventana que puede empaquetar. El archivo declarativo es la mejor opción cuando quieres que el gateway aparezca como su propio proveedor con nombre en la lista de proveedores de Goose, con su propia variable de clave, en lugar de ocupar el slot de openai. La anulación de entorno es la mejor opción para CI y cambios rápidos. Ambas acaban en el mismo endpoint; elige una y evita apilarlas.

{
  "name": "apisrouter",
  "display_name": "APIsRouter",
  "engine": "openai",
  "api_key_env": "APISROUTER_API_KEY",
  "base_url": "https://api.apisrouter.com/v1/chat/completions",
  "models": [
    { "name": "claude-sonnet-4-6", "context_limit": 200000 },
    { "name": "claude-opus-4-7",   "context_limit": 200000 },
    { "name": "kimi-k2.7-code",    "context_limit": 200000 }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

Elegir un modelo para un agente autónomo.

El flujo de trabajo práctico es mantener fijo tu conjunto de tareas y rotar GOOSE_MODEL entre dos o tres candidatos durante unas pocas sesiones cada uno. Como cada candidato se enruta por la misma clave, la vista de uso por clave le pone precio a cada experimento sin ninguna contabilidad de tu parte.

• Goose corre tramos sin supervisión: planifica, edita, ejecuta, lee la salida, repite. La fiabilidad en las llamadas a herramientas importa más que la elocuencia bruta, por eso claude-sonnet-4-6 y claude-opus-4-7 son las opciones por defecto a las que converge la gente para el bucle principal.
• Los ids afinados para código como kimi-k2.7-code merecen probarse en sesiones intensivas en refactorización; a través de un gateway esa prueba es un cambio de GOOSE_MODEL, no una migración de proveedor.
• Las sesiones largas acumulan contexto. Un modelo con una ventana real de 200k, declarada con honestidad vía context_limit en la ruta declarativa, deja que Goose cargue más historial de sesión antes de resumir.
• Para uso guionizado o de CI, un id de nivel medio (gpt-5.4, qwen3.7-max) a menudo supera el listón para tareas bien acotadas a una fracción del gasto de vanguardia; mide sobre tus propias tareas antes de subir por defecto.

Pago por uso · por debajo del precio oficial

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Modos de fallo específicos de Goose.

/v1 añadido a OPENAI_HOST. La variable de host toma el host desnudo; la ruta vive en OPENAI_BASE_PATH, que ya por defecto es v1/chat/completions. https://api.apisrouter.com/v1 como host produce peticiones /v1/v1/... y 404. Este es el error más común, precisamente porque cualquier otra herramienta quiere el sufijo /v1. La convención de URL completa en los archivos de proveedor personalizado. El base_url declarativo es la URL de petición completa incluyendo /v1/chat/completions, la convención opuesta a OPENAI_HOST. Copiar un host desnudo en un archivo de proveedor personalizado lo rompe con la misma seguridad que copiar una URL completa en OPENAI_HOST. Las claves en config.yaml no autentican. Goose lee secretos del llavero o del entorno, e ignora los valores de clave puestos en config.yaml. Si un 401 persiste tras editar el archivo, esa es la razón; exporta la variable o vuelve a ejecutar goose configure e introduce la clave cuando se te pida. Las sesiones de escritorio no ven las exportaciones de shell. La app de escritorio no hereda nada del perfil de tu terminal. Configura el proveedor a través de la interfaz de ajustes de escritorio, o lánzala desde una shell que tenga las variables configuradas. Fuentes de configuración apiladas. Un OPENAI_HOST exportado antiguo puede anular lo que acabas de configurar en config.yaml, porque el entorno gana al archivo. Cuando el enrutamiento se vea raro, imprime las variables relevantes en la misma shell que lanza Goose antes de culpar a ninguna de las dos capas.

Quién enruta Goose a través de un gateway.

• Ingenieros que ejecutan Goose como herramienta diaria y quieren Claude, GPT, Kimi y Qwen alcanzables detrás de una clave en vez de un conjunto de credenciales por proveedor.
• Equipos que meten Goose en CI o en tareas programadas. La ruta solo-entorno significa que el runner necesita exactamente dos variables de enrutamiento y un secreto, fácil de inyectar y fácil de rotar.
• Desarrolladores que comparan modelos de agente en tareas reales. Cada candidato es un valor de GOOSE_MODEL contra el mismo endpoint, con precio automático por uso por clave.
• Equipos de plataforma que quieren el gasto de agente visible por clave y por modelo en una sola superficie de facturación, en vez de conciliar varios paneles de proveedor.
• Desarrolladores sin acceso a la facturación de un proveedor concreto. El acceso basado en recargas sin requisito de tarjeta elimina la dependencia de registrarse en cada proveedor.

Verifica el endpoint y depura la primera sesión.

Confirma que el gateway sirve el id de GOOSE_MODEL antes de iniciar una sesión; el listado /v1/models es la grafía autorizada, sufijos de versión incluidos. Los fallos de primera sesión son consistentes. Un 404 significa que el host y la ruta se combinaron mal, casi siempre /v1 dentro de OPENAI_HOST. Un 401 significa que la clave no está donde Goose la busca: no exportada en la shell que lo lanzó, no en el llavero, o metida sin efecto dentro de config.yaml. Un error de modelo no encontrado desde el gateway es una errata de id en GOOSE_MODEL. Si la sesión arranca pero las llamadas a herramientas se comportan raro, comprueba que estás en un modelo que de verdad admite uso de herramientas; los ids de la tabla de arriba lo hacen todos. Una vez que el bucle corre, la consola de APIsRouter muestra el modelo, el recuento de tokens y el gasto por petición. Un agente autónomo es la carga de trabajo donde esto más importa: las sesiones son largas, los turnos de llamada a herramientas son muchos, y la vista de uso es cómo ves cuánto costó realmente una tarde de Goose.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

Preguntas frecuentes