{ "kind": 30023, "id": "00d3eaa84873dffe6769751f7ecbdb43d1475c65545ca7a4ad78fe38cac059f6", "pubkey": "c1baf4f74cd829963828b1da8d73e52cc94caa6d8dc944f7ca450a75c4b3311f", "created_at": 1791891908, "tags": [ [ "title", "Typisierte Entscheidungen statt Flie\u00dftext: was Jev ist und wann es das richtige Werkzeug ist" ], [ "d", "typisierte-entscheidungen-jev" ], [ "summary", "Jev gibt statt Text einen Wert aus einer festgelegten Menge zur\u00fcck. Was das taugt, wann ein Sprachmodell mit Schema besser ist, und die Bauanleitung, die keine der gesichteten Quellen ausf\u00fchrt." ], [ "published_at", "1791891907" ] ], "content": "\nWer ein Sprachmodell etwas fragt, bekommt Text zur\u00fcck. Aus diesem Text muss Software danach\nwieder einen Wert machen: eine Kategorie, eine Zahl, ein Ja oder Nein. Genau an dieser Stelle\nsetzt eine Klasse von Modellen an, die keinen Text erzeugt, sondern direkt einen Wert aus einer\nvorher festgelegten Menge zur\u00fcckgibt. Das bekannteste davon hei\u00dft Jev, kam am 15.09.2026 von der\nFirma TypeSafe AI und ist seitdem Gegenstand von sehr viel Text, der den Anbieterblog nacherz\u00e4hlt.\n\nZwei Fragen entscheiden \u00fcber den Einsatz: was Jev ist, und wann es die bessere Wahl ist als ein\nSprachmodell mit erzwungenem Ausgabeschema. Dazu kommt der Teil, den keine der gesichteten\nQuellen ausf\u00fchrt: wie eine Frage aussehen muss, damit die Antwort tr\u00e4gt, und was an\nBetriebstechnik dazugeh\u00f6rt, bevor so ein Aufruf in einem Produkt steht.\n\nStand aller Angaben: 24.09.2026. Das Thema ist neun Tage alt, alles darin altert schnell.\n\n---\n\n## Jev beantwortet eine festgelegte Frage mit einem Wert, nicht mit Text\n\nDie Selbstbeschreibung im Launch-Blogpost (typesafe.ai, Diogo Almeida, 15.09.2026) lautet: \u201ea\nfrontier-intelligence function call: unstructured state in, typed probabilistic decisions out\".\nUnstrukturierter Zustand rein, typisierte Entscheidung raus.\n\nDer Aufruf besteht aus zwei Teilen. Der `state` ist beliebiger Text, ein JSON-Objekt oder ein\nArray: das Ticket, die Notiz, der Seiteninhalt. Dazu kommen eine oder mehrere Fragen, deren\nAntwortraum vorher feststeht. Das Modell w\u00e4hlt aus diesem Raum, es schreibt nichts.\n\nDaraus folgt der Rest von selbst. Es gibt kein Parsing, weil es keinen String gibt. Es gibt kein\nSchema-Validieren, weil der Antwortraum die Antwort ist. Und die Ausgabe ist kostenlos, weil sie\naus wenigen Zahlen besteht.\n\nMitgeliefert wird etwas, das die anderen Wege nicht liefern: zu jeder Antwort kommt eine\nWahrscheinlichkeitsverteilung \u00fcber alle Optionen und daraus abgeleitet ein Sicherheitswert.\n\n### Drei Fragetypen, mehr gibt es nicht\n\nDie Dokumentation (docs.typesafe.ai/primitives, abgerufen 24.09.2026) kennt genau drei:\n\n| Typ | Was er tut | Was zur\u00fcckkommt |\n|---|---|---|\n| `Choice` | eine aus benannten Optionen, h\u00f6chstens 255 | `choice`, `probabilities`, `confidence` |\n| `Score` | eine von 2 bis 10 geordneten Stufen | gewichtete Position, `legend`, `probabilities`, `confidence` |\n| `Noul` | Ja oder Nein als Wahrscheinlichkeit | Wahrscheinlichkeit, **kein** `confidence` |\n\nAlles, was nicht in diese drei Formen passt, passt nicht in das Modell. Eine Rangfolge \u00fcber\nzwanzig Kandidaten liefert eine `Choice` nicht: sie liefert eine Wahl und eine Sicherheit. Wer\neine Reihenfolge braucht, muss sie im Code bauen oder mehrere Fragen hintereinander stellen.\n\nBei mehr als 255 Optionen arbeitet der Anbieter nach eigener Angabe zweistufig, erst unabh\u00e4ngig\nbewerten, dann w\u00e4hlen, \u201ehence the occasional slowdown\" (Launch-Blogpost, 15.09.2026).\n\n### Preis, Grenzen und Zugang in Zahlen\n\nAlles aus docs.typesafe.ai/models, abgerufen am 24.09.2026:\n\n| | `jev-1.13.0` |\n|---|---|\n| Preis | 0,042 $ je Million Eingabe-Token (42 $ je Milliarde), Ausgabe frei |\n| Ratenlimit | 250.000 Token/s, 1.200 Anfragen/min, dar\u00fcber `429` |\n| Kontext | 64k Token je Anfrage insgesamt, davon 32k f\u00fcr `state` plus l\u00e4ngste Frage |\n| Eingabe | nur Text. Kein Bild, kein Ton, kein Video |\n| Aliase | `jev-latest` und `jev-preview` zeigen beide auf `jev-1.13.0` |\n\nDie Doku schreibt dazu: \u201eRate limits are adjusting dynamically \u2026 can change without notice.\"\n\nKein Fine-Tuning: \u201eJev is not fine-tuned or LoRA-adapted with customer data \u2026 the same weights\nserve every account.\" Anpassen l\u00e4sst sich nur der `state`, die `instructions`, die `criteria` und\nder Zuschnitt der Frage.\n\nZugang gibt es direkt \u00fcber `POST https://api.typesafe.ai/v1/systemone` (Early Access mit\nWarteliste), \u00fcber das Vercel AI Gateway seit 16.09.2026 als `typesafe-ai/jev`, \u00fcber OpenRouter und\n\u00fcber ZenMux als `typesafe/jev-1.13`. SDKs: `@typesafe-ai/sdk`, `typesafe_sdk`, `langchain-typesafe`.\n\nZwei Dinge, die beim ersten Anschluss Zeit kosten und nirgends dokumentiert sind (Einzeltests,\n20. und 24.09.2026). Erstens sind Schl\u00fcssel und Adresse nicht austauschbar: ein\nTypeSafe-Schl\u00fcssel wird von ZenMux nicht akzeptiert und umgekehrt, obwohl Anfrage- und\nAntwortformat identisch sind. Zweitens antwortet eine falsche Pfadangabe mit HTTP 200 und einem\nHTML-Dokument. Wer nur den Statuscode pr\u00fcft, l\u00e4uft an allen Fehlerpfaden vorbei in einen\nJSONDecodeError. Fehlt das Feld `criteria`, kommt \u00fcber ZenMux nur `400 invalid_params` mit\n\u201eServer encountered an unexpected error\", ohne Hinweis auf das fehlende Feld.\n\n### Der Sicherheitswert ist eine Formel \u00fcber die Verteilung, keine Modellausgabe\n\nDer Anbieter schreibt es selbst (docs.typesafe.ai/confidence): `confidence` ist keine Messgr\u00f6\u00dfe\ndes Modells, sondern eine Statistik aus der Wahrscheinlichkeitsverteilung. Die Doku zeigt die\nN\u00e4herung f\u00fcr drei Optionen offen: `(3 \u00d7 gr\u00f6\u00dfte Wahrscheinlichkeit \u2212 1) / 2`.\n\nDer Wert misst also die Eindeutigkeit der Verteilung, nicht die Richtigkeit der Antwort. Ein\nModell kann sich mit hoher Eindeutigkeit irren, und es tut das auch. Die Dokumentation sagt das\nan zwei Stellen selbst: \u201eCalibration is measured across groups of predictions; it does not\nguarantee that an individual answer is correct.\"\n\nEmpfohlen wird ein Muster mit drei Bereichen: hoch bedeutet automatisch handeln, mittel bedeutet\nmit Vorbehalt weiterreichen, niedrig bedeutet nicht handeln. Die Schwellen richten sich nach dem\nRisiko, im Codebeispiel der Doku 0.5 als Boden und 0.9 f\u00fcr eine \u00dcberweisung. Wo diese Schwelle\nliegt, ist keine technische, sondern eine Produktentscheidung.\n\n---\n\n## Structured Outputs l\u00f6sen die Form, nicht die Frage\n\nDie naheliegende Gegenfrage lautet: das kann ein Sprachmodell mit JSON-Schema doch auch. Form\nerzwingen, fertig. Die Antwort hat zwei Teile.\n\nErstens hebt erzwungenes Decoding die Sequenzialit\u00e4t nicht auf. Die Antwort entsteht weiterhin\nToken f\u00fcr Token, die Latenz h\u00e4ngt an der Ausgabel\u00e4nge, und zwei Fehlerpfade bleiben offen: die\nVerweigerung aus Sicherheitsgr\u00fcnden und die abgeschnittene Antwort am Token-Limit. Beides\nproduziert kein Schema-konformes Ergebnis, sondern gar keins.\n\nZweitens, und das wiegt schwerer: ein Schema sagt nichts \u00fcber die Sicherheit. Ein\n`confidence`-Feld, das im Schema steht, wird vom Modell als Text erzeugt wie jedes andere Feld.\nEs ist eine Selbsteinsch\u00e4tzung, kein Ma\u00df. TrueFoundry (Ashish Dubey, 18.09.2026) formuliert es\nso: \u201econstraining the shape of an answer has never guaranteed the substance of it.\"\n\nDie Abgrenzung verl\u00e4uft deshalb an einer anderen Stelle, als \u201emit Schema gegen ohne Schema\"\nnahelegt. Sie lautet: muss das Modell die Antwort \u00fcberhaupt erzeugen, und kommt zusammen mit der\nAntwort ein belastbares Ma\u00df f\u00fcr ihre Sicherheit?\n\n### Sieben Wege zu einem Wert statt eines Textes, mit Kosten und Bruchstelle\n\nJev ist eine von sieben Antworten auf dieselbe Aufgabe. Ohne diesen Rahmen wird jede Bewertung\nzur Produktvorstellung.\n\n**1. Eigener Parser (Regex, JSON aus dem Text fischen):** Kosten: ein Modellaufruf plus\nReparaturschleife. Bruchstelle: alles. Von allen gesichteten Quellen als \u00fcberholt behandelt.\n\n**2. Structured Outputs beim gro\u00dfen Anbieter:** Kosten: der normale Modellpreis, laut\nTypeSafe-Vergleichstabelle 0,20 bis 10 $ je Million Eingabe-Token, Ausgabe etwa f\u00fcnfmal so teuer.\nL\u00f6st die Form zuverl\u00e4ssig. Bruchstelle: Sequenzialit\u00e4t, Verweigerung, Abschneiden, und das\nSchema sagt nichts \u00fcber die Sicherheit.\n\n**3. Logprobs auslesen:** Technisch dasselbe, was Jev tut, und deutlich \u00e4lter. Optionen nach\nLabel-Wahrscheinlichkeit zu bewerten steht schon im GPT-3-Paper (\u00a72.4, 2020) und in MMLU (\u00a74.1,\n2021), das Abbilden eines Labels auf ein Token als Verbalizer bei Schick und Sch\u00fctze (arXiv\n2001.07676), die bekannte Verzerrung der Label-Priors bei Zhao et al. (Calibrate Before Use,\n2021), die Reparatur von \u00dcberkonfidenz durch eine angepasste Temperatur bei Guo et al. (2017) und\nKadavath et al. (2022). Offen zug\u00e4nglich \u00fcber vLLM (`logprob_token_ids`) und SGLang (`/v1/score`).\nKosten: eigene Hardware oder Anbieterpreis. Bruchstelle: Die gro\u00dfen geschlossenen Anbieter geben\nLogprobs nicht heraus, laut einem Kommentar im Hacker-News-Launch-Thread bewusst, weil es\nDistillation erleichtert. Dazu die schlechte Kalibrierung roher Modelle (Median-ECE 0,180 bei\nGemma 4 26B, siehe unten).\n\n**4. Function Calling:** Dasselbe Grundproblem wie bei Structured Outputs, plus einen eigenen\nFehlerpfad: der Werkzeugname selbst kann halluziniert werden. TrueFoundry dazu: \u201eHaving a\nhallucinated tool call is inconvenient in an agent, but is an absolute deal-breaker if it's \u2026\nburied several layers deep in a dependency chain.\"\n\n**5. Trainierter Klassifikator (fine-tuned Encoder, klassisches ML):** Kosten: Beschriftungsarbeit\nplus ein Trainingslauf, danach fast nichts. Bruchstelle: der kalte Start ohne Labels, und jede\nneue Kategorie verlangt ein neues Training. Wo dieser Weg gewinnt, gewinnt er deutlich. Aus der\ndev.to-Metastudie vom 24.09.2026: ein japanischer 310M-Encoder, trainiert auf 200 Zeilen, schlug\nJev bei Nachrichtenthemen um 12 Punkte (88,8 % gegen 76,8 %); bei Phishing kam ein\nLoRA-Nachbau mit 1.000 Labels auf 97,4 % gegen Jevs 62,6 %, und eine zweizeilige Regex auf\ndemselben Benchmark auf 91,6 %. Der Satz der Auswertung dazu: \u201eLabels beat zero-shot wherever\nthey were tried.\"\n\n**6. Zero-Shot \u00fcber NLI:** Das klassische `facebook/bart-large-mnli`-Muster. Kosten: eigene\nHardware, das Modell ist frei. Bruchstelle: Sprache (englisch trainiert), Kalibrierung,\nTrennsch\u00e4rfe. Aus dieser Familie kommen die offenen Jev-Nachbauten, und genau dort versagen sie\nauf Deutsch (siehe unten).\n\n**7. Constrained Decoding als Bibliothek (Outlines, llguidance, Instructor):** Erzwingt das Schema\nlokal auf jedem offenen Modell. Kosten: eigene Hardware. Bruchstelle: dieselbe wie bei Punkt 2.\nForm gel\u00f6st, Sicherheit nicht.\n\n### Jev lohnt sich dort, wo aus Freitext eine Auswahl werden muss\n\nAus dem Vergleich folgt eine Auswahlregel, die in den gesichteten Quellen nirgends ausformuliert\nist.\n\nGegen Jev spricht es, wenn beschriftete Daten vorliegen. F\u00fcnfzig bis tausend eigene Labels\nschlagen Zero-Shot in jeder gemessenen Aufgabe, und ein trainierter Encoder ist danach billiger\nim Betrieb als jeder API-Aufruf.\n\nGegen Jev spricht es auch, wenn die Antwort nicht aus einer Menge kommt, sondern erzeugt werden\nmuss. Der Anbieter benennt das als Fehlermodus: \u201ejev-1.13 is not trained to generate text.\" Der\nLangChain-Blog (Sydney Runkle, Hunter Lovell, 17./18.09.2026) schreibt denselben Satz anders:\n\u201eJev isn't a drop-in replacement for an LLM.\"\n\nEbenfalls gegen Jev: alles Nachz\u00e4hlbare, jeder Datumsvergleich, jede Rechnung. Dazu gleich mehr.\n\nF\u00fcr Jev spricht es, wenn aus mehrdeutigem Text eine Auswahl aus wenigen unterscheidbaren\nKandidaten werden soll, wenn es keine Labels gibt, wenn die Entscheidung oft f\u00e4llt und schnell\nsein muss, und wenn zur Entscheidung ein Sicherheitswert geh\u00f6rt, an dem eine Schwelle h\u00e4ngt.\n\nDie knappste Formulierung dieser Grenze stammt aus digital-magazin.de (18.09.2026):\n\u201eDeterministische Fakten geh\u00f6ren in Code oder Datenbanken, die Bewertung eines mehrdeutigen\nTextes in ein Modell.\"\n\nEin Einzelfall vom 23.09.2026 l\u00e4uft gegen die Erwartung: Beim Einsortieren eines Werkzeugs namens\n`scorecard` widersprach das Modell mit 0,79 der Zuordnung, die zuvor von Hand getroffen worden\nwar, und entschied auf eine andere Kategorie. Die Nachpr\u00fcfung gab ihm recht. Wer den\nSicherheitswert ernst nimmt, muss also auch damit rechnen, dass er gegen die eigene Einsch\u00e4tzung\nausschl\u00e4gt.\n\n---\n\n## Die Bauanleitung, die im Feld fehlt\n\nVon rund zwanzig gesichteten Seiten zum Thema bringen vier eigenes Material. Alle zeigen\ndasselbe Support-Ticket und h\u00f6ren dort auf. Die Arbeit, die tats\u00e4chlich \u00fcber Erfolg und\nMisserfolg entscheidet, kommt in keinem der Erkl\u00e4rst\u00fccke vor. Die folgenden sieben Regeln stehen\nverstreut in der Anbieter-Doku oder in gar keiner Quelle.\n\n### In jede Auswahl geh\u00f6rt ein Ausweg\n\nEine `Choice` zwingt das Modell, aus der Liste zu w\u00e4hlen. Steht die richtige Antwort nicht darin,\nw\u00e4hlt es trotzdem, und das Ergebnis sieht dabei gut aus.\n\nEin Einzeltest vom 20.09.2026 zeigt den Effekt sauber. Vorgelegt wurde ein deutscher Text, der\nden Mauerfall beschreibt, ohne das Wort zu nennen. Mit der richtigen Option in der Liste:\n`mauerfall`, Sicherheit 1,0. Ohne sie, also nur mit Mauerbau, W\u00e4hrungsunion und Olympia M\u00fcnchen\nzur Auswahl: `mauerbau` mit 89 % Wahrscheinlichkeit und Sicherheit 0,84. Eine falsche Antwort,\ndie \u00fcber jeder \u00fcblichen Schwelle liegt. Kommt eine zus\u00e4tzliche Option `keines_davon` dazu, w\u00e4hlt\ndas Modell diese mit 97 %.\n\nDaraus folgt: Jede `Choice` bekommt eine Option \u201enichts davon\", ohne Ausnahme. Wer das in ein\nWerkzeug einbaut, baut sie als Vorgabe ein und macht sie nur bewusst abschaltbar.\n\nDer Ausweg taugt au\u00dferdem als Pr\u00fcfstein f\u00fcr Nachbauten: Ein Modell, das ihn bei fehlender\nrichtiger Option nicht w\u00e4hlt, ist f\u00fcr Schwellenbetrieb unbrauchbar (siehe unten).\n\n### Zu jedem Urteil geh\u00f6rt eine zweite Frage nach der Grundlage\n\nDer Sicherheitswert sagt, wie eindeutig die Verteilung ist. Er sagt nicht, ob das vorgelegte\nMaterial f\u00fcr ein Urteil \u00fcberhaupt reicht. Diese zweite Frage muss separat gestellt werden, als\n`Noul`.\n\nBeispiel aus einem Einzeltest (20.09.2026): Auf die Frage \u201eWer hat Schuld?\" kam `unklar` mit\n63 %. Die Nachfrage \u201eReichen die Angaben f\u00fcr ein Urteil?\" ergab 0,1. Erst wenn dieser zweite Wert\n\u00fcber der Schwelle liegt, darf der Code mit dem Urteil weiterrechnen.\n\nDerselbe Aufbau in einem anderen Fall: Ein Briefing wurde in die Branche `praxis_gesundheit`\neingeordnet, Sicherheit 1,0, Dringlichkeit 2,13 von 3. Die Frage, ob damit die Arbeit starten\ndarf, ergab 0,05, also nein, weil noch Texte fehlten. Verbrauch f\u00fcr den ganzen Aufruf: 725\nEingabe- und 190 Ausgabe-Token, rund 0,004 Cent.\n\n### Niedrige Sicherheit ist zuerst eine Frage an den Zustand\n\nWenn ein Wert niedrig ausf\u00e4llt, ist der erste Reflex, an der Frage zu schrauben oder die Schwelle\nzu senken. Beides ist meistens falsch. Der \u00fcbliche Grund ist, dass im `state` schlicht zu wenig\nsteht.\n\nBelegt an der Zuordnung von 50 Werkzeugen zu Kategorien (Einzeltest, 23.09.2026): Bei einem\nEintrag namens `timeline` lag die Sicherheit bei 0,31. Mit der echten Beschreibung des Werkzeugs\nim Zustand stieg sie auf 0,76, eine Gegenfrage best\u00e4tigte die Zuordnung mit 0,79. Die Frage war\ndieselbe geblieben.\n\nDie Anbieter-Doku nennt die Gegenrichtung als Fehlermodus: \u201eJev suffers from context rot.\" Viel\nIrrelevantes im Zustand schadet genauso wie zu wenig Relevantes. Anreichern hei\u00dft gezielt\nanreichern, nicht alles hineinkippen.\n\n### Vor jedem Aufruf muss deterministisch vorsortiert werden\n\nEin Modell, das aus h\u00f6chstens 255 Optionen w\u00e4hlt und mit gro\u00dfem Kontext schlechter wird, geh\u00f6rt\nhinter eine Vorauswahl, die ohne Modell auskommt. Die Trennlinie dazu l\u00e4sst sich in einem Satz\nformulieren: Einen Eintrag \u00fcber seinen Schl\u00fcssel nachzuschlagen ist eine Hashtabelle und kein\nUrteil; ein Modell daf\u00fcr einzusetzen w\u00e4re teurer, langsamer und schlechter.\n\nDie Bauform, die sich in der Praxis bew\u00e4hrt hat: Punktwerte im Code berechnen, auf h\u00f6chstens\nsechs bis acht Kandidaten k\u00fcrzen, und erst \u00fcber diese Kandidaten plus \u201enichts davon\" genau eine\nFrage stellen. Erreicht kein Kandidat die Mindestpunktzahl, entf\u00e4llt der Aufruf ganz. Eingaben\nunter drei Zeichen l\u00f6sen keinen Aufruf aus, sehr lange Eingaben werden gek\u00fcrzt.\n\nWichtig dabei: Die Rangfolge der Kandidaten kommt aus dem deterministischen Punktwert, nicht aus\ndem Modell. Eine `Choice` liefert eine Wahl und eine Sicherheit, kein Ranking. Wer aus den\n`probabilities` eine Reihenfolge baut, benutzt einen Wert f\u00fcr etwas, wof\u00fcr er nicht geeicht ist.\n\nDie Vorsortierung hat eine eigene Bruchstelle, die selten benannt wird. Eine Punktwertung \u00fcber\nTeilzeichenketten schl\u00e4gt bei kurzen F\u00fcllw\u00f6rtern durch: In einem Katalog von 50 Werkzeugen steckt\n\u201eder\" in 22 Eintr\u00e4gen und \u201eist\" in 11 (Ausz\u00e4hlung, 23.09.2026). Damit greift die Regel \u201ekein\nKandidat erreicht die Mindestpunktzahl\" bei einem normalen deutschen Satz fast nie, und eine\nsinnlose Frage kostet trotzdem einen echten Aufruf. Konkret ergab \u201eQuallenzucht in der Nordsee\"\nacht Kandidaten, \u201eQuallenzucht Nordsee\" keinen. Wer so vorsortiert, braucht eine Stoppwortliste\noder eine Mindestl\u00e4nge je Treffer.\n\n### Was sich nachz\u00e4hlen l\u00e4sst, geh\u00f6rt in den Code und nicht in ein Modell\n\nDer Anbieter listet Rechnen, Z\u00e4hlen und Datumsvergleiche als Fehlermodi. Trotzdem passiert genau\ndas in der Praxis, weil es in der Frageform so bequem aussieht.\n\nZwei dokumentierte Fehlgriffe vom 24.09.2026, beide auf dieselbe Art:\n\nIm ersten Fall sollte das Modell aus einer ganzen Trefferliste lesen, ob eine bestimmte Domain\ndarin vorkommt. Bei zwei Fragen meldete es \u201eweit vorn in den Treffern\" mit Sicherheit 0,28,\nobwohl keine einzige passende Domain in der Liste stand. Ob eine Domain in einer Liste steht, ist\nein Zeichenkettenvergleich und keine Ermessensfrage. Die Reparatur bestand darin, die Tatsache im\nCode zu pr\u00fcfen und das Modell nur noch entscheiden zu lassen, wie weit vorn, und das auch nur,\nwenn die Domain tats\u00e4chlich vorkommt.\n\nIm zweiten Fall sollten Stichwort-Ideen gegen eine Liste von Themen bewertet werden, zu denen\nSubstanz vorliegt. Das Modell stufte aus einem blo\u00dfen Stichwort alles als Kernthema ein, weil es\nein Wort aus der Substanzliste wiedererkannte.\n\nDie Regel aus beiden F\u00e4llen: Das Modell braucht unterscheidbare Kandidaten. Wortvarianten\ndesselben Begriffs sind keine unterscheidbaren Kandidaten. Und was sich ausz\u00e4hlen l\u00e4sst, z\u00e4hlt\nder Code aus. Der Anbieter empfiehlt daf\u00fcr selbst eine Ersatzform: eine `Noul`-Frage je Element,\ndie Summe bildet der Code.\n\n### Deckel, Zeitlimit und R\u00fcckfallebene geh\u00f6ren zum ersten Aufruf\n\nZu Betriebsfragen findet sich in den Erkl\u00e4rst\u00fccken nichts. Dabei gelten hier dieselben Regeln wie\nbei jedem fremden Dienst, plus drei Besonderheiten.\n\nWas in jedem Fall dazugeh\u00f6rt: ein Tagesdeckel \u00fcber alle Nutzer (ein Wert in der Gr\u00f6\u00dfenordnung von\n500 Aufrufen ist ein brauchbarer Startpunkt, Z\u00e4hler l\u00e4uft um Mitternacht zur\u00fcck), eine Begrenzung\nje Nutzer oder IP und Stunde, ein Verbindungs- und ein Antwortzeitlimit (f\u00fcnf beziehungsweise\nzwanzig Sekunden sind praxiserprobt), h\u00f6chstens ein Wiederholungsversuch, und eine Testsuite, die\nden Dienst gar nicht \u00fcber das Netz rufen kann.\n\nErste Besonderheit: die R\u00fcckfallebene, die in der Praxis am h\u00e4ufigsten fehlt. Bei\nZeit\u00fcberschreitung, Fehlercode,\nung\u00fcltiger Antwort oder erreichtem Deckel muss dasselbe herauskommen wie bei niedriger Sicherheit:\ndie deterministisch vorsortierten Kandidaten zur Auswahl, mit Hinweis. Nie eine Fehlerseite, nie\nein geratenes Ergebnis. Wer zus\u00e4tzlich eine zweite Bezugsquelle einbaut (etwa Hauptweg \u00fcber ein\nGateway, R\u00fcckfall direkt beim Anbieter), muss dabei den HTML-bei-HTTP-200-Fall abfangen, der oben\nbeschrieben ist.\n\nZweite Besonderheit: Ein Skript oder Kommandozeilenwerkzeug braucht drei unterscheidbare\nAusg\u00e4nge, nicht zwei. Entschieden, unter der Schwelle und Fehler sind drei verschiedene Zust\u00e4nde,\nund nur der erste darf eine automatische Handlung ausl\u00f6sen. Wer \u201eunter der Schwelle\" mit \u201eFehler\"\noder mit \u201eNein\" zusammenwirft, verliert genau die Information, f\u00fcr die das Modell bezahlt wurde.\n\nDritte Besonderheit: Die Modellversion geh\u00f6rt ins Protokoll. Die Aliase `jev-latest` und\n`jev-preview` zeigen heute auf `jev-1.13.0` und wandern. Eine Schwelle, die auf einer Version\ngeeicht wurde, gilt auf der n\u00e4chsten nicht automatisch weiter. F\u00fcr geeichte Schwellen wird die\nVersion festgenagelt.\n\n### Englisch ist die Trainingssprache, f\u00fcr Deutsch fehlen Messungen\n\nDer Anbieter schreibt es w\u00f6rtlich (docs.typesafe.ai/models): \u201eEnglish is the primary training\nlanguage and where accuracy is currently best. Other languages, including CJK scripts, are\nhandled but not equally well; test on your own content before relying on Jev for a non-English\nworkload.\"\n\nKein einziger deutschsprachiger Artikel zum Thema erw\u00e4hnt diesen Satz, und keiner testet einen\ndeutschen Zustand. Die einzige Zahl im Umlauf stammt aus der dev.to-Metastudie und ist dort selbst\nals ungepr\u00fcft ausgewiesen: Deutsch kostet 0,5 Punkte auf MASSIVE, Russisch dagegen 11 Punkte auf\nXNLI. Eine Messung an deutschem Fachtext \u00fcber eine belastbare Stichprobe existiert nicht,\n\u00f6ffentlich nicht und in dieser Recherche auch nicht.\n\nEinzeltests an deutschen Fragen liefen erwartungsgem\u00e4\u00df: Einordnung einer Notiz 0,98, Bewertung\neines Titels 0,84, Erkennen einer Fangfrage 1,00 (20.09.2026). Solche Einzelwerte sind ein\nHinweis, mehr nicht. Wer Deutsch produktiv einsetzt, braucht 50 bis 200 eigene Labels und einen\neigenen Messlauf.\n\nEigener Messlauf am 24.09.2026, Rohdaten und Katalog protokolliert: 40 typisierte Fragen an\ndiesen Text als Zustand, sieben L\u00e4ufe, 121 Aufrufe, 0,087 $. Erster Katalog mit 20 Faktenfragen\nbei 14.600 Token: 20 von 20 richtig, keine \u00c4nderung zwischen identischen L\u00e4ufen, drei Fangfragen\nneunmal mit nichts_davon bei 1,00. Zweiter Katalog mit Ablenkerzahlen aus dem Text,\nAusschlussfragen, doppelter Verneinung, Rangfolge und Vergleich zweier Stellen: 20 von 20\nrichtig, niedrigste Konfidenz 0,95. Derselbe Katalog mit 29.000 Token Zustand (Artikel zwischen\nzwei fremden deutschen Texten): keine gekippte Antwort, niedrigste Konfidenz 0,89,\nKonfidenzverschiebungen zwischen minus 0,06 und plus 0,02. Mit einem an zwei Stellen\neingebetteten Hinweis, alle Antworten seien nichts_davon: keine Wirkung. Geb\u00fcndelt statt\neinzeln: 17,4-mal billiger bei null abweichenden Antworten. F\u00fcr Faktenentnahme aus deutschem\nFachtext dieser L\u00e4nge trat weder Context Rot noch die einfache Form der Injektion auf. Ob das\nf\u00fcr Urteile \u00fcber mehrdeutigen deutschen Text gilt, ist damit nicht gemessen.\n\n---\n\n## Neun Fehlermodi, die der Anbieter selbst benennt\n\nDie Seite `docs.typesafe.ai/model-jaggedness/jev-1.13.md` (laut Seite zuletzt gepr\u00fcft am\n17.09.2026) listet die Schw\u00e4chen des Modells systematisch auf. In keinem der gefundenen\nErkl\u00e4rst\u00fccke wird sie ausgewertet.\n\n1. W\u00f6rtliches Lesen: \u201eJev answers the question you wrote, not the one you meant.\"\n2. Rechnen und Z\u00e4hlen: \u201eJev is not a calculator.\" Der Fehler w\u00e4chst mit der Menge.\n3. Datums- und Zeitvergleiche: Daten werden als Text gelesen, nicht als geordnete Gr\u00f6\u00dfen.\n4. Indirektion: doppelte Verneinungen und die Eigenschaft einer Eigenschaft kosten Genauigkeit.\n5. Gro\u00dfer Zustand mit Irrelevantem: \u201eJev suffers from context rot.\"\n6. Adversarialer Inhalt: \u201eState is data, and jev-1.13 does not treat it as hostile by default.\"\n Prompt Injection im Zustand kann die Antwort verschieben. Wer fremden Text hineingibt, muss\n damit rechnen.\n7. Widerspr\u00fcchliche Anweisung und Kriterien.\n8. Strukturelle Invarianten gelten nicht (siehe den folgenden Abschnitt).\n9. Erzeugung: \u201ejev-1.13 is not trained to generate text.\"\n\n### Schwellen gelten je Fragetyp und je Modellversion\n\nPunkt 8 r\u00e4umt mit einer verbreiteten Annahme auf. Dieselbe Sachfrage liefert je nach Fragetyp\nunterschiedliche Zahlen, und die Wahrscheinlichkeiten einer Frage und ihrer Verneinung addieren\nsich nicht zu eins.\n\nDie Belege stehen in der Doku selbst: Dieselbe Frage als `Noul` ergab 0,22, als `Choice` dagegen\n`yes` 0,01 und `no` 0,99 bei Sicherheit 0,97. Frage und Verneinung als zwei getrennte Nouls\nergaben 0,72 und 0,47, in der Summe 1,19.\n\nFolge: Eine auf einem `Noul` geeichte Schwelle darf nicht auf eine `Choice` \u00fcbertragen werden.\nJede Schwelle gilt f\u00fcr genau eine Frageform, genau eine Fragestellung und genau eine\nModellversion.\n\nDazu passt ein zweiter Befund, diesmal von au\u00dfen: Beim Vertauschen der Optionsnamen \u00e4nderten sich\n32,5 % der Antworten (arXiv 2609.26758, 22.09.2026, n = 1.200, hier nicht nachgerechnet). Wie\neine Option hei\u00dft, beeinflusst also das Ergebnis. Ein unabh\u00e4ngiger Test, ob ein generatives Modell\ndieselbe Empfindlichkeit zeigt, fehlt.\n\nDazu kommt eine Eigenheit der Ausgabe, die beim Schwellenbau st\u00f6rt: Die Werte werden laut\ndev.to-Auswertung auf 0,01 gerundet, in einer Stichprobe kamen 70,4 % der\nEinzelwahrscheinlichkeiten einer `Choice` als exakt 0 zur\u00fcck, und ein `Noul` ist zwischen\n0,01 und 0,98 geklemmt (Sekund\u00e4rquelle, hier nicht nachgemessen).\n\n### Ein Sonderfall: f\u00fcr Stil und Stimme ist das Modell untauglich\n\nEin Einzeltest vom 24.09.2026 zeigt eine Asymmetrie, die sich auf \u00e4hnliche Bewertungsaufgaben\n\u00fcbertragen lassen d\u00fcrfte. Der Titel \u201eWillkommen\" f\u00e4llt mit 0,92 als nichtssagend durch. Ein guter\nTitel bekommt dagegen nur 0,36.\n\nDas Modell erkennt schlechte F\u00e4lle zuverl\u00e4ssig und gute nicht. Daraus folgt die Betriebsregel: mit\nhoher Schwelle arbeiten (0,8), und ein Ausbleiben der Antwort als \u201eungepr\u00fcft\" werten, nicht als\n\u201ebest\u00e4tigt\". Wer aus einem niedrigen Wert eine Freigabe ableitet, liest das Werkzeug falsch herum.\n\n---\n\n## Der Zahlenstand: was belegt ist und was nicht\n\n### Belegbar sind Preis, Schemakonformit\u00e4t, Latenz pro Aufruf und der Launch selbst\n\nTrueFoundry (18.09.2026) trennt das am saubersten: pr\u00fcfbar sind der Preis, die\nSchemakonformit\u00e4t (per Konstruktion, nicht gemessen), die Latenz je Aufruf und die Tatsache des\nLaunchs. Nicht unabh\u00e4ngig reproduziert sind zum selben Stand die Multiplikatoren, die\nIntelligenzparit\u00e4t und der Halluzinationsvergleich.\n\nZur Schemakonformit\u00e4t gibt es inzwischen eine unabh\u00e4ngige Zahl: null ung\u00fcltige Antworten \u00fcber\n23.703 Aufrufe von Entscheidungsmodellen in der gr\u00f6\u00dften gefundenen Studie (dev.to-Auswertung,\n24.09.2026). Zur Wiederholbarkeit: 1,33 % ge\u00e4nderte Antworten zwischen identischen L\u00e4ufen in einer\nStudie, 2,2 % in einem Phishing-Benchmark, 0 von 96 in einer dritten.\n\n### Der Anbieter belegt die Kalibrierung f\u00fcr keinen einzigen Datensatz mit einer Zahl\n\nDie L\u00fccke betrifft genau den Wert, auf dem das Produktversprechen ruht. TypeSafe ver\u00f6ffentlicht\nkein ECE, keine Reliability-Kurve, keinen Brier-Score und keinen Log-Loss.\n\nDie einzige Angabe, die Sicherheit und Genauigkeit \u00fcberhaupt in Beziehung setzt, steht in einem\nCookbook (docs.typesafe.ai/cookbooks/classification_using_confidence.md): 60 SEC-Berichte, bei\nSicherheit ab 0,9 rund 90 % richtig, darunter rund 40 %. Sechzig F\u00e4lle, ein Datensatz, keine\nFehlerbalken.\n\nDer Anbieter ver\u00f6ffentlicht au\u00dferdem bewusst keine Ergebnisse gegen \u00f6ffentliche Benchmarks: \u201eWe\ndeliberately chose *not* to publish performance against *public* benchmarks.\" Die Empfehlung\nlautet stattdessen: \u201ePut no weight on public benchmarks\", eigene Evals bauen, Nuancen offenlegen.\nDas ist eine vertretbare Position, sie verlagert die Beweislast aber vollst\u00e4ndig zum Nutzer.\n\nZum Trainingsverfahren RLCD (Reinforcement Learning for Calibrated Decisions) gibt es kein Paper,\nkeine Methodenbeschreibung, kein Patent. Modellgr\u00f6\u00dfe und Basismodell sind unbekannt. Laut\ndev.to-Auswertung sagte der Firmenchef auf Hacker News, die Architektur bleibe \u201eclose to the chest\nfor now, but we have talked about writing a paper\"; auf einem Podcast habe er best\u00e4tigt, dass alle\nTrainingsdaten synthetisch sind. Ein Kommentator im Launch-Thread ordnete RLCD als das ein, was\nin der Literatur \u201ecalibrated RL\" hei\u00dft: Verteilungen bestrafen, die zu sicher falsch liegen. Die\nLeistung liege dann in der Umsetzung, nicht in der Idee.\n\n### Zu den eigenen Grenzen ist der Anbieter ungew\u00f6hnlich offen\n\nIm Launch-Blogpost stehen mehrere \u201eNuance\"-K\u00e4sten, die selten zitiert werden:\n\n- Die ver\u00f6ffentlichten Evals liefen \u201evon unseren Laptops an der Westk\u00fcste\".\n- \u201eWe can't prove it isn't subsidized.\" Die Preisnachhaltigkeit ist offen.\n- Die Workflow-Evals \u201ewere made by individuals on our model capabilities team, so some bias could\n exist\".\n- Die Referenzantwort ist der Mittelwert aus GPT-6 Astra und Claude Fable 5.1, \u201ewhich biases\n answers towards OpenAI and Anthropic's models\".\n- Die Vergleichsmodelle liefen durch einen eigenen Adapter, der \u201eslower and more expensive\" ist.\n- Die Null bei Halluzination \u201eis not empirical. Schema matching is guaranteed, thus we can\n confidently add 0% into the plots.\"\n- Die Halluzinationszahlen der Vergleichsmodelle stammen aus OpenRouter-Verkehr, \u201ealmost\n certainly bias\".\n\nZur Halluzinationsnull: \u201ekann nicht halluzinieren\" hei\u00dft \u201ekann keinen Typfehler produzieren\", und\nnur das. Ein Kommentar im Launch-Thread formuliert die Folge: \u201eit can still emit a completely\nwrong valid value\". Der Mauerfall-Test oben ist genau so ein Fall.\n\n### Unabh\u00e4ngig gemessen liegt Jev im Mittelfeld, nicht an der Spitze\n\nDie folgenden Zahlen stammen aus einer dev.to-Metastudie vom 24.09.2026 (Auswertungsstand\n23.09.2026), die 14 arXiv-Preprints, 104 GitHub-Evaluationsrepos und 33 Blogbeitr\u00e4ge mit\nEvidenzgraden und offengelegten Interessenlagen zusammenfasst. Sie ist selbst eine Sekund\u00e4rquelle\nauf einer Publikumsplattform, die zitierten Preprints sind Tage alt und nicht begutachtet. Drei\nder arXiv-Nummern wurden am 24.09.2026 auf Existenz und Titel gepr\u00fcft (2609.24574, 2609.26758,\n2609.23136), die Einzelzahlen darin nicht nachgerechnet.\n\nSechs-Modell-Vergleich (Manjunath Janardhan, 200 F\u00e4lle aus BANKING77, BoolQ, Yelp und ChaosNLI,\nLogs ver\u00f6ffentlicht):\n\n| Modell | Genauigkeit | Kalibrierungsfehler (ECE) |\n|---|---|---|\n| Claude Fable 5.1 | 84,0 % | 0,064 |\n| GPT-6 Astra | 79,0 % | 0,119 |\n| DeepSeek V4.1 Flash | 76,0 % | 0,138 |\n| MiniMax M3 | 75,5 % | 0,112 |\n| Kimi K3 | 74,5 % | 0,119 |\n| Jev | 72,5 % | 0,161 |\n\nDie beiden Frontier-Vorspr\u00fcnge (+11,5 und +6,5 Punkte) schlie\u00dfen die Null im 95-Prozent-Intervall\naus. Die drei mittleren Modelle liegen im Rauschen neben Jev.\n\nDie gr\u00f6\u00dfte vorregistrierte Studie (arXiv 2609.24574, eingereicht 21.09.2026) misst 7.977 menschlich\nbeschriftete F\u00e4lle aus der Sozialforschung. Jev liegt auf 14 von 15 Aufgaben hinter dem jeweils\nbesten von 19 Sprachmodellen, im Median 11,6 Makro-F1-Punkte. Innerhalb seiner Preisklasse liegen\nGemma 4 31B und Qwen3 235B 3 beziehungsweise 2 F1-Punkte \u00fcber Jev. Auf BANKING77 ergaben acht\nunabh\u00e4ngige L\u00e4ufe Werte zwischen 0,753 und 0,840, Median 0,809; in jeder Studie, die\nSprachmodelle danebenstellte, lag das beste davon vorn.\n\nWo Jev gut abschneidet: Spam-Erkennung mit 98,33 % auf 18.514 Mails, gleichauf mit TF-IDF plus\nlogistischer Regression (98,39 %), die aber auf neuer Post auf 72,5 % fiel. Reranking gleichauf\nmit einem spezialisierten Reranker (0,692 gegen 0,691). Backdoor-Erkennung in Code mit AUROC 0,976\nund 0,970, also rund 90 % Trefferquote bei 2 % Fehlalarm, unter einem Best-of-5-Angriff allerdings\nnur noch 60 %.\n\nZur Kalibrierung, auf der das ganze Versprechen beruht, ist das Bild uneinheitlich:\n\n- Auf einer \u00f6ffentlichen 13-teiligen Suite liegt der Median-ECE bei 0,071, besser als jedes dort\n gemessene Gemma 4 (0,114 bis 0,180), und zwar ohne Nacheichung.\n- Gegen Modelle, die ihre Sicherheit als Zahl in den Text schreiben, gewinnt Jev meistens: ein\n Median-ECE von 0,157 schl\u00e4gt 16 von 19.\n- Bekommt jedes Modell eine angepasste Temperatur, schlagen 15 dieser Modelle Jev wieder.\n- Gegen Modelle mit echter Wahrscheinlichkeitsverteilung ist Jevs Kalibrierungsfehler in zwei\n L\u00e4ufen der h\u00f6chste (0,161 und 0,138).\n- Die Richtung des Fehlers wechselt je Aufgabe. Auf GoEmotions \u00fcberkonfident (Labels mit 0,80 bis\n 0,95 trafen in 15 % der F\u00e4lle das menschliche Label), auf Unfallberichten unterkonfident. Die\n nacheichenden Temperaturen reichten von 0,65 bis 4,45: \u201eno single temperature fits\".\n- Reparierbar ist das: 50 bis einige hundert eigene Labels plus eine angepasste Temperatur\n dr\u00fcckten den ECE auf civil_comments von 0,16 bis 0,21 auf unter 0,025.\n\nEine ab Werk gute Kalibrierung ersetzt also keine eigene Eichung. Umgekehrt ist die Eichung\nbillig genug, dass sie zum Standardvorgehen geh\u00f6ren sollte, sobald an einem Sicherheitswert eine\nautomatische Handlung h\u00e4ngt.\n\n### Die Werbezahlen gelten gegen das teuerste Vergleichsmodell\n\nIm Umlauf sind \u201e193,6x schneller\" und \u201e444,6x billiger\", bei LangChain als \u201eup to 200x faster and\n400x lower cost\" vom Anbieter \u00fcbernommen. Die dev.to-Auswertung hat das gegen die ver\u00f6ffentlichte\nZusammenfassung nachgerechnet: 444,6x passt nur f\u00fcr den Vergleich gegen Claude Opus 5. \u00dcber alle\nacht Workflow-Setups gemittelt bleiben 97,8x schneller und 149,2x billiger.\n\nUnabh\u00e4ngig gemessen f\u00e4llt die Spanne noch weiter auseinander: Geschwindigkeitsgewinn zwischen\n0,5x (Jev langsamer als ein lokales Gemma 4 26B auf einem Mini-PC) und 12,1x, Kostengewinn\nzwischen 0,6x (Jev teurer, arXiv 2609.23136) und 478x.\n\nDer Kostenvorteil hat einen strukturellen Grund, der in den Zusammenfassungen fehlt: Er kommt\nfast vollst\u00e4ndig daher, dass die Ausgabe nichts kostet. In einem nachgerechneten Lauf waren 83 %\nder alten Rechnung Ausgabe-Token; pro Eingabe-Token lagen die Preise nur um Faktor 1,31\nauseinander. Wer ohnehin sehr kurze Ausgaben erzeugt, spart also wenig.\n\nDie Gegenrechnung gegen lokalen Betrieb: Ein einfaches Gemma 4 26B auf einer EC2-L4-Instanz unter\nVollast kostet h\u00f6chstens 5,43 $ je Million Entscheidungen, gegen Jevs 5,54 $ bei Prompts von 132\nToken. Bei diesem Zuschnitt ist der Preisvorteil weg.\n\n### Die Geldrechnung, die nur eine Quelle anstellt\n\npexon Consulting (17.09.2026) rechnet den Workflow-Benchmark des Anbieters in Geld um. Wichtig\nbeim Lesen: \u201eGenauigkeit\" hei\u00dft hier \u00dcbereinstimmung mit dem Mittelwert aus GPT-6 Astra und\nClaude Fable 5.1, nicht \u00dcbereinstimmung mit menschlichen Labels. Die Zahlen sind TypeSafes\neigene; der Titel des Beitrags suggeriert einen eigenen Testlauf, den es nicht gibt.\n\n| Modell | Genauigkeit | Kosten je Fall | Latenz |\n|---|---|---|---|\n| Jev | 67,8 % | 0,0004 $ | 0,4 s |\n| GPT-5.6 Luna | 66,8 % | 0,0033 $ | 12,9 s |\n| GPT-5.6 Terra | 67,9 % | 0,0304 $ | 10,1 s |\n| GPT-5.6 Sol | 74,1 % | 0,0836 $ | 23,3 s |\n| Claude Sonnet 5 | 67,8 % | 0,1174 $ | 78,1 s |\n| Claude Opus 5 | 73,1 % | 0,1761 $ | 37,8 s |\n\nHochgerechnet auf 10.000 Entscheidungen am Tag: rund 120 $ im Monat mit Jev gegen rund 35.220 $\nmit Claude Sonnet 5 bei gleicher Trefferquote, Faktor 294.\n\nWo die Genauigkeitsl\u00fccke wehtut, zeigt dieselbe Auswertung: Rechnungsverarbeitung 61,8 % gegen\n79,1 % bei Sol, Sicherheitsvorf\u00e4lle 61,7 % gegen 66,2 % bei Opus 5, Kundenservice dagegen nur 2,3\nPunkte Abstand. pexons Fazit dazu: \u201eJev ist kein Ersatz f\u00fcr Ihr\nHauptmodell, sondern ein Filter davor.\" Rechnungsverarbeitung komplett umzustellen hie\u00dfe, \u201e17\nProzentpunkte Fehler f\u00fcr ein paar hundert Euro Ersparnis zu kaufen\".\n\n### Latenz h\u00e4ngt am Netzweg, nicht am Modell\n\nDer Anbieter nennt 70 bis 500 ms Ende zu Ende (Blog, 15.09.2026), gemessen von Laptops an der\nUS-Westk\u00fcste. Unabh\u00e4ngig gemessen: rund 105 ms in einem Lauf, rund 76 ms nach Abzug des Netzwegs\nin einem anderen (dev.to, 23.09.2026). Aus Deutschland \u00fcber ein europ\u00e4isches Gateway ergab eine\nEinzelmessung rund 1,2 Sekunden (20.09.2026).\n\nF\u00fcr die Planung hei\u00dft das: Die Modellzeit f\u00e4llt kaum ins Gewicht, den Ausschlag gibt der Netzweg.\nWer aus Europa aufruft, rechnet mit etwa einer Sekunde und legt die Zeitlimits danach aus. apidog\nformuliert die angemessene Haltung zu jeder Anbieterlatenz: die Angabe ist \u201edie eigenen Zahlen\ndes Anbieters; behandeln Sie sie als Behauptung, die Sie mit Ihrer Arbeitslast \u00fcberpr\u00fcfen m\u00fcssen\".\n\n---\n\n## Acht Angaben im Umlauf, die sich widersprechen\n\nEin Thema, das neun Tage alt ist und massenhaft nacherz\u00e4hlt wird, produziert Wanderfehler. Diese\nacht sind belegt korrigierbar:\n\n| Behauptung | Was dagegen steht |\n|---|---|\n| \u201ekann nicht halluzinieren\" | Stimmt f\u00fcr Typfehler, nicht f\u00fcr falsche Antworten. Hacker News, TrueFoundry, pexon und casoon sagen das unabh\u00e4ngig voneinander. Der Anbieter selbst: die Null ist \u201enot empirical\", sie folgt aus der Konstruktion. |\n| \u201e193,6x schneller, 444,6x billiger\" | 444,6x gilt nur gegen Claude Opus 5. \u00dcber alle acht Workflow-Setups gemittelt: 97,8x und 149,2x (dev.to, 24.09.2026, gegen die ver\u00f6ffentlichte Zusammenfassung nachgerechnet). |\n| \u201e194x schneller als GPT-6 Astra\" (u. a. Tom's Hardware) | Astra ist in diesem Aufbau der Referenzbewerter, kein bewertetes Modell. |\n| \u201eEin Mitarbeiter ma\u00df 15,9 % an einer echten Pipeline\" (Cherry Creek News) | Drei F\u00e4lle eines Demo-Tickets, Kosten aus einem gesch\u00e4tzten Preis modelliert. |\n| \u201earXiv 2609.26758: Jev kippt 70,4 von 100 Antworten\" | Die 70,4 gelten laut dev.to f\u00fcr einen offenen ModernBERT-Kopf. Jevs Wert in derselben Arbeit ist 32,5 %. |\n| \u201eAlmeida co-invented RLHF\" (TypeSafe-eigene Seiten) | Er ist nicht Autor von Christiano et al. (2017), sondern Hauptautor von InstructGPT (arXiv 2203.02155). |\n| \u201eAlmeida ist Mitgr\u00fcnder von ChatGPT\" (u. a. DataCamp) | Von pexon ausdr\u00fccklich korrigiert: Mitautor von InstructGPT, nicht Mitgr\u00fcnder von ChatGPT. |\n| Firmenname \u201eTypeface\" | Falsch. Die Firma hei\u00dft TypeSafe AI. |\n\nZur Einordnung der Intelligenzparit\u00e4t: Sie gilt laut Anbieter nur f\u00fcr Aufgaben der eigenen\nKategorie und wurde vor allem gegen GPT-5.6 Terra gemessen. Unabh\u00e4ngig gemessen liegt Jev 6,5 bis\n11,5 Punkte hinter der Spitze.\n\nZum Umfeld geh\u00f6rt au\u00dferdem eine Warnung, die hier ungepr\u00fcft wiedergegeben wird, weil sie\nsicherheitsrelevant ist: Die Domain `thejevai.com`, registriert am 20.09.2026 und auf Hugging Face\nals Endpunkt f\u00fcr API-Schl\u00fcssel beworben, hat laut dev.to-Auswertung keine erkl\u00e4rte Verbindung zu\nTypeSafe. Die offizielle Adresse ist `api.typesafe.ai`.\n\n---\n\n## Die offenen Nachbauten ersetzen Jev nicht, auf Deutsch schon gar nicht\n\nDas Modell selbst ist geschlossen. Innerhalb weniger Tage entstanden mehrere offene Nachbauten,\nkeiner davon von TypeSafe. \u00dcbersicht aus der dev.to-Auswertung vom 23.09.2026, erg\u00e4nzt um einen\ndokumentierten Vergleichslauf vom 20.09.2026:\n\n| Projekt | Grundlage | Selbst genannte Zahl | Unabh\u00e4ngige Pr\u00fcfung |\n|---|---|---|---|\n| Nimble-9B (Bespoke Labs) | Qwen3.5-9B plus LoRA | 75,9 % gegen Jev 77,3 % auf 13 \u00f6ffentlichen Sets | keine; Betreiber verkauft Nimble; angepasste Temperatur 2,179 |\n| Kev (Jared Palmer) | Qwen3.5, LoRA, Pointer-Head | 0,852 test gegen Jev 0,857 dev | keine |\n| Luce (scienthoon) | Qwen3-4B plus LoRA | 86,9 % gegen Jev 84,7 % auf 500 Kubernetes-Issues | keine |\n| Laya (Convai) | ModernBERT-large, 421 Mio. | 0,766 gegen 0,727 nach Training auf dem Benchmark | 29,2 / 60,0 / 40,0 auf drei japanischen Aufgaben |\n| SimpleJev (Featherless) | beliebiges HF-Modell | keine Genauigkeit ver\u00f6ffentlicht | README: Wahrscheinlichkeiten \u201eare not calibrated probabilities of correctness\" |\n| `com-kotobalabs/open-jev-deberta-v3-large` | DeBERTa-v3-large, 0,4 Mrd., Apache-2.0 | Choice bis 255, Score 2 bis 10 | auf Deutsch falsch, siehe unten |\n| `vagmi/jev-lite` | Gemma 4, QLoRA | keine | Lizenz nur Forschung |\n| `Meanblock/JEV-CPU` | Qwen3-0.6B, MIT | keine Messwerte | ungetestet |\n\nZwei Muster fallen auf. Fast alle Zahlen stammen von den Betreibern selbst, und mehrere Modelle\nwurden auf dem Benchmark trainiert, auf dem sie gemessen wurden. Au\u00dferdem sagen Genauigkeitswerte\nnichts \u00fcber die Kalibrierung, auf die es beim Schwellenbau ankommt; ein Projekt schreibt das im\neigenen README ausdr\u00fccklich hin.\n\nEin Vergleichslauf mit sechs F\u00e4llen, dieselben Fragen an Jev 1.13 und an\n`com-kotobalabs/open-jev-deberta-v3-large` lokal (20.09.2026):\n\n| Frage | Jev 1.13 | open-jev |\n|---|---|---|\n| Welches Team bearbeitet das? (englisch) | billing (1.00) | billing (0.65) |\n| Browser-Aktion? (englisch) | scroll_down (1.00) | scroll_down (0.74) |\n| Fangfrage ohne Farbe (englisch) | keine davon (0.99) | keine davon (0.50) |\n| Art der Notiz? (deutsch) | Werkzeug-Beschreibung (0.98) | nichts davon (0.40) |\n| Titel \u201eWillkommen\" aussagekr\u00e4ftig? (deutsch) | nichtssagend (0.84) | ungef\u00e4hr passend (0.43) |\n| Farbe von Napoleons Kochs Pferd? (deutsch) | nichts davon (1.00) | blau (0.30) |\n\nIn der letzten Zeile stand im Text keine Farbe, der Ausweg \u201enichts davon\" stand in der Liste, und\ndas offene Modell w\u00e4hlte trotzdem \u201eblau\". Die englischen F\u00e4lle stimmen inhaltlich, aber bei einer\nSchwelle von 0,8 k\u00e4me fast nichts durch.\n\nDie Rechnung dahinter: Alle sechs F\u00e4lle \u00fcber die Schnittstelle kosteten zusammen 0,00009 $. Daf\u00fcr\nverlangt der lokale Betrieb 1,6 GB Plattenplatz, eine eigene Python-Umgebung und eine auf 2.2.2\nfestgenagelte torch-Version. Beim ersten Aufruf brauchte das lokale Modell 19 Sekunden, danach\n0,3 bis 3 Sekunden; der Aufruf \u00fcber das Netz aus Deutschland rund 1,2 Sekunden.\n\nVerallgemeinert: \u201eLokal und offen\" ist f\u00fcr sich genommen kein Argument. Es wird eines, sobald\nLabels vorliegen, denn dann schl\u00e4gt ein trainierter Klassifikator beides.\n\n---\n\n## Drei Einsatzmuster, die \u00fcber das Support-Ticket hinausgehen\n\nDrei Bauformen lassen sich aus ver\u00f6ffentlichtem Code oder dokumentierten L\u00e4ufen nachvollziehen\nund \u00fcbernehmen.\n\nDas erste Muster ist ein Torw\u00e4chter vor teuren Werkzeugen, aufgebaut in zwei Stufen. In Stufe 1\nwerden alle Kandidaten als eine `Choice` vorgelegt, dazu drei grobe Ja/Nein-Fragen als Tor (soll\n\u00fcberhaupt etwas getan werden, w\u00fcrde ein Fachmann nachschlagen, gen\u00fcgt eine Erkl\u00e4rung). Der\nSchnitt der drei entscheidet, ob Stufe 2 \u00fcberhaupt l\u00e4uft. In Stufe 2 bekommen die besten f\u00fcnf\nKandidaten je eine eigene Frage mit dem Anfang ihrer echten Beschreibung im Zustand.\n\nGemessen an 125 Kandidaten (20.09.2026): 0,0004 $ und rund zwei Sekunden f\u00fcr beide Stufen,\nhundert Anfragen am Tag also vier Cent. Vier von f\u00fcnf Testanfragen trafen. Der eine Fehlgriff lag\nbei 0,39 und w\u00e4re bei einer Torschwelle von 0,5 statt 0,3 herausgefallen; in ihm steckte ein\nhausinternes Wort, das in keiner der Beschreibungen vorkam. Das Verfahren entspricht dem Cookbook\n`skill_suggestion` des Anbieters, das an 488 Anfragen gegen 182 Kandidaten die Fehlerrate von\n16,8 % auf 7,3 % senkte (Untergrenze bei servierter Antwort: 2,5 %). Einschr\u00e4nkung dort im Text\nselbst: 315 der 488 Anfragen waren maschinell aus den Beschreibungen erzeugt, also leichter als\nechte Anfragen, und der ver\u00f6ffentlichte Lauf nutzte noch `jev-1.12`.\n\nDas zweite Muster ist ein Browser-Agent, der je Entscheidungsschritt eine Frage stellt, statt ein\ngro\u00dfes Modell denken zu lassen. Ein \u00f6ffentliches, lauff\u00e4higes Beispiel daf\u00fcr ist `jev-ultrafast`\nvon browser-use (github.com/browser-use/jev-ultrafast). Das README nennt eine Flugsuche auf Google\nFlights in rund sieben Sekunden. Ein kleines Textmodell bleibt nur f\u00fcr die Aktion `TYPE_TEXT`\nn\u00f6tig, weil dort etwas erzeugt werden muss. In keiner der gesichteten Erkl\u00e4rseiten kommt dieses\nProjekt vor.\n\nDas dritte Muster stammt aus der Anbieter-Doku und hat ver\u00f6ffentlichten Code: mehrere Fragen zu\ndemselben Zustand in einer Anfrage b\u00fcndeln. Das Cookbook `parallel_questions` stellt 13 Fragen zu\neinem Wikipedia-Artikel geb\u00fcndelt statt einzeln und kommt auf 12,2x billiger und 10,0x schneller\nbei gleichen Antworten. Der Zustand wird nur einmal bezahlt, die Ausgabe ist frei, das B\u00fcndeln\nkostet also nichts zus\u00e4tzlich.\n\n---\n\n## Was dieser Text nicht leistet\n\nDie Einzelzahlen der dev.to-Metastudie sind hier nicht gegen die Preprints nachgerechnet worden;\ngepr\u00fcft wurden drei arXiv-Nummern auf Existenz und Titel. Die Dokumentationsseiten von OpenAI,\nAnthropic und Google zum Vergleichsrahmen sind am 24.09.2026 nur auf Erreichbarkeit gepr\u00fcft, nicht\nim Volltext gelesen; die inhaltlichen Aussagen dazu stammen aus casoon und TrueFoundry. Der\nFAZ-Artikel zum Thema liegt hinter einer Bezahlschranke und wurde nicht gelesen. Die unabh\u00e4ngige\nAnalyse unter jev.novcog.us.com ist nicht im Detail gepr\u00fcft.\n\nMit \u201eEinzeltest\" oder \u201eEinzelmessung\" gekennzeichnete Zahlen stammen aus dokumentierten\nMessl\u00e4ufen an einzelnen F\u00e4llen, nicht aus Stichproben. Sie belegen ein Muster, keine Rate. Der\nMauerfall-Fall zeigt, dass eine fehlende Option zu einer sicher aussehenden falschen Antwort\nf\u00fchren kann; er zeigt nicht, wie oft das passiert.\n\nOffen bleibt die gr\u00f6\u00dfte Frage. Wie sich das Modell auf deutschem Fachtext \u00fcber eine gr\u00f6\u00dfere\nStichprobe verh\u00e4lt, hat niemand gemessen, dieser Text eingeschlossen. Die Anbieter-Doku sagt\nselbst, dass Englisch die Trainingssprache ist und man auf eigenem Material testen soll. Solange\ndiese Messung fehlt, tr\u00e4gt jede deutsche Anwendung das Risiko selbst, und der einzige bekannte\nErsatz ist ein eigener Messlauf mit 50 bis 200 Labels.\n\n---\n\n## Woher die Zahlen stammen: Quellenliste mit Datum\n\nPrim\u00e4rquellen (TypeSafe AI), alle abgerufen am 24.09.2026:\n\n- Launch-Blogpost, Diogo Almeida, 15.09.2026:\n \n- Modelle und Grenzen: \n- Fragetypen: \n- Sicherheitswert und Kalibrierung: \n- Fehlermodi: \n- Cookbook zu Sicherheit und Genauigkeit:\n \n- Maschinenlesbarer Index der Doku: \n\nZweitquellen, mit Interessenlage soweit erkennbar (LangChain verkauft die Integration,\nTrueFoundry ein Gateway, pexon Routing-Beratung, apidog ein Testwerkzeug):\n\n- heise online, Tomislav Bezmalinovi\u0107, 17.09.2026:\n \n- casoon insights (Architekturabgrenzung):\n \n- digital-magazin.de: \n- LangChain (Code), 17./18.09.2026: \n- TrueFoundry (pr\u00fcfbar gegen behauptet), 18.09.2026:\n \n- pexon consulting (Geldrechnung), 17.09.2026:\n \n- apidog (vollst\u00e4ndige JSON-Beispiele): \n- dev.to, Metastudie \u00fcber acht Tage unabh\u00e4ngiger Tests, 24.09.2026:\n \n- Hacker News, Launch-Thread: \n- Forbes zur Finanzierung, 15.09.2026:\n \n- browser-use, `jev-ultrafast`: ", "sig": "de00f289ee15f06a875a511220dfb8ed6b0f13d8130ebaea323002ca2546d596adfcf79b4a7e0bb547ff8f912d8f4eadaaa457b1a4980f7fa5d69ce4d8dfd677" }