Tutti: A Shared Workspace for Coding Agents, With a Paid Tier Behind the Invite Code
Where people and agents build in tune.
At a glance
- What is it?
- Tutti is an Apache-2.0 TypeScript desktop app that puts multiple coding agents into one real-time workspace so they stop handing off summaries to each other. The open-source build is single-user; the multi-user build is a separate product behind an invite code.
- Who is it for?
- Adopt the open-source build if you already run two or more agents and the paste-between-sessions loop is the bottleneck, and if you are willing to read CONTRIBUTING.md for the development path because the README documents downloads rather than source builds. Do not adopt it if you need multi-user rooms, simultaneous editing, or agent borrowing: the README puts all of those in the Tutti VM column, which is not the repository you are reading.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Handoff Problem Tutti Is Aimed At
The README opens with a scenario, not a feature list. Claude Code finishes an API, then Codex has to build the frontend, so you paste the API docs, brief Codex on the current state, and re-explain the design rationale. Design and assets come next, which means another round of summarizing, generating images in a separate app, downloading, uploading, and pasting into the next agent. The README's summary of that loop is blunt: agents were supposed to do the work, and instead you became the messenger between them. Tutti's stated answer is a real-time shared workspace where context, files, apps, and tasks are connected, so one agent can pick up another's output without a handoff document. The README claims Codex can pick up Claude's output "as if they shared one brain." The target reader is named directly: people running several agents at once who have already copied context between them, possibly by building their own Markdown handoff workflow. That last detail matters. If you have not built a handoff workflow, you may not have the problem this product addresses. The README also states plainly that Tutti is not a replacement for your coding agent, which sets the boundary of the claim: it is a workspace layer, not a model or an agent runtime.
Two Builds, One Repository, and Where the Line Falls
The README's comparison table is the most decision-relevant page in the material, and it is also the sharpest limitation. Tutti Open-source and Tutti VM share four capabilities: connecting existing agents, using existing subscription credits, built-in apps, and the big @ mention across your own agents. Everything collaborative sits on the VM side only. Group chat, working with other people, working with other people's agents, simultaneous editing, agent borrowing, cross-device access, and no-deploy sharing are all marked with a dash in the open-source column. The big @ also changes meaning: across your own agents in the open-source build, across others' agents in VM. So the repository you are evaluating is the single-user workspace. The multi-user, multi-agent, real-time collaboration space that the README's headline describes is the hosted product. This is not a hidden catch, since the table is near the top of the README, but it is easy to miss when the repository description and the marketing copy use the same name. Anyone evaluating tutti-os/tutti for team collaboration is evaluating the wrong artifact. The README also states that Tutti is now open-source and that Tutti VM is in Early Access, with only Room creation requiring an invite code. Downloading VM or joining someone else's Room does not require one, according to the README.
What the README Does Not Say About the Internals
The repository is TypeScript, and the topic list points at the intended architecture: agent-collaboration, agent-orchestration, agent-workspace, shared-context, mcp, local-first, multi-agent. The README itself stops at the conceptual level. It says context, files, running tasks, and apps are all connected, and that any output, including what apps generate, can flow between agents and be used directly in the next step. It does not describe the transport, the storage format for shared context, how agent sessions are isolated from one another, or what the MCP integration exposes. The word local-first appears in the topics but not in the README body, so the sync model is not documented in the material available here. The built-in app ecosystem (image generation, UI/UX design, docs, presentations) is described by capability and by example: when Codex calls the prototype-design app, the README says it is as if Codex gained Claude Design's abilities, and Claude Code can take the result into frontend work. How an agent invokes an app, and whether that is an MCP tool call or something else, is not stated. Treat the architecture as unverified until you read docs/README.md, which the README links but does not reproduce. What can be said from the repository layout is that documentation lives under docs/ and the development guide is CONTRIBUTING.md.
Getting It Running: Downloads First, Source Second
The Quick Start section does not contain build-from-source instructions. It contains download links. For macOS, the link is https://tutti.sh/desktop/download?platform=macos&arch=universal&format=dmg, which the README labels Tutti Local for macOS. For Windows, it is https://tutti.sh/desktop/download?platform=windows&arch=x64&format=exe, labelled Tutti Local for Windows (x64). A third link covers Tutti VM for macOS or Windows and points at the versions anchor on the site. The README then states that creating a Room requires an invite code and links the waitlist, while downloading VM or joining someone else's Room does not. For the development path, the README defers entirely: see CONTRIBUTING.md for the full development guide. That file is not included in the material here, so no package manager command, build script, or environment variable can be quoted without inventing it. This is a real friction point for an open-source project. An engineer evaluating whether to contribute or self-build gets a dmg and an exe link and a pointer to a file they have to open on GitHub. If your adoption decision depends on reproducible builds or on running from source, the README alone will not get you there.
Where Tutti Is the Wrong Tool
The clearest failure case is built into the product split. If your workflow involves another person, the open-source build does not cover it. No group chat, no simultaneous editing, no borrowing someone else's agent, no cross-device continuation. You would be running the single-user workspace and coordinating with teammates outside it, which puts you back in the messenger role the README complains about. A second case is scope. Tutti is not a coding agent. If your bottleneck is one agent producing bad code, a shared workspace does not address it. The README's own framing supports this: it is a workspace for agents, not a replacement for them. A third case is the documentation gap. Someone who wants to audit how shared context is stored, or who needs to run the app in a controlled environment, will not find that in the README. The material describes what the workspace does, not how it does it. A fourth consideration is the invite code on Room creation. The README says downloading VM and joining an existing Room do not require one, so the gate applies to hosting, not to participation. If your plan is to run your own room, plan around the waitlist.
Alternatives: The Markdown Handoff You Already Built
The README names the alternative itself: a Markdown-based handoff workflow that you built because copying context between agents got tedious. That is the honest comparison, and the difference in approach is concrete. A handoff file is a snapshot. You write down state, the next agent reads it, and the file goes stale the moment either side changes something. Tutti's claim is a shared workspace where context, files, and running tasks are connected, so the state is read rather than transcribed. Whether that holds up depends on details the README does not provide, such as how conflicts between two agents touching the same file are resolved. The other alternatives named in the README are the individual tools themselves: Claude Code, Codex, Canvas, Claude Design. Those are agents and design surfaces, not workspaces, so they are not substitutes for the coordination layer. If you only ever run one agent, staying with that agent is the right call, and the README's target-user list confirms it: every bullet assumes multiple agents or multiple subscriptions in play.
Maintenance, Licensing, and What the Release Cadence Suggests
The repository is Apache-2.0, which permits commercial use, modification, and redistribution, and includes an explicit patent grant. That is a permissive licence, and it is a meaningful difference from copyleft alternatives if you intend to embed or redistribute anything. This is not legal advice; read LICENSE and your own counsel's view before relying on it. On cadence, the material shows v0.2.32 on 2026-09-03 and v0.2.33 on 2026-09-05, with a separate stable release published alongside v0.2.33. A two-day gap between patch releases is a fast enough rhythm that pinning matters. The README's download links point at a website endpoint rather than at GitHub release assets, so the binary you get is whatever the site serves at that moment, not necessarily the tag you read about. If you need reproducibility, that mismatch is worth resolving before deployment. The README does not describe an upgrade path, a migration story for workspace data, or a version compatibility policy between the desktop app and any hosted components. Those are the maintenance questions the material leaves open, and they are the ones to raise in the Discord or the issue tracker rather than assume an answer.
Editorial conclusion
Adopt the open-source build if you already run two or more agents and the paste-between-sessions loop is the bottleneck, and if you are willing to read CONTRIBUTING.md for the development path because the README documents downloads rather than source builds. Do not adopt it if you need multi-user rooms, simultaneous editing, or agent borrowing: the README puts all of those in the Tutti VM column, which is not the repository you are reading. Before committing, verify three things from the material itself: which binary the download links actually serve for your platform, whether the GitHub release tagged stable matches the v0.2.33 tag, and whether the invite-code requirement on the VM waitlist applies to the workflow you intend to run.
Community notes