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 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.

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.

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.

Le modèle direct documenté est 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.

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 sur Jev / TypeSafe AI

À lancer en mode Deep Research. Date de référence : 21 septembre 2026. Livrer en français, avec les titres et citations dans leur langue d'origine. Ne rien présumer sur l'architecture interne.

Je prépare un dossier technique évolutif sur Jev, premier « System One Model » de TypeSafe AI, pour un blog de développeurs et le Claude Code Ultimate Guide. Points de départ : https://typesafe.ai/ et https://typesafe.ai/blog/introducing-system-one-models-and-jev .

Mène une contre-enquête indépendante, et cherche activement les contre-exemples. Sépare les annonces du fournisseur, les démonstrations, les mesures indépendantes reproductibles, la littérature connexe et ce qui reste inconnu. 10 reprises d'un même communiqué ne constituent pas 10 confirmations.

1. Établis la chronologie : lancement, versions, accès effectif, SDK, tarification, évolutions documentées. Vérifie l'attribution à Diogo Almeida et le raccourci « co-inventeur de ChatGPT » sans reprendre un titre viral comme un fait.
2. Décris précisément ce que l’API accepte et renvoie : types de sortie, ensembles de choix, limites, probabilités, scores, seuils, erreurs, modèle/version, exemples de code réellement documentés. Distingue déterminisme, validité du schéma, justesse, calibration et abstention.
3. Examine RLCD (Reinforcement Learning for Calibrated Decisions) : publications, fiche du modèle, architecture, fonction de perte, données, évaluation. Cite les informations effectivement publiées ; marque UNKNOWN pour les détails non divulgués. Compare aux classifieurs supervisés, aux encodeurs, aux sorties contraintes par un schéma et aux routeurs. N'attribue pas à Jev les mécanismes d'un article portant sur un autre modèle.
4. Audite séparément 150 ms, 193,6×/200× plus rapide, 444,6× moins cher, 42 dollars par milliard de tokens d'entrée, sorties gratuites et « 0 hallucination ». Pour chaque chiffre : source originale, date, baseline/version, effort de raisonnement, taille d'entrée/sortie, matériel/région, concurrence, répétitions, latence médiane/p95, coût total et mesure de qualité. Signale les dénominateurs absents, l'usage de modèles juges et le risque de biais de sélection.
5. Trouve des essais indépendants, y compris échecs et critiques. Cherche des vidéos YouTube techniques, interviews des fondateurs, conférences, dépôts GitHub, issues, notebooks, arXiv, Hugging Face et discussions publiques. Pour les vidéos : URL, chaîne, date, vues à la collecte si observables, démonstration ou commentaire, transcript disponible ou non, passages horodatés. Exclure les homonymes Jev liés au jeu vidéo.
6. Vérifie les conditions concrètes d'emploi : accès, quotas, facturation, possibilité de fixer une version, traitement et rétention des données, régions, disponibilité, licences des SDK et des poids. Ne tire aucune conclusion de conformité de l'absence d'information.
7. Propose des expériences reproductibles : pré-tri d'issues GitHub, rapprochement d'erreurs Sentry avec des issues existantes, sélection de correctifs pour des notes de version, routage de skills FR/EN contre BM25, sélection de passages RAG et choix parmi beaucoup d'options. Pour chacune : hypothèse, méthode de référence simple, annotations humaines, jeu de calibration distinct du test, erreurs graves, coût par décision correcte, p50/p95, part des cas traités au taux d'erreur fixé, Brier/ECE, dérive et critères de rejet. Inclure les cas ambigus, hors domaine, négations et injections dans les données. Distinguer le coût de la décision et celui du traitement complet, y compris préparation et relecture.

Format attendu : une synthèse, un tableau des affirmations avec verdict et niveau de preuve, un catalogue dédupliqué des sources avec URL directe/auteur/date/type/indépendance, les contradictions, les questions encore ouvertes et une bibliographie scientifique séparant les papiers sur Jev des travaux de contexte. Pour chaque source, préciser ce qui a réellement été lu : texte intégral, abstract, transcript, métadonnées ou extrait de moteur. Fournir les requêtes négatives et les limites de couverture. Une source introuvable reste introuvable ; ne jamais inventer de référence ou d'extrait.

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.

• 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 21 septembre 2026, le dossier documente un service d’évaluation probabiliste et des résultats publics contrastés. Il ne confirme ni une rupture scientifique, ni l’accusation de « scam ». L’architecture et la méthode RLCD restent insuffisamment décrites pour trancher leur nouveauté ; le choix d’un outil dépend des résultats sur le workflow visé.

Le premier essai proposé est le pré-tri GitHub, en mode suggestion. Le jeu de test devra inclure des demandes ambiguës, des issues sans doublon et des cas incomplets. La comparaison avec les règles et le modèle actuels portera sur les erreurs, la part de cas traités, le temps de réponse et le coût total.

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

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