Modèle Jev expliqué : prix API, usages et accès immédiat

Mis à jour le 24 octobre 2026 : ajout de Jev 1.14, désormais servi comme jev-latest.

Le modèle Jev expliqué dans ce guide est le System One Model de TypeSafe AI. Il reçoit un state en texte ou JSON et des questions typées, puis renvoie des décisions typées au lieu de prose. Appelez-le avec model: "jev-latest", aujourd'hui Jev 1.14 : $0.042 par million de tokens d'entrée, sortie gratuite et 64K tokens par requête.

Jev devient ainsi intéressant pour la classification, l'affectation de tickets, le classement, la vérification et les guardrails. Cela n'en fait pas un substitut à un modèle de chat, un modèle de code, une calculatrice ou une règle métier déterministe.

Le modèle Jev expliqué en bref

L'orthographe officielle est Jev : ce n'est pas un acronyme J-E-V. TypeSafe indique avoir choisi ce nom en référence à l'économiste William Stanley Jevons. L'expression « System One » renvoie au Système 1, rapide et intuitif, décrit par Daniel Kahneman dans Thinking, Fast and Slow.

Quoi de neuf dans Jev 1.14 ?

Jev 1.14 (jev-1.14.0) est stable depuis le 14 octobre 2026, et jev-latest comme jev-preview pointent vers cette version. Le prix et les limites par défaut ne changent pas ; la nouveauté, ce sont deux fonctions expérimentales activées par requête.

Les deux se trouvent derrière des en-têtes que TypeSafe appelle « danger zone ». TypeSafe-Danger-Zone-Images: true active les images et le nouveau type de question Box, qui renvoie des coordonnées dans l'image. TypeSafe-Danger-Zone-Long-Context: true porte la fenêtre à 262K tokens par requête et par question. La valeur par défaut est désactivée : sans l'en-tête, rien ne change. L'annonce de TypeSafe (consultée le 24 octobre 2026) demande de les utiliser à vos risques. Nous n'avons pas encore testé ces deux en-têtes via OmniaKey.

Les requêtes qui fixent jev-1.13.0 continuent de fonctionner, et le corps par défaut ne change pas : state, questions et un model facultatif. Revenir en arrière coûte une ligne : testez donc d'abord vos vraies tâches sur 1.14, puis basculez le trafic de production.

Que fait réellement Jev ?

On peut voir Jev comme une fonction sémantique probabiliste :

état structuré ou non structuré
  + questions et espaces de réponse prédéfinis
  -> décisions typées et distributions de probabilité

Un LLM classique est optimisé pour prolonger une séquence et générer des strings. Même avec JSON mode, l'application demande encore à un modèle génératif de composer une réponse. Jev renonce à la génération libre. L'appelant définit d'abord la forme de sortie possible, puis le modèle évalue chaque question à partir du même état.

TypeSafe appelle sa méthode d'entraînement Reinforcement Learning for Calibrated Decisions (RLCD). L'objectif n'est pas seulement de sélectionner une réponse, mais de produire des probabilités dont la confiance suit l'exactitude sur des groupes de prédictions. La calibration est statistique : une probabilité de 0.8 devrait correspondre à environ 80% de réponses correctes sur des cas comparables. Elle ne garantit pas qu'une réponse précise soit correcte.

Choice, Score et Noul

Jev expose trois types de questions. Ils forment le cœur de l'API et ne sont pas des options de formatage ajoutées après une génération.

Un Choice peut contenir jusqu'à 255 options. Un Score accepte de 2 à 10 niveaux décrits. Noul n'a pas de champ de confiance séparé, car sa valeur entre 0 et 1 représente déjà la probabilité d'un « oui ».

Plusieurs questions d'une même requête sont évaluées indépendamment et en parallèle sur le même état. C'est utile lorsqu'un workflow exige plusieurs signaux, mais une réponse ne conditionne donc pas automatiquement la suivante. Si la question B dépend de la question A, le code doit rendre cette dépendance explicite.

Exemple de requête à l'API Jev

Cet exemple abrégé envoie via OmniaKey le format documenté par TypeSafe. Un message adressé au support est évalué, en un seul appel, pour l'affectation, la frustration et l'urgence.

curl https://api.omniakey.com/v1/alpha/search \
  -H "Authorization: Bearer $OMNIAKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "My payouts have failed for three days and I am losing sales. Please help now.",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "Payments, invoices, or refunds",
          "technical": "Bugs, outages, or integrations",
          "sales": "Pricing, upgrades, or new accounts"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "How frustrated is the customer?",
        "criteria": ["Calm", "Frustrated", "Very angry"]
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "Does this message convey urgency?"
      }
    }
  }'

