Jev: das KI-Modell, das nichts schreibt, sondern entscheidet

Für wen

Alle, die in ihrer Software an Stellen ein Sprachmodell rufen, an denen am Ende nur eine Entscheidung herauskommt — einsortieren, weiterleiten, bewerten, freigeben.

Was du danach kannst

Verstehen, was ein Entscheidungsmodell von einem Sprachmodell unterscheidet, an welchen Stellen es sich lohnt, und wie ein erster Aufruf aussieht.

Stand

September 2026

Was Jev ist

Jev ist das erste Modell einer Gattung, die sein Hersteller TypeSafe AI „System One Model" nennt. Die Dokumentation beschreibt sie als „a class of AI models built to make fast, structured decisions that software can use directly" — also Modelle, die schnelle, strukturierte Entscheidungen treffen, mit denen ein Programm unmittelbar weiterarbeiten kann (docs.typesafe.ai, abgerufen am 20.09.2026). Vorgestellt wurde es am 15. September 2026.

Der Unterschied zu allem, was du bisher von KI kennst, steckt im ersten Satz auf der Herstellerseite: „LLMs produce words for people. Jev produces typed decisions and is more like code: reliable, fast, self-consistent, and type-safe." Sprachmodelle produzieren Wörter für Menschen, Jev produziert typisierte Entscheidungen und ist damit eher wie Programmcode (typesafe.ai, abgerufen am 20.09.2026).

Das ist keine Marketingfigur, sondern eine harte Einschränkung. Jev kann ausdrücklich nichts anderes. In der Dokumentation steht, die Modelle „do not write replies, produce code, or generate explanations of their reasoning" — sie schreiben keine Antworten, erzeugen keinen Code und begründen ihre Entscheidung nicht. Du bekommst eine Zahl, keinen Grund.

Die drei Fragen, die Jev beantworten kann

Es gibt genau drei Sorten Fragen, und das ist das ganze Modell:

Auswahl (Choice): Du gibst Optionen vor, Jev nennt eine davon — und dazu, wie sich die Wahrscheinlichkeit auf alle Optionen verteilt. „Geht es in diesem Ticket um Abrechnung, Technik oder etwas anderes?"

Bewertung (Score): Du gibst eine Skala mit beschrifteten Stufen vor, Jev ordnet ein. „Wie dringend ist das — kann warten, diese Woche, heute?"

Wahrscheinlichkeit (Noul): Eine Ja/Nein-Frage, beantwortet mit einer Zahl zwischen 0 und

1. Nicht „ja", sondern „zu 0,95 ja". Das ist der Unterschied, auf den es später ankommt.

Der Kniff liegt darin, dass du alle drei in einem einzigen Aufruf stellen kannst. Die Dokumentation sagt dazu: „Adding questions barely changes the response time and costs only the tokens for the extra questions, which are cheap. Asking a question you might not need is close to free." Eine zusätzliche Frage kostet also kaum Zeit und kaum Geld — eine Frage zu stellen, die man vielleicht gar nicht braucht, ist beinahe umsonst (docs.typesafe.ai, abgerufen am 20.09.2026).

Wichtig dabei: Die Fragen wissen nichts voneinander. „Questions in the same request are independent: one answer does not become context for another question." Du kannst also nicht fragen „und falls ja, dann…" — jede Frage steht für sich.

Ein Ticket, drei Fragen, ein Aufruf

Das Beispiel aus der Dokumentation ist ein Ticket aus dem Kundendienst, und es zeigt die Sache besser als jede Erklärung. Der Zustand ist eine einzige Kundennachricht, daran hängen drei Fragen unterschiedlicher Art:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

with TypeSafeClient() as client:
    response = client.system_one(
        state={"document": "I was charged twice. Please fix this ASAP."},
        questions={
            "billing": Noul(instructions="Is this ticket about billing?"),
            "tone": Choice(
                instructions="What is the customer's tone?",
                criteria={"calm": None, "frustrated": None, "angry": None},
            ),
            "urgency": Score(
                instructions="How urgent is this ticket?",
                criteria=["can wait", "this week", "today"],
            ),
        },
    )

