Custom models (added via the UI) on opencode-go / openai-compatible nodes always
routed as OpenAI-compatible because there was no per-model targetFormat: addCustomModel
didn't accept it, the API schema stripped it, and getModelTargetFormat (static-registry
only) never saw it — so a custom model needing the Anthropic Messages shape fell back to
the provider default 'openai'.
Thread an optional targetFormat through addCustomModel / replaceCustomModels /
updateCustomModel + the providerModelMutationSchema + the POST/PUT route, surface it from
getModelInfo (one combined custom-model metadata lookup alongside apiFormat), and use it
in chatCore's targetFormat resolution before the provider default.
Closes#2905
Custom providers (openai-compatible-<uuid> / anthropic-compatible-<uuid>) showed
the raw UUID id instead of the user-given node name in the active-requests panel,
proxy logger, and home-page provider topology. Only RequestLoggerV2 resolved it
(via a local helper + /api/provider-nodes fetch).
Extract the resolver into a shared util (src/shared/utils/providerDisplayLabel.ts,
unit-tested), reuse it in RequestLoggerV2, and apply it (with a provider-nodes
fetch) in ActiveRequestsPanel, ProxyLogger, and the HomePageClient topology so all
surfaces show the user-defined provider name.
Closes#2968
(A) For a Codex-only account, a bare gpt-5.5 Responses request was rerouted to
codex with the model hardcoded to gpt-5.5-medium (chatHelpers.ts). The Codex
executor reads a model-name suffix as an explicit modelEffort that, per #2331,
overrides the client's reasoning.effort — so a genuine reasoning.effort=xhigh
was silently demoted to medium. Keep the bare gpt-5.5 id (the connection
fallback still supplies the default effort); the executor precedence is
untouched, so #2331 stays intact.
(B) gpt-5.5-xhigh/-high/-low misrouted to the openai provider (only bare gpt-5.5
was codex-preferred), so codex-only users got 'No credentials for provider:
openai'. Add the suffixed variants to CODEX_PREFERRED_UNPREFIXED_MODELS so they
infer codex before the /^gpt-/ → openai fallback.
Closes#2877
opencode-zen serves the public, signup-free OpenCode Zen endpoint
(https://opencode.ai/zen/v1). With no API-key connection configured,
getProviderCredentials returned null, so the Playground/combos surfaced
"No credentials for provider: opencode-zen" when selecting an OpenCode free
model.
Fall back to synthetic no-auth credentials for opencode-zen when no usable
connection exists (a configured active key is still selected first; a
rate-limited/terminal key returns its own signal before this point). Other
api-key providers are unaffected.
Closes#2962
Fireworks Fire Pass (fpk_*) keys return 403 "Fire Pass API keys are not
authorized for this route." on /models while still serving chat. Two paths
wrongly penalized the key:
- validateOpenAILikeProvider returned "Invalid API key" for any 403 on the
models endpoint without trying the chat probe.
- checkFallbackError classified the 403 as AUTH_ERROR (retryable cooldown), and
even a generic fall-through hit the transient-cooldown default — marking the
connection unavailable.
Fix: validateOpenAILikeProvider now inspects the 403 body and falls through to
the chat probe for "not authorized for this route" responses (401 and generic
403 still fail fast). checkFallbackError short-circuits such route-restriction
403s to { shouldFallback: false, cooldownMs: 0 } so the connection is not cooled
down. Per CLAUDE.md, a generic api-key 403 should be recoverable unless terminal.
Closes#2929
The no-auth OpenCode provider has id "opencode" and alias "oc". The combo
builder built qualifiedModel from the provider id ("opencode/big-pickle"), but
parseModel("opencode/...") resolves to the opencode-zen api-key tier via a
manual ALIAS_TO_PROVIDER_ID override — not the no-auth "opencode" provider.
"oc/<model>" resolves correctly.
Rewrite qualifiedModel to the provider alias for no-auth providers (only when
the alias differs from the id), keeping providerId for getModelIsHidden. Aligned
the route test that previously asserted the buggy "opencode/" prefix.
Closes#2901
big-pickle's OpenCode/Zen upstream runs DeepSeek thinking mode, but the model
id reveals no DeepSeek signal, so requiresReasoningReplay (called with
allowLegacyFallback:false) never triggered. Follow-up/tool-use turns failed
with [400] 'The reasoning_content in the thinking mode must be passed back to
the API'. Note: requiresReasoningReplay does not consume supportsReasoning, so
the registry flag alone would not have fixed it.
Add RegistryModel.interleavedField (mirrors models.dev interleaved_field),
declare interleavedField:'reasoning_content' (+ supportsReasoning:true) on
big-pickle in both opencode and opencode-zen, and surface the registry value
in getResolvedModelCapabilities so requiresReasoningReplay returns true.
Closes#2900
077_api_key_stream_default_mode.sql and 077_quota_pools.sql both claimed
prefix 077, so getMigrationFiles() threw a version-collision error and
getDbInstance() failed at every startup (app would not boot; all DB-touching
unit tests were red on release/v3.8.8).
Renumber the dependency-free, idempotent quota_pools migration 077 -> 085
(no other migration references quota_pools/quota_allocations), keep the
non-idempotent api_key_stream_default_mode ALTER at 077, add a retroactive
isSchemaAlreadyApplied guard (case 085) for DBs that already applied it under
077, and add a regression test enforcing unique migration prefixes.
Root cause: model string provider prefix (e.g. "xiaomi" from
"xiaomi/mimo-v2-flash") differs from the credential DB provider ID
(e.g. "opengate") when a combo target has a custom providerId. The
pre-selection and execution flows both looked up credentials using the
model-inferred provider, which didn't match any DB entry.
Fix A (chat.ts): checkModelAvailable now uses target.providerId when
available, falling back to modelInfo.provider.
Fix B (chat.ts): handleSingleModelChat now accepts runtimeOptions.providerId
and preferentially uses it for credential lookup instead of re-resolving
the provider from the model string.
Fix C (model.ts): add "xiaomi" alias for "xiaomi-mimo" so direct
(non-combo) model requests to xiaomi/mimo-* also resolve correctly.
Remove the AuditLogTab from the dashboard logs page now that audit logs
live under the dedicated /dashboard/audit route. Update integration wiring
expectations and add metadata frontmatter to studio framework docs.
Update the main and localized changelogs with the 3.8.7 release notes, including new API self-service status, analytics retention, RAM optimizations, and token accounting fixes.
Clarify release skill instructions to ensure new release branches are always created from the latest main branch.
