Hermes Agent Streaming: Set Up Streams And Stall Caps (2026)

Hermes agent streaming is three separate things: tokens rendering in your terminal, replies editing live in chat apps, and a stack of timers that kill and retry a stream when the provider stalls.

On 1 November 2026 a fourth piece landed on main: an opt-in cap called agent.stream_max_lifetime that cuts a stream which keeps sending data but never finishes.

Below is the exact order I set it all up in, with the config keys copied from the docs and the traps that catch people.

If you want my team to look at where an always-on agent fits your business, book a free SEO strategy session.

What "Streaming" Means In Hermes: Three Separate Switches

Most confusion comes from mixing up three keys that sound alike.

display.streaming only controls how tokens render in the terminal.

streaming.enabled controls progressive message edits on messaging platforms.

model.streaming controls whether Hermes sends streaming requests to the provider at all.

The official configuration docs keep these apart, and so should you.

Turning off terminal rendering doesn't stop the wire request from streaming, and that matters, because the stall detection only works on a streaming request.

Step 1: Turn On Token Streaming In The Terminal

Open ~/.hermes/config.yaml and set the display block.

display:
  streaming: true         # Stream tokens to terminal in real-time
  show_reasoning: true    # Also stream reasoning/thinking tokens (optional)

Replies now appear token by token inside a streaming box.

Tool calls are still captured silently, so you won't see raw tool JSON scroll past.

If your provider doesn't support streaming, Hermes falls back to the normal display on its own.

I leave show_reasoning on while I'm tuning a setup and switch it off once I trust the model.

Step 2: Turn On Gateway Streaming For Telegram, Discord And Slack

The gateway block is off by default, so nothing streams in chat apps until you flip it.

streaming:
  enabled: true           # Enable progressive message editing (default: false)
  transport: auto         # "auto" (default) | "edit" (progressive message editing) | "off"
  edit_interval: 0.8      # Seconds between message edits (default: 0.8)
  buffer_threshold: 24    # Characters before forcing an edit flush (default: 24)
  cursor: " ▉"            # Cursor shown during streaming
  fresh_final_after_seconds: 0    # Opt in to fresh final (Telegram) when preview is this old

With this on, the bot posts a message on the first token and keeps editing it as more text arrives.

Signal, Email and Home Assistant can't edit messages, so Hermes detects that on the first attempt and quietly disables streaming for that session.

Long replies are handled too: past roughly 4,096 characters the current message is finalised and a new one starts.

Step 3: Fix The Discord Default Before You Test

This is the trap I see most.

Once the master switch is on, streaming is decided per platform.

Telegram ships with display.platforms.telegram.streaming: true, so it streams straight away.

Discord ships with display.platforms.discord.streaming: false, so it keeps sending whole messages.

Flip it from the dashboard's Channels toggles, or from the CLI with the canonical path the docs give.

hermes config set display.platforms.discord.streaming true

If you also want separate mid-turn updates without live token edits, set display.interim_assistant_messages: true.

🔥 Want a Hermes agent streaming setup that's already tuned? Inside the AI Profit Boardroom you get step-by-step video trainings, the installable Agent OS with Hermes wired in, four coaching calls a week and 3,400+ members running agents in Telegram, Discord and Slack. → Join the AI Profit Boardroom

The Timers That Watch Every Stream

Hermes runs several timeout layers at once, listed in the API timeouts section.

Timer	Default	Local providers	Where you set it
Socket read timeout	120s	Auto-raised to 1800s	`HERMES_STREAM_READ_TIMEOUT`
Stale stream detection	180s	900s ceiling	`HERMES_STREAM_STALE_TIMEOUT`, local: `agent.local_stream_stale_timeout`
Stream max lifetime	Off (0)	Same	`agent.stream_max_lifetime`
Responses first-event watchdog	120s	900s ceiling	`HERMES_CODEX_TTFB_TIMEOUT_SECONDS`
Post-terminal drain (Codex/Responses)	2s	Unchanged	`agent.stream_drain_timeout`

The socket read timeout is how long the HTTP client waits for the next chunk.

Local models can spend minutes on prefill, which is why Hermes raises it to 30 minutes when it detects a local endpoint.

