Kann Jev die Kosten von KI-Agenten senken? Eine vollständige Rechnung vom Modell-Routing bis zur Ergebnisprüfung

Zusammenfassung

Ein einzelner Jev-Aufruf ist sehr günstig. Trotzdem wird eine Aufgabe nicht automatisch billiger, nur weil einem KI-Agenten ein kostengünstiges Entscheidungsmodell vorgeschaltet wird.

Entscheidend ist, ob Jev einen Teil der Anfragen an deterministischen Code oder ein günstigeres Modell weiterleiten, den an das Hauptmodell gesendeten Kontext verkleinern und durch Ergebnisprüfung unnötige Wiederholungen vermeiden kann. Gleichzeitig verursachen auch Fehlklassifikationen, Latenz, menschliche Prüfung und technischer Betrieb eigene Kosten.

Dieser Artikel untersucht drei häufige Architekturen — Modell-Routing, Kontextfilterung und Ergebnisprüfung — und liefert ein vollständiges Kostenmodell für die praktische Frage: Wann kann Jev die Gesamtkosten eines Agenten senken, und wann fügt es lediglich einen weiteren API-Aufruf hinzu?

---

Viele Kostenprobleme bei KI-Agenten wirken zunächst so, als sei das Hauptmodell schlicht zu teuer. In der Praxis liegt die tiefere Ursache häufig darin, dass der Workflow unterschiedliche Aufgabentypen nicht voneinander trennt.

Eine Anfrage wie „Prüfe den Status meiner Bestellung“ benötigt möglicherweise nur eine Datenbankabfrage. Eine Anfrage wie „Analysiere die Ursachen der Bestellanomalien der vergangenen sechs Monate“ kann dagegen ein starkes Modell erfordern, das mehrere Quellen zusammenführt. Andere Anfragen enthalten zu wenig Informationen; dann ist es sinnvoller, den Nutzer zunächst um eine Präzisierung zu bitten, statt überhaupt ein Modell aufzurufen.

Wenn jede Anfrage direkt an dasselbe leistungsstarke Modell gesendet wird, bleibt das System zwar einfach, bezahlt aber auch für viele Aufgaben den vollen Preis, die normaler Code oder ein kleineres Modell erledigen könnten.

Jev verfolgt einen anderen Ansatz.

Es ist nicht für Chats oder lange Textgenerierung gedacht. Entwickler übergeben einen state und stellen mehrere typisierte Fragen; Jev liefert strukturierte Entscheidungen und Wahrscheinlichkeiten wie Choice, Score oder Noul. Anschließend entscheidet die Geschäftslogik, ob ein Tool aufgerufen, ein günstigeres Modell verwendet, auf ein leistungsstärkeres Modell eskaliert oder der Fall an einen Menschen übergeben wird. TypeSafe bezeichnet Jev als erstes System-One-Modell: ein Modell, das speziell für schnelle, strukturierte Entscheidungen innerhalb von Software entwickelt wurde. (typesafe.ai)

Preislich wirkt eine solche Entscheidung beinahe vernachlässigbar.

Zum Start von Jev nannte TypeSafe einen Preis von 0,042 US-Dollar pro Million Input-Token, ohne Gebühren für Output-Token. Das Unternehmen gab außerdem eine typische End-to-End-Latenz von 70 bis 500 Millisekunden an, wies jedoch darauf hin, dass diese Werte aus bestimmten Regionen und Testbedingungen stammen und nicht ohne Weiteres für jede Deployment-Umgebung gelten. (typesafe.ai)

Das Problem lautet:

Eine günstige Entscheidung macht den gesamten Agenten-Workflow nicht automatisch günstiger.

Ob Jev tatsächlich spart, hängt davon ab, ob es die nachfolgenden Schritte verändert — nicht nur davon, wie billig der Jev-Aufruf selbst ist.

Die echte Rechnung eines KI-Agenten besteht aus mehr als Modellgebühren

Für eine einzelne Agentenaufgabe entstehen meist mindestens sechs Kostenarten:

