chore: remove autopilot experimental feature (#5781)
This commit is contained in:
Michael Neale
@@ -56,7 +56,6 @@ use tokio_util::sync::CancellationToken;
|
||||
use tracing::{debug, error, info, instrument, warn};
|
||||
|
||||
use super::final_output_tool::FinalOutputTool;
|
||||
use super::model_selector::autopilot::AutoPilot;
|
||||
use super::platform_tools;
|
||||
use super::tool_execution::{ToolCallResult, CHAT_MODE_TOOL_SKIPPED_RESPONSE, DECLINED_RESPONSE};
|
||||
use crate::agents::subagent_task_config::TaskConfig;
|
||||
@@ -105,7 +104,6 @@ pub struct Agent {
|
||||
pub(super) scheduler_service: Mutex<Option<Arc<dyn SchedulerTrait>>>,
|
||||
pub(super) retry_manager: RetryManager,
|
||||
pub(super) tool_inspection_manager: ToolInspectionManager,
|
||||
pub(super) autopilot: Mutex<AutoPilot>,
|
||||
}
|
||||
|
||||
#[derive(Clone, Debug)]
|
||||
@@ -180,7 +178,6 @@ impl Agent {
|
||||
scheduler_service: Mutex::new(None),
|
||||
retry_manager: RetryManager::new(),
|
||||
tool_inspection_manager: Self::create_default_tool_inspection_manager(),
|
||||
autopilot: Mutex::new(AutoPilot::new()),
|
||||
}
|
||||
}
|
||||
|
||||
@@ -933,19 +930,6 @@ impl Agent {
|
||||
break;
|
||||
}
|
||||
|
||||
{
|
||||
let mut autopilot = self.autopilot.lock().await;
|
||||
if let Some((new_provider, role, model)) = autopilot.check_for_switch(&conversation, self.provider().await?).await? {
|
||||
debug!("AutoPilot switching to {} role with model {}", role, model);
|
||||
self.update_provider(new_provider).await?;
|
||||
|
||||
yield AgentEvent::ModelChange {
|
||||
model: model.clone(),
|
||||
mode: format!("autopilot:{}", role),
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
let conversation_with_moim = super::moim::inject_moim(
|
||||
conversation.clone(),
|
||||
&self.extension_manager,
|
||||
|
||||
@@ -7,7 +7,6 @@ pub mod extension_manager_extension;
|
||||
pub mod final_output_tool;
|
||||
mod large_response_handler;
|
||||
pub mod mcp_client;
|
||||
pub mod model_selector;
|
||||
pub mod moim;
|
||||
pub mod platform_tools;
|
||||
pub mod prompt_manager;
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
# Autopilot model selector
|
||||
|
||||
This is an advanced feature (config of which may change, use with caution for now)
|
||||
which lets goose automatically rotate through many providers and models based on rules that trigger as part of its work.
|
||||
|
||||
Models can change at any time, and can help (similar to lead/worker) solve persistent issues, get an advanced plan, a second opinion or more.
|
||||
|
||||
`premade_roles.yaml` are the out of the box configurations, which can be used in the `~/.config/goose/config.yaml` like so:
|
||||
|
||||
|
||||
```yaml
|
||||
x-advanced-models:
|
||||
- provider: databricks
|
||||
model: goose-gpt-5
|
||||
role: reviewer
|
||||
- provider: anthropic
|
||||
model: claude-opus-4-1-20250805
|
||||
role: deep-thinker
|
||||
```
|
||||
|
||||
in this case, when there is some complex activity or planning or thining required, it will automatically switch to opus for a while, likewise when code changes have been made, it will use the reviewer model.
|
||||
|
||||
## Use cases
|
||||
|
||||
You can do a lead/worker like combo, or you can default to a low cost model and only in some cases use a frontier model.
|
||||
You could default to a local model, and only intermittently switch when needed.
|
||||
|
||||
use `--debug` flag if you want to see it logging when it changes.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1 +0,0 @@
|
||||
pub mod autopilot;
|
||||
@@ -1,181 +0,0 @@
|
||||
# Pre-made AutoPilot roles with default rules
|
||||
# These define the default behaviors for common roles
|
||||
# Users must specify the provider and model in their config.yaml
|
||||
|
||||
roles:
|
||||
# Lead model - high-capability model for initial turns and failure recovery
|
||||
- role: "lead"
|
||||
rules:
|
||||
triggers:
|
||||
# Triggers at conversation start AND on consecutive failures
|
||||
first_turn: true # Trigger on first turn
|
||||
consecutive_failures: 2 # Same as GOOSE_LEAD_FAILURE_THRESHOLD default
|
||||
source: "any" # Can trigger on both human (start) and machine (failures)
|
||||
active_turns: 3 # Same as GOOSE_LEAD_TURNS default (initial) and GOOSE_LEAD_FALLBACK_TURNS for failures
|
||||
priority: 30 # Highest priority to ensure it always triggers first
|
||||
|
||||
- role: "second-opinion"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["help"]
|
||||
match_type: "any"
|
||||
after_tool_use: true
|
||||
source: "human"
|
||||
active_turns: 5
|
||||
priority: 5
|
||||
|
||||
# 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
|
||||
|
||||
# Consult the oracle
|
||||
- role: "oracle"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["think", "reason", "analyze", "explain why", "what if"]
|
||||
match_type: "any"
|
||||
complexity_threshold: "medium"
|
||||
source: "human" # Only trigger on human messages
|
||||
active_turns: 5
|
||||
priority: 15
|
||||
|
||||
# Consult the planner
|
||||
- role: "planner"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["think", "plan", "help me", "look at", "consider"]
|
||||
match_type: "any"
|
||||
complexity_threshold: "low"
|
||||
source: "any" # Only trigger on human messages
|
||||
active_turns: 3
|
||||
priority: 5
|
||||
|
||||
|
||||
|
||||
# Code debugging and error recovery
|
||||
- role: "debugger"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["error", "bug", "broken", "failed", "exception"]
|
||||
match_type: "any"
|
||||
on_failure: true
|
||||
source: "any" # Can trigger on both human and machine failures
|
||||
active_turns: 2
|
||||
priority: 15 # High priority for error handling
|
||||
|
||||
# Code implementation specialist
|
||||
- role: "coder"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["implement", "code", "function", "class", "refactor", "optimize"]
|
||||
match_type: "any"
|
||||
after_tool_use: true
|
||||
source: "human"
|
||||
active_turns: 2
|
||||
priority: 8
|
||||
|
||||
# Verification and review
|
||||
- role: "reviewer"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["check", "verify", "review", "validate", "test", "correct"]
|
||||
match_type: "any"
|
||||
consecutive_tools: 12 # After many changes
|
||||
source: "any" # Can be triggered by human request OR after lots of tool use
|
||||
active_turns: 2
|
||||
priority: 6
|
||||
|
||||
# Help and guidance specialist
|
||||
- role: "helper"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["help", "assist", "guide", "explain", "teach", "how to"]
|
||||
match_type: "any"
|
||||
source: "human"
|
||||
active_turns: 5
|
||||
priority: 5
|
||||
|
||||
# Math and calculations
|
||||
- role: "mathematician"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["calculate", "solve", "equation", "math", "formula", "compute"]
|
||||
match_type: "any"
|
||||
complexity_threshold: "medium"
|
||||
source: "human"
|
||||
active_turns: 1
|
||||
priority: 7
|
||||
|
||||
# Creative brainstorming
|
||||
- role: "creative"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["idea", "brainstorm", "creative", "innovate", "design", "imagine"]
|
||||
match_type: "any"
|
||||
source: "human"
|
||||
active_turns: 5
|
||||
priority: 4
|
||||
|
||||
# Quick responses for simple queries
|
||||
- role: "quick-responder"
|
||||
rules:
|
||||
triggers:
|
||||
complexity_threshold: "low"
|
||||
source: "human"
|
||||
active_turns: 0
|
||||
priority: 2
|
||||
|
||||
# Research and fact-checking
|
||||
- role: "researcher"
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["research", "find", "search", "lookup", "fact", "source", "reference"]
|
||||
match_type: "any"
|
||||
source: "human"
|
||||
active_turns: 3
|
||||
priority: 6
|
||||
|
||||
# System recovery after multiple failures
|
||||
- role: "recovery-specialist"
|
||||
rules:
|
||||
triggers:
|
||||
consecutive_failures: 2 # After 2 consecutive tool failures
|
||||
source: "machine" # Only triggers on machine-generated failures
|
||||
active_turns: 10
|
||||
priority: 20 # Very high priority
|
||||
|
||||
# Autonomous work reviewer - kicks in after lots of machine work
|
||||
- role: "work-reviewer"
|
||||
rules:
|
||||
triggers:
|
||||
tools_since_human: 5 # After 5+ tools used since last human input
|
||||
source: "machine" # Only when machine is active
|
||||
active_turns: 8
|
||||
priority: 12
|
||||
|
||||
# Progress checker - ensures the machine isn't going off track
|
||||
- role: "progress-checker"
|
||||
rules:
|
||||
triggers:
|
||||
machine_messages_without_human: 4 # After 4+ consecutive machine messages
|
||||
source: "machine"
|
||||
active_turns: 5
|
||||
priority: 11
|
||||
|
||||
# Intensive work monitor - for when lots of tool use is happening
|
||||
- role: "intensive-work-monitor"
|
||||
rules:
|
||||
triggers:
|
||||
consecutive_tools: 10 # 10+ tools in a row
|
||||
messages_since_human: 6 # AND been working for 6+ messages
|
||||
source: "machine"
|
||||
active_turns: 10
|
||||
priority: 14
|
||||
|
||||
@@ -29,11 +29,6 @@ The list of experimental features may change as Goose development progresses. So
|
||||
description="An experimental Android automation app that acts as an open agent running on your phone, providing maximal automation of everyday tasks."
|
||||
link="/docs/experimental/goose-mobile"
|
||||
/>
|
||||
<Card
|
||||
title="Automatic Multi-Model Switching"
|
||||
description="Intelligent, context-aware switching between models based on conversation content, complexity, and tool usage patterns."
|
||||
link="/docs/guides/multi-model/autopilot"
|
||||
/>
|
||||
<Card
|
||||
title="Using goose in ACP Clients"
|
||||
description="Interact with goose natively in ACP-compatible clients like Zed."
|
||||
@@ -77,4 +72,4 @@ The list of experimental features may change as Goose development progresses. So
|
||||
link="https://discord.gg/goose-oss"
|
||||
/>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -787,7 +787,6 @@ This method simplifies authentication and enhances security for enterprise envir
|
||||
|
||||
Beyond single-model setups, goose supports [multi-model configurations](/docs/guides/multi-model/) that can use different models and providers for specialized tasks:
|
||||
|
||||
- **AutoPilot** - Intelligent, context-aware switching between specialized models based on conversation content and complexity
|
||||
- **Lead/Worker Model** - Automatic switching between a lead model for initial turns and a worker model for execution tasks
|
||||
- **Planning Mode** - Manual planning phase using a dedicated model to create detailed project breakdowns before execution
|
||||
|
||||
|
||||
@@ -48,10 +48,6 @@ The following settings can be configured at the root level of your config.yaml f
|
||||
| `security_prompt_enabled` | Enable [prompt injection detection](/docs/guides/security/prompt-injection-detection) to identify potentially harmful commands | true/false | false | No |
|
||||
| `security_prompt_threshold` | Sensitivity threshold for [prompt injection detection](/docs/guides/security/prompt-injection-detection) (higher = stricter) | Float between 0.01 and 1.0 | 0.7 | No |
|
||||
|
||||
:::info Automatic Multi-Model Configuration
|
||||
The experimental [AutoPilot](/docs/guides/multi-model/autopilot) feature provides intelligent, context-aware model switching. Configure models for different roles using the `x-advanced-models` setting.
|
||||
:::
|
||||
|
||||
## Experimental Features
|
||||
|
||||
These settings enable experimental features that are in active development. These may change or be removed in future releases.
|
||||
@@ -177,4 +173,4 @@ This will show all active settings and their current values.
|
||||
|
||||
- **[Multi-Model Configuration](/docs/guides/multi-model/)** - For multiple model-selection strategies
|
||||
- **[Environment Variables](./environment-variables.md)** - For environment variable configuration
|
||||
- **[Using Extensions](/docs/getting-started/using-extensions.md)** - For more details on extension configuration
|
||||
- **[Using Extensions](/docs/getting-started/using-extensions.md)** - For more details on extension configuration
|
||||
|
||||
@@ -52,10 +52,6 @@ export GOOSE_PROVIDER__API_KEY="your-api-key-here"
|
||||
|
||||
These variables configure a [lead/worker model pattern](/docs/tutorials/lead-worker) where a powerful lead model handles initial planning and complex reasoning, then switches to a faster/cheaper worker model for execution. The switch happens automatically based on your settings.
|
||||
|
||||
:::info Automatic Multi-Model Switching
|
||||
The experimental [AutoPilot](/docs/guides/multi-model/autopilot) feature provides intelligent, context-aware model switching. Configure models for different roles using the `x-advanced-models` setting.
|
||||
:::
|
||||
|
||||
| Variable | Purpose | Values | Default |
|
||||
|----------|---------|---------|---------|
|
||||
| `GOOSE_LEAD_MODEL` | **Required to enable lead mode.** Name of the lead model | Model name (e.g., "gpt-4o", "claude-sonnet-4-20250514") | None |
|
||||
|
||||
@@ -1,127 +0,0 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: Automatic Multi-Model Switching
|
||||
sidebar_label: Automatic Model Switching
|
||||
---
|
||||
|
||||
The AutoPilot feature enables intelligent, context-aware switching between different models. You simply work naturally with goose, and AutoPilot chooses the right model based on conversation content, complexity, tool usage patterns, and other triggers.
|
||||
|
||||
:::warning Experimental Feature
|
||||
AutoPilot is an experimental feature. Behavior and configuration may change in future releases.
|
||||
:::
|
||||
|
||||
## How AutoPilot Works
|
||||
|
||||
After you configure which models to use for different roles, AutoPilot handles the rest. During your sessions, it automatically switches to the most appropriate model for your current task—whether you need specialized coding help, complex reasoning, or just want a second opinion.
|
||||
|
||||
**For example:**
|
||||
- When you ask to "debug this error," AutoPilot switches to a model optimized for debugging
|
||||
- When you request "analyze the performance implications," it switches to a model better suited for complex reasoning
|
||||
- When you're doing repetitive coding tasks, it uses a cost-effective model, but escalates to a more powerful one when it encounters failures
|
||||
|
||||
Switching happens automatically based on:
|
||||
- The terminology used in your requests ("debug", "analyze", "implement")
|
||||
- How complex the task appears to be
|
||||
- Whether previous attempts have failed and need a different approach
|
||||
- How much autonomous work has been happening without your input
|
||||
|
||||
When AutoPilot switches to a specialized model, it stays with that model for a configured number of <abbr title="A turn is one complete prompt-response interaction between goose and the LLM" style={{ textUnderlineOffset: "3px" }}>turns</abbr> before evaluating whether to switch back to the base model or to a different specialized model based on the new context.
|
||||
|
||||
:::info
|
||||
You can use `goose session --debug` in goose CLI to see when AutoPilot switches models. Note that each switch applies the provider's rate limits and pricing.
|
||||
:::
|
||||
|
||||
## Configuration
|
||||
|
||||
Add the `x-advanced-models` section to your [`config.yaml`](/docs/guides/config-files) file and map your model preferences to [predefined](#predefined-roles) or custom roles.
|
||||
|
||||
The `provider`, `model` and `role` parameters are required.
|
||||
|
||||
```yaml
|
||||
# Base provider and model (always available)
|
||||
GOOSE_PROVIDER: "anthropic"
|
||||
GOOSE_MODEL: "claude-sonnet-4-20250514"
|
||||
|
||||
# AutoPilot models
|
||||
x-advanced-models:
|
||||
- provider: openai
|
||||
model: o1-preview
|
||||
role: deep-thinker
|
||||
- provider: openai
|
||||
model: gpt-4o
|
||||
role: debugger
|
||||
- provider: anthropic
|
||||
model: claude-opus-4-20250805
|
||||
role: reviewer
|
||||
```
|
||||
|
||||
**Migrate From Lead/Worker Model**
|
||||
|
||||
This example shows how you can reproduce [lead model](/docs/tutorials/lead-worker) behavior using `x-advanced-models`.
|
||||
|
||||
```yaml
|
||||
# Before: Defined lead model using environment variables
|
||||
# GOOSE_LEAD_PROVIDER=openai
|
||||
# GOOSE_LEAD_MODEL=o1-preview
|
||||
|
||||
# After: AutoPilot equivalent
|
||||
GOOSE_PROVIDER: "anthropic"
|
||||
GOOSE_MODEL: "claude-sonnet-4-20250514" # Base is used as the worker model
|
||||
|
||||
x-advanced-models:
|
||||
- provider: openai
|
||||
model: o1-preview
|
||||
role: lead # Use the predefined lead role (or define a custom role)
|
||||
```
|
||||
|
||||
### Predefined Roles
|
||||
|
||||
AutoPilot includes a set of predefined roles defined in [`premade_roles.yaml`](https://github.com/block/goose/blob/main/crates/goose/src/agents/model_selector/premade_roles.yaml) that goose is aware of by default. Examples include:
|
||||
|
||||
- **deep-thinker**: Activates for complex reasoning tasks
|
||||
- **debugger**: Switches in for error resolution
|
||||
- **reviewer**: Monitors after extensive tool usage
|
||||
- **coder**: Handles code implementation tasks
|
||||
- **mathematician**: Processes mathematical computations
|
||||
|
||||
### Custom Roles
|
||||
|
||||
You can create custom roles with specific triggers by defining them in your `config.yaml` file:
|
||||
|
||||
```yaml
|
||||
x-advanced-models:
|
||||
- provider: openai
|
||||
model: gpt-4o
|
||||
role: custom-debugger
|
||||
rules:
|
||||
triggers:
|
||||
keywords: ["bug", "broken", "failing", "crash"]
|
||||
consecutive_failures: 1
|
||||
active_turns: 5
|
||||
priority: 15
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>Custom Role Configuration Fields</summary>
|
||||
|
||||
**Rule Configuration:**
|
||||
| Parameter | Description | Values |
|
||||
|-----------|-------------|---------|
|
||||
| `triggers` | Conditions that activate the role | Object (see parameters below) |
|
||||
| `active_turns` | Number of turns the rule stays active once triggered | Integer (default: 5) |
|
||||
| `priority` | Selection priority when multiple roles match | Integer (higher wins, default: 0) |
|
||||
|
||||
**Trigger Parameters:**
|
||||
|
||||
| Parameter | Description | Values |
|
||||
|-----------|-------------|---------|
|
||||
| `keywords` | Words that activate the role | Array of strings |
|
||||
| `match_type` | How to match keywords | "any", "all" |
|
||||
| `complexity_threshold` | Minimum complexity level | "low", "medium", "high" |
|
||||
| `consecutive_failures` | Failures in sequence | Integer |
|
||||
| `first_turn` | Trigger on conversation start | Boolean |
|
||||
| `source` | Message source filter | "human", "machine", "any" |
|
||||
|
||||
The previous table includes several common rule trigger parameters. For the complete list, see the `TriggerRules` struct in [`autopilot.rs`](https://github.com/block/goose/blob/main/crates/goose/src/agents/model_selector/autopilot.rs).
|
||||
|
||||
</details>
|
||||
@@ -34,10 +34,8 @@ The goose CLI plan mode uses two configuration values:
|
||||
- `GOOSE_PLANNER_PROVIDER`: Which provider to use for planning
|
||||
- `GOOSE_PLANNER_MODEL`: Which model to use for planning
|
||||
|
||||
:::tip Multi-Model Alternatives to Plan Mode
|
||||
goose also supports two options for automatic model switching that help balance model capabilities with cost and speed:
|
||||
- **[Lead/Worker mode](/docs/guides/environment-variables#leadworker-model-configuration)**: Turn-based switching between two models
|
||||
- **[AutoPilot](/docs/guides/multi-model/autopilot)**: Context-aware switching between multiple models
|
||||
:::tip Multi-Model Alternative to Plan Mode
|
||||
goose also supports automatic model switching with [Lead/Worker mode](/docs/guides/environment-variables#leadworker-model-configuration), which provides turn-based switching between two models to help balance model capabilities with cost and speed.
|
||||
:::
|
||||
|
||||
### Set goose planner environment variables
|
||||
@@ -329,4 +327,4 @@ To enter planning mode, type `/plan`. Optionally, you can append your plan desc
|
||||
link="/docs/tutorials/plan-feature-devcontainer-setup"
|
||||
/>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -17,11 +17,6 @@ import TabItem from '@theme/TabItem';
|
||||
<div className={styles.categorySection}>
|
||||
<h2 className={styles.categoryTitle}>📚 Documentation & Guides</h2>
|
||||
<div className={styles.cardGrid}>
|
||||
<Card
|
||||
title="Automatic Multi-Model Switching"
|
||||
description="Intelligent switching between models based on conversation content, complexity, and tool usage patterns."
|
||||
link="/docs/guides/multi-model/autopilot"
|
||||
/>
|
||||
<Card
|
||||
title="Lead/Worker Multi-Model Setup"
|
||||
description="Automatic switching between models using a lead model for initial turns and a worker model for execution."
|
||||
|
||||
@@ -25,10 +25,6 @@ The lead/worker model is a smart hand-off system. The "lead" model (think: GPT-4
|
||||
|
||||
If things go sideways (e.g. the worker model gets confused or keeps making mistakes), Goose notices and automatically pulls the lead model back in to recover. Once things are back on track, the worker takes over again.
|
||||
|
||||
:::tip Consider AutoPilot for Advanced Model Switching
|
||||
[AutoPilot](/docs/guides/multi-model/autopilot) supports turn-based switching and also offers intelligent context-aware switching between multiple models.
|
||||
:::
|
||||
|
||||
## Turn-Based System
|
||||
|
||||
A **turn** is one full interaction - your prompt and the model's response. Goose switches models based on turns:
|
||||
@@ -127,4 +123,4 @@ export GOOSE_LEAD_MODEL="o1-preview" # the lead model used automatically
|
||||
export GOOSE_PLANNER_MODEL="gpt-4o" # the model used when you explicitly call /plan
|
||||
```
|
||||
|
||||
Use **planning mode** when you want a dedicated reasoning model to generate comprehensive strategies that you can review and approve before execution. Use the **lead/worker model** for iterative development work where you want smart automation without interruption - like implementing features, debugging issues, or exploratory coding. Your workflow can combine both: use `/plan` to strategize major decisions, then let the lead/worker models handle the tactical implementation with automatic optimization.
|
||||
Use **planning mode** when you want a dedicated reasoning model to generate comprehensive strategies that you can review and approve before execution. Use the **lead/worker model** for iterative development work where you want smart automation without interruption - like implementing features, debugging issues, or exploratory coding. Your workflow can combine both: use `/plan` to strategize major decisions, then let the lead/worker models handle the tactical implementation with automatic optimization.
|
||||
|
||||
Reference in New Issue
Block a user