Qu'est-ce que TypeSafe AI ? Le laboratoire derrière Jev 1.13 prend des décisions, pas des phrases

TypeSafe AI est un petit laboratoire de San Francisco qui vend un modèle incapable d’écrire une phrase, et Jev 1.13 (typesafe/jev-1.13) est le modèle en question. Il prend un élément d’état — un e-mail, une ligne de journal, un ticket d’assistance, un objet JSON — ainsi qu’un ensemble de questions nommées, et renvoie une réponse typée par question, chacune avec sa propre valeur de confiance. Pas de prose, pas de code, pas d’explication et pas de zone de chat. Le modèle lui-même a été lancé le 15 septembre 2026, il n’est donc pas nouveau et rien ici n’est un récit de lancement : cette page existe à cause d’un changement plus petit et datable. Le 24 septembre 2026, OrcaRouter a ajouté typesafe/jev-1.13 à son catalogue et ouvert la fiche du modèle à sa propre adresse, ce qui était la première fois que Jev pouvait être appelé via une passerelle tierce, et non uniquement via le point de terminaison propre de TypeSafe. C’est l’événement, il a six jours à la date du 30 septembre 2026, et c’est la raison pour laquelle un lecteur qui n’a pas déjà de contrat TypeSafe peut désormais placer un modèle System One sur la même clé que les modèles génératifs aux côtés desquels il est conçu pour se trouver. Tout le reste sur cette page est du contexte sur l’entreprise qui l’a créé.

La mise au point honnête sur le calendrier, car elle compte pour savoir dans quelle mesure tout ceci est vérifié : Jev a été lancé il y a plus de deux semaines et est généralement disponible depuis le 2026-09-21, date à laquelle TypeSafe a supprimé sa liste d’attente. Ce qui se trouve dans la fenêtre de sept jours, c’est le changement de routage, pas le modèle. Si vous êtes venu ici en vous attendant à une revue de lancement, le lancement a déjà eu lieu et une poignée d’autres articles en ont parlé.

Une page d’entreprise avec un manifeste et aucun diagramme d’architecture

TypeSafe se décrit, dans sa propre méta-description, comme « un laboratoire d’IA qui construit une infrastructure d’intelligence native pour les machines destinée à l’automatisation », avec des systèmes « conçus pour prendre des décisions au sein des logiciels ». Sa page d’accueil porte la mention Version 0.01 et, en pied de page, « Fabriqué à SF ». Un manifeste y soutient que le chemin le plus court vers une mutation économique induite par l’IA passe par le fait de rendre l’intelligence composable, afin que les logiciels puissent invoquer un jugement sémantique de la même manière qu’ils invoquent une fonction ; le résumé que l’entreprise donne elle-même de son plan consiste à livrer la forme d’une IA composable native pour les machines, puis à la rendre suffisamment fiable pour une automatisation réelle, puis à offrir des abstractions de plus haut niveau, suffisamment stables pour être empilées par-dessus. Son slogan est « Nous construisons de la prod, pas Dieu. » La page équipe nomme trois fondateurs — Diogo Almeida comme CEO, Sasha Sheng comme COO et Erik Gafni comme CTO. C’est tout ce que l’entreprise dit d’elle-même : une position, un produit, trois noms, et aucun chiffre sur l’entreprise elle-même.

Ce que le site ne propose pas est la première chose qu'un ingénieur évaluant une nouvelle dépendance recherche. Il n'y a pas de page d'architecture, pas de paramètre, pas de divulgation de la puissance de calcul d'entraînement, et pas de fiche de modèle au sens académique. Le tableau de bord de benchmark de TypeSafe est encore marqué. Pour une entreprise dont l'argument de vente repose sur la fiabilité, la surface de divulgation est mince, et c'est un fait concernant ce qui a été publié plutôt qu'une accusation sur ce qui est caché.

System One : la catégorie, et pourquoi le nom est emprunté

Jev est le premier de ce que TypeSafe appelle les modèles System One. Le nom vient de la distinction faite par Daniel Kahneman entre la pensée rapide et intuitive du Système 1 et le raisonnement lent et délibéré du Système 2, et le billet de lancement de l’entreprise le dit clairement — il concède aussi que la « pensée Système 1 » a eu une connotation de propension à l’erreur, et soutient que ces modèles peuvent être rendus plus fiables que les alternatives. TypeSafe n’a pas forgé le terme et ne le possède pas.

Le contenu pratique de la catégorie est une division délibérée du travail : un modèle qui décide et un modèle qui écrit. Vous êtes censé conserver l’arithmétique, l’ordre des dates, le comptage et la comparaison de chaînes dans du code ordinaire, où ils sont exacts, et confier le jugement sémantique à Jev. Trois types de questions sont ce à quoi il peut répondre :

• noul — un jugement vrai/faux, renvoyé avec une probabilité calibrée

• choix — sélectionnez l’une des options étiquetées (jusqu’à 255)

• score — noter sur une échelle ordonnée ; notre fiche publie 2-10 niveaux, et la documentation propre à TypeSafe montre un exemple indexé à 0, donc considérez les niveaux du fournisseur comme la définition et le 2-10 comme ce que la fiche publie

Chaque question comporte ses propres instructions et, pour le choix et le score, ses propres critères. Les requêtes dépassant environ 64 K jetons d’entrée sont rejetées avant d’atteindre le modèle, et les réponses ne sont pas diffusées en streaming. Le fournisseur documente séparément le budget d’état — l’état plus la question la plus longue — à 32 K jetons, un chiffre plus restreint que le contexte de 65 536 jetons indiqué sur la fiche et non une contradiction de celui-ci.

Leur thèse, dans leurs propres mots

TypeSafe énonce la thèse mieux que ne le ferait n’importe quel résumé, alors la voici mot pour mot : « Les LLM produisent des mots pour les gens. Jev produit des décisions typées et ressemble davantage à du code : fiable, rapide, cohérent avec lui-même et type-safe. » La méthode d’entraînement qui sous-tend cela est aussi la leur, et c’est un terme qu’il vaut la peine d’attribuer avec précision, précisément parce qu’il a été repris ailleurs comme s’il était générique. TypeSafe l’appelle Reinforcement Learning for Calibrated Decisions, ou RLCD, et l’oppose à RLHF et RLVR : là où ceux-ci optimisent les préférences humaines ou des récompenses vérifiables par programme, RLCD cible, selon la formulation de l’entreprise, « des réponses avec des probabilités épistémiquement honnêtes sur des tâches du système 1 ». Considérez RLCD comme une création de TypeSafe, et non comme un acronyme établi dans la littérature.

Les chiffres qu’ils mettent en avant, et qui a choisi la charge de travail

La page d’accueil s’ouvre sur « 193,6 fois plus rapide, 444,6 fois moins cher », avec une note de bas de page renvoyant à des workflows pour des tâches System One. En dessous se trouve un exemple détaillé : TypeSafe AI à 0,000081 $ et 0,114 seconde, contre des LLM à 0,013880 $ et 8,566 secondes. Plus bas, « 42 $ par milliard de tokens d’entrée. Prix des tokens d’entrée 238 fois inférieur à celui de Claude Fable 5.1. » Et une section intitulée « Zéro hallucination », qui, à l’examen, est une affirmation sur les estimations de confiance plutôt qu’une preuve de zéro erreur : chaque décision de Jev porte une estimation de confiance, de sorte que le logiciel peut agir lorsque la confiance est élevée et déclencher une escalade lorsqu’elle ne l’est pas. Ces quatre chiffres sont ceux de TypeSafe, sur des charges de travail choisies par TypeSafe, et aucun n’a été reproduit indépendamment. Le billet de lancement lui-même indique que l’équipe s’attend à ce que ses 193,6x et 444,6x se situent dans le haut de la fourchette des gains en conditions réelles, et note que les workflows ont été conçus par sa propre équipe en charge des capacités, les réponses de référence étant produites par des modèles concurrents. Nos propres données de service sur sept jours, pour le même modèle, établissent le taux d’erreur à 0,49 %, ce qui constitue une mesure différente sur une charge de travail différente et le contrepoids honnête à une lecture de « zéro » comme un absolu.

