Multi-Modell-Routing für Coding-Agents: Kosten erklärt

Was Multi-Modell-Routing für einen Coding-Agent bewirkt

Multi-Modell-Routing sendet jede Anfrage an das günstigste Modell, das sie verarbeiten kann. Bei Chat-Verkehr funktioniert das gut. Bei einem Coding-Agent verursacht es meistens höhere Kosten als Einsparungen, weil die Abrechnung eines Agents vom Prompt-Präfix dominiert wird, das pro Modell zwischengespeichert wird. Beim Wechsel des Modells wird dieser Cache verworfen.

Für diesen Beitrag gilt daher folgende Regel: Routen Sie aus Gründen der Verfügbarkeit zwischen Providern. Wechseln Sie aus Kostengründen nur an Aufgabengrenzen zwischen Modellklassen. Für alles Agentische sollte ein Modell pro Sitzung festgelegt werden. Im Folgenden wird diese Begründung erläutert.

Vier Begriffe, jeweils einmal definiert. Ein Router wählt für jede Anfrage ein Modell aus. Ein Gateway ist der Proxy, den die Anfrage durchläuft. Es kann zusätzlich routen, muss dies aber nicht. Ein Prompt-Cache ist ein vom Provider gespeicherter, verarbeiteter Präfix Ihres Prompts. Bei einer späteren Anfrage, die diesen Präfix wiederholt, wird nur ein Bruchteil des Input-Preises berechnet. Ein KV-Cache (Key-Value-Cache) funktioniert nach demselben Prinzip innerhalb eines Servers, den Sie selbst betreiben.

Warum Chat-Verkehr gut geroutet wird und Agentenverkehr nicht

Eine Chat-Anfrage besteht aus einem Durchlauf. Sie trifft ein, wird klassifiziert, an ein Modell weitergeleitet und beantwortet. Nichts davon wird in den nächsten Durchlauf übernommen. Ein Router kann diese Frage an ein kleines Modell und die nächste an ein großes Modell senden. Keine der beiden Anfragen weiß, dass die andere stattgefunden hat. Das ist die Arbeitslast, die fast jeder Routing-Benchmark misst. Gute Router sind darin tatsächlich gut.

Ein Agentendurchlauf besteht nicht aus einer einzelnen Anfrage. Aus einer Anweisung wie „den fehlschlagenden Test reparieren“ werden zwanzig bis sechzig API-Aufrufe. Bei jedem Aufruf wird die gesamte Konversation erneut gesendet: der System-Prompt, jede Tool-Definition, jede vom Agenten gelesene Datei und jede von ihm gesehene Befehlsausgabe. Der Kontext wächst fortlaufend. Beim dreißigsten Aufruf kann das wiederholte Präfix mehrere zehntausend Tokens umfassen, während der tatsächlich neue Inhalt jedes Aufrufs nur wenige hundert Tokens beträgt.

Diese Struktur verändert die Bedeutung des Wortes „teuer“. Beim Chat entsprechen die Kosten ungefähr dem Preis des Modells multipliziert mit der Anfrage. In einer Agentenschleife wird das Präfix bei jedem einzelnen Aufruf erneut abgerechnet. Der restliche Beitrag folgt aus dieser einen Tatsache.

Der Prompt-Cache gilt pro Modell, und der Agent befindet sich innerhalb dieses Caches

Anthropic berechnet einen Cache-Read mit dem Faktor 0.1 des regulären Input-Preises und einen Cache-Write für fünf Minuten mit dem Faktor 1.25. Dies sind die veröffentlichten Listenpreise mit Stand August 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Vergleichen Sie die zweite Reihe zeilenweise mit der ersten, nicht spaltenweise. Ein Cache-Read bei Opus 5 kostet 0.50 Dollar pro Million Tokens. Nicht gecachter Input bei Haiku 4.5, dem günstigsten aufgeführten Modell, kostet 1.00 Dollar. Das erneute Lesen eines warmen Präfixes beim teuersten Modell kostet pro Input-Token also weniger als das erstmalige Lesen desselben Präfixes beim günstigsten Modell.

Dieser einzelne Vergleich widerlegt die meisten Routing-Pläne. Ein Router, der Arbeit in eine niedrigere Stufe verschiebt, vergleicht Listenpreise. Ein Agent während einer Sitzung zahlt für das bereits verwendete Modell jedoch nicht den Listenpreis. Er zahlt den Cache-Read-Preis, der bereits unter dem nicht gecachten Preis des günstigen Modells liegt.