Kostenkategorie	Was sie umfasst
Entscheidungskosten	Intent-Klassifikation, Modell-Routing, Risikoprüfung und die Entscheidung, ob ein Tool benötigt wird
Kontextkosten	Gesprächsverlauf, Suchergebnisse, Tool-Ausgaben, Logs und Dokumente
Generierungskosten	Input-, Output- und Reasoning-Token des Hauptmodells
Wiederholungskosten	Modell-Timeouts, Tool-Fehler, Formatfehler und erneute Generierung
Personalkosten	Prüfung, Korrektur, Ausnahmebehandlung und Freigabe riskanter Aktionen
Kosten von Fehlentscheidungen	Behebung nach falschem Routing, fehlenden Informationen oder der Ausführung einer falschen Aktion

Ein vollständigeres Kostenmodell pro Aufgabe sieht daher so aus:

Gesamtkosten
= Entscheidungskosten
+ Kosten der Kontextverarbeitung
+ Kosten nachgelagerter Modelle und Tools
+ Kosten für Wiederholungen und Fallbacks
+ Kosten menschlicher Prüfung
+ Behebungskosten durch Fehlentscheidungen

Der Jev-Aufruf ist normalerweise nur ein sehr kleiner Teil dieser Summe.

Die eigentliche Chance liegt darin, nachgelagerte Kosten zu reduzieren: einen Aufruf des teuren Modells zu vermeiden, irrelevanten Kontext nicht zu senden, eine fehlgeschlagene Aufgabe nicht erneut auszuführen oder Menschen nur die wirklich unsicheren Fälle prüfen zu lassen.

Die häufigsten Sparmuster lassen sich in drei Gruppen einteilen:

1. Vorab-Routing: zuerst entscheiden, dann auswählen, was aufgerufen wird.
2. Kontextfilterung: unnötige Informationen entfernen, bevor das Hauptmodell aufgerufen wird.
3. Nachgelagerte Verifikation: zuerst ein günstiges Modell arbeiten lassen und nur bei nicht bestandener Prüfung eskalieren.

---

Erste Sparmöglichkeit: Jev als Router vor das Hauptmodell setzen

Die direkteste Architektur lautet:

Nutzeranfrage
   ↓
Jev bewertet Intent, Komplexität und Risiko
   ↓
Deterministischer Code / günstiges Modell / starkes Modell / Mensch

Das offizielle Routing-Muster von TypeSafe folgt derselben Idee: Nicht jede Anfrage muss in dasselbe LLM gelangen. Einige können an deterministischen Code gehen, andere an ein spezialisiertes Modell; komplexe oder risikoreiche Anfragen können an ein teureres Modell oder an einen Menschen eskaliert werden. (docs.typesafe.ai)

Ein Support-Agent könnte zum Beispiel zunächst klären:

• Geht es lediglich um den Status einer Bestellung?
• Betrifft die Anfrage eine Rückerstattung oder einen Chargeback?
• Gehört sie zu Billing, technischem Support oder Vertrieb?
• Ist menschliches Eingreifen erforderlich?
• Wird wirklich ein Frontier-Reasoning-Modell benötigt?

Jev trifft nur diese Entscheidungen.

Datenbankabfrage, Rückerstattung, Antwortgenerierung und menschliche Ticketbearbeitung bleiben Aufgaben des umgebenden Systems.

Wie günstig ist eine Routing-Entscheidung?

In einem realen API-Test aus dem Quellenmaterial wurden zehn Support-Tickets in eine einzige Anfrage gepackt. Für jedes Ticket wurden Routing und die Notwendigkeit menschlicher Prüfung bewertet, insgesamt also 20 Fragen:

• Gesamter Input: 2.571 Token;
• Dauer des Aufrufs: rund 405 Millisekunden;
• Gesamtkosten zum öffentlichen Preis: etwa 0,000108 US-Dollar;
• Durchschnitt pro Ticket: etwa 0,0000108 US-Dollar;
• Bei gleichem Token-Profil hochgerechnet: etwa 10,8 US-Dollar pro Million Tickets.

