mirror of
https://github.com/block/goose.git
synced 2026-04-28 19:49:51 +00:00
docs: new multi-model section with autopilot topic (#4864)
This commit is contained in:
parent
1c424303c2
commit
976e663887
12 changed files with 233 additions and 12 deletions
|
|
@ -13,6 +13,10 @@ 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:
|
||||
|
|
@ -101,7 +105,7 @@ export RUST_LOG=goose::providers::lead_worker=info
|
|||
```
|
||||
|
||||
## Planning Mode Compatibility
|
||||
The lead/worker model is an automatic alternative to the [Goose CLI's `/plan` command](/docs/guides/creating-plans.md). You can assign separate models to use as the lead/worker and planning models. For example:
|
||||
The lead/worker model is an automatic alternative to the [Goose CLI's `/plan` command](/docs/guides/multi-model/creating-plans). You can assign separate models to use as the lead/worker and planning models. For example:
|
||||
|
||||
```bash
|
||||
export GOOSE_PROVIDER="openai"
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: "Learn how to use Goose's Plan feature to break down complex tasks
|
|||
|
||||
Using Goose for large, complex tasks can feel overwhelming, especially when you're unsure of exactly how you want to approach it in advance. I experienced this when I needed to set up a complex development environment for an [API course](https://github.com/LinkedInLearning/java-automated-api-testing-with-rest-assured-5989068) I published. Between Docker configurations, database initialization, devcontainer setup, and GitHub Codespaces integration, there are dozens of moving pieces that need to work together perfectly. One missing configuration or incorrect dependency can derail the entire process.
|
||||
|
||||
This tutorial shows you how to use Goose's [Plan feature](/docs/guides/creating-plans) to transform a complex devcontainer setup into a systematic, executable roadmap. You'll learn how to brainstorm with Goose, refine your requirements, and let Goose create both a detailed plan and implementation checklist.
|
||||
This tutorial shows you how to use Goose's [Plan feature](/docs/guides/multi-model/creating-plans) to transform a complex devcontainer setup into a systematic, executable roadmap. You'll learn how to brainstorm with Goose, refine your requirements, and let Goose create both a detailed plan and implementation checklist.
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue