Jev: Begründeter Hype oder ein Classifier wie jeder andere?

TypeSafe AI, ein bis dahin kaum bekanntes KI-Start-up aus San Francisco, nennt sein Mitte September vorgestelltes Modell Jev eine neue Klasse von KI: Es soll Entscheidungen für Software treffen, statt mit Menschen zu chatten. Beim Ausfüllen der Buzzword-Bingo-Karte greift man der Einfachheit halber zur Schrotflinte: „System One“ als neue Modellgattung (nach Kahnemans schnellem, intuitivem Denken), ein Modell, das laut Anbieter „can't hallucinate“ und dazu laut der Startseite 193,6× schneller und 444,6× billiger ist – Werte, die der Launchtext selbst am oberen Ende des Erreichbaren ansiedelt. Die erste Reaktion darauf liegt nahe: Texte in Kategorien einordnen konnten Classifier schon lange. Warum also der Hype?

Messbar ist er jedenfalls: Die Vorstellung auf Hacker News sammelte fast 2.000 Punkte, und laut Vercel nutzten nach 24 Stunden knapp 13 Prozent der zahlenden Kunden seines KI-Gateways das Modell. Das trifft einen Nerv: KI-Agenten treffen viele kleine Entscheidungen, und jede Sekunde pro Entscheidung summiert sich. Auffällig ist auch, wie schnell Jev von der Community aufgenommen wurde. TypeSafe zeigte zum Start einen Doom-Bot und ein Wettrennen durch Wikipedia-Links; in den Tagen danach steuerte die Community Jev durch Snake – mehrfach und in verschiedenen Varianten –, band es per Erweiterung in Cursor ein und ließ es Video-Transkripte bewerten. Ein Spötter baute das Prinzip in 25 Zeilen Python nach. Die wie Pilze aus dem Boden sprießenden Demos zeigen, wie leicht die Einbindung ist.

Ein Kontext, eine Frage, mögliche Antworten, das genügt für den ersten Aufruf. TypeSafe beschreibt das im Launchtext selbst als „smart if-statements“, als unscharfe Entscheidungsregeln dort, wo handgeschriebene Logik zu spröde wird; Almeida ordnet im Podcast Latent Space (ab 00:58:06) jeder Frageform ein Sprachkonstrukt zu: die Ja/Nein-Frage dem if, die Auswahl dem switch, die Bewertung dem Sortieren oder einem Schwellenwert. Ist Jev also nur ein Classifier mit neuem Etikett – oder ein neuer Baustein für Software?

Fragen hinein, Entscheidungen heraus

Jev erhält einen Kontext – etwa eine E-Mail und Informationen aus dem zugehörigen Vorgang – und Fragen mit vorgegebenen Antwortmöglichkeiten. „Gehört diese Mail zum Rechnungsteam?“ lässt sich als Ja/Nein-Frage formulieren (noul). Für „Welches Team ist zuständig?“ könnte Jev aus mehreren benannten Teams wählen (choice). Daneben bietet die API eine Bewertung anhand beschriebener Stufen (score). Zurück kommen typisierte Werte und Wahrscheinlichkeiten, kein frei formulierter Antworttext. Mehrere Fragen können sich auf denselben Kontext beziehen.

Das Programm entscheidet anschließend, was aus den Werten folgt: weiterleiten, ein Sprachmodell hinzuziehen oder einen Menschen einschalten. Das Modell übernimmt unscharfe Urteile; Rechte und feste Regeln bleiben im Code. Das klingt nach klassischer Textklassifikation – was also ist daran neu?

Fragen zur Laufzeit statt Trainingsstrecke – ist das neu?

Gegenüber manchen etablierten Diensten ist der Unterschied deutlich. Wer mit AWS Comprehend eigene Textkategorien erkennen will, muss mindestens 50 Beispiele pro Kategorie labeln und ein Modell trainieren – und das bei jeder neuen oder geänderten Kategorie erneut; für Azure Language gilt dasselbe. Für eine stabile, gut dokumentierte Aufgabe kann sich dieser Aufwand auszahlen; er ist nur eine erhebliche Investition, bevor überhaupt die erste Antwort kommt. Google Cloud Natural Language liefert Klassifikation ohne eigenes Training, allerdings anhand einer vorgegebenen Themenliste.

