Jev hat die Kosten dieses KI-Agenten um 61 % gesenkt

Im Juli schrieb ich, dass kleine Modelle entscheiden sollten, was große Modelle sehen: Es geht nicht darum, eine Aufgabe an ein günstigeres Modell weiterzuleiten, sondern kleine Modelle neben das große zu setzen, um zu entscheiden, welche Token es überhaupt liest. Ich beendete diesen Beitrag mit der Feststellung, dass die wirtschaftlichen Faktoren ein Grund für Experimente waren, aber noch kein Beweis, und dass jemand den Test durchführen müsse.

Dann veröffentlichte Jev am 15. September. Es ist das erste System One-Modell von TypeSafe: Es schreibt keinerlei Text, sondern gibt kalibrierte Wahrscheinlichkeiten für Antworten zurück, die Ihr Code definiert. Es kostet 0,042 $ pro Million Input-Token und antwortet in wenigen hundert Millisekunden. Diese Kombination macht zwei sehr konkrete Versionen der Juli-Idee günstig genug, um sie tatsächlich zu messen.

Ich habe diese zwei Versionen getestet.

Skills vorladen. Ein Agent, der einen Katalog interner Dokumente erhält, verbringt einen kompletten Roundtrip damit, zu entscheiden, welches er lesen soll, und ein Tool aufzurufen, um sie abzurufen. Jev kann diese Entscheidung vor dem ersten Zug für einen Bruchteil eines Cents treffen, sodass die Dokumente bereits im Prompt ankommen.

Tool-Payload filtern. Eine echte API-Antwort besteht größtenteils aus Feldern, auf die kein Agent reagieren wird. In einem MCP-Setup landet all dies im Kontextfenster und wird bei jedem folgenden Zug erneut gesendet. Jev kann jedes Feld einer Antwort bewerten, bevor der Agent es sieht.

Beides sind Klassifizierungsprobleme, keine Schreibprobleme. Hier ist das Ergebnis von 192 Durchläufen bei 8 Aufgaben, bepreist mit Claude Opus 5:

Die beste Aufgabe wurde 61 % günstiger. Der Durchschnitt über alle acht liegt bei 29 %, die schlechteste bei 13 %. 99 % der Qualitätsprüfungen wurden in jedem Arm bestanden, auch beim einfachen Agenten, sodass für die Einsparungen keine Abstriche bei der Qualität gemacht wurden.

Das gesamte Experiment kostete 1,17 $.

Was Jev ist

Es generiert keinen Text. Sie senden einen state und eine Reihe typisierter Fragen, und es gibt eine kalibrierte Wahrscheinlichkeitsverteilung über die in Ihrem Code definierten Antworten zurück. TypeSafe nennt es ein System One-Modell, das mit einer von ihnen als Reinforcement Learning für kalibrierte Entscheidungen beschriebenen Methode trainiert wurde.

Die Eigenschaft, die dieses Experiment überhaupt erst ermöglicht, ist das Batching. Jede Frage erfolgt in einem einzigen HTTP-Aufruf, wobei der state nur einmal gesendet wird. Die Bewertung von 264 Payload-Feldern ist eine Anfrage, nicht 264.

Mechanismus eins: Skills vorladen

Vor dem ersten Zug des Agenten liest Jev die Anfrage und die einzeilige Beschreibung jedes Skills. Es sieht niemals den Inhalt eines Skills. Alles, was einen Wert von 0,55 oder höher erreicht, wird vollständig in den System-Prompt injiziert.

Das read_skill-Tool bleibt verfügbar, sodass der Agent immer noch alles abrufen kann, was der Router übersehen hat. Das ist wichtig, denn der Router übersieht gelegentlich Dinge.

Mechanismus zwei: Tool-Payload filtern

Nachdem ein Tool einen Wert zurückgegeben hat und bevor die Ausgabe den Agenten erreicht, wird jedes Blatt-Feld der Antwort auf seine Relevanz für die aktuelle Anfrage bewertet. Alles unter 0,35 wird entfernt.

