What is a multiplayer AI coding workspace?

A multiplayer AI coding workspace is a place where several people work with AI coding agents on one codebase and can see each other doing it: the same sessions, the same changes, the same running app, with each person's actions attributed to them. The phrase is used for three different shapes of product, and the shape decides what a team actually shares. In the first, several people steer one live agent session together. In the second, each person runs their own agent thread on a shared project and the results are merged. In the third, one agent lives in a team chat and works asynchronously on requests. Poly (usepoly.co) is the first shape, which we call multiplayer agentic coding: multiplayer AI for building software. This page covers all three.

Key takeaways

• A multiplayer AI coding workspace lets several people see and steer AI coding agents on one codebase, with each person's actions attributed.
• It comes in three shapes: one live session several people steer, each person's own agent merged later, or one agent in the team chat.
• The shape decides what the team shares: the live session, the project, or the requests and results.
• Before choosing, run the Room Test: who can approve a change, who spent what, and where people can talk without prompting the agent.

Why does the phrase exist?

Coding agents such as Claude Code and Codex were built for one person in one terminal. When a team adopts them, every person runs private sessions, and the reasoning behind each change stays in the session that made it. The code gets merged; the understanding does not. "Multiplayer" names the products that put more than one human in the loop with the agents, so the work happens somewhere the team can see.

How is it different from "multiplayer AI"?

"Multiplayer AI" is the broader idea, and it spread quickly in 2026. Sergey Karayev's Multiplayer AI Manifesto (September 2026) defines it this way: "Multiplayer AI means teammates can participate in the same agent session, with shared context." Its principles ask for agents inside the team's own tools, work done in the open, and session history anyone can pick up later. Anthropic's Claude Academy teaches the same shift: single-player AI speeds up one person but can keep what it learns from the team.

A multiplayer AI coding workspace is that idea applied to building software. The shared session is an agent that edits a codebase and runs commands, so it also needs approvals before changes, a record of who did what, and somewhere safe to run.

What shapes does a multiplayer AI coding workspace come in?

1. Live steering: several people, one session

One agent, one timeline, several humans steering it as it runs. Everyone sees the same prompt, the same reply and the same change as it happens; any member can answer the agent's question, approve or refuse a change, or stop it. Prompts queue and run one at a time so the agent is never doing two things at once. This is the shape that gives a team a shared record of every decision, and the only one where a person who cannot code can participate as an equal, because the surface is a timeline and approval cards rather than a terminal.

Examples as of September 2026: Poly, Coshell, AQ (as a shared terminal), MobSession, Omnigent's co-drive mode, HumanLayer's multiplayer prompting, and OpenClaw 2.0's shared sessions.

2. Parallel threads: each person their own agent, one project

Each teammate opens their own agent thread on a shared repository; tasks run in isolated copies and are merged later, with a review step at the end. This is how the large builder platforms do multiplayer, because it scales to many people and never blocks anyone. What the team shares is the project and the review, not the session: you find out what a teammate's agent did when the task is ready.

Examples: Replit (own Agent thread per person, tasks merged by the agent), Lovable (drafts a teammate creates and the owner accepts), Zed's Delta (threads that replicate conversation and worktree, in private beta), Nimbalyst Teams (each person's own local agent, with shared docs and mockups) and Tutti VM (each person's agent in a local VM, sharing one cloud room's files and services).

3. An agent in the team chat: one agent, asynchronous requests

An agent joins Slack, Discord or a chat-shaped app as a member. Anyone can mention it; it works in a sandbox and comes back with a pull request or an answer. The team shares the request and the result. Nobody watches the agent work, and steering is a reply in the thread.

Examples: Claude Tag, Slack Code, hilos, Nairi, Bloome, Linzumi, and 143's Slack and Linear triggers.

What doesn't count as multiplayer?

• Multi-agent. Claude Code's Agent Teams and most orchestration frameworks run several agents for one human. More agents, not more people.
• Shared context. A committed CLAUDE.md, a runbook library or a shared prompt set makes separate sessions consistent. It does not put a second person in any of them.
• A multiplayer editor. Zed, VS Code Live Share and Replit's editor let humans co-edit files. Useful, and a different axis from sharing an agent.
• A share link. A read-only transcript of a finished session is a record, not a workspace.

What should you check before choosing one?

The Room Test is three questions to ask of any multiplayer AI coding workspace before your team shares one.

1. Who can approve. Can any member say yes or no to a change before the agent makes it, from their own screen? In many products the answer is only the person who started the session, or nobody until the pull request.
2. Who spent what. Does each turn say who ran it and what it cost? Products that run on each user's private subscription cannot show this.
3. Where people can talk without prompting. In a shared session, anything typed is an instruction. A channel the agent cannot read is how a team argues about the plan without the argument becoming the prompt.

In September 2026, those three together are rare. They are the reason Poly exists, and the secure shared workspace guide explains the security side of the same choices.

Which products fit each shape?

• Live steering: Poly (hosted, five AI labs, no keys), Coshell (self-hosted, OpenCode), AQ (shared VM terminal), MobSession (mirrors one Claude Code session), HumanLayer (teammates prompt and approve inside one running session, since August 2026), OpenClaw 2.0 (self-hosted sessions with owners and participants, since August 2026), Omnigent (open-source meta-harness with co-drive).
• Parallel threads: Replit, Lovable, Bolt (one prompt at a time in a shared project), Zed Delta, Nimbalyst Teams, Tutti VM (early access).
• Agent in the chat: Claude Tag (Anthropic, Slack), Slack Code (Slack code channels for Claude, Devin, Copilot and Vercel agents), hilos, Nairi, Bloome, Linzumi, 143, Superconductor (ticket-based, with shared implementation chats).

Some sit between shapes; Superconductor lets the whole workspace chat inside any agent's implementation, which is closer to live steering than the rest of its ticket workflow. Our comparisons cover the ones teams ask about most.

What does a multiplayer AI coding workspace cost?

Two things: the product and the AI it runs. Self-hosted tools such as Coshell and OpenClaw are free to run, and the models bill to your own keys or subscriptions. Hosted tools charge per seat, per person who runs the agent, by credits or sandbox hours, or a flat price per team. Poly is free to start: a person who runs the agent pays $20 a month on Pro or $50 on Max, and joining, watching, chatting and approving are free. Team, in early access, is one price for the whole team. Collaborative Claude Code tools, compared lists each product's price.

How long does it take to set up?

Minutes for a hosted workspace. A self-hosted one takes longer: someone runs the server, connects model keys and lets teammates in. Tools that run on each person's own Claude or ChatGPT plan also need every participant to connect one before they can prompt. A Poly room opens in about a minute with no API keys, and you can connect a GitHub repository or start from nothing.

What are the risks?

Sharing an agent shares its reach. Plan for four things:

• Anyone who can prompt can direct it, and so can instructions hidden in the code it reads. Changes need an approval step and a way to undo them.
• A key in a shared sandbox is everyone's key. Every member, and every instruction in the repository, can read it.
• Spend without names. When usage runs on one account, nobody can see who spent what.
• Open internet access. An agent that can reach any host can send your code anywhere; an allowlist of hosts limits that.

The secure shared workspace guide covers each one and how Poly handles it.

Who is a multiplayer AI coding workspace not for?

• One developer working alone. A single-player agent in your terminal is simpler and costs less.
• Teams that must keep code on their own machines. Choose a self-hosted tool such as Coshell or OpenClaw 2.0; Poly runs only on its own servers.
• Large teams that mostly work in parallel. The parallel-threads shape scales further; live steering suits a small group per room.