Helix: a self-hosted fleet of coding agents, each with its own GPU desktop

The problem Helix targets: one agent per laptop does not scale to a team

The README frames the starting point bluntly: you already run Claude Code, or Codex, or Gemini, locally. One agent, one terminal, tied to your machine and your attention. That model breaks in two ways once more than one person is involved. The first is capacity: agents run in parallel only if they have somewhere to run, and a developer laptop is a single machine with a single user session. The second is visibility: if the agent lives in someone's terminal, nobody else can see it, steer it, or pick it up. Helix's answer is to move the agent off the laptop and onto shared infrastructure, giving each agent its own isolated sandbox with a full desktop (browser, terminal, filesystem, GUI apps), and putting the coordination layer on a Kanban board. The intended user is a team that already has GPUs or is prepared to attach them, already runs containers, and wants agent output to arrive as pull requests in repositories the team already uses. It is not aimed at a solo developer who wants a better terminal.

Spec tasks and the six-column board: where work actually lives

Work is organized into projects. A project connects one or more git repositories and owns a board whose columns are Backlog, Planning, Spec Review, In Progress, Pull Request and Merged. A task starts in Backlog as a one-paragraph description of the outcome, written as what should be true when done rather than how to do it. Start Planning hands the task to a planning agent, which reads the repository and writes a spec containing requirements, a design and a task breakdown to a helix-specs branch. The spec lands in Spec Review, where a human reads it, can highlight text to request changes (which triggers a re-plan), or approves it. Only then does an implementation agent start coding inside its own sandbox. The output of that stage is a pull request in your repository, and the task closes when the PR merges. The design choice worth noting is that the spec review is a separate gate from the code review. The README states the PR is the real review gate, so the spec stage is a planning checkpoint, not a substitute for reading the diff. Per-column WIP limits are mentioned as a way to keep the board honest.

Isolation, density and the desktop streaming layer

Each agent runs in its own sandbox with a GPU-accelerated streaming desktop. The README lists the components: browser, terminal, filesystem, GUI apps. You can watch any agent work in real time from a dashboard, zoom into a live screen, and type into the task thread to steer it. Two claims in the README do most of the architectural work. The first is high-density isolation: many fully isolated agent desktops on a single machine, with a deduplicated filesystem and per-agent credential and network isolation. The second is that a task can switch harness mid-session, with the new agent picking up where the previous one left off, because context carries across the switch. That is what makes the cost argument in the README coherent: start on a cheap local model, escalate to an expensive one only when needed. The material does not describe how the deduplication is implemented or what the isolation boundary is (container, VM, or something else), so those are questions to resolve from the deployment docs rather than from the README.

Getting it running: the installer, the Helm path, and what you must attach

The README gives one concrete install path for Docker. Download the installer, make it executable, run it with sudo:

curl -sL -O https://get.helixml.tech/install.sh chmod +x install.sh sudo ./install.sh

The README states the installer prompts before making changes to your system, and that by default the dashboard is available on http://localhost:8080. For a deployment with a DNS name it points to ./install.sh --help and the docs, which it says cover TLS termination. The Kubernetes path is described as the production route and uses Helm charts, but the supplied README text is truncated mid-sentence at that point, so the chart name, values file and required settings cannot be confirmed from this material. Two follow-up steps are named explicitly: attach your own GPU runners per the runners docs, and configure an external OpenAI-compatible LLM (the README gives vLLM as the example, pointed at your server's OpenAI-compatible URL). Both of those are configuration obligations, not optional extras. Without GPU runners you do not get the accelerated desktops, and without a model endpoint you have no models.

The harness and provider matrix, and what swapping actually buys you

Helix does not ship its own coding agent. It drives harnesses you already use: Claude Code, OpenAI Codex, Gemini CLI, Qwen Code, Goose, Zed Agent, and anything that speaks ACP (Agent Client Protocol). Source control integrations cover GitHub, GitLab and Azure DevOps, so PRs open where the code already lives. On the model side the README lists hosted providers (OpenAI, Anthropic and others), Anthropic through a Helix proxy including on Google Vertex AI and AWS Bedrock, and self-hosted models via any OpenAI-compatible endpoint. The per-task harness selection is the part that differentiates Helix from a wrapper around one vendor's agent. It also means the quality of any given task depends on the harness and model you point at it, and on whether your endpoint behaves the way the harness expects. The README does not state which harness versions are tested or what happens when a harness changes its protocol; treat the ACP claim as a compatibility promise you should verify against your own harness build.

Where Helix is the wrong tool

The clearest failure mode is infrastructure mismatch. Helix is self-hosted end to end, and the README explicitly targets air-gapped deployments, which means you carry the operational load: containers or Kubernetes, GPU runners, persistent storage for projects and sandboxes, and a model endpoint. A team without GPU capacity gets the Kanban board and the spec flow but not the accelerated desktops, which removes a large part of the reason to choose it. A solo developer gets a multi-service stack to operate in exchange for parallelism they may not need. There is a second, subtler cost: the six-column flow adds a planning and spec review step before any code is written. For a one-line fix, that ceremony is overhead, and the README's own framing (describe an outcome, approve a plan, review a PR) assumes tasks large enough to justify a spec. Finally, the repository carries a NOASSERTION licence label, meaning the licence could not be automatically identified. The README does not discuss licensing, so anyone planning to redistribute or embed Helix needs to read the actual licence file before making a decision.

The alternative: a local CLI agent, and the real difference in approach

The honest comparison is the one the README sets up itself: running Claude Code, Codex or Gemini locally. The difference is not the model, since both can point at the same providers. It is where the execution and the coordination live. A local CLI agent runs in your shell, in your working copy, under your credentials, and its state ends when the terminal closes. Helix runs the agent in a server-side sandbox with its own filesystem and network identity, keeps the session state on the server so a teammate in another time zone can open the same task and continue, and gates progress through the board rather than through your attention. The trade is control for coordination: the local agent needs no cluster, no GPU node and no Helm release, but it also cannot run ten tasks in parallel while you are asleep, and it cannot be reviewed by anyone but you. If your bottleneck is your own attention on one machine, Helix solves a problem you do not have.

Maintenance, release cadence and the licence question

The repository is active: three releases in the days before the last push, 2.12.11 through 2.12.13, with the most recent pushed on 2026-09-10. A patch-level cadence at that rate is a maintenance signal in both directions. You get fixes quickly, and you also get a moving target: if you deploy the Helm chart or the Docker installer, expect to track releases rather than pin once and forget. The README does not describe an upgrade procedure, a migration path between versions, or a support policy, so the upgrade cost cannot be estimated from this material. On licensing, the repository is labelled NOASSERTION, which means GitHub could not match the licence file to a known identifier. That is not the same as having no licence, and it is not a statement about what the terms permit. Read the licence file in the repository and, if you intend to offer Helix as part of a commercial service, get your own legal review rather than relying on the label.

Editorial conclusion

Adopt Helix if you already run Kubernetes or Docker with GPUs on your own hardware, want agent work to live on a shared board instead of individual laptops, and are willing to operate a multi-service stack. Do not adopt it if you have no GPU capacity, no container orchestration experience, or only need a single agent on one machine; a local CLI is cheaper and simpler. Before committing, verify three things: the exact licence text behind the NOASSERTION label in the repository, whether your chosen harness and model endpoint are supported in the current release, and what the Helm chart expects in terms of runner nodes and persistent storage.

Official sources

1. helixml/helix on GitHub
2. Issues
3. Project website
4. README
5. Releases