Jev beseitigt die Fehler, die man sieht

„Modelle sind im Chat seit Jahren übermenschlich, wo bleibt also die ganze Automatisierung?“ Mit diesem Satz eröffnet Diogo Almeida den Launch-Post von TypeSafe AI, dem Labor in San Francisco, das er mitgegründet hat, nachdem er bei OpenAI die Methoden hinter ChatGPT mitentwickelt hatte. Seine Antwort, am 15. September nach zwei Jahren im Stealth-Modus veröffentlicht und ausgestattet mit 40 Millionen Dollar Seed-Finanzierung unter Führung von DCVC, ist ein Modell, das keinen Satz schreiben kann.

Zustand rein, typisierte Antworten raus

Jev nimmt Text entgegen und gibt keinen Text zurück. Sie schicken ihm einen Block Zustand (einen String, ein JSON-Objekt, einen Agent-Trace) und eine Reihe typisierter Fragen. Zurück kommen typisierte Antworten mit Wahrscheinlichkeiten, alle in einem einzigen parallelen Durchlauf, laut TypeSafe in 70 bis 500 Millisekunden. Der Preis liegt bei 0,042 Dollar pro Million Input-Tokens, der Output ist gratis, weil es kaum welchen gibt.

Es gibt drei Fragetypen. Ein Choice wählt eine Option aus einer definierten Menge, ein Score bewertet den Input anhand beschriebener Stufen, und ein Noul liefert die Wahrscheinlichkeit, dass die Antwort auf eine Ja/Nein-Frage Ja lautet. Das ist die gesamte Schnittstelle. TypeSafe nennt die Kategorie System One, nach Kahneman, und positioniert sie dort, wo handgeschriebene Regeln zu leicht brechen: etwa beim Routing eines Tickets oder bei der Entscheidung, welchen Zweig ein Workflow nimmt.

Die Demo, die Schlagzeilen gemacht hat, ist Doom. Jev spielt anhand einer strukturierten Beschreibung des Spielzustands mit zehn Abfragen pro Sekunde, für rund 7 Dollar pro Stunde, und TypeSafe räumt ein, dass ein konventioneller Bot besser spielen würde. Ich nehme eines daraus mit: Ein Modell dieser Klasse kann jetzt in einer Game Loop sitzen.

Jedes Modell schneidet in einem Workflow besser ab

Meiner Meinung nach versteckt der Launch-Post sein bestes Ergebnis. Es steht auf der Evals-Seite und gilt für jedes Modell im Diagramm. TypeSafe hat vier Business-Aufgaben genommen (Triage von Sicherheitsalarmen, Review von Agent-Traces, Rechnungsverarbeitung, Kundenservice) und jedes Modell auf zwei Arten laufen lassen. Im ersten Fall bekommt das Modell die gesamte Richtlinie als Prompt und überlegt sich selbst den Weg zu einer Aktion. Im zweiten ist die Richtlinie in einen Workflow zerlegt: Enge, typisierte Fragen gehen ans Modell, den Rest erledigt Code. Über die vier Aufgaben gemittelt ist jedes Modell im Workflow genauer, billiger und schneller. Der Zugewinn reicht von etwa fünf Punkten am unteren Ende bis zu über 35 beim kleinsten Modell, das auf 18 Prozent einbricht, wenn es die Richtlinie als Fließtext bekommt. Bei einzelnen Aufgaben kehrt sich die Reihenfolge der Genauigkeit zweimal um, beide Male bei einem DeepSeek-Modell, und in drei Fällen ist der Workflow langsamer als der Prompt.

Das ist ein Ergebnis aus dem Harness Engineering, veröffentlicht von einem Modellanbieter. Die Genauigkeit entsteht dadurch, dass der Kontrollfluss aus dem Modell in den Code wandert, und sie zeigt sich bei den Modellen jedes Anbieters, auch bei denen, die TypeSafe verdrängen will. So gelesen folgt Jev aus dem Harness. Der Code sollte die Arithmetik und die Datumsvergleiche übernehmen (TypeSafes eigene Liste bekannter Fehlermuster rät, beides dort zu lassen), dazu die Verzweigungen. Sobald er das tut, bleibt dem Modell nur noch, geschlossene Fragen über einen Zustand zu beantworten, der ihm nicht gehört. Ein Modell in dieser Position braucht keine Strings. Es braucht auch kein Gedächtnis, weil das Programm den gesamten Zustand zwischen den Aufrufen hält. Die Generierung, also genau das, was ein LLM langsam und teuer macht, hat an dieser Stelle nichts geleistet, und TypeSafe hat sie gestrichen.

