Was Jev von TypeSafe AI für die Automatisierung im Mittelstand ändert

Am 15. September 2026 hat das bis dahin unbekannte Unternehmen TypeSafe AI seinen Stealth-Modus verlassen und im Blogpost "Introducing System One Models and Jev" ein Modell vorgestellt, das keinen Text erzeugt. Gründer Diogo Almeida bringt es auf den Satz "Models have been superhuman at chat for years, so where is all the automation?". Der Hacker-News-Thread dazu kam auf fast 2.000 Punkte und über 500 Kommentare. Laut Pressemitteilung vom selben Tag kam das Unternehmen mit einer Seed-Finanzierung über 40 Millionen Dollar unter Führung von DCVC aus dem Stealth-Modus, und innerhalb einer Woche folgten erste Open-Source-Nachbauten.

Die Frage dahinter begegnet uns in Projekten zur Prozessautomatisierung mit KI täglich. Die meisten Schritte in einem automatisierten Prozess sind Entscheidungen: welche Abteilung ein Ticket bekommt, zu welcher Bestellung eine Rechnung gehört, ob ein Lead heute einen Anruf wert ist, ob ein Kommentar in die Moderation muss. Viele Firmen lösen das heute mit einem Sprachmodell und einem Parser für dessen Antwort. Das funktioniert, ist aber ein teurer Umweg.

Was ein System One Model technisch ist

Der Name spielt auf Daniel Kahnemans Unterscheidung zwischen System 1 (schnelle, automatische Urteile) und System 2 (langsames, überlegtes Denken) an. TypeSafe AI beschreibt Jev, das erste öffentliche Modell dieser Klasse, als "frontier-intelligence function call: unstructured state in, typed probabilistic decisions out". Man gibt unstrukturierten Zustand hinein, etwa einen Ticket-Text, dazu eine Liste typisierter Fragen. Zurück kommen Zahlen, kein Fließtext.

Die Dokumentation nennt drei Fragetypen. Choice wählt eine Option aus einer Liste mit bis zu 255 Einträgen und liefert eine Wahrscheinlichkeitsverteilung über alle Optionen plus einen Confidence-Wert. Score bewertet nach einer Rubrik, ebenfalls mit Verteilung und Confidence. Noul beantwortet "Ist diese Aussage wahr?" mit einem Wert zwischen 0 und 1. Alle Fragen einer Anfrage werden parallel und unabhängig voneinander gegen denselben Zustand beantwortet; laut Dokumentation entsteht so kein "context rot", weil keine Frage die Antworten auf die übrigen beeinflusst.

Ein vereinfachtes Beispiel für den Ticket-Eingang eines Händlers (die verbindliche Syntax steht in den Docs):

const state = `Betreff: Rechnung 4711 doppelt abgebucht
Hallo, die Bestellung vom 3.9. wurde mir zweimal belastet ...`;

const questions = [
  { type: "choice", name: "abteilung",
    options: ["buchhaltung", "versand", "produktberatung", "retoure", "sonstiges"] },
  { type: "score", name: "dringlichkeit",
    rubric: "1 = kann warten, 5 = heute klären" },
  { type: "noul", name: "ist_beschwerde",
    statement: "Der Kunde beschwert sich über einen Fehler auf unserer Seite." }
];

// Ergebnis (Beispielwerte):
// abteilung:      { buchhaltung: 0.91, retoure: 0.05, ... }  confidence: 0.88
// dringlichkeit:  4  { 3: 0.12, 4: 0.71, 5: 0.15, ... }      confidence: 0.79
// ist_beschwerde: 0.94

Zwei Eigenschaften unterscheiden das von einem LLM mit JSON-Ausgabe. Das Modell kann per Konstruktion keinen ungültigen Wert liefern, also weder Freitext noch eine sechste Abteilung. Und die Wahrscheinlichkeiten sollen kalibriert sein. TypeSafe hat das Modell nach eigener Aussage mit einem Verfahren namens "Reinforcement Learning for Calibrated Decisions" (RLCD) trainiert. Kalibriert heißt, dass ein Wert von 0,9 in etwa neun von zehn Fällen richtig sein soll.

Die Zahlen und wie man sie liest

