Catálogo de proveedores

Cada familia de proveedores de modelos que se incluye con ZeroClaw. Para cada una: estructura de configuración, notas sobre autenticación y comportamiento de los endpoints, y la clave de slot que se debe usar en [providers.models.<type>.<alias>].

Consulta Configuration para los campos universales (api_key, uri, model, …) y el orden de resolución.

Los ejemplos a continuación usan home como el alias para subrayar que la mitad del alias la elige el operador; elige el nombre que mejor se ajuste (work, personal, cn, prod, …). Haz referencia a él desde un agente mediante model_provider = "<type>.<alias>".

Nativo

Anthropic / Claude: slot `anthropic`

Admite claves de API de Console y tokens generados por claude setup-token para Claude Max. Ambas formas de credenciales viven en el campo api_key del slot canónico anthropic; Quickstart las expone como opciones api_key y setup_token. Streaming, llamadas a herramientas, visión y razonamiento, todo compatible. Los endpoints personalizados (proxies compatibles con Anthropic, p. ej. la API de Anthropic de Z.AI) también van en este slot: establece uri para sobrescribir.

OpenAI: slot `openai`

GPT-4o, GPT-5, modelos de razonamiento de la serie o. Cuando el razonamiento se transmite en streaming, se transporta en el campo opcional reasoning de un StreamChunk envuelto por TextDelta; consulte Streaming.

OpenAI Codex: slot `openai` con `requires_openai_auth = true`

La autenticación de la suscripción de OpenAI Codex reside en el slot openai. Establece wire_api = "responses" para enrutar a través de POST /v1/responses y requires_openai_auth = true para usar el inicio de sesión de la suscripción de Codex (desde el propio ~/.codex/auth.json del Codex CLI) en lugar de un campo api_key en la entrada. La ruta de suscripción no lee OPENAI_API_KEY; esa variable aplica únicamente al modo de clave API openai medido por uso. Consulta Provider Configuration → OAuth and subscription auth para conocer el modelo de credenciales.

Ollama: slot `ollama`

Inferencia local mediante el /api/chat nativo de Ollama. Salida estructurada basada en esquemas mediante format. Sin clave de API.

Bedrock: ranura `bedrock`

Gemini: ranura `gemini`

La API de Gemini de Google. Admite visión y búsqueda fundamentada preejecutada (consulta Streaming para eventos PreExecutedToolCall).

Gemini CLI: slot `gemini_cli`

Ejecuta el CLI gemini; usa la autenticación existente del CLI.

Grok Build CLI: ranura `grok_cli`

Ejecuta el Grok Build CLI mediante la superficie ACP documentada grok agent stdio y usa la caché de inicio de sesión del CLI de forma predeterminada. Ejecuta grok login o usa el puente explícito de clave de API que se muestra a continuación. No se usa el alias tipado api_key, y XAI_API_KEY del entorno no se hereda a menos que el alias opte por ello, por lo que Grok CLI sigue siendo el responsable de la autenticación. Este es el único transporte: initialize → authenticate → session/new → session/prompt mediante JSON-RPC delimitado por saltos de línea. Tanto las solicitudes pequeñas como las grandes se envían por stdin y nunca aparecen en argv ni en un archivo de solicitudes.

La integración de ACP documentada y el perfil de argumentos predeterminado se validan con Grok Build CLI 0.2.118 (sondeos de anuncio/en vivo de ACP), con 0.2.111 como línea base anterior. Trata las actualizaciones de la CLI externa como un cambio de compatibilidad y vuelve a validar grok agent stdio antes de implementarlas.

Entrada de visión / imágenes de ACP (comportamiento actual de Grok Build)

Grok Build CLI (comprobado hasta 0.2.118) sigue anunciando promptCapabilities.image = false durante initialize de ACP. Eso no es una anulación mediante una variable de entorno por ninguna de las dos partes: ZeroClaw nunca reescribe el anuncio de Grok. El único control de ZeroClaw es el campo de configuración vision, compartido por alias.

