fix(bedrock): Fable reports 128K context — add Fable + Claude 4.6/4.7/4.8 1M entries to Bedrock table, invalidate stale cache

[avifenesh]

Symptom

On current main, every Bedrock-hosted current Claude model gets a wrong context window from get_model_context_length():

• *.anthropic.claude-fable-5 → 128K (no table entry; falls to BEDROCK_DEFAULT_CONTEXT_LENGTH) — for a 1M model
• *.anthropic.claude-opus-4-7 / -4-8 → 200K (substring-match falls back to the generic anthropic.claude-opus-4 key)
• *.anthropic.claude-opus-4-6 / sonnet-4-6 → 200K (explicit stale entries)

Practical effect: the agent compresses history prematurely — at 128K/200K of a 1M window.

Repro on main:

from agent.model_metadata import get_model_context_length
get_model_context_length('global.anthropic.claude-fable-5', provider='bedrock')
# → 128000, expected 1000000

Why DEFAULT_CONTEXT_LENGTHS doesn't save it

#42991 correctly registers claude-fable-5 → 1M in DEFAULT_CONTEXT_LENGTHS, but the Bedrock branch at step 1b in get_model_context_length() returns get_bedrock_context_length() before that catalog is consulted. On Bedrock, BEDROCK_CONTEXT_LENGTHS is the only voice — so it must carry these entries itself.

Fix (whole class, both layers)

1. Table (bedrock_adapter.py): add anthropic.claude-fable-5 / claude-fable / opus-4-8 / opus-4-7 → 1M; correct opus-4-6 / sonnet-4-6 to 1M (AWS lists these as 1M-context Bedrock models). Pre-4.6 models keep 200K. Longest-substring matching keeps the generic opus-4 → 200K fallback safe.
2. Stale cache invalidation (model_metadata.py): fixing the table alone never reaches existing installs — a previously persisted 128K/200K cache entry wins at step 1 and masks the corrected table forever. Bedrock-context cache hits are now reconciled against the static table (authoritative for Bedrock; there is no live probe), so existing users converge without manual cache surgery. Mirrors the existing stale-cache patterns (Codex ≥400K, Kimi 32K, MiniMax-M3, Grok-4.3) already in that function.

Tests

• New table entries incl. inference-profile (us./global.) and versioned (-v1:0) ID forms
• Fable 128K-default regression (test_bedrock_claude_fable_resolves_to_1m_not_128k_default)
• Stale 200K cache entry is dropped and re-resolves to 1M (test_bedrock_claude_4_6_ignores_stale_200k_cache, real cache file in tmp_path, no mocked resolution)
• Pre-4.6 models stay 200K (test_claude_opus_4_base_stays_200k)

pytest tests/agent/test_bedrock_adapter.py tests/agent/test_model_metadata.py → 230 passed.

Relationship to open PRs

#24059 / #26769 / #44419 each correct the 4.6/4.7 table entries but none covers Fable (today's 128K case, the worst one), 4.8, or the stale-cache layer that makes the fix actually land on existing installs. This PR intentionally does not touch the beta-header question (#44419's conditional context-1m forwarding for regional profiles) — that's an orthogonal request-path concern; this PR is purely metadata resolution.

Verified end-to-end on a live Bedrock setup (global.anthropic.claude-fable-5): reports 1,000,000 after this change, 128,000 before.

[tonydwb]

Good fix. Updates Bedrock Fable + Claude 4.6/4.7/4.8 context table entries from 200K to 1M to match AWS/Anthropic documentation. Also adds cache invalidation for stale entries that were seeded before the correction. Test updated. No issues found.

[teknium1]

Thanks for covering both the static metadata and upgrade-cache path. Current main still has the reported defect: agent/bedrock_adapter.py:1298-1326 assigns Claude 4.6 200K and lacks Fable/Opus 4.7/4.8 entries, while agent/model_metadata.py:2105-2178 can return a persistent cached value before the Bedrock table at :2180-2198 runs. The proposed table update plus Bedrock cache reconciliation addresses both verified paths without changing the resolution order or prompt-cache behavior.

Automated hermes-sweeper review.

[teknium1]

Merged via PR #68006 — your commit was cherry-picked onto current main with your authorship preserved (rebase merge). The Claude 4.6-4.8 table rows had landed hours earlier via #67977 (salvaged from older PRs in the same cluster), but your Fable rows and especially the stale-cache invalidation were the surviving value — without it, anyone who ran Bedrock before the table fix would have kept a 200K cached window forever. One adjustment on top: the invalidation now treats the table as a floor (only under-reporting entries are dropped) so it composes with the live context-probe that landed after it. Thanks!

#68006