Jev a réduit le coût de cet agent IA de 61 %

En juillet, j’ai écrit que les petits modèles devraient décider de ce que les grands modèles voient : non pas router une tâche vers un modèle moins cher, mais placer des petits modèles aux côtés du grand pour choisir quels tokens celui-ci lira. J’ai conclu cet article en disant que l’économie était une raison d’expérimenter et non une preuve, et que quelqu’un devait faire le test.

Puis Jev est sorti le 15 septembre. C’est le premier modèle System One de TypeSafe : il n’écrit aucun texte, il renvoie des probabilités calibrées sur des réponses définies par votre code, il coûte 0,042 $ par million de tokens d’entrée, et il répond en quelques centaines de millisecondes. Cette combinaison rend deux versions concrètes de l’idée de juillet assez peu coûteuses pour être mesurées.

J’ai donc testé ces deux versions.

Le préchargement des compétences. Un agent doté d’un catalogue de documents internes passe tout un cycle à décider lequel lire et à appeler un outil pour le récupérer. Jev peut prendre cette décision avant le premier tour, pour une fraction de cent, et les documents arrivent déjà dans le prompt.

Le filtrage du payload des outils. Une réponse API réelle contient surtout des champs sur lesquels aucun agent n’agira, et dans une configuration MCP, tout cela atterrit dans la fenêtre de contexte et est renvoyé à chaque tour suivant. Jev peut noter chaque champ d’une réponse avant que l’agent ne le voie.

Il s’agit dans les deux cas de problèmes de classification, et non d’écriture. Voici les résultats sur 192 exécutions pour 8 tâches, tarifées sur Claude Opus 5 :

La tâche la plus optimisée est devenue 61 % moins chère. La moyenne sur les huit est de 29 %, et la moins optimisée de 13 %. 99 % des contrôles de qualité ont été validés dans chaque configuration, y compris la simple, donc rien n’a été sacrifié pour obtenir ces gains.

L’ensemble de l’expérience a coûté 1,17 $ à exécuter.

Qu’est-ce que Jev

Il ne génère pas de texte. Vous lui envoyez un state et un ensemble de questions typées, et il renvoie une distribution de probabilités calibrées sur les réponses définies par votre code. TypeSafe appelle cela un modèle System One, entraîné avec ce qu’ils décrivent comme de l’apprentissage par renforcement pour des décisions calibrées.

La propriété qui rend cette expérience possible est le batching. Chaque question est envoyée dans un seul appel HTTP avec le state envoyé une seule fois. Noter 264 champs de payload représente une seule requête, et non 264.

Mécanisme un : préchargement des compétences

Avant le premier tour de l’agent, Jev lit la requête et la description d’une ligne de chaque compétence. Il ne voit jamais le corps d’une compétence. Tout score égal ou supérieur à 0,55 est injecté intégralement dans le prompt système.

L’outil read_skill reste disponible, donc l’agent peut toujours récupérer tout ce que le routeur aurait manqué. C’est important, car le routeur manque parfois des choses.

Mécanisme deux : filtrage du payload des outils

Après le retour d’un outil et avant que sa sortie n’atteigne l’agent, chaque champ terminal de la réponse est noté selon sa pertinence pour la requête actuelle. Tout ce qui est inférieur à 0,35 est supprimé.

Il est intéressant de noter dans ces scores que les champs supprimés lors de cet appel se situent entre 0,31 et 0,34 et ceux conservés entre 0,35 et 0,37. La frontière est réelle, et quelques champs la franchissent entre les exécutions. trial_end a été noté 0,34 dans une exécution et 0,37 dans une autre. Rien dont la tâche avait besoin n’était proche de cette limite.

D’où vient réellement la sécurité

C’est dans cette troisième étape, l’état, que tout se décide. Le même seuil avec un état moins riche est dangereux. Avec un état riche, il est à la fois plus sûr et plus agressif.

Mesuré isolément sur le champ qui décide de la tâche de relance :

Les deux colonnes centrales sont les scores attribués au champ dont la tâche dépend réellement. La dernière indique combien des 124 champs survivent à la coupe de 0,35.

