TypeSafe AI hat am 15. September 2026 Jev veröffentlicht. Das Modell soll keine Texte, Zusammenfassungen oder Codeblöcke erzeugen. Es bekommt einen Zustand und klar typisierte Fragen und liefert Entscheidungen zurück, die Software direkt weiterverarbeiten kann.
TypeSafe nennt diese Modellklasse „System One Models“. Der Name ist neu, das Problem dahinter nicht: In vielen Anwendungen wird ein Sprachmodell heute nur deshalb aufgerufen, damit es am Ende eine Kategorie, einen Score oder ein Ja/Nein liefert. Dazwischen erzeugt das LLM Text oder JSON Token für Token, der anschließend geparst und validiert werden muss.
Jev entfernt diese Textschicht vollständig.
Choice, Score und Noul statt freier Textausgabe
Die öffentliche API kennt drei Fragetypen.
Choice wählt aus einer vorher festgelegten Menge von Optionen und liefert zusätzlich die Wahrscheinlichkeitsverteilung sowie einen Confidence-Wert. Score bewertet einen Zustand auf einer definierten Skala. Noul beantwortet eine Aussage nicht mit einem Boolean, sondern mit einer Wahrscheinlichkeit zwischen 0 und 1.
Ein Support-System könnte also einen eingehenden Fall als State übergeben und gleichzeitig fragen, welches Team zuständig ist, wie hoch die Dringlichkeit liegt und ob eine Eskalation nötig ist. Der Anwendungscode entscheidet anschließend anhand der Wahrscheinlichkeiten, welcher Pfad ausgeführt wird.
Nach TypeSafes Dokumentation werden mehrere Fragen in einem Request parallel und unabhängig gegen denselben State ausgewertet. Das Unternehmen schreibt, dass zusätzliche Fragen die Antwortzeit nur gering verändern. Für Workflows mit vielen kleinen Entscheidungen ist das ein anderer Ansatz als ein Prompt, der ein Modell nacheinander durch dieselbe Logik führen soll.
Die Dokumentation empfiehlt ausdrücklich, komplexe Entscheidungen zu zerlegen. Statt ein Modell beispielsweise einen gesamten Prozess bewerten zu lassen, sollen einzelne eng definierte Fragen gestellt und anschließend mit normalem Code kombiniert werden.
Das ist für Produktionssoftware ein sinnvoller Unterschied. Geschäftslogik bleibt sichtbar im Code. Das Modell übernimmt nur die Stellen, an denen feste Regeln zu spröde werden.
TypeSafe trainiert auf kalibrierte Entscheidungen
TypeSafe bezeichnet die Trainingsmethode hinter Jev als Reinforcement Learning for Calibrated Decisions, kurz RLCD. Während klassische RLHF-Verfahren auf von Menschen bevorzugte Antworten und RLVR auf überprüfbare Ergebnisse optimieren, soll RLCD Wahrscheinlichkeiten liefern, die die tatsächliche Unsicherheit des Modells besser abbilden.
Wenn Jev bei einer bestimmten Klasse von Entscheidungen regelmäßig 0,8 ausgibt, sollte eine saubere Kalibrierung bedeuten, dass diese Entscheidungen langfristig ungefähr in acht von zehn vergleichbaren Fällen richtig sind.
Für Automation wäre das nützlich. Ein System könnte hohe Wahrscheinlichkeiten automatisch verarbeiten und unklare Fälle an einen Menschen weiterreichen, ohne dafür einen zusätzlichen Prompt zu benötigen.
Wie RLCD im Detail funktioniert, erklärt TypeSafe in der öffentlichen Launch-Ankündigung bisher nicht. Dort ist von einer neuen Modellarchitektur, einem parallelen Sampler und RLCD die Rede, aber nicht von einem veröffentlichten Trainingsalgorithmus oder einem technischen Paper, aus dem sich die Methode reproduzieren ließe.
70 bis 500 Millisekunden statt Token-Generierung
Die auffälligsten Zahlen stammen von TypeSafe selbst. Das Unternehmen nennt für Jev eine End-to-End-Latenz von 70 bis 500 Millisekunden und einen Preis von 0,042 US-Dollar pro Million Input-Token. Output wird nicht berechnet.
Für „System One shaped queries“ gibt TypeSafe einen Geschwindigkeitsvorteil von 40- bis 200-fach gegenüber Frontier-LLMs an. In den eigenen Workflow-Evals kommen noch größere Spitzenwerte vor: 193,6-mal schneller und 444,6-mal günstiger.
Diese Zahlen sind keine unabhängigen Benchmarks.
TypeSafe schreibt selbst, dass die 193,6- und 444,6-fach-Werte eher am oberen Ende dessen liegen dürften, was in realen Anwendungen zu erwarten ist. Die vier veröffentlichten Workflows wurden von Mitarbeitern des eigenen Model-Capabilities-Teams erstellt. Das Unternehmen weist ausdrücklich darauf hin, dass dadurch Bias möglich ist.
Auch die Referenz ist ungewöhnlich. Die Evals verwenden nicht in jedem Fall objektive Ground-Truth-Labels, sondern bilden Referenzantworten aus GPT-6 Astra und Claude Fable 5.1. Gemessen wird anschließend, wie nahe andere Modelle und Jev an diesen Labels liegen.
Damit beantworten die Zahlen eine engere Frage: Wie schnell und günstig reproduziert Jev Entscheidungen innerhalb dieser strukturierten Workflows im Vergleich zu den getesteten LLM-Konfigurationen? Sie zeigen noch nicht, wie sich das Modell über viele unabhängige Produktionsdatensätze hinweg verhält.
„Kann nicht halluzinieren“ ist eine sehr enge Behauptung
TypeSafe wirbt damit, Jev könne nicht halluzinieren. Technisch garantiert das System vor allem, dass keine Ausgabe außerhalb des vorher definierten Schemas entsteht.
Wenn eine Choice-Frage nur „billing“, „technical“ und „sales“ erlaubt, kann Jev keinen vierten erfundenen Wert zurückgeben und auch kein kaputtes JSON produzieren. TypeSafe bezeichnet Type-Errors deshalb als mathematisch ausgeschlossen.
Das verhindert aber keine falsche Entscheidung innerhalb des gültigen Schemas. Jev kann „technical“ mit hoher Wahrscheinlichkeit wählen, obwohl „billing“ richtig gewesen wäre. The Register weist genau auf diese Trennung hin: Die strukturierte Ausgabe verhindert freie erfundene Texte, nicht automatisch inhaltliche Fehler.
Auch TypeSafes eigene Halluzinationsgrafik muss deshalb genau gelesen werden. Das Unternehmen schreibt, dass der dort eingetragene Wert von null Prozent nicht empirisch gemessen wurde. Er folgt aus der Garantie, dass das Schema eingehalten wird.
Für Software ist diese Garantie trotzdem wertvoll. Ein unbekannter Enum-Wert oder ein erfundener Tool-Name kann einen Workflow technisch zerstören. Eine falsche, aber gültige Entscheidung ist ein anderes Fehlerbild und lässt sich zumindest über Schwellenwerte, Logging und Fallbacks behandeln.
Die Idee konkurriert auch mit besserem Structured Output bei normalen LLMs
Jev ist nicht der erste Weg, ein Modell auf strukturierte Antworten zu begrenzen. Aktuelle LLM-Stacks können JSON-Schemas, constrained decoding oder auf einzelne Auswahlwerte begrenzte Generierung verwenden.
Der Softwareentwickler Sean Goedecke argumentiert deshalb, ein Teil des Geschwindigkeitsvorteils müsse gegen optimierte Structured-Output-Verfahren verglichen werden und nicht nur gegen vollständige autoregressive Antworten. Für eine kleine Auswahl könne ein normales Modell theoretisch ebenfalls nach dem Prefill nur einen begrenzten Antwort-Token erzeugen und mehrere solcher Entscheidungen batchen.
Das macht Jev nicht automatisch überflüssig. TypeSafe trainiert das Modell speziell für solche Entscheidungen, liefert Wahrscheinlichkeitsverteilungen als eigentliche API und baut die Parallelisierung in das Produkt ein. Aber die relevante Vergleichsfrage ist enger als „Jev gegen ChatGPT“.
Interessant wäre ein unabhängiger Test gegen ein starkes Modell, das für exakt dieselben Choice-, Score- und Noul-Aufgaben mit möglichst wenig autoregressiver Ausgabe optimiert wurde.
Für Agenten könnte Jev eher Kontrollschicht als Agent sein
Jev selbst plant keinen langen Task, schreibt keinen Patch und erklärt keine Entscheidung in mehreren Absätzen. Gerade deshalb passt das Modell an Stellen, an denen ein Agent eine schnelle externe Entscheidung braucht.
Ein Agent könnte beispielsweise einen Tool-Call vorbereiten und Jev separat bewerten lassen, ob der Vorgang eine bestimmte Risikoschwelle überschreitet. Ein Trace könnte auf Eskalationsbedarf geprüft werden. Ein Incident-System könnte hunderte Alerts klassifizieren, bevor teurere Modelle oder Menschen die wenigen unsicheren Fälle übernehmen.
Die fehlende Textausgabe verändert dabei auch das Debugging. Ein Entwickler bekommt die Entscheidung und ihre Wahrscheinlichkeitsverteilung, aber keine freie Begründung. Für nachvollziehbare Produktionssysteme müssten deshalb mindestens Input-State, verwendetes Schema, Wahrscheinlichkeiten, Schwellenwerte und der daraus resultierende Codepfad sauber protokolliert werden.
Jev ist damit weniger ein Ersatz für ein Frontier-LLM als ein Versuch, eine bestimmte Aufgabe aus dem LLM-Stack herauszulösen: kleine probabilistische Entscheidungen, die häufig, schnell und direkt innerhalb von Software getroffen werden müssen.
Ob dafür tatsächlich eine eigene Modellklasse nötig ist, lässt sich am Tag nach dem Launch noch nicht beantworten. TypeSafe hat für Jev bislang vor allem eigene Evals veröffentlicht. Der technisch interessante Test beginnt, sobald unabhängige Entwickler dieselben Workflows gegen optimierte Structured-Output-Setups und eigene Ground-Truth-Daten laufen lassen.
Quellen
TypeSafe AI: Introducing System One Models & Jev https://typesafe.ai/blog/introducing-system-one-models-and-jev
TypeSafe AI Docs: Introduction https://docs.typesafe.ai/introduction
TypeSafe AI: Workflow evals https://evals.typesafe.ai/
Sean Goedecke: Jev means structured output is interesting again https://www.seangoedecke.com/jev-means-structured-output-is-interesting-again/
The Register: TypeSafe AI debuts model for machines that plays Doom https://assets.theregister.com/2026/09/16/2026/