A Chat-Completions client can only express reasoning via the top-level
reasoning_effort hint and has no way to request a reasoning summary. When
that hint is promoted to the Responses API's reasoning.effort, the
upstream returns an empty summary and downstream chat clients see no
thinking stream (encrypted reasoning only).
Default reasoning.summary "auto" plus include ["reasoning.encrypted_content"]
on the effort-only path so the summary actually streams back to the chat
client, mirroring the Codex executor's ensureCodexReasoningSummary. An
explicit reasoning object from a Responses-shaped client is preserved
untouched, and reasoning_effort "none" is left without a summary.
Adds regression tests for the effort-only default, the none case, and
keeps the existing explicit-reasoning-object behavior unchanged.
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
A structural engine (ccr / session-dedup) that finds nothing to compress
returns the body unchanged. That no-op was mishandled three ways — the
code-level root cause of the #6465–#6493 "0% savings, no reason" symptom class:
A. Inflation guard mislabelled a no-op as inflation. guardPipelineInflation
used `compressedTokens >= originalTokens`, so an unchanged body
(compressedTokens === originalTokens) tripped the guard, setting
fallbackApplied=true and emitting a misleading "did not shrink; reverted
to original" warning. Changed to strict `>` — only a strictly larger
output is inflation; equality is a no-op. Genuine inflation still reverts.
B. Disabled-engine skip was silent and asymmetric with the breaker skip. Both
stacked loops (sync + async) skipped a registry-disabled engine with a bare
`continue`, recording no validationWarning — while the sibling breaker-open
branch does. Both loops now add
`${engine}: skipped (engine disabled in registry)`, mirroring the breaker branch.
C. No-op engine lost its identity in engineBreakdown. mergeStackStep
early-returned on null stats, pushing no breakdown entry, so
ensureEngineBreakdown synthesized a generic "stacked" 0% node. It now records
a zero-savings entry keyed on the engine that actually ran, preserving identity.
Tests: tests/unit/compression-noop-guard.test.ts covers A (equal-token no-op not
inflated; strictly-larger still reverts), B (disabled skip surfaces a "disabled"
warning), and C (no-op engine keeps its own id in the breakdown). Updated the
existing inflation-guard test whose net-zero case encoded the old buggy behaviour,
and switched its wire test to object-form pipeline steps so the intended engine runs.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
extractUsageFromResponse() and normalizeUsage() used Number(x)
coercion for cost_in_usd_ticks, which silently turned null/""
into 0 -- accepted downstream as a valid $0 exact cost instead of
falling back to the token-based estimate. Both call sites now
require typeof === "number" && Number.isFinite && >= 0.
Rebased onto current release/v3.8.47 tip (already carries #6711)
and trimmed to just the incremental validation fix + 2 regression
tests, replacing the stale-base diff that re-added the whole
already-merged feature.
Co-authored-by: KooshaPari <koosha@phenotype.io>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(providers): scope nvidia NIM 404s to the single failing model (#6773)
The nvidia registry entry multiplexes 17 models from 9 different upstream
vendors (z-ai/, minimaxai/, deepseek-ai/, qwen/, mistralai/, stepfun-ai/,
moonshotai/, openai/, nvidia/) behind one connection, but was missing
passthroughModels: true — unlike 34 other multi-model registries
(modelscope, synthetic, kilo-gateway, etc). Without it, hasPerModelQuota
returns false for nvidia, so a 404 on a single stale/renamed model falls
through checkFallbackError's generic catch-all as a connection-wide
cooldown instead of being scoped to just that model, poisoning all 17
nvidia models for the cooldown window.
Add passthroughModels: true to the nvidia registry entry so 404/429s on
one model lock out only that model.
Regression test: tests/unit/nvidia-passthrough-models-6773.test.ts
* fix(quality): register nvidia passthrough test in stryker tap.testFiles
check-mutation-test-coverage.mjs --strict flagged
tests/unit/nvidia-passthrough-models-6773.test.ts as an unregistered
covering test for accountFallback.ts (Fast Quality Gates).
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
* fix(responses): escape literal control chars in tool call JSON; emit status=failed on upstream error #6785
Two bugfixes in the Responses API translator:
1. escapeJsonStringValues() sanitizes tool call arguments containing
literal 0x0A/0x0D/0x09 bytes (emitted by Gemma4 models) into valid
JSON \n/\r/\t escapes, preventing SSE framing corruption. Only
escapes inside JSON string contexts — already-escaped sequences
and structural JSON pass through unchanged.
2. sendCompleted() checks state.upstreamError and emits status="failed"
with error.code + error.message instead of silently hardcoding
status="completed" + error=null, so mid-stream errors (e.g. Gemini
503 after partial content) are properly surfaced to the client.
3. stream.ts: calls translateResponse(null,...) before controller.error()
so the translator can emit close events (reasoning item done,
response.completed) before the stream is terminated.
* test(boundary): fix ESLint no-explicit-any warnings and quality gates
Green the PR against release/v3.8.47 quality gates without weakening tests:
- Replace @typescript-eslint/no-explicit-any in the new boundary/gemma4
tests with proper interfaces (ResponseBody, ToolDef, ToolArgs, SseEvent
item accessors) — fixes the "No new ESLint warnings" gate.
- Split tests/unit/translator-resp-openai-responses.test.ts (1079 LOC) by
extracting the round-trip suite into a sibling file so both stay under
the 800-line test cap — fixes check:file-size.
- Rename the 5 live boundary tests to *.live.test.ts, gate them behind
RUN_BOUNDARY_LIVE=1, add a test:boundary:live npm script and register the
glob in check-test-discovery COLLECTORS — fixes check:test-discovery
(they hit a live remote and must never run unopted in CI).
Co-authored-by: Markus Hartung <mail@hartmark.se>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
* fix(sse): de-flake timing-sensitive combo cooldown/breaker tests (#6803)
Extracts 3 wall-clock-sensitive assertions (combo-quota-share cooldown
ceiling x2, circuit-breaker HALF_OPEN race) into tests/unit/serial/
(--test-concurrency=1, the repo's established remedy for this class of
test) and widens their margins, since a starved CI-runner event loop can
blow even a serialized test's timing window. Also adds an explicit 30s
vitest timeout to the MCP audit shutdown test, which had no override and
inherited vitest's 5000ms default.
Regression proof: reproduced RED locally under real devbox CPU
contention (2644ms/1796ms elapsed vs the old 1500ms ceiling, exactly the
reported failure mode); confirmed GREEN after the fix under the same
contention.
* fix(quality): register new serial timing tests + prune stale any-suppression count
- stryker.conf.json: add tests/unit/serial/combo-quota-share-cooldown-wait-timing.test.ts
and tests/unit/serial/combo-strategy-fallbacks-half-open-timing.test.ts to
tap.testFiles so their mutant kills count for accountFallback.ts and
circuitBreaker.ts (PR #6897 added these files but didn't register them).
- eslint-suppressions.json: combo-strategy-fallbacks.test.ts's no-explicit-any
suppression count was stale (35) after this PR trimmed 2 any-usages out of
the file when extracting the half-open timing test; corrected to 33.
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
* fix(oauth): embed Trae OAuth client_id via resolvePublicCred (Hard Rule #11)
* fix(quality): register tests/unit/trae-publiccred.test.ts in stryker tap.testFiles
The mutation test-coverage gate (check:mutation-test-coverage --strict) flags
new covering unit tests that mutate open-sse/utils/publicCreds.ts but aren't
listed in stryker.conf.json's tap.testFiles, so their mutant kills wouldn't
count. Register the new test file alphabetically.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
---------
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(sse): stop combo path tripping whole-provider breaker on plain 429
The combo path recorded a whole-provider circuit-breaker failure for a
plain rate-limit 429, opening the breaker after N consecutive 429s and
blocking every account+model on that provider. This contradicts the
single-model path and the documented RESILIENCE_GUIDE policy.
- Single-model path uses PROVIDER_BREAKER_FAILURE_STATUSES =
Set([408, 500, 502, 503, 504]) (src/sse/handlers/chat.ts:206) — 429 excluded.
- Combo path gated shouldRecordProviderBreakerFailure on isProviderFailureCode
(accountFallback.ts), whose PROVIDER_FAILURE_ERROR_CODES INCLUDES 429 for
connection-cooldown scope — so a plain 429 wrongly tripped the whole-provider
breaker.
Fix scopes tightly: comboPredicates now tests a local
PROVIDER_BREAKER_FAILURE_STATUSES set mirroring the single-model constant
(429 excluded), instead of isProviderFailureCode. The shared
isProviderFailureCode / PROVIDER_FAILURE_ERROR_CODES are deliberately left
untouched — they drive connection-cooldown / model-lockout logic where 429
must still count. A genuine quota/token-limit terminal 429 is handled
elsewhere; only the whole-provider breaker-recording gate changes.
Adds tests/unit/combo-breaker-429.test.ts covering the 429 exclusion,
the 408/5xx inclusion, and the sameProviderNext / skipProviderBreaker
suppression paths.
* test(quality): register combo-breaker-429.test.ts in stryker tap.testFiles
Fast Quality Gates' mutation-coverage drift check flagged this PR's new
covering test for comboPredicates.ts as unregistered.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
---------
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(sse): combo model lockout honors parsed upstream quota reset (#6863)
The combo failure path recorded model lockouts from checkFallbackError's
cooldownMs only, discarding quotaResetHintMs — the ungated channel that
carries a parsed upstream quota reset (e.g. Antigravity 429 "Resets in
92h27m28s"). With OAuth profiles defaulting useUpstreamRetryHints=false,
the lockout fell back to the base cooldown (seconds), so quota-dead
accounts were re-walked serially by every combo request for days
(measured 122s per request, 494s worst case in #6863).
Thread max(cooldownMs, quotaResetHintMs) into selectLockoutCooldownMs at
both combo lockout sites, mirroring the single-model path pattern in
src/sse/services/auth.ts (v3.8.43). All three resilience fences are
preserved: useUpstreamRetryHints still gates connection cooldowns, the
hint only affects model-scope lockouts, and combo 429s remain
non-persistent.
TDD: tests/unit/combo-lockout-quota-reset-6863.test.ts fails on base
(lockout 5000ms) and passes with the fix (~92.5h).
* test(sse): tighten #6863 lockout assertion to parsed-reset bounds; prettier pass
Assert remainingMs falls within (parsedResetMs - 5s, parsedResetMs] so a
hardcoded long cooldown cannot satisfy the regression test. Also apply
Prettier to both changed files (includes one pre-existing formatting fix
in handleRoundRobinCombo picked up by --write).
* fix(sse): align combo lockout hint selection with single-model path; register test in mutation gate
Adopt review feedback: replace Math.max(cooldownMs, quotaResetHintMs) with
the auth.ts pattern (usedUpstreamRetryHint ? cooldownMs : quotaResetHintMs)
so a parsed reset SHORTER than the fallback cooldown wins too — e.g. the
subscription-quota branch returns a 1h fallback while the body says
"resets in 45m"; max() would over-lock by 15 minutes.
Add a regression test for the short-reset case (fails against the max()
variant) and register the new test file in stryker.conf.json tap.testFiles
to satisfy check:mutation-test-coverage --strict.
* chore(quality): register cliproxyapi dispatch test in mutation gate
tests/unit/cliproxyapi-model-mapping-dispatch.test.ts landed on
release/v3.8.47 via #6903 without a tap.testFiles entry, so
check:mutation-test-coverage --strict fails on the branch tip and on
every PR merge ref. Register it so the gate is green again.
---------
Co-authored-by: judy459 <JUDYZHU459@outlook.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(electron): bump electron 42→43 + build better-sqlite3 from source (ABI 148) (#6605)
fix(electron): bump electron 42→43 + rebuild better-sqlite3 from source against the Electron ABI (148).
Electron 43 raises NODE_MODULE_VERSION to 148; better-sqlite3@12.11.1 has no electron-v148 prebuild, so the packaged app died with 'Nenhum driver SQLite disponível'. prepare-electron-standalone now compiles better-sqlite3 from source against the electron headers into build/Release (where 'bindings' resolves it). Validated by Electron Package Smoke (green) + local (node_register_module_v148).
Supersedes #6378. (--admin: the only reds are SonarQube/SonarCloud failing on a coverage-report artifact digest-mismatch — a GitHub Actions infra flake, not this diff; Sonar is green on main and the diff touches only the electron build.)
* deps: bump the development group across 1 directory with 6 updates (#6588)
deps: bump the development group (6 updates). Rebased onto current main; all checks green after the electron-smoke fix (#6605).
* fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump (#6620)
fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump.
undici 8.6+ changed ProxyAgent to forward plain-HTTP via request-proxy instead of CONNECT, breaking OAuth refresh through a connection proxy (501). proxyDispatcher now passes proxyTunnel:true. Validated: Unit Tests 3/8 (the OAuth-proxy test) green, new regression test green (fails without the fix on undici 8.7), SonarQube green.
Supersedes #6380. (--admin: the only red is Electron Package Smoke failing on a next-build artifact 'digest-mismatch' — a GitHub Actions infra flake corrupting the asar ('file data stream has unexpected number of bytes'); the better-sqlite3 rebuild itself succeeded (gyp ok) and the electron path is unchanged from #6605 which passed the smoke. Not this diff.)
* feat(provider): add OpenVecta AI inference gateway
OpenVecta (https://openvecta.com/) is an OpenAI-compatible AI inference
gateway hosting LLMs (GLM, Claude, DeepSeek, GPT OSS, Llama, Kimi,
Nemotron...) plus text-embedding-* models behind a single Bearer key.
Wiring (7 integration points):
- src/shared/constants/providers/apikey/inference-hosts.ts: catalog entry
- open-sse/config/providers/registry/openvecta/index.ts: registry w/ 9 seed LLMs
- open-sse/config/providers/index.ts: wire into REGISTRY
- src/app/api/providers/[id]/models/discovery/providerModelsConfig.ts: live /v1/models URL
- src/app/api/providers/[id]/models/discovery/providerSets.ts: NAMED_OPENAI_STYLE_PROVIDERS
- public/providers/openvecta.svg: brand icon
- tests/unit/openvecta-provider-registration.test.ts: regression guard (6 tests, all pass)
No executor needed — buildOpenAiCompatibleRegistryEntry wires
format=openai / executor=default / authType=apikey / authHeader=bearer.
Live catalog discovery uses the existing NAMED_OPENAI_STYLE_PROVIDERS
path (live /v1/models fetch + registry seed as offline fallback).
Validation:
- npm run typecheck:core clean
- npm run typecheck:noimplicit:core 4 errors in unchanged files (combo.ts, cliRuntime.ts); 0 in new code
- npm run lint clean
- node --import tsx/esm --test tests/unit/openvecta-provider-registration.test.ts 6/6 pass
- sibling tests/unit/openai-style-providers-4239-4155-3841.test.ts 18/18 pass (no regression)
* chore(merge): drop unrelated main-drift from PR fork + fix count/golden drift
The fork branch predated main's electron 42→43 bump (#6605) and several other
package.json/lockfile churn; those files are unrelated to the OpenVecta
provider addition and were reintroducing an older/stale state (version
3.8.46, electron 42, older bun/eslint-config-next) that broke the Electron
Package Smoke check. Restored package.json, package-lock.json,
electron/package.json, electron/package-lock.json, and
scripts/build/prepare-electron-standalone.mjs to match
origin/release/v3.8.47.
Also updates the two provider-count assertions (166->167) and regenerates
the translate-path golden snapshot to account for the new openvecta entry.
Co-authored-by: hajilok <120608486+hajilok@users.noreply.github.com>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
* fix(electron): bump electron 42→43 + build better-sqlite3 from source (ABI 148) (#6605)
fix(electron): bump electron 42→43 + rebuild better-sqlite3 from source against the Electron ABI (148).
Electron 43 raises NODE_MODULE_VERSION to 148; better-sqlite3@12.11.1 has no electron-v148 prebuild, so the packaged app died with 'Nenhum driver SQLite disponível'. prepare-electron-standalone now compiles better-sqlite3 from source against the electron headers into build/Release (where 'bindings' resolves it). Validated by Electron Package Smoke (green) + local (node_register_module_v148).
Supersedes #6378. (--admin: the only reds are SonarQube/SonarCloud failing on a coverage-report artifact digest-mismatch — a GitHub Actions infra flake, not this diff; Sonar is green on main and the diff touches only the electron build.)
* deps: bump the development group across 1 directory with 6 updates (#6588)
deps: bump the development group (6 updates). Rebased onto current main; all checks green after the electron-smoke fix (#6605).
* fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump (#6620)
fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump.
undici 8.6+ changed ProxyAgent to forward plain-HTTP via request-proxy instead of CONNECT, breaking OAuth refresh through a connection proxy (501). proxyDispatcher now passes proxyTunnel:true. Validated: Unit Tests 3/8 (the OAuth-proxy test) green, new regression test green (fails without the fix on undici 8.7), SonarQube green.
Supersedes #6380. (--admin: the only red is Electron Package Smoke failing on a next-build artifact 'digest-mismatch' — a GitHub Actions infra flake corrupting the asar ('file data stream has unexpected number of bytes'); the better-sqlite3 rebuild itself succeeded (gyp ok) and the electron path is unchanged from #6605 which passed the smoke. Not this diff.)
* chore(deps): bump github/codeql-action/analyze from 4.36.3 to 4.37.0
Bumps [github/codeql-action/analyze](https://github.com/github/codeql-action) from 4.36.3 to 4.37.0.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](54f647b7e1...99df26d4f1)
---
updated-dependencies:
- dependency-name: github/codeql-action/analyze
dependency-version: 4.37.0
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
When no explicit judgeModel is configured, the judge defaulted to panel[0]
before fan-out and was never reassigned. If panel[0] failed fan-out (timeout /
rate-limit / dropped straggler → it lands in `failures`, not `answers`), the
multi-answer synthesis path still dispatched the judge to that dead panel[0],
erroring the whole fusion request even though a quorum of other panel members
succeeded — exactly the failure fusion exists to tolerate.
Resolve the effective synthesis judge from a survivor when no explicit judge is
set: prefer panel[0] only when it survived, otherwise the first surviving
answer. An explicitly configured judge is still honored unchanged (operator
intent), and the answers.length===0 (503) and single-survivor branches keep
their existing semantics.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
TOTAL_MCP_TOOL_COUNT in open-sse/mcp-server/server.ts summed collection sizes
additively, double-counting tools registered in more than one collection.
The agent-skills trio (omniroute_agent_skills_list/get/coverage) is
intentionally defined in both MCP_TOOLS (schemas/tools.ts) and
agentSkillTools (tools/agentSkillTools.ts), inflating the reported count
from 96 unique tools to 99.
Replace the additive sum with countUniqueMcpTools() (new
open-sse/mcp-server/toolCount.ts), which unions all collection tool
names into a Set before counting, so any future overlap self-corrects
instead of double-counting.
Regression test: tests/unit/mcp-tool-count-dedup-6854.test.ts
Two related root causes in the stacked compression pipeline:
- #6479/#6491: a dispatched step whose engine legitimately finds nothing
eligible (session-dedup with no repeated blocks, ccr below its min-chars
threshold) returns `{ stats: null }`. `mergeStackStep()` silently dropped
that step from `engineBreakdown` with zero trace — no warning, no error.
Now records a `"<engine>: skipped (no eligible content)"` validation
warning for any null-stats step, covering every engine that follows this
convention (session-dedup, ccr, headroom, relevance, llm, llmlingua,
ionizer, readLifecycle), not just the two reported.
- #6480: `finalizeStackedResult` ran the aggregate `guardPipelineInflation`
check unconditionally, even when the loop-level `compressed` flag stayed
false (no step ever advanced `currentBody`). Since tokens are trivially
equal when nothing ran, the guard mislabeled a genuine no-op as
`fallbackApplied: true` with a misleading "reverted to original" warning.
Extracted the guard into `applyStackedInflationGuard()` in
`pipelineGuards.ts` (keeps `strategySelector.ts` under its frozen line
budget) and gated it on `compressed === true`.
Also fixes `compression-pipeline-inflation-guard.test.ts`'s wire test,
which passed a bare engine-id string to the pipeline; `normalizePipelineStep()`
only recognizes a fixed set of built-in string aliases and silently
downgrades any other string to `{ engine: "caveman" }`, so the test's
custom inflating engine was never actually exercised. Passing a step object
restores the test's original intent.
New regression tests: tests/unit/compression/repro-6479-6491-null-stats-silent-drop.test.ts,
tests/unit/compression/repro-6480-noop-guard-misfire.test.ts.
combo.ts's isContextOverflow400() guard required the literal word
'context' in the 400 error body before letting a combo fall through to
the next target. Kimi's exact wording ('Your request exceeded model
token limit: 262144 (requested: 308458)') never says 'context', so the
guard misclassified it as a body-specific error and halted the whole
combo instead of trying the next (larger-context) target.
accountFallback.ts's CONTEXT_OVERFLOW_PATTERNS already recognized this
wording one layer below (via checkFallbackError -> shouldFallback), so
the two independently-maintained classifiers disagreed and the
stricter one won. Export CONTEXT_OVERFLOW_PATTERNS from
accountFallback.ts and reuse it inside combo.ts's
isContextOverflow400() so both layers share a single source of truth.
Regression test: tests/unit/repro-6637-kimi-token-limit.test.ts
(RED on unfixed code -> GREEN after the fix). Existing #4519 guard
tests (tests/unit/combo-param-validation-fallback-4519.test.ts) still
pass, including the negative case that a genuinely body-specific 400
is NOT misclassified as overflow.
* feat(providers): add Z.ai Web free web-cookie provider (#4056)
New zai-web web-session provider drives the free chat.z.ai consumer
chat UI via a pasted browser cookie, distinct from the existing
API-key zai/glm/glm-cn/glmt providers (api.z.ai). ZaiWebExecutor posts
to chat.z.ai/api/chat/completions with the cookie forwarded both as
Cookie and Authorization: Bearer <token>, and normalizes both z.ai's
internal delta_content/phase SSE envelope and a pass-through
OpenAI-shaped choices[].delta frame into standard chat-completion
chunks.
Registered in WEB_COOKIE_PROVIDERS, WEB_SESSION_CREDENTIAL_REQUIREMENTS,
the provider registry (GLM-4.6/4.5/4.5V models), the executor factory,
and tokenExtractionConfig.ts for in-app cookie capture.
* fix(providers): regenerate translate-path golden for zai-web + reduce cognitive complexity
* fix(providers): rename ZaiWebExecutor.buildHeaders to avoid incompatible BaseExecutor override
* chore(merge): re-sync with release/v3.8.47; move changelog bullet to changelog.d fragment (merge-storm proof)
* feat(usage): surface Antigravity weekly quota alongside the 5-hour window (#4017)
Antigravity enforces both a 5-hour and a weekly usage limit, but the agy/antigravity
quota widget only exposed the 5-hour window. The weekly limit isn't in the per-model
retrieveUserQuota response already fetched — it lives in a separate, undocumented
retrieveUserQuotaSummary RPC that groups models into families (Gemini Models, Claude
and GPT models) with one weekly bucket per family.
Adds a self-contained usage/antigravityWeeklyQuota.ts leaf: a cached, best-effort
fetch of that RPC + a pure parser that extracts the weekly-labeled bucket per group
(window inferred from bucketId/displayName text, matching the reverse-engineered
shape documented by third-party Antigravity clients) into gemini_weekly/
claude_gpt_weekly quota entries, merged into the existing quotas map the widget
already renders generically. A failed/unavailable RPC never affects the existing
per-model quotas.
Live VPS validation attempt (192.168.0.15, real antigravity account): both
retrieveUserQuota and retrieveUserQuotaSummary currently return 429
RESOURCE_EXHAUSTED for that account, so the live response shape could not be
captured directly. The parser was instead validated via TDD against the bucket
shape documented by CodexBar (steipete/CodexBar), a third-party Antigravity client
that reverse-engineered the same RPC, and is defensive against both response
envelopes it has observed (top-level groups[] and nested quotaSummary.groups[]).
* chore(merge): re-sync with release/v3.8.47 (restore CHANGELOG, keep own bullet)
* chore(merge): re-sync with release/v3.8.47; move changelog bullet to changelog.d fragment (merge-storm proof)
* feat(codex): echo requested effort-suffixed model id in Responses payloads (#3697)
Codex CLI compatibility shim: the Responses API response.created/
response.in_progress/response.completed payloads now carry a `model`
field (previously absent), and for Codex-CLI-originated requests it
echoes the client-requested effort-suffixed model id (e.g.
gpt-5.5-xhigh) instead of the bare upstream id (gpt-5.5), so the Codex
CLI status line/model button shows the active reasoning effort.
- openai-responses.ts translator threads the upstream model into the
Responses event objects (additive, omitted when unknown).
- New isCodexOriginatedHeaders() (codexIdentity.ts) reuses PR #3481's
originator/User-Agent detection, header-based so it still fires when
a combo routes codex/gpt-5.5-xhigh to a non-codex upstream.
- chatCore's existing opt-in #1311 echoModel pipeline now also fires
automatically for Codex clients on the Responses API, regardless of
the echoRequestedModelName setting.
- responseModelEcho.ts now also rewrites the nested response.model
field the Responses API uses (previously only top-level model).
- /v1/models keeps returning models: [] for Codex (unchanged, #3481).
Regression guard: tests/unit/codex-effort-model-echo-3697.test.ts.
Closes#3697
* chore(merge): re-sync with release/v3.8.47 (restore CHANGELOG, keep own bullet)
* chore(merge): re-sync with release/v3.8.47; move changelog bullet to changelog.d fragment (merge-storm proof)
* feat(routing): per-model web-search interception rule (#3384)
Adds a per-provider/per-model interceptSearch rule (src/lib/db/interceptionRules.ts,
key_value namespace interception_rules) that overrides the existing native
web-search bypass defaults (Codex/Gemini/Claude->Claude passthrough) in
webSearchFallback.ts. Wired at the existing prepareWebSearchFallbackBody() call
site in chatCore.ts. Resolution precedence: per-model rule > provider-level rule
> existing native-bypass defaults.
This lands Phase 1-2 of the plan (rule store + search interception). Web-fetch
interception and the dashboard UI toggle are tracked as follow-up phases.
* fix(db): register interceptionRules in localDb re-export layer (db-rules gate)
* fix(db): renumber interception_rules migration 119→120 (collision with model_capability_overrides)
OmniRoute's calculateCost() always estimated request cost from token
counts x static pricing, discarding xAI's exact provider-reported cost
when present. xAI's chat-completions usage object reports the precise
billed cost via cost_in_usd_ticks (docs.x.ai/developers/cost-tracking
and the API reference's usage schema: "TICKS_IN_USD_CENT: i64 =
100_000_000" => 1e10 ticks/USD, e.g. 37756000 ticks ~= $0.0038).
calculateCost()/computeCostFromPricing() now short-circuit to this
exact figure when present -- before any pricing DB lookup, so it also
works for models without a local pricing row -- and still fall back to
the token-based estimate when it is absent. The field is threaded
through both the streaming (extractUsage/normalizeUsage) and
non-streaming (extractUsageFromResponse) usage-extraction paths.
Corrected divisor vs upstream: the upstream PR used /1e12 (a 100x
under-report, e.g. reporting $0.00123 as the doc's $0.123 example);
this port uses the doc-verified /1e10 instead, confirmed against both
the cost-tracking guide and the API reference's usage-object schema.
Inspired-by: https://github.com/decolua/9router/pull/2453
Co-authored-by: ryanngit <74137224+ryanngit@users.noreply.github.com>
Auto-combo transparency + budget controls: the engine's budgetCap enforcement
always degraded to the globally cheapest candidate when every candidate
exceeded the cap - silently overspending instead of respecting the cap.
- engine.ts: budgetFallback "cheapest" (default, legacy) | "strict"
(BudgetExceededError when no candidate fits budgetCap)
- requestControls.ts: X-OmniRoute-Budget-Fallback header +
resolveRequestAutoControls() consolidating mode/budget/fallback parsing
- resolveAutoStrategy.ts / autoConfig.ts: thread combo-level
config.budgetFallback and catch BudgetExceededError into an HTTP 402
- chat.ts: switch to the consolidated resolveRequestAutoControls() helper
(net line reduction, stays under the frozen file-size baseline)
Regression guard: tests/unit/auto-combo-budget-fallback-3470.test.ts
* fix(kiro): route Amazon Q runtime by profileArn region for cross-region IdC
Enterprise AWS IAM Identity Center accounts whose IdC instance lives outside the two
Amazon Q Developer profile regions (us-east-1 / eu-central-1) - e.g. eu-north-1
(Stockholm), start URL https://d-XXXX.awsapps.com/start - showed no limits and returned
502 on every request.
Root cause: the backend used the IdC/OIDC token region (providerSpecificData.region, e.g.
eu-north-1) for every CodeWhisperer runtime call, hitting q.eu-north-1.amazonaws.com - a
host that does not exist as a Q Developer runtime endpoint. Per AWS docs ("Supported
Regions for the Q Developer console and Q Developer profile"), the Q Developer *profile*
(which produces the profileArn and hosts generateAssistantResponse / GetUsageLimits /
ListAvailableModels / ListAvailableProfiles) is only hosted in us-east-1 and eu-central-1,
regardless of the IdC region; "data is stored in the Region where you create the Amazon Q
Developer profile."
Fix (new open-sse/services/kiroRegion.ts) decouples the two regions:
- providerSpecificData.region stays the IdC/OIDC region, used ONLY for
oidc.{region}.amazonaws.com token mint/refresh.
- The runtime region is derived from the profileArn (resolveKiroRuntimeRegion):
profileArn region -> a valid stored profile region -> us-east-1. A stored IdC region
that is not a Q profile region (eu-north-1) is ignored for runtime.
- Profile discovery (discoverKiroProfileArnAcrossRegions) probes the Q profile regions
(EU IdC -> eu-central-1 first) with the cross-region SSO token instead of q.{idcRegion}.
Wired into: executors/kiro.ts (generateAssistantResponse targets the profile region),
services/usage/kiro.ts (getKiroUsage multi-region discovery + profileArn runtime region so
Limits resolves), services/kiroModels.ts (ListAvailableModels), and
src/lib/oauth/providers/kiro.ts (login-time postExchange profile discovery).
Adds tests/unit/kiro-idc-cross-region.test.ts (15 cases). All Kiro suites pass (60 tests).
* fix(kiro): probe the IdC region too during profileArn discovery (any IdC region)
Make profile discovery general for an IdC in ANY of the ~30 IdC-supported AWS regions
(us-west-2, ap-southeast-2, me-central-1, af-south-1, ...), not just eu-north-1.
buildKiroProfileDiscoveryRegions now probes the two documented Q Developer profile regions
FIRST (us-east-1 / eu-central-1, EU-first for EMEA IdC regions to cut latency), then appends
the IdC/stored region itself as a forward-compatible fallback: if AWS ever co-locates the
profile with the IdC or expands the profile-region list, a same-region probe still finds it.
Probing a region with no profile simply returns nothing and we fall through. The profileArn's
own region remains authoritative for every runtime call (resolveKiroRuntimeRegion), so a
newly-issued ARN in any region is honored automatically.
Adds ap-southeast-2 (APAC) cross-region coverage and updates the discovery-order tests.
---------
Co-authored-by: artickc <artur1992123@mail.ru>
* fix(combo): clamp reasoning buffer to model output cap
* fix(routing): preserve near-cap reasoning max tokens
* fix(routing): getExplicitModelOutputCap falls through to registry cap on non-numeric synced limit_output
getExplicitModelOutputCap short-circuited to null whenever a synced
capability row existed, even if that row's limit_output was not a number
(models.dev commonly omits it). That silently disabled the reasoning-token
buffer clamp for any model with a synced row lacking an output limit.
Now only return the synced value when it IS a number; otherwise fall
through to registryModel.maxOutputTokens / spec.maxOutputTokens, matching
the ??-chain precedence already used by getResolvedModelCapabilities().
Adds a standalone regression test (proves the fallthrough returns the real
registry cap, not null) and hardens the #6274 fixture id so its no-output-cap
case does not prefix-match the real glm-5.2 static spec.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* chore(stryker): register ollama-quota covering tests (release drift from merge burst)
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(lmarena): modernize Arena web provider + static Direct-chat catalog
Update the lmarena provider for arena.ai (product rebranded from LMArena):
- Route chat via arena.ai create-evaluation with Chrome TLS impersonation
(tls-client-node) and optional browser-minted recaptchaV3Token.
- Seed Text+Search (48) into the chat registry; seed Image (27) only into
IMAGE_PROVIDERS. Disable live HTML model discovery; resolve public names to
Arena UUIDs from the static TypeScript allowlist (no scrape JSON in-repo).
- Soft-exclude 404/502 model ids; slow/stop bulk test-all probes for this provider.
- Do not fold IMAGE_PROVIDERS/video specialty into the chat provider catalog when
a chat registry already exists (lmarena/openai/xai).
- Display name Arena (Free); keep wire id `lmarena` / alias `lma` for back-compat.
- Theme-aware provider icons: arena-light.svg / arena-dark.svg.
- Preserve split Supabase SSR cookie reconstruction for arena-auth-prod-v1.*.
* fix(providers): align provider-models-route test fixture + regen provider reference
Fold the topaz image-only catalog entry's apiFormat/supportedEndpoints
into the local-catalog test fixture (route now tags media-only
providers per the lmarena PR's staticModels.ts change), regenerate
PROVIDER_REFERENCE.md against the merged release providers.ts, and add
the changelog fragment for #6280.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* test: align web-cookie fallback suite — lmarena now has a registry entry (probe path)
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* feat: change default LIVE_WS_PORT from 20129 to 20132
Update the default WebSocket port for the live dashboard server from 20129 to 20132 across all configuration files, documentation, code comments, and tests. Also consolidate OMNIROUTE_DISABLE_LIVE_WS and OMNIROUTE_ENABLE_LIVE_WS into a single OMNIROUTE_ENABLE_LIVE_WS flag. Wire the live WebSocket server to start in-process via instrumentation-node.ts.
* feat: clarify NEXT_PUBLIC_LIVE_WS_PUBLIC_URL path usage and derive upgrade path from URL
Update .env.example and ENVIRONMENT.md to document that the pathname portion of NEXT_PUBLIC_LIVE_WS_PUBLIC_URL (e.g. /live-ws) is used as the WebSocket upgrade path by the dev proxy, handshake response, and client connection logic.
Extract deriveLiveWsPath() into shared/utils/wsPath.ts and wire it through:
- src/app/api/v1/ws/route.ts — handshake response path field
- src/hooks/useLiveDashboard.ts — build
* fix: use the standard URL API to safely parse and update the effectiveWsUrl
* build(docker): expose live WebSocket server port and configure CORS origins
Add LIVE_WS_PORT (20132), LIVE_WS_HOST (0.0.0.0), and LIVE_WS_ALLOWED_ORIGINS environment variables to all Docker Compose profiles and expose the WebSocket port mapping. Prevent infinite self-loop in standalone-server-ws.mjs by skipping proxy when the server itself is running on the LiveWS port.
* docs(env): fix comment formatting for HOST and HOSTNAME variables
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* feat(resilience): weekly-429 cooldown for fetcher-less providers (#3709)
Ollama Cloud free-tier accounts have a hard WEEKLY request cap. On cap the
upstream returns 429 "you (<account>) have reached your weekly usage
limit", but ollama-cloud is an apikey-category provider, so the existing
oauth-only shouldUseQuotaSignal gate in checkFallbackError skips the
subscription-quota-text classifier (Issue #2321) for its 429s -- the
account fell through to the generic exponential backoff (~1s, capped at
2min) and got retried every few minutes for the rest of the week (one
account took 285x429 in 48h).
Adds a new, ungated weekly-usage-limit text classifier that applies a 24h
QUOTA_EXHAUSTED cooldown regardless of provider category. Extracted the new
classifier -- together with the existing #2321 subscription-quota logic --
into a new open-sse/services/quotaTextCooldowns.ts module so the frozen
accountFallback.ts (file-size-baseline cap) didn't have to grow; net effect
shrinks accountFallback.ts by 20 lines.
This is Phase A of the plan (open-sse/services/accountFallback.ts:1038-1045
"weekly-429 cooldown"); Phase B (generic local request-counter preflight for
manual provider_plans dimensions) is a separate, larger follow-up per the
plan's own phasing.
* chore(6817): re-sync onto release tip; CHANGELOG entry → changelog.d fragment (fragments-first)
* fix(resilience): apikey-provider 429s honor explicit quota-exhausted text (#6638)
Ollama Cloud (and any other apikey-category provider) 429s skipped body-text
quota classification entirely; a genuine multi-day quota exhaustion was
misclassified as a plain rate_limit_exceeded with a few seconds of cooldown,
so combo routing retried the account immediately. shouldPreserveQuotaSignals()
now lets an explicit quota-exhausted signal (looksLikeQuotaExhausted) override
the apikey-category default, and parseDayGranularityResetMs() adds day-
granularity reset-hint parsing ("...reset in 3 days.") alongside the existing
Xh/Ym/Zs parsing.
Regression guard: tests/unit/issue-6638-ollama-quota.test.ts (RED before the
fix, GREEN after). Aligned two tests/unit/account-fallback-service.test.ts
cases that had codified the old buggy behavior for apikey-provider quota
text.
* chore(6731): re-sync onto release tip; CHANGELOG entry → changelog.d fragment (fragments-first)
* feat(xai): route xAI clients to Grok native /v1/responses endpoint
xAI ships a native /v1/responses endpoint (https://api.x.ai/v1/responses)
alongside /v1/chat/completions, but XaiExecutor extended BaseExecutor
without overriding buildUrl(), so every request always resolved to the
static chat-completions baseUrl regardless of target format — the last
genuinely-missing slice of decolua/9router#2439 (grok-build-0.1, the
reasoning-effort suffix routing, and bare grok-* routing were already
ported in prior cycles).
Add responsesBaseUrl to the xai registry entry and tag
grok-4.20-multi-agent-0309 (upstream's own Responses-only id) with
targetFormat: "openai-responses", mirroring the existing model-tag-driven
routing pattern already used by the gh executor (9router#102) and the
"openai" -pro heuristic in open-sse/executors/default.ts — the per-model
registry tag is the single source of truth that also drives chatCore's
body translation, so URL and body stay in lockstep. XaiExecutor.buildUrl
now checks getModelTargetFormat("xai", model) and resolves to the native
Responses endpoint only for tagged models, leaving every other grok-*
model on the existing chat-completions bridge.
TDD: tests/unit/executor-xai.test.ts adds a RED-then-GREEN case asserting
grok-4.20-multi-agent-0309 resolves to https://api.x.ai/v1/responses and
a control case asserting grok-4.3 still resolves to
https://api.x.ai/v1/chat/completions.
Co-authored-by: ryanngit <74137224+ryanngit@users.noreply.github.com>
Inspired-by: https://github.com/decolua/9router/pull/2439
* chore(6709): re-sync onto release tip; CHANGELOG → changelog.d fragment (fragments-first)
---------
Co-authored-by: ryanngit <74137224+ryanngit@users.noreply.github.com>
* fix(translator): defer content_block_start until GLM streams the tool name (port from 9router#2077)
GLM 5.2 (and similar OpenAI-compatible upstreams) stream a tool call's id and
function.name across separate SSE delta chunks. The openai-to-claude streaming
translator emitted content_block_start immediately on the id-only chunk with an empty
name; the Claude SSE protocol cannot patch a block after emission, so the later
name-only chunk was dropped and Claude Code rejected the tool_use with an empty tool
name / "No such tool available:". Defer content_block_start until the name arrives
(start on args if they arrive first), and emit a start for any orphaned id-only tool
call at finish so content_block_stop is never orphaned.
Reported-by: itiwant (https://github.com/decolua/9router/issues/2077)
* chore(6730): re-sync onto release tip; CHANGELOG → changelog.d fragment (fragments-first)
* fix(translator): strip empty cloud_base_branch from Cursor Subagent tool call (port from 9router#2446)
The Responses->Chat tool-arg cleanup (stripEmptyOptionalToolArgs) only stripped
empty-string/empty-array optional args for Claude Code's Read tool. Cursor's local
Subagent tool call therefore passed through with the cloud-only field
cloud_base_branch: "", which Cursor rejects ("cloud_base_branch may only be specified
when environment equals cloud") before starting the subagent. Extend the cleanup to an
allowlist of Read + Subagent; arbitrary tools stay untouched.
Reported-by: like3213934360-lab (https://github.com/decolua/9router/issues/2446)
* chore(6729): re-sync onto release tip; CHANGELOG → changelog.d fragment (fragments-first)
* fix(antigravity): surface aborted Gemini tool calls off end_turn
Gemini/Antigravity aborts a turn with finishReason MALFORMED_FUNCTION_CALL
(or a sibling like UNEXPECTED_TOOL_CALL) instead of completing cleanly. Both
Claude-facing translators collapsed these to a clean end_turn, hiding the
aborted tool call as a successful completion:
- the OpenAI hub path (openai-to-claude.ts convertFinishReason default), and
- the DIRECT Gemini->Claude path (gemini-to-claude.ts), which is the one
Claude Code actually hits through an antigravity/Gemini-routed model.
Add isAbortFinishReason() to finishReason.ts and map these reasons to
tool_use on both paths; genuinely unknown reasons still fall back to end_turn.
Co-authored-by: anhdiepmmk <n08ni.dieppn@gmail.com>
Inspired-by: https://github.com/decolua/9router/pull/2462
* chore(6713): re-sync onto release tip; CHANGELOG → changelog.d fragment (fragments-first)
---------
Co-authored-by: anhdiepmmk <n08ni.dieppn@gmail.com>
* fix(volcengine): clamp Kimi max_tokens to Ark endpoint cap
VolcEngine Ark's Kimi coding-plan endpoint (ark.cn-beijing.volces.com)
enforces max_tokens <= 32768 server-side and returns 400 "integer above
maximum value, expected a value <= 32768" for anything over that ceiling.
OmniRoute's StripRule only supported dropping params outright, with no
numeric clamp mechanism, so a client sending a larger max_tokens (common
default, e.g. 65536) 400s outright against volcengine's kimi-k2-5-260127.
The 32768 cap is independently confirmed against two live-endpoint bug
reports hitting this exact Ark endpoint for both kimi-k2.5 and
kimi-k2.7-code (NousResearch/hermes-agent#51773, MoonshotAI/kimi-cli#1124),
not just upstream's own value — same cap upstream 9router#2460 uses.
StripRule gains two optional fields: `clampToModelMaxOutput` (clamp to the
model's own catalog maxOutputTokens ceiling, when set) and `maxOutputCap`
(a fixed endpoint-imposed ceiling); when both apply, the lower wins. The
new rule is scoped to the literal id `kimi-k2-5-260127` (OmniRoute's real
volcengine Kimi model, not upstream's `Kimi-K2.7-Code`), not a broad
/kimi/i regex, so it can never clamp an unrelated future Kimi listing
whose Ark cap may differ. glm-4-7-251222 (the other volcengine model) is
unaffected.
Inspired-by: https://github.com/decolua/9router/pull/2460
Co-authored-by: whale9820 <whale9820@users.noreply.github.com>
* chore(6712): re-sync onto release tip; CHANGELOG → changelog.d fragment (fragments-first)
---------
Co-authored-by: whale9820 <whale9820@users.noreply.github.com>
* fix(codex): surface capacity errors embedded in 200-OK SSE streams
Codex sometimes answers with HTTP 200 and a text/event-stream body whose
payload carries a transient error mid-stream (e.g. "Selected model is at
capacity...", server_is_overloaded, service_unavailable_error). Because the
outer HTTP status was 200, this looked like a successful response to every
caller — no retry, no circuit breaker, and no combo/account fallback ever
engaged, so a healthy account sat idle while the request silently failed or
truncated.
Add peekCodexSseTransientError() to open-sse/executors/codex.ts: it peeks the
first bytes of a text/event-stream Codex response, pattern-matches the known
transient-error signatures, and converts a match into a real 503 Response via
errorResponse() (Hard Rule #12 — sanitized, never raw upstream text). A 503 is
already a recognized provider-failure status in accountFallback.ts, so combo
routing and connection cooldown pick it up automatically. When no error
signature is found, the peeked prefix is prepended back onto the remaining
upstream body so the passthrough stays byte-identical to the unmodified
response.
Regression guard: tests/unit/codex-sse-capacity-fallback.test.ts — a
model-at-capacity payload and a server_is_overloaded/service_unavailable_error
payload both convert to 503; a normal single-chunk SSE stream and one split
across multiple network chunks both reassemble byte-for-byte unchanged.
Inspired-by: https://github.com/decolua/9router/pull/2452 (sub-bug #3 only —
OmniRoute already covers PR #2452's other two sub-bugs: service_tier "fast"
normalization and reasoning_effort "max" normalization).
Co-authored-by: ryanngit <74137224+ryanngit@users.noreply.github.com>
* chore(6710): re-sync onto release tip; CHANGELOG → changelog.d fragment (fragments-first)
---------
Co-authored-by: ryanngit <74137224+ryanngit@users.noreply.github.com>
open-sse/translator/request/claude-to-gemini.ts already guards against
sending thinkingConfig for gemma-4-* models (Gemma doesn't support it —
Vertex returns 400: "Thinking budget is not supported for this model"),
but the OpenAI-shape path (openai-to-gemini.ts) lacked the same guard, so
OpenAI-shape clients hitting a vertex gemma-4-* model still got a 400.
Mirrors the existing claude-to-gemini.ts guard: wrap the reasoning_effort
and Claude-shape thinking.budget_tokens branches with a model.startsWith
("gemma-4") check. Branch 3 (default includeThoughts for modern Gemini
models) already excludes non-"gemini" model ids and needed no change.
Inspired-by: https://github.com/decolua/9router/pull/2480
Co-authored-by: chy1211 <31048289+chy1211@users.noreply.github.com>
* fix(sse): unwrap bare {function:{…}} tools in openai→claude translation
Some OpenAI-shape clients send a tool as a bare `{ function: {...} }`
object, omitting the spec-required `type: "function"` parent wrapper.
The tools-mapping in openai-to-claude.ts (~line 366) only unwrapped
`tool.function` when `tool.type === "function"` was ALSO true, so a
bare-function tool fell through to `toolData = tool` (the wrapper
itself, with no `.name`), producing an empty `originalName` and
silently dropping the tool from the translated request — worse than
a 400, since the caller has no signal the tool never made it
upstream. Unwrap `tool.function` whenever present, independent of
the parent `type` field. Regression guard:
tests/unit/openai-to-claude-bare-tool.test.ts.
Co-authored-by: Samir Abis <me@samirabis.com>
Inspired-by: https://github.com/decolua/9router/pull/2473
* chore(6704): re-sync onto release tip; CHANGELOG → changelog.d fragment (fragments-first)
---------
Co-authored-by: Samir Abis <me@samirabis.com>
* fix(api): Responses passthrough emits event-only SSE frames after filtering commentary output (#6561)
The #6199 commentary-drop `continue;` branches in stream.ts skipped the
data: line for a dropped commentary event but never cleared the
already-buffered event: line for the same frame, so the next blank line
flushed the stale event: line alone -- an event-only SSE frame that
crashes the OpenAI Python SDK's json.loads(). Both drop sites now call
clearPendingPassthroughEvent() before continue. The commentary-drop
decision was extracted into a new responsesCommentaryDrop.ts module so
the fix does not grow the frozen stream.ts.
* chore(6735): re-sync onto release tip; CHANGELOG entry → changelog.d fragment (fragments-first)
* fix(resilience): resolve fp-pinned combo account back to real connection id (#6696)
* chore(6732): re-sync onto release tip; CHANGELOG entry → changelog.d fragment (fragments-first)
* fix(providers): drop image_generation for Codex Spark models regardless of plan (#6651)
* chore(6721): re-sync onto release tip; CHANGELOG entry → changelog.d fragment (fragments-first)
* fix(cursor): use Agent CLI build id for x-cursor-client-version
Reconstructed onto release/v3.8.47 to drop unrelated main-drift (deps/electron/proxy
files belong to #6620, not this PR); the author's .env.example/docs deltas were
re-applied cleanly onto the release tip.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* chore(changelog): re-sync CHANGELOG.md to release tip (restore #6701 bullet)
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(providers): ensure DeepSeek Web SSE emits [DONE] after FINISHED
Reconstructed onto release/v3.8.47 to drop unrelated main-drift (deps/electron/proxy
files belong to #6620, not this PR); keeps only the author's changes.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* refactor(deepseek): extract done-terminator helper to keep frozen file under cap
Extracts the FINISHED-drain scheduler and finish-once guard added for
the [DONE] terminator fix (#6777) into a new
deepseek-web-done-terminator.ts module, so deepseek-web.ts stays under
its frozen line cap (1148). Behavior is unchanged.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: Pitchfork-and-Torch <Pitchfork-and-Torch@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
