« System One » en tant que catégorie de modèle : où se situe Jev 1.13

"System One" est le terme de catégorie que TypeSafe utilise pour sa séparation entre un modèle qui décide et un modèle qui écrit, et Jev 1.13 (typesafe/jev-1.13) en est le premier membre — un modèle qui renvoie des réponses typées au lieu de phrases. Ce n'est pas un nouveau modèle. TypeSafe a livré Jev le 2026-09-15, et cette page n'est pas un article de lancement : le modèle a quinze jours et se situe hors de la fenêtre de sept jours dans laquelle ce blog écrit. Ce qui s'est passé dans cette fenêtre, c'est qu'OrcaRouter a ajouté le modèle à son catalogue le 2026-09-24 et a ouvert la fiche du modèle Jev 1.13 à https://www.orcarouter.ai/models/typesafe/jev-1.13 — la première fois qu'il peut être appelé via une passerelle tierce plutôt que uniquement via le point de terminaison propre à TypeSafe. L'idée de catégorie est la raison d'être de cette page ; le changement de mise à disposition est la raison pour laquelle elle est datée d'aujourd'hui.

La version simple de la catégorie : on pose une question à un LLM et il écrit une réponse destinée à être lue par une personne. On pose une question à un modèle System One et il renvoie une valeur sur laquelle un programme peut brancher. La formule de TypeSafe elle-même est que « les LLM produisent des mots pour les humains », tandis que « Jev produit des décisions typées et ressemble davantage à du code : fiable, rapide, cohérent avec lui-même et sûr du point de vue des types. » Cette phrase est toute la catégorie compressée en une seule proposition, et il vaut la peine de la décomposer lentement, car les quatre adjectifs accomplissent une quantité de travail différente et l’un d’eux en fait plus que les autres.

Ce que « plus comme du code » prétend réellement

Prenez les quatre affirmations dans l’ordre, car ce ne sont pas quatre reformulations de « c’est mieux ».

• Fiable — la forme de sortie est fixée à l’avance. Vous déclarez la question ; la réponse ne peut revenir que comme l’une des valeurs que vous avez autorisées. TypeSafe affirme clairement que « le modèle ne commet jamais d’erreur de type », et note qu’il s’agit de la seule de leurs affirmations qui soit « mathématiquement impossible » à réfuter par un contre-exemple, car une valeur qui ne fait pas partie de l’ensemble que vous avez déclaré n’est pas une valeur que le modèle peut émettre.

• Rapide — toutes les réponses sont produites en une seule passe plutôt qu’un token après l’autre. Dans son article de lancement, TypeSafe le formule ainsi : « Jev produit toutes les probabilités en parallèle au lieu de générer de manière autorégressive token par token. » Sur notre propre fenêtre de service de sept jours se terminant le 2026-09-30, le temps médian avant le premier token sur typesafe/jev-1.13 est de 151 ms et le p95 est de 247 ms.

• Auto-cohérent — le même état, avec les mêmes questions, tend à produire les mêmes réponses. Une analogie avec la programmation est ce qui rend cela lisible, mais c’est aussi là que l’analogie cesse d’être une preuve : le déterminisme d’un compilateur est une propriété de sa construction, alors qu’ici il s’agit d’une affirmation sur un comportement. Nos propres mesures en sont la lecture honnête — le taux d’erreur sur le trafic de notre playground au cours de la même fenêtre de sept jours est de 0,49 %, donc il est auto-cohérent de la manière dont une bonne fonction est auto-cohérente, pas de la manière dont l’arithmétique l’est.

