Coste y configuración de la API de ZeroClaw: entorno de ejecución gratuito, proveedores personalizados y coste real de tokens

El runtime de ZeroClaw cuesta $0: es de código abierto, tiene licencia dual MIT OR Apache-2.0 y las propias FAQ de zeroclaw.com indican que no hay suscripción ni puesto alojado; solo pagas los costes de tu propio proveedor de LLM, o nada si ejecutas un modelo local con Ollama. La documentación sobre la filosofía del proyecto es aún más directa: «No es un SaaS. No hay versión alojada, sistema de cuentas ni facturación». Por tanto, en la práctica, «precios de ZeroClaw» significa otras dos facturas: los tokens del modelo en el endpoint al que apuntes un alias y el equipo en el que se ejecuta el demonio. Ambas se comprobaron el 21 de septiembre de 2026.

Hay dos cosas que te costarán dinero o tiempo si las omites. ZeroClaw Labs no publica ningún precio mensual, por lo que la suscripción mensual de «ZeroClaw» que ya hayas visto corresponde al producto de otra persona. Y el propio registro de costes de ZeroClaw informará de cero gasto en una pasarela de terceros hasta que introduzcas manualmente las tarifas, porque el slot de proveedor custom no tiene un catálogo de precios asociado. Ambas cuestiones se explican a continuación.

Precios de ZeroClaw: cuánto cuesta el software y qué se factura realmente

La última fila es el anclaje equivocado al que puede llevar una búsqueda de «zeroclaw pricing». El README de ZeroClaw nombra github.com/zeroclaw-labs/zeroclaw como el único repositorio oficial y afirma que cualquier otro repositorio, organización, dominio o paquete que se presente como ZeroClaw no está autorizado ni afiliado. En los fragmentos de búsqueda de zeroclaw.live también circula una segunda cifra mensual por agente; ese sitio devolvió un error en lugar de una página el 21 de septiembre de 2026, por lo que no se pudo leer la cifra en la página y deliberadamente no se reproduce aquí. Por separado, trata con cuidado las cifras de marketing incluso en dominios que el propio proyecto utiliza: las páginas de destino de zeroclaw.dev, zeroclaw.org y zeroclaw.net anuncian un binario de 3.4MB, mientras que la propia página de filosofía del proyecto dice que una compilación de lanzamiento típica ocupa alrededor de 26 MiB. Es una diferencia entre la documentación y la página de destino, no una prueba de suplantación: el propio README dirige los informes de seguridad a una dirección de zeroclaw.dev. ZeroClaw frente a OpenClaw analiza detalladamente este problema de identificación.

Una nota de alcance, porque los dos hechos parecen contradictorios. «Sin facturación» es cierto para el entorno de ejecución de ZeroClaw y falso para ZeroClaw Labs como organización: la misma organización de GitHub distribuye ZeroRouter, un gateway AGPL cuya descripción del repositorio menciona la facturación prepaga mediante Stripe, accesible desde ZeroClaw a través de su propio zerorouter. Es un producto diferente en fase beta, no una suscripción de ZeroClaw, y sus precios alojados representan el estado activo del gateway, no una lista de precios publicada.

La estructura de configuración que debes escribir hoy: esquema 3, no el fragmento plano

La documentación oficial está actualizada; gran parte de la configuración de ZeroClaw que encontrarás en los resultados de búsqueda no lo está. La versión actual del esquema de configuración es 3 — CURRENT_SCHEMA_VERSION: u32 = 3 en crates/zeroclaw-config/src/migration.rs de la etiqueta de lanzamiento v0.8.5, con una cadena de migración de V1 a V2 a V3. La estructura plana que aparece en tutoriales antiguos corresponde al esquema 1. Un archivo de configuración que no contiene schema_version se trata como versión 1 y se migra en memoria al cargarse, por lo que la carga no reescribe el archivo en disco.

Ten en cuenta el nombre: «ZeroClaw V3» no es un lanzamiento. El lanzamiento más reciente es v0.8.5, publicado el 5 de septiembre de 2026 (API de GitHub, comprobada el 21 de septiembre de 2026); el esquema 3 es el formato de configuración que contiene. Los dos números no están relacionados.

