opentui(phase3): launcher integration — HERMES_TUI_ENGINE dual-engine
hermes --tui launches the native OpenTUI engine (Bun) when HERMES_TUI_ENGINE=opentui (env) or display.tui_engine=opentui (config); Ink stays the default and the shipping path is untouched. - _resolve_tui_engine() (env > config > ink); refuses opentui on Windows/Termux (no Bun) -> falls back to ink with a notice. - _make_opentui_argv() -> [bun, src/entry.real.tsx] (no build step). - _bun_bin() with HERMES_BUN override. - Branch at top of _make_tui_argv BEFORE _ensure_tui_node (Bun-only host must not bootstrap Node). - Gate _launch_tui NODE_OPTIONS/--max-old-space-size on engine==ink (Bun is JSC; the V8 flag errors/ignores). Verified end-to-end via tmux: real hermes --tui -> Bun -> OpenTUI -> real Python gateway streamed a real reply. No-flag default still ink.
This commit is contained in:
alt-glitch
@@ -125,6 +125,35 @@ When `workdir` is set:
|
||||
Jobs with a `workdir` run sequentially on the scheduler tick, not in the parallel pool. This is deliberate: the cron worker applies the job workdir through process-global terminal state, so two workdir jobs running at the same time would corrupt each other's cwd. Workdir-less jobs still run in parallel as before.
|
||||
:::
|
||||
|
||||
## Running cron jobs in a specific profile
|
||||
|
||||
By default a cron job inherits whichever Hermes profile owned the gateway / CLI that created it. Pass `--profile <name>` (CLI) or `profile=` (cronjob tool) to re-target the job at a different profile — the scheduler resolves that profile's `HERMES_HOME`, temporarily switches into it for the duration of the run, loads its `.env` + `config.yaml`, and executes the job there:
|
||||
|
||||
```bash
|
||||
# Pin a job to the `night-ops` profile regardless of where it was scheduled
|
||||
hermes cron create "every 1d at 03:00" \
|
||||
"Tail the security log and flag anomalies" \
|
||||
--profile night-ops
|
||||
```
|
||||
|
||||
```python
|
||||
# From a chat, via the cronjob tool
|
||||
cronjob(
|
||||
action="create",
|
||||
schedule="every 1d at 03:00",
|
||||
prompt="Tail the security log and flag anomalies",
|
||||
profile="night-ops",
|
||||
)
|
||||
```
|
||||
|
||||
Use `--profile default` to explicitly pin to the root Hermes profile. The named profile must already exist; the scheduler refuses to create profiles on the fly. To clear a profile pin during `cron edit`, pass an empty string (`--profile ""` or `profile=""`) — the job reverts to running in whatever profile the scheduler itself is in.
|
||||
|
||||
If the pinned profile is later deleted, the scheduler logs a warning and falls back to running the job in its current profile rather than crashing — so a stale `profile` reference never wedges a job.
|
||||
|
||||
:::note Serialization
|
||||
Jobs with a `profile` set also run sequentially, for the same reason as `workdir`-pinned jobs: switching `HERMES_HOME` is a process-global mutation, so two profile-pinned jobs running in parallel would race each other. Unpinned jobs still run in the normal parallel pool.
|
||||
:::
|
||||
|
||||
## Editing jobs
|
||||
|
||||
You do not need to delete and recreate jobs just to change them.
|
||||
@@ -194,7 +223,7 @@ What they do:
|
||||
- `resume` — re-enable the job and compute the next future run
|
||||
- `run` — trigger the job on the next scheduler tick
|
||||
- `remove` — delete it entirely
|
||||
- `edit` — modify schedule, prompt, delivery, etc.
|
||||
- `edit` — modify schedule, prompt, profile, delivery, etc.
|
||||
|
||||
**Name-based lookup.** All four mutating verbs (`pause`, `resume`, `run`, `remove`, `edit`) plus the agent's `cronjob` tool now accept a job **name** (case-insensitive) in place of the hex ID. The agent and CLI both prefer an exact ID match if one exists; ambiguous name matches (multiple jobs sharing the same name) are refused with the full list of candidate IDs so you can pick one explicitly. Names are not unique, so this guard is load-bearing — it prevents silently mutating the wrong job when two share a name.
|
||||
|
||||
|
||||
@@ -20,13 +20,7 @@ Two files make up the agent's memory:
|
||||
Both are stored in `~/.hermes/memories/` and are injected into the system prompt as a frozen snapshot at session start. The agent manages its own memory via the `memory` tool — it can add, replace, or remove entries.
|
||||
|
||||
:::info
|
||||
Character limits keep memory focused. Memory does **not** auto-compact: when a
|
||||
write would exceed the limit, the `memory` tool returns an error instead of
|
||||
silently dropping entries. The agent then makes room itself — consolidating or
|
||||
removing entries in the same turn before retrying (see [What Happens When Memory
|
||||
is Full](#what-happens-when-memory-is-full)). Note that `replace` is also bound
|
||||
by the limit: swapping an entry for a longer one can still overflow, so the new
|
||||
content must be shortened (or another entry removed) to fit.
|
||||
Character limits keep memory focused. When memory is full, the agent consolidates or replaces entries to make room for new information.
|
||||
:::
|
||||
|
||||
## How Memory Appears in the System Prompt
|
||||
@@ -215,64 +209,8 @@ memory:
|
||||
user_profile_enabled: true
|
||||
memory_char_limit: 2200 # ~800 tokens
|
||||
user_char_limit: 1375 # ~500 tokens
|
||||
write_approval: false # false = write freely (default) | true = require approval
|
||||
```
|
||||
|
||||
## Controlling memory writes (`write_approval`)
|
||||
|
||||
By default the agent saves memory freely — including from the background
|
||||
self-improvement review that runs after a turn. If you'd rather approve saves
|
||||
first, set `memory.write_approval: true`. It's a simple on/off gate applied to
|
||||
**both** foreground turns and the background review:
|
||||
|
||||
| `write_approval` | Behaviour |
|
||||
|------------------|-----------|
|
||||
| `false` (default) | Write freely — the gate is off (the pre-gate behaviour). |
|
||||
| `true` | Require approval before anything is saved. In the interactive CLI, foreground writes prompt you inline (entries are small enough to read in full). Everywhere else — messaging platforms, scripts, and the background self-improvement review — writes are **staged** for review with `/memory pending`. |
|
||||
|
||||
> To turn memory off entirely (not just gate it), set `memory_enabled: false`.
|
||||
|
||||
Review staged writes from the CLI or any messaging platform:
|
||||
|
||||
```
|
||||
/memory pending # list staged memory writes (auto ones tagged [auto])
|
||||
/memory approve <id> # apply one (or 'all')
|
||||
/memory reject <id> # drop one (or 'all')
|
||||
/memory approval on # turn the gate on (or 'off') and persist it
|
||||
```
|
||||
|
||||
This is the answer to "the agent saved a wrong assumption about me": set
|
||||
`write_approval: true`, and every save — especially the unprompted background
|
||||
ones — waits for your yes/no before it ever enters your profile.
|
||||
|
||||
## Controlling skill writes (`skills.write_approval`)
|
||||
|
||||
Skills use the same on/off gate, but the review UX differs because a
|
||||
`SKILL.md` is far too large to read in a chat bubble:
|
||||
|
||||
```yaml
|
||||
skills:
|
||||
write_approval: false # false = write freely (default) | true = require approval
|
||||
```
|
||||
|
||||
When `write_approval: true`, skill writes (create / edit / patch / write_file /
|
||||
delete) always **stage** regardless of origin. You review the one-line gist
|
||||
inline, but the full diff stays out-of-band:
|
||||
|
||||
```
|
||||
/skills pending # list staged skill writes + a one-line gist each
|
||||
/skills diff <id> # full unified diff (best viewed in CLI or dashboard)
|
||||
/skills approve <id> # apply it (or 'all')
|
||||
/skills reject <id> # drop it (or 'all')
|
||||
/skills approval on # turn the gate on (or 'off') and persist it
|
||||
```
|
||||
|
||||
On a messaging platform, approve a skill from its gist + metadata, or open
|
||||
`/skills diff` on the CLI / dashboard / the staged file under
|
||||
`~/.hermes/pending/skills/<id>.json` when you want to read the whole change.
|
||||
Full details in [Gating agent skill writes](/user-guide/features/skills#gating-agent-skill-writes-skillswrite_approval).
|
||||
|
||||
|
||||
## External Memory Providers
|
||||
|
||||
For deeper, persistent memory that goes beyond MEMORY.md and USER.md, Hermes ships with 8 external memory provider plugins — including Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, and Supermemory.
|
||||
|
||||
@@ -401,43 +401,6 @@ The agent can create, update, and delete its own skills via the `skill_manage` t
|
||||
The `patch` action is preferred for updates — it's more token-efficient than `edit` because only the changed text appears in the tool call.
|
||||
:::
|
||||
|
||||
### Gating agent skill writes (`skills.write_approval`)
|
||||
|
||||
By default the agent writes skills freely — including from the [background
|
||||
self-improvement review](/user-guide/features/memory#controlling-memory-writes-write_approval)
|
||||
that runs after a turn. If you'd rather approve every skill write first
|
||||
(small models that misjudge what they learned, secure environments, or just
|
||||
wanting eyes on the self-improvement loop), turn on the write-approval gate:
|
||||
|
||||
```yaml
|
||||
skills:
|
||||
write_approval: false # false = write freely (default) | true = require approval
|
||||
```
|
||||
|
||||
When `write_approval: true`, every `skill_manage` write (create / edit /
|
||||
patch / delete / write_file / remove_file) is **staged** instead of committed —
|
||||
a SKILL.md is too large to review inline, so staging applies regardless of
|
||||
whether the write came from a foreground turn or the background review.
|
||||
Staged writes survive restarts under `~/.hermes/pending/skills/` and are
|
||||
reviewed with the same familiar approve/deny flow as dangerous commands:
|
||||
|
||||
```
|
||||
/skills pending # list staged skill writes + a one-line gist each
|
||||
/skills diff <id> # full unified diff (best viewed in CLI or dashboard)
|
||||
/skills approve <id> # apply it (or 'all')
|
||||
/skills reject <id> # drop it (or 'all')
|
||||
/skills approval on # turn the gate on (or 'off') and persist it
|
||||
```
|
||||
|
||||
The review surface works in the interactive CLI and on messaging platforms
|
||||
(diff output is truncated for chat bubbles — read the full diff on the CLI or
|
||||
in the pending JSON file). Memory writes have the same gate under
|
||||
`memory.write_approval` — see [Controlling memory writes](/user-guide/features/memory#controlling-memory-writes-write_approval).
|
||||
|
||||
> The separate `skills.guard_agent_created` setting is a content scanner
|
||||
> (dangerous-pattern heuristics), not an approval gate — the two are
|
||||
> independent. See [Guard on agent-created skill writes](/user-guide/configuration#guard-on-agent-created-skill-writes).
|
||||
|
||||
## Skills Hub
|
||||
|
||||
Browse, search, install, and manage skills from online registries, `skills.sh`, direct well-known skill endpoints, and official optional skills.
|
||||
|
||||
@@ -66,10 +66,8 @@ tts:
|
||||
model: "voxtral-mini-tts-2603"
|
||||
voice_id: "c69964a6-ab8b-4f8a-9465-ec0925096ec8" # Paul - Neutral (default)
|
||||
gemini:
|
||||
model: "gemini-2.5-flash-preview-tts" # or gemini-3.1-flash-tts-preview
|
||||
model: "gemini-2.5-flash-preview-tts" # or gemini-2.5-pro-preview-tts
|
||||
voice: "Kore" # 30 prebuilt voices: Zephyr, Puck, Kore, Enceladus, Gacrux, etc.
|
||||
audio_tags: false # Enable hidden Gemini 3.1 TTS audio-tag insertion
|
||||
persona_prompt_file: "" # Optional Markdown/text file with Gemini voice direction
|
||||
xai:
|
||||
voice_id: "eve" # or a custom voice ID — see docs below
|
||||
language: "en" # ISO 639-1 code
|
||||
@@ -99,34 +97,6 @@ tts:
|
||||
|
||||
**Speed control**: The global `tts.speed` value applies to all providers by default. Each provider can override it with its own `speed` setting (e.g., `tts.openai.speed: 1.5`). Provider-specific speed takes precedence over the global value. Default is `1.0` (normal speed).
|
||||
|
||||
### Gemini Persona Prompts
|
||||
|
||||
Gemini TTS can follow natural-language performance direction. Set `tts.gemini.persona_prompt_file` to a local Markdown or text file that describes the voice persona. The file can include Gemini-style sections such as `AUDIO PROFILE`, `SCENE`, `DIRECTOR'S NOTES`, `SAMPLE CONTEXT`, and `TRANSCRIPT`.
|
||||
|
||||
If the file contains `{transcript}` or `{{ transcript }}`, Hermes replaces that placeholder with the live TTS text. Otherwise, Hermes appends a labeled `TRANSCRIPT` section automatically. The persona prompt stays local and is not shown in the chat reply.
|
||||
|
||||
```yaml
|
||||
tts:
|
||||
provider: gemini
|
||||
gemini:
|
||||
voice: Algieba
|
||||
persona_prompt_file: ~/.hermes/tts/butler-voice.md
|
||||
```
|
||||
|
||||
### Gemini Audio Tags
|
||||
|
||||
Gemini 3.1 Flash TTS supports freeform square-bracket audio tags such as `[whispers]`, `[excitedly]`, `[very slow]`, `[laughs]`, and other expressive delivery notes. Enable `tts.gemini.audio_tags` to have Hermes run a hidden rewrite pass before Gemini TTS. The rewrite inserts inline tags into the TTS script only; the visible chat reply stays unchanged.
|
||||
|
||||
```yaml
|
||||
tts:
|
||||
provider: gemini
|
||||
gemini:
|
||||
model: gemini-3.1-flash-tts-preview
|
||||
audio_tags: true
|
||||
```
|
||||
|
||||
The rewrite uses `auxiliary.tts_audio_tags` and defaults to your main chat model. Override that auxiliary task if you want tag insertion handled by a cheaper or faster model.
|
||||
|
||||
|
||||
### Input length limits
|
||||
|
||||
@@ -139,7 +109,7 @@ Each provider has a documented per-request input-character cap. Hermes truncates
|
||||
| xAI | 15000 |
|
||||
| MiniMax | 10000 |
|
||||
| Mistral | 4000 |
|
||||
| Google Gemini | 32000 |
|
||||
| Google Gemini | 5000 |
|
||||
| ElevenLabs | Model-aware (see below) |
|
||||
| NeuTTS | 2000 |
|
||||
| KittenTTS | 2000 |
|
||||
|
||||
@@ -28,7 +28,6 @@ This starts a local web server and opens `http://127.0.0.1:9119` in your browser
|
||||
| `--host` | `127.0.0.1` | Bind address |
|
||||
| `--no-open` | — | Don't auto-open the browser |
|
||||
| `--insecure` | off | Allow binding to non-localhost hosts (**DANGEROUS** — exposes API keys on the network; pair with a firewall and strong auth) |
|
||||
| `--isolated` | off | When launched from a named profile (`worker dashboard`), run a dedicated per-profile server instead of routing to the machine dashboard |
|
||||
|
||||
```bash
|
||||
# Custom port
|
||||
@@ -41,43 +40,6 @@ hermes dashboard --host 0.0.0.0
|
||||
hermes dashboard --no-open
|
||||
```
|
||||
|
||||
## Managing multiple profiles
|
||||
|
||||
The dashboard is a **machine-level** management surface: one server manages
|
||||
every [profile](../profiles.md) on the machine. A profile switcher in the
|
||||
sidebar (visible whenever more than one profile exists) decides which
|
||||
profile the management pages read and write — Config, API Keys, Skills,
|
||||
MCP, Models, and the Chat tab all follow it. While a profile other than
|
||||
the dashboard's own is selected, an amber banner names the managed profile
|
||||
so the write target is never ambiguous.
|
||||
|
||||
The selection lives in the URL (`?profile=<name>`), so deep links like
|
||||
`http://127.0.0.1:9119/skills?profile=worker` land with the switcher
|
||||
preselected and survive refresh.
|
||||
|
||||
Launching the dashboard from a profile alias routes to the machine
|
||||
dashboard instead of starting a second server:
|
||||
|
||||
```bash
|
||||
worker dashboard
|
||||
# → already running: opens the browser at ?profile=worker
|
||||
# → not running: starts the machine dashboard with "worker" preselected
|
||||
```
|
||||
|
||||
Pass `--isolated` to opt out and run a dedicated server scoped to that
|
||||
profile (the pre-unification behavior — useful if you deliberately expose
|
||||
different profiles' dashboards with different auth).
|
||||
|
||||
The **Chat** tab follows the switcher too: a scoped chat spawns its PTY
|
||||
child with the selected profile's `HERMES_HOME`, so the conversation runs
|
||||
with that profile's model, skills, memory, and session history. Switching
|
||||
profiles starts a fresh terminal session.
|
||||
|
||||
What stays per-profile and is *not* absorbed by the switcher: gateway
|
||||
processes (manage them via `hermes -p <name> gateway …`), each profile's
|
||||
session database, and cron schedulers (the Cron page already aggregates
|
||||
across profiles with its own filter).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
The default `hermes-agent` install does not ship the HTTP stack or PTY helper — those are optional extras. The **web dashboard** needs FastAPI and Uvicorn (`web` extra). The **Chat** tab also needs `ptyprocess` to spawn the embedded TUI behind a pseudo-terminal (`pty` extra on POSIX). Install both with:
|
||||
@@ -272,17 +234,6 @@ Create and manage scheduled cron jobs that run agent prompts on a recurring sche
|
||||
- **Trigger now** — immediately execute a job outside its normal schedule
|
||||
- **Delete** — permanently remove a cron job
|
||||
|
||||
### Profiles
|
||||
|
||||
Create and manage [profiles](../profiles.md) — isolated Hermes instances with their own config, skills, and sessions.
|
||||
|
||||
- **Profile cards** — each shows its model/provider, skill count, gateway state, description, and badges (active, default, alias)
|
||||
- **Create** — name + optional clone-from-default / clone-everything / no-bundled-skills, description, and model; the dedicated Profile Builder page (`/profiles/new`) offers the full flow (model, MCPs, skills)
|
||||
- **Manage skills & tools** — jumps to the Skills page scoped to that profile (sets the sidebar profile switcher)
|
||||
- **Set as active** — flips the sticky default that **future CLI/gateway runs** pick up (same as `hermes profile use`). This does *not* change what the dashboard manages — that's the profile switcher's job
|
||||
- **Edit model / description / SOUL** — inline editors writing into that profile
|
||||
- **Rename / Delete** — named profiles only
|
||||
|
||||
### Skills
|
||||
|
||||
Browse, search, and toggle installed skills and toolsets, and install new ones from the hub. Skills are loaded from `~/.hermes/skills/` and grouped by category.
|
||||
@@ -398,16 +349,6 @@ This re-reads `~/.hermes/.env` into the running process's environment. Useful wh
|
||||
|
||||
The web dashboard exposes a REST API that the frontend consumes. You can also call these endpoints directly for automation:
|
||||
|
||||
:::tip Profile-scoped endpoints
|
||||
The management endpoint families — `/api/config`, `/api/env`, `/api/skills`,
|
||||
`/api/tools/toolsets`, `/api/mcp`, and `/api/model/{info,options,auxiliary,set}` —
|
||||
accept an optional `?profile=<name>` query parameter (or `"profile"` in the
|
||||
JSON body for writes) that scopes the read/write to that profile's
|
||||
`HERMES_HOME`. Omitted = the dashboard's own profile. Unknown profile names
|
||||
return `404`. The `/api/pty` WebSocket accepts the same parameter to spawn
|
||||
a chat under the selected profile.
|
||||
:::
|
||||
|
||||
### GET /api/status
|
||||
|
||||
Returns agent version, gateway status, platform states, and active session count.
|
||||
@@ -540,7 +481,7 @@ same auth gate as the rest of `/api/`.
|
||||
| `GET /api/ops/checkpoints` · `POST .../prune` | Inspect / prune the `/rollback` store |
|
||||
| `POST /api/ops/hooks` · `DELETE /api/ops/hooks` | Create / remove a shell hook (consent-gated) |
|
||||
| `GET /api/system/stats` | Host stats — OS, CPU, memory, disk, uptime |
|
||||
| `GET /api/hermes/update/check` | Report update availability (commits behind, install method) without applying. For git/pip installs that are behind, also returns a `commits` list (`sha`, `summary`, `author`, `at`) of what's changed. `?force=1` busts the 6h cache |
|
||||
| `GET /api/hermes/update/check` | Report update availability (commits behind, install method) without applying. `?force=1` busts the 6h cache |
|
||||
| `GET /api/curator` · `PUT .../paused` · `POST .../run` | Skill-curator status + pause/resume + run |
|
||||
| `GET /api/portal` | Nous Portal auth + Tool Gateway routing (read-only) |
|
||||
| `POST /api/ops/prompt-size` · `/dump` · `/config-migrate` | Diagnostics (backgrounded) |
|
||||
|
||||
Reference in New Issue
Block a user