Jev est-il open source ? Les poids sont fermés, pas l’outillage

Non. Jev 1.13 (typesafe/jev-1.13) n'est pas open source, il n'existe aucun dépôt de poids à trouver, et aucun défilement, aussi long soit-il, dans l'organisation GitHub de TypeSafe ne fera apparaître un checkpoint, un document d'architecture ou un décompte de paramètres. Ce qui existe, c'est le logiciel autour du modèle : onze dépôts publics, tous sous MIT ou Apache-2.0, aucun ne contenant Jev lui-même. C'est la réponse honnête en une ligne — l'outillage est ouvert, le modèle ne l'est pas — et c'est la moitié de l'histoire qu'un lecteur n'obtient jamais de « fermé, hébergé, non publié » seul. Deux dates l'encadrent. TypeSafe a livré le modèle le 2026-09-15, ce qui est en dehors de la fenêtre de sept jours dans laquelle ce blog écrit, donc il ne s'agit pas d'un article de lancement et rien ici ne doit être lu comme tel. L'événement daté est le 2026-09-24, lorsque OrcaRouter a ajouté typesafe/jev-1.13 à son propre catalogue : la première fois que Jev a pu être appelé via une passerelle tierce plutôt que uniquement via le point de terminaison de TypeSafe. C'est l'exception sur laquelle repose cette page — un modèle devenu exécutable là où il ne l'était pas.

Ce que cela change pour un lecteur est limité et pratique. Avant le 24 septembre 2026, évaluer Jev impliquait d'ouvrir une seconde relation fournisseur avant même de pouvoir tester une seule décision. Après cela, Jev partage la même clé que la partie générative du même workflow : une API pour plus de 200 modèles, 0 % de marge (le prix catalogue du fournisseur est répercuté, donc les baisses de prix des fournisseurs sont effectives ici le jour même), avec le modèle accessible via typesafe/jev-1.13. Vous l'appelez toujours sous sa propre forme — POST /v1/systemone, non-streaming — car ce n'est pas la route chat-completions d'OpenAI, mais le contrat que vous signez et la clé que vous renouvelez sont ceux que vous avez déjà.

La réponse est deux réponses, et les deux sont nécessaires.

« Jev est-il open source ? » se lit comme une question fermée et se comporte comme une question en deux parties. Première partie : le modèle. Il est fermé. TypeSafe n’a publié ni les poids, ni de chiffres sur le calcul d’entraînement, ni le nombre de paramètres de Jev 1.13, et aucun dépôt ne porte son nom. Deuxième partie : le logiciel qui l’entoure. Il est ouvert, activement maintenu et véritablement utile, et c’est la raison pour laquelle un lecteur qui cherche un dépôt n’est pas simplement bredouille.

Confondre les deux conduit à une conclusion erronée dans les deux sens. Supposez que l’ensemble est ouvert et vous passerez un après-midi à chercher un point de contrôle qui n’existe pas. Supposez que l’ensemble est fermé et vous passerez à côté de l’élément qui compte vraiment si vous craignez l’enfermement propriétaire — un adaptateur sous licence MIT qui vous permet de construire par rapport à l’interface de décision typée et de changer ce qui se trouve derrière.

Ce que TypeSafe publie réellement

Consulté le 30 septembre 2026, l’organisation compte onze dépôts publics. Le nombre d’étoiles et les dates de push évoluent, alors considérez ceci comme un instantané plutôt que comme une propriété fixe du projet. Chaque licence est MIT ou Apache-2.0, sauf indication contraire.

• skills — MIT, environ 2,4 k étoiles, dernier push le 2026-09-12. « Compétences d'agent pour développer avec l'API System One de TypeSafe. »

• system-one-adapter-python — MIT, 356 étoiles, dernière mise à jour le 2026-09-22. « Remplacement immédiat de TypeSafeClient, propulsé par des API LLM. »