• Sûr au niveau des types — et c'est celui qui pèse le plus lourd. Sûr au niveau des types n'est pas ici un adjectif de qualité ; c'est une affirmation sur la position du modèle par rapport à un vérificateur de types. Dans un pipeline génératif ordinaire, le système de types intervient après que le modèle a terminé : le modèle écrit du texte, un analyseur devine la forme, un validateur la vérifie, et un chemin d'échec gère les cas où la supposition était erronée. Un modèle System One déplace la déclaration de type avant l'appel. Les trois primitives que documente notre fiche sont le système de types : noul, un jugement vrai/faux renvoyé avec une probabilité calibrée ; choice, une étiquette choisie parmi jusqu'à 255 options étiquetées ; et score, une évaluation sur une échelle ordonnée de 2 à 10 niveaux. Vous choisissez la primitive, vous fournissez les étiquettes ou les critères, et la valeur renvoyée est issue de cet ensemble.

TypeSafe publie bel et bien une différence entre sa propre documentation et la nôtre qui mérite d’être signalée plutôt que résolue : la documentation du fournisseur montre un exemple de Score indexé à partir de zéro, tandis que notre fiche documente l’échelle de 2 à 10 niveaux. Les deux décrivent la même primitive. Si vous construisez un seuil, consultez la page du fournisseur pour connaître l’indexation exacte de votre SDK.

Les deux modes de défaillance qui cessent d’exister

La conséquence intéressante du « pas de prose » n'est pas esthétique. C'est que les deux défaillances qui dominent les pipelines génératifs de production sont absentes de cette conception plutôt que mitigées par elle.

La dérive de format est la première. Un LLM à qui l’on demande de renvoyer du JSON renvoie du JSON la plupart du temps, et quelque chose d’adjacent au JSON le reste du temps — un commentaire en fin de ligne, une clôture Markdown, un champ renommé par un synonyme, un objet imbriqué là où le schéma attendait une chaîne. Les correctifs au niveau du prompt (instructions plus strictes, exemples few-shot, un schéma dans le message système) sont tous des tentatives de maintenir une forme que le modèle est libre d’abandonner, car la forme est une demande, pas une contrainte. Le cadrage de TypeSafe rend le contraste explicite : avec les chaînes, « les sorties et la structure possibles » sont demandées et les réponses « doivent être analysées + validées », avec « toujours un risque que l’IA déraille ». Lorsque les sorties possibles sont déclarées à l’avance, la dérive n’a nulle part où aller.

La sortie non analysable est la seconde, et c'est en réalité la même défaillance, mais à un pire moment — non pas un champ qui revient légèrement erroné, mais une réponse que l'analyseur ne peut pas lire du tout, survenant au point le moins opportun d'un flux de travail. Un modèle qui émet une valeur typée n'a pas cet état.

C'est un argument structurel, et il devrait être présenté comme tel. Il ne dit rien sur la question de savoir si une réponse individuelle est correcte — une question à choix peut sélectionner la mauvaise étiquette, et un noul peut renvoyer true avec une confiance élevée alors que la réponse honnête est fausse. Ce qui disparaît, c'est la catégorie de défaillance qu'un parseur aurait détectée. C'est une réduction réelle et utile, et ce n'est pas la même affirmation que « les réponses sont justes. »

Pourquoi le prix est une forme, pas une remise

Le modèle est facturé à 0,042 $ par million de tokens d'entrée, la sortie étant facturée à zéro — et ce zéro n'est pas un tarif promotionnel, c'est un artefact de la conception. Un modèle qui émet trois tokens de réponse structurée n'a aucun volume de sortie à mesurer, de sorte qu'une tarification par token de sortie n'a rien à quoi s'accrocher. La forme de facturation est une charge par token d'entrée et une décision. Notre catalogue répercute le prix catalogue du fournisseur avec une marge de 0 %, de sorte que le 0,042 $ est le chiffre de TypeSafe plutôt qu'un chiffre que nous fixons, et tout changement de prix du fournisseur serait effectif le jour même.

