Cohub: a shared Space where people and agents work in the same thread
A living space where people and agents create, play, and build together.
At a glance
- What is it?
- Cohub is an Apache-2.0 TypeScript workspace that puts people and agents into a single persistent Space reachable from web, mobile, CLI, Discord and WeChat. The interesting design decision is that the Space, not the chat window, is the unit of work, and that decision carries real constraints.
- Who is it for?
- Adopt Cohub if your work already looks like a long-running project with files, prompts and agent runs that several people and several agents need to see at once, and you are comfortable running `npm install -g @neta-art/cohub-cli` plus `cohub auth login` against it.
- 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 received new commits within the last day.
- 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 problem Cohub picks: agents that live in a chat window lose the project
Most agent tooling treats a conversation as the container. You open a thread, the agent reads some files, you get an answer, and the thread scrolls away. Cohub inverts that. The container is a Space, described in the README as "a living space where people and agents create, play, and build together," and the surfaces (web, mobile, CLI, Discord, WeChat) are just ways to reach the same Space. The README's own framing of the target user is unusually direct: the team says it burns 100 billion tokens per week inside Cohub Spaces. That is a statement about internal dogfooding, not a benchmark, and it tells you the intended user is a group doing sustained work with agents rather than someone making one-off calls. The listed use cases run from games and media to automations and custom homes, which is broad enough to be a warning: a product that claims playful and production workloads in the same sentence usually means the primitives are generic and the opinionated parts live in templates. The one concrete differentiator in the README is the promise that you never start blank. You can fork a checkpoint into a new Space, or pull any Space in as context with `@space`. That is the actual product thesis: context is a first-class, shareable object, and an agent run is something you do inside it.
What a Space contains, and how @space changes the prompt
From the README and the docs index, a Space holds prompts, files, agents and checkpoints. The engineering notes list `docs/generations.md`, `docs/space-hooks.md` and `docs/apps-guide.md`, which suggests three separate mechanisms: generations (some notion of versioned output), hooks (something that fires on Space events), and apps (something you build and run inside a Space). The README does not describe the execution model of any of these, so treat the names as pointers, not as a specification. The one mechanism the README does state plainly is `@space`: referencing a Space by handle pulls it in as context. The README's own example is linking `cohub.live/tzwm/cohub` as the public Space where the team develops Cohub itself, so the reference is to a live, addressable object rather than a pasted transcript. The second stated mechanism is the checkpoint fork: you take an existing checkpoint and branch it into a new Space. Together these two give the model its shape. Context is addressable, and state is branchable. What the README does not say is how much of a referenced Space lands in the prompt, whether nested references are resolved, or what happens when the referenced Space changes mid-run. Those are the questions that decide whether `@space` is a convenience or a cost centre, and the README does not answer them.
Getting it running: three entry points, one of which is a stub
The README gives three ways in. Web is the shortest: open cohub.live and sign in. CLI is two commands: `npm install -g @neta-art/cohub-cli` followed by `cohub auth login`. Self-hosting is a single line pointing at `docs/self-hosting.md`, which the README does not reproduce. For local development the README gives `pnpm install` then `pnpm dev`, with `pnpm lint`, `pnpm typecheck` and `pnpm build` as the quality checks. That is a conventional pnpm workspace setup and it tells you the repo is a monorepo with a dev server, which is consistent with the multi-surface claim: web, CLI and the agent runtime plausibly live in the same tree. The README credits the agent runtime as built on `pi` from earendil-works, so the sandbox and tool-execution layer is not original to this project and its behaviour will be documented upstream. Two things are worth flagging before you install anything. First, the CLI is published under the `@neta-art` scope while the repository is `talesofai/cohub` and the licence holder is Viscept Limited, so there are at least three organisational names in play and you should confirm which one publishes the package you are installing. Second, `cohub auth login` implies an account on a hosted service by default. If your interest is self-hosting, the CLI path and the self-host path are not the same path, and the README does not reconcile them.
Where the shared-Space model breaks down
The design has a clear failure mode: shared mutable context. If a Space is the unit of work and `@space` pulls other Spaces in as context, then every participant (human or agent) is reading and writing into something that other participants can change. The README's answer appears to be checkpoints and forks, which is a version-control-shaped answer, but it is only as good as the granularity of the checkpoint. The README does not state when a checkpoint is created, whether it is automatic, or whether a fork is a copy or a reference. Without that, the fork workflow is hard to reason about in a team setting: two people forking the same checkpoint and both editing will either merge cleanly or diverge silently, and the README does not say which. The second limitation is surface parity. The README claims the Space follows you across web, mobile, CLI, Discord and WeChat. The README does not describe which capabilities exist on which surface, and the CLI quick start only covers authentication. If you need an agent to run a build or touch a filesystem, that presumably happens server-side in the sandbox runtime, not in your Discord client, but the README does not draw that line. Third, the repository is TypeScript and the release cadence is fast: v2.45.1, v2.45.2 and v2.46.0 all landed within roughly two days in September 2026. That is a good sign for activity and a bad sign for anyone pinning to a stable interface.
What you give up compared with a plain agent SDK
The obvious alternative is to skip the Space entirely and build on an agent SDK or framework directly, calling a model with your own tool loop and your own storage. The difference is architectural, not cosmetic. With an SDK you own the state: you decide what goes in the context window, you decide where files live, and you decide what a run produces. Cohub takes those decisions and makes them shared and addressable, which is what lets a colleague open your Space and continue, and what lets `@space` work at all. The cost is that the context window is no longer yours to budget. If you are building a backend service that needs a deterministic prompt and a bounded token cost per request, a Space-shaped product is the wrong shape. The same trade-off applies against notebook-style tools that persist a document with code and outputs: those give you a durable artifact, but the artifact is a document, not a place where multiple agents and people act concurrently. Cohub's claim is closer to the notebook end of the spectrum than the SDK end, with the addition that the notebook is multi-user and agent-addressable. Whether that is worth the loss of prompt control depends entirely on whether your work is collaborative. For a solo developer writing a one-shot script, it is not.
Maintenance, releases and what Apache-2.0 does and does not cover
The licence is Apache-2.0, held by Viscept Limited, and the README links a `LICENSE` file at the repo root. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices, which matters if you fork the code into a product. It does not cover the hosted service at cohub.live, and it does not tell you anything about the terms attached to the `@neta-art/cohub-cli` package or to any hosted API the CLI talks to. Those are separate agreements and the README does not link them. This is a description of what the licence text does, not legal advice; if you plan to redistribute a modified Cohub, read the file and the package metadata yourself. On maintenance cost, the signal is the release cadence: three releases in about two days, with the newest at v2.46.0. Frequent minor releases on a 2.x line usually mean the project is still moving interfaces. The README points to `CHANGELOG.md` and to a docs tree split into `docs/product/en/` and `docs/product/zh/`, which the README calls the source of truth for product docs. That split is worth knowing about: if you self-host and want to understand behaviour, the English product docs under version control are described as authoritative, while cohub.live/docs is a rendered view. Upgrade cost is dominated by whatever the Space format and hooks do across versions, and the README does not publish a compatibility policy.
Who this is for, and what to read before you commit
Cohub is aimed at teams whose agent work is already project-shaped: files accumulate, prompts get reused, several people need to see the same state, and the output is something you keep rather than something you paste into a ticket. The README's own development workflow is the clearest evidence of intent, since specs, agent runs, reviews and shipping are said to happen in a public Space at cohub.live/tzwm/cohub. If that description matches how you work, the Space model is a genuine fit and the multi-surface claim means you can reach the same state from a terminal or a chat client. If your work is a request-response API call, or if you need to run everything on your own hardware with no hosted dependency, the README's self-hosting line is not enough to make that decision on. The first thing to verify is `docs/self-hosting.md`, because it determines whether the hosted service is optional or load-bearing. The second is `docs/agent-sandbox-runtime.md`, because the sandbox is credited to `pi` and its isolation properties are the ones you would be trusting with executed code. The third is the checkpoint and `@space` semantics, which the README leaves open and which decide whether the fork workflow is usable with more than one person editing.
Editorial conclusion
Adopt Cohub if your work already looks like a long-running project with files, prompts and agent runs that several people and several agents need to see at once, and you are comfortable running `npm install -g @neta-art/cohub-cli` plus `cohub auth login` against it. Do not adopt it if you need a single-turn agent API you can call from your own backend, or if your data cannot leave your infrastructure, because the README's self-hosting path is a pointer to `docs/self-hosting.md` and nothing more. Before committing, read that file and `docs/agent-sandbox-runtime.md`, confirm what `@space` actually pulls into a prompt, and check whether the fork-a-checkpoint workflow produces artifacts you can export.
Community notes