typesafe-sdk-js — MIT, 257 étoiles, dernier push le 2026-09-15. La bibliothèque officielle TypeScript/JavaScript pour l’API TypeSafe.

• typesafe-sdk-python — MIT, 254 étoiles, dernier push le 2026-09-26. La bibliothèque Python officielle ; la v0.7.2 a ajouté un extra `http2` ce jour-là, et la v0.7.1, le 2026-09-21, a ajouté des exemples d’utilisation avec des passerelles IA.

• daggerverse — Apache-2.0, 23 étoiles, dernier push le 2026-09-25. Une collection de modules Dagger.

• WorkflowEvals — Apache-2.0, 7 étoiles, dernière poussée le 2026-09-29. « Code de workflow evals.typesafe.ai publié. »

• n8n-nodes-typesafe-ai — MIT, 1 étoile, dernier push le 2026-09-29.

• typesafe-ai.github.io — aucune licence déclarée, 2 étoiles, dernier push le 2026-06-04.

Trois autres sont des forks de projets sans rapport et sont traités ci-dessous : pulumi-clickhouse, LLaDA et vllm.

Rien dans cette liste n’est le modèle. Il n’y a pas de dépôt Jev, pas de fichiers de poids, pas de tokenizer, pas de configuration de service — rien qui vous permettrait de monter une copie fonctionnelle. Les dépôts sont des éléments annexes côté client : deux SDK officiels, un pack de compétences d’agent, une collection de modules CI, une suite d’évaluations publiée, un nœud n8n, le site de l’organisation et l’adaptateur. C’est une surface réelle et bien entretenue, et ce n’est pas le modèle.

Le seul dépôt qui compte si vous cherchez à éviter l'enfermement.

system-one-adapter-python est l’entrée qui a le plus de conséquences pour quiconque prend une décision d’adoption, et sa propre description l’exprime clairement : « Un remplacement direct de TypeSafeClient s’appuyant sur des API LLM. »

Lisez cela attentivement, car cela fait quelque chose de précis. L'actif durable dans une intégration System One est l'interface, pas l'endpoint derrière elle : vous définissez un morceau d'état et un ensemble de questions nommées, et quelque chose renvoie une réponse typée par question. C'est autour de ce contrat que votre base de code finit par se structurer. L'adaptateur découple le contrat de l'implémentation — vous continuez à développer contre l'interface de décision typée, et ce qui produit les décisions est, en dessous, un appel d'API LLM interchangeable.

Deux réserves honnêtes. Un adaptateur n'est pas le modèle : les réponses produites par un LLM généraliste via ce chemin ne sont pas les probabilités calibrées que renvoie Jev, c'est donc un moyen de garder l'interface portable, pas un moyen d'obtenir le comportement de Jev sans Jev. Et c'est explicitement un projet TypeSafe — l'échappatoire est construite par le fournisseur dont vous pourriez vouloir vous échapper, ce qui vaut mieux que rien et n'est pas la même chose qu'une échappatoire indépendante.

Les deux bifurcations, et l’inférence à laquelle elles invitent.

Trois des onze dépôts sont des forks. pulumi-clickhouse est un fournisseur Pulumi pour ClickHouse Cloud, Apache-2.0, 3 étoiles, dernier push le 8 juillet 2026. Les deux autres sont ceux qui sont lus comme des preuves, et les deux lectures sont erronées.

• vllm — Apache-2.0, 3 étoiles, dernier push le 2025-05-23. Un fork du moteur d'inférence et de service à haut débit.

• LLaDA — MIT, 12 étoiles, dernier push le 2025-06-17. Un fork de l’implémentation officielle PyTorch pour « Large Language Diffusion Models ».