Mettez les deux formes côte à côte et la différence n'est pas un pourcentage. Le coût d'un pipeline génératif est proportionnel à ce que le modèle dit : une réponse verbeuse coûte plus cher qu'une réponse concise pour la même décision, et un modèle de raisonnement à chaîne de pensée facture les tokens qu'il dépense à réfléchir avant de répondre, que la réponse s'améliore ou non. Le coût d'un appel System One est proportionnel à ce que vous lui montrez — l'état et les questions. Posez une seule question sur un long document et vous payez pour le document. Entassez quarante questions sur le même état (le budget d'entrée de notre carte est de 65 536 tokens pour l'état et les questions combinés, soit environ 64 K ; si vous avez vu un chiffre « environ 32 000 tokens » dans des articles antérieurs d'OrcaRouter, il s'agit du budget d'état seul, et non d'un total concurrent) et vous payez le document une seule fois et obtenez quarante décisions en retour.

C’est pourquoi le coût par décision, et non le coût par token, est la bonne unité pour cette classe — et pourquoi le compteur tourne à l’inverse de ce à quoi la plupart des équipes s’attendent. La stratégie typique de réduction des coûts en génératif consiste à « faire dire moins au modèle ». Ici, il n’y a rien dont on puisse dire moins.

Les propres chiffres de TypeSafe, qui sont déclarés par le fournisseur et n'ont pas été reproduits de façon indépendante, visent précisément cette comparaison : « 193,6x plus rapide, 444,6x moins cher », avec la note de bas de page « basé sur des flux de travail pour les tâches System One (preuve) », et un exemple concret indiquant « Coût de TypeSafe AI 0,000081 $ — Terminé en 0,114 s / Coût des LLM 0,013880 $ — Terminé en 8,566 s ». La page d'accueil liste également « 42 $ par milliard de tokens d'entrée » face à « un prix d'entrée 238x plus bas que Claude Fable 5.1 ». Considérez tout cela comme l'argument du fournisseur, et non comme un résultat mesuré : l'article de lancement concède que « nos évaluations publiées sont généralement exécutées depuis nos ordinateurs portables sur la côte Ouest » et que « nous ne pouvons pas prouver que ce n'est pas subventionné ; il nous faudra le long terme pour prouver la pérennité de notre tarification (que nous nous attendons à voir baisser, pas augmenter) ». Ces deux concessions sont celles du fournisseur lui-même, et elles constituent le bon cadre pour chaque multiplicateur de la page.

La calibration est la seconde moitié de l'idée.

Si la catégorie ne concernait que les « sorties structurées », elle décrirait l’appel de fonctions avec des étapes supplémentaires. Ce qui en fait une catégorie à part, c’est que chaque réponse arrive avec une probabilité, et que ces probabilités constituent la cible d’entraînement. TypeSafe appelle cette méthode Reinforcement Learning for Calibrated Decisions (RLCD) — leur terme, pas un acronyme générique — et le tableau comparatif de l’article de lancement la place aux côtés de RLHF et RLVR : RLHF optimise ce que préfèrent les évaluateurs humains, RLVR les sorties qui peuvent être vérifiées par programme, et RLCD les « réponses assorties de probabilités épistémiquement honnêtes sur les tâches System One ».

La différence pratique réside dans ce à quoi sert la probabilité. Dans un pipeline génératif, l'estimation de confiance est une seconde génération : on demande au modèle à quel point il est sûr, et il écrit un nombre, lequel est lui-même de la prose avec les mêmes modes de défaillance. Ici, la probabilité revient avec la décision, dans la même passe, et c'est sur elle que l'on branche. La façon dont TypeSafe présente elle-même le gain est la suivante : un modèle capable d'accomplir une tâche 95 % du temps mais qui « ne dit pas quand il se trouve dans les 5 % » ne peut pas servir à automatiser cette tâche ; la confiance vous donne un endroit où placer l'escalade, vers une personne ou vers un modèle de raisonnement.