Ein Browser-Agent, bei dem der Harness der langsame Teil ist

Innerhalb von zwei Tagen nach dem Launch veröffentlichte Gregor Zunic von Browser Use einen kleinen Open-Source-Browser-Agenten, der genau so gebaut ist. Bei jedem Schritt liest der Harness die Seite in eine nummerierte Tabelle der sichtbaren Bedienelemente ein. Jev bekommt diese Tabelle und beantwortet mehrere Fragen in einem Request: welche Operation ausgeführt werden soll (click, type, select, scroll, wait, done, blocked) und welches Element für jede infrage kommende Operation das Ziel ist. Die Zielfragen sind spekulativ, der Harness verwendet nur jene, die zur gewählten Operation passt. Wenn die Operation Tippen ist, schreibt ein kleines LLM den String.

Generierung steckt also weiterhin im System, an den zwei Stellen, an denen die Aufgabe sie brauchte. Im aufgezeichneten Lauf auf Google Flights gingen 17 Requests an Jev und nur zwei an das Textmodell, für die beiden Städtenamen. Der Lauf fand Einwegflüge von Zürich nach London in 7,07 Sekunden, gemessen von der ersten Vorhersage bis zum akzeptierten Abschluss. Das Warten auf Googles Ergebnisse liegt innerhalb dieses Zeitfensters, das erste Laden der Seite außerhalb. Jevs Median-Latenz lag bei 178 Millisekunden. Liefen die Requests nacheinander, entfielen damit rund drei der sieben Sekunden auf das Modell. Zunics Post beziffert die Kosten mit 0,0039 Dollar. Das passt zu den 90.558 Input-Tokens im Log zu TypeSafes Listenpreis, allerdings weisen die Performance-Notizen darauf hin, dass die API Token-Zahlen und keinen abgerechneten Betrag zurückgibt und dass Browserkosten nicht enthalten sind.

Dieselben Notizen stützen das Harness-Argument mit einer Messung. Browser Use ließ die Aufgabe gegen eine eingefrorene frühere Version der eigenen Loop laufen, mit identischen Modellen und Einstellungen in beiden Armen. Die Median-Zeit sank von 9,45 auf 7,09 Sekunden, die Median-Zahl der Browser-Protokollaufrufe von 1.092 auf 101. All das kam von Änderungen am Harness. Die neue Loop liest das DOM in einem einzigen Browseraufruf, wo die alte wiederholt den Accessibility Tree ausgelesen hat, und sie wirft nicht mehr jedes Mal eine Entscheidung weg, wenn eine Animation die Seite berührt. Sobald das Modell in 178 Millisekunden antwortet, ist wieder der Harness der langsame Teil. Die Belege sind dünn, und die Autoren sagen das auch: drei gematchte Paare, eine Aufgabe, ein Chrome-Profil, ein Vorzeichentest mit p = 0,25 und ihre eigene Aussage, dass das kein breiter Benchmark ist.

Compaction, die nur löschen kann

Ein zweites Projekt aus derselben Woche setzt Jev an eine andere Stelle. fast-jev-compaction ersetzt den Schritt, den Agenten ausführen, wenn ihr Kontext voll wird. Üblicherweise lässt man ein LLM alte Turns zusammenfassen, und eine Zusammenfassung kann genau den Dateipfad oder die Einschränkung verlieren, die sich später als wichtig herausstellt. Diese Library schreibt nie etwas um. Sie zeigt Jev die gesamte Konversation, passend gekürzt und mit auf kurze Notizen reduzierten Tool-Ergebnissen, und stellt zu jedem alten Tool-Aufruf zwei Ja/Nein-Fragen: Ist der Aufruf noch relevant, und muss sein Ergebnis wörtlich erhalten bleiben? Was unter einer Wahrscheinlichkeit von 0,5 liegt, fliegt raus: Entweder wird das Ergebnis auf einen kurzen Anfang gekürzt, oder Aufruf und Ergebnis verschwinden gemeinsam. Text von Nutzer und Assistent bleibt Wort für Wort erhalten, die erste Nachricht und die neuesten paar sind fixiert, und wenn Jev scheitert oder zu wenig entfernt, fällt das Claude-Code-Plugin auf die eingebaute Zusammenfassung zurück.

