PostHog Jeeves: das offene Entscheidungsmodell, das nachdenkt, bevor es wählt

Was ist PostHog Jeeves?

Jeeves ist ein „reasoning Jev-style classifier with a diffusion drafter“, den PostHog am 29. September 2026 veröffentlicht hat. Gebaut hat es Nicholas Waltz, AI Research Engineer im AI-Research-Team von PostHog, der zuvor zwei Jahre in einem YC-Startup RL-Modelle für Drohnenlieferungen entwickelt hat, laut seinem PostHog-Profil.

Um Jeeves zu verstehen, muss man wissen, was es nachbaut. Ein „Entscheidungsmodell“ schreibt keinen Text. Sie schicken ihm einen Zustand (eine E-Mail, ein Ticket, einen JSON-Block) und eine Reihe typisierter Fragen, und es schickt für jede Antwortoption eine Wahrscheinlichkeit zurück. Die Kategorie wurde zwei Wochen vorher bekannt, als TypeSafe Jev vorstellte, mit drei Fragetypen: einem Ja/Nein-noul, einem Auswahl-choice und einem Bewertungsraster score. Jev ist geschlossen und gehostet. Binnen Tagen veröffentlichte Jared Palmers Kev offene, Jev-kompatible Gewichte, und Jeeves nennt Kev als Inspiration.

Was Jeeves hinzufügt, ist das Nachdenken. Die README beschreibt das Problem unverblümt: Jev-artige Modelle „give calibrated decision probabilities, but at low accuracy“, daher „a lot of pipelines therefore rely on a reasoning model as a fallback.“ Dieser Fallback ist meist ein gehostetes LLM, das pro Token abgerechnet wird, die Art Kosten, die ich in Claude Sonnet 5.5 pricing aufgeschlüsselt habe. Jeeves versucht, dieser Fallback zu sein, in Jevs eigener Form.

Die wichtigsten Daten:

Ich bin Alicia und baue die KI-Agenten in eesel, ich beschäftige mich also viel mit genau dieser Schicht: dem Teil der Pipeline, der entscheidet, was ein Ticket ist, bevor etwas geschrieben wird. So macht Jeeves das, und hier verdient es sich seinen Platz.

Wie begründet Jeeves, bevor es entscheidet?

Der Mechanismus ist ein hübsches Stück Engineering und erklärt sowohl den Genauigkeitsgewinn als auch die Latenzkosten.

Jeeves lädt den Zustand und jede Frage mit seltenen, kaum genutzten Tokens als Markern in das Qwen-Chat-Template (<|fim_prefix|> für den Zustand, <|box_start|> für jede Option und so weiter). Dann tut es etwas, das Jev nicht tut: Es erzeugt innerhalb eines <think>-Blocks eine freie Begründungskette. Nachdem die Kette geschlossen ist, werden Frage und Optionen wiederholt, und ein kleiner Pointer-Head bewertet jede Option, indem er den versteckten Zustand an einem <decide>-Token mit dem versteckten Zustand am Ende jeder Option vergleicht. Ein Softmax über diese Werte, geteilt durch eine auf Dev-Daten angepasste Temperatur (1.859, laut Hugging-Face-Modellkarte), ergibt die endgültigen Wahrscheinlichkeiten.

Zwei Details aus den Ablationen sind wissenswert, falls Sie so etwas selbst trainieren. Das Ersetzen der seltenen Tokens durch gewöhnliche Wörter wie „State“ verschlechterte die Ergebnisse. Ebenso das Weglassen der wiederholten Frage nach dem Begründungsblock. Das Modell muss kurz vor der Festlegung an die Optionen erinnert werden.

Das Training lief in drei Stufen, alle im Repo dokumentiert:

1. Supervised Fine-Tuning: 2 Epochen, 596 Schritte auf 8 GPUs, über 19,126 Fragen aus 12 öffentlichen Datensätzen plus synthetischen Policy-Daten. Die Hälfte der Fragen enthielt eine vom Basismodell gesampelte Begründungskette.
2. Reinforcement Learning mit CISPO: die RL-Methode aus MiniMax-M1, auf 9,992 Fragen mit je 8 Rollouts, begrenzt auf 2,560 Denk-Tokens. Der Plan über 624 Schritte wurde bei Schritt 402 gestoppt, weil danach „the head over-sharpens“ und die Kalibrierung schlechter wird.
3. Kalibrierung: eine einzelne Temperatur, auf Dev angepasst und mit dem Checkpoint gespeichert.

