Seit Jahren sind Sprachmodelle im Chat besser als die meisten Menschen – und trotzdem läuft in den meisten Unternehmen kaum ein Prozess vollautomatisch über KI. Mit dieser Beobachtung beginnt TypeSafe AI die Vorstellung von Jev, einem Modell, das einen ungewöhnlichen Weg geht: Es schreibt keinen einzigen Satz. Jev ist kein Large Language Model (LLM) im üblichen Sinn, sondern ein Klassifizierer mit dem Sprachverständnis eines Frontier-Modells.
Dieser Beitrag erklärt, was Jev ist, warum der Verzicht auf Text kein Mangel, sondern die Konstruktionsidee ist, was das Modell von einem LLM unterscheidet – und wo die Grenzen der Herstellerangaben liegen. Grundlage sind der Ankündigungsbeitrag von TypeSafe AI vom 15. September 2026 und die öffentliche Dokumentation. Stand: 21. September 2026.
Was ist Jev?
Jev ist das erste sogenannte System One Model von TypeSafe AI. Gründer Diogo Almeida hat nach eigenen Angaben bei OpenAI an den Verfahren mitgearbeitet, die Sprachmodelle zum Befolgen von Anweisungen gebracht haben. TypeSafe arbeitete zwei Jahre im Stillen und hat Jev am 15. September 2026 im Early Access geöffnet.
Die Kurzformel des Herstellers: ein Funktionsaufruf mit Frontier-Intelligenz – unstrukturierter Zustand hinein, typisierte probabilistische Entscheidungen heraus. Der Name „System One“ geht auf Daniel Kahnemans Schnelles Denken, langsames Denken zurück: System 1 ist das schnelle, intuitive Urteil, System 2 das langsame, bewusste Nachdenken. Reasoning-Modelle sind System 2. Jev soll System 1 sein. Benannt ist das Modell nach dem Ökonomen William Stanley Jevons, dessen Paradox besagt, dass effizientere Nutzung eines Rohstoffs die Nachfrage nicht senkt, sondern erhöht.
Ein Klassifizierer, kein Textgenerator
Ein Aufruf an Jev besteht aus zwei Teilen: einem State – dem Text oder JSON, über das geurteilt werden soll – und einer oder mehreren Fragen. Für die Fragen gibt es genau drei Typen:
| Typ | Beantwortet | Rückgabe |
|---|---|---|
| Choice | Welche dieser Optionen trifft zu? | gewählte Option, Wahrscheinlichkeit je Option, Konfidenz |
| Score | Welche Stufe auf einer geordneten Skala? | Wert, Wahrscheinlichkeit je Stufe, Konfidenz |
| Noul | Stimmt diese Aussage? | Wahrscheinlichkeit für „Ja“ zwischen 0 und 1 |
Ein Beispiel aus der Dokumentation: Eine Support-Nachricht geht ein, das Modell soll entscheiden, welches Team zuständig ist und ob die Sache eilt (gekürzt).
{
"state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
"model": "jev-latest",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this",
"criteria": {
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions"
}
},
"is_urgent": {
"type": "noul",
"instructions": "The message conveys urgency or time-sensitivity"
}
}
}Zurück kommt kein Satz, sondern eine Struktur: "choice": "technical" mit den Wahrscheinlichkeiten technical: 0.85, billing: 0.15, sales: 0.0, einer Konfidenz von 0.78 und für die Dringlichkeit "noul": 1.0.
Genau das ist ein Klassifizierer: ein Modell, das eine Eingabe einer von mehreren vorgegebenen Klassen zuordnet und dafür eine Wahrscheinlichkeitsverteilung ausgibt. Neu ist nicht das Prinzip, sondern die Kombination. Ein klassischer Klassifizierer – etwa ein feinabgestimmtes BERT-Modell – wird für feste Klassen trainiert und braucht dafür gelabelte Daten. Bei Jev werden die Klassen erst im Aufruf in natürlicher Sprache definiert. Das Modell wird laut TypeSafe nicht mit Kundendaten nachtrainiert; dieselben Gewichte bedienen alle Kunden, die Fachlogik steckt in instructions und criteria.
Warum Jev keinen Text erzeugt
Der Verzicht auf Zeichenketten ist keine Einschränkung, die TypeSafe in Kauf nimmt, sondern der Hebel, aus dem alle anderen Eigenschaften folgen. TypeSafe formuliert es so: Strings aufzugeben, verleihe dem Modell „Superkräfte“. Vier Folgen lassen sich nachvollziehen.
Erstens: parallele statt sequenzielle Ausgabe. Ein LLM erzeugt Token für Token, jedes abhängig vom vorherigen. Das kostet Zeit, und die Ausgabe ist der teure Teil. Jev liest den State einmal und beantwortet alle Fragen parallel in einem Durchlauf. Deshalb sind Output-Token bei Jev kostenlos, abgerechnet wird nur die Eingabe.
Zweitens: Typsicherheit per Konstruktion. Wenn nur Werte aus einem vorab definierten Antwortraum möglich sind, kann die Antwort das Schema nicht verletzen. Es gibt nichts zu parsen, nichts zu validieren, keine Wiederholungsschleife wegen kaputtem JSON. TypeSafe nennt 0 % Typfehler – nicht als Messwert, sondern als mathematische Garantie.
Drittens: keine Halluzination im engen Sinn. Ein Modell, das nur aus drei Optionen wählen kann, kann keine vierte erfinden. Was es sehr wohl kann: die falsche der drei wählen. Dazu gleich mehr.
Viertens: Wahrscheinlichkeiten, mit denen Code arbeiten kann. Aus einem Text lässt sich Unsicherheit nur heraushören. Aus einer Verteilung lässt sie sich ablesen – und in ein if schreiben.
Jev und LLM im Vergleich
| Klassisches LLM | Jev (System One) | |
|---|---|---|
| Trainingsziel | Antworten, die Menschen bevorzugen (RLHF), oder überprüfbar korrekte Ergebnisse (RLVR) | kalibrierte Entscheidungen (RLCD) |
| Eingabe | unstrukturierter Text, Schwerpunkt Gesprächsverlauf | unstrukturierter Text, Schwerpunkt Programmzustand |
| Ausgabe | Zeichenketten – flexibel, aber zu parsen und zu prüfen | typisierte Werte aus vordefiniertem Antwortraum |
| Erzeugung | sequenziell, Token für Token | parallel, alle Antworten in einem Durchlauf |
| Unsicherheit | auf Nachfrage, laut TypeSafe oft zu selbstsicher und inkonsistent | bei jeder Antwort: Wahrscheinlichkeiten und Konfidenz |
| Antwortzeit | Sekunden bis Minuten bei Frontier-Modellen | laut TypeSafe 70 bis 500 Millisekunden |
| Stärke | Texte, Code, Dialog, mehrstufiges Schließen | klassifizieren, routen, bewerten, prüfen |
Die Tabelle folgt der Gegenüberstellung von TypeSafe. Wichtig ist die Lesart: Jev ist kein besseres LLM, sondern ein anderes Werkzeug. Ein LLM kann auch klassifizieren – Jev kann ausschließlich das.
RLCD: trainiert auf Ehrlichkeit über die eigene Unsicherheit
TypeSafe ordnet das eigene Verfahren als dritten Weg des Post-Trainings ein. RLHF (Reinforcement Learning from Human Feedback) hat aus vortrainierten Modellen Chatbots gemacht, indem es Antworten belohnt, die Menschen bevorzugen. RLVR (Reinforcement Learning with Verifiable Rewards) hat Reasoning-Modelle hervorgebracht, die in Mathematik und Code stark, aber langsam und teuer sind. RLCD – Reinforcement Learning for Calibrated Decisions – belohnt etwas anderes: dass die ausgegebene Wahrscheinlichkeit zur tatsächlichen Trefferquote passt.
Kalibriert heißt: Von allen Aussagen, denen das Modell 80 % gibt, treffen rund 80 % zu. TypeSafe begründet die Abkehr von RLHF damit, dass Präferenzoptimierung gefälliges Verhalten und selbstsicher klingende Halluzinationen belohnen kann. Was einen Menschen überzeugt, ist nicht automatisch verlässlich genug für unbeaufsichtigte Automatisierung.
Der Satz aus der Ankündigung, der das Problem am besten trifft: Wenn ein Modell eine Aufgabe in 95 % der Fälle lösen kann, aber nicht sagt, wann es in den übrigen 5 % ist, lässt sich diese Aufgabe nicht automatisieren.
„Kann nicht halluzinieren“ heißt nicht „kann nicht irren“
Diese Unterscheidung verdient einen eigenen Abschnitt, weil sie in der Berichterstattung schnell verloren geht. Jev kann keinen Wert außerhalb des Schemas erfinden. Jev kann aber die falsche Klasse wählen, eine Stufe zu hoch bewerten oder eine Aussage für wahr halten, die falsch ist. Die Dokumentation sagt das offen: Kalibrierung wird über Gruppen von Vorhersagen gemessen und garantiert nicht, dass eine einzelne Antwort stimmt.
Der Ausweg ist die Konfidenz. TypeSafe empfiehlt drei Bereiche: Bei hoher Konfidenz handelt das System automatisch, bei mittlerer fragt es nach oder markiert den Fall zur Prüfung, bei niedriger handelt es nicht und eskaliert an einen Menschen oder ein anderes System. Die Schwellen hängen vom Risiko ab – eine löschende Aktion braucht eine höhere Schwelle als eine lesende. „Ich weiß es nicht“ wird damit zu einem verwertbaren Signal statt zu einem Fehlerfall.
Was die Zahlen aussagen – und was nicht
TypeSafe nennt beeindruckende Werte und liefert die Einschränkungen gleich mit. Das ist ungewöhnlich und lobenswert, ändert aber nichts daran, dass es Herstellerangaben sind.
- Preis: 0,042 US-Dollar pro Million Input-Token, Output-Token kostenlos (Modell Jev 1.13, Stand der Dokumentation). Ob der Preis subventioniert ist, kann TypeSafe nach eigener Aussage nicht beweisen.
- Geschwindigkeit: 70 bis 500 Millisekunden je Aufruf. Die veröffentlichten Messungen laufen laut TypeSafe von Laptops an der US-Westküste, wo auch der Dienst betrieben wird. Aus Europa kommt Netzwerklatenz hinzu.
- Workflow-Evals: Die Aussagen „193,6-mal schneller“ und „444,6-mal günstiger“ stammen aus einer eigenen Evaluation. Als Referenz dient der Durchschnitt zweier Frontier-Modelle, die Workflows hat das eigene Team gebaut, und TypeSafe rechnet selbst damit, dass die Werte am oberen Ende realer Gewinne liegen.
- Halluzinationsraten der LLMs: Die Vergleichszahlen stammen von OpenRouter; TypeSafe weist auf eine wahrscheinliche Verzerrung hin.
Unabhängige Benchmarks liegen wenige Tage nach dem Start noch nicht vor. Wer Jev bewerten will, sollte es an eigenen Entscheidungen mit bekannter Wahrheit messen.
Wofür sich Jev eignet
TypeSafe spricht von „smarten if-Anweisungen“: Entscheidungsregeln, die zu unscharf für handgeschriebene Logik sind und zu eng für ein Sprachmodell mit freier Hand. Aus der Dokumentation ergeben sich vier Muster.
Intent-Routing vor dem LLM. Eingehende Anfragen werden erst klassifiziert und dann an den passenden Bearbeiter geleitet: deterministischer Code, ein spezialisiertes LLM oder ein Mensch. Das teure Modell läuft nur, wenn es gebraucht wird.
Zusammengesetzte Bewertungen. Statt „Bewerte diesen Lead“ stellt man zehn enge Fragen und gewichtet die Antworten im Code. Ändern sich die Prioritäten, ändert man Gewichte, keinen Prompt.
Prüfen und absichern. Ausgaben, Reasoning-Spuren und Prompts anderer Modelle lassen sich bewerten, etwa auf Jailbreak-Versuche oder Regelverstöße – schnell genug, um im Anfragepfad zu laufen.
Map-Reduce über große Datenbestände. Bei diesem Preis lassen sich Millionen Dokumente in strukturierte Merkmale verwandeln, auf denen dann klassische Modelle oder Auswertungen aufsetzen.
Die Bauanleitung dahinter ist klar: Der Kontrollfluss bleibt im Code, deterministische Regeln bleiben Code, und das Modell erscheint nur dort, wo programmierbarer gesunder Menschenverstand gebraucht wird. TypeSafe grenzt das ausdrücklich von Agenten ab, die ihren nächsten Schritt selbst wählen.
Wo die Grenzen liegen
Jev ersetzt kein LLM. Es schreibt keine Antwort an den Kunden, fasst nichts zusammen, erzeugt keinen Code und erklärt seine Entscheidung nicht. Für alles, was langsames Nachdenken braucht, empfiehlt TypeSafe selbst, die Aufgabe in kleine Fragen zu zerlegen – oder an ein Reasoning-Modell zu eskalieren.
Dazu kommen handfeste Einschränkungen zum Stand der Dokumentation: nur Texteingabe, keine Bilder, kein Audio. Englisch ist die Haupttrainingssprache; andere Sprachen werden verarbeitet, aber nicht gleich gut – für deutsche Inhalte heißt das: selbst testen und die Konfidenz ernst nehmen. Das Kontextbudget liegt bei 64.000 Token je Anfrage. Eine Choice-Frage fasst bis zu 255 Optionen. Der Zugang läuft über Early Access mit Warteliste, und die Rate Limits ändern sich laut TypeSafe derzeit dynamisch.
Technisch wichtig: Jev spricht keine Chat-Completions-Schnittstelle, sondern einen eigenen Endpunkt (POST /v1/systemone). Es ist also kein Modell, das sich per Austausch der Modell-ID hinter eine bestehende LLM-Anbindung hängen lässt. Die Integration ist ein eigener Baustein im Workflow.
Für Unternehmen in der EU kommt der Datenschutz hinzu. Der Dienst läuft nach Herstellerangabe an der US-Westküste, eine EU-Region nennt die Dokumentation nicht. TypeSafe stellt eine Data Processing Agreement bereit, die für Drittlandübermittlungen die EU-Standardvertragsklauseln vorsieht, trainiert nach eigenen Angaben nicht mit Kundendaten und bietet Zero Data Retention für Enterprise-Kunden. Personenbezogene Daten gehören vor einer Prüfung dieser Punkte nicht in den State.
Einordnung: schnelles Urteilen als eigener Baustein
Interessant ist Jev weniger als Produkt denn als Signal. Die letzten Jahre hat die Branche in eine Richtung optimiert: größere Modelle, längeres Nachdenken, mehr Autonomie. TypeSafe setzt den Gegenpunkt: kleinere Aufgaben, sofortige Antwort, keine Autonomie. Beides schließt sich nicht aus.
In unserem Beitrag zum AI Harness haben wir beschrieben, dass ein Agent aus mehr besteht als einem Modell: Schleife, Werkzeuge, Kontext, Gedächtnis, Berechtigungen, Verifikation, Orchestrierung. System-One-Modelle passen in genau die Bausteine, in denen ein generatives Modell fehl am Platz ist – Berechtigungen und Verifikation. Ob eine Aktion riskant ist, ob eine Ausgabe den Vorgaben entspricht, ob eine Anfrage an einen Menschen gehört: Das sind Klassifikationsfragen, und sie sollten schnell, günstig und mit ehrlicher Unsicherheit beantwortet werden.
Das Architekturmuster dahinter gilt unabhängig vom Anbieter: ein schnelles Modell entscheidet und routet, ein generatives Modell formuliert, ein Mensch übernimmt, wenn die Konfidenz nicht reicht. Wer heute Prozesse mit n8n oder in CompanyGPT automatisiert, baut diese Verzweigungen bisher mit LLM-Aufrufen und strukturierten Ausgaben – das funktioniert, ist aber langsamer und teurer als nötig. Den Unterschied zwischen festen Abläufen und Agenten haben wir im Beitrag Digitale Workflows vs. KI-Agenten ausgeführt. Welche Coding-Agenten und Orchestrierer es für die generative Seite gibt, zeigt unsere Übersicht der KI-Harnesses.
Fazit
Jev ist ein Klassifizierer, der sich wie ein Sprachmodell ansprechen lässt. Es erzeugt keinen Text, weil Text für Automatisierung das falsche Ausgabeformat ist: langsam zu erzeugen, aufwendig zu prüfen und ohne verwertbare Aussage über die eigene Sicherheit. Was Jev stattdessen liefert – typisierte Werte, Wahrscheinlichkeiten, Konfidenz, Antwortzeiten im Millisekundenbereich – ist das, was Code braucht, um eine Entscheidung zu übernehmen oder abzugeben.
Ob die Herstellerzahlen in der Praxis halten, muss sich zeigen; das Modell ist wenige Tage alt, der Betrieb liegt in den USA, und für deutsche Inhalte fehlt der Nachweis. Die Idee dahinter ist aber unabhängig von diesem einen Anbieter tragfähig: Nicht jede KI-Entscheidung braucht ein Modell, das auch Gedichte schreiben könnte.
Wir beobachten System-One-Modelle für unsere Kundenprojekte und unterstützen dabei, Prozesse so zu zerlegen, dass Code, schnelle Entscheidungsmodelle, generative Modelle und Menschen jeweils das tun, was sie am besten können. Sprechen Sie uns an, wenn Sie einen Prozess haben, der bisher an der Verlässlichkeit von KI-Entscheidungen scheitert.
