Skip to content

Keep configured model id for custom providers instead of forcing the default#199

Open
scottzx wants to merge 1 commit into
agentclientprotocol:mainfrom
scottzx:fix/keep-config-model-for-custom-providers
Open

Keep configured model id for custom providers instead of forcing the default#199
scottzx wants to merge 1 commit into
agentclientprotocol:mainfrom
scottzx:fix/keep-config-model-for-custom-providers

Conversation

@scottzx

@scottzx scottzx commented Jun 14, 2026

Copy link
Copy Markdown

Problem

When ~/.codex/config.toml selects a custom provider with a model the built-in catalog doesn't know about (e.g. a self-hosted or third-party endpoint), every turn is sent with the wrong model id and the request fails:

{"error":{"message":"unknown model 'gpt-5.5'","code":"invalid_prompt"}}

…even though the same config works fine through the Codex CLI.

Root cause

CodexAcpClient.createModelId() resolves the configured/returned model id against listModels() and, when it's missing, substitutes availableModels.find(m => m.isDefault):

const selectedModel =
    availableModels.find(m => m.id === modelId) ??
    availableModels.find(m => m.isDefault);   // ← discards the configured model

Custom-provider model ids are not enumerated by listModels(), so the configured model is silently replaced by the built-in default. That default id (response.modelcurrentModelId) is then pinned onto every runTurn({ model }), so requests to the custom endpoint fail with unknown model '<default>'.

The Codex CLI handles the identical case differently — it keeps the configured model id and only warns:

Model metadata for MiniMax-M3 not found. Defaulting to fallback metadata; this can degrade performance and cause issues.

Fix

Mirror the CLI: when the model id isn't in the advertised catalog, keep it instead of substituting the default. Only fall back to isDefault when no model id was supplied at all. Downstream session state already degrades gracefully for unknown models (supportedReasoningEfforts ?? [], inputModalities ?? ["text", "image"]).

Testing

  • Added two unit tests in CodexAcpClient.test.ts for an uncatalogued model id (with an explicit reasoning effort, and defaulting the effort when null).
  • vitest run (createModelId suite) and tsc --noEmit pass.
  • Verified end-to-end through an ACP client: a session with model = "MiniMax-M3" now advertises MiniMax-M3[high] (previously gpt-5.5) and a prompt turn completes with a real reply from the custom endpoint.

… the default

createModelId() looked up the configured/returned model id in Codex's
listModels() catalog and, when it was absent, substituted
availableModels.find(m => m.isDefault). Custom providers (self-hosted or
third-party endpoints) expose model ids that the catalog does not enumerate,
so this silently replaced the user's configured model with the built-in
default. That default id was then pinned onto every runTurn, making requests
to the custom endpoint fail with "unknown model '<default>'".

The Codex CLI handles the same case by keeping the configured model id and
warning "Model metadata not found. Defaulting to fallback metadata." This
change mirrors that behavior: keep the requested model id when it is not in
the catalog, and only fall back to isDefault when no model id was provided
at all. Downstream session state already degrades gracefully for unknown
models (supportedReasoningEfforts ?? [], inputModalities ?? ["text","image"]).

Adds unit tests covering an uncatalogued model id with and without an
explicit reasoning effort.
scottzx added a commit to scottzx/1agents that referenced this pull request Jun 14, 2026
Bumps modules/1acp from b54f87e to 9ca943a, pulling in the pnpm patch for
@agentclientprotocol/codex-acp@0.0.44 so web chat honors the model set in
~/.codex/config.toml (e.g. a custom provider's MiniMax-M3) instead of being
forced onto codex-acp's built-in default (gpt-5.5).

See 1acp#2. Upstream fix: agentclientprotocol/codex-acp#199.

Fixes #43

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant