Repository navigation
Conversation
Claude's SDK confirms every `setModel` with a short API probe on a fixed
five-second deadline. When the probe misses it, the bridge returns an
internal error whose `details` read `Couldn't confirm model "<id>" with
the API…`, Staged's pre-prompt setup failed on the spot, and the same
selection was accepted seconds later on the next run. Session records
show this exact failure recurring for `claude-fable-5-1[1m]`.
The driver now treats that one error as confirmation uncertainty rather
than an unavailable model: on a Claude bridge, the identical
`session/set_config_option` request is sent once more after a one-second
delay on the same connection — two attempts total, never while an attempt
is still unanswered, and only for the model option. The existing setup
timeout and cancellation boundary still bound the whole exchange by
dropping the setup future, so a Stop during the delay or the second
attempt sends nothing further and no prompt is released. On success the
existing effort-selection, stale-effort skip, and fallback-announcement
logic continue unchanged and the queued prompt is released exactly once.
Exhausted recovery fails with a plain sentence ("Claude couldn't confirm
the selected model after two attempts. Your selection is unchanged; try
again.") that deliberately does not satisfy
`is_config_selection_unavailable_error`, so the saved model/effort
selection is kept. The matcher is isolated and keyed to the requested
(resolved) model and the adapter's `initialize` name; authentication,
invalid-selection, transport, and generic errors — and every other
adapter — keep their single attempt and Debug-shaped error. Each attempt
logs a sanitized record (phase, adapter, requested/resolved value,
attempt, duration, outcome) with no prompts, credentials, or raw
responses.
The runner's post-run selection clearing is extracted into
`clear_unavailable_acp_config_selection` so the retention contract can be
tested through the real path; its behaviour is unchanged.
Tests drive `run_acp_session` end to end against a scripted in-process
agent under paused time: fail-then-succeed, both fail, cancellation
during the delay and during the second attempt, non-matching errors and
another adapter, an already-current model, effort options changed by the
retried model, a retried fallback value, and setup-deadline expiry — plus
the matcher, the adapter key, and a runner persistence regression.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Matt Toohey <contact@matttoohey.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Claude's SDK confirms every
setModelwith a short API probe that has a fixed five-second deadline. When the probe misses that deadline, the bridge returns an internal error sayingCouldn't confirm model "<id>" with the API…. Staged's pre-prompt setup then failed straight away, even though the same model was accepted a few seconds later on the next run. Session records show this happening over and over forclaude-fable-5-1[1m].crates/acp-client/src/driver.rs): a newsend_config_selectionwrapssession/set_config_option. For the model option only, and only on a Claude bridge (identified by the name the agent gives oninitialize), it waits 1s after this exact error and sends the identical request one more time. That makes two attempts total, and a retry is never sent while an attempt is still unanswered. All other errors (auth, invalid value, transport, generic), other options and other adapters still get a single attempt, with error text unchanged.MODEL_CONFIRMATION_EXHAUSTED_MESSAGE). It deliberately doesn't matchis_config_selection_unavailable_error, so the session keeps its saved model/effort selection for the user's retry.session_runner.rs): the post-run clearing of a stale selection moves intoclear_unavailable_acp_config_selectionso it can be tested directly. Behaviour is unchanged.Tests
New
driver/tests/model_confirmation.rsrunsrun_acp_sessionend to end against a scripted in-process agent under paused time. It covers:It also covers the matcher and the adapter key. A runner test checks that a confirmation failure keeps the saved selection while a stale one is still cleared.
🤖 Generated with Claude Code