Jev
des évaluations probabilistes pour les logiciels

Une personne peut écrire un ticket, mais cela ne fait pas de Jev son interlocuteur. Le logiciel extrait le contexte utile, appelle Jev et lit des valeurs. Il peut ensuite afficher une suggestion à cette personne, déclencher un traitement autorisé ou faire rédiger une réponse par un LLM. Cette séparation explique l’intérêt du produit : certaines étapes ont besoin d’une catégorie, pas d’une conversation.

Pour trier une issue GitHub, vous pouvez fournir son contenu et une liste de catégories. Avec Choice, Jev renvoie l’option retenue et les probabilités associées. Votre application utilise le résultat pour proposer une destination. C’est un exemple d’utilisation de l’API décrite par TypeSafe.

L’appel contient un contexte commun, appelé état ou state, et une ou plusieurs questions. Le programme précise la forme attendue : un choix dans une liste, une note sur une échelle ou la probabilité d’une réponse oui. Il peut ainsi traiter le résultat sans devoir extraire une catégorie d’un paragraphe.

Agrandir ↗

Ces 4 infographies originales s’inspirent de Jev Engineering 101, de Daniel Moka, publié le 22 septembre 2026. Elles présentent une organisation possible des traitements, sans décrire les composants internes de Jev. Visuels générés avec OpenAI puis relus ; valeurs d’exemple fictives.

Du résultat de l’API à l’action

• Le contexte est fourni par l’application. Une mention de paiement refusé dans un ticket n’établit pas l’état réel de la transaction. Pour agir sur celle-ci, le code doit récupérer les données utiles auprès du service concerné. Voir la documentation de State.
• Les questions d’un appel partagent le même état. Si une question doit utiliser la réponse d’une autre, le programme prépare un appel suivant. Le schéma représente 1 requête, sans supposer 1 seul passage interne du modèle.
• Le format et la justesse de la prédiction se vérifient séparément. Une réponse exploitable par le SDK peut être erronée. Définissez le délai maximal, les permissions et le repli avant d’exécuter une action ; choisissez les seuils à partir de vos erreurs acceptables. Voir comment garder les permissions dans le code.

Agrandir ↗

Un agent peut utiliser cette API pour choisir une destination ou évaluer un document, puis confier la rédaction ou l’enquête à un autre modèle. Cette utilisation ponctuelle ne démontre pas que Jev puisse remplacer le modèle qui pilote Claude Code.

Sur petit écran, les diagrammes peuvent se faire défiler horizontalement. Les figures peuvent être agrandies pour lire leurs libellés.

• TypeSafe indique avoir été fondée en 2024 et être basée à San Francisco.
• La page de l’équipe présente Diogo Almeida comme CEO, Erik Gafni comme CTO et Sasha Sheng comme COO.

Ces informations décrivent l’entreprise ; elles ne valident pas les performances de son modèle.

Diogo Almeida est coauteur d’InstructGPT. Le titre viral « co-inventeur de ChatGPT » réduit un travail collectif à une attribution personnelle ; « auteur principal d’InstructGPT » n’est pas davantage établi par la liste des auteurs. Le fait bibliographique utile est sa contribution à ce travail sur l’apprentissage à partir de retours humains.

• TypeSafe emprunte « System One » à la distinction de Daniel Kahneman entre pensée rapide et pensée délibérée.
• Jev renvoie à William Stanley Jevons et à l’idée qu’une baisse du coût peut accroître les usages.

Ces références expliquent le nom du produit ; elles ne décrivent pas ses couches neuronales. Origine des noms selon TypeSafe.

Agrandir ↗

La documentation détaille Choice, Score et Noul.

• Choice impose un choix exclusif. Pour plusieurs étiquettes compatibles, des questions binaires séparées peuvent convenir.
• Pensez aussi aux cas qui n’entrent dans aucune catégorie : une option absente de la liste ne pourra pas être sélectionnée.

• Dans l’entretien ThursdAI, une intervenante de TypeSafe explique comment décrire les niveaux de Score à 19:51, puis pourquoi des tags non exclusifs appellent des questions séparées à 23:00.
• Chez AICodeKing, l’exemple d’extraction à 03:55 consiste à choisir parmi des valeurs fournies au modèle.

La probabilité d’une option et le champ confidence répondent à 2 questions différentes.

• La première porte sur cette option.
• Le second résume la concentration des probabilités entre les options, selon la définition de TypeSafe. Il ne se lit pas directement comme la probabilité d’avoir raison.

Pour évaluer la calibration de Choice, prenez les cas où l’option retenue reçoit une probabilité proche de 80 %. Comparez ce nombre à la proportion de réponses réellement correctes. Cet exemple est pédagogique : aucun résultat Jev n’est mesuré ici. Avec Noul, vérifiez plutôt si les événements auxquels Jev attribue une probabilité de oui proche de 80 % se produisent dans environ 80 % des cas.

Ces comparaisons exigent des réponses de référence, assez d’exemples et un jeu de test qui n’a pas servi au réglage. Guo et al., 2017 présente les méthodes de calibration. Une bonne moyenne sur un jeu ne garantit pas chaque décision ni les résultats sur un autre domaine.

Mesurez aussi la couverture : quelle part des cas l’application traite-t-elle sans relecture ? Un système qui laisse presque tout à un humain peut faire peu d’erreurs tout en automatisant très peu. SelectiveNet étudie ce compromis. Ovadia et al. examine ce qui arrive aux mesures d’incertitude lorsque les données changent. Ces travaux ne portent pas sur Jev.

• Une ECE faible, l’écart moyen de calibration par tranches, peut masquer une classe rare mal calibrée ou une erreur dans la zone automatisée. Publiez les effectifs par tranche, un diagramme de fiabilité et les erreurs parmi les cas acceptés.
• Le score de Brier mesure l’écart au carré entre probabilités et résultats, avec une convention à préciser pour plusieurs classes.
• Pour Score, une moyenne de gravité reste une note sur l’échelle choisie.

TypeSafe annonce aussi qu’une confidence plus élevée accompagne une meilleure justesse dans son billet de lancement. Cette relation se teste : les réponses d’ASSAY-001 permettent de mesurer la justesse et la couverture après sélection par confidence. Cela ne transforme pas ce champ en probabilité de réussite ; le chapitre sur les mesures détaille les 2 calculs.

Le chapitre « Probabilités mesurées et seuils de confidence » distingue 2 mesures : la calibration des probabilités de l’option choisie et l’exactitude des réponses retenues par un seuil sur confidence. Les données ASSAY-001 permettent de recalculer les 2 ; Agent Journal rapporte la seconde sur une autre tâche.

Dans les vidéos, cette distinction est parfois perdue : Fireship à 03:15 assimile la confiance à une fréquence de bonnes réponses. Le chapitre vidéo corrige cette explication et conserve le passage original.

Un LLM génératif autorégressif construit sa réponse en prédisant les tokens suivants à partir du contexte et de ce qu’il a déjà produit. C’est le fonctionnement décrit dans la documentation de génération de Hugging Face. La sortie peut être du texte libre ou du JSON, éventuellement contraint par un schéma.

TypeSafe annonce une architecture nouvelle et un échantillonnage parallèle dans son billet de lancement. L’API reçoit un état et des questions typées, puis renvoie leurs résultats. Selon le fournisseur, les sorties sont calculées en parallèle plutôt que générées token après token. Le dessin compare ce comportement annoncé au fonctionnement d’un LLM autorégressif ; il ne décrit pas les composants internes de Jev.

La différence mise en avant porte sur l’usage prévu : Jev fournit des réponses typées et des probabilités que le code utilise dans sa logique de décision. Un LLM peut lui aussi être appelé par un logiciel et produire une sortie structurée ; dans une conversation, son texte est lu par une personne. Il faut donc distinguer le destinataire de la réponse et la façon dont le modèle la produit.

TypeSafe appelle son procédé d’apprentissage RLCD, pour Reinforcement Learning for Calibrated Decisions. Son introduction technique en expose l’objectif. « System One » est le nom de la famille de modèles, pas la description d’une architecture publiée.

La recherche menée pour ce dossier n’a pas trouvé de publication donnant assez de détails sur l’architecture, les données et l’objectif d’entraînement pour reproduire Jev. D’autres documents peuvent exister hors de ce périmètre. Dans l’entretien ThursdAI à 05:59, l’intervenante de TypeSafe évoque RLCD sans divulguer l’architecture. Décrire Jev comme un modèle « sans raisonnement interne » dépasserait les informations disponibles.

Les résumés de DeepSeek-R1 et Tülu 3 complètent cette sélection sans compter comme PDF acquis. Le chapitre suivant explique leur rapport avec l’apprentissage de Jev.

Une fonction de perte classique peut déjà encourager des probabilités correctes. Pour un événement de probabilité réelle q, l’espérance du score logarithmique q·log(p) + (1−q)·log(1−p) est maximale en p = q. Ce résultat théorique ne garantit pas qu’un modèle entraîné sur des données finies sera calibré sur un nouveau domaine. Cette formule illustre un principe ; elle n’est pas attribuée à RLCD.

Le papier Rewarding Doubt, version 6 étudie l’apprentissage d’une confiance exprimée en texte, avec une récompense logarithmique et PPO.

• Son PDF de 17 pages a été acquis ; mécanisme, résultats, transfert et preuve ont été examinés.
• La première version date du 4 mars 2025, la version 6 du 28 février 2026.
• Le théorème décrit un optimum de l’objectif, tandis que les résultats empiriques varient selon les jeux.

Aucun lien publié avec Jev n’a été établi.

Les résumés et historiques de DeepSeek-R1 et Tülu 3 complètent le contexte du post-entraînement. Leurs expériences n’ont pas été auditées pour ce dossier. Ils ne fournissent aucune preuve sur le nombre de paramètres, le backbone ou les données d’entraînement de Jev.

Dans l’entretien TechCrunch du 18 septembre, Diogo Almeida déclare que Jev est entraîné exclusivement sur des données synthétiques. Cela reste une déclaration rapportée : ni le corpus ni sa procédure de génération n’ont été audités ici. Des données synthétiques peuvent aussi dériver d’autres modèles ou de sources existantes ; cette qualification ne démontre pas une absence de contamination des benchmarks.

La référence HTTP documente POST https://api.typesafe.ai/v1/systemone, avec un jeton Bearer et un corps JSON contenant model, state et questions. GET /v1/models sert à lister les modèles : /v1/systemone n’est donc pas l’unique route de tout le service.

• L’état partagé peut être une chaîne, un objet ou un tableau JSON. Il peut contenir des nombres et des booléens.
• « Entrées textuelles » signifie ici qu’aucune entrée native image, audio ou vidéo n’est documentée pour le modèle ; cela n’oblige pas à convertir chaque valeur JSON en texte.
• Les identifiants des questions servent à retrouver les réponses et ne remplacent pas les instructions explicites.

