Executor mode

Keep your assistant. Add a Flash worker.

Keep your current model in charge of planning and review. Configure Flash as a separate worker with its own provider, context and output budget, then hand it bounded tasks.

What executor mode means

Separate roles. Separate context.

Use a Hermes delegation child, a ZCode native subagent, or a standalone Hermes process under harnesses such as Claude Code, Codex, Hermes, Pi or Cursor — not every harness has native delegation support. Configure a sandbox and isolated workspace before authorizing writes; separate context alone does not isolate tools. To make Flash the primary model instead, use primary mode.

Your original assistantHermesPiZCodeCursorCodexClaude CodeParent model stays unchanged

Separately configured Flash workerSeparate context and provider configurationConfigure provider + budgets before any skill

Isolated filesTask-owned workspacePermissions chosen by the controller

Artifact outPatch, report, resultPermissions chosen by the controller

Original assistant verifiesReview, integrate, own acceptance

Setup facts

Connection and token budget

Base URL: https://api.teralor.com/v1
Model: Flash (exact, case-sensitive)
Transport: Chat Completions (POST /v1/chat/completions)

Flash's current limits: 262,144 total context, up to 262,144 input and 131,072 output tokens. These ceilings are not additive: complete prompt tokens + reserved output ≤ 262,144. Input includes system instructions, tools, skills, history and new messages.

Check GET /v1/models with your own key before setup. Use the returned context_length, max_input_tokens and max_output_tokens if lower. A 401means credential or access setup must be fixed. Start with one worker; increase only within your account's verified concurrency allowance.

The downloadable Hermes and Pi example configs request 32,768 output tokens and compact at 172,032 prompt tokens. These are recommended working budgets for those configs, not API limits and not a setting supplied by ZCode or Cursor, which expose no user-facing compaction threshold. Omitting max_tokens reserves the full output ceiling instead, leaving only 131,072 prompt tokens; use a 98,304 compaction trigger for that policy.

One window. Shared by input and output.

262,144 total tokens · recommended working allocation

Prompt ceiling: 229,376
Output reserved: 32,768
Compact near (Hermes/Pi configs): 172,032

Compaction leaves room for the next message and tool results. It is a history-management trigger, not a hard input limit; a single oversized message can still be rejected.

Handle the key securely first

Export your customer key in the shell that launches the harness. Keep it out of config examples, prompts and Git; use your secret manager for persistent service setup. Use a key for the environment shown above. Downloaded configs are canonical public-API examples.

Secure key setup (Bash — Linux, macOS, WSL)

# Bash (Linux / macOS / WSL) — prompt once, keep the key out of history
read -r -s -p 'Teralor API key: ' TERALOR_API_KEY; printf '\n'; export TERALOR_API_KEY

Confirm YOUR access and limits (run before configuring anything else)

# Metadata check with YOUR customer key (process substitution keeps it out of argv)
curl -fsS --header @<(printf 'Authorization: Bearer %s\n' "$TERALOR_API_KEY") https://api.teralor.com/v1/models

Worker setup

Hermes worker paths

Both paths use the same public API and recommended budget. Choose native delegation for Hermes, or an external Hermes process for another harness.

Path A — Hermes native delegation child

Merge the provider and delegation blocks into your current orchestrator profile. Leave its own model and context settings unchanged. Replace YOUR_PROFILEwith that profile's name:

Configure, enable delegation, then restart

hermes -p YOUR_PROFILE config edit
hermes -p YOUR_PROFILE tools enable delegation
hermes -p YOUR_PROFILE chat

hermes-executor.yaml

Download hermes-executor.yaml

Merge into your current orchestrator profile config. Do not replace the whole file.

The named provider resolves Flash's endpoint and key together and supplies its 262144-token context. Do not add delegation.context_length or delegation.max_tokens: this version does not consume them. A lower parent compaction cap still wins; max_iterations counts turns. Native children do not load a standalone worker profile. See the Hermes delegation guide.

View hermes-executor.yaml

