Qu'est-ce que Jev ? Le modèle System One de TypeSafe expliqué

TL;DR

Jev est un modèle de décision développé par TypeSafe AI. TypeSafe a présenté Jev le 15 septembre 2026 comme son premier modèle System One, conçu pour renvoyer des décisions structurées et des probabilités que les logiciels peuvent utiliser directement. Ce guide s’appuie principalement sur la documentation officielle de TypeSafe, le guide Quick Start, la référence du modèle et l’annonce officielle de Jev.

Jev n’écrit pas de prose, ne génère pas de code et ne tient pas de conversation. Il évalue un état textuel par rapport à des questions typées et renvoie des réponses structurées qu’une application peut utiliser directement.

La distinction est importante pour les workflows logiciels. Un modèle de langage conventionnel produit des jetons, même lorsqu’une application n’a besoin que d’une catégorie, d’un score ou d’un jugement oui/non. Jev est conçu autour de la décision elle‑même. Son interface accepte un état et une ou plusieurs questions, puis renvoie des valeurs typées et des distributions de probabilités. Les réponses Choice et Score incluent également une valeur de confiance.

Jev est destiné à la classification, au routage, à la notation, à la vérification, aux garde‑fous et à d’autres décisions bornées. Ce n’est pas un remplacement général de GPT, Claude, Gemini ou d’autres modèles génératifs. Dans un agent IA, un modèle génératif peut planifier ou créer du contenu tandis que Jev gère les décisions fréquentes comme sélectionner une route, vérifier un risque ou décider si un résultat nécessite une revue.

Points clés

• Jev est développé par TypeSafe et est actuellement présenté comme son modèle System One phare.
• Le modèle accepte un état basé sur du texte plus des questions typées. Il renvoie des décisions structurées plutôt que de la prose générée.
• Jev prend en charge trois types de questions nommés Choice, Score et Noul.
• Plusieurs questions peuvent être évaluées indépendamment et en parallèle contre le même état dans une seule requête.
• TypeSafe entraîne Jev avec le Reinforcement Learning for Calibrated Decisions, ou RLCD.
• La page officielle actuelle du modèle liste Jev 1.13 avec une limite de 64 000 jetons par requête et une entrée texte uniquement.
• La tarification officielle est de 0,042 $ par million de jetons d’entrée. Les jetons de sortie sont indiqués comme gratuits.
• Une sortie type‑safe évite les divergences de schéma. Elle ne garantit pas que chaque décision métier soit correcte.
• TypeSafe rapporte une latence de 70 à 500 millisecondes et de forts gains sur ses propres évaluations de workflow. Ces chiffres sont fournis par le vendeur et s’appliquent aux tâches de forme System One.

Qu’est‑ce que Jev ?

Jev est un modèle de décision conçu par TypeSafe AI. La documentation officielle le décrit comme le modèle phare de l’entreprise et son premier modèle System One. Son entrée comporte deux parties principales.

La première partie est l’état. L’état est l’information que Jev doit examiner, comme un message client, un rapport d’incident, un ensemble d’enregistrements ou un objet JSON contenant le contexte de l’application.

La seconde partie est un ensemble de questions typées. Chaque question définit le jugement à porter et la forme autorisée de la réponse. Jev évalue les questions par rapport à l’état et renvoie des résultats sur lesquels le code peut bifurquer, trier, noter ou router.

Considérez une demande d’assistance signalant qu’une intégration de paiement a échoué depuis trois jours. Un système de support n’a peut‑être pas besoin d’un paragraphe décrivant la situation. Il peut avoir besoin de trois décisions étroites :

• Quelle équipe doit recevoir le ticket ?
• À quel point le client semble‑t‑il frustré ?
• Le message nécessite‑t‑il une attention urgente ?

Jev peut représenter ces besoins sous la forme d’une question Choice, d’une question Score et d’une question Noul dans une seule requête. La réponse contient la catégorie ou le score sélectionné, la distribution de probabilités pertinente et la confiance lorsque cela est pris en charge. L’application décide ensuite quoi faire de ces valeurs.

