Installing pi-subagents took 6 seconds in our sandbox. Getting a finished test result was another matter: the command reached our 900-second timeout without a final suite result. For an extension that coordinates other agents, that leaves a consequential question unanswered: does work reliably finish and return control on the host you intend to use?
pi-subagents adds child sessions to the Pi coding agent. You can ask a reviewer to inspect a diff or a scout to trace an unfamiliar codebase, then bring their findings back into the parent conversation. The reason to consider it is the separation of those jobs. Our run does not establish that several agents produce better code than one.
Child sessions can continue after the parent gets control back
The README distinguishes foreground sessions inside the parent Pi process from background sessions in a detached runner. Foreground work streams into the conversation. Background work keeps running after control returns, with a FleetView and inspector for checking transcripts, steering a child or stopping a run.
That makes the extension relevant when waiting for a review would otherwise occupy your coding session. It also makes result delivery part of the product's value. A child that produces a useful answer but leaves the parent waiting still needs operator attention. We did not measure that workflow in a model-backed session, so the documented inspector is a capability to evaluate rather than evidence of reliability.
The built-in roles have useful boundaries. Reviewer is documented as read-only, while worker edits files and validates its work. Oracle challenges a plan without editing. Researcher and evidence-auditor require pi-web-access in the child. Installing this extension alone therefore does not establish that its research roles have working web access.
What happened when we ran it
Our October 26, 2026 sandbox run installed pi-subagents at commit d9c5ca2 in 6 seconds, recording 138 dependencies and a 226 MB installed footprint. The checkout was 15.3 MB, with 859 files and approximately 264,378 source lines. No build script or target was available, so the build step was skipped.
The test command timed out after 900 seconds. Its supplied tail shows the extension maintenance lifecycle suite passing, including a check that starts session-owned maintenance and cleans it at shutdown. There is no final result for the entire command in that tail. We cannot turn its last visible success into a passing full suite, assign an overall passing-test count or identify what kept the command alive.
The npm audit reported 0 known vulnerabilities. That result describes this dependency scan, without proving that permission handling, child coordination or model-driven edits are safe. The recorded signals include two CI workflow files and a tests directory, with no Dockerfile. Those files show that checks exist, while our timed-out command leaves their complete result unresolved.
The configuration specifies 3 CPUs, 8 GB RAM and image lab-node:22. It does not establish the actual Node or operating-system version. Our measurements also provide no model-call cost, task completion benchmark or comparison with a single agent. The small installed footprint is useful setup evidence for this checkout, not a budget for the work its children might do.
Standalone support has a specific host boundary
pi-subagents requires Pi 1.2.0 or newer. The README says npm Pi uses a detached Node runner, while the official Pi 1.2.0 Linux x64 standalone release uses Pi's embedded SDK. Those are distinct host routes, so knowing only which extension package you installed is insufficient to establish background compatibility.
The standalone documentation names official Pi 1.2.0 on Linux x64 as its fully validated standalone target. It calls Windows experimental and places other versions, systems, architectures and packagers outside that fully validated target. That is a reason to avoid treating a successful npm install as proof of support for an arbitrary standalone Pi executable.
You also need a working model-provider configuration in Pi. This is an extension to an existing agent host, so readers choosing their first coding assistant should compare hosts before choosing this orchestration layer. Our lab did not establish provider authentication, model availability or successful child requests.
A current Rex report warrants a targeted check
Issue 3079, updated October 26, reports a native Pi child starting in a local Rex tab but remaining blocked after its supervisor replies. The reporter names pi-subagents 0.83.0 and describes concatenated bridge commands. This concerns placed-child reply delivery, rather than a generic complaint about agent output quality.
The report is not our reproduction, and it does not explain our test timeout. Its practical implication is narrower: if your intended workflow uses Rex and supervisor questions, check a complete question-and-reply round trip before delegating a job that must wait for a decision. The repository's last push was October 26, and the same day's issue activity shows ongoing work and fresh reports. Calling the project abandoned would ignore both.
OpenCode and Claude Code are host alternatives
OpenCode includes build and plan agents plus a general subagent. Evaluate it when you are selecting a coding host and want those documented roles in that host. It is a different adoption path from adding an extension to an established Pi session, and we have no comparative speed or quality measurements.
Claude Code is a coding agent for terminal and IDE workflows. Its README also documents plugins with custom commands and agents. Consider it if that host fits your existing tools. If you already use Pi, start smaller: ask one read-only child for a bounded review, inspect its result and confirm that stopping or completing it returns control as expected.