fix(context-length): context_window alias, config override bypasses 64K guard, extend 32K underreport guard to MiniMax

[CryptoByz]

Fixes #8015, #11096, #24140, #24268

Problem

Four related issues in the context-length resolution pipeline, all
stemming from the same area of code:

#8015, context_window silently ignored in config.yaml
Users setting model.context_window (a natural alias for
model.context_length) got no error and no effect. Hermes fell through
to auto-detection, hitting the 64K minimum guard on large-context models
configured with a small native window, or compressing unnecessarily on
1M+ models.

#11096, 64K boot guard fires even when context_length is explicitly set
The guard was unconditional. A user running e.g. Qwen 3.5 35B-A3B (32K
native) with model.context_length: 40000 in config.yaml still got:

"context window of 32,768 tokens is below the minimum 64,000 required"
The escape hatch documented in the error message didn't actually work.

#24268, kimi-k2.6 on Nous path resolves to 32K, blocks boot
OpenRouter's catalog reports 32,768 for kimi-k2.6. The existing
_model_name_suggests_kimi() guard was meant to catch this but the
Nous resolution path called the raw ctx <= 32768 and _model_name_suggests_kimi() check inconsistently, allowing a stale
OR cache entry to pass through and freeze 32K into the persistent cache.

#24140,MiniMax-M2.x resolves to 32K on OpenRouter
Same root cause as #24268 - OR catalog underreports MiniMax M2.x as
32,768 tokens. The _model_name_suggests_kimi() guard didn't cover
MiniMax, so these models hit the 64K boot guard every time.

Root causes

1. run_agent.py and gateway/run.py only called .get("context_length")
   the context_window key was never read.
2. The 64K minimum guard at agent init ran unconditionally, ignoring
   whether _config_context_length was set.
3. _model_name_suggests_kimi() only covered Kimi/Moonshot families.
   The scattered ctx <= 32768 and _model_name_suggests_kimi(model)
   pattern was duplicated across 4 call sites with no shared abstraction.

Fix

run_agent.py context_window alias + guard bypass

• Read model.context_window as a fallback when model.context_length
  is absent (Bug: context_window key in config.yaml silently ignored, falls back to 128K default #8015). Both keys now produce the same effect.
• 64K minimum guard now skips when _config_context_length is not None
  (Three bugs in v0.9.0: context_length override, thinking-block sessions, config.yaml vs env precedence #11096). The user explicitly told Hermes the context size respect it.

gateway/run.py context_window alias

• Same context_window alias applied to both context-length read sites
  in the gateway path (Bug: context_window key in config.yaml silently ignored, falls back to 128K default #8015).

agent/model_metadata.py unified 32K underreport guard

• _model_name_suggests_kimi() extended to cover MiniMax M2.x and
  MiniMax-Text-01 (All models rejected with "context window below minimum 64,000 tokens" — Telegram completely down #24140), the second most frequently misreported
  family in OR's catalog.
• New helper _or_ctx_is_plausibly_wrong(ctx, model) consolidates the
  scattered ctx <= 32768 and _model_name_suggests_kimi() pattern.
  All 4 call sites now go through this single function, making future
  additions (new model families) a one-line change.

What this does NOT change

• Resolution order is unchanged no steps added or removed.
• Models correctly reported by OpenRouter are unaffected.
• The 64K guard still fires for genuinely small-context models when no
  explicit override is set, protecting users from tool-calling failures.
• context_window and context_length are treated identically;
  if both are set, context_length wins (existing key takes priority).

[alt-glitch]

Supersedes multiple open PRs: #8010/#15587 (context_window alias), #9142/#11097/#8962 (64K guard bypass), #24436/#24552 (MiniMax 32K guard). Combo fix addressing all four issues. Related to #8015, #11096, #24140, #24268.

[CryptoByz]

Thanks for the summary. Aware of the prior attempts - the reason I bundled these into one PR is that all four issues share the same root in the context-length resolution pipeline, and fixing them in isolation tends to leave edge cases open (e.g. fixing the 64K guard without the context_window alias still breaks users who set the wrong key). Happy to split into smaller PRs if that's easier to review, but the combined approach felt cleaner given the shared code path.

[CryptoByz]

Test Plan

# context_window alias
./scripts/run_tests.sh tests/agent/test_model_metadata.py -q -k "context"

# 64K guard bypass with explicit config override
./scripts/run_tests.sh tests/agent/test_run_agent.py -q -k "context_length or minimum_context"

# MiniMax / Kimi 32K underreport guard
./scripts/run_tests.sh tests/agent/test_model_metadata.py -q -k "kimi or minimax or plausibly_wrong"

Verified locally: _or_ctx_is_plausibly_wrong("MiniMax-M2.7", 32768) returns True, boot no longer blocked. context_window: 40000 in config.yaml now correctly bypasses the 64K guard.

[teknium1]

Thanks for the thorough writeup here, Beyaz — you clearly mapped the context-length resolution path well. We're going to close this without merging, and I want to be straight about why across all four issues it targets:

#24140 (MiniMax-M2.x → 32K) and #24268 (Kimi-k2.6 → 32K): both are already fixed on current main, just via a different mechanism. The hardcoded catalog now carries explicit entries (minimax-m3: 1,000,000, MiniMax-M2.5: 204,800, generic minimax: 204,800), and _model_name_suggests_kimi() + the ctx <= 32768 reject guard already cover the Kimi underreport at all three resolution sites. So the model_metadata.py half of this PR is redundant.

#11096 (64K boot guard): we're declining the override by design. A model below the 64K minimum is genuinely unreliable for tool-calling workflows, and we'd rather not ship a config escape hatch that lets people footgun themselves into a broken setup. The guard stays unconditional on purpose.

#8015 (context_window alias): we're keeping a single canonical key (context_length) rather than accepting a second spelling — one name to document, one name to support.

One heads-up for future PRs: the new _or_ctx_is_plausibly_wrong() helper calls itself in its own body, which is unconditional infinite recursion — it would RecursionError on every context resolution. Worth a local run of the touched path before pushing; the model-metadata path can't be exercised by the existing unit tests alone.

None of this is a reflection on the effort — the analysis was solid and the issue-mapping was useful. It just didn't line up with where we want the resolution path and the guard to go. Keep them coming.