Los nombres de campos del esquema 1 se tomaron de la representación de V1 utilizada para la migración en v0.8.5; las filas del esquema 2 proceden de los comentarios de documentación de la representación de V2 en master, ambas con fecha del 21 de septiembre de 2026. Esas representaciones son las estructuras como las que se interpreta un archivo antiguo durante la migración, por lo que constituyen una buena evidencia de los nombres de campos antiguos. En la última fila, dos fuentes discrepan según su fecha: la representación de V2 registra que V3 eliminó cost.prices y trasladó los precios directamente a cada proveedor de modelos, mientras que la documentación actual de seguimiento de costes describe ese campo pricing integrado por alias como heredado y señala [cost.rates.*] como la estructura prevista para el futuro que prevalece en caso de conflicto. Escribe [cost.rates.*].

En el esquema 3, cada proveedor de modelos se encuentra en [providers.models.<type>.<alias>], donde el tipo es un espacio canónico de familia —«hay un espacio por proveedor, sin sinónimos»— y el alias lo eliges tú. La descripción general de proveedores deja claro que «no existe un parámetro global de “proveedor predeterminado” ni de “modelo predeterminado”», y que Config::validate() falla explícitamente al iniciarse si alguna referencia no se resuelve. Un fragmento del esquema 1 copiado no se rechaza por ser antiguo: la cadena de migración integra sus elementos de nivel superior api_key, api_url y default_model en una entrada de proveedor cuyo nombre determina default_provider, y la representación de V1 utilizada para la migración usa openrouter cuando falta esa clave, por lo que un fragmento plano que solo contenga una clave y una URL termina en una entrada openrouter en lugar de la pasarela que pretendías. El modo de fallo es una referencia que no se resuelve, no un nombre de campo antiguo.

Proveedor personalizado de ZeroClaw: apuntar un alias a una API compatible con OpenAI

Un endpoint que habla chat-completions de OpenAI va en el espacio custom, y la página de proveedores personalizados de v0.8.5 dice que este es un cambio exclusivo de configuración: «El espacio custom requiere uri (la enumeración de endpoints de la familia no tiene un valor predeterminado)». Un endpoint que habla el protocolo Anthropic Messages va en el espacio anthropic con uri establecido para sobrescribirlo, no en custom. Kunavo ofrece ambos formatos de protocolo bajo https://api.kunavo.com/v1 con una sola clave, así que, en principio, cualquiera de los dos espacios encaja. El fragmento siguiente combina los campos documentados del espacio personalizado con la estructura de cuatro encabezados del ejemplo práctico de la propia documentación; es una adaptación, no un bloque oficial copiado.

# Four section headers is the smallest config that loads clean.
[providers.models.custom.kunavo]
uri     = "https://api.kunavo.com/v1"   # REQUIRED: the custom family has no default endpoint
model   = "claude-sonnet-4-6"
api_key = "sk-kn-..."                   # or the secrets store, op://, or a ZEROCLAW_ env override

[agents.assistant]
model_provider  = "custom.kunavo"       # there is no global default provider
risk_profile    = "supervised"
runtime_profile = "resident"

[risk_profiles.supervised]
level                            = "supervised"
workspace_only                   = true
require_approval_for_medium_risk = true
block_high_risk_commands         = true

[runtime_profiles.resident]
max_actions_per_hour   = 10             # example values from the docs, not defaults
max_cost_per_day_cents = 100
max_tool_iterations    = 4
agentic_timeout_secs   = 120

