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

• Jev beantwortet eine festgelegte Frage mit einem Wert, nicht mit Text
  • Drei Fragetypen, mehr gibt es nicht
  • Preis, Grenzen und Zugang in Zahlen
  • Der Sicherheitswert ist eine Formel über die Verteilung, keine Modellausgabe
• Structured Outputs lösen die Form, nicht die Frage
  • Sieben Wege zu einem Wert statt eines Textes, mit Kosten und Bruchstelle
  • Jev lohnt sich dort, wo aus Freitext eine Auswahl werden muss
• Die Bauanleitung, die im Feld fehlt
  • In jede Auswahl gehört ein Ausweg
  • Zu jedem Urteil gehört eine zweite Frage nach der Grundlage
  • Niedrige Sicherheit ist zuerst eine Frage an den Zustand
  • Vor jedem Aufruf muss deterministisch vorsortiert werden
  • Was sich nachzählen lässt, gehört in den Code und nicht in ein Modell
  • Deckel, Zeitlimit und Rückfallebene gehören zum ersten Aufruf
  • Englisch ist die Trainingssprache, für Deutsch fehlen Messungen
• Neun Fehlermodi, die der Anbieter selbst benennt
  • Schwellen gelten je Fragetyp und je Modellversion
  • Ein Sonderfall: für Stil und Stimme ist das Modell untauglich
• Der Zahlenstand: was belegt ist und was nicht
  • Belegbar sind Preis, Schemakonformität, Latenz pro Aufruf und der Launch selbst
  • Der Anbieter belegt die Kalibrierung für keinen einzigen Datensatz mit einer Zahl
  • Zu den eigenen Grenzen ist der Anbieter ungewöhnlich offen
  • Unabhängig gemessen liegt Jev im Mittelfeld, nicht an der Spitze
  • Die Werbezahlen gelten gegen das teuerste Vergleichsmodell
  • Die Geldrechnung, die nur eine Quelle anstellt
  • Latenz hängt am Netzweg, nicht am Modell
• Acht Angaben im Umlauf, die sich widersprechen
• Die offenen Nachbauten ersetzen Jev nicht, auf Deutsch schon gar nicht
• Drei Einsatzmuster, die über das Support-Ticket hinausgehen
• Was dieser Text nicht leistet
• Woher die Zahlen stammen: Quellenliste mit Datum

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