Workspaces

A workspace is your team on Amp. It holds your members, the threads they create, the projects they work in, and one shared bill. It is also where you configure Amp once for everyone: plugins, skills, agents, secrets, MCP servers, and model routing set at the workspace level apply to every member.

Without a workspace, you use Amp on your own: your threads are private, your credits are yours, and your settings only affect you. A user belongs to at most one workspace.

Why Create a Workspace

Create a workspace when more than one person on your team uses Amp. You get:

• Shared threads. Threads are visible to the whole workspace by default, so you can read how a teammate solved a problem, search each other’s threads, and point the agent at them as context. Tag a teammate with @ in a thread to pull them in and pair on the live orb, and agents in the same workspace can message each other.
• Shared projects. A workspace project is visible to every member, and each member’s orbs get the project’s setup scripts and secrets. See Projects.
• One bill. Workspace credits are pooled and shared. Admins buy credits, manage the payment method, and can manage member tiers.
• Configure Amp once. Workspace plugins, skills, agents, secrets, MCP servers, and model provider keys load for every member without each person setting them up.
• Policies. Admins decide whether threads can be shared outside the workspace and can require passkeys. Enterprise workspace admins can also forbid personal model provider keys.

Create a Workspace

Open Workspace Settings and fill in Create a Workspace. You choose a display name and a short name. The short name becomes the workspace URL, ampcode.com/workspaces/<short-name>. If you already have threads, Amp asks whether to share them with the new workspace.

You become the workspace’s first admin. If you have personal paid credits, you can choose to move them into the workspace pool; otherwise they stay on your account.

To join an existing workspace instead, ask a member to invite you. The invitation shows up on the same page and in your email. If your company uses SSO, sign in with your work email and Amp adds you to the workspace automatically.

Invite Members

Open the Members section of workspace settings. Admins can invite people by email, create a shareable invite link with an expiry and a use limit, and change members’ roles. Admins can also let regular members send email invitations.

There are two roles:

• Member: uses everything the workspace provides and sees shared threads and projects.
• Admin: everything a member can do, plus managing members, billing, settings, and policies. Admins can also see members’ private threads.

A workspace with at least one current user on an active Megawatt or Gigawatt tier can set up SAML or OIDC SSO. Enterprise workspaces can set up SSO without a paid member tier. They can also give members narrower roles such as Billing Manager, Auditor, and Group Manager, and provision members and groups with directory sync.

Personal vs. Workspace

Most things you can configure in Amp exist at two levels. The Personal Settings and Workspace Settings tabs at the top of the settings page switch between them. The rule of thumb:

• Things you add (plugins, skills, agents, secrets, MCP servers, model provider keys, domains) exist at both levels and combine. Everyone gets the workspace’s, and you get your own on top. When names collide, your personal one wins, except for remote MCP servers: for the same server ID, project settings take precedence over workspace settings, then personal settings.
• Things admins set as policy (sharing, security, what members may use) apply to everyone and override the personal setting.
• Things that are owned (threads, projects, credits) have one owner, either you or the workspace.

Workspace Settings

Admins manage the workspace from Workspace Settings. Members can open the same page and see the sections that apply to them.

• Workspace: name and icon, the shared balance, member tiers, and high-level policies such as whether members can use orbs or share threads outside the workspace.
• Members: invitations, invite links, roles, removal, and install instructions shown to members.
• Groups: Enterprise workspace groups, their members, and their thread visibility settings.
• Integrations & MCP: Slack, GitHub, and other connectors, whether members may use them, and MCP servers shared with every member.
• Billing: payment method, invoices, and credit purchases.
• Usage: credit usage across the workspace, by member and over time. See Usage.
• Security: passkey requirements, data retention, and other policies.
• Instructions: guidance every member’s agent receives.
• Model Routing: the workspace’s model provider keys and whether members may use their own.
• Secrets & Env Vars: values available in every member’s orbs.
• Plugins, Skills, Prompts, Agents: the workspace repositories that load for every member. See Global Plugins & Skills.
• Service Accounts: workspace-owned accounts for CI pipelines, bots, and GitHub event subscriptions. See Service Accounts.
• Projects: whether members can create workspace projects, defaults for new projects such as ship behavior, and which projects override them. The default orb size is under Orbs.
• Domains: custom domains for portals and the workspace default.

Service Accounts

A service account is a workspace-owned account that is not tied to a single user. Use one for work that belongs to the team, such as reviewing every pull request or running Amp in CI. Its usage is billed to the workspace. Service accounts need an Enterprise workspace, or a Team workspace with a payment method on file, and only admins can create and manage them.

Create one in Workspace Settings → Service Accounts. Turn on Generate an API Key if a script or CI pipeline will sign in as the account; Amp shows the key only once. Set it as AMP_API_KEY, and threads the CLI or SDK starts belong to the service account:

AMP_API_KEY="$SERVICE_ACCOUNT_API_KEY" \
  amp -ox "CI failed on main. Find the cause and open a pull request with a fix." \
  --project acme/widget

To give the account GitHub access, click Connect › GitHub on its row and sign in as the GitHub account it should act as.

With a linked GitHub account, admins can create orb spawners that start each orb as the service account, under Event Subscriptions on the same settings page or by asking Puck, which asks an admin to confirm.

To let the team work with a service account, an admin turns on Members Can Drive Threads for it. Members then see the account’s threads in a sidebar section and can start threads as it under ⋮ › Run As in the new thread composer. Every new orb thread the account owns, however it starts, including with its API key, is shared with the workspace with multiplayer on, so any member can prompt it. Turning the switch on does not change existing threads. Turning it off ends multiplayer on all of the account’s threads, so members cannot use Run As or prompt them. An admin can still turn multiplayer on for one thread from its Share menu.