L’inférence paresseuse s’écrit d’elle-même : ils ont forké un dépôt de modèle de langage de diffusion, donc Jev doit être basé sur la diffusion. Ce n’est pas le cas, et le fork ne vous dit rien sur l’architecture de Jev. Un fork est une copie du code de quelqu’un d’autre sous la licence de quelqu’un d’autre, qui se trouve dans une organisation pour des raisons que sa propre date de dernier push rend évidentes — mai et juin 2025, plus d’un an avant la sortie publique de Jev, et sans modification depuis. Aucun des deux dépôts ne fait partie de ce que TypeSafe a publié en septembre. Si vous voulez savoir comment Jev fonctionne, TypeSafe ne l’a pas publié, et aucun fork dans son organisation ne comble cette lacune.

Ce que la fermeture des poids vous coûte réellement

Quatre choses, et elles sont concrètes plutôt que philosophiques.

• Vous ne pouvez pas l’auto-héberger. Il n’y a aucun artefact à exécuter, donc une panne de fournisseur ou une modification d’accès n’est pas quelque chose que vous pouvez contourner en déployant votre propre copie.

• Vous ne pouvez pas auditer. TypeSafe publie bel et bien une page consacrée à la « jaggedness » de Jev 1.13 — révisée pour la dernière fois le 2026-09-17 — qui recense les points où le modèle n’est pas fiable : la lecture littérale de la formulation plutôt que de l’intention, tout ce qui implique de l’arithmétique, la comparaison de dates et d’heures, l’indirection et les doubles négations, les états volumineux pleins de détails non pertinents, le contenu adversarial dans l’état, les instructions et critères contradictoires, et les invariants structurels qu’il ne garantit pas, comme le fait qu’une réponse vrai/faux et son choix équivalent oui/non soient en désaccord. Cette page est d’une franchise inhabituelle, et c’est encore le fournisseur qui corrige sa propre copie. Personne en dehors de TypeSafe n’a inspecté les poids.

• Vous ne pouvez pas faire de fine-tuning. Il n'y a pas de modèle de base à adapter, donc une tâche de décision que Jev gère mal reste mal gérée jusqu'à ce que le fournisseur la modifie — les remèdes propres à la page sur l'irrégularité sont des solutions de contournement dans votre code, et non des cycles d'entraînement.

• Vous ne pouvez pas épingler une version au-delà de l’alias du fournisseur. typesafe/jev-1.13 est un nom hébergé, donc ce qui répondra à un appel le mois prochain sera ce que TypeSafe servira sous ce nom à ce moment-là.

Rien de tout cela n'est propre à Jev, et rien de tout cela n'est un scandale ; c'est le compromis que fait un modèle de décision hébergé, et la contrepartie, c'est que vous n'avez jamais à porter un checkpoint, une facture de GPU ni une pile d'inférence. Il vaut la peine de savoir de quel côté du compromis vous vous situez avant de construire dessus.

Ce qu'est Jev, maintenant que vous pouvez l'appeler

Jev n’est pas un modèle de chat et ne génère pas de prose. Vous envoyez un état — le matériau à juger, sous forme de texte, d’objet ou de tableau — ainsi qu’un ensemble de questions nommées, et il renvoie une réponse structurée par question. Chaque question relève de l’une des trois primitives :

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

• choix — choisir l'une parmi un maximum de 255 options libellées.

• score — évaluer sur une échelle ordonnée de 2 à 10 niveaux.

La propre documentation de TypeSafe montre un exemple de score indexé à partir de 0 ; la fiche modèle Jev 1.13 publie des niveaux de 2 à 10. Les deux relèvent des propres documents du fournisseur et cette page n'invente aucune conciliation entre eux.

La méthode d'entraînement est une création propre à TypeSafe : Reinforcement Learning for Calibrated Decisions (RLCD), décrite dans l'article de lancement par opposition à RLHF et RLVR sur l'axe des décisions calibrées avec des probabilités honnêtes. RLCD est un terme de TypeSafe, et non un acronyme générique d'apprentissage automatique, et il convient de le lire comme une description commerciale plutôt que comme une technique caractérisée de manière indépendante.

