Jev 1.13 expliqué : pourquoi le modèle répond en étiquettes plutôt qu'en phrases

Jev 1.13 (typesafe/jev-1.13) n'est pas un modèle de chat, et le moyen le plus rapide de le comprendre est d'arrêter de lire sa fiche technique comme vous lisez toutes les autres. TypeSafe l'a publié le 2026-09-15 comme premier membre d'une classe que l'entreprise appelle les modèles System One : vous lui confiez un morceau d'état et un ensemble de questions nommées, et il vous renvoie une réponse typée par question — un libellé issu d'une liste que vous avez fournie, un niveau sur une échelle que vous avez définie, ou un vrai/faux assorti d'une probabilité. Pas de prose, pas de code, pas d'explication. Ce n'est pas un article de lancement. Le modèle lui-même date du 2026-09-15, il a quinze jours et se situe hors de la fenêtre de sept jours couverte par ce blog, il ne mérite donc pas une page pour sa propre sortie. Ce qui s'est passé dans cette fenêtre, c'est qu'OrcaRouter a ajouté typesafe/jev-1.13 à son propre catalogue le 2026-09-24 et a ouvert la fiche modèle Jev 1.13 à l'adresse https://www.orcarouter.ai/models/typesafe/jev-1.13 — la première fois que Jev peut être appelé via une passerelle tierce plutôt que uniquement via le point de terminaison propre à TypeSafe, et les premières données de service en direct que quiconque en dehors de TypeSafe ait publiées à son sujet. Voilà le changement qui vaut la peine d'être lu : le modèle est devenu exécutable là où il ne l'était pas.

La forme concrète de ce changement est modeste et précise. Avant le 2026-09-24, adopter Jev impliquait une seconde relation fournisseur — un compte TypeSafe, une clé TypeSafe, une facture TypeSafe et une forme de requête sur mesure à implémenter. Après cette date, Jev repose sur la même clé que le reste d'une stack : une seule API pour 200+ modèles, 0 % de marge (le prix catalogue du fournisseur est répercuté, de sorte que les baisses de prix des fournisseurs sont effectives ici le jour même), et le modèle accessible à typesafe/jev-1.13 sur POST /v1/systemone. Vous l'appelez toujours dans sa propre forme — le point de terminaison n'est pas la route chat-completions d'OpenAI, et prétendre le contraire produirait un 404 plutôt qu'une décision — mais le contrat que vous signez et la clé que vous renouvelez sont ceux que vous avez déjà.

Quel genre de modèle est Jev ?

L'article de lancement de TypeSafe le formule en une phrase : « Notre premier modèle public est Jev, disponible dès aujourd'hui en accès anticipé. » L'article présente ensuite le modèle comme « un appel de fonction d'intelligence de pointe : un état non structuré en entrée, des décisions probabilistes typées en sortie. » C'est une description juste de l'interface, et une description importante, car presque toutes les attentes erronées concernant Jev viennent du fait qu'on l'évalue comme un petit modèle de langage. Ce n'est pas un petit modèle de langage. C'est un modèle de décision doté d'une grammaire de sortie fixe, et cette grammaire est le produit.

L'interface a exactement deux entrées. L'état est la matière à juger : un e-mail, un ticket d'assistance, une ligne de journal, un enregistrement JSON, un tableau de coordonnées de jeu. Les questions sont une carte d'éléments nommés, chacun portant un type, ses propres instructions et — pour les deux types structurés — ses critères. Chaque question est évaluée par rapport à ce même état, et les réponses reviennent sous la forme d'une seule charge utile JSON structurée. La documentation de TypeSafe décrit les questions comme s'exécutant simultanément et indépendamment, et avance deux affirmations qui découlent de cette conception plutôt que d'un réglage : l'ajout de questions ne modifie presque pas le temps de réponse, et l'ajout de questions ne crée pas de pourrissement du contexte, parce que chaque question est jugée isolément plutôt qu'en aval des précédentes.

Les propres conseils de conception de TypeSafe méritent d'être répétés car ils constituent l'énoncé le plus clair de la finalité du modèle. Gardez chaque question atomique et bien délimitée — « le type de jugement qu'une personne très compétente pourrait porter en quelques secondes ». Si une décision nécessite un raisonnement prolongé ou combine véritablement plusieurs facteurs indépendants, divisez-la en questions distinctes et recombinez-les dans votre propre code. Leur exemple : au lieu d'un seul prompt « évaluez ce pitch de startup », interrogez séparément la taille du marché, la faisabilité technique et la différenciation, puis appliquez votre propre pondération. La raison pour laquelle cela compte, c'est que la pondération réside alors dans un coefficient que vous pouvez modifier, plutôt que dans un prompt que vous devez réécrire.

