[Feature]: expose speed/service-tier capabilities for eligible custom providers and routed models #1436

Client or integration

Codex Desktop using the OpenCodex-generated model catalog

Area

Custom providers / routed model catalog / Responses API / service tier

OpenCodex version

2.11.1

Summary

Models routed through a custom OpenAI-compatible provider cannot expose the Codex Desktop Standard / Fast speed selector, even when the upstream provider may support a priority or fast service tier.

The native ChatGPT/Codex account-pool route for the same model family exposes both reasoning effort and speed, while the routed custom-provider model exposes reasoning effort only.

This appears to be a capability-publication and provider-adaptation gap rather than a Codex Desktop rendering bug: the client displays the speed selector when the generated catalog contains service-tier metadata.

Current behaviour

For a native account-pool model, the generated catalog contains speed metadata similar to:

{
  "slug": "gpt-5.6-sol",
  "service_tiers": [
    {
      "id": "priority",
      "name": "Fast",
      "description": "1.5x speed, increased usage"
    }
  ],
  "additional_speed_tiers": ["fast"]
}

Codex Desktop consequently offers:

Reasoning effort: Low / Medium / High / ...
Speed: Standard / Fast

For the same model routed through a custom provider, the catalog entry is namespaced but does not contain speed metadata:

{
  "slug": "custom-provider/gpt-5.6-sol",
  "service_tiers": null,
  "additional_speed_tiers": null
}

Codex Desktop then offers reasoning effort only.

The current routed-catalog normalization removes fields including:

additional_speed_tiers
service_tier
service_tiers
default_service_tier

Request-time OpenAI service_tier: "priority" injection is also restricted to an openai-responses route with supportsServiceTier: true.

This is safe as a default, but there is no supported opt-in path for a custom provider/model whose upstream capability has been verified.

Expected behaviour

Allow custom providers or individual routed models to explicitly declare a verified speed/service-tier capability.

When that capability is enabled, OpenCodex should:

1. preserve or generate the appropriate service_tiers catalog metadata;
2. expose the speed selector to compatible clients such as Codex Desktop;
3. map the selected tier to the verified upstream parameter;
4. keep the capability disabled for unknown or unsupported providers;
5. avoid inferring support from the model name alone.

Suggested configuration contract

A provider-level capability could reuse the existing safety boundary:

{
  "adapter": "openai-responses",
  "supportsServiceTier": true
}

A per-model capability would be safer when only some upstream models support it:

{
  "models": {
    "gpt-5.6-sol": {
      "supportsServiceTier": true,
      "serviceTiers": ["default", "priority"]
    }
  }
}

The exact public schema can follow existing provider/model capability conventions.

For providers that use a proprietary fast-mode parameter rather than OpenAI service_tier, support should require an explicit provider-specific mapping. OpenCodex should not create a UI-only switch that has no runtime effect.

Minimal reproduction

1. Configure the native ChatGPT/Codex account pool and start OpenCodex.
2. Open Codex Desktop and select the native gpt-5.6-sol catalog entry.
3. Observe both reasoning-effort and Standard / Fast controls.
4. Configure a custom OpenAI-compatible provider that exposes a routed gpt-5.6-sol model.
5. Refresh the generated catalog and select custom-provider/gpt-5.6-sol.
6. Observe that reasoning effort is available but the speed control is absent.
7. Inspect the catalog and compare service_tiers / additional_speed_tiers between the two entries.

No credentials or upstream URLs are required to demonstrate the catalog difference.

Safety requirements

• Do not infer speed-tier support from gpt-5.6-sol or any other model name.
• Do not inject service_tier into providers with false or unknown capability.
• Do not advertise Fast unless selecting it changes the effective upstream request.
• Preserve provider/model namespacing so capability does not leak across providers exposing the same model ID.
• Expose unsupported or unknown capability clearly in the dashboard rather than silently accepting an ineffective setting.

Acceptance criteria

• A custom provider can explicitly opt into OpenAI-compatible service-tier support.
• A custom provider can opt in per model rather than only globally.
• Eligible routed catalog entries retain or generate speed-tier metadata.
• Codex Desktop displays Standard / Fast for an eligible routed model.
• Selecting Fast produces the verified upstream parameter, such as service_tier: "priority".
• Unsupported and unknown providers continue to omit the parameter and speed metadata.
• Model-name similarity alone never enables the capability.
• Catalog behavior and request-time routing use the same effective capability decision.
• Regression tests cover native, supported custom, unsupported custom, and mixed-capability provider models.

Relationship to existing work

Related to #1086, which tracks per-model service-tier override policy after provider capability is already known.

This request covers the preceding gap: allowing an eligible custom provider/model to declare that capability and publish it through the routed catalog. It does not request bypassing the existing supportsServiceTier safety gate.

Checks

• I searched existing service-tier and custom-provider issues.
• The reproduction contains no API keys, credentials, account identifiers, or upstream URLs.
• The proposal preserves capability gating and does not assume that every OpenAI-compatible provider supports priority service tiers.