Jev-Tutorial: So baust du ein Decision-Modell in deine Automation ein

Wenn eine Automation wissen will, ob ein Ticket dringend ist, braucht sie keinen Absatz, sondern eine Entscheidung mit einer Zahl dahinter. Genau dafür hat TypeSafe AI Mitte September 2026 Jev veröffentlicht: ein Modell, das keinen Text erzeugt, sondern vordefinierte Fragen mit typisierten Werten und kalibrierten Wahrscheinlichkeiten beantwortet, in 70 bis 500 Millisekunden. Dieses Tutorial zeigt den kompletten Weg in die eigene Automation: Setup, die drei Fragetypen, die Muster, die den Unterschied machen, und die Stolpersteine, die dich ohne Vorwissen ein Wochenende kosten.

Key Takeaways (TL;DR)

• Ein-Wort-Prompts als Einstiegspunkt nehmen: Suche Prompts der Form “Antworte nur mit einem Wort” und ersetze sie durch einen typisierten Aufruf mit festem Antwortschema.
• Alle Fragen parallel stellen: Ein Aufruf beantwortet die komplette Fragenliste in einem Durchlauf. Stelle auch bedingte Fragen sofort und entscheide im Code, was zählt.
• Eine Schwelle pro Aktion setzen: Lege pro Aktion fest, ab welcher Confidence ein Fall automatisch läuft, nachgefragt wird oder an einen Menschen geht, und skaliere die Schwelle mit den Kosten eines Fehlers.
• State minimal und injection-fest halten: Hole und filtere Kontext im Code und behandle Text aus Nutzereingaben als potenziell feindlich.
• Version pinnen und selbst evaluieren: Feste Modellversion im Client, eigenes Testset vor dem produktiven Einsatz, Logging von Confidence und Modellversion bei jeder Entscheidung.

Basiert auf “Jev: Das kann das KI-Modell wirklich (10 Use Cases)” von Julian Ivanov. Das Original findest du hier: https://www.youtube.com/watch?v=CenkPFVn-vo. Ergänzt um “Das KI-Modell Jev liefert Entscheidungen statt Texte” von Tomislav Bezmalinović auf heise online: https://www.heise.de/news/KI-Modell-Jev-soll-Maschinen-schneller-entscheiden-lassen-11456995.html

Ein Decision-Modell hat einen anderen Vertrag als ein LLM

Ein Sprachmodell erzeugt jede Antwort Token für Token, auch das einzelne “Ja”, das dein Prompt erzwungen hat, und die aktuellen Reasoning-Modelle denken vorher zusätzlich schriftlich nach. Dein Code parst und validiert das Ergebnis hinterher und hofft, dass eines der erlaubten Wörter zurückkam. Jev dreht diesen Vertrag um: Rein geht der State, also der zu prüfende Text als String, JSON-Objekt oder Array, plus eine Liste typisierter Fragen. Raus kommt kein Text, sondern die ausgefüllten Werte, mit denen dein Code direkt weiterrechnet. TypeSafe nennt das Modell in der eigenen Doku eine kluge if-Anweisung.

TypeSafe ordnet Jev als System-One-Modell ein, nach Kahnemans “Schnelles Denken, langsames Denken”: Die Reasoning-Modelle, in die alle Labs seit zwei Jahren investieren, sind System 2, das langsame, bewusste Nachdenken. Jev ist System 1, das schnelle intuitive Beurteilen. Sogar der Name ist eine These: Er verweist auf den Ökonomen William Stanley Jevons, denn je billiger eine Entscheidung wird, desto mehr Nachfrage nach Entscheidungen entsteht.

Alle vier Werte sind Herstellerangaben, selbst erhoben und nicht unabhängig reproduziert. Die Null bei den Formatfehlern verdient zudem eine Fußnote: Jev kann keinen Wert außerhalb deines Schemas zurückgeben, sehr wohl aber den falschen gültigen.

Der Kern des Modells ist die Kalibrierung. Jev ist mit Reinforcement Learning for Calibrated Decisions darauf trainiert, dass die ausgegebene Wahrscheinlichkeit im Aggregat mit der Trefferquote übereinstimmt: Eine Confidence von 90 Prozent heißt, dass Jev in neun von zehn Fällen richtig liegt. Das Wort Aggregat ist wichtig, denn TypeSafe stellt selbst klar, dass die Kalibrierung über viele Vorhersagen gilt und keine einzelne Antwort garantiert. Fragst du ein Chatmodell nach seiner Sicherheit, schreibt es dagegen eine Zahl wie jeden anderen Satz auch: ausgedacht.