Als dieselben zehn Tickets in zehn getrennten Aufrufen gesendet wurden, lag die Gesamtdauer bei rund 3.664 Millisekunden. Die wichtigsten Routing-Ergebnisse blieben gleich, einige Wahrscheinlichkeiten bei Grenzfällen verschoben sich jedoch deutlich. Das zeigt, dass Batching den Request-Overhead stark reduzieren kann. Es beweist aber weder die Routing-Genauigkeit für jede Branche noch, dass derselbe Schwellenwert für Hochrisiko-Gates geeignet ist.

Der Break-even-Punkt für Modell-Routing

Angenommen:

• C_high: Kosten eines Aufrufs des starken Modells;
• C_low: Kosten eines Aufrufs des günstigen Modells;
• C_jev: Kosten der Jev-Entscheidung;
• P_code: Anteil der Anfragen, die deterministischer Code abschließen kann;
• P_low: Anteil der Anfragen, die das günstige Modell abschließen kann;
• P_error: Anteil der Anfragen, die wegen falschen Routings nachbearbeitet werden müssen.

Wenn jede Anfrage direkt an das starke Modell geht, betragen die erwarteten Kosten:

C_direct = C_high

Mit Routing ergeben sich erwartete Kosten von:

C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repair

Routing spart daher nur dann Geld, wenn:

Vermiedene Kosten des starken Modells
>
Jev-Kosten + Behebungskosten durch Routing-Fehler

Da Jev selbst sehr günstig ist, bestimmen meist zwei Fragen die Wirtschaftlichkeit:

1. Wie viele Anfragen können das starke Modell tatsächlich umgehen?
2. Wie teuer sind die Folgen eines Fehlroutings?

Eine rein illustrative Rechnung

Die folgenden Preise dienen nur zur Veranschaulichung und entsprechen nicht den tatsächlichen Preisen bestimmter Modelle:

• Starkes Modell: 0,01 US-Dollar pro Aufruf;
• Günstiges Modell: 0,002 US-Dollar pro Aufruf;
• Jev: ungefähr 0,0000108 US-Dollar pro Aufruf;
• Gesamtvolumen: 100.000 Anfragen.

Angenommen, nach dem Routing:

• werden 20 % von deterministischem Code erledigt;
• gehen 50 % an das günstige Modell;
• gehen 30 % an das starke Modell;
• benötigen weitere 5 % wegen Fehlern oder Ausfällen einen zusätzlichen Aufruf des starken Modells.

Dann ergibt sich:

Position	Kosten
Ohne Routing: alle Anfragen nutzen das starke Modell	1.000 US-Dollar
100.000 Jev-Entscheidungen	1,08 US-Dollar
50.000 Aufrufe des günstigen Modells	100 US-Dollar
30.000 Aufrufe des starken Modells	300 US-Dollar
5.000 Behebungsaufrufe	50 US-Dollar
Gesamtkosten nach Routing	451,08 US-Dollar

Unter diesen Annahmen sinken die Gesamtkosten um rund 55 %.

Wenn jedoch nur 10 % der Anfragen an das günstige Modell gehen können, 90 % dennoch das starke Modell erreichen und zusätzlich 5 % nachbearbeitet werden müssen, steigen die Gesamtkosten auf etwa 971,08 US-Dollar.

Die Einsparung beträgt damit rund 2,9 %.

Berücksichtigt man zusätzlich Entwicklung, Monitoring, Schwellenwert-Kalibrierung und zusätzliche Latenz, kann sich der Aufbau dieser Routing-Schicht nicht mehr lohnen.

Daher sollte zuerst nicht der Stückpreis von Jev gemessen werden, sondern:

Welcher Anteil Ihres realen Traffics benötigt tatsächlich kein starkes Modell?

---

Zweite Sparmöglichkeit: den an das Hauptmodell gesendeten Kontext verkleinern

Kontext ist eine weitere große Kostenquelle für Agenten.

Ein länger laufender Agent kann Folgendes ansammeln:

• Gesprächsverlauf;
• mehrere Runden von Tool-Ausgaben;
• Bash- oder Build-Logs;
• Inhalte von Webseiten;
• durch Suche abgerufene Textpassagen;
• inzwischen veraltete Pläne und Zwischenergebnisse.

Viele Systeme senden all diese Informationen immer wieder an das Hauptmodell. Selbst wenn die aktuelle Aufgabe nur einen kleinen Teil davon benötigt, werden sämtliche Input-Token berechnet.

