OpenCode vs SolOS vs Hermes — Architecture Study

Directive under test (Young): "OpenCode has everything we need; integrate SolOS into it and optimise their existing architecture."

Sources (all fetched, cited in-line): opencode.ai/docs (server, agents, plugins, custom-tools, lsp, providers, rules, enterprise), github.com/sst/opencode README, Hermes llms.txt. SolOS claims from prior review lanes (not re-verified this run).

1. Comparison snapshot

2. Verdict on the hypothesis

Partially true for coding runtime; mostly false for fleet ops.

• OpenCode's verified strength set (sessions-fork/children, 75+ providers, plugin layer, OpenAPI server+SDK, password-protected server, LSP) maps beautifully onto the SOLos agent-runtime tier — it would REPLACE: registry (→ server+SDK), per-agent FastAPI A2A servers (→ plugins/custom-tools; kills 8 python processes), prompt_factory (→ AGENTS.md
  • markdown agent defs), tier-fallback (→ provider config), broken task_ref bookkeeping (→ child-session tree + status API).
• But it has no messaging surface, no memory plane, no cost ledger, no multi-bot mesh — so "integrate SolOS into it" has the direction backwards: OpenCode is the substrate ADOPTING SolOS's superior primitives (they don't need our provider/session code), while SolOS contributes exactly the layer the directive skips — fleet ops: TG mesh, cross-agent memory, CostGov, vault sync. Those must remain custom regardless.

The honest counterpoint: Hermes' feature set (Bot Mode — named bots with own memory/skills that message each other; 21-platform gateway incl. Telegram; FTS5 canonical session store; Bitwarden/1Password credential rotation; iron-proxy egress) is a closer literal match to Young's "everything we need" than OpenCode. If SolOS is a fleet, Hermes is the closer substrate; if SolOS is a coding fleet, OpenCode wins on tool depth (LSP etc).

3. Recommendation: adopt-with-glue, pending a decision spike

Recommended: run a controlled spike — one SolOS agent on each substrate, measure TTFB, memory recall across sessions, cost accuracy, and TG delivery reliability. Do not commit to either substrate without the spike; the two stack-lines diverge:

• OpenCode substrate → keep: TG gateway (PTB → prompt_async — needs idempotency keys, OpenCode gives sessions NOT dedupe), memory_plane, CostGov, vault ops scripts.
• Hermes substrate → bot-native fleet mesh almost for free, less glue engineering.

4. If OpenCode substrate is chosen — integration map

Clean mappings:

• agent personas → config/agents markdown defs (build/plan permission tiers replace tier fallback)
• registry → OpenCode server API (/project, /session, /config/providers) — the registry collapses
• A2A servers → plugins/custom-tools (.opencode/tools/*.ts) — kills 8 FastAPI processes
• prompt_factory → AGENTS.md + per-agent markdown (docs/rules)
• CardGov → /agent config listing (cards become config, not a service)

Must stay custom (no equivalent):

• Telegram gateway mesh; cross-agent memory sharing; CostGov; vault/scp ops; heavy-LM non-coding personas (Qwen/GLM-class bot fidelity in a TUI/coding-shaped harness).

5. Risk register

1. Upstream org churn: repo reads as sst→anomalyco — brand/governance risk for a pinned dependency.
2. OpenCode server ships localhost auth-OFF; we must always set OPENCODE_SERVER_PASSWORD.
3. Bun/Node glue vs Python fleet: mandatory bridge engineering, not free.
4. Cost accounting BYO → keeping CostGov alive will be an internal scope fight.
5. prompt_async is at-most-once — dedupe layer still ours to build.
6. Hermes-based claims_SKILL.md sourced from index only; deeper check needed before commit.

Verdict one-liner

Adopt OpenCode's runtime primitives (sessions/providers/plugins/server-API), keep the fleet layer (mesh + memory + CostGov), and put Hermes on the table for the same spike because Bot Mode may already be what Young actually asked for.