Editing a combo did not invalidate the 10s nested-combo expansion caches
(chat.ts getCombosCachedForChat + chatCore.ts getCombosCached; the exported
clearCombosCache was dead code), so a removed nested target/model could be
served as a phantom for up to 10s. Wire a shared monotonic combos-cache
version in readCache (bumped by invalidateDbCache("combos") on every combo
write); both cache layers treat a version mismatch as a miss.
Also log the resolved DATA_DIR/SQLITE_FILE absolute path at DB init so the
reporter's 'persists across restart + volume wipe' symptom (a multi-replica
Docker volume/DATA_DIR mismatch, not a routing bug) is diagnosable from logs.
Includes consolidated CHANGELOG entries for #3133/#3136/#3007/#3141/#3120/#3121.
Co-authored-by: ViFigueiredo <ViFigueiredo@users.noreply.github.com>
The github (Copilot) provider had a static hardcoded catalog with no
discovery source, so Import Models never refreshed (#3120) and advertised
non-entitled models that 400 on use (#3121). Add a live /models fetch with
fallback to the static list.
Co-authored-by: gabrielmoreira <gabrielmoreira@users.noreply.github.com>
MiniMax-M3 had no MODEL_SPECS entry and capitalized MiniMax-M2.7 missed
its lowercase spec (case-sensitive lookup) → both fell to the 8192 default
cap. Add the M3 spec (512K output), alias the capitalized ids, and make
getModelSpec lookups case-insensitive.
Co-authored-by: totaltube <totaltube@users.noreply.github.com>
Assign unique aliases to HuggingChat, Kimi Web, and Qwen Web so they no longer shadow primary providers or trigger startup warnings.
Add a unit test to enforce provider alias uniqueness and prevent future collisions. Also expand local ignore and VS Code exclude rules for agent, build, and worktree artifacts.
Kiro (AWS CodeWhisperer) tops out at Claude Opus 4.7 in the registry, but the latest Opus 4.8 is already served by the Claude Code provider and Kiro's executor passes the model id through to CodeWhisperer verbatim. Expose claude-opus-4.8 on the kiro provider so clients can select it via kiro/claude-opus-4.8.
- providerRegistry: add claude-opus-4.8 (1M context, 128k output) above 4.7
- pricing: add claude-opus-4.8 (and the previously-missing 4.7) to the kiro pricing block at Kiro's standard Opus rate so usage cost is non-zero
- tests: assert kiro exposes claude-opus-4.8 with matching context/output + pricing
The webpack build failed: route.ts imported '../internal/codex-responses-ws/
modelResolution' (resolves to api/v1/internal/, which doesn't exist). The module
lives at api/internal/codex-responses-ws/. Switched to the @/app/api/... alias.
typecheck/tests passed (tsx resolves leniently; tests import the module directly),
only the production build caught it.
* feat(providers): implement bulk paste for extra API keys
Adds `parseExtraApiKeys` utility to process multi-line key inputs.
Integrates bulk paste functionality into the provider connection modal.
Users can now paste multiple API keys, one per line, into the input field.
Provides notifications for successfully added keys and ignored duplicates.
Adds a "Delete all" button to clear all extra API keys.
Updates i18n messages for new features and improved key masking/pluralization.
* refactor(providers): streamline API key bulk paste and i18n
Remove unused return from `handleAddParsedExtraKeys` to clean up code.
Adjust `onPaste` to allow default paste for single-line input, improving UX.
Remove obsolete bulk paste UI translation keys to reduce bundle size.
Update pluralization for bulk paste messages to ensure correct grammar.
Refine Portuguese (Brazil) API key translations for clarity.
* fix(logs): apply code review feedback - robust signature, immediate fetch on tab restore, reuse memoized apiKeyCount
* test(logs): extract pure polling/signature helpers + cover them (#3109)
Hard rule #8: the perf fix touched src/ without tests. Extract computeLogsSignature,
shouldAutoRefresh and resolveInitialVisibility into a pure module and unit-test
them (change-detection, first-page polling guard, SSR/hidden-tab visibility init).
Also fixes visibleRef to honor the real visibilityState on mount instead of
hardcoding true (no poll when mounted in a hidden tab).
---------
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
* fix(cli): handle Windows exe healthchecks with spaces
* Update src/shared/services/cliRuntime.ts
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
* Update tests/unit/cli-runtime-extended.test.ts
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
* fix(cli): pass command to spawn unquoted; export shouldUseShellForCommand
Remove the manual "${command}" interpolation into the shell command (hard rule
#13 violation, and redundant — Node quotes for cmd.exe when shell:true; .exe runs
with shell:false where the OS handles spaces via argv). Export the helper and add
a cross-platform test asserting non-Windows never uses the shell.
---------
Co-authored-by: Empire Rider <anuruddhawijesiri@gmail.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
* fix(sse): bound Antigravity short-retry 429 loop per endpoint
A persistent 429 on the short-retry branch (retryAfterMs ≤ 60s) looped
forever on the same endpoint because the branch did `urlIndex--; continue`
without checking the shared retry counter. Production log showed 77
consecutive 429s on one daily endpoint/account with zero fallback.
Gate the short-retry branch on `retryAttemptsByUrl[urlIndex] < MAX_AUTO_RETRIES`
(mirroring the already-bounded sibling), so a persistent 429 retries at most
3× per endpoint across all 3 base URLs then returns the 429 to the account-
fallback layer.
Regression test: 'bounds a persistent short-retry 429' in
tests/unit/executor-antigravity.test.ts — asserts 12 total attempts
(3 endpoints × 4) and a returned 429 with zero hang.
* fix(sse): lock Antigravity quota-exhausted account for full reset window
After the retry-loop bound, OmniRoute fell over to the next account but
re-selected the exhausted one first on every subsequent request (~60s wasted
per request). Root cause: the 429 body 'Individual quota reached. Contact
your administrator to enable overages. Resets in 164h27m24s.' was not
recognized as quota exhaustion, so the model was locked for only ~5s instead
of the real 6.8-day reset window.
Two detector fixes (mirrors Antigravity-Manager rate_limit.rs set_lockout_until):
1. classify429.ts — add QUOTA_PATTERNS: /individual quota reached/i,
/quota reached/i, /enable overages/i so looksLikeQuotaExhausted() fires.
2. accountFallback.ts — same patterns in classifyErrorText(); extend
parseRetryFromErrorText() to parse 'Resets? in XhYmZs' (reusing the
existing computeDurationMs helper) so the exact reset duration reaches
recordModelLockoutFailure as exactCooldownMs (uncapped, per user choice).
The lockout machinery already stores until = now + cooldownMs with no clamp,
bypasses getScaledCooldown when exactCooldownMs > 0, and keeps the longer of
existing/new, so the full 164h window flows through intact.
New patterns stay specific — plain 'too many requests'/'rate limit exceeded'
messages still classify as rate_limit.
Verified end-to-end against the real message:
- classify429 → quota_exhausted
- parseRetryFromErrorText → 592044000 ms (164h27m24s exactly)
- checkFallbackError → usedUpstreamRetryHint: true, cooldownMs: 592044000
* refactor(account-fallback): simplify error parsing and add cooldown safety
- Implement a 30-day cap on parsed retry durations to prevent indefinite account lockouts.
- Replace manual string matching with `looksLikeQuotaExhausted` for more robust quota detection.
- Streamline regex logic in `parseRetryFromErrorText` for better readability.
- Add unit tests for extreme cooldown values and free-tier exhaustion scenarios.
* fix(429): drop over-broad /quota reached/ pattern, keep specific matches
The bare /quota reached/ would also flag transient per-minute limits like
'request quota reached, retry in 60s' as quota_exhausted (multi-hour lock).
The Antigravity message is still caught by /individual quota reached/. Added a
regression assertion proving the transient case stays a rate_limit.
---------
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
When the Codex CLI falls back from WebSocket to HTTP (after 1008 Policy
Violation or reconnect exhaustion), it POSTs to /v1/responses with the
bare model id it was configured with (e.g. "gpt-5.5") — never the
provider-prefixed form. OmniRoute's normal routing resolved that bare id
to openrouter, not codex, producing:
"No credentials for provider: openrouter"
Fix: add resolveResponsesApiModel() (extending modelResolution.ts) and
call it in /v1/responses before delegating to handleChat. The function
applies the same codex-preference logic as resolveCodexWsModelInfo:
bare "gpt-5.5" → codex/gpt-5.5 has a codex provider → rewrite ✅
bare "gpt-4o" → codex/gpt-4o not in registry → pass through ✅
"anthropic/x" → has "/" → skip resolution → pass through ✅
Errors are caught; original request is returned on any failure.
8 unit tests added (TDD — watched each fail before implementing).
Refs: openai/codex#15492, openai/codex#13041, openai/codex#13039
zh-CN and ru were each missing 9 whole sections (~823 keys: quotaPlans, activity, agentBridge, trafficInspector, cliCommon, cliCode, cliAgents, acpAgents, agentSkills) added after the last sweep, so those UI strings fell back to English. Filled via the canonical i18n sync+translate pipeline (scripts/i18n/sync-ui-keys.mjs --translate-markers). Both catalogs are now at full key parity with en.json (70 sections / 8025 keys), 0 __MISSING__ markers, valid JSON, Prettier-clean.
The provider Playground (LlmChatCard) only added the providerId/ prefix to models without a slash, so vendor-namespaced ids (moonshotai/kimi-k2.6, nvidia/zyphra/...) were sent bare and rejected with 'Ambiguous model' when the same id exists under multiple providers. Extracted qualifyPlaygroundModel() which always prefixes with the provider unless already qualified. Bug 1 ('unhashable type: dict') is an upstream NVIDIA NIM server error, not OmniRoute. Tests: 4 cases for the qualifier.
createProviderConnection deduped apikey connections only by (provider, name). Adding the same key under a different/blank name created a duplicate row. It now also matches by the decrypted key value (AES-GCM ciphertext is non-deterministic, so we decrypt+compare plaintext, trimmed) and updates the existing connection instead. Tests cover same-key dedup, whitespace-variant dedup, and distinct-key separation.
No-auth providers (OpenCode Free) have no connection row, so handleImportModels returned early and /api/providers/[id]/models 404'd — the import button silently no-op'd. The route now serves the provider's registry/static model catalog when called with a no-auth provider id, and handleImportModels falls back to the provider id when there is no connection. Test: route returns the opencode catalog (source local_catalog) and still 404s for unknown ids.
grok-web only sent the 'sso' cookie; Grok's anti-bot now rejects (403 code 7) requests missing the paired 'sso-rw' write cookie. Adds buildGrokCookieHeader() which emits sso plus sso-rw when the pasted blob carries it (never a phantom sso-rw from a bare value), used by both the executor and the connection validator. Updates the grok-web authHint. Tests: 6 new buildGrokCookieHeader cases; grok-web 62/62 unchanged.
A per-model subscription/permission 403 from a passthrough provider (hasPerModelQuota) now locks only the failing model instead of cooling the whole connection, so free models on the same key keep serving and repeated paid-model 403s don't escalate a connection-wide backoff. Generalizes the grok-web 403 precedent; terminal/credential 403s still deactivate the connection (guarded by resolveTerminalConnectionStatus). TDD: 3 tests in sse-auth.test.ts (2 reproductions fail pre-fix, regression guard passes both ways).
Implements per-API-key context source configuration table and CRUD
functions required by the Obsidian PR. Restores getApiKeyContextSource
in obsidian.ts (was stubbed to null during conflict resolution).
11/11 tests pass in obsidian-config.test.ts.
Add a global OMNIROUTE_CODEX_WS_ENABLED kill-switch for Codex WebSocket transport, defaulting to enabled if feature flag lookup fails.
Track Xiaomi MiMo monthly token usage from OmniRoute usage history and expose it through the usage fetcher provider list.
Support MiniMax Coding Plan quota responses that expose remaining usage as
percentages instead of request counts, including the text quota surfaced under
the `general` model.
Also document Codex CLI WebSocket configuration, clarifying that bare ChatGPT
model ids must be used instead of `codex/`-prefixed ids.
Quality Gate was failing on New Code with 1 hotspot, 1 vulnerability and
4 reliability bugs. Resolved each at the source (no SonarCloud mark-as-safe):
Reliability (4 bugs → rating back to A):
- usage.ts: drop duplicate `case "opencode-go"` (S1862) — the 2nd case was
dead (first match wins) and would have called the wrong usage fetcher.
Also de-duplicate the same id in USAGE_FETCHER_PROVIDERS (mirrors the switch;
prevented a double quota-fetcher registration).
- ApiManagerPageClient.tsx: a dangling `.find(...)?.timestamp || null` expression
(S905) discarded the better matcher — `lastUsed` silently lost the
name-fallback for legacy logs without apiKeyId. Assign the complete matcher.
- chat.ts / auth.ts: `Promise` used in a boolean conditional (S6544). Both are
intentional (memoized promise / mutex default), not a forgotten await —
made the intent explicit via `!== null` and `??` (behaviour identical).
Security (vulnerability → rating back to A):
- nvidia-startswith-diag.ts: neutralize CR/LF before logging env-derived
values (S5145 log injection) in the ad-hoc diagnostic script.
Security Hotspot (reviewed → 0 open):
- pluginWorker.ts uses `vm.runInContext` to run plugin code — that IS the
worker's purpose, inside a hardened vm sandbox (createContext, require
allow-list of just `crypto`, 10s timeout); not eval/new Function. Suppress
S1523 scoped only to pluginWorker.ts in sonar-project.properties, with the
same documented-justification pattern as the existing hotspot suppressions.
In checkModelAvailable and handleSingleModelChat, when the combo target's
providerId is merely the prefix already encoded in the model string (e.g. "p2"
from "p2/test-model"), prefer the fully-resolved provider (e.g. the generated
custom node id openai-compatible-chat-e2e-p2) so the executor resolves the
custom baseUrl from the connection instead of falling back to the base provider
(real openai). Intentional providerId overrides (providerId not encoded in the
model string) are preserved.
Also fixes the resilience-http-e2e combo tests (cooldown window + DB-write
visibility for the cooled-down-primary skip).
The "recent" memory strategy maps to the internal "exact" retrieval path, whose
post-query relevance filter (score > 0) silently dropped recent memories whose
text didn't overlap the current prompt. Since the user-facing strategy enum is
only recent|semantic|hybrid (no "exact"), forwarding the prompt as `query` for
"recent" always engaged that filter, so recency-based injection returned nothing
when the prompt was unrelated to the stored memory.
Skip query forwarding for the "recent" strategy so retrieveMemories returns the
most recent memories (ORDER BY created_at DESC) regardless of prompt overlap.
Semantic/hybrid still forward the query for vector search.
Fixes the chat-pipeline + memory-pipeline integration memory-injection tests.
Back-merge to resolve PR #2930 (release/v3.8.8 -> main) conflicts. Release is a
superset of main's features, so all ~44 content conflicts resolved to the
release ("ours") version; generated .source/* dropped.
Reconciliation:
- auth.ts: port #3058 (getProviderSearchPool expands custom provider_nodes
prefixes to internal connection ids) — release lacked this main fix.
- quota-plan-registry.test.ts: align knownProviders() 6 -> 10 (pre-existing
stale assertion vs the registry).
Addresses findings from the multi-agent PR review of the #3066 fix:
- manager.stub.ts comments: the previous inline comment claimed the throwing ops
(getMitmStatus/startMitm/stopMitm) are "dynamic-import paths that should never hit
the stub at runtime" — factually wrong: those are static imports too, baked into the
bundled build just like getAllAgentsStatus. Rewrote the file header to describe the
real split — exports with a safe degraded value return it (getCachedPassword/
setCachedPassword/clearCachedPassword → null/no-op, getAllAgentsStatus → []) while
getMitmStatus/startMitm/stopMitm throw STUB_ERROR — and trimmed the inline comment.
Comment-only; no runtime/build change (the export still exists).
- stub-drift guard test: now scans ALL of src/ instead of only src/app —
src/lib/tailscaleTunnel.ts statically imports getCachedPassword/setCachedPassword
from @/mitm/manager and is pulled into routes transitively, so the src/app-only scan
had a false-negative blind spot. Also skips inline `type` imports (erased at build,
need no runtime export) and detects stub exports from declaration AND `export { … }`
forms (no false-positive if the stub later uses class/re-export).
Verified: next-config suite 4/4, typecheck:core / lint clean.
Follow-up to 146244b8f (#3066), addressing optional review suggestions:
- manager.stub.ts: getAllAgentsStatus now returns [] (the truthful "no agents"
state, type-faithful) instead of throwing. Unlike the dynamic-import heavy ops,
this is a STATIC import baked into the Turbopack/bundled build, so it is
legitimately reached at runtime there — returning an empty list degrades
gracefully instead of erroring. (Functionally inert for the existing
agent-bridge/state route, where getMitmStatus already rejects first.)
- next-config.test.ts: the stub-drift guard no longer hard-asserts a specific
symbol (getAllAgentsStatus); the generic ">=1 import found" sanity plus the
missing-exports check remain, so the guard survives an agent-bridge /
traffic-inspector route being renamed or removed.
typecheck:core / lint / next-config suite (4/4) clean. The export still exists,
so the Turbopack build resolution is unchanged.
The Docker image build (`docker compose --profile cli build`) runs `next build`
with OMNIROUTE_USE_TURBOPACK=1 and failed with two Turbopack errors that the
webpack-based VM build never hits — which is why the VM deploy validated but the
Docker build errored (#3066). The reporter's log was truncated before the real
errors; reproducing `OMNIROUTE_USE_TURBOPACK=1 npm run build` locally surfaced them:
1. node_modules/sqlite-vec-linux-x64/vec0.so — "Unknown module type". sqlite-vec
ships a native vec0.so loaded at runtime via createRequire(); Turbopack tried to
bundle the .so. Fixed by adding "sqlite-vec" to serverExternalPackages, exactly
like better-sqlite3.
2. /api/tools/agent-bridge/state statically imports getAllAgentsStatus from
@/mitm/manager, which next.config aliases to manager.stub.ts for the Turbopack
build. The stub did not export getAllAgentsStatus → "Export getAllAgentsStatus
doesn't exist in target module". Added the export (throws like the other heavy
ops — MITM/agent-bridge is non-functional in the bundled build anyway).
Tests (tests/unit/next-config.test.ts):
- assert sqlite-vec is in serverExternalPackages.
- new guard: manager.stub.ts must export every name statically imported from
@/mitm/manager across src/app (catches stub/manager drift — would have caught this).
Verified: OMNIROUTE_USE_TURBOPACK=1 npm run build → EXIT 0 (was: Build error
occurred); webpack build → EXIT 0; typecheck:core / check:cycles / lint clean.
Fixes#3066
Symptom: freshly-added Codex accounts (e.g. davi/gabriel) showed "No quota data"
even when healthy. Root cause: the quota path reuses the access_token without
refreshing rotating providers (#3019, anti Auth0 family-revocation cascade), so a
Codex account whose short-lived access_token has expired can never surface quota
from the sync — the live fetch returns "Codex token expired".
Fix (opt-in, cascade-safe):
- refreshAndUpdateCredentials gains `allowRotatingRefresh` + a pure exported gate
`shouldAttemptRotatingRefresh`. The actual token mint is wrapped in
`serializeRefresh` (one refresh at a time per Auth0 rotation group) — so even N
concurrent per-account requests can never refresh siblings in parallel.
- The BULK scheduler (syncAllProviderLimits, concurrent) keeps the flag OFF →
#3019 fully preserved (guardian test codex-quota-sync-no-proactive-refresh stays
green). Only the on-demand, per-connection path (`GET /api/usage/[connectionId]`)
opts in.
- Frontend: the quota page auto-fetches LIVE on open for the VISIBLE connections
that have no cached quota (scoped to what's on screen — not all connections —
and skips entries already cached), so expired-token Codex accounts surface real
quota automatically and cascade-safely.
Adds unit coverage for the gate (bulk skips rotating, on-demand allows; non-rotating
always eligible). typecheck / lint clean.
The quota-sync path deliberately reuses a rotating-refresh provider's (Codex/
OpenAI/Claude — see refreshSerializer ROTATION_LOCK_GROUP) access_token WITHOUT
proactively refreshing it (#3019, to avoid the Auth0 family-revocation cascade).
When that token is expired the codex usage fetch returns "token expired", and
syncExpiredStatusIfNeeded then flagged the connection testStatus="expired" — a
false-negative: the credential is still valid (expires_at in the future) and the
reactive serialized 401 path refreshes the access_token on next use.
Symptom: freshly-added Codex accounts showed "expired" with no quota on the
quota page, while a providers-page refresh turned them green. They never lost
access — only the quota sync mislabeled them.
Fix: extract the decision into the pure, exported `quotaPathShouldMarkExpired()`
and skip rotating providers (rotationGroupFor !== null). Their status is owned by
the reactive path / connection test, never the quota sync. Adds unit coverage.
E2E testing on the VPS showed a normal key (empty allowedQuotas) could call a
qtSd/<group>/<provider>/<model> virtual model and route through a shared quota
pool — because the quota-exclusive enforcement (Check 3) only ran when
allowedQuotas was non-empty, so an unallocated key fell through to the normal
model checks and qtSd was served. This is the "empty allowedQuotas = all pools"
gap from the redesign.
Add Check 2.9 in enforceApiKeyPolicy: if the requested model is a qtSd model and
the key is NOT allocated to any quota pool (allowedQuotas empty), reject 403
QUOTA_NOT_ALLOCATED. Allocated keys are unchanged (Check 3 still validates scope).
This matches the owner's rule: only a key selected in a pool may use its qtSd
models. Normal (non-qtSd) model access for normal keys is unchanged.
Test: tests/unit/apikeypolicy-quota-only.test.ts — new case asserts a non-quota
key is blocked from qtSd (QUOTA_NOT_ALLOCATED) yet still uses normal models.
The key list stacked many badges in one column (tall/cluttered) and didn't
distinguish quota keys. Now renders two sections — "Normal keys" and "Quota keys"
(purple QUOTA pill) — sharing the same compact table header via an extracted
renderKeyRow(). Quota rows prepend a qtSd-only mode chip + group-name chips
(resolved by fetching /api/quota/pools + /api/quota/groups → poolId→group map).
Empty sections are hidden. i18n en/pt-BR for the new labels.
Source-scan test + i18n parity in api-manager-quota-keys-section.test.ts.