Capa	Comportamiento en `0.2.118`
Anunciar ACP	`promptCapabilities.image = false`
Predeterminado `grok_cli`	`vision` no establecido → ZeroClaw trata el alias como no compatible con visión; los marcadores de imagen permanecen como texto
`vision = true`	ZeroClaw indica compatibilidad con visión en el alias y envía bloques ACP `{type: image, data, mimeType}` (no cambia el anuncio de capacidades de Grok)
Reconocimiento de modelos	Sondeo en vivo: los bloques de imagen se aceptan mediante `session/prompt` (sin error de protocolo), pero el agente respondió como si no se hubiera recibido ninguna imagen

[providers.models.grok_cli.default]
model = "grok-4.5"
working_directory = "/srv/zeroclaw/grok-workspace"
# Solo experimento opcional: envía bloques de imagen ACP a pesar de anunciar image=false.
# No hace que Grok Build 0.2.118 vea o describa la imagen de forma fiable.
# vision = true

Deja vision sin establecer para los alias de producción de grok_cli. No enrutes los adjuntos de canal que requieran una comprensión real de imágenes a grok_cli hasta que una CLI desplegada anuncie image = true y una prueba de humo en vivo muestre que el modelo usa el contenido de la imagen. Cuando eso se cumpla, elimina cualquier activación temporal de vision = true y vuelve a evaluar si ZeroClaw debería seguir el indicador anunciado en lugar de una anulación local (GrokCliModelProvider::acp_prompt_content).

Ubuntu 24.04: mantener el entorno aislado de Grok cuando `bwrap` necesita espacios de nombres de usuario

Al implementar Grok Build 0.2.112 o una versión posterior, compruebe la inicialización de ACP en el host de destino. En hosts Ubuntu 24.04 con kernel.apparmor_restrict_unprivileged_userns=1, Grok puede terminar antes de la inicialización de ACP con bwrap: setting up uid map: Permission denied. Esto es un error de configuración del sandbox del host, no un error de ACP, stdout ni autenticación.

Mantén --sandbox strict como valor predeterminado de ZeroClaw (o un perfil workspace explícito) y concede únicamente al ejecutable real de Grok permiso para crear un espacio de nombres de usuario. Este cambio debe realizarlo el administrador del host; conserva la restricción global de los espacios de nombres de usuario y no desactiva el entorno aislado de Grok.

readlink -f "$(command -v grok)"

Cree /etc/apparmor.d/grok-build-userns, reemplazando el marcador de posición por esa ruta absoluta:

abi <abi/4.0>,

include <tunables/global>

profile grok-build-userns /absolute/path/to/grok flags=(unconfined) {
  userns,
}

Luego, cárguelo y verifique que el perfil esté activo:

sudo apparmor_parser -r /etc/apparmor.d/grok-build-userns
sudo aa-status | grep grok-build-userns

flags=(unconfined) es el mecanismo de excepciones de AppArmor por ejecutable de Ubuntu: concede userns al binario de Grok indicado, pero no le añade reglas de archivos de AppArmor. El sandbox solicitado por el propio Grok sigue habilitado, y la restricción de espacios de nombres de usuario para todo el host también sigue habilitada. Usa un perfil específico de la organización completamente confinado si Grok también necesita restricciones de archivos de AppArmor. Dado que las actualizaciones automáticas pueden cambiar la ruta del ejecutable descargado, resuelve la ruta y vuelve a cargar este perfil después de cada actualización de Grok.

No uses --sandbox off simplemente para evitar este error: desactiva el entorno aislado de Grok. No desactives kernel.apparmor_restrict_unprivileged_userns en todo el sistema. xAI documenta Landlock para el aislamiento normal de Linux y documenta bubblewrap solo para perfiles personalizados de denegación de lectura; si esto ocurre sin una lista deny personalizada y no vacía, informa a xAI de la versión, el error exacto, el perfil del entorno aislado y los diagnósticos no confidenciales del host/AppArmor.

max_acp_stdout_bytes limita toda la salida estándar leída del proceso secundario de Grok ACP durante una solicitud, incluidos los marcos del protocolo y las actualizaciones de herramientas nativas. Su valor predeterminado es de 4 MiB; establécelo por alias cuando una carga de trabajo revisada y habilitada para herramientas necesite un presupuesto acotado mayor.

