Connect tools
Supported Flash connection roles per harness — Hermes, Pi, Cursor, ZCode, Claude Code, and Codex — with canonical setup-skill downloads.
Flash connects to a harness in one of two roles:
- Primary — the selected main session itself runs on Flash. Setup skills exist for Hermes, Pi, Cursor (BYOK), and ZCode. See the orchestrator page for full detail.
- Executor — your harness keeps its own model and drives Flash as a separate bounded worker. Setup skills exist for Hermes, Pi, Cursor, ZCode, Claude Code, and Codex. See the executor page for full detail.
Role support per harness:
| Harness | Primary | Executor |
|---|---|---|
| Hermes | yes | yes (native delegation child) |
| Pi | yes | yes (external Hermes worker) |
| Cursor | yes (BYOK, support-backed) | yes (external Hermes worker) |
| ZCode | yes (chat-model selection) | yes (native subagent) |
| Claude Code | no | yes (separate Hermes worker) |
| Codex | no | yes (separate Hermes worker) |
Claude Code and Codex have no stock direct Flash integration as a primary model: no Chat Completions, Responses, or Anthropic-API bridge is provided or assumed for them. Flash runs for them only through a separate, tool-enabled Hermes worker they launch from their terminal tool.
The canonical setup authority is the public executor and orchestrator
pages plus the downloadable setup skills linked below. Those skills are versioned,
inspect-before-write, and idempotent; this page tells you which one applies and what "done" looks
like, without duplicating their steps. Every path follows the same rules: run authenticated discovery
first (Start here), inject TERALOR_API_KEY through your secret manager, and
verify with a real run.
Hermes
Executor role. Flash runs as a delegation child inside your existing Hermes profile. The parent
profile keeps its own model, provider, and context untouched; only a distinctly-named worker provider
(teralor-flash-executor) and delegation keys are added.
Primary role. A new, collision-checked independent flash profile runs its main session on Flash
through a named teralor-flash provider. No existing profile is cloned or modified.
- Hermes 0.21+;
TERALOR_API_KEYresolvable by the Hermes process. - Authenticated discovery first — Start here step 4.
- Install the applicable setup skill and follow it: the executor route validates budgets from discovered limits and finishes with a real child-delegation check; the primary route finishes with a fresh-session activation and one real verification.
Setup skills: flash-executor-setup-hermes · flash-orchestrator-setup-hermes · Workflow skill: flash-executor · Full matrix: orchestrator page
Pi
Executor role. Pi keeps its own primary model and models.json untouched. Flash runs as a
separate Hermes profile that Pi drives through its shell/terminal tool in a trusted project.
Primary role. Flash becomes the selected main session in a chosen project via a named
teralor-flash provider in models.json and project primary selection. This changes the project's
selected model — unlike the executor route, which changes no Pi files.
- Pi installed (and, for the executor route, Hermes on the same machine);
TERALOR_API_KEYin the process environment. - Authenticated discovery first.
- Install the applicable setup skill; each finishes with a real verification run.
Setup skills: flash-executor-setup-pi · flash-orchestrator-setup-pi · Workflow skill: flash-executor
Cursor
Cursor supports both roles: primary through BYOK in a new Agent chat (support-backed recipe, with documented base-URL-scope caveats), and executor through an external Hermes worker launched from Cursor's terminal tool (Cursor cannot pin a custom model for its own subagents). Details and the download links live on the orchestrator page:
flash-orchestrator-setup-cursor and flash-executor-setup-cursor.
ZCode
ZCode supports both roles: primary by selecting Flash as the chat model in a new task (documented GUI
fields), and executor as a native @flash-executor subagent while ZCode's primary stays unchanged.
Both use the ZCode desktop GUI on the machine running it. Details and downloads:
orchestrator page —
flash-orchestrator-setup-zcode— and flash-executor-setup-zcode.
Claude Code (executor via separate worker)
Role. Claude Code stays on its own model and Anthropic configuration — never change
ANTHROPIC_BASE_URL or the native subagent model for Flash. Flash executes as a separate,
tool-enabled Hermes worker that Claude Code launches and supervises through its Bash tool.
- Claude Code with its Bash/terminal tool; Hermes installed on the machine running that tool.
- Discovery + key handling as above.
- The setup skill installs the worker profile and
.claude/skills/flash-executor/SKILL.md, then verifies a real worker invocation.
Setup skill: flash-executor-setup-claude · Workflow skill: flash-executor · Context: executor page
Codex (executor via separate worker)
Role. Same discipline as Claude Code: Codex keeps its own model, provider, and
~/.codex/config.toml — no Responses-API bridges, no provider swaps. A separate Hermes worker
profile, launched from Codex's terminal tool, does the Flash work.
- Codex with a terminal tool; Hermes installed locally.
- Discovery + key handling as above.
- The setup skill installs the worker profile and
.agents/skills/flash-executor/SKILL.md, then verifies with an actual run.
Setup skill: flash-executor-setup-codex · Workflow skill: flash-executor · Context: executor page
If your harness is not listed
The executor page shows the general Chat Completions integration contract for harnesses that can route an explicit provider/model with a securely stored key. Beyond the harnesses above, do not assume support: verify routing end-to-end (discovery + a real completion through the path you intend to use) before trusting it, and do not build bridges between APIs that are not offered.