La réponse conserve les mêmes ID de questions. department renvoie l'un des trois strings autorisés, ainsi qu'une distribution sur les trois. frustration peut être décimal, car il correspond à la position pondérée par les probabilités entre les niveaux fournis. is_urgent renvoie uniquement la probabilité de « oui ».

Les valeurs exactes varient avec l'entrée, les criteria et la version du modèle. C'est votre code, et non le modèle, qui décide à partir de quelle probabilité une action doit être exécutée.

Jev face à un LLM et à un classifieur

Jev occupe une position intermédiaire utile, mais les différences sont importantes.

Qualifier Jev de « simple classifieur » occulte sa souplesse à chaque requête. Le qualifier de « LLM plus rapide » oublie qu'il ne peut ni expliquer, ni rédiger un e-mail, ni coder, ni inventer une réponse absente des options fournies. Les modèles d1 de Liquid AI prennent le même type de décisions bornées et sont aussi distribués en poids ouverts ; voir l'analyse de l'API Liquid AI d1.

JSON mode n'est pas la même chose non plus. Il limite la syntaxe du texte généré. Jev limite l'espace de réponse lui-même et renvoie toute la distribution utilisée pour décider. Cela n'a de valeur que si le problème peut être formulé en questions à options fermées.

Prix de l’API Jev

TypeSafe affiche Jev 1.14, comme 1.13, à $0.042 par million de tokens d'entrée, soit $42 par milliard. La sortie est gratuite car « trop peu coûteuse pour être mesurée », même si les réponses indiquent toujours le nombre de tokens de sortie.

Il s'agit d'exemples arithmétiques, pas de factures mesurées. Ils excluent les retries, le prétraitement, un autre modèle dans une cascade, le stockage, le travail d'ingénierie et toute future évolution tarifaire.

Fenêtre de contexte et quotas Jev

Le contexte impose deux limites simultanées : l'état et toutes les questions doivent tenir dans 64K tokens, tandis que l'état plus la question la plus longue doivent tenir dans 32K. Ajouter du contexte n'améliore pas forcément le résultat. Le propre guide de jaggedness de TypeSafe indique que les détails sans rapport font baisser la précision.

Les limites publiées de 250,000 tokens/s et 1,200 requêtes/minute sont des plafonds par compte, pas une promesse de vitesse par requête. TypeSafe précise qu'elles évoluent dynamiquement pendant l'early access.

Ce sont les limites TypeSafe en direct. Un compte OmniaKey peut avoir ses propres accès, tarifs et quotas. Requêtes complètes, réponses, Python/Node.js et erreurs sont détaillés dans le guide d’intégration de l’API Jev.

Que vaut la promesse de vitesse ?

TypeSafe annonce un temps de réponse de 70–500 ms de bout en bout et affirme que Jev peut être 40–200 fois plus rapide que les modèles frontier sur des requêtes « adaptées à System One », à intelligence comparable. Le lancement met aussi en avant une évaluation de workflow où Jev était 193.6 fois plus rapide et 444.6 fois moins cher.

Ces chiffres proviennent du fournisseur, pas d'un benchmark neutre. TypeSafe reconnaît plusieurs limites importantes :

1. Les mesures de latence publiées ont généralement été lancées depuis les ordinateurs de membres de l'entreprise sur la côte ouest des États-Unis, où se trouvait aussi le service.
2. Les tâches ont été conçues par l'équipe model-capabilities de TypeSafe, ce qui peut introduire un biais de sélection.
3. La réponse de référence faisait la moyenne de GPT-6 Astra et Fable 5.1, ce qui peut favoriser ces familles.
4. Les appels aux LLM concurrents passaient par OpenRouter et le wrapper structuré de TypeSafe.
5. TypeSafe présente lui-même les gains de 193.6x et 444.6x comme le haut de la fourchette attendue dans la réalité.

La conclusion raisonnable est plus étroite : les sorties contraintes et l'évaluation parallèle de Jev offrent une voie crédible vers une latence et un coût très faibles pour des décisions bornées. Ces chiffres ne prouvent pas que Jev soit 40–200 fois plus rapide sur toute tâche, égal à un LLM frontier en intelligence générale ou supérieur pour la génération et le raisonnement multiétape.

« Zéro hallucination » doit être défini précisément