Jev hat die Idee „Kategorien beim Aufruf festlegen“ jedoch nicht erfunden. Das Verfahren ist altbekannt: die Zero-Shot-Klassifikation, also Einordnen ganz ohne Trainingsbeispiele, ist seit 2019 beschrieben. Eine ähnliche API bietet die Zero-Shot-Klassifikation von Hugging Face, diese nimmt Text und frei gewählte Klassen ebenfalls ohne kundenspezifisches Training entgegen. Und generative Modelle können mit Structured Output, etwa über Amazon Bedrock oder die Claude-API, ihre Antworten auf ein striktes Schema beschränken. TypeSafe bestreitet das nicht, argumentiert aber, ein Sprachmodell in ein solches Format zu zwingen koste Leistung, während Jev von Anfang an für Entscheidungen trainiert sei.

Ein Unterschied bleibt aber bei den Zahlen. Jev gibt eine Wahrscheinlichkeit über alle angebotenen Optionen aus, und TypeSafe benennt genau das als Trainingsziel: Reinforcement Learning for Calibrated Decisions soll sie kalibrieren – sagt Jev 80 Prozent, soll es in etwa acht von zehn solcher Fälle recht haben, wie bei einem guten Wetterbericht. Ein Sprachmodell kann man ebenfalls um eine Zahl zwischen 0 und 1 bitten – nur erzeugt es die als Text, ohne dafür trainiert worden zu sein. Der sauberere Weg führt dort über die internen Wahrscheinlichkeiten, die das Modell für die Antwortwörter berechnet, und auch die sind nicht automatisch kalibriert.

Der mögliche Unterschied liegt also im Gesamtpaket: frei formulierbare Fragen, mehrere Antworten zu einem Kontext, Wahrscheinlichkeiten als eigentliches Produkt und ein Dienst, der laut TypeSafe für schnelle Urteile optimiert wurde.

Was steckt hinter dem Tempo und wie könnte Jev funktionieren?

Ein Chatmodell erzeugt eine Antwort üblicherweise Token für Token, also Wortstück für Wortstück. Das ist langsam, obwohl die Entscheidung im internen Zustand des Modells oft längst angelegt ist – Verfahren wie FIRST lesen sie deshalb direkt aus den Werten des ersten Antworttokens ab. TypeSafe beschreibt Jev als Modell, das Wahrscheinlichkeiten für vorgegebene Antworten parallel ausgibt. Vorstellen kann man sich das so: Ein Ausgabeteil ordnet jeder Option einen Wert zu und berechnet daraus eine Verteilung; die API setzt die Zahlen in eine feste Antwortform, ein langer generierter Text entfällt.

Mehrere Fragen können dabei denselben Kontext nutzen, ohne auf die Antwort der jeweils anderen warten zu müssen. Solche Systeme auf Basis vortrainierter Sprachmodelle zu bauen, liegt nahe: Kurz nach Jevs Vorstellung entstanden offene Implementierungen. SemIf liest Antwortwerte eines vorhandenen Modells aus und misst auf derselben Hardware 1,0 statt 5,3 Sekunden gegenüber generiertem JSON. Kev geht einen Schritt weiter: Kontext, Frage und mögliche Antworten werden zu einer Tokenfolge, an deren Ende ein Marker <decide> steht. Ein trainierter Ausgabeteil vergleicht den Zahlenvektor an diesem Marker, eine Art Zusammenfassung des Gelesenen, mit dem jeder Option: drei Vergleiche ergeben drei Werte, daraus drei Wahrscheinlichkeiten – ohne einen Antwortsatz zu generieren. Der einmal verarbeitete Kontext lässt sich für weitere Fragen wiederverwenden und alle Fragen lassen sich parallel beantworten.

Kevs offene Implementierung, von unten nach oben gelesen: Kontext, Frage und drei Optionen durchlaufen als eine Tokenfolge ein Sprachmodell mit trainierten Adaptern. An den schließenden Optionsmarkern entsteht je ein Optionsvektor, am Marker <decide> der blaue Vergleichsvektor. Ein Pointer-Head vergleicht jeden Optionsvektor mit diesem Vergleichsvektor, stets mit denselben trainierten Gewichten; aus den drei Logits macht Softmax drei Wahrscheinlichkeiten.