[providers.models.grok_cli.default]
model = "grok-4.5"
working_directory = "/srv/zeroclaw/grok-workspace"
env_passthrough = ["XAI_API_KEY"]
# Opcional: 4 MiB de forma predeterminada; el rango aceptado es de 1-64 MiB.
max_acp_stdout_bytes = 8388608

Exporte XAI_API_KEY al entorno del demonio antes de iniciar ZeroClaw. El cliente ACP selecciona xai.api_key solo cuando ese nombre aparece en la lista de env_passthrough y hay un valor no vacío en el entorno del proceso en el momento de crear el proceso hijo (no se captura en el manejador del proveedor de larga duración). De lo contrario, recurre a la caché de inicio de sesión de la CLI. El alias tipado api_key sigue rechazándose: se trata de un puente intencional entre el entorno del proceso y no de un segundo campo de secreto de Config. Los valores no se escriben en TOML del proveedor; un futuro puente tipado de Config podría cargar el mismo nombre en el momento de la configuración sin cambiar la interfaz del operador.

Se requiere un working_directory absoluto existente. Se convierte a una forma canónica y se utiliza tanto para el directorio de trabajo del proceso secundario como para el límite de la sesión de ACP, por lo que el proveedor nunca recurre al directorio de trabajo del demonio. El binary_path opcional selecciona un binario que no está en PATH. El alias timeout_secs establece el límite para las lecturas y escrituras del protocolo (600 s de forma predeterminada).

El entorno hijo se vacía antes de la creación. Las variables de tiempo de ejecución del proceso, de configuración regional, de proxy y de CA incluidas en la lista de permitidas integrada siguen disponibles; todos los demás nombres se bloquean, a menos que el alias de ese proveedor los incluya en env_passthrough. Este campo se utiliza para el puente de autenticación explícito de XAI_API_KEY y para las variables de entorno necesarias para las herramientas de Grok habilitadas explícitamente, como las credenciales de CLI en la nube. Los valores se leen del entorno de proceso de ZeroClaw en el momento de la creación y no se almacenan en la configuración del proveedor. La lista predeterminada está vacía. Manténgala limitada, porque cada secreto incluido queda expuesto a Grok y a cualquier herramienta habilitada para ese alias. Se rechazan otros nombres XAI_* pertenecientes al proveedor y todos los nombres GROK_*. La configuración de usuario y de proyecto descubierta por Grok, junto con extra_args del alias, controla la política de herramientas de Grok.

El argv predeterminado añade --no-auto-update, --no-plan, --sandbox strict, --permission-mode dontAsk y --tools "". De forma predeterminada, el cliente ACP rechaza las solicitudes de permisos. Cuando la solicitud proporciona una opción reject_once, el cliente la selecciona en lugar de cancelar el turno completo del agente; de lo contrario, cancela la solicitud. La herramienta solicitada sigue rechazándose por defecto, mientras que Grok puede procesar el rechazo y producir una respuesta final o reintentar con una operación permitida por su política.

Un alias configurado explícitamente con --always-approve, --dangerously-skip-permissions, --yolo o --permission-mode=bypassPermissions cambia la política de respuesta de ACP en modo sin interfaz: el cliente selecciona la opción allow_once de la solicitud. Nunca sustituye allow_always y cancela la operación cuando falta la opción allow_once solicitada. Esta aprobación solo se aplica a la solicitud de permisos actual; las reglas de permisos de Grok y el sandbox activo del sistema operativo aún pueden rechazar o restringir la operación.

[providers.models.grok_cli.ops]
working_directory = "/path/to/agents/ops/workspace"
extra_args = [
  "--tools=run_terminal_cmd",
  "--permission-mode=bypassPermissions",
]

Trata estas banderas de omisión como una autorización para que Grok ejecute todas las herramientas compatibles con solicitudes de ese alias sin una ronda de aprobación humana. Otros modos de permisos, incluido acceptEdits, no habilitan la aprobación automática de ACP. Grok evalúa las reglas de CLI --allow / --deny y la configuración de permisos de usuario/proyecto detectada antes de preguntar al cliente de ACP. Esas superficies son políticas de operador de confianza: una regla de autorización coincidente puede preautorizar una herramienta, de modo que el cliente de ACP nunca vea una solicitud de permisos, y los servidores MCP, complementos o hooks del proyecto pueden añadir capacidades. Usa un working_directory dedicado y revisado para los agentes de canal.

Cuando una regla allow no autoriza previamente la herramienta, Grok sigue enviando session/request_permission y la política predeterminada de rechazo único de ZeroClaw hace que la herramienta falle en modo cerrado. En la práctica, esto importa para las herramientas de shell/execute con el --sandbox strict predeterminado: una regla de CLI --allow=Bash(...) aún puede escalar al host de ACP en la versión actual de Grok Build, por lo que un alias de shell con herramientas habilitadas debería establecer un indicador explícito de bypass (--always-approve / --permission-mode=bypassPermissions) o combinar las reglas allow con un perfil de sandbox que Grok autorice previamente sin aprobación del host (por ejemplo, --sandbox=workspace). Las concesiones de herramientas de solo lectura, como --tools=Read,Grep con un --allow correspondiente, siguen siendo la opción de activación explícita más limitada.

Los operadores también pueden conceder acceso a herramientas o relajar la política de sandbox/permisos con el alias extra_args; ambas interfaces son habilitaciones explícitas para ampliar el límite de los subprocesos. Las opciones de transporte, prompt, modelo, sesión, cwd y actualización siguen siendo propiedad del proveedor y se rechazan en extra_args. Los argumentos posicionales y cortos también se rechazan. Las opciones conocidas que aceptan valores admiten ["--flag", "value"] o --flag=value; las formas de opción desconocidas requieren el formato en línea para que no puedan consumir el comando ACP final.

Grok puede emitir progreso como un agent_message_chunk antes de un plan, una llamada a una herramienta o una solicitud de permiso. El proveedor descarta el segmento de mensaje anterior en esos límites de ACP y devuelve solo el segmento de respuesta más reciente, por lo que la narración de planificación o recopilación de herramientas no se entrega como respuesta del canal. El --no-plan explícito también mantiene el alias de canal de una sola ejecución predeterminado fuera del modo de planificación de Grok; la configuración de herramientas/MCP sigue siendo una capacidad controlada por el operador.

Las tramas de stdout de ACP, el stdout agregado, el texto del asistente y el procesamiento de stderr tienen límites mientras el proceso hijo está en ejecución. Se drena stderr, pero su contenido nunca se almacena, registra ni devuelve. Los errores públicos del proveedor se mantienen estables y no incluyen texto libre del protocolo controlado por el proceso hijo. Después de cada solicitud de una sola ejecución (éxito, tiempo de espera agotado, cancelación o error de protocolo), ZeroClaw termina el grupo de procesos del hijo en Unix o el Job Object en Windows y recoge el proceso hijo directo. Esto cubre a los descendientes habituales; un proceso que crea una nueva sesión o un nuevo grupo de procesos puede escapar a la terminación del grupo en Unix. La cobertura de Job Object en Windows se verifica mediante compilación en CI y no se ejecuta por completo en todos los hosts Linux de desarrollo.

Patrón recomendado: chatbot del canal predeterminado

Usa un alias de proveedor dedicado para el agente de mensajería (por ejemplo, agents.default). El alias predeterminado no concede herramientas integradas de Grok. Grok sigue cargando su configuración normal de usuario y proyecto, por lo que debes usar un espacio de trabajo dedicado cuyas reglas de permisos, servidores MCP, plugins y hooks se hayan revisado para el límite de confianza del canal. Usa un alias y un espacio de trabajo independientes para un agente de programación/operaciones aprobado por el operador.

Comprobación previa de la intención de respuesta (clasificador): ZeroClaw ejecuta una breve clasificación de REPLY / NO_REPLY[*] antes del ciclo completo del agente. Prefiere una API estable de completado de chat para esa comprobación previa (por ejemplo, el slot xai de HTTP/OAuth, o cualquier otro alias de modelo que no sea CLI), y reserva grok_cli únicamente para model_provider (la respuesta completa). Los backends de agentes CLI suelen emitir prosa de planificación en lugar de un único token centinela; esa prosa puede entregarse como mensaje del canal (“guardando silencio” / “sin respuesta en Slack”). Un classifier_provider vacío reutiliza model_provider: está bien para modelos de API, pero no para bots de canal CLI. Los canales ACP omiten por completo el clasificador.

# Respuestas completas: ACP, sandbox estricto, sin herramientas integradas, configuración de Grok revisada
[providers.models.grok_cli.default]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/default/workspace"

# Comprobación previa REPLY / NO_REPLY - API (formato estable). Reutiliza un alias HTTP
# xAI existente si ya tienes uno; no apuntes esto a grok_cli.
[providers.models.xai.default]
model = "grok-4.5"
# uri / auth como para el proveedor xAI normal (sesión de OAuth o api_key)

# Agentes de Ops / programación: política explícita y activación voluntaria de herramientas
[providers.models.grok_cli.ops]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/ops/workspace"
env_passthrough = ["AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY"]
# Herramientas de solo lectura: una coincidencia con --allow puede autorizar previamente sin la aprobación de ACP.
extra_args = ["--tools=Read,Grep", "--allow=Read", "--allow=Grep"]

# Alias ops con capacidad de Shell: puedes omitir la aprobación de ACP o combinar allow con un
# perfil de sandbox que Grok autoriza previamente (workspace es la opción habitual).
[providers.models.grok_cli.ops_shell]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/ops/workspace"
extra_args = [
  "--tools=run_terminal_cmd",
  "--allow=Bash(printf *)",
  "--sandbox=workspace",
]

[agents.default]
model_provider = "grok_cli.default"
classifier_provider = "xai.default"
channels = ["slack.default"]   # ejemplo

[agents.dependabot]
model_provider = "grok_cli.ops"

Capa	Dónde	Propósito
Comprobación previa de respuesta	`classifier_provider` → alias de API (p. ej., `xai.default`)	Solo REPLY / `NO_REPLY[*]`; evita que la CLI considere el texto de razonamiento como el cuerpo del mensaje
Respuesta completa	`model_provider` → `grok_cli.default`	Grok Build ACP; solicitar solo mediante stdin
entorno aislado del sistema operativo	Predeterminado `--sandbox strict` (o anulación de `extra_args`)	Lee CWD y las rutas del sistema; escribe en CWD, `~/.grok` y tmp; la red de los procesos secundarios está bloqueada en Linux. Las funciones integradas no son un límite permanente para las credenciales; usa `deny` personalizado para los secretos
Permisos de la aplicación	Conjunto de herramientas integradas vacío + ACP predeterminado con cierre ante fallos	Los indicadores de omisión explícitos seleccionan `allow_once`; las reglas de Grok detectadas también pueden preautorizar las herramientas configuradas
Entrega de canales	ZeroClaw `thread_replies` / configuración del canal	Ruta única de respuesta dentro del hilo
Puerta opcional	Slack `mention_only` + `strict_mention_in_thread`	Descarta el tráfico de grupos/hilos no mencionados antes del agente (consulta Slack); independientemente del clasificador

Mantén los alias orientados al canal en sus valores predeterminados y asígnales espacios de trabajo dedicados y revisados. Las reglas de permisos, los servidores de MCP, los plugins y los hooks descubiertos por Grok, junto con las opciones de permisos, sandbox y herramientas de extra_args, constituyen una política del operador de confianza y pueden ampliar el límite del subproceso.

Zona de pruebas del SO de Grok CLI (cómo usarla desde ZeroClaw)

Este es el entorno aislado de procesos de Grok Build (Landlock / Seatbelt / seccomp en el subproceso grok). No es el entorno aislado de herramientas de ZeroClaw en [risk_profiles.*.sandbox_*]: ese entorno envuelve las herramientas de ZeroClaw después de las llamadas a herramientas nativas. Si un operador opta por usar un alias de proveedor con las herramientas de Grok, el --sandbox de Grok es el aislamiento efectivo para ese trabajo. Consulta también Aislamiento para obtener información sobre el entorno aislado basado en perfiles de riesgo de ZeroClaw.

