Documentation

Jan Agent

Jan Agent ne fournit aucun moteur d’inférence ; il appelle donc toujours un endpoint que vous indiquez. Une seule commande jan config set inscrit Kunavo dans ~/.jan/config.toml, et l’agent de terminal utilise Claude et GPT avec une seule clé.

Une ligne `jan config set --base-url https://api.kunavo.com/v1` écrit Kunavo dans ~/.jan/config.toml, et la CLI d’aperçu Jan Agent — qui ne fournit aucun moteur d’inférence — fonctionne avec cette clé.

jan config set — écrit dans ~/.jan/config.toml

# 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

L’URL de base conserve son /v1, quel que soit le protocole réseau. Jan ajoute uniquement la route : la page de contribution d’un fournisseur indique que la connexion « valide la clé auprès de GET {base_url}/models », et la page des fournisseurs précise qu’une entrée configurée est interrogée pour obtenir son GET /models la première fois que vous ouvrez /model dans une session. Toutes les URL de base indiquées dans ces documents se terminent par /v1 — y compris celle d’Anthropic dans l’exemple jan cli models list. --api-type anthropic utilise donc aussi https://api.kunavo.com/v1, à l’inverse de Claude Code et des SDK officiels d’Anthropic, pour lesquels le même suffixe produit /v1/v1/messages et une erreur 404. La présence d’un chemin en double dans l’erreur permet de savoir quelle convention vous utilisez.

Jan Agent est une préversion, et il le dit lui-même. Son guide de démarrage rapide indique que l’installateur sur dev récupère la version depuis le canal agent-nightly : « attendez-vous à des compilations de qualité nightly ». Aucune version balisée n’est disponible comme référence. Exécutez donc jan --version et notez cette chaîne à côté de cette configuration : les options ci-dessous ont été relevées dans la documentation à la date indiquée au bas de cette page, et une version nightly peut en renommer une. Une compilation depuis les sources (scripts/install-jan-agent.sh --source) ne se met pas à jour automatiquement, ce qui permet de conserver une version fixe.

Cette configuration a été relevée dans la documentation de Jan. Kunavo n’a pas exécuté Jan Agent contre son endpoint : ni session, ni échange en continu, ni aller-retour d’appel d’outil ; il en va de même pour tous les clients de cette famille. Une page de configuration publiée ne constitue pas un test de compatibilité. Gardez à portée de main la méthode qui fonctionne déjà pendant que vous essayez celle-ci, et rappelez-vous que jan config unset --provider kunavo suffit à tout annuler.

Kunavo ne propose aucun modèle d’intégration, de synthèse vocale ou de reconnaissance vocale ; une entrée fournisseur Kunavo ne traite donc que le chat. Jan Agent n’a pas besoin d’autre chose : sa mémoire se compose de simples fichiers dans <project>/.jan/agent/memory/, plutôt que d’un magasin vectoriel. La boucle de l’agent n’a donc pas besoin d’un autre type de modèle.

Pas encore de clé ? Créez un compte Kunavo, créez une clé (elle commence par sk-kn-) et ajoutez un crédit à partir de 10 $ — les appels sont payés sur ce solde et les appels échoués ne sont pas facturés. Le tableau de bord s’ouvre ensuite sur la configuration Jan Agent.

Étape par étape

Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
Vérifiez ce que vous configurez : jan --version. Jan Desktop fournit également une CLI lancée avec jan, mais ses commandes sont différentes. Vérifiez donc que jan config set --help répertorie --base-url avant de poursuivre.
Exécutez la commande jan config set ci-dessus. --provider est un identifiant que vous choisissez, et non un nom issu d’une liste fixe — l’exemple de matériel local de la documentation utilise --provider local — et --model peut être répété ; il remplace toute liste existante au lieu de lui ajouter des éléments.
Vérifiez que la configuration est bien enregistrée avec jan config list (les clés sont masquées) ou jan config path pour le fichier lui-même, puis exécutez jan cli models list pour voir ce que propose chaque fournisseur. Un identifiant de modèle saisi manuellement reste présent même lorsque l’endpoint ne le répertorie plus ; jan cli models refresh --provider kunavo considère au contraire la liste de l’endpoint comme la référence.
Placez-vous dans un projet et exécutez jan, puis choisissez le modèle avec /model. Pour le premier essai, privilégiez jan --plan : la commande est en lecture seule, de sorte qu’une incompatibilité de protocole se manifeste avant toute écriture sur le disque.
Donnez-lui une tâche qui modifie un fichier. Jan Agent est un agent ; un premier essai doit donc mettre à l’épreuve les appels d’outils et la diffusion en continu. Ce sont les premières fonctions qui échoueraient si l’endpoint n’était que partiellement compatible, tandis qu’une simple salutation ne teste ni l’une ni l’autre.

Vérifié avec la page Fournisseurs de Jan Agent le 21 septembre 2026. Les paramètres tiers évoluent ; si le nom d’un champ ne correspond plus à ce que vous voyez ici, cette page fait autorité, pas celle-ci.

