Jev senkte die Kosten dieses KI-Agenten um 61 %

Im Juli schrieb ich, dass kleine Modelle entscheiden sollten, was große Modelle zu sehen bekommen: Es geht nicht darum, eine Aufgabe an ein günstigeres Modell weiterzuleiten, sondern kleine Modelle neben dem großen einzusetzen, damit sie auswählen, welche Tokens es überhaupt liest. Am Ende des Artikels schrieb ich, die Kosten seien ein Grund zum Experimentieren, aber kein Beweis, und jemand müsse den Test durchführen.

Am 15. September wurde dann Jev veröffentlicht. Es ist das erste System-One-Modell von TypeSafe: Es erzeugt überhaupt keinen Text, sondern liefert kalibrierte Wahrscheinlichkeiten für Antworten, die dein Code vorgibt. Es kostet $0.042 pro Million Eingabe-Tokens und antwortet in wenigen hundert Millisekunden. Mit dieser Kombination lassen sich zwei sehr konkrete Varianten der Juli-Idee günstig genug umsetzen, um sie tatsächlich zu messen.

Also habe ich diese beiden Varianten getestet.

Skills vorab laden. Bekommt ein Agent einen Katalog interner Dokumente, braucht er einen ganzen zusätzlichen Durchlauf, um zu entscheiden, welches er lesen soll, und es dann über ein Tool abzurufen. Jev kann diese Entscheidung vor dem ersten Durchlauf für einen Bruchteil eines Cents treffen. Die Dokumente stehen dann bereits im Prompt.

Tool-Daten filtern. Eine echte API-Antwort enthält größtenteils Felder, mit denen ein Agent nichts anfangen kann. In einem MCP-Setup landen sie trotzdem alle im Kontextfenster und werden in jedem weiteren Durchlauf erneut gesendet. Jev kann jedes Feld einer Antwort bewerten, bevor der Agent sie zu sehen bekommt.

Beides sind Klassifizierungsaufgaben, keine Schreibaufgaben. So fielen die Ergebnisse bei 192 Läufen mit 8 Aufgaben aus, berechnet mit den Preisen für Claude Opus 5:

Ob ein Chat-Titel noch zur Unterhaltung passt, ist eine weitere mögliche Entscheidung für Jev. Ich beschreibe diesen Anwendungsfall in meinem Artikel über das Erstellen von Unterhaltungstiteln. Mit Jev habe ich ihn noch nicht gemessen.

Bei der besten Aufgabe sanken die Kosten um 61%. Der Durchschnitt über alle acht Aufgaben liegt bei 29%, der geringste Wert bei 13%. In jedem Versuchsarm bestanden 99% der Qualitätsprüfungen, auch beim einfachen Agenten. Es musste also nichts aufgegeben werden, um diese Einsparungen zu erzielen.

Das gesamte Experiment kostete $1.17.

Was Jev ist

Jev erzeugt keinen Text. Du übergibst ihm einen state und eine Reihe typisierter Fragen. Zurück kommt eine kalibrierte Wahrscheinlichkeitsverteilung über die Antworten, die dein Code definiert. TypeSafe bezeichnet Jev als System-One-Modell, das mit dem trainiert wurde, was das Unternehmen als Reinforcement Learning für kalibrierte Entscheidungen beschreibt.

Was dieses Experiment überhaupt erst möglich macht, ist Batch-Verarbeitung. Alle Fragen werden in einem HTTP-Aufruf übermittelt, der state wird nur einmal gesendet. 264 Datenfelder zu bewerten erfordert eine Anfrage, nicht 264.

Mechanismus eins: Skills vorab laden

Vor dem ersten Durchlauf des Agenten liest Jev die Anfrage und die einzeilige Beschreibung jedes Skills. Den Inhalt der Skills sieht Jev nie. Alles mit einem Wert von mindestens 0.55 wird vollständig in den System-Prompt eingefügt.

Das Tool read_skill bleibt verfügbar. Der Agent kann also weiterhin alles abrufen, was der Router übersehen hat. Das ist wichtig, denn der Router übersieht durchaus Dinge.

Mechanismus zwei: Tool-Payloads filtern