Cette répartition des responsabilités est volontaire. Le modèle fournit un jugement incertain dans un format stable. Le code applicatif conserve le contrôle sur les seuils, les permissions, les effets de bord et les comportements de repli.

Qu’est‑ce qu’un modèle System One ?

TypeSafe utilise l’expression modèle System One pour une classe de modèles conçus pour prendre des décisions rapides et structurées que les logiciels peuvent consommer. Le nom s’appuie sur la distinction entre pensée rapide et pensée lente associée aux travaux de Daniel Kahneman. Il décrit le rôle prévu du modèle, et non l’affirmation qu’un modèle logiciel reproduit la cognition humaine.

Une tâche System One a un objectif contraint. Un examinateur averti devrait pouvoir porter le jugement rapidement lorsqu’un contexte adéquat est fourni. Exemples : choisir une intention, noter l’urgence sur une échelle définie, vérifier si une affirmation est étayée ou décider si une demande doit être escaladée.

Les tâches qui nécessitent des recherches approfondies, une déduction multi‑étapes, des explications longues ou de la création de contenu ne sont pas naturellement adaptées. TypeSafe recommande de décomposer les jugements larges en questions atomiques et de combiner leurs résultats dans le code.

Par exemple, « évaluer ce pitch de startup » est trop vaste pour produire une décision inspectable. La taille du marché, la faisabilité technique et la différenciation peuvent être évaluées comme des questions séparées. L’application peut ensuite combiner ces scores avec une formule explicite. Si les priorités métier changent, les pondérations peuvent évoluer dans le code sans transformer le prompt du modèle en logique métier cachée.

Comment fonctionne Jev ?

Le contrat de fonctionnement de Jev peut s’écrire :

État + questions typées -> décisions typées + probabilités

Cela diffère du flux habituel d’un modèle de langage :

Prompt -> jetons générés -> parsing et validation -> décision de l’application

La distinction ne porte pas seulement sur un format de réponse différent. Une sortie structurée traditionnelle demande encore à un modèle génératif de produire une séquence de jetons conforme à un schéma. Jev est conçu pour renvoyer des valeurs provenant d’espaces de réponse définis à l’avance.

L’API actuelle accepte l’état sous forme de chaîne, d’objet JSON ou de tableau de valeurs textuelles. L’entrée est uniquement du texte. Les images, l’audio, la vidéo et les documents binaires doivent être convertis en texte ou en champs structurés avant soumission.

Chaque question d’une requête est évaluée indépendamment par rapport au même état. Selon la documentation de TypeSafe, ajouter des questions change à peine le temps de réponse car les questions sont évaluées en parallèle. L’indépendance empêche également la réponse d’une question de devenir le contexte d’une autre question dans le même appel.

Ce comportement a une conséquence importante de conception. Si une décision dépend réellement d’une autre, la dépendance appartient au workflow applicatif. Exécutez la première évaluation, mettez à jour l’état ou bifurquez dans le code, puis procédez à la suivante. Une requête unique convient mieux à des questions qui partagent des preuves sans dépendre des réponses des autres.

Les trois types de questions de Jev

Choice

Une question Choice sélectionne une option selon des critères définis par l’application. Un workflow de support peut fournir billing, technical et sales, avec une description pour chaque catégorie. Jev renvoie l’option sélectionnée, la probabilité associée à chaque option et une valeur de confiance dérivée de la forme de cette distribution.

La conception des catégories affecte l’utilité du résultat. Des options qui se chevauchent créent de l’ambiguïté. Des options manquantes poussent le modèle vers une réponse qui peut ne pas convenir. Les taxonomies en production devraient inclure une route comme insufficient_evidence ou human_review lorsque le workflow doit préserver l’incertitude.

Le libellé doit également correspondre à la décision réelle. « Quelle équipe doit enquêter en premier » demande une route provisoire. « Quelle équipe a causé la panne » demande un diagnostic. Elles peuvent utiliser la même liste d’équipes, mais elles ne posent pas la même question.

Score