L'accès n'est soumis à aucune restriction : Jev est disponible de façon générale depuis le 21 septembre 2026, et la « liste d'attente » n'a plus cours. « Early access » reste la formulation employée actuellement par TypeSafe sur sa page d'accueil : il ne s'agit donc pas d'une allégation à écarter d'emblée — c'est simplement l'appellation du fournisseur, et les limites opérationnelles qu'il publie en parallèle sont concrètes.

Les chiffres sur notre fiche : un contexte de 65 536 jetons, le fournisseur documentant environ 64 K d’entrée pour l’état et les questions combinés. Si vous avez vu un chiffre plus petit cité pour Jev, il s’agit du budget d’état seul, et non d’une mesure concurrente ; les deux ne doivent pas être présentés comme une contradiction. Le prix est de 0,042 $ par million de jetons d’entrée, la sortie étant facturée à zéro — il n’y a aucun jeton de sortie à comptabiliser, car une décision typée n’est pas de la prose.

Nos propres données de service, issues de notre trafic plutôt que du benchmark du fournisseur, sur les sept jours jusqu'au 30/09/2026 : 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 fenêtre a évolué ainsi : 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, avec une véritable valeur aberrante — un p95 de 2 448 ms le 28/09/2026, qui a sa place dans la série sans pour autant être la norme.

Les affirmations phares de TypeSafe, présentées comme celles du fournisseur et non répliquées de manière indépendante : « 193,6x plus rapide, 444,6x moins cher », avec un renvoi aux workflows System One ; un exemple chiffré de 0,000081 $ en 0,114 s contre 0,013880 $ en 8,566 s pour les LLM ; « 42 $ par milliard de jetons d'entrée » ; et « Zéro hallucination », qui est une affirmation sur les estimations de confiance plutôt qu'une preuve d'absence d'erreurs — le taux d'erreur de 0,49 % de notre fiche est le contrepoids honnête. TypeSafe indique aussi clairement qu'il ne peut pas prouver que sa tarification n'est pas subventionnée, et que ses évaluations publiées ont généralement été réalisées depuis des ordinateurs portables sur la côte Ouest, où le service est basé. Sa propre fiche de benchmark est encore marquée comme en attente.

Les dépôts tiers existent, et nous ne nous portons pas garants de ceux-ci.

Les recherches portant sur « jev github » finissent par faire apparaître des dépôts qui ne sont pas ceux de TypeSafe : des wrappers, des collections de prompts, des expérimentations d’adaptateurs et la fameuse liste « awesome » qui apparaît autour de tout nouveau modèle. Ils ne font pas partie de ce que l’éditeur publie, ne font l’objet d’aucune relecture de l’éditeur, et leur nombre d’étoiles mesure la curiosité plutôt que l’exactitude. Ils peuvent être utiles ; ils ne constituent pas de la documentation, et rien en eux n’est une affirmation sur le fonctionnement de Jev.

Qu’est-ce qui changerait cette réponse ?

Une publication de poids, une architecture publiée, ou une évaluation indépendante de la qualité de la décision plutôt que de la latence. N’importe laquelle des trois ferait basculer le premier mot de cette page. D’ici là, la recherche a une réponse stable, et la partie sur laquelle il vaut la peine d’agir est la chaîne d’outils : si l’interface de décision typée est ce sur quoi vous vous appuyez pour développer, un adaptateur sous licence MIT qui remplace le modèle sous-jacent fait la différence entre une décision que vous pouvez réexaminer et une que vous ne pouvez pas.

Jev 1.13 figure dans notre catalogue sous typesafe/jev-1.13, sur la même clé que le reste d'une stack et acheminé via le point de terminaison systemone dédié plutôt que via la forme chat-completions. Le modèle est fermé, l'outillage est ouvert, et les deux moitiés de cela sont désormais accessibles depuis un seul endroit.