provider field in settings.default.json, and you can mix providers across phases by setting analysis and execution models separately. Each provider ships with its own CLI adapter and stream parser, so the rest of the workflow engine stays unchanged regardless of which provider you choose.
Supported providers
dotbot ships with five providers. Each one wraps a command-line tool and exposes its own permission modes that control how autonomous the AI is during execution.claude is the default provider. Each provider’s full configuration lives in a JSON file under content/settings/providers/ (for example, content/settings/providers/claude.json).
Antigravity (Google) replaces the former Gemini provider. Its executable is
agy, and its default permission mode is yolo.Permission modes
Permission modes map to provider-specific CLI flags. The first mode listed for each provider is its default.Switching providers
Set theprovider field in settings.default.json to one of the five provider names. Leave permission_mode as null to use the provider’s own default mode, or set it to a valid mode from the table above to override that default:
settings.default.json
Model tiers
dotbot does not reference model names like Sonnet or Opus directly in your workflow. Instead, each provider exposes three capability tiers:fast, balanced, and best. Every provider defaults to best. The providers block in settings.default.json maps each tier to a concrete model for that provider:
settings.default.json
Setting analysis and execution tiers
Theanalysis.model and execution.model fields set the baseline tier for every task that does not declare its own. Both default to best. Point them at different tiers to balance cost and quality across phases:
settings.default.json
fast, balanced, or best), not a model name. dotbot resolves the tier to a concrete model through the provider’s models mapping at run time.
Per-task tier overrides
An individual task inworkflow.json can set a model field that overrides the baseline tier for that one task. Use a lighter tier for straightforward steps and reserve best for open-ended reasoning:
Tier resolution order
When dotbot resolves which model to use for a task, it evaluates these sources from highest to lowest priority:- The
modeltier on the individual task inworkflow.json. - The
execution.model(oranalysis.model) tier insettings.default.json. - The provider’s
default_model(best).
models block. The first non-null value in the chain wins.
Verifying provider availability
Rundotbot doctor to check that a provider CLI is installed and on your PATH:
claude, codex, agy, opencode, or copilot) is found. When you start a run, dotbot also verifies that the configured provider’s executable is available and fails early with a clear message if it is missing.
dotbot delegates authentication to each provider’s own CLI. Sign in with the provider’s tool (for example,
claude or codex) before starting a run, and confirm the CLI is on your PATH with dotbot doctor.