AQ vs Amp: multiplayer by default vs a multiplayer mode on orbs

Published August 17, 2026 · by the AQ team

Choose AQ if you want your team working inside persistent, shared agent workspaces on infrastructure you control, with the agent CLIs your engineers already use. Choose Amp if you want one integrated agent that spawns an ephemeral cloud machine per task, picks its own models, and lets you open a thread to teammates for a week when you need help. The one-line difference: in Amp, multiplayer is a share mode you switch on per thread; in AQ, the shared workspace is the product.

The comparison matters because the two products now use the same word for different things. Amp shipped "Multiplayer" for its orbs on July 22, 2026; AQ has been built around the multiplayer workspace from the start. Which fits depends on whether collaborating on agent work is an exception in your team or the default.

AQ vs Amp at a glance

What is Amp?

Amp (ampcode.com) is Sourcegraph's AI coding agent. It runs as a CLI and a VS Code extension, threads sync to the web, and its signature design decision is having no model picker: Amp chooses and routes models itself.

Amp's center of gravity moved to orbs on June 30, 2026: ephemeral remote machines, managed by Amp, where the agent runs without supervision. Every new thread can get a fresh orb with the repository cloned and tools installed. Orbs bill by the minute, pause after about five idle minutes, cost nothing while paused, and come in sizes from tiny to xxlarge (base at launch: 32GB, 16 cores, $1.66 per hour). A rapid July release cycle added agent-to-agent messaging, Slack integration, self-scheduling, and event-driven orbs, then Multiplayer; Portals followed on August 6, 2026.

Multiplayer is the piece that overlaps most with AQ. From a thread's Share menu you can make its orb multiplayer: anyone in your Amp workspace can then join the thread, message the agent, and use the orb's portal, file changes, and shared terminal. The mode lasts one week by default, and thread and orb costs bill to the thread owner. Amp's own documentation is direct that while multiplayer is active, every workspace member can access the thread, orb, secrets, files, and terminal.

What is AQ?

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud.

Agents run as the real CLIs your team already uses (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on the team's VM, streamed live to the browser. Sessions survive a closed laptop and resume from any device. Each workspace is an isolated git worktree (branch ai/{id}-{slug}, dependencies installed automatically, one-click rebase onto main), each user signs into the CLIs and GitHub with their own accounts, and agents commit, push, and open PRs that AQ tracks per workspace. Labeling a Linear issue "ai-task" creates a workspace in the team sidebar with two-way status sync. It works in the browser on macOS, Windows, Linux, and mobile.

The core difference: a mode vs a default

Amp's multiplayer answers the question "how do I let a teammate into this run?" You switch it on per thread, the whole workspace gets access (terminal, files, secrets), and it expires after a week unless extended. That shape fits Amp's model: threads are ephemeral, orbs sleep when idle, and collaboration is an event.

AQ answers a different question: "where does the team's agent work live?" A workspace persists across many agent runs, human edits, previews, and PRs. Visibility is owner-managed and permanent: team-visible, or private and shared with specific people. Teammates open the workspace anytime and see the same live terminal. Typing into someone else's terminal is delegated, not ambient: the session owner approves a control request in one click and keeps their own input. Nothing expires, because shared visibility is not a temporary elevation; it is how the team works.

The same difference shows up in previews. Amp's portals give anyone with thread access HTTPS reach into whatever the orb is serving. AQ's previews add the feedback loop: share links are viewable without an account, teammates pin comments (with screenshots) and send them to the agent as prompts, and outside reviewers can comment through a review link after a quick email sign-in.

Where Amp wins

• Zero infrastructure. Orbs spawn per thread in Amp's cloud and bill by the minute; there is no VM to connect. AQ always runs on a VM: yours, or a dedicated AQ-managed one.
• One integrated agent. Nobody manages model subscriptions or picks a CLI; Amp routes models itself. AQ deliberately leaves the harness choice to each engineer.
• Automation primitives. As of August 2026, Amp threads can message other threads and wake on schedules or external HTTP events, making always-on background automation a first-class pattern.
• Frictionless start. A free daily credit grant means trying the full agent costs nothing up front.

Where AQ wins

• Multiplayer is the default, not a mode. Workspaces are visible to the team (or explicitly shared) for their whole life. No one-week window, no per-thread switch, and terminal control is delegated by the owner in one click rather than granted workspace-wide along with secrets.
• Your own cloud. Agents, code, and credentials live on your VM or a dedicated AQ-managed VM in its own isolated network. There is no shared multi-tenant execution tier.
• The CLIs your team already trusts. Claude Code, Codex, Cursor Agent, Kimi, Grok, and plain shells run as real CLIs under each user's own login. AQ never marks up model usage, and there is no new agent to adopt.
• Previews with a feedback loop. Pinned comments on the live preview become prompts to the agent; share links need no account to view.
• Issue tracker intake. Label a Linear issue "ai-task" and a workspace appears, with status syncing both ways and ownership following the assignee.
• Flat, published team pricing. One per-seat price instead of metering agent credits and machine minutes per task.

Pricing compared

Amp is usage-based as of August 2026: agent usage draws on credits (with a free daily grant), orbs are billed by the minute while awake, and a multiplayer thread's costs bill to its owner. Costs scale with usage, so heavy agent use is worth modeling before rollout.

AQ is per-seat: the Team plan is $50 per user per month in early access (standard $200), billed monthly, covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with the rate locked for your first 12 months. Model usage stays on each user's own Claude or OpenAI subscription with no markup. The Free plan is a personal sandbox with no time limit: AQ creates a private machine in an isolated network, nothing to install. Inviting a teammate costs nothing until the person accepts and joins.

Bottom line

Amp is an excellent answer to "give one engineer an agent that can run unsupervised in the cloud, and let teammates drop in when invited." AQ is the answer to "make agent work a place the whole team shares by default, on machines we control, with the CLIs we already use." If your team collaborates on agent sessions occasionally, Amp's share mode may be enough. If watching, steering, and reviewing agent sessions together is becoming how your team ships, that is the case AQ was built for.