Le modèle est fermé dans tous les sens qui comptent pour un ingénieur raisonnant sur le risque. L’architecture, le nombre de paramètres, le calcul d’entraînement et les poids de Jev ne sont pas publiés. Il n’existe aucun dépôt de poids sur l’organisation GitHub TypeSafe — les onze dépôts publics qui s’y trouvent sont des outils, des SDK, des workflows et trois forks sans rapport, et aucun d’entre eux n’est le modèle.

« Typed » est le produit tout entier

La fiche modèle d'OrcaRouter publie les trois primitives et, surtout, les limites de chacune. Chaque question que vous posez à Jev correspond à exactement l'une de trois formes :

• noul — un jugement vrai/faux, renvoyé avec une probabilité calibrée plutôt qu’un simple booléen, de sorte que « probablement vrai » et « certainement vrai » soient des valeurs distinguables.

• choice — choisissez l'une des options étiquetées (255 au maximum), chaque option comportant son propre texte de critères afin que le modèle sache ce qui distingue vos étiquettes.

• score — évaluer sur une échelle ordonnée de 2–10 niveaux, les définitions des niveaux étant fournies comme critères.

La conséquence en est qu’il n’y a rien à extraire de la prose et rien à valider par rapport à un schéma dont vous espériez que le modèle l’ait suivi. Le billet de lancement de TypeSafe est d’une franchise inhabituelle au sujet de la garantie : le « chiffre de 0 % de non-concordance de schéma dans ses » « n’est pas empirique. La concordance de schéma est garantie, donc nous pouvons ajouter en toute confiance 0 % dans les graphiques. » Lorsque votre espace de réponses est un ensemble fermé que vous avez fourni, une valeur renvoyée soit appartient à l’ensemble, soit ne provient pas du modèle — il n’existe pas de troisième issue où le modèle aurait écrit quelque chose de plausible sous une mauvaise forme et où votre expression régulière l’aurait discrètement accepté.

Les trois types sont aussi la raison pour laquelle un évaluateur ne peut pas évaluer Jev comme il évaluerait un modèle de chat. Il n’y a pas de score MMLU-Pro à comparer, pas d’échantillon de rédaction à lire, pas de trace de raisonnement à examiner. La seule question qui compte est de savoir si la réponse typée est correcte, et si la probabilité qui y est attachée est honnête. Ces deux aspects sont mesurables, mais uniquement par rapport à vos données et à vos étiquettes.

Une différence documentée mérite d’être signalée plutôt que résolue : la documentation propre de TypeSafe montre un exemple de Score indexé à partir de zéro, tandis que la fiche OrcaRouter publie l’échelle comme 2–10 niveaux. Le fournisseur documente des niveaux ; notre fiche publie 2–10. Si vous construisez une grille d’évaluation sur la base de Score, lisez les définitions de niveau dans votre propre réponse plutôt que de présumer d’un index.

Pourquoi il n'y a pas de tokens de sortie à facturer

La tarification est l’expression la plus claire de l’architecture. Jev coûte 0,042 $ par million de jetons d’entrée sur OrcaRouter, et le tarif de sortie est de 0,000000 $ par million — non pas une remise, ni une promotion de lancement, mais l’absence d’une quantité mesurable. Un modèle génératif est facturé pour le texte qu’il écrit ; Jev n’écrit aucun texte. Il renvoie une étiquette, un niveau et une probabilité. Il n’y a rien à compter du côté de la sortie, donc rien n’y est facturé.

TypeSafe annonce le même chiffre dans l'autre sens sur sa page d'accueil — « 42 $ par milliard de tokens d'entrée » — et y associe une affirmation comparative : « Prix d'entrée 238 fois inférieur à celui de Claude Fable 5.1 ». Cette comparaison, comme tout le reste sur la page d'accueil, est celle du fournisseur lui-même, que personne n'a reproduite. Mais l'arithmétique sur laquelle elle repose est facile à vérifier par un lecteur à partir de sa propre facture, et c'est là la partie utile. Le volume d'une charge de travail décisionnelle est presque entièrement déterminé par la quantité d'état que vous injectez, et l'état est bon marché d'une manière que les tokens générés ne sont pas.

Les chiffres phares du fournisseur sont plus grands que la ligne de prix et méritent le même étiquetage. TypeSafe annonce « 193,6x plus rapide, 444,6x moins cher » avec une note de bas de page restreignant cette affirmation aux « workflows pour les tâches System One », et publie juste en dessous un exemple détaillé : TypeSafe AI à 0,000081 $ a terminé en 0,114 s, contre des LLMs à 0,013880 $ qui ont terminé en 8,566 s. Le post de lancement lui-même reconnaît le risque de cadrage — les 193,6x et 444,6x sont décrits comme se situant probablement « dans le haut de la fourchette des gains réels » — et note que la démo côte à côte utilisait une requête « hautement simplifiée » avec des clés lisibles par l’humain choisies par le fournisseur pour « présenter notre modèle sous un jour avantageux ». Aucun de ces chiffres n’a été reproduit de façon indépendante, et la fiche de benchmark du fournisseur lui-même est encore marquée comme en attente.

Ce que signifie « calibré », et ce qu’est le RLCD

TypeSafe nomme elle-même sa méthode d'entraînement : « Reinforcement Learning for Calibrated Decisions (RLCD) ». RLCD est un terme propre à TypeSafe, et non un acronyme général d'apprentissage automatique antérieur à l'entreprise, et sa cible d'optimisation est indiquée dans le tableau comparatif de l'article de lancement comme « décisions calibrées : des réponses assorties de probabilités épistémiquement honnêtes sur les tâches System One ». Le contraste établi par ce même tableau est avec RLHF, qui optimise pour la préférence humaine — les articles et réponses de chat que les évaluateurs aiment — et RLVR, qui optimise pour des sorties pouvant être vérifiées par programme. RLCD optimise une troisième chose : la probabilité attachée au fait qu'une réponse constitue un énoncé exact de l'incertitude du modèle lui-même.

En pratique, « calibré » est une affirmation sur les niveaux de confiance, non une garantie que les réponses sont justes. Un modèle calibré qui annonce 0,8 sur un ensemble de questions devrait avoir raison environ 80 % du temps sur cet ensemble ; il peut néanmoins se tromper sur n'importe laquelle prise individuellement. Cette distinction est la façon honnête de lire la phrase d'accueil de TypeSafe : « Zéro hallucination — chaque décision de Jev s'accompagne d'une estimation de confiance, afin que votre logiciel puisse agir lorsque la confiance est élevée et déclencher une escalade lorsqu'elle ne l'est pas. » Il s'agit d'une affirmation portant sur une estimation de confiance, non d'une preuve de zéro erreur, et le contrepoids est constitué de nos propres données : sur les sept jours se terminant le 30 septembre 2026, notre fiche mesure un taux d'erreur de 0,49 % sur le trafic Jev via OrcaRouter — un chiffre qui était de 0,57 % plus tôt dans la même fenêtre, parce qu'il est calculé sur sept jours glissants de trafic réel du playground plutôt que sur un ensemble de tests figé. Ces deux faits ont leur place dans le même paragraphe : les niveaux de confiance sont la raison d'être du modèle, et le modèle échoue tout de même à environ un appel sur deux cents sur notre trafic.

L’histoire de la calibration explique aussi un comportement de latence qui, autrement, ressemblerait à un bug. Le post de lancement de TypeSafe dit : « Pour les choix à cardinalité plus élevée, nous utilisons un système en 2 étapes consistant à évaluer indépendamment, puis à faire un choix explicite, d’où le ralentissement occasionnel. » Un choix à 255 options n’est pas une seule comparaison directe ; le fournisseur évalue, puis choisit. Si vous voyez une requête sur un grand ensemble d’étiquettes prendre nettement plus de temps qu’une requête null, c’est le mécanisme documenté, pas de la congestion.

Comment l’appelez-vous aujourd’hui ?

Sur OrcaRouter, le modèle est typesafe/jev-1.13, nommé « TypeSafe: Jev 1.13 » dans le catalogue, avec un context_length de 65 536 tokens et exactement un type de point de terminaison pris en charge : systemone. Vous l'appelez avec POST /v1/systemone avec votre clé OrcaRouter, en envoyant un champ model, un champ state (chaîne, objet ou tableau), et une map questions où chaque entrée comporte un type (noul, choice ou score), ses instructions et ses critères. Les réponses sont une unique charge utile JSON structurée et ne sont pas streamées — il n'y a pas de mode streaming à activer.

La formulation propre à la carte pour le contrat est « texte en entrée, JSON structuré en sortie », et les limites publiées sont celles sur lesquelles concevoir : non-streaming, jusqu'à environ 64 K tokens d'entrée en combinant l'état et les questions, les requêtes dépassant cette limite étant rejetées avant d'atteindre le modèle. L'entrée de catalogue indique le prix catalogue à 0,042 $ par million de tokens d'entrée et affiche le taux de complétion à zéro. Ce sont les chiffres du fournisseur transmis tels quels — la forme proportionnelle de notre tarification : 0 % de marge sur les tarifs catalogue des fournisseurs.

Deux budgets de tokens circulent pour ce modèle et ils n'entrent pas en conflit, alors gardez-les distincts. Le chiffre de 65 536 est le context_length de la carte et est documenté comme environ 64 K d'entrée, état et questions combinés. Le « environ 32 000 tokens » que citent les articles OrcaRouter précédents est le budget d'état seul — la place que votre contenu obtient avant que les questions ne prennent leur part. Si vous établissez le budget d'une requête, le budget d'état est le nombre qui limite la charge utile que vous construisez ; le chiffre combiné est le plafond pour l'ensemble de l'appel.

Ce que Jev ne peut pas faire, en termes clairs

Il ne peut pas écrire de prose, résumer, traduire ou converser. C'est une décision de conception, et non une limitation dont il faut s'excuser : l'article de lancement dit que Jev « renonce à la génération de chaînes », et la page jaggedness de TypeSafe elle-même liste « Generation » comme un mode de défaillance nommé, avec l'instruction « Use a generative model » à côté. La génération forcée est lente et médiocre. Si votre pipeline a besoin d'un résumé écrit, Jev est le mauvais composant et aucune prouesse dans l'art du prompt n'y changera rien.

Ce n'est pas un remplacement pour un modèle génératif. Le workflow auquel Jev appartient comporte deux modèles : un modèle génératif qui lit, écrit et raisonne en texte, et Jev à côté de lui qui effectue les appels typés en quelques millisecondes. C'est la présentation honnête de chaque comparaison de coûts sur la page d'accueil du fournisseur — la colonne « LLMs » n'est pas un concurrent en train d'être déplacé, elle est l'autre moitié du même système, et la raison pour laquelle l'association est intéressante, c'est que la moitié décisionnelle se trouve désormais sur la même clé que la moitié générative plutôt que derrière son propre contrat.

Et « calibré » ne signifie pas correct. Cela signifie que le nombre attaché à une réponse est censé pouvoir se lire comme une probabilité. Un 0,62 sur un noul, c'est le modèle qui vous dit qu'il n'est pas sûr, une information utile qu'un simple oui/non aurait détruite — et ce n'est pas une promesse que le oui est juste. Une logique d'escalade fondée sur la confiance est le schéma prévu ; traiter la réponse comme une vérité terrain ne l'est pas.

Lire honnêtement les chiffres

Chaque chiffre de performance figurant sur notre fiche provient de notre propre trafic via le playground d'OrcaRouter, sur une fenêtre glissante de sept jours, et non du benchmark du fournisseur ; la fenêtre a évolué pendant la rédaction de cet article — à prendre comme une mesure ponctuelle, pas comme une spécification. Pour les sept jours se terminant le 2026-09-30 : temps médian jusqu'au premier token de 151 ms, p95 de 247 ms, débit de sortie d'environ 349 tokens par seconde, taux d'erreur de 0,49 %, et 76,2 millions de tokens servis. Le p50 quotidien sur l'ensemble de la fenêtre s'établit à 175, 170, 163, 161, 170, 147 et 143 ms — une courbe en légère amélioration. Le p95 du 09-28, à 2 448 ms, est un véritable point aberrant d'un seul jour au sein de cette série ; le citer comme la norme serait erroné, tout comme l'omettre complètement serait malhonnête.

Une réserve supplémentaire concernant le chiffre de trafic : 349 jetons de sortie par seconde, cela ressemble au débit d'un modèle génératif, jusqu'à ce que l'on se rappelle que Jev ne produit aucun texte généré. Le compteur mesure ce que notre playground comptabilise côté réponse pour une charge utile structurée, et il est utile pour repérer une dégradation d'un jour à l'autre plutôt que pour comparer Jev à un modèle de chat.