TypeSafe gibt eine End-to-End-Latenz von 70 bis 500 Millisekunden an und stellt dem 3 bis 329 Sekunden für Frontier-LLMs auf vergleichbaren Aufgaben gegenüber. Daraus leitet der Anbieter eine 40- bis 200-fache Geschwindigkeit bei gleicher Intelligenz ab. Eigene Workflow-Evaluationen beziffert TypeSafe mit 193,6-fach schneller und 444,6-fach günstiger, mit dem Zusatz, dass das am oberen Ende der realen Gewinne liegt. Der Preis liegt bei 0,042 Dollar pro Million Input-Token, Output-Token sind kostenlos. Simon Willison stellt das in seiner Einordnung neben GPT-5 Nano mit 0,05 Dollar pro Million Input-Token.

Alle diese Zahlen stammen vom Anbieter. In den von uns ausgewerteten Quellen haben wir keine unabhängige Nachmessung gefunden. Der Hacker-News-Thread hieß zunächst "New frontier model 40-400x cheaper and 20-200x faster" und wurde innerhalb einer Stunde umbenannt. Im Thread selbst setzte sich die Sicht durch, dass Jev ein sehr guter Zero-Shot-Klassifikator (er ordnet ohne eigene Trainingsdaten zu, nur mit der Frage und der Optionsliste) und eine Routing-Engine ist, der Begriff "frontier model" aber übertrieben. Auch den Geschwindigkeitsvergleich hielt der Thread für irreführend, weil 70 Millisekunden gegen 3 bis 329 Sekunden nur dann ein fairer Vergleich ist, wenn das LLM in dieser Zeit dieselbe Arbeit leistet. Willison und Maggie Appleton verwenden stattdessen den Begriff "Decision Model", und wir übernehmen ihn im Weiteren.

Alt ist an dem Ansatz mehr, als der ursprüngliche Thread-Titel nahelegt. Klassifikatoren gab es immer, als kleine, auf eigene Beispiele trainierte Modelle, für die man ein paar tausend von Hand zugeordnete Fälle braucht. Neu ist die Kombination aus Zero-Shot, kalibrierter Confidence und einem Preis, der einen Aufruf pro Datensatz auch bei großem Volumen erlaubt. Wer heute 5.000 von Hand zugeordnete Retourengründe hat, bekommt mit Custom Models und Fine-Tuning auf einem kleinen Modell vermutlich eine vergleichbare Trefferquote, ohne Abhängigkeit von einem Early-Access-Anbieter.

Welche Aufgaben im Mittelstand Entscheidungen sind

Nehmen wir einen Händler mit 3.000 Bestellungen am Tag. Einige hundert Support-Tickets laufen ein, jede Retoure braucht einen Grund, die Buchhaltung ordnet Eingangsrechnungen Bestellungen zu, das Produktmanagement pflegt Warengruppen für neue Artikel. Jeder dieser Schritte endet mit einem Wert aus einer festen Menge: einer Abteilung, einem Retourengrund aus der Liste, einer Bestellnummer aus fünf Kandidaten, einer Warengruppe aus dem Kategoriebaum.

Heute sieht die Umsetzung meist so aus: Ein Prompt mit einer Seite Anweisungen, das Sprachmodell antwortet nach zwei bis zehn Sekunden mit einem JSON-Objekt, ein Parser prüft, ob die Kategorie in der erlaubten Liste steht, und bei einem Fehler wird der Aufruf wiederholt. Bei 3.000 Bestellungen und mehreren Entscheidungen pro Vorgang sind das schnell 20.000 LLM-Aufrufe am Tag, jeder mit einer Fehlerbehandlung, die nur existiert, weil das Modell eigentlich Text schreiben will.

Eine Beispielrechnung: 20.000 Aufrufe mit je 1.500 Token Kontext sind 30 Millionen Input-Token am Tag. Bei Jev sind das nach Anbieterpreis rund 1,30 Dollar pro Tag, Output-Token kosten nichts. Ein mittelgroßes LLM zu angenommenen 0,50 Dollar pro Million Input-Token liegt mit den Output-Token für die JSON-Antwort bei rund 20 Dollar pro Tag, ohne die Wiederholungen bei Parser-Fehlern. Gegen ein Modell zum Preis von GPT-5 Nano schrumpft der Kostenunterschied. Der größere Unterschied ist die Zeit. 20.000 Aufrufe mit je 5 Sekunden sind aneinandergereiht knapp 28 Stunden pro Tag, mit je 300 Millisekunden sind es unter zwei. Grundlage sind die Preisangaben von TypeSafe und angenommene LLM-Listenpreise, keine eigenen Messungen.

