Typisierte Entscheidungen statt Fließtext: was Jev ist und wann es das richtige Werkzeug ist

Wer ein Sprachmodell etwas fragt, bekommt Text zurück. Aus diesem Text muss Software danach wieder einen Wert machen: eine Kategorie, eine Zahl, ein Ja oder Nein. Genau an dieser Stelle setzt eine Klasse von Modellen an, die keinen Text erzeugt, sondern direkt einen Wert aus einer vorher festgelegten Menge zurückgibt. Das bekannteste davon heißt Jev, kam am 15.09.2026 von der Firma TypeSafe AI und ist seitdem Gegenstand von sehr viel Text, der den Anbieterblog nacherzählt.

Zwei Fragen entscheiden über den Einsatz: was Jev ist, und wann es die bessere Wahl ist als ein Sprachmodell mit erzwungenem Ausgabeschema. Dazu kommt der Teil, den keine der gesichteten Quellen ausführt: wie eine Frage aussehen muss, damit die Antwort trägt, und was an Betriebstechnik dazugehört, bevor so ein Aufruf in einem Produkt steht.

Stand aller Angaben: 24.09.2026. Das Thema ist neun Tage alt, alles darin altert schnell.

Jev beantwortet eine festgelegte Frage mit einem Wert, nicht mit Text

Die Selbstbeschreibung im Launch-Blogpost (typesafe.ai, Diogo Almeida, 15.09.2026) lautet: „a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out". Unstrukturierter Zustand rein, typisierte Entscheidung raus.

Der Aufruf besteht aus zwei Teilen. Der state ist beliebiger Text, ein JSON-Objekt oder ein Array: das Ticket, die Notiz, der Seiteninhalt. Dazu kommen eine oder mehrere Fragen, deren Antwortraum vorher feststeht. Das Modell wählt aus diesem Raum, es schreibt nichts.

Daraus folgt der Rest von selbst. Es gibt kein Parsing, weil es keinen String gibt. Es gibt kein Schema-Validieren, weil der Antwortraum die Antwort ist. Und die Ausgabe ist kostenlos, weil sie aus wenigen Zahlen besteht.

Mitgeliefert wird etwas, das die anderen Wege nicht liefern: zu jeder Antwort kommt eine Wahrscheinlichkeitsverteilung über alle Optionen und daraus abgeleitet ein Sicherheitswert.

Drei Fragetypen, mehr gibt es nicht

Die Dokumentation (docs.typesafe.ai/primitives, abgerufen 24.09.2026) kennt genau drei:

Alles, was nicht in diese drei Formen passt, passt nicht in das Modell. Eine Rangfolge über zwanzig Kandidaten liefert eine Choice nicht: sie liefert eine Wahl und eine Sicherheit. Wer eine Reihenfolge braucht, muss sie im Code bauen oder mehrere Fragen hintereinander stellen.

Bei mehr als 255 Optionen arbeitet der Anbieter nach eigener Angabe zweistufig, erst unabhängig bewerten, dann wählen, „hence the occasional slowdown" (Launch-Blogpost, 15.09.2026).

Preis, Grenzen und Zugang in Zahlen

Alles aus docs.typesafe.ai/models, abgerufen am 24.09.2026:

Die Doku schreibt dazu: „Rate limits are adjusting dynamically … can change without notice."

Kein Fine-Tuning: „Jev is not fine-tuned or LoRA-adapted with customer data … the same weights serve every account." Anpassen lässt sich nur der state, die instructions, die criteria und der Zuschnitt der Frage.

Zugang gibt es direkt über POST https://api.typesafe.ai/v1/systemone (Early Access mit Warteliste), über das Vercel AI Gateway seit 16.09.2026 als typesafe-ai/jev, über OpenRouter und über ZenMux als typesafe/jev-1.13. SDKs: @typesafe-ai/sdk, typesafe_sdk, langchain-typesafe.

Zwei Dinge, die beim ersten Anschluss Zeit kosten und nirgends dokumentiert sind (Einzeltests, 20. und 24.09.2026). Erstens sind Schlüssel und Adresse nicht austauschbar: ein TypeSafe-Schlüssel wird von ZenMux nicht akzeptiert und umgekehrt, obwohl Anfrage- und Antwortformat identisch sind. Zweitens antwortet eine falsche Pfadangabe mit HTTP 200 und einem HTML-Dokument. Wer nur den Statuscode prüft, läuft an allen Fehlerpfaden vorbei in einen JSONDecodeError. Fehlt das Feld criteria, kommt über ZenMux nur 400 invalid_params mit „Server encountered an unexpected error", ohne Hinweis auf das fehlende Feld.

Der Sicherheitswert ist eine Formel über die Verteilung, keine Modellausgabe

Der Anbieter schreibt es selbst (docs.typesafe.ai/confidence): confidence ist keine Messgröße des Modells, sondern eine Statistik aus der Wahrscheinlichkeitsverteilung. Die Doku zeigt die Näherung für drei Optionen offen: (3 × größte Wahrscheinlichkeit − 1) / 2.

Der Wert misst also die Eindeutigkeit der Verteilung, nicht die Richtigkeit der Antwort. Ein Modell kann sich mit hoher Eindeutigkeit irren, und es tut das auch. Die Dokumentation sagt das an zwei Stellen selbst: „Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct."

Empfohlen wird ein Muster mit drei Bereichen: hoch bedeutet automatisch handeln, mittel bedeutet mit Vorbehalt weiterreichen, niedrig bedeutet nicht handeln. Die Schwellen richten sich nach dem Risiko, im Codebeispiel der Doku 0.5 als Boden und 0.9 für eine Überweisung. Wo diese Schwelle liegt, ist keine technische, sondern eine Produktentscheidung.

Structured Outputs lösen die Form, nicht die Frage

Die naheliegende Gegenfrage lautet: das kann ein Sprachmodell mit JSON-Schema doch auch. Form erzwingen, fertig. Die Antwort hat zwei Teile.

Erstens hebt erzwungenes Decoding die Sequenzialität nicht auf. Die Antwort entsteht weiterhin Token für Token, die Latenz hängt an der Ausgabelänge, und zwei Fehlerpfade bleiben offen: die Verweigerung aus Sicherheitsgründen und die abgeschnittene Antwort am Token-Limit. Beides produziert kein Schema-konformes Ergebnis, sondern gar keins.

