Repository navigation
[Bug] Agents not replying #2421
Description
Describe the bug
When using an OpenAI compatible LLM provider, most agent mentioned messages do not generate replies. The only way I can see the response is in the agent activity log.
To Reproduce:
Steps to reproduce the behavior:
- Go to any channel
- Send any message mentioning the agent
- Hover over the agent status and select "View activity"
- See that the agent responds, but the message is never replied to.
Expected behavior:
The message should get a visible response from the agent
Supporting Material
Environment (please complete the following information):
- OS: Mac OS X
- Version 26.5.2, Buzz 0.4.22
Additional context
Add any other context that you feel is relevant about the problem here.
Reacted by Herren5939, Daniel Toubul, debuggerau and George J. Capnias
Reacted by debuggerau
Activity
Herren5939 commentedon Jul 25, 2026
Experiencing the same issue with OpenRouter / DeepSeek config. The Agent does respond, but only in the Activity panel, not in-chat.
stevepresley commentedon Jul 26, 2026
Same here with the Buzz Agents
mesasix commentedon Jul 28, 2026
same here. Hermes found the documented issue, was suggesting a diff fix.
rtdean93 commentedon Jul 28, 2026
Same issue with me on a local llm. I am using an open ai compatible endpoint with a qwen3.6 model. I can see the reasoning, but never the response.
The issue: buzz messages send accepts messages into the backend store even without --broadcast, so buzz messages get always showed them and the CLI always returned {"accepted":true} — making it look like delivery succeeded. But without --broadcast, the event never actually gets published to the Nostr relay network that Buzz Desktop listens to live, so nothing shows up in the app.
The fix — every agent must:
Always pass --broadcast on buzz messages send. No exceptions for DMs or channel posts.
Actually call the CLI. Do not just output reply text — that never reaches the relay at all (I made this mistake twice in this thread before catching it).
To @mention someone, put the literal @DisplayName in --content itself. The CLI parses that text and adds the p tag automatically — --reply-to only sets threading (e-tag), it does not create a mention.
Use --reply-to to keep replies threaded under the right conversation.
Minimal correct pattern:
buzz messages send --channel --broadcast --reply-to --content "@DisplayName your message here"
I have saved the --broadcast and @mention rules to my core memory so I will not repeat this. Worth flagging to whoever maintains the CLI/docs — --broadcast should probably default to true, or buzz --help should warn that omitting it silently fails to reach live clients.
realitymolder commentedon Jul 29, 2026
Very true with local llm, agent thinks he replies on DM but writes only in activity :O
drelabre commentedon Jul 30, 2026
same issue here. I can see it replying in the activity log, but it doesn't display in the thread.
Augustas11 commentedon Jul 30, 2026
Reproducing this cleanly with a self-hosted OpenAI-compatible provider — Malibu, a decentralized Apple-silicon inference network — on Buzz 0.4.22 / macOS, harness = Buzz Agent, model = Qwen3-Coder-30B.
Symptom is exactly as described:
@mentionan agent in a channel → the agent's reply shows up only in the Activity view and is never posted to the channel.Two data points that may help #3403 / #2681:
toolsvia the standard OpenAItoolsarray returns clean structured output —finish_reason: "tool_calls", populatedtool_calls, emptycontent. So the gap is buzz-agent's send-tool dependency / text-mode tool loop, not the model's capability.<tool_call><function=buzz-dev-mcp__shell>…</function></tool_call>— and the executed-tools/callcount is 0. The tool text is never parsed or executed, so nobuzz messages sendever fires and the reply is dropped from the channel. This lines up directly with the turn-text-publishing + sanitization that fix(acp,agent): support reasoning_content fallback and turn text publishing for local reasoning models #3403 adds.Happy to share logs. +1 for prioritizing #3403 — self-hosted / local-model support via buzz-agent is otherwise blocked by this.
Augustas11 commentedon Jul 30, 2026
Follow-up with a wire capture (self-hosted Malibu endpoint, Qwen3-Coder-30B, Buzz Agent harness). I put a logging proxy between buzz-agent and the endpoint to see exactly what's on the wire — it pins the failure firmly on the client side:
The request buzz-agent sends is well-formed:
stream: false,tool_choice: "auto", 6 tools (buzz-dev-mcp__{read_file,shell,str_replace,todo,view_image},load_skill). Notably there is no send/publish tool in the request.The failure is not the model — it's buzz-agent rejecting a valid completion. The turn ends with:
{"error": "No tool call found in response"}With
tool_choice: "auto", a model answering a plain "hello" with assistant text is a correct completion — it legitimately chose not to call a tool. buzz-agent treats "no tool_call" as an error and drops the reply instead of publishing the assistant text to the channel. Nothing in the provider response is malformed; the missing piece is purely buzz-acp's turn-text publishing.That's exactly what #3403 / #2681 close (accumulate and publish the turn text on
EndTurnwhen the model skips the send tool). Confirming from the wire that self-hosted OpenAI-compatible providers return correct responses and this is a buzz-acp gap. +1 to landing #3403.Augustas11 commentedon Jul 31, 2026
Correction to my two earlier comments. After more testing I need to walk back the "this is firmly on the client side / purely a buzz-acp gap" framing — that was wrong. The root cause in my repro is substantially provider-side (our own gateway), not buzz-agent. Correcting the record so it doesn't misdirect work.
What actually happens (Malibu gateway, Qwen3-Coder-30B,
toolspassed via the standard OpenAI array,tool_choice: "auto"):Qwen3-Coder emits tool calls in its native XML format
not the Hermes/Qwen2.5
<tool_call>{json}</tool_call>format. Our gateway's tool-call parser only recognized the latter, so when the model used its native<function>form the parser missed it: the response came back withfinish_reason: "stop",tool_calls: null, and the XML leaked intocontentas text.So buzz-agent's
{"error": "No tool call found in response"}was correct given what it received — the provider handed it assistant text, not a structured tool call. Thetool_callswere dropped one hop upstream, in our gateway, before buzz-agent ever saw them.Why my earlier "the model tool-calls correctly over the API" claim was misleading: that check used a simple tool where the model happened to emit the
<tool_call>{json}form (which our parser does handle →finish_reason: "tool_calls"). The realbuzz-dev-mcp__*tools triggered the<function>XML form (which it didn't). Same model, two output formats, only one parsed — I generalized from the wrong one.Fix (on our side): teach the provider's tool-call parser to handle Qwen3-Coder's native
<function>/<parameter>format (equivalent to vLLM/SGLang'sqwen3_codertool parser) and emit structuredtool_calls. With that, buzz-agent receives a real tool call, firesbuzz messages send, and the reply posts — no client change required.Where #3403 still genuinely helps: for turns where a model answers in plain text with no tool intent (e.g. a bare "hello"), accumulating and publishing the turn text on
EndTurnis a real robustness win and worth landing. It's a safety net for the text-only case, but it isn't the fix for the tool-call-leak case above — that one is provider-side.Apologies for the earlier misattribution.
NoRaincheck commentedon Aug 1, 2026
Similar issue here, this is with local model, I tried omp + pi-acp as well
olsenbro commentedon Aug 13, 2026
I'm reproducing this on macOS with a hosted communities.buzz.xyz relay. An agent receives the @mention and completes the task; I can see its generated output/activity in the Desktop status/activity UI, but the completed response frequently never becomes a persistent channel message. It reproduces with both Buzz Agent/MiniMax M2.7 and Claude Code/Sonnet, suggesting the failure is downstream of the model runtime. Local buzz-acp logs have also shown relay WebSocket timeout/reconnect events near failed turns. Simple replies sometimes publish successfully, while longer tool-using turns fail more frequently.
fborgherodbsagency commentedon Aug 20, 2026
same issue with CODEX and cursor , ZERO visibility on any error
alecov commentedon Sep 9, 2026
Perhaps the system prompt introduced by buzz-acp, the one that teaches the model how to send messages using buzz-cli, is too complex for most LLMs. I tried with multiple models, and all models I've tested miss sending messages ~50% of the time. Some models never send messages at all.
I had to explicitly instruct the model in its system prompt ("never forget about
buzz-cli") and "remind" it occasionally so it doesn't forget how to send messages.In some cases, a model responds twice: once in the thread, once in the activity tab, with completely different content.
This looks like a design bug to me -- general activity output should always go into the thread that triggered the bot, in the form of a reply, without need to force the model to route this through buzz-cli.
NoRaincheck commentedon Sep 21, 2026
Reading through my agent sessions
This part is probably the problematic part
I think there should be an option with the agent/acp setup that is called something like "Allow
buzz messages sendhealing", where, if selected, always triggers the last message to be sent withbuzz messages sendif a message is not detected. This will prevent the 'silent' errors and retain the current behaviour. It may mean that agents a 'too noisy' but at least its a configuration which allows users to choose to suit their needs.