diff --git a/.agents/skills/missing_docs/references/feature_surface_map.md b/.agents/skills/missing_docs/references/feature_surface_map.md index fe23dd7d..955b5305 100644 --- a/.agents/skills/missing_docs/references/feature_surface_map.md +++ b/.agents/skills/missing_docs/references/feature_surface_map.md @@ -207,6 +207,10 @@ SoloUserByok -> src/content/docs/agent-platform/inference/bring-your-own-api-key SuperGrok -> src/content/docs/agent-platform/inference/bring-your-own-api-key.mdx # Custom model routers (Settings > AI > Custom Routers) surface in the model picker. CustomModelRouters -> src/content/docs/agent-platform/inference/model-choice.mdx +# Gemini Enterprise (GEAP) BYOLLM: routes eligible Google models through the +# customer's Google Cloud project using workload identity federation. Documented +# alongside AWS Bedrock as the second BYOLLM host. +GeminiEnterprise -> src/content/docs/enterprise/enterprise-features/bring-your-own-llm.mdx # Billing & Usage settings page (redesigned) BillingAndUsagePageV2 -> src/content/docs/support-and-community/plans-and-billing/index.mdx @@ -423,12 +427,17 @@ GET /memory_stores/{uid}/memories/{memoryUid}/versions -> gated:AIMemories # - /status: show session and account status # - /clear: clear the transcript and start a new conversation # - /statusline: configure the Warp Agent CLI statusline (agents.statusline, internal) -# - /add-api-key, /clear-provider-api-key: store/remove a model-provider API key +# - /reset-statusline: restore the statusline to its default items and ordering +# - /api-keys: view and manage model-provider API keys. This replaced the paired +# /add-api-key and /clear-provider-api-key commands, whose entries are pruned. +# - /vim-mode: toggle Vim mode in the Warp Agent CLI input. The GUI equivalents are +# documented separately (input editor and code editor Vim keybindings). /status -> internal /clear -> internal /statusline -> internal -/add-api-key -> internal -/clear-provider-api-key -> internal +/reset-statusline -> internal +/api-keys -> internal +/vim-mode -> internal # TUI-only color-theme picker (Warp Agent CLI surface, SlashCommandSurfaces::TuiOnly # in static_commands/commands.rs). It sets the Warp Agent CLI theme # (appearance.theme, mapped internal below) and isn't present in the GUI, so it @@ -474,6 +483,13 @@ appearance.zero_state.object -> internal appearance.zero_state.rotation_period_seconds -> internal appearance.zero_state.extrusion_depth -> internal +# Warp Agent CLI-only (crates/warp_tui) push-to-talk modifier for voice input +# (surface: SettingSurfaces::TUI in app/src/settings/tui_voice.rs). It isn't +# present in the GUI settings UI, so it isn't documented in the all-settings +# reference. The GUI equivalent is agents.voice.voice_input_toggle_key, which is +# documented under the [agents.voice] section. +agents.voice.voice_input_hold_key -> internal + ## Unlisted docs pages to ignore # Pages intentionally absent from src/sidebar.ts (one slug per line, e.g. diff --git a/src/content/docs/agent-platform/capabilities/agent-profiles-permissions.mdx b/src/content/docs/agent-platform/capabilities/agent-profiles-permissions.mdx index ac8e343f..b297f191 100644 --- a/src/content/docs/agent-platform/capabilities/agent-profiles-permissions.mdx +++ b/src/content/docs/agent-platform/capabilities/agent-profiles-permissions.mdx @@ -143,7 +143,7 @@ During an Agent interaction, you can give the Agent full autonomy for the curren :::caution _Run until completion_ is the purest form of “YOLO” mode: the Agent proceeds without asking for confirmation, and by default it also runs commands that match your command denylist. -To keep your denylist in force during _Run until completion_, turn off **Allow auto-approve to bypass command denylist** in **Settings** > **Agents** > **Oz** > **Input**. Denylist rules your team enforces through the [Admin Panel](/enterprise/team-management/admin-panel/) always require approval and are never bypassed. +To keep your denylist in force during _Run until completion_, turn off **Allow auto-approve to bypass command denylist** in **Settings** > **Agents** > **Warp Agent** > **Input**. Denylist rules your team enforces through the [Admin Panel](/enterprise/team-management/admin-panel/) always require approval and are never bypassed. ::: --- diff --git a/src/content/docs/agent-platform/capabilities/slash-commands.mdx b/src/content/docs/agent-platform/capabilities/slash-commands.mdx index eb39fea1..f53a0bfc 100644 --- a/src/content/docs/agent-platform/capabilities/slash-commands.mdx +++ b/src/content/docs/agent-platform/capabilities/slash-commands.mdx @@ -18,7 +18,7 @@ As you type, the menu filters results in real time, making it easy to find and r Warp currently supports the following built-in Slash Commands: -
Slash CommandDescription
/add-mcpAdd a new MCP server.
/add-promptAdd a new Agent Prompt in Warp Drive.
/add-ruleAdd a new Global Rule for the Agent.
/agentStart a new agent conversation. Optionally include a prompt to send immediately.
/changelogOpen the latest Warp changelog.
/cloud-agentStart a new cloud agent conversation. {'*'}
/compactFree up context by summarizing conversation history.
/compact-andCompact the current conversation and then send a follow-up prompt.
/conversationsOpen conversation history.
/costToggle credit usage details in the current conversation.
/create-environmentCreate a Warp Environment (Docker image + repos) via guided setup. {'*'}
/create-new-projectHave the Agent walk you through creating a new coding project. {'*'}
/environmentSwitch the environment for the current cloud agent conversation.
/export-to-clipboardExport the current conversation to clipboard in markdown format.
/export-to-fileExport the current conversation to a markdown file.
/feedbackOpen the static feedback experience. See Using /feedback in Warp for details.
/forkForks the current conversation into a new thread with the full context and history of the original.

