Route Anthropic-style aliases (haiku/sonnet/opus/claude-*) to Codex when Kimi isn't used

[bbadler]

Problem

The cross-provider aliases (haiku, sonnet, opus, claude-haiku-4-5, claude-haiku-4-5-20251001, claude-sonnet-4-6, claude-opus-4-7) are currently registered exclusively in Kimi's supportedModels (kimi/index.ts:206-212). The Codex provider only claims gpt-5.* IDs.

This breaks Codex-only setups (authenticated with Codex, no Kimi auth) because Claude Code emits Anthropic-style aliases in several common paths:

1. Built-in general-purpose subagent defaults to opus → routes to Kimi → fails with Run: claude-code-proxy kimi auth login
2. /model picker presets (Default/Sonnet/Opus/Haiku) all send claude-* IDs → all route to Kimi
3. Background tasks (session title gen, etc.) often default to haiku/claude-haiku-*

For users on a ChatGPT Plus/Pro subscription who don't want to also create a kimi.com account, every teammate spawn currently fails. The Agent tool's model parameter is restricted to the enum ["sonnet", "opus", "haiku"], so users can't manually override to gpt-5.4-mini either.

Reproduction

1. Authenticate Codex only: claude-code-proxy codex auth login
2. Start proxy: claude-code-proxy serve
3. Run Claude Code through the proxy
4. Spawn any subagent (e.g. via Agent tool with subagent_type: "general-purpose")
5. Observe the auth error from Kimi provider

Proposed solutions

Any of these would unblock Codex-only users without breaking Kimi users — preference order:

1. Config flag (aliasProvider: "codex" | "kimi", default "kimi" for backward compat) — explicit, minimal surprise
2. Dynamic claim at startup — whichever provider has valid auth claims the aliases; if both, fall back to current Kimi-first behavior or a configured tiebreaker
3. Auth-failure fallback — if the routed provider returns 401/403, retry on the other provider claiming the same alias

Workaround

Forking and adding the aliases to Codex's supportedModels works for Codex-only setups but breaks Kimi-only setups (since Codex is iterated first in providerForModel).

Happy to send a PR for option 1 if you have a design preference. Thanks for the proxy — it's been excellent otherwise!

[raine]

Should be fixed in latest, thanks