La page d'accueil de TypeSafe présente cela comme « Zero Hallucinations », expliquant que chaque décision s'accompagne d'une estimation de confiance afin que le logiciel puisse « agir lorsque la confiance est élevée et déclencher une escalade lorsqu'elle ne l'est pas ». Lisez cela attentivement : il s'agit d'une affirmation sur les estimations de confiance, et non de l'affirmation qu'aucune réponse n'est jamais fausse. Notre propre fiche fait contrepoids — un taux d'erreur de 0,49 % sur les sept jours se terminant le 30 septembre 2026, sur notre trafic, mesuré par nos soins. Ce chiffre correspond à une fenêtre glissante, pas à un ensemble de test fixe : il affichait 0,57 % quelques jours plus tôt sur la même fenêtre, et il évoluera encore.

Où System One se trouve à côté de System Two

Le vocabulaire « rapide/lent » est bien antérieur à TypeSafe. Il vient de Thinking, Fast and Slow de Kahneman, et il a été emprunté par des chercheurs en IA pendant des années avant cela — l’étiquette « Système 2 » a été attachée aux modèles de chaîne de pensée et de raisonnement délibéré bien avant l’existence de TypeSafe, et TypeSafe ne prétend pas avoir inventé l’un ou l’autre terme. Ce qu’ils ont fait, c’est appliquer la distinction à une frontière de produit plutôt qu’à un mode de prompt.

• Un modèle de raisonnement de Système 2 consacre davantage de calcul avant de répondre, et devient meilleur sur les problèmes qui l’exigent. Sa sortie reste de la prose, et le calcul supplémentaire est facturé comme des jetons de sortie.

• Un modèle System One, au sens de TypeSafe, ne réfléchit pas plus longtemps pour mieux répondre. Il répond en une seule passe, et ce qu’il sacrifie pour la vitesse, c’est la capacité de produire autre chose qu’une valeur typée.

• Les deux sont complémentaires dans un flux de travail, et non concurrents dans une comparaison. Un appel à System One traite les décisions qui doivent être rapides, peu coûteuses et lisibles ; le modèle de raisonnement reçoit les cas que le score de confiance a signalés comme incertains. La sortie typée est ce qui rend le passage de relais propre — vous transmettez une valeur et une probabilité à l’étape suivante, pas une phrase à réanalyser.

Là où le vocabulaire devient glissant, c’est lorsqu’on traite « modèle System One » comme une catégorie établie que d’autres fournisseurs auraient adoptée. Il n’en existe aucune preuve, et cette page ne doit pas être lue comme l’affirmant. TypeSafe utilise ce terme pour sa propre catégorie de modèles ; l’avertissement figurant sur notre propre fiche dit la même chose par omission, en ne listant qu’un seul type de point de terminaison pour un seul modèle. Si un autre laboratoire se met à employer cette expression pour la même architecture, ce sera un fait qui méritera d’être rapporté, et il faudra leurs propres mots pour le rapporter.

Notre fiche répertorie aussi l’irrégularité comme faisant partie de la frontière honnête plutôt que comme une surprise : neuf modes de défaillance nommés. Les entrées relatives à la lecture littérale et à l’indirection sont celles qui découlent directement de l’analogie « davantage comme du code » — un modèle qui répond à la question que vous avez écrite plutôt qu’à celle que vous vouliez poser se comporte comme une fonction qui a fait exactement ce que le code disait. Ce n’est pas le cas de l’entrée sur le comptage. Un modèle qui « reconnaît la forme d’une réponse plutôt que de la dénombrer » n’a rien de semblable à du code, et c’est pourquoi la recommandation de TypeSafe elle-même est de compter dans le code et, lorsqu’un jugement est véritablement nécessaire, de poser une question par élément et d’additionner vous-même les réponses.

Deux limites qui façonnent le design, pas le score

Les deux viennent du même endroit : pas de chaînes signifie rien à diffuser et rien à envoyer en morceaux.

