Combo models expose owned_by combo which breaks clients routing by owned_by #2400

@### Summary

Combo (failover-group) models returned by OpenCodex's GET /v1/models carry "owned_by": "combo". The string "combo" is not a real provider, which breaks downstream clients that select their dispatch adapter by the owned_by field (e.g. DeepSeek Harness crashes with registration.adapter.prepareCall is not a function).

Environment

• OpenCodex 2.31.0 (GUI bundle), gateway at 127.0.0.1:10100
• Affected: any client that routes by owned_by (observed: @deepseek-ai/dsh@0.1.1-rc.2)

What happens

Combos configured in the dashboard (#models/combos) such as combo/fallback-free, combo/fallback-think, combo/image are listed by GET /v1/models with:

{ "id": "combo/fallback-free", "owned_by": "combo", ... }

Clients trust owned_by as the provider identity. Because "combo" is unknown, adapter lookup fails.

Important: failover itself is fine

The chat path is correct — POST /v1/chat/completions with model: combo/fallback-free reaches the gateway, which resolves the failover group server-side. Only the metadata (owned_by) is the problem; the actual routing/failover works. The combo works in OpenAI Codex desktop and via direct calls.

Suggested fix

One or more of:

1. Set owned_by for combo models to a neutral/standard value (e.g. "opencodex") or to the actual underlying provider of the combo's primary target, instead of the literal string "combo".
2. Add an explicit capability flag, e.g. "is_combo": true, and document that owned_by for combos is non-standard so clients route by the configured connection, not by owned_by.

This would let OpenAI-compatible clients that key off owned_by interoperate with combos without crashing.

Related

Companion issue filed on the DeepSeek Harness side requesting a fallback to the configured route's provider when owned_by is unrecognized.