feat: multi model and multi provider config and auto switching

[michaelneale]

This generalises the GOOSE_LEAD/WORKER variable structure with a more general multi model approach (ie can remove that old code path).
This is clearly marked with an x- experimental config prefix (as per convention) so the exact format can evolve as people use this.

This is really phase 1, phase 2 will be both GUI/ux changes to support and also having more opionionated defaults when providers are configured, but need to get this out in the wild so we can see how things perform with all the permutations of providers we can't test by hand.

For example, in config:

x-advanced-models:
- provider: databricks
  model: goose-gpt-5
  role: reviewer
- provider: anthropic
  model: claude-opus-4-1-20250805
  role: deep-thinker
- provider: anthropic
  model: claude-opus-4-1-20250805
  role: lead

which maps to premade_roles.yaml which define rules for those models and when they activate:

roles:
  # Deep reasoning and analysis
  - role: "deep-thinker"
    rules:
      triggers:
        keywords: ["think", "reason", "analyze", "explain why", "how does", "what if"]
        match_type: "any"
        complexity_threshold: "high"
        source: "human"  # Only trigger on human messages
      active_turns: 3
      priority: 10

which can be used as is - or each trigger value/setting can be overridding in the personal config (if one of the pre-made set doesn't fit - normally you just say role + provider + model - and let it work it out, but you can customise).

By default the main provider/model is used, and these will supplement when the rules are activate/met, and run for a certain amount of time (this already helped me as the gptoss:120B model was good at spotting short circuit logic bugs other models failed to see).

This could also be used to do most of the work in a low cost or zero cost local model as well.

run with --debug to see it log switching providers and models as it works

discussion #3980
implements: #4036

[joeeuston-dev]

This sounds like an awesome feature. Currently I'm having to switch models when I do more multi modal work as compared to my 'everything' model.

[michaelneale]

@joeeuston-dev yeah - I keep finding uses for it - still tuning what defaults I want, but lots of possibilities here and fairly simple in the end!

[jamadeo]

This is very cool and definitely something Goose needs IMO. I'm worried a bit about the number of knobs to turn with a setup like this though. Would users dive into things like triggering keywords, tool/turn counts and priority? If they would, how do you judge if you're tuning it well? Seems it would take quite a lot of trial and error.

What about an approach that uses a model to judge when to switch roles? If you're already configuring Goose to be multi-model, it could be a reasonable requirement to assign a model to have the role of "routing".

It could also be interesting to combine this with the TO-DO list strategy. Each TODO item gets a role pre-assigned.

[michaelneale]

@jamadeo "This is very cool and definitely something Goose needs IMO. I'm worried a bit about the number of knobs to turn with a setup like this though. Would users dive into things like triggering keywords, tool/turn counts and priority?"

no - I would hope they don't need to, they only time would be if they really went bespoke, and it is more about simplifying the changes to goose itself, as people discover patterns or learn them, vs needing to change code (similar to with providers we make it as easy as possible ideally to add another one). But absolutely no - they should only need to care about a few roles, we can even have some sensible default setup, and cli/gui can also suggest others - make sense?

[michaelneale]

@DOsinga thoughts on if we should consoldate model config to:

models:

... like this (can have that instead of a variable if we want)? this then can help the cli and GUI have a simpler structure to target when storing a model.

[michaelneale]

@jamadeo What about an approach that uses a model to judge when to switch roles?

I like that, wouldn't want it on each turn. One option is that early on it could use that model to "turn the nobs and dials" (ie can help select appropriate roles) which will then kick in so you don't have to? What I would like to get to is what is the minimal setup (ie if you setup N providers and M models - how can we best make use of them, how much do we do automatically and how much do we let users direct it).

[jamadeo]

Let's do it. I like it as an experiment and we definitely need the model-switching infrastructure. I think we'll change our minds on the switching logic and eventually have preferred models that fulfill each role.