Merge branch 'main' of github.com:NousResearch/hermes-agent into bb/gui
# Conflicts: # tui_gateway/server.py
This commit is contained in:
Brooklyn Nicholson
@@ -111,6 +111,17 @@ tail_token_budget = 100,000 × 0.20 = 20,000
|
||||
max_summary_tokens = min(200,000 × 0.05, 12,000) = 10,000
|
||||
```
|
||||
|
||||
:::note Threshold is derived from the MAIN model's context window
|
||||
`threshold_tokens` is always `threshold × context_length`, where `context_length`
|
||||
is the **main agent model's** context window — never the auxiliary/summary
|
||||
model's. On a 262,144-token model at the default `0.50`, the threshold is
|
||||
`262,144 × 0.50 = 131,072`. That number being close to a common "128K context"
|
||||
is a coincidence of the percentage, not a sign that the auxiliary model's window
|
||||
is the trigger. The auxiliary model's context window is a separate concern — see
|
||||
the "Summary model context length" warning below for how it affects whether a
|
||||
summary can be produced, not when compression fires.
|
||||
:::
|
||||
|
||||
|
||||
## Compression Algorithm
|
||||
|
||||
|
||||
@@ -58,6 +58,7 @@ hermes [global-options] <command> [subcommand/options]
|
||||
| `hermes doctor` | Diagnose config and dependency issues. |
|
||||
| `hermes security audit` | On-demand supply-chain audit (OSV.dev) for the venv, plugin requirements, and pinned MCP servers. |
|
||||
| `hermes dump` | Copy-pasteable setup summary for support/debugging. |
|
||||
| `hermes prompt-size` | Show a byte breakdown of the system prompt + tool schemas (skills index, memory, profile). Runs offline. |
|
||||
| `hermes debug` | Debug tools — upload logs and system info for support. |
|
||||
| `hermes backup` | Back up Hermes home directory to a zip file. |
|
||||
| `hermes checkpoints` | Inspect / prune / clear `~/.hermes/checkpoints/` (the shadow store used by `/rollback`). Run with no args for a status overview. |
|
||||
@@ -886,6 +887,50 @@ Lines without a parseable timestamp are included when `--since` is active (they
|
||||
|
||||
Hermes uses Python's `RotatingFileHandler`. Old logs are rotated automatically — look for `agent.log.1`, `agent.log.2`, etc. The `hermes logs list` subcommand shows all log files including rotated ones.
|
||||
|
||||
|
||||
## `hermes prompt-size`
|
||||
|
||||
```bash
|
||||
hermes prompt-size [--platform <name>] [--json]
|
||||
```
|
||||
|
||||
Reports the fixed prompt budget for a fresh session — what gets sent on every
|
||||
API call *before* any conversation content. Useful when a downstream adapter or
|
||||
proxy has a tighter prompt budget than the model's context window, or when you
|
||||
want to see which block (skills index, memory, profile) dominates.
|
||||
|
||||
It builds the same system prompt the agent would, then breaks it down:
|
||||
|
||||
- **System prompt total** — full assembled prompt (identity, guidance, skills
|
||||
index, context files, memory, profile, timestamp).
|
||||
- **Skills index** — the `<available_skills>` block. This is often the largest
|
||||
single block when many skills are installed.
|
||||
- **Memory** and **user profile** — your `MEMORY.md` / `USER.md` snapshots.
|
||||
- **Prompt tiers** — stable / context / volatile, matching how Hermes layers
|
||||
the prompt for cache-friendliness.
|
||||
- **Tool schemas** — the JSON for all enabled tools (the other half of the
|
||||
fixed per-call payload).
|
||||
|
||||
Runs entirely offline — no API call, works with no credentials configured.
|
||||
|
||||
```bash
|
||||
# Human-readable breakdown for the CLI platform (default)
|
||||
hermes prompt-size
|
||||
|
||||
# Simulate a messaging platform's prompt (different platform hint)
|
||||
hermes prompt-size --platform telegram
|
||||
|
||||
# Machine-readable output for scripts
|
||||
hermes prompt-size --json
|
||||
```
|
||||
|
||||
:::tip
|
||||
The skills index and tool schemas scale with how many skills and tools you have
|
||||
enabled. To shrink the prompt, disable unused toolsets (`hermes tools`) or
|
||||
uninstall skills you don't need (`hermes skills`). Context files (AGENTS.md,
|
||||
.cursorrules) in your current directory also count toward the total.
|
||||
:::
|
||||
|
||||
## `hermes config`
|
||||
|
||||
```bash
|
||||
|
||||
@@ -106,6 +106,10 @@ The auto-injected dialectic scales `dialecticReasoningLevel` by query length: +1
|
||||
|
||||
Honcho is configured in `~/.honcho/config.json` (global) or `$HERMES_HOME/honcho.json` (profile-local). The setup wizard handles this for you.
|
||||
|
||||
### Self-Hosted Honcho with Authentication
|
||||
|
||||
When pointing Hermes at a self-hosted Honcho server, `hermes honcho setup` (and `hermes memory setup`) ask for a **local JWT / bearer token** after the base URL. Paste a JWT signed with the server's `AUTH_JWT_SECRET` (the Honcho compose env var) to enable authenticated access; leave it blank for servers running with `AUTH_USE_AUTH=false`. The local token is stored under the host block (`hosts.<host>.apiKey` in `honcho.json`), separate from any cloud `apiKey`, so you can flip the `Cloud or local?` prompt back to `cloud` later without losing either credential.
|
||||
|
||||
### Full Config Reference
|
||||
|
||||
| Key | Default | Description |
|
||||
@@ -199,11 +203,12 @@ When Honcho is active as the memory provider, five tools become available:
|
||||
|
||||
## CLI Commands
|
||||
|
||||
The `hermes honcho` subcommand is **only registered when Honcho is the active memory provider** (`memory.provider: honcho` in `config.yaml`). Run `hermes memory setup` and pick Honcho first; the subcommand appears on the next invocation.
|
||||
The `hermes honcho` subcommand is **only registered when Honcho is the active memory provider** (`memory.provider: honcho` in `config.yaml`). On a fresh install, configure Honcho directly with `hermes memory setup honcho` (or run `hermes memory setup` and pick it from the list); the `hermes honcho` subcommand then appears on the next invocation.
|
||||
|
||||
```bash
|
||||
hermes memory setup honcho # Configure Honcho directly (works before activation)
|
||||
hermes honcho status # Connection status, config, and key settings
|
||||
hermes honcho setup # Redirects to `hermes memory setup`
|
||||
hermes honcho setup # Redirects to `hermes memory setup` (post-activation alias)
|
||||
hermes honcho strategy # Show or set session strategy (per-session/per-directory/per-repo/global)
|
||||
hermes honcho peer # Show or update peer names + dialectic reasoning level
|
||||
hermes honcho mode # Show or set recall mode (hybrid/context/tools)
|
||||
|
||||
@@ -155,6 +155,36 @@ events WebSocket is pinned to a board at connection time; switching in
|
||||
the UI opens a fresh WS against the new board.
|
||||
|
||||
|
||||
## File attachments
|
||||
|
||||
Tasks can carry file attachments — PDFs, images, source documents — so a
|
||||
worker has the source material it needs without you pasting paths into the
|
||||
body and hoping it finds them.
|
||||
|
||||
- **Upload** — open a task in the dashboard drawer and use the
|
||||
**Attachments** section's *Upload file* button (multiple files at once
|
||||
are fine). Each upload is capped at 25 MB.
|
||||
- **Storage** — files land under
|
||||
`<hermes-home>/kanban/attachments/<task_id>/` for the default board, or
|
||||
`<hermes-home>/kanban/boards/<slug>/attachments/<task_id>/` for a named
|
||||
board. Set `HERMES_KANBAN_ATTACHMENTS_ROOT` to pin a custom location.
|
||||
- **What the worker sees** — when the dispatcher hands a task to a worker,
|
||||
the worker's context includes an **Attachments** section listing each
|
||||
file's name and its **absolute path**. The worker has full file/terminal
|
||||
tool access, so it reads attachments directly (`read_file`, or shell
|
||||
tools like `pdftotext`).
|
||||
- **Download / remove** — the drawer lists each attachment with a download
|
||||
link and a remove (×) control. Removing an attachment deletes both the
|
||||
metadata row and the on-disk file.
|
||||
|
||||
:::note Remote terminal backends
|
||||
Attachment paths resolve directly on the **local** terminal backend, which
|
||||
is the default for Kanban workers. If you run workers on a remote backend
|
||||
(Docker, Modal), mount the board's `attachments/` directory into the
|
||||
sandbox so the absolute paths in the worker context are reachable.
|
||||
:::
|
||||
|
||||
|
||||
## Quick start
|
||||
|
||||
The commands below are **you** (the human) setting up the board and creating tasks. Once a task is assigned, the dispatcher spawns the assigned profile as a worker, and from there **the model drives the task through `kanban_*` tool calls, not CLI commands** — see [How workers interact with the board](#how-workers-interact-with-the-board).
|
||||
|
||||
@@ -66,7 +66,7 @@ AI-native cross-session user modeling with dialectic reasoning, session-scoped c
|
||||
hermes memory setup # select "honcho" — runs the Honcho-specific post-setup
|
||||
```
|
||||
|
||||
The legacy `hermes honcho setup` command still works (it now redirects to `hermes memory setup`), but is only registered after Honcho is selected as the active memory provider.
|
||||
On a fresh install, configure Honcho directly with `hermes memory setup honcho`. The legacy `hermes honcho setup` command still works (it now redirects to `hermes memory setup`), but is only registered after Honcho is selected as the active memory provider.
|
||||
|
||||
**Config:** `$HERMES_HOME/honcho.json` (profile-local) or `~/.honcho/config.json` (global). Resolution order: `$HERMES_HOME/honcho.json` > `~/.hermes/honcho.json` > `~/.honcho/config.json`. See the [config reference](https://github.com/NousResearch/hermes-agent/blob/main/plugins/memory/honcho/README.md) and the [Honcho integration guide](https://docs.honcho.dev/v3/guides/integrations/hermes).
|
||||
|
||||
|
||||
@@ -123,6 +123,8 @@ Set these in `config.yaml` under `platforms.weixin.extra`:
|
||||
| `allow_from` | `[]` | User IDs allowed for DMs (when dm_policy=allowlist) |
|
||||
| `group_allow_from` | `[]` | Group IDs allowed (when group_policy=allowlist) |
|
||||
| `split_multiline_messages` | `false` | When `true`, split multi-line replies into multiple chat messages (legacy behavior). When `false`, keep multi-line replies as one message unless they exceed the length limit. |
|
||||
| `text_batch_delay_seconds` | `3.0` | Quiet period (seconds) before a buffered burst of rapid text messages is flushed as one combined request. iLink delivers messages individually, so this debounce avoids one agent invocation per fragment. Set `0` to dispatch each message immediately. |
|
||||
| `text_batch_split_delay_seconds` | `5.0` | Extended flush delay used when the latest fragment is near the split threshold (long messages iLink may have chunked). |
|
||||
|
||||
## Access Policies
|
||||
|
||||
|
||||
@@ -201,6 +201,22 @@ Code blocks and inline code are preserved as-is since WhatsApp supports triple-b
|
||||
|
||||
When the agent calls tools (web search, file operations, etc.), WhatsApp displays real-time progress indicators showing which tool is running. This is enabled by default — no configuration needed.
|
||||
|
||||
### Message Batching (Debounce)
|
||||
|
||||
WhatsApp delivers each message individually, so a rapid burst (forwarded batches, paste-splits, multi-line text) would otherwise trigger a separate agent invocation per fragment — wasting tokens and producing several disjointed replies. The adapter buffers successive text messages from the same chat and dispatches them as one combined request after a short quiet period (default **5s**, extended to **10s** for very long fragments). Tune via `config.yaml`:
|
||||
|
||||
```yaml
|
||||
# ~/.hermes/config.yaml
|
||||
gateway:
|
||||
platforms:
|
||||
whatsapp:
|
||||
extra:
|
||||
text_batch_delay_seconds: 5.0 # quiet period before flushing a batch
|
||||
text_batch_split_delay_seconds: 10.0 # extended delay near the split threshold
|
||||
```
|
||||
|
||||
Set `text_batch_delay_seconds: 0` to dispatch each message immediately (disables batching).
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Reference in New Issue
Block a user