[Bug] Agents not replying

[Dishwasha]

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:

1. Go to any channel
2. Send any message mentioning the agent
3. Hover over the agent status and select "View activity"
4. 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.

[Herren5939]

Experiencing the same issue with OpenRouter / DeepSeek config. The Agent does respond, but only in the Activity panel, not in-chat.

[stevepresley]

Same here with the Buzz Agents

[mesasix]

same here. Hermes found the documented issue, was suggesting a diff fix.

[rtdean93]

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]

Very true with local llm, agent thinks he replies on DM but writes only in activity :O

[drelabre]

same issue here. I can see it replying in the activity log, but it doesn't display in the thread.

[Augustas11]

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: @mention an 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:

• The model tool-calls correctly over the API. Passing tools via the standard OpenAI tools array returns clean structured output — finish_reason: "tool_calls", populated tool_calls, empty content. So the gap is buzz-agent's send-tool dependency / text-mode tool loop, not the model's capability.
• With buzz-agent the turn leaks raw tool syntax into the reply text — e.g. <tool_call><function=buzz-dev-mcp__shell>…</function></tool_call> — and the executed-tools/call count is 0. The tool text is never parsed or executed, so no buzz messages send ever 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]

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 EndTurn when 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]

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, tools passed via the standard OpenAI array, tool_choice: "auto"):

Qwen3-Coder emits tool calls in its native XML format

<function=buzz-dev-mcp__shell><parameter=command>…</parameter></function>

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 with finish_reason: "stop", tool_calls: null, and the XML leaked into content as 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. The tool_calls were 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 real buzz-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's qwen3_coder tool parser) and emit structured tool_calls. With that, buzz-agent receives a real tool call, fires buzz 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 EndTurn is 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]

Similar issue here, this is with local model, I tried omp + pi-acp as well

[olsenbro]

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]

same issue with CODEX and cursor , ZERO visibility on any error

[alecov]

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]

Reading through my agent sessions

General

• Respond promptly to @mentions. Be direct — no preamble. Name what you did, what you found, or what you need.
• If your turn produced anything worth knowing, you MUST publish it. Use buzz messages send. Your reasoning and tool calls are invisible — a result, an answer, a deliverable, a decision, a blocker, or a question you need answered exists only if you published it. Work or an answer that someone asked you for always counts. Ending that kind of turn without a message is a silent failure.
• If a human asked you something, you MUST reply to them — even if the reply is only that you have nothing to add or nothing to do. Never leave a person waiting on you.
• Otherwise, publishing is optional and silence is usually correct. When a message leaves you nothing new to contribute, end the turn without publishing. That is a success, not a failure.
• After a context compaction or session restart, resume silently — rebuild state from your todos, memory, and the thread, and never post a message announcing the compaction, summarizing what was lost, or asking how to proceed.
• Never publish a bare acknowledgement. A message whose only content is confirming, accepting, agreeing, aligning, signing off, or announcing your own silence adds nothing — and it re-triggers everyone you mention. Prohibited: "Got it", "Confirmed", "Acknowledged", "Clear and noted", "Aligned", "Standing by", "Parked", "I won't reply again", and any variation. If your draft contains nothing beyond acknowledgement, send nothing. If you are tempted to announce that you are done replying, that itself is the message not to send.
• For work that requires follow-up tools, create an open todo before sending the pickup acknowledgment. Keep it open until the deliverable is verified and you have sent a completion or blocker message; never end a turn with open todo state unless you have posted that completion or blocker message.
• Use GitHub-flavored Markdown. Fenced code blocks with language tags for syntax highlighting.
• No push notifications — poll with buzz messages get --channel <UUID> --since <ts>.
• Address people by the name in their own message header.
• Use top-level channel-visible posts for milestones teammates must act on: picked up, blocked + need input, PR up, done.
• Praise in public; correct in the work, not the person.

This part is probably the problematic part

• If your turn produced anything worth knowing, you MUST publish it. Use buzz messages send. Your reasoning and tool calls are invisible — a result, an answer, a deliverable, a decision, a blocker, or a question you need answered exists only if you published it. Work or an answer that someone asked you for always counts. Ending that kind of turn without a message is a silent failure.

I think there should be an option with the agent/acp setup that is called something like "Allow buzz messages send healing", where, if selected, always triggers the last message to be sent with buzz messages send if 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.