Caches werden anhand eines Hashes des Prompt-Präfixes adressiert und gelten pro Modell. Eine Anfrage an ein anderes Modell wird gegen einen Store gehasht, der dieses Präfix noch nie gesehen hat. Daher wird nichts gefunden und der vollständige Preis berechnet. Der Cache ist außerdem hierarchisch aufgebaut: zuerst Tools, dann das System, anschließend die Nachrichten. Eine Änderung auf einer Ebene invalidiert diese Ebene und alles Folgende. Wenn Sie eine Tool-Definition bearbeiten, wird dadurch auch der dahinterliegende System-Prompt-Cache verworfen. Agents, die Tools zur Laufzeit registrieren, sind davon betroffen, ohne dass sie überhaupt einen Router verwenden.

Was ein einmaliger Wechsel während der Sitzung tatsächlich kostet

Nehmen wir eine Sitzung mit einem stabilen Präfix von 40,000 Token. Das ist eine übliche Größe, sobald ein Agent einige Dateien gelesen hat. Im Folgenden werden die Präfixkosten eines einzelnen Turns anhand der oben genannten Listenpreise berechnet.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Wenn Sie bei Opus 5 bleiben und der Cache warm ist, kostet das Präfix für diesen Turn 0.020 Dollar. Der erste Turn nach dem Wechsel zu Sonnet 5 kostet 0.100 Dollar, weil Sonnet keinen Eintrag für dieses Präfix enthält und zunächst einen anlegen muss. Der Wechsel zurück zu Opus 5 kostet 0.250 Dollar, weil der ursprüngliche Eintrag während der Abwesenheit der Sitzung abgelaufen ist.

Der Hin- und Rückwechsel verursacht somit zwei Cache-Schreibvorgänge, um zwei Cache-Lesevorgänge zu vermeiden. Dem steht gegenüber, dass ein Turn die Ausgabe zu Sonnet-Preisen statt zu Opus-Preisen erzeugt. Der Detailbereich rechnet den gesamten Ablauf durch: Die Einsparung beträgt Bruchteile eines Cents, während die Cache-Kosten mehrere Zehntel eines Dollars betragen. Die zusätzlichen Kosten sind mehr als eine Größenordnung höher. Sie steigen mit der Präfixlänge, während die Einsparung nicht steigt.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Tool-Call-Formate sind bei verschiedenen Providern nicht identisch

Ein Agent arbeitet in einer Tool-Calling-Schleife. Deshalb ist das Format eines Tool-Aufrufs hier relevant, anders als bei einem Chat. Die Anthropic Messages API gibt einen tool_use-Content-Block zurück und erwartet als Antwort einen tool_result-Block. OpenAI-kompatible APIs geben ein tool_calls-Array zurück, in dem function.arguments ein JSON-kodierter String statt eines verschachtelten Objekts ist. Ein Gateway übersetzt zwischen beiden Formaten. Bei gewöhnlichen Aufrufen funktioniert diese Übersetzung problemlos.

Probleme treten an den Randfällen auf. Parallele Tool-Aufrufe, bei denen ein Modell mehrere Aufrufe in einer Antwort ausgibt, werden unterschiedlich dargestellt und nicht überall gleich unterstützt. Die strikte Schema-Prüfung ist eine Funktion des jeweiligen Providers. Ein Modell, das an einem Endpunkt garantiert schema-konforme Argumente erzeugt, liefert an einem anderen Endpunkt daher nur tendenziell gültige Argumente. Der Agent sieht den Unterschied als Tool-Ergebnis mit einem Parse-Fehler. Anschließend versucht er, den Fehler in einem weiteren Turn zu beheben. Diese Reparatur-Turns werden zum vollen Prefix-Preis abgerechnet. Eine Formatabweichung erscheint daher sowohl in der Abrechnung als auch im Transcript.

Bei selbst gehosteten Endpunkten muss dies explizit konfiguriert werden. Der OpenAI-kompatible Server von vLLM benötigt --enable-auto-tool-choice zusammen mit einem --tool-call-parser, das zur Modellfamilie passt (hermes, mistral, llama3_json und weitere). Zusätzlich ist ein Chat-Template erforderlich, das Nachrichten mit der Rolle tool verarbeitet. Die vLLM-Dokumentation beschreibt die Grenzen dieses Pfads eindeutig: Mit tool_choice="auto" und ohne strikte Schema-Vorgabe extrahiert vLLM Tool-Aufrufe aus Rohtext. Dadurch können Argumente gelegentlich fehlerhaft sein oder gegen das Parameterschema der Funktion verstoßen. Wenn der Parser nicht zum Modell passt, ist das ein Konfigurationsfehler. Er zeigt sich als Agent, der keine Tools aufrufen kann. Das sollten Sie wissen, bevor Sie Netzwerkverkehr an diesen Endpunkt weiterleiten. Der Unterschied zwischen Ollama und vLLM beim eigenen Bereitstellen von Modellen ist hier relevant, weil beide Tool Calling unter unterschiedlichen Bedingungen bereitstellen.

