OpenRouter Auto Router vs. Auto Code: Wann welcher Router passt

Ein Coding-Agent stellt andere Anforderungen als ein allgemeiner Chatbot – deshalb sollten beide nicht dieselbe Router-Einstellung nutzen. Für gemischten Traffic ist openrouter/auto die passende Wahl, für mehrstufige Coding-Sessions openrouter/auto-code. Wichtig dabei: Auto Code kostet pro gelöster Aufgabe in der Regel mehr als Auto. Die beworbenen 74% Ersparnis beziehen sich auf den Vergleich mit Opus 5.5.

OpenRouter hat beide Router am 6. November 2026 angekündigt; gestartet sind sie bereits am 5. November 2026. Unter der Haube verwenden sie dieselbe Routing-Engine. Sie unterscheiden sich vor allem bei der anfänglichen Modellklasse und darin, wie Fehlersignale den Verlauf einer Session beeinflussen. Eine zusätzliche Routing-Gebühr gibt es nicht: Abgerechnet wird jede Anfrage zum regulären Preis des ausgewählten Modells (OpenRouter-Ankündigung).

Auto für Allround-Aufgaben, Auto Code für Coding-Agenten

Auto Code ist der Router für Coding-Agenten. Er startet in einer höheren Preisklasse und bewertet Erfolgsquote, Geschwindigkeit sowie Kosten pro gelöster Aufgabe (OpenRouter-Ankündigung).

Weißt du bereits, welches Modell für deinen Workload am besten funktioniert, empfiehlt OpenRouter selbst, dabei zu bleiben. Router tauschen etwas Spitzenleistung gegen verlässlich kosteneffiziente Modellwahl ein – ohne dass du jede neue Veröffentlichung verfolgen musst (OpenRouter-Ankündigung).

Wie belastbar ist die Aussage „74% günstiger“?

Die Richtung stimmt, bei der konkreten Zahl sind aber Einschränkungen nötig. Die Angabe „74% weniger“ vergleicht Auto Code mit Claude Opus 5.5 anhand von fünf von OpenRouter selbst durchgeführten Benchmarks. Sie ist weder ein Vergleich mit Auto noch unabhängig verifiziert. Bis zum 6. November 2026, also einen Tag nach dem Start, gab es keine unabhängige Reproduktion (OpenRouter-Ankündigung).

Die vollständige Benchmark-Tabelle aus der Ankündigung zeigt mehr als nur die Schlagzeile:

Aus der Tabelle ergeben sich drei wesentliche Punkte (OpenRouter-Ankündigung):

1. Auto Code liegt bei 4 von 5 Scores vor Auto, verliert jedoch Tau-bench Banking mit 52.6% gegenüber 53.1%. Die Unterschiede liegen bei 2 bis rund 5 Punkten – das ist kein Leistungssprung um eine Generation.
2. Bei 4 von 5 Aufgaben ist Auto Code teurer als Auto – auf TerminalBench bis zu 3.7x ($4.96 gegenüber $1.33). Gegenüber dem vorherigen Auto Router ist Auto Code in jedem Benchmark ebenfalls teurer, etwa 8.1x bei TerminalBench.
3. „Günstiger“ gilt nur gegenüber Opus 5.5 pro gelöster Aufgabe. In den Kosten pro Aufgabe stecken Wiederholungsversuche: Ein günstigeres Modell mit zwei Fehlversuchen kann pro gelöster Aufgabe mehr kosten als ein teureres Modell, das beim ersten Anlauf besteht. Für Agenten ist das die richtige Kennzahl, aber deine Token-Rechnung sinkt dadurch nicht automatisch um 74%.

Die Skepsis in der Community richtet sich vor allem gegen die Nachprüfbarkeit, nicht gegen die grundsätzliche Richtung:

„Sagt es klar: Die 74%-Zahl stammt aus den eigenen 5 Benchmarks von OpenRouter, nicht aus unabhängiger Überprüfung. Vertraue der Richtung, nicht den Ziffern.“ — @LJL06019

Ein anderer Nutzer formulierte die Frage, die darüber entscheidet, ob sich das Ergebnis reproduzieren lässt: „the 74% only holds if my prompt tells the router what is hard. What tells the router what is hard?“ (@harden_369741).

Die sachgerechte Einordnung lautet daher: Auto Code erreicht auf diesen fünf code-lastigen Benchmarks ungefähr Opus-5.5-Niveau, aber zu niedrigeren Kosten pro gelöster Aufgabe. Wenn der maximale Score nicht entscheidend ist, bleibt Auto der günstigere Router. Bevor du damit budgetierst, solltest du die Ergebnisse auf deinen eigenen Repositories nachstellen.