Zweitens, und das wiegt schwerer: ein Schema sagt nichts über die Sicherheit. Ein confidence-Feld, das im Schema steht, wird vom Modell als Text erzeugt wie jedes andere Feld. Es ist eine Selbsteinschätzung, kein Maß. TrueFoundry (Ashish Dubey, 18.09.2026) formuliert es so: „constraining the shape of an answer has never guaranteed the substance of it."

Die Abgrenzung verläuft deshalb an einer anderen Stelle, als „mit Schema gegen ohne Schema" nahelegt. Sie lautet: muss das Modell die Antwort überhaupt erzeugen, und kommt zusammen mit der Antwort ein belastbares Maß für ihre Sicherheit?

Sieben Wege zu einem Wert statt eines Textes, mit Kosten und Bruchstelle

Jev ist eine von sieben Antworten auf dieselbe Aufgabe. Ohne diesen Rahmen wird jede Bewertung zur Produktvorstellung.

1. Eigener Parser (Regex, JSON aus dem Text fischen): Kosten: ein Modellaufruf plus Reparaturschleife. Bruchstelle: alles. Von allen gesichteten Quellen als überholt behandelt.

2. Structured Outputs beim großen Anbieter: Kosten: der normale Modellpreis, laut TypeSafe-Vergleichstabelle 0,20 bis 10 $ je Million Eingabe-Token, Ausgabe etwa fünfmal so teuer. Löst die Form zuverlässig. Bruchstelle: Sequenzialität, Verweigerung, Abschneiden, und das Schema sagt nichts über die Sicherheit.

3. Logprobs auslesen: Technisch dasselbe, was Jev tut, und deutlich älter. Optionen nach Label-Wahrscheinlichkeit zu bewerten steht schon im GPT-3-Paper (§2.4, 2020) und in MMLU (§4.1, 2021), das Abbilden eines Labels auf ein Token als Verbalizer bei Schick und Schütze (arXiv 2001.07676), die bekannte Verzerrung der Label-Priors bei Zhao et al. (Calibrate Before Use, 2021), die Reparatur von Überkonfidenz durch eine angepasste Temperatur bei Guo et al. (2017) und Kadavath et al. (2022). Offen zugänglich über vLLM (logprob_token_ids) und SGLang (/v1/score). Kosten: eigene Hardware oder Anbieterpreis. Bruchstelle: Die großen geschlossenen Anbieter geben Logprobs nicht heraus, laut einem Kommentar im Hacker-News-Launch-Thread bewusst, weil es Distillation erleichtert. Dazu die schlechte Kalibrierung roher Modelle (Median-ECE 0,180 bei Gemma 4 26B, siehe unten).

4. Function Calling: Dasselbe Grundproblem wie bei Structured Outputs, plus einen eigenen Fehlerpfad: der Werkzeugname selbst kann halluziniert werden. TrueFoundry dazu: „Having a hallucinated tool call is inconvenient in an agent, but is an absolute deal-breaker if it's … buried several layers deep in a dependency chain."

5. Trainierter Klassifikator (fine-tuned Encoder, klassisches ML): Kosten: Beschriftungsarbeit plus ein Trainingslauf, danach fast nichts. Bruchstelle: der kalte Start ohne Labels, und jede neue Kategorie verlangt ein neues Training. Wo dieser Weg gewinnt, gewinnt er deutlich. Aus der dev.to-Metastudie vom 24.09.2026: ein japanischer 310M-Encoder, trainiert auf 200 Zeilen, schlug Jev bei Nachrichtenthemen um 12 Punkte (88,8 % gegen 76,8 %); bei Phishing kam ein LoRA-Nachbau mit 1.000 Labels auf 97,4 % gegen Jevs 62,6 %, und eine zweizeilige Regex auf demselben Benchmark auf 91,6 %. Der Satz der Auswertung dazu: „Labels beat zero-shot wherever they were tried."

6. Zero-Shot über NLI: Das klassische facebook/bart-large-mnli-Muster. Kosten: eigene Hardware, das Modell ist frei. Bruchstelle: Sprache (englisch trainiert), Kalibrierung, Trennschärfe. Aus dieser Familie kommen die offenen Jev-Nachbauten, und genau dort versagen sie auf Deutsch (siehe unten).

7. Constrained Decoding als Bibliothek (Outlines, llguidance, Instructor): Erzwingt das Schema lokal auf jedem offenen Modell. Kosten: eigene Hardware. Bruchstelle: dieselbe wie bei Punkt 2. Form gelöst, Sicherheit nicht.

Jev lohnt sich dort, wo aus Freitext eine Auswahl werden muss

Aus dem Vergleich folgt eine Auswahlregel, die in den gesichteten Quellen nirgends ausformuliert ist.

Gegen Jev spricht es, wenn beschriftete Daten vorliegen. Fünfzig bis tausend eigene Labels schlagen Zero-Shot in jeder gemessenen Aufgabe, und ein trainierter Encoder ist danach billiger im Betrieb als jeder API-Aufruf.

Gegen Jev spricht es auch, wenn die Antwort nicht aus einer Menge kommt, sondern erzeugt werden muss. Der Anbieter benennt das als Fehlermodus: „jev-1.13 is not trained to generate text." Der LangChain-Blog (Sydney Runkle, Hunter Lovell, 17./18.09.2026) schreibt denselben Satz anders: „Jev isn't a drop-in replacement for an LLM."

Ebenfalls gegen Jev: alles Nachzählbare, jeder Datumsvergleich, jede Rechnung. Dazu gleich mehr.

Für Jev spricht es, wenn aus mehrdeutigem Text eine Auswahl aus wenigen unterscheidbaren Kandidaten werden soll, wenn es keine Labels gibt, wenn die Entscheidung oft fällt und schnell sein muss, und wenn zur Entscheidung ein Sicherheitswert gehört, an dem eine Schwelle hängt.

Die knappste Formulierung dieser Grenze stammt aus digital-magazin.de (18.09.2026): „Deterministische Fakten gehören in Code oder Datenbanken, die Bewertung eines mehrdeutigen Textes in ein Modell."

