Long-Context-Preise: bis zu 6,7x, im Gateway unsichtbar

Sobald ein Prompt lang wird, stimmt der Preis auf der Modellseite eines Gateways nicht mehr mit der Rechnung überein. Wir haben über einen großen Multi-Provider-Aggregator Requests knapp unterhalb und oberhalb jeder dokumentierten Längengrenze für neun Modelle mit Preisstufen gesendet. Fünf Modelle kosteten nach der ersten Grenze genau das Doppelte des Seitenpreises. Die drei Modelle von Alibaba stiegen in ihren höchsten Stufen auf das 3-Fache, 3-Fache und 6,7-Fache. Ein über Azure bereitgestelltes Modell wurde auf beiden Seiten seiner Grenze mit dem 1,25-Fachen des gelisteten Endpoint-Preises abgerechnet und verdoppelte sich anschließend. Nichts davon steht auf der Modellseite. Die Anbieter selbst dokumentieren den Mechanismus: Google, OpenAI, xAI, Alibaba, ByteDance und MiniMax setzen den Preis für den gesamten Request neu fest, einschließlich Output, sobald der Input eine Grenze bei 32K, 128K, 200k, 256K, 272K oder 512k tokens überschreitet. Dieser Beitrag zeigt zuerst die Rechnungen, dann die zugrunde liegenden Preisstufen und schließlich die Einstellungen, mit denen ein Request unter der Grenze bleibt.

TL;DR

• Neun Modelle mit Preisstufen kosteten über die jeweilige Anbietergrenze hinweg das 1,8- bis 6,7-Fache. Der Aggregator zeigt auf den Modellseiten nur einen Preis. GPT-5.6 Luna über Azure kostete das 1,25-Fache des gelisteten Preises.
• qwen3.7-flash kostete zunächst $0.03, dann $0.10 und schließlich $0.20 pro Million Input-tokens, mit Grenzen bei 32K und 256K. qwen3-coder-plus endete beim 3-Fachen, obwohl der Anbieter das 6-Fache ausweist.
• Sobald der Input eine Grenze zwischen 32K und 512k tokens überschreitet, bepreisen die Anbieter den gesamten Request neu, einschließlich Output.
• Begrenze den Input, nicht den Output: Claude Code /autocompact, Codex model_context_window, Compaction-Trigger der API.

Berechnen Gateways den Preis ihrer Modellseite?

Nein, sobald der Prompt lang wird. Um die tatsächliche Höhe pro Vermittler zu ermitteln, braucht man zwei Datenpunkte: die vom Gateway veröffentlichten Preismetadaten und die Kosten, die es für einen Request auf beiden Seiten der Grenze tatsächlich meldet.

Ein großer Multi-Provider-Aggregator veröffentlicht seinen Katalog mit einem Array namens pricing.overrides. Darin stehen ein Basispreis und bedingte Regeln, etwa min_prompt_tokens: 200000 mit den höheren Preisen. Für Modelle von DeepSeek und Tencent gibt es außerdem Zeitfenster mit utc_start / utc_end für günstigere Nebenzeiten. In dem am 2026-09-01 abgerufenen Katalog hatten 60 Einträge solche Overrides, darunter die Gemini-Pro-Modelle, Grok 4.x, qwen3.7-plus, qwen3.7-flash, qwen3-coder-plus, die Seed-2.0-Modelle und die gesamte GPT-5.6-Familie bei 272,000. Die Modellseiten zeigen nur den Basispreis. Die Preisstufe steht ausschließlich in den Metadaten. Diese bilden jedoch nicht zwingend die vollständige Preisstaffel des Anbieters ab: Für qwen3-coder-plus gibt es Regeln bei 32,000 und 128,000, aber keine für die vierte Anbieter-Stufe bei 256K.

Deshalb haben wir am 2026-09-02 und 2026-09-03 Requests auf beiden Seiten jeder dokumentierten Grenze über diesen Aggregator gesendet, jeweils zweimal pro Messpunkt. Usage Accounting war aktiviert, sodass der Aggregator den berechneten Betrag in der Response zurückgab. Außerdem haben wir den bedienenden Endpoint protokolliert. Eine Modell-ID des Aggregators kann mehrere Upstream-Hosts mit jeweils eigenen Preisen ansprechen, die dort Endpoints heißen:

Die Seiten wurden am selben Tag wie die Rechnungen erfasst. Beide zeigen einen Hauptpreis und eine Tabelle pro Endpoint, aber keine längenabhängige Preisstufe. Jede berechnete Summe folgte den Metadaten token-genau. Alle neun Modelle wechselten an der ersten Grenze des Anbieters um dessen angegebenen Faktor. Bei den drei Alibaba-Modellen stieg die Rechnung über eine Preisstaffel, die auf der Seite nicht erwähnt wird: qwen3.7-flash verteuerte sich bei 32K von $0.03 auf $0.10 und bei 256K auf $0.20. Das entspricht dem 6,7-Fachen des Seitenpreises, obwohl dort weiterhin $0.03 steht. GPT-5.6 Luna wechselte ebenfalls die Stufe und zeigte noch eine zweite Abweichung: Jeder über Azure bediente Lauf wurde unterhalb wie oberhalb der Grenze mit dem 1,25-Fachen des gelisteten Azure-Endpoint-Preises abgerechnet ($0.275 statt $0.22 sowie $0.50 und $0.55 statt $0.40 und $0.44). Dieser Aufschlag steht weder auf der Seite noch in den Endpoint-Metadaten.

Die Staffel kann auch vor der des Anbieters enden. Bei qwen3-coder-plus stieg der Preis bei 32K auf das 1,8-Fache und bei 128K auf das 3-Fache. Danach blieb er bis 276k tokens bei $1.95 pro Million. Alibaba selbst erhöht bei 256K auf $6 für Input und $60 für Output, also auf das Sechs- beziehungsweise Zwölffache des Basispreises. In den Metadaten des Aggregators fehlt eine Regel bei 256K, deshalb änderte sich der berechnete Preis nicht. Von außen ist nicht erkennbar, ob der Aggregator die Differenz selbst trägt oder einen anderen Vertrag hat. Sichtbar ist nur: Die Rechnung folgt den Metadaten, während Metadaten und Modellseite zwei unterschiedliche Dokumente sind.

Die Transparenzlücke liegt also nicht zwischen Metadaten und Rechnung, sondern zwischen der Modellseite und beiden. Der hervorgehobene Preis auf der Seite ist der Preis des günstigsten Endpoints aus der darunterstehenden Tabelle, nicht der Preis des Endpoints, der den Request tatsächlich bedient. Keiner der beiden Preise nennt die Längenbedingung. Eine Modellkarte mit nur einem Preis verrät weder die Preisstufe noch den Endpoint des nächsten Requests. Sie zeigt auch nicht, ob der Endpoint mit dem angezeigten Preis für den eigenen Account überhaupt erreichbar ist.

Daraus ergibt sich eine einfache Regel. Lies die maschinenlesbaren Preisdaten des verwendeten Modells auf Endpoint-Ebene und suche dort nach Längenbedingungen. Sende anschließend mit aktiviertem Usage Accounting je einen Request unterhalb und oberhalb der Grenze und vergleiche die gemeldeten Kosten. Springt der berechnete Preis an einer Grenze, die auf der Gateway-Seite fehlt, reicht das Gateway eine Anbieterregel weiter, ohne sie auszuweisen. Bleibt der Preis konstant, obwohl er beim Anbieter steigt, nutzt das Gateway entweder einen Host mit anderen Preisen oder übernimmt die Differenz selbst. Nur die erste Variante ist dauerhaft belastbar.

Wo liegen die Grenzen, und wie wird eine Preisstufe angewendet?

Sechs Anbieter veröffentlichen Längengrenzen. Bei jedem Modell mit dokumentierter Regel gilt der höhere Preis für alle tokens des Requests, einschließlich Output. An den meisten ersten Grenzen verdoppelt sich der Preis, die Staffeln steigen jedoch weiter: qwen3.7-plus erreicht an seiner einzigen Grenze das 3-Fache, qwen3.7-flash in der dritten Input-Stufe das 6,7-Fache und qwen3-coder-plus in der vierten Stufe das 6-Fache für Input sowie das 12-Fache für Output. Die Preise gelten pro Million tokens und wurden am 2026-09-01 von den Preisseiten der Anbieter abgerufen.

Zwei Grenzdetails gehören direkt in den Billing-Code. Die beiden Seiten von Google unterscheiden sich um ein token: In der Vertex-Fußnote steht “longer than or equal to 200K”, in der Preistabelle der Gemini API dagegen “prompts > 200k tokens”. Alibaba definiert K außerdem exakt: 128K entspricht 128,000 tokens und 256K entspricht 256,000, nicht Zweierpotenzen.

Die Input-Länge entscheidet über die Preisstufe. Diese gilt dann für den gesamten Request, also für alle tokens einschließlich Output. Der Grenznutzen des tokens, das die Schwelle überschreitet, entspricht deshalb dem gesamten Aufpreis auf alle vorherigen tokens. Bei Gemini 2.5 Pro kostet ein Prompt mit 199,999 tokens $0.25 Input. Bei 200,001 tokens sind es $0.50. Eine Antwort mit 4,000 tokens verteuert sich zusätzlich von $0.04 auf $0.06. Ein token mehr kostet damit weitere $0.27.

