Là où Jev 1.13 casse : la propre liste de limites de TypeSafe

Jev 1.13 (typesafe/jev-1.13) a été publié le 15 septembre 2026, ce qui le place deux semaines en dehors des sept derniers jours, donc son lancement n'est pas le sujet. L'événement daté est le 24 septembre 2026 : c'est le jour où OrcaRouter a ajouté typesafe/jev-1.13 à son catalogue et ouvert une fiche de modèle pour lui — la première prise en charge de l'inférence pour Jev dans une passerelle tierce, après une quinzaine pendant laquelle le seul moyen de l'appeler était le point de terminaison de TypeSafe lui-même. Cela compte ici pour une raison précise. Jev est inhabituel en ce que son fournisseur publie une liste des façons dont il échoue, et une liste que l'on peut seulement lire est bien plus facile à ignorer qu'un modèle que l'on peut réellement appeler.

Cette page constitue ladite liste, limitée à ce que TypeSafe dit lui-même, plus les limites d'exploitation et la facture.

TypeSafe publie sa propre liste d'irrégularités

docs.typesafe.ai contient une page intitulée Jev 1.13 : aspérités. Elle s’applique explicitement à jev-1.13, comporte une date de révision fixée au 2026-09-17 et s’ouvre sur la formulation du fournisseur lui-même : « Jev n’est pas parfait. Voici quelques aspérités dont nous avons connaissance avec jev-1.13. Bon nombre d’entre elles seront corrigées dans les versions ultérieures. » Neuf modes nommés suivent, chacun avec un cas concret et une solution « Instead: ». Rien de ce qui suit n’est déduit, et rien n’est atténué — la formulation est celle de TypeSafe, et lorsque l’entreprise donne son propre exemple, les chiffres qu’il contient sont les siens.

Lecture littérale : cela répond à la question que vous avez écrite.

Les mots de portée, les négations et les conditions implicites sont pris au pied de la lettre. On répond à une question d’après les mots de la consigne, « alors qu’une personne aurait pu lire l’intention derrière les instructions. »

Le diagnostic du fournisseur est la partie utile : lorsque vous examinez une réponse erronée et que vous vous surprenez à expliquer ce que vous vouliez vraiment dire, cette explication est la moitié manquante de la consigne. Les remèdes consistent à énoncer la condition exacte dans les consignes, à intégrer les cas limites dans les critères et, lorsque l’interprétation est réellement inévitable, à scinder la question en deux questions littérales et à les combiner dans le code.

Mathématiques et nombres : ce n'est pas une calculatrice

TypeSafe dit clairement d’implémenter la logique mathématique dans le code. Trois défaillances spécifiques se cachent sous cela :

• Le comptage n’est pas fiable. Cela couvre les caractères dans un mot, les occurrences d’un terme dans un passage et les éléments d’une longue liste. « Le modèle reconnaît la forme d’une réponse plutôt que de compter, et l’erreur augmente avec la taille de ce qui est compté. » Le propre test du fournisseur pour savoir s’il faut poser la question : si une expression régulière ou un analyseur peut trouver l’unité, le comptage relève du code et le modèle n’apporte rien.

• Les représentations numériques sont moins performantes que les représentations sémantiques. Les questions sur les couleurs utilisant des valeurs hexadécimales donnent de moins bons résultats que les mêmes questions formulées avec des noms de couleurs en anglais ; face à des triplets RGB ou à des valeurs hexadécimales, Jev ne peut pas juger de manière fiable si deux valeurs sont proches l’une de l’autre. Le même écart se manifeste sur le code de bas niveau — assembleur ou instructions encodées en binaire — par rapport aux langages de haut niveau. Convertissez ou regroupez par catégories dans le code, et réservez le modèle à la partie qui relève véritablement du jugement.

• Les sorties de score ne portent pas de magnitudes exactes. Le fournisseur affirme que les niveaux de score de Jev sont peu calibrés numériquement. Une espérance peut être utilisée pour tester si quelque chose franchit un seuil ; elle ne peut pas être utilisée pour reconstruire le nombre en interpolant entre les deux niveaux les plus proches. C’est un non catégorique à toute une classe de mésusages — lire un score comme une mesure.

Date et heure : les dates sont lues comme du texte, et non comme des quantités

Ordonner deux dates, mesurer l’écart entre elles ou déterminer si l’une tombe dans une fenêtre n’est pas fiable, et cela se dégrade encore davantage avec des formats mixtes, des références relatives et des limites de domaine telles que les trimestres, les fenêtres de règlement et les périodes d’accumulation.

