feat(cli): change thinking effort mid-session with /model --effort - #13248

Add the new effort command to the self-test recipe

This feature adds a new interactive command but leaves goose-self-test.yaml unchanged, so the required end-to-end feature verification never exercises the new session mutation path; add a self-test case or phase for /model --effort and run the recipe before merging.

AGENTS.md reference: AGENTS.md:L102-L102

Useful? React with 👍 / 👎.

Added a CLI effort section to the thinking-effort phase of goose-self-test.yaml in 076f0d0, and bare /model now shows the effective effort so the steps can be checked. I ran step 1 (cargo test -p goose-cli effort: 4 tests pass). Steps 2-4 need an interactive session on a live reasoning model, and I have not run those.

Delegate no-op detection to the effort-aware provider

When an ACP-backed CLI session's agent resets its effort (for example after rebuilding its selector during an internal model change), the session's persisted ModelConfig can still equal effort while the provider's mirrored current value does not; AcpProvider::set_effort_option intentionally uses that mirrored value for this reason. This early return bypasses update_thinking_effort, falsely reports the old level as active, and makes /model --effort ... unable to reapply it, so let the service/provider decide whether the update is redundant.

Useful? React with 👍 / 👎.

Agreed. In 076f0d0 I removed the CLI-side no-op check, so every /model --effort goes through update_thinking_effort and the provider decides whether the value is redundant.

Reject effort updates unsupported by managed providers

When the current provider is claude-code, /model --effort low enters this branch before the later manages_own_context rejection. ClaudeCodeProvider inherits the default set_thinking_effort (Ok(false)) and its stream only consumes model_config.model_name (crates/goose/src/providers/claude_code.rs:749-766), so update_thinking_effort merely persists a request parameter and this helper prints success while the Claude harness behavior is unchanged. Gate this branch on provider effort support (or implement forwarding) rather than claiming the setting was applied.

Useful? React with 👍 / 👎.

Good catch. In 91c5446 /model --effort is now rejected when the provider manages its own context and reports ThinkingEffortSupport::Unspecified, so claude-code no longer gets a success message for a setting it ignores. ACP providers that advertise an effort option still go through update_thinking_effort. I added model_effort_flag_is_rejected_for_providers_that_ignore_it, which fails without the check.

Hide effort status for providers that ignore it

When a claude-code session starts with GOOSE_THINKING_EFFORT=high, model-config materialization records high, but ClaudeCodeProvider only forwards model_name from that config when spawning the harness (crates/goose/src/providers/claude_code.rs:385-400). These lines therefore make bare /model report thinking effort 'high' as active even though the setter immediately above correctly rejects effort updates for this provider; derive or suppress the suffix based on the provider's effort support rather than treating the stored/global value as effective.

Useful? React with 👍 / 👎.

Agreed. In 425b1cc bare /model uses the same support check as --effort, so it shows no effort suffix for providers that manage their own context and have no effort option.

Reject efforts the target model cannot apply

When [model] selects a non-reasoning model, for example /model --effort high gpt-4o, this unconditionally persists the level and the success message reports it as applied. The OpenAI request builder deliberately produces no reasoning effort when openai_reasoning_for_model is false (crates/goose-provider-types/src/formats/openai.rs:1755-1770), and the configure flow only offers effort when model metadata says reasoning is supported (crates/goose-cli/src/commands/configure.rs:984-1002), so subsequent requests ignore high while bare /model continues to report it; validate the target model's supported effort choices before switching and apply the same validation to the no-model path.

Useful? React with 👍 / 👎.

In a435bbc I went with a warning rather than a rejection. Providers disagree on whether effort depends on reasoning support: openrouter, databricks_v2, ollama and the OpenAI chat format check is_reasoning_model(), while the anthropic, google and openai providers read thinking_effort() directly. Rejecting on is_reasoning_model() would therefore block models that do honor effort. /model --effort now prints a yellow warning when the target model is not known to be a reasoning model, the same way handle_model already warns about a smaller context window. If maintainers would rather reject, that is a one-line change.

Treat unsupported effort capabilities as unavailable

For an ACP-backed CLI session whose agent advertises no thought-level selector, AcpProvider::thinking_effort_support returns Unsupported and its setter rejects every non-off value, but this predicate only excludes Unspecified providers. With a saved or global high, bare /model therefore reports thinking effort 'high' as effective even though the harness cannot apply it, and /model --effort high is rejected; derive status from the support variant (including Options.current) and suppress or force off for Unsupported. The still-unhandled ACP support variants are fresh evidence beyond the earlier claude-code status case.

Useful? React with 👍 / 👎.

Fixed in f3f6e7b. Bare /model now derives the shown effort from thinking_effort_support(): Options shows the harness's current, Unsupported and self-managed Unspecified show nothing, and only plain Unspecified falls back to the session or global value. /model --effort for an Unsupported ACP agent still goes to the provider, which rejects non-off values with its own error. active_thinking_effort_follows_provider_support covers the four cases.

Warn when the chosen level is remapped