Une question Score place l’état sur un barème ordonné. Les critères peuvent décrire des niveaux tels que calme, frustré et en colère, ou définir une échelle métier plus détaillée. La réponse inclut un score numérique, une légende liant les nombres aux niveaux, une distribution de probabilités sur ces niveaux et la confiance.

Un barème Score utile décrit des différences observables. Des libellés sans définitions laissent le modèle et les examinateurs humains inférer des standards différents. Une échelle de risque devrait indiquer ce qui sépare chaque niveau. Une échelle de qualité devrait préciser quelles exigences sont présentes ou absentes.

Si un score mélange des préoccupations indépendantes, il vaut mieux les scinder. Pertinence, appui factuel, ton et conformité aux politiques peuvent être des questions séparées. Le code applicatif peut calculer un score composite à l’aide de pondérations qui restent visibles et testables.

Noul

Noul est le primitif de décision binaire de TypeSafe. Il estime la probabilité qu’une affirmation soit vraie et renvoie un nombre de 0 à 1. Une valeur de 0,9 représente une probabilité estimée plus élevée de vérité qu’une valeur de 0,6.

Noul ne renvoie pas le champ distinct confidence utilisé par Choice et Score. Sa sortie est déjà une probabilité pour l’affirmation évaluée. La question doit donc être formulée comme une affirmation testable, par exemple « le message véhicule de l’urgence » ou « la réponse est étayée par la source fournie ».

Noul est utile pour la vérification et le gating, mais le seuil appartient à l’application. Une suggestion d’interface à faible risque peut tolérer un seuil plus bas qu’une action financière ou administrative irréversible.

Questions atomiques et workflows composés

Jev fonctionne mieux lorsque chaque question ne demande qu’une chose précise. Cette conception rend la sortie plus facile à inspecter et permet au logiciel de détenir la politique finale.

Supposons qu’un agent doive décider d’exécuter un appel d’outil. Une question large telle que « faut‑il exécuter cette action » peut combiner permission, réversibilité, sensibilité des données, intention de l’utilisateur et risque opérationnel. Un workflow plus inspectable évalue ces dimensions séparément :

• L’appel d’outil est‑il cohérent avec la demande de l’utilisateur ?
• Transmet‑il des informations sensibles ?
• L’action est‑elle destructrice ou difficile à annuler ?
• Affecte‑t‑elle un compte externe ?
• Une confirmation supplémentaire est‑elle requise par la politique ?

Le harnais peut ensuite combiner les réponses avec des règles déterministes. Une opération destructrice peut exiger une confirmation quel que soit le niveau de confiance global du modèle. Une opération en lecture seule peut suivre un chemin moins restrictif. Cette organisation conserve les permissions dans le code et utilise Jev uniquement pour des jugements qui ne peuvent pas s’exprimer de manière fiable sous forme de règles fixes.

Jev vs LLM traditionnels

Jev et les grands modèles de langage servent des rôles différents.

Jev ne doit pas être décrit comme un chatbot plus petit. TypeSafe n’a pas publié de nombre de paramètres ni assez de détails d’architecture pour classer le modèle par taille. Sa distinction publique repose sur son objectif d’entraînement, sa méthode d’échantillonnage et son interface.

Jev ne remplace pas non plus le code déterministe. Les règles fixes restent l’outil approprié lorsque les conditions sont explicites et stables. Un calcul de taxes, une liste de permissions ou une limite de taille de fichier ne doivent pas devenir un appel à un modèle probabiliste. Jev est utile là où des règles écrites à la main sont trop fragiles mais où la réponse souhaitée peut encore être bornée.

Jev vs sorties structurées de LLM

La sortie structurée permet à un modèle de langage de renvoyer du JSON ou des valeurs conformes à un schéma. Elle est utile lorsqu’un workflow a besoin à la fois d’un raisonnement génératif et d’un résultat lisible par machine. Jev traite un problème plus étroit.

Avec un LLM, le schéma contraint la forme d’une réponse générée. Avec Jev, les questions et les espaces de réponse sont l’interface du modèle. Jev renvoie des distributions de probabilités destinées à participer à la logique applicative, et des questions indépendantes sont évaluées séparément contre un état partagé.

