Das Jev-Modell ist das erste System One Model von TypeSafe AI: ein KI-Modell für eng begrenzte, strukturierte Urteile, die Software direkt verarbeiten kann. Statt einen Absatz zu schreiben, erhält Jev einen state als Text oder JSON, bewertet eine oder mehrere typisierte Fragen und liefert Auswahlwerte, Scores, Wahrscheinlichkeiten und Konfidenzwerte.

Damit ist Jev für Klassifizierung, Routing, Ranking, Verifikation und Guardrails interessant. Es ersetzt jedoch weder ein Chat- oder Coding-Modell noch einen Rechner oder eine deterministische Geschäftsregel.

Stand der Prüfung: 19. September 2026. Jev startete am 15. September im Early Access. Das derzeit dokumentierte Modell ist jev-1.13.0. Preise, Limits, Latenz- und Leistungsangaben stammen aus dem Release-Beitrag und der Dokumentation von TypeSafe. Wir erhielten kein vertrauliches Briefing, führten keinen kostenpflichtigen Jev-Benchmark durch und reproduzierten die Tempo- und Qualitätsangaben von TypeSafe nicht unabhängig.

Das Jev-Modell im Überblick

Merkmal	Aktuell dokumentierter Wert
Entwickler	TypeSafe AI
Modellklasse	System One Model
Aktuelle versionierte ID	`jev-1.13.0`
Stabiler Alias	`jev-latest`
Endpoint	`POST https://api.typesafe.ai/v1/systemone`
Eingabe	Nur Text, als String, JSON-Objekt oder Array von Textwerten
Ausgabe	Typisierte Antworten als `Choice`, `Score` und `Noul`
Kontext	64K Tokens pro Request; 32K für `state` plus längste Frage
Preis der direkten API	$0.042 pro 1M Input-Tokens; Output derzeit kostenlos
Veröffentlichte Standardlimits	250,000 Input-Tokens/s und 1,200 Requests/Minute; Änderungen möglich
Latenzangabe des Anbieters	70–500 ms Ende-zu-Ende
Status	Early Access

Die offizielle Schreibweise lautet Jev. Es handelt sich nicht um ein ausgeschriebenes Akronym J-E-V. TypeSafe zufolge ist das Modell nach dem Ökonomen William Stanley Jevons benannt. „System One“ verweist auf das schnelle, intuitive System 1 aus Daniel Kahnemans Thinking, Fast and Slow.

Was macht Jev tatsächlich?

Jev lässt sich als probabilistische semantische Funktion verstehen:

text

unstrukturierter oder strukturierter Zustand
  + vordefinierte Fragen und Antworträume
  -> typisierte Entscheidungen und Wahrscheinlichkeitsverteilungen

Ein gewöhnliches LLM ist darauf optimiert, eine Sequenz fortzusetzen und Strings zu erzeugen. Selbst im JSON mode bittet eine Anwendung ein generatives Modell, eine Antwort zusammenzustellen. Jev verzichtet auf freie Generierung. Der Aufrufer definiert zuerst die mögliche Ausgabeform; anschließend bewertet das Modell jede Frage anhand desselben Zustands.

TypeSafe nennt das Trainingsverfahren Reinforcement Learning for Calibrated Decisions (RLCD). Ziel ist nicht nur die Auswahl einer Antwort, sondern Wahrscheinlichkeiten zu erzeugen, deren Konfidenz über Gruppen von Vorhersagen mit der Genauigkeit übereinstimmt. Calibration ist statistisch: Eine Wahrscheinlichkeit von 0.8 sollte bei vergleichbaren Fällen ungefähr 80% Trefferquote entsprechen. Sie garantiert nicht, dass eine einzelne Antwort richtig ist.

Choice, Score und Noul

Jev bietet drei Fragetypen. Sie sind der Kern der API und keine nachträglich auf die Generierung gesetzten Formatoptionen.

