Hermes "⚠️ No response from provider for 180s (model: ..., context: ~... tokens). Reconnecting..."

Why it happens

The stale-stream detector kills a stream that gets keep-alive pings or nothing at all but no actual tokens within the deadline. The default is 180s, raised to 240s above 50K tokens and 300s above 100K, with longer floors for known reasoning models.

1. A hosted provider accepted the request but queued it or stalled, so no tokens arrived for three minutes. Busy shared or free routes are the usual suspects.
2. Your model runs on a machine Hermes does not treat as local, such as a public hostname, a tunnel URL or a VPS. Loopback, private LAN, .local and Tailscale addresses get a 900s ceiling instead of 180s, but a public address gets the cloud default.
3. The endpoint is dead or wedged: the server crashed after accepting the connection, or a proxy holds the socket open without forwarding anything.
4. A slow thinking model on a large prompt took longer than the deadline to send its first token.

The fix

1. 1 Check the log line to see which model and context size were involved: grep -i 'stale' ~/.hermes/logs/agent.log ~/.hermes/logs/gateway.log.
2. 2 Confirm the endpoint is alive with a direct curl request to it. If it does not answer, restart the server or switch models with /model.
3. 3 If the provider is just slow, raise the deadline for that provider in ~/.hermes/config.yaml: providers: <id>: stale_timeout_seconds: 600 (or per model under providers.<id>.models.<model>.stale_timeout_seconds).
4. 4 Or raise it globally: add HERMES_STREAM_STALE_TIMEOUT=600 to ~/.hermes/.env. This only changes the 180s base; an explicit provider value always wins.
5. 5 For a self-hosted model on a public URL, prefer the per-provider setting so you do not slow failure detection for every other provider.
6. 6 Restart Hermes or run hermes gateway restart so the new values load.

Why fallback does not kick in right away

A stale kill is treated as a dropped connection, so Hermes reconnects to the same provider first. Cross-provider fallback (fallback_providers in config.yaml) engages after the retry budget, agent.api_max_retries (default 3), is spent. With the defaults that can mean several 180s waits before you see a switch.

To fail over faster, set agent.api_max_retries to 0 so the first transient failure on the primary hands off to your fallback. Separately, HERMES_STREAM_STALE_GIVEUP (default 5) aborts calls immediately once that many stale kills happen in a row with no completed response.

Issue #7230, which is often cited for this, is about fallback not firing on auth errors at credential resolution. It is closed and has nothing to do with timeouts.

Still failing?

• If the message shows 900s instead of 180s, Hermes already treats your endpoint as local, and the server is genuinely stuck rather than slow.
• If tokens normally stream but stop mid-answer, look for a proxy or load balancer with an idle timeout shorter than the model's thinking time.
• If every provider times out, check the machine's network and DNS, since the problem is not the provider.

Related errors

• Hermes "API call failed after 3 retries: Connection error."
• Hermes "provider failed after retries; check logs"