Hermes "possible upstream error or malformed SSE response"
This error is Hermes's zero-chunk guard, not a broken SSE parser. Hermes only recognises `choices` deltas and the standard error envelope, so providers that emit `error_type`/`error_message` SSE fields get swallowed and the stream looks empty. The hidden cause is usually context_length_exceeded. Retry without streaming to surface the real provider error, and shorten your context.
Likely cause
This is a zero-chunk guard in Hermes's streaming path, not a real SSE parsing failure. Hermes only understands `choices` deltas and the standard `{"error": {...}}` envelope, so providers that report failures as `error_type` / `error_message` SSE fields get dropped silently. With no content, no reasoning and no tool calls accumulated, the guard raises this RuntimeError and the actual upstream error never reaches you (issue #68451). The hidden error is very often `context_length_exceeded` — Hermes has auto-reduction logic for that, but it only runs when the error arrives as an HTTP exception, not when it is swallowed by the stream loop.
The fix
- 1 Re-send the same prompt with streaming disabled. If it succeeds or returns a readable provider error, the stream loop was hiding it and you now have the real message.
- 2 Assume context length first. Shorten the conversation, start a new session, or lower max_tokens, then retry — this is the most common error hiding behind the empty stream.
- 3 Check your provider's own dashboard or request logs for the failed request; the real status code and reason are recorded there even though Hermes dropped them.
- 4 If you are on a non-OpenAI-shaped endpoint (LLM gateways, proxies, self-hosted routers), point Hermes at the provider's native endpoint instead — non-standard SSE error shapes are what trigger the guard.
- 5 Update Hermes, then re-test; the stream error-handling path is actively being changed.
Hit a different error?
Paste any agent error and get the cause and fix in seconds.
Frequently asked questions
Is my provider actually sending malformed SSE?
Usually not. The message is Hermes's guess when it finishes a stream with zero chunks and no finish_reason. The provider most likely sent a perfectly valid error event in a shape Hermes doesn't parse.
Why does retrying sometimes work?
Because the underlying error is often context length. A retry that starts a fresh session sends a shorter prompt, which fits, so it succeeds — and the real cause stays hidden.
How is this different from 'Response truncated'?
Truncation means the model started generating and hit the output limit, so you get a partial answer. This error means nothing came back at all — zero chunks — so there is no partial output to salvage.
Stop firefighting agent errors
Decoding errors one at a time is the manual version of what BetterClaw automates. Run your OpenClaw agents hosted with managed models, retries and config validation built in.
Free plan available · Pro $49/mo · BYOK · 7-day money-back guarantee