mirror of
https://github.com/coder/coder.git
synced 2026-10-31 02:43:21 +08:00
docs: document org-scoped admin configuration for agents (#28482)
## Summary Documents the organization scoping of Coder Agents admin configuration, and corrects the navigation paths, access wording, and default-model instructions that no longer matched the product. Documentation only, no product code changes. Follows #28473, which moved the organization model overrides into an **Organization settings** section on **Admin settings > AI > Coder Agents**. #28473 is merged, so this targets `main`. Closes CODAGT-715 ## Changes - **New page** `docs/ai-coder/agents/platform-controls/organizations.md`, registered in `docs/manifest.json`. Covers the deployment/organization scope split, what an upgrade changes, how an organization without models or MCP servers behaves, who configures each scope, and how model and MCP server sharing works. - **`models.md`**: models are organization-scoped while providers and their credentials stay deployment-wide. Each organization has one default model, and the first model added becomes it. Documents the **Default** badge and the **Set as Coder Agents default model** form option in place of the star action that no longer exists, and points model overrides at **Organization settings**. - **`getting-started.md`**: replaces the Owner-only claim with the actual access model, adds an organization selection step, and uses the **Add model** label. - **`platform-controls/index.md`**: separates deployment-wide controls from organization-scoped controls, documents personal model overrides alongside the model configuration section rather than as an enforcement caveat, and adds `--agents-allowed` plus the `agents-allowed:` search filter. - **`platform-controls/advisor.md`** and **`platform-controls/virtual-desktop.md`**: the Advisor and Virtual desktop settings are cards in the **Deployment settings** section of the **Coder Agents** page, not sidebar entries. **Providers** is a sidebar item, not a tab. - **`platform-controls/mcp-servers.md`**: slug uniqueness is per organization, the **Add server** label is correct, and the page is no longer described as admin-only. - **`architecture.md`**, **`index.md`**, **`tasks-to-chats-migration.md`**: organization scope corrections and organization-scoped model routes. - Breadcrumbs standardized to **Admin settings > AI > ...**, verified against `AdminSettings.tsx` and `AISettingsSidebarView.tsx`. <details> <summary>Review follow-ups</summary> The first revision leaked implementation detail into user-facing pages and contained several claims that did not match the UI. The follow-up commit removed and corrected the following. Removed as implementation detail: - The `chat_model_config` RBAC resource, its actions, and the token scopes. - The `available`, `unavailable_reason`, and `unsupported_providers` response fields, along with the `missing_api_key`, `fetch_failed`, and `user_api_key_required` values. - Role and permission tables, ACL storage mechanics, audit internals, and JSON error bodies on the new organizations page. - Migration mechanics with no effect on what a user does. Corrected against the product: - The star action does not exist. The list shows a **Default** badge and the add/edit form offers **Set as Coder Agents default model** (`ModelRow.tsx`, `ModelFormFields.tsx`). - The first model added to an organization becomes its default automatically (`coderd/exp_chats.go`). An organization without a stored default does not fail every chat, so that claim is gone. - Advisor and Virtual desktop are cards under **Deployment settings** (`CoderAgentsPageView.tsx`). - The MCP servers page does not require deployment configuration edit permission (`AISettingsSidebarView.tsx`). - Button labels: **Add model** and **Add server**. - The organization query parameter is `org`, confirmed by `modelOrganizationSearchParam`. Left alone deliberately: pre-existing defects outside the introduced text, including the `/api/v2/chats` route prefixes, create-chat examples missing `organization_id`, and the pre-existing MCP permissions table. </details> ## Testing - `pnpm run format-docs` and `pnpm run lint-docs` pass. - `make lint/emdash` passes. No emdash or endash added. - `grep -rn "Defaults & overrides" docs/` returns nothing. - Every navigation path, button label, and access claim checked against the corresponding file under `site/src/pages/AISettingsPage/` and `site/src/modules/management/`. --- This pull request was generated by Coder Agents on behalf of @ethanndickson.
This commit is contained in:
Ethan
@@ -290,12 +290,12 @@ plane, not from the workspace's network.
|
||||
|
||||
### Centralized enforcement
|
||||
|
||||
Administrators control which models are available, the system prompt, and tool
|
||||
configuration from the control plane. Developers can select from the set of
|
||||
admin-enabled models when starting or continuing a chat, but cannot add their
|
||||
own providers or override system prompts or tool permissions. When an
|
||||
administrator removes a model or modifies the system prompt, the change applies
|
||||
to all agent sessions immediately.
|
||||
Administrators control which models are available, the system prompt, and tool configuration from the control plane.
|
||||
The system prompt and the tool configuration are deployment-wide.
|
||||
The model list belongs to an organization, so a chat can only use the models of its own organization.
|
||||
Developers can select from the set of admin-enabled models when starting or continuing a chat, but cannot add their own providers or override system prompts or tool permissions.
|
||||
When an administrator removes a model or modifies the system prompt, the change applies to all affected agent sessions immediately.
|
||||
Refer to [Organization scope](./platform-controls/organizations.md) for the settings that belong to each scope.
|
||||
|
||||
### User identity on every action
|
||||
|
||||
|
||||
@@ -17,6 +17,9 @@ Before you begin, confirm the following:
|
||||
[descriptive name and description](./platform-controls/template-optimization.md)
|
||||
for the agent to select when provisioning workspaces.
|
||||
- **Admin access** to the Coder deployment for configuring providers.
|
||||
- **Access to configure models** in each organization where you configure models.
|
||||
The **Organization Admin** role and the **Owner** role include this access.
|
||||
A custom role with model configuration access also works.
|
||||
- **Coder Agents User role** assigned to each user who needs to interact with Coder Agents.
|
||||
This role is granted **per organization**. Owners and organization admins can
|
||||
assign it from **Admin settings** > **Organizations** > _[your organization]_ >
|
||||
@@ -26,9 +29,12 @@ Before you begin, confirm the following:
|
||||
## Step 1: Configure an LLM provider and model
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Configuring providers, models, and system prompts requires the
|
||||
> **Owner** role (Coder administrator). Non-admin users cannot access the
|
||||
> admin Settings panel or modify deployment-level Agents configuration.
|
||||
> Deployment administrators configure providers and deployment settings.
|
||||
> Users with model configuration access in an organization configure that organization's models.
|
||||
> Coder enables the edit controls for the organization that you select.
|
||||
> Coder shows the deployment settings only to deployment administrators.
|
||||
> Users with model access can view the relevant Models and Coder Agents pages.
|
||||
> Users with MCP server access can open the MCP servers page.
|
||||
|
||||
To configure Coder Agents:
|
||||
|
||||
@@ -36,9 +42,16 @@ To configure Coder Agents:
|
||||
1. Add or update a provider with its credentials and upstream endpoint, then
|
||||
save it.
|
||||
1. Navigate to **Admin settings** > **AI** > **Models**.
|
||||
1. Click **Add** and configure at least one model with its identifier, display
|
||||
name, and context limit.
|
||||
1. Click the **star icon** next to a model to set it as the default.
|
||||
1. Select the correct organization.
|
||||
Coder shows the organization picker when you can access more than 1 organization.
|
||||
1. Select **Add model** and configure at least one model with its identifier, display name, and context limit.
|
||||
|
||||
Coder makes the first model of an organization the default model.
|
||||
To change the default later, open a model and select **Set as Coder Agents default model**.
|
||||
|
||||
Each organization has its own model list and its own default model.
|
||||
Repeat the model steps in every organization that uses Coder Agents.
|
||||
Refer to [Organization scope](./platform-controls/organizations.md) for the settings that stay deployment-wide.
|
||||
|
||||
Detailed instructions for each provider and model option are in the
|
||||
[Models](./models.md) documentation.
|
||||
@@ -189,7 +202,7 @@ deployment. Use this to encode organizational conventions:
|
||||
- Required review processes before merging.
|
||||
- Any guardrails specific to your environment.
|
||||
|
||||
Configure the system prompt from **AI Settings** > **Coder Agents** > **Instructions**
|
||||
Configure the system prompt from **Admin settings** > **AI** > **Coder Agents** > **Instructions**
|
||||
or via the API at `PUT /api/v2/chats/config/system-prompt`.
|
||||
See [Platform Controls](./platform-controls/index.md) for details.
|
||||
|
||||
|
||||
@@ -14,9 +14,9 @@ Your browser does not support the video tag.
|
||||
|
||||
## What Coder Agents is and isn't
|
||||
|
||||
It is a standalone agent written in Go that implements standard
|
||||
agentic patterns — sub-agent delegation, context compaction, file editing, and
|
||||
shell execution — and works with any LLM provider you configure.
|
||||
It is a standalone agent written in Go.
|
||||
It implements standard agentic patterns, such as sub-agent delegation, context compaction, file editing, and shell execution.
|
||||
It works with any LLM provider you configure.
|
||||
|
||||
It is not a wrapper around third-party agent tools like Claude Code
|
||||
or Codex.
|
||||
@@ -90,6 +90,8 @@ creates a workspace automatically. Template visibility is scoped to the user's r
|
||||
Platform teams control template routing by writing clear template descriptions.
|
||||
For example, a description like "Use this template for Python backend services
|
||||
in the payments repo" helps the agent select the correct infrastructure.
|
||||
Administrators can also block agents on a template, which hides it from the agent completely.
|
||||
Refer to [Platform Controls](./platform-controls/index.md#template-routing) for that setting.
|
||||
|
||||
**Examples of what triggers workspace creation:**
|
||||
|
||||
@@ -166,7 +168,7 @@ entirely:
|
||||
else. The workspace never needs to reach the internet for AI functionality.
|
||||
- **Centralized, enforced control.** Platform teams configure models, system
|
||||
prompts, and tool permissions from the control plane. These settings are
|
||||
enforced server-side — they are not user preferences that developers can
|
||||
enforced server-side, so they are not user preferences that developers can
|
||||
override.
|
||||
- **User identity is always attached.** Every action the agent takes — PRs
|
||||
opened, code pushed, commands run — is tied to the user who submitted the
|
||||
@@ -217,8 +219,10 @@ and models from the Coder dashboard or API. Supported providers include:
|
||||
Most providers support custom base URLs, which allows integration with
|
||||
enterprise LLM proxies, self-hosted model endpoints, and internal gateways.
|
||||
|
||||
Administrators can configure multiple providers simultaneously and set a default
|
||||
model. Developers select from enabled models when starting a chat.
|
||||
Administrators can configure multiple providers simultaneously and set a default model in each organization.
|
||||
Developers select from enabled models when starting a chat.
|
||||
Providers are deployment-wide, and models belong to an organization.
|
||||
Refer to [Organization scope](./platform-controls/organizations.md) for details.
|
||||
|
||||
<img src="../../images/guides/ai-agents/llm-providers.png" alt="Screenshot of the provider/model configuration in the Agents settings">
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Models
|
||||
|
||||
Administrators configure LLM providers from **Admin settings** > **AI** and
|
||||
Coder Agents models from **Admin settings** > **AI** > **Models**. Providers,
|
||||
models, and centrally managed credentials are deployment-wide settings managed
|
||||
by platform teams. Developers select from the set of models that an administrator has
|
||||
enabled.
|
||||
Administrators configure LLM providers from **Admin settings** > **AI** and Coder Agents models from **Admin settings** > **AI** > **Models**.
|
||||
Providers and centrally managed credentials are deployment-wide settings managed by platform teams.
|
||||
Each model belongs to an organization. Each organization has its own model list.
|
||||
Developers select from the set of models that an administrator has enabled in their organization.
|
||||
Refer to [Organization scope](./platform-controls/organizations.md) for the split between deployment-wide and organization-scoped settings.
|
||||
|
||||
Optionally, administrators can enable AI Gateway Bring Your Own Key (BYOK)
|
||||
so developers can supply personal API keys for providers. See
|
||||
@@ -43,8 +43,8 @@ add one of the supported provider types above instead.
|
||||
|
||||
### Add a provider
|
||||
|
||||
LLM providers are managed from the deployment AI settings, not from the Agents
|
||||
settings page.
|
||||
LLM providers are managed from the deployment AI settings, not from the Agents settings page.
|
||||
A provider is deployment-wide, whilst the models that reference it are organization-scoped.
|
||||
|
||||
1. Navigate to **Admin settings** > **AI**.
|
||||
1. Select **Providers**.
|
||||
@@ -55,9 +55,9 @@ settings page.
|
||||
[endpoint/base URL](#endpointbase-url-for-openai-compatible-providers).
|
||||
1. Click **Save**.
|
||||
|
||||
After saving a provider, add an Agents model for it from **Admin settings** >
|
||||
**AI** > **Models**. For provider-specific setup, including AWS Bedrock, see
|
||||
[AI Gateway provider configuration](../ai-gateway/providers.md#provider-types).
|
||||
After saving a provider, add an Agents model for it from **Admin settings** > **AI** > **Models**.
|
||||
Select the organization that should own the new model before you add it.
|
||||
For provider-specific setup, including AWS Bedrock, refer to [AI Gateway provider configuration](../ai-gateway/providers.md#provider-types).
|
||||
|
||||
## Endpoint/base URL for OpenAI-compatible providers
|
||||
|
||||
@@ -102,8 +102,8 @@ on this security model.
|
||||
|
||||
## Credential selection
|
||||
|
||||
Coder Agents use the AI providers configured by administrators. Provider API
|
||||
keys entered by administrators are centralized credentials for the deployment.
|
||||
Coder Agents use the AI providers configured by administrators.
|
||||
Provider API keys entered by administrators are centralized credentials for the deployment.
|
||||
|
||||
BYOK for Coder Agents is controlled by the
|
||||
[global AI Gateway BYOK setting](../ai-gateway/auth.md#bring-your-own-key-byok),
|
||||
@@ -137,19 +137,19 @@ Members with model read access can open the model list and model details.
|
||||
Coder shows model fields as read-only unless the member also has update permission.
|
||||
Create, update, delete, and share permissions control their corresponding actions independently.
|
||||
|
||||
### Share a model
|
||||
### Manage model permissions
|
||||
|
||||
Members with model share permission can grant model read access to members and groups in the selected organization.
|
||||
Members with model share permission can let members and groups in the selected organization use the model.
|
||||
|
||||
1. Navigate to **Admin settings** > **AI** > **Models**.
|
||||
2. Select the organization that owns the model.
|
||||
3. Select the model.
|
||||
4. Open **Model actions** and select **Share model**.
|
||||
4. Open **Model actions** and select **Manage permissions**.
|
||||
5. Add or remove organization members and groups.
|
||||
6. Select **Save**.
|
||||
6. Select **Save permissions**.
|
||||
|
||||
Coder applies the member and group changes when you save.
|
||||
Removing all entries clears the model's access list, so members without another read grant lose access on their next request.
|
||||
Removing all entries clears the model's access list, so members without another access grant cannot use the model on their next request.
|
||||
|
||||
### Model visibility and runtime availability
|
||||
|
||||
@@ -158,7 +158,7 @@ A member can see a model in settings through its access list even when the model
|
||||
|
||||
The Agents model selector includes the model only when its exact provider configuration has usable credentials for that member.
|
||||
Coder evaluates providers by provider UUID, so 2 providers of the same type can have different availability.
|
||||
An unavailable provider can remain visible with a redacted reason while its models are omitted from the selector.
|
||||
An unavailable provider can remain visible while its models are omitted from the selector.
|
||||
|
||||
Model APIs identify each configured model with a UUID.
|
||||
The provider's model identifier, such as `gpt-5.3-codex`, doesn't replace this model UUID.
|
||||
@@ -166,7 +166,7 @@ The provider's model identifier, such as `gpt-5.3-codex`, doesn't replace this m
|
||||
### Add a model
|
||||
|
||||
1. Navigate to **Admin settings** > **AI** > **Models**.
|
||||
1. Click **Add** and select the provider for the new model.
|
||||
1. Select **Add model** and select the provider for the new model.
|
||||
1. Enter the **Model Identifier**, the exact model string your provider
|
||||
expects (e.g., `claude-opus-4-6`, `gpt-5.3-codex`).
|
||||
1. Set a **Display Name** so developers see a human-readable label in the model
|
||||
@@ -174,7 +174,7 @@ The provider's model identifier, such as `gpt-5.3-codex`, doesn't replace this m
|
||||
1. Set the **Context Limit**, the maximum number of tokens in the model's
|
||||
context window (e.g., `200000` for Claude Sonnet).
|
||||
1. Configure any provider-specific options (see below).
|
||||
1. Click **Save**.
|
||||
1. Select **Save**.
|
||||
|
||||
<img src="../../images/guides/ai-agents/models-list.png" alt="Screenshot of the models list in the Agents settings">
|
||||
|
||||
@@ -188,9 +188,18 @@ provider.</small>
|
||||
|
||||
### Set a default model
|
||||
|
||||
Click the **star icon** next to a model in the models list to make it the
|
||||
default. The default model is pre-selected when developers start a new chat.
|
||||
Only one model can be the default at a time.
|
||||
Each organization has one default model.
|
||||
The first model that you add to an organization becomes that organization's default model.
|
||||
The models list marks the current default with a **Default** badge.
|
||||
The default model is pre-selected when developers start a new chat in the organization.
|
||||
|
||||
To change the default model:
|
||||
|
||||
1. Navigate to **Admin settings** > **AI** > **Models**.
|
||||
1. Select the organization that owns the model.
|
||||
1. Open the model, or click **Add model** to create a new one.
|
||||
1. Select **Set as Coder Agents default model**.
|
||||
1. Click **Save**.
|
||||
|
||||
### Models with a missing or disabled provider
|
||||
|
||||
@@ -280,15 +289,14 @@ fields appear dynamically in the admin UI when you select a provider.
|
||||
|
||||
## How developers select models
|
||||
|
||||
Developers see a model selector dropdown when starting or continuing a chat on
|
||||
the Agents page. The selector shows only models from providers that have valid
|
||||
credentials configured. Models are grouped by provider if multiple providers
|
||||
are active.
|
||||
Developers see a model selector dropdown when starting or continuing a chat on the Agents page.
|
||||
The selector shows only models in the chat's organization that come from providers with valid credentials.
|
||||
Models are grouped by provider if multiple providers are active.
|
||||
|
||||
The model selector uses the following precedence to pre-select a model:
|
||||
|
||||
1. **Last used model**, stored in the browser's local storage.
|
||||
1. **Admin-designated default**, the model marked with the star icon.
|
||||
1. **Organization default**, the model marked with the **Default** badge.
|
||||
1. **First available model**, if no default is set and no history exists.
|
||||
|
||||
Developers cannot add their own providers or models. If no models are
|
||||
@@ -297,19 +305,20 @@ contact an administrator.
|
||||
|
||||
## Model overrides
|
||||
|
||||
Beyond the chat-level model picker, Coder Agents supports two override
|
||||
layers. Both are stored per organization and resolve from the chat's
|
||||
organization:
|
||||
Beyond the chat-level model picker, Coder Agents supports two override layers.
|
||||
Both are stored per organization and resolve from the chat's organization:
|
||||
|
||||
- **Admin overrides** (per organization): Pin specific contexts to a
|
||||
particular model. Configure them on the **Defaults & overrides** tab
|
||||
under **AI Settings** > **Models** for the selected organization.
|
||||
- **Personal overrides** (per user and organization, opt-in by admin):
|
||||
Let users override the model for their own root chats and delegated
|
||||
subagents. Admins enable the deployment-wide toggle under
|
||||
**AI Settings** > **Coder Agents**; once on, each user sees an
|
||||
**Agents** tab in their personal **Agents** > **Settings**. Users in
|
||||
more than one organization pick which organization to configure.
|
||||
- **Admin overrides** (per organization): Pin specific contexts to a particular model.
|
||||
Configure them in the **Organization settings** section of **Admin settings** > **AI** > **Coder Agents**.
|
||||
Coder shows an organization picker in that section when you can access more than 1 organization.
|
||||
- **Personal overrides** (per user and organization, opt-in by admin): Let users override the model for their own root chats and delegated subagents.
|
||||
Admins enable the deployment-wide toggle in the **Deployment settings** section of the same page.
|
||||
Once the toggle is on, each user sees an **Agents** tab in their personal **Agents** > **Settings**.
|
||||
Users in more than one organization pick which organization to configure.
|
||||
|
||||
The **Coder Agents** page is visible to deployment admins and to organization members with model access.
|
||||
To change an organization override, you need permission to edit that organization's models.
|
||||
The **Deployment settings** section is visible only to deployment admins.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> When a deployment upgrades from the older deployment-wide override
|
||||
|
||||
@@ -30,19 +30,17 @@ after repeated failures, or risk reduction before a destructive operation.
|
||||
## Configuration
|
||||
|
||||
Once the experiment is enabled, configure the advisor's runtime limits
|
||||
under **AI Settings** > **Coder Agents** > **Advisor**. These limits apply
|
||||
deployment-wide.
|
||||
under **Admin settings** > **AI** > **Coder Agents** > **Deployment settings**.
|
||||
Use the **Advisor** card. These limits apply deployment-wide.
|
||||
|
||||
| Field | Default | Notes |
|
||||
|-------------------|----------------------|-------------------------------------------------------------------------------------------------------------------------|
|
||||
| Max uses per turn | `0` (unlimited) | Caps how many times the root agent can call the advisor in a single chat turn. Must be a non-negative integer. |
|
||||
| Max output tokens | `0` (server default) | Caps the advisor model's response length. `0` uses the server default of 16,384 tokens. Must be a non-negative integer. |
|
||||
|
||||
The advisor model and its reasoning effort are organization-scoped
|
||||
[model overrides](../models.md#model-overrides). Configure them on the
|
||||
**Defaults & overrides** tab under **AI Settings** > **Models** for the
|
||||
selected organization. When no override is set, the advisor reuses the
|
||||
root agent's model.
|
||||
The advisor model and its reasoning effort are organization-scoped [model overrides](../models.md#model-overrides).
|
||||
Configure them in the **Organization settings** section of **Admin settings** > **AI** > **Coder Agents** for the selected organization.
|
||||
When no override is set, the advisor reuses the root agent's model.
|
||||
|
||||
The advisor is not available in plan mode or to subagents.
|
||||
Failed advisor invocations refund the per-turn budget.
|
||||
|
||||
@@ -11,7 +11,7 @@ Off by default. Three layers control whether it runs for a given chat:
|
||||
on for every chat. The runtime admin and user toggles become read-only.
|
||||
1. **Runtime admin gate.** With the deployment override unset, the
|
||||
*Let users record chat debug logs* toggle decides whether users can opt
|
||||
in. Configure it under **AI Settings** > **Lifecycle**, or at
|
||||
in. Configure it under **Admin settings** > **AI** > **Coder Agents** > **Lifecycle**, or at
|
||||
`GET/PUT /api/v2/chats/config/debug-logging`.
|
||||
1. **Per-user toggle.** Users with the admin gate enabled can turn debug
|
||||
logging on for their own chats from **Agents** > **Settings** > **General**
|
||||
|
||||
@@ -8,18 +8,20 @@ burden.
|
||||
|
||||
This means:
|
||||
|
||||
- **All agent configuration is admin-level.** Providers, models, system prompts,
|
||||
and tool permissions are set by platform teams from the control plane. These
|
||||
are not user preferences — they are deployment-wide policies.
|
||||
- **All agent configuration is admin-level.** Providers, models, system prompts, and tool permissions are set by administrators from the control plane.
|
||||
These are not user preferences.
|
||||
Deployment administrators own the deployment-wide policies.
|
||||
Users with organization configuration access own the models and the MCP servers of their organization.
|
||||
Refer to [Organization scope](./organizations.md) for the split between the 2 scopes.
|
||||
- **Developers never need to configure anything by default.** A developer just
|
||||
describes the work they want done. They do not need to pick a provider or
|
||||
write a system prompt — the platform team has already set all of that up.
|
||||
write a system prompt. The platform team has already set all of that up.
|
||||
When a platform team enables user API keys for a provider, developers may
|
||||
optionally supply their own key — but this is an opt-in policy decision, not
|
||||
optionally supply their own key, but this is an opt-in policy decision, not
|
||||
a requirement.
|
||||
- **Enforcement, not defaults.** Settings configured by administrators are
|
||||
enforced server-side. Developers cannot override them. This is a deliberate
|
||||
distinction — a setting that a user can change is a preference, not a policy.
|
||||
- **Enforcement, not defaults.** Settings configured by administrators are enforced server-side.
|
||||
Developers cannot override them.
|
||||
A setting that a user can change is a preference, not a policy.
|
||||
|
||||
This is an architectural decision, not just a product choice. Because the agent
|
||||
loop runs in the control plane rather than inside developer workspaces, there is
|
||||
@@ -36,15 +38,23 @@ Coder dashboard. This includes API keys, base URLs (for enterprise proxies or
|
||||
self-hosted models), and per-model parameters like context limits, thinking
|
||||
budgets, and reasoning effort.
|
||||
|
||||
Providers are deployment-wide.
|
||||
Models belong to an organization, so each organization has its own model list and its own default model.
|
||||
|
||||
Developers select from the set of models an administrator has enabled. They
|
||||
cannot add their own providers or access models that have not been explicitly
|
||||
configured.
|
||||
|
||||
When an administrator enables user API keys on a provider, developers can
|
||||
supply their own key from the Agents settings page. See
|
||||
supply their own key from the Agents settings page. Refer to
|
||||
[User API keys (BYOK)](../models.md#user-api-keys-byok) for details.
|
||||
|
||||
See [Models](../models.md) for setup instructions.
|
||||
An administrator can also enable personal model overrides, which let a developer
|
||||
select a different model for their own chats. Coder disables personal model
|
||||
overrides until an administrator enables them.
|
||||
|
||||
Refer to [Models](../models.md) for setup instructions.
|
||||
Refer to [Organization scope](./organizations.md) for the organization scope and the upgrade behavior.
|
||||
|
||||
### System prompt
|
||||
|
||||
@@ -52,7 +62,7 @@ Administrators can set a system prompt that applies to all agent sessions. This
|
||||
is useful for establishing organizational conventions: coding standards,
|
||||
commit message formats, preferred libraries, or repository-specific context.
|
||||
|
||||
This setting is available under **AI Settings** > **Coder Agents** > **Instructions** and is only accessible to administrators. Developers do not see or interact with it.
|
||||
This setting is available under **Admin settings** > **AI** > **Coder Agents** > **Instructions** and is only accessible to administrators. Developers can't access or interact with it.
|
||||
|
||||
### Plan mode instructions
|
||||
|
||||
@@ -61,7 +71,7 @@ enters plan mode. These instructions supplement the built-in planning behavior
|
||||
and are useful for organization-specific planning requirements such as required
|
||||
plan sections, approval checkpoints, or review workflows.
|
||||
|
||||
This setting is available under **AI Settings** > **Coder Agents** > **Instructions**. Developers do not edit it directly.
|
||||
This setting is available under **Admin settings** > **AI** > **Coder Agents** > **Instructions**. Developers do not edit it directly.
|
||||
|
||||
The same value is exposed over the chat configuration API:
|
||||
|
||||
@@ -74,22 +84,23 @@ Platform teams control which templates are available to agents and how the agent
|
||||
selects them. When a developer describes a task, the agent reads template
|
||||
descriptions to determine which template to provision.
|
||||
|
||||
By writing clear template descriptions — for example, "Use this template for
|
||||
Python backend services in the payments repo" — platform teams can guide the
|
||||
By writing clear template descriptions, for example, "Use this template for
|
||||
Python backend services in the payments repo", platform teams can guide the
|
||||
agent toward the correct infrastructure without requiring developers to
|
||||
understand template selection at all.
|
||||
|
||||
Administrators can also restrict which templates are available to agents at **Agents** > **Settings** > **Manage Agents** > **Templates**.
|
||||
Administrators can also restrict which templates are available to agents at **Admin settings** > **AI** > **Coder Agents** > **Templates**.
|
||||
Use the switch for each template in the list.
|
||||
The same control is available on each individual template's settings page as **Allow Coder Agents to create workspaces using this template**.
|
||||
Templates allow agents by default.
|
||||
When you disable the control, the agent cannot read the template or provision workspaces from it.
|
||||
This is separate from what developers observe when manually creating workspaces, so you can apply stricter policies to agent-created workspaces without affecting the manual workspace experience.
|
||||
|
||||
See [Template Optimization](./template-optimization.md) for best practices on writing
|
||||
discoverable descriptions, restricting template visibility, configuring network
|
||||
boundaries, scoping credentials, and designing template parameters for agent
|
||||
use.
|
||||
The same control is available outside the dashboard.
|
||||
Use `coder templates create --agents-allowed=false` or `coder templates edit --agents-allowed=false <template>` for a single template.
|
||||
Use the search filter `agents-allowed:false` on `GET /api/v2/templates` to list the templates that block agents.
|
||||
|
||||
Check out [Template Optimization](./template-optimization.md) for best practices on writing discoverable descriptions, restricting template visibility, configuring network boundaries, scoping credentials, and designing template parameters for agent use.
|
||||
|
||||
### MCP servers
|
||||
|
||||
@@ -99,7 +110,9 @@ authentication, controlling which tools are exposed via allow/deny lists, and
|
||||
setting availability policies that determine whether a server is mandatory,
|
||||
opt-out, or opt-in for each chat.
|
||||
|
||||
See [MCP Servers](./mcp-servers.md) for configuration details.
|
||||
Each organization has its own set of MCP servers.
|
||||
|
||||
Refer to [MCP Servers](./mcp-servers.md) for configuration details.
|
||||
|
||||
### Workspace autostop fallback
|
||||
|
||||
@@ -107,10 +120,9 @@ Administrators can set a default autostop timer for agent-created workspaces
|
||||
that do not define one in their template. Template-defined autostop rules always
|
||||
take precedence. Active conversations extend the stop time automatically.
|
||||
|
||||
This setting is available under **Agents** > **Settings** >
|
||||
**Manage Agents** > **Lifecycle**. The maximum configurable value is 30
|
||||
days. When disabled, workspaces follow their template's autostop rules (or
|
||||
none, if the template does not define any).
|
||||
This setting is available under **Admin settings** > **AI** > **Coder Agents** > **Lifecycle**.
|
||||
The maximum configurable value is 30 days.
|
||||
When disabled, workspaces follow their template's autostop rules (or none, if the template does not define any).
|
||||
|
||||
### Concurrent agents
|
||||
|
||||
@@ -155,16 +167,15 @@ Administrators can configure a retention period for archived conversations.
|
||||
When enabled, archived conversations and orphaned files older than the
|
||||
retention period are automatically purged. The default is 30 days.
|
||||
|
||||
This setting is available under **Agents** > **Settings** >
|
||||
**Manage Agents** > **Lifecycle**. See [Data Retention](./chat-retention.md)
|
||||
for details.
|
||||
This setting is available under **Admin settings** > **AI** > **Coder Agents** > **Lifecycle**.
|
||||
Refer to [Data Retention](./chat-retention.md) for details.
|
||||
|
||||
### Experiments
|
||||
|
||||
Administrators enable experimental features using the `--experiments` flag on
|
||||
`coder server` (or the `CODER_EXPERIMENTS` environment variable). Once enabled,
|
||||
runtime configuration for those features is available under **AI Settings** >
|
||||
**Coder Agents**.
|
||||
runtime configuration for those features is available under **Admin settings** >
|
||||
**AI** > **Coder Agents**.
|
||||
|
||||
See the following pages for experiment-gated features:
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ servers, and chats only offer servers from the chat's organization. Configured
|
||||
servers are injected into or offered to users during chat depending on the
|
||||
availability policy.
|
||||
|
||||
This is an admin-only feature accessible at **AI Settings** > **Coder Agents** > **MCP servers**
|
||||
This feature is accessible at **Admin settings** > **AI** > **Coder Agents** > **MCP servers**
|
||||
(`/ai/settings/mcp-servers`). In multi-organization deployments, use the
|
||||
organization picker to choose which organization's servers to manage. The
|
||||
server list shows the picker when you can access more than one organization's
|
||||
@@ -15,19 +15,19 @@ read-only field when only one organization is available.
|
||||
|
||||
## Add an MCP server
|
||||
|
||||
1. Navigate to **AI Settings** > **Coder Agents** > **MCP servers**.
|
||||
1. Click **Add**.
|
||||
1. Navigate to **Admin settings** > **AI** > **Coder Agents** > **MCP servers**.
|
||||
1. Select **Add server**.
|
||||
1. Fill in the configuration fields described below.
|
||||
1. Click **Save**.
|
||||
1. Select **Save**.
|
||||
|
||||
### Identity
|
||||
|
||||
| Field | Required | Description |
|
||||
|----------------|----------|---------------------------------------------------------------|
|
||||
| `display_name` | Yes | Human-readable name shown to users in chat. |
|
||||
| `slug` | Yes | URL-safe unique identifier, auto-generated from display name. |
|
||||
| `description` | No | Brief summary of what the server provides. |
|
||||
| `icon_url` | No | Emoji or image URL displayed alongside the server name. |
|
||||
| Field | Required | Description |
|
||||
|----------------|----------|---------------------------------------------------------------------------------------------------|
|
||||
| `display_name` | Yes | Human-readable name shown to users in chat. |
|
||||
| `slug` | Yes | URL-safe identifier, auto-generated from display name. It must be unique within the organization. |
|
||||
| `description` | No | Brief summary of what the server provides. |
|
||||
| `icon_url` | No | Emoji or image URL displayed alongside the server name. |
|
||||
|
||||
### Connection
|
||||
|
||||
@@ -186,9 +186,12 @@ grant.
|
||||
Members only see enabled servers in their own organizations. Sensitive fields
|
||||
such as API keys and client secrets are redacted in API responses.
|
||||
|
||||
The **MCP servers** settings page is part of deployment settings, so opening it in the dashboard also requires permission to edit deployment configuration.
|
||||
Organization admins without that permission can manage servers through the API.
|
||||
Creating or updating a server with `auth_type` set to `user_oidc` also requires the `deployment_config:update` permission.
|
||||
Users with access to an organization's MCP servers can open the **MCP servers**
|
||||
settings page. Coder enables the edit controls for the users who can manage the
|
||||
selected organization's servers.
|
||||
Only deployment administrators can add or update a server that uses **User OIDC Identity** authentication.
|
||||
|
||||
Refer to [Organization scope](./organizations.md) for the organization scope of MCP servers and the upgrade behavior.
|
||||
|
||||
### Access control
|
||||
|
||||
|
||||
@@ -0,0 +1,112 @@
|
||||
# Organization scope
|
||||
|
||||
Coder Agents configuration is split between deployment-wide settings and organization-scoped settings.
|
||||
Deployment-wide settings apply to every chat in the deployment.
|
||||
Organization-scoped settings apply only to chats that belong to that organization.
|
||||
|
||||
This page describes which settings belong to each scope, what an upgrade changes, and who can configure each setting.
|
||||
|
||||
Every deployment has at least the default organization, so the organization-scoped settings apply even when you never create a second organization.
|
||||
Running more than 1 organization requires a [Premium license](../../../admin/users/organizations.md).
|
||||
|
||||
## What each scope owns
|
||||
|
||||
| Setting | Scope | Where to configure |
|
||||
|---------------------------------|------------------------|----------------------------------------------------------------------------|
|
||||
| AI providers and credentials | Deployment | **Admin settings** > **AI** > **Providers** |
|
||||
| Chat models | Organization | **Admin settings** > **AI** > **Models** |
|
||||
| Admin model overrides | Organization | **Admin settings** > **AI** > **Coder Agents** > **Organization settings** |
|
||||
| Personal model overrides | User, per organization | **Agents** > **Settings** > **Agents** |
|
||||
| Personal override toggle | Deployment | **Admin settings** > **AI** > **Coder Agents** > **Deployment settings** |
|
||||
| MCP servers | Organization | **Admin settings** > **AI** > **Coder Agents** > **MCP servers** |
|
||||
| System prompt | Deployment | **Admin settings** > **AI** > **Coder Agents** > **Instructions** |
|
||||
| Plan mode instructions | Deployment | **Admin settings** > **AI** > **Coder Agents** > **Instructions** |
|
||||
| Agent access to a template | Template | **Admin settings** > **AI** > **Coder Agents** > **Templates** |
|
||||
| Advisor runtime limits | Deployment | **Admin settings** > **AI** > **Coder Agents** > **Deployment settings** |
|
||||
| Virtual desktop provider | Deployment | **Admin settings** > **AI** > **Coder Agents** > **Deployment settings** |
|
||||
| Autostop fallback and lifecycle | Deployment | **Admin settings** > **AI** > **Coder Agents** > **Lifecycle** |
|
||||
| Data retention | Deployment | **Admin settings** > **AI** > **Coder Agents** > **Lifecycle** |
|
||||
|
||||
The **Deployment settings** section holds the Advisor card and the Virtual desktop card.
|
||||
Both cards appear on the **Coder Agents** page.
|
||||
|
||||
### AI providers stay deployment-wide
|
||||
|
||||
An AI provider holds the upstream endpoint and the credentials, so it stays a deployment-wide resource.
|
||||
A chat model belongs to 1 organization and references 1 provider.
|
||||
You select a provider when you add a model, but the dashboard never shows the provider's credentials.
|
||||
|
||||
Refer to [Models](../models.md) for provider setup and model options.
|
||||
|
||||
## What an upgrade does
|
||||
|
||||
When a deployment upgrades to a release that scopes models and MCP servers to organizations, Coder moves the existing configuration:
|
||||
|
||||
- Every existing chat model moves to the default organization.
|
||||
- Every existing MCP server moves to the default organization, with its credentials intact.
|
||||
- Every moved model and MCP server stays available to the default organization's **Everyone** group, so current members keep access.
|
||||
- The previous default model becomes the default model of the default organization.
|
||||
- Coder removes the existing admin and personal model overrides.
|
||||
- Coder ignores the previous Advisor model override, so you must set it again.
|
||||
- The deployment-wide template allowlist becomes the per-template **Allow Coder Agents to create workspaces using this template** setting.
|
||||
|
||||
Other organizations start with no models and no MCP servers.
|
||||
Coder copies nothing from the default organization.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Coder does not migrate the model overrides.
|
||||
> Administrators must set the organization overrides again in the **Organization settings** section of **Admin settings** > **AI** > **Coder Agents**.
|
||||
> Users must set their personal overrides again in **Agents** > **Settings** > **Agents**.
|
||||
|
||||
The template allowlist conversion follows these rules:
|
||||
|
||||
- A non-empty allowlist allows only the templates it lists, and blocks every other existing template.
|
||||
- A missing or empty allowlist leaves every template allowed.
|
||||
- An unreadable allowlist blocks every template, so review the template list after the upgrade.
|
||||
|
||||
The upgrade removes the stored allowlist, so you cannot recover the original list.
|
||||
Templates created after the upgrade allow agents by default.
|
||||
|
||||
## Organizations without models or MCP servers
|
||||
|
||||
A new organization has no chat models and no MCP servers.
|
||||
Add at least 1 model before members start a chat in that organization.
|
||||
|
||||
When an organization has no model that the user can use, Coder does not start the chat.
|
||||
The user sees a message that asks an administrator to configure a chat model.
|
||||
|
||||
An organization with no MCP servers produces no error.
|
||||
Chats in that organization offer no MCP servers.
|
||||
|
||||
## Who configures each scope
|
||||
|
||||
- Deployment administrators configure the providers and every setting in the **Deployment settings** section.
|
||||
- Users with edit access to an organization's models configure that organization's models and admin model overrides.
|
||||
- Users with read access to an organization's models can open the **Models** page and the **Coder Agents** page, and Coder shows the fields as read-only.
|
||||
- Users with access to an organization's MCP servers can open the **MCP servers** page.
|
||||
- Auditors and custom roles can hold read access without edit access.
|
||||
|
||||
The dashboard shows the organization picker when you can access more than 1 organization.
|
||||
Your access applies to the selected organization, so your controls can differ between organizations.
|
||||
|
||||
## Manage model and MCP server access
|
||||
|
||||
Each chat model and each MCP server has an access list of groups and users.
|
||||
An entry lets a member use the model or the server.
|
||||
Coder adds the organization's **Everyone** group when you create a model or a server, so all members have access by default.
|
||||
You can add only the members and the groups of the organization that owns the model or the server.
|
||||
|
||||
To change a model's access list, open **Model actions** > **Manage permissions** on the **Models** page.
|
||||
Refer to [Manage model permissions](../models.md#manage-model-permissions) for the steps.
|
||||
|
||||
The **MCP servers** page has no access list editor.
|
||||
Change an MCP server access list through the API instead:
|
||||
|
||||
- `GET /api/experimental/organizations/{organization}/mcp-servers/{mcpserverconfig}/acl`
|
||||
- `PATCH /api/experimental/organizations/{organization}/mcp-servers/{mcpserverconfig}/acl`
|
||||
|
||||
## Related pages
|
||||
|
||||
- [Models](../models.md) for providers, models, and model overrides.
|
||||
- [MCP Servers](./mcp-servers.md) for MCP server configuration.
|
||||
- [Template Optimization](./template-optimization.md) for the per-template agent setting.
|
||||
@@ -24,14 +24,15 @@ Lets agents drive a graphical desktop inside the workspace through
|
||||
## Configuration
|
||||
|
||||
Once the experiment is enabled, configure the computer-use provider under
|
||||
**AI Settings** > **Coder Agents** > **Virtual desktop**.
|
||||
**Admin settings** > **AI** > **Coder Agents** > **Deployment settings**.
|
||||
Use the **Virtual desktop** card.
|
||||
|
||||
Choose a **Computer use provider** (Anthropic or OpenAI). Virtual desktop also requires:
|
||||
|
||||
- The [portabledesktop](https://registry.coder.com/modules/coder/portabledesktop)
|
||||
module installed in the workspace template.
|
||||
- An API key for the selected provider configured under the **Providers**
|
||||
tab.
|
||||
sidebar item.
|
||||
|
||||
The Anthropic and OpenAI computer-use models are fixed by Coder per provider
|
||||
and are not selectable from this UI. Anthropic is the default when no
|
||||
|
||||
@@ -47,21 +47,21 @@ Before mapping individual endpoints, understand the structural changes:
|
||||
|
||||
The table below maps each Tasks API endpoint to its Chats API equivalent.
|
||||
|
||||
| Operation | Tasks API | Chats API |
|
||||
|-------------------|-------------------------------------------|-----------------------------------------------------------|
|
||||
| List | `GET /api/v2/tasks` | `GET /api/v2/chats` |
|
||||
| Create | `POST /api/v2/tasks/{user}` | `POST /api/v2/chats` |
|
||||
| Get by ID | `GET /api/v2/tasks/{user}/{task}` | `GET /api/v2/chats/{chat}` |
|
||||
| Delete | `DELETE /api/v2/tasks/{user}/{task}` | `PATCH /api/v2/chats/{chat}` with `{"archived": true}` |
|
||||
| Send follow-up | `POST /api/v2/tasks/{user}/{task}/send` | `POST /api/v2/chats/{chat}/messages` |
|
||||
| Update input | `PATCH /api/v2/tasks/{user}/{task}/input` | `PATCH /api/v2/chats/{chat}/messages/{message}` |
|
||||
| Get logs / stream | `GET /api/v2/tasks/{user}/{task}/logs` | `GET /api/v2/chats/{chat}/stream` (WebSocket) |
|
||||
| Pause | `POST /api/v2/tasks/{user}/{task}/pause` | `POST /api/v2/chats/{chat}/interrupt` |
|
||||
| Resume | `POST /api/v2/tasks/{user}/{task}/resume` | `POST /api/v2/chats/{chat}/messages` (send a new message) |
|
||||
| Watch all | n/a | `GET /api/v2/chats/watch` (WebSocket) |
|
||||
| Get messages | n/a | `GET /api/v2/chats/{chat}/messages` |
|
||||
| List models | n/a | `GET /api/v2/chats/models` |
|
||||
| Upload file | n/a | `POST /api/v2/chats/files` |
|
||||
| Operation | Tasks API | Chats API |
|
||||
|-------------------|-------------------------------------------|-------------------------------------------------------------------|
|
||||
| List | `GET /api/v2/tasks` | `GET /api/v2/chats` |
|
||||
| Create | `POST /api/v2/tasks/{user}` | `POST /api/v2/chats` |
|
||||
| Get by ID | `GET /api/v2/tasks/{user}/{task}` | `GET /api/v2/chats/{chat}` |
|
||||
| Delete | `DELETE /api/v2/tasks/{user}/{task}` | `PATCH /api/v2/chats/{chat}` with `{"archived": true}` |
|
||||
| Send follow-up | `POST /api/v2/tasks/{user}/{task}/send` | `POST /api/v2/chats/{chat}/messages` |
|
||||
| Update input | `PATCH /api/v2/tasks/{user}/{task}/input` | `PATCH /api/v2/chats/{chat}/messages/{message}` |
|
||||
| Get logs / stream | `GET /api/v2/tasks/{user}/{task}/logs` | `GET /api/v2/chats/{chat}/stream` (WebSocket) |
|
||||
| Pause | `POST /api/v2/tasks/{user}/{task}/pause` | `POST /api/v2/chats/{chat}/interrupt` |
|
||||
| Resume | `POST /api/v2/tasks/{user}/{task}/resume` | `POST /api/v2/chats/{chat}/messages` (send a new message) |
|
||||
| Watch all | n/a | `GET /api/v2/chats/watch` (WebSocket) |
|
||||
| Get messages | n/a | `GET /api/v2/chats/{chat}/messages` |
|
||||
| List models | n/a | `GET /api/experimental/organizations/{organization}/chats/models` |
|
||||
| Upload file | n/a | `POST /api/v2/chats/files` |
|
||||
|
||||
## Migration steps
|
||||
|
||||
@@ -74,8 +74,9 @@ configured once in the control plane:
|
||||
1. Navigate to **Admin settings** > **AI** and select **Providers**.
|
||||
1. Add or update a provider with its credentials and upstream endpoint, then
|
||||
save it.
|
||||
1. Navigate to **Admin settings** > **AI** > **Models**, add at least one model,
|
||||
and set it as the default.
|
||||
1. Navigate to **Admin settings** > **AI** > **Models**.
|
||||
1. Select the correct organization.
|
||||
1. Add at least one model, and set it as the default.
|
||||
|
||||
You no longer pass API keys in template variables or workspace environment. See https://coder.com/docs/ai-coder/agents/getting-started for more information.
|
||||
|
||||
@@ -509,12 +510,11 @@ confirm the Chats API integration is working end-to-end.
|
||||
|
||||
### 1. Confirm LLM provider connectivity
|
||||
|
||||
List available models to verify at least one provider is configured and
|
||||
reachable:
|
||||
List the available models in an organization to verify at least one provider is configured and reachable:
|
||||
|
||||
```sh
|
||||
curl -s https://coder.example.com/api/v2/chats/models \
|
||||
-H "Coder-Session-Token: $CODER_SESSION_TOKEN" | jq '.[].display_name'
|
||||
curl -s https://coder.example.com/api/experimental/organizations/$CODER_ORGANIZATION/chats/models \
|
||||
-H "Coder-Session-Token: $CODER_SESSION_TOKEN" | jq '.models[].display_name'
|
||||
```
|
||||
|
||||
If this returns an empty list or an error, revisit
|
||||
@@ -641,7 +641,7 @@ curl -s -X PATCH \
|
||||
|
||||
Use this checklist to confirm each part of your integration:
|
||||
|
||||
- [ ] At least one LLM model is configured and returned by `/chats/models`
|
||||
- [ ] At least one LLM model is configured in the organization and returned by `/organizations/{organization}/chats/models`
|
||||
- [ ] `POST /chats` creates a chat and returns a valid `Chat` object
|
||||
- [ ] WebSocket stream at `/chats/{chat}/stream` delivers events
|
||||
- [ ] Follow-up messages via `/chats/{chat}/messages` are accepted
|
||||
@@ -656,21 +656,21 @@ Use this checklist to confirm each part of your integration:
|
||||
The Chats API includes capabilities that have no equivalent in the Tasks
|
||||
API:
|
||||
|
||||
| Feature | Description |
|
||||
|--------------------------------------|--------------------------------------------------------------------------------|
|
||||
| **WebSocket streaming** | Real-time event stream via `GET /chats/{chat}/stream` instead of HTTP polling |
|
||||
| **Watch all chats** | `GET /chats/watch` pushes events for all chats owned by the user |
|
||||
| **Message editing** | `PATCH /chats/{chat}/messages/{message}` to edit a sent message and re-process |
|
||||
| **Message queuing** | Follow-up messages are automatically queued when the agent is busy |
|
||||
| **File uploads** | Attach images via `POST /chats/files` and reference them in messages |
|
||||
| **Model selection** | `GET /chats/models` to discover models; override per-chat or per-message |
|
||||
| **MCP server attachment** | Attach MCP servers to a chat for tool augmentation |
|
||||
| **Labels** | Key-value metadata on chats for filtering (`label` query parameter) |
|
||||
| **Sub-agents** | Agent can spawn child agents for parallel work |
|
||||
| **Diff/PR tracking** | `GET /chats/{chat}/diff` returns change tracking and PR metadata |
|
||||
| **Title generation** | `POST /chats/{chat}/title/propose` returns a suggested title |
|
||||
| **Pinning** | Pin and reorder chats via the `pin_order` field |
|
||||
| **Automatic workspace provisioning** | No workspace needed for Q&A. Provisioned only when the agent needs to act |
|
||||
| Feature | Description |
|
||||
|--------------------------------------|-------------------------------------------------------------------------------------------------------|
|
||||
| **WebSocket streaming** | Real-time event stream via `GET /chats/{chat}/stream` instead of HTTP polling |
|
||||
| **Watch all chats** | `GET /chats/watch` pushes events for all chats owned by the user |
|
||||
| **Message editing** | `PATCH /chats/{chat}/messages/{message}` to edit a sent message and re-process |
|
||||
| **Message queuing** | Follow-up messages are automatically queued when the agent is busy |
|
||||
| **File uploads** | Attach images via `POST /chats/files` and reference them in messages |
|
||||
| **Model selection** | `GET /organizations/{organization}/chats/models` to discover models; override per-chat or per-message |
|
||||
| **MCP server attachment** | Attach MCP servers to a chat for tool augmentation |
|
||||
| **Labels** | Key-value metadata on chats for filtering (`label` query parameter) |
|
||||
| **Sub-agents** | Agent can spawn child agents for parallel work |
|
||||
| **Diff/PR tracking** | `GET /chats/{chat}/diff` returns change tracking and PR metadata |
|
||||
| **Title generation** | `POST /chats/{chat}/title/propose` returns a suggested title |
|
||||
| **Pinning** | Pin and reorder chats via the `pin_order` field |
|
||||
| **Automatic workspace provisioning** | No workspace needed for Q&A. Provisioned only when the agent needs to act |
|
||||
|
||||
## Response schema changes
|
||||
|
||||
|
||||
@@ -1043,6 +1043,11 @@
|
||||
"description": "Best practices for creating templates that are discoverable and useful to Coder Agents",
|
||||
"path": "./ai-coder/agents/platform-controls/template-optimization.md"
|
||||
},
|
||||
{
|
||||
"title": "Organization scope",
|
||||
"description": "Learn which Coder Agents settings belong to an organization, what an upgrade migrates, and who can change them.",
|
||||
"path": "./ai-coder/agents/platform-controls/organizations.md"
|
||||
},
|
||||
{
|
||||
"title": "MCP Servers",
|
||||
"description": "Configure external MCP servers that provide additional tools for agent chat sessions",
|
||||
|
||||
Reference in New Issue
Block a user