Ein Einzelfall vom 23.09.2026 läuft gegen die Erwartung: Beim Einsortieren eines Werkzeugs namens scorecard widersprach das Modell mit 0,79 der Zuordnung, die zuvor von Hand getroffen worden war, und entschied auf eine andere Kategorie. Die Nachprüfung gab ihm recht. Wer den Sicherheitswert ernst nimmt, muss also auch damit rechnen, dass er gegen die eigene Einschätzung ausschlägt.

Die Bauanleitung, die im Feld fehlt

Von rund zwanzig gesichteten Seiten zum Thema bringen vier eigenes Material. Alle zeigen dasselbe Support-Ticket und hören dort auf. Die Arbeit, die tatsächlich über Erfolg und Misserfolg entscheidet, kommt in keinem der Erklärstücke vor. Die folgenden sieben Regeln stehen verstreut in der Anbieter-Doku oder in gar keiner Quelle.

In jede Auswahl gehört ein Ausweg

Eine Choice zwingt das Modell, aus der Liste zu wählen. Steht die richtige Antwort nicht darin, wählt es trotzdem, und das Ergebnis sieht dabei gut aus.

Ein Einzeltest vom 20.09.2026 zeigt den Effekt sauber. Vorgelegt wurde ein deutscher Text, der den Mauerfall beschreibt, ohne das Wort zu nennen. Mit der richtigen Option in der Liste: mauerfall, Sicherheit 1,0. Ohne sie, also nur mit Mauerbau, Währungsunion und Olympia München zur Auswahl: mauerbau mit 89 % Wahrscheinlichkeit und Sicherheit 0,84. Eine falsche Antwort, die über jeder üblichen Schwelle liegt. Kommt eine zusätzliche Option keines_davon dazu, wählt das Modell diese mit 97 %.

Daraus folgt: Jede Choice bekommt eine Option „nichts davon", ohne Ausnahme. Wer das in ein Werkzeug einbaut, baut sie als Vorgabe ein und macht sie nur bewusst abschaltbar.

Der Ausweg taugt außerdem als Prüfstein für Nachbauten: Ein Modell, das ihn bei fehlender richtiger Option nicht wählt, ist für Schwellenbetrieb unbrauchbar (siehe unten).

Zu jedem Urteil gehört eine zweite Frage nach der Grundlage

Der Sicherheitswert sagt, wie eindeutig die Verteilung ist. Er sagt nicht, ob das vorgelegte Material für ein Urteil überhaupt reicht. Diese zweite Frage muss separat gestellt werden, als Noul.

Beispiel aus einem Einzeltest (20.09.2026): Auf die Frage „Wer hat Schuld?" kam unklar mit 63 %. Die Nachfrage „Reichen die Angaben für ein Urteil?" ergab 0,1. Erst wenn dieser zweite Wert über der Schwelle liegt, darf der Code mit dem Urteil weiterrechnen.

Derselbe Aufbau in einem anderen Fall: Ein Briefing wurde in die Branche praxis_gesundheit eingeordnet, Sicherheit 1,0, Dringlichkeit 2,13 von 3. Die Frage, ob damit die Arbeit starten darf, ergab 0,05, also nein, weil noch Texte fehlten. Verbrauch für den ganzen Aufruf: 725 Eingabe- und 190 Ausgabe-Token, rund 0,004 Cent.

Niedrige Sicherheit ist zuerst eine Frage an den Zustand

Wenn ein Wert niedrig ausfällt, ist der erste Reflex, an der Frage zu schrauben oder die Schwelle zu senken. Beides ist meistens falsch. Der übliche Grund ist, dass im state schlicht zu wenig steht.

Belegt an der Zuordnung von 50 Werkzeugen zu Kategorien (Einzeltest, 23.09.2026): Bei einem Eintrag namens timeline lag die Sicherheit bei 0,31. Mit der echten Beschreibung des Werkzeugs im Zustand stieg sie auf 0,76, eine Gegenfrage bestätigte die Zuordnung mit 0,79. Die Frage war dieselbe geblieben.

Die Anbieter-Doku nennt die Gegenrichtung als Fehlermodus: „Jev suffers from context rot." Viel Irrelevantes im Zustand schadet genauso wie zu wenig Relevantes. Anreichern heißt gezielt anreichern, nicht alles hineinkippen.

Vor jedem Aufruf muss deterministisch vorsortiert werden

Ein Modell, das aus höchstens 255 Optionen wählt und mit großem Kontext schlechter wird, gehört hinter eine Vorauswahl, die ohne Modell auskommt. Die Trennlinie dazu lässt sich in einem Satz formulieren: Einen Eintrag über seinen Schlüssel nachzuschlagen ist eine Hashtabelle und kein Urteil; ein Modell dafür einzusetzen wäre teurer, langsamer und schlechter.

Die Bauform, die sich in der Praxis bewährt hat: Punktwerte im Code berechnen, auf höchstens sechs bis acht Kandidaten kürzen, und erst über diese Kandidaten plus „nichts davon" genau eine Frage stellen. Erreicht kein Kandidat die Mindestpunktzahl, entfällt der Aufruf ganz. Eingaben unter drei Zeichen lösen keinen Aufruf aus, sehr lange Eingaben werden gekürzt.

Wichtig dabei: Die Rangfolge der Kandidaten kommt aus dem deterministischen Punktwert, nicht aus dem Modell. Eine Choice liefert eine Wahl und eine Sicherheit, kein Ranking. Wer aus den probabilities eine Reihenfolge baut, benutzt einen Wert für etwas, wofür er nicht geeicht ist.

Die Vorsortierung hat eine eigene Bruchstelle, die selten benannt wird. Eine Punktwertung über Teilzeichenketten schlägt bei kurzen Füllwörtern durch: In einem Katalog von 50 Werkzeugen steckt „der" in 22 Einträgen und „ist" in 11 (Auszählung, 23.09.2026). Damit greift die Regel „kein Kandidat erreicht die Mindestpunktzahl" bei einem normalen deutschen Satz fast nie, und eine sinnlose Frage kostet trotzdem einen echten Aufruf. Konkret ergab „Quallenzucht in der Nordsee" acht Kandidaten, „Quallenzucht Nordsee" keinen. Wer so vorsortiert, braucht eine Stoppwortliste oder eine Mindestlänge je Treffer.

Was sich nachzählen lässt, gehört in den Code und nicht in ein Modell

Der Anbieter listet Rechnen, Zählen und Datumsvergleiche als Fehlermodi. Trotzdem passiert genau das in der Praxis, weil es in der Frageform so bequem aussieht.

