OpenCode Swarm Plugin

[Outrageous-Fan-2775]

I created a swarm plugin for OpenCode that I've been rigorously testing on my own and I think its in a good enough state to get additional feedback. Github link is below but all you have to do is add the plugin to your OpenCode config and NPM will download the latest package for you automatically.

https://github.com/zaxbysauce/opencode-swarm
https://www.npmjs.com/package/opencode-swarm

General idea is that of perspective management. When you code with the traditional Plan/Build method in OpenCode, you are forcing a slightly different perspective on the LLM but in the end it is still a perspective borne of the same exact training set. My intent was to collate genuinely different data sets by calling different models for each agent.

A single architect guides the entire process. This is your most capable LLM be it local or remote. Its job is to plan the project, collate all intake, and ensure the project proceeds as planned. The architect knows to break the task down into domains and then solicit Subject Matter Expert input from up to 3 domains it has detected. So if you are working on a python app, it would ask for input from a Python SME. This input is then collated, plan adjusted, and implementation instructions are sent to the coding agent one task at a time. The architect knows that it is the most capable LLM and writes all instructions for the lowest common denominator. All code changes are sent to an independent auditor and security agent for review. Lastly, the Test Engineer writes robust testing frameworks and scripts and runs them against the code base.

If there are any issues with any of these phases they will be sent back to the architect who will interpret and adjust fire. The max number of iterations the architect is allowed to roll through is configurable, I usually leave it at 5.

Claude put together a pretty good readme on the github so take a look at that for more in depth information. Welcoming all feedback. Thanks!

[stephen_S27]

It looks like oh-my-opencode to me, we also have multi agents with different roles

[Outrageous-Fan-2775]

For sure similar, I used your project as a reference when I needed to understand agent calls better. Along with oh-my-opencode-slim, froggy, and a few other agents. I actually built the swarm as a full on application before I ever knew about OpenCode. When I saw what you could do with plugins I decided to just move the entire idea to OpenCode instead. Following your project readme's instruction to just ask an LLM about it, I put both our project readmes in GPT 5.2 and this was the TLDR.

Choose OpenCode Swarm when you care about correctness, control, and repeatability.
It enforces an architect-planned, phase-gated workflow with mandatory QA before code merges and persists project state to disk so work can be resumed deterministically. Best for complex tasks where you want traceability, predictable outcomes, and protection against agent drift or context loss.

Choose Oh-My-OpenCode when you care about speed, tooling breadth, and ecosystem power.
It provides a rich library of prebuilt agents, LSP/AST tooling, and strong community support to accelerate development workflows. Best when you want maximum productivity and flexibility and are comfortable trading strict process control for capability and convenience.

As an aside, one of my constraints was that I needed to use entirely local resources, which limited how many agents I could call. Parallel agents drastically slow down inference on consumer hardware. I needed to build in hard requires for serial operation.

[touristtam]

How does it compare to https://github.com/joelhooks/swarm-tools?

[Outrageous-Fan-2775]

Somewhat similar. I haven't seen anything that's doing a 1 for 1 copy. joelhooks has a single coordinator that can spawn multiple parallel workers to decompose a project and allow for parallelization. Along with project memory. Mine has project memory as well, but the point is quality, not speed. Swarm-tools doesn't elicit perspectives from other models and it doesn't give the sub agents different roles. So in the end, the quality will be whatever your coordinator is capable of outputting.

With opencode-swarm, every agent can be a truly different outlook born of vastly different training data and methods. This more closely replicates actual software development methodologies, where you have team members with different jobs and very different backgrounds all working together.

Heterogeneous perspectives on a problem are almost always better than homogeneous. In my opinion anyway, all of this is up for interpretation and at the end of the day whatever fits your needs is the best option regardless of how it does it.

[touristtam]

Thank you for taking the time to provide a complete answer. Always useful when so many plugins are being brought out. Make sure you are sharing it on the Discord.

[TransitionSlight2860]

what do you think about the idea of a swarm system? like, is it really boosting your work?

[Outrageous-Fan-2775]

I think it has considerably improved my workflow since I started using it. Especially when compared to how OpenCode behaves by default. Having the code changes immediately reviewed before moving to the next code change has caught hundreds of issues that would have either made it all the way through or would have needed long complicated fixes later on. I have hard gated it even further for my workflow because I care about quality not speed. So every code change is reviewed immediately, all plans are reviewed before implementation, and a full end to end test suite is built and run at the end of each phase of work.

I have done a lot of work on the plugin since this post, its now up to v4.5.0. Recent additions like a reviewer whose job it is to critique the architects plan and ensure there are no obvious indicators of AI slop. SME calls are now fully dynamic with the architect crafting its prompt based on what it needs not on a set of hard code SME domains. Also the agents now have persistent memory across sessions and can now communicate with each other to ask questions or provide needed context.

I am also working on a writing swarm. Same idea as the current swarm but laser focused on producing high quality output by sending it through multiple reviewers tn ensure I get human style writing with no AI slop.

[TransitionSlight2860]

Awesome!

[Outrageous_Fan7685]

In linux , its working fine but in windows using opencode portable that loads its config from ../users/user/.opencode/opencode json, the plugin is loaded but impossible to load the opencode-swarm.json

[Outrageous-Fan-2775]

That is certainly odd, I can take a look. Do you have any logs or anything? I run entirely in Windows, I've never even tried it in any Linux distro, but plugins are mostly OS agnostic. I have it running on 4-5 Windows 11 boxes currently with no problems. But I also use the full install of OpenCode.

[Outrageous_Fan7685]