L’ajout des compétences ne change rien. L’historique aide un peu. Le déclencheur est la liste des actions restantes. Tant que le scoreur ne sait pas qu’un appel billing_set_account_state(account_id, …) est en attente, un id de compte n’est qu’une chaîne de caractères comme une autre.

La forme générale, qui est la partie transposable à une autre configuration :

Un champ n’est pas utile en soi. Il est utile pour ce que l’agent s’apprête à en faire, et cette information n’est pas dans le payload. Elle se trouve dans le schéma des outils encore disponibles.

Où sont les gains, et où ils ne sont pas

Les deux mécanismes suivent des choses complètement différentes, et savoir lequel s’applique à votre charge de travail importe plus que la moyenne.

L’écart est important. Sur la tâche où six articles du centre d’aide arrivent et où seul updated_at compte, le filtrage supprime 84 % du payload et 63 % des tokens d’entrée. Sur la tâche d’incident, où presque chaque champ est utilisé, il en supprime 5 %. Même agent, même seuil, un facteur 17 entre les deux.

Coût sur Opus 5, par tâche, agent simple contre les deux mécanismes :

Un agent Opus 5 traitant 10 000 tâches par mois passe de 419 $ à 299 $, dont 9 $ vont à Jev.

Le prix de votre modèle principal détermine si le filtrage en vaut la peine

C’est le résultat qui devrait changer votre approche.

Le filtrage coûte des tokens Jev à chaque appel d’outil. Ces tokens ont un prix fixe. Les tokens économisés sont tarifés au prix de votre modèle d’agent. C’est donc un ratio, et il s’inverse.

Les nombres de tokens sont identiques partout. Seul le tarif de l’agent change. Sur le modèle bon marché, Jev représente 42 % de la facture et le filtrage coûte plus qu’il ne rapporte. Sur Opus 5, il représente 3 % de la facture.

Le point de bascule, en maintenant les nombres de tokens mesurés et la structure tarifaire habituelle, se situe à 0,55 $ par million de tokens d’entrée avec mise en cache du prompt, et 0,37 $ sans. En dessous, ne filtrez pas. Au-dessus, filtrez.

Le préchargement des compétences est rentable partout, même sur le modèle le moins cher, car il ne coûte presque rien : environ 1 500 tokens Jev par exécution, soit 0,00006 $, contre un tour économisé.

Il y a un effet de second ordre à connaître. Le cache divise approximativement la facture par deux et réduit la valeur relative du filtrage, car la plupart de ce que le filtrage supprime auraient été des lectures de cache peu coûteuses. Le filtrage a plus de valeur pour un déploiement sans cache que pour un déploiement avec cache.

Le mode de défaillance

Le seuil de 0,35 n’est sûr que grâce à l’état riche. Une version antérieure sans cet état a produit le pire genre d’échec.

Le filtre a supprimé account.id d’un abonnement Stripe, le notant 0,18, et a également supprimé metadata.account_id, la seconde copie. L’agent a pris le seul identifiant restant et a fait ceci :

appel:   billing_set_account_state(account_id="cus_PmT4k9WqLr2XbN", state="read_only")
                                              ↑ l’id client Stripe, pas celui du compte

rapport: "J’ai passé le compte associé en lecture seule, conformément à la politique du jour 10."

L’identifiant correct était acct_borealis_4c77. L’agent a agi sur le mauvais objet et a produit un rapport confiant à son sujet.

Tout ce que vous déployez a besoin de chemins critiques déclarés et d’un seuil calibré en fonction d’eux. Deux centièmes de seuil séparent “économise un tour” de “n’économise rien” côté routage, et l’écart est bien plus grand pour le filtrage.

Ce que j’en retire

Travailler sur l’efficacité de l’IA vaut le temps investi, et combiner des modèles de tailles et de types différents est là que se trouve une grande partie du gain. Ce qui est intéressant, c’est qu’un modèle incapable d’écrire du texte s’avère être un bon juge de ce qu’un modèle qui écrit du texte devrait être autorisé à voir.