TypeSafe présente Jev comme incapable d'halluciner. L'aspect défendable est la sécurité du schema : une réponse Choice ne peut pas inventer une quatrième option, et le service ne devrait pas renvoyer de prose là où le code attend un nombre. TypeSafe explique que cette conformité est garantie par construction, plutôt que mesurée comme un taux d'erreur nul.

Une réponse correctement typée peut néanmoins être sémantiquement fausse. La documentation de Jev 1.13 recense des défaillances liées à :

• une lecture trop littérale qui manque l'intention implicite ;
• un comptage, une arithmétique, des dates et une précision numérique peu fiables ;
• un raisonnement indirect à plusieurs sauts ;
• un état long contenant des détails sans rapport ;
• du contenu adversarial ou une prompt injection ;
• des instructions et criteria contradictoires ;
• des probabilités qui ne respectent pas les identités intuitives entre questions formulées séparément ;
• toute tâche nécessitant de générer du texte.

La formulation pratique est donc zéro génération hors schéma, pas zéro erreur de décision. Le code de production a toujours besoin de données d'évaluation, de seuils prudents, d'une validation déterministe et d'un chemin d'escalade.

Où Jev est pertinent

Jev est un bon candidat lorsque trois conditions sont réunies : l'espace de réponse est borné, le jugement est sémantique plutôt que mathématique, et un autre logiciel consommera le résultat.

Jev n'est pas un choix par défaut pour la rédaction, le résumé, la génération de code, l'extraction ouverte, l'arithmétique exacte, la comparaison de dates ou les longues chaînes causales. Utilisez du code classique pour la logique exacte et un modèle génératif ou de raisonnement lorsque la sortie doit être créée.

Checklist de mise en production

1. Gardez le travail déterministe dans le code. Analysez les dates, comptez, calculez les montants et appliquez les permissions sans modèle.
2. Posez des questions atomiques. Décomposez « Faut-il approuver cette demande ? » en faits indépendants dont dépend réellement la décision.
3. Décrivez chaque limite. Ajoutez other ou none si un Choice n'est pas exhaustif et décrivez précisément les niveaux de Score.
4. Testez sur votre propre distribution. L'anglais est la langue d'entraînement principale ; TypeSafe précise que les autres langues, notamment les écritures CJK, n'offrent pas les mêmes performances.
5. Calibrez les actions, pas seulement les prédictions. Une étape UI réversible et une automatisation à fort impact ne doivent pas partager le même seuil.
6. Épinglez une version après réglage. jev-latest peut évoluer. Journalisez l'ID versionné de la réponse et migrez les seuils volontairement.
7. Escaladez l'incertitude. Transférez les cas ambigus à une personne ou à un modèle de raisonnement plus lent au lieu de forcer une décision.
8. Mesurez le coût par tâche acceptée. Incluez retries, mauvaises décisions, contrôle humain et appels LLM en aval, pas seulement le prix des tokens.

Jev est-il disponible via OmniaKey ?

Oui. Jev est disponible via OmniaKey sous l'identifiant jev-latest. Cet ID pointe aujourd'hui vers Jev 1.14, et OmniaKey le transmet tel quel à TypeSafe : inutile de reconnecter quand une nouvelle version sort. Vous n'avez pas à demander l'early access TypeSafe ni à attendre une validation. Créez une clé dédiée dans le tableau de bord API Keys et utilisez-la immédiatement. La fiche du catalogue est sur la page du modèle Jev 1.14.

Envoyez le corps Jev natif à POST https://api.omniakey.com/v1/alpha/search. Il s'agit d'un endpoint Jev dédié et non d'un endpoint OpenAI Chat Completions : conservez donc la structure state et questions montrée ci-dessus. Le smoke test du 20 septembre a renvoyé HTTP 200, le modèle résolu jev-1.13.0, des answers typées et l'usage des tokens. La même requête résout maintenant jev-1.14.0. Pour le code ouvert et les Agents, le guide des modèles pour Agents de programmation présente les modèles génératifs d'une autre couche du stack.

Verdict final

Le modèle Jev expliqué ci-dessus se comprend mieux comme une nouvelle interface de décision sémantique que comme un remplacement universel des LLM. Son idée la plus forte est simple : confier le jugement flou au modèle, contraindre la sortie à un type compris par le programme, exposer l'incertitude et conserver la composition et la logique exacte dans le code.

