On 13 November 2026 OpenCode shipped v2.3.0. The release notes are short on marketing and long on the one change that actually moves the needle for anyone building multi-agent loops: subagents now return immediately, continue in the background, and report back whenever they become idle. The parent session receives a session ID at once and can keep issuing work or waiting on other results. When a child finishes (or goes idle while its own nested work is still running) it notifies the parent. The system explicitly avoids treating a partial idle as completion if background tasks remain.
That is the opposite of the blocking model most agent frameworks still ship by default. In the old shape you spawn a subagent, the parent blocks until the child returns a final answer, then you continue. With any non-trivial tool use or nested delegation the wall-clock time compounds and the parent session becomes a single point of serialization. Background-by-default flips the control flow: the parent remains a live coordinator.
From the changelog:
mcp_events flag.shell_timeout_background flag moves timed-out shell commands to the background instead of killing them.
The TUI also defaults to lower verbosity: each run of tool calls and thoughts collapses into one activity row. Set verbosity to medium or high if you need the full trace. The desktop app adds a jump-to-message command (Cmd+Alt+G / Ctrl+Alt+G) so you can search earlier prompts in the current session.
These are not speculative features. They are the defaults that change how you structure a session that launches multiple children.
Most production agent loops look roughly like this:
When step 3 blocks, the loop cannot overlap independent work. Background subagents let the parent issue several in parallel and continue reasoning or issuing more work while the children run. The idle-report protocol is the important part: it gives the parent a clear signal without forcing it to poll, and the “still running” case prevents the classic race where a parent acts on an incomplete result.
For CI or scripted runs the same change surfaces a gotcha. If a subagent starts a long-lived process (dev server, file watcher, or any tool that never naturally exits), the parent can hang waiting for an idle that never arrives. The release notes and follow-up commentary call this out. The practical fix is to treat those children as fire-and-forget or to give them an explicit timeout / completion criterion that the harness can observe.
OpenCode’s model is closer to a harness that owns the session lifetime than to a pure library you call from your own process. The parent session stays in the foreground; children are background sessions that share the same process and tool infrastructure. That gives you free concurrency without spinning extra OS processes for every agent, but it also means a hung or misbehaving child can still affect the shared environment (file locks, ports, GPU memory, etc.).
Compare that with a pure MCP-style or CDP-style isolation model (the kind Cloudflare’s Kitesurf or a dedicated browser-agent binary uses). Isolation is cleaner for untrusted or long-running work; the shared-session model is cheaper and faster for trusted local tooling. OpenCode chose the latter as the default and left the more isolated options as experimental flags or future work.
On Windows the process-daemon change for local shell commands is relevant if you are driving the agent from a long-lived desktop process. The daemon survives the parent session better and keeps output across handoffs. That matters when your outer loop is a Windows service, a tray app, or anything that restarts the OpenCode process without wanting to lose in-flight shell state.
Latency-wise the win is obvious for any workload that has independent sub-tasks. The cost is bookkeeping: you now have to handle the idle and “still running” events correctly, and you must decide what “done” means for each child. In a simple sequential agent the old blocking model was easier to reason about. In anything that looks like a real multi-agent or multi-tool loop, the background default removes a serialization tax you were previously paying for free.
If your outer system is already dealing with streaming audio, dual-track capture, or tight latency budgets (the usual Windows WASAPI + STT + overlay path), the same principle applies: keep the coordinator responsive. A parent that blocks on a long STT partial or a tool call that waits for network will miss the next speech segment or the next overlay update. Background subagents (or any equivalent async tool dispatch) let the parent stay in the critical path while the slower work happens elsewhere.
The OpenCode change does not magically solve capture latency or model TTFS. It does remove one more place where an agent framework forces you to serialize work that does not need to be serialized. That is the kind of incremental improvement that compounds when you are already fighting the Windows audio engine, DPC spikes, and network RTT.
A parent that launches two independent children now looks roughly like:
parent: issue subagent A (research task)
parent: issue subagent B (code generation)
parent: continue local reasoning or other tool calls
parent: receives idle report from A with final result
parent: receives idle report from B (or “still running” if B has nested work)
parent: decide next step or emit final answer
No explicit wait, no thread pool you have to manage yourself, and a defined protocol for “not done yet.”
That is the practical difference between a library that forces you to invent your own concurrency and a harness that ships the common case as the default.
OpenCode 2.3 is a small release on paper. For anyone who has watched a parent session sit idle while three subagents run sequentially, it is the change that finally matches the architecture you wanted.
I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.