Primitive	Form der Frage	Rückgabewert	Geeigneter Einsatz
`Choice`	Welche Option passt?	Gewählte Option, Wahrscheinlichkeit jeder Option, Konfidenz	Intent-Routing, Klassifizierung, Ranking einer geschlossenen Menge
`Score`	Wo liegt dies auf einer beschriebenen Skala?	Gewichteter Score, Wahrscheinlichkeiten je Stufe, Konfidenz	Schweregrad, Qualität, Dringlichkeit, Risikoklassen
`Noul`	Ist diese Aussage wahr?	Wahrscheinlichkeit von 0 bis 1	Erkennung, Verifikation, binäre Gates

Ein Choice kann bis zu 255 Optionen enthalten. Ein Score akzeptiert 2 bis 10 beschriebene Stufen. Noul hat kein separates Konfidenzfeld, weil sein Wert zwischen 0 und 1 bereits die Wahrscheinlichkeit für „ja“ ist.

Mehrere Fragen in einem Request werden unabhängig und parallel anhand desselben Zustands bewertet. Das ist für Workflows mit mehreren Signalen nützlich, bedeutet aber auch, dass eine Antwort nicht automatisch eine andere bedingt. Hängt Frage B von Frage A ab, muss der Code diese Abhängigkeit ausdrücklich abbilden.

Beispiel für einen Jev-API-Request

Dieses verkürzte Beispiel folgt dem von TypeSafe dokumentierten Request-Format. Eine Support-Nachricht wird in einem Aufruf nach Zuständigkeit, Frustration und Dringlichkeit bewertet.

bash

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "My payouts have failed for three days and I am losing sales. Please help now.",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "Payments, invoices, or refunds",
          "technical": "Bugs, outages, or integrations",
          "sales": "Pricing, upgrades, or new accounts"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "How frustrated is the customer?",
        "criteria": ["Calm", "Frustrated", "Very angry"]
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "Does this message convey urgency?"
      }
    }
  }'

Die Antwort behält dieselben Frage-IDs bei. department liefert einen der drei erlaubten Strings sowie eine Verteilung über alle drei. frustration kann ein Dezimalwert sein, weil es die wahrscheinlichkeitsgewichtete Position zwischen den vorgegebenen Stufen darstellt. is_urgent gibt nur die Wahrscheinlichkeit für „ja“ zurück.

Die konkreten Werte hängen von Eingabe, Kriterien und Modellversion ab. Der Code, nicht das Modell, legt fest, welche Wahrscheinlichkeit hoch genug für eine Aktion ist.

Jev im Vergleich zu LLM und Klassifikator

Jev besetzt eine nützliche Zwischenposition, doch die Unterschiede sind entscheidend.

Dimension	Jev	Generatives LLM	Klassischer Klassifikator
Hauptaufgabe	Begrenzte semantische Urteile	Generierung oder Schlussfolgern in freiem Text	Vorhersage von Labels für eine feste gelernte Aufgabe
Ausgaberaum	Pro Request definiert	Auch mit Schema grundsätzlich offen	Durch Training festgelegt
Neue Rubrik	Im Request beschreiben	Prompt oder tool schema	Meist Daten sammeln und neu trainieren
Wahrscheinlichkeiten	Vollwertige API-Ausgabe	Oft nicht verfügbar oder schlecht kalibriert	Üblich, sofern vom Modell ausgegeben
Textgenerierung	Nein	Ja	Nein
Beste Rolle	Semantische Verzweigung im Workflow	Erstellen, Erklären, Programmieren, mehrstufiges Denken	Stabile Aufgabe mit hohem Volumen und gelabelten Daten

Jev als „bloßen Klassifikator“ zu bezeichnen, übersieht seine Flexibilität zur Request-Zeit. „Schnelleres LLM“ übersieht, dass es keine Erklärung, E-Mail oder Code erzeugen und keine neue Antwort außerhalb der vorgegebenen Optionen erfinden kann.

