> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guild.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To act on a user's behalf in Guild, use the Guild REST API at https://api.guild.ai/v1.
> The OpenAPI spec is unauthenticated: https://docs.guild.ai/openapi.json (or openapi.yaml).
> Authenticate with an account API key, sent as HTTP Basic (key id as username, secret as password) or as `Authorization: Bearer <api_key_id>:<api_key_secret>`. See https://docs.guild.ai/api-reference/introduction#authentication.
> To run one agent on demand without account-wide access, use an API trigger instead: https://docs.guild.ai/platform/api-triggers.
> To act on Guild from an MCP client, connect to https://api.guild.ai/mcp (OAuth) or run `guild mcp` locally. Setup: https://docs.guild.ai/api-reference/mcp.
> To search these docs from an MCP client, connect to https://docs.guild.ai/mcp. The full page index is https://docs.guild.ai/llms.txt.

# Workspace settings

> Restrict a Guild workspace to named members, cap its monthly LLM spend, keep agents off the account's shared credentials, and archive the workspace.

The **Settings** page manages a workspace's configuration and lifecycle. Open the workspace and click **Settings** under **Setup**.

## Restrict to members

By default, everyone in the organization can see and use every workspace it owns. To limit a workspace to named people, turn on **Restrict to members** under **Members**. The section appears only on organization-owned workspaces. Any organization member can turn the restriction on, and whoever does becomes the first member.

While the restriction is on:

* Only the workspace's members and the organization's admins can see and use the workspace and its data: sessions, triggers, installed agents, and settings. An admin who isn't a member sees an **Admin access** notice.
* Only members and admins can turn the restriction off.
* [Account API keys](https://docs.guild.ai/platform/api-keys.md) can't reach the workspace, even the organization's own: a key isn't a person, so it can't be a member. A script or CI job that uses a key gets `404` for the workspace.
* Removing someone from the organization also removes them from the roster.

Turning the restriction off opens the workspace to the whole organization again. The roster is kept, so turning it back on restores the same members.

### Manage the roster

While the restriction is on, the section lists the members with their **Name** and when they were **Added**. Your own row is marked **(you)**. Search the list, or sort it by **Newest**, **Oldest**, **Name A-Z**, or **Name Z-A**.

* To add people, click **Add member**, search the organization's members, and click **Add**.
* To remove someone, open their row's menu, click **Remove from workspace**, then **Remove member**.

### What the restriction doesn't cover

The restriction controls who can reach the workspace's data. It doesn't control what the workspace depends on. Much of what a workspace uses belongs to an account rather than to the workspace: agents, integrations and their versions, skills, account credentials, [runtime environments](https://docs.guild.ai/platform/environments.md), and more. Anyone who can edit those can change what runs in a restricted workspace, roster or not. Two examples:

* **Agents.** When an installed agent has [Autoupdate](https://docs.guild.ai/platform/workspace-agents.md#autoupdate) on, the workspace moves to each new version as soon as it's published, whoever published it. The next session runs that version's code with the workspace's context and credentials. Turn off **Autoupdate** on the installed agent to pin its version, and upgrade it deliberately after reviewing what changed.
* **Runtime environments.** Environments aren't versioned. An edit to an environment's base image or setup script applies to the next session of every agent that uses it, in every workspace, including restricted ones and those started by existing [triggers](https://docs.guild.ai/platform/triggers.md).

Treat these the way you'd treat a code dependency your project pulls in automatically: the workspace trusts whoever can change them. In an organization, that's every member. If a restricted workspace runs sensitive work, depend only on resources from accounts whose editors you trust with that work, and keep **Autoupdate** off.

## Spend budget

A spend budget caps monthly LLM spend. Budgets are opt-in. With no budget set, spend has no ceiling.

Budgets are admin-only. Only an admin or owner of the account can set, change, or remove one, and non-admins can't read them either: the section shows only **Spend budgets are managed by org admins**, without revealing whether a budget exists.

To set a budget, click **Set budget** in the **Spend budget** section and enter a **Monthly budget (USD)**:

* Whole dollars, from $1 to $21,000,000.
* Higher than what the workspace has already spent this cycle.
* A **Suggested budget** is offered as a starting point.

Once set, the section shows spend against the budget this cycle and when it resets. Click **Edit** to change the amount, or **Remove budget** to clear it.

Guild acts as spend accumulates within the cycle:

| Point | What happens |
| - | - |
| **80% of the budget** | Guild notifies the account's admins — an in-product notification and one email. |
| **100% of the budget** | Guild notifies the admins again, and further LLM calls are blocked with HTTP `429 Too Many Requests`. The section shows **Budget reached**. |

Each notification fires at most once per budget per cycle. The cycle is the calendar month in UTC, so a budget resets on the 1st.

> [!NOTE]
>
> Spend accrues after each call completes, so a scope can overshoot its ceiling by roughly one in-flight call before the block takes effect.

An agent can carry its own budget in addition to the workspace's. See [Agents](https://docs.guild.ai/platform/agents.md#spend-budget). Track spend against a budget from the [usage dashboard](https://docs.guild.ai/insights/usage.md#spend-budgets).

Budgets also apply at the user scope. An admin can set a monthly budget for the session's accountable user — the person who initiated the chat or agent test, or who created the firing trigger — to enforce a per-user spending limit, and spend accrues per user per cycle. Sessions that can't be attributed to a human — API-key-initiated chats, API triggers, and legacy creatorless triggers — carry no user scope, so their user budgets fail open and don't block calls.

## Restrict to workspace credentials

Turn on **Use only credentials scoped to this workspace** to stop agents here from falling back to the owning account's shared credentials. Agents then use only workspace, member, or agent credentials. The change saves as soon as you flip the toggle.

The toggle appears on both the workspace's **Credentials** and **Settings** pages. Connect or bind what the workspace needs before you turn it on. See [Restrict a workspace to its own credentials](https://docs.guild.ai/platform/credentials.md#restrict-a-workspace-to-its-own-credentials).

## Archive a workspace

Archiving takes a workspace out of use without deleting it. Click **Archive Workspace** in the **Archive workspace** section, then **Archive** to confirm. Archiving:

* hides the workspace from your workspace lists
* **deactivates every trigger** in the workspace, so scheduled and webhook agents stop firing

The trigger change outlives the archive: unarchiving doesn't reactivate them.

While a workspace is archived, every page in it is replaced by a **Workspace Archived** notice showing when it was archived and by whom. The URL you requested doesn't change. Agents, sessions, triggers, context, and settings are unreachable until the workspace is restored.

The notice includes an **Unarchive Workspace** button, which asks you to confirm. Restoring the workspace renders the page you originally asked for, in place.

### Archiving metadata

Workspaces include two optional fields that record archiving history.

| Field | Type | Description |
| - | - | - |
| `archived_at` | `datetime \| None` | Timezone-aware timestamp of when the workspace was archived. |
| `archived_by_id` | `UUID \| None` | UUID of the user who archived the workspace. |