Le découpage recommandé est net. L'extraction relève d'un jugement, alors confiez-la au modèle. Chaque composante d'une date est un petit ensemble fermé — douze mois, trente et un jours possibles, une plage d'années bornée — ce qui transforme l'extraction en un choix parmi des options énumérées plutôt qu'en une analyse libre, et vous donne un endroit où placer un « non précisé » explicite afin qu'une partie manquante soit signalée plutôt que devinée. Le code assemble les parties et prend en charge tout ce qui suit, y compris l'ordre, la durée, le décalage et le jour de la semaine.

Indirection : les doubles négations et les sauts supplémentaires nuisent à la précision

Les instructions qui comportent des doubles négations ou une indirection en couches reçoivent des réponses moins fiables. Une question portant sur une propriété d’une propriété, ou qui exige plusieurs étapes de raisonnement, nuit à l’exactitude. Le remède consiste à rédiger les instructions aussi directement que possible et à nommer les parties pertinentes de l’état plutôt que de les décrire.

Un état volumineux rempli de détails non pertinents nuit à la précision

La précision diminue à mesure que l'état s'enrichit de contenu sans rapport avec la décision. Les détails non pertinents agissent comme un distracteur, et un état volumineux rend plus difficile de déterminer quelle partie de l'entrée a produit une mauvaise réponse. Le rappel de TypeSafe lui-même dans la note de clôture est sans détour : « Jev souffre de dégradation du contexte, donc tout élément non pertinent dans l'état vous coûte en précision. »

Récupérez et filtrez d'abord dans le code, puis n'envoyez que les champs dont la question a besoin. Lorsqu'un filtrage avant la requête n'est pas possible, le fournisseur suggère d'utiliser un noul pour filtrer par pertinence, puis d'évaluer les résultats restants.

Le contenu adversarial dans l'état déplace la réponse

L'état est une donnée, et jev-1.13 ne le traite pas comme hostile par défaut. Une intention, un élément délibérément trompeur, ou un texte qui plaide pour son propre résultat peuvent influencer le résultat. C'est le seul mode où le fournisseur présente explicitement la forme comme un travail futur — « Nous espérons améliorer cela à l'avenir » — et le conseil provisoire est d'être explicite dans les critères et de tester l'intégration de manière approfondie avant de la présenter à de nombreux utilisateurs.

Des instructions et des critères contradictoires le déroutent.

Lorsque les instructions et les critères demandent des choses différentes, le modèle peut être confus. L’exemple de TypeSafe est un noul où vrai correspond à non et faux correspond à oui, ce qui donne de moins bons résultats que la même question formulée de manière cohérente. L’instruction consiste à traiter les critères comme une extension de l’instruction et à aligner les deux dans un langage qu’une personne moyenne pourrait lire et comprendre.

Invariants structurels qu'il ne garantit pas

C'est le mode le plus susceptible de faire défaillir un système construit sur une hypothèse que personne n'a consignée. Jev est extrêmement cohérent au sens ordinaire — des entrées sémantiquement similaires produisent des sorties quantitativement similaires — mais les identités structurelles que l'on pourrait s'attendre à voir tenir ne sont pas garanties. Le fournisseur publie deux cas détaillés.

• Une question, deux types de questions. « Le client demande-t-il un remboursement ? » posée sous forme de noul et posée sous forme de choix oui/non, sur le ticket « Je ne suis pas satisfait de l’ajustement. Quelles sont mes options ici ? » renvoie un noul de 0,22, et un choix : oui 0,01, non 0,99, confiance 0,97. Ce sont des réponses à la même question.

• Une question et sa négation. « Le client demande-t-il un remboursement ? » et « Le client demande-t-il autre chose qu’un remboursement ? », posées comme deux nœuds sur le ticket « J’ai été facturé deux fois pour la même commande. Quelqu’un peut-il examiner cela ? », renvoient 0,72 et 0,47. Leur somme est de 1,19.

Les remèdes sont opérationnels, non rhétoriques : ne vous fiez pas à une invariance structurelle attendue, ne transposez pas à un choix un seuil calibré sur un noul, et n'exigez pas du modèle qu'il respecte des identités arithmétiques entre des questions distinctes. La raison en est qu'un choix est relatif — il détermine quelle option — tandis que chaque noul est absolu et peut ressortir bas pour toutes.

Génération : elle n'a pas été entraînée à écrire

jev-1.13 n'est pas entraîné à générer du texte. Vous pouvez forcer la sortie en enchaînant les choix, et TypeSafe dit directement que cela « ne fonctionnera pas bien et sera très lent ». Pour l'extraction, la recommandation est d'extraire les valeurs candidates à l'aide d'une expression régulière ou d'un modèle génératif, puis de laisser Jev choisir la bonne, ou — lorsque l'espace de réponses est borné — de transformer l'extraction en un choix parmi les options plutôt que de demander la valeur elle-même.