An explicit HERMES_STREAM_READ_TIMEOUT always wins over that detection.

How A Stalled Stream Gets Killed And Retried

The stale detector watches for a connection that receives SSE keep-alive pings but no real content.

At the 180-second default it kills that connection.

The docs add implicit tiers on top of the default: 240 seconds above 50k tokens of context and 300 seconds above 100k, plus floors for reasoning models.

Those tiers only apply to the 180-second default.

Set providers.<id>.stale_timeout_seconds and the value is used as-is, so you can shorten how long a hung stream is tolerated.

For transient network errors, the environment variable reference lists HERMES_STREAM_RETRIES, three mid-stream reconnect attempts by default.

If part of the reply already reached you before the cut, the partial-response continuation takes over rather than a plain retry.

The Circuit Breaker That Stops Re-Waiting: HERMES_STREAM_STALE_GIVEUP

Retrying a dead provider forever wastes your whole afternoon.

HERMES_STREAM_STALE_GIVEUP is a cross-turn breaker: after five consecutive stale kills with no completed response, each call aborts at once with an actionable error.

It resets on any completed response, a /model switch, fallback activation, or the primary being restored at turn start.

Set it to 0 to disable it.

I leave it at five, because it's the thing that turns a silent hang into a message telling me to switch models.

Step 4: Add The New stream_max_lifetime Cap

Here's the gap the new setting closes.

The stale detector resets on every chunk, so a gateway trickling chunks or a runaway generation never trips it, and the turn just sits there.

Commit ac8037c05b, authored 31 October and merged to main on 1 November 2026, adds a wall-clock cap that never resets on chunk arrival.

It isn't in a tagged release yet; the latest tag is v0.22.5, so you need to run from main or wait for the next release.

Set it in config.yaml, in seconds.

agent:
  stream_max_lifetime: 600   # seconds; 0 (the default) = off

There's no environment variable for it any more: follow-up b484be5610 removed HERMES_STREAM_MAX_LIFETIME because behaviour settings belong in config.yaml.

When the cap trips, the connection is killed the same way a stale kill is, and the retry or the partial-response continuation takes over.

Each retry attempt gets a fresh clock.

How To Pick A Cap Value

Start from your longest healthy reply, not from a round number.

The cap never fires before the effective stale-stream timeout, so anything you set below 180 seconds behaves as 180 at the default.

The project's own test shows it: a 60-second cap with a 180-second stale timeout resolves to 180.

If you run long reasoning turns that legitimately stream for ages, the docs say leave it at 0.

My rule: chat bots that answer customers get a cap, research agents that think for a long time don't.

For a customer-facing bot I'd start at ten minutes, watch agent.log for a week, then tighten it.

Since 18d6041890, a stale kill also restarts the cap clock, so the two timers never double-count the same silent window.

📞 Not sure which of your agents should have a hard stop? Book a free SEO strategy session and my team will look at what you run and where an agent actually saves you time. → Get your free strategy session

Which Streams The Cap Ignores

The cap covers Chat Completions and Anthropic Messages streams only.

Codex/Responses streams (codex_responses, including custom providers declared with the Responses transport) are not capped.

Bedrock streams aren't capped either.

If your main model runs over the Responses transport, the cap does nothing for you, and the 120-second first-event watchdog plus the 2-second post-terminal drain are your guards instead.

Step 5: Read agent.log When A Stream Gets Cut

A cut used to look like a broken provider.

Follow-up eee418e089 fixed that: the error now reads "Response still streaming after Ns, cut by agent.stream_max_lifetime" and names the setting to raise.

The same commit stopped cap kills from feeding the stale breaker, because two capped long replies used to latch HERMES_STREAM_STALE_GIVEUP and block the next healthy request.

Another follow-up logs the armed stale and cap values at debug level, so agent.log shows which limits a call ran under.

And c552db90bc gives up on a worker the cap can't unwind, so a turn can't be re-cut every window forever.

The Escape Hatch: model.streaming false

Some self-hosted OpenAI-compatible servers break on streaming tool calls.

The docs' example is vLLM with a particular tool-call parser and a reasoning parser leaking tool-call markup into plain text.

For that class of bug only, force non-streaming requests.