Nachdem ein Tool geantwortet hat und bevor seine Ausgabe den Agenten erreicht, wird jedes Blattfeld der Antwort auf seine Relevanz für die aktuelle Anfrage bewertet. Alles unter 0.35 wird entfernt.

Bemerkenswert an diesen Werten: Die Felder, die bei diesem Aufruf wegfallen, liegen bei 0.31 bis 0.34, die erhaltenen bei 0.35 bis 0.37. Der Grenzwert ist also tatsächlich eine Grenze, und einige Felder wechseln zwischen den Durchläufen die Seite. trial_end erzielte in einem Durchlauf 0.34, in einem anderen 0.37. Kein für die Aufgabe benötigtes Feld lag jemals in diesem Bereich.

Woher die Sicherheit tatsächlich kommt

Im dritten Schritt, beim Zustand, fällt die Entscheidung. Derselbe Schwellenwert ist mit einem unvollständigen Zustand gefährlich. Ein umfassenderer Zustand macht die Filterung zugleich sicherer und aggressiver.

Isoliert betrachtet, für das Feld, das bei der Mahnaufgabe entscheidend ist:

Die beiden mittleren Spalten zeigen die Werte für das Feld, von dem die Aufgabe tatsächlich abhängt. Die letzte Spalte gibt an, wie viele der 124 Felder den Schwellenwert von 0.35 überstehen.

Die Skills hinzuzufügen, ändert nichts. Der bisherige Verlauf hilft ein wenig. Entscheidend ist die Liste der noch möglichen Aktionen. Solange der Scorer nicht weiß, dass ein Aufruf von billing_set_account_state(account_id, …) ansteht, ist eine Konto-ID nur eine Zeichenfolge unter vielen.

Die allgemeine Form dieses Prinzips, die sich auch auf andere Setups übertragen lässt:

Ein Feld ist nicht an sich nützlich. Es ist nützlich im Hinblick darauf, was der Agent gleich damit tun wird. Diese Information steckt nicht in der Payload, sondern im Schema der weiterhin verfügbaren Tools.

Wo die Einsparungen entstehen und wo nicht

Die beiden Mechanismen erfassen völlig unterschiedliche Dinge. Für den eigenen Workload ist es wichtiger zu wissen, welcher davon greift, als den Durchschnitt zu kennen.

Die Unterschiede sind groß. Bei der Aufgabe, für die sechs Hilfeartikel eingehen und nur updated_at wichtig ist, entfernt die Filterung 84% der Payload und 63% der Eingabetokens. Bei der Incident-Aufgabe, bei der fast jedes Feld verwendet wird, sind es 5%. Derselbe Agent, derselbe Schwellenwert, ein Unterschied um den Faktor 17.

Kosten pro Aufgabe mit Opus 5, einfacher Agent im Vergleich zu beiden Mechanismen:

Ein Opus-5-Agent, der 10,000 Aufgaben pro Monat bearbeitet, kostet statt $419 nur noch $299. Davon entfallen $9 auf Jev.

Ob sich die Filterung lohnt, hängt vom Preis des Hauptmodells ab

Das ist das Ergebnis, das dein Vorgehen ändern sollte.

Das Filtern kostet bei jedem Tool-Aufruf Jev-Tokens. Diese Tokens haben einen festen Preis. Die eingesparten Tokens werden hingegen zum Preis deines Agentenmodells abgerechnet. Entscheidend ist also das Verhältnis, und das kann sich umkehren.

Die Tokenzahlen bleiben gleich. Nur der Preis des Agentenmodells ändert sich. Beim günstigen Modell entfallen 42% der Kosten auf Jev, und das Filtern kostet mehr, als es einspart. Bei Opus 5 sind es 3% der Kosten.

Berechnet man den Kipppunkt anhand der gemessenen Tokenzahlen und der üblichen Preisstruktur, liegt er bei $0.55 pro Million Eingabe-Tokens mit aktivem Prompt-Caching und bei $0.37 ohne. Darunter solltest du nicht filtern, darüber schon.

Skills vorzuladen lohnt sich immer, auch beim günstigsten Modell, denn es kostet fast nichts: etwa 1,500 Jev-Tokens pro Durchlauf, also $0.00006, und spart dafür einen Gesprächsschritt.