Zur Einordnung gehört der eigene Benchmark: Jev erreicht dort 67,8 Prozent, exakt der Wert von Claude Sonnet 5, bei rund einem Dreihundertstel der Kosten pro Fall. Die Referenzwerte stammen vom Durchschnitt der Antworten von GPT-6 Astra und Claude Fable 5.1, und die Evaluations liefen beim Anbieter selbst. Wer Schwellenwerte justiert, kommt um ein eigenes Testset nicht herum, das diese Eigenbewertung prüft.

Schritt 1: Setup in fünf Minuten

Den API-Key erstellst du unter console.typesafe.ai/settings/keys, der Early Access ist wartelistenbasiert. Alternativ läuft Jev über OpenRouter mit dem eigenen Key oder über den Vercel AI Gateway.

export TYPESAFE_API_KEY="sk-..."

pip install typesafe-sdk        # Python 3.10+
npm install @typesafe-ai/sdk    # Node 20+

Beide SDKs lesen TYPESAFE_API_KEY aus der Umgebung und rufen standardmäßig jev-latest auf. Wer Schwellenwerte justiert, pinnt die Version fest, denn jev-latest zieht bei einem Release um und kann Antworten unterm Code ändern:

client = TypeSafeClient(model="jev-1.13.0")  # pinnen statt jev-latest

Das Feld model in der Antwort meldet die Version, die tatsächlich geantwortet hat, also logge es mit. Der direkte Weg ohne SDK ist ein einzelner Endpoint, POST https://api.typesafe.ai/v1/systemone. Die Rate-Limits von jev-1.13 liegen bei 250.000 Tokens pro Sekunde und 1.200 Anfragen pro Minute; darüber gibt es ein 429, und beide SDKs wiederholen automatisch mit Exponential Backoff.

Schritt 2: Choice, Score und Noul im ersten Call

Die ganze API besteht aus drei Fragetypen, und das ist Design, keine Einschränkung. Choice wählt eine aus bis zu 255 Optionen und liefert die Wahl, eine Wahrscheinlichkeit pro Option und eine Confidence. Füge immer eine explizite other-Option hinzu, damit das Modell sagen kann, dass nichts passt, statt die nächstliegende falsche Option zu wählen. Score platziert eine Eingabe auf einer Skala aus 2 bis 10 Stufen, die du in Worten beschreibst, und das Ergebnis darf zwischen Stufen liegen, etwa 1.035. Noul beantwortet eine Ja-Nein-Frage als einzelne Wahrscheinlichkeit zwischen 0 und 1, ohne separates Confidence-Feld, weil die Zahl selbst die Überzeugung ist.

Das Kundendienst-Routing aus der TypeSafe-Dokumentation zeigt die Form: Der Bestellstatus geht an normalen Programmcode, eine Produktfrage an ein Sprachmodell, ein komplexer Fall an einen Menschen. So sieht der erste komplette Aufruf aus:

# Python 3.10+, Code-Form übernommen aus der TypeSafe-Doku

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # liest TYPESAFE_API_KEY, default jev-latest

response = client.system_one(
    state={
        "ticket": "Kunde wurde für Bestellung A-104 doppelt berechnet und will eine Erstattung.",
        "refund_policy": "Doppelte Abbuchungen sind erstattungsfähig.",
    },
    questions={
        "department": Choice(
            instructions="Welches Team soll das Ticket bearbeiten",
            criteria={
                "billing": "Zahlungen, Rechnungen, Erstattungen",
                "technical": "Fehler oder Integrationsprobleme",
                "other": "Passt auf nichts davon",
            },
        ),
        "frustration": Score(
            instructions="Wie frustriert wirkt der Kunde",
            criteria=["Ruhig, schildert nur Fakten", "Frustriert, aber sachlich", "Sehr verärgert"],
        ),
        "refund_requested": Noul(instructions="Der Kunde verlangt ausdrücklich eine Erstattung"),
    },
)

dept = response.answers["department"]
print(dept.choice, dept.confidence)
print(response.answers["frustration"].score)
print(response.answers["refund_requested"].noul)

Der State darf ein String, ein JSON-Objekt oder ein Array aus Text sein, und nur Text: Bilder, Audio und Video müssen vorher transkribiert werden. Die Kontextgrenzen funktionieren anders als bei einem LLM, weil der State einmal erfasst wird und alle Fragen parallel darüberlaufen: 64.000 Tokens für State und alle Fragen zusammen, 32.000 Tokens für den State plus der längsten einzelnen Frage.

Muster 1: Alle Fragen auf einmal stellen

Jev beantwortet alle Fragen einer Anfrage parallel in einem Durchlauf. Die zehnte Frage kostet Tokens, aber praktisch keine Zeit. Das dreht eine eingewachsene Intuition um: Statt erst billig zu fragen und nur bei Bedarf nachzufragen, stellst du alles sofort, auch die Fragen, die nur in einem der Fälle relevant sind. Dein Code entscheidet hinterher, was zählt. TypeSafe rechnet im eigenen Cookbook vor, dass 13 Fragen zu einem langen Artikel, gebündelt in einem Call, 12,2-mal günstiger und 10,0-mal schneller sind als einzeln gestellt, bei identischen Antworten.

response = client.system_one(
    state=ticket,
    questions={
        "category": Choice(
            instructions="Grobe Kategorie des Tickets",
            criteria={
                "bug": "Etwas funktioniert nicht",
                "billing": "Rechnung oder Erstattung",
                "account": "Login oder Berechtigungen",
            },
        ),
        # Nur relevant, falls es ein Bug ist. Trotzdem stellen.
        "bug_severity": Score(
            instructions="Wie schwer ist das gemeldete Problem",
            criteria=["Kosmetisch", "Eingeschränkt, Workaround existiert", "Blockierend, kein Workaround"],
        ),
        "has_repro": Noul(instructions="Der Nutzer beschreibt Schritte zum Reproduzieren"),
        # Nur relevant, falls es Billing ist. Trotzdem stellen.
        "refund_wanted": Noul(instructions="Der Nutzer verlangt ausdrücklich eine Erstattung"),
    },
)

cat = response.answers["category"]
if cat.choice == "bug":
    repro = response.answers["has_repro"].noul > 0.6
    if response.answers["bug_severity"].score > 1.5 and repro:
        escalate_to_engineering(ticket_id)
    else:
        add_to_backlog(ticket_id)
elif cat.choice == "billing" and response.answers["refund_wanted"].noul > 0.7:
    start_refund_flow(ticket_id)

In der Masse multipliziert sich das: In einer Demo aus dem Video bewerteten 30 erfundene Kundentypen jeweils rund 700 Werbeanzeigen, zusammen über 20.000 Einzelentscheidungen in einer halben Minute, für 22 Cent.

Muster 2: Eine Schwelle pro Aktion, nicht eine fürs System

Das Muster, das die Architektur verändert, ist confidence-gated Routing. Hör auf, eine Schwelle fürs ganze System zu schreiben. Schreibe eine pro Aktion, skaliert danach, was ein Fehler kostet. TypeSafe empfiehlt als grobe Richtlinie, alles über 0,9 automatisch zu erledigen und alles unter 0,5 an den Menschen zu geben; dazwischen wird nachgefragt. Eine reine Leseaktion braucht die niedrige Schwelle, eine Zahlung die hohe:

intent = response.answers["category"]

if intent.confidence < 0.5:
    route_to_human(ticket)            # Boden: echt unsicher
elif intent.choice == "order_status":
    show_order_status(ticket)          # nur lesend, niedrige Schwelle
elif intent.choice == "approve_refund":
    if intent.confidence > 0.85:       # bewegt Geld, hohe Schwelle
        approve_refund(ticket)
    else:
        ask_customer_for_confirmation(ticket)
else:
    route_to_human(ticket)

Daraus wird die Kaskade, wenn Jev entscheidet, welche Anfrage überhaupt ein teures Modell verdient: Ein Zweig bleibt reiner Code ohne jedes Modell, zwei laden unterschiedliche Spezialisten, einer geht an den Menschen. Auf einer Million Tickets sind das nach TypeSafens Rechnung rund 6.480 statt 30.400 Dollar, und rund 800.000 Fälle sind in unter einer halben Sekunde beantwortet. Das ist die Arbeitsweise aus dem Video in einer Zeile:

“Das Sprachmodell schreibt den Text, Jev entscheidet, und dein Code führt aus.”

Dasselbe Modell füllt drei Rollen im Agenten-Umfeld: als Guardrail, das Bot-Antworten vor dem Versand prüft, als Model Router, das zwischen einem kleinen günstigen und einem großen Modell wählt, und als Eingangsfilter, das Prompt Injections blockiert, bevor sie den Agenten erreichen.

Muster 3: Erst im Code holen und filtern, dann urteilen

