TypeSafe AI und Jev: Wenn KI aufhört zu schreiben

Am 15. September ist ein Startup aus zwei Jahren Stealth-Modus aufgetaucht, das mit ziemlich viel Selbstbewusstsein gegen die eigene Branche argumentiert. TypeSafe AI, gegründet von Diogo Almeida (einer der Autoren des InstructGPT-Papers, das ChatGPT sein Verhalten beigebracht hat) zusammen mit Erik Gafni und Sasha Sheng, hat mit 40 Millionen Dollar Seed-Funding von DCVC ein Modell veröffentlicht, das keinen einzigen Satz schreiben kann. Jev heißt es, und laut TypeSafe ist es das erste "System One Model" überhaupt: eine KI, die nicht für Menschen textet, sondern für Software entscheidet.

Klingt erstmal nach Marketing-Sprech. Die Idee dahinter ist aber tatsächlich interessant, gerade wenn du KI in eigene Produkte einbaust statt nur mit ihr zu chatten.

Was macht Jev eigentlich, wenn es keinen Text ausgibt?

Du schickst Jev einen Zustand, den State, das kann ein einfacher String sein, ein JSON-Objekt oder eine Liste, und dazu eine Menge typisierter Fragen. Jev beantwortet jede davon parallel und gibt dir eine strukturierte Antwort zurück, direkt als typisierten Wert statt als Text zum Parsen.

Es gibt genau drei Fragetypen. Choice lässt dich aus einer Liste von bis zu 255 Optionen wählen und liefert die gewählte Option, eine Wahrscheinlichkeit für jede einzelne davon und einen Confidence-Wert. Score platziert den Zustand auf einer Skala, die du selbst mit Beschreibungen definierst, etwa wie schwerwiegend ein Bug ist, und gibt einen gewichteten Mittelwert plus Wahrscheinlichkeitsverteilung über die Stufen zurück. Noul, eine Wortkreuzung aus "no" und "null", beantwortet simple Ja/Nein-Fragen mit einer einzigen Wahrscheinlichkeit zwischen 0 und 1.

Ein Support-Ticket landet bei dir, und statt einen Prompt zu schreiben, der irgendwo zwischen Klassifikation und Textgenerierung hängt, fragst du in einem einzigen Aufruf gleichzeitig: welches Team ist zuständig, wie frustriert klingt die Person, geht es um eine Rückerstattung. Alle drei Antworten kommen in unter einer Sekunde zurück, und dein Code entscheidet, was als Nächstes passiert.

Drei Fragen, ein Aufruf, kaum mehr Zeit

Der eigentliche Clou ist, dass Fragen sich nicht gegenseitig verlangsamen. Weil Jev nicht Token für Token generiert, sondern alle Fragen parallel gegen denselben State auswertet, kostet eine zusätzliche Frage im selben Request kaum mehr Zeit. In einem der TypeSafe-eigenen Cookbooks hat das Bündeln von 13 Fragen in einem Aufruf die Kosten um das 12,2-fache gesenkt und war zehnmal schneller als 13 einzelne Aufrufe, bei identischen Antworten.

Das verändert, wie du rangehst. Bei einem klassischen LLM-Call überlegst du dir vorher genau, welche eine Frage du stellst, weil jeder Call Zeit und Geld kostet. Bei Jev stellst du gleich alle Fragen, die für irgendeinen möglichen Ausgang relevant sein könnten, auch die, deren Antwort du am Ende gar nicht brauchst, und lässt deinen Code danach aussortieren.

So sieht das mit dem offiziellen JavaScript-SDK aus:

import { choice, noul, score, TypeSafeClient } from '@typesafe-ai/sdk'

const client = new TypeSafeClient()

const { answers } = await client.systemOne({
  state: { ticket: 'Der Export-Button crasht die Safari-Ansicht. In Chrome geht es.' },
  questions: {
    category: choice('Um welche Art Ticket handelt es sich?', {
      bug: 'Etwas funktioniert nicht wie erwartet',
      feature: 'Wunsch nach etwas, das es noch nicht gibt',
      billing: 'Rechnung, Abo, Rückerstattung',
    }),
    severity: score('Wie schwerwiegend ist das Problem?', [
      'Kosmetisch, keine Auswirkung auf die Funktion',
      'Feature eingeschränkt, Workaround vorhanden',
      'Blockierend, kein Workaround',
    ]),
    hasRepro: noul('Beschreibt das Ticket Schritte zum Reproduzieren?'),
  },
})

if (answers.category.confidence < 0.6) routeToHuman()

Das Ticket landet, je nach Antwort, im Bug-Backlog, direkt bei Engineering oder bei einem Menschen, und die ganze Entscheidung hat ein paar hundert Millisekunden und einen Bruchteil eines Cents gekostet.

Der Name ist ein ökonomischer Insider-Witz

TypeSafe hätte das Modell irgendwie generisch nennen können, hat sich aber für William Stanley Jevons entschieden, den Ökonomen hinter dem Jevons-Paradoxon. Jevons beobachtete im 19. Jahrhundert, dass effizientere Dampfmaschinen den Kohleverbrauch nicht senkten, sondern erhöhten, weil billigere Energie neue Anwendungen dafür schuf. Die Wette von TypeSafe ist dieselbe: Wenn eine Entscheidung nur noch einen Bruchteil eines Cents kostet, baust du sie an Stellen ein, an denen du vorher nie ein LLM aufgerufen hättest.

Die Kategorie "System One" kommt aus Daniel Kahnemans "Thinking, Fast and Slow": System 1 ist das schnelle, intuitive Urteil, System 2 das langsame, bewusste Nachdenken. Chatmodelle wie Claude oder GPT sollen laut TypeSafe System 2 abdecken, Jev übernimmt System 1, die Bauchentscheidung, die ein erfahrener Mensch in Sekunden trifft.

Kalibriert heißt nicht klug, und das ist der Knackpunkt

Hier wird es interessant, weil TypeSafe selbst ziemlich offen mit den eigenen Grenzen umgeht. Jev wird nicht mit RLHF trainiert wie ein Chatmodell, sondern mit etwas, das die Firma RLCD nennt, Reinforcement Learning for Calibrated Decisions. Das Ziel ist nicht, dass Jev die Antwort gibt, die Menschen am liebsten lesen, sondern dass eine Wahrscheinlichkeit von 90 Prozent auch tatsächlich in 90 Prozent der Fälle stimmt. Das sagt nichts über eine einzelne Antwort aus, sondern über die Verteilung über viele Antworten hinweg, und genau das ist der Unterschied zwischen kalibriert und richtig.

Auf dem eigenen Workflow-Dashboard von TypeSafe liegt Jev im Schnitt bei 67,8 Prozent Genauigkeit, gegen 74,1 Prozent für das beste Vergleichsmodell aus GPT-6 Astra und Claude Fable 5.1. Das ist Mittelklasse, kein Frontier-Wert. Every, ein Newsletter-Unternehmen, hat als bislang einziger unabhängiger Tester 777 Bewertungen über 37 Dokumente in unter 0,7 Sekunden für ein Viertelcent laufen lassen und in einem zweiten, kleineren Test sechs von sieben absichtlich eingebauten Fehlern in Texten erkannt. Claude Fable 5.1 hat im selben Test alle sieben erkannt, brauchte dafür aber 25-mal so lange und kostete das 580-fache. Everys Fazit war "gut, aber nicht perfekt", und das trifft den aktuellen Stand ziemlich genau.

Was komplett fehlt, ist eine unabhängige Überprüfung der Kalibrierungsbehauptung selbst. Kein Paper, keine veröffentlichte Architektur, keine Reliability-Kurven, keine Gewichte. Auf Hacker News blieb TypeSafe die Antwort auf genau die Frage schuldig, die am meisten zählt: ob und wie lange die Kalibrierung unter echten, unsauberen Eingaben hält. Die eigene Dokumentation empfiehlt, Confidence-Schwellenwerte gegen eigene, gelabelte Beispiele zu testen, bevor man irgendetwas automatisiert. Das ist die ehrlichste Zeile im ganzen Launch, und die sollte man ernst nehmen.

Wo Jev in einem Vibe-Coding-Workflow wirklich Sinn ergibt

Für dich als jemand, der mit Claude Code oder Cursor baut, ist Jev kein Konkurrent zu diesen Tools, sondern ein Baustein, der daneben läuft. TypeSafe hat direkt einen Agent-Skill veröffentlicht, claude plugin marketplace add typesafe-ai/skills und danach claude plugin install typesafe@typesafe-ai für Claude Code, npx skills add typesafe-ai/skills für alles andere, der deinem Coding-Agenten beibringt, wie man Jev richtig anspricht.

Das naheliegendste Einsatzgebiet ist ein Sicherheitscheck vor jedem Shell-Befehl, den ein Agent ausführen will: readonly, reversibel oder irreversibel, mit Confidence-Wert, bevor irgendetwas gelöscht wird. Genauso gut passt Jev vor ein bestehendes Support- oder Ticket-System, als Router zwischen mehreren Modellen je nach Komplexität der Anfrage, oder als Verifikationsschicht hinter einem LLM, das schon Text geschrieben hat und dessen Behauptungen jetzt gegen die Quelle gegengeprüft werden. Überall dort, wo bisher eine Regex steht, die alle drei Monate an einer neuen Formulierung bricht, ist Jev eine ernsthafte Alternative.

Wofür es sich nicht eignet, ist klar umrissen: kein Fließtext, kein Code, kein Rechnen, keine Datumsvergleiche. Jev liest Zahlen und Daten als Text und ist darin unzuverlässig, also bleibt Arithmetik in deinem Code, nicht im Modell.

Der Haken: Jev ist kein Ersatz, sondern ein zweiter Baustein

Die Preis- und Latenzzahlen, die TypeSafe zeigt, sind beeindruckend und lassen sich unabhängig nachvollziehen. 70 bis 500 Millisekunden pro Aufruf, 0,042 Dollar pro Million Input-Token, Output kostenlos, weil es schlicht keine Token gibt, die generiert werden müssten. Das ist real, das hat Every bestätigt, und es öffnet Anwendungsfälle, die bei LLM-Preisen wirtschaftlich unsinnig gewesen wären, etwa jeden einzelnen Schritt eines Agenten gegenzuprüfen statt nur den letzten.

Wo TypeSafe übertreibt, ist der Vergleich mit Frontier-Modellen auf der Genauigkeitsachse. Jev gewinnt bei Geschwindigkeit und Preis meilenweit, verliert aber bei Genauigkeit gegen genau die Modelle, mit denen es sich in denselben Charts misst. Die ehrlichere Version der Geschichte: TypeSafe hat die Kosten-Nutzen-Grenze für strukturierte Entscheidungen ein gutes Stück verschoben. Ein Modell, das klüger ist als GPT-6 Astra oder Claude Fable 5.1, ist dabei nicht herausgekommen. Für die allermeisten Vibe-Coding-Projekte reicht das völlig, solange du Jev genau da einsetzt, wo eine Entscheidung tatsächlich in "welche von drei Optionen" zerfällt, und nicht da, wo eigentlich ein Satz gebraucht wird.