{
  "model": "jev-1.13.0",
  "state": {
    "ticket": "Le paiement a échoué et je ne peux plus accéder à mon compte.",
    "language": "fr"
  },
  "questions": {
    "destination": {
      "type": "choice",
      "instructions": "Quelle catégorie décrit le mieux le sujet principal du ticket ? Évaluer les catégories à partir du texte fourni.",
      "criteria": {
        "facturation": "Paiement refusé, facture ou remboursement.",
        "acces_compte": "Connexion impossible ou accès au compte bloqué.",
        "incident_technique": "Panne ou erreur technique hors paiement et accès au compte.",
        "autre": "Aucun des sujets précédents."
      }
    },
    "payment_failed": {
      "type": "noul",
      "instructions": "Le message signale-t-il un paiement refusé ou échoué ?"
    },
    "impact": {
      "type": "score",
      "instructions": "Évaluer l'impact décrit, uniquement à partir du texte.",
      "criteria": [
        "Aucun impact décrit.",
        "Gêne contournable.",
        "Fonction indisponible pour la personne.",
        "Plusieurs utilisateurs bloqués."
      ]
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "destination": {
      "type": "choice",
      "choice": "facturation",
      "probabilities": {
        "facturation": 0.88,
        "acces_compte": 0.08,
        "incident_technique": 0.03,
        "autre": 0.01
      },
      "confidence": 0.81
    },
    "payment_failed": {
      "type": "noul",
      "noul": 0.97
    },
    "impact": {
      "type": "score",
      "score": 1.7,
      "legend": {
        "0": "Aucun impact décrit.",
        "1": "Gêne contournable.",
        "2": "Fonction indisponible pour la personne.",
        "3": "Plusieurs utilisateurs bloqués."
      },
      "probabilities": {
        "0": 0.0,
        "1": 0.3,
        "2": 0.7,
        "3": 0.0
      },
      "confidence": 0.6
    }
  },
  "usage": {
    "input_tokens": 500,
    "output_tokens": 80
  }
}

L’enveloppe contient model, answers et usage.

• Un compteur output_tokens peut exister même si son prix est nul.
• Conserver le modèle effectivement renvoyé et l’usage réel est plus précis que de noter seulement l’alias demandé.
• Le client Python consulté accepte des compteurs absents, représentés par None ; les types JavaScript v0.6.0 les déclarent numériques. Journaliser une absence au lieu de la compter comme 0.

Les structures et codes d’erreur figurent dans la référence native.

"""Exemple documentaire, non exécuté pour ce dossier.
Requiert typesafe-sdk et TYPESAFE_API_KEY dans l'environnement.
Exemple limité à la question Choice du fichier request.json.
"""
from typesafe_sdk import Choice, TypeSafeClient

with TypeSafeClient() as client:
    response = client.system_one(
        model="jev-1.13.0",
        state={
            "ticket": "Le paiement a échoué et je ne peux plus accéder à mon compte.",
            "language": "fr",
        },
        questions={
            "destination": Choice(
                instructions="Quelle catégorie décrit le mieux le sujet principal du ticket ? Évaluer les catégories à partir du texte fourni.",
                criteria={
                    "facturation": "Paiement refusé, facture ou remboursement.",
                    "acces_compte": "Connexion impossible ou accès au compte bloqué.",
                    "incident_technique": "Panne ou erreur technique hors paiement et accès au compte.",
                    "autre": "Aucun des sujets précédents.",
                },
            ),
        },
    )
    answer = response.choices["destination"]
    # Aucune action automatique : les seuils exigent une évaluation propre.
    print(response.model, answer.choice, answer.probabilities, answer.confidence)

// Exemple documentaire, non exécuté pour ce dossier.
// Requiert @typesafe-ai/sdk et TYPESAFE_API_KEY côté serveur.
// Exemple limité à la question Choice du fichier request.json.
import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const response = await client.systemOne({
  model: "jev-1.13.0",
  state: {
    ticket: "Le paiement a échoué et je ne peux plus accéder à mon compte.",
    language: "fr",
  },
  questions: {
    destination: choice("Quelle catégorie décrit le mieux le sujet principal du ticket ? Évaluer les catégories à partir du texte fourni.", {
      facturation: "Paiement refusé, facture ou remboursement.",
      acces_compte: "Connexion impossible ou accès au compte bloqué.",
      incident_technique: "Panne ou erreur technique hors paiement et accès au compte.",
      autre: "Aucun des sujets précédents.",
    }),
  },
});
const answer = response.answers.destination;
// Choice est déjà inféré ici ; cette garde vérifie seulement le type reçu.
if (answer.type === "choice") {
  console.log(response.model, answer.choice, answer.probabilities, answer.confidence);
}

• Dans le client JavaScript v0.6.0 inspecté, le délai est de 10 secondes par tentative et 2 nouvelles tentatives peuvent suivre l’appel initial pour certaines erreurs. Il n’expose pas de budget total de reprise.
• Le SDK Python distingue délai par opération HTTP et budget total de reprise.

Ces réglages doivent accompagner les mesures de latence. Reprises JavaScript, options JavaScript, politique de reprise Python.

Considérons un ticket : « Le paiement a échoué et je ne peux plus accéder à mon compte. » Demander « Quelle équipe ? » impose une priorité qui n’est pas écrite. Une liste exhaustive ne résout pas cette ambiguïté. Définissez d’abord la règle métier : 1 seule équipe pilote-t-elle l’incident, plusieurs étiquettes sont-elles autorisées, ou le cas doit-il être relu ?

Décomposer peut aider : détecter séparément le sujet, les informations manquantes et l’impact, puis appliquer une règle. Cela ajoute aussi des possibilités d’erreur.

• 2 réponses peuvent être incompatibles ; le code doit savoir quoi faire.
• Quand une question dépend d’une réponse précédente, utilisez des appels successifs et comptez leur temps total.

Une extraction avec Choice reste bornée aux valeurs candidates. Pour sélectionner une date, il faut que les dates possibles aient déjà été trouvées ou énumérées. Un exemple de choix parmi 3 dates ne prouve pas que Jev peut extraire librement n’importe quelle valeur d’un document. Vérifiez séparément la qualité de l’étape qui produit les candidats.

Agrandir ↗

La classification et les catégories fournies à l’appel existaient déjà. Un classifieur associe une entrée à des catégories. Avec l’inférence en langage naturel, ou NLI, on peut transformer une catégorie en proposition, puis demander si le texte la confirme. Les catégories n’ont donc pas toujours besoin d’être figées dans une tête entraînée pour 1 seule tâche. Le travail de Yin et al. en 2019 et le pipeline zero-shot de Hugging Face donnent des antécédents concrets à comparer à Jev.

L’API Jev réunit des questions Choice, Score et Noul sur un état commun. Cela facilite leur utilisation dans du code, sans réentraîner un modèle pour chaque ensemble d’options. Ce service peut simplifier le développement d’une application même si les techniques employées existaient déjà. Cette facilité d’utilisation ne prouve pas, à elle seule, une nouvelle architecture ou une meilleure calibration.

Le billet de lancement de TypeSafe expose lui-même des limites :

• l’entrée courte favorise sa démonstration ;
• les grands multiplicateurs se situeraient dans le haut des gains attendus ;
• les références des workflows sont des réponses de modèles.

L’adaptateur demande aux LLM des distributions de probabilités, plus coûteuses à produire qu’une décision seule. Comparer les mêmes sorties est utile pour évaluer ce que renvoie l’API ; une application qui ne demande qu’une catégorie doit aussi tester ce besoin plus restreint.

Les sorties structurées de Claude contraignent déjà le décodage selon les schémas pris en charge. La documentation détaille les limites, dont les refus, les troncatures et une exception de casse pour les valeurs enum et const. Il faut distinguer une consigne « réponds en JSON », un mode garantissant la syntaxe JSON et un décodage contraint par schéma. Présenter tous les LLM comme incapables de respecter un schéma fausserait la comparaison. La conformité du format ne garantit la bonne décision chez aucun des concurrents.

Pixel est le projet de Livio Gamassia. Comme moi, Livio est un membre actif de la communauté DevWithAI. Les sources inspectées sont décrites dans le chapitre sur les projets communautaires. Son routage, son graphe et ses scores explicites permettent déjà de prendre des décisions dans leur périmètre. Les embeddings ajoutent une recherche sémantique ; ils ne transforment pas tous les résultats en preuves exactes. Aucune comparaison exécutée ici n’établit que Pixel et Jev traitent avec la même qualité tous les critères exprimés en langage naturel.

Sur Hacker News, la description comme classifieur est acceptée. Le 15 septembre, petesergeant décrit Jev comme un classifieur zero-shot. CompleteSkeptic répond « exactly right! ». Ce compte se présente comme CEO de TypeSafe dans le même fil. Cet accord porte sur une description fonctionnelle ; il ne publie pas l’architecture ni ne valide les performances annoncées.

La discussion distingue aussi type valide et réponse correcte. Sur la publication de l’architecture, le même compte indique que l’équipe a discuté d’un article, tout en gardant les détails confidentiels. Ce commentaire ne donne ni engagement de publication ni date.

L’antériorité d’une idée et la copie d’un travail sont des questions distinctes. Nandakishor M, auteur de Laya, revendique des travaux antérieurs sur les décisions non autorégressives. Des notices de prépublications de 2025 existent ; son billet reconnaît aussi que son premier système ne traitait pas de nouvelles questions à l’exécution. Ces éléments permettent de discuter la nouveauté revendiquée. Ils ne démontrent pas que TypeSafe a repris son code ou sa méthode. Les résumés ont été consultés, sans audit des PDF.

Les analyses vidéo confrontent aussi les avis favorables aux contre-exemples : jeu de dames de Theo, erreurs décrites par Gary Explains et tri de commentaires d’Erwan. Les réserves de Fireship sur le format sont utiles ; son explication de confidence demande une correction. Aucun de ces passages n’établit à lui seul une escroquerie.

Le chiffre de 150 ms figurait dans le post LinkedIn à l’origine de cette recherche. Je n’ai pas retrouvé de source primaire qui en fasse une latence générale du service. La plage du billet et les mesures datées des essais sont plus utiles pour préparer une comparaison.

Les évaluations TypeSafe donnent le même poids à 4 workflows : incidents de sécurité, traces d’agents, factures et support. Leurs références sont produites par GPT-6 Astra et Claude Fable 5.1 en raisonnement élevé ; les modèles comparés utilisent leurs réglages par défaut. La colonne appelée accuracy mesure donc un accord avec ces références, pas avec des annotations humaines indépendantes.

Valeurs arrondies lues dans les graphiques du fournisseur le 21 septembre.

• Jev coûte moins et répond plus vite dans cet agrégat ; sol et Opus 5 ont un meilleur accord.
• Sur les factures, Jev atteint 61,8 % contre 79,1 % pour sol.
• Les 4 accords Jev sont 61,7 %, 71,6 %, 61,8 % et 76,0 %. Leur moyenne vaut 67,775 %, cohérente avec l’affichage à 67,8 %.

Les multiplicateurs de lancement ne se recalculent pas en divisant arbitrairement 2 cellules arrondies de ce tableau.

Agrandir ↗

Le calcul de base est simple : tokens d’entrée facturés × tarif par token. Avec le tarif direct cité dans ce dossier, 1 000 tokens coûtent 0,000042 dollar. 1 million d’appels de cette taille coûte donc 42 dollars d’entrée. Ce calcul ne suppose ni que chaque appel est correct, ni que 1 seul appel suffit pour terminer une tâche.

Le traitement de plusieurs questions et la réutilisation du contexte changent les volumes facturés.

• Relevez les compteurs usage lorsqu’ils sont présents. S’ils sont absents, consignez « inconnu » dans les journaux, jamais 0 token : les clients Python et JavaScript ne déclarent pas ces champs de la même façon.
• Une estimation à partir du ticket ne remplace pas la facture.
• Les quotas, erreurs et reprises comptent aussi dans la chaîne.

• Le coût par décision correcte divise le coût complet par le nombre de décisions correctes, en précisant si celles corrigées par une personne sont incluses.
• Pour une tâche répétée, publiez aussi le coût par dossier terminé et les minutes de relecture mesurées.

Une solution qui réduit le prix du modèle mais augmente les corrections peut coûter davantage.

Agrandir ↗

Dans une chaîne successive, les durées des étapes s’additionnent. Des questions indépendantes peuvent être parallélisées, mais le gain dépend des quotas et de la distribution des temps de réponse. Mesurez le temps entre la réception du dossier et la suggestion exploitable par l’application, puis les p50 et p95 de ce temps complet.

Le benchmark de phishing d’anisselbd porte sur 2 000 emails aux corps synthétiques. Le premier protocole pose 9 questions à Jev et demande un verdict direct à Haiku 4.5. Jev y obtient 62,6 % de décisions correctes contre 81,3 %. Ces 2 configurations ne permettent pas d’isoler le seul effet du modèle.

Un second protocole pose les mêmes 5 questions aux 2 modèles puis apprend une régression sur leurs signaux. Sur les 1 000 cas réservés au test : 95,0 % avec Jev, 93,2 % avec Haiku, contre 91,8 % pour la référence fondée sur des règles. L’écart Jev/Haiku n’est pas significatif au seuil usuel de 5 % (McNemar p = 0,063). Les auteurs rapportent aussi l’avantage de Jev en coût et en latence pour cette décomposition.

La formulation et l’assemblage des réponses font partie du système évalué. Passer du verdict direct à 5 signaux change le protocole ; ces résultats restent propres à ce corpus.

Le nDCG@10 mesure la qualité du classement des 10 premiers documents. Un reranker reclasse des documents déjà retrouvés. Les valeurs anglaises ne montrent pas de vainqueur établi ; l’intervalle qui contient 0 ne démontre pas non plus une équivalence. Ces tests ne mesurent pas, à eux seuls, la qualité d’une réponse rédigée à partir des documents.

Ces observations ne permettent pas de comparer les régions entre elles : les entrées, les questions et les protocoles diffèrent. Elles donnent des repères plus précis qu’une latence générale de 150 ms.

Le rapport ASSAY-001 évalue Jev sur Banking77 et CLINC150, 2 corpus publics de classification d’intentions. Pour ce dossier, les réponses publiées de Banking77 et CLINC150 ont été récupérées et leurs empreintes contrôlées. Le recalcul porte sur les probabilités, les décisions et le champ confidence. Il exploite la campagne publiée, sans nouvel appel au modèle.

L’ECE compare la probabilité de l’option renvoyée au taux de bonnes décisions, par tranches.

• Le script de calcul utilise 10 tranches : [0 ; 0,1], puis ]0,1 ; 0,2], jusqu’à ]0,9 ; 1]. Une valeur de 0,9 appartient donc à l’avant-dernière tranche.
• Chaque écart absolu pèse proportionnellement au nombre de réponses dans sa tranche.