Bemerkenswert an diesen Scores: Die Felder, die in diesem Aufruf gekürzt werden, liegen bei 0,31 bis 0,34, und die, die bleiben, bei 0,35 bis 0,37. Die Grenze ist tatsächlich eine Grenze, und einige wenige Felder überschreiten sie zwischen den Durchläufen. trial_end wurde in einem Durchlauf mit 0,34 und in einem anderen mit 0,37 bewertet. Nichts, was die Aufgabe benötigte, lag jemals in der Nähe.

Woher die Sicherheit tatsächlich kommt

In diesem dritten Schritt, dem State, wird alles entschieden. Derselbe Schwellenwert bei einem schlechteren State ist gefährlich. Mit einem reichhaltigeren State ist er gleichzeitig sicherer und aggressiver.

Isoliert gemessen an dem Feld, das über die Dunning-Aufgabe entscheidet:

Die beiden mittleren Spalten zeigen die Scores für das Feld, von dem die Aufgabe tatsächlich abhängt. Die letzte Spalte zeigt, wie viele der 124 Felder die 0,35-Kürzung überleben.

Das Hinzufügen von Skills ändert nichts. Die Historie hilft ein wenig. Der Auslöser ist die Liste der verbleibenden Aktionen. Bevor der Scorer weiß, dass ein Aufruf von billing_set_account_state(account_id, …) ansteht, ist eine Konto-ID einfach nur ein weiterer String.

Die allgemeine Formel, die auf andere Setups übertragbar ist:

Ein Feld ist nicht an sich nützlich. Es ist nützlich für das, was der Agent als Nächstes damit tun wird, und diese Information steckt nicht in der Payload. Sie steckt im Schema der noch verfügbaren Tools.

Wo die Gewinne liegen und wo nicht

Die zwei Mechanismen adressieren völlig unterschiedliche Dinge. Zu wissen, welcher auf Ihren Workload zutrifft, ist wichtiger als der Durchschnitt.

Die Spanne ist groß. Bei der Aufgabe, bei der sechs Hilfe-Center-Artikel ankommen und nur updated_at zählt, entfernt die Filterung 84 % der Payload und 63 % der Input-Token. Bei der Incident-Aufgabe, bei der fast jedes Feld genutzt wird, sind es 5 %. Gleicher Agent, gleicher Schwellenwert, ein Faktor von 17 Unterschied.

Kosten auf Opus 5, pro Aufgabe, einfacher Agent gegenüber beiden Mechanismen:

Ein Opus 5-Agent, der 10.000 Aufgaben pro Monat bearbeitet, sinkt von 419 $ auf 299 $, wovon 9 $ auf Jev entfallen.

Der Preis Ihres Hauptmodells entscheidet, ob Filterung sinnvoll ist

Dies ist das Ergebnis, das Ihr Vorgehen ändern sollte.

Filterung kostet bei jedem Tool-Aufruf Jev-Token. Diese Token haben einen Festpreis. Die Token, die sie einspart, kosten das, was Ihr Agent-Modell kostet. Das Ganze ist also ein Verhältnis, und es kippt.

Die Token-Zahlen bleiben gleich. Nur der Satz des Agenten ändert sich. Beim günstigen Modell macht Jev 42 % der Rechnung aus, und die Filterung kostet mehr, als sie einspart. Bei Opus 5 sind es 3 % der Rechnung.

Berechnet man den Schnittpunkt unter Beibehaltung der gemessenen Token-Zahlen und der üblichen Preisstruktur, liegt dieser bei 0,55 $ pro Million Input-Token mit aktivem Prompt-Caching und bei 0,37 $ ohne. Darunter: nicht filtern. Darüber: filtern.

Das Vorladen von Skills ist überall profitabel, auch beim günstigsten Modell, da es fast nichts kostet: etwa 1.500 Jev-Token pro Durchlauf, 0,00006 $, gegenüber einem eingesparten Zug.