Zwei dokumentierte Fehlgriffe vom 24.09.2026, beide auf dieselbe Art:

Im ersten Fall sollte das Modell aus einer ganzen Trefferliste lesen, ob eine bestimmte Domain darin vorkommt. Bei zwei Fragen meldete es „weit vorn in den Treffern" mit Sicherheit 0,28, obwohl keine einzige passende Domain in der Liste stand. Ob eine Domain in einer Liste steht, ist ein Zeichenkettenvergleich und keine Ermessensfrage. Die Reparatur bestand darin, die Tatsache im Code zu prüfen und das Modell nur noch entscheiden zu lassen, wie weit vorn, und das auch nur, wenn die Domain tatsächlich vorkommt.

Im zweiten Fall sollten Stichwort-Ideen gegen eine Liste von Themen bewertet werden, zu denen Substanz vorliegt. Das Modell stufte aus einem bloßen Stichwort alles als Kernthema ein, weil es ein Wort aus der Substanzliste wiedererkannte.

Die Regel aus beiden Fällen: Das Modell braucht unterscheidbare Kandidaten. Wortvarianten desselben Begriffs sind keine unterscheidbaren Kandidaten. Und was sich auszählen lässt, zählt der Code aus. Der Anbieter empfiehlt dafür selbst eine Ersatzform: eine Noul-Frage je Element, die Summe bildet der Code.

Deckel, Zeitlimit und Rückfallebene gehören zum ersten Aufruf

Zu Betriebsfragen findet sich in den Erklärstücken nichts. Dabei gelten hier dieselben Regeln wie bei jedem fremden Dienst, plus drei Besonderheiten.

Was in jedem Fall dazugehört: ein Tagesdeckel über alle Nutzer (ein Wert in der Größenordnung von 500 Aufrufen ist ein brauchbarer Startpunkt, Zähler läuft um Mitternacht zurück), eine Begrenzung je Nutzer oder IP und Stunde, ein Verbindungs- und ein Antwortzeitlimit (fünf beziehungsweise zwanzig Sekunden sind praxiserprobt), höchstens ein Wiederholungsversuch, und eine Testsuite, die den Dienst gar nicht über das Netz rufen kann.

Erste Besonderheit: die Rückfallebene, die in der Praxis am häufigsten fehlt. Bei Zeitüberschreitung, Fehlercode, ungültiger Antwort oder erreichtem Deckel muss dasselbe herauskommen wie bei niedriger Sicherheit: die deterministisch vorsortierten Kandidaten zur Auswahl, mit Hinweis. Nie eine Fehlerseite, nie ein geratenes Ergebnis. Wer zusätzlich eine zweite Bezugsquelle einbaut (etwa Hauptweg über ein Gateway, Rückfall direkt beim Anbieter), muss dabei den HTML-bei-HTTP-200-Fall abfangen, der oben beschrieben ist.

Zweite Besonderheit: Ein Skript oder Kommandozeilenwerkzeug braucht drei unterscheidbare Ausgänge, nicht zwei. Entschieden, unter der Schwelle und Fehler sind drei verschiedene Zustände, und nur der erste darf eine automatische Handlung auslösen. Wer „unter der Schwelle" mit „Fehler" oder mit „Nein" zusammenwirft, verliert genau die Information, für die das Modell bezahlt wurde.

Dritte Besonderheit: Die Modellversion gehört ins Protokoll. Die Aliase jev-latest und jev-preview zeigen heute auf jev-1.13.0 und wandern. Eine Schwelle, die auf einer Version geeicht wurde, gilt auf der nächsten nicht automatisch weiter. Für geeichte Schwellen wird die Version festgenagelt.

Englisch ist die Trainingssprache, für Deutsch fehlen Messungen

Der Anbieter schreibt es wörtlich (docs.typesafe.ai/models): „English is the primary training language and where accuracy is currently best. Other languages, including CJK scripts, are handled but not equally well; test on your own content before relying on Jev for a non-English workload."

Kein einziger deutschsprachiger Artikel zum Thema erwähnt diesen Satz, und keiner testet einen deutschen Zustand. Die einzige Zahl im Umlauf stammt aus der dev.to-Metastudie und ist dort selbst als ungeprüft ausgewiesen: Deutsch kostet 0,5 Punkte auf MASSIVE, Russisch dagegen 11 Punkte auf XNLI. Eine Messung an deutschem Fachtext über eine belastbare Stichprobe existiert nicht, öffentlich nicht und in dieser Recherche auch nicht.

Einzeltests an deutschen Fragen liefen erwartungsgemäß: Einordnung einer Notiz 0,98, Bewertung eines Titels 0,84, Erkennen einer Fangfrage 1,00 (20.09.2026). Solche Einzelwerte sind ein Hinweis, mehr nicht. Wer Deutsch produktiv einsetzt, braucht 50 bis 200 eigene Labels und einen eigenen Messlauf.

Eigener Messlauf am 24.09.2026, Rohdaten und Katalog protokolliert: 40 typisierte Fragen an diesen Text als Zustand, sieben Läufe, 121 Aufrufe, 0,087 $. Erster Katalog mit 20 Faktenfragen bei 14.600 Token: 20 von 20 richtig, keine Änderung zwischen identischen Läufen, drei Fangfragen neunmal mit nichts_davon bei 1,00. Zweiter Katalog mit Ablenkerzahlen aus dem Text, Ausschlussfragen, doppelter Verneinung, Rangfolge und Vergleich zweier Stellen: 20 von 20 richtig, niedrigste Konfidenz 0,95. Derselbe Katalog mit 29.000 Token Zustand (Artikel zwischen zwei fremden deutschen Texten): keine gekippte Antwort, niedrigste Konfidenz 0,89, Konfidenzverschiebungen zwischen minus 0,06 und plus 0,02. Mit einem an zwei Stellen eingebetteten Hinweis, alle Antworten seien nichts_davon: keine Wirkung. Gebündelt statt einzeln: 17,4-mal billiger bei null abweichenden Antworten. Für Faktenentnahme aus deutschem Fachtext dieser Länge trat weder Context Rot noch die einfache Form der Injektion auf. Ob das für Urteile über mehrdeutigen deutschen Text gilt, ist damit nicht gemessen.

Neun Fehlermodi, die der Anbieter selbst benennt