Des formes JSON identiques n’impliquent pas des comportements identiques. Deux systèmes peuvent tous deux renvoyer un champ nommé department, tout en différant en latence, calibration, gestion de l’ambiguïté et stabilité de la réponse. Les équipes comparant Jev à une sortie structurée de LLM devraient conserver le schéma applicatif constant et tester les deux systèmes sur les mêmes données labellisées.

RLCD et décisions calibrées

TypeSafe indique que Jev est entraîné avec le Reinforcement Learning for Calibrated Decisions. Le RLCD diffère par son objectif du RLHF et du RLVR.

Le RLHF optimise les réponses à l’aide de signaux de préférence humaine et a été largement utilisé pour des assistants conversationnels. Le RLVR utilise des récompenses vérifiables et s’associe à des tâches dont la correction peut être vérifiée de manière programmatique. Le RLCD entraîne les modèles de TypeSafe à renvoyer des décisions et des probabilités calibrées plutôt que du texte généré.

La calibration concerne des groupes de prédictions. Si un modèle est bien calibré, des résultats auxquels est assignée une probabilité proche de 0,8 devraient être corrects environ 80 % du temps sur un ensemble de cas approprié. Cela ne garantit pas qu’une prédiction particulière avec une probabilité de 0,8 soit correcte.

La probabilité et la confiance ne doivent pas être considérées comme interchangeables. Choice et Score exposent des distributions de probabilités complètes. TypeSafe déduit la confiance de la forme de chaque distribution. Une distribution concentrée sur une option produit une confiance plus élevée ; une distribution plus plate signale de l’ambiguïté. Les équipes peuvent utiliser la confiance fournie ou calculer une autre statistique à partir des probabilités.

Noul n’a pas de champ de confiance séparé. Sa valeur est la probabilité estimée que l’affirmation soit vraie.

Spécifications du modèle Jev et tarification

Les détails suivants proviennent de la documentation officielle du modèle TypeSafe, consultée le 21 septembre 2026.

TypeSafe note que les limites de débit s’ajustent dynamiquement et peuvent changer sans préavis. Les limites et les prix actuels doivent être vérifiés avant un déploiement en production.

La documentation indique également que l’anglais est la langue principale d’entraînement et fournit actuellement la meilleure précision. D’autres langues, y compris les écritures CJK, sont prises en charge mais pas aussi bien. Une charge de travail en chinois, japonais ou coréen doit être évaluée sur des données représentatives avant d’activer des décisions automatisées.

TypeSafe indique que Jev n’est pas affiné ni adapté par LoRA avec les données de chaque client. Les mêmes poids de modèle servent chaque compte. Le comportement de domaine se façonne via l’état, les instructions, les critères et la composition côté application. L’entreprise indique également que les requêtes et réponses des clients ne sont pas utilisées pour entraîner Jev. Les clients Enterprise peuvent consulter la documentation juridique de TypeSafe pour des conditions de rétention zéro.

Quelle est la rapidité de Jev ?

TypeSafe rapporte des temps de réponse de bout en bout entre 70 et 500 millisecondes. Son billet de lancement compare cette plage à 3 à 329 secondes pour des appels sélectionnés à des modèles de pointe et décrit Jev comme 40 à 200 fois plus rapide à des niveaux d’intelligence comparables sur des requêtes de forme System One.

La société rapporte également des gains de pointe de 193,6 fois en vitesse et 444,6 fois en coût sur ses évaluations de workflow. Ces chiffres nécessitent du contexte.

Ils proviennent du propre cadre d’évaluation de TypeSafe. Les workflows comparent des modèles sur des graphes de décisions structurés et utilisent les prédictions moyennes de modèles externes haut de gamme sélectionnés comme probabilités de référence. TypeSafe indique que les gains rapportés sont probablement proches de l’extrémité haute des améliorations réelles et reconnaît un biais possible parce que des membres de son équipe de capacités du modèle ont créé les workflows.