Es gibt einen Effekt zweiter Ordnung, den man kennen sollte. Caching halbiert die Rechnung in etwa und verringert den relativen Wert der Filterung, da das meiste, was die Filterung entfernt, günstige Cache-Reads gewesen wären. Filterung ist für ein Deployment ohne Caching wertvoller als für eines mit.

Der Failure-Mode

Der 0,35-Schwellenwert ist nur wegen des reichhaltigen States sicher. Eine frühere Version ohne diesen produzierte die schlimmste Art von Fehlern.

Der Filter entfernte die account.id aus einem Stripe-Abonnement (Score 0,18) und entfernte auch metadata.account_id, die zweite Kopie. Der Agent nahm die einzige verbleibende ID und tat dies:

call:   billing_set_account_state(account_id="cus_PmT4k9WqLr2XbN", state="read_only")
                                              ↑ die Stripe Kunden-ID, nicht die Konto-ID

report: "Ich habe das zugehörige Konto auf schreibgeschützt gesetzt, gemäß der Tag-10-Richtlinie."

Die korrekte ID war acct_borealis_4c77. Der Agent handelte gegenüber dem falschen Objekt und erstellte einen selbstbewussten Bericht darüber.

Alles, was Sie bereitstellen, benötigt definierte kritische Pfade und einen darauf kalibrierten Schwellenwert. Zwei Hundertstel eines Schwellenwerts trennten auf der Routing-Seite “spart einen Zug” von “spart nichts”, und bei der Filterung war die Lücke noch viel größer.

Mein Fazit daraus

An KI-Effizienz zu arbeiten, lohnt die Zeit, und die Kombination von Modellen unterschiedlicher Größe und Art ist ein zentraler Hebel. Interessant ist, dass ein Modell, das überhaupt keinen Text schreiben kann, sich als guter Richter dafür erweist, was ein textschreibendes Modell sehen darf.

Hier wurden zwei Ausgangspunkte getestet. Es gibt viele weitere Stellen, an denen dasselbe Muster anwendbar wäre: die Entscheidung, welche Dateien ein Agent öffnet; wann ein Gespräch komprimiert werden sollte; ob ein abgerufenes Dokument seine Token wert ist; das Gating eines Schreibvorgangs, bevor er geschieht. Nichts davon wurde gemessen, und ich würde nicht annehmen, dass es funktioniert, bevor es bewiesen ist.

Die vollständige Aufzeichnung folgt unten: das Harness, jede Aufgabe, jeder Schwellenwert, alle Tabellen und die Dinge, die hier nicht gezeigt werden.

Die vollständigen Details

Alles ab hier ist das komplette Experiment. Es ist absichtlich lang. Wenn Sie nur das Ergebnis wollten, haben Sie es bereits.

Das Setup

Der Agent

Etwa 80 Zeilen. Kein Framework, kein Agent-SDK, keine Orchestrierungs-Bibliothek. Eine while-Schleife um fetch:

1. POST an den Chat-Completions-Endpoint von OpenRouter mit der Nachrichtenliste und den Tool-Schemata im OpenAI-Function-Calling-Format.
2. Wenn die Antwort tool_calls enthält, führe jeden lokal aus, pushe das Ergebnis als role: "tool"-Nachricht und loop.
3. Wenn die Antwort keine tool_calls hat, ist dieser Text die endgültige Antwort und die Schleife endet.

Speziell zum Reasoning: Es wurde nie ein reasoning-Parameter übergeben, daher lief das Modell mit dem Standardwert des Providers. Ein nachträglicher Kontrollaufruf ergab reasoning_tokens: 0, sodass kein separates Reasoning-Budget verbraucht wurde und keine der Token-Zahlen versteckte Reasoning-Token enthält. Ein erneuter Durchlauf mit höherem Reasoning-Aufwand würde andere absolute Zahlen ergeben.

Zwei Sicherheitsmechanismen, da eine außer Kontrolle geratene Agenten-Schleife Geld verbrennt: maximal 8 Züge pro Durchlauf und maximal 6 Tool-Aufrufe pro Zug. Beides wurde in den 192 Durchläufen nicht erreicht. Eine dritte Sicherung summiert jeden Aufruf und bricht ab, sobald die Gesamtsumme eine Grenze überschreitet, die für die Kampagne auf 2,60 $ festgelegt wurde.

