Jev und System One Models: wie Formulare und UIs intelligent werden können

System One Models beantworten Fragen über Freitext mit einer Option aus einer festen Liste und einer Wahrscheinlichkeit dazu, und zwar in wenigen hundert Millisekunden und ohne Trainingsdaten. Damit lohnen sich Urteile dort, wo sie bisher zu teuer oder zu langsam waren, etwa in Formularfeldern, Ergebnislisten und Tickets. Wir zeigen neun Stellen, an denen wir anfangen würden.

Mit diesem Post wollen wir vor allem Anregungen geben. Nach einer kurzen Erklärung, wie System One Models funktionieren, folgen Stellen in Oberflächen und Formularen, an denen wir sie einsetzen würden, und wir hoffen, dass du beim Lesen ähnliche Stellen in deiner eigenen Anwendung entdeckst. Eigene Benchmarks findest du hier keine, und wo wir Messwerte nennen, stammen sie aus dem Praxistest eines INNOQ-Kollegen. Auch eine Empfehlung sprechen wir nicht aus, weil es dafür schlicht zu früh ist.

Was ein System One Model ist

Ein System One Model bekommt einen Sachverhalt und eine typisierte Frage und gibt einen Wert zurück, den der Code direkt weiterverarbeiten kann. Wie groß der Unterschied zu einem Sprachmodell ist, sieht man am besten an der Aufrufstelle. Dort steht weder ein Prompt, der um eine Antwort in der gewünschten Form bittet, noch dahinter ein Parser, der hofft, dass sie eingehalten wurde. Für jede Frage kommt stattdessen eine Antwort zurück, die etwa so aussieht:

{
  "answers": {
    "taetigkeit": {                  // die ID, unter der wir die Frage gestellt haben
      "choice": "Konzeption",        // die wahrscheinlichste Option
      "probabilities": {             // wie sich die Wahrscheinlichkeit verteilt
        "Konzeption": 0.81,
        "Implementierung": 0.13,
        "nicht erkennbar": 0.06
      },
      "confidence": 0.71             // verdichtet die Verteilung zu einer Zahl für Schwellen
    }
  }
}

Ihren Namen hat die Modellklasse von Kahneman, der mit System 1 das schnelle, intuitive Urteil beschreibt, das ein sachkundiger Mensch in wenigen Sekunden fällt. Ein solches enges Urteil liefert auch das Modell, ohne Herleitung und ohne erklärenden Satz. Das Gegenstück wären in diesem Bild die Reasoning-Modelle, die sich vor der Antwort durch eine Kette von Zwischenschritten arbeiten, während bei System One Models die Zerlegung einer Aufgabe im Code stattfindet.

Vorgestellt hat die Kategorie TypeSafe AI, eine junge Firma in der Seed-Phase, am 15. September 2026, zusammen mit dem ersten Modell dieser Art namens Jev. Der Zugang hat sich seitdem mehrmals geändert: Anfangs lief er über eine Warteliste, danach war die Anmeldung kurz für alle offen, und seit dem 22. September sind Neuanmeldungen wegen der Nachfrage pausiert, während bestehende Zugänge weiterlaufen. Über Gateways wie OpenRouter oder das Vercel AI Gateway lässt sich Jev auch ohne eigenes TypeSafe-Konto aufrufen. Schon in den Tagen nach der Ankündigung sind zudem mehrere offene Nachbauten entstanden, die dieselbe Schnittstelle auf frei verfügbaren Modellen anbieten. Mit ihnen lässt sich das Prinzip lokal ausprobieren, wobei sie auf kleineren Modellen laufen und sich ihre Messungen mit denen von Jev nicht direkt vergleichen lassen.

Wir haben unseren Zugang noch über die ursprüngliche Warteliste bekommen und ein paar Tage mit jev-1.13.0 gebaut. Das reicht zwar nicht für belastbare Aussagen über die Qualität der Urteile, wohl aber für einen Eindruck davon, was sich damit bauen lässt. Mit TypeSafe AI arbeiten wir nicht zusammen: Für den Zugang haben wir nichts bezahlt, und für diesen Post haben wir nichts bekommen.

Warum sich das bisher selten gelohnt hat

Urteile über Freitext gab es auch bisher, und dass sie trotzdem selten gebaut wurden, hat zwei Gründe, die einander in den letzten Jahren abgelöst haben.

Lange war der einzige Weg ein feingetuntes eigenes Modell. Dafür braucht man einen gelabelten Datensatz, einen Trainingslauf und ein Deployment, vor allem aber jemanden, der das kann, und die Bereitschaft, das Ergebnis über Jahre zu betreiben. Will die Fachabteilung später eine Kategorie ergänzen, beginnt der Zyklus von vorn, und aus einer kleinen Bitte wird ein Ticket über mehrere Wochen.

Für ein zentrales Feature lohnt sich dieser Aufwand, etwa für eine Betrugserkennung oder eine Dokumentenklassifikation, um die sich ein ganzer Geschäftsprozess dreht. Für die kleine Verbesserung an einem Formularfeld lohnt er sich nie. Solche Verbesserungen wurden deshalb nicht gebaut, und obwohl niemand sie für überflüssig hielt, hatten sie in keiner Schätzung eine Chance, weshalb man sie vor der Zeit der Sprachmodelle meist gar nicht erst vorgeschlagen hat.

Mit Sprachmodellen fiel dieser Aufwand weg, weil ein Prompt in zehn Minuten geschrieben ist und der Wertebereich im Text steht, wo er sich von einem Tag auf den anderen ändern lässt. Dafür tauchte ein Problem auf, das in einer Oberfläche schwerer wiegt: die Wartezeit.

Ein Sprachmodell braucht für eine solche Einordnung je nach Klasse zwischen einer knappen Sekunde und mehreren Sekunden. Für einen nächtlichen Lauf ist das egal, in einem Eingabefeld aber lang, weil der Nutzer in dieser Zeit längst weitergetippt, das Feld verlassen oder schon auf Speichern gedrückt hat. Ein Vorschlag, der erst danach erscheint, stört dann nur noch: Er ändert etwas, das für den Nutzer bereits fertig war. Wer einmal versucht hat, eine Autovervollständigung gegen ein Sprachmodell zu bauen, kennt das: In der Demo funktioniert es, im Alltag fällt es auseinander.

Hinzu kommt die Wahrscheinlichkeit. Solange die Schnittstelle keine Token-Wahrscheinlichkeiten herausgibt, schreibt ein Sprachmodell sie als Teil des generierten Textes ins JSON, und was eine solche Zahl bedeuten soll, muss man vorher im Prompt festlegen.

Die neue Modellklasse braucht keinen Trainingsdatensatz und antwortet in wenigen hundert Millisekunden, wobei eine Million Eingabe-Token laut Hersteller 0,042 US-Dollar kostet und die Ausgabe nichts. Ihre Wahrscheinlichkeiten liefert sie immer mit, vollständig und im richtigen Format. Ob sie auch gut kalibriert sind, muss man auf eigenen Daten prüfen. Im Praxistest unseres Kollegen lagen dabei sogar die verglichenen Sprachmodelle vorn. Bezahlbar wird die kleine Verbesserung am Formularfeld damit trotzdem zum ersten Mal. Vor allem aber lässt sie sich jetzt vorschlagen: Man kann sie ins Refinement mitbringen, ohne dass sofort jemand fragt, wer das denn trainieren soll.

Die drei Fragetypen

Bei allen drei Fragetypen wird der Wertebereich mitgeschickt, sie unterscheiden sich aber darin, was zurückkommt.

Jede Frage besteht aus einer Anweisung und, bei Choice und Score, aus den Optionen beziehungsweise den geordneten Stufen, einen Systemprompt mit Beispielen oder Formatvorgaben braucht es nicht. Weil der Wertebereich als Dictionary im Code steht, wird er im Editor geändert und im Pull Request reviewt wie jeder andere Code auch, und eine neue Kategorie kostet nicht mehr als eine Zeile. Zwischenwerte bei Score eignen sich für eine Schwellenprüfung, als genaue Größe zwischen zwei Stufen sollte man sie laut Hersteller aber nicht lesen.

Bei Choice ist die Antwort immer eine der Optionen aus dem Code. Das Modell kann also nichts erfinden, und der Rückgabewert lässt sich ohne weitere Prüfung verarbeiten. Das hat allerdings eine Kehrseite: Wer einen Ausgang für unklare Fälle braucht, muss ihn selbst als Option mitgeben, damit die Antwort überhaupt „weiß ich nicht“ lauten kann.

Eine Begründung, warum es sich so entschieden hat, liefert das Modell nicht. Ein Sprachmodell schreibt zwar einen solchen Satz, doch ob er den tatsächlichen Grund wiedergibt, lässt sich nicht sicher sagen. Bei System One Models entsteht die Nachvollziehbarkeit auf anderem Weg, denn welche Teilfragen gestellt wurden und mit welcher Schwelle der Code daraus seine Entscheidung ableitet, steht lesbar im Code.

Die Zahl neben der Antwort

Bei Choice und Score liefert das Modell neben dem Wert die Verteilung über alle Optionen oder Stufen und dazu das Feld confidence, das diese Verteilung zu einer einzigen Zahl für Schwellen verdichtet. Nur Noul hat kein confidence, weil der Wert dort selbst schon die Wahrscheinlichkeit für Ja ist. Wer nur die wahrscheinlichste Option übernimmt, baut eine Anwendung, die sich bei einem eindeutigen Fall genauso verhält wie bei einem, in dem zwei Optionen dicht beieinanderliegen. Nutzt man dagegen die Verteilung, kann die Anwendung einen Vorschlag anbieten, statt ihn zu setzen, oder nachfragen, wenn der Fall unklar ist. Die Schwellen dafür setzt man anfangs vorsichtig und justiert sie auf eigenen Daten nach.

Eine Fehlerquelle, die man leicht übersieht, steckt in den Noul-Fragen. Ein niedriger Wert kann dort bedeuten, dass der Sachverhalt Nein sagt, oder aber, dass er zur Frage gar nichts enthält, und weil das Schema für beides denselben Ausgang kennt, verneint das Modell im Zweifel. Im selben Praxistest hat Jev alle 40 Aussagen verneint, zu denen der Text nichts enthielt, obwohl knapp die Hälfte davon zutraf.

Da die Ursache im Schema liegt, ist das Gegenmittel simpel: eine Choice mit einer ausdrücklichen Option „nicht erkennbar“, mit der Jev im Test alle 40 Fälle ohne Information erkannt hat. Eine Schwelle, die man vorher auf einem Noul geeicht hat, lässt sich dabei nicht einfach übernehmen. Wenn du dir beim Lesen der folgenden Beispiele eine eigene Frage überlegst, lohnt es sich, diesen Ausgang gleich mit einzuplanen.

Was das für Oberflächen aufmacht

Die folgenden Stellen sind als Anregung gedacht. Das konkrete Beispiel passt selten eins zu eins auf die eigene Anwendung, die Frage dahinter lässt sich aber meistens übertragen.

Während jemand etwas eingibt

Das Dropdown, bei dem alle den obersten Eintrag nehmen. In der Zeiterfassung steht neben dem Buchungstext eine Auswahlliste mit vierzig Tätigkeitsarten, die seit Jahren gepflegt wird. Trotzdem landet die Hälfte aller Buchungen auf dem ersten Eintrag, weil Scrollen länger dauert als Nachdenken, und entsprechend wertlos ist die Auswertung am Quartalsende.

Dabei reicht eine Choice über genau diesen Katalog: „Welche dieser Tätigkeitsarten beschreibt den Buchungstext am besten?“ Das Feld kommt damit vorausgefüllt, und wer anderer Meinung ist, ändert es. Jede dieser Änderungen zeigt, wo das Modell danebenlag, wenn auch nicht vollständig: Wer aus Bequemlichkeit den obersten Eintrag genommen hat, übernimmt auch einen falschen Vorschlag. Zusammen mit einer regelmäßigen Stichprobe entsteht nach drei Monaten trotzdem ein Eval-Set, für das man sonst ein eigenes Projekt aufsetzen müsste.

Der Pflichttext, der formal ausgefüllt ist. „Geht nicht mehr, bitte dringend anschauen, danke“ hat achtundvierzig Zeichen. Da das Feld „Fehlerbeschreibung“ im Support-Formular fünfzig verlangt, hängt man zwei Ausrufezeichen an, und schon geht das Ticket durch.

Ein Noul, das während des Tippens läuft, prüft stattdessen den Inhalt: „Enthält dieser Text eine Angabe darüber, was der Nutzer getan hat, bevor der Fehler auftrat?“ Fehlt diese Angabe, erscheint der Hinweis direkt unter dem Feld, also bevor jemand abschickt, und nicht erst zwei Tage später als Rückfrage. Mehr als ein Hinweis sollte das nicht sein. Würde das Feld den Text blockieren, lernten die Nutzer schnell, welche Sätze durchgehen.

