Documentación

Open Interpreter

Open Interpreter lee los proveedores de una tabla TOML, como su antecesor Codex, pero conserva un transporte de completaciones de chat que Codex upstream eliminó. Basta un bloque [model_providers.kunavo] para que el agente use cualquier modelo al que dé acceso la clave.

Una única tabla [model_providers.kunavo] en ~/.openinterpreter/config.toml — base_url, env_key, wire_api = "chat" — y el agente de terminal Rust funciona con cualquier modelo al que tenga acceso la clave.

~/.openinterpreter/config.toml

model_provider = "kunavo"
model = "claude-sonnet-5"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"     # the NAME of the variable, not the key
wire_api = "chat"

La URL base conserva el sufijo /v1 para el protocolo chat. La documentación de Open Interpreter lo aclara con ejemplos, no con una regla explícita: el bloque de proveedor personalizado de la página de proveedores usa base_url = "https://api.example.com/v1", el de la página de configuración usa "https://api.acme.example/v1", y la pasarela alojada que documentan por nombre usa "https://app.nz/v1". Si se omite el sufijo, el error es 404, no un error de autenticación.

Kunavo no ha probado este cliente con su endpoint, ni este ni ninguno de los otros clientes de estas páginas. Lo que se ha comprobado es la configuración disponible: las claves de abajo son las que aparecen en la documentación oficial de Open Interpreter, consultada en la fecha indicada al pie de esta página, y la URL base y los identificadores de modelo son de Kunavo. Una guía de configuración publicada no equivale a una prueba. Considere la solicitud de verificación como la comprobación que confirma si funciona.

Hay dos programas distintos llamados «Open Interpreter», y este bloque es para la versión en Rust. El paquete de Python fijado en 0.4.3 se configura mediante --api_base, --api_key y --model openai/<id>, o mediante interpreter.llm en Python. Ninguno de esos elementos existe en el agente de terminal actual, que solo lee la tabla TOML de arriba. Ejecute interpreter --version antes de editar nada: un pip install open-interpreter de un tutorial antiguo deja un segundo binario compitiendo por el mismo nombre.

Un identificador de modelo de Claude hace que Open Interpreter elija automáticamente el entorno de ejecución claude-code: sus valores predeterminados documentados lo seleccionan para «Anthropic, identificadores de modelos Claude, URL base de Anthropic o cualquier proveedor messages». Esa combinación es válida en este caso: la tabla de enrutamiento indica que claude-code es compatible con wire_api = "chat". Defina explícitamente harness si quiere otro; un valor explícito siempre prevalece, y si el valor no se reconoce, se recurre a chat sin un generador de solicitudes integrado, en lugar de producir un error claro.

¿Aún no tienes una clave? Crea una cuenta de Kunavo, genera una clave (empieza por sk-kn-) y añade crédito desde $10; las llamadas se pagan con ese saldo y las llamadas fallidas no se facturan. El panel se abre entonces en la configuración de Open Interpreter.

Paso a paso

Cree una clave en /app/keys y cópiela: se muestra una sola vez.
Expórtela con el nombre que va a escribir en env_key: export KUNAVO_API_KEY=sk-kn-.... Ese campo contiene el nombre de la variable, no su valor; la documentación indica que env_key es la fuente que «lee un token de portador de una variable de entorno».
Coloque el bloque anterior en ~/.openinterpreter/config.toml, o en .openinterpreter/config.toml dentro de un proyecto de confianza si quiere que se aplique solo a un repositorio. La configuración del proyecto tiene prioridad sobre la configuración del usuario; una opción -c key=value tiene prioridad sobre ambas para esa ejecución.
Inicie interpreter y ejecute /model. El selector consulta primero la ruta de modelos del proveedor activo, y Kunavo responde con GET /v1/models, por lo que la lista se completa automáticamente.
Ejecute /debug-config si se están usando valores incorrectos: muestra la configuración efectiva y el origen de cada valor, lo que permite detectar más rápido un perfil obsoleto o un archivo del proyecto que volver a leer el TOML.

Comprobado con Página de proveedores de modelos de Open Interpreter el 21 de septiembre de 2026. La configuración de terceros puede cambiar; si el nombre de un campo ya no coincide con lo que ves, esa página es la autoridad, no esta.

Esta es la versión breve. El tutorial completo —elección del modelo, coste de una sesión real y modos de fallo— está en la diferencia entre las versiones de Open Interpreter, sus precios y alternativas.

Verifica antes de depurar el cliente