# Teralor Flash as a NATIVE DELEGATION WORKER under your existing Hermes
# orchestrator profile. Merge into the CURRENT orchestrator profile config
# (hermes -p YOUR_PROFILE config edit). This file deliberately contains NO
# model/context/compression top-level sections: the parent model and its
# context stay exactly as they are. Restart in a fresh session with the
# delegation tool enabled.
# The named provider below resolves its own endpoint and key via key_env, so
# base_url/api_key are omitted to avoid the direct-endpoint branch, which
# can inherit the parent's key. There is no delegation.context_length or
# delegation.max_tokens option (they are ignored/nonexistent): the provider
# model metadata below supplies the child's 262144 context. A lower global
# compression.threshold_tokens can still clamp children. max_iterations counts
# turns, not output tokens. Native children do NOT load the separate
# flash-worker profile.
providers:
  teralor-flash:
    api: https://api.teralor.com/v1
    key_env: TERALOR_API_KEY
    transport: chat_completions
    default_model: Flash
    discover_models: true
    models:
      Flash:
        context_length: 262144
    extra_body:
      max_tokens: 32768
delegation:
  model: Flash
  provider: custom:teralor-flash
  compression_threshold_tokens: 172032
  max_concurrent_children: 1
  max_iterations: 50

Path B — Standalone Flash worker (portable executor)

Install Hermes from its official guide, then create a dedicated worker profile. Download hermes-primary.yaml and merge it into the new profile. Keep the original harness's model/provider config unchanged.

One-time worker profile setup

hermes profile create flash-executor
hermes -p flash-executor config edit   # merge hermes-primary.yaml here

Launch a bounded task in an isolated, task-owned directory

cd /path/to/isolated/worktree
hermes -p flash-executor chat --oneshot --max-turns 8 \
  -q "Read README.md and summarize it. Do not edit files."

Have the parent run this command through its terminal tool and inspect the returned result. For real tasks, use --query-file task.mdwith the goal, allowed files and acceptance checks. The prompt's read-only instruction is not a sandbox; retain tool approvals and isolation.

Per-parent notes

Executors under each harness

Every note below keeps the parent's own model unchanged. ZCode delegates through a native subagent; Cursor drives the standalone Hermes worker; Codex and Claude Code support Flash as executor only.

ZCode — native subagent

Reuse the same provider and Advanced-limits setup as the ZCode primary guide, but leave the primary model unchanged. These GUI instructions follow the linked ZCode docs and are not a claim of live Flash certification.

Install ZCode from its official docs, then open the chat model selector → Manage Models → Settings / Model Settings (the docs also call this Model Providers). See the ZCode configuration docs.
Add a Provider named Teralor Flash; choose the OpenAI-compatible protocol/endpoint, not Anthropic. The API base URL must be https://api.teralor.com/v1(match the environment), and enter your own matching customer key in the app's API-key field — never paste the key into chat or source control.
Add a Model with the exact ID Flash and enable the provider/model.
Open the model's Advanced settings: context window 262144, Max output tokens 32768, or lower if your authenticated /v1/models result says so. These are the product context and recommended per-reply output, not additive limits. Custom-provider context edits apply to new sessions after saving.
Keep optional thinking controls unset unless your route supports them. Provider options only accept connection fields — arbitrary reasoning/extra_body keys are silently ignored.

Go to Settings → Subagents → New (custom subagents are Beta and user-level). Name it flash-executor and choose the configured Flash model explicitly — not Inherit default.
For the first read-only check allow only Read/Grep/Glob; add Edit/Write/Bash only for authorized coding. The description tells the primary when to delegate; the system prompt specifies goal, allowed files, tests and result format. See the ZCode agents docs.
Save and enable, then start a new session (running sessions do not hot-reload). Invoke @flash-executor and verify the returned result with the unchanged primary model.

ZCode saves definitions under ~/.zcode/agents/<name>.md; select the model/provider in the UI rather than inventing an ID in a downloadable file. Optionally add a workflow skill at ~/.zcode/skills/flash-executor/SKILL.md, enable it via Settings → Skills → Refresh and invoke $flash-executor — a skill adds instructions; it is not a subagent or provider configuration. See the ZCode skill docs.

