Hive: a browser workbench that runs your CLI coding agents as a PTY team

The terminal-scrollback problem Hive is aimed at

Running one CLI coding agent is a single long session in one terminal. Running three of them on the same task is a routing problem: which agent implements, which reviews, which researches, and where does the handoff live. The README lists exactly this: long-running sessions spread across terminals, no routing layer for splitting work, worker progress disappearing into scrollback, and restart recovery depending on each CLI's own session behaviour.

Hive's answer is a browser workbench on 127.0.0.1 that hosts an Orchestrator and workers as visible teammates. The intended audience is narrow and clearly stated: people who already run CLI agents and find one agent insufficient but a pile of terminal windows unworkable. If you have never installed an agent CLI, the README points you at a Try Demo button in the first-run wizard, which renders a fake orchestrator and two workers with prerecorded scrollback and a prefilled task list entirely client-side. That demo is a way to judge the interaction model before installing anything real.

What actually runs: PTY processes, an injected team command, and tasks.md

The mechanism is more literal than the word orchestrator usually implies. Hive does not script a project manager that calls agent APIs. The README states that the Orchestrator is a real agy, claude, codex, opencode, gemini, hermes or qwen process, and workers are real CLI agents too. They run as PTY processes on your laptop, which is why node-pty appears among the native dependencies that npm resolves at install time.

The coordination surface is a small team command that Hive injects into the agents' shells. Through it, agents dispatch work, report results, and maintain a shared markdown task graph at <workspace>/.hive/tasks.md. That file is the part worth pausing on. A markdown task graph is inspectable with any editor and diffable in git, unlike an in-memory queue or a hosted dashboard. It also means the coordination state is only as structured as the agents keep it, and nothing in the supplied material describes a schema, a validator, or conflict handling when two agents write to the same graph.

The data flow implied by the README is: you create a workspace from a project folder, pick an Orchestrator preset, and the Orchestrator plans and delegates while workers implement, review, test, research and report back. Reports land in the workspace rather than in per-terminal scrollback. The README frames the value of this as an inspectable handoff, and that framing is the honest one: Hive is a visibility and routing layer over processes you already trust.

Install, port, upgrade, and the npm warnings you will see

The README's prerequisites are Node.js 22 or newer and at least one supported agent CLI installed, authenticated and on PATH. Installation is two commands:

npm install -g @tt-a1i/hive hive

Hive prints a local URL, usually http://127.0.0.1:3000/. For a different port, the README gives hive --port 4010. Upgrades go through hive update, which the README says runs npm install -g @tt-a1i/hive@latest in place, and it warns that you must restart any in-flight Hive process to pick up the new version. Two operational details are easy to miss. If you installed with pnpm or yarn, upgrade through that same manager, because an npm-installed copy will shadow your existing install. And if a mirror has not synced a release, the README shows installing directly from the official registry with --registry=https://registry.npmjs.org.

The README also pre-empts a common false alarm: npm warn allow-scripts and a prebuild-install@7.1.3 deprecated message during install. These come from npm's install-script review and native binary setup for node-pty, better-sqlite3 and esbuild. The README's test is whether the command ends with added ... packages. Optional PWA installation works in Chromium-based browsers only, since Firefox and Safari do not implement the install-prompt protocol. The daemon must still be running for the PWA to do anything, and the install scope is keyed by origin, so hive --port 4011 installs as a separate app from hive --port 3000. Uninstalling goes through chrome://apps and Remove from Chrome.

Where Hive is the wrong tool

Three constraints stand out from the material.

Platform support is uneven by the project's own admission. The badge line reads macOS, Linux, Windows (best-effort). Best-effort is a meaningful qualifier when the core mechanism is PTY handling and a native SQLite binding; those are precisely the layers most likely to diverge on Windows. Treat Windows as untested rather than supported.

The architecture is local-first and browser-bound. Hive runs on 127.0.0.1 and the workbench is a web UI. There is nothing in the supplied material about a headless mode or a non-interactive entry point, so using Hive as a CI step or a scheduled job is not something the README claims to support. If your workflow is a pipeline rather than a session you watch, Hive's central feature (visible teammates in a browser) is dead weight.

Finally, the coordination model depends on the agents cooperating. Hive injects a team command into their shells, which assumes each CLI accepts that injection and that the agent uses it as instructed. The task graph is markdown in the workspace, and the README does not describe enforcement, locking, or recovery when an agent ignores the protocol or a session dies mid-dispatch. The README also concedes that restart recovery depends on each CLI's native session behaviour, which pushes that risk back onto the tools Hive is coordinating.