Deux points de départ ont été testés ici. Il existe bien d’autres endroits où le même schéma pourrait s’appliquer : choisir quels fichiers un agent ouvre, décider quand une conversation doit être compactée, noter si un document récupéré vaut ses tokens, filtrer une écriture avant qu’elle n’ait lieu. Rien de tout cela n’a été mesuré, et je ne supposerais pas que cela fonctionne avant de l’avoir vérifié.

Le relevé complet se trouve ci-dessous : le harnais, chaque tâche, chaque seuil, tous les tableaux, et les éléments que ceci ne montre pas.

Les détails complets

Tout ce qui suit est l’expérience complète. C’est volontairement long. Si vous ne vouliez que le résultat, vous l’avez déjà.

La configuration

L’agent

Environ 80 lignes. Pas de framework, pas de SDK d’agent, pas de bibliothèque d’orchestration. Une boucle while autour de fetch :

1. POST vers l’endpoint de complétion de chat d’OpenRouter avec la liste des messages et les schémas d’outils au format d’appel de fonction d’OpenAI.
2. Si la réponse contient des tool_calls, exécutez-en chacun localement, poussez le résultat comme un message role: "tool", et bouclez.
3. Si la réponse n’a pas de tool_calls, ce texte est la réponse finale et la boucle s’arrête.

Sur le raisonnement spécifiquement : aucun paramètre reasoning n’a été passé, le modèle a donc tourné avec le défaut du fournisseur. Un appel de contrôle effectué après renvoie reasoning_tokens: 0, donc aucun budget de raisonnement distinct n’a été dépensé et aucun des comptes de tokens n’inclut de tokens de raisonnement cachés. Relancer cela avec un effort de raisonnement plus élevé produirait des chiffres absolus différents.

Deux garde-fous, car une boucle d’agent incontrôlée brûle de l’argent : 8 tours maximum par exécution, et 6 appels d’outils maximum par tour. Aucun n’a été atteint lors des 192 exécutions. Un troisième garde-fou somme chaque appel et s’arrête une fois que le total dépasse un plafond, fixé à 2,60 $ pour la campagne.

Le monde

Une SaaS B2B fictive appelée Northwind Analytics, avec l’agent comme assistant des opérations.

17 outils dont les payloads imitent la forme réelle de Stripe, Zendesk, HubSpot, Statuspage, PagerDuty, Slack, Linear et d’un CMS de centre d’aide : mêmes noms de clés, même imbrication, même bruit. Ce sont des fonctions locales renvoyant des fixtures, donc rien ne quitte la machine. Les écritures sont enregistrées pour la notation et renvoient un accusé de réception plausible.

11 compétences, fichiers Markdown avec une description d’une ligne dans le front matter et un corps contenant les seuils, chiffres et formats réels : churn-save-offers, docs-review-cadence, dunning-playbook, enterprise-contract-terms, escalation-matrix, gdpr-data-requests, incident-comms, oncall-handover, refund-policy, release-notes-format, slack-style-guide. Plusieurs ne concernent aucune tâche. Ce sont des distracteurs pour le routeur.

8 tâches, choisies pour couvrir deux axes indépendants : la longueur, d’un seul appel d’outil à sept tours, et la densité du payload, de “chaque champ compte” à “76 % des octets sont du texte à jeter”.

Les tâches, verbatim

Notation

Déterministe. 59 contrôles sur les huit tâches, chacun étant soit un appel d’outil avec des arguments exacts, comme stripe_create_refund(charge="ch_3QRk9X…", amount=14900, reason="duplicate"), soit un fait qui apparaît uniquement à l’intérieur d’un document de compétence : le palier SLA de 25 %, la règle du jour 10, l’équipe PRIV, le délai de 30 jours.

Aucun juge LLM n’est impliqué. Une exécution qui n’ouvre jamais les compétences échoue mécaniquement au second type de contrôle, ce qui est le but : cela rend mesurable le fait de savoir si “l’agent possédait réellement la politique” plutôt que d’en faire une question d’opinion.

