feat: load provider/model specified inside the recipe config

[Abhijay007]

closes: #6562

PR description

The Recipe details view is likely pulling the provider/model from the global settings state instead of reading it from the recipe's YAML configuration.

Type of Change

• Feature

AI Assistance

• This PR was created or reviewed with AI assistance

Testing

Tested in the desktop UI with recipes and different cases

Screenshots/Demos (for UX changes)

Before:

After:

[Copilot]

Pull request overview

This PR fixes a bug where the Recipe details page in the Goose Desktop UI was displaying the globally-selected provider and model instead of the provider and model specified in the recipe's YAML configuration. The fix adds recipe-aware logic to the ModelsBottomBar component to prioritize displaying recipe-specific provider/model settings when available, falling back to global settings when not specified in the recipe.

Changes:

• Modified ModelsBottomBar component to accept a recipe prop and display recipe-specific provider/model when available
• Updated ChatInput to pass the recipe prop to ModelsBottomBar

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
ui/desktop/src/components/settings/models/bottom_bar/ModelsBottomBar.tsx	Added recipe prop and logic to extract and display provider/model from recipe settings, with fallback to global settings
ui/desktop/src/components/ChatInput.tsx	Pass recipe prop to ModelsBottomBar component

[zanesq]

@Abhijay007 these copilot comments look legit can you take a look? Also maybe this should be rebased/pointed at Abhijay007:feat/editModelGUI since they should probably merge to main at the same time?

[zanesq]

I tested this and I don't think its actually using the selected model once the recipe is loaded, it shows it at the bottom as selected but its still querying the global model in the chat.

[zanesq]

@Abhijay007 I realized that provider/model is already specified in the session there's just something missing, goose says:

Now I see the issue clearly. Looking at restore_provider_from_session:

pub async fn restore_provider_from_session(&self, session: &Session) -> Result<()> {
    let config = Config::global();

    let provider_name = session
        .provider_name
        .clone()
        .or_else(|| config.get_goose_provider().ok())  // Falls back to global config
        .ok_or_else(|| anyhow!("Could not configure agent: missing provider"))?;

    let model_config = match session.model_config.clone() {
        Some(saved_config) => saved_config,
        None => {
            // Falls back to global config
            let model_name = config
                .get_goose_model()
                .map_err(|_| anyhow!("Could not configure agent: missing model"))?;
            crate::model::ModelConfig::new(&model_name)
                .map_err(|e| anyhow!("Could not configure agent: invalid model {}", e))?
        }
    };
    // ...
}

The problem is that when a session is created with a recipe, the recipe's settings.goose_provider and settings.goose_model are never saved to the session's provider_name and model_config fields.

Looking at start_agent:

1. Session is created
2. Extensions are resolved from recipe and saved to session
3. Recipe is saved to session
4. But provider/model from recipe settings are NOT saved to session

Then when resume_agent calls restore_provider_from_session:

• session.provider_name is None (never set)
• session.model_config is None (never set)
• So it falls back to global config, ignoring the recipe's settings

The Fix

In start_agent, after saving the recipe to the session, we need to also save the provider/model from the recipe settings:

// In start_agent, after saving the recipe:
if let Some(ref recipe) = original_recipe {
    if let Some(ref settings) = recipe.settings {
        // Save recipe's provider/model to session so restore_provider_from_session uses them
        let mut update = manager.update(&session.id);
        
        if let Some(ref provider) = settings.goose_provider {
            update = update.provider_name(provider);
        }
        
        if let Some(ref model) = settings.goose_model {
            if let Ok(model_config) = ModelConfig::new(model) {
                update = update.model_config(model_config);
            }
        }
        
        update.apply().await.map_err(|err| {
            error!("Failed to update session with recipe provider/model: {}", err);
            ErrorResponse {
                message: format!("Failed to update session with recipe provider/model: {}", err),
                status: StatusCode::INTERNAL_SERVER_ERROR,
            }
        })?;
    }
}

This way, when restore_provider_from_session is called, it will find the recipe's provider/model in the session and use them instead of falling back to global config.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[zanesq]

@Abhijay007 I found the issue and pushed a fix, test it out and lmk what you think when you get a chance.

agent.rs - restore_provider_from_session now checks recipe.settings as a fallback between session-level overrides and global config, so the agent actually uses the recipe's model.

ModelsBottomBar.tsx - Tracks userChangedModel flag. When false, displays recipe model/provider. When true (after user submits a new model), displays the user's choice. Cancel doesn't flip the flag.

SwitchModelModal.tsx - New initialModel prop so the modal pre-selects the recipe's model when opened during a recipe session.

[zanesq]

Just pushed a better fix for the model/provider loading and bottom bar display syncing

[Abhijay007]

Just pushed a better fix for the model/provider loading and bottom bar display syncing

checking it now

[Abhijay007]

Tested LGTM