La limite de 255 options pour les questions à choix

Une question de choix : une intégration Jev n’est pas une arête déchiquetée, c’est la forme du produit. Ces éléments méritent d’être isolés, car aucun travail de prompt ne les modifiera :

• Aucune génération de texte. Il renvoie une décision, pas de la prose. C’est un choix de conception, pas un défaut.

• Aucune conversation. Jev est un modèle de décision structuré plutôt qu’un modèle de conversation. Vous envoyez un état et un ensemble de questions nommées ; il renvoie une réponse structurée par question. Il n’y a pas d’alternance de tours à intégrer dans la conception.

• Aucune entrée multimodale. L'entrée est uniquement textuelle — chaîne, objet JSON ou tableau de valeurs textuelles, sans image, audio ni vidéo. Tout élément non textuel doit être prétraité en texte ou en champs structurés avant de faire partie de l'état.

• Réponses sans streaming. Il n'existe qu'une seule réponse structurée, et aucun mode de streaming. La raison pour laquelle ce cas n'a pas d'importance est la même que celle qui justifie de le mentionner : il n'y a rien à streamer. Une décision typée — un booléen assorti d'une probabilité, une étiquette parmi un ensemble, ou un niveau sur une échelle — n'a aucune forme partielle qui mérite d'être révélée token par token.

• L'anglais est la langue principale. Les autres langues, y compris les écritures CJK, sont prises en charge, mais pas aussi bien. Le conseil de TypeSafe est de tester sur votre propre contenu avant de compter sur Jev pour une charge de travail non anglophone, et de vous appuyer sur la confiance lors du routage.

La limite de 255 options pour les questions à choix

Une question à choix sélectionne l'une de jusqu'à 255 options étiquetées, et ce plafond est une limite stricte. TypeSafe explique également pourquoi les grands ensembles de choix s'exécutent plus lentement, selon les propres termes du fournisseur : « Pour les choix de cardinalité plus élevée, nous utilisons un système en 2 étapes consistant à noter indépendamment, puis à faire un choix explicite, d'où le ralentissement occasionnel. » Ainsi, le coût de latence d'un grand ensemble d'options est structurel plutôt qu'accidentel, et c'est le fournisseur qui vous dit d'où il vient.

Notre propre fenêtre de service pour typesafe/jev-1.13, lue sur la fiche modèle le 2026-09-30, montre ce que cela donne en pratique sur sept jours de notre propre trafic : une médiane de 151 ms et un p95 de 247 ms, 348 tokens de sortie par seconde, et un taux d'erreur de 0,49 % sur 76,2 millions de tokens servis. Les médianes quotidiennes évoluent dans une bande étroite — 175, 170, 163, 161, 170, 147 et 143 ms du 2026-09-24 au 2026-09-30 — mais le p95 quotidien du 2026-09-28 est de 2 448 ms, soit environ dix fois les jours qui l'entourent. Nous ne pouvons pas attribuer cette valeur aberrante d'un seul jour à la cardinalité des choix, et nous ne le ferons pas ; l'interprétation honnête est que la queue existe, et un flux de travail sensible à la latence devrait être conçu par rapport à la queue plutôt qu'à la médiane.

La facture d'entrée est la facture complète.

La sortie est facturée à zéro sur Jev, ce qui est parfois interprété comme « Jev est gratuit ». Ce n'est pas le cas, car l'entrée est mesurée et un état volumineux n'est pas gratuit simplement parce qu'il n'y a rien du côté sortie. Le prix du fournisseur est de 0,042 $ par million de jetons d'entrée — le même nombre que TypeSafe indique comme étant de 42 $ par milliard — et OrcaRouter répercute le prix catalogue du fournisseur avec 0 % de marge, donc une baisse de prix du fournisseur est répercutée ici le jour même.

Voici ce que cela fait à une forme réaliste, en utilisant le taux du fournisseur :

• Une petite requête. Un ticket d’assistance de 1 200 tokens plus environ 300 tokens de grille d’évaluation et de questions, soit 1 500 tokens d’entrée, ce qui représente 0,000063 $ par appel.

• Une requête volumineuse. Un contrat de 55 000 tokens, auquel s’ajoutent des questions qui portent la requête à 60 000 tokens, représente 40 fois plus de tokens, soit 0,0025 $ par appel — toujours peu élevé par appel, et 40 fois plus important que le premier cas pour une seule et même réponse.

