Summary

Hermes currently handles new user messages during an active run too bluntly. In practice:

• interruption is often not what the user wanted
• the busy-session UI acknowledgement is awkward and sometimes misleading
• users forget /background and /btw / related detached-side-question commands exist
• the system lacks a cheap policy layer that decides what should happen when a new message arrives during active work

This issue proposes an optional, default-off micro interrupt router at the busy-input boundary.

Problem or Use Case

When a user sends a new message while Hermes is already working, the system needs to decide among different intents:

• interrupt the current task
• queue the new message for the next turn
• ignore trivial duplicate chatter
• eventually support richer actions like detached/background/side-question workflows

Today that decision is handled inconsistently and with awkward UX:

• the acknowledgement text (Interrupting current task... I'll respond to your message shortly.) is clunky
• interruption is not always desired
• queue vs interrupt semantics are not surfaced clearly enough
• /background and /btw style commands are easy to forget, so users fall back to ordinary messages that then get handled too aggressively

Proposed Solution

Introduce a tiny optional router that runs only when a session is genuinely busy (actively thinking/replying, or with an active user-visible tool/process run).

The router should:

• be optional and default off
• use a fast cheap model only for ambiguous cases
• run deterministic guards before and after the model
• keep context tiny:
  • current tool/output preview
  • last 2 user messages
  • last 2 assistant messages
• keep v1 action scope conservative:
  • interrupt
  • queue
  • guarded ignore

For v1, background, merge, and ask should remain design placeholders unless runtime support is proven safe enough.

Why this is distinct from the existing issues

This is broader than just queue-mode acknowledgement wording (#11118), and broader than /btw naming/semantics (#9688).

This issue is about the product-level busy-input decision layer that should sit above those commands and behaviors.

Related issues:

• [Feature]: Distinguish queue-mode vs interrupt-mode busy-session acknowledgements in the gateway #11118 — Distinguish queue-mode vs interrupt-mode busy-session acknowledgements in the gateway
• Proposal: clarify /btw vs /side semantics for detached side questions during active runs #9688 — clarify /btw vs /side semantics for detached side questions during active runs
• gateway: queue inbound messages per session instead of overwriting latest pending message #3505 — queue inbound messages per session instead of overwriting latest pending message
• docs(readme): add troubleshooting section #145 — Mid-turn steering: accept user messages while agent is working
• Telegram output #263 / Add codex app-server ChatGPT OAuth provider path #265 / similar queue-interrupt UX issues

Acceptance Criteria

• optional and default off
• disabled state preserves current behavior
• router runs only when Hermes is actually busy
• tiny routing context only (not full transcript)
• deterministic fallbacks on timeout / invalid output
• v1 executable actions are only interrupt, queue, ignore
• gateway busy acknowledgement becomes action-accurate and less awkward
• implementation covers both gateway busy-message interception paths
• tests cover race conditions, media events, duplicate rapid messages, and disabled parity

Notes

A local implementation plan already exists and has been independently reviewed:

• .hermes/plans/2026-04-17_140900-micro-interrupt-router.md

This issue is intended as the product/architecture umbrella so the implementation can land cleanly and link to the fragmented queue/background/btw UX issues instead of adding another isolated fix.