Ce qu'ils n'ont pas publié

L'architecture de Jev, son nombre de paramètres, son compute d'entraînement et ses poids ne sont pas publiés, et il n'existe aucun dépôt de poids dans l'organisation GitHub de l'entreprise. Vérifié le 2026-09-30, cette organisation compte onze dépôts publics ; les plus substantiels sont des outils, tous sous MIT ou Apache-2.0 — un dépôt d'agent-skills, un SDK Python, un SDK TypeScript, un adaptateur client drop-in s'appuyant sur d'autres API de LLM, une collection de modules Dagger, du code d'évaluation de workflows publié, un node n8n, et le site de l'organisation elle-même. Le nombre d'étoiles et les dates de push évoluent, alors consultez-les le jour même plutôt que sur cette page.

Trois des onze sont des forks de projets sans rapport : vLLM, LLaDA et un provider Pulumi pour ClickHouse Cloud. Ce sont des forks du travail de quelqu'un d'autre et ils ne disent rien sur la manière dont Jev est construit — en particulier, rien sur le fait que Jev est basé sur la diffusion. La réponse en une ligne à la question de savoir si Jev est open source est que l'outillage est ouvert et que le modèle ne l'est pas.

Ce qu'ils s'accordent eux-mêmes

Deux aveux dans l’article de lancement valent plus que la plupart des mises en garde des fournisseurs, car ils nomment les endroits exacts où les preuves sont faibles. Sur le prix : « Nous ne pouvons pas prouver qu’il n’est pas subventionné ; nous aurons besoin du long terme pour prouver la durabilité de notre tarification (que nous prévoyons à la baisse, pas à la hausse). » Sur la vitesse : « nos évaluations publiées sont généralement exécutées depuis nos ordinateurs portables sur la côte Ouest (c’est là que notre service est actuellement basé). » Il y en a un troisième, plus utile pour quiconque construit dessus : pour les ensembles de choix à forte cardinalité, Jev exécute un système à deux étapes qui évalue indépendamment puis fait un choix explicite, « d’où le ralentissement occasionnel ». C’est le fournisseur qui explique pourquoi la latence n’est pas uniforme selon les types de questions, et c’est le genre de chose que l’on apprend normalement dans un fil de support.

Où vous pouvez réellement l'appeler, à ce jour

Via l'API propre à TypeSafe, où le modèle est en disponibilité générale et où la page d'accueil utilise encore l'expression du fournisseur « early access » — cette formulation est d'actualité et mérite d'être conservée, tandis que « waitlisted » est abandonnée : la documentation publie des limites d'exploitation concrètes (100K tokens par seconde, 40 requêtes par seconde, 429 avec backoff du SDK au-delà de l'une ou l'autre) et ne comporte aucun terme de liste d'attente. Et, depuis le 2026-09-24, via OrcaRouter.

Ce que nous servons mérite d'être énoncé précisément, car c'est la forme d'appel qui diffère. L'entrée du catalogue est typesafe/jev-1.13, nommée TypeSafe : Jev 1.13, avec le type de point de terminaison pris en charge « systemone » — il est donc atteint via POST /v1/systemone plutôt que via la forme chat-completions d'OpenAI, en non-streaming, texte en entrée et JSON structuré en sortie, jusqu'à environ 64 K tokens d'entrée en cumulant état et questions. L'entrée est à $0.042 par million de tokens et la sortie est facturée à zéro, car il n'y a aucun token de sortie à mesurer : une décision typée n'est pas de la prose. C'est le prix catalogue du fournisseur répercuté, avec 0 % de marge, sur la même clé que les 200+ autres modèles du catalogue — une seule API pour 200+ modèles, 0 % de marge (prix catalogue du fournisseur répercuté, donc les baisses de prix des fournisseurs sont effectives ici le jour même). Si la raison pour laquelle vous lisez à propos de TypeSafe AI est que vous voulez savoir si la calibration de Jev tient sur vos propres données avant d'engager un chemin de production dessus, l'exécuter à côté d'un modèle génératif auquel vous faites déjà confiance est le moyen le moins coûteux de le découvrir ; basculer vers ce modèle lorsque la confiance de Jev revient basse est le moyen le moins coûteux de le mettre en production.