You can optionally include a prompt that will be sent immediately in the forked conversation.
/fork-and-compactForks the current conversation and automatically compacts the forked version.

Useful when you want a fresh, summarized starting point that preserves relevant context while trimming the rest.
/fork-fromOpen a searchable menu to fork the conversation from a specific query. Select a query to create a fork that includes everything up to that point.
/harnessSwitch the harness for the current cloud agent conversation.
/hostSwitch the execution host for the current cloud agent conversation.
/indexIndex the current codebase using Codebase Context.
/initIndex the current codebase and generate an AGENTS.md file. {'*'}
/modelSwitch the base agent model for the current conversation.
/newStart a new agent conversation (alias for /agent).
/open-code-reviewOpen the code review pane.
/open-fileOpen a file for editing in Warp's code editor.
/open-mcp-serversView the status of your MCP servers.
/open-project-rulesOpen the Project Rules file (AGENTS).
/open-repoSwitch to another indexed repository.
/open-rulesView all of your global and project rules.
/open-settings-fileOpen the Warp settings file (settings.toml) in Warp's code editor.
/open-skillOpen an interactive menu to browse and edit project or global skills.
/orchestrateBreak a task into subtasks and run them in parallel with multiple agents. {'*'}
/planPrompt the Agent to do some research and create a plan for a task.
/profileSwitch the active execution profile.
/promptsSearch saved prompts.
/queueQueue a prompt to send after the agent finishes responding. See Prompt Queueing.
/rename-conversationRename the current conversation.
/rename-tabRename the current tab. Include the new tab name as an argument (for example, /rename-tab deploy).
/rewindRewind to a previous point in the conversation.
/skillsInvoke a skill from a searchable menu.
/usageOpen billing and usage settings.
+
Slash CommandDescription
/add-mcpAdd a new MCP server.
/add-promptAdd a new Agent Prompt in Warp Drive.
/add-ruleAdd a new Global Rule for the Agent.
/agentStart a new agent conversation. Optionally include a prompt to send immediately.
/changelogOpen the latest Warp changelog.
/cloud-agentStart a new cloud agent conversation. {'*'}
/compactFree up context by summarizing conversation history.
/compact-andCompact the current conversation and then send a follow-up prompt.
/conversationsOpen conversation history.
/copy-debugging-idCopy debugging information for the current conversation, such as when sharing details with Warp support.
/costToggle credit usage details in the current conversation.
/create-environmentCreate a Warp Environment (Docker image + repos) via guided setup. {'*'}
/create-new-projectHave the Agent walk you through creating a new coding project. {'*'}
/environmentSwitch the environment for the current cloud agent conversation.
/export-to-clipboardExport the current conversation to clipboard in markdown format.
/export-to-fileExport the current conversation to a markdown file.
/feedbackOpen the static feedback experience. See Using /feedback in Warp for details.
/forkForks the current conversation into a new thread with the full context and history of the original.