Ein Decision Model ersetzt genau diesen Teil. Die Fragen bleiben dieselben, die Antwort kommt laut Anbieter in unter einer halben Sekunde und liegt immer im erlaubten Wertebereich. Parser und Wiederholungsschleife entfallen. An der Anbindung an ERP, Ticketsystem oder Shop ändert sich wenig; wie bei jeder KI-Integration für den Mittelstand heißt es Daten holen, Frage stellen, Ergebnis zurückschreiben.

Schwellenwerte und Freigabe durch Mitarbeiter

Die kalibrierte Wahrscheinlichkeit erlaubt eine Schwellenwert-Logik, die sich mit LLM-Antworten nur mit Umwegen bauen lässt, weil die Sicherheit, die ein Sprachmodell für seine Antwort angibt, in der Regel nicht kalibriert ist. Liegt die Wahrscheinlichkeit für die gewählte Abteilung über 0,9, wird das Ticket automatisch zugewiesen. Liegt sie zwischen 0,6 und 0,9, geht es mit dem Vorschlag vorausgefüllt an einen Mitarbeiter. Darunter landet es ohne Vorschlag in der Warteschlange. Der Mitarbeiter bleibt im Prozess, bekommt aber nur noch die Fälle, bei denen seine Entscheidung etwas ändert. Die Schwellen legen Sie nach Ihrem Risiko fest. Bei der Rechnungszuordnung liegt die Automatik-Schwelle höher als beim Ticket-Routing, weil eine falsch gebuchte Rechnung mehr kostet als ein weitergereichtes Ticket. Nach vier Wochen können Sie nachsehen, wie viele Fälle über 0,9 richtig waren, und die Schwelle nachziehen.

Dasselbe Muster passt auf die Lead-Priorisierung (Score nach einer Rubrik Ihres Vertriebs), auf die Produktdaten-Klassifikation (Choice über bis zu 255 Warengruppen) und auf Retourengründe (Choice plus eine Noul-Frage "Die Ware wurde benutzt"). Willison testet gerade Reranking in der Suche, bei dem 100 Kandidaten aus einer klassischen Stichwortsuche (BM25) per Score nach Relevanz sortiert werden. Für eine Produktsuche mit KI-Search im Shop ist das der Schritt, der mit einem LLM bisher oft an Latenz und Kosten scheitert.

Für Unternehmen, die KI-Agenten entwickeln lassen, ändert sich damit auch die Architektur. Ein Agent, der eine Bestellung abwickelt, trifft unterwegs ein Dutzend kleiner Entscheidungen, bisher jede ein voller LLM-Aufruf. Gehen die Entscheidungen an ein Decision Model und bleibt das Sprachmodell nur für die Schritte, die Text oder Planung brauchen, wird der Agent schneller und sein Verhalten vorhersagbarer.

Wo die Grenzen liegen

Der meistbeantwortete Kommentar im Hacker-News-Thread, von jacobgold, nennt die wichtigste inhaltliche Grenze: Das Modell kann keinen ungültigen Typ ausgeben, aber es kann einen falschen gültigen Wert ausgeben. "retoure" statt "versand" ist ein gültiger Wert und trotzdem falsch. Bekommt die Rechnungszuordnung fünf Kandidaten und die richtige Bestellung ist nicht darunter, wählt das Modell die wahrscheinlichste falsche. Eine Option "sonstiges" gehört deshalb fast immer in die Liste, und niedrige Confidence-Werte sollten Sie auswerten.

Eine Begründung gibt es nicht. Markiert Jev eine Mail als Spam, sagt es nicht, welche Signale im Inhalt den Ausschlag gegeben haben, wie Willison am Beispiel Spam-Erkennung zeigt. Für Ticket-Routing ist das verschmerzbar. Für eine Entscheidung, die ein Kunde anfechten kann, etwa eine abgelehnte Kulanz, brauchen Sie eine Begründung, und die muss ein anderes System oder ein Mitarbeiter liefern.