Die Welt

Ein fiktives B2B-SaaS namens Northwind Analytics, wobei der Agent als Operations-Assistent fungiert.

17 Tools, deren Payloads die reale Form von Stripe, Zendesk, HubSpot, Statuspage, PagerDuty, Slack, Linear und einem Hilfe-Center-CMS imitieren: gleiche Schlüsselnamen, gleiche Verschachtelung, gleiches Rauschen. Es sind lokale Funktionen, die Fixtures zurückgeben, sodass nichts die Maschine verlässt. Schreibvorgänge werden für die Bewertung aufgezeichnet und geben eine plausible Bestätigung zurück.

11 Skills, Markdown-Dateien mit einer einzeiligen description im Front Matter und einem Body, der die eigentlichen Schwellenwerte, Zahlen und Formate enthält: 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. Einige davon haben keinerlei Relevanz für die Aufgaben. Sie dienen als Distraktoren für den Router.

8 Aufgaben, gewählt um zwei unabhängige Achsen abzudecken: Länge (von einem einzigen Tool-Aufruf bis zu sieben Zügen) und Payload-Dichte (von “jedes Feld zählt” bis “76 % der Bytes sind wegschmeißbarer Text”).

Die Aufgaben, wortwörtlich

Bewertung

Deterministisch. 59 Prüfungen über die acht Aufgaben hinweg, jede davon entweder ein Tool-Aufruf mit exakten Argumenten, wie stripe_create_refund(charge="ch_3QRk9X…", amount=14900, reason="duplicate"), oder ein Fakt, der nur in einem Skill-Dokument vorkommt: die 25 % SLA-Stufe, die Tag-10-Regel, das PRIV-Team, die 30-Tage-Frist.

Es ist nirgendwo ein LLM-Judge involviert. Ein Durchlauf, der die Skills nie öffnet, scheitert mechanisch an der zweiten Art von Prüfung. Das ist der Punkt: es macht messbar, ob der Agent die Richtlinie tatsächlich vorliegen hatte, statt es einer Meinung zu überlassen.

Jede Aufgabe definiert zudem ihre kritischen Payload-Pfade, also die Felder, von denen die Antwort abhängt. Diese werden niemals zur Steuerung des Filters verwendet. Sie existieren, damit ein zu eifriger Filter in der Aufzeichnung sichtbar wird, selbst wenn der Durchlauf dennoch erfolgreich war.

Die Arme

8 Aufgaben × 4 Arme × 6 Wiederholungen = 192 Durchläufe, Wiederholungen unterscheiden sich nur durch den seed.

Kalibrierung

Beide Schwellenwerte wurden offline geprüft, bevor Agent-Token verbraucht wurden.

0,55 für das Routing ist der höchste Wert, der den vollen Recall bei den Aufgaben beibehält, gegen die er kalibriert wurde. Bei 0,60 erreicht slack-style-guide einen Wert von 0,58 bei der Refund-Aufgabe, und die Ersparnis des Zuges verpufft. Zwei Hundertstel trennen eine Reduzierung der Züge um 15 % von gar nichts.

0,35 für die Filterung ist nur dank des oben beschriebenen reichhaltigen States haltbar. Der Kalibrierungslauf kostete etwa 0,004 $, da er den Router und Scorer ausführt, ohne den Agenten überhaupt zu starten.

Eine verallgemeinerbare Lektion: Jede Formulierung einer Frage hat ihre eigene Kalibrierung. Ein Schwellenwert lässt sich nicht zwischen zwei Formulierungen derselben Frage übertragen. Verteilungen auf völlig unterschiedlichen Grundlagen wurden für eine aufgabenspezifische und eine aufgabenunabhängige Formulierung gemessen. Rekalibrieren Sie immer, wenn Sie umformulieren.

Gesamtkosten der Kampagne