Una solicitud determina si el fallo está en el endpoint, la clave o el archivo de configuración. Si devuelve JSON, la misma URL base y la misma clave funcionan en Open Interpreter.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Qué ID de modelo introducir en el campo

Todos los modelos de texto están disponibles mediante un ID de modelo; la lista activa está en GET /v1/models, y el catálogo con precios está en la página de modelos. Las tarifas son USD por 1M de tokens, entrada / salida.

ID de modelo	Entrada / salida de Kunavo	Dónde encaja en Open Interpreter
`claude-sonnet-5`	$1.40 / $7.00	el modelo de trabajo predeterminado para ciclos de edición y ejecución
`claude-opus-5`	$3.50 / $17.50	planificar una refactorización grande, donde equivocarse de plan sale caro
`claude-haiku-4-5`	$0.70 / $3.50	sesiones con mucho uso del shell, donde predomina la cantidad de turnos
`gpt-5-6-sol`	$2.00 / $12.00	una segunda opinión de una familia distinta, con la misma clave

La facturación es por token desde un saldo prepago, sin cuota mensual; consulta facturación. Con contexto repetido —que constituye la mayor parte de lo que envía un editor o cliente de chat—, la caché de indicaciones cambia más la factura que la elección del modelo.

Preguntas frecuentes

¿Cómo puedo indicar a Open Interpreter que use un proveedor de API personalizado?

Añada una tabla [model_providers.<id>] a ~/.openinterpreter/config.toml con name, base_url, env_key y wire_api; después, selecciónela con la clave model_provider de nivel superior y especifique un modelo con model. Para un endpoint compatible con OpenAI, use wire_api = "chat" y una URL base que termine en /v1; ese es el formato que muestra la propia página de proveedores de Open Interpreter para un proveedor personalizado y para la pasarela alojada que documenta por nombre. env_key contiene el nombre de una variable de entorno, así que exporte la clave en lugar de pegarla en el archivo.

¿Tiene que terminar en /v1 la base_url de Open Interpreter?

Para el protocolo de chat, sí. La documentación no explica en prosa cómo se construye la ruta, pero todos los ejemplos de proveedores personalizados que incluye llevan el sufijo: https://api.example.com/v1 en la página de proveedores, https://api.acme.example/v1 en la página de configuración y https://app.nz/v1 para la pasarela que menciona. El protocolo de mensajes funciona de otra manera: los proveedores al estilo de Anthropic que incluye el cliente usan una raíz de API sin /v1. Por tanto, la respuesta sobre /v1 se limita a wire_api = "chat" y wire_api = "responses".

¿Siguen funcionando las opciones antiguas --api_base y --model openai/... ?

No. Esas opciones pertenecen al paquete de Python fijado en 0.4.3, que se enrutaba mediante LiteLLM y por eso necesitaba el prefijo openai/. El agente de terminal actual es una bifurcación de Codex escrita en Rust y no admite esas opciones ni usa ese convenio de prefijos: lee una tabla de proveedores TOML desde ~/.openinterpreter/config.toml o desde .openinterpreter/config.toml en el nivel del proyecto, y selecciona el proveedor y el modelo con model_provider y model. La configuración se ha escrito desde cero y docs.openinterpreter.com redirige a la documentación de Rust, así que los enlaces de un tutorial antiguo siguen funcionando, aunque describen un programa que no tiene instalado.

¿Por qué el selector /model no muestra el tamaño de contexto de un proveedor personalizado?

Porque esos metadatos provienen del catálogo incluido con el cliente, que se genera a partir de models.dev y de algunos endpoints de proveedores en tiempo real. El catálogo solo se inicializa cuando un proveedor coincide con una entrada por identidad de Anthropic, URL base, nombre del proveedor o variable de entorno de autenticación. Kunavo no está incluido en ese catálogo generado —se comprobó el archivo del repositorio el 21 de septiembre de 2026—, así que un proveedor escrito a mano obtiene la lista de modelos de la propia ruta de modelos del endpoint y nada más. Los modelos siguen funcionando; simplemente hay menos información junto a ellos en el selector.

¿Puede Open Interpreter acceder a un modelo Claude sin una cuenta de Anthropic?

Sí, porque wire_api identifica un transporte, no un proveedor. Con wire_api = "chat", el identificador del modelo se envía tal cual a la base_url que haya configurado y allí se resuelve, por lo que la credencial que utiliza es la del endpoint. Open Interpreter seguirá seleccionando automáticamente su entorno claude-code a partir de un identificador de modelo Claude, y ese entorno figura como compatible con el protocolo de chat. Por eso, esta combinación es la documentada y no una solución alternativa.