Intro: ein Hinweis, keine Ersparnis
Jev macht Claude Code nicht billiger, und das sagt der eigene Benchmark des Gateways. Dieser Artikel liest den Code von jev-gateway und dessen Benchmark-Repository, dann setzt er einen Logging-Proxy vor eine echte Claude-Code-Session, um zu sehen, was ein Router tatsächlich bekommt.
Jev ist TypeSafes Entscheidungsmodell: eine Wahrscheinlichkeit, zurückgegeben in Millisekunden, eingebunden in Claude Code durch sechs Videos in einer Woche. Der Pitch lautet „die günstigste agentische Coding-Loop“. Die eigenen Zahlen des Gateways zeigen, dass Opus 5 bei aktiviertem Routing 47 % mehr Anfragen stellt und 83 % mehr Zeit für eine Feature-Aufgabe braucht.
Wie macht ein Router, der in Millisekunden antwortet, Claude Code langsamer? Es läuft auf eine einzige Zeile Code hinaus. Innerhalb von Claude Code bekommt Jev genau zwei Sätze, und eine normale Session übergibt ihm bei jedem Aufruf 40 Tools.
Was Jev ist, und was die Welle verkauft
Jev ist ein Entscheidungsmodell von TypeSafe. Es generiert keinen Text: Man stellt eine typisierte Frage, und es antwortet mit einer Wahl, einem Score oder einer Ja/Nein-Wahrscheinlichkeit. Die Zahlen des Anbieters:
| Kennzahl | Wert |
|---|---|
| Preis pro Input | $0,04 pro Million Token |
| Preis pro Output | kostenlos („zu billig zum Abrechnen“) |
| Latenz | 70 bis 500 ms |
| Headline auf der Startseite | 194× schneller, 445× günstiger |
Der Blogpost unter dieser Headline sagt, die beiden Multiplikatoren seien das obere Ende realer Gewinne, gemessen gegen den Durchschnitt zweier Frontier-Modelle – ein Vergleich, den die Autoren selbst als zugunsten dieser Modelle verzerrt einräumen.
Sechs Videos in fünf Tagen haben Jev in Claude Code eingebunden. Das größte davon steht bei 139.000 Aufrufen und nennt es die bislang günstigste agentische Coding-Loop. Zwei Repositories tragen die Welle: jev-gateway, ein lokaler Proxy für Claude Code und Codex, fünf Tage zuvor mit 181 Stars erstellt, und fast-jev-compaction, ein Compaction-Plugin, einen Tag davor erstellt, bei 6.400 Stars. Das Gateway ist die Stelle, an der Claude Code andockt, also beginnt dort die Lektüre.
Eine Env-Var, eine Zeile: Hint-Modus
jev-gateway sitzt zwischen Claude Code und der Anthropic-API. Es startet Claude Code mit einer einzigen Umgebungsvariable, ANTHROPIC_BASE_URL, die auf einen lokalen Port zeigt. Sonst ändert sich nichts; ein Kommentar im Quellcode sagt, es gebe kein Gateway-Credential, sodass ein Pro- oder Max-Login unverändert weiterfunktioniert.
Innerhalb des Adapters (src/adapters/messages.ts, Zeile 99) entscheidet eine Zeile darüber, was Jev tun darf:
steer: thinking || cached ? "hint" : "tool_choice"
Bei aktiviertem Extended Thinking oder einer gecachten Konversation kann das Gateway nur einen Hinweis geben. Andernfalls erzwingt es das Tool. Der Kommentar über der Zeile erklärt, warum: Die API lehnt ein erzwungenes Tool bei aktivem Extended Thinking ab, und ein geänderter tool_choice macht die gecachte Konversation ungültig, die Claude Code bei jedem Turn neu einliest.
Um zu prüfen, wie eine echte Anfrage aussieht, nahm ein 60-zeiliger Logging-Proxy den Platz des Gateways auf einer Port-Konfiguration derselben Art ein, mit Claude Code darüber gestartet und einer einzigen Anfrage auf einem echten Repository. Die Anfrage trägt thinking: adaptive und drei Cache-Marker; tool_choice fehlt; 24 Tools reisen bei einer sauberen Installation mit. Wendet man die Zeile des Gateways auf diese Anfrage an, greift der erzwungene Pfad nie. Jeder Claude-Code-Aufruf landet im Hint-Modus. Das README sagt es selbst: Erwarte bessere Tool-Auswahl bei langen Tool-Listen, nicht niedrigere Kosten oder Latenz.
Der Hinweis: zwei Sätze, und wo er nicht landet
Was darf Jev innerhalb von Claude Code tun? Zwei Sätze, angehängt an die letzte Nachricht: „a routing model suggests this tool is the most relevant move now. Ignore this if it doesn't fit.“ Das ist der gesamte Eingriff. Das Modell darf ihn ignorieren, und tool_choice bleibt auf auto.
Ein Tool zu erzwingen ist keine Option, laut Anthropics Dokumentation: Ein erzwungenes Tool liefert bei Opus 5.5 und Fable 5.1 einen 400er-Fehler und bei den übrigen Modellen einen Fehler, wenn manuelles Thinking aktiv ist. Auch eine Änderung von tool_choice fällt aus: Die Dokumentation zum Prompt-Caching sagt, das mache den Messages-Cache ungültig, den größten Teil einer langen Session. Die Beschreibung eines Tools zu bearbeiten macht den gesamten Cache ungültig: Tools, System und Messages.
| Änderung an der Anfrage | Wirkung auf den Prompt-Cache |
|---|---|
| Hinweis an die letzte User-Nachricht anhängen | gecachter Präfix bleibt unverändert |
tool_choice ändern |
Messages-Cache ungültig |
| Tool-Definition bearbeiten | Tools, System und Messages ungültig |
Der Kommentar im Gateway erklärt, warum der Hinweis ganz am Ende steht: Der gecachte Präfix bleibt Byte für Byte identisch mit dem, was Claude Code beim nächsten Turn erneut sendet. Davor sitzt eine Absicherung: Ist die letzte Nachricht nicht die des Users, läuft die Anfrage unverändert durch. Beide aufgezeichneten Anfragen endeten auf einem System-Block, den Claude Code selbst anhängt – einmal ein Environment-Reminder, einmal die Ausgabe eines Hooks. Bei dieser Form hat der Hinweis nirgends Platz. Auf anderen Turns landet er durchaus, da Tool-Ergebnisse als User-Nachrichten zurückkommen, und der Benchmark zählt, dass Jev ein Drittel bis die Hälfte der Claude-Code-Anfragen steuert.
Der Benchmark, den niemand zitiert
Der eigene Benchmark des Gateways, jev-gateway-bench, beantwortet die Eingangsfrage. Er lief über 120 Sessions, fünf Durchläufe pro Zelle, auf demselben Claude Code und demselben Abo, das jeder nutzt, ohne MCP-Server, Plugins oder Skills. Zwei Aufgaben auf einer kleinen Schach-Engine: eine Fehlersuche mit fünf eingebauten Bugs, und ein Feature, die Ergänzung der algebraischen Notation.
| Modell, Aufgabe | Routing an vs. aus |
|---|---|
| Opus 5, Feature | +61 % Input-Token, +47 % Anfragen, +83 % Zeit (dennoch 5/5 gelöst) |
| Sonnet 5, Feature | +16 % Input-Token, +37 % Zeit |
| Sonnet 5, Fehlersuche | −48 % Input-Token, −25 % Zeit |
Bei der Fehlersuche zahlt sich Routing aus, in den Worten der Autoren. Ihre Erklärung ist zugleich die Antwort auf die Ausgangsfrage: Das Gateway kann bei Claude-Modellen nur hinweisen, also kostet ein unpassender Hinweis einen Umweg, statt kostenlos ignoriert zu werden.
Codex bekommt die erzwungene Variante. Jev entschied 76 bis 100 % der Codex-Anfragen, gegenüber einem Drittel bis der Hälfte bei Claude Code. Ein Modell in der anderen Harness wurde günstiger und falsch: drei von fünf Lösungen statt fünf. Günstiger und falsch ist keine Ersparnis.
Die Grenzen sind real: Fünf Durchläufe pro Zelle sind eine kleine Stichprobe, es ist eine einzige Spielzeug-Engine, und niemand hat den Test wiederholt. Auch der Input ist größtenteils gecacht, sodass eine Input-Ersparnis weniger wert ist als eine Output-Ersparnis.
Was meine Session ihm gibt: 24 Tools sauber, 40 voll
Was übergibt eine normale Claude-Code-Session einem Router bei jedem Aufruf? Das Proxy-Log gibt die Antwort: 40 Tools. Gleiches Repository, gleicher einwortiger Prompt, zwei Setups: eine saubere Installation mit leerer Konfiguration und ohne MCP-Server, und ein normales Setup mit seinen Servern und Plugins.
| Saubere Installation | Normales Setup | |
|---|---|---|
| Tools in der Anfrage | 24 | 40 (16 davon von MCP-Servern und Plugins) |
| Abgerechnete Präfix-Token | 47.411 | 57.277 |
| Output-Token | 4 | 4 |
| API-äquivalente Kosten für ein „ok“ | $0,07 | $1,15 |
Die Tool-Liste ist die Rechnung. Die schwersten Definitionen sind fest eingebaut: Allein das Shell-Tool umfasst 12.000 Zeichen, das Agent-Tool fast 9.000.
Die Fußnote des Benchmarks sah bei einer sauberen Installation sechs Tools und 7.000 Token, und 285 Tools bei einem vollgeladenen Setup. Das heutige, saubere Claude Code liefert von Haus aus deutlich mehr Tools mit, und der vollgeladene Fall ist seltener geworden: Die meisten MCP-Tools stecken hinter einem Such-Tool, deferred, sodass die Liste, die ein Router zu sehen bekommt, klein bleibt. Wie groß sie auch ist, das Gateway schickt diese Liste bei jeder Anfrage an Jev; ein offenes Issue im Repository sagt, die vollen Kosten fallen an, bevor die meisten Antworten verworfen werden. Nichts davon ist Jevs Schuld, und nichts davon ist Jevs zu beheben.
Fazit je nach Einsatz
Routing innerhalb von Claude Code: nein. Es ist ein Hinweis, den das Modell ignorieren darf, er machte Feature-Arbeit bei beiden Claude-Modellen langsamer, und der einzige Gewinn liegt bei der Fehlersuche. Die Ausnahme ist ein Tag voller Bug-Hunts auf einer sehr großen Tool-Liste, genau der Fall, den das README selbst nennt.
Das Compaction-Plugin, fast-jev-compaction: noch nicht. Es braucht ein Early-Access-Hook-Flag, seine offenen Issues berichten, dass die Hooks bei manchen Builds nicht registrieren, und nach einer Compaction schrieb das Modell neun Berichte, die Arbeit sei erledigt – allesamt erfunden. Praktiker kamen dem zuvor: Der Top-Thread zum Plugin hat 491 Punkte, und sein Haupteinwand ist nicht die Geschwindigkeit, sondern die Nutzungsbedingungen für das Senden von Transkripten an einen Drittanbieter.
Codex: das ist das eigentliche Ziel. Dort erzwingt das Gateway das Tool, Jev steuerte bis zu jede Anfrage, und die Fehlersuche lief mit 57 % weniger Output-Token.
| Einsatz | Fazit |
|---|---|
| Routing in Claude Code | Nein, außer bei Bug-Hunts auf einer sehr großen Tool-Liste |
| fast-jev-compaction | Noch nicht |
| Codex | Ja |
Eines hat die Welle richtig gemacht: Der Abo-Login bewegt sich nie, das Gateway ändert nur eine URL. Die Grenzen dieser Lektüre: fünf Durchläufe pro Zelle, eine einzige Schach-Engine, ein Benchmark-Repository, das niemand wiederholt hat, und keine eigene geroutete Session. Gemessen habe ich die Tool-Liste und die Anfrage, nicht Jev. Jev selbst ist günstig. Der Umweg nicht.
AIDive