Chaque tâche déclare également ses chemins de payload critiques, les champs dont sa réponse dépend. Ceux-ci ne sont jamais utilisés pour orienter le filtre. Ils existent pour qu’un filtre trop zélé soit visible dans le relevé, même sur des exécutions qui réussissent malgré tout.

Les configurations (Arms)

8 tâches × 4 configurations × 6 répétitions = 192 exécutions, les répétitions différant uniquement par le seed.

Calibration

Les deux seuils ont été balayés hors ligne avant que des tokens d’agent ne soient dépensés.

0,55 pour le routage est la valeur la plus élevée qui maintient un rappel complet sur les tâches contre lesquelles il a été calibré. À 0,60, slack-style-guide obtient un score de 0,58 sur la tâche de remboursement et le tour économisé s’évapore. Deux centièmes séparent une réduction de tour de 15 % de rien du tout.

0,35 pour le filtrage n’est tenable qu’en raison de l’état riche décrit plus haut. La passe de calibration coûte environ 0,004 $ car elle fait tourner le routeur et le scoreur sans lancer l’agent.

Une leçon généralisable : chaque formulation d’une question a sa propre calibration. Un seuil ne se transfère pas entre deux formulations d’une même question. Des distributions sur des supports complètement différents ont été mesurées pour une formulation spécifique à la tâche et une formulation indépendante de la tâche. Recalibrez dès que vous reformulez.

Totaux de la campagne

Global, par configuration

Aucune technique n’a dégradé la qualité. 99 % des contrôles passent dans les quatre configurations. Sur 96 appels filtrés dans la configuration D, exactement un chemin déclaré critique a été supprimé, et cette exécution a tout de même réussi. Les différences de “perfection” par exécution entre 92 % et 96 % sont négligeables pour n = 48. Les effets robustes concernent les tours et les tokens.

Tokens moyens par exécution, répartis selon la facturation réelle :

La configuration D réduit les tokens d’entrée frais, les plus coûteux, de 49 %.

Économie de tokens d’entrée par technique, du pire au meilleur

La seule cellule négative de toute la matrice est A sur la tâche SLA, où le routeur charge une compétence de trop sans supprimer de tour. La compétence supplémentaire entre dans le prompt système et est renvoyée à chaque tour. Les deux techniques ne s’additionnent pas toujours : sur les tâches SLA et post-mortem, D économise moins de tokens que B seul, pour exactement cette raison.

Comment le routeur a réellement noté

Probabilité moyenne par compétence, par tâche. “Chargé” signifie un score égal ou supérieur à 0,55.

Rappel : 132 des 144 compétences nécessaires ont été chargées, soit 92 %. Un oubli systématique et un faux positif systématique, tous deux dignes d’être mentionnés.

L’oubli est slack-style-guide sur la tâche post-mortem, avec un score de 0,47, sous le seuil, dans 12 exécutions sur 12. La tâche dit “informez l’entreprise de la situation” et le routeur ne lit pas cela comme une question de formatage. L’agent l’a récupérée lui-même quand il en a eu besoin.

Le faux positif est refund-policy sur la tâche SLA à 0,84 et le post-mortem à 0,89. Un crédit SLA ressemble à un remboursement. C’est exactement la confusion que refund-policy existe pour interdire, car le document précise que l’indisponibilité du service n’est pas un remboursement. Le routeur se trompe sur la forme mais a raison sur le fond, et l’agent n’en a pas souffert.

La tâche de recherche ne charge rien, correctement. Aucune compétence ne la concerne et le score le plus élevé est de 0,07.

Comment le filtre a réellement réagi

Configuration D, par outil, sur 96 appels filtrés :

Les outils de lecture sont ceux qui rapportent, et l’écart entre eux est énorme : de −89 % sur une liste de documents à −25 % sur un incident où presque tout est crucial.

Les accusés de réception d’écriture vont dans le mauvais sens. billing_apply_credit renvoie 147 caractères, et le marqueur _trimmed ajouté coûte plus cher que les champs supprimés. Filtrer un petit payload est une perte nette, et toute implémentation de production devrait ignorer tout ce qui fait moins de quelques centaines de caractères. Cela a été laissé pour que l’effet soit visible dans le relevé.

