Jan Agent

Una línea `jan config set --base-url https://api.kunavo.com/v1` escribe Kunavo en ~/.jan/config.toml, y la CLI de vista previa Jan Agent — que no incluye motor de inferencia — funciona con esa clave.

# Jan Agent is a preview on a nightly channel — check your build first.
jan --version

jan config set \
  --provider kunavo \
  --api-key sk-kn-... \
  --base-url https://api.kunavo.com/v1 \
  --model claude-sonnet-5 \
  --model claude-haiku-4-5 \
  --api-type openai

jan config list   # configured providers as JSON, keys redacted

Paso a paso

1. Cree una clave en /app/keys y cópiela: se muestra una sola vez.
2. Comprueba qué estás configurando: jan --version. Jan Desktop también incluye un CLI que se invoca como jan, pero tiene un conjunto de comandos distinto. Antes de escribir lo demás, confirma que jan config set --help muestra --base-url.
3. Ejecuta la línea jan config set de arriba. --provider es un ID que eliges, no un nombre de una lista fija; el propio ejemplo de hardware local de la documentación usa --provider local. Además, --model se puede repetir y reemplaza cualquier lista existente en vez de ampliarla.
4. Confirma que se haya aplicado con jan config list (las claves se ocultan) o con jan config path para consultar directamente el archivo; después, ejecuta jan cli models list para ver qué ofrece cada proveedor. Un ID de modelo escrito manualmente permanece aunque el endpoint deje de incluirlo en su lista; jan cli models refresh --provider kunavo usa, en cambio, la lista del endpoint como fuente de verdad.
5. Cambia a un directorio de proyecto y ejecuta jan; después, elige el modelo con /model. Para la primera ejecución, es preferible usar jan --plan: es de solo lectura, por lo que cualquier incompatibilidad de protocolo saldrá a la luz antes de escribir datos en el disco.
6. Asígnale una tarea que modifique un archivo. Jan Agent es un agente, así que la primera ejecución debe poner a prueba las llamadas a herramientas y el streaming: son las primeras funciones que fallarían ante un endpoint solo parcialmente compatible, y un saludo no pone a prueba ninguna de las dos.

Comprobado con Página de proveedores de Jan Agent 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.

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 Jan Agent.

# 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.

Dos cosas distintas reciben el nombre de clave de API de Jan

Se guardan en el mismo archivo y tienen funciones opuestas, por eso jan config list puede parecer incorrecto a quien esperaba la otra.

Jan Desktop no emite ninguna de las dos: no tiene cuenta, así que no hay nada que generar. Su servidor de API local acepta una clave que inventas tú, que es un tercer significado y corresponde a otro host.

Qué transmite Jan Desktop y hasta dónde llega

Jan Agent lee los ajustes del proveedor de cuatro fuentes, cada una con prioridad sobre las anteriores, y la segunda es la que sorprende a la gente.

1. ~/.jan/config.toml — la configuración base y el único archivo que escribe jan config set.
2. El settings.json de Jan Desktop: solo para heredar. Añade proveedores que no hayas configurado en Agent, nunca sobrescribe los que ya tengas y nunca se escribe en él.
3. Un bloque [provider] en el agent.toml de un proyecto: una elección explícita para cada proyecto, por lo que prevalece sobre ambos. Ese archivo suele incluirse en el repositorio, así que no pongas api_key en él.
4. --provider / --api-key en la línea de comandos, o JAN_API_KEY / <PROVIDER>_API_KEY: la opción más explícita y más efímera.

Conviene conocer dos consecuencias antes de depurar lo que no corresponde. jan config list puede indicar que no hay proveedores mientras que jan cli models list devuelve varios: el segundo incluye los proveedores heredados de Desktop, que no están guardados en ~/.jan/config.toml. Además, un proveedor heredado nunca se actualiza, porque aquí no hay ninguna entrada que reescribir: si quieres que la lista de modelos de Kunavo se mantenga al día, debe tener su propia entrada jan config set, que es lo que crea el bloque anterior.

Cuando dos proveedores ofrecen el mismo id de modelo

Kunavo ofrece ids como claude-sonnet-5, al igual que una entrada de proveedor que apunta directamente al proveedor original. Jan Agent tiene que elegir uno, y el orden documentado es el siguiente: primero, una coincidencia exacta en la lista models de un proveedor; después, un prefijo <provider>/<model> que nombre a un proveedor configurado; y, si varios ofrecen el mismo id, prevalece el proveedor con credenciales frente a otro idéntico sin clave. Por eso, kunavo/claude-sonnet-5 indica cuál querías usar. El calificador solo es para Jan: se elimina antes de enviar la solicitud, porque los proveedores upstream rechazan un id calificado con un proveedor.

La misma entrada, desde la consola

Si prefieres no escribir indicadores: /settings > providers permite gestionar las mismas entradas ~/.jan/config.toml, y a abre un formulario para añadirlas con los campos name, base url, api key y models separados por espacios. El formulario hace dos cosas que no hacen los indicadores: la URL base debe ser https:// (o http:// para un endpoint localhost), para que la clave nunca se envíe por una conexión remota sin cifrar —Kunavo usa https://, así que esto no supone ningún problema—; además, al editar, el campo de la clave de API muestra (unchanged) y conserva lo almacenado salvo que escribas algo. Si dejas el campo vacío, se borra la clave en lugar de conservarla.