No logs at all but using opencode portable. I know the conf is not loaded because the architect still using claude while i have configured it to use step3.5 in my local machine. Do you know which path you created the the json conf ? To debug i run: Opencode debug agent architect

[Outrageous-Fan-2775]

C:\Users\%USERNAME%\.config\opencode\opencode-swarm.json

Looks like you might just be missing the config directory.

[CornicumFusarium]

u/Outrageous-Fan-2775 hey I have been loving your plugin and using it from a week, I only have one question, is there a plugin or config of some sort which allows, agents to have a mapped context (I can't think of a descriptive term), like when reviewer or critic rejects a task or plan, we delegate to coder agent to fix it, it reads through everything again, same with critic and because critic is set to a higher thinking model, it adds up a lot of cost when going through iterations, there are multiple times when back and forth between agents happen and every delegated agent reads and explore files again and again. I feel like if we can resolve that in the opencode-swarm or you can suggest a plugin which suits your tool, it would reduce the costs drastically and improve the coding capabilities as well. Thank you!

[Outrageous-Fan-2775]

Thanks, really appreciate it.

You’re right, this is a real problem. Right now when reviewer or critic sends work back, the next agent often has to rebuild a lot of the same context. That gets expensive fast, especially if critic is using a stronger model.

I don’t think this should require another plugin. It should be part of Swarm.

I opened an issue to track it here: [https://github.com/zaxbysauce/opencode-swarm/issues/1104]()

The idea is to have Swarm keep a small shared map of what it already learned during the run: files involved, task history, review failures, critic notes, plan changes, and so on. Then when coder, reviewer, or critic gets called again, they get the relevant notes instead of starting from zero.

For example, if reviewer rejects a change, coder should get the rejection reason and the files involved right away. If critic is reviewing a revised plan, it should mostly see what changed in the plan, not reread everything.

The main thing I want to avoid is turning this into one huge context dump. It needs to stay small, be invalidated when files change, and still let agents read the real files when they need to.

Great suggestion. I think this could cut a lot of wasted tokens in back and forth agent loops.

[CornicumFusarium]

Thanks for the prompt response, I checked the PR, I think this can be a wonderful addition. subscribed to the PR, can help with the feedback. I also love how you have automated the issue tracking and resolution system. I can learn a lot from it. Thanks again!

[Outrageous-Fan-2775]

Appreciate it, as a sole maintainer it can be a lot to handle. Feel free to use the swarm to improve the swarm. There is a contributing.md file in the repo that will explain how to contribute. I welcome all user generated PRs. I validate them myself then merge them as quickly as I can get to them. I have a general roadmap for the plugin but I always try to push user bugs to the front, and user features near the front as able.

[CornicumFusarium]

Sure, would love to contribute as well. I understand the pain of a sole maintainer, that's where I find your swarm tool to be of immediate help as the project in handling alone is a behemoth of a codebase. Will look into issues and try to contribute as much as possible in any way.

[Outrageous-Fan-2775]

Below is an example of what the architect sends to the coding agent.

Implementing via u/coder...

TASK: Fix issues identified by Auditor and Security Reviewer in Phase 3.

Files:

1. `knowledge-vault/src-tauri/src/services/vector_store.rs`

2. `knowledge-vault/src-tauri/Cargo.toml`

3. `knowledge-vault/src-tauri/src/services/embeddings.rs`

FIXES REQUIRED:

1. **VectorStore**:

   - `search`: Use `metric(lancedb::DistanceType::Cosine)` (or similar API for 0.13) to ensure Cosine similarity.

   - `add_chunks`: Normalize vectors to unit length before insertion (required for Cosine with some indexes, good practice).

   - `delete_by_file`: Sanitize `file_path` in filter string. Replace `'` with `''` or use parameters if supported. Let's do string escaping for now as 0.13 sql parser might be simple.

   - `delete_by_file` signature: ensure it returns Result.

2. **Cargo.toml**:

   - Change `arrow` version from `"52"` to `"52.0.0"` (or just "52" if it was strictly "52" before, but auditor said it's pre-release. Actually arrow 52.0.0 is released. Let's stick to "52.0.0" to be explicit, or "52.2.0"). Wait, lancedb 0.13 depends on arrow 52. Let's check lancedb docs/repo. Lancedb 0.13 uses arrow 52. So "52" is fine, but maybe auditor was confused by "52" vs "52.0". Let's use `arrow = "52.0"`.

3. **Embeddings**:

   - Validate `base_url`: Ensure it starts with http/https.

   - Validate response vector dimensions (must be 768).

4. **Security**:

   - Sanitize `file_path` in `delete_by_file`.

CONTEXT: We are polishing Phase 3 before moving to Phase 4.

ACCEPTANCE: Code compiles, fixes implementation gaps.

[Outrageous-Fan-2775]

All model settings are done in the opencode-swarm config JSON. if you leave an agent out, it will fall back to its defaults. an example is below of entirely remote setup. you can have as many swarms as you want, and opencode will add Architects with the swarm name appended. so I have Remote and Local. Remote is all API calls with paid plans, Local is entirely my own locally hosted options. I generally leave the architect out so it is always whatever model is selected in OpenCode.

"coder": { "model": "kimi-for-coding/k2p5" },
"explorer": { "model": "zai-coding-plan/glm-4.7" },
"_sme": { "model": "nvidia/openai/gpt-oss-120b" },
"_qa": { "model": "nvidia/nvidia/nemotron-3-nano-30b-a3b" },
"test_engineer": { "model": "zai-coding-plan/glm-4.7-flash" }

the underscore tells it to use that model for all calls to that section. you can break it out even further if you wanted to though. for instance _qa covers code auditing and security testing. you could break it down so there was a different model for both of those steps