Cuatro notas prácticas. Las credenciales pueden proporcionarse de cuatro maneras: insertadas directamente mediante api_key, como referencia op://vault/item/field de 1Password, en el almacén cifrado de ~/.zeroclaw/secrets, o mediante la sobrescritura de entorno genérica ZEROCLAW_providers__models__custom__kunavo__api_key, donde un doble guion bajo se asigna a un punto. Un nombre de shell predeterminado del ecosistema como $ANTHROPIC_API_KEY no se lee directamente a menos que la familia del proveedor documente su propio puente de entorno nativo; la documentación indica que debes expandirlo manualmente al nombre reflejado en el esquema; y una variable de entorno reflejada en el esquema es una inyección en tiempo de ejecución que nunca se convierte en configuración persistente. El espacio custom usa por defecto el protocolo chat-completions, y wire_api se respeta en las familias de endpoints propios (openai, llamacpp, custom), mientras que los espacios de proveedores con marca tienen un protocolo fijo y lo ignoran, con opencode como única excepción. Si tu gateway rechaza un campo temperature, déjalo sin establecer: la documentación indica que un temperature sin establecer se omite por completo del cuerpo de la solicitud. Además, un inicio correcto demuestra menos de lo que parece: el calentamiento de la conexión es un GET que consume el cuerpo y acepta códigos de estado no exitosos, por lo que el daemon se inicia en ambos casos; la página de proveedores personalizados en master lo documenta como GET {base_url}/models, mientras que el código de v0.8.5 calienta en su lugar la URL de chat-completions.

Valida en el orden documentado, los tres en v0.8.5: zeroclaw config list carga la configuración e imprime los fallos de validación en stderr, zeroclaw models refresh --model-provider custom.kunavo enumera lo que anuncia el endpoint y zeroclaw agent -a assistant -m "hello" realiza una prueba superficial del agente. El propio /v1/models de Kunavo responde HTTP 401 sin una clave (verificado el 21 de septiembre de 2026), lo que no es un bloqueo: el comando de actualización envía la clave del alias. Kunavo no ha probado ZeroClaw en tiempo de ejecución; todo lo de esta sección es una revisión de los documentos fuente de ZeroClaw, así que ejecuta tu propia tarea acotada antes de confiar en la ruta.

Kunavo no ofrece modelos de embeddings, texto a voz ni voz a texto, por lo que un agente que necesite esos pasos debe dirigirlos a un endpoint diferente, independientemente del espacio de ZeroClaw en el que se encuentre el modelo de chat.

El medidor de costes marca $0 hasta que escribes la tabla de tarifas

ZeroClaw mide su propio gasto, y en un gateway de terceros ese medidor comienza con datos incorrectos. El seguimiento de costes está controlado por cost.enabled, y los registros se escriben en un libro mayor de solo anexado en <workspace>/state/costs.jsonl, un objeto JSON por línea. El problema es de dónde proceden los precios. En catalog.rs de v0.8.5, catalog_source_for no devuelve ni una clave de models.dev ni un prefijo de proveedor de OpenRouter para la familia custom; la mayoría de los espacios con marca tienen al menos uno de los dos, aunque varios (zerorouter, telnyx, nearai) tampoco tienen ninguno. La activación opcional live_pricing está desactivada de forma predeterminada y, cuando se activa, primero lee el listado /models del propio endpoint y recurre después a models.dev usando el nombre de models.dev de la familia; la familia custom no tiene una clave de ese tipo, por lo que en ese espacio el listado del propio endpoint es la única fuente. El listado de Kunavo no contiene un campo de precio por token, leído de la fuente de la ruta y no de una respuesta de producción autenticada. Por tanto, un alias de espacio personalizado registra cost_usd = 0 con unpriced_tokens por encima de cero hasta que escribas las tarifas manualmente.

[cost]
enabled = true

# Keyed by the UPSTREAM model id as it appears in usage telemetry,
# not by your alias. USD per 1M tokens.
[cost.rates.providers.models.custom.claude-sonnet-4-6]
input        = 2.1
output       = 10.5
cached_input = 0.21

De ahí se derivan tres comportamientos, todos de la documentación de seguimiento de costes, comprobada el 21 de septiembre de 2026. Las entradas de tarifas se identifican por el identificador del modelo ascendente tal como aparece en la telemetría de uso, no por tu alias. Las comparaciones presupuestarias usan el cost_usd registrado, por lo que un total diario o mensual por debajo de su límite no garantiza la seguridad mientras el mes contenga tokens sin precio. Y las filas existentes del libro mayor nunca se vuelven a calcular: «no hay recálculo retroactivo», por lo que las tarifas solo se aplican a las solicitudes realizadas después de configurarlas. La aplicación tiene tres modos: warn (el predeterminado), block y route_down, que sustituye por un route_down_model más barato; además de allow_override, que es falso de forma predeterminada y permite que una solicitud omita block mediante un token de sobrescritura en la CLI.

Una estimación práctica frente al límite diario propio de ZeroClaw