Zurück kommt kein Satz, sondern je Frage ein Eintrag. So sieht ein solcher Eintrag für eine Auswahl-Frage aus — das Beispiel stammt aus der Schnittstellen-Referenz und gehört zu einem anderen Aufruf, zeigt den Aufbau aber genau so, wie er auch hier zurückkäme:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.88, "technical": 0.12, "sales": 0.0 },
      "confidence": 0.81
    }
  },
  "usage": { "input_tokens": 318, "output_tokens": 34 }
}

Daran lohnt sich ein zweiter Blick (docs.typesafe.ai, abgerufen am 20.09.2026). choice ist die Entscheidung, probabilities zeigt, wie knapp sie war, und confidence sagt, wie sicher sich das Modell ist. Genau diese beiden Zusatzangaben sind der Grund, warum man so ein Modell überhaupt vor ein Programm setzt: Du kannst eine Schwelle ziehen. Alles über 0,8 läuft durch, alles darunter landet bei einem Menschen. Mit einem Sprachmodell, das „Abrechnung" antwortet, geht das nicht — es klingt bei einem Zufallstreffer genauso überzeugt wie bei einem sicheren.

Wann sich das lohnt — und wann das Sprachmodell bleibt

Eine ehrliche Einordnung dazu kommt von LangChain, die Jev in ihre eigene Werkzeugkette eingebaut haben: „Jev isn't a drop-in replacement for an LLM. It doesn't generate text." Es ersetzt also kein Sprachmodell, sondern übernimmt die Stellen davor und dahinter (langchain.com, 17.09.2026, abgerufen am 20.09.2026).

Wofür es eingesetzt wird

Fünf Tage nach der Veröffentlichung lässt sich das schon recht gut sagen, weil die Einbindungen bei den großen Anbietern öffentlich sind.

Den nächsten Schritt in einem Ablauf wählen. Vercel nennt das als ersten offiziellen Anwendungsfall: „Choosing the next tool or subagent in an agent loop" (vercel.com, 16.09.2026, abgerufen am 20.09.2026). LangChain hat daraus eine Zwischenschicht gebaut, die Jev fragt, welches Modell eine Anfrage bedienen soll.

Prüfen, bevor etwas passiert. LangChains Baustein legt Jev einen geplanten Werkzeugaufruf vor und bricht ab, bevor er ausgeführt wird. Das ist der Fall, der mich am meisten überzeugt: eine Zwischenprüfung, deren Wartezeit im Zehntelsekundenbereich niemanden stört, die aber verhindert, dass eine Automatik etwas Dummes tut.

Einsortieren und vorsortieren. Tickets, Dokumente, Kontobewegungen — mit dem oben beschriebenen Schwellwert, unterhalb dessen ein Mensch übernimmt. Der Hersteller führt dieses Muster selbst als eigenen Abschnitt seiner Dokumentation.

Suchen ohne Vektordatenbank. Das ist der technisch eleganteste Fall. Die Schwäche einer Auswahl-Frage ist, dass sich die Wahrscheinlichkeiten immer zu 1 addieren — eine Zeile gewinnt also auch dann, wenn keine passt. Die Dokumentation löst das, indem parallel eine Ja/Nein-Frage mitläuft, deren Wahrscheinlichkeit „doesn't depend on the other options, so it can fall near zero when the document has no answer": Sie kann gegen null gehen, wenn das Dokument die Antwort schlicht nicht enthält (docs.typesafe.ai, abgerufen am 20.09.2026). Damit erkennt man „steht hier nicht drin" — was Ähnlichkeitssuche notorisch schlecht kann.

Was es nicht kann

Hier wird es interessant, und zwar aus einem ungewöhnlichen Grund: Die ehrlichste Quelle über Jevs Schwächen ist TypeSafe selbst. Der Hersteller pflegt eine Seite, auf der steht, wo das Modell danebenliegt. Wörtlich: „jev-1.13 is fast, calibrated, and good at common-sense judgment but it is not perfect" (docs.typesafe.ai, abgerufen am 20.09.2026). Was dort aufgeführt ist:

• Rechnen: „Jev is not a calculator."
• Zählen: „jev-1.13 does not count reliably."
• Datumsangaben: Welches von zwei Daten früher liegt, wie weit sie auseinanderliegen oder ob eines in einen Zeitraum fällt — laut Hersteller unzuverlässig.
• Wörtlichkeit: „jev-1.13 answers the question you wrote, not the one you meant." Es beantwortet die Frage, die du geschrieben hast, nicht die, die du gemeint hast.
• Große Zustände: Je mehr Beiwerk im übergebenen Text steht, das mit der Entscheidung nichts zu tun hat, desto ungenauer wird die Antwort.
• Angriffe: „State is data, and jev-1.13 does not treat it as hostile by default." Der übergebene Zustand ist für das Modell erst einmal nur Inhalt — Text, der es gezielt in eine Richtung schieben soll, kann die Antwort verschieben.

Der letzte Punkt verdient eine eigene Warnung, denn er steht quer zu dem, was Jev gerade zugeschrieben wird.

Eine unabhängige Einzelmessung gibt es immerhin. Mike Taylor hat zwölf Textpassagen mit je vier Prüffragen durchlaufen lassen und kam auf einen Median von 0,35 Sekunden je Passage gegenüber 8,83 Sekunden für Claude Fable 5.1 bei hoher Anstrengungsstufe — bei sechs von sieben gefundenen eingebauten Fehlern gegenüber sieben von sieben. Sein eigenes Fazit: Er wolle „a more thorough accuracy check before putting it into production", also eine gründlichere Prüfung, bevor das in den Betrieb geht (every.to, 15.09.2026, abgerufen am 20.09.2026).

Für deutsche Texte gilt eine Einschränkung

Das geht in den meisten Berichten unter, ist hier aber der wichtigste Satz. Die Modellseite schreibt: „English is the primary training language and where accuracy is currently best. Other languages, including CJK scripts, are handled but not equally well; test on your own content before relying on Jev for a non-English workload, and pay close attention to Confidence when routing." Englisch ist also die primäre Trainingssprache und dort liegt die Genauigkeit derzeit am besten; andere Sprachen werden verarbeitet, aber nicht gleich gut — mit der ausdrücklichen Aufforderung, vor einem nicht-englischen Einsatz an eigenen Inhalten zu messen und beim Weiterleiten genau auf den Konfidenzwert zu achten (docs.typesafe.ai, abgerufen am 20.09.2026).

Wer also deutsche Tickets, Mails oder Formulare einsortieren will, kann das nicht einfach annehmen. Nimm fünfzig Fälle, bei denen du die richtige Antwort kennst, lass sie durchlaufen und vergleiche. Das ist eine Stunde Arbeit und ersetzt jede Hochrechnung aus einem Blogartikel — auch aus diesem.

Selbst ausprobieren

Du brauchst ein Konto bei TypeSafe und einen Schlüssel aus der Verwaltungsoberfläche; die Dokumentation verweist dafür auf console.typesafe.ai. Der Schlüssel gehört in die Umgebungsvariable TYPESAFE_API_KEY. Zum Zugang selbst steht im Ankündigungsbeitrag, man hole Entwickler „off the waitlist as quickly as we can" — es gibt also eine Warteliste, und wie lange man darauf steht, ist nicht dokumentiert.

Der Baukasten für Python verlangt mindestens Version 3.10:

pip install typesafe-sdk

Für JavaScript und TypeScript, ab Node.js 20:

npm install @typesafe-ai/sdk

Wer nur einmal sehen will, wie sich das anfühlt, braucht gar keinen Baukasten. Der Schnellstart zeigt den nackten Aufruf:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
  {
    "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": {
      "urgency": {
        "type": "noul",
        "instructions": "Does this message express urgency?"
      }
    }
  }