L'API actuelle est inhabituellement peu chère sur le papier et son architecture vise une faible latence. Le modèle reste en early access, n'accepte que du texte par défaut, est meilleur en anglais et présente des faiblesses documentées en mathématiques, dates, raisonnement indirect, contexte non pertinent et entrées adversarial. Les comparaisons de vitesse et d'intelligence restent des affirmations du fournisseur tant qu'il n'existe pas de tests indépendants équivalents.

Questions fréquentes

Jev est-il un LLM ?

TypeSafe appelle Jev un System One Model plutôt qu'un LLM. Il comprend un état en langage naturel, mais ne génère pas de texte libre. Les sources examinées ne divulguent pas assez de détails d'architecture pour déterminer indépendamment à quel point son réseau sous-jacent ressemble à un modèle de langage classique.

Jev peut-il remplacer GPT ou Claude ?

Non. Jev ne peut pas rédiger, expliquer, programmer ni produire une génération ouverte. Il peut compléter un modèle génératif en orientant des requêtes, vérifiant des sorties, évaluant des réponses ou décidant quand lancer un modèle plus lent.

Que signifient Choice, Score et Noul ?

Choice sélectionne dans un ensemble fermé et renvoie les probabilités de toutes les options. Score place l'état sur 2 à 10 niveaux décrits. Noul renvoie la probabilité qu'une affirmation oui/non soit vraie.

Jev a-t-il vraiment zéro hallucination ?

Il ne peut pas générer une valeur hors du type de réponse déclaré, ce qui élimine de nombreuses erreurs de parsing et de schema. Il peut toujours choisir une option valide mais erronée ou attribuer une probabilité trompeuse. La sûreté de type n'est pas l'exactitude sémantique.

Comment accéder à l'API Jev sans liste d'attente ?

Créez une clé API OmniaKey, envoyez le corps Jev natif à POST https://api.omniakey.com/v1/alpha/search et définissez model sur jev-latest. Aucun compte TypeSafe séparé ni validation d'early access n'est nécessaire.

Combien coûte l'API Jev ?

TypeSafe affiche Jev 1.14 à $0.042 par million de tokens d'entrée, avec une sortie actuellement gratuite. Prix directs et rate limits peuvent changer pendant l'early access.

Quelle version est jev-latest aujourd'hui ?

Jev 1.14 (jev-1.14.0). jev-preview pointe aussi vers le même build pour l'instant. Pour figer, indiquez jev-1.13.0 ou jev-1.14.0 dans la requête.

Jev accepte-t-il les images ou le français ?

Il accepte du texte par défaut. Strings, objets JSON et tableaux doivent finalement contenir du texte. Jev 1.14 ajoute des images derrière l'en-tête TypeSafe-Danger-Zone-Images: true, que TypeSafe marque comme expérimental. Le français et les autres langues sont acceptés, mais TypeSafe indique que l'anglais est actuellement le plus performant et recommande d'évaluer les charges non anglophones avec vos propres données.

Jev est-il gratuit ?

Le tarif direct vérifié facture l’entrée $0.042 par million de tokens et rend la sortie gratuite. Une sortie gratuite ne rend pas la requête gratuite. Essais, crédits promotionnels et facturation d’une passerelle ont leurs conditions ; vérifiez l’offre de votre compte au lieu de supposer un quota gratuit universel.

Combien de paramètres possède Jev ?

La page officielle de TypeSafe (consultée le 24 octobre 2026) décrit le contexte et les formats d’entrée, mais ne donne pas de nombre de paramètres. 64K et 32K sont des limites de tokens, pas des paramètres du modèle. Elles ne permettent pas de déduire la taille des poids ou le matériel nécessaire en local.

Sources primaires

• TypeSafe : Jev 1.14 release (anglais) (consultée le 24 octobre 2026)
• TypeSafe : Introducing System One Models & Jev (anglais)
• Documentation TypeSafe : Introduction (anglais)
• Documentation TypeSafe : System One (anglais)
• Documentation TypeSafe : Models and pricing (anglais) (consultée le 24 octobre 2026)
• Documentation TypeSafe : HTTP API reference (anglais)
• Documentation TypeSafe : Confidence (anglais)
• Documentation TypeSafe : Jev 1.13 jaggedness (anglais)

Prix, quotas et détails de Jev 1.14 revérifiés le 24 octobre 2026. Le test antérieur du gateway reste daté du 20 septembre ; cette mise à jour ne constitue pas un nouveau test payant. Jev évolue vite : revérifiez la version et les conditions du compte avant la production.