Gesamtübersicht nach Arm

Keine Technik verschlechterte die Qualität. 99 % der Prüfungen wurden in allen vier Armen bestanden. Über 96 gefilterte Aufrufe im Arm D wurde genau ein als kritisch markierter Pfad entfernt, und dieser Durchlauf war dennoch erfolgreich. Die Unterschiede bei den “perfekten” Durchläufen zwischen 92 % und 96 % liegen bei n = 48 im Rauschen. Die robusten Effekte sind Züge und Token.

Durchschnittliche Token pro Durchlauf, aufgeteilt wie sie tatsächlich abgerechnet werden:

Arm D reduziert frische Input-Token, die teure Sorte, um 49 %.

Input-Token-Ersparnis pro Technik, schlechteste bis beste

Die einzige negative Zelle in der gesamten Matrix ist A bei der SLA-Aufgabe, wo der Router einen Skill zu viel lädt, ohne einen Zug einzusparen. Der extra Skill gelangt in den System-Prompt und wird dann in jedem Zug erneut gesendet. Die zwei Techniken addieren sich zudem nicht immer: Bei den SLA- und Postmortem-Aufgaben spart D weniger Token als B allein, und zwar genau aus diesem Grund.

Wie der Router tatsächlich bewertet hat

Durchschnittliche Wahrscheinlichkeit pro Skill, pro Aufgabe. “Geladen” bedeutet 0,55 oder höher.

Recall: 132 von 144 benötigten Skills geladen, 92 %. Ein systematischer Fehler und ein systematischer falsch-positiver Treffer, beide sollten offen benannt werden.

Der Fehler ist slack-style-guide bei der Postmortem-Aufgabe, mit einem Score von 0,47 (unter dem Schwellenwert) in 12 von 12 Durchläufen. Die Aufgabe verlangt, “dem Unternehmen mitzuteilen, wie es steht”, und der Router interpretiert dies nicht als Formatierungsfrage. Der Agent hat den Skill selbst abgerufen, als er ihn benötigte.

Der falsch-positive Treffer ist refund-policy bei der SLA-Aufgabe mit 0,84 und beim Postmortem mit 0,89. Eine SLA-Gutschrift sieht aus wie eine Rückerstattung. Genau diese Verwechslung soll refund-policy verhindern, da das Dokument besagt, dass Service-Nichtverfügbarkeit keine Rückerstattung ist. Der Router liegt formal falsch, inhaltlich aber richtig, und der Agent wurde dadurch nicht beeinträchtigt.

Die Lookup-Aufgabe lädt korrekterweise nichts. Kein Skill ist relevant und der höchste Score liegt bei 0,07.

Wie sich der Filter tatsächlich verhielt

Arm D, nach Tool, über 96 gefilterte Aufrufe:

Bei den Lese-Tools liegt das große Geld, und die Spanne zwischen ihnen ist enorm: von −89 % bei einer Dokumentenliste bis −25 % bei einem Incident, bei dem fast alles entscheidend ist.

Die Schreib-Bestätigungen schlagen in die andere Richtung aus. billing_apply_credit gibt 147 Zeichen zurück, und der angehängte _trimmed-Marker kostet mehr als die entfernten Felder. Die Filterung einer kleinen Payload ist ein Nettoverlust, und jede Produktionsimplementierung sollte alles unter ein paar hundert Zeichen konsequent auslassen. Es wurde hier beibehalten, damit der Effekt in der Aufzeichnung sichtbar ist.

Jede Aufgabe, jeder Arm

Die Preise sind die Gesamtkosten eines Durchlaufs, Agent plus Jev, unter Verwendung der gemessenen Aufteilung zwischen frisch und cached. Die Spalten für Sonnet 5 und Opus 5 berechnen den gemessenen Traffic zu den Preisen dieser Modelle. Die Kosten für Jev sind in allen drei Spalten identisch.

T1-refund, mittel · gemischte Payload

T2-sla, lang · gemischte Payload

T3-dunning, kurz · gemischte Payload