Ein weiterer Effekt ist wissenswert: Caching halbiert die Kosten ungefähr und verringert den relativen Nutzen des Filterns, weil das meiste, was beim Filtern entfernt wird, ohnehin günstige Cache-Lesezugriffe gewesen wären. Filtern lohnt sich für einen Einsatz ohne Caching mehr als für einen mit Caching.

Der Fehlermodus

Der Schwellenwert von 0.35 ist nur dank des umfangreichen Zustands sicher. Eine frühere Version ohne diesen Zustand führte zum schlimmsten denkbaren Fehler.

Der Filter entfernte account.id aus einem Stripe-Abonnement und bewertete es mit 0.18. Außerdem entfernte er metadata.account_id, die zweite Kopie. Der Agent nahm den einzigen verbliebenen Bezeichner und tat Folgendes:

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

Bericht: „Ich habe das zugehörige Konto gemäß der Richtlinie für Tag 10 auf schreibgeschützt gesetzt.“

Der richtige Bezeichner war acct_borealis_4c77. Der Agent führte die Aktion am falschen Objekt aus und meldete das selbstbewusst.

Für jeden Einsatz müssen kritische Pfade festgelegt und der Schwellenwert darauf abgestimmt werden. Beim Routing entschieden zwei Hundertstel beim Schwellenwert darüber, ob ein Gesprächsschritt eingespart wurde oder nicht. Beim Filtern war der Unterschied noch deutlich größer.

Was ich daraus mitnehme

Es lohnt sich, an der Effizienz von KI zu arbeiten. Viel Potenzial liegt darin, Modelle unterschiedlicher Größe und Art zu kombinieren. Interessant ist hier, dass sich ein Modell, das überhaupt keinen Text verfassen kann, als guter Beurteiler dafür erweist, was ein textgenerierendes Modell sehen darf.

Hier wurden zwei Ansatzpunkte getestet. Dasselbe Muster könnte an vielen weiteren Stellen greifen: bei der Auswahl der Dateien, die ein Agent öffnet, bei der Entscheidung, wann ein Gespräch komprimiert werden sollte, bei der Bewertung, ob ein abgerufenes Dokument seine Tokens wert ist, oder beim Prüfen eines Schreibvorgangs, bevor er ausgeführt wird. Nichts davon wurde gemessen. Ich würde nicht davon ausgehen, dass es funktioniert, bevor es getestet wurde.

Weiter unten findest du die vollständige Dokumentation: den Testaufbau, jede Aufgabe, jeden Schwellenwert, alle Tabellen und auch, was diese Untersuchung nicht zeigt.

Alle Details

Alles ab hier ist das vollständige Experiment. Es ist absichtlich lang. Wenn du nur das Ergebnis wolltest, hast du es bereits.

Der Versuchsaufbau

Der Agent

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

1. Sende einen POST-Request an den Chat-Completions-Endpunkt von OpenRouter, mit der Nachrichtenliste und den Tool-Schemas im OpenAI-Format für Funktionsaufrufe.
2. Enthält die Antwort tool_calls, führe jeden Aufruf lokal aus, füge das Ergebnis als Nachricht mit role: "tool" hinzu und starte die Schleife erneut.
3. Enthält die Antwort keine tool_calls, ist dieser Text die endgültige Antwort und die Schleife endet.

Zum Thema Reasoning: Es wurde nie ein reasoning-Parameter übergeben, das Modell lief also mit dem Standardwert des Anbieters. Ein späterer Kontrollaufruf gibt reasoning_tokens: 0 zurück. Es wurde somit kein separates Reasoning-Budget verbraucht, und keine der Tokenzahlen enthält verborgene Reasoning-Token. Bei einer Wiederholung mit höherem Reasoning-Aufwand wären die absoluten Werte anders.

Zwei Sicherheitsvorkehrungen, denn eine außer Kontrolle geratene Agentenschleife kostet Geld: maximal 8 Durchläufe pro Ausführung und höchstens 6 Tool-Aufrufe pro Durchlauf. Bei den 192 Ausführungen wurde keine der beiden Grenzen erreicht. Eine dritte Vorkehrung summiert die Kosten aller Aufrufe und bricht ab, sobald der festgelegte Grenzwert überschritten wird. Für die Kampagne lag er bei $2.60.

