HKUDS/AutoSwarm

AutoSwarm is worth a trial if you already juggle several agent CLIs and want one task to fan out across them; it is not a model or a new agent, but a coordination layer you install as a Skill into a host agent.

The problem

You have Codex for refactors, Claude Code for long-context reading, and another CLI for browsing, so a single request becomes manual: copy the prompt into each tool, export the partial answer, reconcile disagreements by hand. With AutoSwarm, you give the task to the host agent you already use, and it selects and connects the other locally installed agents, then collects their results before answering. The step that changes is dispatch and aggregation, not the agents' own capabilities.

What's different

The mechanism is a lightweight plug-in plus a Skill: autoswarm setup --host <id> writes host-specific files, and the installed SKILL.md documents the launcher and delegation pattern used by the host agent. The README lists many host IDs (Codex, Claude Code, OpenCode, Cursor, Copilot, Muse, CodeBuddy, hermes, nanobot, dsh, grok), and the intended benefit is reusing your existing credentials, models and proxy settings rather than reconfiguring a stack. Delegated work is meant to be collected with wait --any, with questions and approvals routed back during the task.

The trade-off is operational: the README says the installed Skill carries its own runtime copy, so updating the checkout or package alone is insufficient, and there is no automatic updater. The setup notes also warn that the old Skill launcher cannot fetch a new version, which means an update-and-recover loop is part of ordinary upkeep. A paper and an archived v1.0.0 tree are linked for coordination details, but the supplied material does not contain independent evaluation of coordination quality.

Who should try it

A good fit is a developer with two or more agent CLIs already installed and authenticated, who wants a single conversation to read a large document set, split summarization and code review across different agents, and then verify deliverables. A poor fit is someone with one agent and no desire to manage host bindings: the setup and per-host refresh steps add work without replacing anything. The README describes setup per host, so a single-host user can still try it, but get less from cross-agent routing.

Requirements and limitations

PYTHON 3.10+ is required; installation uses uv tool install or python -m pip install . in a dedicated environment. The README's first-install flow asks the host to inspect the machine and reuse existing CLIs, credentials and proxy settings, and setup can be pointed at an existing home and skill directory. Host support is enumerated by ID, but each host needs its own setup run and refresh after updates, so mixed environments carry per-host maintenance.

Ongoing care matters more than install: complete delegated work before updating, run setup from the updated package, refresh every host in use, and verify providers with doctor --probe. Native wake-up for completed tasks is optional and needs a supported host binding. The README also directs users to diagnose retained calls and logs before retrying uncertain operations; that recovery guidance is a hint that failed or ambiguous delegations are expected, not an assurance they are harmless.

HotRepo's take

HotRepo's only dated observation is 2026-10-27, when the repo appeared on the daily board with 2,019 stars and +41 that day. With one recorded board date, persistence and trend cannot be judged. Before adopting, verify the specific host binding you need against the agent capabilities reference and the upgrade notes, since host setup and refresh are the parts most likely to differ from your environment.

Useful starting points: the project README, the arXiv paper, and the Chinese setup notes.