Jev-Modell erklärt: API-Preise, Einsatz und direkter Zugang

Aktualisiert am 24. Oktober 2026: Jev 1.14 ergänzt, jetzt als jev-latest ausgeliefert.

Das Jev-Modell ist das System One Model von TypeSafe AI. Es nimmt einen state als Text oder JSON plus typisierte Fragen und liefert typisierte Entscheidungen statt Prosa. Aufruf mit model: "jev-latest", heute Jev 1.14: $0.042 pro 1M Input-Tokens, Output kostenlos, 64K Tokens pro Request.

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

Das Jev-Modell im Überblick

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 ist neu in Jev 1.14?

Jev 1.14 (jev-1.14.0) ist seit dem 14. Oktober 2026 stabil, und sowohl jev-latest als auch jev-preview zeigen auf diese Version. Preis und Standardlimits bleiben gleich; neu sind zwei experimentelle Funktionen, die pro Request aktiviert werden.

Beide liegen hinter Headern, die TypeSafe „Danger Zone“ nennt. TypeSafe-Danger-Zone-Images: true aktiviert Bildmaterial und den neuen Fragetyp Box, der Koordinaten im Bild zurückgibt. TypeSafe-Danger-Zone-Long-Context: true erweitert das Fenster auf 262K Tokens pro Request und pro Frage. Standardmäßig ist beides aus, ohne Header ändert sich also nichts. Der TypeSafe-Release-Beitrag (geprüft am 24. Oktober 2026) verlangt, sie auf eigene Verantwortung zu nutzen. Wir haben diese beiden Header über OmniaKey noch nicht getestet.

Requests mit jev-1.13.0 funktionieren weiter, und der Standard-Body bleibt gleich: state, questions und ein optionales model. Zurückzurollen ist eine Zeile, also teste zuerst deine echten Aufgaben mit 1.14 und verschiebe dann den Produktionsverkehr.

Was macht Jev tatsächlich?

Jev lässt sich als probabilistische semantische Funktion verstehen:

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.

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 sendet das von TypeSafe dokumentierte Request-Format über OmniaKey. Eine Support-Nachricht wird in einem Aufruf nach Zuständigkeit, Frustration und Dringlichkeit bewertet.

curl https://api.omniakey.com/v1/alpha/search \
  -H "Authorization: Bearer $OMNIAKEY_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.

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. Die d1-Modelle von Liquid AI treffen dieselbe Art begrenzter Entscheidungen und sind ebenfalls als offene Gewichte verfügbar; siehe den Überblick zur Liquid AI d1 API.

Auch JSON mode ist nicht dasselbe. 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 Fragen mit festen Optionen formulieren lässt.

Jev-API-Preise

TypeSafe listet Jev 1.14 wie 1.13 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.

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.

Jev-Kontextfenster und Rate Limits

Der Kontext hat 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.

Das sind TypeSafe-Direktlimits. Ein OmniaKey-Konto kann eigene Zugangs-, Preis- und Ratenbedingungen haben. Vollständige Requests, Antwortfelder, Python/Node.js und Fehlerbehandlung stehen in der Jev-API-Integrationsanleitung.

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:

1. Die veröffentlichten Latenzmessungen wurden meist von Firmen-Laptops an der US-Westküste gestartet, wo auch der Dienst betrieben wurde.
2. Die Workflow-Aufgaben erstellte TypeSafes Model-Capabilities-Team; Selektionsbias ist daher möglich.
3. Die Referenzantwort war der Mittelwert aus GPT-6 Astra und Fable 5.1 und kann diese Modellfamilien begünstigen.
4. Konkurrierende LLM-Aufrufe liefen über OpenRouter und TypeSafes strukturierten Wrapper.
5. 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.

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

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

Ist Jev über OmniaKey verfügbar?

