Modèles Jan AI et coûts API : local, cloud et endpoints personnalisés

Les modèles cloud de Jan AI ne sont pas les modèles de Jan. Jan n’héberge aucun service d’inférence et ne vend rien ; dans Jan Desktop, « modèles cloud » désigne donc onze passerelles intégrées utilisant votre propre clé vers des fournisseurs tiers, ainsi que tout point de terminaison au format OpenAI ou Anthropic que vous ajoutez vous-même — chacun étant facturé par l’entité située à l’autre extrémité. L’application elle-même est gratuite : jan.ai/pricing renvoyait HTTP 404 lors de la vérification du 19 septembre 2026, et ni Jan Desktop ni Jan Agent ne documente de forfait, de siège, de crédit ou de quota. Le seul chiffre à prévoir est donc celui des tokens au tarif de votre fournisseur — ou zéro par requête si le modèle s’exécute sur votre propre machine.

Une première clarification s’impose, car les recherches les mélangent. Janitor AI (janitorai.com) est un site grand public de discussion avec des personnages et un produit totalement différent ; une grande partie des recherches « jan ai api key » désigne sa clé proxy. Si c’est ce que vous configurez, commencez plutôt par la page de configuration de Janitor AI — aucune information de prix ou de limite pour ce produit n’apparaît sur cette page.

Trois produits partagent la marque Jan, et deux partagent le nom du binaire

C’est cette confusion qui explique pourquoi les acheteurs ne savent plus si Jan est gratuit à exécuter. jan.ai répertorie exactement trois produits (page d’accueil consultée le 18 septembre 2026) :

• Jan Desktop — l’application stable privilégiant l’usage local. Dernière version étiquetée v0.8.4, publiée le 23 juillet 2026 ; le dépôt n’est pas archivé et a reçu son dernier push le 18 septembre 2026, avec 44 551 étoiles (API GitHub, 19 septembre 2026). Il intègre les moteurs llama.cpp et MLX et peut accéder facultativement à des fournisseurs cloud. Le dépôt se décrit comme fonctionnant à 100 % hors ligne.
• Jan Agent — un agent de terminal distinct, distribué séparément. Son démarrage rapide comporte un avertissement de préversion : l’installateur de dev extrait la version depuis le canal agent-nightly. Il n’a aucune version marquée dans le dépôt, et le démarrage rapide n’en affiche une qu’avec jan --version ; toute information que vous écrivez sur ses options dépend donc de la version que vous avez installée.
• Tokamak — un backend auto-hébergé au niveau de l’organisation, avec son propre domaine documentaire. Sa page ne publie ni prix, ni forfait, ni nombre de sièges, ni crédit, ni liste d’attente ; cette page n’en cite donc aucun — et l’absence de conditions publiées ne signifie pas que le service est gratuit. Il s’agit d’un backend auto-hébergé distinct plutôt que d’un forfait payant ajouté à Jan Desktop, et jan login est la procédure documentée pour y accéder.