• Non-streaming — la première sortie est la réponse finale, donc un appel au Système 1 est une réponse unique, pas un flux. La question n'est pas de savoir s'il peut diffuser en flux, mais ce qui diffuserait.

• Une seule forme de requête — le modèle est servi via POST /v1/systemone sur notre catalogue plutôt que via la forme chat-completions, et c'est la version honnête d'une ancienne affirmation selon laquelle il « a sa propre forme de requête ». C'est une vraie différence dans la façon de l'appeler : un objet d'état et une table de questions nommées entrent ; une réponse structurée par question sort. Vous écrirez un mapper pour cela, et comme la sortie est typée, le mapper constitue toute l'intégration — il n'y a pas de couche de parsing défensive en dessous.

Bon à savoir avant de lancer un test de charge : la latence n'est pas uniforme selon les types de questions. TypeSafe explique pourquoi, dans leurs propres termes — « Pour les choix à cardinalité plus élevée, nous utilisons un système en 2 étapes : une notation indépendante, puis un choix explicite, d'où le ralentissement occasionnel. » Une décision de routage à 4 options et une classification à 200 options sont la même primitive sur le papier, mais représentent une quantité de travail différente en pratique. Nos médianes quotidiennes sur les sept jours se terminant le 2026-09-30 s'établissent à 175, 170, 163, 161, 170, 147, 143 ms. Un jour de cette série, le 2026-09-28, a affiché un p95 de 2 448 ms — un véritable point aberrant sur une seule journée qui figure honnêtement dans la série, mais qui ne représente pas la forme du service.

L’autre chose à savoir avant une première intégration, c’est ce à quoi vous vous connectez. L’outillage autour de Jev est open source sous licences MIT et Apache-2.0 — les SDK Python et JavaScript, un adaptateur qui présente le même client adossé à des API LLM ordinaires, le code workflow-evals, et un ensemble de compétences d’agent, tous dans les dépôts publics de TypeSafe, avec des nombres d’étoiles et des dates de push qui ont bougé aussi récemment que le 2026-09-26 et le 2026-09-29. Le modèle ne l’est pas. Il n’y a pas de dépôt de poids : l’architecture de Jev, son nombre de paramètres, son compute d’entraînement et ses poids ne sont pas publiés, et un lecteur qui vérifie cela ne doit pas être induit en erreur par les trois dépôts de cette organisation qui sont des forks de projets sans rapport — un fork de vLLM, une publication de modèle de langage à diffusion de 2025, et un provider Pulumi. Aucun d’eux ne dit quoi que ce soit sur la façon dont Jev est construit. La réponse en une ligne est que l’outillage est ouvert et que le modèle ne l’est pas.

Le lancer aujourd'hui, et ce qui change pour un lecteur

Jev 1.13 est disponible sur OrcaRouter sous le nom typesafe/jev-1.13, accessible avec la même clé que plus de 200 autres modèles, avec le prix catalogue du fournisseur répercuté à 0 % de marge. La valeur pratique de cela sur une page consacrée à une catégorie est limitée et mérite d'être énoncée précisément : essayer un modèle System One ne nécessite plus un compte séparé, une clé séparée et une facture séparée pour un modèle que vous ne savez peut-être pas encore vouloir. Il se trouve aux côtés de la moitié générative du même flux de travail — le classifieur et le rédacteur sur une seule accréditation, au même endroit, avec le décompte de ce que vous avez réellement appelé.

Rien ici ne change ce qu’est le modèle. Il a été lancé le 15 septembre 2026 et TypeSafe le décrit toujours comme un accès anticipé ; ce qu’il est n’a pas bougé depuis. Ce qui a changé le 24 septembre 2026, c’est qu’un lecteur peut désormais découvrir ce que cela lui coûte en pratique sans d’abord s’engager dans une relation avec un second fournisseur. Si vous attendiez de voir si le type mérite un prototype, c’est cela qui a bougé.