diff --git a/src/content/docs/agent-platform/cloud-agents/agents.mdx b/src/content/docs/agent-platform/cloud-agents/agents.mdx index c22f7c20..21f8eb4e 100644 --- a/src/content/docs/agent-platform/cloud-agents/agents.mdx +++ b/src/content/docs/agent-platform/cloud-agents/agents.mdx @@ -18,7 +18,7 @@ Agent identities are useful when you want to: ## How agent identities work -Each team has one default agent identity. Headless runs (such as team API key runs that don't specify an identity) execute under this default. User-triggered runs default to running as the calling user, which is surfaced as **Quick run** in the web app, unless you pick a specific agent identity. You can create additional agent identities on top of the default and run as any of them. Identities are team-scoped, so every member of a team can see and use the same set of agent identities. +Each team has one default agent identity called **Default Service Account**. Headless runs that use an Agent API key for **Default Service Account** execute under this default, which is equivalent to the old team API key behavior. User-triggered runs default to running as the calling user, which is surfaced as **Quick run** in the web app, unless you pick a specific agent identity. You can create additional agent identities on top of the default and run as any of them. Identities are team-scoped, so every member of a team can see and use the same set of agent identities. You can attach the following configuration to an agent identity: @@ -68,9 +68,9 @@ A few constraints apply across every endpoint: ## API keys bound to an agent identity -A team API key can be bound to a specific agent identity at creation time. Calls authenticated with that key run as the chosen identity. The team is resolved automatically from the identity, so you don't need to specify a team when generating the key. +An Agent API key is bound to a specific agent identity at creation time. Calls authenticated with that key run as the chosen identity. The team is resolved automatically from the identity, so you don't need to specify a team when generating the key. -To create a key bound to an agent identity, choose the identity when creating the team API key. See [API keys](/reference/cli/api-keys/) for the full key creation flow and for the difference between user-scoped and team-scoped keys. +To create a key bound to an agent identity, choose the identity when creating the Agent API key. Choose **Default Service Account** for the same behavior as the old team API key. See [API keys](/reference/cli/api-keys/) for the full key creation flow. Once the key exists, the CLI and SDK authenticate as that agent identity for every call. There is no extra flag to set; the binding is on the key itself. @@ -81,7 +81,7 @@ There are two ways to run a cloud agent as a specific agent identity: * **Authenticate with a key bound to the identity** - Every run started with that key executes as the bound agent identity. This is the typical path for CI pipelines and scheduled work. * **Pass `agent_identity_uid` on `POST /agent/runs`** - For one-off runs, send the agent identity's `uid` in the request body. The field is only valid for team-owned runs. -When neither path is used, headless runs (team API key runs without an identity) execute under the team's default agent identity. User-triggered runs (Warp app, personal API key, Slack, Linear) execute as the calling user and are surfaced as **Quick run** in the web app. +When neither path is used, headless runs execute under the team's default agent identity. User-triggered runs (Warp app, `oz login`, Slack, Linear) execute as the calling user and are surfaced as **Quick run** in the web app. ## Where agent identities appear in the product diff --git a/src/content/docs/agent-platform/cloud-agents/environments.mdx b/src/content/docs/agent-platform/cloud-agents/environments.mdx index ee398826..94454cf1 100644 --- a/src/content/docs/agent-platform/cloud-agents/environments.mdx +++ b/src/content/docs/agent-platform/cloud-agents/environments.mdx @@ -133,7 +133,7 @@ You can create and configure environments with Warp’s guided setup, or through Make sure you have: * One or more GitHub repositories that the agent should clone and work in. -* **GitHub authorization configured** so the agent can access your repos. For user-triggered runs, each user authorizes GitHub individually. For automated workflows using team API keys, configure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) in the Admin Panel. +* **GitHub authorization configured** so the agent can access your repos. For user-triggered runs, each user authorizes GitHub individually. For automated workflows using Agent API keys, configure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) in the Admin Panel. * A publicly-accessible Docker image that can build and run your code. Official images like [node](https://hub.docker.com/_/node), [python](https://hub.docker.com/_/python), or [rust](https://hub.docker.com/_/rust) work for many projects. You can also use one of [Warp's prebuilt dev images](https://github.com/warpdotdev/oz-dev-environments). :::caution diff --git a/src/content/docs/agent-platform/cloud-agents/integrations/quickstart-github-actions.mdx b/src/content/docs/agent-platform/cloud-agents/integrations/quickstart-github-actions.mdx index 4d2ebc38..df67cf91 100644 --- a/src/content/docs/agent-platform/cloud-agents/integrations/quickstart-github-actions.mdx +++ b/src/content/docs/agent-platform/cloud-agents/integrations/quickstart-github-actions.mdx @@ -13,7 +13,7 @@ Add agents to your GitHub Actions workflows with [`oz-agent-action`](https://git ## Prerequisites -* **Warp API key** - In the Warp app, click your profile photo, then go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create one. Use a personal key if the agent needs to write to your repo. See [API Keys](/reference/cli/api-keys/) for details. +* **Agent API key** - In the Warp app, click your profile photo, then go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create one. Use **Default Service Account** for the same behavior as the old team API key, and configure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) if the agent needs to write to your repo. See [API Keys](/reference/cli/api-keys/) for details. * **A GitHub repository with Actions enabled** - The workflow file will live in `.github/workflows/` in your repo. --- diff --git a/src/content/docs/agent-platform/cloud-agents/quickstart.mdx b/src/content/docs/agent-platform/cloud-agents/quickstart.mdx index 8e7b0d5c..c811fd9f 100644 --- a/src/content/docs/agent-platform/cloud-agents/quickstart.mdx +++ b/src/content/docs/agent-platform/cloud-agents/quickstart.mdx @@ -154,7 +154,7 @@ Use the [Oz API & SDK](/reference/api-and-sdk/) to trigger agents programmatical Use official Docker Hub images like `node`, `python`, or `rust` for best compatibility. Ensure your GitHub repos are accessible. If using a custom image, avoid Alpine/musl-based images—the agent runtime requires glibc. See [Environments](/agent-platform/cloud-agents/environments/) for more guidance on choosing Docker images. **Agent can't access repos**\ -Warp prompts you to authorize GitHub when you create an environment or trigger your first agent. If authorization fails or needs updating, see [How GitHub Authorization works](/reference/cli/integration-setup/#how-github-authorization-works). For automated workflows using team API keys, make sure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) is configured in the Admin Panel. Also verify that repos are correctly configured in your environment with `oz environment get `. +Warp prompts you to authorize GitHub when you create an environment or trigger your first agent. If authorization fails or needs updating, see [How GitHub Authorization works](/reference/cli/integration-setup/#how-github-authorization-works). For automated workflows using Agent API keys, make sure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) is configured in the Admin Panel. Also verify that repos are correctly configured in your environment with `oz environment get `. **Not enough credits to run cloud agents**\ Your team needs at least 20 credits available. Check your credit balance in Settings or see [Access, Billing, and Identity](/agent-platform/cloud-agents/team-access-billing-and-identity/) for details on credit requirements and which plans support cloud agents. diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-direct.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-direct.mdx index 2fc2d350..533fff4e 100644 --- a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-direct.mdx +++ b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-direct.mdx @@ -39,7 +39,7 @@ The Direct backend does not provide per-task container isolation. Each task runs * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team. * **A worker host** with write access to `workspace_root` (defaults to `/var/lib/oz/workspaces`). * **The Oz CLI** installed and available in `PATH` on the worker host (or specify `oz_path` in the config file). See [Installing the CLI](/reference/cli/#installing-the-cli). -* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details. +* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details. --- @@ -50,7 +50,7 @@ The Direct backend does not provide per-task container isolation. Each task runs Export the API key so the worker can authenticate to Oz: ```bash -export WARP_API_KEY="your_team_api_key" +export WARP_API_KEY="your_agent_api_key" ``` ### 2. Start the worker with the Direct backend diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-docker.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-docker.mdx index fb29b4f1..1de5bc67 100644 --- a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-docker.mdx +++ b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-docker.mdx @@ -26,7 +26,7 @@ This page covers the [managed architecture](/agent-platform/cloud-agents/self-ho * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team. * **A machine to run the worker** — A VM, server, or local machine running Linux (recommended for production). For testing, macOS and Windows hosts running Docker Desktop work. * **Docker installed** — The worker uses Docker to spawn task containers. The Docker daemon must run Linux containers (Windows containers are not supported). Verify with `docker info`. -* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details. +* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details. :::caution Task containers require a **linux/amd64** or **linux/arm64** Docker daemon. The worker host itself can be any OS — Docker Desktop on macOS and Windows runs a Linux VM that satisfies this requirement. @@ -46,10 +46,10 @@ docker info ## Set your API key -Export your team API key so the worker can authenticate to Oz: +Export your Agent API key so the worker can authenticate to Oz: ```bash -export WARP_API_KEY="your_team_api_key" +export WARP_API_KEY="your_agent_api_key" ``` ## Install and run the worker diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-kubernetes.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-kubernetes.mdx index 278c424d..c93d3dae 100644 --- a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-kubernetes.mdx +++ b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-kubernetes.mdx @@ -38,7 +38,7 @@ This page covers the [managed architecture](/agent-platform/cloud-agents/self-ho * Allow the worker's namespace to create Jobs with a **root init container** (sidecar materialization depends on this pattern). * Grant the worker these namespace-scoped permissions: `create`, `get`, `list`, `watch`, `delete` on `jobs`; `get`, `list`, `watch` on `pods`; `get` on `pods/log`; `list` on `events`. * **[Helm](https://helm.sh/docs/intro/install/)** installed locally, plus `kubectl` authenticated against the target cluster. -* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details. +* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details. --- @@ -59,7 +59,7 @@ The chart does not create CRDs or cluster-scoped RBAC resources. ### 1. Set your API key and namespace ```bash -export WARP_API_KEY="your_team_api_key" +export WARP_API_KEY="your_agent_api_key" ``` Create the namespace if it doesn't exist: diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/quickstart.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/quickstart.mdx index 4eade66b..0a32d0a9 100644 --- a/src/content/docs/agent-platform/cloud-agents/self-hosting/quickstart.mdx +++ b/src/content/docs/agent-platform/cloud-agents/self-hosting/quickstart.mdx @@ -19,7 +19,7 @@ This quickstart sets up the [managed architecture](/agent-platform/cloud-agents/ * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team. * **A Linux machine with Docker** — A VM, server, or local machine with the Docker daemon running Linux containers. Verify with `docker info`. Docker Desktop on macOS or Windows works for testing. -* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details. +* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details. * **The Oz CLI** (for routing a test run) — See [Installing the CLI](/reference/cli/#installing-the-cli). --- @@ -30,10 +30,10 @@ _~10 minutes_ ### 1. Export your API key -Export the team API key so the worker container can authenticate to Oz automatically: +Export the Agent API key so the worker container can authenticate to Oz automatically: ```bash -export WARP_API_KEY="your_team_api_key" +export WARP_API_KEY="your_agent_api_key" ``` ### 2. Start the worker @@ -83,7 +83,7 @@ Open the [Oz dashboard](https://oz.warp.dev), find the new task, and confirm the Verify Docker is running (`docker info`) and that the daemon platform is `linux/amd64` or `linux/arm64`. Musl-based (Alpine) worker hosts are not supported. **Worker won't connect**\ -Verify your API key has team scope. Ensure the machine has outbound internet access to `oz.warp.dev:443`. Increase log verbosity with `--log-level debug` to see connection details. +Verify your API key is an Agent API key for the same Warp team as the worker. Ensure the machine has outbound internet access to `oz.warp.dev:443`. Increase log verbosity with `--log-level debug` to see connection details. **Task stays queued and never runs**\ Confirm the `--host` value you passed to `oz agent run-cloud` matches your `--worker-id` exactly (case-sensitive). Check that the worker's team matches the team creating the task. diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/reference.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/reference.mdx index 3764033a..a8b1feb6 100644 --- a/src/content/docs/agent-platform/cloud-agents/self-hosting/reference.mdx +++ b/src/content/docs/agent-platform/cloud-agents/self-hosting/reference.mdx @@ -20,7 +20,7 @@ The following flags are available when starting the worker. ### Required * `--worker-id` — A string identifying this worker. This is the value you pass to `--host` when routing tasks. Choose something meaningful for your team (e.g., `prod-runner-1` or `ci-worker`). Multiple workers can share the same ID for load balancing. -* `--api-key` or `WARP_API_KEY` env var — Your team API key for authentication. When running via Docker, pass it as `-e WARP_API_KEY="..."`. When running the binary directly, use `--api-key` or the environment variable. +* `--api-key` or `WARP_API_KEY` env var — Your Agent API key for authentication. Use a key for **Default Service Account** for the same behavior as the old team API key. When running via Docker, pass it as `-e WARP_API_KEY="..."`. When running the binary directly, use `--api-key` or the environment variable. ### Optional diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/unmanaged.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/unmanaged.mdx index 84d725d2..b7d45e2a 100644 --- a/src/content/docs/agent-platform/cloud-agents/self-hosting/unmanaged.mdx +++ b/src/content/docs/agent-platform/cloud-agents/self-hosting/unmanaged.mdx @@ -33,14 +33,14 @@ No Docker, no worker daemon, no environment required — just the Oz CLI on any ### Prerequisites * **The Oz CLI** installed on the machine where agents will run. See [Installing the CLI](/reference/cli/#installing-the-cli) for platform-specific instructions. -* **A Warp API key** — For automation, create a team-scoped API key in the Warp app at **Settings** > **Cloud platform** > **Oz Cloud API Keys**. See [API Keys](/reference/cli/api-keys/) for details. +* **An Agent API key** — For automation, create an Agent API key in the Warp app at **Settings** > **Cloud platform** > **Oz Cloud API Keys**. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details. ### 1. Authenticate Export your API key so the CLI can authenticate requests automatically: ```bash -export WARP_API_KEY="your_team_api_key" +export WARP_API_KEY="your_agent_api_key" ``` ### 2. Run an agent @@ -63,7 +63,7 @@ Use `--share` to control who can attach to the session and steer the agent: * `--share user@example.com` — Give a specific user read-only access. * `--share user@example.com:edit` — Give a specific user read/write access. -The `--share` flag can be repeated to combine multiple sharing targets. If you authenticate with a team API key, agents are automatically team-scoped. +The `--share` flag can be repeated to combine multiple sharing targets. If you authenticate with an Agent API key, agents are automatically team-scoped. --- diff --git a/src/content/docs/agent-platform/cloud-agents/team-access-billing-and-identity.mdx b/src/content/docs/agent-platform/cloud-agents/team-access-billing-and-identity.mdx index f000e7ee..00147f75 100644 --- a/src/content/docs/agent-platform/cloud-agents/team-access-billing-and-identity.mdx +++ b/src/content/docs/agent-platform/cloud-agents/team-access-billing-and-identity.mdx @@ -82,7 +82,7 @@ Your team must meet the following requirements to run integrations: When a user triggers an agent through an integration (like Slack or Linear), the run draws from credits based on who the run is billed to: * **User-triggered runs on Build, Max, or Business** - Warp draws from any [cloud agent credits](/support-and-community/plans-and-billing/credits/#compute-credits) the user has, then the user's plan-included credits, then the user's add-on credits. Add-on credits are scoped to the individual user and are not shared across the team. -* **Team API key or scheduled cloud agent runs on Build, Max, or Business** - Warp bills the team owner. The waterfall is: the owner's plan-included credits, then the owner's add-on credits. With auto-reload off, the request is blocked when both pools are depleted. With auto-reload on, usage can trigger a reload on the owner's pool subject to the team-wide monthly spend cap. +* **Agent API key or scheduled cloud agent runs on Build, Max, or Business** - Warp bills the team owner. The waterfall is: the owner's plan-included credits, then the owner's add-on credits. With auto-reload off, the request is blocked when both pools are depleted. With auto-reload on, usage can trigger a reload on the owner's pool subject to the team-wide monthly spend cap. * **Enterprise plans** - Runs draw from the team-scoped credit pool, per your Enterprise contract terms. If all applicable credit sources are exhausted and no auto-reload is configured, integrations and cloud agents will not run until credits are added. See [add-on credits](/support-and-community/plans-and-billing/add-on-credits/) for the full self-serve waterfall and [platform credits](/support-and-community/plans-and-billing/platform-credits/) for the third bucket that applies to every cloud agent run. @@ -108,13 +108,13 @@ This ensures runs are scoped to what the user is allowed to see and modify, and By default, cloud agents authenticate with GitHub using the personal token of the user who triggered the run. Team GitHub authorization gives you an alternative: authenticate with the **Oz by Warp** GitHub App instead, so agents can clone repositories and open pull requests without relying on any individual's token. -This is useful for fully automated workflows that use a [team API key](/reference/cli/api-keys/), like CI/CD pipelines, scheduled agents, and SDK-triggered runs, where you want code changes attributed to the GitHub App rather than a specific person. +This is useful for fully automated workflows that use an [Agent API key](/reference/cli/api-keys/), like CI/CD pipelines, scheduled agents, and SDK-triggered runs, where you want code changes attributed to the GitHub App rather than a specific person. ### How it works -When an agent task is initiated with a team API key, there is no individual user to authenticate on behalf of. Instead, Warp uses tokens issued by the **Oz by Warp** GitHub App installation to authenticate directly with GitHub. +When an agent task is initiated with an Agent API key, there is no individual user to authenticate on behalf of. Instead, Warp uses tokens issued by the **Oz by Warp** GitHub App installation to authenticate directly with GitHub. -The GitHub App token gives the agent access to the repositories included in the app installation — it can clone repos, create branches, push commits, and open pull requests. During installation, you choose whether the app can access **all repositories** or only **selected repositories** in your GitHub organization, and this controls what team API key runs can access. +The GitHub App token gives the agent access to the repositories included in the app installation — it can clone repos, create branches, push commits, and open pull requests. During installation, you choose whether the app can access **all repositories** or only **selected repositories** in your GitHub organization, and this controls what Agent API key runs can access. ### Setting up team GitHub authorization @@ -140,11 +140,11 @@ There are two places you may encounter this installation flow:
Enabled GitHub Orgs setting in the Admin Panel.
-3. **Use a team API key.** Tasks initiated with a team API key now use tokens from the GitHub App installation to clone repos and push changes. No individual GitHub authorization is needed. +3. **Use an Agent API key.** Tasks initiated with an Agent API key now use tokens from the GitHub App installation to clone repos and push changes. No individual GitHub authorization is needed. Use **Default Service Account** for the same behavior as the old team API key. ### How this relates to environments -An [environment](/agent-platform/cloud-agents/environments/) is a template for a cloud agent's sandbox — it defines the Docker image, repos, and setup commands, but it does not carry its own GitHub permissions. The same environment can be used by different users or by team API key runs, and each will authenticate to GitHub independently. +An [environment](/agent-platform/cloud-agents/environments/) is a template for a cloud agent's sandbox — it defines the Docker image, repos, and setup commands, but it does not carry its own GitHub permissions. The same environment can be used by different users or by Agent API key runs, and each will authenticate to GitHub independently. The environment configuration and the **Enabled GitHub Orgs** setting in the Admin Panel serve different purposes: @@ -155,13 +155,13 @@ The environment configuration and the **Enabled GitHub Orgs** setting in the Adm Team GitHub authorization is complementary to the existing personal token flow: -* **User-triggered runs** (personal API key, Slack, Linear, Warp app) - The agent authenticates as Oz acting on the triggering user's behalf. PRs and commits are attributed to that user. -* **Team API key runs with GitHub App authorization** - The agent authenticates as the GitHub App installation. PRs and commits are not attributed to any individual user. +* **User-triggered runs** (`oz login`, Slack, Linear, Warp app) - The agent authenticates as Oz acting on the triggering user's behalf. PRs and commits are attributed to that user. +* **Agent API key runs with GitHub App authorization** - The agent authenticates as the GitHub App installation. PRs and commits are attributed to the agent identity rather than an individual user. -Both flows can coexist on the same team. Personal tokens are still used for user-triggered runs, and the GitHub App installation token is used when a task is initiated with a team API key. +Both flows can coexist on the same team. Personal tokens are still used for user-triggered runs, and the GitHub App installation token is used when a task is initiated with an Agent API key. :::caution -GitHub App installation tokens are scoped to a single GitHub organization at a time. If your team works across repos in multiple GitHub organizations, the agent can only use the installation token for the organization enabled in the Admin Panel. Repos in other organizations require user-triggered runs with a personal API key. +GitHub App installation tokens are scoped to a single GitHub organization at a time. If your team works across repos in multiple GitHub organizations, the agent can only use the installation token for the organization enabled in the Admin Panel. Repos in other organizations require user-triggered runs with `oz login` or another user-authenticated surface. ::: :::note @@ -213,19 +213,19 @@ Cloud agent runs consume credits based on the complexity of the task and whether How credits are consumed depends on how the agent run is triggered and authenticated: -**User-triggered runs** (CLI with personal API key, Slack, Linear, or the Warp app): +**User-triggered runs** (CLI with `oz login`, Slack, Linear, or the Warp app): * Runs are tied to the triggering user's identity. * On Build, Max, and Business plans, credits are consumed starting with any [cloud agent credits](/support-and-community/plans-and-billing/credits/#compute-credits) allocated to the user, then the user's plan-included credits, then the user's add-on credits. Add-on credits are scoped to the individual user. * On Enterprise plans, runs draw from the team-scoped credit pool, per your Enterprise contract terms. -**Team API key and scheduled cloud agent runs** (fully automated or headless workflows): +**Agent API key and scheduled cloud agent runs** (fully automated or headless workflows): * Runs are not tied to any individual user. * On Build, Max, and Business plans, Warp bills the team owner: the owner's plan-included credits, then the owner's add-on credits. With auto-reload off, the request is blocked when both pools are depleted. With auto-reload on, usage can trigger a reload on the owner's add-on credit pool subject to the team-wide monthly spend cap. * On Enterprise plans, these runs draw from the team-scoped credit pool, per your Enterprise contract terms. * Ideal for CI/CD pipelines, scheduled tasks, and other automated workflows. -* For workflows that require code changes (opening pull requests, pushing branches, or writing to a repository), configure [team GitHub authorization](#team-github-authorization) so the agent can authenticate with the Oz by Warp GitHub App. Alternatively, use a [personal API key](/reference/cli/api-keys/) to authenticate as an individual user. +* For workflows that require code changes (opening pull requests, pushing branches, or writing to a repository), configure [team GitHub authorization](#team-github-authorization) so the agent can authenticate with the Oz by Warp GitHub App. Alternatively, use `oz login` for user-authenticated CLI runs. For more details on creating and using API keys, see [API Keys](/reference/cli/api-keys/). @@ -244,7 +244,7 @@ All triggers and instructions used by cloud agents are defined and controlled by Because triggers and instructions are configured by your team, the credits consumed when an agent runs are billed according to the model above: -* **Build, Max, Business** - User-triggered runs draw from the triggering user's pools (plan-included credits, then their add-on credits). Team API key and scheduled cloud agent runs are billed to the team owner (the owner's plan-included credits, then the owner's add-on credits, subject to the team-wide spend cap when auto-reload is on). +* **Build, Max, Business** - User-triggered runs draw from the triggering user's pools (plan-included credits, then their add-on credits). Agent API key and scheduled cloud agent runs are billed to the team owner (the owner's plan-included credits, then the owner's add-on credits, subject to the team-wide spend cap when auto-reload is on). * **Enterprise** - All runs draw from the team-scoped credit pool, per your Enterprise contract terms. It's the team's responsibility to manage triggers, confirm they behave as intended, and monitor usage. Reviewing triggers, prompts, and agent behavior periodically helps ensure that credit usage aligns with expectations. diff --git a/src/content/docs/enterprise/support-and-resources/billing.mdx b/src/content/docs/enterprise/support-and-resources/billing.mdx index 46638e3f..39ccbeca 100644 --- a/src/content/docs/enterprise/support-and-resources/billing.mdx +++ b/src/content/docs/enterprise/support-and-resources/billing.mdx @@ -37,7 +37,7 @@ Cloud agents consume AI credits for inference, compute credits for the sandbox t On Enterprise plans, local and cloud agent usage both draw from the same team credit pool across all three credit types (AI credits, compute credits, and platform credits). The credit type a run consumes depends on what infrastructure it uses, not on whether it's local or cloud. -For team API key runs (e.g., CI/CD pipelines, scheduled tasks), credits also draw from the team's shared pool since these runs are not tied to any individual user. +For Agent API key runs (e.g., CI/CD pipelines, scheduled tasks), credits also draw from the team's shared pool since these runs are not tied to any individual user. For more details, see [Access, Billing, and Identity](/agent-platform/cloud-agents/team-access-billing-and-identity/). diff --git a/src/content/docs/enterprise/team-management/admin-panel.mdx b/src/content/docs/enterprise/team-management/admin-panel.mdx index 56bd4b25..32320766 100644 --- a/src/content/docs/enterprise/team-management/admin-panel.mdx +++ b/src/content/docs/enterprise/team-management/admin-panel.mdx @@ -252,7 +252,7 @@ Configure cloud agent settings for your team, including GitHub authorization for **Enabled GitHub Orgs** -The **Enabled GitHub Orgs** setting associates your Warp team with one or more GitHub App installations, enabling cloud agents initiated with a [team API key](/reference/cli/api-keys/) to clone repositories and open pull requests using the Oz by Warp GitHub App. +The **Enabled GitHub Orgs** setting associates your Warp team with one or more GitHub App installations, enabling cloud agents initiated with an [Agent API key](/reference/cli/api-keys/) to clone repositories and open pull requests using the Oz by Warp GitHub App. To configure: @@ -268,7 +268,7 @@ To configure: The organizations and repository access shown here reflect the Oz by Warp GitHub App installation scope, which is configured in [GitHub settings](https://github.com/settings/installations). To change which repositories the app can access, edit the installation directly in GitHub. :::note -This setting controls GitHub access for team API key runs only. Runs triggered by individual users (via personal API key, Slack, or Linear) continue to use that user's personal GitHub token. For more details, see [Team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization). +This setting controls GitHub access for Agent API key runs only. Runs triggered by individual users (via `oz login`, the Warp app, Slack, or Linear) continue to use that user's personal GitHub token. For more details, see [Team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization). ::: ## Multi-admin functionality diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/external-authentication-required.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/external-authentication-required.mdx index 72433c1e..3d709752 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/external-authentication-required.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/external-authentication-required.mdx @@ -101,7 +101,7 @@ This error includes extra fields beyond the standard response format: 2. Ensure the app has access to all repositories listed in `inaccessible_repos`. 3. Retry the task. -If you are using a **team API key** bound to an [agent identity](/agent-platform/cloud-agents/agents/), ensure the Warp GitHub App is installed on the organization that owns the repositories. +If you are using an **Agent API key** bound to an [agent identity](/agent-platform/cloud-agents/agents/), ensure the Warp GitHub App is installed on the organization that owns the repositories. ### Account matching failed diff --git a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/insufficient-credits.mdx b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/insufficient-credits.mdx index f7133cbf..1ced74b6 100644 --- a/src/content/docs/reference/api-and-sdk/troubleshooting/errors/insufficient-credits.mdx +++ b/src/content/docs/reference/api-and-sdk/troubleshooting/errors/insufficient-credits.mdx @@ -2,7 +2,7 @@ title: insufficient_credits description: >- The principal billed for the run has no remaining credits. Top up the - right pool — the triggering user's, or the team owner's for team API + right pool — the triggering user's, or the team owner's for Agent API key and scheduled runs — to continue. --- @@ -11,7 +11,7 @@ The `insufficient_credits` error occurs when the principal billed for a cloud ag On self-serve plans (Build, Max, Business), the billed principal depends on how the run was triggered: * **User-triggered runs** draw from the triggering user's pool: plan-included credits first, then their user-scoped add-on credits. -* **Team API key and scheduled runs** draw from the team owner's pool: the owner's plan-included credits first, then the owner's add-on credits. +* **Agent API key and scheduled runs** draw from the team owner's pool: the owner's plan-included credits first, then the owner's add-on credits. When both pools are depleted and [auto-reload](/support-and-community/plans-and-billing/add-on-credits/) is off, new runs return this error. On Enterprise plans, runs draw from the team-scoped credit pool per your contract — contact your account manager when the pool is exhausted. @@ -30,7 +30,7 @@ When both pools are depleted and [auto-reload](/support-and-community/plans-and- This error is returned when: * A user-triggered run runs out of the user's plan-included credits and their user-scoped add-on credits. -* A team API key or scheduled run runs out of the team owner's plan-included credits and the owner's add-on credits. +* An Agent API key or scheduled run runs out of the team owner's plan-included credits and the owner's add-on credits. * Auto-reload is off, or auto-reload is on but the team-wide monthly spend cap has been reached. For the full waterfall, see [How are cloud agent runs on team plans billed when no individual user triggered them?](/support-and-community/plans-and-billing/pricing-faqs/#how-are-cloud-agent-runs-on-team-plans-billed-when-no-individual-user-triggered-them) in the Pricing FAQs. @@ -61,7 +61,7 @@ The fix depends on which principal was billed. 2. Alternatively, enable auto-reload, subject to your team's monthly spend cap. 3. Retry the failed operation. -**For team API key or scheduled runs (the team owner's pool was exhausted):** +**For Agent API key or scheduled runs (the team owner's pool was exhausted):** 1. The team owner tops up their pool: purchase add-on credits or wait for the monthly refresh. 2. If auto-reload is on but the team-wide spend cap was reached, an admin can raise the cap in **Settings** > **Billing and usage**. @@ -73,7 +73,7 @@ If you are not a team admin or the team owner, contact them to top up the right ## Related -* [Access, billing, and identity permissions](/agent-platform/cloud-agents/team-access-billing-and-identity/) — Credit billing for individual and team API key runs. +* [Access, billing, and identity permissions](/agent-platform/cloud-agents/team-access-billing-and-identity/) — Credit billing for individual and Agent API key runs. * [Add-on credits](/support-and-community/plans-and-billing/add-on-credits/) — Purchase additional credits and configure auto-reload. * [Platform credits](/support-and-community/plans-and-billing/platform-credits/) — The third credit bucket alongside AI credits and compute credits. * [Cloud Agents Overview](/agent-platform/cloud-agents/overview/) — Billing and plan requirements for cloud agents. diff --git a/src/content/docs/reference/cli/api-keys.mdx b/src/content/docs/reference/cli/api-keys.mdx index c9207226..99ce3dcc 100644 --- a/src/content/docs/reference/cli/api-keys.mdx +++ b/src/content/docs/reference/cli/api-keys.mdx @@ -10,25 +10,29 @@ API keys let the Oz CLI and cloud agents authenticate without human interaction. ## Creating API keys -You can create an API key from your settings in Warp: +For programmatic Oz usage, create an **Agent API key**. Agent API keys are bound to an [agent identity](/agent-platform/cloud-agents/agents/), which lets automated runs execute as a team-scoped agent instead of a person. + +Older docs and examples may refer to **team API keys**. Agent API keys replace that model for Oz automation. If your workflow previously used a team API key, create an Agent API key for the **Default Service Account** agent identity. A key for **Default Service Account** is equivalent to the old team key behavior. + +You can create an Agent API key from your settings in Warp: 1. Click your profile photo in the top-right corner, then click **Settings**. 2. In the sidebar, expand **Cloud platform** and click **Oz Cloud API Keys**. 3. In the API Keys section, click **+ Create API Key**. 4. Name the key and choose an expiration (1 day, 30 days, 90 days, or never). -5. Select the key type: - * `Personal` - Tied to your individual Warp account - * `Team` - Tied to your team, not any individual user +5. Select the agent identity that should own runs authenticated with this key. + * Use **Default Service Account** for the same behavior as the previous team-scoped API keys. + * Use another agent identity when you want a specific bot account, scoped secrets, or workflow-specific attribution. :::note When an agent needs to make code changes (e.g., opening pull requests, pushing branches, or writing to a repository), you have two options: -* Use a **personal API key** to authenticate as you. The agent runs with your GitHub permissions, and code changes are attributed to your GitHub account. -* Use a **team API key** with [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) configured. The agent authenticates with the Oz by Warp GitHub App, and code changes are not attributed to any individual user. +* Use interactive user authentication, such as `oz login`, when the run should authenticate as you. The agent runs with your GitHub permissions, and code changes are attributed to your GitHub account. +* Use an **Agent API key** with [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) configured. The agent authenticates with the Oz by Warp GitHub App, and code changes are attributed to the agent identity rather than an individual user. ::: :::note -Team keys without GitHub App authorization are the right fit for automated workflows that don't require writing to GitHub, such as analysis, monitoring, or triage. +Agent API keys without GitHub App authorization are the right fit for automated workflows that don't require writing to GitHub, such as analysis, monitoring, or triage. ::: 6. Click **Create key**. @@ -39,14 +43,17 @@ Team keys without GitHub App authorization are the right fit for automated workf
API key management interface in Warp settings.
-## Personal vs team API keys +## Agent API keys and older key types + +Agent API keys are the current model for non-interactive Oz authentication. They are a superset of the previous team API keys because they can run as the team's default agent identity or as a specific agent identity you create for a workflow. -Warp supports two types of API keys, each with different billing and identity behavior: +Use the following mapping when updating older automation: -* **Personal API keys** - Cloud agent runs authenticate as you, just like running an agent from the Warp app or triggering one via Slack or Linear. On Build, Max, and Business plans, runs draw from your plan-included credits, then your add-on credits — both scoped to your individual user. On Enterprise plans, runs draw from the team-scoped credit pool, per your Enterprise contract terms. -* **Team API keys** - Cloud agent runs are not tied to any individual user. On Build, Max, and Business plans, Warp bills the team owner: the owner's plan-included credits, then the owner's add-on credits. With auto-reload off, the request is blocked when both pools are depleted (insufficient credits error). With auto-reload on, usage can trigger a reload on the owner's pool subject to the team-wide monthly spend cap. On Enterprise plans, team API key runs draw from the team-scoped credit pool. When [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) is configured, team key runs can also clone repositories and open pull requests using the Oz by Warp GitHub App. +* **Old team API key** - Create an Agent API key for **Default Service Account**. This preserves the same team-scoped automation behavior. +* **Workflow-specific team key** - Create or choose a named agent identity, then create an Agent API key for that identity. +* **Personal API key for interactive work** - Prefer `oz login` for local and remote user-authenticated CLI usage. For headless automation, use an Agent API key. -Team API keys are useful for fully automated workflows, CI/CD pipelines, and scheduled tasks where no specific user context is needed. For the full credit waterfall and how it interacts with add-on credits, see [Access, billing, and identity permissions](/agent-platform/cloud-agents/team-access-billing-and-identity/) and [add-on credits](/support-and-community/plans-and-billing/add-on-credits/). +On Build, Max, and Business plans, Agent API key runs are billed to the team owner: the owner's plan-included credits, then the owner's add-on credits. With auto-reload off, the request is blocked when both pools are depleted. With auto-reload on, usage can trigger a reload on the owner's pool subject to the team-wide monthly spend cap. On Enterprise plans, Agent API key runs draw from the team-scoped credit pool. For the full credit waterfall and how it interacts with add-on credits, see [Access, billing, and identity permissions](/agent-platform/cloud-agents/team-access-billing-and-identity/) and [add-on credits](/support-and-community/plans-and-billing/add-on-credits/). ## Authenticating with API keys @@ -75,7 +82,7 @@ The API Keys section in **Settings** > **Cloud platform** > **Oz Cloud API Keys* * **Name** - The name you assigned when creating the key * **Key** - A masked suffix (`wk-**xxxx`) to help identify the key -* **Scope** - Whether the key is Personal or Team +* **Agent** - The agent identity bound to the key * **Created** - When the key was created * **Last used** - When the key was last used for authentication * **Expires at** - The key's expiration date, or "Never" if it doesn't expire @@ -94,7 +101,8 @@ Deleted keys are immediately invalidated and cannot be recovered. Any services o * **Use environment variables** - Avoid passing API keys directly in commands where they may be logged or visible in shell history. * **Set appropriate expiration** - Use shorter expiration times for development and testing; consider longer durations for stable production workflows. -* **Use team keys for automation** - For CI/CD and scheduled tasks, team keys provide cleaner billing attribution and don't depend on any individual user's account. -* **Use personal keys or configure team GitHub authorization when agents need to write to GitHub** - Personal keys authenticate as you; team keys can also write to GitHub when [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) is configured via the Admin Panel. +* **Use Agent API keys for automation** - For CI/CD and scheduled tasks, Agent API keys provide cleaner billing attribution and don't depend on any individual user's account. +* **Use Default Service Account for legacy team-key workflows** - If a guide or script asks for a team API key, create an Agent API key for **Default Service Account** unless your team wants a more specific agent identity. +* **Configure team GitHub authorization when agents need to write to GitHub** - Agent API key runs can write to GitHub when [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) is configured via the Admin Panel. * **Rotate keys periodically** - Create new keys and retire old ones on a regular schedule to limit exposure from compromised credentials. * **Store securely** - Use secret managers (like 1Password CLI, HashiCorp Vault, or cloud provider secret services) rather than plain text files. diff --git a/src/content/docs/reference/cli/integration-setup.mdx b/src/content/docs/reference/cli/integration-setup.mdx index 97db4c3a..9b0bc148 100644 --- a/src/content/docs/reference/cli/integration-setup.mdx +++ b/src/content/docs/reference/cli/integration-setup.mdx @@ -178,14 +178,14 @@ You typically only need to handle this once per team, unless your repo access ch #### Team-level GitHub authorization -For automated workflows that use a [team API key](/reference/cli/api-keys/) (CI/CD pipelines, scheduled agents, SDK-triggered runs), you can configure team GitHub authorization so the agent authenticates with the Oz by Warp GitHub App instead of an individual's personal token. +For automated workflows that use an [Agent API key](/reference/cli/api-keys/) (CI/CD pipelines, scheduled agents, SDK-triggered runs), you can configure team GitHub authorization so the agent authenticates with the Oz by Warp GitHub App instead of an individual's personal token. -This requires a Warp team admin to enable the GitHub organization in the Admin Panel (**Settings** > **Admin Panel** > **Platform**). Once configured, tasks initiated with a team API key can clone repos and open pull requests using the GitHub App installation token. +This requires a Warp team admin to enable the GitHub organization in the Admin Panel (**Settings** > **Admin Panel** > **Platform**). Once configured, tasks initiated with an Agent API key can clone repos and open pull requests using the GitHub App installation token. For full setup instructions, see [Team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization). :::note -**Using API keys:** Personal API keys authenticate as you, so the agent runs with your GitHub permissions and code changes are attributed to your account. Team API keys with [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) configured use the GitHub App token instead. +**Using API keys:** Agent API keys with [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) configured use the GitHub App token instead of an individual's personal token. Use `oz login` for local or remote user-authenticated CLI runs that should use your GitHub permissions. ::: --- diff --git a/src/content/docs/reference/cli/quickstart.mdx b/src/content/docs/reference/cli/quickstart.mdx index de2a145c..a3c61e07 100644 --- a/src/content/docs/reference/cli/quickstart.mdx +++ b/src/content/docs/reference/cli/quickstart.mdx @@ -39,7 +39,7 @@ Interactive login works on both **local** and **remote** machines, and does not export WARP_API_KEY="wk-..." ``` -In the Warp app, create an API key in **Settings** > **Cloud platform** > **Oz Cloud API Keys**. See [API Keys](/reference/cli/api-keys/) for guidance on personal vs. team keys and security best practices. +In the Warp app, create an Agent API key in **Settings** > **Cloud platform** > **Oz Cloud API Keys**. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for guidance on Agent API keys and security best practices. ::: ## 3. Run an agent diff --git a/src/content/docs/support-and-community/plans-and-billing/add-on-credits.mdx b/src/content/docs/support-and-community/plans-and-billing/add-on-credits.mdx index 4fa79bd4..3799df4e 100644 --- a/src/content/docs/support-and-community/plans-and-billing/add-on-credits.mdx +++ b/src/content/docs/support-and-community/plans-and-billing/add-on-credits.mdx @@ -81,7 +81,7 @@ Team admins manage add-on credit settings for the team in **Settings** > **Billi * **Auto-reload** — When enabled, the admin selects an add-on credit denomination for the team. Warp automatically purchases that denomination for any user whose add-on credit balance drops below 100 credits, subject to the team-wide spend cap. While auto-reload is on, individual users cannot purchase add-on credits manually. * **Manual purchases** — When auto-reload is off, eligible team members can purchase add-on credits for themselves, as long as the team stays below the team-wide spend cap. -For how cloud agent runs that aren't initiated by a specific team member (scheduled runs, team API key runs) are billed, see [How are cloud agent runs on team plans billed when no individual user triggered them?](/support-and-community/plans-and-billing/pricing-faqs/#how-are-cloud-agent-runs-on-team-plans-billed-when-no-individual-user-triggered-them) in the Pricing FAQs. +For how cloud agent runs that aren't initiated by a specific team member (scheduled runs, Agent API key runs) are billed, see [How are cloud agent runs on team plans billed when no individual user triggered them?](/support-and-community/plans-and-billing/pricing-faqs/#how-are-cloud-agent-runs-on-team-plans-billed-when-no-individual-user-triggered-them) in the Pricing FAQs. ### Plan changes and cancellations diff --git a/src/content/docs/support-and-community/plans-and-billing/credits.mdx b/src/content/docs/support-and-community/plans-and-billing/credits.mdx index 4819d112..7ce74802 100644 --- a/src/content/docs/support-and-community/plans-and-billing/credits.mdx +++ b/src/content/docs/support-and-community/plans-and-billing/credits.mdx @@ -161,6 +161,6 @@ For a full breakdown of how platform credits work, see [platform credits](/suppo ### Cloud agent runs on team plans -Cloud agent runs that aren't initiated by a specific team member — for example, scheduled runs or runs triggered through a team API key — follow plan-specific billing rules. On self-serve plans (Build, Max, Business), these runs are billed to the team owner: the owner's plan-included credits first, then their add-on credits. With auto-reload off, the request is blocked when both pools are depleted (insufficient credits error). With auto-reload on, usage can trigger a reload on the owner's pool subject to the team-wide spend cap. On Enterprise plans, these runs draw from the team-scoped credit pool per your contract. +Cloud agent runs that aren't initiated by a specific team member — for example, scheduled runs or runs triggered through an Agent API key — follow plan-specific billing rules. On self-serve plans (Build, Max, Business), these runs are billed to the team owner: the owner's plan-included credits first, then their add-on credits. With auto-reload off, the request is blocked when both pools are depleted (insufficient credits error). With auto-reload on, usage can trigger a reload on the owner's pool subject to the team-wide spend cap. On Enterprise plans, these runs draw from the team-scoped credit pool per your contract. For the full waterfall, see [How are cloud agent runs on team plans billed when no individual user triggered them?](/support-and-community/plans-and-billing/pricing-faqs/#how-are-cloud-agent-runs-on-team-plans-billed-when-no-individual-user-triggered-them) in the Pricing FAQs. diff --git a/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx b/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx index 5aed7023..8ece5833 100644 --- a/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx +++ b/src/content/docs/support-and-community/plans-and-billing/pricing-faqs.mdx @@ -189,10 +189,10 @@ Auto-reload can be enabled, paused, or reconfigured at any time in **Settings** ### How are cloud agent runs on team plans billed when no individual user triggered them? -Some cloud agent runs aren't initiated by a specific team member — for example, scheduled runs or runs triggered through a team API key. On self-serve plans (Build, Max, Business), these runs are billed to the **team owner**. +Some cloud agent runs aren't initiated by a specific team member — for example, scheduled runs or runs triggered through an Agent API key. On self-serve plans (Build, Max, Business), these runs are billed to the **team owner**. :::caution -Team owners: scheduled runs and runs triggered through a team API key draw from your personal credit pool. If auto-reload is enabled on your account, automated jobs can consume your add-on credits and count toward your spend cap. Review your auto-reload settings and team-wide spend cap in **Settings** > **Billing and usage** before relying on scheduled or API-key-triggered cloud agents. +Team owners: scheduled runs and runs triggered through an Agent API key draw from your personal credit pool. If auto-reload is enabled on your account, automated jobs can consume your add-on credits and count toward your spend cap. Review your auto-reload settings and team-wide spend cap in **Settings** > **Billing and usage** before relying on scheduled or API-key-triggered cloud agents. ::: The waterfall on the owner's account is: