Environment - Traycer host: 1.1.7, Windows x64 - Bundled Claude Code: 2.1.214 - Model:

claude-haiku-4-5-20251001

- Haiku runs with thinking disabled - Traycer A2A MCP server is authenticated and configured with

alwaysLoad: true

Impact Haiku currently cannot be used reliably as a Traycer child. It generates the requested answer, but the parent never receives it automatically. Reproduced in 3/3 fresh sessions. Actual behavior 1. Parent sends a message with

expectReply: true

. 2. The child receives an explicit instruction to call

traycer_send_message

with the supplied

responseId

. 3. Haiku generates correct terminal text, then returns

end_turn

without making a tool call. 4. Traycer leaves the response thread open and emits “finished its turn without replying.” 5. The answer is only recoverable by manually reading the child transcript. Expected behavior The generated answer should reach the parent and complete the response thread exactly once. Control A Sonnet High child using the same workspace, provider profile and A2A transport correctly called

mcp__traycer_a2a__traycer_send_message

and delivered its answer. Reproduction IDs - Haiku: agent

3106a155-6cac-4db6-b189-1b70e27a9118

- Response:

bb6258f2-47e5-4528-8fd8-d8d967f40fcc

- Provider session:

269c543e-0af3-43e4-b175-20f09e38d2bd

- Haiku: agent

91cc07eb-1bbb-4132-b027-7154a3aaaa0f

- Response:

92b406df-2480-4698-a8a7-aace88028e04

- Provider session:

528fc1f7-49d7-4a27-bcfc-7a9f294e42d6

- Haiku: agent

83094862-3f73-492f-9395-ed3a453aa6e9

- Response:

e0cad8ab-a4f7-40db-a016-a1906d257314

- Provider session:

8d3db9d5-e378-489b-8b54-9eb3cf1341bd

- Successful Sonnet control: agent

9ce62cb8-121a-4f69-85d1-51094181f603

- Response:

3028b59b-5e7e-432c-a833-6c3edbf947bd

- Provider session:

8c34f841-dd40-4841-a202-5de21afda470

Suggested fix At successful child-turn finalization, if an

expectReply: true

thread is still open: 1. Atomically check whether

traycer_send_message

already completed it. 2. If not, and non-empty terminal assistant text exists, deliver that text as the reply. 3. Record the delivery mode as

terminal-text-fallback

. 4. Ensure a concurrent or late tool reply cannot create a duplicate. 5. Retain the current inactivity/error behavior for empty, failed, stopped or cancelled turns. Acceptance criteria - Plain terminal child text completes the response thread once. - Normal reply-tool calls remain authoritative and create no fallback duplicate. - Tool-call/finalization races always produce exactly one reply. - A tool reply followed by a terminal acknowledgement does not send twice. - Empty/error/stopped/cancelled turns do not fabricate replies. - Joined messages sharing one response thread still complete atomically. - Three fresh Haiku children deliver 3/3 replies without transcript recovery. - Sonnet and another existing child route continue working without duplicates. I can provide the host-log excerpts and Claude session JSONL files if needed.

Thank you for highlighting this issue and providing a detailed bug report. This information will help us quickly identify the root cause and implement a fix sooner.

Amazing product! You guys rock 🙂

No, it was not part of the release. This is a very model-specific issue where only Haiku is failing to follow the instructions which all the other models are able to follow correctly. We are experimenting a few things around the instructions so that it works on all models.

Would be awesome if we can troubleshoot that. I use Haiku for very low effort tasks and it would be awesome, if traycer could utilize this

Hey are we sure that this is only a haiku-specific issue? I think it is some bug in Claude Code as well because I see a lot of subagents terminating silently without returning back a message. I'm not sure. It could be user-specific setup thing also. I did not have this issue for quite some time but the last month or so I have been experiencing this more frequently. I have started tightening up my instructions file but it is probably worth a look to rule out traycer-specific issues.

@melodic-gigabyte-32016 The bug reported here affects Traycer-launched agents via A2A communication. Claude native subagent termination is a separate Claude-specific issue, not related to this.

Ah My bad

@proud-printer-9482 Quick update from my side — I re-ran the Haiku A2A repro today and it no longer reproduces. Fresh Haiku children now call traycer_send_message themselves and close the response thread normally: • 8/8 successful replies (was 0/3 on 24 Jul) • Verified at provider-event level — each run shows a real tool_use block calling the reply tool, so this is genuine model compliance, not terminal text being surfaced some other way • Covered trivial probes, realistic tool-using packets, a 5-step multi-tool packet, and one packet with no "report back" instruction at all (the envelope alone was enough) Two things changed on my machine between the failing and passing runs, and I can't tell from here which one did it: • Traycer host 1.1.7 → 1.1.8 (installed today 11:41 UTC, ~35 min before the first passing test) • Bundled Claude Code 2.1.214 → 2.1.220 One request either way: the exactly-once terminal-text fallback from my original report is still worth having. This fix arrived via a version bump, so without host-side resilience the same class of failure can return with any future harness release. Separately — while testing across harnesses I hit two Copilot issues that look unrelated to the Haiku ticket: 1. Copilot children can't reply to their parent at all, on any model. The A2A tools aren't injected into Copilot child agents — the tool simply isn't there. A Sonnet-5 control failed identically and listed its own tools: powershell, read_powershell, stop_powershell, list_powershell, view, create, edit, web_fetch, skill, ask_user, sql, read_agent, list_agents, write_agent, grep, glob — no traycer_send_message. Prompting can't work around it; I sent an explicit follow-up telling it to load the tool via ToolSearch and it still couldn't. Effectively Copilot is unusable for delegated child work right now. 2. Copilot's model list advertises a param the API rejects. claude-haiku-4.5 is listed with reasoningEffort: low|medium|high|xhigh, but creating that agent dies at session start: Failed to start Copilot: Model 'claude-haiku-4.5' does not support reasoning effort configuration. So a valid-looking agent creation fails before its first turn.