Description
codemie proxy connect desktop curates the Claude models exposed to Claude Desktop via a hardcoded PREFERRED_CLAUDE_MODELS array in dist/cli/commands/proxy/connectors/desktop.js. This list is stale relative to the current Claude model lineup and hasn't been updated across the last two published releases (0.11.0 and 0.12.0 — diffed identical).
Current list:
claude-sonnet-4-6
claude-opus-4-8
claude-opus-4-7
claude-opus-4-6
claude-haiku-4-5
The Opus (4.8/4.7/4.6) and Haiku 4.5 entries still resolve correctly against the gateway. However, the Sonnet entry (claude-sonnet-4-6) refers to a superseded generation — the current model is claude-sonnet-5, which does not appear anywhere in the preferred list.
Per the code's own matching logic (selectPreferredClaudeModels), each preferred entry is only resolved against an exact gateway model ID or that ID with a -YYYYMMDD date suffix — there's no cross-generation fallback. So if the gateway's /v1/llm_models?include_all=true no longer serves anything matching claude-sonnet-4-6*, no Sonnet model gets selected for Claude Desktop at all.
Steps to Reproduce
codemie profile login / configure an active SSO profile against https://codemie.lab.epam.com
codemie proxy connect desktop --verbose
- Inspect the resolved models written to the Claude Desktop config (or check
discoveredModels / resolvedModels in the verbose log output)
Expected Behavior
The Sonnet entry in PREFERRED_CLAUDE_MODELS should track the current Claude generation (claude-sonnet-5), so Claude Desktop is offered the latest Sonnet model through the proxy — consistent with how Opus and Haiku are already current.
Actual Behavior
PREFERRED_CLAUDE_MODELS still lists claude-sonnet-4-6 instead of claude-sonnet-5. If the gateway has retired the older Sonnet generation, Claude Desktop connected via the CodeMie proxy loses Sonnet entirely and only gets Opus/Haiku.
Environment
| Field |
Value |
| OS |
Darwin 25.5.0 arm64 |
| Node.js |
v24.18.0 |
| npm |
11.16.0 |
| CodeMie CLI |
0.12.0 |
| Shell |
/bin/zsh |
| Terminal |
Apple_Terminal |
Installed Agents
- CodeMie Code (0.0.47)
- Claude Code (2.1.218)
Additional Notes
Confirmed this is not fixed by upgrading — pulled the published 0.12.0 tarball from npm and diffed PREFERRED_CLAUDE_MODELS against the locally installed 0.11.0; the array is byte-for-byte identical.
Description
codemie proxy connect desktopcurates the Claude models exposed to Claude Desktop via a hardcodedPREFERRED_CLAUDE_MODELSarray indist/cli/commands/proxy/connectors/desktop.js. This list is stale relative to the current Claude model lineup and hasn't been updated across the last two published releases (0.11.0 and 0.12.0 — diffed identical).Current list:
The Opus (4.8/4.7/4.6) and Haiku 4.5 entries still resolve correctly against the gateway. However, the Sonnet entry (
claude-sonnet-4-6) refers to a superseded generation — the current model isclaude-sonnet-5, which does not appear anywhere in the preferred list.Per the code's own matching logic (
selectPreferredClaudeModels), each preferred entry is only resolved against an exact gateway model ID or that ID with a-YYYYMMDDdate suffix — there's no cross-generation fallback. So if the gateway's/v1/llm_models?include_all=trueno longer serves anything matchingclaude-sonnet-4-6*, no Sonnet model gets selected for Claude Desktop at all.Steps to Reproduce
codemie profile login/ configure an active SSO profile againsthttps://codemie.lab.epam.comcodemie proxy connect desktop --verbosediscoveredModels/resolvedModelsin the verbose log output)Expected Behavior
The Sonnet entry in
PREFERRED_CLAUDE_MODELSshould track the current Claude generation (claude-sonnet-5), so Claude Desktop is offered the latest Sonnet model through the proxy — consistent with how Opus and Haiku are already current.Actual Behavior
PREFERRED_CLAUDE_MODELSstill listsclaude-sonnet-4-6instead ofclaude-sonnet-5. If the gateway has retired the older Sonnet generation, Claude Desktop connected via the CodeMie proxy loses Sonnet entirely and only gets Opus/Haiku.Environment
Installed Agents
Additional Notes
Confirmed this is not fixed by upgrading — pulled the published
0.12.0tarball from npm and diffedPREFERRED_CLAUDE_MODELSagainst the locally installed0.11.0; the array is byte-for-byte identical.