ZeroClaw siempre proporciona una opción de sandbox explícita. El valor predeterminado es strict. Establece --sandbox=<profile> en extra_args del alias del proveedor para elegir un perfil diferente; la configuración ambiental de Grok o GROK_SANDBOX no puede relajar silenciosamente el valor predeterminado propio del proveedor.

El proyecto .grok/config.toml puede contener MCP / complementos / [permission]. Grok carga ese archivo como una política de operador de confianza; las reglas de autorización coincidentes pueden autorizar herramientas sin una solicitud de permisos de ACP. Por sí solo, no selecciona el perfil de sandbox activo. Los nombres de perfil y los cuerpos de perfil personalizados pueden residir en el proyecto <workspace>/.grok/sandbox.toml; pasa --sandbox=<name> mediante extra_args para activar ese perfil.

Perfiles integrados (de la documentación del entorno aislado de Grok):

Perfil	Lectura de FS	Escritura en FS	Red de procesos hijos (Linux)	Uso típico
`off` (predeterminado)	sin restricciones	sin restricciones	sin restricciones	Acceso total
`workspace`	en todas partes	CWD + `~/.grok` + tmp	permitido	Programación cotidiana
`read-only`	en todas partes	`~/.grok` + solo tmp	bloqueado	Revisa cuándo se permiten las lecturas amplias
`strict`	CWD + rutas del sistema	CWD + `~/.grok` + tmp	bloqueado	Chatbot del canal predeterminado (recomendado)
`devbox`	en todas partes	la mayor parte del árbol	permitido	Máquinas virtuales desechables

El bloqueo de red de los procesos secundarios del shell solo se aplica en Linux; las herramientas de Grok en proceso (LLM, búsqueda web integrada) todavía necesitan acceso a la red. Se recomienda strict para los bots de mensajería, para limitar la superficie predeterminada de escritura en el sistema de archivos al espacio de trabajo del agente y las rutas de ejecución de Grok. Los perfiles integrados no constituyen un límite permanente para las credenciales: la documentación del sandbox de xAI advierte que las rutas como ~/.ssh no tienen garantizada la protección mediante los perfiles integrados, y recomienda un perfil personalizado con una lista de deny impuesta por el kernel para los secretos. Use read-only solo cuando el agente deba leer fuera del espacio de trabajo sin escribir archivos del proyecto.

Ejemplo de perfil personalizado (defínalo en el espacio de trabajo y selecciónelo desde ZeroClaw):

# <agent-workspace>/.grok/sandbox.toml
[profiles.channel-bot]
extends = "strict"
# Rutas de denegación opcionales del kernel (requiere bubblewrap en Linux cuando no está vacío):
# deny = ["**/.env", "**/*.pem"]

# ZeroClaw config.toml
[providers.models.grok_cli.default]
working_directory = "/path/to/agents/default/workspace"
extra_args = ["--sandbox=channel-bot"]

Entorno aislado por agente: usa alias de proveedor independientes con diferentes extra_args explícitos y directorios de trabajo dedicados. Mantén los alias de canal con el valor predeterminado estricto/sin herramientas integradas, revisa la configuración de Grok detectada para cada espacio de trabajo y asigna a cada agente el alias model_provider correspondiente.

Azure OpenAI: ranura `azure`

resource, deployment y api_version residen en esta configuración tipada; no se leen desde variables de entorno.

Copilot: ranura `copilot`

Utiliza una suscripción de GitHub Copilot para la inferencia del agente. La autenticación usa un token OAuth de Copilot obtenido de GitHub.

Telnyx: slot `telnyx`

Punto final de IA orientado a la voz. Se combina con el canal clawdtalk para llamadas SIP en tiempo real.

KiloCLI: slot `kilocli`

Inferencia local a través de KiloCLI.

Kilo AI Gateway: slot `kilo`

[providers.models.kilo.home]
model   = "anthropic/claude-sonnet-4-6"
api_key = "..."
# endpoint = "gateway"  # predeterminado → https://api.kilo.ai/api/gateway

