That 128K Context Window Might Be a Guess — Hermes Now Says So


You try a new model on Bedrock, and Hermes shows ctx 128K in the status bar. You act on it: a cross-file question in a thirty-thousand-token repository. Halfway through the answer, it starts compressing history. You check the vendor’s model card afterwards and the window is 1,050,000 tokens — eight times what you were told.

Worse, the label next to that number said “detected”. It looked like a fact. It was a default.

One number decides three things

A context window is not decoration. It decides when history gets compressed, how much material fits in a prompt, and how overflow recovery behaves. Underestimate it and compression fires too early, so long tasks lose their memory mid-flight. Overestimate it and the provider rejects the request outright.

So “was this number detected or guessed” is not academic. It explains two completely different symptoms.

Where the number comes from

The resolver tries sources in order and stops at the first hit:

  1. Probe the provider and take the exact value.
  2. The provider’s static table — on Bedrock, the model table.
  3. The catalog’s window for the same family — what Hermes’ model catalog says about that model family.
  4. A static default — 128K on Bedrock, 256K on the generic route.

Step 3 is what this change adds. Before it, a Bedrock model missing from the static table fell straight from step 2 to the 128K default at step 4, even when the model catalog already knew the family’s window.

That step only applies to Anthropic, OpenAI and xAI models: bare IDs, geo- or global-prefixed IDs, and IDs inside a foundation-model or inference-profile ARN. The next section explains why it stops there.

What “fallback” actually claims

The marker makes exactly one claim: no local source reported this number; it is the fallback value.

You will see it on the gateway session line (worded “fallback, not a detected limit”), in /usage, in the wide status bar, in the welcome banner, and in the /model switch summary; follow-up fixes extended the same label to /status and /context. In the status bar it shows up as a short suffix.

Keep it distinct from the other suffix: pinned means you set the value yourself, fallback means the system defaulted. Neither one means the provider said so.

The marker only does local reads, fails open, and never probes, so it cannot slow the status bar down. It records per profile home, model and base URL — which was one of the follow-up fixes: the first implementation used a 60-second memo keyed without the profile home, so one profile’s verdict could label another profile’s window.

A real case: nine days of GPT-6.1 Terra as 128K

On the day Terra launched (October 26), the model catalog learned its window: 1,050,000. The Bedrock table did not change, and the Bedrock resolver never consults the catalog. So v0.22.6, v0.22.7 and main all resolved Terra on Bedrock to 128K — and compression starts at 75% of the window, which means 96K.

After the fix, a Bedrock model from Anthropic, OpenAI or xAI that the static table does not list yet takes its family window from the catalog before the 128K default applies. Terra gets 1,050,000 back, and so does GPT-5.4. The bare Terra ID also gained routing: its model card lists Mantle as the only endpoint for that form.

Why only those three vendors? Because their catalog rows match their Bedrock cards closely: of 34 cards, 27 are equal, 6 are below and 1 is above. The single row above is GPT-6.1 Sol (1,050,000 in the catalog against a 1M card), and it has its own table row, which wins.

Other vendors cannot be borrowed this way. Their catalog rows are vendor-direct windows that can exceed what Bedrock serves: Llama 3 8B has an 8K card while the llama row says 131,072; Qwen3 32B has a 32K card while the qwen row says 131,072. Borrowing those would trade an early compression for a request the provider rejects.

Why the default does not just move to a million

The suggestion comes up: new models are huge, so raise the floor to 1M. The answer is in a hundred Bedrock text-model cards: 32 are ≥1M, but 36 are ≤128K and 8 sit below that (Llama 3 8B/70B at 8K; Mistral 7B, Mixtral, Small and Large 2402 at 32K; Qwen3 32B at 32K; Palmyra Vision at 4K).

A 1M floor would send those models requests 8 to 250 times too large. Bedrock’s reply to an oversized payload is unhelpful: an opaque InternalServerException, or “Input is too long for requested model.” Overflow recovery only adopts a limit the error actually quotes, so with no number in the message there is nothing to correct — the turn compresses and fails again on every request.

So the default stays at 128K and the family window handles new models instead: the models that actually hit the default are new frontier releases, and those reach the catalog first.

Here is the whole card set checked before and after:

equal to the card under the card over the card
before 55 37 8
after 77 15 8

All 8 “over” rows are cards below 128K that hit the default; this change leaves them alone.

Setting it yourself

There is no new config key — the overrides are the same as before. Pin one globally:

model:
  context_length: 200000

Or override per provider and model:

model_overrides:
  bedrock:
    us.openai.gpt-6.1-terra:
      context_window: 1050000

The generic form is the same shape: under model_overrides, provider first, then model, then context_window.

A pinned value outranks a fallback and shows as pinned rather than fallback. If you switch model or route in the gateway, the configured pin is dropped first, so an old window’s number never sits next to a new model’s name.

How to tell whether your number is trustworthy

A four-step check:

  1. Look for fallback after the number in /usage, /status or /context.
  2. If it is there, check the model card or the provider docs for the real window.
  3. Pin it with model_overrides once you know.
  4. Confirm the direction with symptoms: compression much earlier than expected means the number is too small; rejected requests that mention input length mean it is too large.

This landed on main on November 4, after the v0.22.7 release point, so it is not in a release yet as of this writing — the next version picks it up.

To go one layer deeper, the context usage and anchor post covers keeping the right information through compression, the lean-tail compression guide covers making history cheaper to keep, and the Codex context window defaults post is the same mechanism seen from another entry point.