EOF

Und in JavaScript sieht der kleinste sinnvolle Aufruf so aus:

import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const response = await client.systemOne({
  state: { document: "I was charged twice. Please fix this ASAP." },
  questions: {
    category: choice("What is this ticket about?", {
      billing: null,
      technical: null,
      other: null,
    }),
  },
});

console.log(response.answers.category.choice);

Wenn du schon über einen Vermittlungsdienst gehst, ist Jev dort ebenfalls zu haben — bei Vercel unter der Kennung typesafe-ai/jev (vercel.com), bei Cloudflare unter typesafe/jev (developers.cloudflare.com), bei OpenRouter unter typesafe/jev-1.13 (openrouter.ai), alle abgerufen am 20.09.2026. Achtung dabei: Vercel benutzt eine eigene Schreibweise, dort heißt die Ja/Nein-Frage boolean statt noul. Die Beispiele aus der Hersteller-Dokumentation laufen also nicht unverändert. In der Dokumentation von TypeSafe habe ich zu diesen Wegen nichts gefunden — wer sie nutzt, hält sich an die Anleitung des jeweiligen Anbieters.

Was es kostet

Der Preis ist die eigentliche Nachricht. Die Modellseite nennt 42 US-Dollar je Milliarde Token Eingabe, also 0,042 Dollar je Million — und dazu einen knappen Satz: „Output tokens are free." Im Ankündigungsbeitrag steht es blumiger, „FREE (too cheap to meter)", zu billig zum Abrechnen. Das ergibt Sinn, wenn man verstanden hat, dass es gar keine Ausgabe im üblichen Sinn gibt: Es entsteht kein Text, nur eine Zahl.

Dazu die übrigen Eckdaten der Modellseite, alle abgerufen am 20.09.2026: 64.000 Token je Anfrage, wobei Zustand und längste Einzelfrage zusammen 32.000 nicht überschreiten dürfen. 250.000 Token je Sekunde und 1.200 Anfragen je Minute — mit dem ausdrücklichen Hinweis, dass sich diese Durchsatzgrenzen derzeit ohne Ankündigung ändern können. Nur Text — „No image, audio, or video input". Auf Kundendaten wird nicht trainiert (docs.typesafe.ai). Die Antwortzeit von 70 bis 500 Millisekunden steht nicht dort, sondern im Ankündigungsbeitrag (typesafe.ai/blog, 15.09.2026, abgerufen am 20.09.2026).

Meine Einordnung

Ich halte die Gattung für richtig und das Modell für zu jung, um darauf etwas Wichtiges zu stellen. Richtig ist die Gattung, weil in jeder zweiten Automatisierung, die ich baue, ein großes Sprachmodell für eine Aufgabe gerufen wird, deren ganzes Ergebnis ein Wort ist — und dafür bezahlt man Wartezeit, Geld und ein Ergebnis, das man erst wieder auseinandernehmen muss. Eine Zahl mit Konfidenz ist für ein Programm schlicht das bessere Format.

Zu jung ist es, weil es zum Zeitpunkt dieses Beitrags fünf Tage alt ist, in einer frühen Zugangsphase steckt, in genau einer Version vorliegt und weder eine Zusicherung zur Verfügbarkeit noch eine Ankündigungsfrist für Versionswechsel veröffentlicht hat. Selbst die Durchsatzgrenzen stehen ausdrücklich unter Vorbehalt — sie „can change without notice", schreibt die Modellseite. Was davon in einem Jahr noch steht, weiß heute niemand.

Der vernünftige Umgang damit ist deshalb nicht „einbauen" oder „ignorieren", sondern an einer Stelle ausprobieren, an der ein Fehler nichts kostet: eine Vorsortierung, hinter der ohnehin ein Mensch sitzt. Da siehst du an deinen eigenen Daten, ob die Genauigkeit für deinen Fall reicht — auch auf Deutsch.