Esto es aritmética ilustrativa de tokens, no el coste medido de una tarea ni un límite de facturación. El ejemplo práctico de [runtime_profiles] de la documentación limita un agente a max_actions_per_hour = 10 y max_cost_per_day_cents = 100; son valores de ejemplo para un modelo local pequeño, no valores predeterminados. Toma literalmente ese límite para ocho horas activas al día: 80 turnos diarios, cada uno enviando 6,000 tokens de entrada sin caché y devolviendo 500 tokens de salida. Las tarifas son precios activos del catálogo de Kunavo por millón de tokens.

La lectura útil no es la clasificación, sino la interacción con el límite. Un perfil escrito para un modelo local pequeño coloca un modelo de frontera bajo los mismos límites: max_actions_per_hour restringe el volumen de turnos, y el límite de coste diario rechaza una solicitud solo cuando enforcement.mode es block. Con warn, el valor predeterminado, el límite no bloquea en absoluto: registra el evento y deja pasar la solicitud. (warn_at_percent, 80% de forma predeterminada, es un parámetro independiente: controla cuándo el gateway muestra un aviso antes del límite estricto). Peor aún, si nunca escribiste la tabla de tarifas anterior, nada de esto se activa, porque el límite no puede detectar tokens sin precio. Escala la tabla según tu propio volumen de turnos y proporción de entrada y salida antes de tratarla como presupuesto; excluye los cargos de caché, las llamadas a herramientas y los reintentos, y supone que el modelo más barato termina el trabajo sin intentos adicionales.

El importe del catálogo de Kunavo es un mínimo de facturación, no un límite: cuando el upstream informa de su cargo, la factura es el mayor entre el coste del catálogo y el coste del upstream multiplicado por el margen aplicable. La recarga mínima es $10 en crédito prepago, que es un mínimo de financiación, no una tarifa por tarea ni una suscripción; consulta los detalles de facturación.

Mejor modelo y mejor API para ZeroClaw: lo que el proyecto dirá y no dirá

ZeroClaw no publica ningún modelo recomendado y se niega a hacerlo públicamente. Su página de configuración multimodelo afirma que «este flujo de trabajo no establece una lista de modelos verificada por ZeroClaw» y que «la evidencia de una compilación, modelo, cuantización y configuración de contexto no verifica otras combinaciones». Esa es la respuesta honesta a «mejor modelo para ZeroClaw»: no existe una clasificación oficial que citar, así que elige basándote en dos propiedades comprobables.

La primera es la llamada nativa a herramientas, y la misma página establece un criterio estricto: «Inspecciona la ejecución para comprobar que haya una llamada real a una herramienta, su resultado ejecutado y una continuación del asistente que use ese resultado. Una respuesta plausible o un marcado de llamada a herramienta impreso por sí solo no supera la prueba de herramientas». El parámetro del perfil de ejecución strict_tool_parsing trata el texto de respaldo con apariencia de XML o JSON como texto normal del asistente, a menos que el proveedor devuelva llamadas reales a herramientas, por lo que un modelo que simplemente describa una llamada parecerá funcionar y nunca actuará. La segunda es si el modelo termina tu tarea sin intentos adicionales; por eso el precio más barato de la lista y el menor coste para terminar son afirmaciones diferentes.

Hay dos comportamientos que conviene presupuestar antes de activar la conmutación por error. El streaming tiene el contrato más limitado: la página del ciclo de vida del enrutamiento de proveedores dice que el envoltorio «elige la primera entrada ordenada que admita las capacidades de streaming solicitadas y no esté en periodo de enfriamiento», luego «abre ese stream una sola vez» y «no cambia de entrada después de que el stream haya comenzado»; sin embargo, un stream que falle antes de comprometer cualquier salida se reintenta mediante la ruta sin streaming, que vuelve a recorrer por completo la evaluación de fiabilidad sobre fallback_models y fallback. Esos reintentos sin streaming cubren el tiempo de espera, el error de conexión, 429 y 503, y excluyen explícitamente 400, el fallo de autenticación permanente y los errores de salida del modelo. Además, una entrada de respaldo puede trasladar el trabajo a otro nivel de precios, así que asígnale primero un presupuesto. Para una comparación más amplia de las rutas del gateway, consulta la guía de API compatible con OpenAI y las alternativas a OpenRouter.