Was die Router technisch voneinander trennt

Die Engine ist dieselbe, die Routing-Strategie nicht. Beide Router bewerten pro Anfrage 11 Faktoren: Aufgabentyp, Schwierigkeit, Relevanz der Geschwindigkeit, Bedarf an Vision oder Codebase-Wissen sowie die Frage, ob ein größeres Modell oder mehr Reasoning helfen würde. Kombiniert wird das mit aktuellen Preisen, Provider-Zustand, Prompt-Cache-Status, Benchmark-Daten und dem Session-Verlauf (OpenRouter-Ankündigung).

Bei Auto Code kommen drei coding-spezifische Gewichtungen hinzu (OpenRouter-Ankündigung und Auto-Code-Seite):

• Statt Autos kosteneffizienter medium-Klasse beginnt der Router mit einer stärkeren und teureren Coding-Modellklasse.
• Latenz wird stärker gewichtet, während fehlgeschlagene Codeänderungen härter bestraft werden.
• Wenn Änderungen Tests nicht bestehen oder derselbe Fehler erneut auftritt, wechselt der Router schneller das Modell.

Entscheidend ist die Eskalationsreihenfolge: Stockt eine Session, erhöht Auto Code zunächst den Reasoning-Aufwand und wechselt erst danach das Modell. Laut OpenRouter blieb der Router in der Beta bei fast 9 von 10 Agent-Turns auf demselben Modell. Ungültige Tool-Calls waren gegenüber dem alten Router 4x seltener, abgeschnittene agentische Antworten halbierten sich (OpenRouter-Ankündigung). Die Routing-Latenz bei p90 sank von 1.96s auf 0.65s, also ungefähr um den Faktor 3 (OpenRouter-Ankündigung).

Der allgemeine Routing-Pfad von Auto ist älter und separat dokumentiert: Ein leichtgewichtiger Klassifikator ordnet rund 30 feingranulare Aufgabentypen zu, etwa code:debugging oder agent:multi_step_planning. Anschließend werden Modelle anhand ihres Community-Ausgabenanteils der vergangenen 7 Tage je Aufgabe eingestuft, deine Kostenklasse und Einschränkungen angewandt und ein primäres Modell samt Fallbacks gewählt (Auto-Router-Dokumentation). Die neue Generation behält dieses Marktsignal bei, ergänzt es aber um die Session-Ebene.

Aktuelle Routing-Mixe zeigen, was die „stärkere Klasse“ in der Praxis bedeutet. In einem Snapshot vom 6. November lagen bei Auto Code in den vorangegangenen 24 Stunden und 992 Anfragen GPT-6.1 Sol bei 70.4%, Claude Opus 5.5 bei 14.8% und GLM 5.3 bei 11.0% (Auto-Code-Seite). Der allgemeine Mix von Auto ist günstiger ausgerichtet: Varianten von DeepSeek V4 Flash machten auf der Übersichtsseite allein etwa 47% des angezeigten Volumens aus (Auto-Übersicht). Diese Mischungen können sich durch Preisänderungen und neue Releases innerhalb weniger Tage drehen – sie sind eher Wetterbericht als feste Aufstellung.

Die versteckten Wechselkosten: Cache-Neuaufbau und Provider-Stickiness

Genau dieser Punkt fehlt in vielen Launch-Artikeln, entscheidet aber über die tatsächliche Rechnung. Ein Modellwechsel mitten in der Session verwirft den Prompt-Cache: Das neue Modell muss den Kontext wieder zum vollen Input-Preis einlesen. OpenRouter bestätigt diesen Mechanismus. Um Neuaufbauten zu reduzieren, hält der Router mehrturnige Konversationen auf demselben Modell, bis dieses keine führende Wahl mehr ist (OpenRouter-Ankündigung).

Nutzer berichten von diesem Problem in beide Richtungen:

„people keep trying to build routers at request level which is not going to work … a prompt without surrounding context is simply not enough signal to judge complexity … we can't frequently change the model during a session in an economic way. one or two missteps … spending more cost than simply using the best model all along“ — @kunchenguid