Admins can also have Slack requests in public channels run as a service account; see Integrations › Slack.

Anyone who can prompt a service account’s threads, or who holds its API key, can use everything the account is connected to. Only add credentials you are comfortable giving to all members of your workspace. Choose Disable in the account’s ⋮ menu to stop its key and credentials at once.

Usage

Admins, Auditors, and Usage Viewers see where the workspace’s credits go under Usage in workspace settings. All dates are in UTC.

Usage Breakdown charts spend over time and totals it in a table. Choose what to break it down by:

• Category: models, orbs, and other features such as web search
• Model: the model that served each request
• Mode: the thread’s agent mode, such as Medium or High
• Member: who used it
• Reasoning: the reasoning effort of each request. Usage from before October 2026 shows Not recorded.
• Speed: Standard, Fast, or Plaid serving
• Orb Size: the orb size, such as a1.medium
• Provider: Amp, or the model provider key that served the request

Filter to one member, switch between spend, tokens, and orb hours, and group by day, week, or month. Spend includes Amp fees, even on your own provider keys. Tier-Covered is usage paid for by members’ paid tiers, which does not reduce the workspace balance.

Export as CSV downloads numbers, not formatted text, for spreadsheets and BI tools:

• Totals and per period for the current breakdown
• Member Summary: each member’s spend, tier-covered usage, model, orb, and fast spend, tokens, orb hours, and their most-used mode and model. Use it to decide which members belong on a paid tier.
• All Usage per Thread and Day: one row per day, member, thread, mode, model, speed, reasoning effort, provider, and orb size, with tokens, orb hours, and cost. It covers at most the last 30 days. Private thread titles are included only for admins and Auditors who can audit them. When the workspace requires passkey authentication, Amp asks for your passkey before exporting.

Billing

A Team workspace can mix pooled credits with paid tiers for individual members that the workspace pays for. Enterprise workspaces use pooled credits and do not use paid Amp tiers.

Workspace credits are pooled and shared by all workspace members. Admins (or Enterprise Billing Managers) purchase credits for the pool and manage the payment method.

• When you create or join a workspace, you can choose to move your personal paid credits to the workspace pool. Moved credits are not returned if you leave or are removed. Credits you keep stay on your account and are used after you leave the workspace or it stops paying for you. In a Team workspace, your personal free credits are used before the workspace pool. If you join an Enterprise workspace while you belong to no other workspace, your personal free credit balance is cleared.
• Purchased credits expire twelve months after purchase.
• When an admin deletes a workspace, the remaining paid credits move to that admin’s personal balance. Remaining free credits are lost.
• In a Team workspace, paid tiers stay assigned to individual members. The next renewal or upgrade uses the workspace’s billing. If the workspace paid for the current period and you leave, it will not renew unless you resume with personal billing. Any remaining free free tier months stay unused until you resume. If you paid for the current period yourself, renewal continues with personal billing.
• When an admin deletes a workspace, paid tiers funded by that workspace remain active until their current periods end, but their renewals stop. Tiers paid personally or by another workspace continue.
• Paid tier charges use the first source that covers the full amount: your eligible personal free credits, workspace free credits, workspace paid credits, then the workspace’s payment method.
• Team workspace members can start, change, cancel, and resume their own paid tiers, paid from workspace credits or the workspace’s payment method. Admins and Billing Managers can also manage any member’s tier.
• Team workspace admins can change a member’s tier from the Members list. They can also set an optional base tier of Megawatt or Gigawatt for all members. Service accounts never get a base tier seat and do not count toward its price.

Pay for Members

A Team workspace pays for its members’ usage and paid tiers by default. Admins and Billing Managers can turn off Pay for Members in workspace Billing. Members then keep collaborating in the workspace but pay for themselves:

• Members’ usage comes from their own paid tier and personal credits, never the workspace pool.
• Members start and renew their own paid tiers with their own payment method. A tier the workspace already paid for stays active until its period ends, then members can resume it with personal billing.
• The workspace still pays for its service accounts and workspace Boxes.
• Turning it off removes the base tier.

Enterprise workspaces always pay for their members, so the setting does not appear there.

Delete a Workspace

Admins delete a Team workspace from Security in workspace settings. Deletion is permanent and removes:

• Every thread in the workspace. This includes every thread a member created while in the workspace, even private threads and threads in personal projects. Threads stay with the workspace when a member leaves, so leaving first does not keep them. The admin who deletes the workspace can keep their own threads (see below). Other members can export the threads they need before the workspace is deleted.
• Workspace projects and their Amp-hosted repositories. Personal projects are not deleted.

The admin who deletes the workspace can choose Move my threads to my personal account. It is on by default. Their threads then move to their personal account instead of being deleted. Moved threads become private, except threads shared by public link. Threads in workspace projects are archived and become read-only, because their project is deleted.

Threads you made before joining and did not move to the workspace when you joined stay on your personal account. For what happens to credits and paid tiers, see Billing.

Enterprise

Enterprise uses custom pricing and adds controls and support for larger organizations. To upgrade, contact the Amp team. Enterprise adds:

• SCIM directory sync for provisioning members and groups
• Narrower roles: Auditor, Billing Manager, Group Manager, Usage Viewer, Global Plugin Manager, and Model Provider Key Manager
• Groups and thread visibility controls for sharing threads with part of the workspace
• Entitlements for per-user usage quotas
• Allowed Models to choose which models members can use
• An MCP registry allowlist
• Controls to stop members from using personal model provider keys

All enterprise workspaces are covered under our minimal data retention policy.