Cursor — standalone Hermes worker

Pinning an explicit custom/BYOK Flash model via a .cursor/agents model: field is not supported currently: support confirms model: inheritonly works when the parent already uses that custom model — which is not unchanged-primary executor mode. Instead, keep Cursor's model, key and base-URL settings unchanged and use the standalone Hermes worker path above through Cursor's terminal tool: first run the full runnable read-only command shown in Path B, then pass a task.md via --query-file and inspect the artifacts.

Hermes, your customer-key environment, the workspace and approved tool/network access must exist on the machine actually running the terminal — a local install does not automatically exist in SSH or Cloud workspaces. Do not disable all sandboxing. Optionally add .cursor/skills/flash-executor/SKILL.md (or the shared .agents/skills location), restart/discover, then /flash-executor to attach instructions — this does not configure model routing. See the Cursor skills docs.

Codex — executor only

Using Flash as the orchestrator in Codex is not possible at the moment — Flash is an executor here only. Keep Codex's own model unchanged and drive the standalone Hermes worker from Codex, then optionally load the workflow skill into Codex once a bounded worker task succeeds.

Claude Code — executor only

Using Flash as the orchestrator in Claude Code is not possible at the moment — Flash is an executor here only. Keep Claude's own model unchanged and drive the standalone Hermes worker from Claude Code, then optionally load the workflow skill once a bounded worker task succeeds.

Skills come after configuration

Once a bounded worker task succeeds, install the optional workflow skill in the parent harness:

Claude Code: .claude/skills/flash-executor/SKILL.md
Codex: .agents/skills/flash-executor/SKILL.md
Cursor: .cursor/skills/flash-executor/SKILL.md
ZCode: ~/.zcode/skills/flash-executor/SKILL.md (enable via Settings → Skills → Refresh)
Hermes: the active profile's skills directory
Pi: .pi/skills/flash-executor/SKILL.md

Tell the parent to use the configured Flash worker, not an inherited default subagent. The skill adds task-scoping and review instructions; it does not install the connection.

Verify before your first real task

Confirm the selected model is Flash, the endpoint is the public API and the expected context and output settings are loaded in a fresh session. Then run one small read-only task and check its result.
Our public Flash execution path uses Hermes workers. The server's separate internal Codex endpoints and smaller worker window are local policies, not settings required on your machine.
Settings were checked against Hermes 0.21 and Codex 0.151 source. Pi is documentation-backed. The ZCode and Cursor GUI instructions follow the linked vendor docs and support notes and are not a claim of live Flash certification. Syntax and budgeting checks are not end-to-end compatibility tests.

Harness skill

Flash Executor

Your AI leads. Flash executes.

Keep planning, decisions, and final review with your preferred assistant. Delegate bounded tasks to Flash, running independent work in parallel when your harness supports it.

Download skill

View skill instructions

---
name: flash-executor
description: Use when the user requests Teralor Flash, Flash workers, or parallel task execution through Flash in an IDE or agent harness, including multi-part coding, research, document transformation, and batch analysis tasks.
compatibility: Requires authorized Flash access and a harness with explicitly Flash-routed workers or a trusted HTTPS request tool. Concurrent execution requires concurrent tools. This skill supplies instructions, not a worker runtime or universal IDE configuration.
metadata:
  author: Teralor
  version: "1.0.0"
---

# Flash Executor

Keep your current model as orchestrator. Use Flash for bounded execution, favoring independent concurrent jobs over a long serial conversation. Optimize for verified task completion, not worker count or token volume.

## Prerequisite: configuration comes first

Before using this skill, the harness must already have a configured Flash provider: endpoint `https://api.teralor.com/v1`, transport Chat Completions, the exact model `Flash`, a securely stored customer key, and supported context/output/compaction settings reviewed against authenticated `GET /v1/models`. See the public setup guides at `https://teralor.com/orchestrator` and `https://teralor.com/executor`. This skill installs no runtime and may not set any configuration; if connection or budget configuration is missing, stop and report the setup gap instead of dispatching.