Den Stopp bei Schritt 402 würde ich unterstreichen. Das Team opferte etwas Rohwert, um die Wahrscheinlichkeiten ehrlich zu halten, und genau deshalb nutzt man überhaupt ein Entscheidungsmodell. Ein Modell, das 90 % sagt und in 70 % der Fälle richtig liegt, ist in einer Routing-Pipeline schlimmer als nutzlos, und es ist dasselbe Grundproblem hinter den meisten KI-Halluzinationen im Support.

Um Tempo zurückzuholen, liefert Jeeves einen Diffusion-Drafter mit, der für spekulatives Decoding mehrere Begründungs-Tokens auf einmal vorschlägt. Bei einer Frage hebt er die Kettengeschwindigkeit mit Block-4-Drafting von 109 auf 176 Tokens pro Sekunde und bei acht gebündelten Fragen auf insgesamt etwa 960 Tokens pro Sekunde.

Wo schlägt Jeeves Jev, und wo verliert es?

PostHogs Ergebnistabelle ist ungewöhnlich offen, und das Muster darin ist das Nützlichste am Launch.

*PostHog vermerkt, dass für Kev-9B kein JevBench-Ergebnis veröffentlicht ist, diese Zellen sind also Kev-8B. Alle Zahlen aus der Jeeves-README.

Liest man die Tabelle von oben nach unten, zeigt sich eine Trennung. Wo es darum geht, Regeln auf eine unordentliche Eingabe anzuwenden (zurückgehaltene Regelstrukturen, kontrastive Policies, Paraphrasenerkennung, JevBench hard), gewinnt das Nachdenken, teils deutlich. Wo es darum geht, eine Tatsache zu wissen (MMLU, MMLU-Pro), gewinnt Jev um etwa 10 Punkte. Nachdenken kann Wissen nicht herbeizaubern, das ein 9B-Modell nicht hat. Für Wissen verankern Support-Teams das Modell meist in ihren eigenen Dokumenten, der Kompromiss ist in RAG vs Fine-Tuning beschrieben.

Diese Trennung passt gut zur Support-Arbeit. „Fällt diese Erstattungsanfrage in unsere 30-Tage-Regel, wenn das Bestelldatum in Absatz drei vergraben ist?“ ist eine Regelfrage. „Was ist die Hauptstadt von Peru?“ taucht nie in einer Ticket-Warteschlange auf. Wenn Ihre Entscheidungen der ersten Art ähneln, spricht die Tabelle für Sie.

Zwei ehrliche Einschränkungen von PostHog selbst: Die Vergleiche mit Kev und Jev außerhalb von JevBench „use different items from the same sources“, und die Begründungsketten sind nicht sehr lesbar, weil „no language consistency reward was included.“ Sie bekommen die Antwort und eine Kette, aber planen Sie nicht, diese Kette einem Prüfer zu zeigen.

Wie langsam ist „Nachdenken“ in der Praxis?

Hier gab es im Hacker-News-Thread den stärksten und berechtigten Widerspruch.

PostHog hat drei Einstellungen an 325 Dev-Fragen gemessen, auf einer H100 mit FP8:

Die mittlere Zeile würde ich tatsächlich einsetzen. max_think schneidet jede Begründungskette bei einem Token-Budget ab, und nothink_threshold überspringt das Nachdenken ganz, wenn die schnelle Antwort bereits sicher ist. Sie behalten den größten Teil des Genauigkeitsgewinns (0.806 vs 0.775) und senken die p90-Latenz um zwei Drittel.

Zum Vergleich: Jevs eigenes Versprechen sind 70 bis 500 Millisekunden pro Aufruf, was ich in meinem Jev-Geschwindigkeitstest behandelt habe. Die HN-Leute haben es bemerkt:

"Cool engineering, but 17s p90 latency kind of defeats the point of a Jev-class model, which is supposed to be fast and cheap."

