TypeSafe AIs Jev und "System One Models": Was tatsächlich veröffentlicht wurde

Auf Geschwindigkeit ausgelegt: ~ 10 ms Latenz, auch unter Last
Unglaublich schnelle Methode zum Erstellen, Verfolgen und Bereitstellen Ihrer Modelle!
- Verarbeitet mehr als 350 RPS auf nur 1 vCPU — kein Tuning erforderlich
- Produktionsbereit mit vollem Unternehmenssupport
Was TypeSafe AI veröffentlicht hat
TypeSafe AI ist ein KI-Labor, das von Diogo Almeida – ehemals bei OpenAI, wo er an der Forschung zum Befolgen von Anweisungen arbeitete, aus der ChatGPT hervorging – sowie Erik Gafni und Sasha Sheng gegründet wurde. Nach etwa zwei Jahren im Verborgenen veröffentlichte das Unternehmen am 15. September 2026 seinen Launch-Beitrag, flankiert von einer Seed-Finanzierungsrunde in Höhe von 40 Millionen US-Dollar unter der Leitung von DCVC. DataCamp und mehrere Fachmedien berichteten in den darauffolgenden Tagen darüber.
Die Argumentation im Launch-Beitrag ist eher eine Fragestellung als ein Benchmark: Modelle sind seit Jahren bei Chat-Anwendungen übermenschlich gut, wo bleibt also die Automatisierung? Die Antwort von TypeSafe lautet, dass der Engpass nie die reine Intelligenz war – sondern dass ein Modell, das in Prosa antwortet, eine unhandliche Komponente für die Softwareentwicklung ist. Das Firmenmanifest drückt es deutlicher aus: Die heutige KI wurde unter der Annahme trainiert, dass auf der anderen Seite ein Mensch sitzt.
Jev ist das erste Modell, das auf dieser Prämisse aufbaut. Der Name stammt von William Stanley Jevons, dessen Paradoxon besagt, dass sinkende Kosten den Verbrauch steigern; „System One“ ist eine Anspielung auf Daniel Kahnemans schnelles, intuitives System-1-Denken, im Gegensatz zum langsamen, bewussten System-2-Denken.
Was ein „System-One-Modell“ eigentlich ist
Unter den Arten von KI-Modellen , die man in der Produktion einsetzen würde, zeichnet sich dieses Modell dadurch aus, worauf es verzichtet. Ein Chat-Modell liefert eine Zeichenkette zurück, und eine Zeichenkette kann alles sein – eine Antwort, eine Verweigerung, ein Absatz voller Überlegungen oder etwas Fehlerhaftes, an dem Ihr Parser scheitert. Jev liefert überhaupt keine Zeichenketten zurück.
Stattdessen definieren Sie vorab die Struktur der Antwort: welche Felder Sie wünschen und welche Werte für jedes Feld zulässig sind. Das Modell gibt diese Felder ausgefüllt zurück, jeweils mit einer zugehörigen Wahrscheinlichkeit. TypeSafe beschreibt das Ergebnis als einen Funktionsaufruf mit Spitzenintelligenz – unstrukturierter Status rein, typisierte probabilistische Entscheidungen raus. In der Praxis verhält es sich weniger wie ein Chatbot und mehr wie eine KI-Entscheidungsmaschine , die Sie aus einer Codezeile heraus aufrufen können.
Aus diesem Design ergeben sich drei Eigenschaften:
- Paralleles Sampling. Jedes Feld wird in einem einzigen Durchgang erstellt, anstatt Token für Token – daher stammt auch das Versprechen der hohen Geschwindigkeit.
- Schema-Konformität durch Konstruktion. Da mögliche Ausgaben vorab aufgezählt werden, ist ein Typfehler nicht unwahrscheinlich – er ist schlicht unmöglich. TypeSafe merkt an, dass dies mit einem einzigen Gegenbeispiel trivial zu widerlegen wäre.
- Kalibriertes Vertrauen bei jeder Antwort. Jeder Output ist mit einer Wahrscheinlichkeit versehen, und das Trainingsziel – von TypeSafe als Reinforcement Learning for Calibrated Decisions (RLCD) bezeichnet – optimiert darauf, dass diese Wahrscheinlichkeiten ehrlich sind, anstatt auf menschliche Präferenzen (RLHF) oder programmatisch verifizierbare Belohnungen (RLVR) zu setzen.

