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

> Jev-Modell im Überblick: Jev 1.14 läuft als jev-latest für $0.042 pro 1M Input-Tokens, Output gratis, ein API-Key.

- Canonical HTML: https://omniakey.com/de/blog/jev-model-explained
- Markdown: https://omniakey.com/de/blog/jev-model-explained.md
- Published: 2026-09-19 (updated 2026-10-24)
- Author: Kiki, COO at OmniaKey
- Language: de
- Category: Guide
- Reading time: 11 min
- All posts: https://omniakey.com/blog/llms.txt

---

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.

> **Jetzt über OmniaKey verfügbar; Stand der Prüfung: 24. Oktober 2026.** Eine TypeSafe-Early-Access-Bewerbung oder Wartelistenfreigabe ist nicht nötig. Die aktuelle Version ist `jev-1.14.0`, ausgeliefert als `jev-latest`. Preise, Limits, Latenz- und Leistungsangaben stammen aus dem Release-Beitrag und der Dokumentation von TypeSafe. Der Smoke Test vom 20. September erhielt HTTP 200 von `jev-1.13.0`; dieser Verbindungstest ist kein unabhängiger Benchmark für Latenz, Kalibrierung oder Qualität.

## Das Jev-Modell im Überblick

|Merkmal|Aktueller Wert|
|-|-|
|Entwickler|TypeSafe AI|
|Modellklasse|System One Model|
|Aktuelle versionierte ID|`jev-1.14.0`|
|Alias|`jev-latest` (SDK-Standard) und `jev-preview`; beide zeigen auf 1.14.0|
|Direkter TypeSafe-Endpoint|`POST https://api.typesafe.ai/v1/systemone`|
|OmniaKey-Endpoint|`POST https://api.omniakey.com/v1/alpha/search`|
|Eingabe|Standardmäßig Text, als String, JSON-Objekt oder Array von Textwerten. Bildeingabe in 1.14 ist optional|
|Ausgabe|Typisierte Antworten als `Choice`, `Score` und `Noul`. `Box` in 1.14 ist experimentell|
|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|Jev 1.14 seit 14. Oktober 2026; `jev-1.13.0` weiterhin verfügbar|

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.

|Merkmal|Jev 1.13|Jev 1.14|
|-|-|-|
|Status|Nutzbar, wenn die ID fixiert wird|Aktuelle Version seit 14. Oktober 2026|
|Preis|$0.042 pro 1M Input|$0.042 pro 1M Input|
|Standardlimits|64K pro Request, 32K pro Frage|64K pro Request, 32K pro Frage|
|Experimentelle Funktionen|Keine|Bildmaterial, Box-Fragen, 262K Kontext|

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:

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

```bash
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.

|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. 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](https://omniakey.com/de/blog/liquid-ai-d1-open-models-api-local-deployment).

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.

|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.

## Jev-Kontextfenster und Rate Limits

|Offizielles Standardlimit von Jev 1.14|Geltungsbereich|
|-|-|
|64K tokens|Gesamter State und alle Fragen einer Anfrage|
|32K tokens|State plus längste einzelne Frage|
|250,000 tokens/s|Aktueller Token-Durchsatz des Direktkontos, veränderlich|
|1,200 Anfragen/Minute|Aktuelle Anfragerate des Direktkontos, veränderlich|
|Standardmäßig Text|Strings, JSON-Objekte oder Arrays mit Text. In 1.14 kommt Bildeingabe per Danger-Zone-Header dazu. Kein Audio, kein Video|

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](https://omniakey.com/de/blog/jev-api-guide).

## 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.

|Workload|Warum Jev passen kann|Wichtiger Guardrail|
|-|-|-|
|Zuweisung 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|
|Zuweisung von Agent-Aktionen|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

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](https://omniakey.com/de/dashboard/tokens) einen zweckgebundenen Schlüssel und verwenden Sie ihn sofort. Der Katalogeintrag steht auf der [Modellseite zu Jev 1.14](https://omniakey.com/de/jev-latest).

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](https://omniakey.com/de/blog/best-llm-coding-agents) 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)](https://typesafe.ai/blog/jev-1-14) (geprüft am 24. Oktober 2026)
- [TypeSafe: Introducing System One Models & Jev (Englisch)](https://typesafe.ai/blog/introducing-system-one-models-and-jev)
- [TypeSafe-Dokumentation: Introduction (Englisch)](https://docs.typesafe.ai/introduction)
- [TypeSafe-Dokumentation: System One (Englisch)](https://docs.typesafe.ai/concepts/system-one)
- [TypeSafe-Dokumentation: Models and pricing (Englisch)](https://docs.typesafe.ai/models) (geprüft am 24. Oktober 2026)
- [TypeSafe-Dokumentation: HTTP API reference (Englisch)](https://docs.typesafe.ai/api)
- [TypeSafe-Dokumentation: Confidence (Englisch)](https://docs.typesafe.ai/confidence)
- [TypeSafe-Dokumentation: Jev 1.13 jaggedness (Englisch)](https://docs.typesafe.ai/model-jaggedness/jev-1.13)

_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._