You can optionally include a prompt that will be sent immediately in the forked conversation.
/fork-and-compactForks the current conversation and automatically compacts the forked version.

Useful when you want a fresh, summarized starting point that preserves relevant context while trimming the rest.
/fork-fromOpen a searchable menu to fork the conversation from a specific query. Select a query to create a fork that includes everything up to that point.
/harnessSwitch the harness for the current cloud agent conversation.
/hostSwitch the execution host for the current cloud agent conversation.
/indexIndex the current codebase using Codebase Context.
/initIndex the current codebase and generate an AGENTS.md file. {'*'}
/modelSwitch the base agent model for the current conversation.
/newStart a new agent conversation (alias for /agent).
/open-code-reviewOpen the code review pane.
/open-fileOpen a file for editing in Warp's code editor.
/open-mcp-serversView the status of your MCP servers.
/open-project-rulesOpen the Project Rules file (AGENTS).
/open-repoSwitch to another indexed repository.
/open-rulesView all of your global and project rules.
/open-settings-fileOpen the Warp settings file (settings.toml) in Warp's code editor.
/open-skillOpen an interactive menu to browse and edit project or global skills.
/orchestrateBreak a task into subtasks and run them in parallel with multiple agents. {'*'}
/planPrompt the Agent to do some research and create a plan for a task.
/profileSwitch the active execution profile.
/promptsSearch saved prompts.
/queueQueue a prompt to send after the agent finishes responding. See Prompt Queueing.
/rename-conversationRename the current conversation.
/rename-tabRename the current tab. Include the new tab name as an argument (for example, /rename-tab deploy).
/rewindRewind to a previous point in the conversation.
/skillsInvoke a skill from a searchable menu.
/usageOpen billing and usage settings.
:::caution Slash commands marked with a `*` consume credits to complete the task. diff --git a/src/content/docs/enterprise/enterprise-features/bring-your-own-llm.mdx b/src/content/docs/enterprise/enterprise-features/bring-your-own-llm.mdx index 3d811245..6fe80ef4 100644 --- a/src/content/docs/enterprise/enterprise-features/bring-your-own-llm.mdx +++ b/src/content/docs/enterprise/enterprise-features/bring-your-own-llm.mdx @@ -1,16 +1,23 @@ --- title: Bring Your Own LLM description: >- - Route Warp's agents through your AWS Bedrock models for billing control and - infrastructure flexibility. + Route Warp's agents through your own AWS Bedrock or Gemini Enterprise models + for billing control and infrastructure flexibility. --- -Warp supports **Bring Your Own LLM (BYOLLM)** for enterprise teams that need to run inference on their own cloud infrastructure. With BYOLLM, your team can use Warp's agents while routing inference through models hosted in your AWS Bedrock environment. +Warp supports **Bring Your Own LLM (BYOLLM)** for enterprise teams that need to run inference on their own cloud infrastructure. With BYOLLM, your team can use Warp's agents while routing inference through models hosted in your own cloud environment. This gives you control over cloud spend and model hosting, without changing how your team works in Warp. +## Supported hosts + +Warp supports two BYOLLM hosts. A team can enable either or both, and admins choose per host which models route through it. + +* **AWS Bedrock** - Routes Claude models through your AWS account. Interactive terminal sessions use each member's AWS CLI session credentials; cloud agent runs assume an IAM role via OIDC. +* **Gemini Enterprise** - Routes eligible Google models through your Google Cloud project. Warp mints short-lived Google credentials from each member's Warp session using workload identity federation, so members don't run a separate cloud login. + :::caution -BYOLLM currently supports **AWS Bedrock** only. Coming soon: Azure Foundry and Google Vertex support. +Azure Foundry support is not yet available. ::: :::note @@ -22,15 +29,16 @@ BYOLLM is only available on Warp's Enterprise plan. [Contact sales](https://www. * **Cloud-native credentials** - No long-lived API keys. Interactive terminal sessions use each user's AWS CLI session credentials; cloud agent runs assume an IAM role in your AWS account via OIDC. * **Admin-controlled IAM** - Admins define which IAM role(s) Warp can assume and which models are available via AWS Bedrock, with the ability to disable non-Bedrock model access entirely. * **Admin-enforced routing** - Team admins configure which models are available to users in AWS Bedrock, with the ability to disable non-Bedrock model access entirely. -* **Consolidated billing** - Inference costs are billed directly to your AWS account, leveraging existing cloud commitments. +* **Consolidated billing** - Inference costs are billed directly to your cloud account, leveraging existing cloud commitments. +* **Per-host enforcement** - For each host, admins either enforce it for every member or leave it to each member to opt in. ## How BYOLLM works {/* TODO: Add architecture diagram showing BYOLLM request flow (admin configures routing → user authenticates to AWS → Warp routes request → inference in customer AWS account) */} -When BYOLLM is enabled, Warp redirects inference calls to your AWS Bedrock environment instead of using model providers' direct APIs. +When BYOLLM is enabled, Warp redirects inference calls to your cloud environment instead of using model providers' direct APIs. -Here's the high-level flow: +Here's the high-level flow for AWS Bedrock. Gemini Enterprise follows the same shape, except that instead of a local cloud login, Warp exchanges the member's Warp session for Google credentials. See [Gemini Enterprise credentials](#gemini-enterprise-credentials). **Interactive terminal flow** @@ -56,18 +64,34 @@ BYOLLM uses **cloud-native IAM authentication**, not long-lived API keys: This approach ensures access management stays with your cloud provider, giving admins member-by-member control. +### Gemini Enterprise credentials + +Gemini Enterprise uses **Google Cloud workload identity federation** rather than a locally installed cloud CLI. Warp exchanges an identity token rooted in the member's Warp session for a Google access token: + +1. Warp issues an OIDC identity token for the signed-in member. +2. Warp exchanges that token at Google's Security Token Service for a federated access token, using the workload identity pool audience your admin configured. +3. If your admin also configured a service account, Warp calls Google's IAM Credentials API to mint an access token that impersonates that service account. Without a service account, Warp uses the federated token directly. +4. Warp signs inference requests to Gemini Enterprise with the resulting token. + +Access tokens are scoped to Google's `cloud-platform` scope and last one hour. Warp refreshes them ahead of expiry, and re-mints when your workspace settings change or when a request finds the stored token expired. + +Because the mint is rooted in a Warp session, Gemini Enterprise routing requires the member to be signed in to Warp. It's unavailable to anonymous or signed-out users. + ### Model availability -BYOLLM supports the intersection of models that Warp supports and models available on AWS Bedrock. Currently, only **Claude models** (Anthropic) are available through AWS Bedrock. OpenAI and Google models are not available on Bedrock. +BYOLLM supports the intersection of models that Warp supports and models your host makes available. + +* **AWS Bedrock** - Currently only **Claude models** (Anthropic) are available. OpenAI and Google models are not available on Bedrock. +* **Gemini Enterprise** - Eligible **Google models** route to your Google Cloud project. To determine which models you can use with BYOLLM: * [Model Choice](/agent-platform/inference/model-choice/) - Full list of Warp-supported models. * [Supported models in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-cards.html) - AWS Bedrock model availability. -A model must appear on both lists to be available through BYOLLM. +A model must be supported by both Warp and the host to be available through BYOLLM. -## Enabling BYOLLM +## Enabling BYOLLM with AWS Bedrock ### Prerequisites @@ -133,6 +157,53 @@ Run a test prompt in Warp using a model configured for BYOLLM routing. Verify: * The request completes successfully. * Logs appear in AWS CloudWatch. +## Enabling BYOLLM with Gemini Enterprise + +Gemini Enterprise has no local CLI step for members, so setup is entirely on the admin and Google Cloud side. + +### Prerequisites + +* You have admin access to Warp's [Admin Panel](/enterprise/team-management/admin-panel/) and to the Google Cloud project hosting Gemini Enterprise. +* You can create a workload identity pool and provider in that project, so Warp-issued identity tokens can be federated. + +### 1. Configure workload identity federation (cloud admin) + +Create a workload identity pool and an OIDC provider in your Google Cloud project that trusts Warp as the token issuer. This is what lets Warp exchange a member's Warp session for Google credentials without distributing keys. + +Note the full audience string for the provider. Warp needs it to perform the token exchange. + +If you want requests to run as a dedicated identity rather than the federated principal, also create a service account with access to Gemini Enterprise and grant the federated principal permission to impersonate it. + +For more detail, see Google's [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) documentation. + +### 2. Enable Gemini Enterprise for the workspace (admin) + +In the [Admin Panel](/enterprise/team-management/admin-panel/), enable Gemini Enterprise as an LLM host for your workspace and supply the workload identity audience from Step 1, plus the service account email if you created one. + +Choose how strictly the host applies: + +* **Enforce** - Every member routes eligible models through Gemini Enterprise. Members can't turn it off. +* **Respect user setting** - Each member decides. The host is off until they opt in. + +### 3. Opt in (team member) + +This step applies only when your admin chose **Respect user setting**. + +In the Warp app, go to **Settings** > **Agents** > **Warp Agent** and toggle **Use Gemini Enterprise credentials** on. Warp mints credentials immediately, so you don't need to restart Warp or run a cloud login. + +### 4. Validate + +Run a test prompt using a Google model that your admin routed through Gemini Enterprise, then confirm the request appears in your Google Cloud project's logs. + +### Troubleshooting Gemini Enterprise + +Warp reports the state of your Gemini Enterprise credentials in **Settings** > **Agents** > **Warp Agent**, alongside an action to refresh them. + +* **Unconfigured** - Your admin enabled the host but the workload identity audience is missing or blank. Ask your admin to add it in the Admin Panel. +* **Credentials fail to mint** - Confirm the workload identity provider trusts Warp as the token issuer, the audience string matches exactly, and the federated principal can impersonate the service account when one is configured. +* **Not signed in** - Gemini Enterprise credentials derive from your Warp session. Sign in to Warp, then refresh credentials. +* **Setting won't turn on** - If the toggle is missing or locked, your admin either hasn't enabled the host or has set it to **Enforce**, which leaves members no choice. + ## Enabling BYOLLM for cloud agents Cloud agents authenticate to AWS Bedrock differently from the local terminal flow above. Instead of relying on each user's AWS CLI session, Warp assumes an IAM role you provision in your AWS account using OIDC identity federation. @@ -338,14 +409,14 @@ However, when using BYOLLM: **BYOK (Bring Your Own API Key)** lets individual users add their own API keys for direct model provider access (e.g., Anthropic, OpenAI, Google). Warp stores keys locally on the user's device. -**BYOLLM (Bring Your Own LLM)** routes inference through your organization's cloud infrastructure (AWS Bedrock) using cloud-native IAM. Admins configure it at the admin level and it applies to the entire team. +**BYOLLM (Bring Your Own LLM)** routes inference through your organization's cloud infrastructure (AWS Bedrock or Gemini Enterprise) using cloud-native IAM. Admins configure it at the admin level and it applies to the entire team. Enterprise admins can also centrally manage BYOK itself: [team-managed API keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) let an admin configure shared provider keys and OpenAI-compatible endpoints that are stored server-side and work for both interactive requests and cloud agents. The table below compares BYOLLM with the self-serve, user-level form of BYOK. For a side-by-side comparison that also includes team-managed keys and endpoints, see [How team-managed providers differ from self-serve BYOK and BYOLLM](/enterprise/enterprise-features/team-managed-keys-and-endpoints/#how-team-managed-providers-differ-from-self-serve-byok-and-byollm). | Feature | BYOK | BYOLLM | | --- | --- | --- | | Configuration level | User | Admin/Team | -| Authentication | API keys (local) | IAM role assumed by Warp via OIDC | +| Authentication | API keys (local) | Cloud identity federated by Warp (AWS IAM role via OIDC, or Google workload identity) | | Billing | Direct to provider | Your cloud account | | Data locality | Provider infrastructure | Your cloud infrastructure | @@ -355,9 +426,13 @@ Auto model selection is disabled if an admin disables **any** Direct API model, When Direct API models remain enabled and BYOLLM is configured, Auto picks the best model for the task. If the selected model is also enabled for AWS Bedrock, the request routes through Bedrock; otherwise it routes through the Direct API. +### Do team members need a cloud CLI installed? + +It depends on the host. AWS Bedrock relies on your local AWS credential provider chain for interactive terminal sessions, so members need the AWS CLI and an `aws login`. Gemini Enterprise doesn't: Warp mints Google credentials from your Warp session, so members only need to be signed in to Warp. + ### Where does compute run and who pays? -Inference runs in **your AWS account**, which AWS bills directly. Warp does not consume AI credits for BYOLLM-routed inference. Cloud agent runs continue to consume platform and compute credits for orchestration. See [The three credit buckets](/support-and-community/plans-and-billing/platform-credits/#the-three-credit-buckets) for more. +Inference runs in **your cloud account** — your AWS account for Bedrock, or your Google Cloud project for Gemini Enterprise — which your cloud provider bills directly. Warp does not consume AI credits for BYOLLM-routed inference. Cloud agent runs continue to consume platform and compute credits for orchestration. See [The three credit buckets](/support-and-community/plans-and-billing/platform-credits/#the-three-credit-buckets) for more. ### What data does Warp store? Do you store our cloud credentials? diff --git a/src/content/docs/terminal/settings/all-settings.mdx b/src/content/docs/terminal/settings/all-settings.mdx index 1a1cdc43..5277b0c7 100644 --- a/src/content/docs/terminal/settings/all-settings.mdx +++ b/src/content/docs/terminal/settings/all-settings.mdx @@ -335,6 +335,7 @@ Settings for Warp's agents, including model behavior, permissions, knowledge, MC * `orchestration_message_display_mode` — How child-agent message bodies are displayed during [multi-agent runs](/platform/orchestration/multi-agent-runs/). Type: string. Default: `"always_collapse"`. Options: `"show_and_collapse"`, `"always_show"`, `"always_collapse"`. * `should_force_disable_cloud_handoff` — Whether to force-disable [local-to-cloud handoff](/platform/handoff/local-to-cloud/). Type: boolean. Default: `false`. * `should_force_disable_ampersand_handoff` — Whether to force-disable the `&` prefix that composes a prompt for cloud handoff. Type: boolean. Default: `false`. +* `auto_approve_bypasses_command_denylist` — Whether auto-approve and [Run until completion](/agent-platform/capabilities/agent-profiles-permissions/#run-until-completion) run commands that match your [command denylist](/agent-platform/capabilities/agent-profiles-permissions/#command-denylist) without asking for confirmation. Turn this off to keep your denylist in force during auto-approve. Denylist rules enforced through the [Admin Panel](/enterprise/team-management/admin-panel/) are never bypassed. Type: boolean. Default: `true`. ### Third-party (CLI agents)