Conversation
…ives (#11915 follow-up on #11883) (#11933) Merges #11883's already-merged usage-harvesting extraction with #11915's finish-deferral mechanism, verified to fix a real remaining bug: the client-visible message_delta carried stale/zero usage when finish_reason arrived before the trailing usage chunk. 86/86 tests passing across 16 translator regression files.
…ced (#11829) (#11919) Suppresses stale static registry models (including effort-tier variants) for any provider whose active connection has an authoritative live synced catalog, not just providers using exclusive-synced-listing — closing a gap where a connection with providerUsesAuthoritativeLiveCatalog kept serving both the live-synced models and the stale static rows side by side. Closes #11829. 4/4 focused tests passing. Thanks!
…sponses (#11826) (#11916) stripStore() now forces store=false for stateless OpenAI-compatible Responses-API targets unless the connection explicitly opts in via providerSpecificData.openaiStoreEnabled, instead of only handling the openai/agentrouter cases — a client-supplied store value previously passed through untouched to backends that don't actually persist responses server-side. Closes #11826. Thanks!
…elease/v3.8.51 Fifteen unit files were red on this branch's PRs; running them on the pre-sync tip (d5dfcff) and on the synced one showed thirteen already failed before the sync — the cycle's own drift — and exactly two regressed: - open-sse/services/tokenExtractionConfig.ts: git kept BOTH sides' identical volcengine-console config (23 entries instead of 22). The duplicate is gone. - src/lib/usage/providerLimits.ts: the sync took release/v3.8.50's cooldown release helper, which is looser than this branch's #11277 contract (it frees an extra_usage block when the policy is off and a window with no reset evidence). tests/unit/provider-limits-recovery.test.ts pins the contract; the pre-sync call site is restored and the unused helper and its imports dropped. 20/20 again, siblings unchanged.
…-main-into-3851-20260828b
…ote-only replace CodeQL js/incomplete-sanitization (#888): the hand-rolled replace only escaped double quotes, so a backslash in the fixture would have produced a malformed YAML scalar. JSON.stringify covers every escape the double-quoted YAML scalar needs.
…#11876 shipped on release/v3.8.51 (#11944) Eleven PRs landed on release/v3.8.51 while the branch carried fifteen base reds, and nine more red tests hid among them. None is a defect in the shipped code; each test still encoded the contract that the merged PR deliberately replaced: - openai-to-claude finish deferral (dd35750, #11933): a finish chunk that carries no usage is now held until the end-of-stream flush that production performs (open-sse/utils/stream.ts flush -> translateResponse(..., null, state)). The drivers in stream-markdown-token-boundary, translator-tool-call-shim and gemini-malformed-function-call-finish-reason-2462 fed the finish chunk and asserted the terminal events immediately; they now mirror the flush. Assertions unchanged. - authoritative live catalog (3d2832b, #11919 fixes #11829): a synced catalog replaces the static registry, so model-lifecycle-integration no longer expects the static-only gpt-5.6-sol row to survive a sync. The #8627 contract the file guards (stale chat rows suppressed, typed media retained) is untouched. - provider asset provenance (#11876): the unit shards check out with depth 1. The fixture pinned a historical commit as auditedCommit (absent on a shallow clone), the "binds auditedCommit" case relied on the repository root commit (the grafted HEAD on a shallow clone, which matches the physical snapshot), and the real-manifest case needs the audited commit fetched. The fixture now audits HEAD, the mismatch case builds a dangling empty-tree commit (no ref written), and the real-manifest case skips only on a shallow checkout that lacks the commit - the gate itself keeps running on both fetch-depth-0 rails, which the next test asserts. All five files pass locally (30, 11, 38, 3 and 18 tests); lint with the frozen suppressions is clean.
…was born with (#11940) * fix(release): drain the twelve reds every PR against release/v3.8.51 was born with Measured on the cycle tip: fifteen unit files were red on every PR. Two came from the v3.8.50 sync-back (fixed in #11929); the other thirteen predate it and are the branch's own drift. This sweep clears all of them but the ESLint debt (#11924), each with the smallest change that keeps the guard honest: - .env.example + ENVIRONMENT.md: NEXT_PUBLIC_SW_BUILD_ID / OMNIROUTE_SW_BUILD_ID / SOURCE_VERSION (#11779 service-worker cache busting) documented — the env/docs contract gate was failing on every PR. - stryker.conf.json: the six tests the mutation gate found covering mutated modules (four retirement runtime-block suites, combo connection-aware expansion, tunnel error sanitization) registered in tap.testFiles. - dependency-allowlist: eslint-plugin-react-hooks 7.0.1 approved; its findings are tracked in #11924. - i18n: the six combo.sort.* strings (d5dfcff) translated for vi (strict parity) and pt-BR. - docs/providers/CHATGPT_WEB.md: the retirement test is migration-168, not 163. - g4f gateways: authHint now says member key, which the discontinued-providers guard asserts. - tests realigned to the catalog the branch actually ships: qwen-web (#11713) and chatgpt-web (#11720) are retired, so web-session-contract and token-health-check-webcookie use perplexity-web, grok-web and chatgpt-web-codex. - db-core-init: the two minimal legacy fixtures gained the columns migrations 164-168 UPDATE (error_code, last_error*, test_status) — they exist on every real legacy DB (base CREATE TABLE); the fixtures simply never declared them. - no-js-extension guard: a .js specifier whose target is a genuine JavaScript file (open-sse/lib/deepseek-pow-hash.js, shared with a worker) is not the #10674 defect; the test now skips targets that exist as .js. All twelve files pass locally; docs-sync, docs-counts, env-doc-sync, the tap drift gate and the fabricated-docs gates are green on the tree. * test(release): move the deferred-finish translator test into a collected path tests/unit/translator/ is not one of the unit collectors (package.json test:unit, merge-train.sh, build-test-impact-map, check-test-discovery), so the suite that dd35750 added there never ran — check:test-discovery flagged it as a new orphan on every PR. Relocated next to its sibling openai-to-claude-trailing-usage-11817 under tests/unit/, where the root glob collects it (5/5 pass). * fix(dashboard): type the four sort-method sites #11812 left red on the dashboard typecheck ratchet d5dfcff added the combo model sort and raised combos/page.tsx from 23 to 27 scoped TypeScript errors (TS2339 +1, TS2345 +2, TS2322 +1), which fails check:dashboard-typecheck on every PR against release/v3.8.51: - initialSortMethod: sanitizeComboRuntimeConfig() is untyped, so config.modelSort is unknown; narrow it before reading .method (normalizeSortMethod takes unknown anyway). - handleAddModels: the batch path passes ComboBuilderDraftModelStep[] to the ComboStep[] sort helpers without the cast handleSortChange already uses; mirror it. - ComboSortSelect expects a translate-with-fallback (k, f) => string, but received next-intl's Translator whose second argument is a values object. Pass the page's getI18nOrFallback adapter instead of the raw translator — that is also what makes the `has()` check and the fallback text actually work at runtime. Baseline untouched (no widening). Scoped tsc: 0 new/regressed errors.
…finish test #11940 moved tests/unit/translator/openai-to-claude-trailing-usage.test.ts one level up so a collector would run it, but kept the ../../../ import path from the old directory, so the file failed to load and painted Unit Tests fast-path (3/4) red on every PR since a94fe23. The path now matches its new location (5/5 pass).
…from a clean-room run (#11955) * chore(quality): re-freeze the ESLint suppressions on release/v3.8.51 from a clean-room run `No new ESLint warnings` failed on every PR against release/v3.8.51 with exit 2: "There are suppressions left that do not occur anymore". Measured in a depth-1 clone with `npm ci` from the branch's own lockfile and the job's exact command (`npm run lint:json -- --max-warnings 0`): 56 errors — 55 `no-explicit-any` in six files that landed while the base was red (#11843 isFree tests: 22; b710214 socks connect timeout: 33) plus one `no-unused-vars` — and stale entries for files that no longer violate. The devbox figure previously quoted in #11924 (280, with 224 react-hooks/*) does not reproduce on the lockfile install and is withdrawn. - config/quality/eslint-suppressions.json: `--prune-suppressions` (two stale file entries removed) and the 55 pre-existing `any` frozen at their exact counts — the file is a ratchet, counts only go down; the debt stays tracked in #11924. - open-sse/services/adobeFireflyCatalog.ts: remove `GPT_SIZE_MAP`, a constant the f3d9279 split left behind with no reader (the real violation, fixed not frozen). Verification in the clean room after both changes, same command as CI: exit 0, 0 errors, 0 warnings (1238 files / 5487 suppressions). * chore(quality): tighten openapiCoverage.pct to the measured 39 (require-tighten) With ESLint back to 0/0 on this PR, the job's next step (check-quality-ratchet --require-tighten) started failing: openapiCoverage.pct improved from 38.4 to 39 (delta 0.6 > slack 0.5) and the baseline must be tightened in the same PR. 39 is the value CI collect-metrics measured on run 33213844112 and a clean-room checkout of 777d9d1 reproduces it; the cycle's new routes landed documented in docs/openapi.yaml. Only this metric moves; annotation follows the file's convention.
…int caches (#11963) - quality.yml fast-unit: timeout-minutes: 30. A shard finishes in ~10 min; without a ceiling a hung test process holds the PR for GitHub's 6 h default. On 2026-08-28 shard 1/4 sat 64 min without a line of output — twice at the same spot, a timing race that vanished on the third run — while the other three shards were long green. A fast red plus a re-run beats a silent multi-hour hold. - quality.yml lint-guard + the earlier ESLint cache block: drop the `restore-keys: eslint-<os>-` fallback (#11600, P-II.1 of the v3.8.50 postmortem). The key already hashes the lint config, the suppressions file and the lockfile; the fallback restored a cache built under a DIFFERENT configuration and its stale per-file verdicts are how 215 pre-existing errors stayed invisible for a cycle. Exact key or a cold full lint — never a partial cache from another configuration. check:workflows --ratchet unchanged (194/194); check-workflows suite 32/32.
Records the v3.8.50 → v3.8.51 precedent in the single source of truth: a main → release/vX+1 sync PR lands by fast-forward push so main stays an ancestor of the release branch (squash re-conflicts the next sync-back on every file main touched — 551 conflicts this cycle before the two-step merge), plus the two post-landing checks (ancestry assert; ratchet files carried main's freezes). The full procedure lives in the generate-release Phase 5 skill.
…ption 3) (#11962) The hosted 7 GB runner cannot build release/v3.8.51 in any profile: `Build App` (build.yml, push on every branch, full `build:release`) died in 19 of the last 30 runs — the branch tip included — with "The runner has received a shutdown signal" ~8 min into `next build`, swapfile and all; the advisory quality.yml build failed on 8/8 recent fork PRs with the same recipe; and `DAST smoke (PR)`'s backend-only build died ~7 min in before the server even started, hidden as a permanently red continue-on-error check. Together they painted every PR into release/** red with zero signal and, on build.yml, produced an artefact nothing downloads. - build.yml: workflow_dispatch only. The bundle is validated where a build fits — ci.yml `Build` on the self-hosted omni-build pool after every merge to main, and nightly-release-green.yml on the same pool for release/**. - dast-smoke.yml: pull_request into main only (plus workflow_dispatch to smoke a release branch by hand); main's tree still builds on the hosted runner in ~5.5 min. - quality.yml: the fork-only rationale of `Build (advisory)` updated to say why own-origin PRs no longer get a hosted build either. Behaviour unchanged. check:workflows --ratchet: 194 zizmor findings, baseline 194. check-workflows and backend-only-smoke-workflows suites pass. Trade-off stated in the PR: own-origin PRs into release/** lose a pre-merge build that was not succeeding anyway; the nightly rail files a base-red issue within a day if a merge breaks the build.
…11965) (#11967) Four nightly jobs run a backend-only `next build` on ubuntu-latest (7 GB): Schemathesis, promptfoo injection guard, garak probes and the axe a11y suite (self-building webServer). On release/v3.8.51 three of them died with the hosted VM shutdown signature and nobody saw it — nightlies have no audience — and the fourth passes by a margin of minutes. They now target [self-hosted, omni-light] (hosted fallback when USE_VPS_RUNNER is off), a new two-listener label on the .113 box for jobs that need ~6 GB, not the 14-16 GB of a full build; they run once a day in the 04:00-06:00 UTC window, when the box is idle. Fleet reshaped the same day and documented in docs/ops/RUNNER_BOX.md: 4 active OmniRoute listeners (omniroute-113-5/-6 omni-build, omniroute-113/-2 omni-light), omniroute-113-3/-4/-7/-8 disabled (systemctl enable --now brings one back), janitor ceiling MAX_ACTIVE_RUNNERS=4. The remaining headroom limit is the VM's 31 GB of RAM (2 heavy + 2 light ≈ 42 GB peak, inside the 16 GB swap); more RAM on the Proxmox VM is the lever that turns the label ceilings into 3 heavy + 2 light. check:workflows --ratchet unchanged (194/194); check-workflows and backend-only-smoke-workflows suites pass; docs-sync PASS.
…ard on ENOTEMPTY (#11966) (#11968) * test(infra): retry recursive temp-dir removal instead of failing a shard on ENOTEMPTY (#11966) Two shards on release/v3.8.51 went red in one day with the same signature — "ENOTEMPTY, Directory not empty: /tmp/omniroute-<test>-XXXXXX" — from combo-same-provider-cascade (Unit Tests fast-path 4/4, on a PR that touches only .github/) and auth-policy-embeddings-webfetch-7785 (the 20k-test TIA step). Both pass alone and on re-run: the cleanup races something still writing into the directory (SQLite WAL/-shm checkpoint, a worker, the backup) and under a loaded hosted runner the window opens. 1154 test files do their own cleanup with fs.rmSync(dir, { recursive: true, force: true }); 57 already asked for retries. One-shot codemod (scripts/ad-hoc/codemod-rm-maxretries.mjs, kept for the record): every rm / rmSync / rmdirSync option object with `recursive: true` and no `maxRetries` gains `maxRetries: 5, retryDelay: 100` — Node itself then retries ENOTEMPTY/EBUSY/EPERM for up to ~0.5 s before giving up. 2243 call sites in 1292 files under tests/, the shared tests/_setup/isolateDataDir.ts exit hook included. Only the option object changes: no call site, assertion or import is touched. Validation: prettier and ESLint (with the frozen suppressions) clean on all 1292 files; a random 20-file sample runs green (quota-redis-store hangs identically on the untouched tree — it needs a Redis on localhost, an environment matter). The four unit shards on this PR are the full run. * fix(quality): let check-forgotten-sibling-tests read a 1,000-file diff The gate shells out to `git diff` through execFileSync with Node's default 1 MB maxBuffer; the 1,292-file codemod in this PR is the first diff large enough to overflow it, and the gate died with `spawnSync git ENOBUFS` before comparing anything. 64 MB is far above any real PR and costs nothing when unused.
…ob and the main run (#11972) The job has timeout-minutes: 20; the c8 merge across 8 shards takes ~10 min and the Codecov upload (declared informational) then hung for the rest of the budget on two consecutive main runs (33207760653, 33215115341) — GitHub cancels the step, the job ends cancelled, and the run's conclusion turns cancelled although every blocking job was green. The upload step now has its own 5-minute ceiling and continue-on-error; the job budget is 30 min. check-workflows suite 32/32; zizmor ratchet unchanged.
…ead to the npm leg (release/v3.8.51 twin of #11973) (#11974) Same three changes as #11973 on main, applied to this branch's newer copy of the workflow so the v3.8.51 tag does not repeat v3.8.50's zero-asset release: publish-npm grants actions:read (the called publish job requests it — a caller that grants less is refused at startup and the release job dies with it), a publish_npm dispatch input gates the npm leg, and web-build/build/release check out the tag named by the dispatch. actionlint clean; the five workflow-pinning suites pass.
…#11975) Production (open-sse/utils/socksConnectorWithFamily.ts, 4 sites): every cast was redundant — undici's buildConnector.BuildOptions already has `timeout?: number | null`, socks' SocksClientOptions has `timeout?: number`, and Agent.Options' `connect` / `connectTimeout` narrow to the connector's parameter types on their own. Behaviour unchanged; check:open-sse-typecheck stays at the frozen 5. Tests (51 sites): the socks-timeout mocks now carry the real types — the patched SocksClient.createConnection is typed as the static it replaces, the fake buildConnector returns buildConnector.connector, the proxy is a SocksProxy, the dynamic import is typed as the module it loads; the e2e suite passes a SocksProxy and Agent.Options and no longer casts undici's fetch init (its RequestInit already has `dispatcher`); the isFree suites narrow getCustomModels()' JSON to a declared row shape, feed deliberately-wrong values through `unknown`, and stop casting for zod's safeParse, which takes unknown. The six files' suppression entries are removed: 1238 → 1232 files, 5487 → 5432 suppressed. ESLint without the suppressions file reports 0 problems on all six; with it, no stale entry is left. The five suites pass (4, 2, 5, 4, 4).
…koff (Gemini ban prevention) (#11762) Root-caused via a real Gemini-ban incident log: deprecated-model 404/410s (e.g. gemini-2.5-flash "no longer available to new users") fell through checkFallbackError's generic transient-cooldown branch, so combo/auto-routing kept re-selecting a permanently dead model every cooldown window forever — the hammering that got the account flagged as abusive. Fix: `MODEL_PERMANENTLY_UNAVAILABLE_PATTERNS` + `isModelPermanentlyUnavailable()` classify these as a 24h lockout instead, surfaced via `quotaResetHintMs` so combo's per-request model-lockout honors it in full. Validated: 6/6 new tests + 133/133 existing accountFallback/error-classification tests, no regressions. Thanks for tracing this end-to-end with real production logs!
…ng-suspended accounts (#11774) Follow-up to #11762, same bug class hitting freeaiapikey (410 permanently-moved endpoint) and fireworks (412 billing-suspension) — both fell through checkFallbackError's generic transient-cooldown branch and got retried every ~1 minute for a full day. Fix: `ENDPOINT_PERMANENTLY_MOVED_PATTERNS`/`isEndpointPermanentlyMoved()` → 24h lockout; `ACCOUNT_SUSPENDED_BILLING_PATTERNS`/`isAccountSuspendedForBilling()` → treated as credits-exhausted (1h cooldown), independent of status code so it also catches Fireworks' 412. #11762 landed first and touched the same file — rebased/re-merged onto the updated tip (additive, no logic changes) and re-validated: 13/13 tests pass. Thanks for tracing this with real production logs again!
… requests (#11781) Follow-up to #11762/#11774, same bug class in combo's own model-lockout wiring: GitHub rejects several models (gpt-5.4, gpt-5.3-codex, etc.) with a 400 that's permanently unavailable for this account's Copilot integration, but nothing recorded a cross-request lockout — combo's #5249 in-request advance guard is correct but doesn't persist, so the same doomed model gets retried from scratch on every new request, indefinitely. Fix: on a model-scoped 400 (`isModelScoped400`), call `lockModelIfPerModelQuota(provider, connectionId, rawModel, "model_capacity", 1h)`. GitHub already has per-model-quota enabled, so only the rejected model locks — siblings keep working. `isModelLocked()` is already checked pre-dispatch, so no other wiring needed. Validated: 3/3 new tests + fixed a pre-existing test-isolation gap in combo-model-scoped-400-advance.test.ts (shared model name across sub-tests without clearing lockout state). Thanks!
…EADME (#11772) Finishes the Freepik → Magnific rebrand from #10594 across 40 locale files and 3 README feature-list bullets (README.md, docs/i18n/it, docs/i18n/tr) — legacy `freepik` alias intentionally left in code/tests/redirects for backward compatibility, and historical CHANGELOG entries left untouched as documented history. The README bullet had base-drifted since the PR branched (release tip's "What's New" changelog snippet had already dropped two providers mentioned nowhere else in the codebase, unrelated to this PR's scope) — resolved by keeping the tip's current bullet shape and applying only the Freepik→Magnific rename on top, in both the combined-worktree validation and the pushed branch. Validated: all 40 edited locale JSON files parse; re-verified after resync onto the updated tip (post #11762/#11774/#11781).
…t createTask flow (#11296) (#11985) flux/kontext is catalogued with isMarket: true, so handleKieImageGeneration routed it through KIE's unified Market createTask endpoint with model: "flux/kontext". KIE does not expose Flux Kontext through the Market catalog at all -- it lives under a dedicated API tree (POST /api/v1/flux/kontext/generate, poll GET /api/v1/flux/kontext/record-info, models flux-kontext-pro/flux-kontext-max) -- so the Market endpoint rejected it with "model name not supported", matching the reporter's exact error text. Special-case flux/kontext ahead of the isMarket branch so it hits the dedicated endpoint/payload shape instead of being treated as a Market entry. z-image/4.0-*/4.5-* remains intentionally untouched (still blocked on reporter/live confirmation per the existing in-code comment). Co-authored-by: Markus Hartung <mail@hartmark.se>
…outs (#11500) (#11989) * fix(db): rate-limit Arena ELO fetch-failure warnings on repeated timeouts (#11500) * test(quality): split the #11500 fetch-failure-dedup tests into their own file tests/unit/arena-elo-sync.test.ts crossed the 1000-line new-test-file cap (file-size gate, PR mode). The two new tests don't need the file's DB fixture (fetchArenaLeaderboards() never touches the DB), so they move to a self-contained sibling file instead of growing the frozen suite. --------- Co-authored-by: Markus Hartung <mail@hartmark.se>
…te path (#11707) (#11984) enforceCodexResponsesLiteParallelToolCalls() forces parallel_tool_calls:false at the top of CodexExecutor.execute(), but transformRequest() early-returns the body before its RESPONSES_API_ALLOWLIST field filter only when _nativeCodexPassthrough is set. Any request that reaches the codex executor via the translated (non-native-passthrough) path never gets that flag, so the allowlist filter silently deleted parallel_tool_calls right before the fetch body was sent, reproducing the reported upstream rejection ('X-OpenAI-Internal-Codex-Responses-Lite requires parallel_tool_calls to be false') for every model. Add parallel_tool_calls to RESPONSES_API_ALLOWLIST so the value survives the translated path too. Update the sibling #2608 allowlist test that previously asserted parallel_tool_calls gets stripped like other Chat Completions-only fields -- it is a legitimate Responses API field that must now survive. Co-authored-by: Markus Hartung <mail@hartmark.se>
…+ autoDetect) (#12289) * feat(sse): add it/ru/zh caveman output instructions * fix(sse): expose the dormant terse-prose translations through the catalog * feat(sse): translate less-code to es/de/fr/it/ru/zh * feat(sse): translate ponytail to es/de/fr/it/ru/zh * feat(sse): translate i-have-adhd to es/de/fr/it/ru/zh * test(sse): anchor wave-2 output-style translations to their own language * feat(dashboard): offer every output-style language in the default-language selector * feat(sse): let autoDetect pick the output-style instruction language * docs(compression): consolidate the output-style tables and record full language parity
…in the fileSize worst-file signal (#12291) The nightly headroom monitor flagged fileSize 🟡 permanently because the worst frozen file was src/app/docs/lib/openapi.generated.ts — frozen at its emitter's exact output size in #12212, i.e. ~0% headroom BY CONSTRUCTION (growth is policed by conscious re-freezes, never by editing the module). Same class: open-sse/vendor/** (upstream code nobody slims by hand). isMonitorExemptFile() excludes .generated. modules and vendor/ paths from the monitor's worst/near-cap accounting only — check:file-size itself still enforces both. The fileSize row now points at the worst HUMAN-EDITABLE frozen file (currently tests/integration/skills-pipeline.test.ts at 4.5%, a true early warning: its baseline note already requires a split rationale for any further growth). Refs #12149
…bailian 401 (#12288) * fix(usage): console-aware Token Plan guidance and subscription hint on bailian 401 The personal Token Plan is sold through two consoles with different portals, gateway hosts and login tickets. Two operator-facing messages ignored the split: - The quota guidance always said 'get the cookie at home.qwencloud.com', even for connections served by the Alibaba Model Studio console — following it verbatim produces a cookie the gateway rejects (console mismatch → BailianGateway.Login.NotLogined). The guidance now derives the console from the provider via resolveConsoleSite, matching what the fetcher will do with the pasted cookie. - Key validation mapped upstream 401 to a bare 'Invalid API key'. An expired Token Plan subscription produces the exact same upstream 401 (observed live 2026-09-01: subscription ended 08-23, the working key started failing), so the message now names the subscription as a cause worth checking. * test(providers): align the remaining bailian 401/403 message pins to prefix match search-provider-validation.test.ts pinned the exact 'Invalid API key' string for the bailian validator; the message now also names an expired Token Plan subscription. Same property asserted (401/403 => invalid), prefix match.
…ready calls (#12321) usage/fetcherProviders.ts exists, in its own words, "so the registration list can't drift from the dispatcher's switch statement". It drifted: #8006 added adobe-firefly and firefly to the dispatcher and to USAGE_SUPPORTED_PROVIDERS but not to this list, so the connection UI advertised usage support while the provider-plugin manifest, genericQuotaFetcher and the free-access quota cache all reported no fetcher — for two ids getUsageForProvider would happily serve. Declaring them is what makes the balance actually get fetched (registerGenericQuotaFetchers wires a generic fetcher per declared id, and resolveFreeAccessState stops returning early), which the PR states plainly rather than burying as a side effect. The test turns the docstring's prose invariant into enforcement: it reads the dispatcher's cases from source and compares both directions, and records each accepted difference against USAGE_SUPPORTED_PROVIDERS with a reason plus a staleness check, so the next drift can't hide among them. xiaomi-mimo-token-plan is left flagged as a real gap rather than widening the PR. Verified in a combined batch worktree: 174/174 focused tests across all 11 PRs of this batch, typecheck:core clean, complexity 2706/3218, cognitive-complexity 1221/1437, check:cycles and check:docs-counts green. Thanks @maxmad64bis.
…talog (#12215) GET /api/free-tier/summary could answer from a Radar overlay built 2026-08-02 while the release ships a catalog curated 2026-08-30 (FREE_CATALOG_CURATED_AT) — totals computed from older data, still tagged catalogSource: radar-overlay. The route now refuses any overlay built before the shipped catalog and falls back to that catalog through the operator's local state. Tightens #11550 using the generatedAt persisted by #11435. Verified in a combined batch worktree: 174/174 focused tests across all 11 PRs of this batch (this PR's free-tier-summary-radar-overlay suite included), typecheck:core clean, check-file-size, check-changelog-integrity, check:cycles and check:docs-counts green. Thanks @maxmad64bis.
…12319) With freeAccessPolicy: "strict" the read-only candidate listing silently dropped rows, so an operator could not tell "no free allowance left" from "the quota fetcher is broken" — in a listing whose own module header promises a candidate the routing path would skip "is never dropped". #9133 settled the same question for the resilience filter via a skip opt-out; the zero-cost guard never got one. It gets it now: the guard is disabled for the inspector build exactly as the resilience filter already is, and every candidate carries freeAccessExclusion — null when satisfied, otherwise one of seven named reasons. The last three (exhausted, state-unknown, no-connection) are the point: they used to look identical because the row just disappeared. STRICT_ZERO_COST.md documents what each asks the operator to do. Dispatch is untouched and a test pins that. The three existing guard suites were not modified — their 31 cases are the net and still pass. excludeTosAvoid still drops candidates without a reason; documented as a separate question rather than widened into here. Verified in a combined batch worktree: 174/174 focused tests across all 11 PRs of this batch, typecheck:core clean, complexity 2706/3218, cognitive-complexity 1221/1437, check:cycles and check:docs-counts green. Thanks @maxmad64bis — the reason table and the honest note about the order change (freshness before status) made this easy to review.
#12151) A passthrough stream could end with no usage even though the client asked for it via stream_options: {include_usage: true}, so providers that do not meter always showed 0 tokens. The fix estimates usage at the finish marker when the upstream stays silent (flagged estimated: true) and drops any duplicate trailing usage chunk so the client never sees two. open-sse/utils/stream.ts:1982,1749 · open-sse/utils/usageTracking.ts:651,664 Six cases: the predicate (finish without usage but with content, trailing valid, empty response, tool-only) plus two SSE harness cases through createSSEStream passthrough. Note on base: this branch forked 442 commits back and carried a base-red marker for #12109, which is now closed — the release tip has no open base-red issue. It merged cleanly against the current tip regardless. Verified in a combined batch worktree: 174/174 focused tests across all 11 PRs of this batch (this PR's stream-passthrough-usage-estimation suite included), typecheck:core clean, check:cycles and check:docs-counts green. Thanks @maxmad64bis.
) Two of the fifteen factors calculateScore applies could not be set by anyone. scoringWeightsSchema is a plain z.object, so zod strips what it does not name: PUT a combo with connectionDensity and you get a 200 back with nothing saved, and normalizeScoringWeights then reads the gap as a deliberate zero — switching off anti-concentration and the quality signal. DEFAULT_INTELLIGENT_WEIGHTS, the dashboard's own copy, missed the same two and every non-zero value differed from the engine's; summing to 1.05, validateWeights rejected them outright. This adds the two keys to both lists and takes the dashboard defaults from DEFAULT_WEIGHTS. The scorer is not touched. One behaviour change, and it is the point: a combo whose stored weights omitted the two keys was running with them at zero and the other thirteen renormalized upward. It now uses the engine's distribution (quota 0.1549 → 0.1429, health 0.1740 → 0.1605) and a test pins those numbers. Left alone and documented rather than widened: rounded percentages now total 101% (six factors at 4.76% each render as 5%), and five stale .default() values in the schema that only bite when a config omits the key. Verified in a combined batch worktree: 174/174 focused tests across all 11 PRs of this batch, typecheck:core clean, complexity 2706/3218, cognitive-complexity 1221/1437, check:cycles and check:docs-counts green. Thanks @maxmad64bis — the red-before-green note (7 of 8 failing, and naming the one that passes on purpose) is exactly the evidence that makes a behaviour change reviewable.
#12316) docs/routing/AUTO-COMBO.md documented four mode packs; six ship. It printed 0.14 where modePacks.ts says 0.1333. And nothing was watching: four documents stated a scoring-factor count and check:docs-counts covered none of them. Wiring them up turned the gate red on seven real drifts — ARCHITECTURE.md and REPOSITORY_MAP.md at "9-factor" (code: 15) and "4 mode packs" (code: 6), RESILIENCE_GUIDE.md and SKILL.md at 13, AUTO-COMBO-GUIDE.md at both 5 and 13. ARCHITECTURE.md did not merely have the wrong number: it named nine factors that are not the engine's, and its four "mode packs" were the auto/* request prefixes. A product fact fell out of writing the table: no pack sets quality, and applying a pack replaces the weight map wholesale (weights = pack in engine.ts, not a merge), so quality carries 0.03 by default and normalizes to 0 under any pack — pick a mode pack and the observed-quality signal stops voting. Documented, not changed. The gate reads pack names from the module through the tsx subprocess that already reads every other code-derived count, matching the three spellings the docs actually use; on the reference document a missing claim now fails rather than passing. The dashboard was behind too (four of six packs offered); the count is dropped from the strategy label rather than corrected, since nothing reads selector labels and a right-today number goes stale unnoticed. Verified in a combined batch worktree: 174/174 focused tests across all 11 PRs of this batch, typecheck:core clean, and check:docs-counts green with the four newly-wired documents. Thanks @maxmad64bis — finding the quality-under-a-pack behaviour while writing a docs table is the kind of thing a table is for.
…minalizes the whole connection (#12266) * fix(resilience): per-model 402 on a passthrough gateway no longer terminalizes the whole connection 402 variant of #3027. Passthrough/gateway providers that multiplex many models behind one credential (kilo-gateway, ollama-cloud, etc.) can 402 on a single PAID model while free models on the same key remain perfectly usable. Previously any 402 unconditionally set the connection to a terminal `credits_exhausted` status, which is never auto-recovered without an operator reset — taking out every remaining model on that provider, amplified further inside combo routing (measured: one 402 removed 9 of 14 fallback targets in a real combo, dropping success rate from 98.3% to 74.2% on a fixed load test per the issue report). Root cause (matches the issue's own analysis): 1. resolveTerminalConnectionStatus() returned "credits_exhausted" for ANY status === 402, with no per-model/passthrough check. 2. The generic per-model lockout gate (404/429/>=500) excluded 402. 3. The #3027 403-branch is gated on `!terminalStatus` — since (1) already resolves a terminal status for any 402 before that branch runs, simply adding 402 to its condition alone would not have fired. Fix: - resolveTerminalConnectionStatus() now takes isPerModelQuotaProvider and skips the connection-wide terminal path for a bare `status === 402` when true, letting it fall through to the per-model lockout branch instead. An explicit result.creditsExhausted (a provider's own classification, independent of HTTP status) is untouched and remains unconditionally terminal. - Extended the existing #3027 per-model lockout branch to also handle 402 (reason "credits" vs "forbidden" for 403), reusing the same cooldown/lockout machinery and log format. - Single-credential (non-passthrough) providers are unaffected: isPerModelQuotaProvider is false there, so a 402 still terminalizes the connection as before — that behavior is deliberate for prepaid API keys (#5239 / #10616). Also checked the issue's 4th root cause (terminal statuses never auto-recovering) against the current codebase: connectionRecovery.ts already has a 30-minute credits_exhausted reprobe (isCreditsExhaustedReprobeCandidate) that the issue's report — filed against v3.8.49 — didn't account for. The other two files it names (rateLimit.ts's clearStaleCrashCooldowns, tokenHealthCheck.ts's OAuth-refresh skip) legitimately exclude credits_exhausted for unrelated reasons and are not bugs. Moot regardless: this fix prevents credits_exhausted from being set at all for the passthrough case, so no recovery wait is needed in the first place. Tests: tests/unit/auth-passthrough-per-model-402-12242.test.ts, modeled on the existing #3027 precedent test (real DB-backed integration test via auth.markAccountUnavailable). Covers: paid-model-only lockout with free model unaffected, a subsequent free-model request succeeding after a sibling paid-model 402, single-credential 402 still fully terminal, and no connection-wide backoff escalation on repeated 402s. Verified: - node --import tsx/esm --test tests/unit/auth-passthrough-per-model-402-12242.test.ts: 4/4 pass - All related pre-existing tests (auth-ollama-cloud-per-model-403-3027, auth-terminal-status, openrouter-free-model-credits-exhausted, vertex-passthrough-model-lockout, 10347-embed-402-cooldown): 27/27 pass, no regressions - npm run typecheck:core: 0 errors - npm run check:cycles: no cycles - eslint (auth.ts + new test file, with project suppressions): 0 errors Fixes #12242 * chore(quality): register 402 per-model test in stryker tap and de-ratchet auth.ts - stryker.conf.json: add tests/unit/auth-passthrough-per-model-402-12242.test.ts to tap.testFiles in its alphabetical slot - auth.ts: extract the #12242 connection-wide 402 decision into the pure helper isConnectionWideCreditsExhausted() so resolveTerminalConnectionStatus stays within the cyclomatic ratchet (file back to the base's 11 violations) --------- Co-authored-by: OmniRoute Dev <dev@local> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
) docs/reference/FREE_TIERS.md said its numbers were "gathered by web research (confidence tagged per row)". No entry carries one: grep -c confidence on the catalog returns 0, the type does not declare the field, and the API serves nothing of the sort. A reader looking for "how much can I trust this figure" was pointed at a per-row signal that never existed. Replaced with the two counts the data actually supports — 7 of 446 entries carry hardStopGuaranteed (the field with the strictest sourcing rule in the repo: set only when the provider's own terms document that exceeding the free allowance refuses the request, source in a comment, never defaulted to true) and 13 carry a prompt-training disclosure. check:docs-counts reads both from the catalog at runtime, as required claims, so a reworded or deleted sentence fails rather than passing as "no claim in this file". The PR deliberately does not add a confidence field — curating one is a product call, and it says so instead of inventing it. Reconciled on merge: #12316 landed the gate extension underneath, so scripts/check/check-docs-counts-sync.mjs and its test took the tip's side plus this PR's own required-claim additions. Verified afterwards: check:docs-counts green, 48/48 across check-docs-counts-sync and free-catalog-no-confidence-field. Thanks @maxmad64bis — checking the gate against a number it should reject (7 swapped for 99) is the right way to prove a gate works.
Free Provider Rankings sorted by the top model's Arena score, so a provider stayed first even if it failed every call — the reliability column from #11546 already showed what each one actually served, but ordering ignored it. Adds an opt-in ?sortBy=reliability (API) and a "Most reliable first" toggle (page) sharing one comparator in freeProviderRankingsUsage.ts: measured providers first by successRate desc with ELO on ties, then unmeasured in their incoming order. The default is unchanged and locked by tests. successRate is null below MIN_USAGE_REQUESTS = 5 (existing, never zero), and ordering runs before slice(0, limit) so limit counts in the requested order. The toggle composes with the existing sortTypeFirst/groupByType grouping — a stable sort keeps reliability order within each group. Opt-in is the right default here: the page is for discovery, including providers never called. 13 tests across three files (6 new for the comparator in isolation, plus filter and route coverage including unknown sortBy → 400 and the default path staying off call_logs). Verified in a combined batch worktree with all 11 PRs of this batch: 174/174 focused tests, typecheck:core clean, complexity 2706/3218, cognitive-complexity 1221/1437, check:cycles and check:docs-counts green. The 42-locale i18n pass was checked with the CI gates: check-ui-keys-coverage PASS (all 42 locales at or above 65%) and check-ui-value-drift PASS against the release tip. Thanks @maxmad64bis.
…ready sends (#12320) The Radar feed reports per-model rate limits and whether a provider says it may train on your prompts. Both fields are on RadarMergedEntry and the catalog table rendered neither — grep them in RadarCatalogTable.tsx and the only hits were the type declaration. The training flag is the one that stings: freeModelCatalog.ts documents it as "Surfaced in the UI", a promise the UI did not keep, and thirteen catalog entries carry it today. Adds a Rate limits column and a badge in the ToS cell when a provider discloses training. No new data, no request, no API change. Two judgement calls worth keeping: a limit of zero renders as 0/min rather than formatTokens' "rate-only" (right for a monthly budget, nonsense for a ceiling where zero is a real and alarming fact), and the badge condition is === true, since an absent training statement is not a guarantee. Validation note — read before trusting the green: this PR's own suite (tests/unit/dashboard/radar-catalog-table-limits-training.test.tsx, 14 cases) could NOT be run locally. Vitest fails to resolve react18-json-view, which is declared in package.json and package-lock.json but is not present in this machine's node_modules; two pre-existing .test.tsx files in the same directory fail identically, so the cause is environmental and not this PR. The blocking test-vitest CI job runs npm ci and will execute it. What was verified locally, in a combined batch worktree with all 11 PRs of this batch: 174/174 node-runner focused tests, typecheck:core clean, complexity 2706/3218, cognitive-complexity 1221/1437, check:cycles and check:docs-counts green, plus both CI i18n gates for the 42-locale pass — check-ui-keys-coverage PASS (all 42 locales at or above 65%) and check-ui-value-drift PASS against the release tip. Thanks @maxmad64bis.
…checks (#12232) When fetching version metadata from npm registry or GitHub APIs, if the remote connection stalls during stream reading, the 10-second AbortController timer aborts the request signal but the underlying body reader stream was not listening to the abort signal. This caused readBoundedJson reader.read() loop to hang until external socket close. Now readBoundedJson listens to AbortSignal abort events, triggers reader.cancel(), and releases locks immediately on abort.
…it (#12177) * fix(combos): send null to clear an agent feature instead of omitting it PUT /api/combos/[id] merges its body over the stored record, so an omitted field means "leave unchanged". The combos editor deleted a cleared agent feature from the payload, so unchecking context cache protection -- or emptying the system message or the tool filter -- never persisted: the old value survived the merge and the editor reopened with the toggle still on. updateCombo already deletes any key explicitly set to null, which is how description and context_length are cleared in the same save handler. Use the same shape for the three agent fields, and make them nullable in updateComboSchema so the null survives validation. The clearing logic moves into comboAgentFeatures.ts so it can be tested directly, matching comboQuotaOnlyFallback.ts next to it. Fixes #12158 * chore(changelog): point the fragment at the real PR number
Atualizaçao link global do Grupo 2 Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…heckComboVision (#12112) (#12169) * fix(guardrails): pass providerId to getResolvedModelCapabilities in checkComboVision (#12112) Signed-off-by: Minxi Hou <houminxi@gmail.com> * chore(quality): register combo-vision providerId test in the stryker tap set --------- Signed-off-by: Minxi Hou <houminxi@gmail.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…12224) * feat(providers): manual "Clear cooldown" action in the cooling panel The persisted 429 cooldown (provider_connections.rate_limited_until) is OmniRoute's local lesson, not upstream truth. When a quota has already refreshed upstream (daily/weekly reset, provider-side fix), the only automatic clear paths — Test-button success or Edit-modal key re-validation — still require an upstream round-trip, so the user waits out a bench that is already stale. Adds a per-row "Clear cooldown" button to CoolingConnectionsPanel that PUTs rateLimitedUntil: null (the route applies backoff reset defaults), optimistically drops the bench, and refetches. The next request becomes the real test of the key. - useProviderConnections: handleClearCooldown + clearingCooldownId (in-flight guard mirrors the retestingId pattern) - CoolingConnectionsPanel: optional onClearCooldown/clearingCooldownId props; button hidden for id-less rows, disabled per-row while clearing - ProviderDetailPageClient: wires the new handler through - i18n: en.json keys (clearCooldown, cooldownCleared, failedClearCooldown, ...) with providerText fallbacks Tests: CoolingConnectionsPanel.test.tsx — click fires handler with the row id, disabled + silent while in flight, per-row independence, read-only when handler omitted, no button without connection id, renders nothing when empty. Pre-existing tests/unit/ui/CoolingConnectionsPanel.test.tsx stays green. * fix(dashboard): dedupe clear-cooldown i18n keys and extract the row button The providers namespace already carried an (orphaned) clearCooldown / cooldownCleared / failedClearCooldown key trio, so the new feature keys re-declared them as duplicate JSON keys ~1200 lines apart. JSON.parse is last-wins, which silently shadowed the older values and broke ICU placeholder parity in every locale (EN lost {model} while all 42 translations still carry it). Rename the feature's five keys to a connection-scoped family instead: clearConnectionCooldown / clearConnectionCooldownInProgress / clearConnectionCooldownTitle / connectionCooldownCleared / failedClearConnectionCooldown Also extract the per-row action into ClearCooldownButton so the panel body stays inside the max-lines-per-function ratchet (was 83/80). * feat(dashboard): mirror the clear-cooldown keys into all 42 locales Adds the five connection-cooldown keys to every non-EN catalog with the English value as the runtime fallback (fill-missing-from-en semantics), and real translations for pt-BR and vi so their strict parity suites stay meaningful: pt-BR: Limpar cooldown / Limpando… / Cooldown limpo — a conexão voltou ao roteamento / Falha ao limpar cooldown vi: Xóa thời gian chờ / Đang xóa… / Đã xóa thời gian chờ — kết nối đã tham gia lại định tuyến / Không thể xóa thời gian chờ --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…12317) The weight table said stability accounts for "low latency stdDev / error rate". Grep errorRate in scoring.ts and you find it declared on ProviderCandidate and read nowhere — while combo.ts pulls 24 hours of usage history behind a ten-sample floor, falls back to real-time metrics, and hands every candidate an errorRate the scorer ignores. Two candidates, one failing 1% of calls and one failing 99%, scored identically at 0.459486. This declares reliability as a sixteenth factor: 1 - failureRate, using the same formula, field precedence and rate-bounding speedRanking.ts already applies, so a corrupt reading means "nothing observed" rather than "fails every call". It ships at weight 0, leaving the ranking unchanged to the digit — the honest default, since which weight this deserves is a product call backed by traffic the author does not have. Two declared-but-silent factors already ship (cacheAffinity, resetWindowAffinity), so the pattern is not new. The stability row now describes what that factor actually computes: latency variance. The rest is the mechanical 15 → 16 across nineteen documents and the forty-two llm.txt mirrors — sourced from check:docs-counts rather than a grep, the first real use of the gate #12316 extended. Protected-surface note: this PR touches AGENTS.md, llm.txt and its 42 mirrors, and skills/omni-combos-routing/SKILL.md. Every changed line in those 45 files is a digit substitution and nothing else — masking all digits makes the removed and added lines identical, with no sentence added, removed or reworded. Reviewed and approved on that basis before merging. Verified on the author's rebased head: check:docs-counts green (the gate that now enforces the count this PR moves), typecheck:core clean, and 71/71 focused tests across scoring-reliability-factor, combo-scoring-weights-schema-coverage, check-docs-counts-sync, lkgp-enabled-context, intelligent-routing-options and the combo-matrix auto integration suite. Thanks @maxmad64bis — shipping the factor at weight 0 and saying plainly that the weight is someone else's call is the right way to land this.
#12183) * fix: resolve compression worker file using runtime anchors instead of import.meta.url Replace workerUrl() function that used import.meta.url with resolveWorkerFile() function that uses runtime anchors (process.cwd() and process.argv[1]) to locate the worker file. This fixes webpack module resolution in Next.js standalone bundles where import.meta.url is replaced with a stub pointing to build machine path. Also update Dockerfile to copy required worker-related scripts and adjust npm install flags for better compatibility. * fix(docker): restore base Dockerfile — keep npm ci --ignore-scripts supply-chain guard Revert every Dockerfile change from this branch back to release/v3.8.51: the branch dropped --ignore-scripts (reopening install-time script execution for all transitive deps), swapped the reproducible npm ci for npm install, invoked the nonexistent 'npm approve-scripts' command, and broke the better-sqlite3 smoke test with a stray space in ':memory: '. The worker-file fix does not need any Dockerfile change. * test(compression): export runtime-anchor helpers and cover worker-file resolution firstAncestorWith's doc already claimed 'exported for tests' without the export; export it together with resolveWorkerFile and add unit coverage for the runtime-anchor resolution: cwd anchor, dirname(argv[1]) anchor, bounded walk-up (8-level cap boundary), prod-first .js-over-.ts ordering, dev .ts fallback and the fail-open cwd fallback when nothing exists. Fixtures live in mkdtemp sandboxes only — the repo tree is never touched. --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…t of dependabot groups (#12329) onnxruntime-node only ever moves paired with @huggingface/transformers (already frozen, #9962/#4050) — a solo bump breaks the single-copy ABI contract test and reds every production-group PR. eslint-plugin-react-hooks stays pinned to 7.0.1 by a contract test until the 7.1.1 rule set is adopted in its own PR (the #12146 migration completed today, so that adoption is now unblocked).
…12214) The provider plugin manifest already exposed usage-fetch (40 providers, #11903); this publishes the second capability, usage-supported, so integrators can tell without reading TypeScript whether the server usage routes accept a provider. #11903 closed #11722 after shipping only half of it and said so at the time — this is the follow-up it promised. The two scopes genuinely differ and the docs now say how: usage-fetch resolves on id or alias (the dispatcher accepts both), usage-supported on id alone, because the runtime guard does a plain USAGE_SUPPORTED_PROVIDERS.includes(providerId) with no alias resolution. 42 providers carry both tags, 4 carry only usage-fetch (opencode, opencode-zen, openrouter, xai) and 3 only usage-supported (adobe-firefly, firefly, xiaomi-mimo-token-plan) — 7 measured differences, so neither tag implies the other. No list mutation, no new route, schemaVersion stays 1. USAGE_SUPPORTED_PROVIDERS moved out of src/shared/constants/providers.ts into an import-free leaf at open-sse/services/usage/supportedProviders.ts, keeping the manifest's import graph light — the same move fetcherProviders.ts got in #11903, landed on the correct side of the workspace boundary. Base note: the branch forked 46 commits before kilocode joined the list, so a wholesale take of its providers.ts would have silently dropped that id. Verified against the current release tip before merging — both sides hold the same 46 ids, nothing lost. Verified on the current tip: typecheck:core clean, check:cycles OK across 417 files (the import-free-leaf claim holds), and 63/63 focused tests across provider-plugin-manifest, usage-fetcher-registration-coverage, adobe-firefly and agentrouter-quota-dashboard-rendering. Thanks @maxmad64bis — and for finishing the half of #11722 that was left open rather than letting it sit.
…e regression + radarPage i18n keys (#12327) * fix(sse): forward the upstream's real trailing usage in passthrough; estimate only at flush #12151 injected estimated usage into the finish chunk and dropped the real trailing usage block that genuine OpenAI upstreams send afterwards — metered clients got estimates instead of real token counts. The estimate now leaves via a canonical usage-only chunk at flush, only when the upstream stayed silent; a real trailing block is forwarded verbatim and wins. The tool_calls finish_reason normalization now materializes its own rewrite (it piggybacked on the removed finish-time rewrite), and the dead collectSSE helper goes with it (subsumes #12324). * fix(i18n): seed the radarPage limits/training keys the #12320 UI already consumes RadarCatalogTable.tsx references radarPage.colLimits / trainsOnPrompts / trainsOnPromptsHelp but #12320 never added them to en.json, so the EN fallback could not resolve the __MISSING__ markers across 42 locales. Real translations for pt-BR and vi; the rest resolve via the EN fallback. * fix(sse): carry the chat stream id into flush-time synthetic chunks The estimated usage-only chunk emitted at flush used passthroughResponsesId, which is only ever set on the Responses path — on the chat path the synthetic chunk shipped id: null, breaking the string-id invariant pinned by stream-numeric-ids.test.ts. Track the upstream chat-completion id in the passthrough loop and reuse it (falling back to the Responses id, then a generated one). Sibling sweep: 74 files importing utils/stream — 603/603.
* feat(radar): explain access rules before opt-in * docs(radar): pin D32 evidence boundary * chore(changelog): number Radar D32 fragment * fix(radar): clarify single-use account scope * fix(radar): use a reliable activation icon * fix(radar): complete Vietnamese D32 copy * fix(radar): mark stale D32 locale copy
…tion, CI loader parity (#8084 D1) (#12353) - test:scoped:full (documented in the script header since #9143 but never wired) rebuilds config/quality/test-impact-map.json and then selects. - select-impacted-tests.mjs gains --stdin so --staged selects from the index; the git-diff path only ever saw commits, so staged-only runs silently fell back to the heuristic. - Loader parity with npm run test:unit / quality.yml TIA step (#6787): tests/unit/dashboard/** under --import tsx (CJS transform), tests/unit/serial/** at --test-concurrency=1, the rest under tsx/esm. The single tsx/esm invocation false-redded every dashboard test the map selected ("Unexpected token 'export'"). - CONTRIBUTING.md → Running Tests documents the three modes and the fail-safe exit 1. Refs #8084
… (2.3/2.4/2.8/2.11/2.12, #12270, #12271) (#12393) * feat(dashboard): orchestration pure snapshot filter (search + chips) * feat(dashboard): orchestration collapse-by-source in flow projection * refactor(dashboard): orchestration model polish (#12271 model items) * feat(dashboard): theme-aware orchestration status tokens (2.12) * feat(dashboard): particle StatusEdge for orchestration canvas (2.11) * feat(dashboard): orchestration search/filter chips + collapse in URL (2.3+2.4) * feat(dashboard): drawer trace copy + error/a11y hardening (2.8, #12270) * chore(dashboard): orchestration UI hardening (#12270) * fix(dashboard): type-safe source read in AgentsTab collapse handler * fix(dashboard): pass staleSince into the sourceStale message * test(dashboard): orchestration missing coverage + fase2 i18n (#12271) * refactor(dashboard): split orchestration page/toolbar/drawer helpers under complexity ratchet --------- Co-authored-by: Markus Hartung <diegosouzapw@users.noreply.github.com>
OpenCode Zen/Go uses x-opencode-session as the sticky-routing key so consecutive requests of one coding session land on the same upstream provider instance and reuse its prompt prefix cache. Forward this single client header (length-capped, exact-name match) so third-party agents behind a gateway get the same cache affinity as native OpenCode clients. No other client header is forwarded.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Forward the
x-opencode-sessionclient header to upstream providers inBaseExecutor.buildHeaders.Why
OpenCode Zen/Go uses
x-opencode-sessionas the sticky-routing key: requests sharing the same session id are routed to the same upstream provider instance, which is what makes upstream prompt-prefix cache hits possible (OpenCode's own docs ask clients to send "a stable session ID per conversation").Today
buildHeaders()discards all client headers (void clientHeaders), so any third-party coding agent behind a gateway/proxy — even one that faithfully sends the header, as the docs recommend — loses this cache affinity. Every request can land on a different upstream instance, defeating upstream prompt caching and inflating cost/latency.How
x-opencode-sessionTesting
buildHeadersclient-header behavior; happy to add a unit test if preferredSupersession note: none. First-time contributor.
🤖 Generated with Claude Code