[Bug]: Empty final response after tool calls can hit unbound assistant_msg path

[zhou-shiliu]

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.

[alt-glitch]

Likely regression of the fix in #11021 (merged) — same assistant_msg unbound variable in post-tool empty response nudge path. See also #10435 (closed earlier attempt).

[Gyanesh5]

The latest version I am using is 0.12.0, and the model is GLM-5-TURBO, but I still encounter similar issues.

[konsisumer]

Thanks for the report. The fix from #11021 is still in place on main (the post-tool nudge path now builds a fresh _nudge_msg via _build_assistant_message(...) at run_agent.py:13757 rather than reusing assistant_msg), and I couldn't spot another path where assistant_msg is read before assignment. To confirm whether this is a regression or a different empty-response code path, could you share:

1. The full Python traceback for the UnboundLocalError (file + line number where it actually fires) — the message in the issue is the exception's args[0], but the traceback is what tells us which path hit it.
2. Exact Hermes version: hermes --version (or pip show hermes-agent). fix: empty response nudge crash + placeholder leak to cron targets #11021 merged on 2026-04-16; if you're on an older build the fix may not be present.
3. The provider config you're using — gpt-5.4 isn't a model id we recognize. A redacted snippet of the relevant custom_providers entry (api mode, base URL host, any custom transport flags) is enough.
4. Whether you can still reproduce on the latest release with the same prompt/tool sequence.
5. If possible, the session log or a redacted transcript of the conversation up to the failure (just enough to see the tool calls and the immediate post-tool turn) — this would let us identify which specific recovery branch is being entered.

@Gyanesh5 if your repro on 0.12.0 / GLM-5-TURBO surfaces a different traceback or a different recovery branch, please open a separate issue with the same details — combining two repros under one ticket has historically made these harder to pin down.

[metatron-sudo]

Just updated to Hermes Agent v0.15.1 (2026.5.29)

• Model: minimax/minimax-m2.7 via openrouter
• Symptom: (empty) after 3-4 tool calls in multi-step tasks
• Additional context: Issue [Bug]: model.max_tokens in config.yaml has no effect — setting is never passed to AIAgent #4404 (max_tokens not forwarded) may be the root cause for this provider/model combination

[FedeCuci]

I'm having the same issue

[teknium1]

This was fixed in commit 8575279 and shipped in v2026.4.16. Automated hermes-sweeper review.

• The UnboundLocalError: cannot access local variable 'assistant_msg' in the post-tool empty-response nudge path was directly addressed in 85752791e.
• The fix replaces the bare assistant_msg["content"] = "(empty)" reference (which was only assigned in the tool-calls branch) with _nudge_msg = self._build_assistant_message(assistant_message, finish_reason), eliminating the unbound variable.
• Verified on current main: run_agent.py lines 13414–13416 show the corrected _nudge_msg pattern.
• The fix commit message explicitly references the regression @alt-glitch noted in the comments (same nudge path, same variable).

Thanks for the detailed report and for @alt-glitch's quick triage linking the prior context.