From cf8ee6a40768f22935bd300c55659e4bbc23d512 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:08:27 +0200 Subject: [PATCH 01/10] docs(getting-started): add interactive tour pointer to quickstart Mention `docker agent getting-started` after the first successful run so new users can discover the guided tour without digging through the CLI reference (not yet on main). --- docs/getting-started/quickstart/index.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/getting-started/quickstart/index.md b/docs/getting-started/quickstart/index.md index c42e42db31..0fc916feed 100644 --- a/docs/getting-started/quickstart/index.md +++ b/docs/getting-started/quickstart/index.md @@ -105,6 +105,16 @@ Once your agent is running, try asking it to: > [!TIP] > Add `--yolo` to auto-approve all tool calls: `docker agent run agent.yaml --yolo` +## Take the Interactive Tour + +Prefer to learn by doing? Run: + +```bash +$ docker agent getting-started +``` + +This launches a short, scripted tour inside the chat UI: sending messages, approving tool calls, the command palette, and slash commands. It's skippable at any point with Esc, and you can replay it later with the same command or the `/getting-started` slash command. + ## Non-Interactive Mode Use `docker agent run --exec` for one-shot tasks: From 384a4c4e09af8ba019352ad204db1873845fe648 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:10:37 +0200 Subject: [PATCH 02/10] docs(configuration): expand add_prompt_files into a Prompt Files subsection Cover file resolution order (cwd hierarchy walk + home dir), the per-turn re-read behavior, and the --prompt-file CLI flag as the one-off equivalent, with a runnable example. --- docs/configuration/agents/index.md | 34 ++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/configuration/agents/index.md b/docs/configuration/agents/index.md index 7812438c33..f2b819c389 100644 --- a/docs/configuration/agents/index.md +++ b/docs/configuration/agents/index.md @@ -177,6 +177,40 @@ contents are loaded as the agent's instruction when the config is loaded. Notes: A runnable example lives in [`examples/instruction_file.yaml`](https://github.com/docker/docker-agent/blob/main/examples/instruction_file.yaml). +## Prompt Files + +`add_prompt_files` injects the contents of one or more files into the agent's +context at the start of every turn — handy for repo-wide conventions like +`AGENTS.md` or `CLAUDE.md` that should stay available without being pasted +into `instruction`: + +```yaml +agents: + root: + model: anthropic/claude-sonnet-4-5 + description: A helpful coding assistant + instruction: You are an expert software developer. + add_prompt_files: + - AGENTS.md +``` + +For each name, the agent loads the closest match found by walking up from the +current working directory, plus (if it's a different file) a copy at that +name directly under the user's home directory — so a personal `~/AGENTS.md` +can layer on top of a repo-local one. Missing files are skipped rather than +erroring. Because resolution and the read happen on every turn, edits to the +file are picked up without restarting the agent. + +Use `--prompt-file` to add files for a single run without editing the +config. It's merged with any `add_prompt_files` already set on the agent, +with duplicates dropped: + +```bash +$ docker agent run agent.yaml --prompt-file CONTRIBUTING.md +``` + +Resolved prompt files show up as their own entries in the `/context` dialog — see [File Attachments](../../features/tui/index.md#file-attachments) in the Terminal UI guide. + ## Response Cache The response cache short-circuits the model when the same user question is asked again. The first time a question is asked, the agent calls the model normally and stores the assistant's reply. Subsequent identical questions skip the model entirely and replay the stored reply verbatim. From 6442d4cbba63eddc7472ee8e6091702f71c641ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:14:07 +0200 Subject: [PATCH 03/10] =?UTF-8?q?docs(style):=20naming=20sweep=20=E2=80=94?= =?UTF-8?q?=20getting-started=20+=20concepts?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace prose/front-matter uses of the product name 'docker-agent' with 'Docker Agent' per STYLE.md, in docs/getting-started/installation and docs/concepts/{agents,distribution,models,tools}. Preserved unchanged: canonical/alias URLs, the docker/docker-agent repo path, the docker-agent binary name and *.yaml/*.yml/*.hcl config filenames in code blocks, and CLI-reference anchor links (#docker-agent-setup, #docker-agent-doctor). --- docs/concepts/agents/index.md | 8 ++++---- docs/concepts/distribution/index.md | 6 +++--- docs/concepts/models/index.md | 12 ++++++------ docs/concepts/tools/index.md | 10 +++++----- docs/getting-started/installation/index.md | 22 +++++++++++----------- 5 files changed, 29 insertions(+), 29 deletions(-) diff --git a/docs/concepts/agents/index.md b/docs/concepts/agents/index.md index 4724133a26..092f7af510 100644 --- a/docs/concepts/agents/index.md +++ b/docs/concepts/agents/index.md @@ -1,16 +1,16 @@ --- title: "Agents" -description: "Agents are the core building blocks of docker-agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents." +description: "Agents are the core building blocks of Docker Agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents." keywords: docker agent, ai agents, concepts, agents weight: 10 canonical: https://docs.docker.com/ai/docker-agent/concepts/agents/ --- -_Agents are the core building blocks of docker-agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents._ +_Agents are the core building blocks of Docker Agent. Each agent is an AI-powered entity with a model, instructions, tools, and optional sub-agents._ ## What is an Agent? -An agent in docker-agent is defined by: +An agent in Docker Agent is defined by: - **Model** — The AI model powering it (e.g., Claude, GPT-5, Gemini). See [Models](../models/index.md). - **Description** — A brief summary of what the agent does (used by other agents for delegation) @@ -34,7 +34,7 @@ agents: ## The Root Agent -Every docker-agent configuration has a **root agent** — the entry point that receives user messages. In a single-agent setup, this is the only agent. In a multi-agent setup, the root agent acts as a coordinator, delegating tasks to specialized sub-agents. +Every Docker Agent configuration has a **root agent** — the entry point that receives user messages. In a single-agent setup, this is the only agent. In a multi-agent setup, the root agent acts as a coordinator, delegating tasks to specialized sub-agents. > [!NOTE] > **Naming** diff --git a/docs/concepts/distribution/index.md b/docs/concepts/distribution/index.md index 6f66766744..b865ced141 100644 --- a/docs/concepts/distribution/index.md +++ b/docs/concepts/distribution/index.md @@ -12,7 +12,7 @@ _Package, share, and run agents via OCI-compatible registries — just like cont ## Overview -docker-agent agents can be pushed to any OCI-compatible registry (Docker Hub, GitHub Container Registry, etc.) and pulled/run anywhere. This makes sharing agents as easy as sharing Docker images. +Docker Agent agents can be pushed to any OCI-compatible registry (Docker Hub, GitHub Container Registry, etc.) and pulled/run anywhere. This makes sharing agents as easy as sharing Docker images. > [!TIP] > For CLI commands related to distribution, see [CLI Reference](../../features/cli/index.md) (`docker agent share push`, `docker agent share pull`, `docker agent alias`). @@ -108,7 +108,7 @@ $ docker agent serve api docker.io/username/agent:latest --pull-interval 10 ## Private Repositories -docker-agent supports pulling from private GitHub repositories and registries that require authentication. Use standard Docker login or GitHub authentication: +Docker Agent supports pulling from private GitHub repositories and registries that require authentication. Use standard Docker login or GitHub authentication: ```bash # Login to a registry @@ -122,7 +122,7 @@ $ docker agent run docker.io/myorg/private-agent:latest > [!NOTE] > **Docker Desktop credentials** > -> When pulling or running an agent from a `docker.com` or `*.docker.com` HTTPS URL (e.g. `desktop.docker.com`), docker-agent automatically forwards your Docker Desktop JWT for authentication — no explicit login required when Docker Desktop is running and signed in. +> When pulling or running an agent from a `docker.com` or `*.docker.com` HTTPS URL (e.g. `desktop.docker.com`), Docker Agent automatically forwards your Docker Desktop JWT for authentication — no explicit login required when Docker Desktop is running and signed in. > > Note: `docker.io` (the standard Docker Hub registry domain) is a separate domain and is **not** covered by automatic JWT forwarding. Agents pulled from `docker.io` or `registry-1.docker.io` still require `docker login docker.io` for private repositories. diff --git a/docs/concepts/models/index.md b/docs/concepts/models/index.md index 0334618187..cdc8bfda5c 100644 --- a/docs/concepts/models/index.md +++ b/docs/concepts/models/index.md @@ -1,12 +1,12 @@ --- title: "Models" -description: "Models are the AI brains behind your agents. docker-agent supports multiple providers and flexible configuration." +description: "Models are the AI brains behind your agents. Docker Agent supports multiple providers and flexible configuration." keywords: docker agent, ai agents, concepts, models weight: 20 canonical: https://docs.docker.com/ai/docker-agent/concepts/models/ --- -_Models are the AI brains behind your agents. docker-agent supports multiple providers and flexible configuration._ +_Models are the AI brains behind your agents. Docker Agent supports multiple providers and flexible configuration._ ## Inline vs. Named Models @@ -63,7 +63,7 @@ agents: instruction: You are a helpful assistant. ``` -At load time, docker-agent selects the first candidate whose credentials are +At load time, Docker Agent selects the first candidate whose credentials are configured. You only need credentials for one candidate. See [Model Configuration](../../configuration/models/index.md#first-available-models) for details. @@ -129,11 +129,11 @@ Control how much the model "thinks" before responding: | Anthropic | int or str | 1024–32768 tokens, or `adaptive`, `adaptive/`, effort level | off | | Gemini 2.5 | int | 0 (off), -1 (dynamic), or token count | -1 (dynamic) | | Gemini 3 | string | `minimal`, `low`, `medium`, `high` | varies | -| All | string/int | `none` or `0` clears docker-agent's local config | — | +| All | string/int | `none` or `0` clears Docker Agent's local config | — | `none` and `0` are not universal API-level disable switches. On genuine OpenAI gpt-5.6+ endpoints (Sol/Terra/Luna), `none` is a real `reasoning_effort` value -that docker-agent sends as-is and the model does not reason. On older OpenAI +that Docker Agent sends as-is and the model does not reason. On older OpenAI models, `none`/`0` only clear the local `thinking_budget` — omitting the field has the same effect — and the model falls back to the API's own default effort (still reasoning internally for always-reasoning models like the o-series). @@ -162,7 +162,7 @@ models: ## Alloy Models -"Alloy models" let you use more than one model in the same conversation — docker-agent alternates between them to leverage the strengths of each: +"Alloy models" let you use more than one model in the same conversation — Docker Agent alternates between them to leverage the strengths of each: ```yaml agents: diff --git a/docs/concepts/tools/index.md b/docs/concepts/tools/index.md index 5ebce14cae..03676e0a93 100644 --- a/docs/concepts/tools/index.md +++ b/docs/concepts/tools/index.md @@ -10,21 +10,21 @@ _Tools give agents the ability to interact with the world — read files, run co ## How Tools Work -When an agent needs to perform an action, it makes a **tool call**. The docker-agent runtime executes the tool and returns the result to the agent, which can then use it to continue its work. +When an agent needs to perform an action, it makes a **tool call**. The Docker Agent runtime executes the tool and returns the result to the agent, which can then use it to continue its work. 1. Agent receives a user message 2. Agent decides it needs to use a tool (e.g., read a file) -3. docker-agent executes the tool and returns the result +3. Docker Agent executes the tool and returns the result 4. Agent incorporates the result and responds > [!NOTE] > **Tool Confirmation** > -> By default, docker-agent asks for user confirmation before executing tools that have side effects (shell commands, file writes). Use `--yolo` to auto-approve all tool calls. +> By default, Docker Agent asks for user confirmation before executing tools that have side effects (shell commands, file writes). Use `--yolo` to auto-approve all tool calls. ## Built-in Tools -docker-agent ships with several built-in tools that require no external dependencies. Each is enabled by adding its `type` to the agent's `toolsets` list: +Docker Agent ships with several built-in tools that require no external dependencies. Each is enabled by adding its `type` to the agent's `toolsets` list: | Tool | Description | | --- | --- | @@ -52,7 +52,7 @@ docker-agent ships with several built-in tools that require no external dependen ## MCP Tools -docker-agent supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) for extending agents with external tools. There are three ways to connect MCP tools: +Docker Agent supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) for extending agents with external tools. There are three ways to connect MCP tools: - **Docker MCP** (recommended) — Run MCP servers in Docker containers via the [MCP Gateway](https://github.com/docker/mcp-gateway). Browse the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp). - **Local MCP (stdio)** — Run MCP servers as local processes communicating over stdin/stdout. diff --git a/docs/getting-started/installation/index.md b/docs/getting-started/installation/index.md index 75b0ebbe85..d231ce9117 100644 --- a/docs/getting-started/installation/index.md +++ b/docs/getting-started/installation/index.md @@ -1,12 +1,12 @@ --- title: "Installation" -description: "Get docker-agent running on your system in minutes." +description: "Get Docker Agent running on your system in minutes." keywords: docker agent, ai agents, getting started, installation weight: 20 canonical: https://docs.docker.com/ai/docker-agent/getting-started/installation/ --- -_Get docker-agent running on your system in minutes._ +_Get Docker Agent running on your system in minutes._ ## Prerequisites @@ -15,18 +15,18 @@ _Get docker-agent running on your system in minutes._ ## Docker Desktop (Pre-installed) -Starting with [Docker Desktop 4.63](https://docs.docker.com/desktop/release-notes/#4630), **docker-agent is already available**. No separate installation needed — just open a terminal and run: +Starting with [Docker Desktop 4.63](https://docs.docker.com/desktop/release-notes/#4630), **Docker Agent is already available**. No separate installation needed — just open a terminal and run: ```bash $ docker agent version ``` > [!TIP] -> Docker Desktop bundles docker-agent and keeps it up to date. This is the easiest way to get started, especially if you want to use Docker MCP tools and Docker Model Runner. +> Docker Desktop bundles Docker Agent and keeps it up to date. This is the easiest way to get started, especially if you want to use Docker MCP tools and Docker Model Runner. ## Homebrew (macOS / Linux) -Install docker-agent using [Homebrew](https://brew.sh/): +Install Docker Agent using [Homebrew](https://brew.sh/): ```bash # Install @@ -36,7 +36,7 @@ $ brew install docker-agent $ docker-agent version ``` -You can also install docker-agent as a docker CLI plugin, by copying `docker-agent` binary in `~/.docker/cli-plugins`. You can then run `docker agent version`. +You can also install Docker Agent as a docker CLI plugin, by copying the `docker-agent` binary in `~/.docker/cli-plugins`. You can then run `docker agent version`. ## Download Binary Releases @@ -65,7 +65,7 @@ Download `docker-agent-windows-amd64.exe` from the [releases page](https://githu ## Optional Self-Updates -When docker-agent is installed from a standalone GitHub release binary, you can opt in to automatic self-updates by setting `DOCKER_AGENT_AUTO_UPDATE` to a truthy value (`1`, `true`, `yes`, or `on`): +When Docker Agent is installed from a standalone GitHub release binary, you can opt in to automatic self-updates by setting `DOCKER_AGENT_AUTO_UPDATE` to a truthy value (`1`, `true`, `yes`, or `on`): ```bash # Enable for one command @@ -76,14 +76,14 @@ export DOCKER_AGENT_AUTO_UPDATE=1 docker agent run ``` -With self-updates enabled, docker-agent checks the latest GitHub release before normal commands run. If a newer release exists and your session is interactive, docker-agent asks whether you want to install it or keep running your current version. When the answer is yes (or the session is non-interactive, such as CI or piped input, in which case the update proceeds automatically), it downloads the asset for your OS and architecture, verifies the release-provided SHA-256 digest/checksum, replaces the current binary, and restarts the command with the same arguments. +With self-updates enabled, Docker Agent checks the latest GitHub release before normal commands run. If a newer release exists and your session is interactive, Docker Agent asks whether you want to install it or keep running your current version. When the answer is yes (or the session is non-interactive, such as CI or piped input, in which case the update proceeds automatically), it downloads the asset for your OS and architecture, verifies the release-provided SHA-256 digest/checksum, replaces the current binary, and restarts the command with the same arguments. -Self-updates are fail-safe: if checking, downloading, verifying, installing, or restarting fails, docker-agent keeps running the current binary. Version/help/completion commands and Docker CLI plugin metadata handshakes do not trigger self-updates. +Self-updates are fail-safe: if checking, downloading, verifying, installing, or restarting fails, Docker Agent keeps running the current binary. Version/help/completion commands and Docker CLI plugin metadata handshakes do not trigger self-updates. > [!NOTE] > **Package-manager installs** > -> Docker Desktop and Homebrew already manage docker-agent updates. Prefer those update mechanisms when you installed docker-agent that way. Self-updates are mainly intended for standalone release binaries. +> Docker Desktop and Homebrew already manage Docker Agent updates. Prefer those update mechanisms when you installed Docker Agent that way. Self-updates are mainly intended for standalone release binaries. ## Build from Source @@ -114,7 +114,7 @@ task build ## Set Up API Keys -docker-agent needs API keys for the model providers you want to use. Set them as environment variables: +Docker Agent needs API keys for the model providers you want to use. Set them as environment variables: ```bash # Pick one (or more) depending on your provider From 1b3239b3f53a3a1fd687a1c8aca73a28e9781d6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:18:04 +0200 Subject: [PATCH 04/10] =?UTF-8?q?docs(style):=20naming=20sweep=20=E2=80=94?= =?UTF-8?q?=20configuration?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace prose/front-matter uses of 'docker-agent' with 'Docker Agent' in docs/configuration/{hcl,hooks,models,overview,routing,sandbox,tools}. Preserved unchanged: canonical/alias URLs, docker/docker-agent repo and examples/ links, the docker-agent binary and sandbox template/image identifiers (docker/sandbox-templates:docker-agent, docker/docker-agent-sbx-templates[...], the com.docker.sandboxes.flavor label), config filenames, and CLI anchor links (#docker-agent-alias). --- docs/configuration/hcl/index.md | 12 ++++++------ docs/configuration/hooks/index.md | 10 +++++----- docs/configuration/models/index.md | 22 +++++++++++----------- docs/configuration/overview/index.md | 16 ++++++++-------- docs/configuration/routing/index.md | 2 +- docs/configuration/sandbox/index.md | 14 +++++++------- docs/configuration/tools/index.md | 6 +++--- 7 files changed, 41 insertions(+), 41 deletions(-) diff --git a/docs/configuration/hcl/index.md b/docs/configuration/hcl/index.md index a0de8dca6b..7a465e47a1 100644 --- a/docs/configuration/hcl/index.md +++ b/docs/configuration/hcl/index.md @@ -1,19 +1,19 @@ --- title: "HCL Configuration" -description: "Write docker-agent configs in HCL instead of YAML, using labeled blocks, heredocs, and the same underlying schema." +description: "Write Docker Agent configs in HCL instead of YAML, using labeled blocks, heredocs, and the same underlying schema." keywords: docker agent, ai agents, configuration, yaml, hcl configuration weight: 20 canonical: https://docs.docker.com/ai/docker-agent/configuration/hcl/ --- -_Write docker-agent configs in HCL instead of YAML. It maps to the same docker-agent schema and validation rules._ +_Write Docker Agent configs in HCL instead of YAML. It maps to the same Docker Agent schema and validation rules._ `docker-agent` supports `.hcl` config files anywhere it supports `.yaml` or `.yml` files. HCL is useful if you prefer labeled blocks, less punctuation, and heredocs for long prompts. > [!TIP] > **Same config model, different syntax** > -> YAML and HCL are just two syntaxes for the same docker-agent configuration model. docker-agent converts HCL to the equivalent YAML structure internally, then runs the normal schema validation and loading pipeline. +> YAML and HCL are just two syntaxes for the same Docker Agent configuration model. Docker Agent converts HCL to the equivalent YAML structure internally, then runs the normal schema validation and loading pipeline. ## Minimal Example @@ -181,7 +181,7 @@ agent "root" { HCL treats `${...}` inside strings and heredocs as template interpolation. If you need the literal text `${...}` in your prompt, escape it as `$${...}`. -This matters for command prompts that intentionally show docker-agent template snippets: +This matters for command prompts that intentionally show Docker Agent template snippets: ```hcl command "fix-lint" { @@ -288,14 +288,14 @@ The same idea applies to other list-shaped sections such as RAG `strategy` block ## Important Differences from Terraform -docker-agent uses HCL as a configuration syntax, not as Terraform: +Docker Agent uses HCL as a configuration syntax, not as Terraform: - There are no modules, `locals`, or `variable` blocks. - The only function available in expressions is [`file()`](#loading-files-with-file); Terraform's function library (including `templatefile()`, which `file()` with a vars object replaces) is not available. - Prefer normal literal values: strings, numbers, booleans, lists, objects, and nested blocks. - After conversion, the result is validated exactly like the equivalent YAML config. -If you already know Terraform, think of docker-agent HCL as a thin block-based syntax over the existing config schema. +If you already know Terraform, think of Docker Agent HCL as a thin block-based syntax over the existing config schema. ## Examples diff --git a/docs/configuration/hooks/index.md b/docs/configuration/hooks/index.md index cc652e01c8..f88b03f65e 100644 --- a/docs/configuration/hooks/index.md +++ b/docs/configuration/hooks/index.md @@ -29,7 +29,7 @@ Hooks allow you to execute shell commands or scripts at key points in an agent's ## Hook Types -docker-agent dispatches the following hook events: +Docker Agent dispatches the following hook events: | Event | When it fires | Can block? | | --------------------------- | --------------------------------------------------------------------------------- | ---------- | @@ -158,7 +158,7 @@ Global hooks cannot be suppressed by an individual agent. Use them for user-wide ### Hook drop-in files (`hooks.d`) -External tools that integrate with docker-agent (terminal emulators, IDEs, audit or observability sidecars) shouldn't have to rewrite your `config.yaml` to install a hook. Instead, docker-agent also loads every `*.yaml` / `*.yml` file from the `hooks.d` directory next to your user config (default: `~/.config/cagent/hooks.d/`). Each file is a standalone hooks block with the same schema as the content of `settings.hooks`: +External tools that integrate with Docker Agent (terminal emulators, IDEs, audit or observability sidecars) shouldn't have to rewrite your `config.yaml` to install a hook. Instead, Docker Agent also loads every `*.yaml` / `*.yml` file from the `hooks.d` directory next to your user config (default: `~/.config/cagent/hooks.d/`). Each file is a standalone hooks block with the same schema as the content of `settings.hooks`: ```yaml # ~/.config/cagent/hooks.d/50-mytool.yaml @@ -178,7 +178,7 @@ The config directory can be relocated with the `--config-dir` flag or the `DOCKE ## Built-in Hooks -In addition to shell `command` hooks, docker-agent ships a small library of **built-in hooks** — in-process Go functions that run without spawning a subprocess. They're invoked with `type: builtin`, where `command` is the builtin's registered name and `args` are passed through as the builtin's parameters. +In addition to shell `command` hooks, Docker Agent ships a small library of **built-in hooks** — in-process Go functions that run without spawning a subprocess. They're invoked with `type: builtin`, where `command` is the builtin's registered name and `args` are passed through as the builtin's parameters. ```yaml hooks: @@ -214,7 +214,7 @@ Built-ins are typically zero-config and faster than equivalent shell hooks becau | `add_user_info` | `session_start` | _none_ | Adds the current OS user (username and full name) and the hostname. | | `add_recent_commits` | `session_start` | _none_, or `[""]` | Adds `git log --oneline -n N`. `N` defaults to 10; pass a positive integer to override. | | `max_iterations` | `before_llm_call` | `[""]` (required) | Hard-stops the agent after `N` model calls. Stateless: the runtime supplies the iteration counter on every dispatch. | -| `snapshot` | `session_start`, `turn_start`, `turn_end`, `pre_tool_use`, `post_tool_use`, `session_end` | _none_ | Records filesystem snapshots in a shadow git repo under the docker-agent data directory. No-op outside git repos; respects the source repo's ignore rules and skips newly-added files larger than 2 MiB. | +| `snapshot` | `session_start`, `turn_start`, `turn_end`, `pre_tool_use`, `post_tool_use`, `session_end` | _none_ | Records filesystem snapshots in a shadow git repo under the Docker Agent data directory. No-op outside git repos; respects the source repo's ignore rules and skips newly-added files larger than 2 MiB. | | `redact_secrets` | `pre_tool_use`, `before_llm_call`, `tool_response_transform` | _none_ | Scrubs detected secrets (API keys, tokens, private keys, …) out of tool call arguments, outgoing chat content, and tool output. The same builtin handles all three events and dispatches on the event name. Auto-registered on all three events by `redact_secrets: true` on the agent — see [`examples/redact_secrets_hooks.yaml`](https://github.com/docker/docker-agent/blob/main/examples/redact_secrets_hooks.yaml) for the manual wiring. | | `limit_large_tool_results` | `tool_response_transform`, `session_end` | _none_ | **Always-on safety hook** — automatically injected by the runtime, no configuration required. When a tool result from the `filesystem`, `shell`, `mcp`, or `a2a` categories exceeds 2,000 lines or 50 KiB, the full payload is written to a per-session temp file and replaced in the conversation with a notice plus a bounded tail (last 2,000 lines, up to 50 KiB). The `session_end` leg deletes the temp directory. Internal toolsets (`memory`, `plan`, `tasks`, `think`, …) are not affected. | | `safer_shell` | `pre_tool_use` (with `preempt_yolo: true`) | `[""]` (optional pin) | Classifies shell commands against an embedded taxonomy. Verdict adapts to the session's `SafetyPolicy`. `unsafe`: silent. `safer`: destructive matches Ask with `blast_radius`/`category` metadata; safe and unknown flow through silently. `safe-auto`: safe matches auto-Allow with `blast_radius=safe`; destructive and unknown Ask. `strict` (default): safe, destructive, and unknown all Ask with `blast_radius` metadata (safe/low/medium/high/unknown). Filters by tool name internally (no-op for non-shell calls). Auto-registered by `safer: true` on a shell toolset — see [`examples/shell_safer.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shell_safer.yaml). | @@ -719,7 +719,7 @@ At every transfer the runtime ships a snapshot of the previous agent's model end `worktree_create` fires once, just after `docker agent run --worktree[=name]` creates a fresh [git worktree](../../features/cli/index.md) and **before** the session starts. Each hook runs **inside** the new worktree — its working directory (and `cwd` in the input) is the fresh checkout — so setup commands operate on the new tree rather than your original one. The worktree path and branch are in `worktree_path` and `worktree_branch`, and `worktree_source_dir` carries the repository root it was branched from. -Use it to prepare the checkout before the agent begins: copy untracked files git won't carry over (`.env`, local config), install dependencies, or warm caches. Because the worktree lives under the docker-agent data directory — not next to your checkout — resolve the original files through `worktree_source_dir` rather than a relative path. A hook may **abort the run** by returning `decision: block` / `{"continue": false}` / exit code 2 (for example, when a setup step fails); plain stdout is surfaced as additional context. +Use it to prepare the checkout before the agent begins: copy untracked files git won't carry over (`.env`, local config), install dependencies, or warm caches. Because the worktree lives under the Docker Agent data directory — not next to your checkout — resolve the original files through `worktree_source_dir` rather than a relative path. A hook may **abort the run** by returning `decision: block` / `{"continue": false}` / exit code 2 (for example, when a setup step fails); plain stdout is surfaced as additional context. ```yaml hooks: diff --git a/docs/configuration/models/index.md b/docs/configuration/models/index.md index afcc82e9c5..068bf3260b 100644 --- a/docs/configuration/models/index.md +++ b/docs/configuration/models/index.md @@ -80,9 +80,9 @@ models: ## Attachment Capability Overrides For custom OpenAI-compatible providers, local models (Ollama, DMR), and any -model the built-in catalogue does not describe, docker-agent cannot +model the built-in catalogue does not describe, Docker Agent cannot auto-detect whether the endpoint accepts image or PDF attachments. When the -model is absent from the catalogue, docker-agent logs a diagnostic and falls +model is absent from the catalogue, Docker Agent logs a diagnostic and falls back to text-only, silently dropping attachments. Declare `capabilities` to make the model's attachment support authoritative @@ -119,7 +119,7 @@ See [`examples/capability-overrides.yaml`](https://github.com/docker/docker-agen ## Custom Token Pricing -docker-agent prices each model call from the [models.dev](https://models.dev/) +Docker Agent prices each model call from the [models.dev](https://models.dev/) catalogue. Models the catalogue does not know — custom OpenAI-compatible providers, local models, private deployments — are "unpriced": every call is recorded at $0 despite consuming tokens, with only a log warning. @@ -208,7 +208,7 @@ The value can be a named entry from the `models` stanza or an inline `provider/model` string. When omitted, the primary model compacts. If the compaction model has a **smaller context window** than the primary, -docker-agent triggers compaction against the smaller window so the summary +Docker Agent triggers compaction against the smaller window so the summary call can always ingest the full conversation. Pair the primary with a compaction model whose window is at least as large to keep the proactive trigger aligned with the primary's window. @@ -281,7 +281,7 @@ See [`examples/bypass_models_gateway.yaml`](https://github.com/docker/docker-age ## First Available Models -Use `first_available` when the same agent should work with whichever provider credentials are available in the current environment. docker-agent checks the candidates in order at load time and replaces the selector with the first candidate whose required environment variables are configured. +Use `first_available` when the same agent should work with whichever provider credentials are available in the current environment. Docker Agent checks the candidates in order at load time and replaces the selector with the first candidate whose required environment variables are configured. ```yaml models: @@ -300,7 +300,7 @@ agents: Candidates can be inline `provider/model` references or names from the same `models:` section. Local providers such as `dmr` and `ollama` do not require credentials, so they are useful as final fallbacks. -If none of the candidates has credentials configured, docker-agent reports the missing environment variables grouped by candidate. You only need to configure one group of credentials, not every provider in the list. +If none of the candidates has credentials configured, Docker Agent reports the missing environment variables grouped by candidate. You only need to configure one group of credentials, not every provider in the list. A `first_available` model is only a selector. It cannot be combined with `provider`, `model`, `routing`, `token_key`, budgets, sampling options, or other model settings. Put those settings on named candidate models instead: @@ -388,9 +388,9 @@ models: thinking_budget: none # or 0 ``` -`none` and `0` both clear docker-agent's local thinking configuration (omitting `thinking_budget` has the same effect); neither is guaranteed to reach the API as a real "off" switch: +`none` and `0` both clear Docker Agent's local thinking configuration (omitting `thinking_budget` has the same effect); neither is guaranteed to reach the API as a real "off" switch: -- **OpenAI gpt-5.6+** (Sol/Terra/Luna) is the only case with a genuine API-level `none` reasoning effort: docker-agent sends it as-is and the model does not reason. +- **OpenAI gpt-5.6+** (Sol/Terra/Luna) is the only case with a genuine API-level `none` reasoning effort: Docker Agent sends it as-is and the model does not reason. - **Older OpenAI reasoning models** (o-series, gpt-5 through gpt-5.5) have no such switch: `none`/`0` just clear the local config, and the model falls back to the API's own default effort and still reasons internally. Same for other always-reasoning models (Gemini 3). - Providers with a true optional-thinking switch (Gemini 2.5, Claude, local models) are fully disabled by `none`/`0`. @@ -415,10 +415,10 @@ choose a tight per-call `max_tokens`. It is forwarded to Anthropic's [`output_config.task_budget`](https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7) -request field. docker-agent automatically attaches the required +request field. Docker Agent automatically attaches the required `task-budgets-2026-03-13` beta header whenever this field is set. -You can configure `task_budget` on **any** Claude model — docker-agent never +You can configure `task_budget` on **any** Claude model — Docker Agent never gates it by model name. At the time of writing only **Claude Opus 4.7** actually honors the field; other Claude models will reject requests that include it. Check the Anthropic release notes linked above for the current @@ -475,7 +475,7 @@ models: ## Thinking Display (Anthropic) -For Anthropic Claude models, `thinking_display` controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); docker-agent requests `summarized` thinking by default for adaptive/effort-based budgets so reasoning stays visible. Set this provider option to override: +For Anthropic Claude models, `thinking_display` controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); Docker Agent requests `summarized` thinking by default for adaptive/effort-based budgets so reasoning stays visible. Set this provider option to override: ```yaml models: diff --git a/docs/configuration/overview/index.md b/docs/configuration/overview/index.md index 7380c080c4..a0a8b2dbc3 100644 --- a/docs/configuration/overview/index.md +++ b/docs/configuration/overview/index.md @@ -1,6 +1,6 @@ --- title: "Configuration Overview" -description: "docker-agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships." +description: "Docker Agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships." keywords: docker agent, ai agents, configuration, yaml, configuration overview linkTitle: "Overview" weight: 10 @@ -9,13 +9,13 @@ aliases: - /ai/docker-agent/reference/config/ --- -_docker-agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships._ +_Docker Agent uses YAML or HCL configuration files to define agents, models, tools, and their relationships._ ## File Structure -A docker-agent config can be written in YAML or HCL. The examples on this page use YAML; see [HCL Configuration](../hcl/index.md) for the block-based HCL syntax. +A Docker Agent config can be written in YAML or HCL. The examples on this page use YAML; see [HCL Configuration](../hcl/index.md) for the block-based HCL syntax. -A docker-agent config has these main sections: +A Docker Agent config has these main sections: ```bash # 1. Version — configuration schema version (optional but recommended) @@ -172,7 +172,7 @@ API keys and secrets are read from environment variables — never stored in con ## Variable Expansion in Config Fields -docker-agent expands `${env.VAR}` references in many config fields. This is the **canonical syntax everywhere** — prefer it for every field. Two engines back it: a full JavaScript evaluator for prompt/HTTP fields (where you also get defaults, ternaries, and tool calls), and a simpler path expander for filesystem/env fields (which additionally accepts the legacy `$VAR` / `${VAR}` / `~` shell forms). Picking `${env.VAR}` everywhere always works; the one caveat is that the path expander does not evaluate richer JS expressions. Using a shell-style `$VAR` in a JS-templated field is currently a silent no-op, so the literal string is passed through. Tracking issue: [#2615](https://github.com/docker/docker-agent/issues/2615). +Docker Agent expands `${env.VAR}` references in many config fields. This is the **canonical syntax everywhere** — prefer it for every field. Two engines back it: a full JavaScript evaluator for prompt/HTTP fields (where you also get defaults, ternaries, and tool calls), and a simpler path expander for filesystem/env fields (which additionally accepts the legacy `$VAR` / `${VAR}` / `~` shell forms). Picking `${env.VAR}` everywhere always works; the one caveat is that the path expander does not evaluate richer JS expressions. Using a shell-style `$VAR` in a JS-templated field is currently a silent no-op, so the literal string is passed through. Tracking issue: [#2615](https://github.com/docker/docker-agent/issues/2615). ### JavaScript template literals — `${env.VAR}` @@ -276,7 +276,7 @@ Prefer `${env.X}` everywhere. The bare `$X` / `${X}` and `~` forms are accepted ## Validation -docker-agent validates your configuration at startup: +Docker Agent validates your configuration at startup: - Local `sub_agents` must reference agents defined in the config (external OCI references like `agentcatalog/pirate` are pulled from registries automatically; pin them to a digest with `@sha256:…` to avoid a per-run registry lookup) - Named model references must exist in the `models` section @@ -294,7 +294,7 @@ For YAML editor autocompletion and validation, use the [Docker Agent JSON Schema ## Config Versioning -docker-agent configs are versioned. The current version is `12`. Add the version at the top of your config: +Docker Agent configs are versioned. The current version is `12`. Add the version at the top of your config: ```yaml version: 12 @@ -305,7 +305,7 @@ agents: # ... ``` -When you load an older config, docker-agent automatically migrates it to the latest schema. It's recommended to include the version to ensure consistent behavior. +When you load an older config, Docker Agent automatically migrates it to the latest schema. It's recommended to include the version to ensure consistent behavior. If you use a config key that requires a newer schema version, Docker Agent will fail with a strict-parse error and include a hint like: diff --git a/docs/configuration/routing/index.md b/docs/configuration/routing/index.md index 6cc224b167..54c187bbf6 100644 --- a/docs/configuration/routing/index.md +++ b/docs/configuration/routing/index.md @@ -15,7 +15,7 @@ Model routing lets you define a "router" model that automatically selects the be > [!NOTE] > **How It Works** > -> docker-agent uses NLP-based text similarity (via Bleve full-text search) to match user messages against example phrases you define. The route with the best-matching examples wins, and that model handles the request. +> Docker Agent uses NLP-based text similarity (via Bleve full-text search) to match user messages against example phrases you define. The route with the best-matching examples wins, and that model handles the request. ## Configuration diff --git a/docs/configuration/sandbox/index.md b/docs/configuration/sandbox/index.md index a7c9c2ed70..62209fee55 100644 --- a/docs/configuration/sandbox/index.md +++ b/docs/configuration/sandbox/index.md @@ -17,7 +17,7 @@ The backend is provided by the [`docker sandbox`](https://docs.docker.com/ai/san > [!NOTE] > **Requirements** > -> Sandbox mode requires Docker Desktop with sandbox support (or a working `sbx` CLI). docker-agent shells out to these tools, it does not start raw `docker run` containers. +> Sandbox mode requires Docker Desktop with sandbox support (or a working `sbx` CLI). Docker Agent shells out to these tools, it does not start raw `docker run` containers. ## Usage @@ -27,7 +27,7 @@ Enable sandbox mode with the `--sandbox` flag on the `docker agent run` command: docker agent run --sandbox agent.yaml ``` -docker-agent launches a sandbox VM, copies itself into it, mounts the current working directory, and re-runs the agent from inside. +Docker Agent launches a sandbox VM, copies itself into it, mounts the current working directory, and re-runs the agent from inside. ## Flags @@ -230,13 +230,13 @@ docker agent run --sandbox agent.yaml ## How It Works -1. `--sandbox` tells docker-agent to prefer the `sbx` CLI (if available and `--sbx` is true), otherwise it falls back to `docker sandbox`. +1. `--sandbox` tells Docker Agent to prefer the `sbx` CLI (if available and `--sbx` is true), otherwise it falls back to `docker sandbox`. 2. A new sandbox VM is created from the image passed via `--template`. 3. The current working directory is mounted into the VM; the agent binary is copied in. 4. The [auto-kit](#auto-kit) is staged on the host and bind-mounted read-only into the VM, so the agent sees its skills and prompt files inside the sandbox. 5. The default-deny network proxy is opened for the configured [models gateway](../../features/cli/index.md#runtime-configuration-flags) and any package hosts the auto-installer needs for the agent's MCP/LSP toolsets. 6. All tools (shell, filesystem, background jobs, etc.) run inside the VM. -7. When the session ends, docker-agent exits but does not stop or remove the sandbox VM; both the VM and the kit are kept around so subsequent runs from the same workspace can reuse them. A fresh sandbox is created only when the mount set has changed. +7. When the session ends, Docker Agent exits but does not stop or remove the sandbox VM; both the VM and the kit are kept around so subsequent runs from the same workspace can reuse them. A fresh sandbox is created only when the mount set has changed. ### What the default template includes @@ -253,7 +253,7 @@ repository's own build — including the `docker-mcp` CLI plugin — see ## Auto-Kit -The sandbox VM has its own filesystem and `$HOME` — none of the host's `~/.agents/skills/`, `~/.claude/skills/`, project-level `.agents/skills/`, or prompt files like `AGENTS.md` and `CLAUDE.md` are visible inside it. To bridge that gap, docker-agent automatically builds a **kit**: a self-contained directory staged on the host before the sandbox starts and bind-mounted read-only into the VM at the same path. +The sandbox VM has its own filesystem and `$HOME` — none of the host's `~/.agents/skills/`, `~/.claude/skills/`, project-level `.agents/skills/`, or prompt files like `AGENTS.md` and `CLAUDE.md` are visible inside it. To bridge that gap, Docker Agent automatically builds a **kit**: a self-contained directory staged on the host before the sandbox starts and bind-mounted read-only into the VM at the same path. The kit is built whenever `--sandbox` is used with an agent reference. It is opt-out via `--no-kit`. @@ -265,7 +265,7 @@ For the agent referenced on the command line, the kit collects: - **Prompt files** — every file referenced via the agent's `add_prompt_files` (`AGENTS.md`, `CLAUDE.md`, …) is collected. Files that already live under the working directory are left alone (the live workspace mount surfaces them); files outside it (e.g. an `AGENTS.md` in `$HOME`) are copied under `/prompt_files/`. - **A manifest** — `/manifest.json` records what was staged. The on-disk copy is sanitised so it cannot be used to map the host filesystem from inside the sandbox. -Before launch, docker-agent prints a summary of what was staged so you can see exactly which skills and prompt files the agent will have access to inside the sandbox. +Before launch, Docker Agent prints a summary of what was staged so you can see exactly which skills and prompt files the agent will have access to inside the sandbox. ### Secret redaction @@ -277,7 +277,7 @@ The sandbox templates ship with a default-deny network proxy that allows the maj ### Caching -Kits are stored under the docker-agent cache directory (`~/Library/Caches/cagent/sandbox-kits/` on macOS) keyed by a content hash of the agent reference. Reusing the same agent across runs reuses the same kit directory in place; disk usage is bounded by the number of distinct agents you have run. Kits are deliberately kept on disk between runs because the reused sandbox VM holds a hard reference to the kit's bind-mount path — deleting it would leave the sandbox un-startable. +Kits are stored under the Docker Agent cache directory (`~/Library/Caches/cagent/sandbox-kits/` on macOS) keyed by a content hash of the agent reference. Reusing the same agent across runs reuses the same kit directory in place; disk usage is bounded by the number of distinct agents you have run. Kits are deliberately kept on disk between runs because the reused sandbox VM holds a hard reference to the kit's bind-mount path — deleting it would leave the sandbox un-startable. ### Disabling the kit diff --git a/docs/configuration/tools/index.md b/docs/configuration/tools/index.md index e9ada86ab2..7258b1b9cb 100644 --- a/docs/configuration/tools/index.md +++ b/docs/configuration/tools/index.md @@ -13,7 +13,7 @@ _Complete reference for configuring built-in tools, MCP tools, and Docker-based ## Built-in Tools -Built-in tools are included with docker-agent and require no external dependencies. Add them to your agent's `toolsets` list by `type`. Each tool's dedicated page covers its full configuration options, available operations, and examples. +Built-in tools are included with Docker Agent and require no external dependencies. Add them to your agent's `toolsets` list by `type`. Each tool's dedicated page covers its full configuration options, available operations, and examples. | Type | Description | Page | | --- | --- | --- | @@ -133,7 +133,7 @@ toolsets: | ----------------------- | ------- | --------------------------------------------------------------------------------------------------------------------- | | `remote.url` | string | URL of the MCP server. Accepts `https://`, `http://`, and `unix://` (Unix domain socket) schemes. | | `remote.transport_type` | string | `streamable` or `sse` | -| `remote.headers` | object | HTTP headers sent on every request. Values support `${env.VAR}` and `${headers.NAME}` placeholders, resolved per request. `${env.VAR}` reads an environment variable; `${headers.NAME}` forwards a header from the caller's incoming request (useful when docker-agent runs as an API server). | +| `remote.headers` | object | HTTP headers sent on every request. Values support `${env.VAR}` and `${headers.NAME}` placeholders, resolved per request. `${env.VAR}` reads an environment variable; `${headers.NAME}` forwards a header from the caller's incoming request (useful when Docker Agent runs as an API server). | | `allow_private_ips` | boolean | Permit remote MCP OAuth helper requests to dial non-public IP addresses. Use only for trusted internal servers. | ## Auto-Installing Tools @@ -225,7 +225,7 @@ The simplest knob is `profile`, which picks a preset: | Profile | Auto-restart | Use case | | --- | --- | --- | -| `resilient` | Yes | Default. Exponential backoff on disconnect; the agent keeps running if the toolset is unavailable. Matches the historical docker-agent behaviour. | +| `resilient` | Yes | Default. Exponential backoff on disconnect; the agent keeps running if the toolset is unavailable. Matches the historical Docker Agent behaviour. | | `strict` | No | Fail-fast. Marks the toolset as required. Intended for CI / headless runs where a missing dependency should be a hard error. | | `best-effort` | No | Single attempt, no retries. Good for experimental MCPs whose flakiness should not amplify into a restart loop. | From d87d6a339a3d749c3d887f031dd30cff5cf4e8aa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:22:43 +0200 Subject: [PATCH 05/10] =?UTF-8?q?docs(style):=20naming=20sweep=20=E2=80=94?= =?UTF-8?q?=20features?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace prose/front-matter uses of 'docker-agent' with 'Docker Agent' across docs/features/{a2a,acp,api-server,chat-server,cli,evaluation, mcp-mode,remote-mcp,skills,snapshots,tui}. Also fixes one stale command typo in remote-mcp (`docker-agent serve api` -> `docker agent serve api`, matching the correct form used elsewhere on the same page). Preserved unchanged: canonical/alias URLs, docker/docker-agent repo and examples/ links, the docker-agent binary name, sandbox template image refs, the literal MCP elicitation meta keys (docker-agent/type, docker-agent/server_url, docker-agent/authorize_url, docker-agent/state), a literal API JSON response value ("owned_by":"docker-agent"), config filenames, and CLI anchor links (#docker-agent-serve-chat). --- docs/features/a2a/index.md | 6 +++--- docs/features/acp/index.md | 14 +++++++------- docs/features/api-server/index.md | 4 ++-- docs/features/chat-server/index.md | 12 ++++++------ docs/features/cli/index.md | 8 ++++---- docs/features/evaluation/index.md | 10 +++++----- docs/features/mcp-mode/index.md | 4 ++-- docs/features/remote-mcp/index.md | 28 ++++++++++++++-------------- docs/features/skills/index.md | 4 ++-- docs/features/snapshots/index.md | 6 +++--- docs/features/tui/index.md | 16 ++++++++-------- 11 files changed, 56 insertions(+), 56 deletions(-) diff --git a/docs/features/a2a/index.md b/docs/features/a2a/index.md index d381db7849..5cd5ac3358 100644 --- a/docs/features/a2a/index.md +++ b/docs/features/a2a/index.md @@ -1,6 +1,6 @@ --- title: "A2A Protocol" -description: "Expose docker-agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks." +description: "Expose Docker Agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks." keywords: docker agent, ai agents, features, a2a protocol weight: 60 canonical: https://docs.docker.com/ai/docker-agent/features/a2a/ @@ -8,7 +8,7 @@ aliases: - /ai/docker-agent/integrations/a2a/ --- -_Expose docker-agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks._ +_Expose Docker Agent agents via Google's Agent-to-Agent (A2A) protocol for interoperability with other agent frameworks._ ## Overview @@ -54,7 +54,7 @@ $ docker agent serve a2a agentcatalog/pirate - **Auto port selection** — Picks an available port if not specified - **Agent card** — Provides standard A2A agent metadata -- **Full docker-agent features** — Supports all tools, models, and gateway features +- **Full Docker Agent features** — Supports all tools, models, and gateway features - **Multiple sources** — Load agents from files or the agent catalog > [!TIP] diff --git a/docs/features/acp/index.md b/docs/features/acp/index.md index ac04d04b25..82f81086db 100644 --- a/docs/features/acp/index.md +++ b/docs/features/acp/index.md @@ -1,6 +1,6 @@ --- title: "ACP (Agent Client Protocol)" -description: "Expose docker-agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools." +description: "Expose Docker Agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools." keywords: docker agent, ai agents, features, acp (agent client protocol) linkTitle: "ACP" weight: 70 @@ -9,11 +9,11 @@ aliases: - /ai/docker-agent/integrations/acp/ --- -_Expose docker-agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools._ +_Expose Docker Agent agents via the Agent Client Protocol for integration with ACP-compatible hosts like VS Code, IDEs, and other developer tools._ ## Overview -The `docker agent serve acp` command starts an ACP server that communicates over **stdio** (standard input/output). This makes it ideal for integration with editors, IDEs, and other tools that spawn agent processes — the host sends JSON-RPC messages to docker-agent's stdin and reads responses from stdout. +The `docker agent serve acp` command starts an ACP server that communicates over **stdio** (standard input/output). This makes it ideal for integration with editors, IDEs, and other tools that spawn agent processes — the host sends JSON-RPC messages to Docker Agent's stdin and reads responses from stdout. ACP is built on the [ACP Go SDK](https://github.com/coder/acp-go-sdk) and provides a standardized way for client applications to interact with AI agents. @@ -42,7 +42,7 @@ $ docker agent serve acp ./agent.yaml --session-db ./my-sessions.db 1. The host application spawns `docker agent serve acp agent.yaml` as a child process 2. Communication happens over **stdin/stdout** using the ACP protocol -3. The host sends user messages, docker-agent processes them through the agent +3. The host sends user messages, Docker Agent processes them through the agent 4. Agent responses, tool calls, and events stream back to the host 5. Sessions are persisted in a SQLite database for continuity @@ -58,7 +58,7 @@ Host Application - **Stdio transport** — No network ports needed; ideal for subprocess integration - **Session persistence** — SQLite-backed sessions survive process restarts -- **Full agent support** — All docker-agent features work: tools, multi-agent, model fallbacks +- **Full agent support** — All Docker Agent features work: tools, multi-agent, model fallbacks - **Multi-agent configs** — Team configurations with sub-agents work transparently - **Filesystem operations** — Agents can read/write files relative to the host's working directory @@ -84,7 +84,7 @@ docker agent serve acp | [flags] ## Integration Example -A host application would spawn docker-agent as a subprocess and communicate via the ACP protocol: +A host application would spawn Docker Agent as a subprocess and communicate via the ACP protocol: ```javascript // Pseudocode for an IDE extension @@ -109,7 +109,7 @@ child.stdout.on("data", (data) => { > [!TIP] > **When to use ACP** > -> Use ACP when building **IDE integrations**, **editor plugins**, or any tool that wants to embed a docker-agent agent as a subprocess. For HTTP-based integrations, use the [API Server](../api-server/index.md) instead. +> Use ACP when building **IDE integrations**, **editor plugins**, or any tool that wants to embed a Docker Agent agent as a subprocess. For HTTP-based integrations, use the [API Server](../api-server/index.md) instead. > [!NOTE] > **See also** diff --git a/docs/features/api-server/index.md b/docs/features/api-server/index.md index 721f686db6..0e9c4e8026 100644 --- a/docs/features/api-server/index.md +++ b/docs/features/api-server/index.md @@ -186,12 +186,12 @@ docker agent serve api | [flags] | `--pull-interval` | `0` (disabled) | Auto-pull OCI reference every N minutes | | `--fake` | (none) | Replay AI responses from cassette file (testing) | | `--record` | (none) | Record AI API interactions to cassette file. Routes through `--models-gateway` when one is configured. | -| `--mcp-oauth-redirect-uri` | (none) | Public HTTPS URL advertised as the OAuth `redirect_uri` for unmanaged MCP OAuth flows. When set, docker-agent drives PKCE and code exchange in-process and sends the full authorize URL to the client via elicitation. See [Remote MCP](../remote-mcp/index.md) for details. | +| `--mcp-oauth-redirect-uri` | (none) | Public HTTPS URL advertised as the OAuth `redirect_uri` for unmanaged MCP OAuth flows. When set, Docker Agent drives PKCE and code exchange in-process and sends the full authorize URL to the client via elicitation. See [Remote MCP](../remote-mcp/index.md) for details. | > [!TIP] > **Live profiling (advanced)** > -> For production diagnostics, set the `CAGENT_PPROF_ADDR` environment variable (or the hidden `--pprof-addr` flag) to a TCP address such as `127.0.0.1:6060`. docker-agent will start a Go pprof HTTP server at `/debug/pprof/`, which you can query with `go tool pprof`. Use a loopback address — a non-loopback binding logs a security warning. This flag is intentionally hidden from `--help`. +> For production diagnostics, set the `CAGENT_PPROF_ADDR` environment variable (or the hidden `--pprof-addr` flag) to a TCP address such as `127.0.0.1:6060`. Docker Agent will start a Go pprof HTTP server at `/debug/pprof/`, which you can query with `go tool pprof`. Use a loopback address — a non-loopback binding logs a security warning. This flag is intentionally hidden from `--help`. > [!TIP] > **Multi-agent configs** diff --git a/docs/features/chat-server/index.md b/docs/features/chat-server/index.md index bf7efcf559..8c212da15a 100644 --- a/docs/features/chat-server/index.md +++ b/docs/features/chat-server/index.md @@ -1,12 +1,12 @@ --- title: "Chat Server" -description: "Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a docker-agent agent." +description: "Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a Docker Agent agent." keywords: docker agent, ai agents, features, chat server weight: 90 canonical: https://docs.docker.com/ai/docker-agent/features/chat-server/ --- -_Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a docker-agent agent._ +_Expose your agents through an OpenAI-compatible Chat Completions API so any tool that already speaks OpenAI can drive a Docker Agent agent._ ## Overview @@ -15,7 +15,7 @@ more agents through an **OpenAI-compatible Chat Completions API** at `/v1/chat/completions` and `/v1/models`. Any client that already speaks the OpenAI protocol — for example [Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI -Python SDK, or LangChain — can drive a docker-agent agent without any custom +Python SDK, or LangChain — can drive a Docker Agent agent without any custom integration. ```bash @@ -38,7 +38,7 @@ $ docker agent serve chat agent.yaml --api-key-env CHAT_BEARER_TOKEN > [!TIP] > **When to use chat server vs. API server** > -> Use the **chat server** when you want to plug docker-agent into existing OpenAI-compatible tooling (chat UIs, IDE integrations, OpenAI SDK clients). Use the [API server](../api-server/index.md) when you want full control over sessions, agent execution, tool-call confirmations, and streamed runtime events. +> Use the **chat server** when you want to plug Docker Agent into existing OpenAI-compatible tooling (chat UIs, IDE integrations, OpenAI SDK clients). Use the [API server](../api-server/index.md) when you want full control over sessions, agent execution, tool-call confirmations, and streamed runtime events. ## Endpoints @@ -207,7 +207,7 @@ also accepted. ## Open WebUI Integration -Open WebUI can talk to any OpenAI-compatible endpoint. To plug docker-agent +Open WebUI can talk to any OpenAI-compatible endpoint. To plug Docker Agent in: 1. Start the chat server, optionally with auth: @@ -229,4 +229,4 @@ in: > [!NOTE] > **See also** > -> For the docker-agent–native HTTP API (sessions, tool-call confirmation, runtime events), see the [API Server](../api-server/index.md). For full CLI flag documentation, see the [CLI Reference](../cli/index.md#docker-agent-serve-chat). +> For the Docker Agent–native HTTP API (sessions, tool-call confirmation, runtime events), see the [API Server](../api-server/index.md). For full CLI flag documentation, see the [CLI Reference](../cli/index.md#docker-agent-serve-chat). diff --git a/docs/features/cli/index.md b/docs/features/cli/index.md index 506839fa42..9e0227968e 100644 --- a/docs/features/cli/index.md +++ b/docs/features/cli/index.md @@ -1,6 +1,6 @@ --- title: "CLI Reference" -description: "Complete reference for all docker-agent command-line commands and flags." +description: "Complete reference for all Docker Agent command-line commands and flags." keywords: docker agent, ai agents, features, cli reference weight: 30 canonical: https://docs.docker.com/ai/docker-agent/features/cli/ @@ -8,7 +8,7 @@ aliases: - /ai/docker-agent/reference/cli/ --- -_Complete reference for all docker-agent command-line commands and flags._ +_Complete reference for all Docker Agent command-line commands and flags._ > [!TIP] > **No config needed** @@ -359,7 +359,7 @@ See [ACP](../acp/index.md) for details on the Agent Client Protocol. ### `docker agent serve chat` -Start an HTTP server that exposes one or more agents through an **OpenAI-compatible Chat Completions API** at `/v1/chat/completions` and `/v1/models`. This lets any tool that already speaks the OpenAI protocol — for example [Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI Python SDK, or LangChain — drive a docker-agent agent without any custom integration. +Start an HTTP server that exposes one or more agents through an **OpenAI-compatible Chat Completions API** at `/v1/chat/completions` and `/v1/models`. This lets any tool that already speaks the OpenAI protocol — for example [Open WebUI](https://github.com/open-webui/open-webui), `curl`, the OpenAI Python SDK, or LangChain — drive a Docker Agent agent without any custom integration. ```bash $ docker agent serve chat [flags] @@ -593,7 +593,7 @@ These flags are available on every `docker agent` command: ### OpenTelemetry environment variables -When `--otel` is enabled, the standard [OTel SDK env vars](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/) are honored (`OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_RESOURCE_ATTRIBUTES`, etc.). Two additional docker-agent-specific variables control GenAI instrumentation: +When `--otel` is enabled, the standard [OTel SDK env vars](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/) are honored (`OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_RESOURCE_ATTRIBUTES`, etc.). Two additional Docker Agent-specific variables control GenAI instrumentation: | Variable | Default | Description | | -------- | ------- | ----------- | diff --git a/docs/features/evaluation/index.md b/docs/features/evaluation/index.md index 19f00a4742..5d6a417ffa 100644 --- a/docs/features/evaluation/index.md +++ b/docs/features/evaluation/index.md @@ -12,7 +12,7 @@ _Measure agent quality with automated evaluations — tool call accuracy, respon ## Overview -The `docker agent eval` command runs your agent against a set of recorded sessions and scores the results. Each eval session captures a user question, the expected tool calls, and criteria the response must satisfy. docker-agent replays the question, compares the agent's behavior to expectations, and produces a report. +The `docker agent eval` command runs your agent against a set of recorded sessions and scores the results. Each eval session captures a user question, the expected tool calls, and criteria the response must satisfy. Docker Agent replays the question, compares the agent's behavior to expectations, and produces a report. > [!NOTE] > **Docker required** @@ -43,7 +43,7 @@ $ docker agent eval agent.yaml --only "auth*" --repeat 5 ## Eval Directory Structure -By default, docker-agent looks for eval sessions in an `evals/` directory next to your agent config: +By default, Docker Agent looks for eval sessions in an `evals/` directory next to your agent config: ```bash my-agent/ @@ -128,7 +128,7 @@ The `evals` object inside each session controls what gets scored: ## Scoring Metrics -docker-agent evaluates agents across three dimensions: +Docker Agent evaluates agents across three dimensions: | Metric | How It's Measured | | ------------------- | ------------------------------------------------------------------------------------------------------------------------- | @@ -170,13 +170,13 @@ $ docker agent eval | [|./evals] When `--base-image` is set, the eval harness builds a derived image on top of your base image at evaluation time. Two things happen automatically: 1. **The docker-agent binary is injected** — it is copied from `docker/docker-agent:edge` into the derived image at build time, so you don't need to include it in your base image. -2. **The entrypoint is overridden** — docker-agent replaces your base image's entrypoint with its own `/run.sh` wrapper. +2. **The entrypoint is overridden** — Docker Agent replaces your base image's entrypoint with its own `/run.sh` wrapper. Your base image therefore only needs to provide the runtime environment: language runtimes, installed dependencies, test fixtures, the appropriate working directory, and so on. Any `ENTRYPOINT` or `CMD` defined in your base image is ignored. ## Output -After a run completes, docker-agent produces: +After a run completes, Docker Agent produces: - **Console summary** — Pass/fail status per eval with metric breakdowns - **JSON results** — Full structured results for programmatic analysis diff --git a/docs/features/mcp-mode/index.md b/docs/features/mcp-mode/index.md index 2609d5e357..569ef91be0 100644 --- a/docs/features/mcp-mode/index.md +++ b/docs/features/mcp-mode/index.md @@ -1,12 +1,12 @@ --- title: "MCP Mode" -description: "Expose your docker-agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications." +description: "Expose your Docker Agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications." keywords: docker agent, ai agents, features, mcp mode weight: 40 canonical: https://docs.docker.com/ai/docker-agent/features/mcp-mode/ --- -_Expose your docker-agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications._ +_Expose your Docker Agent agents as MCP tools for use in Claude Desktop, Claude Code, and other MCP-compatible applications._ ## Why MCP Mode? diff --git a/docs/features/remote-mcp/index.md b/docs/features/remote-mcp/index.md index 2de5640871..88a38c9b47 100644 --- a/docs/features/remote-mcp/index.md +++ b/docs/features/remote-mcp/index.md @@ -1,16 +1,16 @@ --- title: "Remote MCP Servers" -description: "Connect docker-agent to cloud services via remote MCP servers with built-in OAuth authentication." +description: "Connect Docker Agent to cloud services via remote MCP servers with built-in OAuth authentication." keywords: docker agent, ai agents, features, remote mcp servers weight: 120 canonical: https://docs.docker.com/ai/docker-agent/features/remote-mcp/ --- -_Connect docker-agent to cloud services via remote MCP servers with built-in OAuth authentication._ +_Connect Docker Agent to cloud services via remote MCP servers with built-in OAuth authentication._ ## Overview -Docker Agent supports connecting to remote MCP servers over **Streamable HTTP**, **SSE** (Server-Sent Events), and **Unix domain sockets**. Streamable HTTP is the current recommended transport for most hosted MCP servers. Many popular services offer MCP endpoints with OAuth — docker-agent handles the authentication flow automatically. +Docker Agent supports connecting to remote MCP servers over **Streamable HTTP**, **SSE** (Server-Sent Events), and **Unix domain sockets**. Streamable HTTP is the current recommended transport for most hosted MCP servers. Many popular services offer MCP endpoints with OAuth — Docker Agent handles the authentication flow automatically. ```yaml toolsets: @@ -22,7 +22,7 @@ toolsets: ## Unix Domain Sockets -Use a `unix://` URL to connect to an MCP server listening on a local Unix socket. This is useful when running docker-agent inside a container and exposing an MCP server from the host via a bind-mounted socket: +Use a `unix://` URL to connect to an MCP server listening on a local Unix socket. This is useful when running Docker Agent inside a container and exposing an MCP server from the host via a bind-mounted socket: ```yaml toolsets: @@ -37,7 +37,7 @@ The path after `unix://` is the absolute path to the socket file. Configured `he > [!TIP] > **OAuth flow** > -> When you connect to a remote MCP server that requires OAuth, docker-agent opens your browser automatically for authentication. Tokens are cached for subsequent sessions. +> When you connect to a remote MCP server that requires OAuth, Docker Agent opens your browser automatically for authentication. Tokens are cached for subsequent sessions. > [!TIP] > **Cancelling the authorization dialog** @@ -73,30 +73,30 @@ Set `allow_private_ips: true` on a remote MCP toolset only when the MCP server o > Header values in `remote.headers` support `${env.VAR}` and `${headers.NAME}` placeholders. Both are resolved on every outbound HTTP request (not just once at initialization), so short-lived credentials and forwarded caller headers always reflect the latest values: > > - `${env.VAR}` — reads the named environment variable. Useful for credentials stored in a secret manager that rotates them in-process. -> - `${headers.NAME}` — forwards the named header from the caller's incoming HTTP request. Only meaningful when docker-agent is running as an API server (`docker agent serve api`) and a client passes authentication headers that the upstream MCP server also accepts. +> - `${headers.NAME}` — forwards the named header from the caller's incoming HTTP request. Only meaningful when Docker Agent is running as an API server (`docker agent serve api`) and a client passes authentication headers that the upstream MCP server also accepts. > [!NOTE] > **Automatic reconnection after idle timeouts** > -> Remote MCP connections (Streamable HTTP / SSE) automatically reconnect after the server closes an idle connection — no configuration needed. Services like Notion and Linear close idle connections periodically; docker-agent detects the clean close and reconnects with exponential backoff. To tune reconnect behaviour or disable reconnection entirely, use the [`lifecycle` block](../../configuration/tools/index.md#toolset-lifecycle). +> Remote MCP connections (Streamable HTTP / SSE) automatically reconnect after the server closes an idle connection — no configuration needed. Services like Notion and Linear close idle connections periodically; Docker Agent detects the clean close and reconnects with exponential backoff. To tune reconnect behaviour or disable reconnection entirely, use the [`lifecycle` block](../../configuration/tools/index.md#toolset-lifecycle). > [!NOTE] > **Automatic recovery from revoked or rotated OAuth tokens** > -> If a remote MCP server rejects the cached token with a `401 invalid_token` error (for example, because the token was revoked or rotated server-side), docker-agent handles the failure automatically: +> If a remote MCP server rejects the cached token with a `401 invalid_token` error (for example, because the token was revoked or rotated server-side), Docker Agent handles the failure automatically: > -> - **Silent refresh:** when a refresh token is available, docker-agent silently exchanges it for a new access token and replays the request — no user interaction required. +> - **Silent refresh:** when a refresh token is available, Docker Agent silently exchanges it for a new access token and replays the request — no user interaction required. > - **Re-authentication prompt:** when the refresh token is absent or has also expired, the toolset transitions to a "needs re-auth" state and surfaces an OAuth prompt on your next message (exactly like the first-time flow). > > Either way, the agent never burns 5 reconnect attempts on an auth failure — it fails fast and either refreshes silently or defers to interactive re-auth. If you want to trigger re-auth immediately without waiting for the next message, run `/toolset-restart ` from the TUI. ### OAuth for servers without Dynamic Client Registration -Most remote MCP servers that require OAuth support [Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) — no configuration is needed, docker-agent handles the flow for you. +Most remote MCP servers that require OAuth support [Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) — no configuration is needed, Docker Agent handles the flow for you. -For servers that do **not** support DCR, docker-agent falls back automatically: +For servers that do **not** support DCR, Docker Agent falls back automatically: -1. **Interactive credential prompt**: docker-agent presents a dialog asking for your `client_id` (required) and optionally a `client_secret`. This covers servers that require pre-registered app credentials but don't advertise them via DCR. +1. **Interactive credential prompt**: Docker Agent presents a dialog asking for your `client_id` (required) and optionally a `client_secret`. This covers servers that require pre-registered app credentials but don't advertise them via DCR. 2. **Explicit `oauth:` block** (recommended when you know the credentials in advance): add the block described below to skip the interactive prompt and supply credentials directly in config. ```yaml @@ -118,7 +118,7 @@ toolsets: | -------------- | --------------- | -------- | ------------------------------------------------------------------------------------------------ | | `clientId` | string | ✓ | OAuth client ID registered with the remote MCP server. | | `clientSecret` | string | ✗ | OAuth client secret. Omit for public clients using PKCE. | -| `callbackPort` | integer | ✗ | Local port to receive the OAuth redirect. If omitted, docker-agent picks a random free port. | +| `callbackPort` | integer | ✗ | Local port to receive the OAuth redirect. If omitted, Docker Agent picks a random free port. | | `scopes` | array[string] | ✗ | Scopes to request during the authorization step. Values are server-specific. | | `callbackRedirectURL` | string | ✗ | Custom OAuth redirect URI. Useful when the auth server requires HTTPS or a pre-registered URL. The literal placeholder `${callbackPort}` is replaced with the actual local callback port. See below. | @@ -156,7 +156,7 @@ The local callback server still listens on the loopback interface on `callbackPo ### Unmanaged OAuth flow (server mode) -When running `docker-agent serve api` (no local browser, no callback server), the runtime delegates the OAuth dance to the connected client via an MCP elicitation. There are two sub-behaviors, selected by the `--mcp-oauth-redirect-uri` flag: +When running `docker agent serve api` (no local browser, no callback server), the runtime delegates the OAuth dance to the connected client via an MCP elicitation. There are two sub-behaviors, selected by the `--mcp-oauth-redirect-uri` flag: - **`--mcp-oauth-redirect-uri=` set** (recommended for hosts like Docker Desktop): the runtime generates `state` + PKCE + (optional) Dynamic Client Registration in-process, builds the full authorize URL, and emits an elicitation whose `Meta` includes: diff --git a/docs/features/skills/index.md b/docs/features/skills/index.md index 92bb74ca1b..bba760387a 100644 --- a/docs/features/skills/index.md +++ b/docs/features/skills/index.md @@ -10,7 +10,7 @@ _Skills provide specialized instructions that agents can load on demand when a t ## How Skills Work -1. docker-agent scans standard directories for `SKILL.md` files +1. Docker Agent scans standard directories for `SKILL.md` files 2. Skill metadata (name, description) is injected into the agent's system prompt 3. When a user request matches a skill, the agent reads the full instructions 4. The agent follows the skill's detailed instructions to complete the task @@ -342,7 +342,7 @@ When multiple skills share the same name: ## Skills in Sandbox Mode -When you run an agent with [`--sandbox`](../../configuration/sandbox/index.md), the sandbox VM has its own filesystem with no access to your host's skill directories. docker-agent handles this transparently via the [auto-kit](../../configuration/sandbox/index.md#auto-kit): every discovered local skill is staged into a per-agent kit on the host, run through best-effort secret redaction (see the [auto-kit](../../configuration/sandbox/index.md#secret-redaction) docs), and bind-mounted read-only into the sandbox so the agent sees the same skills inside the VM as on the host. No configuration is required — use `--no-kit` only if you explicitly want to run the sandbox without any host skills. +When you run an agent with [`--sandbox`](../../configuration/sandbox/index.md), the sandbox VM has its own filesystem with no access to your host's skill directories. Docker Agent handles this transparently via the [auto-kit](../../configuration/sandbox/index.md#auto-kit): every discovered local skill is staged into a per-agent kit on the host, run through best-effort secret redaction (see the [auto-kit](../../configuration/sandbox/index.md#secret-redaction) docs), and bind-mounted read-only into the sandbox so the agent sees the same skills inside the VM as on the host. No configuration is required — use `--no-kit` only if you explicitly want to run the sandbox without any host skills. ## Creating a Skill diff --git a/docs/features/snapshots/index.md b/docs/features/snapshots/index.md index d3bd939421..bc624bf891 100644 --- a/docs/features/snapshots/index.md +++ b/docs/features/snapshots/index.md @@ -10,9 +10,9 @@ _Shadow-git snapshots capture your workspace at turn boundaries so you can revie ## Overview -When snapshots are enabled, docker-agent records the state of your working +When snapshots are enabled, Docker Agent records the state of your working directory as the agent runs. Each checkpoint is stored in a **shadow git -repository** kept under the docker-agent data directory — completely separate +repository** kept under the Docker Agent data directory — completely separate from your project's own `.git`. This lets you: - **Review** exactly which files an agent touched on a given turn. @@ -84,7 +84,7 @@ when snapshots are turned off. ## How It Works - **Shadow repository.** The first time a snapshot is taken for a worktree, - docker-agent initializes a separate shadow git directory under the data + Docker Agent initializes a separate shadow git directory under the data directory (`~/.cagent/snapshot/...` by default), keyed by a hash of the worktree path. The shadow repo stores tree objects only — it never writes commits and never touches your source repository's `.git`. diff --git a/docs/features/tui/index.md b/docs/features/tui/index.md index fdc419293a..821c5d34c7 100644 --- a/docs/features/tui/index.md +++ b/docs/features/tui/index.md @@ -1,15 +1,15 @@ --- title: "Terminal UI (TUI)" -description: "docker-agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more." +description: "Docker Agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more." keywords: docker agent, ai agents, features, terminal ui (tui) linkTitle: "Terminal UI" weight: 10 canonical: https://docs.docker.com/ai/docker-agent/features/tui/ --- -_docker-agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more._ +_Docker Agent's default interface is a rich, interactive terminal UI with file attachments, themes, session management, and more._ -![docker-agent TUI in action showing an interactive agent session](../../demo.gif) +![Docker Agent TUI in action showing an interactive agent session](../../demo.gif) ## Launching the TUI @@ -225,7 +225,7 @@ settings: snapshot: true ``` -When enabled, docker-agent records filesystem snapshots at turn boundaries. The TUI exposes two slash commands that operate on those snapshots: +When enabled, Docker Agent records filesystem snapshots at turn boundaries. The TUI exposes two slash commands that operate on those snapshots: - **`/undo`** restores files from the most recent snapshot (one step back). - **`/snapshots`** opens a dialog showing how many snapshots have been captured and the number of files in each one. Use ↑/↓ (or j/k) to highlight an entry, then press r to reset the workspace to that point. Pick `` to revert every snapshot and bring the workspace back to its pre-agent state. Esc closes the dialog without changing anything. @@ -286,7 +286,7 @@ Each error message includes a clickable **↻ retry** button. Clicking it resume ## Session Management -docker-agent automatically saves your sessions. Use `/sessions` to browse past conversations: +Docker Agent automatically saves your sessions. Use `/sessions` to browse past conversations: - **Browse** past sessions with search and filtering - **Workspace grouping**: sessions started in the current directory are listed first under "This workspace", everything else under "Other locations" with its originating directory shown next to each entry; press Ctrl+G in the browser to cycle between all, current-directory only, and other-directory views. Restoring a session reopens it in its original directory, so the label always matches where a restore will land @@ -297,7 +297,7 @@ docker-agent automatically saves your sessions. Use `/sessions` to browse past c ### Session Title Editing -Customize session titles to make them more meaningful and easier to find. By default, docker-agent auto-generates titles based on your first message, but you can override or regenerate them at any time. +Customize session titles to make them more meaningful and easier to find. By default, Docker Agent auto-generates titles based on your first message, but you can override or regenerate them at any time. **Using the `/title` command:** @@ -450,7 +450,7 @@ settings: theme_light: default-light # optional, theme used on light backgrounds (default: default-light) ``` -At startup the terminal background is queried (OSC 11) to pick the dark or light theme of the pair; non-interactive runs (pipes, CI) fall back to the dark theme. In terminals that report appearance changes (DEC mode 2031 — Ghostty, kitty, contour, …), flipping the OS or terminal appearance while docker-agent is running switches the theme live. Terminals without that mode re-sync when the window regains focus. +At startup the terminal background is queried (OSC 11) to pick the dark or light theme of the pair; non-interactive runs (pipes, CI) fall back to the dark theme. In terminals that report appearance changes (DEC mode 2031 — Ghostty, kitty, contour, …), flipping the OS or terminal appearance while Docker Agent is running switches the theme live. Terminals without that mode re-sync when the window regains focus. ### Custom Themes @@ -519,7 +519,7 @@ settings: ## Tool Permissions -When an agent calls a tool, docker-agent shows a confirmation dialog by default. You can: +When an agent calls a tool, Docker Agent shows a confirmation dialog by default. You can: - **Approve once** — Allow this specific call - **Always allow** — Permanently approve this tool/command for the session From aa3d09f0e9a5b135b902caf64c169e24b262b8cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:24:46 +0200 Subject: [PATCH 06/10] =?UTF-8?q?docs(style):=20naming=20sweep=20=E2=80=94?= =?UTF-8?q?=20tools?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace prose uses of 'docker-agent' with 'Docker Agent' across docs/tools/{open-url,shell,plan,background-jobs,mcp-catalog,lsp,mcp,rag}. Preserved unchanged: canonical/alias URLs, docker/docker-agent repo/examples links, and a literal HTTP header value (X-Internal-Client: "docker-agent") in a fetch example. --- docs/tools/background-jobs/index.md | 2 +- docs/tools/lsp/index.md | 4 ++-- docs/tools/mcp-catalog/index.md | 10 +++++----- docs/tools/mcp/index.md | 8 ++++---- docs/tools/open-url/index.md | 4 ++-- docs/tools/plan/index.md | 2 +- docs/tools/rag/index.md | 4 ++-- docs/tools/shell/index.md | 2 +- 8 files changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/tools/background-jobs/index.md b/docs/tools/background-jobs/index.md index 158d4b1473..8a7a3915e6 100644 --- a/docs/tools/background-jobs/index.md +++ b/docs/tools/background-jobs/index.md @@ -50,7 +50,7 @@ toolsets: recall: true ``` -When the agent starts a background job with `recall: true`, docker-agent sends a steering message back into the running agent loop after the job finishes. The message contains a short completion sentence and the job output, so the agent can react without polling `view_background_job`. +When the agent starts a background job with `recall: true`, Docker Agent sends a steering message back into the running agent loop after the job finishes. The message contains a short completion sentence and the job output, so the agent can react without polling `view_background_job`. Use recall for finite background work where completion matters (for example, a long build or test suite). Avoid it for servers and watchers that are expected to run until stopped. See [`examples/shell_recall.yaml`](https://github.com/docker/docker-agent/blob/main/examples/shell_recall.yaml) for a complete configuration. diff --git a/docs/tools/lsp/index.md b/docs/tools/lsp/index.md index 0cb6216fd1..b2d97b7227 100644 --- a/docs/tools/lsp/index.md +++ b/docs/tools/lsp/index.md @@ -171,7 +171,7 @@ The LSP tool includes built-in instructions that guide the agent on how to use i ## Capability Detection -Not all LSP servers support all features. During the `initialize` handshake, docker-agent reads the server's `ServerCapabilities` and **filters out the `lsp_*` tools the server does not advertise**. The model never sees, for example, `lsp_inlay_hints` against a server that doesn't support it, so it can't waste a turn calling a tool that would only fail. +Not all LSP servers support all features. During the `initialize` handshake, Docker Agent reads the server's `ServerCapabilities` and **filters out the `lsp_*` tools the server does not advertise**. The model never sees, for example, `lsp_inlay_hints` against a server that doesn't support it, so it can't waste a turn calling a tool that would only fail. The agent uses `lsp_workspace` to discover what's available: @@ -224,4 +224,4 @@ All LSP tools use **1-based** line and character positions: > [!TIP] > **Auto-Installation** > -> docker-agent can automatically download and install LSP servers if they are not found in your PATH. Use the `version` property to specify a package, or let docker-agent auto-detect it from the command name. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools) for details. +> Docker Agent can automatically download and install LSP servers if they are not found in your PATH. Use the `version` property to specify a package, or let Docker Agent auto-detect it from the command name. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools) for details. diff --git a/docs/tools/mcp-catalog/index.md b/docs/tools/mcp-catalog/index.md index b2fbdf3d48..4bf58a9a6b 100644 --- a/docs/tools/mcp-catalog/index.md +++ b/docs/tools/mcp-catalog/index.md @@ -11,7 +11,7 @@ _Let the agent discover and activate remote MCP servers from the Docker MCP Cata ## Overview -The `mcp_catalog` toolset gives an agent access to a curated subset of the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp) — every server in this subset is reachable over the **streamable-http** transport, so docker-agent can talk to it directly without the MCP gateway or a local subprocess. +The `mcp_catalog` toolset gives an agent access to a curated subset of the [Docker MCP Catalog](https://hub.docker.com/search?q=&type=mcp) — every server in this subset is reachable over the **streamable-http** transport, so Docker Agent can talk to it directly without the MCP gateway or a local subprocess. Servers are **not** active by default. Instead, the toolset exposes a small set of meta-tools the agent uses to search, enable, and disable servers as a turn unfolds. Tools from un-enabled servers stay hidden, so the prompt is not flooded with hundreds of tool definitions the agent will never use. @@ -27,7 +27,7 @@ toolsets: - type: mcp_catalog ``` -The catalog is embedded in the docker-agent binary and refreshed with each release. By default every server in the embedded subset is offered. +The catalog is embedded in the Docker Agent binary and refreshed with each release. By default every server in the embedded subset is offered. ### Restricting the offered servers @@ -72,7 +72,7 @@ Up to five tools are exposed to the model. The disable / reset-auth pair only ap ## Authentication -The catalog only includes servers docker-agent can authenticate itself, so there are two auth flavours: +The catalog only includes servers Docker Agent can authenticate itself, so there are two auth flavours: - **`oauth`** — `enable_remote_mcp_server` surfaces an authorization URL through the elicitation pipeline (the same one used by YAML-declared remote MCP toolsets) and blocks until the user either authorizes or cancels. Once the user authorizes, tokens are persisted in the OS keyring and re-used on subsequent runs. Use `reset_remote_mcp_server_auth` to wipe them. If the user dismisses the dialog, `enable` returns an error result naming the decline so the agent can ask whether to retry. - **`none`** — No authentication. The server is reachable as soon as it is enabled. @@ -102,10 +102,10 @@ A complete, runnable configuration lives in [`examples/mcp_catalog.yaml`](https: ## Notes and Limitations - **Streamable-http only.** The catalog deliberately excludes servers that require a local subprocess or the MCP gateway — declare those with [`type: mcp`](../../configuration/tools/index.md#mcp-tools) instead. -- **Catalog membership changes between releases.** The set of available servers is updated with each docker-agent release as integrations are added or removed. Servers present in one release may not appear in the next. +- **Catalog membership changes between releases.** The set of available servers is updated with each Docker Agent release as integrations are added or removed. Servers present in one release may not appear in the next. - **Blocking enable.** DNS, TCP, MCP handshake and any OAuth flow happen synchronously inside `enable_remote_mcp_server` so the agent gets a deterministic result in the same turn. On startup, however, the runtime probes tools non-interactively (`mcp.WithoutInteractivePrompts`); OAuth-pending servers fail fast there and are silently deferred to the next interactive turn — including the sidebar-only tool-count pass, where a dialog would be impossible. - **No prompt discovery.** MCP prompt lookups (`/prompts`) walk YAML-declared `mcp` toolsets directly; prompts exposed by servers activated through the catalog are not surfaced. Tools — the primary interface — work fine. -- **Frozen at build time.** The list of servers is embedded in the binary. New entries land with each docker-agent release. +- **Frozen at build time.** The list of servers is embedded in the binary. New entries land with each Docker Agent release. > [!TIP] > **Pair with permissions** diff --git a/docs/tools/mcp/index.md b/docs/tools/mcp/index.md index 0b60da5193..b1acb0cca7 100644 --- a/docs/tools/mcp/index.md +++ b/docs/tools/mcp/index.md @@ -76,11 +76,11 @@ toolsets: > [!TIP] > **Auto-installation** > -> If the `command` is not in your `PATH`, docker-agent looks it up in the [aqua registry](https://github.com/aquaproj/aqua-registry) and installs it for you. Use `version: "false"` to opt out, or set `DOCKER_AGENT_AUTO_INSTALL=false` globally. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools). +> If the `command` is not in your `PATH`, Docker Agent looks it up in the [aqua registry](https://github.com/aquaproj/aqua-registry) and installs it for you. Use `version: "false"` to opt out, or set `DOCKER_AGENT_AUTO_INSTALL=false` globally. See [Auto-Installing Tools](../../configuration/tools/index.md#auto-installing-tools). ## Remote MCP (Streamable HTTP / SSE) -Connect to MCP servers over the network. OAuth flows (including [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591)) are handled automatically — docker-agent opens your browser when authentication is required and caches tokens for subsequent sessions. Tokens are refreshed silently when they expire or are revoked server-side; if a silent refresh is not possible, the OAuth prompt reappears on the next message. +Connect to MCP servers over the network. OAuth flows (including [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591)) are handled automatically — Docker Agent opens your browser when authentication is required and caches tokens for subsequent sessions. Tokens are refreshed silently when they expire or are revoked server-side; if a silent refresh is not possible, the OAuth prompt reappears on the next message. ```yaml toolsets: @@ -120,7 +120,7 @@ MCP servers can expose **prompts** — named, parameterized templates that the s - Each MCP prompt appears in the command palette (accessible via Ctrl+K) under the **MCP Prompts** category. - Typing `/` in the input box invokes the prompt immediately. - If the prompt declares arguments and you provide text after the slash command, that text is mapped to the first declared argument. -- If a required argument is missing, docker-agent opens the argument input dialog before running the prompt. +- If a required argument is missing, Docker Agent opens the argument input dialog before running the prompt. - When no argument is needed or all required arguments are supplied, the prompt runs immediately. > [!NOTE] @@ -239,7 +239,7 @@ See [Per-Toolset Model Routing](../../configuration/tools/index.md#per-toolset-m ### Lifecycle (auto-restart, profiles) -Local stdio and remote MCP servers are supervised: crashed servers reconnect automatically with exponential backoff. **Remote** MCP servers (Streamable HTTP / SSE) also reconnect after idle/clean connection closes — services like Notion and Linear periodically close idle connections, and docker-agent reconnects transparently. Tune the policy with the `lifecycle` block: +Local stdio and remote MCP servers are supervised: crashed servers reconnect automatically with exponential backoff. **Remote** MCP servers (Streamable HTTP / SSE) also reconnect after idle/clean connection closes — services like Notion and Linear periodically close idle connections, and Docker Agent reconnects transparently. Tune the policy with the `lifecycle` block: ```yaml toolsets: diff --git a/docs/tools/open-url/index.md b/docs/tools/open-url/index.md index bb07b93970..b2a97dd44b 100644 --- a/docs/tools/open-url/index.md +++ b/docs/tools/open-url/index.md @@ -14,7 +14,7 @@ _Open a fixed URL in the user's default browser._ The `open_url` toolset exposes a single, argument-less tool that opens a URL baked into the toolset definition in the user's default browser. The model never supplies the URL — it just calls the tool by name. Launching the browser -is cross-platform: docker-agent uses `open` on macOS, `xdg-open` on Linux, and +is cross-platform: Docker Agent uses `open` on macOS, `xdg-open` on Linux, and `rundll32` on Windows. > [!NOTE] @@ -88,7 +88,7 @@ toolsets: - The URL must include a scheme (e.g. `https://`); bare paths are rejected. - URLs that look like a command-line flag (starting with `-`) are refused to prevent argument injection into the platform `open` helper. -- The tool opens the URL on the **host** running docker-agent; in headless or +- The tool opens the URL on the **host** running Docker Agent; in headless or remote environments where no browser/launcher is available, the call fails gracefully and reports the error to the agent. diff --git a/docs/tools/plan/index.md b/docs/tools/plan/index.md index e1d15c8ce1..23761d8a6a 100644 --- a/docs/tools/plan/index.md +++ b/docs/tools/plan/index.md @@ -13,7 +13,7 @@ _Shared persistent scratchpad for multi-agent collaboration._ The plan tool gives agents a shared, persistent scratchpad of named documents. Any agent in a multi-agent config that loads the `plan` toolset can read and write the same plans, and those plans survive across sessions. This makes it straightforward to wire a planner agent that sketches work and one or more executor agents that consume it without any custom tool wiring. -Plans are stored as JSON files in the docker-agent data directory (`~/.cagent/plans/` by default). All agents that share a process serialize on a single mutex so concurrent reads and writes are safe. Writes are atomic (temp file + rename), so a reader never observes partial content. +Plans are stored as JSON files in the Docker Agent data directory (`~/.cagent/plans/` by default). All agents that share a process serialize on a single mutex so concurrent reads and writes are safe. Writes are atomic (temp file + rename), so a reader never observes partial content. ## Configuration diff --git a/docs/tools/rag/index.md b/docs/tools/rag/index.md index f47dd070c6..111ebfa606 100644 --- a/docs/tools/rag/index.md +++ b/docs/tools/rag/index.md @@ -13,7 +13,7 @@ _Give your agents access to document knowledge bases with background indexing, m ## Overview -The `rag` toolset lets agents search through your documents to find relevant information before responding. Knowledge bases are declared once at the top of the config under `rag:` and then referenced from any agent via `type: rag, ref: `. docker-agent supports: +The `rag` toolset lets agents search through your documents to find relevant information before responding. Knowledge bases are declared once at the top of the config under `rag:` and then referenced from any agent via `type: rag, ref: `. Docker Agent supports: - **Background indexing** — Files are indexed automatically and re-indexed on change - **Multiple strategies** — Semantic embeddings, BM25 keyword search, and LLM-enhanced search @@ -182,7 +182,7 @@ $ docker agent run config.yaml --debug --log-file debug.log Look for log tags: `[RAG Manager]`, `[Chunked-Embeddings Strategy]`, `[BM25 Strategy]`, `[RRF Fusion]`, `[Reranker]`. -**Permanent model errors abort early.** If the embedding model, semantic-LLM model, or reranking model returns a permanent error (HTTP 400, 401, 404, or 429 — invalid config, bad auth, unknown model, or rate limit), docker-agent treats the model configuration as invalid and stops immediately rather than retrying doomed requests: +**Permanent model errors abort early.** If the embedding model, semantic-LLM model, or reranking model returns a permanent error (HTTP 400, 401, 404, or 429 — invalid config, bad auth, unknown model, or rate limit), Docker Agent treats the model configuration as invalid and stops immediately rather than retrying doomed requests: - **Indexing** — the entire indexing run is aborted after the first permanent failure (including 429). The error is surfaced in the logs so you know immediately if a model name or API key is wrong, rather than silently producing incomplete results. - **Reranking** — a permanent error (including 429) permanently disables the reranker for the lifetime of the manager. Subsequent queries fall back to un-reranked results. Only transient errors (5xx, timeouts) fall back and retry on the next query. diff --git a/docs/tools/shell/index.md b/docs/tools/shell/index.md index 2921f629c1..bcac1b9d8a 100644 --- a/docs/tools/shell/index.md +++ b/docs/tools/shell/index.md @@ -111,4 +111,4 @@ The shell toolset exposes one tool: > [!NOTE] > **Tool Confirmation** > -> By default, docker-agent asks for user confirmation before executing shell commands. Use `--yolo` to auto-approve all tool calls. +> By default, Docker Agent asks for user confirmation before executing shell commands. Use `--yolo` to auto-approve all tool calls. From 73aef680890166b7d1fc37693a43870a76d28e89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:30:35 +0200 Subject: [PATCH 07/10] =?UTF-8?q?docs(style):=20naming=20sweep=20=E2=80=94?= =?UTF-8?q?=20providers?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace prose/front-matter uses of 'docker-agent' with 'Docker Agent' across all 30 docs/providers/*/index.md pages (built-in alias providers, AWS Bedrock, DMR, Mistral, OpenAI, custom providers, and the providers overview). Preserved unchanged: canonical/alias URLs, docker/docker-agent repo and examples/ links, literal HTTP header/default-value identifiers (X-Request-Source: docker-agent, role_session_name default docker-agent-bedrock-session), and config filenames (docker-agent.yaml/.yml/.hcl). --- docs/providers/anthropic/index.md | 16 ++++++++-------- docs/providers/baseten/index.md | 8 ++++---- docs/providers/bedrock/index.md | 4 ++-- docs/providers/cerebras/index.md | 10 +++++----- docs/providers/chatgpt/index.md | 10 +++++----- docs/providers/cloudflare-ai-gateway/index.md | 12 ++++++------ docs/providers/cloudflare-workers-ai/index.md | 10 +++++----- docs/providers/custom/index.md | 2 +- docs/providers/deepseek/index.md | 8 ++++---- docs/providers/dmr/index.md | 8 ++++---- docs/providers/fireworks/index.md | 10 +++++----- docs/providers/github-copilot/index.md | 18 +++++++++--------- docs/providers/google/index.md | 6 +++--- docs/providers/groq/index.md | 8 ++++---- docs/providers/huggingface/index.md | 10 +++++----- docs/providers/local/index.md | 8 ++++---- docs/providers/minimax/index.md | 8 ++++---- docs/providers/mistral/index.md | 14 +++++++------- docs/providers/moonshot/index.md | 8 ++++---- docs/providers/nebius/index.md | 8 ++++---- docs/providers/nvidia/index.md | 10 +++++----- docs/providers/openai/index.md | 6 +++--- docs/providers/opencode-go/index.md | 12 ++++++------ docs/providers/opencode-zen/index.md | 12 ++++++------ docs/providers/openrouter/index.md | 14 +++++++------- docs/providers/overview/index.md | 6 +++--- docs/providers/ovhcloud/index.md | 12 ++++++------ docs/providers/together/index.md | 10 +++++----- docs/providers/vercel/index.md | 10 +++++----- docs/providers/xai/index.md | 10 +++++----- 30 files changed, 144 insertions(+), 144 deletions(-) diff --git a/docs/providers/anthropic/index.md b/docs/providers/anthropic/index.md index c7e8804190..104a609d88 100644 --- a/docs/providers/anthropic/index.md +++ b/docs/providers/anthropic/index.md @@ -1,12 +1,12 @@ --- title: "Anthropic" -description: "Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with docker-agent." +description: "Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, anthropic weight: 20 canonical: https://docs.docker.com/ai/docker-agent/providers/anthropic/ --- -_Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with docker-agent._ +_Use Claude Sonnet 4, Claude Sonnet 4.5, and other Anthropic models with Docker Agent._ ## Setup @@ -20,7 +20,7 @@ export ANTHROPIC_API_KEY="sk-ant-..." Authenticate with short-lived tokens minted from your own OIDC identity provider instead of a long-lived API key. See Anthropic's [Workload Identity Federation guide](https://platform.claude.com/docs/en/build-with-claude/workload-identity-federation) -to provision a Federation Rule, then configure docker-agent with a typed +to provision a Federation Rule, then configure Docker Agent with a typed `auth:` block: ```yaml @@ -156,9 +156,9 @@ is forwarded as and is ideal for letting long-running agents self-regulate effort without tightening `max_tokens` on every call. -docker-agent automatically attaches the required `task-budgets-2026-03-13` +Docker Agent automatically attaches the required `task-budgets-2026-03-13` beta header whenever this field is set. You can configure `task_budget` on -**any** Claude model — docker-agent never gates it by model name. At the time +**any** Claude model — Docker Agent never gates it by model name. At the time of writing, only **Claude Opus 4.7** actually honors the field; other Claude models (Sonnet 4.5, Opus 4.5 / 4.6, etc.) are expected to reject requests that include it. Check the Anthropic release notes linked above for the @@ -204,7 +204,7 @@ models: - claude-sonnet-4-6 ``` -docker-agent automatically attaches the required +Docker Agent automatically attaches the required `server-side-fallback-2026-06-01` beta header and forwards the option as `fallbacks: [{"model": "..."}]`. The response's `model` field reports which model actually served the request. @@ -216,7 +216,7 @@ AI, or the Message Batches API. ## Thinking Display -Controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); docker-agent counters this by requesting `summarized` thinking whenever an adaptive/effort-based budget is used without an explicit `thinking_display`, so reasoning stays visible in the UI. Set `thinking_display` in `provider_opts` to override: +Controls whether thinking blocks are returned in responses when thinking is enabled. Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default (`omitted`); Docker Agent counters this by requesting `summarized` thinking whenever an adaptive/effort-based budget is used without an explicit `thinking_display`, so reasoning stays visible in the UI. Set `thinking_display` in `provider_opts` to override: ```yaml models: @@ -230,7 +230,7 @@ models: Valid values: -- `summarized`: thinking blocks are returned with summarized thinking text (docker-agent's default for adaptive/effort-based budgets). +- `summarized`: thinking blocks are returned with summarized thinking text (Docker Agent's default for adaptive/effort-based budgets). - `display`: thinking blocks are returned for display. - `omitted`: thinking blocks are returned with an empty thinking field; the signature is still returned for multi-turn continuity. Useful to reduce time-to-first-text-token when streaming. diff --git a/docs/providers/baseten/index.md b/docs/providers/baseten/index.md index 16337d3cf8..f364284848 100644 --- a/docs/providers/baseten/index.md +++ b/docs/providers/baseten/index.md @@ -1,16 +1,16 @@ --- title: "Baseten" -description: "Use Baseten AI models with docker-agent." +description: "Use Baseten AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, baseten weight: 40 canonical: https://docs.docker.com/ai/docker-agent/providers/baseten/ --- -_Use Baseten AI models with docker-agent._ +_Use Baseten AI models with Docker Agent._ ## Overview -Baseten provides AI models through an OpenAI-compatible API. docker-agent includes built-in support for Baseten as an alias provider. +Baseten provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for Baseten as an alias provider. ## Setup @@ -67,7 +67,7 @@ Baseten hosts various open models through its Model APIs. Check the [Baseten doc ## How It Works -Baseten is implemented as a built-in alias in docker-agent: +Baseten is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://inference.baseten.co/v1` diff --git a/docs/providers/bedrock/index.md b/docs/providers/bedrock/index.md index 7aae4d6878..f7e190a086 100644 --- a/docs/providers/bedrock/index.md +++ b/docs/providers/bedrock/index.md @@ -138,7 +138,7 @@ models: region: us-east-1 ``` -docker-agent recognizes these models (including Bedrock-style IDs) and transparently coerces a configured token budget or effort level to adaptive thinking, logging a warning — so `thinking_budget: 32768` on Opus 4.8 won't fail, but `adaptive` or `adaptive/` is the recommended configuration. On older models that still use token-based thinking (e.g. Sonnet 4.5), `adaptive` is forwarded as-is and rejected by Bedrock — use a token count or effort level there instead. +Docker Agent recognizes these models (including Bedrock-style IDs) and transparently coerces a configured token budget or effort level to adaptive thinking, logging a warning — so `thinking_budget: 32768` on Opus 4.8 won't fail, but `adaptive` or `adaptive/` is the recommended configuration. On older models that still use token-based thinking (e.g. Sonnet 4.5), `adaptive` is forwarded as-is and rejected by Bedrock — use a token count or effort level there instead. > [!NOTE] > **Temperature and top_p** @@ -160,7 +160,7 @@ models: # interleaved_thinking is auto-enabled when thinking_budget is set ``` -docker-agent auto-enables `interleaved_thinking` whenever a thinking budget is configured on a Bedrock-hosted Claude model and automatically adds the `interleaved-thinking-2025-05-14` beta header. If you set `interleaved_thinking: false` while a thinking budget is active, a warning is logged because the budget may be ignored by Bedrock without the beta header. +Docker Agent auto-enables `interleaved_thinking` whenever a thinking budget is configured on a Bedrock-hosted Claude model and automatically adds the `interleaved-thinking-2025-05-14` beta header. If you set `interleaved_thinking: false` while a thinking budget is active, a warning is logged because the budget may be ignored by Bedrock without the beta header. See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for a full cross-provider overview. diff --git a/docs/providers/cerebras/index.md b/docs/providers/cerebras/index.md index 4252330924..bf0dba14c9 100644 --- a/docs/providers/cerebras/index.md +++ b/docs/providers/cerebras/index.md @@ -1,19 +1,19 @@ --- title: "Cerebras" -description: "Use Cerebras models with docker-agent." +description: "Use Cerebras models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, cerebras weight: 50 canonical: https://docs.docker.com/ai/docker-agent/providers/cerebras/ --- -_Use Cerebras models with docker-agent._ +_Use Cerebras models with Docker Agent._ ## Overview [Cerebras](https://www.cerebras.ai/) serves open-weight models such as GPT-OSS and GLM through an OpenAI-compatible API on its wafer-scale hardware, delivering some of the highest tokens/sec available. That speed makes it a strong fit for -latency-sensitive coding workflows. docker-agent includes built-in support for +latency-sensitive coding workflows. Docker Agent includes built-in support for Cerebras as an alias provider. ## Setup @@ -75,14 +75,14 @@ for current model IDs, context limits, and pricing. ## How It Works -Cerebras is implemented as a built-in alias in docker-agent: +Cerebras is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.cerebras.ai/v1` - **Token Variable:** `CEREBRAS_API_KEY` Because Cerebras fronts open-weight models whose chat templates may only accept -a single leading system message, docker-agent coalesces its per-source system +a single leading system message, Docker Agent coalesces its per-source system messages (agent instruction plus each toolset's instructions) into one before sending the request. diff --git a/docs/providers/chatgpt/index.md b/docs/providers/chatgpt/index.md index d911d17970..870ddcfb61 100644 --- a/docs/providers/chatgpt/index.md +++ b/docs/providers/chatgpt/index.md @@ -1,12 +1,12 @@ --- title: "ChatGPT (OpenAI account)" -description: "Use your ChatGPT Plus/Pro/Business subscription with docker-agent by signing in with your OpenAI account, no API key needed." +description: "Use your ChatGPT Plus/Pro/Business subscription with Docker Agent by signing in with your OpenAI account, no API key needed." keywords: docker agent, ai agents, model providers, llm, chatgpt, openai, codex, subscription weight: 55 canonical: https://docs.docker.com/ai/docker-agent/providers/chatgpt/ --- -_Use your ChatGPT subscription with docker-agent by signing in with your OpenAI account. No API key needed._ +_Use your ChatGPT subscription with Docker Agent by signing in with your OpenAI account. No API key needed._ ## Overview @@ -15,7 +15,7 @@ The `chatgpt` provider authenticates with a ChatGPT account (the same `OPENAI_API_KEY`. Usage is billed against your ChatGPT Plus, Pro, or Business plan rather than pay-per-token API credits. -Under the hood, docker-agent talks to the ChatGPT Codex backend +Under the hood, Docker Agent talks to the ChatGPT Codex backend (`https://chatgpt.com/backend-api/codex`), which serves the `gpt-5` model family over the OpenAI Responses API. GPT-5.6 (Sol/Terra/Luna) is served there too; GPT-5.2 and GPT-5.3-Codex are deprecated for ChatGPT sign-in. @@ -34,7 +34,7 @@ docker agent setup Pick **chatgpt** in the provider list: instead of asking for an API key, the wizard opens your browser on the ChatGPT sign-in page and stores the -resulting OAuth credential in the docker-agent config directory +resulting OAuth credential in the Docker Agent config directory (`~/.config/cagent/chatgpt-auth.json`, owner-only permissions). The access token is refreshed automatically; you only need to sign in again if the refresh token is revoked. @@ -97,7 +97,7 @@ The effort picker exposes Low/Medium/High/XHigh/Max on the GPT-5.6 family - **API:** requests go to the Responses API only; the backend has no Chat Completions endpoint, so `api_type` is pinned automatically. - **Request shape:** the backend requires stateless requests (`store: false`) - and a top-level `instructions` field, so docker-agent moves system messages + and a top-level `instructions` field, so Docker Agent moves system messages there. Client-side sampling parameters (`temperature`, `top_p`, `max_tokens`) are not supported by the backend and are dropped. diff --git a/docs/providers/cloudflare-ai-gateway/index.md b/docs/providers/cloudflare-ai-gateway/index.md index 175d537fd4..558d8c6e03 100644 --- a/docs/providers/cloudflare-ai-gateway/index.md +++ b/docs/providers/cloudflare-ai-gateway/index.md @@ -1,18 +1,18 @@ --- title: "Cloudflare AI Gateway" -description: "Use Cloudflare AI Gateway models with docker-agent." +description: "Use Cloudflare AI Gateway models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, cloudflare ai gateway weight: 60 canonical: https://docs.docker.com/ai/docker-agent/providers/cloudflare-ai-gateway/ --- -_Use Cloudflare AI Gateway models with docker-agent._ +_Use Cloudflare AI Gateway models with Docker Agent._ ## Overview [Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/) is a single OpenAI-compatible endpoint that routes to models from OpenAI, Anthropic, -Workers AI and more, with caching, rate limiting and observability. docker-agent +Workers AI and more, with caching, rate limiting and observability. Docker Agent includes built-in support for AI Gateway as an alias provider. The alias sends your token in the standard `Authorization: Bearer` header, so it @@ -82,7 +82,7 @@ the current provider list, model IDs, and how billing works. ## How It Works -Cloudflare AI Gateway is implemented as a built-in alias in docker-agent: +Cloudflare AI Gateway is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://gateway.ai.cloudflare.com/v1/${CLOUDFLARE_ACCOUNT_ID}/${CLOUDFLARE_GATEWAY_ID}/compat` @@ -91,13 +91,13 @@ Cloudflare AI Gateway is implemented as a built-in alias in docker-agent: The base URL is templated: `${CLOUDFLARE_ACCOUNT_ID}` and `${CLOUDFLARE_GATEWAY_ID}` are substituted from the environment when the provider is built, so both must be set in addition to `CLOUDFLARE_API_TOKEN`. Because the -gateway can route to open-weight models with strict chat templates, docker-agent +gateway can route to open-weight models with strict chat templates, Docker Agent coalesces consecutive system messages into a single leading one for this provider. ## Authentication -docker-agent authenticates by sending `CLOUDFLARE_API_TOKEN` in the standard +Docker Agent authenticates by sending `CLOUDFLARE_API_TOKEN` in the standard `Authorization: Bearer` header. On the `.../compat` endpoint that header is treated as the **provider** key, so this alias works when: diff --git a/docs/providers/cloudflare-workers-ai/index.md b/docs/providers/cloudflare-workers-ai/index.md index 181878c4f7..68477296ae 100644 --- a/docs/providers/cloudflare-workers-ai/index.md +++ b/docs/providers/cloudflare-workers-ai/index.md @@ -1,19 +1,19 @@ --- title: "Cloudflare Workers AI" -description: "Use Cloudflare Workers AI models with docker-agent." +description: "Use Cloudflare Workers AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, cloudflare workers ai weight: 70 canonical: https://docs.docker.com/ai/docker-agent/providers/cloudflare-workers-ai/ --- -_Use Cloudflare Workers AI models with docker-agent._ +_Use Cloudflare Workers AI models with Docker Agent._ ## Overview [Cloudflare Workers AI](https://developers.cloudflare.com/workers-ai/) runs open-weight models (Llama, Mistral, Qwen, Gemma, and more) on Cloudflare's global edge network through an OpenAI-compatible endpoint. No separate provider -accounts are needed for the supported models. docker-agent includes built-in +accounts are needed for the supported models. Docker Agent includes built-in support for Workers AI as an alias provider. ## Setup @@ -78,7 +78,7 @@ for the current list, IDs, and pricing. ## How It Works -Cloudflare Workers AI is implemented as a built-in alias in docker-agent: +Cloudflare Workers AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/ai/v1` @@ -87,5 +87,5 @@ Cloudflare Workers AI is implemented as a built-in alias in docker-agent: The base URL is templated: `${CLOUDFLARE_ACCOUNT_ID}` is substituted from the environment when the provider is built, so `CLOUDFLARE_ACCOUNT_ID` must be set in addition to `CLOUDFLARE_API_TOKEN`. Because Workers AI serves open-weight models -with strict chat templates, docker-agent coalesces consecutive system messages +with strict chat templates, Docker Agent coalesces consecutive system messages into a single leading one for this provider. diff --git a/docs/providers/custom/index.md b/docs/providers/custom/index.md index a56534cbd4..9dcc86bd93 100644 --- a/docs/providers/custom/index.md +++ b/docs/providers/custom/index.md @@ -156,7 +156,7 @@ Only applicable for OpenAI-compatible providers (when `provider` is `openai` or - **`openai_chatcompletions`** — Standard OpenAI Chat Completions API. Works with most OpenAI-compatible endpoints. - **`openai_responses`** — OpenAI Responses API. For newer models that require the Responses API format. -> If `api_type` is not set, docker-agent automatically selects the API type based on the model name. You only need to set `api_type` explicitly to override the detected default. +> If `api_type` is not set, Docker Agent automatically selects the API type based on the model name. You only need to set `api_type` explicitly to override the detected default. ## Examples diff --git a/docs/providers/deepseek/index.md b/docs/providers/deepseek/index.md index 212fb870d7..e62710a4f4 100644 --- a/docs/providers/deepseek/index.md +++ b/docs/providers/deepseek/index.md @@ -1,18 +1,18 @@ --- title: "DeepSeek" -description: "Use DeepSeek models with docker-agent." +description: "Use DeepSeek models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, deepseek weight: 80 canonical: https://docs.docker.com/ai/docker-agent/providers/deepseek/ --- -_Use DeepSeek models with docker-agent._ +_Use DeepSeek models with Docker Agent._ ## Overview [DeepSeek](https://www.deepseek.com/) serves its frontier chat and reasoning models through an OpenAI-compatible API, with strong price/performance on coding -and reasoning tasks. docker-agent includes built-in support for DeepSeek as an +and reasoning tasks. Docker Agent includes built-in support for DeepSeek as an alias provider. ## Setup @@ -73,7 +73,7 @@ for current model IDs, context limits, and pricing. ## How It Works -DeepSeek is implemented as a built-in alias in docker-agent: +DeepSeek is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.deepseek.com/v1` diff --git a/docs/providers/dmr/index.md b/docs/providers/dmr/index.md index ea1f34422b..65b0528bec 100644 --- a/docs/providers/dmr/index.md +++ b/docs/providers/dmr/index.md @@ -12,7 +12,7 @@ _Run AI models locally with Docker — no API keys, no costs, full data privacy. Docker Model Runner (DMR) lets you run open-source AI models directly on your machine. Models run in Docker, so there's no API key needed and no data leaves your computer. -docker-agent automatically discovers models you have already pulled from DMR. When no model is explicitly configured, auto-selection prefers a locally-installed model (choosing the model specified via the `model:` key in the agent YAML if it is already pulled locally, or otherwise the first available non-embedding model) rather than always defaulting to `ai/qwen3:latest` and triggering a pull prompt. +Docker Agent automatically discovers models you have already pulled from DMR. When no model is explicitly configured, auto-selection prefers a locally-installed model (choosing the model specified via the `model:` key in the agent YAML if it is already pulled locally, or otherwise the first available non-embedding model) rather than always defaulting to `ai/qwen3:latest` and triggering a pull prompt. > [!TIP] > **No API key needed** @@ -92,7 +92,7 @@ models: If `context_size` is omitted, Model Runner uses its default. `max_tokens` is **not** used as the context window. -docker-agent's auto-compaction scales its summary and keep-tail token budgets proportionally to `context_size`. This ensures compaction works correctly even for small context windows — for example, an 8k-token local model will not have its session history wiped during compaction. +Docker Agent's auto-compaction scales its summary and keep-tail token budgets proportionally to `context_size`. This ensures compaction works correctly even for small context windows — for example, an 8k-token local model will not have its session history wiped during compaction. ## Thinking / reasoning budget @@ -236,7 +236,7 @@ models: ## Custom Endpoint -If `base_url` is omitted, docker-agent auto-discovers the DMR endpoint. To set manually: +If `base_url` is omitted, Docker Agent auto-discovers the DMR endpoint. To set manually: ```yaml models: @@ -248,6 +248,6 @@ models: ## Troubleshooting -- **Plugin not found:** Ensure Docker Model Runner is enabled in Docker Desktop. docker-agent will fall back to the default URL. +- **Plugin not found:** Ensure Docker Model Runner is enabled in Docker Desktop. Docker Agent will fall back to the default URL. - **Endpoint empty:** Verify the Model Runner is running with `docker model status --json`. - **Performance:** Use `runtime_flags` to tune GPU layers (`--ngl`) and thread count (`--threads`). diff --git a/docs/providers/fireworks/index.md b/docs/providers/fireworks/index.md index 8ccdf36876..9644653071 100644 --- a/docs/providers/fireworks/index.md +++ b/docs/providers/fireworks/index.md @@ -1,18 +1,18 @@ --- title: "Fireworks AI" -description: "Use Fireworks AI models with docker-agent." +description: "Use Fireworks AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, fireworks ai weight: 100 canonical: https://docs.docker.com/ai/docker-agent/providers/fireworks/ --- -_Use Fireworks AI models with docker-agent._ +_Use Fireworks AI models with Docker Agent._ ## Overview [Fireworks AI](https://fireworks.ai/) is a fast inference host for open-weight models, serving Kimi K2, Llama, Qwen, DeepSeek, GLM and others through an -OpenAI-compatible API. docker-agent includes built-in support for Fireworks AI +OpenAI-compatible API. Docker Agent includes built-in support for Fireworks AI as an alias provider. ## Setup @@ -75,14 +75,14 @@ limits, and pricing. ## How It Works -Fireworks AI is implemented as a built-in alias in docker-agent: +Fireworks AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.fireworks.ai/inference/v1` - **Token Variable:** `FIREWORKS_API_KEY` Because Fireworks fronts open-weight models whose chat templates may reject more -than one leading system message, docker-agent coalesces its per-source system +than one leading system message, Docker Agent coalesces its per-source system messages into a single one for this provider. ## Example: Code Assistant diff --git a/docs/providers/github-copilot/index.md b/docs/providers/github-copilot/index.md index 9111e0a5d8..b523c85f38 100644 --- a/docs/providers/github-copilot/index.md +++ b/docs/providers/github-copilot/index.md @@ -1,19 +1,19 @@ --- title: "GitHub Copilot" -description: "Use GitHub Copilot's hosted models (GPT-4o, Claude, Gemini, and more) with docker-agent through your GitHub subscription." +description: "Use GitHub Copilot's hosted models (GPT-4o, Claude, Gemini, and more) with Docker Agent through your GitHub subscription." keywords: docker agent, ai agents, model providers, llm, github copilot weight: 110 canonical: https://docs.docker.com/ai/docker-agent/providers/github-copilot/ --- -_Use GitHub Copilot's hosted models with docker-agent through your existing GitHub subscription._ +_Use GitHub Copilot's hosted models with Docker Agent through your existing GitHub subscription._ ## Overview GitHub Copilot exposes an OpenAI-compatible Chat Completions API at -`https://api.githubcopilot.com`. docker-agent ships with built-in support for +`https://api.githubcopilot.com`. Docker Agent ships with built-in support for it as the `github-copilot` provider, so any user with a paid GitHub Copilot -subscription can reuse their entitlement from docker-agent. +subscription can reuse their entitlement from Docker Agent. ## Prerequisites @@ -70,14 +70,14 @@ for the current model list. ## `Copilot-Integration-Id` Header GitHub's Copilot API rejects requests that don't carry a -`Copilot-Integration-Id` header with a `Bad Request` error. docker-agent +`Copilot-Integration-Id` header with a `Bad Request` error. Docker Agent automatically sends `copilot-developer-cli` for the `github-copilot` provider, so PAT-based usage works out of the box. We specifically chose `copilot-developer-cli` (instead of, say, `vscode-chat`) because it is the integration id accepted by the Copilot API for **both** OAuth tokens and Personal Access Tokens. Most -docker-agent users authenticate with a PAT exported as `GITHUB_TOKEN`, +Docker Agent users authenticate with a PAT exported as `GITHUB_TOKEN`, and `vscode-chat` is rejected for those tokens. If you need to send a different integration id — for example if your @@ -102,7 +102,7 @@ works too. GitHub Copilot proxies OpenAI models behind two endpoints: the legacy `/chat/completions` and the newer `/responses`. Newer models (the `gpt-5` family, Codex variants, etc.) are only served via `/responses` and reject -`/chat/completions` with a `400 Bad Request`. docker-agent auto-selects the +`/chat/completions` with a `400 Bad Request`. Docker Agent auto-selects the right endpoint per model, so no configuration is needed in the common case. If you ever need to force one or the other, set `api_type` explicitly: @@ -135,7 +135,7 @@ models: ## How It Works -GitHub Copilot is implemented as a built-in alias in docker-agent: +GitHub Copilot is implemented as a built-in alias in Docker Agent: - **API type:** OpenAI-compatible (Chat Completions) - **Base URL:** `https://api.githubcopilot.com` @@ -143,5 +143,5 @@ GitHub Copilot is implemented as a built-in alias in docker-agent: - **Default headers:** `Copilot-Integration-Id: copilot-developer-cli` This means the same client as OpenAI is used, so every OpenAI feature -supported by docker-agent (tool calling, structured output, multimodal +supported by Docker Agent (tool calling, structured output, multimodal inputs, etc.) is available when the underlying model supports it. diff --git a/docs/providers/google/index.md b/docs/providers/google/index.md index 4f2a788139..efbb278171 100644 --- a/docs/providers/google/index.md +++ b/docs/providers/google/index.md @@ -1,16 +1,16 @@ --- title: "Google Gemini" -description: "Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with docker-agent." +description: "Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, google gemini weight: 120 canonical: https://docs.docker.com/ai/docker-agent/providers/google/ --- -_Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with docker-agent._ +_Use Gemini 2.5 Flash, Gemini 3 Pro, and other Google models with Docker Agent._ ## Setup -docker-agent reads the first credential it finds from these environment variables (see `pkg/model/provider/gemini/client.go`): +Docker Agent reads the first credential it finds from these environment variables (see `pkg/model/provider/gemini/client.go`): | Variable | Purpose | | --------------------------- | ----------------------------------------------------------------------------------- | diff --git a/docs/providers/groq/index.md b/docs/providers/groq/index.md index 110ac699aa..4c7d394558 100644 --- a/docs/providers/groq/index.md +++ b/docs/providers/groq/index.md @@ -1,17 +1,17 @@ --- title: "Groq" -description: "Use Groq fast-inference models with docker-agent." +description: "Use Groq fast-inference models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, groq weight: 130 canonical: https://docs.docker.com/ai/docker-agent/providers/groq/ --- -_Use Groq models with docker-agent._ +_Use Groq models with Docker Agent._ ## Overview [Groq](https://groq.com/) serves open-weight models on its LPU inference engine -through an OpenAI-compatible API, with a focus on very low latency. docker-agent +through an OpenAI-compatible API, with a focus on very low latency. Docker Agent includes built-in support for Groq as an alias provider. ## Setup @@ -76,7 +76,7 @@ model IDs, context limits, and rate limits. ## How It Works -Groq is implemented as a built-in alias in docker-agent: +Groq is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.groq.com/openai/v1` diff --git a/docs/providers/huggingface/index.md b/docs/providers/huggingface/index.md index be46c30771..8b5860100a 100644 --- a/docs/providers/huggingface/index.md +++ b/docs/providers/huggingface/index.md @@ -1,18 +1,18 @@ --- title: "Hugging Face" -description: "Use Hugging Face Inference Providers with docker-agent." +description: "Use Hugging Face Inference Providers with Docker Agent." keywords: docker agent, ai agents, model providers, llm, hugging face weight: 140 canonical: https://docs.docker.com/ai/docker-agent/providers/huggingface/ --- -_Use Hugging Face Inference Providers with docker-agent._ +_Use Hugging Face Inference Providers with Docker Agent._ ## Overview [Hugging Face Inference Providers](https://huggingface.co/docs/inference-providers/index) routes requests to open models (Llama, Qwen, DeepSeek, Kimi, GLM and others) -across many backends through a single OpenAI-compatible endpoint. docker-agent +across many backends through a single OpenAI-compatible endpoint. Docker Agent includes built-in support for Hugging Face as an alias provider. ## Setup @@ -74,14 +74,14 @@ for current model IDs, context limits, and pricing. ## How It Works -Hugging Face is implemented as a built-in alias in docker-agent: +Hugging Face is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://router.huggingface.co/v1` - **Token Variable:** `HF_TOKEN` Because Hugging Face fronts open-weight models whose chat templates may reject -more than one leading system message, docker-agent coalesces its per-source +more than one leading system message, Docker Agent coalesces its per-source system messages into a single one for this provider. ## Example: Code Assistant diff --git a/docs/providers/local/index.md b/docs/providers/local/index.md index 341c4672bc..a79822f0ae 100644 --- a/docs/providers/local/index.md +++ b/docs/providers/local/index.md @@ -1,6 +1,6 @@ --- title: "Local Models (Ollama, vLLM, LocalAI)" -description: "Run docker-agent with locally hosted models for privacy, offline use, or cost savings." +description: "Run Docker Agent with locally hosted models for privacy, offline use, or cost savings." keywords: docker agent, ai agents, model providers, llm, local models (ollama, vllm, localai) linkTitle: "Local Models" weight: 150 @@ -9,11 +9,11 @@ aliases: - /ai/docker-agent/local-models/ --- -_Run docker-agent with locally hosted models for privacy, offline use, or cost savings._ +_Run Docker Agent with locally hosted models for privacy, offline use, or cost savings._ ## Overview -docker-agent can connect to any OpenAI-compatible local model server. This guide covers the most popular options: +Docker Agent can connect to any OpenAI-compatible local model server. This guide covers the most popular options: - **Ollama** — Easy-to-use local model runner - **vLLM** — High-performance inference server @@ -26,7 +26,7 @@ docker-agent can connect to any OpenAI-compatible local model server. This guide ## Ollama -Ollama is a popular tool for running LLMs locally. docker-agent includes a built-in `ollama` alias for easy configuration. +Ollama is a popular tool for running LLMs locally. Docker Agent includes a built-in `ollama` alias for easy configuration. ### Setup diff --git a/docs/providers/minimax/index.md b/docs/providers/minimax/index.md index 84ebf0ce58..e6eeac606e 100644 --- a/docs/providers/minimax/index.md +++ b/docs/providers/minimax/index.md @@ -1,16 +1,16 @@ --- title: "MiniMax" -description: "Use MiniMax AI models with docker-agent." +description: "Use MiniMax AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, minimax weight: 160 canonical: https://docs.docker.com/ai/docker-agent/providers/minimax/ --- -_Use MiniMax AI models with docker-agent._ +_Use MiniMax AI models with Docker Agent._ ## Overview -MiniMax provides AI models through an OpenAI-compatible API. docker-agent includes built-in support for MiniMax as an alias provider. +MiniMax provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for MiniMax as an alias provider. ## Setup @@ -68,7 +68,7 @@ Check the [MiniMax documentation](https://www.minimaxi.com/document/introduction ## How It Works -MiniMax is implemented as a built-in alias in docker-agent: +MiniMax is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai`) - **Base URL:** `https://api.minimax.io/v1` diff --git a/docs/providers/mistral/index.md b/docs/providers/mistral/index.md index 5d2805fbcc..7e40916d53 100644 --- a/docs/providers/mistral/index.md +++ b/docs/providers/mistral/index.md @@ -1,16 +1,16 @@ --- title: "Mistral" -description: "Use Mistral AI models with docker-agent." +description: "Use Mistral AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, mistral weight: 170 canonical: https://docs.docker.com/ai/docker-agent/providers/mistral/ --- -_Use Mistral AI models with docker-agent._ +_Use Mistral AI models with Docker Agent._ ## Overview -Mistral AI provides powerful language models through an OpenAI-compatible API. docker-agent includes built-in support for Mistral as an alias provider. +Mistral AI provides powerful language models through an OpenAI-compatible API. Docker Agent includes built-in support for Mistral as an alias provider. ## Setup @@ -70,23 +70,23 @@ Check the [Mistral Models documentation](https://docs.mistral.ai/getting-started ## Auto-Detection -When you run `docker agent run` without specifying a config and no project-level `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` exists, docker-agent automatically detects available providers. If `MISTRAL_API_KEY` is set and higher-priority providers (OpenAI, Anthropic, Google) are not available, Mistral will be used with `mistral-small-latest` as the default model. +When you run `docker agent run` without specifying a config and no project-level `docker-agent.yaml`, `docker-agent.yml`, or `docker-agent.hcl` exists, Docker Agent automatically detects available providers. If `MISTRAL_API_KEY` is set and higher-priority providers (OpenAI, Anthropic, Google) are not available, Mistral will be used with `mistral-small-latest` as the default model. ## Extended Thinking -docker-agent's `thinking_budget` field is **not applied** to Mistral models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Mistral model passes config validation but has no effect on the request. +Docker Agent's `thinking_budget` field is **not applied** to Mistral models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Mistral model passes config validation but has no effect on the request. Mistral reasoning models (e.g. `magistral`) reason on their own without configuration. For non-reasoning models, use the [think tool](../../tools/think/index.md) instead. ## How It Works -Mistral is implemented as a built-in alias in docker-agent: +Mistral is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.mistral.ai/v1` - **Token Variable:** `MISTRAL_API_KEY` -This means Mistral uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by docker-agent. +This means Mistral uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by Docker Agent. ## Example: Code Assistant diff --git a/docs/providers/moonshot/index.md b/docs/providers/moonshot/index.md index f937beb2f2..f370592b49 100644 --- a/docs/providers/moonshot/index.md +++ b/docs/providers/moonshot/index.md @@ -1,18 +1,18 @@ --- title: "Moonshot AI" -description: "Use Moonshot AI (Kimi) models with docker-agent." +description: "Use Moonshot AI (Kimi) models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, moonshot ai weight: 180 canonical: https://docs.docker.com/ai/docker-agent/providers/moonshot/ --- -_Use Moonshot AI (Kimi) models with docker-agent._ +_Use Moonshot AI (Kimi) models with Docker Agent._ ## Overview [Moonshot AI](https://www.moonshot.ai/) serves its Kimi model family through an OpenAI-compatible API. The Kimi K2 models have strong momentum for coding and -agentic tasks. docker-agent includes built-in support for Moonshot AI as an +agentic tasks. Docker Agent includes built-in support for Moonshot AI as an alias provider. ## Setup @@ -74,7 +74,7 @@ model IDs, context limits, and pricing. ## How It Works -Moonshot AI is implemented as a built-in alias in docker-agent: +Moonshot AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.moonshot.ai/v1` diff --git a/docs/providers/nebius/index.md b/docs/providers/nebius/index.md index 3b062a0d11..deadbaaea4 100644 --- a/docs/providers/nebius/index.md +++ b/docs/providers/nebius/index.md @@ -1,16 +1,16 @@ --- title: "Nebius" -description: "Use Nebius AI models with docker-agent." +description: "Use Nebius AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, nebius weight: 190 canonical: https://docs.docker.com/ai/docker-agent/providers/nebius/ --- -_Use Nebius AI models with docker-agent._ +_Use Nebius AI models with Docker Agent._ ## Overview -Nebius provides AI models through an OpenAI-compatible API. docker-agent includes built-in support for Nebius as an alias provider. +Nebius provides AI models through an OpenAI-compatible API. Docker Agent includes built-in support for Nebius as an alias provider. ## Setup @@ -66,7 +66,7 @@ Nebius hosts various open models. Check the [Nebius documentation](https://nebiu ## How It Works -Nebius is implemented as a built-in alias in docker-agent: +Nebius is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.studio.nebius.com/v1` diff --git a/docs/providers/nvidia/index.md b/docs/providers/nvidia/index.md index 916b867457..330dad99f0 100644 --- a/docs/providers/nvidia/index.md +++ b/docs/providers/nvidia/index.md @@ -1,18 +1,18 @@ --- title: "NVIDIA NIM" -description: "Use NVIDIA NIM models with docker-agent." +description: "Use NVIDIA NIM models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, nvidia, nim, nemotron weight: 290 canonical: https://docs.docker.com/ai/docker-agent/providers/nvidia/ --- -_Use NVIDIA NIM models with docker-agent._ +_Use NVIDIA NIM models with Docker Agent._ ## Overview NVIDIA provides access to Nemotron and many other open-weight models through [build.nvidia.com](https://build.nvidia.com/) (with a free tier) via an -OpenAI-compatible API. docker-agent includes built-in support for NVIDIA as an +OpenAI-compatible API. Docker Agent includes built-in support for NVIDIA as an alias provider. The same alias also works against a self-hosted [NVIDIA NIM](https://docs.nvidia.com/nim/) deployment by overriding `base_url`. @@ -86,14 +86,14 @@ models: ## How It Works -NVIDIA is implemented as a built-in alias in docker-agent: +NVIDIA is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://integrate.api.nvidia.com/v1` - **Token Variable:** `NVIDIA_API_KEY` Because NIM fronts open-weight models whose chat templates often only accept -a single system message, docker-agent coalesces the agent instruction and any +a single system message, Docker Agent coalesces the agent instruction and any toolset instructions into one leading system message before sending the request. diff --git a/docs/providers/openai/index.md b/docs/providers/openai/index.md index 4e866c24de..abd11c54fb 100644 --- a/docs/providers/openai/index.md +++ b/docs/providers/openai/index.md @@ -1,12 +1,12 @@ --- title: "OpenAI" -description: "Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with docker-agent." +description: "Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, openai weight: 200 canonical: https://docs.docker.com/ai/docker-agent/providers/openai/ --- -_Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with docker-agent._ +_Use GPT-5.6, GPT-4o, GPT-5, GPT-5-mini, and other OpenAI models with Docker Agent._ ## Setup @@ -86,7 +86,7 @@ Token counts, `adaptive`, and `adaptive/` are rejected with a configurat > [!WARNING] > **Hidden reasoning tokens** > -> OpenAI reasoning models always produce hidden reasoning tokens that count against `max_tokens` — even with `thinking_budget: none` on older models. docker-agent automatically raises the output-token floor for its internal low-effort calls so reasoning cannot starve visible text output. +> OpenAI reasoning models always produce hidden reasoning tokens that count against `max_tokens` — even with `thinking_budget: none` on older models. Docker Agent automatically raises the output-token floor for its internal low-effort calls so reasoning cannot starve visible text output. See the [Thinking / Reasoning guide](../../guides/thinking/index.md) for a cross-provider overview. diff --git a/docs/providers/opencode-go/index.md b/docs/providers/opencode-go/index.md index fa6abe5de1..69199c31f5 100644 --- a/docs/providers/opencode-go/index.md +++ b/docs/providers/opencode-go/index.md @@ -1,18 +1,18 @@ --- title: "OpenCode Go" -description: "Use OpenCode Go models with docker-agent." +description: "Use OpenCode Go models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, opencode go weight: 210 canonical: https://docs.docker.com/ai/docker-agent/providers/opencode-go/ --- -_Use OpenCode Go models with docker-agent._ +_Use OpenCode Go models with Docker Agent._ ## Overview [OpenCode Go](https://opencode.ai/docs/go) is a low-cost subscription service ($5 first month, then $10/month) that provides reliable access to popular open-source coding models. It serves models through both OpenAI-compatible and Anthropic-compatible APIs from globally distributed endpoints. -docker-agent includes built-in support for OpenCode Go as an alias provider. +Docker Agent includes built-in support for OpenCode Go as an alias provider. ## Setup @@ -122,15 +122,15 @@ agents: ## How It Works -OpenCode Go is implemented as a built-in alias in docker-agent: +OpenCode Go is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://opencode.ai/zen/go/v1` - **Token Variable:** `OPENCODE_API_KEY` -This means OpenCode Go uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by docker-agent. +This means OpenCode Go uses the same client as OpenAI, making it fully compatible with all OpenAI features supported by Docker Agent. -For Anthropic-compatible models (MiniMax, Qwen), docker-agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen/go` with the same token. +For Anthropic-compatible models (MiniMax, Qwen), Docker Agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen/go` with the same token. ## Example: Code Assistant diff --git a/docs/providers/opencode-zen/index.md b/docs/providers/opencode-zen/index.md index ab997252ca..dc765cfd43 100644 --- a/docs/providers/opencode-zen/index.md +++ b/docs/providers/opencode-zen/index.md @@ -1,18 +1,18 @@ --- title: "OpenCode Zen" -description: "Use OpenCode Zen models with docker-agent." +description: "Use OpenCode Zen models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, opencode zen weight: 220 canonical: https://docs.docker.com/ai/docker-agent/providers/opencode-zen/ --- -_Use OpenCode Zen models with docker-agent._ +_Use OpenCode Zen models with Docker Agent._ ## Overview [OpenCode Zen](https://opencode.ai/docs/zen) is a curated gateway of tested and verified AI models provided by the OpenCode team. It offers pay-per-use access to a wide range of models — from GPT and Claude to open-source models — all through a single API key. Several free models are also available. -docker-agent includes built-in support for OpenCode Zen as an alias provider for OpenAI-compatible models. Anthropic and Google models are supported via custom provider definitions. +Docker Agent includes built-in support for OpenCode Zen as an alias provider for OpenAI-compatible models. Anthropic and Google models are supported via custom provider definitions. ## Setup @@ -97,7 +97,7 @@ These models use the `/v1/chat/completions` endpoint and work directly with the ### OpenAI-Compatible (Responses API) -These models use the `/v1/responses` endpoint and are auto-detected by docker-agent based on the model name: +These models use the `/v1/responses` endpoint and are auto-detected by Docker Agent based on the model name: | Model | Description | | ---------------------- | --------------------------------- | @@ -194,7 +194,7 @@ agents: ## How It Works -OpenCode Zen is implemented as a built-in alias in docker-agent: +OpenCode Zen is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (auto-detects Responses API for GPT models, Chat Completions for others) - **Base URL:** `https://opencode.ai/zen/v1` @@ -202,7 +202,7 @@ OpenCode Zen is implemented as a built-in alias in docker-agent: The same API key works for both OpenCode Go and OpenCode Zen — they are part of the same platform. Zen uses a pay-per-use billing model, while Go uses a fixed subscription. -For Anthropic-compatible models, docker-agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen` with the same token. For Google models, a custom provider points to the Google client at `https://opencode.ai/zen` (the Google SDK appends its own `/v1beta/models/...` path segment). +For Anthropic-compatible models, Docker Agent uses a custom provider pointing to the Anthropic client at `https://opencode.ai/zen` with the same token. For Google models, a custom provider points to the Google client at `https://opencode.ai/zen` (the Google SDK appends its own `/v1beta/models/...` path segment). ### Differences from OpenCode Go diff --git a/docs/providers/openrouter/index.md b/docs/providers/openrouter/index.md index 19dbca4d4a..b01d40211e 100644 --- a/docs/providers/openrouter/index.md +++ b/docs/providers/openrouter/index.md @@ -1,16 +1,16 @@ --- title: "OpenRouter" -description: "Use OpenRouter models with docker-agent." +description: "Use OpenRouter models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, openrouter weight: 230 canonical: https://docs.docker.com/ai/docker-agent/providers/openrouter/ --- -_Use OpenRouter models with docker-agent._ +_Use OpenRouter models with Docker Agent._ ## Overview -OpenRouter provides access to models from many providers through an OpenAI-compatible API. docker-agent includes built-in support for OpenRouter as an alias provider. +OpenRouter provides access to models from many providers through an OpenAI-compatible API. Docker Agent includes built-in support for OpenRouter as an alias provider. ## Setup @@ -35,7 +35,7 @@ agents: instruction: You are a helpful assistant. ``` -OpenRouter model IDs usually include the upstream provider name, such as `anthropic/claude-sonnet-4-5` or `meta-llama/llama-3.3-70b-instruct`. docker-agent splits only the first slash, so the full upstream model ID is preserved. +OpenRouter model IDs usually include the upstream provider name, such as `anthropic/claude-sonnet-4-5` or `meta-llama/llama-3.3-70b-instruct`. Docker Agent splits only the first slash, so the full upstream model ID is preserved. ### Named Model @@ -58,13 +58,13 @@ agents: ## Pricing and Model Metadata -docker-agent fetches OpenRouter model metadata from [models.dev](https://models.dev/), including pricing per 1M input/output tokens, cache pricing when available, context limits, output limits, and modalities. This powers cost tracking and the model picker in the same way as other first-class providers. +Docker Agent fetches OpenRouter model metadata from [models.dev](https://models.dev/), including pricing per 1M input/output tokens, cache pricing when available, context limits, output limits, and modalities. This powers cost tracking and the model picker in the same way as other first-class providers. -If models.dev is unavailable, docker-agent falls back to its embedded catalog snapshot. +If models.dev is unavailable, Docker Agent falls back to its embedded catalog snapshot. ## How It Works -OpenRouter is implemented as a built-in alias in docker-agent: +OpenRouter is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai`) - **Base URL:** `https://openrouter.ai/api/v1` diff --git a/docs/providers/overview/index.md b/docs/providers/overview/index.md index 53f6f60b42..03147c7787 100644 --- a/docs/providers/overview/index.md +++ b/docs/providers/overview/index.md @@ -1,6 +1,6 @@ --- title: "Model Providers" -description: "docker-agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration." +description: "Docker Agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration." keywords: docker agent, ai agents, model providers, llm linkTitle: "Overview" weight: 10 @@ -9,7 +9,7 @@ aliases: - /ai/docker-agent/model-providers/ --- -_docker-agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration._ +_Docker Agent supports multiple AI model providers. Choose the right one for your use case, or use multiple providers in the same configuration._ ## Supported Providers @@ -32,7 +32,7 @@ _docker-agent supports multiple AI model providers. Choose the right one for you ## Additional Built-in Providers -docker-agent also includes built-in aliases for these providers: +Docker Agent also includes built-in aliases for these providers: | Provider | Alias | API Key / Env Variable | | -------------- | ---------------- | ----------------------------------- | diff --git a/docs/providers/ovhcloud/index.md b/docs/providers/ovhcloud/index.md index c58cc295c3..53298c8d57 100644 --- a/docs/providers/ovhcloud/index.md +++ b/docs/providers/ovhcloud/index.md @@ -1,17 +1,17 @@ --- title: "OVHcloud" -description: "Use OVHcloud AI Endpoints models with docker-agent." +description: "Use OVHcloud AI Endpoints models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, ovhcloud weight: 240 canonical: https://docs.docker.com/ai/docker-agent/providers/ovhcloud/ --- -_Use OVHcloud AI Endpoints models with docker-agent._ +_Use OVHcloud AI Endpoints models with Docker Agent._ ## Overview [OVHcloud AI Endpoints](https://endpoints.ai.cloud.ovh.net/) serves open-weight -models through an OpenAI-compatible API, hosted in the EU. docker-agent includes +models through an OpenAI-compatible API, hosted in the EU. Docker Agent includes built-in support for OVHcloud as an alias provider. ## Setup @@ -74,20 +74,20 @@ IDs, context limits, and free-tier availability. ## How It Works -OVHcloud is implemented as a built-in alias in docker-agent: +OVHcloud is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://oai.endpoints.kepler.ai.cloud.ovh.net/v1` - **Token Variable:** `OVH_AI_ENDPOINTS_ACCESS_TOKEN` -docker-agent automatically coalesces consecutive system messages into one for +Docker Agent automatically coalesces consecutive system messages into one for OVHcloud, because some OVHcloud models return an empty stream when a request carries more than one system message. ## Free tier OVHcloud offers rate-limited free access to several models. Under heavy -rate-limiting the endpoint may return an empty response; docker-agent surfaces +rate-limiting the endpoint may return an empty response; Docker Agent surfaces this as a warning rather than failing. For sustained use, an access token with a paid plan avoids the free-tier request-rate cap. diff --git a/docs/providers/together/index.md b/docs/providers/together/index.md index 2bf83457b6..8dda710061 100644 --- a/docs/providers/together/index.md +++ b/docs/providers/together/index.md @@ -1,18 +1,18 @@ --- title: "Together AI" -description: "Use Together AI models with docker-agent." +description: "Use Together AI models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, together ai weight: 250 canonical: https://docs.docker.com/ai/docker-agent/providers/together/ --- -_Use Together AI models with docker-agent._ +_Use Together AI models with Docker Agent._ ## Overview [Together AI](https://www.together.ai/) is one of the largest hosts of open models, serving Llama, Qwen, DeepSeek, Kimi, GLM and others through an -OpenAI-compatible API. docker-agent includes built-in support for Together AI as +OpenAI-compatible API. Docker Agent includes built-in support for Together AI as an alias provider. ## Setup @@ -74,14 +74,14 @@ current model IDs, context limits, and pricing. ## How It Works -Together AI is implemented as a built-in alias in docker-agent: +Together AI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.together.xyz/v1` - **Token Variable:** `TOGETHER_API_KEY` Because Together AI fronts open-weight models whose chat templates may reject -more than one leading system message, docker-agent coalesces its per-source +more than one leading system message, Docker Agent coalesces its per-source system messages into a single one for this provider. ## Example: Code Assistant diff --git a/docs/providers/vercel/index.md b/docs/providers/vercel/index.md index 1047fa0d46..f2278690bb 100644 --- a/docs/providers/vercel/index.md +++ b/docs/providers/vercel/index.md @@ -1,19 +1,19 @@ --- title: "Vercel AI Gateway" -description: "Use Vercel AI Gateway models with docker-agent." +description: "Use Vercel AI Gateway models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, vercel ai gateway weight: 260 canonical: https://docs.docker.com/ai/docker-agent/providers/vercel/ --- -_Use Vercel AI Gateway models with docker-agent._ +_Use Vercel AI Gateway models with Docker Agent._ ## Overview [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) is a single, unified OpenAI-compatible endpoint that routes to models from OpenAI, Anthropic, Google, xAI and more at list price with no markup, plus provider routing and failover. -It lets you reach many providers with one API key. docker-agent includes +It lets you reach many providers with one API key. Docker Agent includes built-in support for Vercel AI Gateway as an alias provider. ## Setup @@ -82,14 +82,14 @@ the current model list, IDs, and pricing. ## How It Works -Vercel AI Gateway is implemented as a built-in alias in docker-agent: +Vercel AI Gateway is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://ai-gateway.vercel.sh/v1` - **Token Variable:** `AI_GATEWAY_API_KEY` Because the gateway can route to open-weight models with strict chat templates, -docker-agent coalesces consecutive system messages into a single leading one for +Docker Agent coalesces consecutive system messages into a single leading one for this provider. ## Example: Code Assistant diff --git a/docs/providers/xai/index.md b/docs/providers/xai/index.md index 0e9fa089a7..638e501882 100644 --- a/docs/providers/xai/index.md +++ b/docs/providers/xai/index.md @@ -1,16 +1,16 @@ --- title: "xAI (Grok)" -description: "Use xAI's Grok models with docker-agent." +description: "Use xAI's Grok models with Docker Agent." keywords: docker agent, ai agents, model providers, llm, xai (grok) weight: 270 canonical: https://docs.docker.com/ai/docker-agent/providers/xai/ --- -_Use xAI's Grok models with docker-agent._ +_Use xAI's Grok models with Docker Agent._ ## Overview -xAI provides the Grok family of models through an OpenAI-compatible API. docker-agent includes built-in support for xAI as an alias provider. +xAI provides the Grok family of models through an OpenAI-compatible API. Docker Agent includes built-in support for xAI as an alias provider. ## Setup @@ -69,13 +69,13 @@ Check the [xAI documentation](https://docs.x.ai/docs) for the latest available m ## Extended Thinking -docker-agent's `thinking_budget` field is **not applied** to xAI models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Grok model passes config validation but has no effect on the request. +Docker Agent's `thinking_budget` field is **not applied** to xAI models: the underlying OpenAI-compatible client only sends `reasoning_effort` for OpenAI reasoning model names (o-series, gpt-5). Setting `thinking_budget` on a Grok model passes config validation but has no effect on the request. Grok reasoning models (e.g. `grok-3-mini`) reason on their own without configuration. For non-reasoning models, use the [think tool](../../tools/think/index.md) instead. ## How It Works -xAI is implemented as a built-in alias in docker-agent: +xAI is implemented as a built-in alias in Docker Agent: - **API Type:** OpenAI-compatible (`openai_chatcompletions`) - **Base URL:** `https://api.x.ai/v1` From 3a88a2bffc7f5d4c07d6eab9297c361608420c81 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:34:01 +0200 Subject: [PATCH 08/10] =?UTF-8?q?docs(style):=20naming=20sweep=20=E2=80=94?= =?UTF-8?q?=20guides?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace prose uses of 'docker-agent' with 'Docker Agent' across docs/guides/{go-sdk,secrets,thinking,tips}. docs/guides/compaction had no prose occurrences to fix (only example/repo links). Preserved unchanged: canonical/alias URLs, docker/docker-agent repo and examples/ links, Go import paths (github.com/docker/docker-agent/pkg/...), the docker_agent_ build-tag prefix, Docker image refs (docker/docker-agent), config filenames, and literal shell/YAML string values inside code blocks (notification titles, CI step names, the get.docker-agent.dev install-script domain, and the standalone `docker-agent run --sandbox` binary invocation). --- docs/guides/go-sdk/index.md | 30 +++++++++++++------------- docs/guides/secrets/index.md | 40 +++++++++++++++++------------------ docs/guides/thinking/index.md | 22 +++++++++---------- docs/guides/tips/index.md | 10 ++++----- 4 files changed, 51 insertions(+), 51 deletions(-) diff --git a/docs/guides/go-sdk/index.md b/docs/guides/go-sdk/index.md index 11ae699894..d2651cebfe 100644 --- a/docs/guides/go-sdk/index.md +++ b/docs/guides/go-sdk/index.md @@ -1,16 +1,16 @@ --- title: "Go SDK" -description: "Use docker-agent as a Go library to embed AI agents in your applications." +description: "Use Docker Agent as a Go library to embed AI agents in your applications." keywords: docker agent, ai agents, guides, go sdk weight: 40 canonical: https://docs.docker.com/ai/docker-agent/guides/go-sdk/ --- -_Use docker-agent as a Go library to embed AI agents in your applications._ +_Use Docker Agent as a Go library to embed AI agents in your applications._ ## Overview -docker-agent can be used as a Go library, allowing you to build AI agents directly into your Go applications. This gives you full programmatic control over agent creation, tool integration, and execution. +Docker Agent can be used as a Go library, allowing you to build AI agents directly into your Go applications. This gives you full programmatic control over agent creation, tool integration, and execution. > [!NOTE] > **Import Path** @@ -40,7 +40,7 @@ docker-agent can be used as a Go library, allowing you to build AI agents direct ## Embedding TUI Components -When building custom UIs on top of docker-agent's TUI primitives, four packages define the contracts that keep the runtime and the UI in sync: +When building custom UIs on top of Docker Agent's TUI primitives, four packages define the contracts that keep the runtime and the UI in sync: - **`pkg/tui/components/toolconfirm`** — import this package for the permission-decision policy rather than copying the pattern-building logic. The `Decision` enum, `BuildPermissionPattern` helper, and rejection-reason presets are the canonical source of truth: whatever pattern is shown to the user in the confirmation dialog is exactly the pattern granted to the runtime. - **`pkg/tui/service`** — use `StaticSessionState` as a stub `SessionStateReader` when rendering individual message or tool views outside the full TUI app. It returns conservative fixed values for all nine interface methods, eliminating the need for hand-rolled stubs. @@ -49,7 +49,7 @@ When building custom UIs on top of docker-agent's TUI primitives, four packages ## Headless Embedded Chat (`pkg/embeddedchat`) -`pkg/embeddedchat` is a thin wrapper around the docker-agent runtime that lets you drive an agent from your own UI instead of running docker-agent's Bubble Tea application. It handles runtime construction, event projection, and conversation state, exposing a simple `Send` / `Confirm` / `Restart` / `Close` API. +`pkg/embeddedchat` is a thin wrapper around the Docker Agent runtime that lets you drive an agent from your own UI instead of running Docker Agent's Bubble Tea application. It handles runtime construction, event projection, and conversation state, exposing a simple `Send` / `Confirm` / `Restart` / `Close` API. ### Creating a session @@ -148,7 +148,7 @@ For advanced use (custom elicitation, raw event inspection), call `chat.Runtime( ## Optional Provider Build Tags -By default docker-agent includes all four cloud providers (OpenAI, Anthropic, Google, Amazon Bedrock). When embedding docker-agent in your own binary you can compile out unneeded providers — together with their transitive SDK dependencies — to reduce binary size. +By default Docker Agent includes all four cloud providers (OpenAI, Anthropic, Google, Amazon Bedrock). When embedding Docker Agent in your own binary you can compile out unneeded providers — together with their transitive SDK dependencies — to reduce binary size. Each provider is gated by a negative build tag prefixed `docker_agent_` to avoid collisions with your own project's tags: @@ -197,7 +197,7 @@ Pass the custom registry via `teamloader.WithToolsetRegistry(registry)` when cal ## Registering Custom Built-in Themes -When embedding docker-agent, you can contribute your own built-in themes via `styles.RegisterBuiltinThemes`. Registered themes integrate seamlessly with the existing theme picker, `/theme` command, and `settings.theme` config key — they behave exactly like docker-agent's own bundled themes. +When embedding Docker Agent, you can contribute your own built-in themes via `styles.RegisterBuiltinThemes`. Registered themes integrate seamlessly with the existing theme picker, `/theme` command, and `settings.theme` config key — they behave exactly like Docker Agent's own bundled themes. ```go import ( @@ -225,9 +225,9 @@ colors: background: "#1A0F0A" ``` -If `name:` is omitted, docker-agent uses the filename stem as the display name in the theme picker (e.g. `brand` from `themes/brand.yaml`). +If `name:` is omitted, Docker Agent uses the filename stem as the display name in the theme picker (e.g. `brand` from `themes/brand.yaml`). -To replace docker-agent's default theme entirely, ship the file as `themes/default.yaml` — it masks the bundled default while inheriting any colors you don't set. +To replace Docker Agent's default theme entirely, ship the file as `themes/default.yaml` — it masks the bundled default while inheriting any colors you don't set. **Semantics:** @@ -237,7 +237,7 @@ To replace docker-agent's default theme entirely, ship the file as `themes/defau ## MCP OAuth Token Persistence -By default, MCP OAuth tokens are stored in-memory only and are not persisted across process restarts. The CLI registers a keyring-backed store automatically at startup; when embedding docker-agent as a library you must do this yourself if you want tokens to survive restarts. +By default, MCP OAuth tokens are stored in-memory only and are not persisted across process restarts. The CLI registers a keyring-backed store automatically at startup; when embedding Docker Agent as a library you must do this yourself if you want tokens to survive restarts. Call `keyringstore.Register()` **before** any MCP toolset is initialised to enable the OS keyring-backed token store: @@ -255,7 +255,7 @@ func main() { > [!WARNING] > **Call order matters** > -> If `keyringstore.Register()` is called after the default token store has already been lazily initialised, docker-agent panics. The store is initialised when any remote MCP toolset is constructed — which happens inside `teamloader.Load()`. Always call `keyringstore.Register()` before calling `teamloader.Load()` on a config that includes remote MCP toolsets. +> If `keyringstore.Register()` is called after the default token store has already been lazily initialised, Docker Agent panics. The store is initialised when any remote MCP toolset is constructed — which happens inside `teamloader.Load()`. Always call `keyringstore.Register()` before calling `teamloader.Load()` on a config that includes remote MCP toolsets. If you do not need persistent OAuth tokens (for example, in short-lived batch jobs or tests), omit the call and tokens will be kept in-memory for the process lifetime. @@ -469,7 +469,7 @@ func createTeam(llm provider.Provider) *team.Team { ## Built-in Tools -Use docker-agent's built-in tools: +Use Docker Agent's built-in tools: ```go import ( @@ -505,7 +505,7 @@ func createAgentWithBuiltinTools(llm provider.Provider) *agent.Agent { ## HTTP Middleware / Transport Wrappers -Use `options.WithHTTPTransportWrapper` to inject HTTP middleware into the transport chain of all provider clients built by docker-agent. This is useful for request tracing, injecting custom headers, collecting metrics, or any other cross-cutting concern at the HTTP layer. +Use `options.WithHTTPTransportWrapper` to inject HTTP middleware into the transport chain of all provider clients built by Docker Agent. This is useful for request tracing, injecting custom headers, collecting metrics, or any other cross-cutting concern at the HTTP layer. ```go import ( @@ -544,11 +544,11 @@ The wrapper receives the already-instrumented transport (OpenTelemetry, SSE deco > [!WARNING] > **Vertex AI not supported** > -> Vertex AI uses an ADC-managed HTTP client that docker-agent cannot intercept. When a transport wrapper is set, docker-agent falls back to the GeminiAPI backend instead of Vertex AI — a debug message is logged. +> Vertex AI uses an ADC-managed HTTP client that Docker Agent cannot intercept. When a transport wrapper is set, Docker Agent falls back to the GeminiAPI backend instead of Vertex AI — a debug message is logged. In **gateway mode** the wrapper is called on every LLM request because gateway clients are rebuilt each call for short-lived auth tokens. In **direct mode** it is called once at client construction. Rate-limit responses (HTTP 429) are classified as non-retryable by the runtime and cause the model chain to skip to the next fallback, so wrappers that track per-request outcomes will observe these as failures rather than retried calls. -Returning `nil` from your wrapper function is not allowed; docker-agent logs a warning and keeps the original transport instead. +Returning `nil` from your wrapper function is not allowed; Docker Agent logs a warning and keeps the original transport instead. ## Using Different Providers diff --git a/docs/guides/secrets/index.md b/docs/guides/secrets/index.md index 97b7c137d5..8468471ed9 100644 --- a/docs/guides/secrets/index.md +++ b/docs/guides/secrets/index.md @@ -1,16 +1,16 @@ --- title: "Managing Secrets" -description: "How to securely provide API keys and credentials to docker-agent using environment variables, env files, Docker Compose secrets, macOS Keychain, pass, and 1Password references." +description: "How to securely provide API keys and credentials to Docker Agent using environment variables, env files, Docker Compose secrets, macOS Keychain, pass, and 1Password references." keywords: docker agent, ai agents, guides, managing secrets weight: 30 canonical: https://docs.docker.com/ai/docker-agent/guides/secrets/ --- -_How to securely provide API keys and credentials to docker-agent._ +_How to securely provide API keys and credentials to Docker Agent._ ## Overview -docker-agent needs API keys to talk to model providers (OpenAI, Anthropic, etc.) and MCP tool servers (GitHub, Slack, etc.). These keys are **never stored in config files**. Instead, docker-agent resolves them at runtime through a chain of secret providers, checked in order (see `pkg/environment/default.go`): +Docker Agent needs API keys to talk to model providers (OpenAI, Anthropic, etc.) and MCP tool servers (GitHub, Slack, etc.). These keys are **never stored in config files**. Instead, Docker Agent resolves them at runtime through a chain of secret providers, checked in order (see `pkg/environment/default.go`): | Priority | Provider | Description | | --- | --- | --- | @@ -24,13 +24,13 @@ docker-agent needs API keys to talk to model providers (OpenAI, Anthropic, etc.) The first provider that has a value wins. You can mix and match — for example, use environment variables for one key and Keychain for another. -Whatever provider returns the value, if that value looks like a [1Password secret reference](#1password-references) (it starts with `op://`), docker-agent resolves it through the `op` CLI before handing it to a model provider or tool. +Whatever provider returns the value, if that value looks like a [1Password secret reference](#1password-references) (it starts with `op://`), Docker Agent resolves it through the `op` CLI before handing it to a model provider or tool. -When docker-agent runs inside a Docker sandbox (detected via `SANDBOX_VM_ID`), a sandbox token provider is prepended to the chain so that `DOCKER_TOKEN` is read from a continuously-refreshed file instead of a stale environment variable. +When Docker Agent runs inside a Docker sandbox (detected via `SANDBOX_VM_ID`), a sandbox token provider is prepended to the chain so that `DOCKER_TOKEN` is read from a continuously-refreshed file instead of a stale environment variable. ## Environment Variables -The simplest approach. Set variables in your shell before running docker-agent: +The simplest approach. Set variables in your shell before running Docker Agent: ```bash export OPENAI_API_KEY=sk-... @@ -62,7 +62,7 @@ toolsets: ## Env Files -For convenience, you can store secrets in a `.env` file and pass it to docker-agent with `--env-from-file`: +For convenience, you can store secrets in a `.env` file and pass it to Docker Agent with `--env-from-file`: ```bash # .env @@ -98,7 +98,7 @@ The file is created with owner-only permissions (`0600`), but the values are sto ## Docker Compose Secrets -When running docker-agent in a container with Docker Compose, you can use [Compose secrets](https://docs.docker.com/compose/how-tos/use-secrets/) to inject credentials securely. Compose mounts secrets as files under `/run/secrets/`, and docker-agent reads from this location automatically. +When running Docker Agent in a container with Docker Compose, you can use [Compose secrets](https://docs.docker.com/compose/how-tos/use-secrets/) to inject credentials securely. Compose mounts secrets as files under `/run/secrets/`, and Docker Agent reads from this location automatically. ### From a file @@ -124,7 +124,7 @@ secrets: file: ./.anthropic_api_key ``` -Docker Compose mounts the file as `/run/secrets/ANTHROPIC_API_KEY`. docker-agent picks it up with no extra configuration. +Docker Compose mounts the file as `/run/secrets/ANTHROPIC_API_KEY`. Docker Agent picks it up with no extra configuration. ### From a host environment variable @@ -166,7 +166,7 @@ secrets: ## Credential Helper -docker-agent can shell out to an external credential helper you define in your user config. This is useful when your organisation already has a secrets daemon you want to reuse (HashiCorp Vault, 1Password CLI, `bitwarden-cli`, etc.). +Docker Agent can shell out to an external credential helper you define in your user config. This is useful when your organisation already has a secrets daemon you want to reuse (HashiCorp Vault, 1Password CLI, `bitwarden-cli`, etc.). Declare the helper in `~/.config/cagent/config.yaml`: @@ -181,11 +181,11 @@ The command is invoked with the variable name appended as the final argument, an ## Docker Desktop -On machines where Docker Desktop is installed, docker-agent queries Docker Desktop's backend for secrets stored against your signed-in Docker account. This is transparent — no extra configuration — and it is how signed-in Docker users get provider API keys without setting any environment variables. +On machines where Docker Desktop is installed, Docker Agent queries Docker Desktop's backend for secrets stored against your signed-in Docker account. This is transparent — no extra configuration — and it is how signed-in Docker users get provider API keys without setting any environment variables. ## `pass` Password Manager -docker-agent integrates with [`pass`](https://www.passwordstore.org/), the standard Unix password manager. Secrets are stored as GPG-encrypted files in `~/.password-store/`. +Docker Agent integrates with [`pass`](https://www.passwordstore.org/), the standard Unix password manager. Secrets are stored as GPG-encrypted files in `~/.password-store/`. ### Store a secret @@ -193,7 +193,7 @@ docker-agent integrates with [`pass`](https://www.passwordstore.org/), the stand pass insert ANTHROPIC_API_KEY ``` -The entry name must match the environment variable name that docker-agent expects. +The entry name must match the environment variable name that Docker Agent expects. ### Verify it works @@ -201,11 +201,11 @@ The entry name must match the environment variable name that docker-agent expect pass show ANTHROPIC_API_KEY ``` -Once `pass` is set up, docker-agent resolves secrets from it automatically. +Once `pass` is set up, Docker Agent resolves secrets from it automatically. ## macOS Keychain -On macOS, docker-agent can read secrets from the system Keychain. This is useful for local development — you store the key once and it's available across all your projects. +On macOS, Docker Agent can read secrets from the system Keychain. This is useful for local development — you store the key once and it's available across all your projects. ### Store a secret @@ -213,7 +213,7 @@ On macOS, docker-agent can read secrets from the system Keychain. This is useful security add-generic-password -a "$USER" -s ANTHROPIC_API_KEY -w "sk-ant-your-key-here" ``` -The `-s` (service name) must match the environment variable name that docker-agent expects. +The `-s` (service name) must match the environment variable name that Docker Agent expects. ### Verify it works @@ -227,11 +227,11 @@ security find-generic-password -s ANTHROPIC_API_KEY -w security delete-generic-password -s ANTHROPIC_API_KEY ``` -Once stored, docker-agent finds the secret automatically — no flags or config needed. +Once stored, Docker Agent finds the secret automatically — no flags or config needed. ## 1Password References -Any secret value resolved through the chain above can be a **1Password secret reference** instead of the literal secret. If the value starts with `op://`, docker-agent resolves it by invoking the [1Password CLI](https://developer.1password.com/docs/cli/) (`op read `) and uses the result. +Any secret value resolved through the chain above can be a **1Password secret reference** instead of the literal secret. If the value starts with `op://`, Docker Agent resolves it by invoking the [1Password CLI](https://developer.1password.com/docs/cli/) (`op read `) and uses the result. This works with every provider — most commonly an environment variable or env file: @@ -245,7 +245,7 @@ References follow the `op:////` format. Make sure the `op` C > [!WARNING] > **Behaviour when resolution fails** > -> If the value starts with `op://` but the `op` CLI is not installed, or the reference cannot be read (not signed in, wrong path, locked vault), docker-agent logs a warning and uses an **empty value** — it never forwards the raw `op://` reference to a model provider or tool. Resolved references (and deterministic failures) are cached for the lifetime of the run; transient failures such as a cancelled lookup are not cached, so a later attempt can retry. +> If the value starts with `op://` but the `op` CLI is not installed, or the reference cannot be read (not signed in, wrong path, locked vault), Docker Agent logs a warning and uses an **empty value** — it never forwards the raw `op://` reference to a model provider or tool. Resolved references (and deterministic failures) are cached for the lifetime of the run; transient failures such as a cancelled lookup are not cached, so a later attempt can retry. ## Choosing a Method @@ -263,7 +263,7 @@ You can combine methods. For example, store long-lived provider keys in macOS Ke ## Preventing Secret Leaks -Provider keys live in the secret store and are passed to docker-agent through the chain above — the agent itself never receives them as input. But the **content of a conversation** can still leak credentials: a user pasting a token, a tool returning a config file with embedded keys, a transcript dumped into a prompt. +Provider keys live in the secret store and are passed to Docker Agent through the chain above — the agent itself never receives them as input. But the **content of a conversation** can still leak credentials: a user pasting a token, a tool returning a config file with embedded keys, a transcript dumped into a prompt. For that defense-in-depth case, set `redact_secrets: true` on an agent. It scrubs detected secrets out of: diff --git a/docs/guides/thinking/index.md b/docs/guides/thinking/index.md index 1e43db5462..079be3b9a2 100644 --- a/docs/guides/thinking/index.md +++ b/docs/guides/thinking/index.md @@ -12,7 +12,7 @@ _Control how much a model reasons before responding. Works across OpenAI, Anthro Several modern models support an extended reasoning phase that happens before they produce visible output. During this phase the model plans, evaluates options, and works through the problem — internally, not shown in the response by default. This typically improves accuracy on complex tasks like coding, math, and multi-step planning, at the cost of higher token usage and latency. -docker-agent exposes this through a single `thinking_budget` field on any named model. The value format differs slightly by provider, but the semantics are the same: higher effort means more thorough reasoning. +Docker Agent exposes this through a single `thinking_budget` field on any named model. The value format differs slightly by provider, but the semantics are the same: higher effort means more thorough reasoning. > [!NOTE] > **Think tool vs. thinking budget** @@ -63,7 +63,7 @@ Token counts, `adaptive`, and `adaptive/` are rejected with a configurat > [!WARNING] > **Tokens and max_tokens** > -> Older OpenAI reasoning models always reason internally — even with `thinking_budget: none` there are hidden reasoning tokens that count against `max_tokens`. On gpt-5.6+ (Sol/Terra/Luna), `none` is a real API value that genuinely disables reasoning. docker-agent automatically raises the output-token floor for its internal low-effort calls (e.g. title generation) so hidden reasoning cannot starve visible text output. +> Older OpenAI reasoning models always reason internally — even with `thinking_budget: none` there are hidden reasoning tokens that count against `max_tokens`. On gpt-5.6+ (Sol/Terra/Luna), `none` is a real API value that genuinely disables reasoning. Docker Agent automatically raises the output-token floor for its internal low-effort calls (e.g. title generation) so hidden reasoning cannot starve visible text output. ## Anthropic @@ -81,7 +81,7 @@ models: thinking_budget: 16384 # tokens reserved for internal reasoning ``` -docker-agent auto-adjusts `max_tokens` when you set a thinking budget but leave `max_tokens` at its default. If you set `max_tokens` explicitly, it must be greater than `thinking_budget`. +Docker Agent auto-adjusts `max_tokens` when you set a thinking budget but leave `max_tokens` at its default. If you set `max_tokens` explicitly, it must be greater than `thinking_budget`. ### Adaptive thinking (Opus 4.6+ and Sonnet 4.6) @@ -130,7 +130,7 @@ thinking_budget: none # or 0 ### Interleaved thinking -Interleaved thinking lets the model reason between tool calls — useful for complex agentic tasks. docker-agent auto-enables it whenever a thinking budget is configured on a Claude model, so you only need to set it explicitly to turn it off: +Interleaved thinking lets the model reason between tool calls — useful for complex agentic tasks. Docker Agent auto-enables it whenever a thinking budget is configured on a Claude model, so you only need to set it explicitly to turn it off: ```yaml models: @@ -146,11 +146,11 @@ models: > [!NOTE] > **Temperature and top_p** > -> When extended thinking is enabled, Anthropic requires `temperature=1.0`. docker-agent automatically suppresses any `temperature` or `top_p` settings you have configured — they are silently ignored while thinking is active. +> When extended thinking is enabled, Anthropic requires `temperature=1.0`. Docker Agent automatically suppresses any `temperature` or `top_p` settings you have configured — they are silently ignored while thinking is active. ### Thinking display -Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default at the API level. To keep reasoning visible, docker-agent requests `summarized` thinking whenever adaptive/effort-based thinking is used without an explicit `thinking_display`. Use `thinking_display` in `provider_opts` to override: +Newer Claude models (Opus 4.7+, Fable 5) hide thinking content by default at the API level. To keep reasoning visible, Docker Agent requests `summarized` thinking whenever adaptive/effort-based thinking is used without an explicit `thinking_display`. Use `thinking_display` in `provider_opts` to override: ```yaml models: @@ -164,7 +164,7 @@ models: | Value | Behavior | | ------------ | ------------------------------------------------------------------------------------- | -| `summarized` | Thinking blocks returned with a text summary (docker-agent default for adaptive thinking). | +| `summarized` | Thinking blocks returned with a text summary (Docker Agent default for adaptive thinking). | | `display` | Full thinking blocks returned for display. | | `omitted` | Thinking blocks hidden — only the signature is returned. | @@ -254,7 +254,7 @@ models: # interleaved_thinking is auto-enabled when thinking_budget is set ``` -**Claude Opus 4.6+ on Bedrock requires adaptive thinking** — these models reject `thinking.type=enabled` (token budgets). Configure them with `adaptive` or `adaptive/`; docker-agent auto-coerces token budgets and effort levels on these models with a warning: +**Claude Opus 4.6+ on Bedrock requires adaptive thinking** — these models reject `thinking.type=enabled` (token budgets). Configure them with `adaptive` or `adaptive/`; Docker Agent auto-coerces token budgets and effort levels on these models with a warning: ```yaml models: @@ -269,7 +269,7 @@ models: > [!WARNING] > **Bedrock thinking requirements** > -> Bedrock Claude requires token-based `thinking_budget` values to be ≥ 1024 and less than `max_tokens`. docker-agent logs a warning and ignores the budget if either condition is violated. Interleaved thinking requires the `interleaved-thinking-2025-05-14` beta header, which docker-agent adds automatically; it is auto-enabled whenever a token thinking budget is set on a Bedrock-hosted Claude model (adaptive thinking interleaves on its own). +> Bedrock Claude requires token-based `thinking_budget` values to be ≥ 1024 and less than `max_tokens`. Docker Agent logs a warning and ignores the budget if either condition is violated. Interleaved thinking requires the `interleaved-thinking-2025-05-14` beta header, which Docker Agent adds automatically; it is auto-enabled whenever a token thinking budget is set on a Bedrock-hosted Claude model (adaptive thinking interleaves on its own). ## Docker Model Runner (local models) @@ -291,7 +291,7 @@ See the [Docker Model Runner provider page](../../providers/dmr/index.md) for de ## xAI (Grok) and Mistral -xAI and Mistral run through docker-agent's OpenAI-compatible client, but the `reasoning_effort` parameter is only sent for OpenAI reasoning model names (o-series, gpt-5). **Setting `thinking_budget` on Grok or Mistral models currently has no effect** — the value is accepted by config validation but never sent to the API. +xAI and Mistral run through Docker Agent's OpenAI-compatible client, but the `reasoning_effort` parameter is only sent for OpenAI reasoning model names (o-series, gpt-5). **Setting `thinking_budget` on Grok or Mistral models currently has no effect** — the value is accepted by config validation but never sent to the API. Grok and Mistral reasoning models (e.g. `grok-3-mini`, `magistral`) manage reasoning on their own; for non-reasoning models, consider the [think tool](../../tools/think/index.md) instead. @@ -312,7 +312,7 @@ models: thinking_budget: 0 ``` -`none` and `0` clear docker-agent's thinking configuration — no thinking parameter is sent. Models that always reason (OpenAI o-series, gpt-5 through gpt-5.5, Gemini 3) then fall back to the API's default behavior and still reason internally; gpt-5.6+ (Sol/Terra/Luna) sends `none` as a real API value that genuinely disables reasoning. Models with optional thinking (Gemini 2.5, Claude, local models) are also fully disabled. +`none` and `0` clear Docker Agent's thinking configuration — no thinking parameter is sent. Models that always reason (OpenAI o-series, gpt-5 through gpt-5.5, Gemini 3) then fall back to the API's default behavior and still reason internally; gpt-5.6+ (Sol/Terra/Luna) sends `none` as a real API value that genuinely disables reasoning. Models with optional thinking (Gemini 2.5, Claude, local models) are also fully disabled. ## Choosing an Effort Level diff --git a/docs/guides/tips/index.md b/docs/guides/tips/index.md index 35e20806af..bde25ee34a 100644 --- a/docs/guides/tips/index.md +++ b/docs/guides/tips/index.md @@ -14,7 +14,7 @@ _Expert guidance for building effective, efficient, and secure agents._ ### Auto Mode for Quick Start -Don't have a config file? docker-agent can automatically detect your available API keys and use an appropriate model: +Don't have a config file? Docker Agent can automatically detect your available API keys and use an appropriate model: ```bash # Automatically uses the best available provider @@ -56,7 +56,7 @@ agents: ### Model Aliases Are Auto-Pinned -docker-agent automatically resolves model aliases to their latest pinned versions. This ensures reproducible behavior: +Docker Agent automatically resolves model aliases to their latest pinned versions. This ensures reproducible behavior: ```yaml # You write: @@ -402,7 +402,7 @@ On Linux, replace `osascript` with `notify-send`: command: notify-send "docker-agent" "Agent needs your input" ``` -Hooks inherit docker-agent's environment, so this works as-is from a desktop terminal. In detached contexts (SSH, tmux started outside your desktop session, containers), `notify-send` needs the session's `DISPLAY` and `DBUS_SESSION_BUS_ADDRESS` to reach the notification daemon, and fails silently without them. Pass them with the per-hook `env` option: +Hooks inherit Docker Agent's environment, so this works as-is from a desktop terminal. In detached contexts (SSH, tmux started outside your desktop session, containers), `notify-send` needs the session's `DISPLAY` and `DBUS_SESSION_BUS_ADDRESS` to reach the notification daemon, and fails silently without them. Pass them with the per-hook `env` option: ```yaml on_user_input: @@ -426,13 +426,13 @@ settings: osascript -e "display notification \"$MESSAGE\" with title \"docker-agent\"" ``` -If a sound is enough, set `settings: { sound: true }` instead — docker-agent plays a failure sound when a task errors, and a success sound when a task that ran longer than `sound_threshold` seconds (default 10) completes. +If a sound is enough, set `settings: { sound: true }` instead — Docker Agent plays a failure sound when a task errors, and a success sound when a task that ran longer than `sound_threshold` seconds (default 10) completes. See the [Hooks documentation](../../configuration/hooks/index.md) for the full list of events, their payloads, and per-hook options (`env`, `working_dir`, `timeout`). ### GitHub PR Reviewer Example -Use docker-agent as a GitHub Actions PR reviewer: +Use Docker Agent as a GitHub Actions PR reviewer: ```yaml # .github/workflows/pr-review.yml From 64bd45a3f6520b70a4aef6ccc9a0d0ba49cc868a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 21:35:30 +0200 Subject: [PATCH 09/10] =?UTF-8?q?docs(style):=20naming=20sweep=20=E2=80=94?= =?UTF-8?q?=20community?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace prose/front-matter uses of 'docker-agent' with 'Docker Agent' across docs/community/{contributing,opentelemetry,telemetry,troubleshooting}. Preserved unchanged: canonical URLs, docker/docker-agent repo/examples links, the docker-agent binary and repo directory name, and CLI anchor links (#docker-agent-doctor). --- docs/community/contributing/index.md | 10 +++++----- docs/community/opentelemetry/index.md | 12 ++++++------ docs/community/telemetry/index.md | 6 +++--- docs/community/troubleshooting/index.md | 20 ++++++++++---------- 4 files changed, 24 insertions(+), 24 deletions(-) diff --git a/docs/community/contributing/index.md b/docs/community/contributing/index.md index b5cf7d2b34..302997a137 100644 --- a/docs/community/contributing/index.md +++ b/docs/community/contributing/index.md @@ -1,12 +1,12 @@ --- title: "Contributing" -description: "docker-agent is open source. Here's how to set up your development environment and contribute." +description: "Docker Agent is open source. Here's how to set up your development environment and contribute." keywords: docker agent, ai agents, community, contributing weight: 10 canonical: https://docs.docker.com/ai/docker-agent/community/contributing/ --- -_docker-agent is open source. Here's how to set up your development environment and contribute._ +_Docker Agent is open source. Here's how to set up your development environment and contribute._ ## Development Setup @@ -52,14 +52,14 @@ export ANTHROPIC_API_KEY=your_key_here ## Dogfooding -Use docker-agent to work on docker-agent! The project includes a specialized developer agent: +Use Docker Agent to work on Docker Agent! The project includes a specialized developer agent: ```bash cd docker-agent docker agent run ./golang_developer.yaml ``` -This agent is an expert Go developer that understands the docker-agent codebase. Ask it questions, request fixes, or have it implement features. +This agent is an expert Go developer that understands the Docker Agent codebase. Ask it questions, request fixes, or have it implement features. ## Core Concepts @@ -121,7 +121,7 @@ Find us on [Slack](https://dockercommunity.slack.com/archives/C09DASHHRU4) for q ## Code of Conduct -We want to keep the docker-agent community welcoming, inclusive, and collaborative. Key guidelines: +We want to keep the Docker Agent community welcoming, inclusive, and collaborative. Key guidelines: - **Be nice** — Be courteous, respectful, and polite. No abuse of any kind will be tolerated. - **Encourage diversity** — Make everyone feel welcome regardless of background. diff --git a/docs/community/opentelemetry/index.md b/docs/community/opentelemetry/index.md index 69979b7740..ae6b3c9a13 100644 --- a/docs/community/opentelemetry/index.md +++ b/docs/community/opentelemetry/index.md @@ -1,14 +1,14 @@ --- title: "OpenTelemetry Tracing" -description: "Export docker-agent traces to any OTLP backend, including Langfuse and LangSmith, for debugging agentic workflows." +description: "Export Docker Agent traces to any OTLP backend, including Langfuse and LangSmith, for debugging agentic workflows." keywords: docker agent, ai agents, community, opentelemetry tracing weight: 40 canonical: https://docs.docker.com/ai/docker-agent/community/opentelemetry/ --- -_docker-agent can export OpenTelemetry traces of an agent run to any OTLP/HTTP backend. This is separate from [product-analytics telemetry](../telemetry/index.md) and is opt-in via the `--otel` flag._ +_Docker Agent can export OpenTelemetry traces of an agent run to any OTLP/HTTP backend. This is separate from [product-analytics telemetry](../telemetry/index.md) and is opt-in via the `--otel` flag._ -When enabled, docker-agent emits OpenTelemetry GenAI (`gen_ai.*`) and MCP (`mcp.*`) spans following the [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/). Spans cover the agent turn, model calls (with token usage and cost attributes), tool calls, MCP client/server activity, sub-agent hand-offs, and provider fallbacks. W3C `traceparent` context is propagated so the whole run renders as a single connected trace tree. +When enabled, Docker Agent emits OpenTelemetry GenAI (`gen_ai.*`) and MCP (`mcp.*`) spans following the [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/). Spans cover the agent turn, model calls (with token usage and cost attributes), tool calls, MCP client/server activity, sub-agent hand-offs, and provider fallbacks. W3C `traceparent` context is propagated so the whole run renders as a single connected trace tree. ## Enabling @@ -20,7 +20,7 @@ Without an exporter endpoint configured, spans are recorded locally as no-ops. T ## Configuration -docker-agent reads the standard OTLP environment variables: +Docker Agent reads the standard OTLP environment variables: | Variable | Purpose | | --- | --- | @@ -32,7 +32,7 @@ docker-agent reads the standard OTLP environment variables: > [!NOTE] > **Base endpoint, not the full signal URL** > -> Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the **base** endpoint (for example `https://cloud.langfuse.com/api/public/otel`). docker-agent appends `/v1/traces` for you, matching the value documented by Langfuse and LangSmith. A bare `host:port` is also accepted and gets `https://` (or `http://` for localhost). +> Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the **base** endpoint (for example `https://cloud.langfuse.com/api/public/otel`). Docker Agent appends `/v1/traces` for you, matching the value documented by Langfuse and LangSmith. A bare `host:port` is also accepted and gets `https://` (or `http://` for localhost). > [!WARNING] > **Message content can contain sensitive data** @@ -88,7 +88,7 @@ docker agent run agent.yaml --otel > [!NOTE] > **Langfuse and LangSmith ingest traces only** > -> Both backends accept the traces signal only. docker-agent also wires metric and log exporters at the same endpoint, so their periodic exports return `404` against trace-only backends. This is harmless to traces but appears in the debug log. Point a full OTLP collector at the endpoint if you also want metrics and logs. +> Both backends accept the traces signal only. Docker Agent also wires metric and log exporters at the same endpoint, so their periodic exports return `404` against trace-only backends. This is harmless to traces but appears in the debug log. Point a full OTLP collector at the endpoint if you also want metrics and logs. ## Inspecting traces locally diff --git a/docs/community/telemetry/index.md b/docs/community/telemetry/index.md index 3f738fa62b..54974db155 100644 --- a/docs/community/telemetry/index.md +++ b/docs/community/telemetry/index.md @@ -1,14 +1,14 @@ --- title: "Telemetry" -description: "docker-agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time." +description: "Docker Agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time." keywords: docker agent, ai agents, community, telemetry weight: 30 canonical: https://docs.docker.com/ai/docker-agent/community/telemetry/ --- -_docker-agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time._ +_Docker Agent collects anonymous usage data to help improve the tool. Telemetry can be disabled at any time._ -On first startup, docker-agent displays a notice about telemetry collection so you're always informed. All events are processed synchronously when recorded. +On first startup, Docker Agent displays a notice about telemetry collection so you're always informed. All events are processed synchronously when recorded. ## Disabling Telemetry diff --git a/docs/community/troubleshooting/index.md b/docs/community/troubleshooting/index.md index 51ae191f41..f6daa2b37a 100644 --- a/docs/community/troubleshooting/index.md +++ b/docs/community/troubleshooting/index.md @@ -1,12 +1,12 @@ --- title: "Troubleshooting" -description: "Common issues and how to resolve them when working with docker-agent." +description: "Common issues and how to resolve them when working with Docker Agent." keywords: docker agent, ai agents, community, troubleshooting weight: 20 canonical: https://docs.docker.com/ai/docker-agent/community/troubleshooting/ --- -_Common issues and how to resolve them when working with docker-agent._ +_Common issues and how to resolve them when working with Docker Agent._ ## Common Errors @@ -29,7 +29,7 @@ The agent hit its `max_iterations` limit without completing the task. ### Model Fallback Triggered -When the primary model fails, docker-agent automatically switches to fallback models. Look for log messages like `"Switching to fallback model"`. +When the primary model fails, Docker Agent automatically switches to fallback models. Look for log messages like `"Switching to fallback model"`. - **429 errors:** Rate limited — the cooldown period keeps using the fallback - **5xx errors:** Server issues — retries with exponential backoff first, then falls back @@ -49,7 +49,7 @@ agents: ## Missing credentials or model errors -When docker-agent can't find a usable model at startup, it fails fast with an actionable error. The message names the exact next step. `docker agent doctor` is the fastest way to see the full picture — which providers have credentials, whether Docker Model Runner is reachable, and which model `auto` would pick. +When Docker Agent can't find a usable model at startup, it fails fast with an actionable error. The message names the exact next step. `docker agent doctor` is the fastest way to see the full picture — which providers have credentials, whether Docker Model Runner is reachable, and which model `auto` would pick. ### Required environment variables not set @@ -109,7 +109,7 @@ If instead you see `cannot query Docker Model Runner at `, Docker Model Run ## Debug Mode -The first step for any issue is enabling debug logging. This provides detailed information about what docker-agent is doing internally. +The first step for any issue is enabling debug logging. This provides detailed information about what Docker Agent is doing internally. ```bash # Enable debug logging (writes to ~/.cagent/cagent.debug.log) @@ -168,7 +168,7 @@ If the agent hangs or times out, check that you can reach the provider's API end - Ensure the MCP tool command is installed and on your `PATH` - Check file permissions — tools need to be executable -- Test MCP tools independently before integrating with docker-agent +- Test MCP tools independently before integrating with Docker Agent - For Docker-based MCP tools (`ref: docker:*`), ensure Docker Desktop is running ### Filesystem / shell tool errors @@ -184,7 +184,7 @@ MCP and LSP toolsets are managed by a supervisor that auto-restarts them when th - `/tools` — the unified tools dialog. Its top section lists every toolset with its current state (`Stopped`, `Starting`, `Ready`, `Degraded`, `Restarting`, `Failed`), restart count, and last error; the bottom section lists every tool the agent can call. Start here whenever a tool seems missing or stuck. - `/toolset-restart ` — force a supervisor-driven reconnect of the named toolset. Useful after completing OAuth, when a remote MCP server has been redeployed, or when a language server like `gopls` is unresponsive. -Remote MCP servers that return `401 invalid_token` (e.g. because the stored OAuth token was revoked or rotated) are now self-healing: docker-agent silently exchanges the refresh token for a new one when possible, or surfaces an OAuth re-authentication prompt on your next message when refresh is not possible. No more stuck toolsets that require a process restart — but if you want to trigger re-auth immediately, `/toolset-restart ` forces it right away. +Remote MCP servers that return `401 invalid_token` (e.g. because the stored OAuth token was revoked or rotated) are now self-healing: Docker Agent silently exchanges the refresh token for a new one when possible, or surfaces an OAuth re-authentication prompt on your next message when refresh is not possible. No more stuck toolsets that require a process restart — but if you want to trigger re-auth immediately, `/toolset-restart ` forces it right away. MCP tools using stdio transport must complete the initialization handshake before becoming available. If tools fail silently: @@ -196,7 +196,7 @@ MCP tools using stdio transport must complete the initialization handshake befor > [!NOTE] > **Startup tool-listing timeout** > -> At startup, docker-agent queries each toolset for its tool list. If a toolset does not respond within 10 seconds (e.g. a wedged MCP stdio server that never answers `tools/list`), that toolset is skipped with a warning and the remaining toolsets load normally. The sidebar resolves showing whichever tools did load — no infinite spinner. Enable `--debug` to see the warning message, and use `/toolset-restart ` once the server becomes responsive. +> At startup, Docker Agent queries each toolset for its tool list. If a toolset does not respond within 10 seconds (e.g. a wedged MCP stdio server that never answers `tools/list`), that toolset is skipped with a warning and the remaining toolsets load normally. The sidebar resolves showing whichever tools did load — no infinite spinner. Enable `--debug` to see the warning message, and use `/toolset-restart ` once the server becomes responsive. If a toolset keeps crashing in a tight loop, tune the [`lifecycle`](../../configuration/tools/index.md#toolset-lifecycle) block on the toolset (e.g. raise `backoff.initial`, lower `max_restarts`, or switch to the `best-effort` profile) so a flaky dependency does not amplify into a restart storm. @@ -204,7 +204,7 @@ If a toolset keeps crashing in a tight loop, tune the [`lifecycle`](../../config ### YAML syntax issues -docker-agent validates config at startup and reports errors with line numbers. Common problems: +Docker Agent validates config at startup and reports errors with line numbers. Common problems: - Incorrect indentation (YAML is whitespace-sensitive) - Missing quotes around values containing special characters (`:`, `#`, `{`, `}`) @@ -231,7 +231,7 @@ docker-agent validates config at startup and reports errors with line numbers. C ### Port conflicts -When running docker-agent as an API server or MCP server, ensure the port is not already in use: +When running Docker Agent as an API server or MCP server, ensure the port is not already in use: ```bash # Check if port 8080 is in use From 484dbfec54fce47d5b8b66caa72d754ed85948e7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arnaud=20He=CC=81ritier?= Date: Thu, 16 Jul 2026 22:13:58 +0200 Subject: [PATCH 10/10] docs(style): fix binary-name false positive and complete prose naming sweep Revert docker-agent binary reference in mcp-catalog (executable, not product name) and convert remaining product-name prose occurrences in tools, cli, and secrets guides to Docker Agent. --- docs/configuration/tools/index.md | 8 ++++---- docs/features/cli/index.md | 2 +- docs/guides/secrets/index.md | 6 +++--- docs/tools/mcp-catalog/index.md | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/configuration/tools/index.md b/docs/configuration/tools/index.md index 7258b1b9cb..6ffc6b8402 100644 --- a/docs/configuration/tools/index.md +++ b/docs/configuration/tools/index.md @@ -138,12 +138,12 @@ toolsets: ## Auto-Installing Tools -When configuring MCP or LSP tools that require a binary command, docker agent can **automatically download and install** the command if it's not already available on your system. This uses the [aqua registry](https://github.com/aquaproj/aqua-registry) — a curated index of CLI tool packages. +When configuring MCP or LSP tools that require a binary command, Docker Agent can **automatically download and install** the command if it's not already available on your system. This uses the [aqua registry](https://github.com/aquaproj/aqua-registry) — a curated index of CLI tool packages. ### How It Works -1. When a toolset with a `command` is loaded, docker agent checks if the command is available in your `PATH` -2. If not found, it checks the docker agent tools directory (`~/.cagent/tools/bin/`) +1. When a toolset with a `command` is loaded, Docker Agent checks if the command is available in your `PATH` +2. If not found, it checks the Docker Agent tools directory (`~/.cagent/tools/bin/`) 3. If still not found, it looks up the command in the aqua registry and installs it automatically ### Explicit Package Reference @@ -166,7 +166,7 @@ The format is `owner/repo` or `owner/repo@version`. When a version is omitted, t ### Automatic Detection -If the `version` property is not set, docker agent tries to auto-detect the package from the command name by searching the aqua registry: +If the `version` property is not set, Docker Agent tries to auto-detect the package from the command name by searching the aqua registry: ```yaml toolsets: diff --git a/docs/features/cli/index.md b/docs/features/cli/index.md index 9e0227968e..bdf9a2503c 100644 --- a/docs/features/cli/index.md +++ b/docs/features/cli/index.md @@ -219,7 +219,7 @@ $ docker agent toolsets --format json | jq # machine-readable (type, ### `docker agent setup` -Set up a model interactively. Three paths: pick a cloud provider, paste its API key, and choose where to store it (macOS Keychain, `pass`, or the docker agent env file `~/.config/cagent/.env`); check Docker Model Runner and pull a local model (no API key needed); or register a custom OpenAI-compatible provider (endpoint URL, API format, and API key variable) saved to your [user configuration](../../providers/custom/index.md#global-providers-user-configuration) so its models work everywhere via `--model /`. Ends with the exact command to start chatting. Secret values are never printed. +Set up a model interactively. Three paths: pick a cloud provider, paste its API key, and choose where to store it (macOS Keychain, `pass`, or the Docker Agent env file `~/.config/cagent/.env`); check Docker Model Runner and pull a local model (no API key needed); or register a custom OpenAI-compatible provider (endpoint URL, API format, and API key variable) saved to your [user configuration](../../providers/custom/index.md#global-providers-user-configuration) so its models work everywhere via `--model /`. Ends with the exact command to start chatting. Secret values are never printed. The wizard is also offered automatically when an interactive run finds no usable model (decline-able; set `DOCKER_AGENT_NO_SETUP=1` to suppress the offer). diff --git a/docs/guides/secrets/index.md b/docs/guides/secrets/index.md index 8468471ed9..38c4d56527 100644 --- a/docs/guides/secrets/index.md +++ b/docs/guides/secrets/index.md @@ -16,7 +16,7 @@ Docker Agent needs API keys to talk to model providers (OpenAI, Anthropic, etc.) | --- | --- | --- | | 1 | [Environment variables](#environment-variables) | `export OPENAI_API_KEY=sk-...` | | 2 | [Docker Compose secrets](#docker-compose-secrets) | Files in `/run/secrets/` | -| 3 | [docker agent env file](#docker-agent-env-file) | `~/.config/cagent/.env`, written by `docker agent setup` | +| 3 | [Docker Agent env file](#docker-agent-env-file) | `~/.config/cagent/.env`, written by `docker agent setup` | | 4 | [Credential helper](#credential-helper) | Custom command declared in `~/.config/cagent/config.yaml` under `credential_helper:` | | 5 | [Docker Desktop](#docker-desktop) | Secrets stored by the Docker Desktop backend (no setup on a Desktop install) | | 6 | [`pass` password manager](#pass-password-manager) | `pass insert OPENAI_API_KEY` | @@ -85,7 +85,7 @@ The file format supports: > [!IMPORTANT] > Add `.env` to your `.gitignore` to avoid committing secrets to version control. -## docker agent env file +## Docker Agent env file A `.env` file (same format as above) at `~/.config/cagent/.env` is read automatically on every run — no `--env-from-file` flag needed. It is where [`docker agent setup`](../../features/cli/index.md#docker-agent-setup) stores API keys when you choose the env-file location, and you can edit it by hand: @@ -253,7 +253,7 @@ References follow the `op:////` format. Make sure the `op` C | --- | --- | --- | | Environment variables | Quick local development, scripts | Low | | Env files | Team projects, multiple keys | Low | -| docker agent env file | Keys used across all projects, written by `docker agent setup` | Low | +| Docker Agent env file | Keys used across all projects, written by `docker agent setup` | Low | | Docker Compose secrets | Containerized deployments, CI/CD | Medium | | `pass` | Linux/macOS, GPG-based workflows | Medium | | macOS Keychain | macOS local development | Low | diff --git a/docs/tools/mcp-catalog/index.md b/docs/tools/mcp-catalog/index.md index 4bf58a9a6b..d395a3ef6d 100644 --- a/docs/tools/mcp-catalog/index.md +++ b/docs/tools/mcp-catalog/index.md @@ -27,7 +27,7 @@ toolsets: - type: mcp_catalog ``` -The catalog is embedded in the Docker Agent binary and refreshed with each release. By default every server in the embedded subset is offered. +The catalog is embedded in the `docker-agent` binary and refreshed with each release. By default every server in the embedded subset is offered. ### Restricting the offered servers