API en la nube a través de Kilo AI Gateway. Autenticación con token Bearer y múltiples niveles de modelos (free, balanced, pro). El endpoint /models es público (PUBLIC_MODEL_LISTING), por lo que el listado de modelos funciona sin credencial. Como se consulta en vivo, es la fuente que aporta los precios al editor de tarifas de costos. El catálogo compartido de models.dev (clave kilo) es solo una alternativa de respaldo para cuando el endpoint en vivo no está disponible, y no incluye precios.

Migración de nombres: kilo ahora se refiere a este proveedor de gateway. El proveedor de subproceso KiloCLI conserva su espacio kilocli (sinónimo kilo-cli). Si anteriormente configuraste el proveedor de CLI con el atajo kilo, cambia a kilocli.

ZeroRouter: ranura `zerorouter`

[providers.models.zerorouter.gateway]
model   = "anthropic/claude-sonnet-5"
api_key = "..."   # una clave de ZeroRouter (prefijo `zcr_`); o inyectar desde el entorno
# uri = "http://localhost:8080/v1"  # un enrutador autohospedado o local; omitir para usar el valor predeterminado alojado

Puerta de enlace LLM compatible con OpenAI; autenticación mediante token Bearer. ZeroRouter se encuentra actualmente en fase beta. La ranura usa de forma predeterminada la implementación pública alojada en https://zerorouter.ai/v1, por lo que la detección de modelos funciona sin ninguna configuración. ZeroRouter también puede autoalojarse (AGPL); para acceder a tu propio router, de forma local en http://localhost:8080/v1 o en cualquier otro lugar, establece uri explícitamente. Una clave generada en un router no autentica en otro, por lo que api_key debe proceder de la implementación a la que apunta uri.

Más allá del protocolo chat-completions que admite este slot, ZeroRouter también sirve la API de Responses de OpenAI para solicitudes entrantes (POST /v1/responses), por lo que los clientes del protocolo Responses, como un model_provider de Codex CLI con wire_api = "responses", pueden apuntar directamente al mismo despliegue y clave.

El endpoint /v1/models es público (PUBLIC_MODEL_LISTING), por lo que el listado de modelos y sus precios de prompts/completions se obtienen en tiempo real del propio enrutador sin necesidad de una credencial; como se consulta en tiempo real, es la fuente que proporciona los precios al editor de tarifas de costes (esta familia no tiene ningún mecanismo de respaldo de models.dev ni de OpenRouter). La inferencia sí requiere una clave: establece api_key directamente o inyéctala desde el entorno del mismo modo que cualquier otra clave de proveedor (consulta Configuración para conocer el orden de resolución de api_key).

Sin inicio de sesión integrado. Este preajuste configura el proveedor únicamente a través de la ruta estándar y tipada de api_key; no añade un inicio de sesión mediante flujo de dispositivo, OAuth ni almacenamiento de credenciales específico del proveedor. Establece api_key (o su inyección mediante variables de entorno) para ejecutar inferencias.

Todas las ranuras

Cada ranura canónica, su endpoint predeterminado, si se ejecuta localmente y el conjunto completo de campos de configuración, generado a partir del registro de proveedores y del esquema de configuración. Haz clic en una ranura para expandir sus campos; haz clic en un campo para ver cómo configurarlo. Las entradas fijas muestran los valores predeterminados canónicos. operator required significa que el alias necesita datos del endpoint, como un recurso y una implementación de Azure o un custom uri. Los endpoints dynamic / resolved at runtime pueden depender de las credenciales, la región, el descubrimiento o el estado en tiempo de ejecución, y no requieren necesariamente uri. Los proveedores basados en CLI usan su comando local.

Campos compartidos

Cada slot de proveedor acepta estos campos. Los extras específicos de cada slot se enumeran por proveedor a continuación.

api_key 🔑 secret · default —

Token API secreto para este model_provider. Obténgalo desde el panel de control del model_provider (plataforma de OpenAI, consola de Anthropic, página de claves de OpenRouter, etc.). Se almacena mediante el keyring del sistema operativo cuando es posible; nunca lo incluya directamente en config.toml.

Colócalo sobre cualquier superficie:

Keyboard shortcuts

ZeroClaw Docs