Repository navigation
Ollama subagent executes tool calls correctly but always returns empty text to orchestrator #18423
Description
Description
When using an Ollama model as a subagent (via @agentname / task tool), the subagent executes tool calls correctly but its text response is always empty when returned to the orchestrator.
Tested with two different Ollama models — the issue is consistent across both.
Environment
- opencode version: 1.2.27
- OS: Windows 10
- Orchestrator model:
minimax-m2.5-free(cloud) - Hardware: Intel i7-6700T, NVIDIA RTX 3060 (12 GB VRAM), 32 GB RAM
Models tested
| Model | Size | Context | Plain text (no tools) | Text after tool call |
|---|---|---|---|---|
ollama/qwen3.5:9b |
6.6 GB | 32k | ✅ works | ❌ empty |
ollama/qwen2.5-coder:7b |
4.7 GB | 32k | ✅ works | ❌ empty |
nvidia/z-ai/glm4.7 |
cloud | 204k | ✅ works | ✅ works (but slow, ~3-8min) |
Behavior
Expected: subagent executes tools and returns a text summary to the orchestrator.
Actual: subagent executes tools correctly (files are written, bash commands run), but returns empty string to the orchestrator. The orchestrator receives no confirmation and must verify results manually.
Reproduction steps
- Configure a subagent in ~/.config/opencode/agents/coder.md with model: ollama/qwen3.5:9b or ollama/qwen2.5-coder:7b
- From a session using a cloud model as orchestrator, delegate: @coder create a file test.txt with content "hello"
- The file is created correctly on disk
- The orchestrator receives an empty return from the subagent
Key evidence
Plain text without tools works:
Task: "Say 'Hola, soy coder' without using any tools"
Result: "Hola, soy coder" ← correct
Text after tools is always empty:
Task: "Run echo 'test' and tell me what it returned"
→ bash tool executes correctly (output: "test")
→ subagent return to orchestrator: "" ← empty
The subagent session log (visible via ctrl+x) confirms the model DID generate a text response after the tool call ("El comando devolvió: test"). The text is lost between the subagent and the orchestrator.
Conclusion
The issue is NOT:
- The model failing to execute tools (it does)
- The model failing to generate text (it does, visible in subagent session log)
- Hardware/VRAM limitations (RTX 3060 with 12 GB VRAM, models fit entirely in GPU)
- Model-specific — reproduced consistently with both Qwen models tested
The issue appears to be that text generated by an Ollama model after tool calls is not captured or forwarded by opencode to the orchestrator.
Related issues
- Ollama: User message content arrives as empty array - model cannot see user input #5187 (Ollama user message arrives as empty array)
- Local Ollama tool calling either not calling or failing outright #1034 (Ollama tool calling not executing)
- Ollama (qwen2.5-coder): tool calls (edit/write) show as executed but no files are created/modified #7030 (Ollama tool calls show executed but files not created)
Plugins
No response
OpenCode version
OpenCode 1.2.27
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
Windows 10
Terminal
PowerShell 7
Activity
schell commentedon Mar 20, 2026
I'm seeing this as well and I'm on macOS 26.3.1.
ParthSareen commentedon Mar 20, 2026
Can you confirm this behavior with larger cloud models as well?
How much context length are you running at? Could you run
ollama psor check context length in the setting page for Ollama?pablohevia commentedon Mar 20, 2026
Tested with two different cloud orchestrators (minimax-m2.5-free and Nemotron 3 Super via OpenCode Zen) — the behavior is identical with both.
ollama ps output while subagent was active:
Note: coder.md has num_ctx: 16384 set, but Ollama is running at 32768 — the parameter doesn't seem to be passed through to Ollama.
ParthSareen commentedon Mar 20, 2026
@pablohevia 32k is still quite low for coding agents - especially for a 9b parameter model. Could you try one of the Ollama cloud models? I want to narrow down if it's just a small model issue or another issue on our end
https://docs.ollama.com/integrations/opencode
schell commentedon Mar 21, 2026
ParthSareen commentedon Mar 21, 2026
@schell I'll double check some of the qwen3/5 bits, but do you run into the same issue with a larger qwen3.5 variant? like the 27 or 35b?
schell commentedon Mar 21, 2026
I've never tried those and I'm not quite sure how to set them up.
schell commentedon Mar 21, 2026
I figured it out - it's pulling the 35b right now.
schell commentedon Mar 21, 2026
With
glm-4.7-flash:latesteverything works as expected. I'm still downloading a biggerqwenvariant.schell commentedon Mar 21, 2026
Just for more info, here's
ollama pswhile runningglm-4.7-flash:pablohevia commentedon Mar 21, 2026
Tested with
nvidia/z-ai/glm4.7(204k context) as the subagent — same behavior. The subagent session log confirms the model generates text after the tool call, but the orchestrator receives empty.This rules out context size as the root cause. The issue appears to be in how opencode captures and forwards subagent output to the orchestrator, regardless of model or context length.
Update: with nvidia/z-ai/glm4.7 (204k context), the subagent DID return text after the tool call — but after a ~8 minute delay.
supernovae commentedon May 4, 2026
I think this issue is related to #24090. In both cases the assistant message that comes back from a subagent loses fields during reconstruction. Here it drops the text field after a tool call, and in #24090 it drops the tool_calls field during history replay. The failure pattern is the same: everything works before the tool call, but the assistant message that should follow is partially empty once it passes through the subagent/orchestrator pipeline. That suggests a shared bug in the message reconstruction layer rather than model behavior.
github-actions commentedon Jul 5, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.