Heliox is BYOK (bring-your-own-key): it never bundles a model subscription or proxies your prompts through a Heliox-operated backend. Instead, you register connection profiles — the same mental model DBeaver uses for databases, applied to model providers.

Adding a connection

A connection profile has:

• a name you choose,
• a protocol — openai or anthropic (compatible endpoints included — anything speaking the same wire protocol works, not just the official APIs),
• a base URL (pre-filled with the official default — https://api.openai.com/v1 or https://api.anthropic.com — but editable for self-hosted or proxied endpoints),
• an API token (optional — omit it for tokenless local endpoints),
• per-model enable flags once the connection reports which models it serves.

Testing a connection

Heliox probes the connection’s model-listing endpoint (${baseUrl}/models for OpenAI-protocol, ${baseUrl}/v1/models for Anthropic-protocol) and reports back the model ids it advertises. A successful test also refreshes the connection’s known model list, so newly available models show up as toggleable entries without re-creating the connection.

Where your token goes

The token is encrypted at rest via the OS-level secure storage Electron exposes (safeStorage) — the connection-profile file on disk never holds a plaintext secret. If the current OS/environment has no secure-storage backend available (some minimal Linux setups lack a keyring), Heliox falls back to storing it in plaintext with a loud warning rather than silently failing — you’ll know if you’re in that mode.

The renderer (the UI you interact with) never sees the decrypted token — every connection object crossing that boundary carries only a hasToken: boolean. The plaintext value is resolved main-process-side only, at the two points that actually need to send it to a provider: the connection tester and the harness’s model resolver when a step actually executes.

Using a connection in a flow

Once a connection is enabled for a given model, that model becomes selectable as a step’s model override or the flow’s default, addressed as conn:<connectionId>/<modelId>. This is what lets a per-step model override — the same field that round-trips through .flow.json export — point at one of your own connections rather than a Heliox-managed default.

Next steps

• Getting Started — connect a provider as part of your first flow.
• Serve & Deploy — the model a served flow executes against still resolves through your connections.