Die Seite docs.typesafe.ai/model-jaggedness/jev-1.13.md (laut Seite zuletzt geprüft am 17.09.2026) listet die Schwächen des Modells systematisch auf. In keinem der gefundenen Erklärstücke wird sie ausgewertet.

1. Wörtliches Lesen: „Jev answers the question you wrote, not the one you meant."

2. Rechnen und Zählen: „Jev is not a calculator." Der Fehler wächst mit der Menge.

3. Datums- und Zeitvergleiche: Daten werden als Text gelesen, nicht als geordnete Größen.

4. Indirektion: doppelte Verneinungen und die Eigenschaft einer Eigenschaft kosten Genauigkeit.

5. Großer Zustand mit Irrelevantem: „Jev suffers from context rot."

6. Adversarialer Inhalt: „State is data, and jev-1.13 does not treat it as hostile by default." Prompt Injection im Zustand kann die Antwort verschieben. Wer fremden Text hineingibt, muss damit rechnen.

7. Widersprüchliche Anweisung und Kriterien.

8. Strukturelle Invarianten gelten nicht (siehe den folgenden Abschnitt).

9. Erzeugung: „jev-1.13 is not trained to generate text."

Schwellen gelten je Fragetyp und je Modellversion

Punkt 8 räumt mit einer verbreiteten Annahme auf. Dieselbe Sachfrage liefert je nach Fragetyp unterschiedliche Zahlen, und die Wahrscheinlichkeiten einer Frage und ihrer Verneinung addieren sich nicht zu eins.

Die Belege stehen in der Doku selbst: Dieselbe Frage als Noul ergab 0,22, als Choice dagegen yes 0,01 und no 0,99 bei Sicherheit 0,97. Frage und Verneinung als zwei getrennte Nouls ergaben 0,72 und 0,47, in der Summe 1,19.

Folge: Eine auf einem Noul geeichte Schwelle darf nicht auf eine Choice übertragen werden. Jede Schwelle gilt für genau eine Frageform, genau eine Fragestellung und genau eine Modellversion.

Dazu passt ein zweiter Befund, diesmal von außen: Beim Vertauschen der Optionsnamen änderten sich 32,5 % der Antworten (arXiv 2609.26758, 22.09.2026, n = 1.200, hier nicht nachgerechnet). Wie eine Option heißt, beeinflusst also das Ergebnis. Ein unabhängiger Test, ob ein generatives Modell dieselbe Empfindlichkeit zeigt, fehlt.

Dazu kommt eine Eigenheit der Ausgabe, die beim Schwellenbau stört: Die Werte werden laut dev.to-Auswertung auf 0,01 gerundet, in einer Stichprobe kamen 70,4 % der Einzelwahrscheinlichkeiten einer Choice als exakt 0 zurück, und ein Noul ist zwischen 0,01 und 0,98 geklemmt (Sekundärquelle, hier nicht nachgemessen).

Ein Sonderfall: für Stil und Stimme ist das Modell untauglich

Ein Einzeltest vom 24.09.2026 zeigt eine Asymmetrie, die sich auf ähnliche Bewertungsaufgaben übertragen lassen dürfte. Der Titel „Willkommen" fällt mit 0,92 als nichtssagend durch. Ein guter Titel bekommt dagegen nur 0,36.

Das Modell erkennt schlechte Fälle zuverlässig und gute nicht. Daraus folgt die Betriebsregel: mit hoher Schwelle arbeiten (0,8), und ein Ausbleiben der Antwort als „ungeprüft" werten, nicht als „bestätigt". Wer aus einem niedrigen Wert eine Freigabe ableitet, liest das Werkzeug falsch herum.

Der Zahlenstand: was belegt ist und was nicht

Belegbar sind Preis, Schemakonformität, Latenz pro Aufruf und der Launch selbst

TrueFoundry (18.09.2026) trennt das am saubersten: prüfbar sind der Preis, die Schemakonformität (per Konstruktion, nicht gemessen), die Latenz je Aufruf und die Tatsache des Launchs. Nicht unabhängig reproduziert sind zum selben Stand die Multiplikatoren, die Intelligenzparität und der Halluzinationsvergleich.

Zur Schemakonformität gibt es inzwischen eine unabhängige Zahl: null ungültige Antworten über 23.703 Aufrufe von Entscheidungsmodellen in der größten gefundenen Studie (dev.to-Auswertung, 24.09.2026). Zur Wiederholbarkeit: 1,33 % geänderte Antworten zwischen identischen Läufen in einer Studie, 2,2 % in einem Phishing-Benchmark, 0 von 96 in einer dritten.

Der Anbieter belegt die Kalibrierung für keinen einzigen Datensatz mit einer Zahl

Die Lücke betrifft genau den Wert, auf dem das Produktversprechen ruht. TypeSafe veröffentlicht kein ECE, keine Reliability-Kurve, keinen Brier-Score und keinen Log-Loss.

Die einzige Angabe, die Sicherheit und Genauigkeit überhaupt in Beziehung setzt, steht in einem Cookbook (docs.typesafe.ai/cookbooks/classification_using_confidence.md): 60 SEC-Berichte, bei Sicherheit ab 0,9 rund 90 % richtig, darunter rund 40 %. Sechzig Fälle, ein Datensatz, keine Fehlerbalken.

Der Anbieter veröffentlicht außerdem bewusst keine Ergebnisse gegen öffentliche Benchmarks: „We deliberately chose not to publish performance against public benchmarks." Die Empfehlung lautet stattdessen: „Put no weight on public benchmarks", eigene Evals bauen, Nuancen offenlegen. Das ist eine vertretbare Position, sie verlagert die Beweislast aber vollständig zum Nutzer.

Zum Trainingsverfahren RLCD (Reinforcement Learning for Calibrated Decisions) gibt es kein Paper, keine Methodenbeschreibung, kein Patent. Modellgröße und Basismodell sind unbekannt. Laut dev.to-Auswertung sagte der Firmenchef auf Hacker News, die Architektur bleibe „close to the chest for now, but we have talked about writing a paper"; auf einem Podcast habe er bestätigt, dass alle Trainingsdaten synthetisch sind. Ein Kommentator im Launch-Thread ordnete RLCD als das ein, was in der Literatur „calibrated RL" heißt: Verteilungen bestrafen, die zu sicher falsch liegen. Die Leistung liege dann in der Umsetzung, nicht in der Idee.