## 1. Establish the execution path

Check the tools and configured providers actually available in this harness. Choose the first supported path:

| Available capability | Execution path |
| --- | --- |
| Workers can explicitly select the Flash provider/model | Launch tool-enabled Flash workers with isolated context and workspace grants. |
| Native workers inherit another model, but a trusted API request tool exists | Make bounded Flash API requests through that tool; receive findings, transformed content, or proposed patches. The host executes local tools and applies validated changes. |
| Neither exists | Report the missing capability and stop Flash dispatch. Do not invent a CLI flag, pretend parallel execution occurred, or silently use another model. |

Preserve the primary assistant's model and configuration. A worker named "Flash" is not proof of routing: set the provider and exact model explicitly, and inspect nonsecret request/dispatch metadata. Do not use inherited worker defaults unless they are verified to route to Flash.

### Flash API contract

- Base URL: `https://api.teralor.com/v1`.
- Model identifier: `Flash` (case-sensitive).
- Discovery: authenticated `GET /v1/models`.
- Generation: authenticated `POST /v1/chat/completions`.
- Authentication: HTTP bearer credential from the user's configured secret store or trusted client environment. Never include its value in prompts, URLs, source files, browser code, logs, or reports.
- Public guide: `https://teralor.com/api`.

Before the first dispatch, query discovery through the trusted client and confirm Flash access. Use the returned capabilities and limits rather than remembered context sizes or advertised concurrency. Use only advertised `reasoning_effort` values when reasoning controls are available. Check tool-calling or other optional features before relying on them; API compatibility alone is not proof of support. Account-wide concurrency may require account settings or onboarding documentation if discovery omits it. Do not invent missing fields.

A chat request supplies `model: "Flash"`, a `messages` array with the worker task/context, an appropriate `max_tokens` output budget, and an explicit `stream` choice. With an SDK base ending in `/v1`, do not accidentally append `/v1` twice. Keep input plus reserved output within the advertised total context limit, and respect separate input/output caps where reported. Prefer compact context over filling the entire window.

A raw completion cannot read a repository, run tests, or edit files unless the harness supplies and authorizes a tool-execution loop. Treat returned tool requests and patches as proposals until the trusted harness validates and executes them. Never execute response text blindly as shell commands.

## 2. Decompose by independent outcomes

Inspect the task, relevant inputs, and acceptance criteria before dispatching. Keep product choices, architecture, shared contracts, dependency ordering, and final acceptance with the orchestrator. Workers execute settled slices.

Build a small task ledger with stable IDs, dependencies, owned inputs/outputs, and states: `queued`, `ready`, `running`, `produced`, `verified`, `failed`, `uncertain`, or `blocked`. A dependency is satisfied by a verified artifact, not a confident completion message.

Prefer splits such as independent modules against a fixed interface, document batches with distinct output files, research questions with separate source lists, or test fixtures against an agreed contract. Define shared schemas and interfaces first; do not send dependent workers conflicting guesses.

For a trivial edit or genuinely serial task, do not manufacture a swarm. Use one bounded Flash job when the user requested Flash, or handle permitted orchestration work directly. Do not substitute the host for explicitly requested Flash execution without saying why it is unavailable.

## 3. Compile each worker packet

Give each worker a self-contained packet, not the entire parent conversation:

- **Identity and goal:** task ID, one observable outcome, expected artifact/count.
- **Inputs:** relevant source excerpts or permitted paths, baseline/revision, settled interfaces, already verified dependencies.
- **Ownership:** exact writable files or output artifact names; everything else read-only.
- **Constraints:** invariants, non-goals, data/permission boundaries, no additional delegation, no global settings changes, no publishing or destructive actions without the user's authorization.
- **Acceptance:** required checks and exact runnable commands when available; distinguish tests the worker can execute from controller-only checks.
- **Budget and stop conditions:** output/context budget, bounded attempt allowance, ambiguity or scope conflict means return a blocker.
- **Return contract:** task ID; completed/blocked/failed status; artifact paths or actual content/patch; changed files; checks really run and their results; assumptions, unresolved issues, and truncation status.

