Diese 128K im Kontextfenster sind vielleicht nur geraten — Hermes sagt es jetzt

Du probierst ein neues Modell auf Bedrock aus, und Hermes zeigt ctx 128K in der Statusleiste. Du handelst danach: eine dateiübergreifende Frage in einem Repository mit dreißigtausend Tokens. Mitten in der Antwort beginnt es, den Verlauf zu komprimieren. Danach schaust du in die Modellkarte des Anbieters — das Fenster hat 1.050.000 Tokens, achtmal so viel wie dir gesagt wurde.
Schlimmer noch: Das Label neben der Zahl sagte „detected“. Es sah aus wie ein Fakt. Es war ein Default.
Eine Zahl entscheidet über drei Dinge
Ein Kontextfenster ist keine Dekoration. Es entscheidet, wann der Verlauf komprimiert wird, wie viel Material in einen Prompt passt und wie sich Overflow-Recovery verhält. Schätzt du es zu klein, feuert die Kompression zu früh, und lange Aufgaben verlieren mitten im Flug ihr Gedächtnis. Schätzt du es zu groß, lehnt der Anbieter die Anfrage rundheraus ab.
Ob eine Zahl erkannt oder geraten wurde, ist also keine akademische Frage. Sie erklärt zwei völlig verschiedene Symptome.
Woher die Zahl kommt
Der Resolver probiert die Quellen der Reihe nach und stoppt beim ersten Treffer:
- Probe beim Anbieter und den exakten Wert übernehmen.
- Die statische Tabelle des Anbieters — auf Bedrock die Modelltabelle.
- Das Fenster des Katalogs für dieselbe Familie — was der Modellkatalog von Hermes über diese Modellfamilie sagt.
- Ein statischer Default — 128K auf Bedrock, 256K auf der generischen Route.
Schritt 3 ist das, was diese Änderung hinzufügt. Vorher fiel ein Bedrock-Modell, das in der statischen Tabelle fehlte, direkt von Schritt 2 auf den 128K-Default in Schritt 4 — selbst wenn der Modellkatalog das Fenster der Familie längst kannte.
Dieser Schritt gilt nur für Modelle von Anthropic, OpenAI und xAI: nackte IDs, geo- oder global-präfixierte IDs und IDs innerhalb eines Foundation-Model- oder Inference-Profile-ARN. Der nächste Abschnitt erklärt, warum es dort endet.
Was „fallback“ tatsächlich behauptet
Der Marker behauptet genau eines: Keine lokale Quelle hat diese Zahl gemeldet; es ist der Fallback-Wert.
Du siehst ihn in der Gateway-Session-Zeile (formuliert als „fallback, not a detected limit“), in /usage, in der breiten Statusleiste, im Willkommensbanner und in der Zusammenfassung beim Modellwechsel über /model; Folge-Fixes haben dasselbe Label auf /status und /context ausgeweitet. In der Statusleiste erscheint er als kurzes Suffix.
Halt ihn getrennt vom anderen Suffix: pinned heißt, du hast den Wert selbst gesetzt; fallback heißt, das System hat ihn defaultet. Keines von beiden heißt, dass der Anbieter es gesagt hat.
Der Marker macht nur lokale Reads, failt offen und prüft nie aktiv, kann die Statusleiste also nicht ausbremsen. Er wird pro Profil-Home, Modell und Base-URL erfasst — was einer der Folge-Fixes war: Die erste Implementierung nutzte ein 60-Sekunden-Memo, dessen Key das Profil-Home nicht enthielt, sodass das Urteil eines Profils das Fenster eines anderen labeln konnte.
Ein echter Fall: neun Tage GPT-6.1 Terra als 128K
Am Tag des Terra-Launches (26. Oktober) lernte der Modellkatalog sein Fenster: 1.050.000. Die Bedrock-Tabelle änderte sich nicht, und der Bedrock-Resolver konsultiert den Katalog nie. Also lösten v0.22.6, v0.22.7 und main Terra auf Bedrock alle zu 128K auf — und die Kompression beginnt bei 75 % des Fensters, also bei 96K.
Nach dem Fix nimmt ein Bedrock-Modell von Anthropic, OpenAI oder xAI, das die statische Tabelle noch nicht listet, sein Familienfenster aus dem Katalog, bevor der 128K-Default greift. Terra bekommt 1.050.000 zurück, und GPT-5.4 auch. Die nackte Terra-ID bekam außerdem Routing: Ihre Modellkarte listet Mantle als einzigen Endpunkt für diese Form.
Warum nur diese drei Anbieter? Weil ihre Katalogzeilen eng zu ihren Bedrock-Karten passen: Von 34 Karten sind 27 gleich, 6 liegen darunter und 1 darüber. Die einzige Zeile darüber ist GPT-6.1 Sol (1.050.000 im Katalog gegen eine 1M-Karte), und sie hat ihre eigene Tabellenzeile, die gewinnt.
Andere Anbieter lassen sich so nicht ausleihen. Ihre Katalogzeilen sind Vendor-Direct-Fenster, die überschreiten können, was Bedrock serviert: Llama 3 8B hat eine 8K-Karte, während die Zeile llama 131.072 sagt; Qwen3 32B hat eine 32K-Karte, während die Zeile qwen 131.072 sagt. Diese auszuleihen würde eine frühe Kompression gegen eine Anfrage tauschen, die der Anbieter ablehnt.
Warum der Default nicht einfach auf eine Million wandert
Der Vorschlag kommt auf: Neue Modelle sind riesig, also heb den Boden auf 1M. Die Antwort steht in hundert Bedrock-Textmodell-Karten: 32 sind ≥1M, aber 36 sind ≤128K und 8 liegen darunter (Llama 3 8B/70B mit 8K; Mistral 7B, Mixtral, Small und Large 2402 mit 32K; Qwen3 32B mit 32K; Palmyra Vision mit 4K).
Ein 1M-Boden würde an diese Modelle Anfragen schicken, die 8- bis 250-mal zu groß sind. Bedrocks Antwort auf eine überdimensionierte Payload ist wenig hilfreich: eine opake InternalServerException oder „Input is too long for requested model.“ Overflow-Recovery übernimmt nur eine Grenze, die der Fehler tatsächlich zitiert; steht keine Zahl in der Meldung, gibt es nichts zu korrigieren — der Turn komprimiert und scheitert bei jeder Anfrage erneut.
Also bleibt der Default bei 128K, und das Familienfenster übernimmt neue Modelle: Die Modelle, die den Default tatsächlich treffen, sind neue Frontier-Releases, und die erreichen den Katalog zuerst.
Hier der ganze Kartensatz, vorher und nachher geprüft:
| gleich der Karte | unter der Karte | über der Karte | |
|---|---|---|---|
| vorher | 55 | 37 | 8 |
| nachher | 77 | 15 | 8 |
Alle 8 „über“-Zeilen sind Karten unter 128K, die den Default treffen; diese Änderung lässt sie in Ruhe.
Selbst setzen
Es gibt keinen neuen Config-Key — die Overrides sind dieselben wie vorher. Global festnageln:
model:
context_length: 200000
Oder pro Anbieter und Modell überschreiben:
model_overrides:
bedrock:
us.openai.gpt-6.1-terra:
context_window: 1050000
Die generische Form hat dieselbe Gestalt: unter model_overrides, zuerst der Anbieter, dann das Modell, dann context_window.
Ein gepinnter Wert schlägt einen Fallback und erscheint als pinned statt fallback. Wenn du Modell oder Route im Gateway wechselst, wird der konfigurierte Pin zuerst verworfen, damit die Zahl eines alten Fensters nie neben dem Namen eines neuen Modells steht.
Woran du erkennst, ob deine Zahl vertrauenswürdig ist
Ein Vier-Schritte-Check:
- Suche in
/usage,/statusoder/contextnachfallbackhinter der Zahl. - Steht es da, prüfe die Modellkarte oder die Anbieter-Doku auf das echte Fenster.
- Pinne es mit
model_overrides, sobald du es weißt. - Bestätige die Richtung an den Symptomen: Kompression viel früher als erwartet heißt, die Zahl ist zu klein; abgelehnte Anfragen, die die Eingabelänge erwähnen, heißen, sie ist zu groß.
Das landete am 4. November auf main, nach dem Release-Punkt von v0.22.7, ist also zum Zeitpunkt dieses Textes noch in keinem Release — die nächste Version nimmt es mit.
Um eine Schicht tiefer zu gehen: Der Beitrag zu Kontextnutzung und Anker behandelt, wie die richtigen Informationen durch die Kompression kommen, der Leitfaden zur Lean-Tail-Kompression macht den Verlauf günstiger zu halten, und der Beitrag zu den Codex-Kontextfenster-Defaults ist derselbe Mechanismus von einem anderen Einstiegspunkt aus.