T4-gdpr, mittel · gemischte Payload

T5-incident, kurz · dichte Payload

T6-stale-docs, kurz · sehr spärliche Payload

T7-postmortem, sehr lang · gemischte Payload

T8-lookup, ein Aufruf · spärliche Payload

Wie die Preise berechnet wurden

Einmal messen, dann neu bepreisen. Die Token-Zahlen sind die Basis, und die Rechnung jedes Modells basiert auf diesen Zahlen zu den jeweiligen Tarifen.

Die Abrechnungsformel wurde aus den Daten rückwärts entwickelt, anstatt sie vorauszusetzen. Über alle 192 Durchläufe hinweg stimmt die beobachtete Agenten-Kostenrechnung mit

frischer_input × 0,25 $/M  +  cached_input × 0,02 $/M  +  output × 1,20 $/M

bei einem medianen relativen Fehler von 0,04 % überein. Zwei Konsequenzen daraus: Prompt-Caching war die ganze Zeit automatisch aktiv, ohne cache_control-Marker, und 80 % der Input-Token waren Cache-Reads. Zudem wird jeder frische Input-Token zum Cache-Write-Tarif abgerechnet, welcher das 1,25-fache des nominalen Input-Preises beträgt, sodass der nominale 0,20 $/M-Satz in einer Multi-Turn-Schleife faktisch nie das ist, was man bezahlt.

Ein früheres theoretisches Modell des Cachings, bei dem Reads in Zug t dem Präfix in Zug t−1 entsprechen, unterschätzte die realen Cache-Reads um 19 %. Es wurde zugunsten der gemessenen Aufteilung pro Zug verworfen.

Die gleichen Durchläufe ohne jegliches Caching als Referenz:

Eine Annahme ist konservativ statt neutral. OpenAI cached automatisch und berechnet jeden frischen Input-Token zum Write-Tarif, was gemessen wurde. Anthropic-Caching ist Opt-in: nur Inhalte innerhalb eines cache_control-Breakpoints werden zum Write-Tarif abgerechnet, der Rest zum normalen Input-Tarif. Die Abrechnung aller frischen Token zum Write-Tarif übertreibt die Anthropic-Spalten daher leicht. Eine Neuberechnung mit frischen Token zum normalen Input-Tarif verschiebt den Opus 5-Schnitt von 0,04191 $ → 0,02995 $ (−29 %) auf 0,03823 $ → 0,02808 $ (−27 %), und kein Einzelwert pro Aufgabe verschiebt sich um mehr als 3 Punkte.

Was dies nicht zeigt

• Ein Agenten-Modell. Alles wurde an openai/gpt-5.6-luna mit Standard-Reasoning gemessen. Die Token-Zahlen sind das Lieferbare, und die Preisspalten sind Arithmetik darauf. Ein anderes Modell würde andere Token-Zahlen produzieren, nicht nur andere Preise.
• n = 6 pro Zelle. Genug für Zug-Zahlen und Token-Zahlen, die nahezu deterministisch sind. Nicht genug, um 92 % von 96 % Qualität zu trennen.
• Fixtures, keine Live-APIs. Die Payload-Formen sind getreu. Echte Endpoints haben Pagination, partielle Fehler und Rate-Limits, die dieses Harness nicht prüft.
• Die Aufgaben wurden von derselben Person geschrieben wie die Skills. Die Bewertung ist deterministisch, aber die Welt ist nicht adversariell.
• Jevs eigene Kalibrierung wurde nicht auditiert. Gemessen wurde, was seine Scores mit einem Agenten machen, nicht ob sie im statistischen Sinne gut kalibriert sind.
• Eine Agenten-Struktur. Eine while-Schleife mit Function Calling. Sub-Agenten, parallele Tool-Aufrufe und langlebige Sessions ändern die Arithmetik.

Quellen

• TypeSafe: introducing System One models and Jev
• TypeSafe: System One concepts
• Jev 1.13 on OpenRouter
• Mein früherer Artikel: small models should decide what big models see
• Model Context Protocol: tools specification