Hier macht gerade Jevs Unfähigkeit zu schreiben das Design sicher. Ein Compactor, der nur löschen kann, kann keinen erfundenen Satz ins Gedächtnis des Agenten schmuggeln. Das ist also eine Stelle, an der die Behauptung „kann nicht halluzinieren“ tatsächlich Biss hat. Außerdem hat das Projekt eine Stelle gewählt, an der ein falscher gültiger Wert billig ist. Wird ein Tool-Ergebnis irrtümlich gelöscht, führt der Agent das Tool eben noch einmal aus. Das README sagt genau das und fügt hinzu, dass eine Wahrscheinlichkeit kein Beweis dafür ist, dass sich ein Ergebnis gefahrlos löschen lässt. Messungen gibt es keine, vorerst ist das also ein gutes Design, das noch auf eine wartet.

Ein Judge, der weiterhin einen zweiten Leser braucht

Ein dritter früher Nutzer hat Jev als Judge eingesetzt. Good Start Labs, das frühen Zugang hatte, hat 6.003 Rubrik-Checks zu 1.203 Antworten aus der Finanzrecherche mit Jev und fünf LLM-Judges unter denselben Anweisungen neu bewertet. Jev stimmte mit dem Urteil jedes einzelnen LLM in 86 bis 92 Prozent der Fälle überein. Die LLMs stimmten untereinander zu 88 bis 95 Prozent überein, mit den drei Frontier-Modellen an der Spitze, und die Autoren nennen den Unterschied eine echte Lücke. Wie TypeSafes Diagramm misst das Übereinstimmung, und der Bericht sagt klar, dass Übereinstimmung nicht Genauigkeit ist. Zwei methodische Details verdienen eine Anmerkung. Jevs Urteile stammen aus dem Juli, die LLMs liefen im September, und ein Check gilt ab einer Wahrscheinlichkeit von 0,70 als bestanden, eine Schwelle, die der Bericht nicht an gelabelten Ergebnissen validiert.

Ihr Plan für Jev ist die Art von Stelle, an der sich Fehler reparieren lassen: ein billiger zweiter Leser bei jedem Check, Meinungsverschiedenheiten gehen an einen Menschen. Das funktioniert nur, wenn Jev anders scheitert als die LLM-Judges, und das ist ungetestet. Der Plan birgt auch ein größeres Risiko, weil Good Start Trainingsumgebungen baut. Sobald das Urteil eines Judges in einen Reward einfließt, wird das trainierte Modell zu jemandem, der eine bestimmte Antwort will und den Zustand schreibt, den Jev liest.

Was die Zahlen des Anbieters messen

Wie gut Jev an diesen Stellen ist, lässt sich schwerer sagen, denn jede der folgenden Genauigkeitszahlen ist eine Selbstauskunft des Anbieters. Die vier Workflows stammen von Leuten aus TypeSafes eigenem Capabilities-Team, eine Verzerrung, auf die das Unternehmen selbst hinweist.

Im gemittelten Diagramm kommt Jev auf 67,8 Prozent, gleichauf mit den Mittelklassemodellen von OpenAI und Anthropic und fünf bis sechs Punkte hinter den besten. Die Referenzlabels sind allerdings die gemittelten Antworten der beiden größten Frontier-Modelle, beide mit hohem Reasoning-Aufwand, während alles andere mit Standardeinstellungen läuft. Genauigkeit heißt hier also Übereinstimmung mit zwei LLMs. TypeSafe begründet das damit, eine Debatte über die Labels vermeiden zu wollen, und merkt an, dass diese Wahl die Tabelle zugunsten von OpenAI und Anthropic verschiebt. Nichts im Diagramm, Jev eingeschlossen, wurde daran gemessen, was tatsächlich richtig war.