Während in der Community die ersten Nachbauten nach Tagen erschienen, brauchten größere Player ein paar Wochen. Fast dasselbe Prinzip wie Kev hat AWS Anfang Oktober mit dem Labs-Projekt Strands Decider veröffentlicht; Mitautor Marc Brooker nennt den Ansatz selbst „fairly similar to the approach Kev takes“. Dass es nicht die eine Bauweise gibt, zeigt Cloudflares am 1. Oktober vorgestelltes Clef: Auch dort bewertet ein kleiner trainierter Aufsatz auf einem Sprachmodell die Optionen, statt Text zu erzeugen – er entscheidet aber alle Fragen bewusst gemeinsam, statt sie voneinander zu trennen.

Daneben gibt es weitere offene Varianten: Nimble von Bespoke Labs, ein auf Entscheidungen nachtrainiertes Sprachmodell mit 9 Milliarden Parametern, das ähnlich wie SemIf die Wahrscheinlichkeiten von Antwortbuchstaben ausliest und Trainingsdaten wie Rezept offenlegt; und am anderen Ende der Skala Laya, kein Sprachmodell, sondern ein nur 421 Millionen Parameter kleiner Encoder, der Frage, Optionen und Kontext gemeinsam liest, auf dem Laptop läuft und bei Vercel derzeit kostenlos erreichbar ist.

All diese Projekte sind damit gute Blicke unter die Haube möglicher Verfahren, aber keine Rekonstruktion von Jev – auch wenn Clef sich „fully Jev-API compatible“ nennt: Gleiche Schnittstelle heißt nicht gleiches Innenleben. Wie Jev intern aufgebaut und genau trainiert wird, ist nicht veröffentlicht.

Schnell entschieden heißt nicht richtig entschieden

Beide Werbeversprechen halten nur unter Bedingungen, die TypeSafe nicht nennt. Das Tempo zuerst: Der Anbieter nennt 70 bis 500 Millisekunden, unabhängige Messungen liegen bei 247 Millisekunden im Median auf kurzen Einzelfragen und bei 710 Millisekunden auf 2.000 Entscheidungen – schnell, aber lastabhängig. Entscheidend ist der Bezugspunkt: Gegen welches Modell die 193,6× gemessen sind, sagt TypeSafe nicht; die Zahl stammt aus eigenen Tests mit einer ganzen Reihe von Modellen. Unabhängige Vergleiche, die Jev und ein kleines Modell mit ähnlicher oder besserer Trefferquote dieselben Fälle bearbeiten lassen, kommen auf deutlich kleinere Faktoren: Ein Pilotvergleich auf dem BANKING77-Datensatz misst 2,5× gegenüber OpenAIs GPT-5.6 Luna – bei 7,2 gegenüber 11,5 US-Cent je 1.000 Anfragen, aber 58 statt 64 von 77 Kategorien richtig und das neuere GPT-6 Luna war sogar günstiger als Jev, allerdings bei schlechterer Trefferquote.

Und das zweite Versprechen? „Can't hallucinate“ ist keine Messung, sondern folgt aus der Bauweise: Weil nur deklarierte Optionen zurückkommen können, garantiert TypeSafe null Formatfehler – über die inhaltliche Richtigkeit sagt das nichts. Wie wenig das bedeutet, zeigt ein Detail der Dokumentation – bietet man keine Option „keines davon“ an, wählt Jev auch dann eine der angebotenen, wenn keine passt. Ein TypeSafe-Vertreter räumt selbst ein, dass Typsicherheit nicht faktische Korrektheit ist, hält den Halluzinationsbegriff aber für auf Klassifikatoren nicht übertragbar; der Streit um das Wort ist offen. Messen lassen sich dagegen Trefferquoten: In TypeSafes eigenen Evaluationen, gemessen an den Urteilen zweier großer Modelle, erreicht Jev 67,8 Prozent über vier Aufgaben, genauso viel wie Anthropics Sonnet 5, bei der Rechnungsprüfung aber nur 61,8 gegenüber 79,1 Prozent für OpenAIs großes Modell Sol. heise nennt dazu ein Transparenzproblem: Man sieht das Urteil, nicht den Weg dorthin.