L’ECE porte sur la probabilité de l’option choisie, même dans les 3 cas où elle diffère du maximum affiché ; elle ne porte pas ici sur confidence.

Le protocole retient ECE ≤ 0,05 comme critère pour cette étude. CLINC150 le satisfait, Banking77 non. Ce seuil n’est pas une norme générale. L’ECE dépend aussi du découpage : avec des tranches fermées à gauche, [0 ; 0,1[ jusqu’à [0,9 ; 1], celle de CLINC150 passe de 0,0204 à 0,0209 sur les mêmes réponses amendées. Aucun des 2 découpages ne change le verdict au seuil de 0,05. Ces résultats n’isolent pas l’effet du nombre de classes ; le corpus avec davantage d’options a ici l’ECE la plus faible.

Le deuxième amendement, décrit dans le rapport, relève après la mesure la tolérance sur la somme des probabilités, de 0,001 à 0,02. Il réintègre 145 réponses Banking77 et 368 réponses CLINC150 dont la somme vaut 0,99 à la précision publiée. La documentation Vercel du fournisseur TypeSafe AI précise que les probabilités sont arrondies à 2 décimales et peuvent ne pas totaliser exactement 1. Les données sont compatibles avec cette précision : 101 valeurs centésimales distinctes, en écartant le bruit de représentation des nombres flottants. Ce comptage seul ne révèle pas le procédé interne d’arrondi. Une somme de 0,99 ne suffit donc pas à établir une erreur de type.

La réintégration baisse l’exactitude sur les 2 corpus. Elle augmente l’ECE de Banking77 et réduit légèrement celle de CLINC150. Le changement de tolérance modifie donc aussi la population évaluée ; il faut conserver les 2 résultats pour comprendre son effet.

Un autre contrôle retrouve 3 choix inférieurs de 1 point de probabilité au maximum affiché : 0,46 contre 0,47 et 0,47 contre 0,48 dans Banking77 ; 0,48 contre 0,49 dans CLINC150. La référence API décrit choice comme l’option la plus probable. Un arrondi monotone appliqué de la même manière à chaque option ne peut, à lui seul, inverser leur ordre. Ces 3 écarts restent donc à expliquer ; les valeurs internes avant affichage ne sont pas publiées.

Les fichiers ASSAY permettent aussi de vérifier ce que garde un filtre confidence ≥ 0,9.

• Dans le tableau suivant, la couverture est la part des réponses exploitables conservée par ce filtre.
• L’exactitude est calculée seulement parmi ces réponses conservées, avec la tolérance amendée sur les sommes.

Le chiffre de 72,2 % relayé par des articles de synthèse vient d’Agent Journal. L’auteur décrit 300 cas synthétiques ; 126 ont une confidence d’au moins 0,9 et 72,2 % de leurs réponses sont correctes. Les réponses brutes n’ont pas été retrouvées dans les liens et la recherche ciblée. Ce résultat reste rapporté par l’auteur, sans recalcul dans ce dossier.

La couverture annoncée par Agent Journal est de 42 %. La tâche demande de combiner des indices faibles dans des textes synthétiques ; elle diffère des intentions Banking77 et CLINC150. L’auteur indique l’alias jev-latest, sans version résolue vérifiable dans des réponses brutes. Ces résultats peuvent coexister : les protocoles, les données et éventuellement les versions diffèrent. Ils ne permettent pas d’isoler la cause de l’écart.

Les 3 expériences conservent des erreurs après sélection par confidence. L’exactitude et la couverture de cette sélection ne sont pas des mesures d’ECE. Comme confidence n’est pas contractuellement la probabilité d’avoir raison, comparer le seuil 0,9 à 72,2 %, 92,61 % ou 96,11 % ne mesure pas la calibration des probabilités des options.

• Pour Agent Journal, l’absence de distributions brutes et de labels associés empêche ce recalcul de calibration.
• Pour ASSAY, ces données sont disponibles et l’ECE figure plus haut.

Le 8 octobre, Astronomer observe que chaque modèle de décision a sa propre échelle de confidence : sur le jeu riche en erreurs intermittentes, médiane de 0,94 pour Jev 1.13, 0,84 pour decider-0.8b et 0,45 pour GLiNER2.5-Decide. La confidence de Jev varie jusqu’à 0,14 entre 2 appels répétés. Un seuil choisi pour Jev ne se transfère donc pas à un autre modèle compatible.

• Le tutoriel Building a Harness with Jev, publié par Sydney Runkle et Hunter Lovell le 17 septembre, explique une intégration.
• Les chiffres repris dans ExplainX viennent d’une autre source : le dépôt jev-as-a-judge.

Le tutoriel, l’article de reprise et le benchmark ont des fonctions différentes.

Le test prend 5 traces fixes, répétées 100 fois chacune. 1 seul annotateur fournit les labels de référence : 4 réussites et 1 échec. Sur la trace Dublin, la clarification paraît raisonnable mais ne satisfait pas la rubrique qui attend une recherche. Le choix de cette rubrique fait donc partie du résultat.

Ces taux concordent avec les résumés publiés par cas. Les décisions élémentaires ne figurent pas dans l’archive consultée : elles n’ont pas été recomptées. Les 5 traces et les répétitions doivent rester visibles dans toute présentation du « 100 % ».

Les résumés du fichier benchmark.json donnent aussi la moyenne des variances de quality, calculées à l’intérieur de chacune des 5 traces. Le tableau recalcule les rapports à partir de ces résumés ; les jugements élémentaires ne sont pas disponibles pour recalculer les variances elles-mêmes.

Ces rapports décrivent la stabilité d’un score continu sur les mêmes traces. Ils ne multiplient ni le taux de bonnes décisions ni la précision des probabilités.

• Le juge Jev assemble 3 réponses Noul pour quality et utilise un autre appel pour le verdict binaire.
• Les rubriques des juges ne sont pas formulées à l’identique : cette expérience n’isole pas un effet de l’architecture.

Les métadonnées de cette exécution datent du 18 septembre.

• Elles nomment les 3 modèles LLM et signalent un arbre de travail modifié lors du lancement. Le code archivé n’est donc pas une garantie de retrouver tous les fichiers exacts de cette exécution.
• La version du modèle Jev hébergé n’est pas indiquée ; la version du client LangChain ne permet pas de la déduire.

Le script de collecte des coûts interroge LangSmith. Le périmètre des moyennes et des totaux ne se réduit pas clairement aux 500 verdicts. Luna apparaît par ailleurs proche de Jev en coût dans leur tableau. La comparaison ne justifie donc pas l’affirmation que tous les LLM coûteraient plusieurs ordres de grandeur de plus.

Pour tester Jev comme juge, variez les tâches, les outils utilisés, les échecs partiels et les rubriques, puis faites annoter des traces nouvelles. Répéter une trace est utile pour mesurer la stabilité ; ajouter des traces différentes est nécessaire pour tester la couverture des situations.

Theo à 12:40 critique le choix entre plusieurs implémentations par un juge qui n’explore pas le dépôt. Cette objection rappelle de tester un critère précis avec le contexte nécessaire. Elle n’établit pas qu’un modèle sans raisonnement rédigé ne puisse jamais servir de juge. L’analyse de la vidéo distingue ces 2 affirmations.

Le protocole JevGrep ajouté le 22 septembre distingue performances locales avec fournisseur simulé et pilote de recherche sémantique. Il définit 30 questions sur 3 petits dépôts synthétiques, dont 6 négatives. La présence de ce protocole ne prouve ni un résultat final réservé ni un gain sur la réussite d’un agent.

Capital & Compute rapproche plusieurs résultats, mais ceux-ci ne partagent ni tâche, ni comparateur, ni définition du coût. Le résultat sur 18 514 emails est relayé par Arize, qui renvoie à bitnovus. Le compter 1 fois pour chaque article multiplierait artificiellement les confirmations.

Ces essais sont plus utiles lorsqu’on conserve leur objet précis.

• Le test de produits ressemble à un rapprochement Sentry : rechercher des candidats, puis juger une paire. L’annotation et le coût d’une erreur restent pourtant différents.
• Les scores du code-review ne prédisent pas la qualité d’une revue de PR avec plusieurs fichiers et des règles métier.

• Capital & Compute rapporte aussi son propre essai sur 483 requêtes Search Console : Jev est appelé, mais les coûts des autres modèles sont calculés et seuls 18 exemples font l’objet d’un contrôle humain. Ce résultat n’est donc pas une comparaison d’exécutions complètes de tous les concurrents.
• Les chiffres Every repris dans ce circuit ne sont pas intégrés comme résultats vérifiés ici : l’article a été localisé, mais son corps et les pièces liées n’étaient pas lisibles.

L’analyse CounterProof sur les labels par consensus relève 8 divergences parmi 19 cas où ses 2 juges répondent. Ces cas proviennent d’une sélection de 20 exemples du fournisseur, pas d’un échantillon aléatoire de toute l’évaluation. Ce contrôle invite à discuter les labels ; il ne remplace pas ceux-ci par une vérité terrain humaine ni ne rejoue le benchmark complet.

L’article MindStudio sur Jev et les classifieurs rapporte notamment 93,2 % pour un encodeur de 22 millions de paramètres. Le corps consulté ne donne pas de lien vers le protocole ou le dépôt de cette expérience. Ce chiffre n’est donc pas ajouté au tableau des résultats vérifiés à la source. L’article rapporte aussi un résultat inverse sur Yelp ; il ne justifie pas la conclusion générale selon laquelle un classifieur entraîné gagnerait toujours.

Jev a ouvert la catégorie le 15 septembre. En 4 semaines, Cloudflare, Strands Labs, Perplexity et OpenAI ont publié des modèles qui répondent aux mêmes types de questions : oui ou non, choix parmi des options, note sur une échelle. Ils renvoient des probabilités, pas un texte à analyser.

Deux formats d’appel coexistent. System One, l’interface de Jev, envoie un state et des questions nommées de type noul, choice ou score. Clef, Strands Decider et Ollama 0.35 le reprennent. OpenAI utilise /v1/decisions : un input, un tableau de questions predicate, choice ou score, jusqu’à 400 questions, et une réponse refusal possible pour chaque question. LiteLLM sert les 2 routes depuis le 14 octobre.

Cloudflare présente Clef comme premier du Jev Decision Index ; sa propre table laisse Jev devant sur When2Call, BRIGHT et les traces d’agents. Le billet de lancement affirme aussi que les Clef battent les autres modèles de décision en latence, sauf Laya. Sa table donne pourtant 51,4 ms de médiane pour Kev-9B et 84,4 ms pour DiffusionGemma Jev, contre 209,3 ms pour Clef. Le 9 octobre, Cloudflare annonce 152 ms de médiane pour Clef sur environ 800 tokens, grâce à un changement de couche de service, sans nouveaux poids. Le même billet raconte que le projet a été décidé un vendredi soir, entraîné pendant le week-end et lancé le jeudi.

Les évaluations de Perplexity (pplx-decider) et de Strands Labs (Strands Decider) sont aussi des mesures d’éditeurs. La fiche de Strands Decider 2B v1-2610 annonce 180 bonnes réponses sur les 231 tâches publiques de JevBench, avec une fenêtre de 4 096 tokens.

3 évaluations publiées par des tiers. Aucune ne compare tous les modèles sur une même tâche, et aucune n’a été reproduite pour ce dossier.

• Chez Astronomer, au seuil 0,8, Jev 1.13 arrête 147 tâches dont 15 récupérables, Clef 112 dont 5, Clef-flash 133 dont 11 et Strands Decider 63 dont 2. Moins d’erreurs va avec moins d’arrêts justes : 128, 105, 118 et 61 sur 222.
• Reformuler les descriptions de catégories change 5 à 14 % des décisions de chaque modèle ; la confidence de Jev varie jusqu’à 0,14 entre 2 appels répétés.
• Des règles placées avant le modèle produisent 25 arrêts, tous justes.
• Sur le JevBench Index, l’écart entre Jev 1.13 et Clef est de 0,4 point : un même tableau ne suffit pas à les départager.

Le laboratoire a été exécuté sur un Mac Apple M5 Max, 128 Gio, macOS 26.5.1, Python 3.12.13, Laya-MLX 0.2.0 et MLX 0.32.2, sur GPU en FP16. Modèle : aac6fef/laya-multilingual-mlx, révision f2b4faf51023039425946074e2cf1361d2db11d5. Compilation et cache de prompts désactivés. Les 11 fichiers du manifeste ont été vérifiés, dont environ 614 Mio de poids.

Les données contiennent 72 exemples synthétiques de développement. Les 3 tâches ci-dessous utilisent 20 exemples chacune, soit 60 prédictions. Questions, labels et mots-clés ont été figés avant l’inférence. Le validateur de scores ordinaux de l’évaluateur a été renforcé avant les rapports ; sa version finale est archivée. Ce n’est ni un test indépendant sur des données réelles, ni une annotation humaine indépendante. Aucun réglage n’a été modifié pour effacer les erreurs observées.

Protocole de vitesse : 10 appels de chauffe puis 100 appels successifs par configuration, avec le même texte court. Le temps inclut la validation du moteur, mais exclut chargement, HTTP et navigateur. Chargement mesuré : 5,45 s. Pic d’allocation MLX : environ 822 Mio, pas toute la mémoire du processus. Ce n’est pas un débit général de documents longs. Ces mesures ne sont pas directement comparables aux appels distants Jev ni aux données M3 Max du chapitre sur les modèles locaux.

Les données et mesures de cette révision contiennent les exemples synthétiques, questions, prédictions, références lexicales, échantillons de latence et empreintes des preuves. Aucune donnée client ou conversation privée n’y figure.

La question était limitée : à quel domaine technique appartient la modification demandée ? Les options étaient tooling, backend, frontend, fullstack, multiple, other et unknown. Le pilote ne mesure ni les doublons, ni la complétude du ticket, ni le type de demande. Aucune étiquette GitHub n’a été modifiée et aucune automatisation n’a été activée.

La précision divise les suggestions conformes par les suggestions émises. La couverture divise les suggestions émises par les 60 tickets, y compris ceux trop longs. 8 sur 60 n’est donc pas la précision de Laya. Il laisse 49 tickets sans suggestion, contre 43 pour les règles actuelles. Ces cas nécessitent une autre prise en charge ; ils ne sont pas tous des classifications erronées.

La variante lexicale réutilise les expressions et leur priorité sur le titre et le corps. Elle n’est pas le workflow déployé. Elle donne aux règles davantage de texte, comme à Laya : son résultat ne doit pas être confondu avec celui de la référence titre seul. Ses 40 suggestions conformes en font une piste à faire vérifier humainement, avec 11 erreurs à examiner ; aucun gain de temps n’a été mesuré.

Le modèle a produit 52 sorties structurées valides et 8 refus de longueur, sans autre erreur technique observée dans le lot test. Les questions et options laissent 896 tokens au texte sérialisé dans la limite totale de 1 024. Les 8 dépassements représentent 13,3 % du test. Les 8 suggestions conformes de Laya concernent toutes l’outillage ; aucun succès de suggestion n’est obtenu pour les autres domaines sur cet échantillon.

Ces temps ne sont pas interchangeables avec les 8,55 ms du filtre synthétique du chapitre précédent : entrées, question et périmètre diffèrent. Les autres activités du Mac n’étaient pas contrôlées. Aucun appel à une API d’inférence distante ni repli cloud ; chaque processus de calcul a vérifié un refus réseau EPERM. L’export GitHub nécessitait du réseau. Énergie et temps humain de correction n’ont pas été mesurés.

Une suggestion est une réponse same pour Sentry/reviews, ou une orientation code, configuration ou infrastructure pour la CI. La précision divise les suggestions conformes par les suggestions proposées. La couverture rapporte les suggestions à tous les cas test, y compris ceux trop longs : 79,2 % pour Sentry, 25,0 % pour les reviews et 55,6 % pour la CI. Un comparateur qui ne propose rien n’a pas une précision de 0 % ; elle est non définie.

Sentry : aucun rapprochement conforme supplémentaire au-delà des liens connus. Le zéro lexical concerne les paires après masquage des liens et identifiants. Parmi les 48 paires, 16 ont déjà une association Sentry explicite dans la provenance GitHub. Les 2 suggestions Laya conformes appartiennent à cet ensemble. Un lien documentaire ne prouve pas à lui seul une cause commune.

CI : 1 suggestion conforme de plus au total, mais 13 erronées de plus. Laya propose 6 orientations conformes et 14 non conformes, contre 5 et 1 pour les signatures lexicales. Ses 20 suggestions sont toutes code : 6 concordent, 8 portent sur des cas annotés configuration et 6 sur des cas inconnus. Aucune orientation configuration ou infrastructure n’est proposée sur ce test.

Pour les reviews, Laya propose 1 rapprochement conforme et 8 non justifiés. Le macro-F1 légèrement supérieur au comparateur ne suffit donc pas à qualifier le regroupement. La tâche consiste à reconnaître le même défaut allégué ; elle ne vérifie pas que ce défaut existe.

Les 15 dépassements sur 120 cas test restent dans les dénominateurs. Les décisions different, unknown et les abstentions ne sont pas des rapprochements erronés. Elles restent distinctes des erreurs de contexte. Aucun autre type d’erreur d’inférence n’est rapporté.

Les refus de contexte sont comptés séparément des quantiles. La charge globale du Mac n’est pas contrôlée ; collecte, annotation et correction humaine ne sont pas incluses. Ces temps ne mesurent pas un gain de temps humain et ne sont pas interchangeables avec ceux des autres tâches.

Les vidéos donnent des idées de tests et montrent aussi des échecs. Un même auteur peut apprécier la rapidité de Jev tout en critiquant ses décisions. Les avis sont attribués ci-dessous ; les résultats annoncés restent ceux de leurs auteurs. Aucun de ces essais n’a été reproduit pour ce dossier.

La présentation de l’épisode ThursdAI du 17 septembre identifie Allie Laabs comme Founding DevRel chez TypeSafe. Les liens ci-dessous utilisent les minutes de l’extrait YouTube consacré à Jev, distinctes de celles de l’épisode complet.

La courte vidéo Jev Doom Demo SoftBed est une reprise commentée, sans expérience indépendante identifiée. Dans la démo originale, TypeSafe indique que Jev reçoit un état textuel du jeu, pas les images. Ni cette reprise ni une vidéo montée ne mesurent la capacité générale à jouer. Les liens minutés de ce dossier ont été contrôlés dans les transcriptions, sans audit audiovisuel des compteurs affichés.

Jev est un service hébergé. Vous installez ici la bibliothèque cliente Python qui appelle son API. Les poids de Jev ne sont pas téléchargés sur votre machine. Le résultat sert au programme : aucune conversation avec un chatbot n’est nécessaire.

1. Obtenir une clé et vérifier Python.

• Ouvrez la console TypeSafe et créez une clé API si votre compte dispose de l’accès au service.
• Il faut Python 3.10 ou plus récent et une connexion Internet.
• Ce parcours utilise l’API directe de TypeSafe ; une clé d’un autre fournisseur ne convient pas.
• L’accès de votre compte et sa facturation se vérifient dans la console.

2. Installer le client dans un dossier dédié. Dans un terminal macOS ou Linux, lancez les commandes suivantes. Vérifiez que la version affichée de Python est au moins 3.10 avant de continuer. La version du SDK est fixée à 0.7.0 pour pouvoir reproduire l’exemple avec la même version du client.

mkdir jev-premier-appel
cd jev-premier-appel
python3 --version
python3 -m venv .venv
source .venv/bin/activate
python -m pip install "typesafe-sdk==0.7.0"

3. Créer le script. Dans ce dossier, enregistrez le bloc suivant dans premier_appel.py. La clé est lue dans TYPESAFE_API_KEY si cette variable existe ; sinon, le programme la demande dans le terminal avec une saisie masquée. Elle ne figure ni dans le fichier ni dans le prompt pour l’assistant.

"""Un ticket fictif, une tentative API et une catégorie prédite affichée.

Requiert Python 3.10+ et typesafe-sdk==0.7.0.
Lancer ce fichier envoie une requête à TypeSafe, facturable selon le compte.
"""
import getpass
import json
import os
from time import perf_counter

from typesafe_sdk import (
    Choice, RetryPolicy, TypeSafeAPIConnectionError, TypeSafeAPIError, TypeSafeClient,
)


def main():
    api_key = os.environ.get("TYPESAFE_API_KEY", "").strip()
    if not api_key:
        api_key = getpass.getpass("Clé API TypeSafe (saisie masquée) : ").strip()
    if not api_key:
        raise SystemExit("Aucune clé fournie ; aucun appel envoyé.")

    try:
        with TypeSafeClient(
            api_key=api_key,
            base_url="https://api.typesafe.ai",
            retry=RetryPolicy(max_retries=0),
            timeout=30.0,
        ) as client:
            start = perf_counter()
            response = client.system_one(
                model="jev-1.13.0",
                state={
                    "ticket": "Le paiement a échoué et je ne peux plus accéder à mon compte.",
                    "language": "fr",
                },
                questions={
                    "destination": Choice(
                        instructions=(
                            "Quelle catégorie décrit le mieux le sujet principal du ticket ? "
                            "Évaluer les catégories à partir du texte fourni."
                        ),
                        criteria={
                            "facturation": "Paiement refusé, facture ou remboursement.",
                            "acces_compte": "Connexion impossible ou accès au compte bloqué.",
                            "incident_technique": "Panne hors paiement et accès au compte.",
                            "autre": "Aucun des sujets précédents.",
                        },
                    ),
                },
            )
            elapsed = perf_counter() - start
    except TypeSafeAPIError as error:
        raise SystemExit(f"Erreur API TypeSafe : HTTP {error.status}.") from None
    except TypeSafeAPIConnectionError:
        raise SystemExit("Connexion à TypeSafe impossible ou délai HTTP dépassé.") from None

    answer = response.choices["destination"]
    print(json.dumps({
        "model": response.model,
        "proposition": answer.choice,
        "probabilities": answer.probabilities,
        "confidence": answer.confidence,
        "duree_appel_secondes": round(elapsed, 3),
        "usage": {
            "input_tokens": response.usage.input_tokens,
            "output_tokens": response.usage.output_tokens,
        },
    }, ensure_ascii=False, indent=2))


if __name__ == "__main__":
    main()

4. Envoyer le ticket fictif. Avec l’environnement virtuel toujours actif, lancez la commande ci-dessous.

• Elle effectue une tentative SDK vers TypeSafe, facturable selon les conditions de votre compte.
• Les reprises automatiques sont désactivées.
• Le délai de 30 secondes s’applique aux opérations HTTP ; il ne garantit pas une durée totale de 30 secondes.

python premier_appel.py

5. Lire la catégorie prédite. Le programme affiche un objet JSON avec l’option Choice et ses probabilités. Le ticket mentionne deux sujets : observez leur distribution sans attendre une priorité de traitement imposée au modèle. Le script ne déplace aucun ticket. Un premier appel réussi confirme le fonctionnement de la connexion pour ce cas ; il ne mesure pas la fiabilité du classement.

La décision appartient au code : démonstration hors réseau. Pour un ticket qui cumule paiement échoué et accès bloqué, deux Noul peuvent évaluer séparément ce que le texte mentionne. Ces signaux ne prouvent pas l’état réel de la transaction ou du compte. Le bloc suivant déclare les questions sans les envoyer et utilise uniquement des réponses fictives. Enregistrez-le dans decision_policy.py, puis lancez python decision_policy.py avec Python 3.10 ou plus récent ; aucune clé ni bibliothèque tierce n’est nécessaire.

"""Démonstration hors réseau : valeurs et seuils fictifs, aucun appel Jev."""
import json

# Deux questions indépendantes à poser à Jev ; ce fichier ne les envoie pas.
questions = {
    "payment_failed": {
        "type": "noul",
        "instructions": "Le ticket mentionne-t-il un paiement refusé ou échoué ?",
    },
    "access_blocked": {
        "type": "noul",
        "instructions": "Le ticket mentionne-t-il un accès au compte bloqué ?",
    },
}


def decide_route(probabilities, *, threshold=0.8, priority="facturation"):
    # Politique pédagogique conservatrice, seuil non validé pour la production.
    if not 0.5 < threshold <= 1 or priority not in ("facturation", "acces_compte"):
        raise ValueError("Politique invalide")
    payment = probabilities["payment_failed"]
    access = probabilities["access_blocked"]
    if not (0 <= payment <= 1 and 0 <= access <= 1):
        raise ValueError("Probabilités attendues entre 0 et 1")
    if payment >= threshold and access >= threshold:
        return priority
    if payment >= threshold and access <= 1 - threshold:
        return "facturation"
    if access >= threshold and payment <= 1 - threshold:
        return "acces_compte"
    return "relecture"


# Réponses simulées aux deux Noul, réutilisées sans nouvel appel.
probabilities = {"payment_failed": 0.92, "access_blocked": 0.88}
proposals = {
    "billing_first": decide_route(probabilities, priority="facturation"),
    "access_first": decide_route(probabilities, priority="acces_compte"),
    "higher_threshold": decide_route(probabilities, threshold=0.95),
}
assert proposals == {
    "billing_first": "facturation",
    "access_first": "acces_compte",
    "higher_threshold": "relecture",
}
assert decide_route({"payment_failed": 0.52, "access_blocked": 0.48}) == "relecture"
assert decide_route({"payment_failed": 0.92, "access_blocked": 0.10}) == "facturation"
assert decide_route({"payment_failed": 0.10, "access_blocked": 0.92}) == "acces_compte"
print(json.dumps({"questions": questions, "simulated_probabilities": probabilities,
                  "application_proposals": proposals}, ensure_ascii=False, indent=2))

Les mêmes probabilités, 0,92 et 0,88, donnent facturation ou acces_compte selon la priorité écrite dans le code. Avec un seuil fictif de 0,95, la fonction renvoie relecture. Elle ne propose un traitement sur un seul motif que si l’autre motif est sous le seuil complémentaire ; les cas ambigus passent en relecture. Les assertions vérifient cette politique locale, pas Jev. Aucun ticket n’est déplacé. Il faut mesurer les erreurs et choisir les seuils sur ses propres données avant une utilisation réelle.

Préparer le même essai avec Claude Code ou Codex. Copiez le prompt suivant dans votre assistant, depuis le dossier du projet. Il demande d’abord une simulation locale ; le passage au service réel reste une commande distincte que vous lancez. Ne collez pas votre clé dans la conversation.

Crée dans ce projet une démonstration minimale de l’API Jev de TypeSafe, avec un ticket entièrement fictif. Commence par lire la structure et les instructions du projet ; préserve les fichiers existants.

Documentation à vérifier avant de coder :
- https://docs.typesafe.ai/introduction/quickstart
- https://docs.typesafe.ai/sdk/python/usage
- https://docs.typesafe.ai/sdk/python/api/retries
- https://docs.typesafe.ai/models

Utilise Python 3.10+ et typesafe-sdk==0.7.0 dans un environnement virtuel dédié. Demande le modèle jev-1.13.0 et enregistre l’identifiant réellement renvoyé. Si cette version n’est plus documentée, signale le changement dans le README.

Cas : « Le paiement a échoué et je ne peux plus accéder à mon compte. » Crée une question Choice nommée destination, avec facturation, acces_compte, incident_technique et autre. Décris chaque catégorie et demande celle qui décrit le mieux le sujet principal. Ne place pas de priorité opérationnelle dans cette question : choice est une catégorie prédite, pas une affectation de ticket.

Par défaut, lance une simulation locale utilisant le vrai SDK et un transport HTTP simulé. Étiquette clairement toutes les valeurs simulées. Ajoute une option --live que je lancerai moi-même pour envoyer ce ticket fictif au service ; ne l’exécute pas pendant ton travail. En mode réel, 1 seule tentative SDK avec RetryPolicy(max_retries=0), délai HTTP de 30 secondes, clé TYPESAFE_API_KEY ou saisie masquée dans le terminal. Ne demande jamais la clé dans la conversation et ne l’écris pas dans le code.

Affiche la catégorie prédite, les probabilités, confidence, le modèle, les compteurs de tokens et la durée complète de l’appel client. Conserve null si un compteur manque. Explique que confidence décrit la concentration des probabilités, pas la probabilité d’avoir raison.

Ajoute un fichier autonome decision_policy.py, sans client API ni réseau. Déclare deux questions Noul indépendantes sur la mention d’un paiement échoué et d’un accès bloqué. Utilise des réponses explicitement fictives et une fonction decide_route(probabilities, *, threshold=0.8, priority="facturation") qui applique une priorité et renvoie une proposition ou relecture. Les valeurs et seuils sont pédagogiques, non validés pour la production. Teste que les mêmes probabilités peuvent donner une autre proposition quand seule la politique change, ainsi que les motifs coexistants et les cas ambigus envoyés en relecture. Affiche séparément les probabilités simulées et la proposition applicative ; ne déplace aucun ticket. Ces signaux portent sur le texte, pas sur l’état réel du paiement ou du compte.

Produis le script, les commandes d’installation et d’exécution, puis des tests hors réseau pour une réponse valide, une clé absente, une erreur HTTP et l’absence de nouvelle tentative sur surcharge. N’effectue aucune modification sur GitHub ou Sentry. Indique exactement ce qui a été testé ; un transport simulé ne teste ni Jev ni l’accès à mon compte.

Après ce premier essai.

• Le chapitre Appeler l’API et lire ses réponses couvre aussi HTTP, TypeScript, Noul et Score.
• Pour passer à vos propres tâches, suivez les pilotes GitHub et Sentry, puis le protocole de comparaison.

Remplacer le ticket fictif par une issue réelle ne suffit pas à valider une automatisation.

Références du tutoriel : démarrage officiel, SDK Python 0.7.0 sur PyPI, client Python et options, politique de reprise. Documentation et déclarations de types du SDK relues le 21 septembre 2026.

Prérequis : Mac Apple Silicon, Python 3.12 déjà disponible et espace pour l’environnement et environ 614 Mio de poids. Ce parcours utilise les versions du laboratoire. Son inférence locale et l’interface de commande ont été vérifiées ; l’installation complète n’a pas été rejouée sur un Mac vierge. Windows, Linux et Mac Intel ne sont pas qualifiés ici. Installation officielle.

1. Depuis le dossier où vous rangez vos essais, créez un nouveau dossier. Ces commandes installent des paquets via Internet. Si python3.12 est introuvable, installez Python 3.12 avant de continuer. Si le dossier existe, choisissez un autre nom.

mkdir laya-demo
cd laya-demo
python3.12 -m venv .venv
.venv/bin/python -m pip install \
  'laya-mlx==0.2.0' 'mlx==0.32.2' 'tokenizers==0.23.2' 'numpy==2.5.3' 'huggingface-hub==1.33.0'
.venv/bin/python -m pip freeze > requirements-laya.txt

2. Dans ce même dossier, téléchargez explicitement la révision multilingue. Cette étape nécessite Internet ; elle est séparée des prédictions. Conservez le fichier requirements-laya.txt pour identifier l’environnement résolu.

.venv/bin/python - <<'PY'
from huggingface_hub import snapshot_download

snapshot_download(
 \
   repo_id="aac6fef/laya-multilingual-mlx",
 \
   revision="f2b4faf51023039425946074e2cf1361d2db11d5",
 \
   local_dir="models/laya-multilingual",
)
PY

3. Enregistrez le JSON ci-dessous dans questions.json, à côté de .venv. Il demande une catégorie sur un texte court. Les questions sont en anglais ; le modèle sélectionné accepte une entrée française ou anglaise.

{
  "department": {
    "type": "choice",
    "instructions": "Which team should handle the main request?",
    "criteria": {
      "billing": "Invoices, payments and refunds.",
      "technical": "Software bugs and outages.",
      "other": "A clear request unrelated to billing or technical support."
    }
  }
}

4. Lancez une prédiction avec les poids locaux. Le JSON doit contenir answers.department et les probabilités des options. Le paiement en double suggère une catégorie de facturation, mais cette attente ne doit pas devenir un résultat garanti. Une sortie JSON valide prouve le fonctionnement de l’appel, pas sa justesse.

HF_HUB_OFFLINE=1 HF_HUB_DISABLE_TELEMETRY=1 HF_HUB_DISABLE_IMPLICIT_TOKEN=1 \
  .venv/bin/laya-mlx predict \
  --model ./models/laya-multilingual \
  --device gpu \
  --questions questions.json \
  --state "J'ai été débité 2 fois. Je demande le remboursement du doublon."

printf '(version 1)
(allow default)
(deny network*)
' > deny-network.sb
/usr/bin/sandbox-exec -f deny-network.sb \
  env HF_HUB_OFFLINE=1 HF_HUB_DISABLE_TELEMETRY=1 HF_HUB_DISABLE_IMPLICIT_TOKEN=1 \
  .venv/bin/laya-mlx predict \
  --model ./models/laya-multilingual --device gpu \
  --questions questions.json --state "I was billed twice. Please refund the duplicate."

Le pilote de tri d’issues a maintenant été exécuté : 30 exemples de développement puis 60 de test. Le candidat est écarté et la validation humaine des annotations reste à faire. Pour un autre essai, grouper les doublons avant séparation, faire relire les labels, figer les seuils avant test et employer un nouveau jeu réservé. Mesurer qualité par catégorie, couverture, abstention, erreurs, dépassements et latence complète. Le tuto installe le moteur ; il ne promet pas un gain de qualité.

Le labo utilisé pour nos mesures ajoute une page locale, 6 formulaires, des imports et des lots reprenables. Il n’est pas encore distribué : les commandes start.command, stop.command et laya-lab ne sont pas installées par pip install laya-mlx. Le tuto public ci-dessus permet une première inférence ; reproduire tout le laboratoire demande son code et son environnement.

Au 28 octobre, la page Models liste jev-1.14.0 et jev-1.13.0, au même prix et avec les mêmes limites ; jev-latest et jev-preview pointent vers jev-1.14.0. Le modèle direct documenté à l’édition initiale était jev-1.13.0.

• La limite de 64k tokens porte sur l’état et toutes les questions ; celle de 32k porte sur l’état et la question la plus longue.
• Les plafonds affichés, 250 000 tokens par seconde et 1 200 requêtes par minute, sont dynamiques et peuvent dépendre de l’offre. Ils ne constituent pas un engagement de disponibilité.

Modèles et limites TypeSafe.

Ces routes sont décrites par les pages des opérateurs : Vercel, Cloudflare et OpenRouter.

• Leurs fiches 32k ne suffisent pas à leur attribuer le double budget 64k/32k de l’API directe. Vérifier le découpage appliqué par la route choisie avant de dimensionner les requêtes.
• Aucun droit d’accès de compte n’a été vérifié ici.
• La promotion Vercel est datée ; elle ne doit pas devenir un tarif permanent dans les comparatifs.

Les adaptations ne portent pas forcément les mêmes noms. Vercel expose notamment un type boolean là où l’API native a Noul, et range certaines informations dans les métadonnées du fournisseur. Un changement de passerelle peut aussi changer la facturation, les limites et la gestion des données. Comparez 2 routes comme 2 configurations distinctes, même si elles portent le nom Jev.

Les SDK officiels Python et JavaScript inspectés sont sous licence MIT. Le manifeste Python lu indique 0.7.0 et Python 3.10 minimum ; le tag JavaScript examiné est v0.6.0 et requiert Node 20 minimum. Le SDK Python 0.7.0 a aussi été installé pour le tutoriel Premier appel, puis exécuté avec un transport simulé. Le client JavaScript n’a pas été exécuté ici. SDK Python, SDK JavaScript.

L’audit Perplexity indiquait que toutes les conditions de traitement restaient inconnues. Les pages officielles permettent d’être plus précis. Le tableau résume leurs déclarations au 21 septembre ; il ne vérifie ni leur exécution technique ni la conformité d’un usage particulier.

Les pages Trust Center et sous-traitants n’ont pas fourni de contenu exploitable à l’outil de lecture. Les certifications, la liste nominative des sous-traitants et les modalités applicables au compte restent donc non vérifiées. Cette limite d’accès ne prouve pas que ces informations ou garanties sont absentes.

Le SDK Python prévient que son mode debug peut journaliser les corps de requêtes et de réponses sans expurgation. Préparer un pilote impose donc de regarder aussi les journaux côté application. Les messages Sentry, les descriptions de bugs et les diffs peuvent contenir plus d’informations qu’un simple titre.

Les versions du 19 septembre des conditions du site et du contrat client lues ne contiennent pas d’interdiction explicite de publier un benchmark identifiée dans cet audit. Le contrat conserve néanmoins des dispositions de confidentialité, des restrictions d’imitation ou de distillation et d’éventuelles conditions particulières. Ce constat documentaire ne vaut pas autorisation générale de publication.

Avant de publier ses propres résultats, conserver les conditions effectivement acceptées et celles de la plateforme choisie. Les crédits promotionnels, le tarif nominal et le montant payé sont 3 informations distinctes. Un essai gratuit ne démontre pas le coût durable d’une exploitation.

J’ai relu une sélection de mes définitions de skills, d’agents et de tâches automatisées. Les propositions reprennent ces tâches existantes. Leur fréquence et leur coût restent à mesurer avant de juger l’intérêt d’ajouter Jev.

• Pour Sentry, Jev interviendrait seulement lorsque les correspondances exactes n’ont rien donné. Il classerait les candidats déjà retrouvés, avec une relecture avant tout rattachement.
• Pour les notes de version, il aiderait à sélectionner les correctifs ; le modèle rédacteur garderait la rédaction. Un titre de commit vague ne suffit pas à établir l’impact utilisateur : fournir aussi le contexte de la PR.

• Pour le pilote notes de version, le programme rassemblerait les commits et le contexte des PR.
• Jev proposerait une catégorie pour chaque correctif.
• Le code appliquerait les règles de sélection puis transmettrait au LLM les changements retenus avec leurs références.

Jev peut donc fournir une évaluation avant que le code sélectionne les éléments transmis au LLM. Cette répartition reste un choix à tester : un LLM peut aussi classer des correctifs, et de simples règles peuvent suffire. Le schéma ne démontre aucun gain de vitesse, de coût ou de justesse.

Une autre proposition apparaît chez Syntax à 10:54 : transcrire un contenu, faire rédiger les notes par un LLM, puis demander à Jev de vérifier des affirmations. Il s’agit d’une idée d’utilisation présentée dans la vidéo, sans mesure d’exactitude de cette chaîne.

• Pour chaque essai, relever les erreurs, la part de cas traités, les temps de réponse p50/p95 et le coût par décision correcte.
• Préciser la région, le nombre de requêtes simultanées, la taille des entrées, le nombre de questions et la version.
• Compter les erreurs réseau, les nouvelles tentatives et la relecture.

Brier et ECE se calculent sur les probabilités adaptées à la tâche, pas sur le champ confidence renommé.

Pour ces essais proposés, les règles qui calculent la sévérité Sentry, normalisent les URL ou traduisent un verdict en action restent dans le code. Les essais portent sur les évaluations sémantiques pour lesquelles une règle lexicale peut manquer une reformulation ou rapprocher à tort 2 problèmes.

1. Décrire la décision

   Fixer l’unité évaluée : ticket, paire Sentry/issue, correctif ou document. Écrire les catégories, les ambiguïtés et l’action que la suggestion pourrait entraîner.

2. Constituer les réponses de référence

   Faire annoter des exemples réels autorisés ou synthétiques par des personnes connaissant la tâche. Sur un sous-ensemble, 2 annotations indépendantes permettent de repérer les désaccords. Les arbitrer et conserver les consignes.

3. Séparer les données

   Réserver des ensembles distincts pour une éventuelle adaptation, le choix des questions et seuils, puis le test final. Grouper les doublons et reformulations du même incident. Pour un workflow historique, tester aussi une période ultérieure.

4. Fixer les comparateurs

   Règles existantes, recherche lexicale, classifieur ou LLM contraint et Jev reçoivent les mêmes informations utiles. Une variante avec questions décomposées doit être proposée à chaque modèle concerné.

5. Exécuter et journaliser

   Consigner version, route API, région cliente, options, nombre de questions, tokens, temps, réponse brute et erreurs. Alterner l’ordre des concurrents pour limiter l’effet des variations de charge.

6. Évaluer la chaîne

   Mesurer les erreurs, la couverture, les reprises, le coût et la latence. Vérifier ensuite l’effet sur la rédaction ou l’enquête finale, avec le même modèle en aval.

Le français mérite un sous-ensemble propre : accents, formulations orales, abréviations métier, fautes, négations et tickets mêlant français et anglais. Une traduction d’un même cas doit rester dans le même groupe de données. Comparer 2 jeux de sujets différents en français et en anglais ne permet pas d’attribuer leur écart à la langue seule.

• Pour les choix nombreux, faire varier le nombre de distracteurs proches tout en gardant le même problème.
• Permuter à la fois la position et les identifiants des options.
• Au-delà de la limite documentée, un filtre préalable puis un choix final forment un nouveau système : mesurer les candidats éliminés à tort et le coût des 2 étapes.

Commencer en mode suggestion permet de comparer chaque sortie à la décision habituelle. Le journal peut stocker un identifiant pseudonymisé, les versions, la décision suggérée, son devenir et les métriques de l’appel. Les clés API et les contenus sensibles n’ont pas leur place dans un jeu de résultats destiné à être partagé.

Pour le routage de modèles, demander à un expert quel modèle il préfère ne suffit pas. Exécutez la tâche avec les modèles candidats sur un ensemble de référence, puis comparez la qualité obtenue, le coût et la latence du modèle choisi. Le routeur ajoute son propre coût. Évaluer son accord avec un avis expert est une mesure distincte, utile mais insuffisante pour établir un gain sur les tâches terminées.

• Mesurer l’erreur et la couverture pour toutes les méthodes. Pour celles qui produisent des probabilités, évaluer aussi leur calibration et la qualité des décisions conservées après un seuil. Le champ confidence n’est pas une probabilité d’exactitude.
• Régler les seuils sur le jeu de validation, puis mesurer le taux d’erreur et la couverture sur le test réservé.

Un texte synthétique ou une langue rare ne prouvent pas que le modèle n’a jamais rencontré une donnée proche pendant son entraînement.

L’audit Perplexity envisage un contrôle avant l’action d’un agent. Le test proposé consiste à utiliser Jev pour repérer les cas qui méritent une relecture supplémentaire. L’autorisation reste définie par l’identité, les droits, les actions permises et les approbations du système. Comparer ce signal aux règles locales et à un juge LLM exige de compter les actions dangereuses non signalées, les actions sûres bloquées, la latence et le coût.

Un format strict limite la forme de la réponse. Il n’empêche pas une instruction malveillante dans un ticket de modifier la catégorie choisie. Le test doit donc inclure du texte ordinaire, des instructions intégrées aux données et des formulations ambiguës, sans confondre ces 3 populations. Une classification rassurante ne neutralise pas une injection.

Pour GitHub et Sentry, la première sortie reste une suggestion. Retrouver un identifiant exact, vérifier un droit d’accès ou appliquer une règle de sévérité est un travail de code. Réserver le modèle à une question sémantique ne dispense pas de tester cette question : « même cause probable » peut être faux malgré des messages d’erreur très proches.

L’adaptateur officiel facilite les comparaisons des pilotes GitHub et Sentry : les mêmes entrées et questions peuvent passer par Jev ou par un LLM.

• Son mode discrete demande une décision, son mode probabilities demande une distribution. Ces 2 tâches n’ont pas le même coût ; le protocole doit préciser laquelle répond au besoin.
• Le README documente les traces des tentatives et les corrections de structure.
• Cet adaptateur n’a pas été exécuté pour ce dossier. Le tutoriel Premier appel vérifie le client Python officiel sur un transport simulé, sans inférence.

Le test SemIf compare une lecture de scores à du JSON généré sur RTX 3090, avec un accord de 18 décisions sur 21. Sa comparaison à Jev reprend des sorties publiques du fournisseur, sans nouvel appel à Jev. Ces résultats proviennent du README. Aucun projet de ce tableau n’a été installé ni exécuté pour ce dossier.

Dans sa vidéo, Micah explique sa lecture de logits à 02:07, puis la distillation par un modèle professeur à 02:39. Cette démonstration entraînée est distincte du Qwen 4B gelé de SemIf. À 03:55, il précise les limites de sa démonstration Doom et rappelle que l’architecture Jev n’est pas divulguée.

La fiche OpenSysOne, inaccessible lors de la première collecte, a été lue le 21 septembre. Elle distingue entraînement, calibration et test.

• Sur 768 décisions Social IQA réservées, elle rapporte 72,92 % contre 70,31 % pour son modèle de base.
• Ses mesures de vitesse sont en FP32, à chaud et en série sur une machine GB10 : elles comparent ses propres variantes, sans appel Jev.

Le README de Laya publie aussi les échecs de ses modèles de base : sur 2 000 décisions typées, ils restent sous la classe majoritaire, tandis que le modèle ajusté atteint 76,6 %.

• Les auteurs reprennent les chiffres Jev publiés ailleurs ; cela ne forme pas un face-à-face à entrées identiques.
• Les latences locales sur GPU T4 ne comprennent pas le service réseau de Jev. L’inférence locale demande du matériel, même sans facture d’API.
• Le sigle RLCD employé par Laya désigne sa méthode publiée, sans établir qu’elle reproduit celle de TypeSafe.

• Dans Pixel 0.4.0, le routage de plan reconnaît des mots et choisit parmi 5 analyses.
• Le classement des fichiers combine plusieurs indices.
• Les pistes issues d’embeddings sont classées P2 et signalées comme non vérifiées.
• Le champ confidence du résolveur de concepts prend les valeurs resolved, ranked ou unresolved ; ce statut de recherche n’est pas une probabilité de justesse.

Pour choisir entre Pixel et Jev, commencer par la décision attendue. Pixel peut calculer et classer ce que ses règles et ses index décrivent ; Jev évalue par inférence apprise des critères fournis dans l’appel. Une règle métier peut très bien suffire à trier des tickets. L’intérêt de Jev dépend des cas que cette règle couvre mal et du coût pour l’entretenir. Les sources de Pixel ont été inspectées à la version citée, sans benchmark comparatif : une équivalence de qualité ou de vitesse entre ces approches reste à mesurer.

Les conditions de jev-agent.com précisent que les textes sont transmis à TypeSafe. TokenRa, agrégateur d’API, affiche Jev à 0,042 dollar par million de tokens, au même prix que sa colonne « tarif officiel ». Ce sont les déclarations des opérateurs, lues le 21 septembre ; aucun appel ni circuit réel de transmission des données n’a été testé ici.

• La description de la vidéo de Micah a fourni les liens SemIf, jevlike, open-jev et OpenSysOne.
• Celle de Sam Witteveen, à 17:50 renvoie à Laya.
• Les listes AnotiaWang/awesome-jev, fatwang2/awesome-jev et Made with Jev complètent cette découverte.

Seules leurs sections utiles ont été parcourues ; leur sélection ne garantit ni exhaustivité ni performance.

Les ajouts du 24 septembre sont répartis entre les commandes et intégrations et Laya-MLX / Kev. Les premières utilisent une interface d’évaluation; les seconds servent d’autres poids. Leurs résultats ne révèlent pas l’architecture de Jev.

La collecte du 24 septembre ajoute 17 dépôts absents de la version 0.15.0. Certains existaient avant le 21 septembre : date de découverte et date de création sont séparées. Les sources utiles ont été lues et une partie du code de jgrep a été inspectée; aucun de ces outils n’a été installé ou exécuté pour ce dossier.

Ces commandes partagent jevkit-core, distribué sous le nom jevkit-runtime, pour le transport, le cache, la provenance et les coûts. Elles viennent du même auteur; leur nombre ne mesure pas le nombre de validations indépendantes. Versions observées le 23 septembre : jgrep 0.4.1, jselect 0.3.1 et runtime 0.3.1. Le support des serveurs locaux date des versions précédentes du 22.

Le code de jgrep inspecté construit des questions Noul et applique un seuil de 0,5 par défaut. Avec plusieurs descriptions, il utilise un minimum ou un maximum selon le mode; ces opérations ne calculent pas une probabilité jointe. Le README annonce environ 200 ms par appel et rapporte 994 titres traités en 4,6 secondes pour 0,012 dollar, avec concurrence. Ces chiffres sont ceux de l’auteur.

Exemples adaptés, non exécutés. Ils supposent jgrep installé et un fournisseur configuré; un fournisseur hébergé peut facturer les appels. Le premier attend un CSV avec une colonne abstract, le second évalue les hunks du diff courant. Les sorties demandent une relecture.

jgrep --csv --field abstract "reports a failed replication" papers.csv
git diff --no-color | jgrep --diff "removes error handling for a persistent write"

La sélection de tests de kyu1204 retient d’abord les fichiers par nom et imports, puis interroge Jev sur les autres candidats à partir du diff et des noms de tests. L’auteur demande de lancer ensuite toute la suite. Mesurer le premier signal utile et les régressions manquées, en incluant le coût de sélection.

Laya-MLX est un portage indépendant de Laya vers MLX sur Apple Silicon. Après téléchargement, l’inférence est locale et produit Choice, Score et Noul. Le README figé au 22 septembre documente un modèle anglais de 421 millions de paramètres, un multilingue de 322 millions et une variante typed-decisions de 421 millions. Il ne fournit pas les poids de Jev. Version déclarée : 0.2.0, commit 0a85951.

Les 50 échantillons de chaque fichier donnent 17,745958 et 10,9073125 ms après recalcul. Les données sont datées du 22 septembre, sur M3 Max à 40 cœurs GPU et 128 Gio. Le temps inclut préparation, inférence synchronisée et formatage; chargement et téléchargement sont exclus. Le README ne concorde pas avec ces fichiers au même commit. Sources : rapport, anglais, multilingue. Ces benchmarks M3 Max n’ont pas été rejoués dans les mêmes conditions.

L’accord de 63/63 réponses avec le moteur d’origine, pour chaque modèle et précision, mesure la fidélité du portage. Le petit test AG News porte sur un corpus présent dans le mélange d’entraînement amont. Ces 2 observations ne prouvent pas une équivalence générale avec Jev.

Le guide JevKit fournit un serveur adaptateur séparé et documente jgrep --api laya. Il refuse par défaut les textes qui seraient coupés. L’auteur n’a essayé que le modèle anglais 421M; son guide épingle le portage au 19 septembre, avant la correction de calibration. Ses essais ne valident donc pas automatiquement la révision du 22. Le comparatif jgrep montre aussi des classements différents selon les tâches.

Dans la démo Snake, le programme prépare des informations sur le plateau, Laya évalue les propositions, puis une règle de sécurité peut corriger l’action. Les résultats de survie concernent cet ensemble; ils ne démontrent pas une résolution autonome à partir du plateau.

Kev propose des poids et des recettes d’entraînement pour une famille Qwen3.5 de 0,8B, 4B et 9B. Son API reprend System One; le README examiné documente CUDA, ROCm et Apple Silicon via MLX. Sa référence à une analyse intitulée « Architecture Unmasked » ne prouve pas que l’architecture propriétaire de Jev est connue.

Le 24 septembre, Kev-4B reçoit une spécialisation sur des réclamations financières : le gain annoncé reste dans le même domaine et les mêmes formulations de questions. Le commit 60c8d39 ajoute le traitement groupé et des optimisations GPU. Les données d’entraînement de Jev étant inconnues, le comparatif ne permet pas d’isoler les architectures. Le dépôt conserve aussi des écarts défavorables à Kev sur des évaluations externes.

L’audit Perplexity sert de carte de recherche. Ses articles de synthèse, vidéos et reprises commerciales ne sont pas comptés comme autant de réplications. Les sources primaires ont été privilégiées pour l’API, les conditions d’accès et les expériences ; les pages secondaires restent utiles pour retrouver un auteur ou un essai.

La veille signale les changements utiles ; elle ne publie pas le dossier et ne lance pas de tests payants. Chaque révision conserve la date des sources, les résultats bruts et les versions antérieures.

Recherche complémentaire Jev / TypeSafe. Dossier de référence : version 0.16.0, collecte du 24 septembre 2026. Fixe une nouvelle date de fin et cherche les changements postérieurs; marque séparément les projets plus anciens absents du dossier.

Déjà couverts : primitives, calibration, RLCD non entièrement divulgué, benchmarks antérieurs et 17 dépôts supplémentaires : keltokhy/jgrep, jsort, jlink, jcol, jselect et jevkit-core; nassim-arifette/jevgrep; sglenon/jev-semantic-reviewer; supercorp-ai/supercov; simonw/llm-typesafe; edwardyen724-g/jev-compactor; uehaj/jev-semgrep; kyu1204/jgrep; NiazMorshed2007/jev-review; devagrawal09/jev-review; mizorewww/laya-mlx; jaredpalmer/kev. Ne les présente pas comme nouveaux sans changement daté. Les jgrep/jevgrep sont des projets distincts.

Vérifie les releases TypeSafe (Python 0.7.1 observé, tutoriel du dossier testé sur 0.7.0; JS 0.6.0), les modèles, prix et limites. Distingue Jev hébergé et modèles locaux. Pour Laya-MLX, examine l’écart README/mesures brutes, la troncature et les températures corrigées; le guide JevKit épingle une révision antérieure. Pour Kev, sépare développement, test et spécialisation de domaine.

Explore les outils composables, sélection de contexte, rapprochement, extraction de valeurs existantes, citations, variables supervisées et sélection de tests. Relis les cookbooks skill_suggestion, autoresearch_feature_discovery, pre_parsed_value_extraction_cookbook et citation_check sur docs.typesafe.ai. Essaie de récupérer autoformat, annoncé par llms.txt mais inaccessible lors de la collecte. Leurs exemples Jev 1.12 ne deviennent pas de nouvelles mesures de septembre.

Priorité aux sources primaires, commits, protocoles, échecs et réponses brutes. Jev évalue; le code applique seuils, permissions et actions. Confidence ne mesure pas une probabilité de justesse. Ne généralise pas les facteurs 100×, les coûts par email ou les boucles à 300 ms. Ne déduis pas l’architecture propriétaire d’une réimplémentation.

Livre 5 découvertes utiles, une matrice datée des changements et sources, les limites et des essais avec comparateurs et critères de réussite. Sépare fonctionnalités documentées, chiffres des auteurs, résultats reproduits et propositions. UNKNOWN pour ce qui reste invérifiable. N’installe rien, n’appelle pas l’API et ne publie rien. Les synthèses Perplexity précédentes contenaient des erreurs; vérifie chaque fait à sa source.

Une publication détaillant RLCD permettrait d’étudier la nouveauté de la méthode. Un comparatif avec des méthodes d’apprentissage ou de calibration concurrentes devrait contrôler le modèle de base, les données et les réglages. Cette publication dépend de TypeSafe ; elle constitue un point de veille, pas un test que le lecteur peut exécuter avec la seule API.

L’index officiel annonce aussi un cookbook autoformat qui reconstitue une structure Markdown. Sa page détaillée était inaccessible pendant cette collecte : piste à recouper, sans résultat retenu.

• Configuration portable de Claude Code et Codex (EN) : organiser instructions, skills, hooks et vérifications dans une configuration partagée.
• Back Market et OpenRouter (FR) : un retour d’expérience sur les budgets et le choix des fournisseurs derrière une API commune.
• Concevoir les boucles et les étapes d’un agent (EN) : définir les étapes, les conditions d’arrêt et le passage à une personne.
• Évaluer un agent (EN) : choisir les critères de qualité et comparer des exécutions avec leurs outils et leurs règles.
• Calculer le coût par tâche acceptée (EN) : compter les tentatives, les reprises et la relecture dans le coût d’un résultat accepté.
• Sécuriser les agents, hooks et outils (EN) : traiter les permissions, les dépendances et les entrées non fiables.

Abstention

Cas que l’application laisse à une personne ou à une autre méthode, faute de pouvoir décider selon ses règles.

Calibration

Accord entre les probabilités annoncées et les résultats sur un ensemble de cas. Parmi des prédictions à 80 %, on s’attend à environ 80 % de réussites ; cela ne garantit aucune réponse prise isolément.

Réponse typée

Réponse dont la forme est définie avant l’appel : option et probabilités avec Choice, note et probabilités avec Score, probabilité de oui avec Noul. Le code applicatif détermine comment l’utiliser pour décider du traitement.

Conclusion

Au 27 septembre 2026, le dossier sépare Jev, les benchmarks publiés, nos essais Laya synthétiques et le pilote sur les issues Aristote. L’inférence locale fonctionne. Le pilote n’apporte toutefois pas le gain requis : 8 suggestions conformes sur 11 émises par Laya, contre 12 sur 17 pour les règles titre seul, sur 60 tickets. Aucun appel à l’API Jev ni comparaison directe Jev/Laya n’a été exécuté.

Conserver les règles et liens exacts. Le pilote de domaine et les 3 POCs Sentry, reviews et CI écartent les configurations Laya testées. Sur les 120 cas des 3 derniers POCs, les suggestions conformes sont 2/38, 1/9 et 6/20 ; en CI, les règles atteignent 5/6. Les annotations d’agents sans validation humaine et les corpus diagnostiques limitent la généralisation. Toute nouvelle configuration exige un autre jeu réservé. La variante lexicale du premier pilote reste non déployée.

Au 28 octobre, la question n’est plus seulement « Jev ou un LLM ? ». Clef, Strands Decider, pplx-decider et la Decisions API proposent la même famille de réponses ; les classements publiés par des tiers placent plusieurs modèles à quelques points les uns des autres, et leurs auteurs n’en tirent pas de vainqueur général. Mes POCs Laya restent négatifs. Le prochain essai local candidat est Strands Decider 2B, sur les mêmes jeux réservés et avec des seuils recalibrés.

Sources datées

• Introducing System One Models & Jev · TypeSafe AI / Diogo Almeida · consulté le 21/09/2026 · 15 septembre 2026 · Source documentaire
• Introduction · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Choice · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Score · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Noul · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Confidence · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• AI primer · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Models · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• API reference · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Jev 1.13 jaggedness · TypeSafe AI · consulté le 21/09/2026 · 17 septembre 2026 · Source documentaire
• Workflow evals · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• System One Adapter · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Python SDK manifest · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• JavaScript SDK manifest · TypeSafe AI · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• InstructGPT paper · OpenAI authors / arXiv · consulté le 21/09/2026 · 4 mars 2022 · Source documentaire
• Privacy policy · TypeSafe AI · consulté le 21/09/2026 · 19 novembre 2025 · Source documentaire
• Phishing benchmark · anisselbd · consulté le 21/09/2026 · 17 septembre 2026 · Source documentaire
• BTZSC pilot · AbdelStark · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Jev measured · WallerChen · consulté le 21/09/2026 · 20 septembre 2026 · Source documentaire
• JevBench · Benchmark Heaven / fstandhartinger · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• TypeSafe Jev on AI Gateway · Vercel · consulté le 21/09/2026 · 16 septembre 2026 · Source documentaire
• Jev reranking benchmark, MIRACL French · anessbelbati · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Jev 1.13.0 behavior study, arithmetic permutations · RINNECODER · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Calibration, Guo et al. · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SelectiveNet · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Uncertainty under shift, Ovadia et al. · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• BERT · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• ModernBERT · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• RouteLLM · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SCX Router, résumé uniquement · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Text generation · Hugging Face · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• ASSAY-001, rapport et données · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• ASSAY-001, protocole · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• ASSAY-001, premier amendement du protocole · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Vercel AI SDK, TypeSafe AI : arrondis et confidence · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Agent Journal, LLM judge vs feature extraction · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• LangChain, Building a Harness with Jev · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Jev as a judge, dépôt de l’expérience · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Rewarding Doubt, v6 · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• DeepSeek-R1, résumé · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Tülu 3, résumé · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• TechCrunch, entretien avec Almeida · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Équipe TypeSafe · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Annonce de financement DCVC · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• State, contexte partagé · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SDK Python, usage · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SDK Python, types de réponses inspectés · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SDK JavaScript v0.6.0, types de réponses et options · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SDK JavaScript v0.6.0, helpers de questions · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SDK JavaScript v0.6.0 · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Vercel, fiche Jev et promotion · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Cloudflare, Jev · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• OpenRouter, catalogue Jev · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• TypeSafe, DPA · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• TypeSafe, contrat client MCA · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• TypeSafe, documents juridiques et ZDR · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• TypeSafe, conditions du site · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Capital & Compute, compilation de coûts et usages · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Near Here, validation d’événements · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• gemanor, benchmark de revue de code · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• paddo, Thirty-Cent Judge · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• bitnovus, expériences de filtrage d’emails · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• SemIf, interface de décision sur Qwen · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• jevlike, prototype communautaire · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• daseinlabs, open-jev sur MLX · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• razorback16, openjev avec DiffusionGemma · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• AnotiaWang, catalogue awesome-jev · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Made with Jev, catalogue de projets · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• jevtypesafeai.com, documentation du service tiers · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• jev-agent.com, conditions d’utilisation du site tiers · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• CounterProof, examen des labels de consensus · consulté le 21/09/2026 · 21 septembre 2026 · Source documentaire
• Every · article de Mike Taylor (titre et URL ; corps non lu) · 21 septembre 2026 · Source documentaire
• Arize / Laurie Voss · évaluation de Jev comme juge · 21 septembre 2026 · Source documentaire
• OpenSysOne · carte de modèle publiée par andyshu · 21 septembre 2026 · Source documentaire
• TokenRa · offre et prix affichés · 21 septembre 2026 · Source documentaire
• NandhaKishorM / Laya · README et limites des comparaisons · 21 septembre 2026 · Source documentaire
• LivioGama / Pixel · code intelligence et classification · 21 septembre 2026 · Source documentaire
• TypeSafe · SDK Python officiel · 21 septembre 2026 · Source documentaire
• Browser Use · démonstration Jev Ultrafast · 21 septembre 2026 · Source documentaire
• Aness Belbati · benchmark de reranking · 21 septembre 2026 · Source documentaire
• ThursdAI · épisode du 17 septembre et présentation d’Allie Laabs · 21 septembre 2026 · Source documentaire
• ExplainX · reprise des chiffres du benchmark Jev comme juge · 21 septembre 2026 · Source documentaire
• Yin et al., 2019 · classification zero-shot par NLI · 21 septembre 2026 · Source documentaire
• Hugging Face · pipeline ZeroShotClassification · 21 septembre 2026 · Source documentaire
• Anthropic · sorties structurées et limites des schémas · 21 septembre 2026 · Source documentaire
• simonmesmith · Jev sur Banking77 avec exemples, README consulté · 21 septembre 2026 · Source documentaire
• MindStudio · synthèse sur les classifieurs, protocole d’origine non retrouvé · 21 septembre 2026 · Source documentaire
• Hacker News · lancement Jev, discussion publique · 21 septembre 2026 · Source documentaire
• Hacker News · description zero-shot par petesergeant · 21 septembre 2026 · Source documentaire
• Hacker News · réponse de CompleteSkeptic à la description zero-shot · 21 septembre 2026 · Source documentaire
• Hacker News · CompleteSkeptic se présente comme CEO · 21 septembre 2026 · Source documentaire
• Hacker News · confidentialité de l’architecture et discussion d’un article · 21 septembre 2026 · Source documentaire
• Hacker News · type valide et exactitude factuelle · 21 septembre 2026 · Source documentaire
• Reddit / LocalLLaMA · hypothèses sur l’architecture Jev · 21 septembre 2026 · Source documentaire
• Reddit / LocalLLaMA · comparaison avec BERT · 21 septembre 2026 · Source documentaire
• Reddit / accelerate · résumé et réactions · 21 septembre 2026 · Source documentaire
• Reddit / accelerate · choix successifs de lettres · 21 septembre 2026 · Source documentaire
• Reddit / accelerate · discussion sur le classement d’emails · 21 septembre 2026 · Source documentaire
• Nandakishor M · revendication d’antériorité, billet de l’auteur · 21 septembre 2026 · Source documentaire
• SalesRLAgent · notice et résumé, PDF non audité · 21 septembre 2026 · Source documentaire
• Routage par confiance · notice et résumé, PDF non audité · 21 septembre 2026 · Source documentaire
• Laya · README épinglé, périmètres de calibration · 21 septembre 2026 · Source documentaire
• Laya typed-decisions · modèle ajusté et réglages de calibration · 21 septembre 2026 · Source documentaire
• TypeSafe · démarrage officiel · 21 septembre 2026 · Source documentaire
• PyPI · typesafe-sdk 0.7.0 et prérequis Python · 21 septembre 2026 · Source documentaire
• TypeSafe · client Python synchrone et transport · 21 septembre 2026 · Source documentaire
• Theo · Jev is incredible · transcription complète analysée le 22/09/2026 · 22 septembre 2026 · Source documentaire
• Fireship · An ex-OpenAI researcher just deleted language from the LLM... · transcription complète analysée le 22/09/2026 · 22 septembre 2026 · Source documentaire
• Jev Engineering 101 · Daniel Moka / Craft Better Software · inspiration pédagogique, consulté le 23/09/2026 · 22 septembre 2026 · Source documentaire
• keltokhy/jgrep · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• keltokhy/jsort · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• keltokhy/jlink · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• keltokhy/jcol · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• keltokhy/jselect · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• keltokhy/jevkit-core · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• nassim-arifette/jevgrep · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• sglenon/jev-semantic-reviewer · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• supercorp-ai/supercov · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• mizorewww/laya-mlx · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• simonw/llm-typesafe · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• edwardyen724-g/jev-compactor · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• uehaj/jev-semgrep · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• kyu1204/jgrep · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• NiazMorshed2007/jev-review · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• devagrawal09/jev-review · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• jaredpalmer/kev · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• jgrep · Noul questions and filtering · 5727fe3 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• jgrep · code-review diagnostic · September 19 run · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• jgrep · local model comparison · September 22 runs · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• JevGrep · retrieval pilot protocol · 2495212 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Laya-MLX · README · 0a85951 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Laya-MLX · detailed local benchmarks · 0a85951 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Laya-MLX · English FP16 raw timings · September 22 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Laya-MLX · multilingual FP16 raw timings · September 22 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Laya-MLX · input preparation and truncation · 0a85951 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Laya-MLX · calibration temperature handling · 0a85951 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• JevKit · Laya adapter and pinned environment · 3a672d7 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Laya-MLX · Snake planner and safety interventions · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Kev · model family and evaluation boundaries · 30c619b · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Kev · batching and GPU optimizations · September 24 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Kiln · Auto Optimizing Jev with Autoresearch · September 21 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• TypeSafe Python SDK · v0.7.1 release · September 21 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• TypeSafe · skill suggestion cookbook · Jev 1.12 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• TypeSafe · AutoResearch feature discovery · Jev 1.12 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• TypeSafe · pre-parsed value extraction · Jev 1.12 · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• TypeSafe · citation checking · August 16 example · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• TypeSafe · documentation index and unresolved autoformat lead · consulté le 24 septembre 2026 · 24 septembre 2026 · Source documentaire
• Essais Laya locaux : données synthétiques et preuves jointes · 26 septembre 2026 · Observation vérifiée
• Poids multilingues : révision utilisée dans nos essais · 26 septembre 2026 · Source documentaire
• Laya-MLX 0.2.0 : version installée · 26 septembre 2026 · Source documentaire
• Pilote Laya / Aristote : agrégats et configuration, corpus privé exclu · 27 septembre 2026 · Observation vérifiée
• POCs Laya Sentry, reviews et CI : agrégats et configurations, corpus privé exclu · 27 septembre 2026 · Observation vérifiée
• Cloudflare, lancement de Clef et Clef-flash · consulté le 28/10/2026 · 1 octobre 2026 · Source documentaire
• Cloudflare, changelog Workers AI : Clef · consulté le 28/10/2026 · 1 octobre 2026 · Source documentaire
• Cloudflare, Clef-omni et baisse du prix de Clef-flash · consulté le 28/10/2026 · 9 octobre 2026 · Source documentaire
• Hugging Face, fiche du modèle Clef · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• Hugging Face, fiche du modèle Clef-omni · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• Cloudflare, fiche Workers AI de Clef-omni · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• Cloudflare, fiche Workers AI de Jev 1.14 · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• TypeSafe, Jev 1.14 et fonctions expérimentales · consulté le 28/10/2026 · 14 octobre 2026 · Source documentaire
• TypeSafe, annonce de la Series A · consulté le 28/10/2026 · 9 octobre 2026 · Source documentaire
• Andreessen Horowitz, investissement dans TypeSafe · consulté le 28/10/2026 · 9 octobre 2026 · Source documentaire
• TypeSafe, étude de cas Jack & Jill · consulté le 28/10/2026 · 7 octobre 2026 · Source documentaire
• TypeSafe, type de question Box · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• TypeSafe, images en entrée · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• TypeSafe, changelog du SDK Python · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• OpenAI, guide de la Decisions API · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• OpenAI, changelog de l’API · consulté le 28/10/2026 · 22 octobre 2026 · Source documentaire
• Strands Labs, dépôt strands-decider · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• Hugging Face, fiche Strands Decider 2B v1-2610 · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• Astronomer, évaluer un modèle de décision avant de lui faire confiance · consulté le 28/10/2026 · 8 octobre 2026 · Source documentaire
• AIMultiple, AIM-Decision : Jev, Clef et LLM · consulté le 28/10/2026 · 22 octobre 2026 · Source documentaire
• Leanmcp, JevBench Index · consulté le 28/10/2026 · 11 octobre 2026 · Source documentaire
• Ollama, version 0.35.0 · consulté le 28/10/2026 · 28 septembre 2026 · Source documentaire
• Hugging Face, fiche pplx-decider v1.1 · consulté le 28/10/2026 · 28 octobre 2026 · Source documentaire
• LiteLLM, routes /v1/decisions et /v1/systemone · consulté le 28/10/2026 · 14 octobre 2026 · Source documentaire

La mention « consulté le » indique la date de lecture. Une source peut avoir été publiée plus tôt, puis modifiée.

Historique des mises à jour