Ein Fallback während einer Aufgabe ändert das Verhalten ohne Fehlermeldung

Fallback-Routing wird am häufigsten versehentlich aktiviert. Ein Gateway wird so konfiguriert, dass es auf ein anderes Modell wechselt, wenn das erste eine Rate-Limit- oder 5xx-Antwort liefert, und das ausgefallene Modell anschließend für einige Sekunden in eine Abkühlphase versetzt. Bei Chat-Verkehr ist das genau richtig. Innerhalb einer längeren Agent-Aufgabe bedeutet es, dass die zweite Hälfte Ihrer Aufgabe auf einem Modell ausgeführt wurde, das Sie nicht ausgewählt haben.

Nichts weist darauf hin. Die Aufgabe schlägt nicht fehl, der Agent gibt keine Warnung aus und der Exit-Status ist erfolgreich. Das Ergebnis ist eine Aufgabe, bei der ein Modell den Plan erstellt und ein anderes die Änderungen vorgenommen hat. Ton und Arbeitsweise ändern sich dabei in der Mitte der Aufgabe. Das einzige verlässliche Signal ist das Feld model im Request-Log des Gateways oder in den Antwortmetadaten. Wenn Sie überhaupt Fallbacks verwenden, protokollieren Sie dieses Feld für jede Anfrage und prüfen Sie es, wenn Sie von einem Ergebnis überrascht sind. Das Verhalten zu untersuchen, ohne zu wissen, welches Modell es erzeugt hat, kostet mehr Zeit, als der Fallback eingespart hat.

Dieselbe Falle betrifft die Kontextkomprimierung. Viele Agents fassen einen langen Verlauf zusammen, indem sie ein kleines Modell aufrufen. Wenn dieser Aufruf ein anderes Modell oder einen anderen System-Prompt verwendet, schreibt er seinen eigenen Cache-Eintrag und aktualisiert den Cache der Hauptsitzung nicht. Der nächste vollständige Durchlauf muss dann erneut ein kaltes Präfix verarbeiten. Die Komprimierung hat Tokens eingespart und den Cache verworfen.

Routing-Overhead ist real, aber die Latenz verursacht nicht die eigentlichen Kosten

Router verursachen pro Anfrage zusätzlichen Aufwand. Es lohnt sich, dessen Größenordnung korrekt einzuordnen. DigitalOcean gibt an, dass das eigene Modell Arch-Router die Routing-Absicht in etwa 51 Millisekunden ermittelt und bei der eigenen Evaluierung eine Routing-Genauigkeit von 93.17% erreicht. Das sind die Werte von DigitalOcean, aus deren Messung und Benchmark. Sie stammen nicht von uns und sind kein allgemeingültiges Ergebnis. Nimmt man diese Werte unverändert an, ist das Ergebnis beruhigend: 51 Millisekunden bei vierzig Agent-Aufrufen entsprechen etwa zwei zusätzlichen Sekunden bei einer Aufgabe, die mehrere Minuten dauert.

Zwei Sekunden machen das Routing hier nicht teuer. Relevant ist ein Router, der die Klassifizierung mit einem vollständigen Modellaufruf durchführt. Das ist bei jeder Anfrage eine zweite Inferenz, die wie jede andere Inferenz abgerechnet und in die Warteschlange eingereiht wird. Darunter liegt die oben beschriebene Cache-Arithmetik. Sie ist überhaupt kein Overhead. Sie ist der Preis für das, was das Routing eigentlich optimieren sollte.

Auf einem selbst betriebenen Server gilt dieselbe Regel, allerdings mit weniger Spielraum. Das lokale Gegenstück zum Prompt-Cache ist Prefix-Caching im KV-Cache, der im GPU-Speicher liegt. Wenn Sie zwei Modelle auf einer GPU hosten, wird dieser Speicher zwischen beiden aufgeteilt. Dadurch behält jedes Modell einen kleineren KV-Cache, und Präfixe werden früher verdrängt. Das Routing zwischen zwei lokalen Modellen kann daher die Cache-Trefferrate beider Modelle gleichzeitig senken. Wenn Sie die Hardware dafür dimensionieren, ist der Speicher- und CPU-Bedarf eines Coding-Agenten auf einem VPS ein sinnvollerer Ausgangspunkt als ein Router.