Die Welt

Ein fiktives B2B-SaaS-Unternehmen namens Northwind Analytics, für das der Agent als Betriebsassistent arbeitet.

17 Tools, deren Nutzdaten die tatsächliche Struktur von Stripe, Zendesk, HubSpot, Statuspage, PagerDuty, Slack, Linear und einem Help-Center-CMS nachbilden: gleiche Schlüsselnamen, gleiche Verschachtelung, gleicher Datenballast. Es handelt sich um lokale Funktionen, die Testdaten zurückgeben, daher verlässt nichts den Rechner. Schreibvorgänge werden zur Bewertung protokolliert und mit einer plausiblen Bestätigung quittiert.

11 Skills: Markdown-Dateien mit einer einzeiligen description im Frontmatter und einem Textkörper, der die konkreten Grenzwerte, 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. Mehrere davon sind für keine der Aufgaben relevant. Sie dienen dem Router als Ablenkung.

8 Aufgaben, ausgewählt entlang zweier unabhängiger Dimensionen: Länge, von einem einzelnen Tool-Aufruf bis zu sieben Durchläufen, und Dichte der Nutzdaten, von „jedes Feld ist wichtig“ bis zu „76 % der Bytes sind Text, den man verwerfen kann“.

Die Aufgaben im Wortlaut

Bewertung

Deterministisch. 59 Prüfungen über die acht Aufgaben hinweg, jede entweder ein Tool-Aufruf mit exakt vorgegebenen Argumenten, etwa stripe_create_refund(charge="ch_3QRk9X…", amount=14900, reason="duplicate"), oder eine Information, die nur in einem Skill-Dokument vorkommt: die SLA-Stufe von 25 %, die Regel für Tag 10, das Team PRIV und die Frist von 30 Tagen.

Es kommt nirgends ein LLM als Prüfer zum Einsatz. Öffnet eine Ausführung die Skills nicht, scheitert sie automatisch an der zweiten Art von Prüfung. Genau darum geht es: So lässt sich messen, „ob der Agent die Richtlinie tatsächlich vorliegen hatte“, statt darüber zu spekulieren.

Für jede Aufgabe sind außerdem kritische Nutzdatenpfade festgelegt, also die Felder, von denen die Antwort abhängt. Sie werden nie dazu verwendet, den Filter zu steuern. So wird ein übermotivierter Filter im Protokoll sichtbar, selbst wenn die Ausführung trotzdem erfolgreich ist.

Die Varianten

8 Aufgaben × 4 Varianten × 6 Wiederholungen = 192 Durchläufe. Die Wiederholungen unterschieden sich nur durch seed.

Kalibrierung

Beide Schwellenwerte wurden offline getestet, bevor Agent-Tokens verbraucht wurden.

0.55 für das Routing ist der höchste Wert, bei dem der vollständige Recall für die Aufgaben erhalten bleibt, auf die der Wert kalibriert wurde. Bei 0.60 erzielt slack-style-guide bei der Rückerstattungsaufgabe einen Wert von 0.58, und die eingesparte Runde geht verloren. Zwei Hundertstel entscheiden darüber, ob die Zahl der Runden um 15 % sinkt oder gar nicht.

0.35 für die Filterung ist nur dank des oben beschriebenen umfangreichen Zustands vertretbar. Der Kalibrierungslauf kostet etwa $0.004, da dabei Router und Scorer ausgeführt werden, nicht aber der Agent.

Eine allgemeingültige Erkenntnis: Jede Formulierung einer Frage muss eigens kalibriert werden. Ein Schwellenwert lässt sich nicht von einer Formulierung auf eine andere übertragen, selbst wenn beide dieselbe Frage stellen. Für eine aufgabenspezifische und eine aufgabenunabhängige Formulierung wurden Verteilungen mit völlig unterschiedlichen Trägern gemessen. Bei jeder Umformulierung neu kalibrieren.

Summen der Testkampagne

Gesamtübersicht nach Variante