itzikkatz, Hacker News

Das stimmt, wenn man Jeeves als Jev-Ersatz betrachtet. Weniger, wenn man es als das betrachtet, was nach dem schnellen Modell läuft, wenn dieses mit den Schultern zuckt. Ein Kommentator beschrieb die Architektur schlicht:

"Seems like this is the way, a hybrid approach where some of the pipeline will be jev like and some traditional LLM depending on the nature of the work."

swader999, Hacker News

Jeeves fasst diesen Hybrid in einem Modell zusammen. Nachdenken aus ist Ihre schnelle Stufe. Nachdenken an ist Ihre langsame Stufe. Und weil beide Stufen eine API und eine Kalibrierung teilen, müssen Sie die Wahrscheinlichkeiten eines Klassifikators nicht mit der Freitextantwort eines LLM abgleichen.

Was passiert bei einem echten Support-Ticket?

Die Demo-Anfrage in der README ist ein Support-Ticket, das machte meine Arbeit leicht. Der Zustand lautet: „Shoes arrived two weeks late and in the wrong size. Also I see two charges on my card.“ Drei Fragen kommen mit: welche Abteilung, ob eskaliert werden soll und wie frustriert der Kunde ist.

Jeeves antwortete mit billing 0.46, returns 0.40, shipping 0.14 und einer Choice-Sicherheit von nur 0.19. Eskalation erhielt 0.72. Frustration lag bei 1.5 auf einer Skala von 0 bis 2. Die ganze Anfrage dauerte 8.1 Sekunden, wobei die drei Fragen parallel nachdachten.

Hier dasselbe Ticket (plus ein zusätzlicher Satz) in Kevs Playground mit Kev-4B:

Kev-4B sagte returns mit 0.91 in 670 Millisekunden. Es ist ein kleineres Modell und der Prompt unterscheidet sich leicht, es ist also kein sauberer Direktvergleich. Aber sehen Sie sich das Ticket an. Es enthält tatsächlich zwei Probleme, die zwei Teams gehören. Kev antwortete schnell und klang sicher. Jeeves dachte nach und sagte sinngemäß: „Das ist knapp, und ich bin nicht sicher.“

Für eine Support-Warteschlange ist die zweite Antwort die nützlichere. Eine sichere falsche Zuordnung bedeutet, dass der Kunde in der Retouren-Warteschlange wartet, während seine doppelte Abbuchung unbearbeitet liegt. Eine unsichere Aufteilung ist das Signal, etwas Klügeres zu tun: an Billing routen und Returns taggen, das Ticket aufteilen oder es mit einer sauberen KI-zu-Mensch-Übergabe an eine Person schicken.

Das deckt sich mit dem, was ich bei eesel an echten Warteschlangen gesehen habe. In einem Test mit echtem Traffic in einem E-Commerce-Postfach waren die Entscheidungen der verlässliche Teil: 93 % Triage-Genauigkeit und 100 % Spam-Erkennung ohne Falschpositive. Bei den generierten Antworten haperte es, mit 7 % Faktenfehlern in Entwürfen. Klassifizierung ist die Hälfte der Support-KI, der man früh vertrauen kann, solange das Modell zugibt, wenn es unsicher ist. Ich habe auch gesehen, wie selbstsicher klingende Bots stillschweigend falsche Antworten gaben, weshalb jeder eesel-Rollout gegen historische Tickets simuliert wird, bevor er einen Live-Kunden berührt. Ein kalibriertes „Ich weiß es nicht“ ist mehr wert als ein schneller Tipp.

Wer sollte PostHog Jeeves tatsächlich nutzen?

Jeeves ist ein Forschungs-Release, kein Produkt, und es liest sich so, ähnlich wie ein Großteil der Landschaft der Open-Source-KI-Agenten: vollständiger Trainingscode, Train/Dev/Test-Daten, ein Reproduktionsskript, kein gehosteter Endpunkt. Die Modellseite auf Hugging Face vermerkt, dass das Modell „isn't deployed by any Inference Provider.“

So würde ich es einordnen:

Erste Community-Tests sind für Moderationsaufgaben ermutigend. Ein HN-Kommentator hat es mit eigenen Daten laufen lassen:

"Update: Jeeves took about 2 hours to moderate 394 data points and performed really well. It's not as good as Jev, but it's super close!"

TN1ck, Hacker News

Beachten Sie die „2 hours“. Das ist wieder die Nachdenk-Steuer auf Hardware, die keine H100 ist. Ein PostHog-Ingenieur, Robbie Coomber, antwortete im selben Thread, dass ein MPS-Port in Arbeit sei, um Apple Silicon zu beschleunigen, und das Repo zeigt, dass er inzwischen gemergt wurde.

Wenn Sie das einbauen, lohnt sich vorab ein Blick auf die vollständige Übersicht der Jev-Alternativen, denn strukturierte Ausgaben bei gehosteten LLMs könnten Ihren Fall ohne GPU abdecken.

Was ein Entscheidungsmodell für Ihr Helpdesk nicht leistet

Hier möchte ich die Perspektive verschieben. Ein Entscheidungsmodell beantwortet „Was ist dieses Ticket?“ sehr gut. Es beantwortet nicht „Was tun wir jetzt?“. Jemand muss weiterhin den Code schreiben, der billing: 0.46 in ein Helpdesk-Tag verwandelt, in eine Antwort, eine Erstattungsprüfung, eine Eskalation mit Notiz und eine Aufzeichnung des Warum.

Hier zeigt sich der Unterschied zwischen Infrastruktur und einem Mitarbeiter. Jeeves, Jev und Kev sind Infrastruktur: hervorragende, günstig zu betreibende Bausteine für Ticket-Klassifizierung, Priorisierung und Stimmungsanalyse. Ein KI-Teammitglied ist der Mitarbeiter, der dieselben Entscheidungen in Ihrem tatsächlichen Helpdesk trifft und dann die Arbeit erledigt. Wenn Sie beides abwägen, zeigt mein Leitfaden zum Automatisieren der Ticket-Triage den Kompromiss zwischen Selbstbau und Einstellen ausführlicher.

eesel ausprobieren

Wenn Sie Jeeves ansehen, weil Sie klügere Triage wollen, möchten Sie wahrscheinlich kein 9B-Modell hosten und den Kleber drumherum schreiben. eesels KI-Helpdesk-Teammitglied steigt in Ihre bestehende Warteschlange in Zendesk, Freshdesk oder Help Scout ein, lernt aus Ihren vergangenen Tickets und Ihrem Help Center und trifft bei jedem Ticket die Entscheidung über Routen, Taggen und Eskalieren, gemäß den Eskalationsregeln, die Sie bereits nutzen. Dann entwirft oder sendet es die Antwort und übergibt die wirklich unsicheren Fälle mit einer Notiz an eine Person. Bevor es live geht, können Sie es an Hunderten Ihrer vergangenen Tickets simulieren und genau sehen, wo es richtig und wo falsch gelegen hätte.

Wenn der Self-Hosting-Reiz von Jeeves eigentlich Kontrolle per Code meint, deckt das die eesel-CLI ab. Sie führt dasselbe Teammitglied von Ihrem Terminal aus: eesel activity listet jeden Lauf und zeigt einen im Detail, eesel approvals lässt Sie Aktionen genehmigen oder ablehnen, die einen Menschen brauchen, und eesel instructions bearbeitet die dauerhaften Regeln des Teammitglieds. Jeder Befehl gibt JSON aus, schreibende Befehle unterstützen --dry-run, damit Sie den genauen Aufruf vorab sehen, und der Workspace dient zugleich als MCP-Server, sodass Coding-Agenten wie Claude Code ihn direkt steuern können. Mehr dazu in meinem Leitfaden zur KI-Agenten-CLI.

Wenn Sie es mit der eingebauten KI Ihres Helpdesks vergleichen, ist der Vergleich eesel vs Zendesk AI die nächste gute Lektüre. Der Start ist kostenlos mit 100 Credits und ohne Karte, und ein Ticket oder Chat zählt als ein Credit, laut Preisseite. Testen Sie eesel an Ihrer eigenen Warteschlange und sehen Sie, wie viele Tickets es letzten Monat richtig geroutet hätte.