Hermes Agent
Hermes cuts repeat billing for deterministic empty responses
A Hermes Agent patch says one empty answer cost about $2.33 because recovery resent the full context through repeated attempts. It proposes stopping after two identical zero-output responses and trimming the retry budget when one empty attempt crosses a configurable cost threshold.
NousResearch/hermes-agent PR #75115 is the inspected primary source: “fix(agent): stop re-billing deterministic empty responses (NS-503).” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- NousResearch/hermes-agent PR #75115 was created 2026-07-31T00:57:40Z and was open at inspection; its title is “fix(agent): stop re-billing deterministic empty responses (NS-503).” - NousResearch/hermes-agent issue #32827 was created 2026-05-26T21:38:53Z and was open at inspection; its title is “[bug] same_tool_failure_warning does not auto-escalate to block; allows unbounded retry-loop cost amplification.” - NousResearch/hermes-agent issue #31584 was created 2026-05-24T17:08:12Z and was open at inspection; its title is “[Feature]: Treat memory-context as background context, not authoritative user-message content.” - The repository reported 222881 stars, 25961 open issues, default branch main, and last push 2026-07-31T00:46:38Z. - The latest tagged-release baseline checked was v2026.7.30 published 2026-07-30T23:45:37Z.
What changed
NousResearch/hermes-agent PR #75115 reports: Problem (NS-503) A customer was charged ~$2.33 for a turn that produced **no answer**. Root cause: the empty-response recovery path retries up to 3 times and then walks the fallback chain, and **every attempt re-sends the full conversation input at full price**. On a large context, an unsignaled provider refusal (HTTP 200, zero output tokens, generic finish_reason) turns into 4+ full-price input bills for a single visible "(empty)". Signaled refusals (finish_reason="content_filter", Anthropic stop_reason="refusal", guardrail interventions) are already terminal today and never reach this loop — the uncovered class is the
NousResearch/hermes-agent issue #32827 reports: The same_tool_failure_warning mechanism (visible in tool_result content as [Tool loop warning: same_tool_failure_warning; count=N; has failed N times this turn....]) ▎ increments a counter but does not auto-block the task when N exceeds a reasonable threshold. The warning text actively encourages continued tool use ("Do not switch to text-only ▎ replies; keep using tools, but diagnose before retrying"), and frontier models often interpret this as license to retry the same failing call with minor argument tweaks. ▎ ▎ We observed two production loops driven by this: ▎ ▎ 1. MCP
NousResearch/hermes-agent issue #31584 reports: Problem or Use Case __NB: I had my agent write this request for me since the nitty-gritty details are a bit beyond my comprehension, but I do see this emerging as a point of confusion for agents and a potential threat surface if used maliciously (at least in my imagination). The fact that it's come up during normal use with my agent "thinking" I'm testing my own anti-prompt injection rules means that it might indeed be an issue worth investigating.__ Hermes currently injects ephemeral memory/provider context into the current turn's
Why it matters
A retry that repeats identical paid input without new evidence is not resilience; it is cost amplification. Empty-response handling needs a deterministic stop rule, a visible meter and a distinct fallback decision. This is an operator boundary: persisted state, execution ownership and visible controls must describe the same event. A workaround that broadens access, deletes state or hides the symptom would trade a visible defect for an unmeasured one.
Current
The primary record was open when captured on 2026-07-31. The release baseline was v2026.7.30 published 2026-07-30T23:45:37Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/NousResearch/hermes-agent/pull/75115. Supporting records are https://github.com/NousResearch/hermes-agent/issues/32827 and https://github.com/NousResearch/hermes-agent/issues/31584. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Verify usage metadata and signature stability before suppressing retries, keep unknown metering fail-open, and separately decide whether provider-side zero-output completions should be credited. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.