Bei qwen3.7-plus steigt der Preis auf das 3-Fache: Ein Prompt mit 255,029 tokens kostet zum offiziellen Tarif $0.102, einer mit 257,332 tokens dagegen $0.309. Bei qwen3-coder-plus greift derselbe Mechanismus über vier Stufen. Ein Prompt mit 260k tokens hat daher den sechsfachen Preis pro token eines Prompts mit 30k tokens, beim Output ist es das Zwölffache.

Die Regel zeigt sich nicht nur in der Preistabelle des Anbieters, sondern auch auf einer echten Rechnung. Bei qwen3.5-plus liegen die offiziellen Input-Preisstufen bei $0.40 und ab 256K bei $0.50 pro Million tokens. In unserer Gateway-Abrechnung unterschied sich der Preis pro Input-token zwischen zehn Läufen unterhalb der Grenze mit 243k tokens und 24 Läufen oberhalb mit 256k bis 321k exakt um den Faktor 1,25. Der Output-Preis blieb unverändert. Der Request mit 259k tokens zahlte also nicht nur für die letzten 3k tokens das 1,25-Fache, sondern für alle.

Bei einem Agent, der seinen Verlauf fortlaufend erweitert, wird die Grenze mitten in der Session und ohne Hinweis überschritten. Der Turn, der die Schwelle reißt, zahlt den Aufpreis für alle mitgeführten früheren Turns. Jeder spätere Turn zahlt ihn ebenfalls, bis der Kontext verkleinert wird.

Steigt die Modellleistung an derselben Grenze?

Nein. Wir haben das geprüft, weil die Preisstufe leicht mit einer technischen Leistungsgrenze verwechselt werden kann. Das ist sie nicht. Bei zwei Qwen-Modellen mit Preisgrenze bei 256K haben wir an fünf Positionen jeweils eine gesalzene Needle platziert, also eine einzeilige Information mit einem zufälligen Code pro Lauf. Beide Modelle fanden sie bei 243k, 269k und 320k tokens jeweils in 30 von 30 Fällen, bei deaktiviertem Thinking. Die Latenz stieg kontinuierlich mit der Länge und zeigte keinen Sprung: Der Median bei qwen3.7-plus lag bei 15,2 s, 17,0 s und 20,5 s. Eine schwierigere Aufgabe, bei der K seltene, über das gesamte Log verteilte Vorkommen gezählt werden mussten, verschlechterte sich dagegen mit zunehmender Länge. qwen3.7-plus fand bei 128k noch 74%, bei 192k 60%, bei 243k 58% und bei 320k 45%. Der Rückgang beginnt deutlich unterhalb der Preisgrenze. Die Messpunkte direkt davor und danach liegen auf derselben Kurve.

Anthropic bezeichnet diesen schleichenden Effekt in der eigenen Dokumentation: Mit wachsender token-Anzahl nehmen Genauigkeit und Erinnerungsvermögen ab, ein Phänomen namens Context Rot. Der Effekt ist real und kontinuierlich, aber unabhängig von der Preisgrenze.

Wie bleibt ein Request unter der Grenze?

Begrenze den Input, nicht den Output. Die Preisstufe richtet sich nach der Input-Länge des Requests, daher hilft max_tokens als Output-Limit nicht. Entscheidend sind die Einstellungen, die begrenzen, was der Client sendet. Dafür gibt es vier Ebenen.

Die folgende Tabelle zeigt die Einstellungen zur Begrenzung des Prompts nach Ebene. “Unter einer Preisstufe?” markiert Optionen, die eine absolute token-Anzahl akzeptieren und sich deshalb knapp unterhalb einer Preisgrenze setzen lassen. Fensterbezogene Optionen halten den Request nur innerhalb des Context Window des Modells. Das ist eine andere Grenze.

Aus der Tabelle folgen zwei Punkte. Wird ein Coding Agent mit einem Modell mit Preisstufen verwendet, wandelt das Compaction Window den Kostensprung in eine Zusammenfassung um. Es muss als absolute token-Anzahl knapp unterhalb der Preisgrenze gesetzt werden, nicht als Anteil eines 1M-Fensters. Die beiden häufigsten Sicherheitseinstellungen, Responses truncation: "auto" und Middle-out des Aggregators, schützen dagegen nur vor dem Überschreiten des Context Window. Bei den betroffenen Modellen Gemini und GPT-5.6 liegt dieses bei 1M statt an den Preisgrenzen von 200,000 beziehungsweise 272,000 tokens. Sie verhindern also einen fehlgeschlagenen Request, aber nicht das Überschreiten der Preisgrenze.