Jev kann vor das Hauptmodell gesetzt werden, um zu entscheiden:

• welche Suchergebnisse für die aktuelle Frage relevant sind;
• welche Tool-Ausgaben später noch benötigt werden könnten;
• welche früheren Nachrichten Einschränkungen oder unerledigte Punkte enthalten;
• welche Passagen möglicherweise Prompt Injection enthalten;
• welche Informationen gelöscht oder nur noch als Zusammenfassung aufbewahrt werden können.

Die offizielle Use-Case-Map von TypeSafe nennt ebenfalls Kontextauswahl, semantisches Retrieval, RAG-Passagenfilterung und Kontextmanagement in Agent-Harnesses. (docs.typesafe.ai)

Der finanzielle Effekt lässt sich näherungsweise so ausdrücken:

Nettonutzen der Kontextfilterung
= entfernte Token × Input-Preis des Hauptmodells
- Kosten der Jev-Filterung
- Kosten für erneutes Retrieval und Wiederholungen durch fehlende Informationen

Die ersten beiden Terme sind einfach zu berechnen. Der dritte wird am häufigsten übersehen.

Dutzende irrelevante Log-Zeilen zu entfernen, ist meist ein klarer Gewinn. Wird jedoch eine wichtige Nutzeranforderung aus einer früheren Nachricht entfernt, kann das Hauptmodell ein vollständig falsches Ergebnis liefern. Dann sind erneutes Retrieval, ein weiterer Modellaufruf oder manuelle Korrektur nötig.

Eine einzige Wiederholung kann die Ersparnis vieler erfolgreicher Filterungen aufzehren.

Jev eignet sich daher besser, um zu entscheiden, welche Inhalte wahrscheinlich relevant sind, als als alleiniger dauerhafter Speicherverwalter. Ein Produktionssystem sollte mindestens:

• Systemanweisungen, harte Nutzeranforderungen und Sicherheitsregeln immer behalten;
• einen Index oder das Original entfernter Inhalte aufbewahren;
• dem Agenten ermöglichen, ausgelassene Inhalte bei Informationsmangel erneut abzurufen;
• den Erfolg anhand nachgelagerter Aufgabenerfüllung statt nur anhand der Kompressionsrate bewerten.

Für Kontextkompression ist daher folgende Größe aussagekräftiger:

Gesamte Token nach Kompression
+ Token für erneutes Retrieval
+ Wiederholungs-Token aufgrund von Auslassungen

und nicht nur „wie viele Token in diesem Schritt entfernt wurden“.

---

Dritte Sparmöglichkeit: zuerst ein günstiges Modell einsetzen und das Ergebnis mit Jev prüfen

In einer weiteren häufigen Architektur entscheidet Jev nicht, welches Modell aufgerufen wird. Stattdessen prüft es das Ergebnis eines anderen Modells.

Der Ablauf sieht so aus:

Das günstige Modell erzeugt ein Ergebnis
       ↓
Jev prüft faktische Belege, extrahierte Felder, Policy-Risiko oder Vollständigkeit
       ↓
Bestanden: Ergebnis verwenden
Nicht bestanden: wiederholen, zum starken Modell eskalieren oder an einen Menschen geben

TypeSafe bezeichnet diese Muster als Universal Verification. Die offiziellen Materialien umfassen RAG-Zitatprüfung, Validierung von Tool-Aufrufen, Bewertung der Ergebnisqualität und Kaskaden für strukturierte Datenextraktion. Das offizielle SDE-Cascade-Beispiel nutzt „Extraktion durch ein günstiges Modell → feldweise Prüfung durch Jev → Eskalation an ein Reasoning-Modell nur bei einem Warnsignal“. Dabei handelt es sich um Ergebnisse aus einem Hersteller-Cookbook. Sie sind kein Beleg dafür, dass jede Extraktionsaufgabe dieselbe Kostensenkung erreicht. (docs.typesafe.ai)

Die erwarteten Kosten dieser Kaskade sind ungefähr:

C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failure

Die wichtigste Variable ist P_escalate: der Anteil der Ergebnisse des günstigen Modells, die dennoch an das starke Modell weitergereicht werden müssen.

