[Feature]: Honor compat.openRouterRouting in BYOK custom providers (OpenRouter provider routing: sort/order/only)

[SvenMeyer]

Product or interface

CLI - headless (same config/runtime path as CLI - interactive TUI)

Use case and problem

When an OpenRouter model is used as a BYOK custom_provider, there is no way to control OpenRouter provider routing from config.yaml. OpenRouter can route the same model to different upstream inference providers (DeepSeek, DeepInfra, Fireworks, Morph, Relace, ...), and its request body supports a provider object (sort, order, only, ignore, allow_fallbacks, data_collection, zdr, max_price, require_parameters, ...). See https://openrouter.ai/docs/guides/routing/provider-selection.

The underlying transport already supports this, but the BYOK config reader drops it before it reaches the model, so the field is silently ignored:

• packages/local-runtime-v2/src/service/model-system/resolution/model-resolver-byok.ts → readModelCompat() only reads the boolean keys (BOOLEAN_COMPAT_KEYS), plus maxTokensField, thinkingFormat, and cacheControlFormat. openRouterRouting / vercelGatewayRouting are not read.
• packages/local-runtime-v2/src/service/model-system/contracts.ts → LocalModelCompatOverrides does not include openRouterRouting.
• The pi transport does honor it: third_party/pi-mono/packages/ai/src/providers/openai-completions.ts (~L619):

  if (model.compat?.openRouterRouting) {
    (params as any).provider = model.compat.openRouterRouting;
  }

Today the only config-only workaround is OpenRouter's model-ID routing variants (deepseek/deepseek-v4.1-flash:nitro, :floor, :exacto). Those cover sort, but they cannot express pinning (only/order), exclusions (ignore), allow_fallbacks: false, data_collection/zdr, or max_price.

Desired behavior

Honor a model-level compat.openRouterRouting (and ideally compat.vercelGatewayRouting) for BYOK custom providers. Example config.yaml:

custom_provider:
  openrouter:
    name: openrouter
    kind: custom
    enabled: true
    api: openai-completions
    options:
      apiKey: sk-or-v1-...
      baseURL: https://openrouter.ai/api/v1
      authMode: api-key
    models:
      deepseek/deepseek-v4.1-flash:
        reasoning: true
        limit:
          context: 1048576
          output: 131072
        compat:
          openRouterRouting:
            only: ["DeepSeek"]
            allow_fallbacks: false

Acceptance criteria:

• compat.openRouterRouting (and vercelGatewayRouting) declared in LocalModelCompatOverrides and validated in readModelCompat (object with the documented keys; drop unknown/malformed values gracefully, consistent with the existing defensive readers).
• The object is merged into the resolved model.compat so the pi transport sends it as the request provider field.
• Works for both a pinned provider (only/order) and a sort strategy.
• Existing behavior is unchanged when the field is absent (no provider field sent).

Platform

Multiple platforms

Alternatives and additional context

• Related: [Feature]: Openrouter support in custom models #215 (generic OpenRouter support).
• Workaround used today: one config entry per routing variant (:nitro, :floor, :exacto). Verified these are resolved server-side by OpenRouter from the model ID alone, so they need no request field — but they only cover sorting.
• mcode --version: 0.5.1.

[SvenMeyer]

Related picker note, not a fix for this issue.

OpenRouter never reaches BYOK setup today, because resolveTransport() only accepts @ai-sdk/openai, @ai-sdk/openai-compatible, and @ai-sdk/anthropic. models.dev tags OpenRouter as @openrouter/ai-sdk-provider, so the preset is dropped before a compat block can matter.

A separate, smaller change makes just that preset addable: in resolveTransport(), if providerId === 'openrouter', use openai-completions and provider.api (https://openrouter.ai/api/v1). Match the id, not the npm package — standardcompute publishes the same package with a different URL. MiniMax ids, tool_call: false models, and every other SDK stay filtered.

Tested as a preset-parser change only, on SvenMeyer/minimax-code@bd97572. Details and the test command are on #289.

That commit does not read compat.openRouterRouting. This issue still needs LocalModelCompatOverrides and readModelCompat() to pass that object through to the pi transport, which already assigns it to the request provider field.

[SvenMeyer]

The OpenRouter preset test does not cover this issue.

We ran the add-provider flow from SvenMeyer/minimax-code@bd97572 and could select xiaomi/mimo-v2.6-flash and xiaomi/mimo-v2.6-pro-ultraspeed. Requests were plain Chat Completions. Nothing in that run sent a provider routing object, and readModelCompat() still drops compat.openRouterRouting.

The preset-only branch is https://github.com/SvenMeyer/minimax-code/tree/openrouter-preset (bd97572). A pull request from this account was rejected. Routing stays here.

[Ralle1976]

Root-cause analysis for this issue, verified against current main (44b13d3) — no code attached, just the evidence, in case it helps the routing decision:

Confirmed: the transport honors it, the BYOK config reader drops it.

1. The pi transport already sends it — third_party/pi-mono/packages/ai/src/providers/openai-completions.ts:619-621: if (model.compat?.openRouterRouting) { (params as any).provider = model.compat.openRouterRouting; } (and vercelGatewayRouting at :624-631, additionally gated on ai-gateway.vercel.sh hosts).
2. readModelCompat() in packages/local-runtime-v2/src/service/model-system/resolution/model-resolver-byok.ts:180-248 reads exactly: the 18 BOOLEAN_COMPAT_KEYS, then maxTokensField (:242), thinkingFormat (:244), cacheControlFormat (:246). openRouterRouting/vercelGatewayRouting are not read and fall out of the built compat object.
3. LocalModelCompatOverrides (packages/local-runtime-v2/src/service/model-system/contracts.ts:32-57) has no routing fields, so the resolver's compat spread can never carry one.
4. Config YAML parsing needs no change: packages/config/src/byok-config.ts:67-79 passes the custom_provider subtree through opaquely, so compat.openRouterRouting survives parsing and is only dropped at (2).

Minimal fix scope (for whoever picks this up — happy to prepare a branch on request): two files — add the field to LocalModelCompatOverrides mirroring pi's OpenRouterRouting shape, and validate + copy it in readModelCompat() following the existing drop-wrong-type pattern. One design note from the reader's doc comment (model-resolver-byok.ts:227-233): custom_provider is untrusted persisted config and pi treats any present field as an explicit override, so the routing object needs strict shape validation (e.g. only/order must be strings), not blind passthrough.

Routing-variant IDs (:nitro/:floor/:exacto, per the issue body) remain the config-only workaround until then.