On a reasoning model with a restricted effort set—for example OpenAI gpt-5-pro, whose catalog entry lists only high (crates/goose-provider-types/src/canonical/data/canonical_models.json:201959-201965)—/model --effort low skips this warning because is_reasoning_model() is true. openai_reasoning_effort_for_thinking then falls back to high (crates/goose-provider-types/src/formats/openai.rs:1934-1957), while the command's success text and bare /model report the persisted low, which can silently increase reasoning cost and latency. Check the model's supported levels or report the mapped value; this restricted-level reasoning-model mapping is fresh evidence beyond the earlier non-reasoning-model case.

Useful? React with 👍 / 👎.

I am leaving this one out of this PR. The issue lists "no new provider-side effort mapping" as a non-goal, and the clamp to a model's supported levels happens in the provider format layer. Setting GOOSE_THINKING_EFFORT=low or using ACP session/set_thinking_effort on gpt-5-pro gets the same remap and reports the requested level the same way, so /model --effort matches the existing paths. Surfacing the mapped level would mean exposing the per-model clamp from the provider layer for all three entry points, and I think that belongs in a separate change. Happy to open an issue for it if maintainers want one.

Complete flags that follow the effort value

When the user enters a valid second flag such as /model --effort low --p<Tab>, this branch takes --p as the model partial and searches the current provider's model cache, so it never offers --provider (and after a full provider flag it cannot complete that provider's models). parse_model_command now accepts flags in any order and the CLI guide says slash commands support completion, so tokenize the already-consumed flags before choosing flag, provider, or model candidates.

Useful? React with 👍 / 👎.

Fixed in 58ec541. Completion now walks the tokens already typed, so /model --effort low --p offers --provider, a provider given after --effort scopes model completion, and --effort after --provider completes levels. I added cases for each to test_complete_model_names_effort.

Accept provider-advertised ACP effort values

In an ACP-backed interactive session whose thought selector advertises minimal (the bootstrap fixture does exactly this in crates/goose/tests/acp_bootstrap_effort_test.rs:76-128), this eagerly converts the argument to the five-value enum and rejects it before StateMachineServices::update_thinking_effort can forward it. ACP ThinkingEffortSupport::Options deliberately carries arbitrary raw values and AcpProvider::set_thinking_effort accepts exact offered values, so bare /model can report minimal as current while /model --effort minimal cannot select it; retain and validate the raw value for provider-managed options, and parse the enum only on the legacy path.

Useful? React with 👍 / 👎.

Fixed in f607bc9. When the provider reports ThinkingEffortSupport::Options, /model --effort forwards the raw value to update_thinking_effort and lets the harness validate it. The five built-in levels are parsed only on the legacy path. model_effort_flag_forwards_harness_values_unparsed checks that minimal reaches the session.

Stop suggesting a second model argument

In interactive completion, once a model token is followed by a space (for example /model claude-sonnet-4 ), this arm discards the already-consumed model; with an empty partial and no pending flag, the function then offers every model again. Selecting one makes parse_model_command produce a two-word model and handle_model rejects the command as Unexpected arguments after model name, so track whether a model was already consumed and stop returning model candidates in that state while still allowing later flag completion.

Useful? React with 👍 / 👎.

Fixed in f607bc9. Completion now tracks whether a model token was already typed and stops offering models after it, so /model claude-sonnet-4 --e still completes --effort. Both cases are in test_complete_model_names_effort.

Complete provider-advertised effort values

When an ACP-backed CLI session's harness advertises its own values (for example minimal in crates/goose/tests/acp_bootstrap_effort_test.rs:76-128), this arm still completes only the five legacy enum values. handle_model now deliberately accepts raw ThinkingEffortSupport::Options values, so tab completion never exposes minimal and suggests levels that the harness rejects; populate these candidates from the current provider capability (and avoid legacy candidates for unsupported providers) instead of always using THINKING_EFFORTS.

Useful? React with 👍 / 👎.

Fixed in 87d6acc. CompletionCache now holds the session provider's effort values, filled from thinking_effort_support() on refresh: harness options for Options, nothing for Unsupported or self-managed Unspecified, and the five built-in levels otherwise. /model --effort <Tab> completes from that list. thinking_effort_values_follow_provider_support covers the mapping, and the completion test covers harness values.

Refresh effort completions after capability updates

When an ACP-backed CLI session's agent emits a ConfigOptionUpdate that rebuilds its thought-level selector, AcpProvider immediately publishes the new support (crates/goose/src/acp/provider.rs:1260-1262), but this value is copied only during the general completion refresh and the CLI never subscribes to subscribe_thinking_effort_support. Consequently, /model --effort <Tab> continues offering removed choices or omitting newly valid ones until an unrelated provider/model/new-session refresh, even though command execution validates against the live capability; update this cache from the provider's support subscription.

Useful? React with 👍 / 👎.

I have left this out on purpose. Completion is only a hint: /model --effort sends the value to update_thinking_effort, which checks it against the live capability, so a stale list can cost a rejected Tab suggestion but never applies a wrong value. The cache already refreshes on the existing triggers (model or provider switch, new session). Keeping it current between those would mean running a background task in the CLI session on subscribe_thinking_effort_support. That is new lifecycle code, and I would rather not add it to this PR unless maintainers want it. It is straightforward to follow up with if they do.