Das Formular, das alles auf einmal zeigt. Eine Schadenmeldung hat gut dreißig Felder, von denen je nach Fall nur zehn relevant sind. Da die Fallunterscheidung nirgends sauber definiert ist, sieht der Nutzer trotzdem alle und füllt die Hälfte mit „entfällt“.

Oft verraten allerdings schon die ersten beiden Freitextangaben, worum es geht, und dann genügt eine Choice darauf: „Um welche Art von Schaden geht es hier?“ Anschließend blendet der Code die Felder ein, die dazugehören. Ganz ungefährlich ist das nicht: Ein falsch eingeblendeter Feldsatz kostet den Nutzer mehr Zeit, als wenn er gleich alle Felder gesehen hätte. Wir würden deshalb nur ausblenden, wenn die Wahrscheinlichkeit hoch ist, und im Zweifel lieber alles zeigen.

Die Duplikate, die man erst hinterher sieht. „Bezeichnen diese beiden Einträge dieselbe Sache?“ Diese Frage stellt man am besten, während jemand einen neuen Kontakt oder ein neues Bauteil anlegt, denn oft existiert derselbe Eintrag schon unter leicht anderer Schreibweise. Eine exakte Suche findet ihn nicht, und ein Ähnlichkeitsmaß auf Zeichenketten schlägt zu oft falsch an, als dass man es einblenden wollte. Deshalb liefert zuerst eine grobe Vorsuche eine Handvoll Kandidaten, die zusammen mit dem neuen Eintrag in den Sachverhalt kommen, und pro Kandidat verweist ein Noul im selben Aufruf auf dessen Schlüssel. So erscheint der Hinweis noch beim Tippen, und der nächtliche Bereinigungslauf hat weniger zu tun.

Wenn jemand auf eine Liste schaut

Der Betreff, der nichts sagt. Im Ticketsystem heißt jedes vierte Ticket „Problem“, „Frage“ oder „dringend“, und in einer Übersicht mit fünfzig Zeilen erfährt man bei der Hälfte erst beim Aufklappen, worum es geht. Abhilfe schafft eine Choice über die Themen, die im Projekt tatsächlich vorkommen, samt einem Ausgang für alles andere: „Worum geht es in diesem Ticket?“ Das Ergebnis erscheint dann als Label neben dem ursprünglichen Betreff.

Die Anhänge, die niemand zuordnet. An einem Vorgang hängen sieben Dateien, die alle scan_0043.pdf oder IMG_2291.jpg heißen, und wer ihn bearbeitet, öffnet sie der Reihe nach, bis er die Rechnung gefunden hat. Schickt man den Text jeder Datei an eine Choice mit der Frage „Was für ein Dokument ist das?“, kann die Liste neben jedem Dateinamen den Typ anzeigen. Weil Jev nur Text verarbeitet, muss bei Scans und Fotos vorher eine Texterkennung oder ein Vision-Modell laufen. Zur Auswahl stehen dann die Dokumentarten, die im Prozess vorkommen, also Rechnung, Lieferschein, Korrespondenz, Foto, Vertrag und unklar.

Die Suche, die immer etwas findet. Jede Ergebnisliste hat einen ersten Treffer, doch ob er etwas taugt, sieht man erst nach dem Klick. Bei einer internen Wissensdatenbank mit zweitausend Dokumenten klickt man deshalb ziemlich oft umsonst, zumal die Liste bei einer guten und einer schlechten Anfrage gleich aussieht.

Hier gehören zwei Fragen in einen Aufruf. Eine Choice über die Kandidaten liefert mit ihrer Verteilung die Reihenfolge, und daneben fragt ein Noul: „Beantwortet eines dieser Dokumente die Frage?“ Nötig ist das, weil sich die Wahrscheinlichkeiten einer Choice zu eins addieren und deshalb immer irgendetwas auf Platz eins landet, auch wenn nichts passt. Erst mit der zweiten Frage kann die Suche sagen, dass es zu einer Anfrage nichts gibt.

