Helix Private Coding Fleet
Run parallel coding agents on your infrastructure, from reviewed specs to pull requests.
What does this agent do, and when should you use it?
Helix is a private coding-agent fleet platform organized around projects, connected Git repositories, and Kanban-based spec tasks. A task progresses through Backlog, Planning, Spec Review, In Progress, Pull Request, and Merged: a planning agent writes a specification to a helix-specs branch, then an approved implementation agent changes code and opens a PR. Each active agent runs in an isolated, GPU-accelerated desktop environment with a browser, terminal, filesystem, and GUI applications. Teams can observe work live, steer it through the task thread, and switch agent harnesses during a task. Helix supports Claude Code, OpenAI Codex, Gemini CLI, Qwen Code, Goose, Zed Agent, and ACP-compatible agents, with GitHub, GitLab, and Azure DevOps source-control connections. It offers Docker installation plus Kubernetes Helm charts for the control plane and GPU runners, including an end-to-end self-hosted and air-gapped deployment path.
A user connects one or more Git repositories to a project and creates a spec task on the Kanban board. Selecting Start Planning causes a planning agent to read the repository and write requirements, design, and task breakdown to a helix-specs branch; the user can request changes by highlighting text or approve the specification. In In Progress, an implementation agent runs in its own desktop sandbox using the selected agent harness, with access to a browser, terminal, filesystem, and GUI apps; users can watch live, steer through the task thread, or switch agents mid-session. When the work is complete, Helix opens a Pull Request in the connected source-control system, and the task closes after the PR merges. The platform also ingests PDF, Word, text, and scraped web content for knowledge/RAG, integrates tools through REST/OpenAPI, MCP, GPTScript, and a custom-tool SDK, and traces LLM, API, and MCP requests alongside token usage and cost.
- An engineering team with several independent features or bug fixes that wants to dispatch coding work in parallel while retaining a shared board and PR review.
- An enterprise running self-hosted models in a controlled or isolated network that needs coding agents and GPU runners on its own infrastructure.
- A project lead using GitHub, GitLab, or Azure DevOps who wants to approve an agent-produced specification before implementation and keep the PR as the final review gate.
- A development team that needs to choose or switch among Claude Code, OpenAI Codex, Gemini CLI, Qwen Code, or an ACP-compatible agent for individual tasks.
- An internal engineering group that wants agents to work with PDF, Word, text, or scraped-web knowledge through the documented RAG capabilities.
What are this agent's strengths and limitations?
- It makes specification review and pull requests explicit gates: plans are written to a helix-specs branch and implementation returns through the existing code-hosting workflow.
- Each agent receives an isolated, GPU-accelerated desktop with a browser, terminal, filesystem, and GUI apps rather than only a shared terminal session.
- Tasks can select or switch among Claude Code, Codex, Gemini CLI, Qwen Code, Goose, Zed Agent, and ACP-compatible agents, while also supporting OpenAI-compatible endpoints.
- It provides both a Docker quick start and Kubernetes control-plane and runner Helm charts, with documented self-hosted and air-gapped operation.
- RAG, OpenAPI/MCP tool connectivity, OIDC, RBAC, and usage/cost tracing are included for teams centralizing agent operations.
- Local development explicitly requires Docker, Docker Compose, Go 1.24.0+, Node.js 18+, and Make; production also requires planning for a control plane and GPU runners.
- Hosted-model usage requires the relevant OPENAI_API_KEY or ANTHROPIC_API_KEY, while self-hosted use requires a reachable OpenAI-compatible endpoint and customer-managed GPU capacity.
- The spec, approval, and PR workflow suits collaborative delivery but may be heavier than a one-off, local terminal-assistance workflow.
- Large commercial use is subject to license terms: companies with more than $10M in annual revenue or 250 employees must purchase a license through Launchpad.
- The README does not specify per-host agent density, GPU sizing, resource-scheduling behavior, or feature differences between supported agent harnesses, so capacity planning needs independent validation.
How do you install or deploy this agent?
For the Docker quick start:
curl -sL -O https://get.helixml.tech/install.sh
chmod +x install.sh
sudo ./install.shThe installer prompts before changing the system, and the dashboard defaults to http://localhost:8080. Production deployment is documented through Control Plane and Runner Helm charts. Server configuration uses environment variables: configure OPENAI_API_KEY or ANTHROPIC_API_KEY for the chosen hosted provider, POSTGRES_* for database connectivity, SERVER_URL for the public deployment URL, and RUNNER_* for GPU runner configuration. Local development requires Docker Desktop, or Docker with Docker Compose, plus Go 1.24.0+, Node.js 18+, and Make.
How do you use this agent?
Open http://localhost:8080 after installation, create a project, and connect one or more Git repositories. Create a spec task in Backlog that states the desired outcome, then select Start Planning; the planning agent writes the specification to the helix-specs branch. Review it in Spec Review, highlighting text to request changes or selecting Approve. In In Progress, choose an available agent harness and steer the agent through the task thread; switch agents if needed. The completed agent opens a PR in the connected source-control system, and merging that PR moves the task to Merged.
How does this agent compare with similar options?
Helix runs agents server-side in separate desktop environments and manages them through a shared Kanban board. Its stated contrast is the local-terminal pattern of running one Claude Code, Codex, or Gemini agent on a developer’s laptop; Helix uses those harnesses as selectable task executors rather than replacing them.