Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug]: Empty final response after tool calls can hit unbound assistant_msg path [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#17248•Fetched 2026-04-30 06:48:52
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
zhou-shiliuzhou-shiliu
Participants
alt-glitchalt-glitchzhou-shiliuzhou-shiliu
Timeline (top)
labeled ×3commented ×1cross-referenced ×1

Error Message

After successful tool calls, Hermes sometimes emits no assistant response at all in CLI chats. The terminal logs show retries with Model returned empty after tool calls, followed by an internal exception:

  • a clear structured error message Error during OpenAI-compatible API call #1: cannot access local variable 'assistant_msg' where it is not associated with a value
  • The error strongly suggests a response-construction code path where assistant_msg is referenced before assignment.

Fix Action

Fixed

PR fix notes

PR #17331: fix(agent): initialize assistant_msg before loop to prevent UnboundLocalError (#17248)

Description (problem / solution / changelog)

Summary

Fixes #17248 — UnboundLocalError: cannot access local variable 'assistant_msg' where it is not associated with a value during the agent main loop.

Root Cause

assistant_msg is only assigned inside conditional branches of the main loop (tool-call path at L12770, invalid-tool-names path at L12654, empty-exhausted path at L13117). If an exception occurs before any assignment on the first iteration — for example during _cap_delegate_task_calls() or _deduplicate_tool_calls() validation at L12763–12768 — the variable remains unbound. The outer except catches the error and continues, but the variable is never initialized.

On subsequent iterations or error paths that reference assistant_msg, Python raises UnboundLocalError because the name exists in the function's local scope (due to assignments elsewhere) but was never bound in this execution.

Fix

Initialize assistant_msg = None before the main loop, alongside the other per-run state variables (final_response, interrupted, api_call_count, etc.).

This is a zero-risk defensive guard:

  • The variable is always re-assigned on every successful API response
  • The None initialization only activates on exception paths where no assignment was reached
  • No behavioral change for any normal execution path

Testing

  • python3 -m py_compile run_agent.py passes
  • Change is a single line addition with no logic change

Changed files

  • run_agent.py (modified, +1/-0)

Code Example

Model returned empty after tool calls — nudging to continue
Error during OpenAI-compatible API call #1: cannot access local variable 'assistant_msg' where it is not associated with a value
Empty response from model — retrying (1/3)
Empty response from model — retrying (2/3)
Empty response from model — retrying (3/3)
Model returned no content after all retries. No fallback providers configured.
RAW_BUFFERClick to expand / collapse

Bug Description

After successful tool calls, Hermes sometimes emits no assistant response at all in CLI chats. The terminal logs show retries with Model returned empty after tool calls, followed by an internal exception:

cannot access local variable 'assistant_msg' where it is not associated with a value

From the user perspective, the agent appears to go silent mid-task even though the tools actually ran.

Steps to Reproduce

  1. Use Hermes in CLI chat mode with an OpenAI-compatible provider/model (observed on gpt-5.4 via custom provider).
  2. Run a multi-step task that includes several tool calls and then needs a natural-language wrap-up.
  3. Observe that tools succeed, but Hermes occasionally returns an empty final response.
  4. Hermes retries automatically, then still returns no content.

Expected Behavior

After tool calls complete, Hermes should always produce either:

  • a normal assistant message, or
  • a clear structured error message

It should not silently drop the reply or reference an uninitialized assistant_msg variable.

Actual Behavior

Observed log/output:

Model returned empty after tool calls — nudging to continue
Error during OpenAI-compatible API call #1: cannot access local variable 'assistant_msg' where it is not associated with a value
Empty response from model — retrying (1/3)
Empty response from model — retrying (2/3)
Empty response from model — retrying (3/3)
Model returned no content after all retries. No fallback providers configured.

Why this seems like a Hermes bug

  • Tool calls did execute successfully.
  • Failure happens when Hermes is trying to assemble/send the assistant reply after tool execution.
  • The error strongly suggests a response-construction code path where assistant_msg is referenced before assignment.

Environment

  • Platform: Hermes CLI
  • Model: gpt-5.4
  • Provider: custom OpenAI-compatible provider
  • Session type: normal chat with developer tools/tool calls
  • Date observed: 2026-04-29

Notes

A related symptom is that the agent may appear to "freeze" or "stop talking" mid-task, but the actual root issue seems to be empty-response handling after tool calls rather than tool execution itself.

extent analysis

TL;DR

The issue can be addressed by ensuring that the assistant_msg variable is properly initialized before it is referenced in the response construction code path.

Guidance

  • Review the code responsible for constructing the assistant reply after tool execution to ensure that assistant_msg is assigned a value before it is used.
  • Verify that the gpt-5.4 model via the custom OpenAI-compatible provider is correctly configured and functioning as expected.
  • Check the retry mechanism to ensure it is properly handling empty responses and not causing the assistant_msg variable to be uninitialized.
  • Consider adding error handling to provide a clear structured error message when the model returns an empty response.

Example

No code snippet can be provided without more context, but the fix likely involves initializing assistant_msg before referencing it, e.g., assistant_msg = "" or assistant_msg = None, depending on the expected value.

Notes

The root cause appears to be related to the response construction code path, but without more information about the code, it's difficult to provide a more specific solution. The custom OpenAI-compatible provider and gpt-5.4 model may also be contributing factors.

Recommendation

Apply a workaround by adding error handling to provide a clear structured error message when the model returns an empty response, as this will at least provide a better user experience while the root cause is being investigated.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#agent execution#callback error#memory management#API rate limit

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING