The bidirectional parity branch already supports subswitch models --client claude-code|codex|both --json. Integrations still cannot consume one consistent view of models applicable to the user's configuration.
Observed gaps
- Omitting
--client always selects claude-code, regardless of the configured integration.
- Forward output uses schema version 1 and reverse output version 2; alias entries and model metadata have different shapes. The combined version-2 output embeds the version-1 forward payload.
- Forward JSON omits custom alias targets outside the built-in registry even when the router accepts them; reverse rows include custom targets.
- Registered/routable models are not evidence of account entitlement or live availability.
- CLI rows describe alternative routed destinations, not a complete list of native passthrough models. Codex's HTTP discovery separately augments the upstream OpenAI catalog.
Scope
- Define a consistent, versioned schema for both clients, including model ID, aliases, destination provider, route enabled status, registration/source, and supported capability metadata where known.
- Make default selection reflect configured integrations; retain explicit
--client overrides and a combined view. Define deterministic behavior for both clients configured or no integration configured.
- Derive discovery from the same effective routing definitions used at runtime, including valid custom targets and alias precedence.
- Distinguish known support, configured/enabled routes, and account availability. Represent unverified availability as unknown; ordinary listing must not imply a successful inference probe.
- Clearly define whether native passthrough catalogs are included or separately identified, and keep CLI discovery and native model discovery consistent where they overlap.
- Provide an explicit compatibility/migration strategy for existing JSON consumers rather than silently changing version-1 semantics.
Acceptance
Exercise forward-only, reverse-enabled, both-client, default/no-config, disabled-route, custom-alias, and alias-conflict cases. Integrations should be able to build an accurate model picker without provider-specific parsing or advertising unsupported capabilities. Listing must not expose credentials, rotate tokens, or generate billable inference merely to enumerate models.
Coordinate capability reporting with #48 and provider expansion with #10. Full implementation of the broader content features in #48 is not required for truthful discovery.
The bidirectional parity branch already supports
subswitch models --client claude-code|codex|both --json. Integrations still cannot consume one consistent view of models applicable to the user's configuration.Observed gaps
--clientalways selectsclaude-code, regardless of the configured integration.Scope
--clientoverrides and a combined view. Define deterministic behavior for both clients configured or no integration configured.Acceptance
Exercise forward-only, reverse-enabled, both-client, default/no-config, disabled-route, custom-alias, and alias-conflict cases. Integrations should be able to build an accurate model picker without provider-specific parsing or advertising unsupported capabilities. Listing must not expose credentials, rotate tokens, or generate billable inference merely to enumerate models.
Coordinate capability reporting with #48 and provider expansion with #10. Full implementation of the broader content features in #48 is not required for truthful discovery.