* fix(api): reach DeepSeek V4's native max reasoning tier
DeepSeek V4 accepts reasoning_effort low | high | max, defaults to high,
and maps medium and xhigh down to high
(https://api-docs.deepseek.com/api/create-chat-completion; the upstream 400
on an invalid value enumerates none, minimal, low, medium, high, xhigh, max).
OmniRoute's canonical vocabulary is none|low|medium|high|xhigh, where `max`
is an alias collapsing onto `xhigh`. DeepSeek then maps `xhigh` back down to
`high`, so a client sending {"effort":"max"} silently got high — the model's
top reasoning tier was unreachable through the canonical field, and the
catalog never advertised `max` as an available tier.
Mirror the existing extendCodexGpt56EffortValues precedent: expose the
provider-native tier for these models only, without widening the global
request vocabulary. CANONICAL_EFFORT_VALUES and normalizeEffort() are
unchanged, so every other provider keeps collapsing max -> xhigh.
Scoped to the native `deepseek`/`ds` provider. Routed namespaces that merely
carry "deepseek" in the id (openrouter/deepseek/..., tllm/deepseek_v4,
oc/deepseek-v4-flash-free) terminate at a different upstream whose effort
vocabulary we do not control, so they keep the canonical behavior. The
provider is not resolved yet where the canonical params are folded in
(chat.ts), so the check also accepts a `<prefix>/<model>` id.
An explicit client reasoning_effort / reasoning.effort still wins, as before.
Covered by tests/unit/deepseek-native-max-effort.test.ts: 4 of its 6 cases
fail without this change.
* chore(changelog): add fragment for #10230
* fix(codex): preserve GPT-5.6 reasoning contract
* fix(vscode): expose Responses text models
* fix(codex): keep GPT-5.6 limits through discovery
* fix(ci): extract isUsableChatModel helpers to satisfy complexity ratchet
Splitting the supported_endpoints/output_modalities guard clauses into
excludesChatAndResponsesEndpoints() / excludesTextOutputModality() drops
isUsableChatModel's cyclomatic complexity from 16 to under the ratchet's
max of 15 (complexity-ratchets gate: 2057 -> 2056, back at baseline).
Behavior is unchanged; existing vscode/codex route tests cover it.
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
* fix(codex): merge capacity limits conservatively (smaller of live vs pinned wins)
Resolve the #7012 catalog-merge policy collision: instead of the pinned
GPT-5.6 contract always winning for a fixed set of model ids, capacity
limits (inputTokenLimit/outputTokenLimit) now merge via
mergeCapacityLimitConservatively — Math.min(pinned, live) when both are
present, so OmniRoute never promises more context than the account can
actually serve. All other overlapping fields still take the live value
unconditionally.
Guard tests cover both directions (pinned smaller wins / pinned larger
loses) at the route level and via an isolated helper-level unit test.
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
---------
Co-authored-by: Xiangzhe <xz-dev@users.noreply.github.com>
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
* feat(providers): add GPT-5.6 model family
* fix(chatgpt-web): resume temporary chat handoffs
* fix(codex): auto-merge discovery, filter denylist, revalidate on lifecycle
Restore live/GitHub auto-merge for Codex catalogs, drop models via
explicit denylist (GPT-5.4 family), and run scrub+live re-sync once on
first-start, app upgrade, or setup completion. Success log:
kill deprecated models complete.
* fix(codex): preserve live catalog reconciliation
Expose remote-only Codex models without dropping user custom entries, and complete lifecycle revalidation only after a successful internal sync. Keep credentialed self-fetches pinned to the active dashboard listener.
---------
Co-authored-by: backryun <backryun@daonlab.local>