La documentation de Jan semble contradictoire sur ce point, et c’est la page des fournisseurs qui permet de la concilier. Le texte de présentation de la documentation décrit Jan Agent comme lançant des agents sur un modèle local ; le démarrage rapide affirme catégoriquement que Jan Agent ne possède aucun moteur d’inférence local — il appelle un fournisseur distant. Les deux affirmations sont exactes, mais concernent des aspects différents. L’Agent n’exécute lui-même aucun modèle, qui s’exécute donc toujours ailleurs — mais cet « ailleurs » peut être votre propre machine : la page des fournisseurs comporte une section « Your own hardware » qui dirige l’Agent vers le serveur d’API local de Jan Desktop (http://localhost:6767/v1) et précise que rien ne quitte votre machine dans cette configuration. L’Agent a donc toujours besoin d’un point de terminaison ; il n’a pas toujours besoin d’un point de terminaison payant.

La collision des noms aggrave encore la situation. La propre CLI de Jan Desktop (disponible depuis 0.7.8) et le binaire Jan Agent sont tous deux invoqués avec jan, mais proposent des ensembles de commandes différents. Il existe donc trois « points de terminaison Jan » distincts : 127.0.0.1:1337 pour le serveur d’API local de l’interface graphique Desktop, localhost:6767/v1 pour jan serve depuis la CLI Desktop, et toute URL de base distante vers laquelle un fournisseur est dirigé.

Tarification de Jan AI : coût du logiciel et services qui vous facturent

Une note sur la licence, car la lecture automatique est incorrecte : l’API de GitHub renvoie NOASSERTION pour ce dépôt, car le fichier LICENSE est constitué d’un préambule personnalisé de Menlo Research suivi de la mention standard Apache 2.0 et d’une demande d’attribution, plutôt que du texte Apache 2.0 reproduit mot pour mot qu’un analyseur recherche. Le fichier lui-même indique « Licensed under the Apache License, Version 2.0 » ; c’est donc la licence, et non le champ de l’API.

Les onze fournisseurs cloud intégrés, et ce qu’ils sont réellement

Jan Desktop initialise chaque fournisseur intégré avec une URL de base dans web-app/src/constants/providers.ts. Chacune pointe vers un tiers. Il n’existe aucune entrée jan ou menlo.

Lu dans ce fichier le 18 septembre 2026. Remarquez le schéma que chacun suit : le chemin de version fait partie de l’URL de base. Cette convention unique est la cause d’échec de configuration la plus fréquente dans Jan, et elle est couverte ci-dessous.

Trois choses différentes appelées « clé API Jan AI »

Les deux significations se confondent réellement dans Jan, car son serveur local reproduit les deux formats réseau. La documentation des préférences d’API de Jan montre que le serveur local expose GET /v1/models, POST /v1/chat/completions et un POST /v1/messages compatible Anthropic, authentifié avec x-api-key. C’est la même structure qu’expose une passerelle distante — la même commande curl peut donc être dirigée vers votre ordinateur portable ou vers un point de terminaison payant ; seul l’hôte indique lequel.

Local ou cloud : décidez selon la mémoire, le contexte et le besoin de travailler hors ligne

La base la plus objective pour cette décision est publiée par Jan lui-même sur la page d’installation Mac (macOS 13.6 ou version ultérieure, Apple Silicon uniquement — les Mac Intel ne sont pas pris en charge — et au moins 10GB d’espace libre) :

Les minima Windows sont indiqués séparément sur la page d'installation de Windows et incluent un seuil de VRAM : Windows 10 ou version ultérieure, 8GB de RAM minimum avec 16GB recommandés, 6GB de VRAM minimum pour les GPU NVIDIA, AMD ou Intel Arc, 10GB d'espace libre et la prise en charge d'AVX2. Cette page ne publie aucun tableau de RAM par taille de modèle. Les exigences Linux n'ont pas été vérifiées pour cette page. Dans l'application, le Hub remplace les chiffres par un verdict — une pastille colorée indiquant S'adapte, Peut être lent ou Ne s'adaptera pas pour chaque niveau de quantification — et précise qu'aucune donnée n'est téléchargée pour déterminer l'état d'adéquation.

Concernant le choix du modèle : Jan documente sept modèles propriétaires — Jan-v3-4B, Jan-Code-4B, Jan-v1, Jan-v2-VL-med, Jan-Nano-32, Jan-Nano-128 et Lucy — avec des poids ouverts sur Hugging Face dans les propres organisations de Jan, janhq et Menlo. Ils ne sont pas tous de la même taille : la documentation des modèles indique 4B paramètres pour Jan-v3-4B et Jan-v1, 8B pour Jan-v2-VL-med et 1.7B pour Lucy. Jan-v3-4B possède également un contexte natif de 262,144 tokens, et sa page énonce clairement sa propre limite : les 4B paramètres limitent les raisonnements complexes en plusieurs étapes par rapport aux modèles plus grands. Cette phrase résume à elle seule l'argument local contre cloud. Utilisez le local pour les tâches délimitées et la confidentialité ; passez au distant lorsque la tâche dépasse le nombre de paramètres ou votre mémoire.

API personnalisée de Jan Desktop : ajouter un endpoint au format OpenAI ou Anthropic

Le chemin documenté est Settings → Model Providers → Add Provider. La page des endpoints personnalisés de Jan (vérifiée le 19 septembre 2026) propose exactement deux formats filaires — compatible OpenAI, présenté comme destiné à vLLM, Ollama, LocalAI, TGI, llama.cpp server et LiteLLM en mode OpenAI, et compatible Anthropic, pour les endpoints qui exposent l'API Anthropic Messages — puis demande un nom de fournisseur, une URL de base et une clé API. Le champ de clé est obligatoire même pour les serveurs locaux sans clé, pour lesquels n'importe quel espace réservé convient.

Deux détails déterminent si cela fonctionne du premier coup.

Le chemin de version doit figurer dans l'URL de base. La documentation de Jan présente cela comme l'erreur courante, avec ces mots : saisir http://localhost:8000 au lieu de http://localhost:8000/v1, ce qui produit une 404 à chaque requête. Pour un fournisseur au format OpenAI destiné à Kunavo, cela signifie https://api.kunavo.com/v1.

Pour le format Anthropic, la documentation de Jan ne donne pas de règle — elle indique d'utiliser la base documentée par votre passerelle, et son seul exemple est une instance locale de LiteLLM. Le code source de Jan permet de résoudre la question : le chemin Anthropic repose sur le fournisseur Anthropic du SDK Vercel AI, dont l'URL de requête est construite comme {baseURL}/messages avec un en-tête x-api-key, et dont la base par défaut comporte le préfixe de version. Ainsi, la même https://api.kunavo.com/v1 est la valeur à saisir, ce qui envoie la requête vers /v1/messages. Il s'agit d'une lecture de deux bases de code plutôt que d'un test ; considérez donc cette valeur comme celle à essayer en premier — consultez la note non testée à la fin de cette page.

Cette distinction piège les utilisateurs, car les instructions de Kunavo concernant ANTHROPIC_BASE_URL indiquent l'inverse pour une autre famille de clients : les SDK Anthropic officiels et Claude Code ajoutent eux-mêmes /v1/messages, donc ils prennent l'origine nue et l'ajout de /v1 produit /v1/v1/messages et une 404. Le fournisseur au format Anthropic de Jan ne fait pas partie de ces clients. Si vous voyez une 404, le chemin doublé dans l'erreur indique la convention utilisée. L'endpoint Messages de Kunavo accepte également l'en-tête Anthropic x-api-key ainsi que Authorization: Bearer, et l'endpoint chat completions couvre la route au format OpenAI.

Découverte des modèles et capacités. Lors de l'enregistrement, Jan tente de récupérer les modèles disponibles depuis {base_url}/models ; si cela échoue, vous saisissez exactement l'identifiant du modèle attendu par votre serveur. Kunavo fournit une liste de modèles au même préfixe, donc la découverte devrait fonctionner sur la route au format OpenAI — mais la question de savoir si Jan l'interroge pour un fournisseur au format Anthropic n'est pas documentée ni testée ; soyez donc prêt à ajouter l'identifiant manuellement. Plus important encore : les capacités des fournisseurs personnalisés ne sont pas détectées. Jan indique qu'il ne peut pas déduire si un modèle prend en charge les outils, la vision ou l'audio, et vous demande d'ajouter chaque modèle manuellement et de configurer ses capacités modèle par modèle. Sa documentation MCP montre l'autre cas : pour un fournisseur intégré comme Anthropic, Jan lit automatiquement les capacités des modèles du fournisseur une fois la clé ajoutée, et l'entrée de dépannage de la page concernant « le modèle n'utilise pas les MCP que j'ai activés » consiste à vérifier que le modèle dispose des outils activés. Aucune des deux pages n'indique les valeurs par défaut d'un modèle personnalisé nouvellement ajouté ; vérifiez donc Model Capabilities avant de supposer que MCP est actif. C'est la principale différence pratique entre coller une clé dans le fournisseur Anthropic intégré et ajouter une passerelle comme fournisseur personnalisé.

L'application expose également un champ Base URL pour certains fournisseurs intégrés, ce qui permettrait de rediriger l'entrée Anthropic ou OpenAI intégrée vers une passerelle. Aucune page de documentation de Jan ne couvre ce point, et cette page n'a pas exécuté l'application pour le confirmer — considérez le flux Add Provider comme la voie prise en charge.

Jan Agent prend en charge les mêmes deux formats sous forme d'options

La documentation des fournisseurs Agent configure l'endpoint avec --provider, --api-key, --base-url, --model (répétable) et --api-type, ce dernier étant le protocole filaire, soit openai soit anthropic, avec OpenAI-compatible par défaut.

# Jan Agent is a preview build from a nightly channel.
# Re-check these flags against your own `jan config --help` before relying on them.
jan config set \
  --provider kunavo \
  --api-type anthropic \
  --base-url https://api.kunavo.com/v1 \
  --api-key sk-kn-... \
  --model claude-sonnet-4-6

Les paramètres sont enregistrés dans ~/.jan/config.toml, avec une surcharge par projet dans agent.toml sous [provider] et une surcharge éphémère via JAN_API_KEY. La priorité est documentée dans le code source lui-même, dans providers.rs : la configuration globale constitue la base, les paramètres de Desktop sont ajoutés comme source uniquement héritée qui ne l'écrase jamais, le fichier de projet remplace les deux, et les options CLI ainsi que les variables d'environnement ont priorité sur tout le reste. Les deux interfaces de Jan acceptent également plusieurs clés par fournisseur et réessaient avec la suivante, avec la même portée dans les deux cas : la page des endpoints personnalisés de Jan Desktop documente un repli uniquement pour les codes HTTP 401, 403 ou 429, les autres erreurs n'étant pas réessayées, et le code source d'Agent applique les mêmes trois statuts. Le message key rotation exhausted vient de Jan Desktop, et sa page de dépannage l'interprète comme l'échec de toutes les clés configurées avec 401 ou 403, et non d'une seule.

Si vous auditez vous-même le dépôt, vous rencontrerez ici un piège : un commentaire sur stream_openai_chat_completions dans core/agent/upstream.rs indique que api_type « is None for every caller today » et que l'agent a toujours utilisé OpenAI /chat/completions quelle que soit sa valeur. Ce commentaire décrit un seul utilitaire et est obsolète pour le reste : core/agent/loop.rs appelle resolve_api_type_for_model et construit un convertisseur à partir de celui-ci, et ce convertisseur réécrit la requête vers /messages avec x-api-key et un en-tête anthropic-version fixe (converters.rs). Ainsi, --api-type anthropic est bien pris en compte — et le propre commentaire du convertisseur indique que le base_url enregistré doit inclure le préfixe de version, raison pour laquelle l'extrait ci-dessus se termine par /v1.

En cas d'échec

Les trois premières lignes proviennent de la page de dépannage de Jan ; les deux dernières de la page des endpoints personnalisés. Les journaux de l'application se trouvent dans ~/Library/Application Support/Jan/data/logs/app.log sur macOS, %APPDATA%\Jan\data\logs\app.log sur Windows et ~/.local/share/Jan/data/logs/app.log sur Linux. La référence des erreurs de Kunavo couvre les mêmes codes d'état côté passerelle.

Budget cloud détaillé pour Jan

Ces chiffres sont une arithmétique illustrative des tokens, et non des coûts de tâches mesurés ni un plafond de facturation. La colonne chat suppose une journée dans Jan Desktop d'environ 40 tours, durant laquelle le fil grandissant est renvoyé à chaque fois — 240,000 tokens d'entrée et 20,000 tokens de sortie. La colonne agent suppose une session plus longue utilisant des outils avec 400,000 tokens d'entrée et 30,000 tokens de sortie. Ces deux décomptes sont les propres estimations de cette page, et non des chiffres publiés par Jan. Les deux supposent aucune lecture de cache, car la persistance de la mise en cache des prompts via un fournisseur personnalisé dans l'une ou l'autre interface de Jan n'a pas été vérifiée. Les tarifs sont les prix actuels du catalogue Kunavo par million de tokens.

Deux interprétations. Premièrement, l'écart entre le modèle le moins cher et le plus cher de ce tableau est d'environ 5.0x pour la même session supposée — une amplitude suffisante pour que le choix du modèle soit le levier à actionner en premier, et un argument en faveur d'une route permettant de changer de modèle sans ouvrir un nouveau compte. Deuxièmement, comparez honnêtement ces totaux à l'option locale : un modèle qui tient dans le tableau de RAM ci-dessus coûte $0 par requête, et Jan fournit le moteur nécessaire. Pour un utilisateur de Jan Desktop, la facture distante est un choix de capacité, et non un coût d'utilisation de l'application.

Projetez ces chiffres sur vos propres journées avant de considérer quoi que ce soit comme un budget. Le montant du catalogue Kunavo constitue un seuil de facturation plutôt qu'un plafond : lorsque le fournisseur amont communique son coût, la facture correspond au montant le plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Le rechargement minimum est de $10 en crédit prépayé — un minimum de financement, et non des frais de tâche ni un abonnement. Consultez les détails de facturation et l'optimisation des coûts d'IA pour appliquer la méthode mesurer puis choisir.

Quelle route l'emporte selon le cas

Si vous évaluez la ligne de la passerelle, l'annuaire des clients indique comment chaque client desktop et agent gère les URL de base et les formats filaires, et l'API compatible OpenAI couvre la convention suivie par le premier format de Jan.

Configuration et vérification de la première facture

Tout ce qui précède provient de la documentation et du code source publiés par Jan, ainsi que de la propre documentation de Kunavo. Kunavo n'a pas testé Jan Desktop ni Jan Agent en conditions réelles : aucune requête n'a été envoyée via l'une ou l'autre application pour cette page, donc rien ici ne signifie que l'appel d'outils, le streaming ou la découverte des modèles a réussi de bout en bout. Considérez les URL de base comme celles déduites des deux ensembles de documentation et confirmez-les vous-même sur une tâche limitée. Conservez une route fonctionnelle pendant vos essais, envoyez une petite requête, puis consultez le montant réellement enregistré par votre compte plutôt qu'une estimation figurant sur cette page. Créez un compte Kunavo lorsque vous serez prêt à approvisionner une clé.

Questions fréquentes

Revérifié le 21 septembre 2026 : l'URL de tarification (toujours en 404), le dépôt GitHub et sa dernière version (v0.8.4), la page d'accueil, la page Tokamak, les documentations des endpoints personnalisés, du serveur API, de la référence API, de MCP, de l'installation Mac, de l'installation Windows, du Hub et du dépannage, le guide de démarrage rapide et la documentation des fournisseurs d'Agent, la documentation des modèles propriétaires, les organisations Hugging Face, ainsi que les fichiers source des constantes des fournisseurs, du convertisseur, de l'amont de l'agent et de la boucle de l'agent. Les chiffres d'étoiles et de dernier push proviennent de l'API GitHub au 19 septembre 2026 et évoluent quotidiennement. Non vérifiés : les exigences système Linux, les conditions commerciales de Tokamak et le comportement de la mise en cache via un fournisseur personnalisé. Les tarifs des tokens Kunavo proviennent du catalogue actuel, et chaque montant en dollars ici est une arithmétique illustrative des tokens plutôt qu'un coût de tâche mesuré.