How it differs from a single-agent CLI or a fixed pipeline

The obvious alternative is what you already have: one CLI agent in one terminal, plus a second terminal when you want a reviewer. That approach has no routing layer and no shared task state, which is the gap the README opens with. It also has no injected commands and no extra dependency tree, and it works on any platform the CLI itself supports.

A fixed scripted pipeline is the other direction: a shell script or CI job that runs agent A, pipes output to agent B, and fails on a non-zero exit. That gives you determinism and reproducibility, and it fits automation. Hive's difference is that the Orchestrator is a live agent making routing decisions at runtime rather than a script with hardcoded stages. You trade reproducibility for adaptivity, and you get a human-visible workspace instead of a log. Neither is strictly better; they answer different questions. If you want the same three-stage review every time, a script is cheaper and easier to reason about. If the division of labour changes per task, a scripted pipeline becomes a pile of conditionals, which is roughly where Hive starts.

Within the multi-agent space, Hive's distinguishing choice is that it does not replace the CLIs. The README is explicit that it adds a coordination layer without replacing them, and that the agents remain real processes you could have started yourself. That keeps your existing authentication, model choice and CLI flags intact. It also means Hive inherits every quirk of those CLIs, including their session semantics.

Maintenance cost and the BUSL-1.1 licence question

The maintenance surface is the native dependency chain. node-pty, better-sqlite3 and esbuild all need to build or fetch binaries on install, which is the source of the npm warnings the README documents. Those three packages are also the ones most likely to break across Node major versions, so the Node 22 or newer floor is worth respecting rather than testing. Upgrades are a single command (hive update) followed by a process restart, and the README's pnpm/yarn caveat is the main way that goes wrong.

The release cadence visible in the supplied material is a single recent release, v0.6.0-alpha.0, dated 2026-05-13, with the repository's last push on 2026-06-18. An alpha tag on the most recent release is the relevant signal here, not any count of stars or forks. Plan for interface churn between minor versions.

The licence needs care. The repository metadata reports NOASSERTION, while the README's badge points at BUSL-1.1 and links to ./LICENSE.BSL. Business Source License 1.1 is not an OSI-approved open source licence. It typically carries restrictions on production or commercial use and specifies a change date after which the licence converts to a stated change licence. The supplied material does not include the licence text, so the change date, the change licence, and the exact permitted uses cannot be confirmed here. This is not legal advice: read LICENSE.BSL yourself, and if Hive would sit in a commercial product or a client deliverable, get the terms checked before you build a workflow around it. The README's own framing, that this repository is the public source baseline while user-facing releases ship through npm, is consistent with a source-available model rather than a permissive one.

Who should adopt Hive, and what to confirm first

Hive fits a specific profile: you already have at least one agent CLI authenticated and on PATH, you regularly want two or more agents on one task with distinct roles, and you are willing to run a local daemon and watch a browser tab while they work. The three use cases the README spells out (a PR with a reviewer in the loop, a parallel bug hunt split across workers, and research/draft/fact-check) all share that shape. The shared .hive/tasks.md graph and the reports-in-one-workspace model are the concrete payoff, because they replace scrollback archaeology with a file you can read.

Skip it if you need a permissive OSI licence, if your agents run in CI rather than on your laptop, or if Windows is your primary platform. Skip it too if a single agent plus a second terminal already works for you; the coordination layer only pays for itself once routing and handoff are the bottleneck.

Before committing, verify three things against your own setup. First, that npm install -g @tt-a1i/hive completes with node-pty and better-sqlite3 built for your Node version, since those are the native pieces the README flags. Second, that your chosen CLI appears in the supported list (agy, claude, codex, opencode, gemini, hermes, qwen) and behaves correctly when Hive injects the team command into its shell. Third, read LICENSE.BSL and confirm the change date and change licence match how you intend to deploy, because the badge says BUSL-1.1 and the repository metadata says NOASSERTION, and only the licence file resolves that difference.

Editorial conclusion

Adopt Hive if you already run two or more authenticated CLI agents and keep losing their output in scrollback; the team command and .hive/tasks.md give you an inspectable handoff without swapping out the CLIs. Do not adopt it if you need a permissive OSI licence, a headless CI runner, or Windows parity, since the README marks Windows best-effort and the repository ships BUSL-1.1. Before committing, verify that node-pty and better-sqlite3 build on your machine, that your chosen agent CLI accepts an injected shell command, and what the BUSL change date and change licence actually say in LICENSE.BSL.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tt-a1i/hive on GitHub