Bleibt der confidence-Wert, der anzeigen soll, wann man einem Urteil trauen kann. Er ist laut TypeSafe zunächst ein Maß dafür, wie stark die Wahrscheinlichkeiten auf eine Option konzentriert sind – keine unabhängig gemessene Trefferquote, und für Ja/Nein-Fragen gibt es ihn gar nicht. Wie verlässlich die Wahrscheinlichkeiten selbst sind, hat ein Entwickler nachgeprüft: Auf seinen eigenen, künstlich erzeugten Ja/Nein-Fragen lag Jev immer richtig, wenn es sich zu mindestens 90 Prozent sicher war. Auf einem öffentlichen Phishing-Benchmark stimmten dagegen nur knapp drei Viertel dieser sehr sicheren Antworten. Eine Schwelle, die in einem Einsatzgebiet funktioniert, lässt sich also nicht ungeprüft übertragen – und erst recht nicht von einem Modell auf ein anderes: In einem unabhängigen Test mit 3.600 Logikaufgaben lag OpenAIs GPT-6 Luna bei angegebener Sicherheit von mindestens 99 Prozent nur in 68 Prozent der Fälle richtig, Jev in 98,9 Prozent. Dazu dokumentiert TypeSafe für Version 1.13 Schwächen bei Zahlen, Datumsvergleichen, langen irrelevanten Kontexten und manipulativen Eingaben. Jev verarbeitet zudem derzeit nur Text und ist als Early Access gekennzeichnet. Almeida sagt es im Interview (00:13:32) am deutlichsten: Von der Zuverlässigkeit einer Datenbankabfrage sei Jev noch weit entfernt.

Was von Jev bleiben könnte

Jev ist ein Classifier. Als allgemeiner Ersatz für Sprachmodelle ist es weder gedacht noch belegt. Vielleicht erklärt gerade das einen Teil des Hypes: Nach Jahren, in denen KI weitgehend mit großen Sprachmodellen gleichgesetzt wurde und fast jede Aufgabe zum agentischen Workflow mit Tool-Calls zu werden schien, hat Jev viele Entwickler daran erinnert, dass KI mehr ist als ein LLM – und dass der Classifier nie aus der Werkzeugkiste verschwunden ist. Nicht jede Entscheidung braucht ein Modell, das plant, Schritte ausführt und Text formuliert; oft genügt eines, das zwischen vorgegebenen Optionen wählt.

Folgenreich könnte die Möglichkeit sein, kleine, flexibel definierbare KI-Urteile als spezialisierten Dienst ohne aufwändiges Training in Software einzubauen. Wer das nutzen will, sollte Jev mit alternativen Klassifikationsdiensten und eineten geeigneten kleinen Modellen auf eigenen Beispielen vergleichen: nicht nur Preis und Antwortzeit, sondern auch Fehlentscheidungen und nötige menschliche Prüfung sind entscheidend.

Unsere These: Das Überzeugendste an Jev ist die Form der Schnittstelle – ein Kontext, mehrere typisierte Fragen, Wahrscheinlichkeiten statt Text zurück. Genau die lässt sich nachbauen, und wie schnell sie sich verbreitet, zeigten die zwei Wochen nach dem Start: Cloudflare stellte mit Clef ein ausdrücklich Jev-kompatibles Modell auf seine Plattform, AWS-Entwickler veröffentlichten mit Strands Decider ein offenes Pendant, Ollama und llama.cpp bieten denselben Endpunkt lokal an, und OpenAI kündigte eine eigene Decisions API an. Ein Preprint legt zudem nahe, dass gewöhnliche Sprachmodelle solche Entscheidungen schon ohne zusätzliches Training liefern können – neu ist vor allem die Form. Einen tiefen Burggraben sahen schon kurz nach dem Start weder der KI-Berater John Berryman noch die von TechTarget befragten Analysten.

Ob Jev selbst dabei gewinnt, ist offen. Dass eine Entscheidungsfrage ohne Trainingsstrecke direkt im Code formuliert wird, ist aber ein Muster, das bleiben dürfte.