Ces résultats ne doivent pas être interprétés comme une affirmation générale selon laquelle Jev est des centaines de fois plus rapide que chaque LLM sur chaque tâche. Jev abandonne la génération de texte et cible des décisions bornées. Une comparaison équitable devrait utiliser des tâches que les deux systèmes peuvent réaliser, mesurer la qualité de la décision ainsi que la latence et inclure le coût de la validation, des retries et de la revue humaine.

Pour quoi Jev est le mieux adapté

Jev convient le mieux aux workflows à fort volume avec un espace de réponse défini et un besoin d’estimations d’incertitude.

• Triage du support client : Classer un ticket par département, urgence, frustration, risque de churn ou besoin d’une revue humaine.
• Routage d’intention et de modèle : Identifier le type de demande et le router vers l’outil, le workflow, l’agent ou le modèle approprié. La confiance peut déterminer si le routage est automatique.
• Contrôles de risque des outils d’agent : Évaluer des appels d’outils proposés pour des actions destructrices, des données sensibles ou une incohérence avec la demande de l’utilisateur avant exécution. Le code applicatif reste responsable des permissions.
• Évaluation de sortie LLM : Vérifier si une réponse de LLM est étayée par le contexte fourni, respecte le format requis ou nécessite une revue humaine.
• Modération de contenu : Utiliser Choice pour les catégories de politique, Score pour la sévérité et Noul pour les contrôles binaires de règles. Les cas à faible confiance peuvent être envoyés aux modérateurs.
• Traitement de données à haut volume : Traiter des logs, e‑mails, avis, leads, publicités ou segments de documents lorsque chaque enregistrement peut être évalué indépendamment et que la sortie est une catégorie, un score ou une probabilité.

Place de Jev dans un agent IA

Un agent IA combine généralement un modèle génératif, des outils, l’état de l’application et des règles qui contrôlent l’exécution. Jev s’insère dans ce système comme une couche de décision structurée autour du modèle génératif principal.

Le modèle génératif peut gérer des tâches ouvertes telles qu’interpréter une demande, planifier un workflow, écrire du contenu ou générer du code. Jev peut gérer des décisions plus étroites qui doivent se produire à répétition au cours du workflow :

• Quel outil ou modèle doit être utilisé ?
• L’action proposée est‑elle risquée ou incohérente avec la demande ?
• L’agent doit‑il continuer, retenter, s’arrêter ou demander une clarification ?
• Le résultat répond‑il à une exigence définie ?
• La tâche doit‑elle être escaladée vers un humain ?

L’application reste responsable des permissions, des seuils et des effets de bord. Jev fournit une décision et sa probabilité associée, tandis que le code applicatif détermine l’action qui suit.

Cela crée une division des responsabilités. Les modèles génératifs gèrent le raisonnement ouvert, Jev gère des évaluations bornées, le code déterministe applique la politique et les outils réalisent des actions externes. Jev fonctionne donc comme un complément à un agent IA plutôt que comme un remplacement de son modèle principal de raisonnement.

Limites de Jev

Jev ne génère pas de prose, de code ni d’explications ouvertes. Il est conçu pour des questions ciblées avec des espaces de réponse définis.

Une réponse type‑safe peut toujours contenir une décision incorrecte, donc la précision métier doit être évaluée avec des données réelles. Le texte est actuellement le format d’entrée pris en charge, et l’anglais offre les performances documentées les plus solides. D’autres langues requièrent des tests séparés.

La vitesse et le coût de Jev proviennent des évaluations propres à TypeSafe et ne doivent pas être traités comme des garanties de performance universelles.

Jev et CometAPI

Au moment de la revue le 21 septembre 2026, Jev n’était pas listé comme modèle généralement disponible dans le catalogue public de CometAPI. CometAPI prévoit d’évaluer et d’intégrer Jev une fois l’accès disponible et la connexion requise ouverte. Les développeurs doivent vérifier le répertoire des modèles CometAPI pour la disponibilité la plus récente.

Jev est actuellement accessible via la console TypeSafe et son API officielle. TypeSafe fournit également des SDK officiels Python et JavaScript. L’API actuelle utilise state et des questions typées, avec jev-latest comme alias stable du modèle.