Auch JSON mode ist nicht derselbe Vertrag. JSON mode begrenzt die Syntax generierten Textes. Jev begrenzt den Antwortraum selbst und liefert die vollständige Verteilung der Entscheidung. Das ist nur dann wertvoll, wenn sich das Problem als begrenzte Fragen formulieren lässt.

Preis, Kontext und Durchsatz

TypeSafe listet Jev 1.13 derzeit mit $0.042 pro Million Input-Tokens, also $42 pro Milliarde. Output ist „too cheap to meter“ und damit kostenlos, obwohl die Response weiterhin die Output-Token-Nutzung ausweist.

Eingabevolumen	Direkte Jev-Inputkosten
10,000 Tokens	$0.00042
1 Million Tokens	$0.042
100 Millionen Tokens	$4.20
1 Milliarde Tokens	$42.00

Dies sind Rechenbeispiele, keine gemessenen Rechnungen. Nicht enthalten sind Retries, Vorverarbeitung, ein weiteres Modell in einer Cascade, Speicherung, Engineering-Aufwand und künftige Preisänderungen.

Der Kontextvertrag enthält zwei gleichzeitige Grenzen: Zustand und alle Fragen zusammen müssen in 64K Tokens passen; Zustand plus die längste einzelne Frage in 32K. Mehr Kontext ist nicht automatisch besser. TypeSafes eigener Jaggedness-Leitfaden beschreibt sinkende Genauigkeit durch irrelevante Details.

Die veröffentlichten Limits von 250,000 Tokens/s und 1,200 Requests/Minute gelten pro Account und sind keine Geschwindigkeitszusage für einen einzelnen Request. TypeSafe weist ausdrücklich darauf hin, dass sie sich während des Early Access dynamisch ändern.

Wie belastbar ist die Tempoangabe?

TypeSafe berichtet 70–500 ms Ende-zu-Ende-Antwortzeit und erklärt, Jev könne bei „System-One-förmigen“ Anfragen und vergleichbarer Intelligenz 40–200-mal schneller als Frontier-Modelle sein. Das Launch-Material hebt zudem eine Workflow-Evaluation hervor, in der Jev 193.6-mal schneller und 444.6-mal günstiger war.

Diese Werte stammen vom Anbieter und nicht aus einem neutralen Benchmark. TypeSafe nennt mehrere wichtige Einschränkungen:

Die veröffentlichten Latenzmessungen wurden meist von Firmen-Laptops an der US-Westküste gestartet, wo auch der Dienst betrieben wurde.
Die Workflow-Aufgaben erstellte TypeSafes Model-Capabilities-Team; Selektionsbias ist daher möglich.
Die Referenzantwort war der Mittelwert aus GPT-6 Astra und Fable 5.1 und kann diese Modellfamilien begünstigen.
Konkurrierende LLM-Aufrufe liefen über OpenRouter und TypeSafes strukturierten Wrapper.
TypeSafe bezeichnet die Werte 193.6x und 444.6x selbst als oberes Ende der erwartbaren realen Gewinne.

Die richtige Schlussfolgerung ist enger: Jevs beschränkte Ausgabe und parallele Auswertung eröffnen für begrenzte Entscheidungen einen glaubwürdigen Weg zu sehr niedriger Latenz und geringen Kosten. Sie beweisen nicht, dass Jev bei jeder Aufgabe 40–200-mal schneller ist, einem Frontier-LLM in allgemeiner Intelligenz entspricht oder bei Generierung und mehrstufigem Denken überlegen ist.

„Null Halluzinationen“ braucht eine genaue Definition

TypeSafe bewirbt Jev als Modell, das nicht halluzinieren kann. Der belastbare Teil ist Schema-Sicherheit: Eine Choice-Antwort kann keine vierte Option erfinden, und der Dienst sollte keine Prosa liefern, wenn der Code eine Zahl erwartet. TypeSafe zufolge wird diese Ausgabekonformität konstruktiv garantiert und nicht als empirische Null-Fehler-Rate gemessen.

Eine typkorrekte Antwort kann dennoch semantisch falsch sein. TypeSafes Dokumentation zu Jev 1.13 nennt Fehler bei:

zu wörtlichem Lesen und übersehener impliziter Absicht;
unzuverlässigem Zählen, Rechnen, Datums- und Zahlenverständnis;
mehrstufiger indirekter Schlussfolgerung;
langen Zuständen mit irrelevanten Details;
adversarial content oder prompt injection;
widersprüchlichen instructions und criteria;
Wahrscheinlichkeiten, die bei getrennt formulierten Fragen keine intuitiven Identitäten erfüllen;
jeder Aufgabe, die Textgenerierung verlangt.

Die praktische Aussage lautet daher keine Ausgabe außerhalb des Schemas, nicht keine Entscheidungsfehler. Produktionscode braucht weiterhin Evaluationsdaten, konservative Schwellen, deterministische Validierung und einen Eskalationspfad.

Wo Jev gut passt

Jev ist ein starker Kandidat, wenn drei Bedingungen erfüllt sind: Der Antwortraum ist begrenzt, das Urteil ist semantisch statt mathematisch, und eine andere Softwarekomponente verarbeitet das Ergebnis.

Workload	Warum Jev passen kann	Wichtiger Guardrail
Routing von Support-Tickets	Geschlossene Teammenge und nützliches Unsicherheitssignal	`other` ergänzen; geringe Konfidenz prüfen
Filterung von RAG-Passagen	Relevanz, Widerspruch oder Injection-Risiko bewerten	Quellenprüfung außerhalb des Modells behalten
LLM-Input/Output-Guardrails	Viele enge Prüfungen in einem Request parallel ausführen	Adversarial Input als getestetes Threat Model behandeln
Entity Matching	Bewerten, ob zwei Datensätze dasselbe Objekt meinen	Exakte IDs und Invarianten durch Code erzwingen
Content-Moderation	Begrenzte Labels und Schweregrade	Schwellen je Schadenskategorie abstimmen
Agent-Action-Routing	Tool wählen oder Anwendbarkeit einer Skill prüfen	Berechtigungen und destruktive Aktionen im Code prüfen

Für Schreiben, Zusammenfassen, Codegenerierung, offene Extraktion, exakte Arithmetik, Datumsvergleiche oder lange Kausalketten ist Jev keine gute Standardwahl. Exakte Logik gehört in normalen Code; wenn die Ausgabe erst erzeugt werden muss, passt ein generatives oder Reasoning-Modell.

Checkliste für den Produktionseinsatz

Deterministische Arbeit bleibt im Code. Daten parsen, Elemente zählen, Geld berechnen und Berechtigungen prüfen braucht kein Modell.
Atomare Fragen stellen. „Sollen wir diesen Antrag genehmigen?“ in die unabhängigen Fakten zerlegen, die die Entscheidung bestimmen.
Jede Grenze beschreiben. other oder none ergänzen, wenn Choice nicht vollständig ist, und konkrete Score-Stufen formulieren.
Mit der eigenen Verteilung testen. Englisch ist die primäre Trainingssprache; TypeSafe sagt, dass andere Sprachen einschließlich CJK nicht gleich gut funktionieren.
Aktionen statt nur Vorhersagen kalibrieren. Reversibles UI-Routing und Automation mit hoher Auswirkung dürfen nicht dieselbe Konfidenzschwelle nutzen.
Nach dem Tuning eine Version fixieren. jev-latest kann sich ändern. Die versionierte Response-ID protokollieren und Schwellen bewusst migrieren.
Unsicherheit eskalieren. Mehrdeutige Fälle an Menschen oder ein langsameres Reasoning-Modell geben, statt eine Entscheidung zu erzwingen.
Kosten pro akzeptierter Aufgabe messen. Retries, Fehlentscheidungen, manuelle Prüfung und nachgelagerte LLM-Aufrufe einbeziehen, nicht nur Tokenpreise.

Ist Jev über OmniaKey verfügbar?