Ohne Fehlerkosten ist die Kaskade günstiger als der direkte Einsatz des starken Modells für alle Anfragen, wenn:

P_escalate
<
1 - (C_low + C_jev) / C_high

Verwenden wir dieselben hypothetischen Preise:

• Starkes Modell: 0,01 US-Dollar;
• Günstiges Modell: 0,002 US-Dollar;
• Jev: ungefähr 0,0000108 US-Dollar.

Damit liegt die Break-even-Eskalationsrate bei etwa 80 %. Solange also weniger als rund 80 % der Anfragen letztlich eskaliert werden, kann die nominelle Modellrechnung unter der Basisvariante „starkes Modell für jede Anfrage“ bleiben.

Das ist jedoch nur der Preis-Break-even, nicht der Qualitäts-Break-even.

„Nahe an der Qualität des starken Modells“ und „dieselbe Qualität wie das starke Modell“ sind unterschiedliche Kostenziele

Eine vorregistrierte unabhängige Evaluation testete eine Jev-zu-starkem-Modell-Kaskade auf einer CLINC150-Stichprobe:

• Wenn die Endgenauigkeit einen Prozentpunkt unter der des starken Modells liegen durfte, musste Jev etwa 22 % der Anfragen eskalieren;
• Wenn exakt dieselbe Genauigkeit wie beim starken Modell gefordert wurde, musste die Kaskade jede Anfrage eskalieren und degenerierte damit praktisch zu „immer das starke Modell aufrufen“.

Die Forschenden betonten deshalb, das Ergebnis müsse als „für weniger Geld nahe an die Qualität des starken Modells kommen“ verstanden werden und nicht als „identische Qualität mit weniger Aufrufen“. Das Experiment umfasste nur 200 Beispiele, einen Datensatz und einen Servicepfad und lässt sich daher nicht direkt auf andere Agenten übertragen. Es zeigt jedoch ein wichtiges wirtschaftliches Muster: Schon eine kleine Erhöhung des Qualitätsziels kann die Eskalationsrate sprunghaft steigen lassen. (github.com)

Eine Kaskadenbewertung darf daher nicht nur berichten:

• wie viele Aufrufe des starken Modells vermieden wurden;
• welcher Traffic-Anteil automatisch verarbeitet wurde.

Sie muss ebenfalls ausweisen:

• die Genauigkeit des automatisch verarbeiteten Anteils;
• die endgültige End-to-End-Erfolgsrate;
• den Qualitätsverlust gegenüber einer vollständigen Verarbeitung durch das starke Modell;
• welche Fehler sich in nachgelagerten Schritten verstärken.

---

Mehrere Fragen in einem Aufruf sind häufig wichtiger als das Bündeln der Anfragen selbst

Jev unterstützt mehrere Fragen zum selben state und gibt die Antworten parallel zurück. Die offizielle Dokumentation empfiehlt, komplexe Entscheidungen in atomare Fragen zu zerlegen und die Ergebnisse im Code zusammenzuführen, statt mehrere Urteile in einer vagen Frage zu verstecken. (docs.typesafe.ai)

Statt beispielsweise zu fragen:

Wie soll dieses Support-Ticket bearbeitet werden?

lässt sich die Aufgabe zerlegen in:

• In welche Fachwarteschlange gehört es?
• Verlangt es ausdrücklich eine Rückerstattung?
• Erwähnt es Chargeback, rechtliche Schritte oder eine Aufsichtsbehörde?
• In welche Dringlichkeitsstufe fällt es?
• Ist ein Mensch erforderlich?
• Lohnt sich der Aufruf eines stärkeren Modells?

In den Messungen des Quellenmaterials blieb die Latenz für denselben state nach dem Aufwärmen ungefähr im gleichen Bereich von 350 bis 400 Millisekunden, als die Zahl der Fragen von einer auf acht und dann auf 32 erhöht wurde. Die Input-Token stiegen mit der Fragenzahl, die Netzwerk-Roundtrips jedoch nicht linear.

Ein sinnvolles Muster lautet daher:

Alle atomaren Fragen, die im aktuellen Schritt wirklich benötigt werden, in einem Request stellen, statt für jede Entscheidung einen separaten API-Aufruf zu senden.

Batching bedeutet jedoch nicht, alle Nutzer, Dokumente und Aufgaben in einen riesigen state zu packen. Der Ticket-Test zeigte ebenfalls, dass Array-Batching die Hauptklassifikationen beibehielt, aber einige Wahrscheinlichkeiten in Grenzfällen verschob.

Die Batching-Strategie muss weiterhin anhand der tatsächlichen Datenverteilung der Anwendung validiert werden.

---

Vier versteckte Kosten, die leicht übersehen werden

1. confidence ist nicht Genauigkeit

Typisierte Ausgabe kann garantieren, dass eine Antwort zur Schnittstelle passt. Sie kann nicht garantieren, dass die geschäftliche Entscheidung richtig ist.

Eine unabhängige Evaluation stellte fest, dass Jev bei 102 von 200 Beispielen einen confidence-Wert von exakt 1.0 zurückgab, obwohl sechs dieser Entscheidungen falsch waren. Außerdem zeigte sich nicht, dass die Jev-Confidence die eigenen Fehler besser sortiert als die selbstberichtete Confidence eines kleinen LLM. (github.com)

Produktionslogik sollte daher nicht auf Folgendes reduziert werden:

if (confidence === 1) {
  executeDestructiveAction();
}

Sicherer ist es:

• bei konkreten Entscheidungsregeln die probabilities der einzelnen Optionen zu bevorzugen;
• Schwellenwerte auf einem anwendungsspezifischen gelabelten Datensatz festzulegen;
• unterschiedliche Schwellenwerte für unterschiedliche Risikostufen zu verwenden;
• für Zahlungen, Löschungen, Sperren und ähnliche Aktionen menschliche Bestätigung beizubehalten;
• Modellversion, Wahrscheinlichkeiten und tatsächliche Ergebnisse zu protokollieren, um Drift zu überwachen.

Eine weitere vorregistrierte Kalibrierungsstudie lieferte ebenfalls gemischte Ergebnisse: Der ECE lag auf CLINC150 bei 0,0204 und auf Banking77 bei 0,0936, wobei beim zweiten Datensatz systematische Überkonfidenz auftrat. Das zeigt, dass Kalibrierung von Aufgabe und Korpus abhängt; ein für einen Datensatz eingestellter Schwellenwert sollte nicht direkt auf ein anderes Geschäftsfeld übertragen werden. (systemonemodels.org)

2. Fehlrouting ist nicht kostenlos

Wenn ein Router eine einfache Anfrage an das starke Modell schickt, geht möglicherweise nur eine Sparchance verloren. Wenn er eine komplexe Anfrage fälschlich an deterministischen Code sendet, kann das zu einer falschen Antwort, doppelter Arbeit oder Nutzerabwanderung führen.

Bei Hochrisiko-Aufgaben kann eine einzelne Fehlentscheidung mehr kosten als alle beteiligten Modellaufrufe zusammen.

Daher sollten vier Fehlerarten getrennt erfasst werden:

• Falsche Eskalation: Eine günstig behandelbare Anfrage wird an das starke Modell gesendet.
• Falsches Downgrade: Eine Anfrage, die das starke Modell benötigt, landet auf einem günstigen Pfad.
• Falsches Durchlassen: Der Prüfer erkennt ein fehlerhaftes Ergebnis nicht.
• Falsches Blockieren: Ein korrektes Ergebnis wird unnötig wiederholt oder zur menschlichen Prüfung geschickt.

Eine einzige aggregierte Genauigkeitszahl bildet die Kosten dieser vier Fehlerarten nicht ab.

3. Latenz und Ausfälle sind ebenfalls Kosten

Im Quellenmaterial lagen aufgewärmte serielle Aufrufe meist bei etwa 340 bis 450 Millisekunden. In einem Test mit 24 gleichzeitigen Requests stieg die mediane Latenz auf ungefähr 1,2 Sekunden, und drei Transportfehler traten auf. Das war ein kleiner Test in einer bestimmten Umgebung und beschreibt nicht die allgemeine Verfügbarkeit des offiziellen Dienstes. Er reicht jedoch aus, um zu zeigen, dass eine Produktionsarchitektur die Entscheidungsschicht nicht als unfehlbare lokale Funktion behandeln darf.