Keine der Techniken hat die Qualität verschlechtert. In allen vier Varianten werden 99% der Prüfungen bestanden. Bei 96 gefilterten Aufrufen in Variante D wurde genau ein als kritisch gekennzeichneter Pfad verworfen, und der betreffende Durchlauf wurde trotzdem bestanden. Die Unterschiede bei den „fehlerfreien“ Durchläufen pro Lauf zwischen 92% und 96% liegen bei n = 48 im Bereich des Zufalls. Belastbare Effekte zeigen sich bei Runden und Tokens.

Durchschnittliche Tokens pro Durchlauf, aufgeschlüsselt nach tatsächlicher Abrechnung:

Variante D senkt die Zahl der neuen Eingabe-Tokens, der teuren Tokenart, um 49%.

Einsparung bei Eingabe-Tokens pro Technik, von geringster bis höchster

Der einzige negative Wert in der gesamten Matrix tritt bei A für die SLA-Aufgabe auf: Der Router lädt einen Skill zu viel, ohne eine Runde einzusparen. Der zusätzliche Skill wird in den System-Prompt aufgenommen und anschließend in jeder Runde erneut gesendet. Außerdem addieren sich die beiden Techniken nicht immer: Bei der SLA-Aufgabe und beim Postmortem spart D weniger Tokens als B allein, genau aus diesem Grund.

So hat der Router tatsächlich abgeschnitten

Mittlere Wahrscheinlichkeit pro Skill und Aufgabe. Als geladen gilt ein Skill ab 0.55.

Recall: 132 der 144 benötigten Skills wurden geladen, also 92 %. Ein systematischer Fehltreffer und ein systematischer falsch positiver Treffer, die beide klar benannt werden sollten.

Beim Postmortem wurde slack-style-guide in allen 12 Durchläufen übersehen: Der Wert lag mit 0.47 unter dem Schwellenwert. In der Aufgabe heißt es „dem Unternehmen sagen, wo es steht“, und der Router erkennt darin keine Formatierungsfrage. Der Agent hat den Skill selbst abgerufen, als er ihn brauchte.

Der falsch positive Treffer ist refund-policy bei der SLA-Aufgabe mit 0.84 und beim Postmortem mit 0.89. Eine SLA-Gutschrift sieht wie eine Rückerstattung aus. Genau diese Verwechslung soll refund-policy verhindern, denn das Dokument stellt klar, dass ein Dienstausfall keine Rückerstattung ist. Der Router liegt bei der Form falsch, beim Inhalt aber richtig, und dem Agenten ist dadurch kein Schaden entstanden.

Bei der Lookup-Aufgabe wird richtigerweise nichts geladen. Kein Skill ist dafür relevant, und der höchste Wert liegt bei 0.07.

So hat der Filter tatsächlich funktioniert

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

Bei den Lese-Tools liegt das größte Einsparpotenzial, und die Unterschiede sind enorm: von −89% bei einer Dokumentenliste bis zu −25% bei einem Vorfall, bei dem fast alles unverzichtbar ist.

Bei den Bestätigungen für Schreibvorgänge geht es in die falsche Richtung. billing_apply_credit gibt 147 Zeichen zurück, und der angehängte Marker _trimmed kostet mehr, als durch die entfernten Felder eingespart wird. Einen kleinen Payload zu filtern, bringt unterm Strich also Nachteile. Eine Implementierung für den Produktionseinsatz sollte alles unter ein paar hundert Zeichen ganz überspringen. Hier blieb es dabei, damit der Effekt in den Daten sichtbar ist.

Jede Aufgabe, jeder Arm

Die Preise zeigen die vollständigen Kosten eines Durchlaufs für Agent plus Jev und basieren auf der gemessenen Aufteilung in frische und zwischengespeicherte Daten. Die Spalten für Sonnet 5 und Opus 5 rechnen den gemessenen Traffic zu den jeweiligen Modellpreisen durch. Jevs Kosten sind in allen drei Spalten identisch.

T1-refund, mittel · gemischter Payload

T2-sla, lang · gemischter Payload

T3-dunning, kurz · gemischter Payload

T4-gdpr, mittel · gemischter Payload

T5-incident, kurz · dichter Payload

T6-stale-docs, kurz · sehr dünner Payload

T7-postmortem, sehr lang · gemischter Payload

