talesofai/cohub: people and agents in one Space, developed inside its own public Space

Four names for one project

The naming is the first thing to untangle, and there are four entities in it.

The repository is under an organisation called talesofai, and the package inside it is named cohub. The homepage is at cohub.live. The command line tool you install is published under a different scope entirely, as a package scoped to a different name, and the readme links a separate product called Neta Studio on another domain.

And the licence line names a fourth party, stating Apache License 2.0 with a copyright to a limited company, alongside a notice file at the top of the repository.

None of that is necessarily a problem. A project with a hosted product, a separate studio brand, a company behind it and an open-source repository can legitimately carry four names. But it means that when you go looking for the source of the CLI you installed, the scope in the install command is not the scope in the repository URL, and the copyright holder is neither.

The repository description is the shortest honest summary available: a living space where people and agents create, play and build together.

The public Space is the development process

There is a section of the readme with no technical content in it at all, and it is the one that explains the project's shape.

Cohub is developed inside Cohub. The core development workflow, which the readme names as specs, agent runs, reviews and shipping, happens in a public Space, and there is a link to it. The sentence underneath is the whole argument: watch how the product is built, by the product.

So the tool used to build the tool is the tool being shipped, and the record of that is not a blog post but a Space anyone can open. That is a different bet from publishing a blog, and it has an obvious property worth noting: the development history is a first-class artefact of the product rather than a byproduct of it.

The number attached to that practice is a scale claim rather than a process one: the readme states that a hundred billion tokens per week are burned inside the company within Cohub Spaces.

Everything else in the readme is consistent with that framing, including the feature that most directly encodes it, which is that you can fork a checkpoint into a new Space or reference any Space with a space mention as context.

Node 24, pnpm 10, and Biome instead of the usual two tools

The workspace manifest is strict about its floors and unconventional about its tooling.

The package manager is pinned to a specific version of pnpm, and the engine requirements ask for Node 24 or later and pnpm 10 or later. Those are recent floors, so a machine on an older Node cannot run the development server at all.

The root package is private, which means nothing is published from the root. The thing users install is the command line tool, built as its own workspace package.

The linting choice is the notable one. Rather than the two tools most TypeScript monorepos reach for, this one uses a single binary for both formatting and linting, and the manifest wires it to three scripts: a recursive lint across packages, a fix variant, and a direct format command that writes across the whole tree. A separate file at the top level carries its configuration.

Commit hooks are set up through Husky, and there is a staged-changes configuration file beside it, so formatting and linting also run on staged files rather than only on demand.

An embedded Postgres in the dev dependencies

One entry in the development dependencies explains how the project runs locally without asking you to install a database.

It is a packaged Postgres compiled to WebAssembly. That is a real Postgres engine running in process rather than a substitute for one, which means the local development environment speaks the same SQL and the same protocol as production.

For a product whose entire unit of work is a Space containing sessions, having the storage layer available with no external service is what makes the two-line development setup work. The readme's development section is only an install command and a dev command, with quality checks listed as a lint, a typecheck and a build. There is no database service to start, because there is no database server to start.

The same dependency list carries a native canvas binding, which is a compiled module rather than a pure JavaScript one and is the kind of entry that decides whether a project can build on your platform without a toolchain. A script runner for TypeScript is also there, and the manifests use it to run the operational scripts directly rather than compiling them first.

Eight packages, and three separate sandbox rollouts

The build scripts name eight workspace packages, and the way they are addressed says something about the dependency graph.

There is a package for the API, one for the agent, one for a gateway, one for a worker, and one whose workspace name is simply the lowercase word for the web front end rather than a scoped name like the others. That inconsistency is a small signal that the web package was created at a different time or by a different hand.

The build targets use pnpm's filter syntax in two forms. A dev target for a single package filters to just that package. The build targets for the agent, API, gateway and worker each add an ellipsis after the name, which means that package and everything that depends on it. So a gateway build compiles the gateway and its dependency closure, which is how a monorepo of this shape avoids discovering breakage at deploy time.

Then there are three rollout scripts, and they are the part worth pausing on: one for the sandbox, one for the sandbox in production, and one for the sandbox in development. A sandbox is a distinct deployment target rather than a mode, and three separate entry points mean it is something the team rolls forward often.

The changelog is generated, not written

Versioning and release notes are both automated, and the manifest shows it in detail.

A changeset directory sits at the top level and a changeset command is available as a script, paired with a script that versions the packages and a release script that does two things in order: it builds the command line package together with everything that depends on it, and only then publishes. So the CLI is compiled before publication rather than published from a stale build.

The changelog has three scripts of its own, named for generating it, rendering it and releasing it. A changelog file exists at the top level as the artefact those three produce.

That is a different arrangement from hand-maintaining release notes, and it has a visible consequence: the release cadence you see in the tags is driven by when changesets are merged. The three newest tags are a minor version on 29 September 2026 followed by a patch the next day and a previous minor five days before that, and the last push to the default branch main is dated 1 October 2026, one day after the newest tag.

So the tags track the merge rhythm rather than a marketing calendar.

Five client surfaces, one Space

The feature list is short, and the client list inside it is the part that determines whether the product is usable for you.

The readme claims five surfaces: web, mobile, a command line tool, Discord and WeChat, with the line that the Space follows you. The first entry point is the hosted site, where you sign in. The command line tool has its own two-step install:

npm install -g @neta-art/cohub-cli
cohub auth login

Self-hosting is the third route and points at its own document.

The other three features describe what happens inside a Space rather than how you reach it. You can open a Space and work with ideas, prompts, files and agents. People and agents share one Space, creating together and saving and sharing. And the work is meant to be real work, with games, apps, media, automations and custom homes named as the range.

That combination is the actual product claim: not a chat window with an agent attached, but a persistent shared surface where an agent's output is saved alongside yours and can be forked into something new.

An agent runtime built on someone else's foundation

The readme has a Thanks section, and for a repository of this size it carries more information than its two lines suggest.

Cohub's agent runtime is built on another project, credited by name and by link, described in the readme as the foundation. That is an unusual thing to find stated plainly at the top level of a repository: the agent execution layer, which is the part everyone assumes is the product, is a dependency on someone else's work.

It reframes the rest. The parts this repository appears to own are the Space abstraction, the multi-client surface, the workspace and deployment machinery, and the development workflow that runs inside a public Space. The part it acknowledges building on is the loop that actually runs an agent.

For anyone evaluating the project that matters, because it determines what happens to the product if the foundation changes or stops being maintained.

The engineering documentation list gives the same kind of signal. Four notes are linked by name: self-hosting, the agent sandbox runtime, generations, and space hooks. Three of those four are about the runtime and its lifecycle rather than about the user interface, which is consistent with a product whose hardest problems are operational.

Editorial conclusion

Cohub fits a team that wants its agents and its people working in the same shared surface rather than in separate tools, and that wants the option to self-host rather than depend on someone else's account. It is a poor fit if you need a stable published SDK contract, because the workspace manifest is private and only the CLI is published, or if you want the agent runtime to be yours, since it is built on someone else's foundation. Before you commit, check three things: which of the five client surfaces your team actually uses, whether self-hosting suits your environment given the Node 24 and pnpm 10 floors, and whether the public development Space is a process you want your own work visible in.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. talesofai/cohub on GitHub