Willison hat auch Bay-Area-Städte nach "good" bewerten lassen; Cupertino landete oben, East Palo Alto unten. Das Modell trägt also die Vorurteile seiner Trainingsdaten, und eine kalibrierte Wahrscheinlichkeit sagt nichts darüber, ob die Rubrik selbst vernünftig ist. Für Entscheidungen über Menschen, etwa Bewerber oder Kreditwürdigkeit, ist ein Score ohne Begründung kein Entscheidungsgrund.

Jev ist im Early Access und nur über die API erreichbar. Open Weights gibt es nicht, und die Modellgröße nennt TypeSafe nicht. Zu Preisgarantien und zum Zeitplan für die allgemeine Verfügbarkeit haben wir in den Quellen nichts gefunden. TypeSafe AI, Inc. sitzt in San Francisco, und die Datenschutzerklärung nennt die USA als Hosting-Standort; Eingaben werden laut derselben Erklärung nicht zum Training verwendet. Eine EU-Region oder einen Auftragsverarbeitungsvertrag haben wir dort nicht gefunden. Solange beides fehlt, würden wir Zustände mit personenbezogenen Daten nicht an die API schicken. Ob das für Ihr Unternehmen zulässig wäre, klären Sie mit Ihrem Datenschutzbeauftragten; wie wir solche Fälle technisch aufsetzen, steht auf unserer Seite zu DSGVO-konformen KI-Lösungen mit EU-Hosting. Dazu kommt die Abhängigkeit vom Anbieter, denn wer seine Schwellenwerte auf die Kalibrierung eines Modells eingestellt hat, muss sie beim Wechsel neu vermessen.

Innerhalb einer Woche veröffentlichte Jared Palmer "Kev", eine Familie von Open-Source-Decision-Models mit 0,8, 4 und 9 Milliarden Parametern auf Basis von Qwen 3.5, die auf einer GPU oder einem Mac mit 32 GB Arbeitsspeicher laufen. Auf dem Entwicklungsdatensatz des Projekts erreicht Kev-9B laut README eine Trefferquote von 0,82 gegenüber 0,86 für das gehostete Jev; unabhängig geprüft ist weder das noch die Kalibrierung. Ein nachgebautes Decision Model kann in einem deutschen Rechenzentrum stehen.

Wann Sie das heute nutzen und wann nicht

Für Aufgaben ohne personenbezogene Daten, bei denen eine falsche Entscheidung billig zu korrigieren ist, lohnt sich ein Test jetzt. Produktdaten-Klassifikation, Duplikaterkennung im Katalog, Reranking in der Shopsuche, Vorsortierung von Lieferanten-Dokumenten: Der Zustand ist hier ein Produkttext oder ein Dokument, und ein Fehler fällt bei der nächsten Sichtung auf. Lassen Sie im Test das Decision Model und Ihren heutigen LLM-Prompt auf denselben 500 Fällen laufen und legen Sie Trefferquote, Latenz und Kosten nebeneinander.

Für alles mit Kundendaten, also Ticket-Routing und Rechnungszuordnung, würden wir warten, bis TypeSafe eine EU-Region und einen Auftragsverarbeitungsvertrag anbietet, oder den Weg über ein selbst gehostetes Modell gehen. In beiden Fällen lohnt es sich, in der Pipeline die Stellen, an denen Text entsteht, von den Stellen zu trennen, an denen entschieden wird. Das zahlt sich auch aus, wenn vorerst dasselbe LLM beides bedient, weil Sie die Entscheidungsstelle später austauschen können, ohne den Rest anzufassen.

Unabhängig vom Modell hilft eine Bestandsaufnahme, welche Stellen in Ihren Prozessen Entscheidungen mit endlichem Wertebereich sind. In den meisten Shops, die wir bei Projekten zu KI im E-Commerce sehen, ist diese Liste länger als die der Textgenerierung. Wenn Sie diese Bestandsaufnahme mit uns machen wollen, erreichen Sie uns über das Kontaktformular.