Die Entscheidungsregel

• Für Verfügbarkeit über Provider hinweg routen. Wenn die Alternative eine fehlgeschlagene Anfrage ist, sind alle Kosten vertretbar. Legen Sie den Fallback auf ein Modell mit demselben Format für Tool-Aufrufe fest, damit die Schleife des Agents weiter funktioniert. Protokollieren Sie, welches Modell den jeweiligen Aufruf verarbeitet hat.
• Für Kosten nur an Aufgabengrenzen zwischen Tiers routen. Haiku für eine Umbenennung und Opus für ein Refactoring auszuwählen, ist eine gute Entscheidung, wenn sie einmal vor dem Start der Sitzung getroffen wird. In der dreißigsten Runde dieser Sitzung ist es eine schlechte Entscheidung.
• Für agentische Aufgaben pro Sitzung ein Modell festlegen. Der Wert einer Sitzung liegt in ihrem Warm Cache. Behandeln Sie einen Modellwechsel so, wie Sie das Leeren dieses Caches behandeln würden. Genau das geschieht dabei.
• Subagents frei routen. Ein Subagent, der mit einem neuen, kleinen Kontext startet, hat keinen Warm Cache, den er verlieren kann. Daher kann er mit dem für seine Aufgabe geeigneten Modell ausgeführt werden. Innerhalb eines Agents ist Routing an dieser Stelle nahezu kostenlos.

Die Umsetzung übernimmt das Gateway: mit Modellaliasen und expliziten Fallback-Listen. Eine minimale LiteLLM-Proxy-Konfiguration sieht so aus.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Verweisen Sie den Agent auf agent-primary. Er bleibt bei einem Modell, bis dieses Modell nicht erreichbar ist. Beide Einträge verwenden denselben Provider. Daher ändert sich das Format für Tool-Aufrufe nicht, wenn der Fallback ausgelöst wird. Sie akzeptieren in diesem Moment trotzdem einen Wechsel des Tiers. Dieser Kompromiss lohnt sich nur, weil die Alternative eine fehlgeschlagene Anfrage wäre. Das ist Availability-Routing ohne zusätzliches Cost-Routing. Diese Kombination ist für die meisten Coding-Agents die passende Lösung. Der vollständige Aufbau einschließlich Schlüsseln und Budgets wird unter ein selbst gehostetes LiteLLM-Gateway auf dem eigenen VPS betreiben beschrieben. Dieser Beitrag wiederholt ihn bewusst nicht.

Wenn ein gut ausgewähltes Modell jeden Router übertrifft

Routing ist eine Lösung für Schwankungen beim Schwierigkeitsgrad von Anfragen. Bei einem Coding-Agent ist diese Schwankung geringer, als es zunächst scheint, weil der kostenintensive Teil jedes Aufrufs aus demselben Präfix besteht, unabhängig von der Anfrage. Sobald das Präfix den größten Anteil ausmacht, schrumpft der Unterschied zwischen Ihrer günstigen und Ihrer teuren Stufe auf den Unterschied bei den Output-Preisen. Output macht bei den Tokens eines Agents jedoch nur einen kleinen Anteil aus.

Die sinnvolle Standardeinstellung ist daher ein einmalig ausgewähltes Modell mit aktiviertem Caching und einer ausreichend langen TTL (time to live), die auch die Pausen abdeckt, in denen Sie einen Diff prüfen. Anthropic bietet einen einstündigen Cache-Write zum 2-fachen Preis für Base-Input. Das amortisiert sich nach zwei Lesevorgängen. Dieser Hebel ist häufig sinnvoller als jeder Router. Wählen Sie die Stufe bewusst anhand eines direkten Vergleichs von Opus, Sonnet und Haiku aus. Wenn die Rechnung weiterhin das Problem ist, senken Sie sie mit Budgets und kleineren Kontexten, wie unter AI-Agent-Kosten auf einem VPS kontrollieren beschrieben, statt während einer Sitzung das Modell zu wechseln.

Routen Sie Anfragen, wenn sie unabhängig und kurz sind oder wenn Subagents mit neuen Kontexten starten. Verwenden Sie ein festgelegtes Modell, wenn eine lange Sitzung eine einzelne Aufgabe bearbeitet. Die meiste Arbeit mit Coding-Agents gehört zur zweiten Kategorie. Deshalb verursacht der Router, der bei Ihrem Chat-Produkt Geld spart, hier unbemerkt zusätzliche Kosten. Wenn Sie sich noch nicht für den Agent selbst entschieden haben, erklärt der Vergleich von Claude Code mit Cursor, Codex und Copilot, wie die einzelnen Lösungen die Modellauswahl handhaben. Einige davon nehmen Ihnen diese Entscheidung ab.

