OpenCode Swarm
An architect-led coding swarm that verifies generated changes through independent review, testing, and security gates.
Per-dimension scores and reasoning
The evidence shows strong least-privilege engineering: read-only review roles, scoped writes, containment and symlink guards, external-skill curation and optimization disabled by default, and oversight for higher-risk actions. This justifies full credit for least_privilege. Confirmation and external-effect controls are substantial—destructive reset requires --confirm and Full-Auto routes ambiguous or risky actions through oversight—but installation changes global configuration and disables native agents, while auto-proceed can remove phase prompts; user_confirmation and external_effects therefore each lose one point. The README identifies .swarm state, telemetry, providers, PR monitoring, and network-sensitive actions, but does not provide a complete field inventory, retention policy, destination map, or privacy treatment, so data_flow_transparency loses one point. Secrets scanning, dependency audits, quarantine, and hash/provenance validation are present, but credential storage, log redaction, and incident handling are not documented; sensitive_data_handling loses one point. Dependency auditing is asserted and the shown GitHub Action is commit-pinned, but runtime dependencies mostly use ranges and the supplied evidence includes no lockfile, vulnerability-response policy, or update automation; dependency_security loses one point. Tested configuration backups and the optimizer's atomic activation/rollback support full credit for rollback. Repository and npm metadata identify the project and an MIT license is supplied, but the license has no named copyright holder and publisher identity remains unknown, so source_attribution loses one point.
The README, package metadata, and limited CLI tests generally describe one product, but the installation documentation directly conflicts: the first-run note says a missing project override is created, while Quick Start says the installer does not create project configuration. self_consistency is therefore limited to 1. Bun/Node requirements, OpenCode dependencies, an optional peer, model fallback, and cache-upgrade paths are documented, but no lockfile or comprehensive offline/degraded behavior for external services is shown, so dependency_availability loses one point. Tests demonstrate clear handling for missing flag values, malformed JSON, missing environment variables, and hangs, but they cover only the swarm-model helper rather than systematic failures across the main orchestration pipeline; failure_messages loses one point.
The source clearly addresses everyday development, rapid iteration, parallel execution, unattended operation, PR feedback, and multilingual projects, earning full credit for audience_and_scenarios. Core, optional, and conditional agents and the strict/balanced/fast, Turbo, and Full-Auto modes provide meaningful boundaries, but broad claims such as compatibility with every OpenCode-supported provider are not qualified in detail, so capability_boundaries loses one point. Slash commands, issue labels, configuration switches, conditional agents, and the active-architect requirement make activation conditions precise, earning full credit for trigger_precision. Bun and Node requirements, Linux/macOS/Windows cache layouts, 13 language profiles, 20 grammars, and provider formats support full credit for environment_fit.
The README has clear navigation and dedicated architecture, mode, command, agent, upgrade, and configuration sections, earning full credit for information_architecture. Installation requirements, npm fallback, first-run effects, and cache-aware upgrades are concrete, earning full credit for install_notes. A stated command registry as the source of truth plus canonical names and deprecated aliases supports full credit for naming_stability. Examples, a recording script, and configuration snippets are useful, but the supplied evidence lacks a complete FAQ and the illustrated demo outcome is asserted rather than statically demonstrated, so examples_and_faq loses one point. Cache behavior, mode safety differences, command conflicts, and pause conditions are disclosed, but there is no consolidated, comprehensive limitation register, so known_limitations loses one point. LICENSE and package metadata consistently specify MIT, earning full credit for license. A semantic package version, upgrade instructions, and deprecation compatibility are present, but no changelog or complete version-to-change history is supplied, so versioning_changelog loses one point. The repository is identified, but no named rights holder, maintainers, support path, security contact, or maintenance commitment is shown; maintenance_responsibility is limited to 1.
Status, plan, evidence, diagnosis, resumability, and structured feedback are designed for usable operational output, and configuration tests show preservation of nested fields and backups. The main workflow was not run, however, and the supplied static evidence does not validate every claimed gate artifact, so output_usability loses one point. Role separation, independent review, scoped mutation, resumable state, and provider routing offer plausible added value over a single-agent flow, but the competitor comparison is unsupported by accompanying evidence; marginal_value loses one point. Free-model support, configurable agents, serial fallback, and an explicit cost burn-in show cost awareness, but there are no latency, token, resource, or measured quality-benefit results, so cost_benefit loses one point.
Several capabilities are tied to concrete commands, configuration keys, source-file names, issue identifiers, and test labels, supporting good claim_traceability. Major promotional claims such as “6000+” tests, review/testing of every task, and competitor comparisons are not individually substantiated by the supplied files, so one point is deducted. Version, engines, license, scripts, and some helper behavior are corroborated across README, package metadata, and tests, but implementation and tests for the central orchestration, security gates, and much of the agent roster are absent from the evidence set; cross_source_corroboration loses one point. The source distinguishes defaults, opt-in features, and conditional roles and identifies live registries as sources of truth, but the storyboard and comparison table still present expected behavior as established fact; fact_inference_separation loses one point.
- Installation modifies global OpenCode plugin configuration and disables the native explore/general agents. Back up configuration and verify actual installer behavior, especially because the documentation conflicts on whether project configuration is created.
- Full-Auto, auto-proceed, automatic PR feedback, and parallel worktrees increase the automation blast radius. Enable them first in an isolated repository while retaining high-risk oversight and strict write scopes.
- Do not treat the README's “6000+ tests,” universal gates, or competitor table as independently established. The supplied tests cover only a limited swarm-model helper surface, not the core orchestration pipeline.
- Operation may send code or context to external model providers and may enable GitHub polling, telemetry, or external-skill discovery. Confirm data fields, destinations, retention, credential handling, and log-redaction policy before using sensitive code.
- Dependencies use version ranges and no lockfile evidence was supplied. Pin the deployment graph, produce an SBOM, and perform an independent vulnerability and supply-chain review before production use.
What does this agent do, and when should you use it?
OpenCode Swarm is an OpenCode plugin that divides a coding session among specialized roles for planning, implementation, review, testing, security, and documentation. A Swarm architect coordinates core and optional agents such as `coder`, `reviewer`, `test_engineer`, `critic`, `explorer`, and `sme`, enforcing gates at task and phase boundaries. The plugin inspects a repository, creates a phased plan, changes project files, runs builds and tests, and stores plans, evidence, context, and telemetry under `.swarm/`. Its local controls include Tree-sitter syntax validation, placeholder detection, offline SAST, dependency inventories, quality budgets, scoped write authority, and shell-write detection. It is a strong fit for OpenCode users who want a resumable and auditable engineering workflow, but adopters must accept an OpenCode-specific operating model, substantial configuration, filesystem permissions, and the cost of multiple model calls.
After a user gives the Swarm architect a development request, the architect can send explorer through the codebase and consult sme for domain guidance, then produce a phased plan for the critic gate. During execution, coder changes files; checks such as syntax_check, placeholder_scan, sast_scan, build_check, quality_budget, or pre_check_batch run; reviewer examines correctness and security; and test_engineer writes and executes tests. phase_complete revalidates the applicable gates against an exact locked snapshot of the plan, configuration, and evidence before committing the phase, while failures return structured feedback to the workflow. The plugin can also produce CycloneDX SBOMs, retain evidence in .swarm/evidence/, resume .swarm/ sessions, and inspect code with tools including diff, git_blame, symbols, and test_runner. Optional surfaces include a gh-based PR Monitor, external-skill curation, governed skill and harness optimizers, mutation testing, and higher automation modes; several require explicit configuration or human confirmation.
- An OpenCode team shipping production applications that wants generation, independent review, tests, and security checks enforced in one workflow.
- A maintainer of a long-running codebase who needs plans, task state, technical context, and verification evidence to survive across coding sessions.
- An engineering group changing authentication, cryptography, or session code that wants security-sensitive file patterns reviewed and coder writes confined to declared scope.
- A polyglot team working across TypeScript, Python, Go, Rust, Java, C/C++, C#, or other documented profiles that wants common syntax, build, and test orchestration.
- A GitHub-based team that wants implementation issues to produce evidence PRs through
swarm-implement.ymland optionally monitor PR checks, reviews, and conflicts. - An OpenCode user running unattended development who needs Full-Auto's deterministic permission policy and approval records from
critic_oversight.
What are this agent's strengths and limitations?
- Implementation, review, and testing are assigned to separate roles, with explicit task and phase gates instead of relying on a coding model to approve its own work.
- The plugin combines Tree-sitter parsing, 68 offline SAST rules, placeholder scanning, CycloneDX SBOM generation, quality budgets, and native project build checks.
- Write scope persists across processes and is protected with TTLs, realpath containment, symlink guards, and validation of array-based path arguments.
- Plans, context, evidence, and telemetry persist under
.swarm/, allowing interrupted projects to resume without repeating the entire discovery stage. - It documents 13 full language profiles and 20 Tree-sitter grammars, while model assignments can mix OpenCode, Anthropic, Google, Z.ai, MiniMax, and Kimi providers.
- The core product is an OpenCode plugin; no standalone deployment, embeddable library, or native ChatGPT, Codex, or Claude Code route is documented.
- Installation requires Bun 1.3.13 or newer, or Node.js 22.13 or newer for npm, and OpenCode's persistent package cache requires an explicit refresh and restart during upgrades.
- Separate planning, coding, review, and test roles can increase model traffic, latency, and paid-provider expense; the supplied material does not establish a complete cost benchmark.
- The configuration surface is broad, covering models, authority, gates, automation, context budgets, and optional systems. Selecting a non-Swarm architect bypasses the workflow entirely.
- Several capabilities are disabled by default or constrained: external-skill screening is regex-based and unsigned, mutation testing is opt-in, and some PR and optimizer operations require human confirmation.
- The supplied README is internally inconsistent about Context Budget Guard behavior: one section says it measures the full conversation and may enforce limits, while another says it measures only injected context and never blocks. Adopters should verify the effective configuration and runtime behavior.
How do you install or deploy this agent?
Install OpenCode and Bun 1.3.13 or newer, then run bunx opencode-swarm install. That command installs the package, registers the OpenCode plugin, writes ~/.config/opencode/opencode-swarm.json, and disables the potentially conflicting native explore and general agents. For npm, install Node.js 22.13 or newer and run npm install -g opencode-swarm && opencode-swarm install. The installer may create a missing project override; .opencode/opencode-swarm.json can also be created manually when project-specific settings are needed. Credentials depend on the selected OpenCode model provider; the documented OpenCode Zen free configuration does not require an API key.
How do you use this agent?
Start OpenCode with opencode and select a Swarm architect in the agent or mode picker; if no Swarm architect is active, Swarm gates, reviewers, and test agents are bypassed. Run /swarm help and /swarm agents to confirm the plugin and inspect the live roster, then enter a task such as Build me a JWT auth helper with tests.. Use /swarm status for the current phase, /swarm show-plan for the plan, and /swarm evidence for review, test, and security results. Session behavior can be changed with /swarm turbo [on|off], /swarm full-auto [on|off], and /swarm auto-proceed [on|off]. To upgrade, run bunx opencode-swarm update and restart OpenCode; use bunx opencode-swarm install when a full reinstall that reasserts configuration is desired.
How does this agent compare with similar options?
The repository compares Swarm with oh-my-opencode and get-shit-done, positioning Swarm as the option with specialized roles, pre-coding plan review, per-task review and testing, separate coder and reviewer models, shell-write detection, persistent scope enforcement, resumable sessions, and built-in security scanning. The supplied comparison is the Swarm project's own table and contains no independent implementation evidence for the other two projects, so it should be treated as the author's positioning.
FAQ
Do I need a paid model API?
Which files can the agents change?
src/, tests/, docs/, and scripts/; the reviewer writes evidence; and explorer and sme are read-only. authority.rules can override scope, while protected areas such as .swarm/ receive additional safeguards.What happens after a failed gate or interrupted session?
.swarm/, so an architect reopening an existing project can enter RESUME and EXECUTE rather than repeating full discovery.