fix(catalog): cap DeepSeek V4 context window at 512K for Together/Fireworks bindings

[steventohme]

Together and Fireworks serve DeepSeek V4 at 512,000 tokens, not the native 1,048,576. Setting the catalog ContextWindow to 1M caused the HMM policy resolver and excludeContextOverflowModels to pass through requests >512K, which hit a 400 context_length_exceeded on Together/Fireworks after failover from Makora.

Makora may serve the full 1M window, but failover walks to 512k-capped providers, so the conservative minimum matches the existing minimax pattern (PR#381) that already caps m2.7 at 204,800 and m3 at 512,000.

Observed in prod: deepseek-v4-pro requests with ~581K input tokens failed with context_length_exceeded on Together after Makora failover. Also caught 490K+ requests failing on Fireworks across 29 error calls in 7 days. The max Makora-served input in the same window is ~604K (no errors), confirming Makora's own capacity doesn't need the cap. But the binding-ordered failover chain means a Makora → Together/Fireworks hop on a >512K request will always 400.

🤖 Generated with Weave Router

[claude]

Claude finished @steventohme's task —— View job

---

Advisory comment-length review posted.

• Run git diff origin/main...HEAD -- '*.go' and scan added comment blocks
• Flag blocks ≥ 3 consecutive lines that are verbose or redundant
• Post committable suggestions via PR review

---

[workweave-bot]

Advisory only — comment-length nits. Won't block merge.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 3e5f173. Configure here.}

[greptile-apps]

T-Rex Logs

What T-Rex did

• T-Rex produced a finding-comment-proof for a posted P1 finding.
• T-Rex produced a second finding-comment-proof for another posted P1 finding.
• T-Rex ran a general-contract-validation-proof that compared catalog bindings and token-window behavior, confirming the exclusion of the 512000-range case and the existence of usable dispatch targets, with an eligible outcome for the 512001-token request.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Flash is globally pre-filtered at 512K despite having no 512K-capped bindings

   • Bug
     • At 512,001 tokens, Flash is inserted into the context-overflow exclusion set before the route request is created. The model therefore cannot be selected even when Makora or OpenRouter is enabled and resolves successfully. The catalog comment's minimum-across-bindings rationale names Together and Fireworks, neither of which is a Flash binding.
   • Cause
     • internal/router/catalog/catalog.go:371 hard-codes Flash's ContextWindow to 512_000, while its bindings at lines 372-374 are Makora and OpenRouter. excludeContextOverflowModels in internal/proxy/service.go:754-780 uses that model-level value before router binding selection.
   • Fix
     • Set Flash's catalog context window to the supported minimum of its actual configured bindings (the adjacent catalog documentation states native 1,048,576 tokens), and update the focused catalog/proxy expectation. If a provider-specific lower limit is later required, represent it per binding or exclude that provider at binding resolution rather than globally rejecting the model.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(catalog): cap DeepSeek V4 context wi..." | Re-trigger Greptile}

[greptile-apps]

Flash context pre-filter rejects usable bindings

The 512,000-token model-level limit is enforced by the production context-overflow pre-filter before routing resolves a provider binding. Consequently, a 512,001-token Flash request excludes deepseek/deepseek-v4-flash even when Makora or OpenRouter is available. Those are Flash's only configured bindings; neither is the Together or Fireworks provider cited by the adjacent minimum-window rationale.

Artifacts

Evidence from the check

• Review-authored test source directly invokes the production pre-filter at 512,001 tokens and resolves each configured Flash binding, ending with the takeaway that the test exercises the exact affected decision path.

Command output from the check

• Executed `go test ./internal/proxy -run ^TestPR865Flash512001PreFilter$ -count=1 -v` from `/home/user/repo`; it exited 0 and shows Flash excluded at 512,001 before its Makora and OpenRouter bindings are resolved, ending with the takeaway that the current catalog makes the configured model unavailable.

Command output from the check

• Executed `go test ./internal/proxy -run ^TestPR865FlashNativeWindowControl$ -count=1 -v` from `/home/user/repo`; it exited 0 and shows the same 512,001-token request fits a 1,048,576-token window, ending with the takeaway that the lower catalog cap causes the rejection.

_{Ran code and verified through T-Rex}

[claude]

Claude finished @steventohme's task —— View job

---

• Run git diff and analyze added comment lines
• Check for 3+ line comment blocks that are verbose/redundant
• Post review suggestion or exit silently

No added comment blocks of 3+ consecutive lines found — nothing to flag.

View job