fix(combo): reject known context overflow without exhausting providers

[JxnLexn]

What changed

• Reject combo requests before upstream dispatch when every target has a known context limit and every target is too small.
• Return a machine-readable context_length_exceeded HTTP 400 response with combo diagnostics.
• Classify Codex status: "failed" responses without usable output as request-scoped upstream failures.
• Prevent request-scoped synthetic failures from opening provider breakers, disabling accounts, exhausting connections, or applying model/provider/semaphore cooldowns.
• Preserve the concrete combo failure message in rejected-request logs instead of reporting every failure as all targets exhausted.

Why

Oversized Codex requests were still dispatched even when all combo targets had known insufficient context windows. Codex could answer HTTP 200 with status: "failed" and empty output; OmniRoute converted this into a synthetic 502 and incorrectly treated it as provider-wide failure. Repetition then opened the Codex breaker and produced the misleading all targets exhausted dashboard state.

Scope

This PR is based directly on release/v3.8.49. It contains only the local context-window fix diff from JxnLexn/OmniRoute:dev/fix_error_context_window_size against its unchanged JxnLexn/OmniRoute:main base. No additional changes from JxnLexn/OmniRoute:main and no encrypted-reasoning changes are included.

Validation

• Focused context-window/breaker/diagnostics suite: 60/60 passed.
• Adjacent combo/chatCore regression suite: 119/119 passed.
• npm run typecheck:core
• Targeted ESLint on all changed files.
• git diff --check
• Stable patch ID matches the captured source diff exactly.

[gemini-code-assist]

Code Review

This pull request introduces request-scoped upstream failure detection to prevent model-specific or request-specific errors (such as context length exceeded or empty responses) from triggering provider-wide resilience penalties like cooldowns or circuit breakers. It also adds early rejection for requests that exceed the context limits of all targets in a combo, and improves error logging for failed combo responses. The review feedback suggests adding a defensive guard check in getKnownContextLimit to prevent potential runtime TypeError crashes when model capabilities are undefined.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

To prevent potential runtime TypeError crashes if getResolvedModelCapabilities returns null or undefined (e.g., for unknown or custom models), we should add a defensive guard check at the beginning of getKnownContextLimit.

Suggested change

	function getKnownContextLimit(
	capabilities: {
	maxInputTokens?: number | null;
	contextWindow?: number | null;
	},
	requestedOutputTokens = 0
	): number | null {
	const limits: number[] = [];
	if (capabilities.maxInputTokens != null) {
	limits.push(capabilities.maxInputTokens + requestedOutputTokens);
	}
	if (capabilities.contextWindow != null) {
	limits.push(capabilities.contextWindow);
	}
	return limits.length > 0 ? Math.min(...limits) : null;
	}
	function getKnownContextLimit(
	capabilities: {
	maxInputTokens?: number | null;
	contextWindow?: number | null;
	} | null | undefined,
	requestedOutputTokens = 0
	): number | null {
	if (!capabilities) return null;
	const limits: number[] = [];
	if (capabilities.maxInputTokens != null) {
	limits.push(capabilities.maxInputTokens + requestedOutputTokens);
	}
	if (capabilities.contextWindow != null) {
	limits.push(capabilities.contextWindow);
	}
	return limits.length > 0 ? Math.min(...limits) : null;
	}

[diegosouzapw]

Not applying this one — verified false positive.

getResolvedModelCapabilities (src/lib/modelCapabilities.ts:385) is declared (input: CapabilityInput): ResolvedModelCapabilities — a non-nullable return type — and its body has exactly one return, an object literal. There is no code path that returns null/undefined, including for unknown/custom models: those resolve to an object whose maxInputTokens/contextWindow fields are null, which getKnownContextLimit already handles (both != null guards fail → limits stays empty → returns null → the caller fails open and keeps the legacy behavior). That unknown-metadata path is covered by tests/unit/combo-context-window-filter.test.ts ("unknown context metadata keeps overflow detection fail-open").

Widening the parameter type to | null | undefined would weaken the signature to accept a value the compiler already proves cannot occur, so the guard would be dead code.

Note getKnownContextLimit moved in 63966f5 — it is now exported from comboStructure.ts and consumed by the new open-sse/services/combo/knownContextOverflow.ts leaf (file-size ratchet extraction). Leaving this thread open for the maintainer to close.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[diegosouzapw]

Thanks for this — both pieces are real fixes. The pre-flight overflow rejection (avoiding wasted upstream dispatch + a clean context_length_exceeded 400 instead of a misleading 'all targets exhausted' after repeated retries) and the Codex status:"failed" request-scoped classification (stopping a single oversized-context request from poisoning the provider-wide circuit breaker / model lockout / connection cooldown) are both legitimate resilience bugs. I ran the full surface you touched — combo-context-window-filter, combo-breaker-429, combo/combo-target-exhaustion, diagnostics, combo-failure-log-message — 79/79 pass, ESLint clean on all 8 changed files.