Une fois Jev disponible via CometAPI, les développeurs pourront trouver son ID de modèle, l’endpoint pris en charge, la tarification et le format de requête dans la documentation API de CometAPI et le répertoire des modèles.

Foire aux questions

Qu’est‑ce que Jev AI ?

Jev est le modèle phare de TypeSafe et son premier modèle System One. Il évalue un état textuel par rapport à des questions typées et renvoie des décisions structurées et des probabilités au lieu de texte généré.

Jev est‑il un grand modèle de langage ?

TypeSafe ne présente pas Jev comme un LLM traditionnel. Il qualifie Jev de modèle System One conçu pour des décisions structurées. L’entreprise n’a pas publié son nombre de paramètres, donc le modèle ne doit pas être classé comme grand ou petit sur la base des informations publiques.

Que sont Choice, Score et Noul ?

Choice sélectionne une option parmi un ensemble défini et renvoie des probabilités plus la confiance. Score note l’état sur un barème ordonné et renvoie également des probabilités plus la confiance. Noul renvoie une valeur de 0 à 1 représentant la probabilité qu’une affirmation soit vraie.

Jev génère‑t‑il du texte ou du code ?

Non. Jev renvoie des décisions contraintes. Un modèle génératif est nécessaire lorsqu’un workflow a besoin de prose, de dialogue, de code source ou d’une explication ouverte.

Jev peut‑il remplacer GPT, Claude ou Gemini ?

Non. Jev traite des tâches de décision bornées, tandis que les LLM généralistes gèrent la génération et le raisonnement étendu. Un système de production peut utiliser les deux types de modèles pour différentes étapes d’un même workflow.

Jev prend‑il en charge les images, l’audio ou la vidéo ?

Pas directement. Le modèle actuel accepte le texte sous forme de chaîne, d’objet JSON ou de tableau de valeurs textuelles. Les entrées non textuelles doivent d’abord être converties en texte ou en champs structurés.

Une sortie type‑safe garantit‑elle une décision correcte ?

Non. La sécurité de types garantit que la sortie est conforme à la structure prise en charge. Jev peut toujours choisir la mauvaise option valide ou attribuer une probabilité inexacte. La précision métier doit être mesurée avec des données représentatives.

Jev est‑il open source ?

TypeSafe n’a pas publiquement publié les poids du modèle Jev. L’entreprise publie de la documentation, des SDK, des exemples et du code d’intégration associé, mais ces ressources ne rendent pas le modèle lui‑même open weight.

Conclusion

Jev introduit une interface de modèle construite autour des décisions plutôt que de la génération de langage. Il accepte un état partagé et des questions atomiques, typées, puis renvoie des catégories, des scores, des probabilités binaires et des mesures d’incertitude que les logiciels peuvent utiliser directement.

Son rôle le plus crédible n’est pas de remplacer les LLM généralistes. Il consiste à gérer des jugements fréquents et bornés autour d’eux. Le routage du support client, la sélection de modèle, les contrôles de risque des outils, la vérification de sorties, la modération et la classification de workflows s’inscrivent tous dans ce schéma lorsque l’espace de réponse est défini à l’avance.

La valeur en production dépend de plus que d’une faible latence ou d’un schéma valide. Les équipes ont besoin d’évaluations représentatives, de seuils calibrés, de règles de permission explicites, de contrôles de version de modèle et de chemins de revue humaine. Les chiffres publiés par TypeSafe sur la vitesse et le coût rendent Jev intéressant à tester pour des charges de travail riches en décisions, mais les affirmations restent liées à la méthode d’évaluation de l’entreprise et doivent être vérifiées sur des données applicatives réelles.

Pour des équipes utilisant déjà plusieurs modèles génératifs via CometAPI, Jev illustre une architecture plus large dans laquelle la génération, le jugement probabiliste, la politique déterministe et l’exécution d’outils sont des composants distincts. Cette séparation rend chaque partie plus facile à tester et donne au code applicatif le contrôle final sur ce qui se passe ensuite.