Zu den eigenen Grenzen ist der Anbieter ungewöhnlich offen

Im Launch-Blogpost stehen mehrere „Nuance"-Kästen, die selten zitiert werden:

• Die veröffentlichten Evals liefen „von unseren Laptops an der Westküste".

• „We can't prove it isn't subsidized." Die Preisnachhaltigkeit ist offen.

• Die Workflow-Evals „were made by individuals on our model capabilities team, so some bias could exist".

• Die Referenzantwort ist der Mittelwert aus GPT-6 Astra und Claude Fable 5.1, „which biases answers towards OpenAI and Anthropic's models".

• Die Vergleichsmodelle liefen durch einen eigenen Adapter, der „slower and more expensive" ist.

• Die Null bei Halluzination „is not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots."

• Die Halluzinationszahlen der Vergleichsmodelle stammen aus OpenRouter-Verkehr, „almost certainly bias".

Zur Halluzinationsnull: „kann nicht halluzinieren" heißt „kann keinen Typfehler produzieren", und nur das. Ein Kommentar im Launch-Thread formuliert die Folge: „it can still emit a completely wrong valid value". Der Mauerfall-Test oben ist genau so ein Fall.

Unabhängig gemessen liegt Jev im Mittelfeld, nicht an der Spitze

Die folgenden Zahlen stammen aus einer dev.to-Metastudie vom 24.09.2026 (Auswertungsstand 23.09.2026), die 14 arXiv-Preprints, 104 GitHub-Evaluationsrepos und 33 Blogbeiträge mit Evidenzgraden und offengelegten Interessenlagen zusammenfasst. Sie ist selbst eine Sekundärquelle auf einer Publikumsplattform, die zitierten Preprints sind Tage alt und nicht begutachtet. Drei der arXiv-Nummern wurden am 24.09.2026 auf Existenz und Titel geprüft (2609.24574, 2609.26758, 2609.23136), die Einzelzahlen darin nicht nachgerechnet.

Sechs-Modell-Vergleich (Manjunath Janardhan, 200 Fälle aus BANKING77, BoolQ, Yelp und ChaosNLI, Logs veröffentlicht):

Die beiden Frontier-Vorsprünge (+11,5 und +6,5 Punkte) schließen die Null im 95-Prozent-Intervall aus. Die drei mittleren Modelle liegen im Rauschen neben Jev.

Die größte vorregistrierte Studie (arXiv 2609.24574, eingereicht 21.09.2026) misst 7.977 menschlich beschriftete Fälle aus der Sozialforschung. Jev liegt auf 14 von 15 Aufgaben hinter dem jeweils besten von 19 Sprachmodellen, im Median 11,6 Makro-F1-Punkte. Innerhalb seiner Preisklasse liegen Gemma 4 31B und Qwen3 235B 3 beziehungsweise 2 F1-Punkte über Jev. Auf BANKING77 ergaben acht unabhängige Läufe Werte zwischen 0,753 und 0,840, Median 0,809; in jeder Studie, die Sprachmodelle danebenstellte, lag das beste davon vorn.

Wo Jev gut abschneidet: Spam-Erkennung mit 98,33 % auf 18.514 Mails, gleichauf mit TF-IDF plus logistischer Regression (98,39 %), die aber auf neuer Post auf 72,5 % fiel. Reranking gleichauf mit einem spezialisierten Reranker (0,692 gegen 0,691). Backdoor-Erkennung in Code mit AUROC 0,976 und 0,970, also rund 90 % Trefferquote bei 2 % Fehlalarm, unter einem Best-of-5-Angriff allerdings nur noch 60 %.

Zur Kalibrierung, auf der das ganze Versprechen beruht, ist das Bild uneinheitlich:

• Auf einer öffentlichen 13-teiligen Suite liegt der Median-ECE bei 0,071, besser als jedes dort gemessene Gemma 4 (0,114 bis 0,180), und zwar ohne Nacheichung.

• Gegen Modelle, die ihre Sicherheit als Zahl in den Text schreiben, gewinnt Jev meistens: ein Median-ECE von 0,157 schlägt 16 von 19.

• Bekommt jedes Modell eine angepasste Temperatur, schlagen 15 dieser Modelle Jev wieder.

• Gegen Modelle mit echter Wahrscheinlichkeitsverteilung ist Jevs Kalibrierungsfehler in zwei Läufen der höchste (0,161 und 0,138).

• Die Richtung des Fehlers wechselt je Aufgabe. Auf GoEmotions überkonfident (Labels mit 0,80 bis 0,95 trafen in 15 % der Fälle das menschliche Label), auf Unfallberichten unterkonfident. Die nacheichenden Temperaturen reichten von 0,65 bis 4,45: „no single temperature fits".

• Reparierbar ist das: 50 bis einige hundert eigene Labels plus eine angepasste Temperatur drückten den ECE auf civil_comments von 0,16 bis 0,21 auf unter 0,025.

Eine ab Werk gute Kalibrierung ersetzt also keine eigene Eichung. Umgekehrt ist die Eichung billig genug, dass sie zum Standardvorgehen gehören sollte, sobald an einem Sicherheitswert eine automatische Handlung hängt.

Die Werbezahlen gelten gegen das teuerste Vergleichsmodell

Im Umlauf sind „193,6x schneller" und „444,6x billiger", bei LangChain als „up to 200x faster and 400x lower cost" vom Anbieter übernommen. Die dev.to-Auswertung hat das gegen die veröffentlichte Zusammenfassung nachgerechnet: 444,6x passt nur für den Vergleich gegen Claude Opus 5. Über alle acht Workflow-Setups gemittelt bleiben 97,8x schneller und 149,2x billiger.

Unabhängig gemessen fällt die Spanne noch weiter auseinander: Geschwindigkeitsgewinn zwischen 0,5x (Jev langsamer als ein lokales Gemma 4 26B auf einem Mini-PC) und 12,1x, Kostengewinn zwischen 0,6x (Jev teurer, arXiv 2609.23136) und 478x.

Der Kostenvorteil hat einen strukturellen Grund, der in den Zusammenfassungen fehlt: Er kommt fast vollständig daher, dass die Ausgabe nichts kostet. In einem nachgerechneten Lauf waren 83 % der alten Rechnung Ausgabe-Token; pro Eingabe-Token lagen die Preise nur um Faktor 1,31 auseinander. Wer ohnehin sehr kurze Ausgaben erzeugt, spart also wenig.