Voici la version courte. Le guide complet — choix du modèle, coût d’une session réelle et modes d’échec — se trouve dans le guide des coûts de Jan pour les modèles et l’API, qui couvre également Jan Desktop.

Vérifiez avant de déboguer le client

Une requête suffit à déterminer si l’échec vient de l’endpoint, de la clé ou du fichier de configuration. Si cette requête renvoie du JSON, la même URL de base et la même clé fonctionnent dans 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-..."

Quel identifiant de modèle saisir dans le champ

Tous les modèles textuels sont accessibles sous forme d’identifiant de modèle — la liste à jour se trouve sur GET /v1/models, et le catalogue avec les prix sur la page des modèles. Les tarifs sont en USD par million de tokens, entrée / sortie.

Identifiant du modèle	Entrée / sortie sur Kunavo	Où cela s’intègre dans Jan Agent
`claude-sonnet-5`	$1.40 / $7.00	le modèle de travail par défaut — l’identifiant à placer en premier après --model
`claude-opus-5`	$3.50 / $17.50	un plan dont une erreur coûterait cher ; associez-le à jan --plan
`claude-haiku-4-5`	$0.70 / $3.50	requêtes à faible coût : triage, résumés et boucle qui fonctionne toute la journée
`gpt-5-6-sol`	$2.00 / $12.00	un second avis d’une autre famille, avec la même clé et la même URL de base
`gpt-5-6-terra`	$0.70 / $4.20	lecture de longs contextes, toujours avec le type d’API openai

La facturation se fait au token à partir d’un solde prépayé, sans frais mensuels — consultez la facturation. Avec un contexte répété — ce qu’envoient la plupart des éditeurs et clients de chat — la mise en cache des prompts influe davantage sur la facture que le choix du modèle.

Deux éléments différents sont appelés une clé API Jan

Ils se trouvent dans le même fichier et ont des fonctions opposées ; c’est pourquoi jan config list peut sembler incorrect à quelqu’un qui s’attend à l’autre clé.

Quoi	D’où elle provient	Ce qu’elle authentifie
`jan login`	Se connecter à Tokamak, le backend auto-hébergé, depuis le terminal ou avec /login dans la console	Votre propre déploiement de Tokamak. Jan Agent écrit pour vous la clé qu’il reçoit dans ~/.jan/config.toml
`jan config set --api-key`	Un identifiant que vous possédez déjà pour un endpoint — ici, la clé sk-kn- de Kunavo	Cet endpoint, facturé à la requête. C’est la ligne traitée par cette page

Jan Desktop n’émet ni l’un ni l’autre : il n’a pas de compte, donc rien à générer. Son serveur API local accepte une clé que vous inventez vous-même ; il s’agit là d’un troisième sens, qui relève d’un autre hôte.

Ce que Jan Desktop transmet, et où cela s’arrête

Jan Agent lit quatre sources de paramètres de fournisseur, chacune ayant priorité sur celles qui la suivent ; la deuxième surprend souvent.

~/.jan/config.toml — la configuration de base, et le seul fichier que jan config set modifie.
Le settings.json de Jan Desktop — hérité uniquement. Il ajoute les fournisseurs que vous n’avez pas configurés dans Agent, ne remplace jamais ceux que vous avez déjà configurés et n’est jamais réécrit.
Un bloc [provider] dans le fichier agent.toml d’un projet — un choix explicite propre au projet, qui a donc priorité sur les deux autres sources. Ce fichier est généralement enregistré dans le dépôt ; gardez donc api_key à l’écart.
--provider / --api-key sur la ligne de commande, ou JAN_API_KEY / <PROVIDER>_API_KEY — l’option la plus explicite et la plus éphémère.

Deux conséquences à connaître avant de chercher le problème au mauvais endroit. jan config list peut ne signaler aucun fournisseur alors que jan cli models list en renvoie plusieurs : cette deuxième commande inclut ceux hérités de Desktop, qui ne sont pas stockés dans ~/.jan/config.toml. Par ailleurs, un fournisseur hérité n’est jamais actualisé, car il n’y a aucune entrée à réécrire ici. Pour que la liste de modèles de Kunavo reste à jour, il faut créer sa propre entrée jan config set, comme le fait le bloc ci-dessus.

Quand deux fournisseurs proposent le même identifiant de modèle

Kunavo propose des identifiants comme claude-sonnet-5, tout comme une entrée de fournisseur pointant directement vers l’éditeur. Jan Agent doit choisir l’un des deux. L’ordre documenté est le suivant : d’abord, une correspondance exacte dans la liste models d’un fournisseur ; ensuite, un préfixe <provider>/<model> désignant un fournisseur configuré ; enfin, si plusieurs fournisseurs proposent le même identifiant, le fournisseur avec identifiants d’accès est prioritaire sur son équivalent sans clé. Utilisez donc kunavo/claude-sonnet-5 pour indiquer celui que vous vouliez. Ce qualificatif ne sert qu’à Jan : il est retiré avant l’envoi de la requête, car les services en amont refusent les identifiants qualifiés par fournisseur.

La même entrée, depuis la console