• À grande échelle. 60 000 jetons par appel et 10 000 appels par jour représentent 600 millions de jetons d’entrée par jour, soit 0,6 milliard, donc 25,20 $ par jour et environ 756 $ sur un mois de 30 jours. Le même nombre d’appels avec la requête de 1 500 jetons représente 15 millions de jetons par jour : 0,63 $ par jour, environ 18,90 $ par mois.

L'écart entre ces deux dernières lignes n'est pas une astuce tarifaire, c'est l'état comptabilisé. C'est pourquoi les conseils de filtrage de la section sur la pourriture du contexte ne sont pas seulement une mesure d'exactitude : réduire cet état est aussi le seul levier qui fait bouger la facture.

Les limites de fonctionnement publiées, pour que personne n'ait à deviner

La page des modèles de TypeSafe publie des chiffres concrets, ce qui évite à un planificateur de devoir les déduire :

• Débit et cadence. 100K tokens par seconde et 40 requêtes par seconde, d’après docs.typesafe.ai/models.md. Une requête dépassant l’une ou l’autre de ces limites renvoie 429 Too Many Requests ; les SDK clients du fournisseur réessaient avec backoff par défaut et respectent l’en-tête retry-after lorsque la réponse en comporte un.

• Les limites évoluent. Le fournisseur indique que les limites de débit s’ajustent dynamiquement et « peuvent changer sans préavis » à mesure que la capacité est mise en ligne, avec des limites plus élevées disponibles sur les offres personnalisées et entreprises. Considérez 100K/40 comme la valeur d’aujourd’hui plutôt que comme un engagement contractuel.

• Budget de contexte. Le budget de requête est d'environ 64 000 jetons pour l'état combiné et l'ensemble des questions — la fiche du modèle indique 65 536 — et la page des modèles du fournisseur plafonne séparément l'état plus la question la plus longue à 32 000 jetons. Ce second chiffre correspond au budget d'état, et non à une version réduite du premier ; les deux sont réels et ni l'un ni l'autre ne contredit l'autre.

• Les alias bougent sous vos pieds. jev-latest et jev-preview pointent tous deux vers jev-1.13.0 aujourd'hui, et le fournisseur signale qu'aucune version preview n'est disponible pour le moment. Un alias change lorsqu'une nouvelle version est publiée, donc si vous avez ajusté vos seuils de confiance pour une version spécifique, épinglez l'ID versionné et évoluez selon votre propre calendrier.

À quoi votre cas d'usage doit ressembler

Lue d'un bout à l'autre, la liste du fournisseur lui-même décrit un outil étroit et utile. Jev convient lorsque le jugement est circonscrit et que l'arithmétique n'est pas la tâche du modèle : cet enregistrement est-il conforme à la politique, laquelle de ces quarante étiquettes s'applique, comment cela se lit-il sur une échelle à cinq niveaux — posées sur un état que vous avez filtré vous-même, avec une instruction littérale et des critères qui concordent avec elle, et avec chaque comptage, comparaison et mesure de date effectués dans du code autour.

Ce n'est pas adapté lorsque la tâche exige du comptage, du tri ou de l'arithmétique de dates, lorsqu'elle demande plusieurs étapes de raisonnement, lorsque le matériau d'entrée n'est pas du texte, lorsque l'état est une botte de foin et que la question est une aiguille, ou lorsque quoi que ce soit à propos de la source est hostile. Ce ne sont pas des lacunes dans un prompt ; ce sont des endroits où le modèle ne fonctionne pas, et c'est TypeSafe qui le dit.

Une dernière chose à savoir avant de le mettre en place : la véritable différence dans la façon dont Jev est appelé. Sur OrcaRouter, le catalogue atteint Jev via le point de terminaison dédié systemone, POST /v1/systemone, plutôt que via la structure chat-completions d'OpenAI. C'est une vraie différence dans la requête que vous écrivez, et c'est la version correcte de l'ancienne affirmation selon laquelle Jev « parle sa propre forme de requête ». Tout le reste est identique à n'importe quel autre modèle du compte — une clé pour plus de 200 modèles, aucun frais par token de notre part, et un basculement automatique si une route tombe en panne. TypeSafe a supprimé la liste d'attente le 2026-09-21 ; la page d'accueil du fournisseur lui-même décrit encore Jev comme étant en accès anticipé, et sa propre page de benchmarks est toujours marquée en attente, donc les seuls chiffres de performance sur cette page sont les chiffres de service que nous avons mesurés nous-mêmes et les affirmations du fournisseur lui-même, étiquetées comme telles.