For code changes, request a failing regression or reproducer before the fix where applicable, then focused passing checks. An API-only worker should return test/code proposals and explicitly say tests were not run.

## 4. Schedule a bounded, replenished queue

Set a local concurrency ceiling from verified account headroom, harness/tool limits, ready task count, and the approved resource budget. Account headroom includes all clients and the orchestrator's own requests if it also uses Flash. A local semaphore cannot reserve capacity against other applications; handle server admission as authoritative.

If account concurrency is unknown, do not invent an entitlement: begin with at most one authorized request while obtaining reliable limits. If there is no headroom, queue rather than dispatch. Never hardcode eight workers or promise a proportional speedup.

Dispatch independent ready jobs together using the harness's actual asynchronous/batch mechanism. Do not send one request and await it before starting the next independent job. Consume results as they arrive, verify each produced artifact, and launch newly unblocked useful work without waiting for unrelated slow tasks. Avoid constant status polling and duplicate submissions; use supported completion notifications or bounded waits.

Use separate workspaces for concurrent coding writers, with explicit ownership even when branches are isolated. Do not let workers edit shared configuration, dependency manifests, or interfaces concurrently. If isolation is unavailable, run read-only/proposal workers in parallel and make the orchestrator the sole writer. Separate workspaces do not isolate shared databases, ports, services, or remote state; serialize or sandbox those resources too.

## 5. Handle failure without multiplying it

- Authentication or access failure: stop dispatch and report setup/access requirements. Never guess credentials or fall back to another model silently.
- Rate/concurrency rejection: lower local pressure and honor documented retry guidance, including `Retry-After` when supplied. Retry only when safe under the known dispatch status, within a bounded budget; do not retry indefinitely.
- Interrupted streaming, timeout, or unknown dispatch: mark the task `uncertain`, preserve partial output as incomplete, and do not immediately assume its request slot or workspace is free. Reconcile through supported harness/provider status or confirmed cancellation before resubmission. If no such mechanism exists, report the uncertainty and obtain an explicit recovery decision; do not invent a status endpoint or automatically replay a potentially dispatched request.
- Truncated/malformed output or failed acceptance: do not mark complete. Preserve useful artifacts and give at most one narrow repair packet with concrete failure evidence. If it still fails, the orchestrator replans the slice or reports the blocker instead of starting an endless worker loop.
- Changed requirements or contracts: invalidate affected dependent work and stop/reconcile its active writers before replacement. Do not restart unaffected verified jobs.

Cancellation must account for active workers and pending tool operations. Do not remove a workspace or run destructive cleanup while its execution status is unknown.

## 6. Integrate and prove completion

Inspect the actual returned bytes, file scope, baseline compatibility, and evidence. For batches, reconcile every requested input ID against returned artifacts; detect missing and duplicate items programmatically when tools permit. A claim of three outputs with only two artifacts is incomplete.

Accept only artifacts that satisfy their contract. Apply accepted changes through the orchestrator's single integration path, resolve conflicts deliberately, then run the relevant combined tests, build, lint, or domain-specific validation. Worker-reported passing tests are development evidence, not a substitute for final integration checks. Never fabricate files, citations, command output, test results, or successful execution.

Report the delivered result, actual Flash execution path and observed concurrency, checks performed, remaining uncertainty, and any unavailable capability. Distinguish measured elapsed time from estimates. Do not infer task speedup from aggregate token throughput or claim parallel execution when tools ran serially.

## Example: dashboard CSV export

The orchestrator settles columns, encoding, escaping, permissions, and the endpoint/UI contract. It then dispatches independent Flash jobs for backend implementation, UI controls, and contract-based edge-case fixtures, each with separate ownership and workspace. As artifacts pass acceptance, it starts ready dependent work without waiting for an unrelated slow job. It integrates all required outputs and exercises the export end to end before declaring completion.

If that same request is only changing the label from `Export` to `Export CSV`, use one small Flash job, not three workers.