Si vous préférez ne pas saisir de paramètres : /settings > providers permet de gérer les mêmes entrées ~/.jan/config.toml, et a ouvre un formulaire d’ajout avec les champs name, base url, api key et models séparés par des espaces. Le formulaire fait deux choses que les options ne font pas : l’URL de base doit être en https:// (ou en http:// pour un endpoint localhost), afin qu’une clé ne soit jamais envoyée en clair sur une connexion distante — Kunavo est en https://, ce qui ne pose donc aucun problème — et, en cas de modification, le champ de clé API affiche (unchanged) et conserve la valeur enregistrée tant que vous n’y saisissez rien. Effacer le contenu de ce champ supprime la clé au lieu de la laisser inchangée.

Questions fréquentes

Comment configurer un endpoint API personnalisé dans Jan Agent ?

Avec une seule commande : jan config set --provider <id> --api-key <key> --base-url <url> --model <model> --api-type openai. Vous choisissez l’identifiant du fournisseur ; il ne provient pas d’une liste prédéfinie. L’option --model peut être répétée et remplace toute liste existante. --api-type est compatible avec OpenAI par défaut et peut donc être omis pour un endpoint au format OpenAI. L’entrée est écrite dans ~/.jan/config.toml, que vous pouvez aussi modifier dans la console, via /settings > providers. La page de Jan sur l’ajout de fournisseurs précise qu’un endpoint compatible avec OpenAI n’exige aucun code : il suffit de le configurer à cet endroit.

L’URL de base de Jan Agent doit-elle se terminer par /v1 ?

Oui, y compris pour le type de protocole Anthropic. Jan n’ajoute que le chemin d’accès : la page sur l’ajout de fournisseurs indique que la connexion vérifie la clé avec GET {base_url}/models, et la page des fournisseurs précise qu’une entrée configurée est interrogée via son GET /models à la première ouverture de /model dans une session. Comme le chemin ajouté est /models, et non /v1/models, l’URL de base enregistrée doit déjà être la racine /v1 — pour Kunavo, https://api.kunavo.com/v1. Toutes les URL de base présentées dans la documentation de Jan se terminent de la même manière, y compris l’entrée Anthropic dans l’exemple de liste de modèles de jan cli models list. C’est l’inverse de Claude Code et des SDK officiels Anthropic, où l’ajout de /v1 produit /v1/v1/messages et une erreur 404.

Quelle est la différence entre jan login et jan config set --api-key ?

Ces commandes authentifient des accès différents. jan login se connecte à Tokamak, le backend auto-hébergé, et enregistre la clé obtenue dans ~/.jan/config.toml : il s’agit d’une connexion à votre propre déploiement. jan config set --api-key enregistre un identifiant d’accès que vous possédez déjà pour un endpoint donné ; c’est la méthode à utiliser avec un fournisseur tiers comme Kunavo. Jan Desktop n’émet ni l’un ni l’autre, puisqu’il n’a pas de compte permettant d’en générer. La clé demandée par son serveur API local est une chaîne que vous inventez ; c’est un troisième sens du terme.

Pourquoi jan config list n’affiche-t-il rien alors que jan cli models list affiche des modèles ?

Parce que ces deux commandes consultent des ensembles différents. jan config list affiche uniquement ce qui est stocké dans ~/.jan/config.toml, tandis que jan cli models list inclut aussi les fournisseurs hérités de Jan Desktop, qui ne sont pas enregistrés dans ce fichier. La documentation de Jan le précise clairement. En pratique, un fournisseur hérité n’est jamais actualisé, car aucune entrée ne peut être réécrite. Pour maintenir à jour la liste de modèles d’un fournisseur, ajoutez-le d’abord avec jan config set.

Jan Agent peut-il exécuter des modèles Claude sans compte Anthropic ?

Oui. Jan Agent ne fournit aucun moteur d’inférence : un modèle s’exécute donc toujours sur l’endpoint que vous configurez, et --api-type désigne le protocole de communication, pas l’éditeur. Un identifiant Claude est résolu sur l’URL de base que vous définissez ; les identifiants d’accès utilisés sont donc ceux de cet endpoint. Kunavo propose des identifiants Claude et GPT sur son interface compatible avec OpenAI, avec une seule clé. Cette configuration est tirée de la documentation de Jan, et non d’un essai du client. Jan Agent étant lui-même une préversion diffusée sur un canal nightly, vérifiez la version concernée avec jan --version avant de vous fier aux options.

Jan Agent renvoie une erreur 404 à chaque requête. Quel est le problème ?

Dans presque tous les cas, l’URL de base est en cause. Sans /v1, Jan envoie /models et /chat/completions à la racine de l’hôte, ce qui provoque une erreur 404 plutôt qu’un échec d’authentification. Si le message d’erreur indique un double /v1/v1, le suffixe a été ajouté à une URL qui le contenait déjà. Commencez par vérifier l’endpoint en dehors du client : envoyez un GET /v1/models avec un simple appel curl et la même clé. Si vous recevez du JSON, l’endpoint et la clé sont valides et le problème vient de l’entrée configurée ; une erreur 401 indique un problème de clé, et une erreur 404, un problème d’URL. Vérifiez ensuite jan config path et lisez directement la valeur base_url enregistrée.