Zum Zeitpunkt der Prüfung nicht. Im aktuellen Katalog und Code von OmniaKey fanden wir keine Jev-Route. Endpoint und Preise in diesem Artikel gehören zur direkten TypeSafe-API; die Veröffentlichung dieses Leitfadens kündigt keine OmniaKey-Integration an.

Die tatsächliche Gateway-Verfügbarkeit steht im aktuellen OmniaKey-Modellkatalog. Für offene Coding- und Agent-Aufgaben behandelt der Leitfaden zu Coding-Agent-Modellen die generativen Modelle einer anderen Ebene des Stacks.

Fazit

Jev lässt sich am besten als neue Schnittstelle für semantische Entscheidungen verstehen, nicht als universeller LLM-Ersatz. Die überzeugende Idee ist einfach: Unscharfe Urteile übernimmt das Modell, die Ausgabe wird auf einen vom Programm verstandenen Typ begrenzt, Unsicherheit wird sichtbar, und Komposition sowie exakte Logik bleiben im Code.

Die aktuelle API ist auf dem Papier ungewöhnlich günstig und auf niedrige Latenz ausgelegt. Das Modell befindet sich zugleich im Early Access, verarbeitet nur Text, ist auf Englisch am stärksten und weist dokumentierte Schwächen bei Mathematik, Datumsangaben, Indirektion, irrelevantem Kontext und adversarial input auf. Bis vergleichbare unabhängige Tests vorliegen, sind Tempo- und Intelligenzvergleiche als Anbieterbelege zu behandeln.

Häufig gestellte Fragen

Ist Jev ein LLM?

TypeSafe nennt Jev ein System One Model und kein LLM. Es versteht natürlichsprachliche Zustände, erzeugt aber keinen freien Text. Die geprüften Quellen legen nicht genug Architekturdetails offen, um unabhängig zu beurteilen, wie ähnlich das zugrunde liegende Netz einem herkömmlichen Sprachmodell ist.

Kann Jev GPT oder Claude ersetzen?

Nein. Jev kann nicht schreiben, erklären, programmieren oder offen generieren. Es kann ein generatives Modell ergänzen, indem es Requests routet, Ausgaben prüft, Evidenz bewertet oder entscheidet, wann ein langsameres Modell laufen soll.

Was bedeuten Choice, Score und Noul?

Choice wählt aus einer geschlossenen Menge und liefert die Wahrscheinlichkeiten aller Optionen. Score ordnet den Zustand auf 2 bis 10 beschriebenen Stufen ein. Noul liefert die Wahrscheinlichkeit, dass eine Ja/Nein-Aussage wahr ist.

Hat Jev wirklich null Halluzinationen?

Es kann keinen Wert außerhalb des deklarierten Antworttyps erzeugen und beseitigt damit viele Parsing- und Schemafehler. Es kann dennoch eine falsche, aber gültige Option wählen oder eine irreführende Wahrscheinlichkeit vergeben. Typsicherheit ist nicht semantische Korrektheit.

Was kostet die Jev-API?

TypeSafe listet Jev 1.13 mit $0.042 pro Million Input-Tokens; Output ist derzeit kostenlos. Direkte Preise und Rate Limits können sich während des Early Access ändern.

Unterstützt Jev Bilder oder Deutsch?

Jev verarbeitet nur Text. Strings, JSON-Objekte und Arrays müssen letztlich Text enthalten. Deutsch und andere Sprachen werden akzeptiert, doch laut TypeSafe ist Englisch derzeit am stärksten. Nicht-englische Workloads sollten mit eigenen Daten evaluiert werden.

Primärquellen

Die Belege wurden am 19. September 2026 geprüft. Jev ändert sich im Early Access schnell; Modell-ID, Preis, Limits, Sprachverhalten und Datenbedingungen sollten vor dem Produktionseinsatz erneut geprüft werden.

OmniaKey entdecken Aktuellen Modellkatalog prüfen

Was ist das Jev-Modell?

JEV-MODELL