T8-lookup, ein Aufruf · dünner Payload

So wurden die Preise berechnet

Einmal messen, dann neu berechnen. Die Tokenzahlen bilden die Grundlage; die Kosten für jedes Modell ergeben sich aus denselben Zahlen, multipliziert mit den jeweiligen Modellsätzen.

Die Abrechnungsformel wurde anhand der Daten rückerschlossen, nicht einfach angenommen. Über alle 192 Durchläufe hinweg entspricht der beobachtete Agentenpreis

fresh_input × $0.25/M  +  cached_input × $0.02/M  +  output × $1.20/M

einem medianen relativen Fehler von 0.04%. Daraus ergeben sich zwei Dinge. Prompt-Caching war die ganze Zeit automatisch aktiviert, ohne cache_control-Marker, und 80% der Eingabetoken waren Cache-Lesezugriffe. Außerdem wird jedes nicht gecachte Eingabetoken zum Schreibpreis abgerechnet, also zum 1.25-Fachen des nominalen Eingabepreises. In einer Schleife mit mehreren Durchläufen zahlt man daher praktisch nie den nominalen Satz von $0.20/M.

Ein früheres theoretisches Caching-Modell, bei dem die Lesezugriffe im Durchlauf t dem Präfix aus Durchlauf t−1 entsprechen, unterschätzte die tatsächlichen Cache-Lesezugriffe um 19%. Es wurde zugunsten der gemessenen Aufteilung pro Durchlauf verworfen.

Zum Vergleich: dieselben Durchläufe ganz ohne Caching:

Eine Annahme ist bewusst konservativ statt neutral. OpenAI cached automatisch und berechnet jedes nicht gecachte Eingabetoken zum Schreibpreis, genau das wurde gemessen. Caching bei Anthropic muss ausdrücklich aktiviert werden: Nur Inhalte innerhalb eines cache_control-Breakpoints werden zum Schreibpreis abgerechnet, der Rest zum regulären Eingabepreis. Werden also alle nicht gecachten Token zum Schreibpreis berechnet, fallen die Anthropic-Werte etwas zu hoch aus. Bei einer Neuberechnung mit dem regulären Eingabepreis für nicht gecachte Token sinkt der Opus-5-Mittelwert von $0.04191 → $0.02995 (−29%) auf $0.03823 → $0.02808 (−27%); kein Wert pro Aufgabe verschiebt sich um mehr als 3 Punkte.

Was dies nicht zeigt

• Ein Agentenmodell. Alles wird mit openai/gpt-5.6-luna bei standardmäßiger Denktiefe gemessen. Die Tokenzahlen sind das Ergebnis, die Preisspalten werden darauf aufbauend berechnet. Ein anderes Modell würde andere Tokenzahlen liefern, nicht nur andere Preise.
• n = 6 pro Zelle. Das reicht für die Anzahl der Durchläufe und Tokenzahlen, die nahezu deterministisch sind. Es reicht nicht aus, um eine Qualität von 92 % von 96 % zu unterscheiden.
• Test-Fixtures statt Live-APIs. Die Payload-Strukturen entsprechen den realen. Echte Endpunkte haben Paginierung, Teilausfälle und Ratenbegrenzungen, die dieser Testaufbau nicht abbildet.
• Dieselben Personen haben die Aufgaben und die Skills verfasst. Die Bewertung ist deterministisch, aber die Testumgebung stellt keine adversarialen Bedingungen dar.
• Jevs eigene Kalibrierung wurde nicht geprüft. Gemessen wurde, wie sich Jevs Bewertungen auf einen Agenten auswirken, nicht, ob sie statistisch gesehen gut kalibriert sind.
• Ein Agentenaufbau. Eine while-Schleife mit Funktionsaufrufen. Unteragenten, parallele Tool-Aufrufe und lang laufende Sitzungen verändern die Berechnung.

Quellen

• TypeSafe: Einführung der System-One-Modelle und von Jev
• TypeSafe: Konzepte von System One
• Jev 1.13 auf OpenRouter
• Mein früherer Artikel: Kleine Modelle sollten entscheiden, was große Modelle sehen
• Model Context Protocol: Spezifikation für Tools