Home for BitRouter's agent-harness adapters — each an independent, separately-published package (its own version and release) that shares this repo's CI and a single source of truth for BitRouter's drift-prone data. BitRouter's own first-party plugin (its skill + MCP) ships from the core gateway repo instead; the index below covers both.
The complete index of BitRouter's agent-harness integrations. Where each one lives follows a single rule: which side's SDK and release cadence does it track? Tracks a third-party harness → it lives here (and uses the codegen + auto-update machine below). Tracks BitRouter itself → it ships from core.
Each adapts BitRouter to a third-party harness, tracks that harness's release cadence, and publishes independently. See each directory's README for install details.
| Adapter | Harness | Published as | Coupling |
|---|---|---|---|
openclaw/ |
OpenClaw | @bitrouter.ai/openclaw-plugin (npm) |
binary — downloads & pins the gateway |
pi/ |
pi-agent | @bitrouter/pi (npm) |
api — cloud/daemon over HTTP |
hermes-agent/ |
Hermes Agent | hermes-bitrouter-plugin (PyPI) |
api — local daemon over HTTP |
opencode/ |
opencode | seed — not yet published | api |
BitRouter's own agent plugin — the bitrouter setup skill plus the bitrouter mcp serve MCP
server. It has no third-party SDK to break and versions with the gateway binary, so it ships
straight from bitrouter/bitrouter, not from
here. Same plugin, exposed through each host's plugin/marketplace convention:
| Host | Manifest (in core) | Install |
|---|---|---|
| Claude Code | .claude-plugin/ |
/plugin marketplace add bitrouter/bitrouter → /plugin install bitrouter@bitrouter |
| Codex | .codex-plugin/ |
see core repo |
| agents marketplace | .agents/plugins/ |
see core repo |
Why two homes? An adapter translates BitRouter to a third-party runtime's plugin API — it breaks when that runtime changes, so it's versioned and released against the host and lives here. A first-party manifest just exposes BitRouter's own skill + MCP to a plugin host; nothing foreign to break, versions with the gateway, so it ships from core. Rule of thumb: tracks a third-party harness → here; tracks BitRouter → core.
shared/bitrouter.json— the one source of truth for data that changes when BitRouter changes (gateway version + download coords, cloud/auth URLs,/v1surface, default model).scripts/gen.mjs(just gen) — mechanically writes that data into each plugin'sgenerated/file (TS or Python). Generated files are checked in; CI fails if stale. Adapter logic is never generated — it stays hand-written and local per plugin.plugins.manifest.json— the registry. CI builds its matrix from here, not from the directory listing. Maps each dir to its package, language, build/test commands, BitRouter coupling, and how its harness update is detected.
Two triggers, deliberately asymmetric:
- BitRouter released → 1:N (
.github/workflows/on-bitrouter-release.yml). Onerepository_dispatchfrombitrouter/bitrouter→ a deterministic shared-data bump PR → a coupling-aware agent per plugin → one PR per plugin.binaryplugins re-pin the gateway;apiplugins only change if the/v1surface moved. - Harness released → 1:1 (
.github/workflows/on-harness-update.yml). Dependabot bumps the harness package in one plugin dir → a compat agent scoped to that plugin. Plugins whose harness isn't a package dependency (hermes-agent) use a repo-release watcher instead (pending the Hermes repo URL).
The agent (anomalyco/opencode/github on bitrouter/kimi-k2.5) is reserved for judgment
— did the API break, does the adapter still compile. Mechanical data propagation is gen.mjs.
just gen # regenerate constants from shared/bitrouter.json
just gen-check # CI: fail if generated files are stale
just plugin openclaw # install + build + test one plugin, in isolation
just all # every plugin (islands, sequential)Add a directory + a plugins.manifest.json entry (dir, package, language, build/test,
coupling, harness detection). just gen and the CI matrix pick it up automatically.