Jev hat kein Weltwissen. Es kennt nur den State, den du ihm übergibst, und kann nichts nachschlagen. Die TypeSafe-Dokumentation ist hier ungewöhnlich deutlich: Die Genauigkeit sinkt, sobald der State Material enthält, das die Frage nicht braucht, also hole und filtere im Code und sende nur die Felder, die die Frage wirklich braucht. Wer den State zusammenbaut, entscheidet, was Jev wissen darf. Stopfst du ihn voll, verlierst du Genauigkeit an Context Rot; speist du ihn aus schwacher Quelle, bekommst du eine gut kalibrierte Einschätzung schlechten Materials, weil der State die einzige Welt ist, die das Modell hat.

Für ein Support-Postfach mit 50.000 Mails heißt das: Beim Eingang holen, auf die relevanten Felder kürzen und die Entscheidung an Schwellenwerten festmachen. Und die ehrliche Rechnung dazu: Ein einmalig aufgeräumtes Postfach mit 1.000 Mails war auch mit einem Sprachmodell machbar, für rund 2 Euro und 5 Minuten; Jev braucht dafür 3 Cent und 7 Sekunden. Das ist kein Argument, solange die Aufgabe einmalig bleibt. Es zählt beim täglichen Anfall.

Was die erste Woche gebaut hat

Julian Ivanov zeigt in seinem Video die zwei Demos, an denen man das Muster am schnellsten versteht: eine App, die zu einem beliebigen eingegebenen Text aus 180 Emojis in Echtzeit die passenden auswählt, weil Jev für jedes Emoji parallel prüft, ob es passt, und eine Wikipedia-Jagd von Kartoffel bis künstliche Intelligenz, bei der Jev auf jeder Seite alle Links ausliest und den wahrscheinlichsten zum Ziel wählt. Für diesen Weg brauchte das Modell 6,6 Sekunden, 1.688 ausgewertete Links und 0,14 Cent.

Das Browser-Beispiel ist als Projekt erhältlich: browser-use/jev-ultrafast baut jede Seite in eine nummerierte Tabelle der klickbaren Elemente um, und ein einziger Jev-Request pro Schritt wählt Operation und Ziel, aus CLICK, TYPE_TEXT, SELECT, SCROLL, WAIT, DONE und BLOCKED. Ein kleines Schreibmodell läuft nur für TYPE_TEXT, denn schreiben kann Jev nicht. Die Buchung eines Flugs von Zürich nach London über Google Flights dauert damit 7,1 Sekunden und kostet 0,0039 Dollar, Seitenladezeiten eingerechnet.

Das ökonomische Argument zeigt Hassan El Mghari mit 1.018 wissenschaftlichen Arbeiten: Die Zusammenfassungen stammen von einem Schreibmodell und kosteten 3,99 Dollar, die Zuordnung zu den Themen hat Jev für 8 Cent erledigt, mit einer Latenz von im Median 256 Millisekunden pro Paper. Zwei Modelle, zwei Rollen, eine Pipeline. Und ein Extremfall aus der Robotik zeigt die Architekturgrenzen: Ein Drohnenprojekt lässt Jev mit 2,5 Hertz als rein beratende Schicht entscheiden, während Flugsteuerung mit 500 Hertz, Sicherheit mit 50 Hertz und Wahrnehmung als klassische CV komplett im Code bleiben. Das Projekt-README sagt es selbst: Jev kann nicht die Wahrnehmungsschicht sein und nicht im Kontrolltakt laufen. Auch wer keine Drohne baut, sollte diese Reihenfolge kopieren.

Die Stolpersteine, bevor du shipst

TypeSafe veröffentlicht eine eigene Seite zu den Schwächen von jev-1.13. Erstens liest Jev wörtlich: Es beantwortet die Frage, die du geschrieben hast, nicht die, die du meintest; Verneinungen und implizite Bedingungen landen beim Wortwert. Zweitens ist der State nicht vertrauenswürdig. Text, der für seine eigene Klassifikation argumentiert, kann die Antwort verschieben, und das Video nennt das natürliche Beispiel: eine Mail, die im Betreff ihre eigene Dringlichkeit behauptet, wird wörtlich gelesen und kann als dringend einsortiert werden. Nutzerkontrollierter Inhalt im State ist dein Threat-Modell. Schreibe die Einordnungskriterien explizit in den State, untersage die Befolgung von Anweisungen aus dem Prüftext und teste das Ganze mit Angriffstexten, so wie probabilistische Agenten generell Leitplanken statt Vertrauen brauchen.