FAQ

Geht der Prompt-Cache wirklich verloren, wenn ich das Modell während einer Sitzung wechsle?

Ja. Prompt-Caches werden anhand eines Hashes des Prompt-Präfixes adressiert und pro Modell gespeichert. Eine Anfrage an ein anderes Modell wird daher gegen einen Speicher gehasht, der dieses Präfix noch nie gesehen hat. Sie findet keinen Eintrag und bezahlt den vollständigen Preis für nicht gecachten Input. Wenn das Caching aktiviert ist, kommt zusätzlich der Preis für das Schreiben in den Cache hinzu. Auch ein Wechsel zurück stellt den ursprünglichen Eintrag nicht wieder her, weil die standardmäßige Lebensdauer von fünf Minuten bis dahin normalerweise abgelaufen ist. Prüfen Sie die Felder cache_read_input_tokens und cache_creation_input_tokens im Response-Usage-Objekt. Bei einer langen Sitzung ist ein Durchlauf mit null gelesenen gecachten Tokens das typische Anzeichen.

Ist das Routing an ein günstigeres Modell für einen Agenten jemals günstiger?

Nur wenn kein warmer Cache verloren gehen kann. Ein Cache-Lesevorgang bei Anthropic kostet 0.1-mal den regulären Input-Preis. Damit liegt ein warmer Lesevorgang bei Opus 5 unter dem Preis für nicht gecachten Input bei Haiku 4.5. Sobald eine Sitzung ein großes gecachtes Präfix hat, ist das bisher verwendete Modell beim Input bereits die günstigere Option. Routing lohnt sich bei einem frischen und kleinen Kontext: am Anfang einer Aufgabe oder bei einem Subagenten, der nur den benötigten Kontext mitführt.

Warum hat sich mein Agent mitten in einer Aufgabe anders verhalten?

Prüfen Sie, ob ein Gateway-Fallback ausgelöst wurde. Ein Rate Limit oder ein 5xx-Fehler beim primären Modell veranlasst das Gateway, die Anfrage mit dem Standby-Modell zu wiederholen und das primäre Modell für einige Sekunden in den Cooldown zu versetzen. Der restliche Teil der Aufgabe läuft dann auf einem anderen Modell. Dabei wird kein Fehler und keine Warnung ausgegeben. Die Aufgabe meldet weiterhin Erfolg. Das Feld model im Gateway-Anforderungslog oder in den Response-Metadaten ist der einzige zuverlässige Nachweis. Protokollieren Sie es daher für jede Anfrage, wenn Sie überhaupt Fallbacks verwenden.

Funktionieren Tool-Aufrufe bei allen Providern gleich?

Nicht genau. Anthropic's Messages API verwendet die Content-Blöcke tool_use und tool_result. OpenAI-kompatible APIs verwenden dagegen ein tool_calls-Array, dessen function.arguments ein JSON-kodierter String ist. Ein Gateway übersetzt die üblichen Fälle zuverlässig. Parallele Tool-Aufrufe und die strikte Durchsetzung von Schemas unterscheiden sich jedoch je nach Provider. Bei selbst gehostetem vLLM müssen Sie --enable-auto-tool-choice und ein --tool-call-parser setzen, das zu Ihrer Modellfamilie passt. Die vLLM-Dokumentation weist außerdem darauf hin, dass der Server Tool-Aufrufe ohne eine strikte Schemaeinschränkung aus dem Rohtext extrahiert. Dadurch können Argumente gelegentlich fehlerhaft formatiert sein.

Wie lange sollte ich die Cache-TTL für eine Coding-Sitzung festlegen?

Verwenden Sie bei kontinuierlicher Arbeit die standardmäßige Lebensdauer von fünf Minuten. Wählen Sie die Option für eine Stunde, wenn eine Person zwischen den Durchläufen Diffs liest. Anthropic berechnet für das Schreiben mit fünf Minuten das 1.25-Fache des regulären Input-Preises und für das Schreiben mit einer Stunde das 2-Fache. Das Lesen kostet 0.1-mal den regulären Preis. Das Schreiben mit fünf Minuten amortisiert sich durch einen einzigen Lesevorgang. Das Schreiben mit einer Stunde amortisiert sich durch zwei Lesevorgänge. In jeder Sitzung, in der Sie später zurückkehren und weiterarbeiten möchten, ist die längere Lebensdauer daher normalerweise günstiger, als den kalten Präfix erneut zu bezahlen.