Ja. Jev ist über OmniaKey als jev-latest verfügbar. Diese ID zeigt heute auf Jev 1.14, und OmniaKey reicht sie unverändert an TypeSafe weiter, ein neuer Anschluss bei einem Versionswechsel ist also nicht nötig. Eine TypeSafe-Early-Access-Bewerbung oder Wartelistenfreigabe ist nicht nötig. Erstellen Sie im API-Key-Dashboard einen zweckgebundenen Schlüssel und verwenden Sie ihn sofort. Der Katalogeintrag steht auf der Modellseite zu Jev 1.14.

Senden Sie den nativen Jev-Body an POST https://api.omniakey.com/v1/alpha/search. Dies ist ein eigener Jev-Endpoint und kein OpenAI-Chat-Completions-Endpoint; behalten Sie daher die gezeigte Struktur aus state und questions bei. Der Smoke Test vom 20. September lieferte HTTP 200, das aufgelöste Modell jev-1.13.0, typisierte answers und Token-usage. Derselbe Request löst heute jev-1.14.0 auf. Für offene Coding- und Agent-Aufgaben behandelt der Leitfaden zu Coding-Agent-Modellen generative 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 standardmäßig 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 Anbieterangaben 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 zuweist, Ausgaben prüft, Antworten 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.

Wie nutze ich die Jev-API ohne Warteliste?

Erstellen Sie einen OmniaKey API Key, senden Sie den nativen Jev-Body an POST https://api.omniakey.com/v1/alpha/search und setzen Sie model auf jev-latest. Ein separates TypeSafe-Konto oder eine Early-Access-Freigabe ist nicht nötig.

Was kostet die Jev-API?

TypeSafe listet Jev 1.14 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.

Welche Version ist jev-latest gerade?

Jev 1.14 (jev-1.14.0). Auch jev-preview zeigt derzeit auf denselben Build. Zum Fixieren jev-1.13.0 oder jev-1.14.0 im Request angeben.

Unterstützt Jev Bilder oder Deutsch?

Jev verarbeitet standardmäßig Text. Strings, JSON-Objekte und Arrays müssen letztlich Text enthalten. Jev 1.14 fügt Bildmaterial hinter dem Header TypeSafe-Danger-Zone-Images: true hinzu, den TypeSafe als experimentell kennzeichnet. Deutsch und andere Sprachen werden akzeptiert, doch laut TypeSafe ist Englisch derzeit am stärksten. Nicht-englische Workloads sollten mit eigenen Daten evaluiert werden.

Kann ich Jev kostenlos nutzen?

Der geprüfte Direktpreis berechnet Eingabe mit $0.042 je Million Tokens und macht Ausgabe kostenlos. Kostenlose Ausgabe bedeutet keinen kostenlosen Request. Testzugänge, Aktionsguthaben und Gateway-Abrechnung haben eigene Bedingungen; prüfe dein Konto statt allgemeines Gratisguthaben anzunehmen.

Wie viele Parameter hat Jev?

Die offizielle Modellseite von TypeSafe (geprüft am 24. Oktober 2026) nennt Kontext und Eingabeformate, aber keine Parameterzahl. 64K und 32K sind Tokengrenzen, keine Modellparameter. Daraus lassen sich weder Gewichtedateigröße noch Hardwarebedarf für lokalen Betrieb ableiten.

Primärquellen

• TypeSafe: Jev 1.14 Release (Englisch) (geprüft am 24. Oktober 2026)
• TypeSafe: Introducing System One Models & Jev (Englisch)
• TypeSafe-Dokumentation: Introduction (Englisch)
• TypeSafe-Dokumentation: System One (Englisch)
• TypeSafe-Dokumentation: Models and pricing (Englisch) (geprüft am 24. Oktober 2026)
• TypeSafe-Dokumentation: HTTP API reference (Englisch)
• TypeSafe-Dokumentation: Confidence (Englisch)
• TypeSafe-Dokumentation: Jev 1.13 jaggedness (Englisch)

Preise, Limits und Details zu Jev 1.14 wurden am 24. Oktober 2026 erneut geprüft. Der frühere Gateway-Smoke-Test bleibt auf den 20. September datiert; dies ist kein neuer kostenpflichtiger Test. Jev ändert sich schnell, prüfe daher Version und Kontobedingungen vor Produktion erneut.