# Cursor Multiplayer Projects: Setup, Billing and Shared Context Cursor now lets teammates coordinate their coding agents, but a useful shared Project needs clearer ownership than a group chat. By Paras Madan | 2026-11-11 Cursor launched multiplayer Projects in beta on November 10, letting teammates coordinate coding agents around shared tasks and context. The useful change is that two engineers can work through separate agents without manually relaying every dependency. Setting it up still requires checking team access, repository permissions and billing. [Cursor's announcement](https://cursor.com/blog/projects-multiplayer) describes a common problem: agents know a lot about one person's work and much less about the work happening beside it. Multiplayer adds a shared board and project knowledge while preserving separate coordinator conversations. That makes it worth trying for a migration or feature spanning several owners, rather than adding it to every small bug fix. ## How to create a shared Cursor Project The [Projects documentation](https://cursor.com/docs/agent/projects) requires a team account and Cursor 3.26.13 or later for sharing. Open New Project in the Agents Window, choose a name, repository and coordinator model. Use Invite to add someone from your Cursor team with repository access. Archived Projects, self-hosted-machine Projects and Privacy Mode (Legacy) are excluded. Before inviting everyone, pick one bounded piece of work and two people who already collaborate on it. A shared workspace cannot rescue a brief that leaves the outcome undefined. Write down what success looks like, what must remain unchanged and who will review the result before anyone starts delegating implementation. ## Who pays for agents in a shared Project? Each member's chat runs and bills as that person. Sharing a Project therefore should not be mistaken for routing everybody's work through its creator's allowance. [Cloud Agents billing](https://cursor.com/docs/cloud-agent#billing) follows the selected model's rate and the account's plan usage. Larger context windows can increase token consumption and cost. Cursor asks for a spend limit when Cloud Agents are first used; legacy request-based plans have separate API-rate and Max Mode treatment. For a first team trial, record the starting usage of each participant and agree on a stopping point. Compare the total cost of producing a reviewed change, including failed attempts and integration work. A cheap individual run tells you little if three people independently ask their agents to solve the same problem. **Give each deliverable one human owner.** Others can inspect or challenge it, but they should not commission competing implementations without an explicit reason. That is a practical cost control as well as a way to keep the work understandable. ## Decide what belongs in shared context Project Context lives at `/cursor/stores/self`, where members' agents can read and write. Personal preferences and skills live at `/cursor/stores/user`, available to that person's agents. Keep shared rules specific to this work. A useful project document should distinguish a decision from a suggestion. For example, “Use the existing database client” is an agreed constraint. “We might replace the database client later” is background discussion. If both appear as equally authoritative instructions, sharing more context can spread confusion faster. Keep a short decision record with an owner and date. When something changes, replace or clearly retire the old instruction instead of appending another paragraph that contradicts it. This is the maintenance work that a shared agent workspace makes more valuable, not less necessary. ## A worked plan for a two-person migration Consider a hypothetical team moving account settings to a new API. One engineer owns the endpoint and another owns the settings screen. This is an illustrative workflow, not a tested performance claim. Start with a brief that says the existing screen must remain usable during rollout. Agree on the request fields, response fields, error behavior and compatibility period before asking either agent to implement changes. Put that contract in the shared context and assign a human reviewer to it. The backend owner's opening instruction could be: “Plan the endpoint migration against the agreed contract. Identify compatibility risks and propose tests before changing code. Keep the current endpoint working until the frontend migration is reviewed.” The frontend owner's instruction could be: “Plan the settings-screen migration using the agreed API contract. List assumptions that need backend confirmation. Do not invent missing response fields. Include tests for validation errors and failed saves.” Review those plans together, then approve implementation in a dependency order you understand. Once both changes are ready, test the combined behavior. Two passing sets of isolated tests do not establish that the screen and endpoint agree on error handling. ## What multiplayer does not prove Cursor says coordinators can communicate about overlapping work. Its documentation treats incoming agent messages as untrusted agent input, rather than instructions from the human owner. That distinction matters when one agent asks another to change course. There is no reason to read the launch as a guarantee that merge conflicts or integration mistakes disappear. Shared context can make dependencies visible earlier; people still need to resolve incompatible requirements and decide whether the final change is safe to ship. The strongest reason to adopt multiplayer is a recurring handoff that currently loses important information. Start there and measure whether the next person can continue the work with fewer clarifications. More parallel agents are only useful when the team spends less time reconciling their output. I'm Paras. I work at the intersection of AI, engineering and distribution. I help technical teams turn product changes and engineering decisions into clear stories developers can use and share. [Book a 30-minute call](https://cal.com/paras-madan/30min).