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
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 and use the returned limits if lower; a 401 means credential or access setup must be fixed first. The recommended working budget below is what every downloadable/mergeable configuration on this page uses: 32,768 reserved output, prompt up to 229,376, compaction near 172,032 (ZCode compacts automatically with no user threshold). The step-by-step key handling, configuration and launch commands live inside each harness panel — start with One-Promt Setup or open a panel below.

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.

Standalone skill

Flash skill

Already configured? Download or copy the Flash skill on its own. The per-harness setup panels below configure your role and install this same skill — you never need the setup package just to carry the skill between machines or share it with a teammate.

Download skill

View skill instructions

---
name: flash-executor
description: Use when executing tasks with Teralor Flash, including independently verifiable coding, research, document and batch outcomes. Preserve the coordinator and use bounded, dependency-ready parallel work.
compatibility: Requires configured, authorized Flash access and supported harness tools. Concurrency requires verified account headroom and an actual concurrent dispatch mechanism.
metadata:
  author: Teralor
  version: "2.0.0"
---

# Flash

Keep the current coordinator model, whether Flash or another model. The coordinator owns decisions, contracts, scheduling and acceptance; Flash executes settled outcomes. Optimize verified completion, not worker count.

## Check readiness

Use the installed harness binding and verify nonsecret route/model evidence; a worker called Flash is not routing proof. If access, budgets or binding are missing, stop and use the harness-specific [Executor onboarding](https://teralor.com/executor) or [Orchestrator onboarding](https://teralor.com/orchestrator). This skill does not configure providers or switch the primary model. Keep credentials out of prompts and artifacts. Raw completions cannot execute tools; treat their proposed patches as unexecuted until the trusted harness validates and applies them.

## Decompose by verifiable outcome

Inspect the inputs and acceptance criteria. Settle shared interfaces first, then split only where each result can be checked independently: a module against a fixed interface, a document batch with distinct outputs, or a research question with its own sources. Keep dependent work queued. For a trivial or serial task, use one bounded execution; never manufacture sixteen tasks.

Maintain a compact ledger: task ID, dependencies, owner, artifact and state (`ready`, `running`, `produced`, `verified`, `failed`, `uncertain`, `blocked`). Only verified artifacts satisfy dependencies.

Give each worker this compact contract, not the full conversation:

- **Outcome:** task ID, observable result and expected artifact/count.
- **Inputs:** baseline, relevant paths/excerpts, settled interfaces and verified dependencies.
- **Ownership:** writable paths, isolated workspace, invariants, non-goals and permissions.
- **Acceptance:** runnable checks, return format, budgets and stop conditions.
- **Return:** actual artifacts/patch, changed paths, checks really run, failures and uncertainty.

For code, require a failing regression/reproducer before the fix where applicable and focused passing checks afterward. Workers must not recursively delegate, change global configuration, publish or broaden permissions.

## Run a replenishing queue

When the account allowance is verified as **16 concurrent requests**, dispatch up to that allowance—not sixteen workers unconditionally. Bound active requests by remaining account headroom, harness/tool limits, resource budget and independently ready work. Count other clients and the coordinator's own Flash requests. A worker can emit multiple requests; request capacity is not a worker entitlement. Unknown allowance: use at most one authorized request while resolving it; zero headroom: queue. Server admission remains authoritative.

Launch independent ready jobs together through supported asynchronous/batch tools, rather than awaiting each before starting the next. Consume completions, verify artifacts and replenish newly ready work without waiting for unrelated slow jobs. Use completion notifications or bounded waits; avoid duplicate submissions.

Concurrent writers require separate workspaces and explicit file ownership. Serialize shared interfaces, databases, ports and remote mutations. Without isolation, parallelize read-only proposals and keep one writer. Without concurrent tools, execute serially and say so.

## Verify, repair, integrate

Inspect actual bytes, scope, baseline compatibility and evidence; reconcile requested IDs against outputs for missing/duplicate items. Run combined integration checks after accepting individual artifacts. Never substitute worker confidence for results.

Repair only the failed slice, once, with concrete failure evidence; retain unaffected verified work. Authentication failure stops dispatch. Rate limits reduce pressure with bounded, safe retries. Interrupted or unknown dispatch stays uncertain until reconciled or confirmed cancelled—never assume its slot/workspace is free or replay blindly.

Report delivered artifacts, actual routing and observed concurrency, checks and remaining blockers. Claim neither parallel execution nor speedup without measured evidence.

Per-harness setup

Set up your harness

Open the panel for the harness you use. Each one is complete on its own: configuration, secure key handling, the exact workflow-skill path and invocation, and a final verification step — no cross-referencing between panels. Every command shown is a Bash example; the setup skills also cover native Windows. Each setup configures the executor role and installs the Flash skill, so already configured users can just download or copy that skill alone from the standalone section above.

Harness

Manual copy: Codex setup instructions

Download the Codex setup skill

Set up and verify Teralor Flash as a separate EXECUTOR in Codex, following the complete instructions below. Keep Codex's own PRIMARY model, provider, context window and every unrelated setting unchanged — the only permitted changes are the executor-only ones the instructions specify (for native Hermes, adding the new worker provider and delegation keys is intended). The setup also installs the canonical Flash skill (identifier flash-executor) at the actual skill path the instructions name, validating the download and stopping on any conflict instead of overwriting existing customizations. Pause for me whenever secure credential entry, installation approval or a GUI step needs my action, and only report READY after real verification succeeds.

---
name: flash-executor-setup-codex
description: Use only when the user explicitly asks to set up, configure, or verify Teralor Flash as a separate executor worker for Codex while keeping Codex's own model unchanged. Installs/inspects a dedicated Hermes worker profile, secure TERALOR_API_KEY handling, budget validation, workflow-skill installation, and real verification. Reviewing or downloading this skill is not consent to change anything.
compatibility: Requires Codex with a terminal tool, Bash (or WSL) or native Windows PowerShell as noted, network access to https://api.teralor.com, and Hermes installed on the machine actually running the terminal. Installation steps require explicit user approval. Flash is NOT a native Codex model or subagent here.
metadata:
  author: Teralor
  version: "1.1.0"
---

# Flash Executor setup — Codex (external Hermes worker)

Run this skill only on an explicit user request to set up Flash as an executor in Codex. Reviewing or downloading it is not consent: present a concise plan, then act. The explicit setup request itself authorizes the scoped executor-only changes below — do not stop for a separate approval per already-authorized edit — while reading or downloading this skill authorizes nothing. Still pause for: software installation, missing secure credentials, name collisions or changes this task does not own, and any metered smoke test outside the authorization. Codex is currently executor-only for Flash — never edit `~/.codex/config.toml`, switch Codex's provider/model, or add Responses-API bridges. Flash runs as a separate Hermes process Codex drives from its terminal tool.

## 1. Protected scope (never modified)

- Codex's own model, provider and settings, including `~/.codex/config.toml`.
- Any existing Hermes profile, provider or skill that is not owned by this task.
- Task-owned additions only: the `flash-executor` Hermes profile (if absent), the provider keys listed below inside it, and `.agents/skills/flash-executor/SKILL.md`.

## 2. Discovery first

1. Detect the actual host OS/shell. Commands below are Bash (Linux/macOS/WSL). On native Windows use PowerShell equivalents and the official `install.ps1`; do not blindly run Bash snippets in PowerShell.
2. Check tools/versions you will rely on: `codex --version`, `hermes --version`, `command -v curl`.
3. Hermes install docs: https://hermes-agent.nousresearch.com/docs/getting-started/installation/ (CLI installer https://hermes-agent.nousresearch.com/install.sh; Windows native install.ps1). No private launcher or GPU/Docker image is required. Installing software needs the user's approval — fetch and review the official script before running it; never execute remote code blindly.

## 3. Inspect-before-write plan

- Before any write: read the target files/dirs you will touch; timestamp backups of every file you modify, keeping their permissions (0600 for anything secret-bearing).
- Parse and merge only the exact owned keys listed here; never dump whole configs or credential stores into model-visible output; do not follow unexpected symlinks.
- If a different `flash-executor` profile, provider or skill already exists, stop that step: reuse only when it already matches, otherwise choose a distinct name. Never overwrite, never create duplicates on rerun.
- Rollback: record every owned addition; to roll back, remove exactly those keys/files and restore the timestamped backups after checking the target was not edited by someone else since. Never use destructive resets, force flags, broad chmod, or sudo by default.

## 4. Secure TERALOR_API_KEY

- Resolve the key from the customer's own environment/secret store, or a private profile `.env` (permissions 0600). It must reach the actual worker process — confirm with a fresh launched process, not just a temporary shell export.
- Never place the key in chat, prompts, argv, URLs, project files, Git, config literals, or logs. A trusted local secret client may load it into process memory; print only allowlisted metadata such as set/missing, never the value or a model-visible read of the secret file.
- If no key exists for this environment, pause and ask the customer to enter it securely. Do not guess or borrow credentials from another service.

## 5. Verify the target API before configuring

- Target: `https://api.teralor.com/v1`, Chat Completions, exact model `Flash`.
- Run an authenticated `GET /v1/models` with the customer key and require an exact `Flash` entry. Stop on 401, a missing model, or an incompatible protocol — no internal aliases, renamed models, alternate paid providers, or silent fallback.
- Existing account only: no purchases, no quota resets. Ask before any metered smoke test that is not already authorized.

## 6. Budget validation

Ceilings (not additive): total 262144, input ceiling 262144, output ceiling 131072. Recommended working values: output 32768, prompt room 229376, compaction trigger 172032. Keep these defaults in the YAML template. From the authenticated `/v1/models` metadata compute C and I FIRST: C=min(262144, advertised total), I=min(262144, advertised input); every discovery field must be a positive integer. Then choose O=min(32768, advertised output ceiling, floor(C/2)) — never above the advertised output, and never above floor(C/2): the half-capacity cap reserves at least half the total context for input at small capacities. If C<2, or the resulting O is not a positive integer, reject the budget as `BLOCKED` — a previously recommended output value being too large for the advertised capacity is not a viable budget. Then client_window=min(C, I+O), prompt_room=client_window−O, trigger=floor(prompt_room*3/4); O must leave positive prompt room and is never applied at or above the total window. Lower the template when the account advertises lower. System, tool, skill and history tokens count as input. If discovery is missing or unverifiable, any capacity field is missing or not a positive integer, or a positive safe budget is impossible at the advertised capacity, STOP before applying or using any budget settings — `BLOCKED` (or `MANUAL_STEP_REQUIRED` while waiting for metadata). Never fall back to the template in that state, and never treat `READY` as reachable without verified limits plus the actual worker check in section 9. Hermes 0.21 ignores legacy `model.max_tokens`/`HERMES_MAX_TOKENS`; the output budget lives in provider `extra_body.max_tokens` and the compaction threshold is separate.

## 7. Create the isolated worker profile

Ordering matters. If the customer chose a private worker-profile `.env` and the profile does not exist yet, create ONLY the empty, collision-checked worker profile first, then PAUSE for secure key entry/authentication (`MANUAL_STEP_REQUIRED`) — never apply model/budget configuration before the section-5/6 metadata is verified. Never clone the parent:

```bash
hermes profile list
hermes profile create flash-executor --no-alias --no-skills   # only if absent — empty profile, collision-checked first
# pause here for secure key entry / authentication if the chosen mode needs it
hermes -p flash-executor config edit                          # merge, do not replace
```

Merge exactly these keys into `~/.hermes/profiles/flash-executor/config.yaml`, preserving all other settings. `teralor-flash-executor` is a deliberately distinct provider name, but a name that looks unique is not guaranteed collision-free: inspect the existing providers first, reuse only when an existing block matches exactly, otherwise choose a new name and substitute the ACTUAL chosen name in every path, command, invocation and binding below. Inspect worker fallbacks with `hermes -p flash-executor fallback list` and disable them only through supported CLI subcommands if present (`fallback remove` is interactive and takes no index in this release); never change the parent Codex setup or another profile's fallbacks.

```yaml
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032
```

## 8. Install Flash (separate from this setup skill)

Validate the download BEFORE installing: require HTTP success, expected Agent Skills frontmatter with `name: flash-executor`, and no error/HTML page in the body — on any failure stop and re-check the endpoint instead of installing. Download the canonical Flash execution skill from `https://teralor.com/assets/neural/skills/flash-executor/SKILL.md` and save it as `.agents/skills/flash-executor/SKILL.md` in the project. Codex detects project skills automatically; restart Codex if it does not appear, then invoke `$flash-executor`. Preserve any existing customized skill (update rather than overwrite, keeping user additions). Align the downloaded workflow's declared endpoint/origin to THIS verified environment (dev copies adapt URLs; downloads stay canonical production). Append exactly ONE owned block delimited by these exact markers — if an unowned or duplicated block makes the delimiters ambiguous, stop:

```text
<!-- BEGIN FLASH EXECUTOR LOCAL BINDING -->
worker=external Hermes profile "flash-executor" (custom:teralor-flash-executor, model Flash)
launch=hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
binding=Before launching, the parent writes a bounded task file (task.md) in an approved workspace, then invokes the command above with that file; executor work ALWAYS routes through this profile, never an inherited default. On rerun, replace only this owned block and preserve all surrounding custom skill text.
<!-- END FLASH EXECUTOR LOCAL BINDING -->
```

Substitute the ACTUAL chosen profile/provider/skill names everywhere if a collision forced a rename — never leave example placeholders installed. This setup skill and the workflow skill stay distinct: one configures, the other scopes tasks.

Stage the download in a task-owned temporary file before touching the destination; require nonempty `description` as well as the expected name, and reject symlink destinations. Compare the staged bytes with the installed canonical body before adding the local binding. Reuse an identical installation; if an existing body differs or contains customizations, preserve it and stop for reconciliation rather than overwriting it. Replace only an unambiguous owned binding block. In a fresh/reloaded harness, confirm `flash-executor` is actually discoverable at the resolved path and load it with the invocation above; a file existing on disk is not discovery. Report the canonical digest, installed path and any deliberate environment or binding delta. `READY` requires this installation/discovery check as well as the route smoke below. The execution procedure lives only in Flash, not in this onboarding skill.

## 9. Real bounded verification — one marker-read smoke

1. In a task-owned temp directory, create the marker file containing a freshly generated nonsecret nonce; keep the nonce value out of the worker prompt and use the REAL marker path.
2. Through Codex's terminal tool run ONE smoke test from the current project or an approved isolated directory — the actual external worker, `--max-turns 8`, the properly quoted real marker path:

```bash
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the file at \"$MARKER_PATH\" and reply with its exact contents. Do not edit files."
```

Require the EXACT marker content returned, plus route/model/config evidence (profile `flash-executor`, `custom:teralor-flash-executor`, `Flash`). Regular bounded tasks afterwards use the section-8 binding (`task.md`, `--max-turns 50`). This is the one smoke test — do not add extra vague probe tasks.
3. A canned "OK", a config file write, an HTTP 200 on `/models` alone, or the worker self-claiming success is NOT verification. Never substitute fake probes, scratch paths, or another model when verification fails — keep the failure evidence, clean up only the owned temp fixture. Failure means `BLOCKED`, not `READY`.
4. Confirm Codex's own config (`~/.codex/config.toml` untouched) and model are unchanged, then report. Keep authorizations and sandboxing as they were; no `--yolo` or `-z` bypass flags and no arbitrary project edits or network broadening.

## 10. Final report

Report: harness/route/model, config path and installed skill path, chosen C/O/prompt/trigger values, backup and rollback locations, the checks actually run, and any step not performed. Status is one of:

- `READY` — only after the real bounded verification above succeeded.
- `BLOCKED` — a required condition failed (missing key, 401, model absent, incompatible protocol, failed verification); describe evidence.
- `MANUAL_STEP_REQUIRED` — something needs the customer (secure key entry, install approval, GUI action); describe precisely what to do, honestly.

References: Hermes installation https://hermes-agent.nousresearch.com/docs/getting-started/installation/ ; Hermes delegation docs (for native Hermes setups, not this one) https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation/ ; Codex skills documentation https://developers.openai.com/codex/skills/ . Codex remains executor-only for Flash; no host-private paths or implementation model details apply.

Manual prompts

Open your harness below and copy the full setup prompt manually, or download its setup skill.

Codex — full setup prompt

Download the Codex setup skill

Set up and verify Teralor Flash as a separate EXECUTOR in Codex, following the complete instructions below. Keep Codex's own PRIMARY model, provider, context window and every unrelated setting unchanged — the only permitted changes are the executor-only ones the instructions specify (for native Hermes, adding the new worker provider and delegation keys is intended). The setup also installs the canonical Flash skill (identifier flash-executor) at the actual skill path the instructions name, validating the download and stopping on any conflict instead of overwriting existing customizations. Pause for me whenever secure credential entry, installation approval or a GUI step needs my action, and only report READY after real verification succeeds.

---
name: flash-executor-setup-codex
description: Use only when the user explicitly asks to set up, configure, or verify Teralor Flash as a separate executor worker for Codex while keeping Codex's own model unchanged. Installs/inspects a dedicated Hermes worker profile, secure TERALOR_API_KEY handling, budget validation, workflow-skill installation, and real verification. Reviewing or downloading this skill is not consent to change anything.
compatibility: Requires Codex with a terminal tool, Bash (or WSL) or native Windows PowerShell as noted, network access to https://api.teralor.com, and Hermes installed on the machine actually running the terminal. Installation steps require explicit user approval. Flash is NOT a native Codex model or subagent here.
metadata:
  author: Teralor
  version: "1.1.0"
---

# Flash Executor setup — Codex (external Hermes worker)

Run this skill only on an explicit user request to set up Flash as an executor in Codex. Reviewing or downloading it is not consent: present a concise plan, then act. The explicit setup request itself authorizes the scoped executor-only changes below — do not stop for a separate approval per already-authorized edit — while reading or downloading this skill authorizes nothing. Still pause for: software installation, missing secure credentials, name collisions or changes this task does not own, and any metered smoke test outside the authorization. Codex is currently executor-only for Flash — never edit `~/.codex/config.toml`, switch Codex's provider/model, or add Responses-API bridges. Flash runs as a separate Hermes process Codex drives from its terminal tool.

## 1. Protected scope (never modified)

- Codex's own model, provider and settings, including `~/.codex/config.toml`.
- Any existing Hermes profile, provider or skill that is not owned by this task.
- Task-owned additions only: the `flash-executor` Hermes profile (if absent), the provider keys listed below inside it, and `.agents/skills/flash-executor/SKILL.md`.

## 2. Discovery first

1. Detect the actual host OS/shell. Commands below are Bash (Linux/macOS/WSL). On native Windows use PowerShell equivalents and the official `install.ps1`; do not blindly run Bash snippets in PowerShell.
2. Check tools/versions you will rely on: `codex --version`, `hermes --version`, `command -v curl`.
3. Hermes install docs: https://hermes-agent.nousresearch.com/docs/getting-started/installation/ (CLI installer https://hermes-agent.nousresearch.com/install.sh; Windows native install.ps1). No private launcher or GPU/Docker image is required. Installing software needs the user's approval — fetch and review the official script before running it; never execute remote code blindly.

## 3. Inspect-before-write plan

- Before any write: read the target files/dirs you will touch; timestamp backups of every file you modify, keeping their permissions (0600 for anything secret-bearing).
- Parse and merge only the exact owned keys listed here; never dump whole configs or credential stores into model-visible output; do not follow unexpected symlinks.
- If a different `flash-executor` profile, provider or skill already exists, stop that step: reuse only when it already matches, otherwise choose a distinct name. Never overwrite, never create duplicates on rerun.
- Rollback: record every owned addition; to roll back, remove exactly those keys/files and restore the timestamped backups after checking the target was not edited by someone else since. Never use destructive resets, force flags, broad chmod, or sudo by default.

## 4. Secure TERALOR_API_KEY

- Resolve the key from the customer's own environment/secret store, or a private profile `.env` (permissions 0600). It must reach the actual worker process — confirm with a fresh launched process, not just a temporary shell export.
- Never place the key in chat, prompts, argv, URLs, project files, Git, config literals, or logs. A trusted local secret client may load it into process memory; print only allowlisted metadata such as set/missing, never the value or a model-visible read of the secret file.
- If no key exists for this environment, pause and ask the customer to enter it securely. Do not guess or borrow credentials from another service.

## 5. Verify the target API before configuring

- Target: `https://api.teralor.com/v1`, Chat Completions, exact model `Flash`.
- Run an authenticated `GET /v1/models` with the customer key and require an exact `Flash` entry. Stop on 401, a missing model, or an incompatible protocol — no internal aliases, renamed models, alternate paid providers, or silent fallback.
- Existing account only: no purchases, no quota resets. Ask before any metered smoke test that is not already authorized.

## 6. Budget validation

Ceilings (not additive): total 262144, input ceiling 262144, output ceiling 131072. Recommended working values: output 32768, prompt room 229376, compaction trigger 172032. Keep these defaults in the YAML template. From the authenticated `/v1/models` metadata compute C and I FIRST: C=min(262144, advertised total), I=min(262144, advertised input); every discovery field must be a positive integer. Then choose O=min(32768, advertised output ceiling, floor(C/2)) — never above the advertised output, and never above floor(C/2): the half-capacity cap reserves at least half the total context for input at small capacities. If C<2, or the resulting O is not a positive integer, reject the budget as `BLOCKED` — a previously recommended output value being too large for the advertised capacity is not a viable budget. Then client_window=min(C, I+O), prompt_room=client_window−O, trigger=floor(prompt_room*3/4); O must leave positive prompt room and is never applied at or above the total window. Lower the template when the account advertises lower. System, tool, skill and history tokens count as input. If discovery is missing or unverifiable, any capacity field is missing or not a positive integer, or a positive safe budget is impossible at the advertised capacity, STOP before applying or using any budget settings — `BLOCKED` (or `MANUAL_STEP_REQUIRED` while waiting for metadata). Never fall back to the template in that state, and never treat `READY` as reachable without verified limits plus the actual worker check in section 9. Hermes 0.21 ignores legacy `model.max_tokens`/`HERMES_MAX_TOKENS`; the output budget lives in provider `extra_body.max_tokens` and the compaction threshold is separate.

## 7. Create the isolated worker profile

Ordering matters. If the customer chose a private worker-profile `.env` and the profile does not exist yet, create ONLY the empty, collision-checked worker profile first, then PAUSE for secure key entry/authentication (`MANUAL_STEP_REQUIRED`) — never apply model/budget configuration before the section-5/6 metadata is verified. Never clone the parent:

```bash
hermes profile list
hermes profile create flash-executor --no-alias --no-skills   # only if absent — empty profile, collision-checked first
# pause here for secure key entry / authentication if the chosen mode needs it
hermes -p flash-executor config edit                          # merge, do not replace
```

Merge exactly these keys into `~/.hermes/profiles/flash-executor/config.yaml`, preserving all other settings. `teralor-flash-executor` is a deliberately distinct provider name, but a name that looks unique is not guaranteed collision-free: inspect the existing providers first, reuse only when an existing block matches exactly, otherwise choose a new name and substitute the ACTUAL chosen name in every path, command, invocation and binding below. Inspect worker fallbacks with `hermes -p flash-executor fallback list` and disable them only through supported CLI subcommands if present (`fallback remove` is interactive and takes no index in this release); never change the parent Codex setup or another profile's fallbacks.

```yaml
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032
```

## 8. Install Flash (separate from this setup skill)

Validate the download BEFORE installing: require HTTP success, expected Agent Skills frontmatter with `name: flash-executor`, and no error/HTML page in the body — on any failure stop and re-check the endpoint instead of installing. Download the canonical Flash execution skill from `https://teralor.com/assets/neural/skills/flash-executor/SKILL.md` and save it as `.agents/skills/flash-executor/SKILL.md` in the project. Codex detects project skills automatically; restart Codex if it does not appear, then invoke `$flash-executor`. Preserve any existing customized skill (update rather than overwrite, keeping user additions). Align the downloaded workflow's declared endpoint/origin to THIS verified environment (dev copies adapt URLs; downloads stay canonical production). Append exactly ONE owned block delimited by these exact markers — if an unowned or duplicated block makes the delimiters ambiguous, stop:

```text
<!-- BEGIN FLASH EXECUTOR LOCAL BINDING -->
worker=external Hermes profile "flash-executor" (custom:teralor-flash-executor, model Flash)
launch=hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
binding=Before launching, the parent writes a bounded task file (task.md) in an approved workspace, then invokes the command above with that file; executor work ALWAYS routes through this profile, never an inherited default. On rerun, replace only this owned block and preserve all surrounding custom skill text.
<!-- END FLASH EXECUTOR LOCAL BINDING -->
```

Substitute the ACTUAL chosen profile/provider/skill names everywhere if a collision forced a rename — never leave example placeholders installed. This setup skill and the workflow skill stay distinct: one configures, the other scopes tasks.

Stage the download in a task-owned temporary file before touching the destination; require nonempty `description` as well as the expected name, and reject symlink destinations. Compare the staged bytes with the installed canonical body before adding the local binding. Reuse an identical installation; if an existing body differs or contains customizations, preserve it and stop for reconciliation rather than overwriting it. Replace only an unambiguous owned binding block. In a fresh/reloaded harness, confirm `flash-executor` is actually discoverable at the resolved path and load it with the invocation above; a file existing on disk is not discovery. Report the canonical digest, installed path and any deliberate environment or binding delta. `READY` requires this installation/discovery check as well as the route smoke below. The execution procedure lives only in Flash, not in this onboarding skill.

## 9. Real bounded verification — one marker-read smoke

1. In a task-owned temp directory, create the marker file containing a freshly generated nonsecret nonce; keep the nonce value out of the worker prompt and use the REAL marker path.
2. Through Codex's terminal tool run ONE smoke test from the current project or an approved isolated directory — the actual external worker, `--max-turns 8`, the properly quoted real marker path:

```bash
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the file at \"$MARKER_PATH\" and reply with its exact contents. Do not edit files."
```

Require the EXACT marker content returned, plus route/model/config evidence (profile `flash-executor`, `custom:teralor-flash-executor`, `Flash`). Regular bounded tasks afterwards use the section-8 binding (`task.md`, `--max-turns 50`). This is the one smoke test — do not add extra vague probe tasks.
3. A canned "OK", a config file write, an HTTP 200 on `/models` alone, or the worker self-claiming success is NOT verification. Never substitute fake probes, scratch paths, or another model when verification fails — keep the failure evidence, clean up only the owned temp fixture. Failure means `BLOCKED`, not `READY`.
4. Confirm Codex's own config (`~/.codex/config.toml` untouched) and model are unchanged, then report. Keep authorizations and sandboxing as they were; no `--yolo` or `-z` bypass flags and no arbitrary project edits or network broadening.

## 10. Final report

Report: harness/route/model, config path and installed skill path, chosen C/O/prompt/trigger values, backup and rollback locations, the checks actually run, and any step not performed. Status is one of:

- `READY` — only after the real bounded verification above succeeded.
- `BLOCKED` — a required condition failed (missing key, 401, model absent, incompatible protocol, failed verification); describe evidence.
- `MANUAL_STEP_REQUIRED` — something needs the customer (secure key entry, install approval, GUI action); describe precisely what to do, honestly.

References: Hermes installation https://hermes-agent.nousresearch.com/docs/getting-started/installation/ ; Hermes delegation docs (for native Hermes setups, not this one) https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation/ ; Codex skills documentation https://developers.openai.com/codex/skills/ . Codex remains executor-only for Flash; no host-private paths or implementation model details apply.

Claude Code — full setup prompt

Download the Claude Code setup skill

Set up and verify Teralor Flash as a separate EXECUTOR in Claude Code, following the complete instructions below. Keep Claude Code's own PRIMARY model, provider, context window and every unrelated setting unchanged — the only permitted changes are the executor-only ones the instructions specify (for native Hermes, adding the new worker provider and delegation keys is intended). The setup also installs the canonical Flash skill (identifier flash-executor) at the actual skill path the instructions name, validating the download and stopping on any conflict instead of overwriting existing customizations. Pause for me whenever secure credential entry, installation approval or a GUI step needs my action, and only report READY after real verification succeeds.

---
name: flash-executor-setup-claude
description: Use only when the user explicitly asks to set up, configure, or verify Teralor Flash as a separate executor worker for Claude Code while keeping Claude's own model unchanged. Covers a dedicated Hermes worker profile, secure TERALOR_API_KEY handling, budget validation, workflow-skill installation, and real verification. Reviewing or downloading this skill is not consent to change anything.
compatibility: Requires Claude Code with its Bash/terminal tool, Bash (or WSL) or native Windows PowerShell as noted, network access to https://api.teralor.com, and Hermes installed on the machine actually running the Bash tool. Installation steps require explicit user approval. Flash is NOT a native Claude Code model or subagent here.
metadata:
  author: Teralor
  version: "1.1.0"
---

# Flash Executor setup — Claude Code (external Hermes worker)

Run this skill only on an explicit user request to set up Flash as an executor in Claude Code. Reviewing or downloading it is not consent: present a concise plan, then act. The explicit setup request itself authorizes the scoped executor-only changes below — do not stop for a separate approval per already-authorized edit — while reading or downloading this skill authorizes nothing. Still pause for: software installation, missing secure credentials, name collisions or changes this task does not own, and any metered smoke test outside the authorization. Claude Code is currently executor-only for Flash — never change Claude's model or settings, `ANTHROPIC_BASE_URL`, or the native subagent model. Flash runs as a separate Hermes process that Claude Code drives through its Bash tool.

## 1. Protected scope (never modified)

- Claude Code's model, settings, `ANTHROPIC_BASE_URL` / `ANTHROPIC_API_KEY` handling, and native subagent model.
- Any existing Hermes profile, provider or skill not owned by this task.
- Task-owned additions only: the `flash-executor` Hermes profile (if created here), the provider keys listed below inside it, and `.claude/skills/flash-executor/SKILL.md`.

## 2. Discovery first

1. Detect the actual host OS/shell. Commands below are Bash (Linux/macOS/WSL). On native Windows use PowerShell equivalents and the official `install.ps1`; do not blindly run Bash snippets in PowerShell.
2. Check tools/versions you will rely on: `claude --version`, `hermes --version`, `command -v curl`.
3. Hermes install docs: https://hermes-agent.nousresearch.com/docs/getting-started/installation/ (CLI installer https://hermes-agent.nousresearch.com/install.sh; Windows native install.ps1). No private launcher or GPU/Docker image is required. Installing software needs the user's approval — fetch and review the official script before running it; never execute remote code blindly.

## 3. Inspect-before-write plan

- Before any write: read the target files/dirs you will touch; timestamp backups of every file you modify, keeping their permissions (0600 for anything secret-bearing).
- Parse and merge only the exact owned keys listed here; never dump whole configs or credential stores into model-visible output; do not follow unexpected symlinks.
- If a different `flash-executor` profile or skill already exists, stop that step: reuse only when it already matches, otherwise choose a distinct name. Never overwrite, never create duplicates on rerun.
- Rollback: record every owned addition; to roll back, remove exactly those keys/files and restore the timestamped backups after checking the target was not edited since. Never use destructive resets, force flags, broad chmod, or sudo by default.

## 4. Secure TERALOR_API_KEY

- Resolve the key from the customer's own environment/secret store, or a private profile `.env` (permissions 0600). It must reach the actual worker process — confirm with a fresh launched process, not just a temporary shell export.
- Never place the key in chat, prompts, argv, URLs, project files, Git, config literals, or logs. A trusted local secret client may load it into process memory; print only allowlisted metadata such as set/missing, never the value or a model-visible read of the secret file.
- If no key exists for this environment, pause and ask the customer to enter it securely. Do not guess or borrow credentials from another service.

## 5. Verify the target API before configuring

- Target: `https://api.teralor.com/v1`, Chat Completions, exact model `Flash`.
- Run an authenticated `GET /v1/models` with the customer key and require an exact `Flash` entry. Stop on 401, a missing model, or an incompatible protocol — no internal aliases, renamed models, alternate paid providers, or silent fallback.
- Existing account only: no purchases, no quota resets. Ask before any metered smoke test that is not already authorized.

## 6. Budget validation

Ceilings (not additive): total 262144, input ceiling 262144, output ceiling 131072. Recommended working values: output 32768, prompt room 229376, compaction trigger 172032. Keep these defaults in the YAML template. From the authenticated `/v1/models` metadata compute C and I FIRST: C=min(262144, advertised total), I=min(262144, advertised input); every discovery field must be a positive integer. Then choose O=min(32768, advertised output ceiling, floor(C/2)) — never above the advertised output, and never above floor(C/2): the half-capacity cap reserves at least half the total context for input at small capacities. If C<2, or the resulting O is not a positive integer, reject the budget as `BLOCKED` — a previously recommended output value being too large for the advertised capacity is not a viable budget. Then client_window=min(C, I+O), prompt_room=client_window−O, trigger=floor(prompt_room*3/4); O must leave positive prompt room and is never applied at or above the total window. Lower the template when the account advertises lower. System, tool, skill and history tokens count as input. If discovery is missing or unverifiable, any capacity field is missing or not a positive integer, or a positive safe budget is impossible at the advertised capacity, STOP before applying or using any budget settings — `BLOCKED` (or `MANUAL_STEP_REQUIRED` while waiting for metadata). Never fall back to the template in that state, and never treat `READY` as reachable without verified limits plus the actual worker check in section 9. Hermes 0.21 ignores legacy `model.max_tokens`/`HERMES_MAX_TOKENS`; the output budget lives in provider `extra_body.max_tokens` and the compaction threshold is separate.

## 7. Create the isolated worker profile

Ordering matters. If the customer chose a private worker-profile `.env` and the profile does not exist yet, create ONLY the empty, collision-checked worker profile first, then PAUSE for secure key entry/authentication (`MANUAL_STEP_REQUIRED`) — never apply model/budget configuration before the section-5/6 metadata is verified. Never clone the parent:

```bash
hermes profile list
hermes profile create flash-executor --no-alias --no-skills   # only if absent — empty profile, collision-checked first
# pause here for secure key entry / authentication if the chosen mode needs it
hermes -p flash-executor config edit                          # merge, do not replace
```

Merge exactly these keys into `~/.hermes/profiles/flash-executor/config.yaml`, preserving all other settings. `teralor-flash-executor` is a deliberately distinct provider name, but a name that looks unique is not guaranteed collision-free: inspect the existing providers first, reuse only when an existing block matches exactly, otherwise choose a new name and substitute the ACTUAL chosen name in every path, command, invocation and binding below. Inspect worker fallbacks with `hermes -p flash-executor fallback list` and disable them only through supported CLI subcommands if present (`fallback remove` is interactive and takes no index in this release); never change Claude Code's settings or another profile's fallbacks.

```yaml
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032
```

## 8. Install Flash (separate from this setup skill)

Validate the download BEFORE installing: require HTTP success, expected Agent Skills frontmatter with `name: flash-executor`, and no error/HTML page in the body — on any failure stop and re-check the endpoint instead of installing. Download the canonical Flash execution skill from `https://teralor.com/assets/neural/skills/flash-executor/SKILL.md` and save it as `.claude/skills/flash-executor/SKILL.md` in the project. Start a new (or reloaded) Claude Code session, then invoke `/flash-executor`. Preserve any existing customized skill (update rather than overwrite, keeping user additions). Align the downloaded workflow's declared endpoint/origin to THIS verified environment (dev copies adapt URLs; downloads stay canonical production). Append exactly ONE owned block delimited by these exact markers — if an unowned or duplicated block makes the delimiters ambiguous, stop:

```text
<!-- BEGIN FLASH EXECUTOR LOCAL BINDING -->
worker=external Hermes profile "flash-executor" (custom:teralor-flash-executor, model Flash)
launch=hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
binding=Before launching, the parent writes a bounded task file (task.md) in an approved workspace, then invokes the command above with that file; executor work ALWAYS routes through this profile, never a native Claude subagent. On rerun, replace only this owned block and preserve all surrounding custom skill text.
<!-- END FLASH EXECUTOR LOCAL BINDING -->
```

Substitute the ACTUAL chosen profile/provider/skill names everywhere if a collision forced a rename — never leave example placeholders installed. This setup skill and the workflow skill stay distinct: one configures, the other scopes tasks.

Stage the download in a task-owned temporary file before touching the destination; require nonempty `description` as well as the expected name, and reject symlink destinations. Compare the staged bytes with the installed canonical body before adding the local binding. Reuse an identical installation; if an existing body differs or contains customizations, preserve it and stop for reconciliation rather than overwriting it. Replace only an unambiguous owned binding block. In a fresh/reloaded harness, confirm `flash-executor` is actually discoverable at the resolved path and load it with the invocation above; a file existing on disk is not discovery. Report the canonical digest, installed path and any deliberate environment or binding delta. `READY` requires this installation/discovery check as well as the route smoke below. The execution procedure lives only in Flash, not in this onboarding skill.

## 9. Real bounded verification — one marker-read smoke

1. In a task-owned temp directory, create the marker file containing a freshly generated nonsecret nonce; keep the nonce value out of the worker prompt and use the REAL marker path.
2. Through Claude Code's Bash tool run ONE smoke test from the current project or an approved isolated directory — the actual external worker, `--max-turns 8`, the properly quoted real marker path:

```bash
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the file at \"$MARKER_PATH\" and reply with its exact contents. Do not edit files."
```

Require the EXACT marker content returned, plus route/model/config evidence (profile `flash-executor`, `custom:teralor-flash-executor`, `Flash`). Regular bounded tasks afterwards use the section-8 binding (`task.md`, `--max-turns 50`). This is the one smoke test — do not add extra vague probe tasks.
3. A canned "OK", a config file write, an HTTP 200 on `/models` alone, or the worker self-claiming success is NOT verification. Never substitute fake probes, scratch paths, or another model when verification fails — keep the failure evidence, clean up only the owned temp fixture. Failure means `BLOCKED`, not `READY`.
4. Confirm Claude's model, settings and `ANTHROPIC_BASE_URL` are unchanged, then report. Keep authorizations and sandboxing as they were; no `--yolo` or `-z` bypass flags and no arbitrary project edits or network broadening.

## 10. Final report

Report: harness/route/model, config path and installed skill path, chosen C/O/prompt/trigger values, backup and rollback locations, the checks actually run, and any step not performed. Status is one of:

- `READY` — only after the real bounded verification above succeeded.
- `BLOCKED` — a required condition failed (missing key, 401, model absent, incompatible protocol, failed verification); describe evidence.
- `MANUAL_STEP_REQUIRED` — something needs the customer (secure key entry, install approval, new-session reload); describe precisely what to do, honestly.

References: Hermes installation https://hermes-agent.nousresearch.com/docs/getting-started/installation/ ; Claude Code skills documentation https://code.claude.com/docs/en/skills . Claude Code remains executor-only for Flash; no host-private paths or implementation model details apply.

Hermes — full setup prompt

Download the Hermes setup skill

Set up and verify Teralor Flash as a separate EXECUTOR in Hermes, following the complete instructions below. Keep Hermes's own PRIMARY model, provider, context window and every unrelated setting unchanged — the only permitted changes are the executor-only ones the instructions specify (for native Hermes, adding the new worker provider and delegation keys is intended). The setup also installs the canonical Flash skill (identifier flash-executor) at the actual skill path the instructions name, validating the download and stopping on any conflict instead of overwriting existing customizations. Pause for me whenever secure credential entry, installation approval or a GUI step needs my action, and only report READY after real verification succeeds.

---
name: flash-executor-setup-hermes
description: Use only when the user explicitly asks to set up, configure, or verify Teralor Flash as a NATIVE delegation executor inside an existing Hermes orchestrator profile, keeping the parent's own model, provider and context unchanged. Covers the unique teralor-flash-executor provider, delegation config merge, secure TERALOR_API_KEY handling, budget validation, workflow-skill installation and real verification. Reviewing or downloading this skill is not consent to change anything.
compatibility: Requires Hermes 0.21 or compatible with the delegation tool, Bash (or WSL) or native Windows PowerShell as noted, and network access to https://api.teralor.com. The parent profile keeps its model; if the local routing cannot preserve the parent, offer the isolated standalone worker instead of pretending native setup succeeded.
metadata:
  author: Teralor
  version: "1.1.0"
---

# Flash Executor setup — Hermes (native delegation child)

Run this skill only on an explicit user request to set up Flash as a native executor in Hermes. Reviewing or downloading it is not consent: present a concise plan, then act. The explicit setup request itself authorizes the scoped executor-only changes below — do not stop for a separate approval per already-authorized edit — while reading or downloading this skill authorizes nothing. Still pause for: software installation, missing secure credentials, name collisions or changes this task does not own, and any metered smoke test outside the authorization. Route: native delegation inside the ACTIVE orchestrator profile (replace `YOUR_PROFILE` with its real name), using the distinctly named provider `teralor-flash-executor` — a name that looks unique is not guaranteed collision-free, so inspect the existing providers first, reuse the name only when an existing block already matches exactly, and otherwise choose a new name and substitute the ACTUAL chosen name in every config reference, path, command, invocation and binding below. The parent's own provider is a different thing from this new worker provider — never conflate them.

## 1. Protected scope (never modified)

- The parent profile's top-level `model`, `context` and `compression` sections and its own provider blocks — this setup adds keys only.
- Global/lower compression caps: inspect them (a lower global `compression.threshold_tokens` still clamps children) but do not change the parent to make numbers match.
- Task-owned additions only: the `providers.teralor-flash-executor` block, the `delegation` keys listed below, and `skills/flash-executor/SKILL.md` under the active profile.

## 2. Discovery first

1. Detect the actual host OS/shell. Commands below are Bash (Linux/macOS/WSL). On native Windows use PowerShell equivalents and the official `install.ps1`; do not blindly run Bash snippets in PowerShell.
2. Check what exists: `hermes --version`, `hermes profile list`. Resolve the ACTIVE profile correctly — the default profile's data lives directly under `~/.hermes` (commands omit `-p`), a named profile's under `~/.hermes/profiles/<name>` (use `-p <name>`), and a custom `HERMES_HOME` relocates everything; never blindly write `~/.hermes/profiles/default`. Read only the leaf values you need through trusted local parsing or leaf queries (e.g. `hermes -p YOUR_PROFILE config get delegation.provider`, `... config get providers.teralor-flash-executor.api`) — never read the whole `delegation` or `providers` blocks (they may contain credentials).
3. Hermes docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation/ ; install docs https://hermes-agent.nousresearch.com/docs/getting-started/installation/ (CLI installer https://hermes-agent.nousresearch.com/install.sh; Windows native install.ps1) if Hermes itself is missing — installing software needs the user's approval, review the official script, never blind remote-code execution or a purchase.

## 3. Inspect-before-write plan

- Timestamp backups of any config you modify, keeping permissions (0600 for secret-bearing files); merge only the exact owned keys; use trusted local parsing/redaction and return only allowlisted nonsecret fields — never dump whole configs or credential stores to model-visible output; do not follow unexpected symlinks.
- If a provider already owns the name `teralor-flash-executor` with different settings, stop and reconcile — reuse only when identical, otherwise a distinct name (then substitute the ACTUAL chosen name everywhere). No overwrite, no duplicates on rerun.
- Rollback: record every owned key added; restore removes exactly those keys after checking for later edits by others. Never destructive resets, force flags, broad chmod, or sudo by default.

## 4. Secure TERALOR_API_KEY

- The named provider resolves its own key via `key_env: TERALOR_API_KEY` from the environment of the actual Hermes process. Take it from the customer's secure terminal/secret manager or a private profile `.env` (0600); confirm a fresh launch sees it, not just a temporary export.
- Never the key in chat, prompts, argv, URLs, project files, Git, logs, or config literals; print only allowlisted metadata (set/missing). Do not add `delegation.base_url` or `delegation.api_key` — the direct-endpoint branch can inherit the parent's key.
- If no key exists for this environment, pause for secure customer entry; never guess or borrow internal credentials.

## 5. Verify the target API before configuring

- Target: `https://api.teralor.com/v1`, Chat Completions, exact model `Flash`.
- Authenticated `GET /v1/models` with the customer key must list `Flash` exactly. Stop on 401, missing model, or incompatible protocol. No internal aliases, renamed models, alternate paid providers, or silent fallback.
- Existing account only: no purchases or quota resets; ask before any metered smoke test not already authorized.

## 6. Budget validation

Ceilings (not additive): total 262144, input ceiling 262144, output ceiling 131072. Recommended working values: output 32768, prompt room 229376, compaction trigger 172032. Keep these defaults in the YAML template. From authenticated `/v1/models` metadata compute C and I FIRST: C=min(262144, advertised total), I=min(262144, advertised input); every discovery field must be a positive integer. Then choose O=min(32768, advertised output ceiling, floor(C/2)) — never above the advertised output, and never above floor(C/2): the half-capacity cap reserves at least half the total context for input at small capacities. If C<2, or the resulting O is not a positive integer, reject the budget as `BLOCKED` — a previously recommended output value being too large for the advertised capacity is not a viable budget. Then client_window=min(C, I+O), prompt_room=client_window−O, trigger=floor(prompt_room*3/4); O must leave positive prompt room and is never applied at or above the total window. Lower the template when the account advertises lower. System, tool, skill and history tokens count as input. If discovery is missing or unverifiable, any capacity field is missing or not a positive integer, or a positive safe budget is impossible at the advertised capacity, STOP before applying or using any budget settings — `BLOCKED` (or `MANUAL_STEP_REQUIRED` while waiting for metadata). Never fall back to the template in that state, and never treat `READY` as reachable without verified limits plus the actual child check in section 9 — do not manufacture limits. Child context comes from provider model metadata and output from `extra_body.max_tokens`; there is no `delegation.context_length` or `delegation.max_tokens` option. Hermes 0.21 ignores legacy `model.max_tokens`/`HERMES_MAX_TOKENS`; the compression threshold is a separate key.

## 7. Native delegation configuration

Apply this only after section 5 (authenticated discovery) and section 6 (verified budget) succeed; if either is unverified the setup is `BLOCKED`/`MANUAL_STEP_REQUIRED`, not configured. Merge exactly this YAML into the current orchestrator profile config via `hermes -p YOUR_PROFILE config edit` (plain `hermes config edit` for the default profile; respect a custom `HERMES_HOME`). It deliberately contains NO top-level model/context/compression sections — the parent model and context stay exactly as they are:

```yaml
providers:
  teralor-flash-executor:
    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-executor
  compression_threshold_tokens: 172032
  max_concurrent_children: 1
  max_iterations: 50
```

Then enable the tool. Install the workflow skill (section 8) BEFORE starting the fresh session:

```bash
hermes -p YOUR_PROFILE tools enable delegation
hermes -p YOUR_PROFILE chat -s flash-executor   # fresh parent session startup — omit -p for the default profile
```

`max_iterations` counts turns, not output tokens. Native children do not load a standalone worker profile. Note that `chat -s flash-executor` only starts the parent orchestrator session with the skill loaded — it is NOT the child dispatch; the actual child runs when the parent invokes `delegate_task` (section 8 binding).

## 8. Install Flash (separate from this setup skill)

Validate the download BEFORE installing: require HTTP success, expected Agent Skills frontmatter with `name: flash-executor`, and no error/HTML page in the body — on any failure stop and re-check the endpoint instead of installing. Download the canonical Flash execution skill from `https://teralor.com/assets/neural/skills/flash-executor/SKILL.md` into the ACTIVE profile's real skills directory BEFORE starting the fresh session: `~/.hermes/skills/flash-executor/SKILL.md` for the default profile, `~/.hermes/profiles/<name>/skills/flash-executor/SKILL.md` for a named profile, or the equivalent under a custom `HERMES_HOME`. Preserve existing customizations (keep user additions). Align the downloaded workflow's declared endpoint/origin to THIS verified environment (dev copies adapt URLs; downloads stay canonical production). Append exactly ONE owned block delimited by these exact markers — if an unowned or duplicated block makes the delimiters ambiguous, stop:

```text
<!-- BEGIN FLASH EXECUTOR LOCAL BINDING -->
worker=native delegation child in profile "YOUR_PROFILE" (custom:teralor-flash-executor, model Flash)
dispatch=When executing a bounded task, invoke the delegate_task tool: it runs the child through the configured delegation route (custom:teralor-flash-executor, model Flash). Starting a session with `hermes -p YOUR_PROFILE chat -s flash-executor` is separate fresh-session startup only and is NOT the child dispatch.
binding=On rerun, replace only this owned block and preserve all surrounding custom skill text.
<!-- END FLASH EXECUTOR LOCAL BINDING -->
```

Substitute the ACTUAL chosen profile/provider/skill names everywhere if a collision forced a rename — never leave example placeholders installed. The binding must make the orchestrator actually delegate through the configured child via `delegate_task` rather than an unconfigured default. This setup skill and the workflow skill stay distinct: one configures, the other scopes tasks.

Stage the download in a task-owned temporary file before touching the destination; require nonempty `description` as well as the expected name, and reject symlink destinations. Compare the staged bytes with the installed canonical body before adding the local binding. Reuse an identical installation; if an existing body differs or contains customizations, preserve it and stop for reconciliation rather than overwriting it. Replace only an unambiguous owned binding block. In a fresh/reloaded harness, confirm `flash-executor` is actually discoverable at the resolved path and load it with the invocation above; a file existing on disk is not discovery. Report the canonical digest, installed path and any deliberate environment or binding delta. `READY` requires this installation/discovery check as well as the route smoke below. The execution procedure lives only in Flash, not in this onboarding skill.

## 9. Real bounded verification — one marker-read smoke

1. In a task-owned temp directory, create the marker file containing a freshly generated nonsecret nonce; keep the nonce value out of the child prompt and use the REAL marker path.
2. In the fresh session, invoke `delegate_task` ONCE for one bounded read of the marker file through the actual native child, and require the EXACT marker content returned plus evidence the child ran on `custom:teralor-flash-executor` / `Flash` with the configured thresholds. No README-test-plus-another-task: this single marker-read smoke is the check.
3. A canned "OK", a config file write, an HTTP 200 on `/models` alone, or the child self-claiming success is NOT verification. Never substitute fake probes, scratch paths, or another model on failure — preserve failure evidence, clean up only the owned temp fixture. Failure means `BLOCKED`, not `READY`.
4. Confirm the parent's own model/provider/context/compression settings are unchanged (leaf queries such as `hermes -p YOUR_PROFILE config get model.provider` — never whole secret-bearing blocks). No arbitrary project edits or network broadening; keep approvals and sandboxing as they were.
5. If your custom context engine or routing cannot preserve the parent, do not claim native success — report and offer the isolated standalone Hermes worker profile instead (its own template ships at `setup/hermes-standalone-executor.yaml` alongside this guide).

## 10. Final report

Report: harness/route/model, config path and installed skill path, chosen C/O/prompt/trigger values, backup and rollback locations, the checks actually run, and any step not performed. Status is one of:

- `READY` — only after the real bounded verification above succeeded.
- `BLOCKED` — a required condition failed (missing key, 401, model absent, routing cannot preserve the parent, failed verification); describe evidence.
- `MANUAL_STEP_REQUIRED` — something needs the customer (secure key entry, install approval, fresh-session restart); describe precisely what to do, honestly.

References: Hermes delegation https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation/ ; provider/context detection https://hermes-agent.nousresearch.com/docs/integrations/providers ; installation https://hermes-agent.nousresearch.com/docs/getting-started/installation/ . No host-private paths or implementation model details apply.

Pi — full setup prompt

Download the Pi setup skill

Set up and verify Teralor Flash as a separate EXECUTOR in Pi, following the complete instructions below. Keep Pi's own PRIMARY model, provider, context window and every unrelated setting unchanged — the only permitted changes are the executor-only ones the instructions specify (for native Hermes, adding the new worker provider and delegation keys is intended). The setup also installs the canonical Flash skill (identifier flash-executor) at the actual skill path the instructions name, validating the download and stopping on any conflict instead of overwriting existing customizations. Pause for me whenever secure credential entry, installation approval or a GUI step needs my action, and only report READY after real verification succeeds.

---
name: flash-executor-setup-pi
description: Use only when the user explicitly asks to set up, configure, or verify Teralor Flash as a separate executor worker for Pi while keeping Pi's primary model unchanged. Covers a dedicated Hermes worker profile, secure TERALOR_API_KEY handling, budget validation, workflow-skill installation in a trusted project, and real verification. Reviewing or downloading this skill is not consent to change anything.
compatibility: Requires Pi with a shell/terminal capability in a trusted project, Bash (or WSL) or native Windows PowerShell as noted, network access to https://api.teralor.com, and Hermes installed on the machine actually running the shell. Installation steps require explicit user approval. The worker is external — no Pi models.json change and no speculative subagent extension.
metadata:
  author: Teralor
  version: "1.1.0"
---

# Flash Executor setup — Pi (external Hermes worker)

Run this skill only on an explicit user request to set up Flash as an executor in Pi. Reviewing or downloading it is not consent: present a concise plan, then act. The explicit setup request itself authorizes the scoped executor-only changes below — do not stop for a separate approval per already-authorized edit — while reading or downloading this skill authorizes nothing. Still pause for: software installation, missing secure credentials, name collisions or changes this task does not own, and any metered smoke test outside the authorization. Flash runs as a separate Hermes process Pi drives from its shell. Leave `~/.pi/agent/models.json`, Pi's primary model and the project's compaction settings unchanged, and do not install a speculative subagent extension.

## 1. Protected scope (never modified)

- `~/.pi/agent/models.json`, Pi's selected primary model, and `.pi/settings.json` compaction values.
- Any existing Hermes profile, provider or skill not owned by this task.
- Task-owned additions only: the `flash-executor` Hermes profile (if created here), the provider keys listed below inside it, and `.pi/skills/flash-executor/SKILL.md`.

## 2. Discovery first

1. Detect the actual host OS/shell. Commands below are Bash (Linux/macOS/WSL). On native Windows use PowerShell equivalents and the official `install.ps1`; do not blindly run Bash snippets in PowerShell.
2. Check tools/versions you will rely on: `pi --version`, `hermes --version`, `command -v curl`.
3. Hermes install docs: https://hermes-agent.nousresearch.com/docs/getting-started/installation/ (CLI installer https://hermes-agent.nousresearch.com/install.sh; Windows native install.ps1). No private launcher or GPU/Docker image is required. Installing software needs the user's approval — fetch and review the official script before running it; never execute remote code blindly. Pi documentation: https://github.com/earendil-works/pi with skills docs at https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/skills.md — Pi's own model config is NOT touched by this route.

## 3. Inspect-before-write plan

- Before any write: read the target files/dirs you will touch; timestamp backups of every file you modify, keeping their permissions (0600 for anything secret-bearing).
- Parse and merge only the exact owned keys listed here; never dump whole configs or credential stores into model-visible output; do not follow unexpected symlinks.
- If a different `flash-executor` profile or skill already exists, stop that step: reuse only when it already matches, otherwise choose a distinct name. Never overwrite, never create duplicates on rerun.
- Rollback: record every owned addition; to roll back, remove exactly those keys/files and restore the timestamped backups after checking the target was not edited since. Never use destructive resets, force flags, broad chmod, or sudo by default.

## 4. Secure TERALOR_API_KEY

- Resolve the key from the customer's own environment/secret store, or a private profile `.env` (permissions 0600). It must reach the actual worker process — confirm with a fresh launched process, not just a temporary shell export.
- Never place the key in chat, prompts, argv, URLs, project files, Git, config literals, or logs. A trusted local secret client may load it into process memory; print only allowlisted metadata such as set/missing, never the value or a model-visible read of the secret file.
- If no key exists for this environment, pause and ask the customer to enter it securely. Do not guess or borrow credentials from another service.

## 5. Verify the target API before configuring

- Target: `https://api.teralor.com/v1`, Chat Completions, exact model `Flash`.
- Run an authenticated `GET /v1/models` with the customer key and require an exact `Flash` entry. Stop on 401, a missing model, or an incompatible protocol — no internal aliases, renamed models, alternate paid providers, or silent fallback.
- Existing account only: no purchases, no quota resets. Ask before any metered smoke test that is not already authorized.

## 6. Budget validation

Ceilings (not additive): total 262144, input ceiling 262144, output ceiling 131072. Recommended working values: output 32768, prompt room 229376, compaction trigger 172032. Keep these defaults in the YAML template. From the authenticated `/v1/models` metadata compute C and I FIRST: C=min(262144, advertised total), I=min(262144, advertised input); every discovery field must be a positive integer. Then choose O=min(32768, advertised output ceiling, floor(C/2)) — never above the advertised output, and never above floor(C/2): the half-capacity cap reserves at least half the total context for input at small capacities. If C<2, or the resulting O is not a positive integer, reject the budget as `BLOCKED` — a previously recommended output value being too large for the advertised capacity is not a viable budget. Then client_window=min(C, I+O), prompt_room=client_window−O, trigger=floor(prompt_room*3/4); O must leave positive prompt room and is never applied at or above the total window. Lower the template when the account advertises lower. System, tool, skill and history tokens count as input. If discovery is missing or unverifiable, any capacity field is missing or not a positive integer, or a positive safe budget is impossible at the advertised capacity, STOP before applying or using any budget settings — `BLOCKED` (or `MANUAL_STEP_REQUIRED` while waiting for metadata). Never fall back to the template in that state, and never treat `READY` as reachable without verified limits plus the actual worker check in section 9. Hermes 0.21 ignores legacy `model.max_tokens`/`HERMES_MAX_TOKENS`; the output budget lives in provider `extra_body.max_tokens` and the compaction threshold is separate.

## 7. Create the isolated worker profile

Ordering matters. If the customer chose a private worker-profile `.env` and the profile does not exist yet, create ONLY the empty, collision-checked worker profile first, then PAUSE for secure key entry/authentication (`MANUAL_STEP_REQUIRED`) — never apply model/budget configuration before the section-5/6 metadata is verified. Never clone the parent:

```bash
hermes profile list
hermes profile create flash-executor --no-alias --no-skills   # only if absent — empty profile, collision-checked first
# pause here for secure key entry / authentication if the chosen mode needs it
hermes -p flash-executor config edit                          # merge, do not replace
```

Merge exactly these keys into `~/.hermes/profiles/flash-executor/config.yaml`, preserving all other settings. `teralor-flash-executor` is a deliberately distinct provider name, but a name that looks unique is not guaranteed collision-free: inspect the existing providers first, reuse only when an existing block matches exactly, otherwise choose a new name and substitute the ACTUAL chosen name in every path, command, invocation and binding below. Inspect worker fallbacks with `hermes -p flash-executor fallback list` and disable them only through supported CLI subcommands if present (`fallback remove` is interactive and takes no index in this release); never change Pi's configuration or another profile's fallbacks.

```yaml
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032
```

## 8. Install Flash (separate from this setup skill)

Validate the download BEFORE installing: require HTTP success, expected Agent Skills frontmatter with `name: flash-executor`, and no error/HTML page in the body — on any failure stop and re-check the endpoint instead of installing. Download the canonical Flash execution skill from `https://teralor.com/assets/neural/skills/flash-executor/SKILL.md` and save it as `.pi/skills/flash-executor/SKILL.md` in a trusted project. Restart Pi, then invoke `/skill:flash-executor`. Preserve any existing customized skill (update rather than overwrite, keeping user additions). Align the downloaded workflow's declared endpoint/origin to THIS verified environment (dev copies adapt URLs; downloads stay canonical production). Append exactly ONE owned block delimited by these exact markers — if an unowned or duplicated block makes the delimiters ambiguous, stop:

```text
<!-- BEGIN FLASH EXECUTOR LOCAL BINDING -->
worker=external Hermes profile "flash-executor" (custom:teralor-flash-executor, model Flash)
launch=hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
binding=Before launching, the parent writes a bounded task file (task.md) in an approved workspace, then invokes the command above with that file; executor work ALWAYS routes through this profile, never any native/extension subagent. On rerun, replace only this owned block and preserve all surrounding custom skill text.
<!-- END FLASH EXECUTOR LOCAL BINDING -->
```

Substitute the ACTUAL chosen profile/provider/skill names everywhere if a collision forced a rename — never leave example placeholders installed. This setup skill and the workflow skill stay distinct: one configures, the other scopes tasks.

Stage the download in a task-owned temporary file before touching the destination; require nonempty `description` as well as the expected name, and reject symlink destinations. Compare the staged bytes with the installed canonical body before adding the local binding. Reuse an identical installation; if an existing body differs or contains customizations, preserve it and stop for reconciliation rather than overwriting it. Replace only an unambiguous owned binding block. In a fresh/reloaded harness, confirm `flash-executor` is actually discoverable at the resolved path and load it with the invocation above; a file existing on disk is not discovery. Report the canonical digest, installed path and any deliberate environment or binding delta. `READY` requires this installation/discovery check as well as the route smoke below. The execution procedure lives only in Flash, not in this onboarding skill.

## 9. Real bounded verification — one marker-read smoke

1. In a task-owned temp directory, create the marker file containing a freshly generated nonsecret nonce; keep the nonce value out of the worker prompt and use the REAL marker path.
2. Through Pi's shell run ONE smoke test from the current project or an approved isolated directory — the actual external worker, `--max-turns 8`, the properly quoted real marker path:

```bash
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the file at \"$MARKER_PATH\" and reply with its exact contents. Do not edit files."
```

Require the EXACT marker content returned, plus route/model/config evidence (profile `flash-executor`, `custom:teralor-flash-executor`, `Flash`). Regular bounded tasks afterwards use the section-8 binding (`task.md`, `--max-turns 50`). This is the one smoke test — do not add extra vague probe tasks.
3. A canned "OK", a config file write, an HTTP 200 on `/models` alone, or the worker self-claiming success is NOT verification. Never substitute fake probes, scratch paths, or another model when verification fails — keep the failure evidence, clean up only the owned temp fixture. Failure means `BLOCKED`, not `READY`.
4. Confirm `~/.pi/agent/models.json`, Pi's primary model and project compaction settings are unchanged, then report. Keep authorizations and sandboxing as they were; no bypass flags and no arbitrary project edits or network broadening.

## 10. Final report

Report: harness/route/model, config path and installed skill path, chosen C/O/prompt/trigger values, backup and rollback locations, the checks actually run, and any step not performed. Status is one of:

- `READY` — only after the real bounded verification above succeeded.
- `BLOCKED` — a required condition failed (missing key, 401, model absent, incompatible protocol, failed verification); describe evidence.
- `MANUAL_STEP_REQUIRED` — something needs the customer (secure key entry, install approval, Pi restart for skill reload); describe precisely what to do, honestly.

References: Hermes installation https://hermes-agent.nousresearch.com/docs/getting-started/installation/ ; Pi repository https://github.com/earendil-works/pi ; Pi skills documentation https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/skills.md . The external-worker route deliberately changes no Pi configuration file; no host-private paths or implementation model details apply.

ZCode — full setup prompt

Download the ZCode setup skill

Set up and verify Teralor Flash as a separate EXECUTOR in ZCode, following the complete instructions below. Keep ZCode's own PRIMARY model, provider, context window and every unrelated setting unchanged — the only permitted changes are the executor-only ones the instructions specify (for native Hermes, adding the new worker provider and delegation keys is intended). The setup also installs the canonical Flash skill (identifier flash-executor) at the actual skill path the instructions name, validating the download and stopping on any conflict instead of overwriting existing customizations. Pause for me whenever secure credential entry, installation approval or a GUI step needs my action, and only report READY after real verification succeeds.

---
name: flash-executor-setup-zcode
description: Use only when the user explicitly asks to set up, configure, or verify Teralor Flash as a native ZCode subagent executor while keeping ZCode's primary model unchanged. Covers the GUI provider/model fields, secure key entry by the customer, Advanced limits, the flash-executor subagent with explicit Flash selection, the workflow skill, and real verification. Reviewing or downloading this skill is not consent to change anything.
compatibility: Requires the ZCode desktop app on the customer's machine (GUI). Steps are the documented GUI fields, not invented config files; ZCode compacts automatically and has no user-facing compaction threshold. If GUI automation is unavailable, hand the customer precise manual steps instead of fabricating configuration changes.
metadata:
  author: Teralor
  version: "1.1.0"
---

# Flash Executor setup — ZCode (native subagent, GUI)

Run this skill only on an explicit user request to set up Flash as an executor in ZCode. Reviewing or downloading it is not consent: present a concise plan, then act. The explicit setup request itself authorizes the scoped executor-only changes below — do not stop for a separate approval per already-authorized change — while reading or downloading this skill authorizes nothing. Still pause for: app installation, missing secure credentials (GUI key entry is the customer's action), collisions with existing entries or changes this task does not own, GUI unavailability, and any metered smoke test outside the authorization. Route: a ZCode-native subagent bound explicitly to a GUI-configured Flash model. ZCode's official docs (https://zcode.z.ai/en/docs/configuration , https://zcode.z.ai/en/docs/subagents , https://zcode.z.ai/en/docs/skill ) describe the fields below; these instructions are documentation-backed, not a claim of live Flash certification.

## 1. Protected scope (never modified)

- ZCode's primary/default chat model selection — Flash must NOT become the primary here.
- Any existing ZCode provider, model, subagent or skill not owned by this task.
- Task-owned additions only: the `Teralor Flash` provider + `Flash` model entries, the `flash-executor` subagent definition, and `~/.zcode/skills/flash-executor/SKILL.md`.

## 2. Discovery and OS awareness

1. Confirm the actual OS and that ZCode is installed and launchable; detect the app version if shown. Steps below follow the documented GUI path — record what the GUI actually displays at each step.
2. Native Windows, macOS and Linux GUI differences matter: describe where the customer clicks; never run invented shell commands against ZCode state. Follow the documented GUI path only — do not invent automation schemas.
3. If ZCode is missing, installation is the customer's action from the official site/docs, with their approval — never blind remote-code execution or a purchase.
4. ZCode discovery is NOT optional: reliable limits must come from a trusted authenticated client call or the app itself. If neither can provide verified capacity metadata, hand off manually or block (`MANUAL_STEP_REQUIRED`/`BLOCKED`) — a saved key plus a saved nonce alone is never enough to proceed, and never substitute a fake probe.
5. Confirm the terminal/shell that will run the `/v1/models` discovery call exists on this machine (Bash, WSL or PowerShell); if it does not, discovery falls back to the in-app key save plus the subagent verification below, and the honest status stays `MANUAL_STEP_REQUIRED`/`BLOCKED` until limits are verified — say so in the report.

## 3. Inspect-before-write plan

- Before adding anything, open the relevant Settings panes and record what already exists (providers, models, subagents, skills). Reuse an existing identical entry; stop rather than overwrite or duplicate a different one on rerun.
- Before ANY change, record ONLY the nonsecret UI field values (provider/model names, base URL, limits, subagent settings — never secret values, never the credential store) in your plan so they can be restored. When the on-disk layout exists and is documented, additionally make an opaque, permission-preserving private backup of the actual config/agent files before touching them; the currently known config path is `~/.zcode/v2/config.json`, but discover and check the current installed version's actual path first and use that. Back up with the file's own permissions, store it privately, never read or print its secret contents into model-visible output. Roll back ONLY the entries this task added, after checking nothing was changed by the customer since.
- Do not read or dump ZCode's credential storage or full app config to model-visible output; do not follow unexpected symlinks. No destructive resets, broad chmod, or sudo by default.
- If any pane's labels or controls differ from the linked docs, stop that step, describe the actual UI, and ask the customer how to proceed rather than guessing fields into existence.

## 4. Secure key handling

- The key goes ONLY into the app's own secure API-key field, entered by the customer (GUI key entry may require customer action). Never place the key in chat, prompts, argv, URLs, project files, Git, or logs.
- If no key exists for this environment, pause and ask the customer to obtain/enter one securely; never guess or borrow credentials from another service. Confirm the provider saves and a fresh session authenticates.

## 5. Verify the target API before configuring

- Target: `https://api.teralor.com/v1`, OpenAI-compatible Chat Completions, exact model `Flash`.
- With the customer's consent, run an authenticated `GET /v1/models` (their key, e.g. via a shell that already holds it in memory) and require an exact `Flash` entry. Stop on 401, missing model, or incompatible protocol — no internal aliases, renamed models, alternate paid providers, or silent fallback.
- Existing account only: no purchases or quota resets; ask before any metered smoke test not already authorized.

## 6. Budget validation

Ceilings (not additive): total 262144, input ceiling 262144, output ceiling 131072. Recommended working values: output 32768, prompt room 229376. ZCode's Advanced fields take context window and Max output tokens only — ZCode compacts automatically with its own headroom and exposes NO user-facing threshold and no manual trigger, so do not fabricate a 172032 trigger or `extra_body` JSON fields; the same window/output budgeting still applies. From authenticated `/v1/models` metadata compute the window first: C=min(262144, advertised total), I=min(262144, advertised input), each a positive integer; choose max output O=min(32768, advertised output, floor(C/2)) — never above the advertised output, and never above floor(C/2): the half-capacity cap reserves at least half the total context for input at small capacities. If C<2, or the resulting O is not a positive integer, reject the budget as `BLOCKED` — a previously recommended output value being too large for the advertised capacity is not a viable budget. Never apply O at or above the client window min(C, I+O), leaving positive prompt room min(C, I+O)−O; set the GUI context window to that client window. Lower the entries when the account advertises lower. System, tool, skill and history tokens count as input. If discovery is missing or unverifiable, any capacity field is missing or not a positive integer, or a positive safe budget is impossible at the advertised capacity, STOP before applying or using any budget entries — `BLOCKED` (or `MANUAL_STEP_REQUIRED` while waiting for metadata). Never fall back to the recommended entries in that state, and never treat `READY` as reachable without verified limits plus the actual subagent check in section 9.

## 7. GUI configuration (exact fields; leave the primary model unchanged)

Follow Settings → Model Settings / Manage Models (the docs also call this Model Providers):

1. Add Provider named `Teralor Flash`; choose the OpenAI-compatible protocol/endpoint, not Anthropic; API base URL exactly `https://api.teralor.com/v1` (match the verified environment); the customer enters their own key into the app's secure API-key field.
2. Add Model with the exact ID `Flash`; enable the provider/model.
3. Advanced settings for the model: context window `262144`, Max output tokens `32768`, or lower if the authenticated `/v1/models` result says so. Custom-provider context edits apply to new sessions after saving.
4. Keep optional thinking controls unset unless the route supports them; provider options accept connection fields only — arbitrary reasoning/extra_body keys are silently ignored.
5. Settings → Subagents → New (custom subagents are Beta and user-level). Name it `flash-executor`; choose the configured `Teralor Flash` / `Flash` model EXPLICITLY — not "Inherit default". Definitions persist under `~/.zcode/agents/<name>.md`, but choose model/provider in the UI rather than inventing persisted IDs in a file.
6. Initially grant only Read/Grep/Glob; authorize Edit/Write/Bash only for coding tasks the customer approves. Save and enable.

## 8. Install Flash (separate from this setup skill)

Validate the download BEFORE installing: require HTTP success, expected Agent Skills frontmatter with `name: flash-executor`, and no error/HTML page in the body — on any failure stop and re-check the endpoint instead of installing. Download the canonical Flash execution skill from `https://teralor.com/assets/neural/skills/flash-executor/SKILL.md` into `~/.zcode/skills/flash-executor/SKILL.md`, then Settings → Skills → Refresh and enable; invoke `$flash-executor`. Preserve existing customizations (keep user additions); a skill adds instructions and is not a subagent or provider configuration. Align the downloaded workflow's declared endpoint/origin to THIS verified environment (dev copies adapt URLs; downloads stay canonical production). Append exactly ONE owned block delimited by these exact markers — if an unowned or duplicated block makes the delimiters ambiguous, stop:

```text
<!-- BEGIN FLASH EXECUTOR LOCAL BINDING -->
worker=native ZCode subagent "flash-executor" (provider Teralor Flash, model Flash, explicit selection)
launch=@flash-executor in a new session; workflow invoked with $flash-executor
binding=Before launching, the parent writes a bounded task file (task.md) in an approved workspace and passes only that bounded task; executor work ALWAYS routes through the explicitly-selected Flash subagent, never the primary model. On rerun, replace only this owned block and preserve all surrounding custom skill text.
<!-- END FLASH EXECUTOR LOCAL BINDING -->
```

Substitute the ACTUAL chosen provider/subagent/skill names everywhere if a collision forced a rename — never leave example placeholders installed. This setup skill and the workflow skill stay distinct: one configures, the other scopes tasks.

Stage the download in a task-owned temporary file before touching the destination; require nonempty `description` as well as the expected name, and reject symlink destinations. Compare the staged bytes with the installed canonical body before adding the local binding. Reuse an identical installation; if an existing body differs or contains customizations, preserve it and stop for reconciliation rather than overwriting it. Replace only an unambiguous owned binding block. In a fresh/reloaded harness, confirm `flash-executor` is actually discoverable at the resolved path and load it with the invocation above; a file existing on disk is not discovery. Report the canonical digest, installed path and any deliberate environment or binding delta. `READY` requires this installation/discovery check as well as the route smoke below. The execution procedure lives only in Flash, not in this onboarding skill.

## 9. Real bounded verification — one marker-read smoke

1. In a task-owned temp directory, create the marker file containing a freshly generated nonsecret nonce; keep the nonce value out of the subagent prompt and use the REAL marker path.
2. Start a NEW session (running sessions do not hot-reload) and invoke `@flash-executor` ONCE with the single bounded marker-file read — one smoke, not a README test plus another task — and require the EXACT marker content returned plus evidence the reply came from the explicitly selected Flash model (model indicator/agent metadata in the session) — not the primary model.
3. A canned "OK", a saved config file, an HTTP 200 on `/models` alone, or the subagent self-claiming success is NOT verification. Never substitute fake probes, scratch paths, or another model on failure — keep failure evidence, clean up only the owned temp fixture. Failure means `BLOCKED`, not `READY`.
4. Confirm the primary model selection is unchanged and no other provider/subagent was modified. No arbitrary project edits or permission broadening.

## 10. Final report

Report all of the following — no field may be summarized away:

- harness/route/model: ZCode / native `flash-executor` subagent / explicit `Teralor Flash` + `Flash`
- configuration entries created (provider, model, Advanced values) and the installed skill path
- chosen context-window and max-output numbers and the `/v1/models` evidence behind them
- what was recorded before each GUI change (rollback notes) and where
- the checks actually run (models discovery, marker-nonce subagent round-trip, primary-model confirmation)
- every step the customer performed manually (key entry, clicks, session restart)

Status is one of:

- `READY` — only after the real bounded verification above succeeded with verified limits.
- `BLOCKED` — a required condition failed (missing key, 401, model absent, capacity metadata missing/unverifiable, GUI state differs from docs); describe evidence.
- `MANUAL_STEP_REQUIRED` — GUI automation is unavailable or a step needs the customer (key entry, subagent creation, session restart, providing capacity metadata); hand over the precise click-path honestly instead of fabricating config changes. Missing GUI or missing metadata NEVER yields READY.

References: https://zcode.z.ai/en/docs/configuration , https://zcode.z.ai/en/docs/subagents , https://zcode.z.ai/en/docs/skill . No host-private paths or implementation model details apply.

Cursor — full setup prompt

Download the Cursor setup skill

Set up and verify Teralor Flash as a separate EXECUTOR in Cursor, following the complete instructions below. Keep Cursor's own PRIMARY model, provider, context window and every unrelated setting unchanged — the only permitted changes are the executor-only ones the instructions specify (for native Hermes, adding the new worker provider and delegation keys is intended). The setup also installs the canonical Flash skill (identifier flash-executor) at the actual skill path the instructions name, validating the download and stopping on any conflict instead of overwriting existing customizations. Pause for me whenever secure credential entry, installation approval or a GUI step needs my action, and only report READY after real verification succeeds.

---
name: flash-executor-setup-cursor
description: Use only when the user explicitly asks to set up, configure, or verify Teralor Flash as a separate executor worker for Cursor while keeping Cursor's own model, keys and base URL unchanged. Covers a dedicated Hermes worker profile on the real terminal host, secure TERALOR_API_KEY handling, budget validation, workflow-skill installation, and real verification. Reviewing or downloading this skill is not consent to change anything.
compatibility: Requires Cursor with its terminal tool, Hermes installed on the machine actually running that terminal (a local install does not automatically exist in SSH or Cloud Agent workspaces), Bash (or WSL) or native Windows PowerShell as noted, and network access to https://api.teralor.com. Installation steps require explicit user approval. Cursor cannot pin an explicit custom/BYOK model for subagents, so the worker is external, not a native Cursor model.
metadata:
  author: Teralor
  version: "1.1.0"
---

# Flash Executor setup — Cursor (external Hermes worker)

Run this skill only on an explicit user request to set up Flash as an executor in Cursor. Reviewing or downloading it is not consent: present a concise plan, then act. The explicit setup request itself authorizes the scoped executor-only changes below — do not stop for a separate approval per already-authorized edit — while reading or downloading this skill authorizes nothing. Still pause for: software installation, missing secure credentials, name collisions or changes this task does not own, and any metered smoke test outside the authorization. Pinning an explicit custom/BYOK Flash model via a `.cursor/agents` `model:` field is not supported currently — support confirms `model: inherit` only follows an already-Flash parent, which is not unchanged-primary executor mode (https://forum.cursor.com/t/custom-model-unavailable-for-explicit-subagent-selection/170676/6). Flash therefore runs as a separate Hermes process Cursor drives through its terminal tool.

## 1. Protected scope (never modified)

- Cursor Settings → Models / API Keys / base-URL overrides — all left unchanged.
- Any existing Hermes profile, provider or skill not owned by this task.
- Task-owned additions only: the `flash-executor` Hermes profile (if created here), the provider keys listed below inside it, and `.cursor/skills/flash-executor/SKILL.md`.

## 2. Discovery first (the actual host matters)

1. Identify the machine that actually runs Cursor's terminal — local, an SSH remote, or a Cloud Agent workspace. Hermes, the workspace and the secure key environment must exist THERE; a local install does not automatically exist in SSH or Cloud environments.
2. Detect OS/shell on that host. Commands below are Bash (Linux/macOS/WSL). On native Windows use PowerShell equivalents and the official `install.ps1`; do not blindly run Bash snippets in PowerShell.
3. Check tools/versions: `hermes --version`, `command -v curl`. Hermes install docs: https://hermes-agent.nousresearch.com/docs/getting-started/installation/ (CLI installer https://hermes-agent.nousresearch.com/install.sh; Windows native install.ps1). No private launcher or GPU/Docker image is required. Installing software needs the user's approval — fetch and review the official script before running it; never execute remote code blindly.

## 3. Inspect-before-write plan

- Before any write: read the target files/dirs you will touch; timestamp backups of every file you modify, keeping their permissions (0600 for anything secret-bearing).
- Parse and merge only the exact owned keys listed here; never dump whole configs or credential stores into model-visible output; do not follow unexpected symlinks.
- If a different `flash-executor` profile or skill already exists, stop that step: reuse only when it already matches, otherwise choose a distinct name. Never overwrite, never create duplicates on rerun.
- Rollback: record every owned addition; to roll back, remove exactly those keys/files and restore the timestamped backups after checking the target was not edited since. Never use destructive resets, force flags, broad chmod, or sudo by default. Do not disable Cursor's sandboxing wholesale to make commands "work".

## 4. Secure TERALOR_API_KEY

- Resolve the key on the actual terminal host from the customer's own environment/secret store, or a private profile `.env` (permissions 0600). It must reach the actual worker process — confirm with a fresh launched process, not just a temporary shell export.
- Never place the key in chat, prompts, argv, URLs, project files, Git, config literals, or logs. A trusted local secret client may load it into process memory; print only allowlisted metadata such as set/missing, never the value or a model-visible read of the secret file.
- If no key exists for this environment, pause and ask the customer to enter it securely. Do not guess or borrow credentials from another service.

## 5. Verify the target API before configuring

- Target: `https://api.teralor.com/v1`, Chat Completions, exact model `Flash`.
- Run an authenticated `GET /v1/models` with the customer key and require an exact `Flash` entry. Stop on 401, a missing model, or an incompatible protocol — no internal aliases, renamed models, alternate paid providers, or silent fallback.
- Existing account only: no purchases, no quota resets. Ask before any metered smoke test that is not already authorized.

## 6. Budget validation

Ceilings (not additive): total 262144, input ceiling 262144, output ceiling 131072. Recommended working values: output 32768, prompt room 229376, compaction trigger 172032. Keep these defaults in the YAML template. From the authenticated `/v1/models` metadata compute C and I FIRST: C=min(262144, advertised total), I=min(262144, advertised input); every discovery field must be a positive integer. Then choose O=min(32768, advertised output ceiling, floor(C/2)) — never above the advertised output, and never above floor(C/2): the half-capacity cap reserves at least half the total context for input at small capacities. If C<2, or the resulting O is not a positive integer, reject the budget as `BLOCKED` — a previously recommended output value being too large for the advertised capacity is not a viable budget. Then client_window=min(C, I+O), prompt_room=client_window−O, trigger=floor(prompt_room*3/4); O must leave positive prompt room and is never applied at or above the total window. Lower the template when the account advertises lower. System, tool, skill and history tokens count as input. If discovery is missing or unverifiable, any capacity field is missing or not a positive integer, or a positive safe budget is impossible at the advertised capacity, STOP before applying or using any budget settings — `BLOCKED` (or `MANUAL_STEP_REQUIRED` while waiting for metadata). Never fall back to the template in that state, and never treat `READY` as reachable without verified limits plus the actual worker check in section 9. Hermes 0.21 ignores legacy `model.max_tokens`/`HERMES_MAX_TOKENS`; the output budget lives in provider `extra_body.max_tokens` and the compaction threshold is separate.

## 7. Create the isolated worker profile

Ordering matters. If the customer chose a private worker-profile `.env` and the profile does not exist yet, create ONLY the empty, collision-checked worker profile first, then PAUSE for secure key entry/authentication (`MANUAL_STEP_REQUIRED`) — never apply model/budget configuration before the section-5/6 metadata is verified. Never clone the parent:

```bash
hermes profile list
hermes profile create flash-executor --no-alias --no-skills   # only if absent — empty profile, collision-checked first
# pause here for secure key entry / authentication if the chosen mode needs it
hermes -p flash-executor config edit                          # merge, do not replace
```

Merge exactly these keys into `~/.hermes/profiles/flash-executor/config.yaml`, preserving all other settings. `teralor-flash-executor` is a deliberately distinct provider name, but a name that looks unique is not guaranteed collision-free: inspect the existing providers first, reuse only when an existing block matches exactly, otherwise choose a new name and substitute the ACTUAL chosen name in every path, command, invocation and binding below. Inspect worker fallbacks with `hermes -p flash-executor fallback list` and disable them only through supported CLI subcommands if present (`fallback remove` is interactive and takes no index in this release); never change Cursor's models/keys or another profile's fallbacks.

```yaml
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032
```

## 8. Install Flash (separate from this setup skill)

Validate the download BEFORE installing: require HTTP success, expected Agent Skills frontmatter with `name: flash-executor`, and no error/HTML page in the body — on any failure stop and re-check the endpoint instead of installing. Download the canonical Flash execution skill from `https://teralor.com/assets/neural/skills/flash-executor/SKILL.md` and save it as `.cursor/skills/flash-executor/SKILL.md` in the workspace on the actual terminal host (see https://cursor.com/docs/skills ). Let Cursor discover the skill, then invoke `/flash-executor`. A skill adds instructions only — it does not configure model routing. Preserve any existing customized skill (update rather than overwrite, keeping user additions). Align the downloaded workflow's declared endpoint/origin to THIS verified environment (dev copies adapt URLs; downloads stay canonical production). Append exactly ONE owned block delimited by these exact markers — if an unowned or duplicated block makes the delimiters ambiguous, stop:

```text
<!-- BEGIN FLASH EXECUTOR LOCAL BINDING -->
worker=external Hermes profile "flash-executor" (custom:teralor-flash-executor, model Flash)
launch=hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
binding=Before launching, the parent writes a bounded task file (task.md) in an approved workspace, then invokes the command above with that file; executor work ALWAYS routes through this profile, never a native Cursor model/subagent. On rerun, replace only this owned block and preserve all surrounding custom skill text.
<!-- END FLASH EXECUTOR LOCAL BINDING -->
```

Substitute the ACTUAL chosen profile/provider/skill names everywhere if a collision forced a rename — never leave example placeholders installed. This setup skill and the workflow skill stay distinct: one configures, the other scopes tasks.

Stage the download in a task-owned temporary file before touching the destination; require nonempty `description` as well as the expected name, and reject symlink destinations. Compare the staged bytes with the installed canonical body before adding the local binding. Reuse an identical installation; if an existing body differs or contains customizations, preserve it and stop for reconciliation rather than overwriting it. Replace only an unambiguous owned binding block. In a fresh/reloaded harness, confirm `flash-executor` is actually discoverable at the resolved path and load it with the invocation above; a file existing on disk is not discovery. Report the canonical digest, installed path and any deliberate environment or binding delta. `READY` requires this installation/discovery check as well as the route smoke below. The execution procedure lives only in Flash, not in this onboarding skill.

## 9. Real bounded verification — one marker-read smoke

1. In a task-owned temp directory, create the marker file containing a freshly generated nonsecret nonce; keep the nonce value out of the worker prompt and use the REAL marker path.
2. Through Cursor's terminal tool run ONE smoke test on the actual terminal host, from the current project or an approved isolated directory — the actual external worker, `--max-turns 8`, the properly quoted real marker path:

```bash
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the file at \"$MARKER_PATH\" and reply with its exact contents. Do not edit files."
```

Require the EXACT marker content returned, plus route/model/config evidence (profile `flash-executor`, `custom:teralor-flash-executor`, `Flash`). Regular bounded tasks afterwards use the section-8 binding (`task.md`, `--max-turns 50`). This is the one smoke test — do not add extra vague probe tasks.
3. A canned "OK", a config file write, an HTTP 200 on `/models` alone, or the worker self-claiming success is NOT verification. Never substitute fake probes, scratch paths, or another model when verification fails — keep the failure evidence, clean up only the owned temp fixture. Failure means `BLOCKED`, not `READY`.
4. Confirm Cursor's Models/API Keys/base-URL settings are unchanged and sandboxing is intact, then report. Keep authorizations and approvals as they were; no bypass flags, arbitrary project edits, or network broadening.

## 10. Final report

Report: harness/route/model, actual terminal host used, config path and installed skill path, chosen C/O/prompt/trigger values, backup and rollback locations, the checks actually run, and any step not performed. Status is one of:

- `READY` — only after the real bounded verification above succeeded.
- `BLOCKED` — a required condition failed (missing key/host, 401, model absent, incompatible protocol, failed verification); describe evidence.
- `MANUAL_STEP_REQUIRED` — something needs the customer (secure key entry, install approval on the remote host, skill reload); describe precisely what to do, honestly.

References: Hermes installation https://hermes-agent.nousresearch.com/docs/getting-started/installation/ ; Cursor skills https://cursor.com/docs/skills ; Cursor subagent-model limitation https://forum.cursor.com/t/custom-model-unavailable-for-explicit-subagent-selection/170676/6 . No host-private paths or implementation model details apply.

Codex — external Flash worker

Complete standalone setup for Codex. Everything needed is below; no other section is required.

Keep Codex's own provider, model and settings unchanged — Flash runs as a separate Hermes process, not as a native Codex model or subagent. Using Flash as the Codex orchestrator is not possible at the moment — Flash is an executor here only. Do not edit ~/.codex/config.toml, switch Codex's provider, or add Responses-API bridges.
Install Hermes from the machine that will actually run the worker using its official installation guide (CLI installer https://hermes-agent.nousresearch.com/install.sh; native Windows uses install.ps1). No private launcher or GPU/Docker image is required. Installing software needs your approval — review the official script before running it; never execute remote code blindly.
Check first (Bash example)
```
hermes --version || echo "Hermes is not installed"
```
Create a dedicated worker profile only if absent — never clone or inherit the parent, and never overwrite an existing profile. If flash-executor already exists with different settings, inspect it, reuse it only when it matches, or choose a distinct profile name.
Create once, then merge the YAML below (Bash)
```
hermes profile list
hermes profile create flash-executor --no-alias --no-skills
hermes -p flash-executor config edit
```
The key is read from TERALOR_API_KEY in the actual worker process. There are two supply modes: export it in the environment of the process that launches the worker (a plain bash -lc check does not load the Hermes profile .env, so a valid private-profile key would falsely look missing there), or place it in the private worker-profile .env (permissions 0600), which Hermes itself loads at startup. Never paste a key into chat, a repository or a config literal, and never print its value — the fresh authenticated Hermes smoke test below is what actually proves the worker sees the key.
Keep your normal authorizations and sandboxing in both harnesses; do not add bypass flags such as --yolo or -z.

Worker profile config

Download hermes-standalone-executor.yaml

Merge the shown keys into ~/.hermes/profiles/flash-executor/config.yaml — do not replace other settings.

The named provider teralor-flash-executor resolves the endpoint and key together (key_env, never a literal). Inspect worker fallbacks with hermes -p flash-executor fallback list and disable them only via supported CLI subcommands if present — fallback removeis interactive and accepts no index in this release. Never change the parent harness's or another profile's fallback settings.

View hermes-standalone-executor.yaml

# Teralor Flash as an ISOLATED STANDALONE EXECUTOR PROFILE in Hermes 0.21 —
# the worker a parent harness (Codex, Claude Code, Pi, Cursor) drives from its
# own terminal tool while keeping its own model unchanged.
# Create a dedicated profile (nothing is cloned from the parent) and merge
# this YAML into ~/.hermes/profiles/flash-executor/config.yaml:
#   hermes profile create flash-executor --no-alias --no-skills   # only if absent
#   hermes -p flash-executor config edit   # merge; do not replace other settings
# If a different flash-executor profile already exists, inspect and reuse it
# only when it matches, or choose a distinct profile name — never overwrite.
# The key is read from the TERALOR_API_KEY environment variable of the actual
# worker process — never paste a key literal into this file, a prompt, argv,
# URLs or source control.
# Hermes 0.21 ignores legacy model.max_tokens / HERMES_MAX_TOKENS: the output
# budget lives in providers.teralor-flash-executor.extra_body.max_tokens and
# the compaction trigger is the separate compression.threshold_tokens below.
# Inspect `hermes -p flash-executor fallback list`; disable worker-side
# fallbacks only through supported CLI subcommands, and never touch the parent
# harness's or another profile's fallback settings.
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032

Install the Flash skill (required). Install the original workflow skill from the same-origin download into the host path below, checking HTTP success, parsing valid YAML frontmatter with name: flash-executor and a non-empty description, rejecting an HTML or error-page body (valid skills may contain HTML comments), and staging the validated body in a unique temp file before placing it as a new file. The setup instructions you are reading and this workflow skill stay distinct; if a file already exists at the path, stop on the conflict and preserve the existing customization rather than overwriting.
Download workflow SKILL.md
Save as .agents/skills/flash-executor/SKILL.md in the project. Codex detects project skills automatically; restart Codex if it does not appear. Invoke it with $flash-executor.
The skill adds task-scoping and invocation instructions only — it is not the connection. Its instructions must explicitly bind external calls to this flash-executor profile rather than an inherited Codex subagent.
Run ONE bounded marker-read smoke test from the current project or an approved isolated directory (Bash example). First write a task-owned temp marker file containing a freshly generated nonce, then point the command at the REAL marker path — never put the nonce value in the prompt, and never substitute a fake probe, path or model. Require the exact nonce returned plus route/config evidence (profile flash-executor, custom:teralor-flash-executor, Flash).The parent should invoke this through its own terminal tool and check the actual artifact and result, not just the worker's claim. A read-only instruction in the prompt is not a sandbox — keep approvals and isolation.
Full runnable smoke-test command pattern (first set MARKER_PATH to the actual created nonce file)
```
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the marker file whose path is $MARKER_PATH. Reply with its exact contents. Do not edit files."
```
Regular bounded tasks (parent writes a bounded task.md first)
```
hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
```
Confirm setup: with your own key, an authenticated GET /v1/models lists the exact model Flash; the smoke test above returned the exact marker nonce through custom:teralor-flash-executor; and Codex's own model/settings are still unchanged. Any failure means fixing setup first — never fall back to another model silently.

Claude Code — external Flash worker

Complete standalone setup for Claude Code. Everything needed is below; no other section is required.

Keep Claude Code's own provider, model and settings unchanged — Flash runs as a separate Hermes process, not as a native Claude Code model or subagent. Using Flash as the Claude Code orchestrator is not possible at the moment — Flash is an executor here only. Do not change Claude's model, settings, ANTHROPIC_BASE_URLor native subagent model; the worker is driven through Claude's terminal/Bash tool.
Install Hermes from the machine that will actually run the worker using its official installation guide (CLI installer https://hermes-agent.nousresearch.com/install.sh; native Windows uses install.ps1). No private launcher or GPU/Docker image is required. Installing software needs your approval — review the official script before running it; never execute remote code blindly.
Check first (Bash example)
```
hermes --version || echo "Hermes is not installed"
```
Create a dedicated worker profile only if absent — never clone or inherit the parent, and never overwrite an existing profile. If flash-executor already exists with different settings, inspect it, reuse it only when it matches, or choose a distinct profile name.
Create once, then merge the YAML below (Bash)
```
hermes profile list
hermes profile create flash-executor --no-alias --no-skills
hermes -p flash-executor config edit
```
The key is read from TERALOR_API_KEY in the actual worker process. There are two supply modes: export it in the environment of the process that launches the worker (a plain bash -lc check does not load the Hermes profile .env, so a valid private-profile key would falsely look missing there), or place it in the private worker-profile .env (permissions 0600), which Hermes itself loads at startup. Never paste a key into chat, a repository or a config literal, and never print its value — the fresh authenticated Hermes smoke test below is what actually proves the worker sees the key.
Keep your normal authorizations and sandboxing in both harnesses; do not add bypass flags such as --yolo or -z.

Worker profile config

Download hermes-standalone-executor.yaml

Merge the shown keys into ~/.hermes/profiles/flash-executor/config.yaml — do not replace other settings.

View hermes-standalone-executor.yaml

# Teralor Flash as an ISOLATED STANDALONE EXECUTOR PROFILE in Hermes 0.21 —
# the worker a parent harness (Codex, Claude Code, Pi, Cursor) drives from its
# own terminal tool while keeping its own model unchanged.
# Create a dedicated profile (nothing is cloned from the parent) and merge
# this YAML into ~/.hermes/profiles/flash-executor/config.yaml:
#   hermes profile create flash-executor --no-alias --no-skills   # only if absent
#   hermes -p flash-executor config edit   # merge; do not replace other settings
# If a different flash-executor profile already exists, inspect and reuse it
# only when it matches, or choose a distinct profile name — never overwrite.
# The key is read from the TERALOR_API_KEY environment variable of the actual
# worker process — never paste a key literal into this file, a prompt, argv,
# URLs or source control.
# Hermes 0.21 ignores legacy model.max_tokens / HERMES_MAX_TOKENS: the output
# budget lives in providers.teralor-flash-executor.extra_body.max_tokens and
# the compaction trigger is the separate compression.threshold_tokens below.
# Inspect `hermes -p flash-executor fallback list`; disable worker-side
# fallbacks only through supported CLI subcommands, and never touch the parent
# harness's or another profile's fallback settings.
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032

Install the Flash skill (required). Install the original workflow skill from the same-origin download into the host path below, checking HTTP success, parsing valid YAML frontmatter with name: flash-executor and a non-empty description, rejecting an HTML or error-page body (valid skills may contain HTML comments), and staging the validated body in a unique temp file before placing it as a new file. The setup instructions you are reading and this workflow skill stay distinct; if a file already exists at the path, stop on the conflict and preserve the existing customization rather than overwriting.
Download workflow SKILL.md
Save as .claude/skills/flash-executor/SKILL.md in the project, start a new or reloaded session, and invoke /flash-executor.
The skill adds task-scoping and invocation instructions only — it is not the connection. Its instructions must explicitly bind external calls to this flash-executor profile rather than an inherited Claude Code subagent.
Run ONE bounded marker-read smoke test from the current project or an approved isolated directory (Bash example). First write a task-owned temp marker file containing a freshly generated nonce, then point the command at the REAL marker path — never put the nonce value in the prompt, and never substitute a fake probe, path or model. Require the exact nonce returned plus route/config evidence (profile flash-executor, custom:teralor-flash-executor, Flash).The parent should invoke this through its own terminal tool and check the actual artifact and result, not just the worker's claim. A read-only instruction in the prompt is not a sandbox — keep approvals and isolation.
Full runnable smoke-test command pattern (first set MARKER_PATH to the actual created nonce file)
```
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the marker file whose path is $MARKER_PATH. Reply with its exact contents. Do not edit files."
```
Regular bounded tasks (parent writes a bounded task.md first)
```
hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
```
Confirm setup: with your own key, an authenticated GET /v1/models lists the exact model Flash; the smoke test above returned the exact marker nonce through custom:teralor-flash-executor; and Claude Code's own model/settings are still unchanged. Any failure means fixing setup first — never fall back to another model silently.

Hermes — native delegation child

Run Flash as a native delegation child of your active Hermes orchestrator profile. Resolve that profile's real name and data location first: the default profile lives under ~/.hermes (launch commands omit -p), named profiles live under ~/.hermes/profiles/<name> (use -p <name>), and a custom HERMES_HOME relocates everything — never blindly write ~/.hermes/profiles/default. The parent keeps its own model, provider and context settings exactly as they are.

Inspect the orchestrator profile config first through leaf queries or a trusted local parser that returns only the nonsecret fields you need (provider names, delegation keys) — never dump whole providers or delegation blocks that may embed credentials. This route adds the distinctly named provider teralor-flash-executor— distinct from the parent's own provider, which stays untouched — but a name that looks unique is not guaranteed collision-free: inspect the existing providers first, reuse the name only when an existing block already matches exactly, and otherwise choose a new name and substitute the ACTUAL chosen name in every path, command and reference below. Do not add delegation.base_url, delegation.api_key, or the nonexistent delegation.context_length/delegation.max_tokens knobs: the named provider resolves its own endpoint and key via key_env, and the model metadata below supplies the child's 262144-token context and 32768-token output (via extra_body.max_tokens).
Inspect leaf keys only — never whole secret-bearing blocks
```
hermes -p YOUR_PROFILE config get delegation.provider
hermes -p YOUR_PROFILE config get delegation.model
hermes -p YOUR_PROFILE config get providers.teralor-flash-executor.api
```
Supply the key and verify authenticated discovery BEFORE applying configuration: export TERALOR_API_KEYin the environment that launches Hermes, or place it in the active profile's private .env (permissions 0600) — never in chat, a repository, a config literal, or printed output. Then run an authenticated GET /v1/models with your key and require the exact model Flash; a missing key or a 401 stops the setup here rather than proceeding on template values.

Delegation config

Download hermes-executor.yaml

Merge into your current orchestrator profile config (hermes -p YOUR_PROFILE config edit, or plain `hermes config edit` for the default profile). Do not replace the whole file, and add no top-level model/context/compression changes.

A lower global or parent compaction cap still wins — inspect it, but do not change the parent. 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 provider is named teralor-flash-executor — a name distinct from the
# primary-mode provider (teralor-flash) — so merging this file never rewrites
# an existing primary-mode provider block. Inspect the target config first and
# skip or reconcile the block if a different provider already owns this name.
# 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 a separate standalone
# worker profile.
providers:
  teralor-flash-executor:
    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-executor
  compression_threshold_tokens: 172032
  max_concurrent_children: 1
  max_iterations: 50

Enable the delegation tool, then install the original workflow skill under the ACTIVE profile's real skills directory BEFORE starting the fresh session: ~/.hermes/skills/ for the default profile, ~/.hermes/profiles/<name>/skills/ for a named profile, or the equivalent under a custom HERMES_HOME — as …/skills/flash-executor/SKILL.md. Download workflow SKILL.md Preserve existing customizations. The skill adds task-scoping instructions only — the delegation configuration above is the connection.
Enable delegation, then start a fresh session (omit -p for the default profile)
```
hermes -p YOUR_PROFILE tools enable delegation
hermes -p YOUR_PROFILE chat -s flash-executor
```
Confirm setup:in the fresh session, bind execution with the workflow skill's local binding — the parent invokes the delegate_task tool, which runs the child through the configured custom:teralor-flash-executor route (chat -s flash-executor above only starts the parent session; it is not the child dispatch). Run ONE bounded marker-read smoke: create a task-owned temp marker file with a fresh nonce, delegate a read of the REAL marker path with the nonce kept out of the prompt, and require the exact nonce plus evidence the child ran on custom:teralor-flash-executor with model Flash. Then confirm the parent's own model/settings are unchanged (for example hermes -p YOUR_PROFILE config get model.provider). If your custom context engine or routing cannot preserve the parent natively, do not pretend the native setup succeeded — use an isolated standalone worker instead, as the Codex/Claude Code/Pi/Cursor panels above do.

Pi — external Flash worker

Complete standalone setup for Pi. Everything needed is below; no other section is required.

Keep Pi's own provider, model and settings unchanged — Flash runs as a separate Hermes process, not as a native Pi model or subagent. Leave ~/.pi/agent/models.json, Pi's primary model and your project compaction settings unchanged, and do not install a speculative subagent extension. The worker runs as an external process driven from Pi's shell.
Install Hermes from the machine that will actually run the worker using its official installation guide (CLI installer https://hermes-agent.nousresearch.com/install.sh; native Windows uses install.ps1). No private launcher or GPU/Docker image is required. Installing software needs your approval — review the official script before running it; never execute remote code blindly.
Check first (Bash example)
```
hermes --version || echo "Hermes is not installed"
```
Create a dedicated worker profile only if absent — never clone or inherit the parent, and never overwrite an existing profile. If flash-executor already exists with different settings, inspect it, reuse it only when it matches, or choose a distinct profile name.
Create once, then merge the YAML below (Bash)
```
hermes profile list
hermes profile create flash-executor --no-alias --no-skills
hermes -p flash-executor config edit
```
The key is read from TERALOR_API_KEY in the actual worker process. There are two supply modes: export it in the environment of the process that launches the worker (a plain bash -lc check does not load the Hermes profile .env, so a valid private-profile key would falsely look missing there), or place it in the private worker-profile .env (permissions 0600), which Hermes itself loads at startup. Never paste a key into chat, a repository or a config literal, and never print its value — the fresh authenticated Hermes smoke test below is what actually proves the worker sees the key.
Keep your normal authorizations and sandboxing in both harnesses; do not add bypass flags such as --yolo or -z.

Worker profile config

Download hermes-standalone-executor.yaml

Merge the shown keys into ~/.hermes/profiles/flash-executor/config.yaml — do not replace other settings.

View hermes-standalone-executor.yaml

# Teralor Flash as an ISOLATED STANDALONE EXECUTOR PROFILE in Hermes 0.21 —
# the worker a parent harness (Codex, Claude Code, Pi, Cursor) drives from its
# own terminal tool while keeping its own model unchanged.
# Create a dedicated profile (nothing is cloned from the parent) and merge
# this YAML into ~/.hermes/profiles/flash-executor/config.yaml:
#   hermes profile create flash-executor --no-alias --no-skills   # only if absent
#   hermes -p flash-executor config edit   # merge; do not replace other settings
# If a different flash-executor profile already exists, inspect and reuse it
# only when it matches, or choose a distinct profile name — never overwrite.
# The key is read from the TERALOR_API_KEY environment variable of the actual
# worker process — never paste a key literal into this file, a prompt, argv,
# URLs or source control.
# Hermes 0.21 ignores legacy model.max_tokens / HERMES_MAX_TOKENS: the output
# budget lives in providers.teralor-flash-executor.extra_body.max_tokens and
# the compaction trigger is the separate compression.threshold_tokens below.
# Inspect `hermes -p flash-executor fallback list`; disable worker-side
# fallbacks only through supported CLI subcommands, and never touch the parent
# harness's or another profile's fallback settings.
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032

Install the Flash skill (required). Install the original workflow skill from the same-origin download into the host path below, checking HTTP success, parsing valid YAML frontmatter with name: flash-executor and a non-empty description, rejecting an HTML or error-page body (valid skills may contain HTML comments), and staging the validated body in a unique temp file before placing it as a new file. The setup instructions you are reading and this workflow skill stay distinct; if a file already exists at the path, stop on the conflict and preserve the existing customization rather than overwriting.
Download workflow SKILL.md
Save as .pi/skills/flash-executor/SKILL.md in a trusted project, restart Pi, then invoke /skill:flash-executor.
The skill adds task-scoping and invocation instructions only — it is not the connection. Its instructions must explicitly bind external calls to this flash-executor profile rather than an inherited Pi subagent.
Run ONE bounded marker-read smoke test from the current project or an approved isolated directory (Bash example). First write a task-owned temp marker file containing a freshly generated nonce, then point the command at the REAL marker path — never put the nonce value in the prompt, and never substitute a fake probe, path or model. Require the exact nonce returned plus route/config evidence (profile flash-executor, custom:teralor-flash-executor, Flash).The parent should invoke this through its own terminal tool and check the actual artifact and result, not just the worker's claim. A read-only instruction in the prompt is not a sandbox — keep approvals and isolation.
Full runnable smoke-test command pattern (first set MARKER_PATH to the actual created nonce file)
```
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the marker file whose path is $MARKER_PATH. Reply with its exact contents. Do not edit files."
```
Regular bounded tasks (parent writes a bounded task.md first)
```
hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
```
Confirm setup: with your own key, an authenticated GET /v1/models lists the exact model Flash; the smoke test above returned the exact marker nonce through custom:teralor-flash-executor; and Pi's own model/settings are still unchanged. Any failure means fixing setup first — never fall back to another model silently.

ZCode — native subagent (GUI)

ZCode delegates through a native subagent you configure in the GUI. These instructions follow the ZCode configuration docs, subagents docs and skill docs and are not a claim of live Flash certification. Keep the primary model unchanged, and if GUI automation is unavailable on your machine, perform these precise manual steps yourself rather than letting an agent fabricate configuration changes.

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. ZCode saves definitions under ~/.zcode/agents/<name>.md, but choose the model/provider in the UI rather than inventing persisted IDs in a file.
For the first read-only check allow only Read/Grep/Glob; authorize Edit/Write/Bash only for coding tasks that need them. Automatic compaction exposes no user threshold — do not add a fake threshold or extra_body JSON fields.
Install the original workflow skill at ~/.zcode/skills/flash-executor/SKILL.md: Download workflow SKILL.md Then Settings → Skills → Refresh and enable, and invoke $flash-executor. A skill adds instructions; it is not a subagent or provider configuration.
Confirm setup: save and enable, start a new session (running sessions do not hot-reload), invoke @flash-executor with one bounded read-only task, and confirm it answered with the explicit Flash model while the primary model remains unchanged.

Cursor — external Flash worker

Complete standalone setup for Cursor. Everything needed is below; no other section is required.

Keep Cursor's own provider, model and settings unchanged — Flash runs as a separate Hermes process, not as a native Cursor model or subagent. Pinning an explicit custom/BYOK Flash model through a model: field is not supported currently: support confirms model: inheritonly follows an already-Flash parent — not unchanged-primary executor mode. Keep Cursor's Models, API Keys and base-URL settings unchanged (see the Cursor skills docs).
Install Hermes from the machine that will actually run the worker using its official installation guide (CLI installer https://hermes-agent.nousresearch.com/install.sh; native Windows uses install.ps1). No private launcher or GPU/Docker image is required. Installing software needs your approval — review the official script before running it; never execute remote code blindly.
Check first (Bash example)
```
hermes --version || echo "Hermes is not installed"
```
Create a dedicated worker profile only if absent — never clone or inherit the parent, and never overwrite an existing profile. If flash-executor already exists with different settings, inspect it, reuse it only when it matches, or choose a distinct profile name.
Create once, then merge the YAML below (Bash)
```
hermes profile list
hermes profile create flash-executor --no-alias --no-skills
hermes -p flash-executor config edit
```
The key is read from TERALOR_API_KEY in the actual worker process. There are two supply modes: export it in the environment of the process that launches the worker (a plain bash -lc check does not load the Hermes profile .env, so a valid private-profile key would falsely look missing there), or place it in the private worker-profile .env (permissions 0600), which Hermes itself loads at startup. Never paste a key into chat, a repository or a config literal, and never print its value — the fresh authenticated Hermes smoke test below is what actually proves the worker sees the key.
Keep your normal authorizations and sandboxing in both harnesses; do not add bypass flags such as --yolo or -z.

Worker profile config

Download hermes-standalone-executor.yaml

Merge the shown keys into ~/.hermes/profiles/flash-executor/config.yaml — do not replace other settings.

View hermes-standalone-executor.yaml

# Teralor Flash as an ISOLATED STANDALONE EXECUTOR PROFILE in Hermes 0.21 —
# the worker a parent harness (Codex, Claude Code, Pi, Cursor) drives from its
# own terminal tool while keeping its own model unchanged.
# Create a dedicated profile (nothing is cloned from the parent) and merge
# this YAML into ~/.hermes/profiles/flash-executor/config.yaml:
#   hermes profile create flash-executor --no-alias --no-skills   # only if absent
#   hermes -p flash-executor config edit   # merge; do not replace other settings
# If a different flash-executor profile already exists, inspect and reuse it
# only when it matches, or choose a distinct profile name — never overwrite.
# The key is read from the TERALOR_API_KEY environment variable of the actual
# worker process — never paste a key literal into this file, a prompt, argv,
# URLs or source control.
# Hermes 0.21 ignores legacy model.max_tokens / HERMES_MAX_TOKENS: the output
# budget lives in providers.teralor-flash-executor.extra_body.max_tokens and
# the compaction trigger is the separate compression.threshold_tokens below.
# Inspect `hermes -p flash-executor fallback list`; disable worker-side
# fallbacks only through supported CLI subcommands, and never touch the parent
# harness's or another profile's fallback settings.
providers:
  teralor-flash-executor:
    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
model:
  provider: custom:teralor-flash-executor
  default: Flash
context:
  engine: compressor
compression:
  enabled: true
  threshold_tokens: 172032

Install the Flash skill (required). Install the original workflow skill from the same-origin download into the host path below, checking HTTP success, parsing valid YAML frontmatter with name: flash-executor and a non-empty description, rejecting an HTML or error-page body (valid skills may contain HTML comments), and staging the validated body in a unique temp file before placing it as a new file. The setup instructions you are reading and this workflow skill stay distinct; if a file already exists at the path, stop on the conflict and preserve the existing customization rather than overwriting.
Download workflow SKILL.md
Save as .cursor/skills/flash-executor/SKILL.md, let Cursor discover the skill, then invoke /flash-executor. A skill adds instructions only — it does not configure model routing.
The skill adds task-scoping and invocation instructions only — it is not the connection. Its instructions must explicitly bind external calls to this flash-executor profile rather than an inherited Cursor subagent.
Run ONE bounded marker-read smoke test from the current project or an approved isolated directory (Bash example). First write a task-owned temp marker file containing a freshly generated nonce, then point the command at the REAL marker path — never put the nonce value in the prompt, and never substitute a fake probe, path or model. Require the exact nonce returned plus route/config evidence (profile flash-executor, custom:teralor-flash-executor, Flash). Hermes, the workspace and the secure key environment must exist on the machine actually running the terminal — a local install does not automatically exist in SSH or Cloud Agent workspaces, and sandboxing must not be disabled wholesale.The parent should invoke this through its own terminal tool and check the actual artifact and result, not just the worker's claim. A read-only instruction in the prompt is not a sandbox — keep approvals and isolation.
Full runnable smoke-test command pattern (first set MARKER_PATH to the actual created nonce file)
```
hermes -p flash-executor chat --oneshot --max-turns 8 -t terminal,file -q "Read the marker file whose path is $MARKER_PATH. Reply with its exact contents. Do not edit files."
```
Regular bounded tasks (parent writes a bounded task.md first)
```
hermes -p flash-executor chat --oneshot --max-turns 50 -t terminal,file --query-file task.md
```
Confirm setup: with your own key, an authenticated GET /v1/models lists the exact model Flash; the smoke test above returned the exact marker nonce through custom:teralor-flash-executor; and Cursor's own model/settings are still unchanged. Any failure means fixing setup first — never fall back to another model silently.