Verlass dich nicht auf Caching, um unter der Grenze zu bleiben. Prompt Caching senkt zwar die Rechnung, aber nicht die Preisstufe der Google-Modelle. Dort gelten für Cache-Lesezugriffe dieselben längenabhängigen Preisstufen: Ein gecachter Prefix mit 150k und 60k frischer Kontext ergeben zusammen einen Prompt mit 210k und werden als Einheit abgerechnet. Provisionierte Kapazität umgeht die Frage vollständig, weil Provisioned Throughput Units (PTUs) unabhängig von der token-Anzahl pro Stunde abgerechnet werden. Wenn sich das Überschreiten lohnt, sollte es bewusst geschehen. Unsere Messung zeigt keinen Qualitätssprung an der Grenze. Entscheidend ist allein, ob der zusätzliche Kontext einen Multiplikator von 2x, 3x oder in den höchsten Stufen 6,7x auf den gesamten Request rechtfertigt.

Wie Synthorai damit umgeht

Eine Längenstufe ist eine Preisbedingung, deshalb behandelt das Gateway sie auch so. Die Preiskarte eines Modells kann eine Liste von Stufen enthalten, die jeweils an eine Grenze für Input-tokens gebunden sind. Jeder Request wird anhand der von seiner Prompt-Länge gewählten Stufe bepreist, und zwar für alle seine tokens, genau wie beim Anbieter. Diesen Mechanismus hat die oben gezeigte Rechnung für qwen3.5-plus durchlaufen. Der Usage Record speichert die Anzahl der Prompt-tokens und die Preisversion zusammen mit den berechneten Kosten. Eine Rechnung lässt sich daher bis zur Aussage “Dieser Request hat die Grenze überschritten” aufschlüsseln. Die für einen Request verwendete Preisstufe lässt sich aus dem Usage Record auslesen, nicht nur aus einer Preistabelle.

FAQ

Wird der höhere Long-Context-Preis nur für tokens oberhalb der Grenze berechnet?

Nein. Jeder Anbieter mit dokumentierter Regel bepreist den gesamten Request neu: Google (“all tokens (input and output) are charged at long context rates”), OpenAI (“for the full request”), xAI (“for all tokens in the request”), Alibaba (“all tokens in the request are billed at the unit price of the corresponding tier”). Bereits ein Prompt, der die Grenze um ein token überschreitet, zahlt den Aufpreis auf alle vorherigen tokens.

Reichen API-Gateways Long-Context-Preisstufen weiter?

Ja, zumindest in unserer Messung. Über einen großen Aggregator wurden neun Modelle oberhalb der jeweiligen Anbietergrenze zum höheren Anbieterpreis abgerechnet, obwohl ihre Modellseiten nur einen Preis zeigen. Die Preisstufe steht in den Preismetadaten des Gateways, nicht auf der Seite. Die Metadaten können zugleich eine Anbieter-Stufe auslassen, wie bei qwen3-coder-plus oberhalb von 256K.

Hält max_tokens einen Request unter einer Preisstufe?

Nein. max_tokens begrenzt den Output, die Preisstufe wird jedoch von der Input-Länge bestimmt. Nützlich sind Einstellungen, die den Prompt begrenzen: ein Compaction Window oder token-Limit im Agent, etwa Claude Code /autocompact oder Codex model_context_window, ein Compaction-Trigger in der API oder clientseitiges Truncation vor dem Senden des Requests.

Sinkt die Modellqualität an der Preisgrenze?

Nicht in unserer Messung. Bei zwei Qwen-Modellen mit Preisstufen war der Needle Recall auf beiden Seiten der 256K-Grenze perfekt. Eine Zählaufgabe verschlechterte sich mit wachsender Länge kontinuierlich, ohne Sprung an der Grenze. Die Preisstufe ist eine Geschäftsregel. Der Qualitätsverlust durch längere Kontexte ist real, verläuft aber kontinuierlich.

Preise und Semantik stammen von den am 2026-09-01 abgerufenen Preisseiten der Anbieter. Die Einstellungen für Agents und APIs stammen aus der am 2026-09-02 verlinkten Dokumentation. Die Rechnungsmessungen liefen vom 2026-09-01 bis 2026-09-03 mit deaktiviertem Thinking und gesalzenen Prompts, jeweils zwei Läufe pro Messpunkt des Aggregators. Preise ändern sich. Prüfe die verlinkte Quelle, bevor du eine Grenze fest in den Billing-Code einbaust.

Verwandte Beiträge: Praxisleitfaden zu Abrechnungseinheiten (die hier genauer betrachtete Modifier-Ebene), Anatomie der token-Nutzung, Prompt Caching erklärt, gemessene Cache-Mindestgrößen.

← Zurück zum Blog