Jev von TypeSafe AI: Was ist neu, wie es funktioniert und Alternativen (2026)
Bei den meisten Modell-Launches in diesem Jahr ging es darum, mehr zu können. Bei diesem hier geht es darum, absichtlich weniger zu tun.
TypeSafe AI hat ein Modell veröffentlicht, das weder chattet noch schreibt oder sich selbst erklärt. Es beantwortet Fragen mit typisierten Werten und Wahrscheinlichkeiten. Das ist die gesamte Produktoberfläche.
Dieser Leitfaden erklärt, was das Modell ist und wie seine drei Fragetypen funktionieren. Er behandelt auch die Preisgestaltung, worin es laut Anbieter schlecht ist und wie es sich in die tatsächliche Arbeit der meisten Teams einfügt.
Was veröffentlicht wurde
Jev ist das Flaggschiff-Modell von TypeSafe. Laut der offiziellen Dokumentation des Anbieters ist es zudem „das erste System One-Modell“.
Der Ansatz geht von einer Kritik daran aus, wie der Rest dieser Kategorie funktioniert. Große Sprachmodelle, so die Dokumentation, „sind darauf ausgelegt, Text zu generieren, den Menschen lesen können“. Wenn man eine Entscheidung benötigt, die vom Code verarbeitet werden soll, „führt das zu einer Diskrepanz“.
Die Dokumentation beschreibt diese Diskrepanz genauer. Man „zwingt ein Textgenerierungssystem dazu, strukturierte Entscheidungen auszugeben, um die Ergebnisse dann wieder in etwas zu parsen, auf das sich der Code verlassen kann“.
Die angebotene Alternative macht diesen Umweg überflüssig. Jev „wertet typisierte Fragen anhand eines Zustands aus und liefert direkt strukturierte Ergebnisse zurück. Keine Textgenerierung, kein Parsen“.
Die Website des Unternehmens selbst stellt Jev ans Ende einer Entwicklungslinie. Frühe Sprachmodelle, dann vortrainierte LLMs, dann RLHF-Chat-Modelle, dann RLVR-Reasoning-Modelle. Jetzt RLCD, was als „Reinforcement Learning für kalibrierte Entscheidungen“ ausgeschrieben wird.
Was ein System One-Modell ist
Der Name ist entliehen, worauf die Dokumentation auch direkt hinweist. Er „stammt von dem Konzept, das Daniel Kahneman in seinem Buch Thinking, Fast and Slow bekannt gemacht hat“.
System 1 ist schnell und intuitiv. System 2 ist langsamer und bedächtig. Hier „liegt der Schwerpunkt auf schnellen, gezielten Entscheidungen“.
Die funktionale Definition ist enger gefasst als die Metapher. Es handelt sich um „eine Klasse von KI-Modellen, die dafür entwickelt wurden, schnelle, strukturierte Entscheidungen zu treffen, die Software direkt nutzen kann“. Ein solches Modell „wertet einen Zustand aus und liefert typisierte Antworten und Wahrscheinlichkeiten zurück“.
Ein einziger Satz unterscheidet Jev von allem anderen auf dem Markt. „Wie ein LLM versteht ein System One-Modell Eingaben in natürlicher Sprache. Es liefert typisierte Entscheidungen und Wahrscheinlichkeiten anstelle von generiertem Text.“
Auch das, was das Modell nicht tut, wird vom Anbieter klar benannt. System One-Modelle „schreiben keine Antworten, erstellen keinen Code und generieren keine Erklärungen für ihre Argumentation“.
Die drei Fragetypen
Man promptet Jev nicht. Man definiert einen Antwortraum, und das Modell wählt daraus aus.
Es gibt drei Primitive. Die Dokumentation nennt für jedes ein Beispiel.
| Primitive | Question | Answer space | Output |
|---|---|---|---|
| Choice | Which team should handle this ticket? | billing, technical oder account | choice: "billing" |
| Score | How frustrated is this customer? | 0 = ruhig, 1 = frustriert, 2 = sehr frustriert | score: 1.4 |
| Noul | Does this message request a refund? | True oder False | noul: 0.95 |
Choice wählt eine Option aus einer definierten Menge aus. Score bewertet anhand geordneter, beschreibender Stufen. Noul gibt die Wahrscheinlichkeit zurück, mit der eine Ja/Nein-Frage wahr ist.
Das Score-Beispiel lohnt einen zweiten Blick. Die Antwort lautet 1.4, nicht 1. Jev ordnet den Fall zwischen zwei benannten Stufen ein, anstatt auf die nächste Stufe auf- oder abzurunden. Das ist ein völlig anderes Ausgabeformat als alles, was ein Textmodell zurückgibt.
Was es kostet und was es akzeptiert
Die Preisseite ist ungewöhnlich übersichtlich. Das schreibt man nicht oft über den Launch eines Modells.
Das aktuelle Modell ist jev-1.13.0. Der Preis beträgt $42 pro Milliarde Token oder $0,042 pro Million. In der Dokumentation wird ausdrücklich darauf hingewiesen, dass die Abrechnung „pro Input-Token“ erfolgt und „Output-Token kostenlos“ sind.
Die Ratenbegrenzungen sind mit 250.000 Token pro Sekunde und 1.200 Anfragen pro Minute angegeben. Die Kontextlänge beträgt 64k Token pro Anfrage. Davon stehen 32k für den Zustand plus die längste Frage zur Verfügung.
Die Eingabe besteht ausschließlich aus Text. In der Dokumentation wird erwähnt, dass Jev „Strings, JSON-Objekte und Text-Arrays auswertet“. Zudem heißt es: „Bilder, Audio und Video werden (noch) nicht unterstützt.“
Alles läuft über einen einzigen Endpunkt: POST /v1/systemone. Ein model-Feld bestimmt, welches Modell den Aufruf verarbeitet.
| Eigenschaft | Wert |
|---|---|
| Modell | jev-1.13.0 |
| Preis | $42 pro Mrd. Token / $0,042 pro Mio. Token, nur Input |
| Output-Token | Kostenlos |
| Rate Limits | 250.000 Token pro Sekunde; 1.200 Anfragen pro Minute |
| Kontext | 64k pro Anfrage; 32k für Zustand plus längste Frage |
| Eingabetypen | Nur Text |
Das Vertrauensniveau (Confidence) ist der entscheidende Punkt
Der Preis sorgt für Schlagzeilen. Der Umgang mit dem Vertrauensniveau (Confidence) ist jedoch die interessantere Designentscheidung.
Jede Choice- und Score-Antwort enthält eine probabilities-Eigenschaft für die verschiedenen Optionen oder Stufen. Die Dokumentation erklärt, wie dies zu interpretieren ist. Eine Verteilung, die sich „auf ein einziges Ergebnis konzentriert, bedeutet eine sichere Antwort; eine breit gestreute Verteilung bedeutet eine unsichere“.
Eine separate confidence-Eigenschaft fasst diese Verteilung in einer einzigen Zahl von 0 bis 1 zusammen. Der dokumentierte Zweck ist, „dass Sie einen Schwellenwert festlegen können, ohne die Berechnung selbst durchführen zu müssen“.
Die Begründung für die Bereitstellung dieses Werts wird als Grundsatz formuliert. „Wenn ein intelligentes System, ob Mensch oder Maschine, keine ehrliche Unsicherheit ausdrücken kann, kann man dem System nicht vertrauen.“
Was man dadurch gewinnt, ist eher eine Routing-Regel als eine bessere Antwort. Hohe Konfidenz geht direkt durch. Niedrige Konfidenz geht an einen Menschen. Die Dokumentation beschreibt dies als die Entscheidung, „wann gehandelt und wann an eine Person oder ein Reasoning-Modell eskaliert werden soll“.
Jeder, der schon einmal eine Klassifizierungspipeline in Betrieb genommen hat, weiß, warum das wichtig ist. Der Eskalationspfad, nicht der Genauigkeitswert, entscheidet darüber, ob das System den Kontakt mit echten Daten überlebt.
Worin das Modell laut Anbieter schlecht ist
TypeSafe veröffentlicht eine Seite namens „Model Jaggedness“ (Modell-Unregelmäßigkeit), Stand 17.09.2026. Sie listet die dem Unternehmen bekannten Fehlermodi auf. So etwas zeitgleich mit einem Launch zu veröffentlichen, ist selten und erspart allen Beteiligten eine Runde Rätselraten.
Das Fazit ist aufrichtig. Jev 1.13 „ist schnell, kalibriert und gut bei Entscheidungen mit gesundem Menschenverstand, aber es ist nicht perfekt“.
Drei Schwachstellen werden direkt beim Namen genannt. Es „tut sich möglicherweise schwer mit Aufgaben, die zusätzliche Ebenen der Indirektion erfordern“. Es „kann in seinem Verständnis sehr wortwörtlich sein“. Und es „hat Probleme mit Aufgaben, die numerische Präzision erfordern“.
Die Tabelle der Fehlermodi stellt jedem Problem eine Abhilfe gegenüber. Zwei davon sind für jeden, der ein Pilotprojekt plant, besonders erwähnenswert.
- Für Mathe und Zahlen lautet der dokumentierte Rat: „Belassen Sie die Arithmetik im Code.“
- Bei einem großen Zustand voller irrelevanter Details heißt es: „Zuerst filtern; senden Sie nur das, was für die Frage benötigt wird.“
Beide Punkte weisen auf dieselbe Design-Annahme hin. Dies ist eine Entscheidungs-Engine, kein Taschenrechner und kein Suchindex. Sie funktioniert am besten, wenn das umgebende System die Fragestellung bereits eingegrenzt hat.
Wie sich dies in Ihre bestehende Arbeit einfügt
Im Beispiel des Anbieters selbst verbirgt sich eine klare Arbeitsteilung. Diese beim Namen zu nennen, entscheidet darüber, ob dieser Launch für Sie überhaupt relevant ist.
Der dokumentierte Rückerstattungs-Workflow baut einen Zustand auf und stellt mehrere unabhängige Fragen auf einmal. Anschließend kombiniert er die Antworten „mit deterministischen Prüfungen im Code“ und leitet den Fall „zur Aktion oder Überprüfung“ weiter.
Jeder Schritt dort setzt einen Entwickler, eine Anwendung und ein hohes Anfragevolumen voraus. Die Kosten pro Token müssen erst ein echter Budgetposten sein, bevor sich das Ganze auszahlt.
Die meiste Berichterstattung hat ein anderes Format. Sie haben eine Datei statt eines kontinuierlichen Datenstroms. Die Entscheidungen sind ein Mittel zum Zweck und nicht das Produkt selbst. Am Ende muss ein Dokument stehen, das jemand liest.
Die Klassifizierung von viertausend Zeilen Kundenfeedback ist der mittlere Teil dieser Aufgabe. Das Ende ist eine Zusammenfassung, die die drei Hauptthemen nennt und die Ausnahmen hervorhebt.
Diese zweite Hälfte ist genau das, was ein dateibasierter Workspace erledigt. Sie laden den Export hoch und beschreiben die Kategorien in natürlicher Sprache. Die Zeilen werden beschriftet zurückgegeben, und der Bericht, der sie erklärt, wird im selben Durchgang erstellt. Powerdrill Bloom funktioniert genau so, und die kostenlose Version deckt bereits grundlegende Präsentationen, Dokumente, Tabellen und Bilder ab.
Die beiden konkurrieren nicht um denselben Platz. Das eine ist eine API, die Sie in ein Produkt einbinden. Das andere ist der Ort, an den eine Tabellenkalkulation geschickt wird, wenn jemand bis Donnerstag eine Antwort braucht. Wenn Ihre Version dieses Problems als Datei vorliegt, probieren Sie Powerdrill Bloom aus.
Für die tabellenbasierte Version der Kategorisierungsaufgabe gibt es eine Anleitung zur Kategorisierung von Excel-Daten. Für die Version zur Themenerkennung finden Sie eine Übersicht über Tools zur Analyse von Kundenfeedback.
Alternativen, die einen Vergleich wert sind
Drei Ansätze decken denselben Bereich ab. Welcher der richtige ist, hängt hauptsächlich vom Volumen ab.
Mehrzweckmodelle mit strukturierter Ausgabe. Jeder größere Anbieter beschränkt Antworten mittlerweile auf ein Schema. Sie erhalten ein einziges Modell für die Bewertung und die Generierung. Der Nachteil sind Generierungspreise für reine Bewertungsarbeit und die Notwendigkeit, die Kalibrierung selbst durchzuführen.
Klassische Klassifikatoren. Ein feinabgestimmtes kleines Modell oder ein Gradient-Boosted Tree ist noch günstiger und absolut vorhersehbar. Das gilt unter der Voraussetzung, dass Sie über gelabelte Daten und ein mobiles Label-Set verfügen. Eine in Prosa verfasste Richtlinie versteht ein solches Modell jedoch nicht.
Dateibasierte Analyse-Workspaces. Diese behandeln die Bewertung als einen Schritt innerhalb der Erstellung eines Endergebnisses. Keine API, kein Schema, keine Budgetierung pro Token. Allerdings können sie auch nicht in einen Anfragepfad integriert werden.
| Wenn Ihre Situation wie folgt aussieht | Sollten Sie sich Folgendes ansehen |
|---|---|
| Millionen von Entscheidungen innerhalb eines Produkts | Ein reines Entscheidungsmodell |
| Mischung aus Bewerten und Entwerfen, geringes Volumen | Ein allgemeines Modell mit strukturierter Ausgabe |
| Stabile Labels und reichlich Trainingsdaten | Einen klassischen Klassifikator |
| Eine Datei, die zu einem Bericht werden soll | Einen dateibasierten Workspace |
Es gibt eine entsprechende Übersicht über Tools zur Berichterstellung, die sich mit dem letzten Punkt befasst.
Für wen das jetzt von Bedeutung ist
Teams, die ein hohes Volumen an Entscheidungen innerhalb eines Produkts verarbeiten, haben das klarste Argument für Jev. Ticket-Routing, Moderations-Queues, Lead-Qualifizierung und Vorprüfungen der Berechtigung passen alle in dieses Schema. Das Muster ist eine präzise Frage, die tausende Male am Tag gestellt wird und eine Verzweigung im Code füttert.
Teams, die im Rahmen von Analysen nur gelegentlich Klassifizierungen vornehmen, haben die schwächsten Argumente. Die wirtschaftlichen Vorteile, die Jev bei großen Mengen attraktiv machen, fallen bei einigen tausend Zeilen nicht ins Gewicht. Zudem benötigt man danach immer noch ein Tool, um die Zusammenfassung zu schreiben.
Alle anderen können eher ein Vokabular übernehmen, als dass sie ein neues Tool einführen müssten. Die Trennung von schneller Entscheidung und langsamer Synthese ist eine nützliche Perspektive auf die eigene Pipeline. Sie bleibt nützlich, unabhängig davon, ob Sie jemals eine Anfrage an diese API senden.
Noch ein praktischer Hinweis für alle, die das Modell evaluieren: Lesen Sie die Jaggedness-Seite vor der Preisseite. Zu wissen, wo die Schwächen eines Modells liegen, prägt das Pilotprojekt weitaus mehr als das Wissen um die Kosten.
Häufig gestellte Fragen
Was ist ein System One-Modell?
Es handelt sich um eine Klasse von Modellen, die dafür entwickelt wurden, schnelle, strukturierte Entscheidungen zu treffen, die Software direkt nutzen kann. Es wertet einen Zustand aus und liefert typisierte Antworten und Wahrscheinlichkeiten zurück. Der Name bezieht sich auf Kahnemans System 1, die schnelle und intuitive Denkweise. Im Gegensatz zu einem Chat-Modell schreibt es keine Antworten, generiert keinen Code und erklärt seine Argumentation nicht.
Wie viel kostet Jev?
Der veröffentlichte Preis für jev-1.13.0 beträgt $42 pro Milliarde Token oder $0,042 pro Million. Die Abrechnung erfolgt ausschließlich auf Basis der Input-Token, Output-Token sind kostenlos.
Was kann Jev als Eingabe verarbeiten?
Ausschließlich Text, in Form von Strings, JSON-Objekten oder Text-Arrays. Laut Dokumentation werden Bilder, Audio und Video noch nicht unterstützt. Der Kontext beträgt 64k Token pro Anfrage, wobei 32k für den Zustand plus die längste Frage zur Verfügung stehen.
Wie unterscheidet es sich davon, ein LLM nach JSON zu fragen?
Beide verstehen Eingaben in natürlicher Sprache. Der Unterschied liegt darin, was zurückgegeben wird und wie das Modell trainiert wurde. Jev liefert typisierte Entscheidungen mit einer Wahrscheinlichkeitsverteilung und einem Konfidenzwert. Die Kalibrierung wird über Gruppen von Vorhersagen hinweg gemessen, sodass sie keine Garantie dafür bietet, dass jede einzelne Antwort korrekt ist.
Worin ist Jev nicht gut?
Die Jaggedness-Seite des Anbieters listet wortwörtliches Verständnis, Mathe und Zahlen sowie den Vergleich von Datum und Uhrzeit auf. Ebenso werden Indirektion, große Zustände voller irrelevanter Details, gegnerische Inhalte (Adversarial Content) und widersprüchliche Kriterien genannt. Der dokumentierte Rat für arithmetische Fälle lautet, die Arithmetik im Code zu belassen.
Quellen: TypeSafe AI-Dokumentation — Introduction, System One, Models, Confidence und Jev 1.13 Jaggedness, docs.typesafe.ai, Stand 18. September 2026.