chore: remove autopilot experimental feature

[michaelneale]

"Autopilot" was an experiment in using heuristics to switch models, but it hasn't been widely used, nor has it been that successful.

some limitations:

• config is complex
• rules are complex for when models kick in
• doesn't manage context appropriately for different models
• different models can behave radically different if you switch around without managing the context

I think a better approach in future would be:

1. similar to lead/worker, a virtual provider that routes requests to appropriate model based on accumulated context and user signals
2. use a tool based approach to consult models when specific skills or advice are needed
3. have a sub-agent use a specialised model when needed (with its own context, as it does now, only reporting back results)
4. a new modality where session start/stop/continue with different contexts and different models but with common goal (eg a planner/executor or coach/player) more autonimously, where there is a natural point to swith models

1 above can be done today with virtual providers like openrouter

2 to 4 are natural places to switch providers or models to get best effect (and in 3, can even be in parallel)

[Copilot]

Pull Request Overview

This PR removes the experimental AutoPilot feature, which provided context-aware automatic model switching based on conversation content, complexity, and tool usage patterns. The feature proved too complex with limitations around configuration complexity, unclear switching rules, and poor context management across different models.

• Complete removal of AutoPilot implementation code (~1,366 lines)
• Deletion of all AutoPilot configuration files and documentation
• Clean removal of AutoPilot integration from Agent class

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
documentation/docs/tutorials/lead-worker.md	Removed AutoPilot promotional tip that referenced the now-deleted feature
documentation/docs/guides/multi-model/creating-plans.md	Updated multi-model alternatives section to only mention Lead/Worker mode, removed AutoPilot reference
documentation/docs/guides/multi-model/autopilot.md	Complete deletion of AutoPilot documentation (127 lines)
crates/goose/src/agents/model_selector/premade_roles.yaml	Deleted pre-made AutoPilot role configurations (181 lines)
crates/goose/src/agents/model_selector/mod.rs	Deleted module declaration for autopilot
crates/goose/src/agents/model_selector/autopilot.rs	Deleted complete AutoPilot implementation (1,366 lines including tests)
crates/goose/src/agents/model_selector/README.md	Deleted AutoPilot feature README
crates/goose/src/agents/mod.rs	Removed model_selector module from agents
crates/goose/src/agents/agent.rs	Removed AutoPilot field from Agent struct, removed AutoPilot import and initialization, removed model switching logic from reply loop

Note: There are some stale AutoPilot references in documentation files that are not part of this PR (experimental/index.md, config-files.md, and environment-variables.md). These should be addressed in a follow-up to ensure complete removal of AutoPilot references from the documentation.

[github-actions]

PR Preview Action v1.6.0
Preview removed because the pull request was closed.
2025-11-19 00:49 UTC

[taniandjerry]

Autopilot used has been referenced from us in conjunction with lead/worker model as a solution to tokens being eaten up, namely for folks who can't use OpenRouter.

As long as as the proposed solution we give community members doesn't solely depend on OpenRouter, then it's okay to remove Autopilot.

I haven't seen much mention of Autopilot explicitly by community members, but I have seen mentions of concerns with tokens being eaten up and how to best manage that.

[michaelneale]

@taniandjerry yeah - I wouldn't recommend it for low cost reasons as it may not end up saving (could end up costing more if it moves around, less caching) - lead worker is a little better, as you can have lead as the pricey one and worker as low cost grinding one. Am curious what combo of models people use for cost when that is a case, and token use, as that seems a separate thing to address (and I know @DOsinga has been thinking about it - likely a lot of things that can massively reduce the token use coming).

I could also see an approach which has fallback providers - ie use them in order (low cost first), but this doesn't do that.

and no future solution would depend on it, no.

[michaelneale]

@taniandjerry so youok with removing this (and docs) in that case?

[blackgirlbytes]

im okay with removing this. chatted with my team..and yes let's remove the documentation around this.