Chaque tâche, chaque configuration

Les prix sont le coût total d’une exécution, agent plus Jev, en utilisant la répartition mesurée entre frais et cache. Les colonnes Sonnet 5 et Opus 5 rejouent le trafic mesuré aux tarifs de ces modèles. Le coût de Jev est identique dans les trois colonnes.

T1-refund, moyen · payload mixte

T2-sla, long · payload mixte

T3-dunning, court · payload mixte

T4-gdpr, moyen · payload mixte

T5-incident, court · payload dense

T6-stale-docs, court · payload très clairsemé

T7-postmortem, très long · payload mixte

T8-lookup, un appel · payload clairsemé

Comment les prix ont été calculés

Mesurer une fois, puis recalculer le prix. Les nombres de tokens sont la base, et la facture de chaque modèle correspond à ces mêmes nombres aux tarifs du modèle.

La formule de facturation a été rétro-ingéniée à partir des données plutôt que supposée. Sur les 192 exécutions, le coût de l’agent observé correspond à

entrée_fraîche × 0,25 $/M  +  entrée_cachée × 0,02 $/M  +  sortie × 1,20 $/M

avec une erreur relative médiane de 0,04 %. Deux conséquences. La mise en cache du prompt était active tout le temps, automatiquement, sans marqueurs cache_control, et 80 % des tokens d’entrée étaient des lectures de cache. Et chaque token d’entrée frais est facturé au tarif d’écriture du cache, soit 1,25 fois le prix d’entrée nominal, donc le tarif nominal de 0,20 $/M n’est pratiquement jamais ce que vous payez dans une boucle multi-tours.

Un modèle théorique antérieur de mise en cache, où les lectures au tour t étaient égales au préfixe au tour t−1, sous-estimait les lectures de cache réelles de 19 %. Il a été abandonné au profit de la répartition mesurée par tour.

Les mêmes exécutions sans aucune mise en cache, pour référence :

Une hypothèse est conservatrice plutôt que neutre. OpenAI met en cache automatiquement et facture chaque token d’entrée frais au tarif d’écriture, ce qui a été mesuré. La mise en cache d’Anthropic est optionnelle : seul le contenu à l’intérieur d’un point d’arrêt cache_control est facturé au tarif d’écriture et le reste au tarif d’entrée simple. Facturer tous les tokens frais au tarif d’écriture surestime donc légèrement les colonnes Anthropic. Le recalcul avec les tokens frais au tarif d’entrée simple déplace la moyenne d’Opus 5 de 0,04191 $ → 0,02995 $ (−29 %) à 0,03823 $ → 0,02808 $ (−27 %), et aucun chiffre par tâche ne bouge de plus de 3 points.

Ce que cela ne montre pas

• Un seul modèle d’agent. Tout est mesuré sur openai/gpt-5.6-luna avec le raisonnement par défaut. Les nombres de tokens sont la donnée et les colonnes de prix sont des calculs basés sur eux. Un modèle différent produirait des nombres de tokens différents, pas seulement des prix différents.
• n = 6 par cellule. Suffisant pour les nombres de tours et de tokens, qui sont quasi déterministes. Pas assez pour séparer une qualité de 92 % d’une qualité de 96 %.
• Fixtures, pas d’API réelles. Les formes de payload sont fidèles. Les endpoints réels ont une pagination, des échecs partiels et des limites de débit que ce harnais n’exerce pas.
• Les tâches ont été écrites par la même personne que les compétences. La notation est déterministe, mais le monde n’est pas adverse.
• La propre calibration de Jev n’a pas été auditée. Ce qui a été mesuré est l’effet de ses scores sur un agent, et non si ils sont bien calibrés au sens statistique.
• Une seule structure d’agent. Une boucle while avec appel de fonction. Les sous-agents, les appels d’outils parallèles et les sessions de longue durée changent tous l’arithmétique.

Sources

• TypeSafe: introducing System One models and Jev
• TypeSafe: System One concepts
• Jev 1.13 on OpenRouter
• Mon article précédent : les petits modèles devraient décider de ce que les grands modèles voient
• Model Context Protocol: tools specification