* build(docker): make the bundler build-arg actually take effect
A bare ENV shadows a same-named ARG for the rest of the stage, so
--build-arg OMNIROUTE_USE_TURBOPACK=0 was silently ignored and the
webpack escape hatch the surrounding comment advertises only ever
worked through -e at runtime, never at build time.
That mattered because Turbopack compiles in native Rust memory living
outside the V8 heap, so OMNIROUTE_BUILD_MEMORY_MB cannot bound it. A
build host with a memory ceiling gets SIGKILLed by the cgroup OOM
killer with no error text at all, which reads like a hung build rather
than an out-of-memory one.
* docs(docker): correct the builder stage facts and document its cost
The stage table described a builder that no longer exists: it named
node:24.15.0-trixie-slim where every stage now derives from
node:26-trixie-slim, and said the stage runs `npm run build -- --webpack`
where it runs plain `npm run build`, which is Turbopack by default.
That second one is worse than stale. A reader who needs the webpack
fallback would conclude the Docker build already uses it and never look
for the switch.
Adds a Build-time resources section covering the two build args, why the
V8 heap arg cannot bound Turbopack, and measured ceilings for both
bundlers. The runtime paragraphs that followed get their own heading so
they no longer read as part of the build-time story.
* docs(docker): correct the runtime heap defaults
Same drift as the builder stage, in the paragraphs just below it. The
image exports OMNIROUTE_MEMORY_MB=1024 and derives NODE_OPTIONS from it,
but the guide reported 512 in three places, including the environment
variable table.
The "if unset, the launcher uses 512" line was misleading in both
readings: the image always sets the variable so that branch cannot fire
under Docker, and outside Docker the launcher calibrates from host RAM
rather than using a flat 512.
* docs(changelog): add fragment for #9695
* fix(web-tools): anchor tool contract at prompt tail + user-turn reminder
The <tool> contract from prepareToolMessages was prepended as the first
system message. Web executors fold all system messages into one block, so
with agentic clients whose system prompts exceed ~28K chars the contract
sat at the head of a huge block and web models ignored it, refusing tool
calls with "tool X is not in my tool set" (chatgpt-web, 0/3 at 30K chars).
Two changes, both required in testing:
- Dual placement: the full contract now rides as a trailing system
message (folds to the tail of the system block) and a one-line
reminder naming the tools is appended to the latest user message.
- Rewording: the contract now frames injected tools as client tools
invoked via a plain-text protocol, distinct from the model's native
tool registry (web.run, python.exec, ...), and instructs the model to
never claim they are unavailable. Without this the model resolved
tool names against its native registry and refused even when it had
seen the contract.
Measured on cgpt-web gpt-5.5-thinking/gpt-5.6-thinking/o3: prepend 0/3
tool calls at 30K chars; dual placement 16/17 across 30K-250K system
prompts, 30-tool sets, multi-turn tool history, streaming, and 3-way
concurrency, with no spurious calls on no-tool prompts. Known limit:
~40K-char single user messages still flake (2/3) due to the upstream
model's own injection heuristics.
All prepareToolMessages consumers parse system messages
position-independently and select the current user turn by role scan,
so the trailing system message is shape-safe for every web executor.
* test(web-tools): cover contract placement edge cases
---------
Co-authored-by: Ryan Brosas <ryanjoserbrosas@gmail.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Four of the original six free-catalog model IDs return 400/403/410 from
Workers AI. Remove them from freeModelCatalog + cloudflare-ai registry,
keep the live replacements from #8763, and move the 30M monthlyTokens
budget onto @cf/meta/llama-3.3-70b-instruct-fp8-fast.
Co-authored-by: MumuTW <42820974+MumuTW@users.noreply.github.com>
Add a per-target priority option that advances only after trusted quota exhaustion while preserving retry, nested Combo, quality, and Global Fallback semantics.
* feat(media): add provider-neutral video and music generation
* fix(db): clean audit tables by created timestamp
* fix(media): support Fal-hosted Grok video
* fix(media): route Fal video references to Grok
* fix(media): support Gemini Omni Flash video
* fix(media): use Gemini Omni Flash Fal endpoint
---------
Co-authored-by: rinseaid <rinseaid@rinseaid.net>
* fix(executors): strip redundant oneOf matching sibling enum
The Codex private Responses endpoint intermittently returns a 502 upstream_empty_response for tool parameters that combine oneOf:[{const,...}] with a sibling enum containing the same value set.
When the const and enum sets match exactly, oneOf adds no constraint beyond enum. Add stripRedundantOneOfConstEnum to normalizeCodexTools to remove only this semantically redundant form.
The schema-aware recursive walker requires non-empty, unique string const branches containing annotations only, string enum values, and an exact set match. It preserves bare oneOf[const], narrowing or non-matching sets, type-discriminated oneOf, empty oneOf, non-string values, and anyOf/allOf.
Run the normalization after stripUnsupportedRegexPatterns and before assigning tool.parameters. Add focused regression coverage for matching, non-matching, nested, immutable, and Chat-to-Responses cases.
* docs(changelog): update PR number in changelog fragment
* fix(command-code): normalize malformed tool call arguments and fix test assertion handling
* fix(command-code): resolve toolName from assistant calls and update version header to 1.15.1
* refactor(command-code): consolidate pre-pass message tool metadata extraction and add unknown fallback test
* fix(command-code): fallback unnamed tool calls to unknown to satisfy upstream name validation
* fix(db): rename 139_job_registry -> 143 to avoid collision with 139_ccr_blocks
release/v3.8.50 owns version 139 (ccr_blocks, #9061). The #9631 job
registry cherry-pick (5e5919dcc) landed its migration as 139_job_registry,
recreating the version collision that fix 21a3cb32f had already resolved
on the standalone branch. The migration runner throws on startup, which
makes getDbInstance() fail and every route return 500.
Bump the job registry migration to 143 (next free slot; 140 is taken by
connection_runtime_state) so the runner stops throwing. The SQL is
idempotent (CREATE TABLE IF NOT EXISTS + INSERT OR IGNORE), so DBs that
never applied it just pick it up on next boot; no DB can have recorded
version 139 as job_registry because the collision always threw before
any migration ran.
* fix(command-code): emit arguments on tool-result parts to satisfy /alpha/generate schema
* fix(command-code): rename tool names colliding with upstream built-ins to satisfy /alpha/generate result normalization
The upstream server normalizes tool-call/tool-result parts against its own
built-in registry for matching names. A tool named `tool_search` collides
with a server-side built-in, so the result is rejected mid-stream with
`input[N] missing required field 'arguments'` (verified live: renaming the
pair makes the identical request pass; the server pairs each result with the
nearest preceding tool-call, so any result following such a call is affected).
Rename colliding names consistently on the wire (definitions + calls +
results) via a request-scoped toolNameMap, then un-rename on the response
path so the client still sees its original tool names.
Assess adding a Telegram Mini App chat surface to OmniRoute. Verifies
against current main (918fba5e3) what exists (outbound telegram webhook
integration, bot-token validation + encryption gate) and what is missing
(inbound Bot API listener, WebApp initData HMAC verification, mini app
hosting, per-user API key mapping).
Concludes: feasible with moderate effort (2-4 dev-days for a working
slice). Identifies constraints (public HTTPS webhook, no native
streaming to Telegram, server-side initData trust, encryption gate) and
a phased next-steps plan (spike, minimal chat slice, hardening).
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
copyOpenAICompatibleReasoningFields only stripped the sentinel
(NON_ANTHROPIC_THINKING_PLACEHOLDER = "(prior reasoning summary
unavailable)") from reasoning_content and reasoning. Non-standard
reasoning fields (reasoning_text, thinking, thought) and
reasoning_details items passed through raw, leaking the internal
replay sentinel to clients on providers that use those fields
(e.g. Venice), where the model echo surfaces as a bogus thought block
and can degrade into empty turns.
Strip the sentinel from every forwarded reasoning field, including
per-item text/content inside reasoning_details; drop items/fields that
strip to nothing while preserving non-text details such as
reasoning.encrypted.
Fixes#9765
Refs #8081, #9606
* fix(sse): apply Azure request-param rules on the azure-ai wire path
Azure rejects several stock Chat Completions params on its newer deployments
and returns HTTP 400 rather than ignoring them:
max_tokens -> 'max_tokens' is not supported with this model.
Use 'max_completion_tokens' instead.
reasoning_effort -> Function tools with reasoning_effort are not supported.
Those rules lived inline in AzureOpenAIExecutor, so they only covered the
azure-openai provider. azure-ai (Azure AI Foundry) had no executor entry and
fell through to the bare DefaultExecutor, so the SAME Azure deployment
succeeded on one connection and 400'd on the other. Every agentic client sends
tools on every turn, so azure-ai failed on the first request.
Extract the rules to open-sse/executors/azureParamRules.ts, add an
AzureAiExecutor that inherits DefaultExecutor's azure-ai URL/header/apiType
handling unchanged and applies the shared rules, and register it for azure-ai.
Also widen the deployment pattern to cover gpt-chat-latest: it is a moving
alias that resolves to a GPT-5-era model and rejects max_tokens, but carries no
version number for the token-boundary pattern to key on. Verified against the
base regex - gpt-chat-latest did not match, which is exactly the observed 400.
Regression guard: tests/unit/azure-param-rules.test.ts, including an assertion
that getExecutor("azure-ai") no longer resolves to a bare DefaultExecutor.
* fix(sse): clamp Azure gpt-4o-mini completion tokens to its 16384 ceiling
Azure gpt-4o-mini deployments accept at most 16384 completion tokens and 400 on
anything larger:
max_tokens is too large: 32000. This model supports at most 16384 completion
tokens, whereas you provided 32000.
The 32000 is OmniRoute's own doing: adjustMaxTokens raises any smaller
max_tokens to DEFAULT_MIN_TOKENS (32000) whenever tools are present, to avoid
truncated tool arguments. That floor has no upper bound, so an agentic client
asking for far less still trips the model ceiling on its first turn.
Add scoped maxOutputCap rules in paramSupport.ts for both Azure wire paths.
PROVIDER_MAX_TOKENS is the wrong lever here - it is provider-wide, and the same
Azure resource also serves GPT-5 deployments with a much higher ceiling.
Regression guard: tests/unit/azure-max-output-clamp.test.ts, which also pins
that the clamp does not leak to gpt-5.1 or to gpt-4o-mini on other providers.
Step 1 of the pivot (openai-responses -> openai) flattens namespace sub-tools
to a qualified wire name (#8295) and records the `{namespace, name}` pair on a
non-enumerable `_toolNameMap`. Step 2 (openai -> target) returns a brand-new
object, so the property was dropped for every non-OpenAI target. chatCore then
handed `null` to the #7936 response seam and namespace sub-tool calls reached
the client under their flattened name, which Codex rejects with
`unsupported call: <name>` — the symptom #7936 was opened to fix.
Copying `_toolNameMap` through is not viable: openai-to-claude and
openai-to-gemini publish their own `Map<string, string>` alias map on that same
property during step 2, so it carries two incompatible types. This adds a
dedicated `_namespaceToolIdentityMap`, propagated by translateRequest across
the pivot; chatCore prefers it and falls back to `_toolNameMap` for the
non-pivot producers. Both keys are stripped from the cliproxyapi wire body.
Fixes#9780
The /v1/models catalog mirrors `claude/<provider>/<model>` ids purely from the
alias gate -- ccAliasPredicate.ts consults no provider registry. The request
path additionally required the prefix to be an open-sse REGISTRY entry or an
operator-defined custom node.
Enterprise-cloud providers such as azure-ai / azure-openai live only in the
provider catalog (src/shared/constants/providers/apikey/enterprise-cloud.ts).
They route fine directly -- `azure-ai/Phi-4` returns 200 -- but have no
open-sse registry entry, so the two sides disagreed: the catalog advertised
`claude/azure-ai/<model>` while stripCcDiscoveryAlias refused to strip it.
The unstripped id then fell through to normal resolution, which splits on the
first / and parsed `claude` as the provider. Every Claude Code request for an
Azure model was routed to the Claude provider instead:
ROUTING: Provider: claude, Model: azure-ai/DeepSeek-V4-Flash
Extract the predicate as `isRoutableProviderPrefix()` and widen it to the
provider catalog (id + alias) alongside the open-sse registry, so the request
path recognises exactly what the catalog can advertise.
Regression guard: tests/unit/cc-discovery-alias-routable-prefix.test.ts pins
azure-ai/azure-openai/azure as routable, keeps openai/anthropic routable, and
keeps an unknown prefix non-routable. Verified failing before the widening.
The provider-connection dialog (AddApiKeyModal / EditConnectionModal)
rendered humanized key names instead of real copy for
providers.validationModelId{Label,Placeholder,Hint} in 34 of 43 locales —
the values read "Validation Model Id Label", "Validation Model Id
Placeholder" and "Validation Model Id Hint" verbatim.
Each translation follows the terminology and register already used by the
neighbouring provider keys in its own file — e.g. de Anbieter/API-Schlüssel
with formal Sie, fr fournisseur/clé API, ru провайдер/ключ API — and each
locale's own "e.g." convention (z. B., 例:, напр., ör., cth., hal.).
Source of truth is en.json, which labels the field "Validation Model"
(no "ID"); a few older locales say "validation model ID" and were left
untouched rather than propagating that divergence.
Rebase of PR #9675 onto origin/release/v3.8.50. This feature was already
cherry-picked into the release branch (commit 58f0ff1b41, PR #9873), so the
branch is reconciled to the release tip, resolving the merge conflict without
reintroducing duplicate i18n keys or stray content.
Co-authored-by: Hermes Agent <hermes@hermes-chloe.hyades.io>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(combo): restore routing module load
* fix(db): resolve ccr migration version collision
Renumber the CCR block-store migration from 134 to 139, reconcile databases that already applied the legacy slot, and add regression coverage for both upgrade paths.
Co-Authored-By: GPT-5 <noreply@openai.com>
* fix(test): narrow this branch to the drifted test expectations
Three other PRs already cover what this one was carrying. #9618 renumbers the
colliding ccr_blocks migration, #9632 repairs the malformed aggregator changelog
fragment, and #9676 restores the combo module load by implementing the selection
helper the import was reaching for, rather than deleting the caller the way this
branch did. Keeping any of it here would put two files back on the same migration
slot and overwrite a better fix with a worse one.
What survives is the part none of them touch. Once the combo barrel loads again,
three assertions in the context-window filter suite start failing: they demand
that catalog-too-small targets be dropped, while the file's own header and its
four neighbouring tests say those targets stay available as runtime fallback.
The unresolved import was masking them. A new case pins the output-token limit
as a genuine hard requirement so the relaxation cannot drift further.
The provider count assertion kept one literal at the old value after the rest of
the file moved to 198, so the partition check failed on a sum that was correct.
* fix(release): restore base-relative reconcile to mergeable state
Rebase fix/release-v3850-basereds onto release/v3.8.50 resolving conflicts.
The substantive changes (ccr_blocks renumber #9618, aggregator changelog
well-formedness #9632, combo module load #9676) are already covered on the
release tip. Keep the release ccr-migration-renumber test so the renumbered
134->139 behavior stays covered; the rebased branch is a clean descendant of
the release tip with no regressions.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: alexey.nazarov@softmg.ru <alexey.nazarov@softmg.ru>
Co-authored-by: GPT-5 <noreply@openai.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* feat(db): add a job registry for scheduled background work
Background jobs each ship their own timer today, so there is no list of what
is scheduled, no history of what ran, and no way to pause one without an
environment variable and a restart. The registry gives them one home: a jobs
table holding the schedule, a job_runs table holding the outcomes, and a
loopback-only API to inspect and control both.
Cron jobs read their expression through an optional cronGetter rather than the
stored column, so an operator changing OMNIROUTE_WARMUP_CRON does not need the
row rewritten. register() is an idempotent upsert that refreshes the schedule
but never overwrites `enabled` or `created_at`, which is what lets a job be
re-registered on every boot without discarding the operator's toggle.
Run history is pruned per job rather than globally, and safeRun records a
failure for a handler that throws as well as one that returns success:false,
so a crashing job leaves a trail instead of a gap.
The API is under /api/jobs and gated to loopback in the route guard. It can
trigger a run and flip a job off, which is runtime administration and does not
belong on a remotely reachable surface.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* feat(jobs): move the budget reset and token health check onto the registry
Both jobs owned their own timer and started themselves as an import side effect,
so nothing could report whether they were running, when they last ran, or why a
run failed. They now register with the job registry and are started from it, which
also means their schedule and run history are visible through /api/jobs.
startAll() runs each interval job's first tick synchronously, so both entry points
start the registry only after initializeCloudSync() has been awaited. The old
wiring reached that ordering two different ways: the budget reset was started
after the init call, and the health check's first sweep sat behind a 10s timer.
Replacing both with one startAll() would otherwise have moved the two handlers
in front of the initialisation they run against.
Both entry points also register the same pair of jobs. Registering one and not
the other is how a background job goes missing without anything failing.
sweep() now returns how many connections it swept, so the health check can record
a real records_affected the way the budget reset does. The migration documents
that column as a per-job count, and hardcoding zero would have left one of the two
jobs reporting a number the schema promises but the code never produces. A skipped
or empty sweep reports zero. Every existing caller ignores the return value.
The token health check keeps its own disable semantics: the handler still calls
isHealthCheckDisabled() before sweeping, so OMNIROUTE_DISABLE_TOKEN_HEALTHCHECK,
the production-build phase and the automated-test guard behave as before. Its
registry adapter lives in src/lib/jobs/ next to the budget reset rather than in
tokenHealthCheck.ts, which is already above its frozen size ceiling on the base
branch and should not grow further. The adapter lets a failing sweep throw rather
than reporting it itself, matching the budget reset: safeRun records a thrown
error as a failure run with its message.
The warmup job is seeded disabled. Its handler arrives with the warmup scheduler,
and startAll() filters on enabled before it looks for a handler, so seeding it
enabled here would warn about the missing handler on every boot.
* fix: allowlist cron-parser dep and document OMNIROUTE_RUNNOW_TIMEOUT_MS env var
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
* chore: align rebased branch with release tip (migration renumbered 139->146 in release; feature already cherry-picked in #9886)
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* ci(test): route orphaned Vitest tests through blocking CI
* docs: fix advisory status in AGENTS.md and refresh baseline note
* fix(changelog): fix fragment format for #9415
* fix(changelog): preserve upstream fragment format
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(providers): refuse to store the dashboard password as a connection API key
A browser autofilled the management password into a connection's API-key field.
The resulting credential authenticates against nothing, so every request routed
through that connection came back 401, and because the field looks like any
other password input the same autofill fired again while the connection was
being repaired by hand.
The refusal belongs on the write path rather than in the form. Twenty routes
create or update connections and all of them funnel through
createProviderConnection and updateProviderConnection, so one check there covers
every entry point including a future one. The two other places that write
api_key are left alone on purpose: one re-encrypts rows that already exist and
the other is the one-time db.json import, and neither takes a value an operator
just typed.
Update checks the incoming value, never the merged one. A connection that
already holds the password has to stay editable or the operator cannot repair
the exact state this prevents, and re-checking the merged value would spend a
bcrypt round on every unrelated field edit.
Only a real match blocks the write. An unreadable settings row or a throwing
bcrypt call logs and allows, because a guard against one specific mistake must
not turn into a way to lock out every connection write.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* fix(providers): compare the untrimmed credential, and cover the guard's branches
The guard trimmed the incoming value before comparing it, which catches a paste
carrying whitespace the password does not have. It missed the mirror case:
neither the login route nor the set-password route trims, so a dashboard
password may itself begin or end with a space, and an autofill reproducing it
exactly was trimmed into a value that no longer matched the stored hash. The
write then went through, which is the state this guard exists to prevent. Both
forms are compared now, the second only when the first fails on a string that
differs, so an ordinary key still costs a single bcrypt round.
Two branches carried no coverage and both are load-bearing. The catch that logs
and allows is the only path that lets a write through; a stored hash bcrypt
cannot parse reaches it without needing a mock, since the shape check accepts an
impossible cost factor that the comparison then rejects. The early return is
what keeps a token renewal -- a write carrying tokens but no apiKey -- from
paying for a settings read and a bcrypt round every time it fires, and the same
unparseable hash makes that path observable, so an absent warning is proof the
return happened.
The narrower scope is deliberate and now says so in the code: the OAuth tokens
arrive from a provider's token endpoint rather than from a form, so extending
the comparison to them would charge every renewal for a field no autofill can
reach.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
---------
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* fix(providers): switch minimax from claude to openai format so images work
The Anthropic-compatible /anthropic/v1/messages endpoint rejects image
input with 403. MiniMax's OpenAI-compatible /v1/chat/completions endpoint
supports image_url natively for MiniMax-M3.
- minimax + minimax-cn: format claude→openai, baseUrl→/v1/chat/completions
- Remove Anthropic-Version header + ?beta=true suffix (not needed for openai)
- Remove minimax/minimax-cn from ?beta=true executor case
- Update cache-control tests (openai format uses different caching path)
- Fix reasoning-split test names (no longer claude format)
TDD: 2 registry tests assert format=openai (red→green).
Refs: Hermes Agent #15715, MiniMax OpenAI-compatible API docs.
* fix(sse): re-align stream-readiness-policy tests with minimax's openai format
PR #9463 switched minimax/minimax-cn from claude to openai format so images
work. The stream-readiness bump for Claude-format replicas is keyed off the
registry's format field (single source of truth), so minimax legitimately
falls out of that group now. Swap the "Claude-format replica" test fixtures
to agentrouter (still format: "claude") and add explicit coverage that
minimax no longer gets the claude_format_heavy_reasoning bump.
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* docs: document provider model refresh fix
Document the verified live-model refresh path for stale provider catalogs,
record the current Pollinations anonymous-access limitation, and sync the
provider-count references after regenerating the provider reference.
Co-Authored-By: Oz <oz-agent@warp.dev>
* docs: note codex local env and mac path
Co-Authored-By: Oz <oz-agent@warp.dev>
---------
Co-authored-by: Oz <oz-agent@warp.dev>
The doc's own breakdown at line 11 (42+3+4+3+6+8+8+6+22+2) sums to
104, matching the two existing '104 unique tools' mentions. The
'105 tools' mentions in the intro and cardinality-reduction section
were stale and inconsistent with the documented source of truth.
* fix(#8171): map DeepSeek prompt_cache_hit_tokens into prompt_tokens_details.cached_tokens
DeepSeek native API returns cache stats in flat top-level fields
(prompt_cache_hit_tokens / prompt_cache_miss_tokens) instead of
the standard prompt_tokens_details.cached_tokens. The usage
sanitizer (sanitizeUsage / sanitizeResponsesUsage) was stripping
these non-standard fields, so clients never received real cache
hit counts even when the upstream served cached responses.
Changes:
- sanitizeUsage(): map prompt_cache_hit_tokens into
prompt_tokens_details.cached_tokens when the latter is unset
- sanitizeResponsesUsage(): same mapping for input_tokens_details
- filterUsageForFormat(): add prompt_cache_hit_tokens and
prompt_cache_miss_tokens to the default format allow list
so they survive field-level filtering
* fix: passthrough non-standard cache token fields for DeepSeek / MiniMax / Bedrock across streaming, non-streaming, and Dashboard paths
* fix(sse): shrink cache-hit token passthrough to fit file-size gate
PR #8591 added a DeepSeek/MiniMax/Bedrock flat cache-hit-token ->
nested prompt_tokens_details.cached_tokens mapping (#8171) that grew
responseSanitizer.ts and stream.ts past their frozen file-size
baselines.
- Extract the chat-completions/Responses-API mapping logic into a new
leaf module (responseSanitizer/cacheHitTokens.ts).
- Move the streaming-path rebuild into filterUsageForFormat()
(usageTracking.ts), the single conversion chokepoint both stream.ts
call sites already used, eliminating the duplicated stream.ts patch
entirely.
- Rebaseline responseSanitizer.ts by the 2 lines that remain
irreducible (the mandatory ES import for the extracted helper).
Behavior verified unchanged via the existing response-sanitizer and
stream-handler unit suites.
Co-authored-by: ikelvingo <ikelvingo@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: ikelvingo <ikelvingo@users.noreply.github.com>
* feat(providers): add support for TinyCMS Web including WASM-based cryptographic signing and Proof-of-Work emulation
* feat(providers): add unit tests, ESLint suppressions, and fix hardcoded userid for TinyCMS Web
- Add unit tests for WASM init, UUID validation, challenge flow (15 tests)
- Add WASM source comment explaining binary origin
- Replace hardcoded userid with dynamic provider-specific data
- Add ESLint suppressions for no-explicit-any in WASM bridge code
- Add explanatory comments for DOM shim (runtime WASM-bindgen, not test mocks)
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* refactor(providers): extract TinyCMS DOM shims into an explicit setup function
tinycmsSigner.ts installed its window/document/HTMLCanvasElement/
CanvasRenderingContext2D shims for the wasm-bindgen glue as a module-load
side effect. That meant merely importing the module (even transitively,
e.g. through the provider registry from an unrelated test) mutated
global state for the rest of the test process.
Extract the shim installation into setupDomMocks(), which returns a
restore callback:
- initTinyCmsWasm() calls it once before instantiating the WASM module
(production path — unchanged behavior, still automatic).
- tests/unit/provider-tinycms-web.test.ts now calls it explicitly in a
`before` hook and restores the previous globals in `after`, so the
shims never leak into other test files.
As a side effect, replacing five separate `as any` casts with a single
typed `global as Record<string, any>` handle drops the file's
no-explicit-any count from 5 to 1; eslint-suppressions.json updated to
match.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* docs(providers): regenerate PROVIDER_REFERENCE.md for tinycms-web
Mechanical `npm run gen:provider-reference` run after merging release/
v3.8.50 into this branch — the generated table was stale for both the
new tinycms-web entry this PR adds and the release's own cheaperinference
addition. Total providers 290 -> 292, Web Cookie Providers 31 -> 32.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(adobe-firefly): open browser sign-in and resolve provider slug in /login
POST /api/providers/[id]/login passed the connection DB id to
inAppLoginService.startLogin, but TOKEN_EXTRACTION_CONFIGS is keyed by
provider slug — so browser login never launched for web-cookie providers.
Adobe Firefly also cannot use cookie extraction: the IMS JWT only appears
on Authorization headers to firefly-3p.ff.adobe.io. Add a dedicated
Playwright interceptor and persist credentials with camelCase keys that
updateProviderConnection actually reads.
* fix(adobe-firefly): use system Chrome/Edge CDP for browser sign-in
Playwright is not available inside the pkg-packaged VibeProxyServices.exe,
so import('playwright') always failed with 'Playwright not installed' and
never opened a window. Launch Chrome/Edge with --remote-debugging-port and
capture the firefly-3p Authorization Bearer via pure CDP WebSocket instead.
* fix(adobe-firefly): live x-arp-session-id / Arkose wire (stop 408 under load)
Browser generate-async requires x-arp-session-id as base64({sid,ark,ftr}) with a
real Arkose blob (sherlockToken). JWT alone frequently returns colligo HTTP 408
system under load while credits still work.
- Match live ftr magic __UDF43-m4_31ck + Arkose pk in synthetic ARP fallback
- Ranked extract of sherlockToken / x-arp from Cookie, HAR, fetch() paste, and
space-joined JWT+ARP (PasswordBox newline collapse)
- Reuse one ARP for storage upload + generate-async
- Clearer 408 errors when browser ARP is missing vs stale
- Unit suite 42/42
* fix(adobe-firefly): durable session ARP rebuild and aux_sid false-positive
Rebuild x-arp-session-id from forterToken/arkose/ff_session_guid instead of
ranking long Cookie pairs (e.g. aux_sid=…) as opaque ARP, which caused colligo
HTTP 408. Cache IMS JWT + cookie sessions, rotate ARP on 408 retries, and keep
Playwright warm-up opt-in only (headless Forter is rejected).
Also expand synthetic ARP shape with bfp/fpjs to match live successful captures.
* fix(adobe-firefly): renew sessions through durable CDP
* fix(adobe-firefly): isolate browser sessions per account
* fix(adobe-firefly): make account login fresh and deterministic
* docs(adobe-firefly): document renewal controls
* fix(adobe-firefly): harden CDP warm, risk session, and browser sign-in
Stop colligo 408 thrash from stale Forter and frozen Google login during
Sign in with browser:
- CDP warm: clear Firefly origin storage + risk cookies (keep SSO); require
forter age under 10 minutes on loop and timeout paths; dual CDP queues;
await Runtime.runIfWaitingForDebugger; profile-lock launch retries
- Session: connectionId fingerprint; write-back JWT+Cookie; warm-fail
cooldown; fail closed risk_session_stale when forter is known-stale
- Client: submit gate around generate-async; max 2 attempts when forter
known-stale; poll 401 one refresh; pass sessionBrowserKey through handlers
- Login route: pure system Chrome/Edge CDP only; camelCase credential persist
- Unit: browser-login + firefly suites green (60)
* fix(adobe-firefly): dedupe CDP session hardening blocks after rebase
Remove duplicated guard blocks and test bodies introduced when rebasing
the CDP session hardening work onto release/v3.8.50, which already
carries the hardened implementation.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Hoisting a mid-conversation `system`/`developer` message into the top-level
`system` field carried its `cache_control` marker along. Anthropic assembles the
cache prefix as tools -> system -> messages, so the marker ended the cached
prefix at the system block and left the accumulated conversation without a
breakpoint: that turn was billed as fresh input and the next one rebuilt the
cache.
`relocateHoistedCacheBoundary` moves the marker to the nearest preceding block
that can carry a breakpoint, skipping thinking blocks, empty text and anything
the upstream normalisation discards or empties out. If that block already
carries the client's own marker, both are kept - unless the hoisted one, now
ahead of the target in `system[]`, would put a 5m breakpoint before a 1h one,
which Anthropic rejects; it is dropped in that case. Either way the breakpoint
count never grows.
normalizeClaudeUpstreamMessages rewrites tool_result and inlined file/document
blocks into plain text after the hoist, which silently discarded any marker on
them - including a relocated one. The replacement block now inherits it.
Both hoisting implementations share the helper; a fix touching only
claudeSystemRole.ts would leave extractSystemMessagesToBody broken, and the
native Claude path reaches the former through normalizeClaudeUpstreamMessages.
Capability-gated hoisting for strict providers (#7293) is unaffected.
Fixes#9436
Co-authored-by: LeonG606 <leongudat01@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
* feat(sse): server-side template expansion for combo system prompts (#5501)
* fix(quality-gates): register combo-system-prompt-templates-5501 test in stryker tap.testFiles
check:mutation-test-coverage --strict flagged tests/unit/combo-system-prompt-templates-5501.test.ts
as covering src/shared/utils/circuitBreaker.ts without being listed in stryker.conf.json
tap.testFiles, so its mutant kills wouldn't count.
Co-authored-by: maxmad64bis <maxmad64bis@users.noreply.github.com>
---------
Co-authored-by: Max <maxmad64@gmail.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: maxmad64bis <maxmad64bis@users.noreply.github.com>
* fix(command-code): preserve literal max effort for command-code provider
* test(command-code): type the new sanitizeReasoningEffortForProvider assertions
The 3 new command-code reasoning-effort test cases cast the function's
unknown return value with `as any`, which pushes the file's frozen
no-explicit-any suppression count (48) to 51 and trips the "No new
ESLint warnings" gate. Use a minimal EffortCarrierResult shape instead
of any, matching the fields the assertions actually read.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* test(v1-models): type the API key lookup in the #9320 auth-leak regression test
The release-tip test file added by #9320 used `(k: any)` in an Array.find
callback, which is not covered by config/quality/eslint-suppressions.json
(the file was added after the suppressions snapshot was frozen). That
leaves the "No new ESLint warnings" gate red for any branch that merges
this exact release/v3.8.50 tip, unrelated to this PR's own diff. Fixing
it here with a minimal derived type (Awaited<ReturnType<typeof
getApiKeys>>[number]) unblocks the gate without touching the frozen
suppressions baseline.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
The combo success path called recordProviderSuccess (cooldown-only)
without notifying the circuit breaker. When a provider breaker entered
HALF_OPEN after repeated failures, successful probe requests never
transitioned it back to CLOSED -- the breaker stayed stuck indefinitely.
Production evidence: agy breaker HALF_OPEN with 699 requests at 98%
success rate, never recovering.
Root cause: combo.ts calls recordProviderSuccess from
providerCooldownTracker.ts (resets cooldown failureCount only) but
never calls breaker._onSuccess(). The failure path in accountFallback.ts
calls breaker._onFailure(), creating an asymmetry.
Fix: add recordProviderSuccess to accountFallback.ts as the symmetric
counterpart of recordProviderFailure. Uses getProviderBreaker (not
configureProviderBreaker) to avoid overwriting the breaker's resetTimeout
with default profile values. Calls breaker._onSuccess() for all non-OPEN
states (CLOSED/DEGRADED/HALF_OPEN), matching execute()'s behavior.