Nos propres chiffres de service sur sept jours pour la période se terminant le 2026-09-30, qui sont nos chiffres issus de notre propre trafic plutôt que du benchmark du fournisseur : p50 151 ms, p95 247 ms, environ 349 jetons de sortie par seconde, un taux d’erreur de 0,49 % et 76,2 M de jetons servis. Le p50 quotidien sur cette période s’est établi à 175, 170, 163, 161, 170, 147, 143 ms, la médiane diminue donc légèrement. Un jour de la série, le 09-28, affiche un p95 de 2 448 ms — une véritable valeur aberrante dans les données, pas la norme, et ce n’est pas un chiffre autour duquel bâtir un budget de latence. Ces chiffres sont actualisés quotidiennement ; la carte fait foi.

Là où le modèle est faible, selon TypeSafe

Le fournisseur publie une page sur les aspérités pour Jev 1.13, révisée pour la dernière fois le 2026-09-17, qui nomme les modes de défaillance plus franchement que la plupart des documents de lancement. C'est la bonne page à lire avant de construire sur le modèle, et sa propre liste se présente comme suit. Jev répond à la question que vous avez écrite plutôt qu'à celle que vous vouliez poser, donc les mots de portée, les négations et les conditions implicites doivent être explicités. Ce n'est pas une calculatrice : il est moins performant sur les questions mathématiques que sémantiques. Il lit les dates comme du texte plutôt que comme des quantités ordonnées, donc l'ordre, les écarts et l'appartenance à une fenêtre ne sont pas fiables, et c'est pire avec des formats mixtes. Les doubles négations et l'indirection à sauts multiples réduisent la précision. La précision diminue à mesure que l'état s'enrichit de détails non pertinents — la page dit qu'il « souffre de pourriture du contexte » — donc filtrer d'abord dans le code est la solution. L'état est traité comme des données, et non comme hostile par défaut, donc des instructions injectées peuvent modifier les réponses. Des instructions et des critères incohérents le confondent. Les invariants structurels ne sont pas garantis : une sortie noul et une sortie choix n'ont pas besoin de correspondre, et une question plus sa négation n'ont pas besoin de somme à un, donc les seuils ne devraient pas être transposés entre les deux. Et il n'est pas entraîné à générer du texte — le forcer à passer par des choix en chaîne « ne fonctionnera pas bien et sera très lent ».

Comment interpréter TypeSafe AI six jours après le changement de routage

L’entreprise avance une affirmation forte, précise et réfutable : qu’un modèle décisionnel étroit peut être plus rapide, moins cher et plus digne de confiance qu’un modèle généraliste sur le sous-ensemble de travail où l’on a besoin d’un jugement plutôt que d’un paragraphe. L’affirmation est plausible et en partie auto-démontrée — les estimations de confiance constituent une véritable différence de conception, le prix est réel, et la latence que nous mesurons sur notre propre trafic est du même ordre que celle du fournisseur. Ce qui manque, c’est la partie qui permettrait à un tiers de vérifier le reste : aucune architecture, aucun paramètre, aucun poids, aucun benchmark indépendant, et un prix dont l’entreprise dit elle-même qu’elle ne peut pas prouver qu’il est soutenable. Les modes de défaillance sont documentés, ce que la plupart des laboratoires ne font pas, et c’est la meilleure raison, à elle seule, de prendre le modèle au sérieux.

Si vous vous demandez si vous devez y prêter attention : lancez Jev sur des entrées que vous avez déjà étiquetées, en masquant les étiquettes, et regardez si ses chiffres de confiance séparent les cas qu’il réussit de ceux qu’il rate. Ce test ne coûte presque rien, à 0,042 $ par million de jetons d’entrée, et c’est le seul qui répond à la question que vous vous posez réellement. Si vous vous demandez si vous pouvez faire confiance à l’entreprise : les informations divulguées sont ce qu’elles sont, et la réponse honnête est que les preuves se résument pour l’instant à la parole du fournisseur, plus ce que vous générez vous-même.