Die Vorschlagsliste ohne Reihenfolge. Unter jedem Artikel einer Wissensdatenbank stehen fünf verwandte Beiträge, die über gemeinsame Tags ermittelt und nach Erstellungsdatum sortiert werden, weil nie jemand eine bessere Reihenfolge definiert hat. Für jeden Kandidaten genügt im selben Aufruf ein Noul: „Vertieft dieser Artikel ein Thema aus dem aktuellen Artikel?“ Danach sortiert der Code, lässt aber alle fünf in der Liste, denn eine neue Reihenfolge lässt sich leichter vertreten als ein ausgeblendeter Eintrag.

Wenn etwas untergeht

Der Kommentar, der der Freigabe widerspricht. In einer Bestellfreigabe klickt die Teamleitung auf „Freigeben“ und schreibt dazu ins Kommentarfeld: „Menge bitte prüfen, 500 statt 50?“ Weil der Workflow nur auf den Status schaut, geht die Bestellung weiter an den Einkauf, während der Kommentar in einem Feld liegt, das auf diesem Weg niemand mehr öffnet.

Prüft beim Speichern ein Noul, ob der Kommentar einen Einwand oder Vorbehalt enthält, bekommt die Freigabe im Zweifel den Vermerk „mit Vorbehalt“, und wer die Bestellung angelegt hat, erfährt sofort davon. Entscheiden müssen nach wie vor die Menschen, nur geht der Vorbehalt nicht mehr unter.

Wo die Grenzen liegen

Die neun Fälle haben gemeinsam, dass ein Fehler des Modells wenig anrichtet und sich leicht korrigieren lässt. Ganz folgenlos sind sie trotzdem nicht alle, denn beim Formular verschwinden Felder aus dem Blick, und beim Kommentar geht eine Benachrichtigung raus. Als Maßstab taugen deshalb die drei Kriterien aus dem verlinkten Praxistest: Eine Entscheidung eignet sich, wenn sie folgenarm ist, sich billig korrigieren lässt und nicht allein an einem unbegründeten Modellurteil hängt. Sobald am Ende eine Buchung, eine Freigabe oder eine Ablehnung steht, ist mindestens eines davon verletzt.

Was im Sachverhalt steht, wirkt dabei mit, auch wenn es mit der Frage nichts zu tun hat. Im selben Test hat eine sachfremde Angabe über die Person, die ein Ticket geschrieben hatte, dessen Einschätzung als dringend spürbar gesenkt, und TypeSafe führt irrelevanten Kontext selbst als bekannte Fehlerquelle. Für die Ticket- und Schadensbeispiele heißt das, dass Freitext von Kunden gefiltert werden sollte, bevor er in eine Urteilsfrage geht.

Eine weitere Grenze ergibt sich aus der fehlenden Begründung. Wo jemand einem Menschen eine Entscheidung erklären muss, etwa in einem Bescheid, fehlt mit ihr genau das, was verlangt ist.

In einem deutschen Refinement dürfte allerdings eine andere Frage zuerst kommen, nämlich die nach dem Datenfluss. Jev läuft als gehosteter Dienst in den USA, und wer den Weg über ein Gateway nimmt, schaltet noch einen Dienstleister dazwischen. Bevor Schadenmeldungen oder Kontaktdaten dorthin gehen, muss das geklärt sein, und wo es sich nicht klären lässt, bleiben die offenen Nachbauten als lokale Alternative.

Und in deinem Projekt?

Oberflächen sind dabei nur ein Einsatzfeld unter mehreren. In späteren Posts wird es um Entscheidungen im Code gehen, wo bisher eine Heuristik oder eine wuchernde Regelkaskade steht, und um LLM-Agenten, die das schnelle Modell als Werkzeug aufrufen, anstatt jeden Zwischenschritt selbst auszuformulieren.

Deine eigene Anwendung sieht sicher anders aus als unsere Beispiele, die Frage dahinter lässt sich aber übertragen: An welcher Stelle hast du um ein Urteil herumgebaut, weil es zu langsam oder zu teuer gewesen wäre? Vielleicht ist es das Pflichtfeld, das alle mit „siehe Mail“ ausfüllen, die Regex, die seit drei Jahren mit Sonderfällen wächst, oder die Ergebnisliste, die alphabetisch sortiert ist, weil niemand eine sinnvolle Reihenfolge bauen konnte.

Alle Angaben beziehen sich auf jev-1.13.0, Stand Ende September 2026. Preise, Antwortzeiten und Modellversion können sich ändern.