Ce sont nos chiffres. Les chiffres du fournisseur sont le 193,6x, le 444,6x, l’exemple de calcul à 0,000081 $ et la comparaison à 238x face à Claude Fable 5.1 — tous propres à TypeSafe, aucun n’a été reproduit de manière indépendante, et tous sont limités par leurs propres notes de bas de page aux workflows de tâches System One spécifiquement. La seule affirmation de performance que fait TypeSafe qui n’est pas du tout un benchmark, et qui vaut plus que les multiplicateurs, est structurelle : parce que les réponses sont typées, l’intégration n’a ni étape d’analyse syntaxique ni étape de validation de schéma, et c’est un coût qui n’apparaît dans aucun tableau de latence.

Qu'est-ce qui est ouvert, et qu'est-ce qui ne l'est pas

Vérifié le 2026-09-30, l’organisation GitHub TypeSafe a publié onze dépôts. Aucun ne contient Jev. Ceux qui importent pour un développeur intégrant le modèle sont tous sous MIT ou Apache-2.0 : skills (MIT), system-one-adapter-python (MIT, décrit comme un « remplacement direct de TypeSafeClient s’appuyant sur des API LLM »), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0, avec le code de workflow publié sur evals.typesafe.ai), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io et pulumi-clickhouse. Le nombre d’étoiles et les dates de push évoluent, donc si vous lisez ceci plus tard, revérifiez plutôt que de vous fier à la liste.

Trois des onze sont des forks de projets sans rapport et ne prouvent rien sur le fonctionnement de Jev : un fork de vLLM dont la dernière mise à jour remonte à mai 2025, un fork de LLaDA de juin 2025 — LLaDA est une publication de modèle de langage à diffusion sans rapport — et un provider Pulumi pour ClickHouse Cloud. Il est tentant de déduire une architecture d'une liste de forks. Ne le faites pas : rien dans la conception de Jev ne découle de ces trois-là, et en particulier Jev n'est pas un modèle de diffusion, quoi que puisse suggérer la présence d'un fork de LLaDA.

La réponse honnête, en une phrase, à la question « Jev est-il open source ? » est que l’outillage est ouvert et que le modèle ne l’est pas. C’est un arrangement normal pour un modèle de pointe hébergé, et c’est l’arrangement que vous devez présumer lorsque vous planifiez autour de Jev : une API avec un prix publié, un contrat documenté et un nombre de paramètres non publié.

Là où le fournisseur dit que Jev n'est pas fiable

TypeSafe publie sa propre page sur les aspérités pour jev-1.13, dernière révision le 2026-09-17, qui indique où le modèle échoue. Elle est d'une franchise inhabituelle et c'est le bon point de départ pour une section sur les limites, car il s'agit de la liste du fournisseur lui-même plutôt que de celle d'un concurrent :

• Lecture littérale — elle prend les formulations au pied de la lettre. Les mots de portée, les négations et les conditions implicites ne sont pas déduits ; elle « répond à la question que vous avez écrite, pas à celle que vous vouliez poser. » La solution du fournisseur consiste à écrire la condition exacte et les critères pour chaque option.

• Mathématiques et nombres — ce n'est pas une calculatrice, et il ne compte pas de manière fiable. Laissez l'arithmétique au code.

• Comparaison de dates et d'heures — les dates sont lues comme du texte, et non comme des quantités ordonnées ; le tri, les écarts et les fenêtres sont donc peu fiables, et cela empire avec des formats mixtes.

• Indirection — les doubles négations et le raisonnement multi-sauts réduisent la précision. Réduisez les sauts et pointez vers l’état pertinent.

• État volumineux rempli de détails non pertinents — le contenu sans rapport agit comme un distracteur et la précision diminue à mesure que l'état grandit. Filtrez d'abord.

• Contenu adversarial — l'état n'est pas traité comme hostile, de sorte que des instructions injectées ou un cadrage trompeur peuvent modifier les réponses.

• Instructions et critères contradictoires — lorsque les deux demandent des choses différentes, le modèle « risque de s’embrouiller ».

• Invariants structurels de bon sens — P(noul) et 1 − P(not noul) ne sont pas garantis d’être cohérents. Interrogez chaque décision dans un sens et imposez les identités dans le code.

• Génération — déjà couvert, et le conseil du fournisseur lui-même est d’utiliser un modèle génératif.

Deux d’entre eux méritent d’être soulignés. Celui qui relève de l’adversarial compte parce que toute la proposition de valeur de Jev consiste à juger du contenu non fiable, et un état contenant des instructions peut modifier une réponse ; si votre état provient des utilisateurs, c’est une surface d’injection de prompt de la même forme que n’importe quelle autre. Celui des invariants structurels compte parce qu’un modèle « calibré » vous invite à faire de l’arithmétique sur ses probabilités, et le fournisseur vous dit de ne pas supposer que l’arithmétique se referme.