Drittens ist Jev kein Taschenrechner, und der Fehler wächst mit der Größe des Gezählten. Zählen geht trotzdem, mit einer Noul-Frage pro Element und der Summe im Code:

items = ["Apfel", "Banane", "Karotte", "Laptop"]

result = client.system_one(
    {"items": items},
    {f"item_{i}": Noul(instructions=f"Ist items[{i}] der Name einer Frucht?")
     for i in range(len(items))},
)
fruechte = sum(result.nouls[f"item_{i}"].noul > 0.5 for i in range(len(items)))

Viertens sind Datumsangaben für Jev Text, keine geordneten Werte: Was zuerst war, wie weit auseinander, ob etwas in ein Fenster fällt, ist unzuverlässig. Extrahiere per Choice mit einer expliziten nicht-angegeben-Option und ordne im Code. Fünftens erzeugt Jev nichts: Für Werte aus Freitext holst du die Kandidaten per Regex oder Schreibmodell und lässt Jev nur wählen. Die Doku fasst die Regeln zusammen: Frag nichts, was Code exakt berechnen kann, und pack nie mehrere Urteile in eine Frage.

Und sechstens, das ist keine Modellfrage, sondern eine Betriebsfrage: Logge pro Entscheidung die Modellversion, die Wahrscheinlichkeiten und die Confidence. Eine falsch geroutete Erstattung für 0,0004 Dollar pro Call ist unsichtbar, bis jemand fragt, warum 300 Anfragen in der falschen Queue gelandet sind.

Datenschutz und der lokale Weg mit Laya

TypeSafe ist ein US-Anbieter, die Daten landen auf amerikanischen Servern, und die Zusicherung, dass nichts gespeichert wird, gilt laut Dokumentation nur für Enterprise-Kunden. Für personenbezogene Daten ohne solche Verträge gibt es einen lokalen Weg: Laya, wenige Tage nach Jev erschienen, läuft mit pip install laya unter Apache-2.0-Lizenz auf eigener Hardware, als 421-Millionen-Parameter-Checkpoint für Englisch auf ModernBERT-large und als 322-Millionen-Parameter-Checkpoint multilingual, mit einem Router, der die Sprache erkennt. Auf einer Tesla T4 antwortet es mit 33 bis 40 Millisekunden, auf der CPU mit 193 bis 464 Millisekunden.

Der Haken ist ausgerechnet das, was Jev besonders macht: Laya ist ein klassischer Klassifikator, den du pro Aufgabe mit tausenden beschrifteten Beispielen trainierst. Ivanov empfiehlt im Video, dieses Fine-Tuning von Claude Code oder Codex erledigen zu lassen. Weitere Grenzen: schlecht ab mehr als 20 Kategorien, Kontext von nur etwa 512 bis 1.024 Tokens, keine Kalibrierung im Jev-Sinne. Erst nach einer Temperaturanpassung fiel der Kalibrierungsfehler des englischen Checkpoints von 0,466 auf 0,081. Auf OpenRouter ist Laya nicht zu finden, es ist zum Self-Hosting gedacht.

5 Schritte zur Umsetzung

1. Setup und Version pinnen: Key von console.typesafe.ai oder über OpenRouter, SDK installieren und jev-1.13.0 festpinnen, solange du Schwellenwerte justierst.
2. Decision-Stellen inventarisieren: Suche in deinen Automationen Prompts der Form “Antworte nur mit einem Wort” und JSON-Schemas mit fester Antwortmenge. Jede dieser Stellen ist ein Kandidat für einen typisierten Aufruf.
3. Fan-out bauen und Schwellen pro Aktion festlegen: Stelle alle Fragen in einem Call, auch die bedingten, und lege pro Aktion fest, ab welcher Confidence automatisch läuft, nachgefragt wird oder ein Mensch übernimmt.
4. State minimal und injection-fest halten: Hole und filtere Kontext im Code, schreibe die Einordnungskriterien explizit in den State und teste mit Prüftexten, die Anweisungen enthalten.
5. Eigenes Testset und Logging: Prüfe an echten Fällen, wie gut die Confidence mit der Trefferquote übereinstimmt, und logge pro Entscheidung die Modellversion, die Wahrscheinlichkeiten und die Confidence.

Mit InstructGPT hat Diogo Almeida den Sprachmodellen das Reden beigebracht. Sein aktuelles Modell kann es nicht, und genau das ist das Produkt.