Mindestens sollte das System vorab festlegen:

• ob ein Timeout zu fail-open, fail-closed oder menschlicher Eskalation führt;
• ob und wie oft wiederholt wird;
• ob bei Jev-Ausfall direkt das Hauptmodell aufgerufen wird;
• ob ein Ausfall des Routing-Dienstes den gesamten Agenten blockieren darf;
• ob p95- und p99-Latenzen noch zum Interaktionsbudget des Produkts passen.

Eine vorregistrierte Drittstudie beobachtete eine mediane Jev-Aufrufzeit von etwa 0,42 bis 0,44 Sekunden, wies aber ausdrücklich darauf hin, dass dies einen bestimmten Client, Gateway, Standort und Lastzustand widerspiegelt — nicht die reine Inferenzgeschwindigkeit des Modells. (github.com)

4. Wenn gelabelte Daten bereits vorhanden sind, ist Jev möglicherweise nicht die günstigste Option

Ein wichtiger Vorteil von Jev ist der Kaltstart: Ohne gelabelte Daten kann es Zero-Shot-Entscheidungen anhand natürlichsprachlicher Beschreibungen treffen.

Hat ein stabiler Workflow jedoch bereits viele menschlich gelabelte Beispiele gesammelt, kann ein klassisches kleines Modell attraktiver sein.

In einer vorregistrierten Banking77-Evaluation erzielte ein eingefrorenes bge-small-Embedding-Modell mit logistischer Regression, trainiert auf 10.003 Beispielen, eine Genauigkeit von 0,933; Jev erreichte 0,832. Der Encoder lief auf der Testhardware in ungefähr 9 Millisekunden und verursachte keine API-Gebühr pro Anfrage. Die Forschenden betonten zugleich, dass die Informationsbedingungen unterschiedlich waren: Der Encoder hatte einen großen gelabelten Datensatz derselben Verteilung gesehen, Jev wurde Zero-Shot bewertet. Es handelte sich daher nicht um einen Fähigkeitsvergleich unter identischen Bedingungen, sondern um einen Vergleich realistischer Deployment-Alternativen. (github.com)

Ein praktischer Entwicklungspfad könnte so aussehen:

Phase	Sinnvolle Option zur Prüfung
Keine gelabelten Daten, Regeln ändern sich häufig	Zero-Shot-Entscheidungsmodell wie Jev
Ein kleiner gelabelter Datensatz ist entstanden	Jev + Schwellenwert-Kalibrierung + menschliche Prüfung
Labels sind stabil und ein großer Datensatz liegt vor	Lokaler Encoder, Klassifikator oder feinabgestimmtes Modell
Long-Tail-Aufgaben ändern sich weiterhin	Jev als Fallback beibehalten

Jev kann besonders als Kaltstart-Beschleuniger und Entscheidungsschicht für den Long Tail nützlich sein, ohne zwangsläufig die dauerhafte Endlösung für jede stabile Klassifikationsaufgabe zu sein.

---

So berechnen Sie die Wirtschaftlichkeit vor dem Start

Nehmen Sie historische Aufgaben aus der realen Anwendung und vergleichen Sie offline drei Pfade:

A. Jede Aufgabe an das starke Modell senden
B. Jev-Routing → Code / günstiges Modell / starkes Modell
C. Günstiges Modell → Jev-Prüfung → bei Bedarf Eskalation an das starke Modell

Mindestens sollten folgende Kennzahlen erfasst werden:

Kennzahl	Welche Frage sie beantwortet
Durchschnittliche Gesamtkosten	Was kostete jede erfolgreich abgeschlossene Aufgabe tatsächlich?
Aufrufrate des starken Modells	Wie viele teure Aufrufe hat Jev wirklich verhindert?
Abdeckung automatischer Bearbeitung	Wie viele Aufgaben benötigten weder Menschen noch das starke Modell?
Genauigkeit automatisch bearbeiteter Aufgaben	Wie viele automatisch bearbeitete Aufgaben waren tatsächlich korrekt?
Eskalationsrate	Wie viele Kaskadenaufgaben landeten letztlich dennoch beim starken Modell?
Wiederholungsrate	Wie viele zusätzliche Aufrufe entstanden durch Routing- oder Prüfungsfehler?
Menschliche Prüfquote	Wurde menschliche Arbeit reduziert oder nur an eine andere Stelle verschoben?
p95-Latenz	Welche Tail-Latenz erlebten Nutzer tatsächlich?
End-to-End-Erfolgsrate	Sank die finale Aufgabenqualität unter den Ausgangswert?