Trabajo mantenido: perfiles de riesgo, límites y el servicio que lo reinicia

La autonomía es por agente, no global. La página de autonomía de v0.8.5 acepta exactamente tres niveles: readonly, supervised y full; y rechaza read_only con guion bajo al cargar la configuración. Con el supervised predeterminado, las herramientas de bajo riesgo se ejecutan automáticamente, las de riesgo medio muestran una solicitud de aprobación al operador y las de alto riesgo se bloquean. Las solicitudes de aprobación caducan después del approval_timeout_secs del canal, 120 segundos para la mayoría de los canales, y un tiempo de espera cuenta como denegación; por tanto, un agente sin supervisión falla de forma segura en lugar de quedar en cola.

Hay dos límites en el trabajo mantenido. El comportamiento de reinicio no es uniforme entre plataformas: la unidad de usuario de systemd instalada establece Restart=always con RestartSec=3 y sin una lista de códigos de salida permitidos, por lo que un daemon que falle rápidamente debido a una configuración incorrecta entrará en un ciclo de reinicios; el LaunchAgent de macOS establece RunAtLoad y KeepAlive; y en Windows zeroclaw service install registra una tarea del Programador de tareas ONLOGON que inicia el daemon al iniciar sesión sin añadir una política de reinicio tras un fallo. El trabajo programado es declarativo y se identifica por alias en [cron.<alias>], separado de los propios parámetros de la sección [scheduler]. Además, el motor SOP determinista está marcado como experimental por la propia matriz de funciones del proyecto: los activadores periféricos y de calendario están definidos y se pueden hacer coincidir, pero todavía no se dirigen a una fuente activa; por tanto, no diseñes todavía un flujo de trabajo sin supervisión basándote en él.

Configúralo y comprueba el primer cargo

Kunavo no publica ninguna página de integración específica de ZeroClaw y no ha probado el cliente en tiempo de ejecución, así que trata la configuración anterior como una ruta basada en los documentos fuente, no como un resultado de compatibilidad. La secuencia práctica es breve: crea una clave, financia la recarga mínima, escribe los cuatro encabezados, ejecuta los tres comandos de validación en orden y luego escribe el bloque [cost.rates.*] antes de de la primera ejecución larga para que el libro mayor tenga algo que registrar. Empieza por la guía de inicio rápido para la URL base y el formato de la clave, por la referencia de chat-completions para el protocolo que utiliza el espacio custom y por crear una cuenta de Kunavo cuando estés listo para añadir fondos. Si tu agente utiliza el protocolo Anthropic, la documentación de la URL base de Anthropic explica la ruta del espacio anthropic.

Preguntas frecuentes

Comprobado el 21 de septiembre de 2026. Para esta página se volvieron a leer directamente: las preguntas frecuentes de zeroclaw.com, el README del repositorio, la API de GitHub para el estado del repositorio y el lanzamiento v0.8.5, migration.rs, schema/v1.rs, catalog.rs, compatible.rs, providers/custom.md, security/autonomy.md y ops/service.md en la etiqueta v0.8.5, y en master la perspectiva de migración de V2, providers/overview.md, providers/configuration.md, providers/catalog.md, providers/routing.md, providers/custom.md, architecture/provider-routing-lifecycle.md, ops/cost-tracking.md, getting-started/multi-model-setup.md, philosophy/minimal.md, philosophy/what-this-isnt.md y reference/feature-matrix.md, además del repositorio de zerorouter, los sitios de terceros y las páginas de destino mencionados anteriormente, y un GET sin autenticación a /v1/models de Kunavo. Todo lo citado desde master corresponde a documentación de la rama de desarrollo y puede adelantarse a la versión estable. Kunavo no ha probado ZeroClaw en tiempo de ejecución: no se realizó ninguna instalación, ningún config list ni ninguna ejecución de agente, por lo que el streaming, las llamadas nativas a herramientas y la visión mediante esta ruta no están verificados aquí. Las tarifas de tokens de Kunavo se leen del catálogo activo y todas las cifras en dólares de esta página son aritmética ilustrativa de tokens.