Der Durchschnitt verdeckt außerdem eine Streuung. Jev erreicht beim Kundenservice 76 Prozent, gut zwei Punkte hinter dem Spitzenreiter. Bei der Rechnungsverarbeitung schafft es etwa 62, während das beste LLM auf 79 kommt und jedes Modell außer dem kleinsten besser abschneidet. Bei Rechnungen geht es um Beträge, Daten und Querverweise zwischen Dokumenten, also genau um das Terrain, vor dem die Liste der Fehlermuster warnt. Würde ich Jev für den Finanzbetrieb evaluieren, würde ich beim Wert für Rechnungen anfangen und den Durchschnitt ignorieren.

TypeSafes Homepage verspricht 193,6-mal schneller und 444,6-mal billiger, und der Launch-Post erwartet, dass diese Werte eher am oberen Ende dessen liegen, was in der Praxis herauskommt. Sie scheinen gegen das teure Ende des Diagramms gerechnet zu sein. Das billigste vergleichbare LLM im selben Diagramm landet einen Punkt unter Jev, bei etwa den achtfachen Kosten pro Fall. Achtmal billiger ist ein guter Rabatt, mehr aber nicht. Good Starts Tabelle wiederholt das Muster mit den Zahlen eines Dritten. Jev kommt auf 160 Dollar pro Million bewerteter Antworten, der teuerste Judge auf 33.000 Dollar. Der billigste LLM-Judge kostet aber 260 Dollar und stimmt häufiger mit den Frontier-Judges überein als Jev. Was dieses Modell nicht kann, ist in unter einer Sekunde zu antworten: Es braucht 12,9 Sekunden pro Fall, Jev 0,4. Eine Einschränkung wirkt in die andere Richtung. Die LLMs liefen über TypeSafes Adapter, der sie auf strukturierte Entscheidungen mit Wahrscheinlichkeiten festlegt und laut TypeSafe tendenziell langsamer und teurer ist, als eine nackte Entscheidung abzufragen. Ich würde trotzdem erwarten, dass der Großteil des Latenzvorsprungs auch einen faireren Aufbau übersteht. Latenz ist das, was Jev hat und den anderen fehlt.

Typsicherheit beseitigt die lauten Fehler und lässt die leisen übrig

TypeSafe sagt außerdem, Jev könne nicht halluzinieren. Konstruktionsbedingt stimmt das: Der Output-Raum ist das Schema, eine Antwort außerhalb des Schemas ist also unmöglich. Eine Garantie, die per Definition gilt, sagt aber nichts über Qualität aus, und TypeSafe merkt selbst an, dass die null Prozent in seinem Halluzinationsdiagramm keine empirische Zahl sind. The Register brachte den Einwand wenige Stunden nach dem Launch: Eine typisierte Antwort mit angehängter Wahrscheinlichkeit kann trotzdem die falsche Antwort sein.

Typsicherheit verändert, welche Fehler Sie sehen. Ein fehlerhafter Tool-Aufruf eines LLM scheitert laut, am Parser, wo ein Retry oder ein Alert ihn abfangen kann. Ein falscher gültiger Wert besteht jede Prüfung, die das Typsystem vornehmen kann. Jev beseitigt die Klasse der lauten Fehler und lässt die leise übrig, damit hängt alles an den Wahrscheinlichkeiten, die jede Antwort mitbringt.

Good Start hat die laute Klasse gemessen. Sein teuerster LLM-Judge lieferte bei 67 von 1.203 Antworten einen unbrauchbaren ersten Versuch, während Jev in einem separaten Lauf 10.500 Bewertungsaufrufe ohne einen einzigen Fehlschlag absolvierte. Die Autoren fügen hinzu, dass das nichts darüber aussagt, ob die Urteile richtig waren. Browser Use kam nach zwei Tagen Arbeit mit Jev zum selben Schluss. In den Notizen steht „Eine gültige Operation kann trotzdem falsch sein“, und Jevs DONE wird dort als Behauptung behandelt, die erst zu prüfen ist. Jeder der gemessenen Läufe wurde von einem unabhängigen Checker außerhalb der Loop verifiziert.