Ce à quoi le post de lancement s'engage, et ce à quoi il ne s'engage pas

Presque toutes les affirmations de l'éditeur citées dans cet article remontent à une seule page : l'annonce de TypeSafe elle-même, classée dans la rubrique Company News et datée du 15 septembre 2026, signée par le fondateur Diogo Almeida. La lire directement vaut les deux minutes que cela prend, car la formulation d'une seule ligne définit les termes de tout ce qui a suivi. « Notre premier modèle public est Jev, disponible dès aujourd'hui en accès anticipé. » L'accès anticipé est la description que l'éditeur donne lui-même de la disponibilité sur sa propre plateforme, et c'est une affirmation plus restrictive qu'il n'y paraît : elle engage TypeSafe à mettre le modèle à disposition d'utilisateurs approuvés, et ne dit rien sur les autres acteurs susceptibles de le proposer. C'est précisément la lacune qu'a comblée l'ajout au catalogue du 24 septembre 2026, et la raison pour laquelle la fiche du modèle compte davantage que le billet pour quiconque évalue Jev aujourd'hui.

La même page est tout aussi claire sur ses propres limites, c’est pourquoi elle est citée plutôt que paraphrasée ci-dessus. Elle ne publie aucun nombre de paramètres, aucune description d’architecture au-delà de « une nouvelle architecture de modèle », aucun calcul d’entraînement et aucun dépôt de poids, et elle ne donne ni date ni conditions de disponibilité générale. Ces absences constituent les contraintes de planification : d’un côté une API avec un prix publié, de l’autre une pile dont vous ne pouvez pas inspecter les rouages. L’article présente aussi le modèle avec assez d’honnêteté pour être utile comme spécification — « un appel de fonction d’intelligence de frontière : état non structuré en entrée, décisions probabilistes typées en sortie » — ce qui est la seule phrase du texte qui décrive l’interface plutôt que l’ambition.

Questions soulevées par cette interface

Que se passe-t-il lorsqu'un ensemble de choix compte plus de 255 options ? Il est plafonné — 255 options étiquetées constituent le plafond pour une question à choix, et l'approche en deux étapes du fournisseur (notation puis sélection) est ce qu'il fait à mesure que la cardinalité augmente, ce qui est aussi la source documentée de ralentissements occasionnels sur les grands ensembles d'étiquettes. Si votre taxonomie est plus grande que cela, la réponse en matière de conception consiste à la décomposer en plusieurs questions et à recombiner dans le code, ce qui est le même conseil que TypeSafe donne pour les jugements composites.

Le contexte de 65 536 tokens signifie-t-il 65 536 tokens d'état ? Non. Le budget publié est d'environ 64K tokens pour l'état et l'ensemble des questions combinés, et le chiffre d'environ 32 000 tokens qui apparaît dans les publications plus anciennes correspond au seul budget d'état. Dimensionnez votre charge utile d'après le chiffre de l'état, et non d'après le chiffre combiné, et rappelez-vous que les requêtes dépassant la limite sont rejetées avant même d'atteindre le modèle.

Que faire de ceci

Jev 1.13 vaut le coup d’œil pour une raison précise, et non pour une raison générale. Si vous avez, dans votre pipeline, une étape qui est actuellement un modèle de chat auquel on demande de renvoyer une étiquette et à qui l’on fait confiance pour la renvoyer dans le bon format — un routeur, un évaluateur, un contrôle de politique, un score de grille d’évaluation appliqué à des milliers d’enregistrements — cette étape est ce que ce modèle remplace, à 0,042 $ par million de tokens d’entrée, sans rien de facturé au compteur côté sortie. Si vous avez une étape qui exige une réponse rédigée, Jev n’est pas l’outil, et son propre fournisseur le dit.

Ce qui a changé au cours de la dernière semaine, ce n’est pas le modèle. C’est que le tester ne nécessite plus une seconde relation avec un fournisseur. Il y a huit jours, une évaluation de Jev impliquait un compte et une intégration distincts ; aujourd’hui, c’est un seul identifiant de modèle sur une clé qui donne déjà accès à plus de 200 modèles, avec le prix catalogue du fournisseur répercuté tel quel et les réponses typées qui reviennent du même endroit que tout le reste. Pour un modèle aussi inhabituel, la possibilité de le tester par rapport à vos propres étiquettes sans vous engager dans un nouveau contrat représente l’essentiel de la décision.