model:
  streaming: false

Know the price: non-streaming calls lose the liveness checks above.

Hermes also switches a session to non-streaming by itself if a gateway answers with a contentless SSE frame, shows a warning, and keeps streaming off for that session.

Step 6: Watch Streams With The Observer Hooks

If you want a log of every streamed reply, the Hermes hooks docs list four observer-only plugin hooks.

on_stream_start fires when a streaming response begins and carries identifiers and routing metadata only.

on_stream_delta fires per text delta, with a kind of text or reasoning.

on_stream_end fires after the stream closes, with the final text, a finished flag and any error.

on_interim_message fires when a mid-loop assistant message surfaces before the final answer.

Each callback gets its own bounded queue and worker, so a slow plugin drops its own oldest events and never delays the turn.

Reasoning deltas stay hidden from plugins until you opt in.

plugins:
  stream_reasoning_deltas: true

Return values are ignored, so keep callbacks quick: enqueue the work and return.

Pair on_stream_end with the cap and you get a clean record of which replies were cut and which finished.

Local Models: Raise The Ceiling, Not The Cap

Ollama, oMLX and llama-cpp behave differently from hosted APIs.

They send no keep-alive pings during prefill, so a fixed 180-second stale window would kill healthy work.

Hermes swaps in a finite 900-second ceiling instead, set with agent.local_stream_stale_timeout.

Because the cap is floored at the effective stale timeout, a local endpoint at that ceiling never gets cut before 900 seconds.

Tune the local ceiling first, then decide whether a cap adds anything.

Gotchas I'd Check Before Going Live

Discord won't stream until you flip its per-platform toggle.
A cap below the stale timeout is silently raised to the stale timeout.
The cap is on main only, not in v0.22.5.
Responses-transport and Bedrock models are never capped.
Silence notices only appear after 60 seconds of quiet, so a short pause is normal.
Scheduled runs stream too.

That last one matters if you run jobs overnight.

Cron jobs and delegated subagents send stream: true on their own thread, so the stale budget governs them; my Hermes agent cron job setup guide covers the scheduling side.

Want the full Agent OS with all of this pre-wired? Join the AI Profit Boardroom.

🔥 Get the agent configs I'd copy for a live chat bot Inside the AI Profit Boardroom you get step-by-step video trainings, the installable Agent OS, four coaching calls a week and 3,400+ members comparing their gateway settings. → Join the AI Profit Boardroom

Also On Our Network

FAQ: Hermes Agent Streaming

Why doesn't my Hermes bot stream on Discord?

After you turn on streaming.enabled, Discord still ships with display.platforms.discord.streaming set to false. Flip that toggle and it streams.

Can I set stream_max_lifetime with an environment variable?

No. Commit b484be5610 removed HERMES_STREAM_MAX_LIFETIME, so agent.stream_max_lifetime in config.yaml is the only way.

What happens if I set the cap to 30 seconds?

It never fires before the effective stale-stream timeout, so at the 180-second default the cap behaves as 180 seconds.

Does a capped stream trip the stale circuit breaker?

No. Since commit eee418e089 a cap kill is never counted toward HERMES_STREAM_STALE_GIVEUP, because the provider was still responding.

Is stream_max_lifetime in the latest Hermes release?

Not yet. It merged to main on 1 November 2026, after the v0.22.5 tag, so run from main or wait for the next release.

📺 Video notes + links to the tools 👉

🎥 Learn how I make these videos 👉

🆓 Get a FREE AI Course + Community + 1,000 AI Agents 👉

About Julian

I'm Julian Goldie, an SEO entrepreneur, author and founder of the AI Profit Boardroom, which has 3,400+ members.

I help business owners scale with AI agents, automation and SEO.

I've built a 7-figure SEO and link building agency, Goldie Agency, with a team of 70+ SEO experts.
I've grown a YouTube channel to 400,000+ subscribers.
I wrote "Link Building Mastery".
My Udemy courses have taught over 29,000 students.

→ Get my best AI training inside the AI Profit Boardroom

Set the display block, fix the Discord toggle, add a cap only where replies should end, and if you want my team to map which agents deserve one, book a free strategy session and bring your Hermes agent streaming config.