Helix Private Coding Fleet
Run parallel coding agents on your infrastructure, from reviewed specs to pull requests.
- Source repo
- helixml/helix
- Stars
- ★ 809
- Last updated
- 5d ago
- License
- NOASSERTION
- Primary language
- Go
- FA score
- 43/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformCodex · Claude Code · OpenAI API · Claude API
- You'll need
- Typical use
- 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.
- Main limitation
- 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.
- Source review
- 43/100 · Major gaps
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.
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.
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 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.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| Helix Private Coding Fleet This agent | 43 · Major gaps | ★ 809 | 5d ago | Go | Codex · Claude Code · OpenAI API · Claude API |
| Symphony | 47 · Major gaps | ★ 27k | 8d ago | Elixir | Codex |
| fx Coding Agent | 63 · Some gaps | ★ 3.1k | 4d ago | Zig | ChatGPT · Codex · OpenAI API |
| Helmor Local Agent Workbench | 52 · Major gaps | ★ 1.3k | 2mo ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence: README claims isolated sandboxes, credential and network isolation per agent, but no implementation details. Installer prompts user, but specific permissions not detailed. Data flow transparency limited, only mentions tracing and observability. Sensitive data handling has DPA mention, but not detailed. Many dependencies, but no security audit. External effects include opening PRs, sending notifications, but user confirmation not explicit. Rollback not mentioned. Source attribution: contributors must assign ownership to HelixML, but publisher identity unverified. Deductions: most security claims lack code evidence, user confirmation and rollback not explicit.
Evidence: README workflow consistent with code structure, but not verified. Many dependencies, but no availability guarantees. Failure messages not documented. Deductions: lack of test evidence and failure handling documentation.
Evidence: Target audience clear (development teams), scenarios diverse (parallel agents, multiple models). Capability boundaries not explicit, trigger precision (e.g., task approval) described but not detailed. Environment fit: supports Docker, K8s, multiple LLM providers. Deductions: capability boundaries and trigger precision lack implementation details.
Evidence: Information architecture clear (README, docs links), install notes detailed (Docker, K8s). Naming stable but no version history. Examples and FAQ limited. Known limitations not explicit. License is custom, restricts commercial use. Versioning changelog not provided. Maintenance responsibility: contributors must assign ownership, but maintainers not explicit. Deductions: license unclear (NOASSERTION), versioning and changelog missing.
Evidence: Output usability high (PRs, Kanban), marginal value clear (parallel agents, multiple models). Cost-benefit: claims cost reduction, but no specific data. Deductions: cost-benefit lacks evidence.
Evidence: Some claims in README traceable (e.g., feature list), but lack independent verification. Cross-source corroboration limited. Facts and inferences not clearly separated. Deductions: lack of tests and independent verification.
- License is custom, restricts commercial use, and metadata is NOASSERTION, requiring careful review.
- Publisher identity unverified, contributors must assign ownership, posing IP risks.
- Security claims (e.g., isolation, credential management) lack code evidence, need further verification.
- Many dependencies, no security audit, posing supply chain risks.