hermes - 💡(How to fix) Fix Feature request: structured event stream for non-interactive Hermes runs

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Please add a supported machine-readable event stream for hermes chat non-interactive runs so third-party supervisors, dashboards, and adapters can display live run progress without scraping human-oriented terminal output.

Today, hermes chat -q ... -Q is excellent for clean final-response automation, but it intentionally suppresses most intermediate UI output. Running without --quiet can expose more human terminal output, but that output is not a stable integration contract and still requires fragile parsing of display text, emoji/status lines, stderr routing, and session metadata.

A first-class event stream would let integrations consume structured run lifecycle, assistant, and tool events while preserving the existing human CLI UX.

Error Message

  • full session id, whether resume succeeded, error if not
  • call id, status, duration, result summary, error flag
  • exit status, error, duration, final session id

Root Cause

External orchestrators and dashboards often need to show a live run log while a Hermes agent is executing. Without a structured event stream they must choose between:

  1. quiet mode: reliable final output, but sparse/no live progress; or
  2. non-quiet mode: more visible activity, but only as terminal UI text that may change and is difficult to parse robustly.

A supported stream would make Hermes easier to integrate into:

  • web dashboards
  • job runners
  • CI-style supervisors
  • multi-agent orchestration systems
  • audit/logging pipelines
  • long-running unattended agent workflows

Code Example

{"schema_version":1,"type":"run_start","run_id":"...","session_id":null,"model":"...","provider":"...","ts":"2026-05-21T21:00:00Z"}
{"schema_version":1,"type":"tool_call_start","call_id":"call_1","tool":"terminal","summary":"pwd","ts":"2026-05-21T21:00:02Z"}
{"schema_version":1,"type":"tool_call_end","call_id":"call_1","status":"ok","duration_ms":83,"ts":"2026-05-21T21:00:02Z"}
{"schema_version":1,"type":"assistant_message","text":"Done.","ts":"2026-05-21T21:00:04Z"}
{"schema_version":1,"type":"session_id","session_id":"20260521_210004_abcdef","ts":"2026-05-21T21:00:04Z"}
{"schema_version":1,"type":"run_end","status":"ok","session_id":"20260521_210004_abcdef","duration_ms":4123,"ts":"2026-05-21T21:00:04Z"}
RAW_BUFFERClick to expand / collapse

Summary

Please add a supported machine-readable event stream for hermes chat non-interactive runs so third-party supervisors, dashboards, and adapters can display live run progress without scraping human-oriented terminal output.

Today, hermes chat -q ... -Q is excellent for clean final-response automation, but it intentionally suppresses most intermediate UI output. Running without --quiet can expose more human terminal output, but that output is not a stable integration contract and still requires fragile parsing of display text, emoji/status lines, stderr routing, and session metadata.

A first-class event stream would let integrations consume structured run lifecycle, assistant, and tool events while preserving the existing human CLI UX.

Requested capability

Add an opt-in CLI/API mode such as one of:

  • hermes chat --events-jsonl -q "..."
  • hermes chat --event-stream jsonl -q "..."
  • hermes chat --events-file /path/to/events.ndjson -q "..."
  • or an equivalent callback/sink interface usable by adapters

The key requirement is a stable schema and ordering guarantee for events emitted during a run.

Suggested event types

A minimal useful stream could include:

  • run_start
    • session id if known, source tag, model/provider metadata, toolsets, timestamp
  • resume_session
    • full session id, whether resume succeeded, error if not
  • assistant_delta or assistant_message
    • incremental assistant text where available, or complete messages as they are produced
  • tool_call_start
    • tool name, call id, sanitized input/summary, timestamp
  • tool_call_output
    • call id, stdout/stderr/content chunks where appropriate, redacted/sanitized
  • tool_call_end
    • call id, status, duration, result summary, error flag
  • final_answer
    • final response text
  • session_id
    • full persisted Hermes session id
  • usage
    • token/cost/model metadata when available
  • run_end
    • exit status, error, duration, final session id

Why this matters

External orchestrators and dashboards often need to show a live run log while a Hermes agent is executing. Without a structured event stream they must choose between:

  1. quiet mode: reliable final output, but sparse/no live progress; or
  2. non-quiet mode: more visible activity, but only as terminal UI text that may change and is difficult to parse robustly.

A supported stream would make Hermes easier to integrate into:

  • web dashboards
  • job runners
  • CI-style supervisors
  • multi-agent orchestration systems
  • audit/logging pipelines
  • long-running unattended agent workflows

Compatibility / safety notes

  • Keep current stdout/stderr behavior unchanged unless the flag is explicitly enabled.
  • If streaming to stdout would conflict with final-response automation, support writing events to stderr or to a separate NDJSON file path.
  • Include a documented redaction boundary for secrets/tool inputs/tool outputs.
  • Emit full session ids, not shortened display prefixes, so external systems can safely resume later.
  • Prefer append-only JSONL/NDJSON so consumers can tail the stream live.
  • Include a schema version, e.g. { "schema_version": 1, "type": "tool_call_start", ... }.

Non-goals

  • This should not require consumers to parse Hermes' human terminal UI.
  • This should not change default CLI output.
  • This should not require a TTY.

Example shape

{"schema_version":1,"type":"run_start","run_id":"...","session_id":null,"model":"...","provider":"...","ts":"2026-05-21T21:00:00Z"}
{"schema_version":1,"type":"tool_call_start","call_id":"call_1","tool":"terminal","summary":"pwd","ts":"2026-05-21T21:00:02Z"}
{"schema_version":1,"type":"tool_call_end","call_id":"call_1","status":"ok","duration_ms":83,"ts":"2026-05-21T21:00:02Z"}
{"schema_version":1,"type":"assistant_message","text":"Done.","ts":"2026-05-21T21:00:04Z"}
{"schema_version":1,"type":"session_id","session_id":"20260521_210004_abcdef","ts":"2026-05-21T21:00:04Z"}
{"schema_version":1,"type":"run_end","status":"ok","session_id":"20260521_210004_abcdef","duration_ms":4123,"ts":"2026-05-21T21:00:04Z"}

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix Feature request: structured event stream for non-interactive Hermes runs