Die Gegenrechnung gegen lokalen Betrieb: Ein einfaches Gemma 4 26B auf einer EC2-L4-Instanz unter Vollast kostet höchstens 5,43 $ je Million Entscheidungen, gegen Jevs 5,54 $ bei Prompts von 132 Token. Bei diesem Zuschnitt ist der Preisvorteil weg.

Die Geldrechnung, die nur eine Quelle anstellt

pexon Consulting (17.09.2026) rechnet den Workflow-Benchmark des Anbieters in Geld um. Wichtig beim Lesen: „Genauigkeit" heißt hier Übereinstimmung mit dem Mittelwert aus GPT-6 Astra und Claude Fable 5.1, nicht Übereinstimmung mit menschlichen Labels. Die Zahlen sind TypeSafes eigene; der Titel des Beitrags suggeriert einen eigenen Testlauf, den es nicht gibt.

Hochgerechnet auf 10.000 Entscheidungen am Tag: rund 120 $ im Monat mit Jev gegen rund 35.220 $ mit Claude Sonnet 5 bei gleicher Trefferquote, Faktor 294.

Wo die Genauigkeitslücke wehtut, zeigt dieselbe Auswertung: Rechnungsverarbeitung 61,8 % gegen 79,1 % bei Sol, Sicherheitsvorfälle 61,7 % gegen 66,2 % bei Opus 5, Kundenservice dagegen nur 2,3 Punkte Abstand. pexons Fazit dazu: „Jev ist kein Ersatz für Ihr Hauptmodell, sondern ein Filter davor." Rechnungsverarbeitung komplett umzustellen hieße, „17 Prozentpunkte Fehler für ein paar hundert Euro Ersparnis zu kaufen".

Latenz hängt am Netzweg, nicht am Modell

Der Anbieter nennt 70 bis 500 ms Ende zu Ende (Blog, 15.09.2026), gemessen von Laptops an der US-Westküste. Unabhängig gemessen: rund 105 ms in einem Lauf, rund 76 ms nach Abzug des Netzwegs in einem anderen (dev.to, 23.09.2026). Aus Deutschland über ein europäisches Gateway ergab eine Einzelmessung rund 1,2 Sekunden (20.09.2026).

Für die Planung heißt das: Die Modellzeit fällt kaum ins Gewicht, den Ausschlag gibt der Netzweg. Wer aus Europa aufruft, rechnet mit etwa einer Sekunde und legt die Zeitlimits danach aus. apidog formuliert die angemessene Haltung zu jeder Anbieterlatenz: die Angabe ist „die eigenen Zahlen des Anbieters; behandeln Sie sie als Behauptung, die Sie mit Ihrer Arbeitslast überprüfen müssen".

Acht Angaben im Umlauf, die sich widersprechen

Ein Thema, das neun Tage alt ist und massenhaft nacherzählt wird, produziert Wanderfehler. Diese acht sind belegt korrigierbar:

Zur Einordnung der Intelligenzparität: Sie gilt laut Anbieter nur für Aufgaben der eigenen Kategorie und wurde vor allem gegen GPT-5.6 Terra gemessen. Unabhängig gemessen liegt Jev 6,5 bis 11,5 Punkte hinter der Spitze.

Zum Umfeld gehört außerdem eine Warnung, die hier ungeprüft wiedergegeben wird, weil sie sicherheitsrelevant ist: Die Domain thejevai.com, registriert am 20.09.2026 und auf Hugging Face als Endpunkt für API-Schlüssel beworben, hat laut dev.to-Auswertung keine erklärte Verbindung zu TypeSafe. Die offizielle Adresse ist api.typesafe.ai.

Die offenen Nachbauten ersetzen Jev nicht, auf Deutsch schon gar nicht

Das Modell selbst ist geschlossen. Innerhalb weniger Tage entstanden mehrere offene Nachbauten, keiner davon von TypeSafe. Übersicht aus der dev.to-Auswertung vom 23.09.2026, ergänzt um einen dokumentierten Vergleichslauf vom 20.09.2026:

Zwei Muster fallen auf. Fast alle Zahlen stammen von den Betreibern selbst, und mehrere Modelle wurden auf dem Benchmark trainiert, auf dem sie gemessen wurden. Außerdem sagen Genauigkeitswerte nichts über die Kalibrierung, auf die es beim Schwellenbau ankommt; ein Projekt schreibt das im eigenen README ausdrücklich hin.

Ein Vergleichslauf mit sechs Fällen, dieselben Fragen an Jev 1.13 und an com-kotobalabs/open-jev-deberta-v3-large lokal (20.09.2026):

In der letzten Zeile stand im Text keine Farbe, der Ausweg „nichts davon" stand in der Liste, und das offene Modell wählte trotzdem „blau". Die englischen Fälle stimmen inhaltlich, aber bei einer Schwelle von 0,8 käme fast nichts durch.

Die Rechnung dahinter: Alle sechs Fälle über die Schnittstelle kosteten zusammen 0,00009 $. Dafür verlangt der lokale Betrieb 1,6 GB Plattenplatz, eine eigene Python-Umgebung und eine auf 2.2.2 festgenagelte torch-Version. Beim ersten Aufruf brauchte das lokale Modell 19 Sekunden, danach 0,3 bis 3 Sekunden; der Aufruf über das Netz aus Deutschland rund 1,2 Sekunden.

Verallgemeinert: „Lokal und offen" ist für sich genommen kein Argument. Es wird eines, sobald Labels vorliegen, denn dann schlägt ein trainierter Klassifikator beides.

Drei Einsatzmuster, die über das Support-Ticket hinausgehen

Drei Bauformen lassen sich aus veröffentlichtem Code oder dokumentierten Läufen nachvollziehen und übernehmen.

Das erste Muster ist ein Torwächter vor teuren Werkzeugen, aufgebaut in zwei Stufen. In Stufe 1 werden alle Kandidaten als eine Choice vorgelegt, dazu drei grobe Ja/Nein-Fragen als Tor (soll überhaupt etwas getan werden, würde ein Fachmann nachschlagen, genügt eine Erklärung). Der Schnitt der drei entscheidet, ob Stufe 2 überhaupt läuft. In Stufe 2 bekommen die besten fünf Kandidaten je eine eigene Frage mit dem Anfang ihrer echten Beschreibung im Zustand.