Ein Chat-LLM erstellt seine Antwort Token für Token; ein System-One-Modell füllt jedes Feld eines festen Schemas in einem Durchgang aus, jeweils mit einem Konfidenzwert.
Diese dritte Eigenschaft wird am ehesten unterschätzt. Ein Modell, das zu 95 % richtig liegt, aber nicht sagen kann, welche Aufrufe in die restlichen 5 % fallen, lässt sich nicht automatisieren. Eines, das ehrliche Unsicherheit meldet, hingegen schon – man kann basierend auf dem Konfidenzwert verzweigen und Fälle mit geringer Konfidenz an einen Menschen oder ein größeres Modell weiterleiten.
Unterschiede zu einem Chat-LLM
Eine praktische Grenze, die man kennen sollte: Jev unterstützt eine Kardinalität von bis zu 255 Optionen pro Auswahl. Darüber hinaus verwendet TypeSafe einen zweistufigen Ansatz – Kandidaten werden unabhängig bewertet und anschließend eine explizite Auswahl getroffen –, was, wie das Unternehmen einräumt, langsamer ist.
Was ist verifizierbar und was ist eine Behauptung des Anbieters
Hier lohnt es sich, genauer hinzusehen, da die Zahlen zum Start ungewöhnlich hoch sind und die Belege dafür ungewöhnlich in sich geschlossen wirken. Positiv hervorzuheben ist, dass TypeSafe in seinem Beitrag unter jedem Ergebnis eigene „Nuancen“-Anmerkungen aufführt, aus denen der Großteil der folgenden Informationen stammt.
Aktuell unabhängig überprüfbar:
- Preisgestaltung. Offen veröffentlicht. Was sich nicht verifizieren lässt, ist, ob sie nachhaltig ist oder subventioniert wird – TypeSafe äußert sich dazu selbst und geht davon aus, dass die Preise eher sinken als steigen werden.
- Schema-Konformität. Eine Garantie für die Struktur der Ausgabe lässt sich durch eine einzige fehlerhafte Antwort widerlegen; die von TypeSafe angegebene Fehlerrate von 0 % bei Typenfehlern ergibt sich aus der Konstruktion und wurde nicht gemessen.
- Latenz pro Aufruf. Jeder mit Vorabzugang kann dies messen, wobei zu beachten ist, dass die veröffentlichten Testläufe von den Laptops des Teams an der US-Westküste stammten.
- Der Start selbst. Finanzierung, Hintergrund der Gründer und Verfügbarkeit sind durch unabhängige Presseberichte belegt.
Selbst berichtet und noch nicht unabhängig reproduziert:
- Die Werte für 193,6-mal schneller / 444,6-mal günstiger. Diese stammen aus TypeSafes eigenen Workflow-Evaluierungen – einem neuen Bewertungsformat, das das Unternehmen entwickelt hat. Dabei durchläuft jedes Modell denselben Rechengraphen und wird anhand von Referenzwahrscheinlichkeiten bewertet, die aus dem Durchschnitt von GPT-6 Astra und Fable 5.1 abgeleitet wurden. TypeSafe weist selbst auf drei Einschränkungen hin: Die Workflows wurden vom eigenen Team für Modellfähigkeiten erstellt, die Auswahl der Referenzmodelle verzerrt die Ergebnisse zugunsten von OpenAI und Anthropic, und konkurrierende LLMs werden über TypeSafes eigenen System-One-Adapter ausgeführt.
- Intelligenzparität mit Frontier-Modellen. Die Behauptung bezieht sich auf Parität bei Aufgaben, die auf System One zugeschnitten sind und wurde spezifisch hauptsächlich gegen GPT-5.6 Terra gebenchmarkt. Es handelt sich nicht um eine Aussage über allgemeine Fähigkeiten und sollte auch nicht als solche verstanden werden.
- Der Vergleich der Halluzinationsraten. Die LLM-Zahlen in dieser Grafik stammen aus dem OpenRouter-Traffic, von dem TypeSafe anmerkt, dass er wahrscheinlich verzerrt ist, da schwierigere Anfragen an leistungsfähigere Modelle weitergeleitet werden.
Noch unbekannt: Leistung bei öffentlichen Benchmarks, Verhalten bei Aufgaben, die nicht klar entscheidungsbasiert sind, Genauigkeit bei domänenspezifischen Arbeiten in der Praxis sowie jegliche Informationen zur Produktionszuverlässigkeit im großen Maßstab. Der Vorabzugang wurde erst diese Woche eröffnet.
Es gibt zudem ein sprachliches Detail, bei dem man präzise sein sollte, da es in Zusammenfassungen oft vereinfacht wird. TypeSafe sagt, Jev könne nicht halluzinieren, und im engeren Sinne ist das korrekt: Ein Modell, das niemals freien Text ausgibt, kann keine Zitate oder Tool-Namen erfinden. Aber LLM-Halluzinationen und Korrektheit sind nicht dasselbe Problem. Ein Modell, das auf drei zulässige Kategorien beschränkt ist, kann immer noch überzeugt die falsche wählen – eliminiert wurde die fehlerhafte Form der Antwort, nicht das fehlerhafte Urteil. Kalibrierung ist TypeSafes Antwort darauf, und genau diese Kalibrierung ist der Punkt, der unabhängig geprüft werden muss. Teams, die bereits strukturierte Ausgaben mit JSON-Schema nutzen, werden den Unterschied erkennen: Die Einschränkung der Form einer Antwort hat noch nie die inhaltliche Richtigkeit garantiert.
Wo ein Entscheidungsmodell in einen Produktions-Stack passt
Lassen wir den konkreten Launch einmal beiseite, denn die Struktur dahinter ist interessanter als die Zahlen. Was TypeSafe argumentiert – und worauf immer mehr Teams unabhängig voneinander kommen – ist, dass ein Allzweckmodell, das jede Anfrage beantwortet, ein Prototyping-Muster ist, kein Produktionsmuster.

Ein Produktions-Stack enthält letztlich mehrere Modelltypen gleichzeitig, wobei die Routing-Ebene entscheidet, welches Modell eine bestimmte Anfrage bedient.
Die Entscheidungen innerhalb eines laufenden Systems sind meist klein und repetitiv: Ist dieses Ticket dringend, in welche Warteschlange gehört es, verstößt diese Antwort gegen Richtlinien, welches dieser Felder ist die Rechnungsnummer? Jede dieser Anfragen an ein Frontier-Chatmodell zu senden funktioniert zwar, und Teams tun das auch, aber es bedeutet, Generierungspreise und Generierungslatenz für etwas zu zahlen, das eher einem Nachschlagevorgang entspricht. Das ist dasselbe Kalkül, das hinter der Entscheidung steckt, wann man ein kleines Modell spezialisiert, anstatt ein großes Modell zu nutzen, und deshalb ist Arbeit im Bereich Verifizierung – Scoring, Beurteilung, Erkennung von Jailbreaks, Agenten-Guardrails – der Anwendungsfall, mit dem TypeSafe vorangeht. Guardrails müssen bei jeder Anfrage laufen, was Kosten und Latenz zur entscheidenden Einschränkung macht, nicht die reine Leistungsfähigkeit.
Die Konsequenz für jeden, der KI in der Produktion einsetzt, ist ein KI-Orchestrierungsproblem und kein Problem der Modellauswahl. Wenn die richtige Antwort für manche Anfragen ein Chat-LLM ist, für andere ein schnelles Entscheidungsmodell und für eine dritte Gruppe ein feinabgestimmtes kleines Modell, dann muss die Ebene davor stabil sein – ein einheitlicher Aufrufpfad, konsistente Authentifizierung und Protokollierung sowie die Freiheit, das Modell für eine bestimmte Aufgabe zu ändern, ohne die Anwendung neu schreiben zu müssen. Das ist die Prämisse hinter Auto-Routing auf dem TrueFoundry AI Gateway, und deshalb ist ein Launch wie dieser als architektonisches Signal interessanter als als Benchmark.
Jev ist derzeit eine geschlossene gehostete API im Early Access, es gibt also nichts zu implementieren und keine Integration zu bewerten. Das mag sich ändern. Das Muster, das es repräsentiert, wird sich mit ziemlicher Sicherheit nicht ändern.
TrueFoundry AI Gateway bietet eine Latenz von ~3—4 ms, verarbeitet mehr als 350 RPS auf einer vCPU, skaliert problemlos horizontal und ist produktionsbereit, während LiteLM unter einer hohen Latenz leidet, mit moderaten RPS zu kämpfen hat, keine integrierte Skalierung hat und sich am besten für leichte Workloads oder Prototyp-Workloads eignet.



Steuern, implementieren und verfolgen Sie KI in Ihrer eigenen Infrastruktur
Aktuelle Blogs
Häufig gestellte Fragen
What latency does the TrueFoundry AI Gateway add?
Roughly 3–4 ms of overhead, handling 350+ RPS on a single vCPU. That matters more as model calls get faster: a routing layer that adds hundreds of milliseconds would erase the advantage of a sub-second decision model.









%20(28).webp)

.png)
.png)


.webp)


.png)
.png)
.png)
.webp)
.webp)

.png)
.png)
.png)
.png)
.png)
.png)
.png)