Der Launch zeigt nicht, dass diese Wahrscheinlichkeiten etwas taugen. Laut Doku wird Kalibrierung über Gruppen von Vorhersagen gemessen und garantiert nichts für eine einzelne Antwort. Das Confidence-Feld ist eine Statistik, die aus der Form der Output-Verteilung berechnet wird, und Noul-Antworten haben gar keines. Im Launch-Post, in der Evals-Übersicht und in den Doku-Seiten, die ich gelesen habe, fand ich keine Reliability-Kurve und keine Zahl zum Kalibrierungsfehler. Die Trainingsmethode ist nach Kalibrierung benannt, aber das Launch-Material misst nur Übereinstimmung.

Guardrails sind die falsche erste Aufgabe

Der Guardrail-Anwendungsfall macht mir die meisten Sorgen. TypeSafe bewirbt Jev für das Bewerten und Prüfen von LLM-Traffic, Jailbreak-Erkennung eingeschlossen. Die eigene Seite zu den Fehlermustern sagt, dass das Modell Zustand standardmäßig nicht als feindlich behandelt und dass eine im Zustand platzierte Anweisung oder ein Text, der für sein eigenes Label argumentiert, die Antwort verschieben kann. Der Zustand einer Guardrail ist per Definition feindlich. Der Browser-Agent zeigt beide Hälften des Problems. Sein README betont, dass Modell-Output nie zu einem Selektor, einer Koordinate oder einer Zeile JavaScript wird und dass jedes ausgeführte Ziel aus einem Knoten aufgelöst wird, den der Harness selbst beobachtet hat. Eine feindliche Seite kann den Agenten also nicht aus dieser Tabelle hinausdrängen. Sie kann aber innerhalb der Tabelle für den falschen Button argumentieren. Die Entscheidungsschicht erbt das Injection-Problem, und zum Auditieren bleibt nur ein Satz Wahrscheinlichkeiten.

Wo ich es einsetzen würde

Ich würde Jev trotzdem ausprobieren, und diese drei Projekte zeigen, wo. Alle setzen es an eine Stelle, an der sich eine falsche Antwort reparieren lässt. Der Browser-Agent prüft das Ergebnis außerhalb der Loop, der Compactor löscht nur, was sich der Agent wieder holen kann, und der Judge schickt seine Meinungsverschiedenheiten an einen Menschen. Die ersten beiden halten außerdem ein LLM in der Nähe, für den Teil, der Worte braucht. Eine Guardrail hat keine dieser Eigenschaften, denn einen verpassten Jailbreak können Sie nicht einfach noch einmal versuchen. Wo auch immer Sie es einsetzen: Ich würde die Zahlen des Anbieters nicht an die Stelle eigener Messungen setzen. Bevor Sie einen LLM-Aufruf durch Jev ersetzen, messen Sie drei Dinge auf Ihren Daten:

1. Kalibrierung auf Ihrer Verteilung: Teilen Sie die angegebenen Wahrscheinlichkeiten in Buckets ein, prüfen Sie sie gegen Ergebnisse, die Sie gelabelt haben, und fixieren Sie die Modellversion, denn der Alias wandert.
2. Genauigkeit pro Workflow, gemessen an Labels, die ein Mensch geprüft hat.
3. Das Verhalten, wenn der Zustand von jemandem geschrieben wird, der eine bestimmte Antwort will.

Der Name ist eine Wette auf das Jevons-Paradoxon: Jedes Mal, wenn die Kosten von Intelligenz um den Faktor zehn fallen, sollten weit mehr als zehnmal so viele Anwendungen entstehen. Das stimmt wahrscheinlich, und genau das stört mich. Software wird weit mehr solcher Entscheidungen treffen, und keine davon wird geparst oder validiert, weil es nichts mehr zu validieren gibt. Wenn ein LLM eine fehlerhafte Antwort lieferte, stürzte etwas ab, und jemand merkte es. Wenn Jev den falschen gültigen Wert liefert, geht er in Produktion.

Aus dem Englischen übersetzt: zum Originalbeitrag