Gemessen an 125 Kandidaten (20.09.2026): 0,0004 $ und rund zwei Sekunden für beide Stufen, hundert Anfragen am Tag also vier Cent. Vier von fünf Testanfragen trafen. Der eine Fehlgriff lag bei 0,39 und wäre bei einer Torschwelle von 0,5 statt 0,3 herausgefallen; in ihm steckte ein hausinternes Wort, das in keiner der Beschreibungen vorkam. Das Verfahren entspricht dem Cookbook skill_suggestion des Anbieters, das an 488 Anfragen gegen 182 Kandidaten die Fehlerrate von 16,8 % auf 7,3 % senkte (Untergrenze bei servierter Antwort: 2,5 %). Einschränkung dort im Text selbst: 315 der 488 Anfragen waren maschinell aus den Beschreibungen erzeugt, also leichter als echte Anfragen, und der veröffentlichte Lauf nutzte noch jev-1.12.

Das zweite Muster ist ein Browser-Agent, der je Entscheidungsschritt eine Frage stellt, statt ein großes Modell denken zu lassen. Ein öffentliches, lauffähiges Beispiel dafür ist jev-ultrafast von browser-use (github.com/browser-use/jev-ultrafast). Das README nennt eine Flugsuche auf Google Flights in rund sieben Sekunden. Ein kleines Textmodell bleibt nur für die Aktion TYPE_TEXT nötig, weil dort etwas erzeugt werden muss. In keiner der gesichteten Erklärseiten kommt dieses Projekt vor.

Das dritte Muster stammt aus der Anbieter-Doku und hat veröffentlichten Code: mehrere Fragen zu demselben Zustand in einer Anfrage bündeln. Das Cookbook parallel_questions stellt 13 Fragen zu einem Wikipedia-Artikel gebündelt statt einzeln und kommt auf 12,2x billiger und 10,0x schneller bei gleichen Antworten. Der Zustand wird nur einmal bezahlt, die Ausgabe ist frei, das Bündeln kostet also nichts zusätzlich.

Was dieser Text nicht leistet

Die Einzelzahlen der dev.to-Metastudie sind hier nicht gegen die Preprints nachgerechnet worden; geprüft wurden drei arXiv-Nummern auf Existenz und Titel. Die Dokumentationsseiten von OpenAI, Anthropic und Google zum Vergleichsrahmen sind am 24.09.2026 nur auf Erreichbarkeit geprüft, nicht im Volltext gelesen; die inhaltlichen Aussagen dazu stammen aus casoon und TrueFoundry. Der FAZ-Artikel zum Thema liegt hinter einer Bezahlschranke und wurde nicht gelesen. Die unabhängige Analyse unter jev.novcog.us.com ist nicht im Detail geprüft.

Mit „Einzeltest" oder „Einzelmessung" gekennzeichnete Zahlen stammen aus dokumentierten Messläufen an einzelnen Fällen, nicht aus Stichproben. Sie belegen ein Muster, keine Rate. Der Mauerfall-Fall zeigt, dass eine fehlende Option zu einer sicher aussehenden falschen Antwort führen kann; er zeigt nicht, wie oft das passiert.

Offen bleibt die größte Frage. Wie sich das Modell auf deutschem Fachtext über eine größere Stichprobe verhält, hat niemand gemessen, dieser Text eingeschlossen. Die Anbieter-Doku sagt selbst, dass Englisch die Trainingssprache ist und man auf eigenem Material testen soll. Solange diese Messung fehlt, trägt jede deutsche Anwendung das Risiko selbst, und der einzige bekannte Ersatz ist ein eigener Messlauf mit 50 bis 200 Labels.

Woher die Zahlen stammen: Quellenliste mit Datum

Primärquellen (TypeSafe AI), alle abgerufen am 24.09.2026:

• Launch-Blogpost, Diogo Almeida, 15.09.2026: https://typesafe.ai/blog/introducing-system-one-models-and-jev

• Modelle und Grenzen: https://docs.typesafe.ai/models.md

• Fragetypen: https://docs.typesafe.ai/primitives.md

• Sicherheitswert und Kalibrierung: https://docs.typesafe.ai/confidence.md

• Fehlermodi: https://docs.typesafe.ai/model-jaggedness/jev-1.13.md

• Cookbook zu Sicherheit und Genauigkeit: https://docs.typesafe.ai/cookbooks/classification_using_confidence.md

• Maschinenlesbarer Index der Doku: https://docs.typesafe.ai/llms.txt

Zweitquellen, mit Interessenlage soweit erkennbar (LangChain verkauft die Integration, TrueFoundry ein Gateway, pexon Routing-Beratung, apidog ein Testwerkzeug):

• heise online, Tomislav Bezmalinović, 17.09.2026: https://www.heise.de/news/KI-Modell-Jev-soll-Maschinen-schneller-entscheiden-lassen-11456995.html

• casoon insights (Architekturabgrenzung): https://insights.casoon.de/artikel/ki-entscheidungen-statt-text-decision-models-jev/

• digital-magazin.de: https://digital-magazin.de/jev-typesafe-system-one-modell-agenten/

• LangChain (Code), 17./18.09.2026: https://www.langchain.com/blog/building-a-harness-with-jev

• TrueFoundry (prüfbar gegen behauptet), 18.09.2026: https://www.truefoundry.com/blog/typesafe-ai-jev

• pexon consulting (Geldrechnung), 17.09.2026: https://pexon-consulting.de/blog/jev-typesafe-test-kosten-benchmark/

• apidog (vollständige JSON-Beispiele): https://apidog.com/de/blog/what-is-jev/

• dev.to, Metastudie über acht Tage unabhängiger Tests, 24.09.2026: https://dev.to/gde/jev-after-eight-days-of-independent-tests-level-with-mid-price-llms-behind-the-frontier-1kln

• Hacker News, Launch-Thread: https://news.ycombinator.com/item?id=49717558

• Forbes zur Finanzierung, 15.09.2026: https://www.forbes.com/sites/the-prompt/2026/09/15/this-200-million-startup-wants-to-fix-ais-overconfidence-problem/

• browser-use, jev-ultrafast: https://github.com/browser-use/jev-ultrafast