Die aussagekräftigste Kennzahl ist nicht „Jev-Entscheidungsgenauigkeit“, sondern:

Kosten pro erfolgreich abgeschlossener Aufgabe

Selbst eine extrem günstige Entscheidungs-API kann die Wirtschaftlichkeit des Agenten verschlechtern, wenn sie mehr Wiederholungen, menschliche Prüfung oder falsche Ausführungen verursacht.

---

Wann Jev zuerst getestet werden sollte

Je mehr der folgenden Bedingungen erfüllt sind, desto wahrscheinlicher erzeugt Jev praktischen Nutzen:

• Das Anfragevolumen ist hoch und Entscheidungen fallen häufig an.
• Die Aufgabengrenzen sind klar und lassen sich in einstufige semantische Fragen zerlegen.
• Viele Anfragen können von deterministischem Code oder einem günstigen Modell bearbeitet werden.
• Es gibt noch nicht genügend gelabelte Daten für einen dedizierten Klassifikator.
• Der Aufruf des Hauptmodells ist deutlich teurer als der Entscheidungsaufruf.
• Fehler lassen sich durch Eskalation, Wiederholung oder menschliche Prüfung begrenzen.
• Das System kann Wahrscheinlichkeiten, Schwellenwerte und Endergebnisse protokollieren.
• Entscheidungskriterien müssen schnell ergänzt oder geändert werden.

Umgekehrt sollte Jev nicht die erste Maßnahme sein, wenn:

• fast jede Anfrage am Ende ein starkes Modell benötigt;
• das Verkehrsvolumen gering ist und API-Einsparungen die technische Komplexität nicht rechtfertigen;
• die Aufgabe mehrstufiges Reasoning, Arithmetik, Datumsvergleiche oder lange Textgenerierung verlangt;
• eine Fehlentscheidung direkt eine irreversible Aktion auslösen kann;
• bereits ein großer, stabiler gelabelter Datensatz für ein lokales Kleinmodell existiert;
• keine zuverlässigen Fallback- und menschlichen Prüfpfade aufgebaut werden können;
• Schwellenwerte aus einer offiziellen Demo unverändert in Produktion übernommen werden sollen.

---

Fazit: Jev spart nicht an der Entscheidung, sondern an der Arbeit danach

Ein Jev-Aufruf ist tatsächlich günstig. Das allein entscheidet jedoch nicht darüber, ob die Kosten eines KI-Agenten sinken.

Der eigentliche Wert liegt darin, einen Workflow aufzuteilen, der sonst alles an ein einziges starkes Modell senden würde:

• Einfache Anfragen gehen an deterministischen Code.
• Routinemäßige Anfragen gehen an ein günstiges Modell.
• Komplexe Anfragen gehen an das starke Modell.
• Unsichere Anfragen gehen an einen Menschen.
• Redundanter Kontext wird nicht gesendet.
• Fehlerhafte Ergebnisse werden gestoppt, bevor sie den Nutzer erreichen.

Wird Jev vor das Hauptmodell gesetzt, aber jede Anfrage läuft trotzdem weiter zu diesem Modell, wurde lediglich ein zusätzlicher API-Aufruf eingefügt.

Wenn Jev zuverlässig teure Aufrufe, Kontextmenge oder Nacharbeit reduziert, wird es zu einem echten Kostenhebel.

Die richtige Frage lautet daher nicht:

Wie günstig ist ein Jev-Aufruf?

Sondern:

Welche teure Arbeit musste das System nach dieser Entscheidung nicht mehr erledigen?

Das ist die vollständige Rechnung, die ein KI-Agent aufstellen sollte.