Skip to main content
Skip to Content
DocsGetting Started

Heliox is a dashboard for designing agentic flows — DAGs of LLM and tool-calling steps — and integrating them into external systems through portable, conformance-verified cross-runtime SDKs. It’s local-first, Apache-2.0, and bring-your-own-key (BYOK): your provider tokens and your flows never leave your machine unless you choose to serve or export them.

This page gets you from zero to a running flow in a few minutes.

1. Install Heliox

Option A — download the installer. Grab the build for your platform from the download page or directly from the GitHub releases . macOS (.dmg, Apple Silicon and Intel), Windows (.exe), and Linux (.deb, .rpm, or a portable .zip) are all published there.

Option B — build from source.

git clone https://github.com/CMolG/heliox-ide.git
cd heliox-ide
npm install
npm start

npm start boots the Electron desktop app in development mode. On first launch, Heliox opens straight onto an empty canvas — the surface where flows are designed.

2. Connect a model provider

Before a step can run, Heliox needs somewhere to send prompts. Open Provider Connections and add a profile: pick a protocol (OpenAI- or Anthropic-compatible), a base URL, and paste in your API key. The key is encrypted at rest via the OS keychain (Electron safeStorage) — Heliox never phones home with it. See Provider Connections for the full walkthrough, including per-model enable flags for multi-model providers.

3. Design your first flow

A flow is a small DAG of steps. Each step is an execution unit — an llm_call, tool_call, or router — with a prompt, optional tools, and dependencies on earlier steps. You have two ways to build one:

  • Canvas. Drop a step node onto the canvas, wire it to its dependencies, and write its prompt. Add more steps and connect them to shape the DAG.
  • Text-to-Flow. Describe the outcome you want in one sentence and let the meta-agent compiler assemble a full step DAG for you — roles, mods, and dependency wiring included. You can then open any generated step and adjust it by hand.

See Flow Design for a deeper walkthrough of both paths, and Core Concepts for the mental model behind steps, flows, loops, and checkpoints.

4. Attach a role and a mod

Open a step’s inspector and attach:

  • A role — the persona executing the step (e.g. frontend-engineer, security-researcher). Exactly one role per step.
  • A mod — a stackable constraint layered on top, injected into the step’s system prompt (e.g. test-driven, strict-linting). You can stack several compatible mods on the same step.

Both are drawn from the signed marketplace catalog — see Roles & Mods for the full list and how composition works.

5. Run it

Heliox gives you three granularities of execution, all reachable from the canvas:

  • Run the whole flow, start to finish.
  • Run step — execute a single step in isolation.
  • Run from here — re-execute from a chosen step through the rest of the DAG, reusing the already-completed upstream context.

Every step completion is captured as an immutable checkpoint, so you can rewind through a run, inspect what a step actually saw and produced, and Fork from here to branch a new attempt from any point in the history. See Core Concepts for how time-travel and forking fit into the execution model.

6. Export a portable .flow.json

Once a flow works the way you want, export it. Heliox writes a vendor-neutral HelioxFlowExport (format version 1) JSON file that captures the DAG, prompts, tools, contracts, model overrides, and loops — everything needed to run the same flow outside the IDE.

That file is what powers the rest of the platform:

Next steps

  • Core Concepts — the mental model: steps, flows, loops, checkpoints, roles, mods, contracts.
  • Flow Design — canvas and Text-to-Flow in depth.
  • Cross-Runtime SDKs — run an exported flow on TS, Java, or Python.
  • Architecture — how the pieces fit together end to end.
Last updated on
ArchitectureCore Concepts