Die Zahl hinter dieser Kritik stammt vom Autor von OpenCode: Durch die Behebung des OpenRouter-Cachings fiel eine Testrechnung von $50 auf $6 (@thdxr). Auf Reddit berichtete ein Nutzer beim Test von openrouter/auto: „It's cache hit rate when we tested it was basically 0“ (u/tankerkiller125real). Ein anderer stellte fest: „every time Auto flipped the id the next call came back with cache_discount 0 while the pinned run kept reading“ (u/Michael_Jeffords). Der meistgewählte Rat im VS-Code-Thread ist entsprechend direkt: „Keep model and provider fixed for better results as cache would save cost else u would be sending large context to random providers“ (u/Zealousideal-Part849).

Daraus folgen zwei praktische Konsequenzen:

1. Die Cache-Hit-Rate bestimmt die Rechnung, nicht der Listenpreis. Nach einer Schätzung eines Nutzers stammen inzwischen rund 87% der Agent-Tokens aus dem Cache (@shu8ham_). Ein Router, der die Stickiness bricht, kann damit teurer werden als ein kostspieligeres gepinntes Modell, das Kontext wiederverwendet. Bei diesem Nutzer reichte es, einen Zeitstempel im System-Prompt vom Anfang ans Ende zu verschieben, um einen bei jedem Call brechenden Cache zu beheben (@shu8ham_).
2. Stickiness kann dich auch an einen schlechten Host binden. Folgeanfragen bleiben beim selben Provider, solange dessen Cache warm ist. Ein schwacher quantisierter Endpoint kann dadurch eine ganze Session beeinträchtigen: „Same model name is not the same model. Pin what serves it“ (@webtkdev). Schwankt die Qualität nach einem Wechsel, solltest du nicht nur das Modell, sondern auch den Provider protokollieren.

Der Ansatz von Auto Code – erst das Reasoning erhöhen, bei eindeutigen Fehlern erst dann schnell wechseln – ist grundsätzlich sinnvoll (Auto-Code-Seite). Solange dein eigener cache_discount-Stream jedoch nicht über eine Session hinweg von null verschieden bleibt, solltest du Wechsel als budgetiertes Risiko behandeln, nicht als kostenlose Optimierung.

So begrenzt du die Kosten wirklich

cost_tier ist ein Kostenband, keine Preisobergrenze. Die fünf Stufen low, medium, high, xhigh und max wählen jeweils ein Kostenband geeigneter Modelle. Modelle oberhalb und unterhalb des Bands können ausgeschlossen werden. Ohne gesetzte Stufe verhält sich der klassische Dokumentationspfad ungefähr wie low (Auto-Router-Dokumentation). Die Reddit-Zusammenfassung trifft es: „cost_tier is a band, not a ceiling … pin an exact model whenever the bill has to be deterministic“ (u/conifer_v11).

Für beide Router funktioniert dieses Setup:

• Starte Auto Code für ein Test-Set von Repositories mit dem Standardwert. Wenn dir das frühere günstige Verhalten gefiel, beginne bei Auto mit low. OpenRouter hat die neue Standardpreiswahl auf ein Niveau näher an „vor einigen Monaten“ angehoben, damit leistungsfähigere Modelle zugelassen werden (OpenRouter-Ankündigung).
• Begrenze den Pool mit Wildcards in allowed_models / excluded_models, beispielsweise anthropic/*. Ausschlüsse haben Vorrang vor Allowlists; bleibt der Pool leer, schlägt die Anfrage geschlossen mit 404 fehl (Auto-Router-Dokumentation). Achte auf die Plugin-ID-Falle: openrouter/auto nutzt Einstellungen für auto-router, während openrouter/auto-beta Einstellungen für auto-beta-router liest. Überkreuz eingereichte Einstellungen werden stillschweigend ignoriert (Auto-Router-Dokumentation).
• Kombiniere provider.max_price mit Ausgabenlimits im Workspace, wenn du eine harte Obergrenze brauchst. Die Tier-Stufe allein kann das nicht leisten (Auto-Router-Dokumentation).
• Übergib für mehrturnige Arbeit eine explizite session_id, damit sich die Stickiness an deiner Konversation orientiert und nicht an einem Nachrichten-Fingerprint (Auto-Router-Dokumentation).
• Pro Anfrage solltest du model, Provider, Tokens, Preis-Snapshot und cache_discount protokollieren. Nur mit diesem Log kannst du Kosten pro akzeptierter Aufgabe berechnen – genau die Kennzahl, auf die Auto Code optimiert und die für dein Budget zählt.

Weiterführende Beiträge auf dieser Website: der Leitfaden zur Auto-Router-Einrichtung, der OpenRouter-Preisleitfaden, der Leitfaden zum Prompt-Caching sowie LiteLLM vs OpenRouter zu selbst gehosteten Routing-Alternativen.

In einer Zeile aufrufen – und das tatsächlich verwendete Modell prüfen

Beide Router funktionieren überall dort, wo ein Modell-String akzeptiert wird (Auto-Übersicht):

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto-code",
    "messages": [{"role": "user", "content": "Add a retry with backoff to fetchUser in api/users.ts"}]
  }'

Für allgemeinen Traffic ersetzt du den Modellnamen durch openrouter/auto. Das Feld model in der Antwort nennt das Modell, das tatsächlich geantwortet hat – erfasse es immer (Auto-Router-Dokumentation). Mit X-OpenRouter-Metadata: enabled erhältst du die Aufgabenklassifizierung (Auto-Router-Dokumentation). Alternativ zeigt das Routing-Insights-Panel des Chatrooms, warum ein Modell ausgewählt wurde: Aufgabentyp, Schwierigkeitsbewertung und Kandidatenanteil (OpenRouter-Ankündigung). Beide Router unterstützen Tool-Calls, Streaming, Bilder, PDFs sowie Audio- und Video-Input bei Text-/Bild-Output. Das Routing-Limit liegt bei bis zu 2,000,000 Tokens; das tatsächliche Kontextfenster hängt vom jeweils gewählten Modell ab (Auto-Übersicht und Auto-Code-Seite).

Ein Hinweis für IDEs: Codex CLI, Cline, Kilo Code, OpenCode, Continue und Copilot-ähnliche VS-Code-Setups können zusätzlich zu deinem Prompt eigene Sub-Calls, Wiederholungen und große Kontexte erzeugen. Ein Nutzer verglich etwa 20 Tokens über direktes Python mit 20k–40k Tokens über eine Plugin-Anfrage (r/openrouter-Routing-Thread). Wenn eine scheinbar kleine Anfrage teuer wird, prüfe zuerst, ob die Tokens vom Router oder vom Harness stammen. Hinter beiden Routern umfasst der OpenRouter-Katalog mehr als 600 Modelle (OpenRouter-Ankündigung).

FAQ: OpenRouter Auto vs. Auto Code

Ist Auto Code teurer als Auto Router?

Meistens ja, gemessen an den Kosten pro Aufgabe. In OpenRouters eigener Tabelle kostet Auto Code bei vier von fünf Benchmarks mehr als Auto und liegt beim fünften gleichauf. „Günstiger“ ist Auto Code nur gegenüber einem festen Frontier-Modell pro gelöster Aufgabe.

Fällt für den Router eine zusätzliche Gebühr an?

Nein. Sowohl openrouter/auto als auch openrouter/auto-code rechnen zum regulären Preis des ausgewählten Modells ab; es gibt keinen Router-Aufschlag (Auto-Übersicht).

Zerstört ein Modellwechsel das Prompt-Caching?

Ja, das kann passieren. Ein neues Modell oder ein neuer Provider muss den Cache neu aufbauen. Nutzer haben dokumentiert, dass cache_discount unmittelbar nach einem Wechsel auf 0 fällt. Auto Code versucht zunächst, den Reasoning-Aufwand zu erhöhen, und blieb in der Beta bei etwa 9 von 10 Turns sticky (OpenRouter-Ankündigung). Überprüfen solltest du das trotzdem in deinen eigenen Sessions.

Welche Modelle dürfen die Router wählen, und lassen sich Modelle ausschließen?

Grundsätzlich jedes Modell im Katalog, nachdem Guardrails, Zero-Data-Retention-, Provider-, Allowlist- und Excludelist-Filter angewandt wurden (Auto-Code-Seite). Wildcards wie anthropic/* funktionieren; Ausschlüsse haben Vorrang (Auto-Router-Dokumentation).

Wann sollte ich lieber ein festes Modell pinnen als einen Router zu verwenden?

Wenn die Rechnung planbar sein muss, Audit- oder Residency-Anforderungen ein bekanntes Modell verlangen oder dein gepinntes Modell auf deinen Repositories bereits besser ist als die durchschnittliche Router-Auswahl. Ein sinnvoller Ablauf ist: mit Auto entdecken, anschließend den Gewinner pinnen oder auf eine Whitelist setzen.

Der Zielkonflikt lässt sich nicht wegprompten: Auto Code kauft einige zusätzliche Punkte bei der Erfolgsquote durch eine höhere Modellklasse und Session-Bewusstsein. Jeder Wechsel kostet jedoch Cache. Bei langen Sessions mit viel Kontext ist der günstigste Router derjenige, der am seltensten wechseln muss.