Vinculum sits underneath the client. It doesn't wrap one.
Vinculum runs as an MCP server underneath whatever connects to it: a browser tab, a desktop app, a phone app, a CLI session. It doesn't wrap a single client on a single machine. The server holds the project graph, and any client that speaks MCP can read and write to it (#8922).
Visibility on that graph is scoped to the project, not to the machine or the person running it. Two different operators can each spawn their own workers against the same project and watch each other's work land as it happens: same workers row, same lineage view, live (#8922).
Two operators, two continents, two model families. One project.
One operator worked from one continent. A second worked from another. Different machines, different networks, no coordination beyond both already having access to the same Vinculum project (#8922).
The two setups weren't even running the same kind of model. One connected through Claude. The other ran a different model family entirely, through a local setup with zero cloud subscription attached. Both operators spawned their own workers against that project, and both operators' entries showed up together on the same dashboard: same workers row, same lineage view (#8922).
#11287 is what confirms this ran, not just as a diagram: a second operator connected from their own machine, on a non-Claude model, and spawned workers against the shared project.
Designed once. Then it actually ran.
The architecture note (#8922) lays out why a server underneath the client, rather than an app wrapped around one, makes cross-client and cross-model access possible in the first place. The follow-up (#11287) is the confirmation that it wasn't just a design: a second operator, on a different model family, actually connected and worked the same project live.
| What happened | Detail |
|---|---|
| server sits under the client | An MCP server underneath any client (browser tab, desktop app, phone app, CLI), not an app wrapping one client on one machine (#8922) |
| visibility scoped to the project | Scoped to the project rather than the machine or the person running it, so two operators' workers and entries show up together, live, in the same workers row and lineage view (#8922) |
| cross-model, not just cross-machine | One operator on Claude, one on a different model family entirely running locally with no cloud subscription, both against the same project graph (#8922) |
| ran live, not just designed | A second operator connected from their own machine on a non-Claude model, and it worked (#11287) |
| source | Vinculum substrate entries #8922, #11287 |
Common questions.
Does this mean anyone can join any project?
No. Visibility is scoped to the project, not thrown open to the world. What's cross-client and cross-model is who can connect once they already have access: a Claude session, a completely different model family, any client speaking MCP. Access itself still has to be granted first (#8922).
Is there a public share link today?
Not yet. A separate feature for that is proposed and under consideration, not shipped: handing someone outside the project a link to view a slice of it read-only. What's described on this page, and confirmed running live, is the cross-client multiplayer above: people who already have access to a project meeting on its graph from different machines and different models.
Does the model on each side have to match?
No. One operator ran Claude. The other ran a different model family entirely, through a local setup with no cloud subscription behind it. Both ended up spawning workers against the same project, at the same time, on the same dashboard (#8922).