One thing to flag before merge: there's another open PR (#7052) that fixes the exact same double-counting bug (#7039) in getKnownContextLimit, and it's more complete — it fixes both call sites (hasKnownCompatibleContextLimit and getTargetCompatibilityFailures), where your version only fixes the second one and keeps the old, still-buggy formula alive in the first via a 'legacy' fallback. We're merging #7052 first, then we'll rebase this branch on top and swap your getKnownContextOverflow to reuse #7052's fixed helper instead of carrying a second formula. Doesn't affect your new pre-flight-rejection or request-scoped-failure-classification logic — just a follow-up consistency cleanup during the rebase, we'll handle it.

[diegosouzapw]

Babysit summary — now green ✅

Base was 25 commits behind release/v3.8.49; merged the release tip in (clean, no conflicts). That merge is what surfaced the two real reds below — neither was pre-existing base-red.

Fixed — Fast Quality Gates (check:file-size) → 63966f50d
Two ratchet violations, both fixed by extraction (no baseline edits):

• comboStructure.ts: 826 > cap 800 (new-file cap) → extracted getKnownContextOverflow + its KnownContextOverflow type into a new leaf open-sse/services/combo/knownContextOverflow.ts (60 LOC). comboStructure.ts → 784.
• chat.ts: 1806 > frozen 1796 → extracted the skipConnectionDisable predicate out of handleSingleModelChat into comboPredicates.ts::shouldSkipConnDisable (pure, unit-testable), and consolidated the two new combo-failure imports into one line. chat.ts → 1790 (below the frozen 1796 — the ratchet only shrinks).

Fixed — Unit Tests fast-path (1/4) → 63966f50d
A real bug in this PR, not a flake. combo-routing-engine.test.ts:3051 (#3587 non-reasoning model does not get max_tokens buffer) went red because estimateRequestInputTokens counted a caller-omitted messages: [] as real content — JSON.stringify of the empty array charged ~4 phantom "structural" tokens toward the estimate. With max_tokens: 4096 against a 4096-context target (the common limit_input === limit_output === limit_context config) that pushed requiredContextTokens to 4100 > 4096, so the PR's new overflow check rejected a request that has no input at all. Empty arrays/objects no longer count as estimable content.

• TDD-verified: added #7177 an empty messages array is not counted as real content at an exact-boundary limit to combo-context-window-filter.test.ts — confirmed it fails on the unfixed code ({estimatedInputTokens: 4, requiredContextTokens: 4100, maxKnownContextTokens: 4096} instead of null) and passes after.

dast-smoke — infra flake, not a code failure: the Build CLI bundle step was cancelled by a runner shutdown signal. Re-ran; passes (9m9s). No code change.

Local validation (beyond CI): check:file-size, check:complexity-ratchets (complexity 2056 = baseline, cognitive 890 = baseline — both unchanged), check:duplication (4.53%), check:cycles, check:deps, check:known-symbols, check:test-discovery, check:mutation-test-coverage, check:build-scope, check:pack-policy, check:error-helper, check:db-rules, check:public-creds, check:route-guard-membership, check:any-budget:t11, typecheck:core, scoped ESLint. Full combo test surface: 783/783 pass.

Review threads — 1 open (gemini-code-assist, medium: null-guard on getKnownContextLimit). Replied with evidence that it is a false positive (getResolvedModelCapabilities has a non-nullable declared return type and exactly one return, an object literal; unknown models already fail open via the existing != null guards, covered by a test). Not applied, not resolved — left for the maintainer.

⚠️ For maintainer review — scope note, not a blocker: REQUEST_SCOPED_UPSTREAM_ERROR_CODES includes upstream_empty_response / upstream_response_failed alongside context_length_exceeded. That means malformed/empty-200 upstream responses now also skip connection cooldown and the provider breaker — a resilience-policy change broader than the PR title ("reject known context overflow") implies. It reads as intentional and consistent with RESILIENCE_GUIDE (a malformed body is a request/model signal, not provider health), and #5085 already carves out empty-content 502s at the combo layer — but it is a policy call, so flagging it explicitly.

No policy collision with the open GPT-5.x contract PRs (#7012/#7101/#7242) or the reasoning-summary pair (#7095/#7176): the only shared file is chatCore.ts, and #7101 edits the request-translation path (~L2093) while this PR edits the response/malformed path (~L4035) — disjoint regions, different root causes.

Authorship preserved (@JxnLexn). No tests weakened, no CI/baseline edits, no --no-verify. All checks green — ready for human review & merge. Not merging.

[diegosouzapw]

Thanks @JxnLexn! Merged into release/v3.8.49 after combined merge-train validation (static gates + tests + vitest green on the merged tree). Where quality gates flagged growth we decomposed/extracted inside your branch keeping you as author — including renumbering the reasoning-routing migration slot and the ProviderDetailPageClient rebaseline annotation.