Twelve-way AI-agent comparison and review (Claude Code / opencode / hermes-agent / Raven / CodeWhale / goose / nanobot / grok-build / OpenWorker / **Open Design** / **MiMo Code** / **MiroFish**)

2.1 Architectural shape: from “a terminal program” to “a set of local infrastructure”

How each house thinks: architectural shape, at bottom, answers “what sits between the UI and the brain.” Claude Code’s answer is “nothing”—no protocol overhead, state sharing most direct, so iteration is fastest and terminal feel is finest; the cost is weak “being integrated” (later patched with SDK, ACP, bridge). opencode and goose are the most radical: a public protocol sits in between, even in the same process—local single-machine and remote team are the same code path; Zed, GitHub Action, third-party SDKs plug in at zero cost; the cost is lifelong protocol and process-management maintenance. hermes, Raven, nanobot sit behind a message/process boundary: a crashed TUI does not take the kernel with it; nanobot further decouples the storefront from the back shop with two asyncio queues; the cost is one more message model to keep. CodeWhale proves a compromise works: a message pipe can live inside one process, and the same engine serves TUI, exec headless mode, and the web client—“headless is not a castrated edition, it just has no UI.”

flowchart TB
    subgraph CC["Claude Code：单体 TUI"]
        A1["React/Ink 界面"] --> A2["五层全在同一进程
src/query.ts 主循环"]
    end
    subgraph OC["opencode：服务器即本体"]
        B1["TUI (SolidJS)"] -->|"Worker RPC → 内存 fetch
http://opencode.internal"| B2["HTTP 服务器
session/prompt.ts"]
    end
    subgraph GS["goose：引擎即服务器"]
        C1["Desktop GUI / Zed / 第三方"] -->|"ACP over HTTP/WebSocket"| C2["goose serve
Rust 核心 crates/goose"]
    end
    subgraph HM["hermes：Python 大脑 + 多平台网关"]
        D1["TUI / 桌面 / 约20个IM平台"] -->|"JSON-RPC over stdio 或网关"| D2["Python 内核
conversation_loop.py"]
    end
    subgraph RV["Raven：Spine 调度脊骨"]
        E1["TUI / 12个IM平台"] --> E2["Spine：submit 进 → Lane 串行 → emit 出"]
    end
    subgraph CW["CodeWhale：单二进制消息管道"]
        F1["ratatui 界面"] -->|"Op / Event 枚举"| F2["Rust 引擎
turn_loop.rs"]
    end
    subgraph NB["nanobot：MessageBus + 状态机"]
        G1["Channels / WebUI / CLI"] -->|"inbound / outbound 双队列"| G2["AgentLoop 状态机
→ AgentRunner"]
    end

2.2 Agent main-loop implementation: the same heartbeat, six constitutions

How each house thinks: at textbook level the eight loops are identical—request the model, if there is tool_use execute and append, request again; “the answer is out when the model stops asking for tools.” The real gap is density of boundary-case handling: opencode re-reads the database every turn, so “queued messages are taken over naturally, multi-client concurrency is safe” comes for free; hermes makes “persist first, then act” iron order—a tool may execute hermes restart and suicide; that order was bought with blood; Raven carries “errors are also context” all the way through, tool errors return a string plus a crib sheet “try another method”; nanobot uses an explicit state machine to split the turn lifecycle cleanly, default budget 200 for long tasks; CodeWhale’s loop is buried in #issue comments for every historical bug, a numbered error-notebook. Another convergent evolution is steer: when the user speaks while the agent is working, the houses give two answers—queue (Claude Code, opencode) versus mid-flight inject (hermes, Raven, CodeWhale, goose)—standard kit in the long-task era.

sequenceDiagram
    participant L as 主循环（七家同款骨架）
    participant M as 模型 API
    participant T as 工具层
    loop 直到模型不再要工具
        L->>L: 家务：drain插话 / 压缩检查 / 预算检查 / 取消检查
        L->>M: 流式请求（全部历史 + 工具清单）
        M-->>L: 文本 + tool_use（边收边解析，参数收齐即执行）
        L->>T: 权限裁决后执行（只读并行 / 写串行）
        T-->>L: tool_result 追加进历史
    end
    L-->>L: 正常出口：无 tool_use 的那次回复

2.3 Tool-system design: count does not matter; discipline does

How each house thinks: the most important consensus of the tool system is—every tool’s schema is sent with every request, a continuous bill (hermes’s AGENTS.md wrote this as a standing order: "Every model tool we add is sent on every API call, so the bar for a new core tool is high"). Around that bill, the houses give three kinds of throttle: Claude Code’s ToolSearch is “announce the dish names first, then hand the menu” (the shelf first shows only titles; pull the book you need); hermes/Raven’s tool_search is “fetch from the shelf on demand”; CodeWhale is “merge likes” (one File tool eats four actions, the catalog shortens, the model’s chance of picking wrong shrinks); nanobot simply presses core tools to ~20+ and pushes capability to the edge with pkgutil/entry_points/skills. On safety metadata there are two roads: Claude Code and CodeWhale make safety attributes declarations of the tool itself (three tags / capability tags; CodeWhale even derives approval level from the declaration automatically—that is the literal meaning of “safe by construction”); opencode and goose externalize the safety judgment into permission rules or MCP annotations. The former’s benefit is safety living and dying with the tool; the latter’s is a thinner tool implementation. Finally notice a recurring small wisdom: “do not show the model a tool it cannot use”—deny-strip early, probe registration, check_fn gating, all the same thing: if the model cannot see it, it will not call it at random.

2.4 Permissions and safety: four sharply different roads

How each house thinks: permissions are where the eight houses diverge most; they split into four roads. The popup-ask school (Claude Code) believes in “human in the loop”: five-gate verdict filters layer by layer, if unsure pop a dialog, “always allow” precipitates into rules—safety is “a chance to veto every time.” The rules-first school (opencode, hermes) believes in “legislate first, then enforce”: write the rules in advance, run with less interruption; opencode’s “teachable refusal” is a neat stroke—attach a sentence on deny (“do not run rm -rf, please use a safer way”) back to the model, and the refuse instant becomes a teaching scene. The structural-safety school (CodeWhale at the extreme) believes “there is simply no tool that can overreach”: Plan mode does not register write tools at all; constitution.json cannot be bypassed even in full-access mode; UserInputProvenance distinguishes “a real person typed this” from “a sub-agent handed this over,” and non-human origin cannot inherit auto-approve—this is a source-level defense against the new threat of “indirect prompt injection privilege escalation.” The sandbox school (nanobot / Raven) simply gives up per-call approval: in always-on IM there is nobody to press y; they replace the human gate with “blacklist + sandbox + workspace fence” front-line defense—nanobot bets bwrap, Raven after the fork upgrades to boxlite microVM. Honesty is also worth remembering: a blacklist is only “best-effort”; the real backstop is the sandbox.

flowchart LR
    subgraph P1["① 弹窗询问派（人在回路）"]
        A["Claude Code
五关裁决，兜底弹窗
'始终允许'沉淀为规则"]
    end
    subgraph P2["② 规则前置派（先立法后执法）"]
        B1["opencode：三态通配符
拒绝可附教学反馈"]
        B2["hermes：审批三级 + YOLO 导入即冻结
防提示注入偷开免审批"]
    end
    subgraph P3["③ 结构安全派（没有越权的工具）"]
        C1["CodeWhale：Plan 不注册写工具
constitution.json 只加锁不放权
provenance 降级"]
        C2["goose：Chat 模式禁工具
SmartApprove 靠注解 + LLM 裁判"]
    end
    subgraph P4["④ 沙箱派（隔离代替审批）"]
        D0["nanobot：黑名单 + 工作区 + SSRF + bwrap
Raven 上游出厂设置"]
        D1["Raven：黑名单 + microVM
无人值守场景的答案"]
        D2["hermes：docker/modal 后端
按任务选隔离级别"]
    end
    subgraph P5["⑤ LLM 分类器派（智能分类）"]
        E1["grok-build：PermissionClassifier 实时判断
Auto 模式 3/20 上限后强制弹窗
把'该不该'也交给模型"]
    end

2.5 Context engineering and compaction: the summary-and-discard school vs the lossless-asset-management school

How each house thinks: this is the eight houses’ most beautiful philosophical battlefield. The summary-and-discard school (including nanobot) thinks “compaction = concentrate”: dispatch a clone or a cheap model to write old history as a summary, then look only at the summary and the last few turns; all the craft is in the details—how much tail to keep, free slimming before compaction (mechanical trim / prune pre-scan / micro-compact), how to fall back on failure (fuse, prefer not to compact); nanobot also uses Dream to write valuable things back to Markdown across sessions. The lossless-asset-management school has only Raven: it holds that “context is not a consumable, it is a managed asset”; compaction is not “throw away old newspapers” but “archive into the library, leave a call number and reading notes”—Archive loses not one character; Working State guarantees the model always remembers goals and pending items. The cost is equally blunt: extra money for a small model plus a Manifest/Plan/validate complexity, and Raven itself still keeps a lossy Consolidator as a retreat (that is exactly the original path forked from nanobot).

flowchart TD
    O["上下文要爆了"] --> P{"两派选择"}
    P --> Q["摘要丢弃派
Claude Code / opencode / hermes / CodeWhale / goose / nanobot"]
    P --> R["无损资产管理派
Raven Curator"]
    Q --> Q1["派分身/辅助模型写摘要
旧历史离开窗口，只留要点
功夫在：保留尾部 + 免费预剪 + 失败兜底"]
    R --> R1["Archive：原文逐字落盘 + 留引用
Working State：蒸馏笔记注回系统提示
确定性代码执行小模型的方案，Fail-Safe 兜底"]

2.6 Memory systems: from “one constitution file” to “dual-track long-term memory”

How each house thinks: the eight houses have three consensuses on memory—memory is Markdown files (humans can read them, can edit them by hand), project constitution enters the system prompt, compatible with the opponent’s format is basic courtesy (opencode/hermes/CodeWhale/goose all read CLAUDE.md). The split is on the “auto-learning” axis: opencode is the most restrained, explicitly does no cross-session memory, and leaves “remembering the user” to config rather than algorithm; Claude Code and CodeWhale sit in the middle, have auto memory but keep the file shape; nanobot’s Dream reflection is the flagship of the file-memory road—night tidy-up, git-auditable; hermes and Raven make memory a closed loop—hermes’s five-piece kit interlocking, Raven’s dual-track storing “your affairs” and “the agent’s own craft” separately, recalled separately. Memory is the dimension of largest “product personality” difference: some treat it as config, some as an asset, some as a moat.

2.7 Sub-agents and multi-agent: three generations of cloning

How each house thinks: the hard part of sub-agents was never “sending them out,” but “bringing them back” and “not going mad.” Return methods show three generations: generation 1, block-and-wait—the parent agent sits and waits, simple and reliable but the UI freezes; generation 2, message inject—the result merges into a later turn as a notification/sentinel; CodeWhale’s comment is the most thorough: "Launching a sub-agent is not the same as joining it"; generation 3, scheduling backbone / message bus—nanobot makes the result an InboundMessage with injected_event re-entering through the bus’s front door; Raven on that basis swaps in Spine’s origin=SUBAGENT. Anti-runaway means highly converge: limit depth, limit concurrency, shrink the toolbox, do not inherit permissions—because everyone fears “recursion that spends tokens by itself.” And Claude Code’s “the child agent reuses the same query()” is the most beautiful design among them: main agent, child agent, compaction clone are all reuse of the same engine—which is also why the compaction clone can incidentally hit the prompt cache.

sequenceDiagram
    participant P as 父 agent
    participant S as 子 agent
    Note over P,S: ① 阻塞等待（CC前台 / opencode默认 / hermes编排者）
    P->>S: 派活
    P-->>P: ⏸️ 原地等待
    S-->>P: 结果作为 tool_result
    Note over P,S: ② 消息注入（CC后台 / hermes / CodeWhale）
    P->>S: 派活（后台，立即返回）
    S-->>P: 完成 → 通知消息/哨兵汇入后续回合
    Note over P,S: ③ 消息总线 / 调度脊骨（nanobot → Raven）
    P->>S: spawn
    S-->>P: publish_inbound(injected_event)
或 Spine TurnRequest(origin=SUBAGENT)

2.8 Extension ecosystem: MCP is the floor; above the floor each house shows its hand

How each house thinks: MCP has become the eight houses’ shared floor—all support it, and treat it as equal to built-in tools (same validation, same permission verdict). Competition happens above the floor: Claude Code uses a marketplace for experience (even sparse-clone details are polished), hermes uses plugins for breadth (even platform adapters and model vendors are plugins), goose uses recipe for circulation (agent workflows can for the first time be versioned and shared like scripts), opencode uses Hooks of every category for openness (even “permission ask” can be taken over by a plugin), CodeWhale uses compatibility to minimize migration cost (skills you wrote for another house just work), nanobot uses ClawHub + entry_points + channel plugins to keep the core small and capability at the edge, Raven uses narrowing to express pre-alpha restraint. Another consensus is SKILL.md + progressive disclosure (ordinarily only the list, full text loaded when used)—almost everyone has it; it is one of the fastest-converging practices across projects.

2.9 Models and auth: subscription reuse is the open-source community’s breakout

How each house thinks: the most interesting dark war on auth is “subscription reuse”: official products want you to use their subscription; the open-source community turned that wall into a door—opencode logs into your ChatGPT Plus and Copilot with plugins, goose wrote five providers specifically to reuse your existing Claude/ChatGPT/Gemini/Kimi/Cursor subscriptions, hermes on detecting a sibling project’s config directory even offers one-click migration. Fallback design exposes maturity: nanobot / Raven’s error classification is the most careful—distinguish “should retry” (rate limit), “no hope” (arrears), and “wrong medicine” (on context overflow, degrading is meaningless; what you should do is compact); Raven outsources adapters to LiteLLM, nanobot insists on a home-grown registry so “every path is traceable.” CodeWhale’s auto-route represents another direction: since the model is a part, let the system pick the part for you.

2.10 Prompt-cache engineering: the sharpest shared theme among the seven

How each house thinks: the sharpest shared theme of this round of analysis is obsession with prompt cache—the cache-hit portion is free or cheaper, responses are faster; a cache hit is real money. The means collapse into five axes (see the figure): static content first, volatile content last or moved onto the user-message side, tool list byte-stable, compaction triggered with care, telemetry visible. The three deepest houses each have a slogan: hermes says cache is “sacred,” CodeWhale says “saving money is engineering, not luck,” goose treats cache as an “engineering” object; nanobot is a plain “fixed three breakpoints + stable sort,” Raven adds adaptive TokenWise on top. An interesting corollary: Claude Code, locked to a single vendor, can instead take cache optimization to the extreme (billing headers, cache scope, breakpoint placement all “inside job” with the API vendor)—an important foreshadowing of the next chapter’s “model strategy” duel.

flowchart TD
    C["prompt cache 命中 = 省钱 + 提速
本轮分析最鲜明的共同主题"] --> S1["① 静态内容前置
CC 静态段 / hermes stable 层 / CodeWhale 恒定区"]
    C --> S2["② 易变内容后置或外移
goose MOIM / Raven 环境信息 / CodeWhale 易变区"]
    C --> S3["③ 工具清单逐字节稳定
CC 连续前缀 / hermes 冻结 toolset / goose 按名排序"]
    C --> S4["④ 压缩慎重触发
CodeWhale 晚做少做 / CC 同前缀 fork 分身"]
    C --> S5["⑤ 遥测可见
CodeWhale /cache + PrefixStabilityManager"]

3.1 Language and runtime: four bets, on four different pain points

Before an AI agent’s first line of code is written, you have to answer: what language, on what runtime? That decision permeates concurrency model, distribution method, contributor barrier, almost irreversible. Seven houses gave four answers.

How each house thinks: the most interesting thing about this table is—no house picked a language “to run fast”; all picked it so “a particular hard thing is harder to get wrong.”

• Claude Code’s pain is precision of terminal experience. It has to do “ESC emergency-brakes all the way to the wire,” character-level streaming, mouse selection; an ordinary Ink wrapper cannot satisfy that, so it simply vendors the whole of Ink and rewrites even a Yoga layout-engine subset in TS (src/native-ts/yoga-layout/index.ts:1). This is “for experience, we would rather maintain a renderer ourselves.”
• opencode’s pain is long-term maintainability and concurrency correctness. It bets Effect—Layer for DI, Fiber for structured concurrency—in exchange for extremely clean interrupt-cleanup paths, almost no mocks needed to test. The cost is written in its own contributing guide: the barrier is high. A typical “long-termism high-stakes bet.”
• hermes, Raven, nanobot’s pain is ecosystem reuse + a readable core. Memory, multi-provider, full-text search: Python’s ecosystem is most mature; nanobot as academic open source even writes “small core / readable internals” as iron law, and refuses to outsource LiteLLM—explicit over magic. Interestingly they split on sync/async: hermes’s main loop insists on fully synchronous; Raven / nanobot are full asyncio (nanobot’s MessageBus and state machine are concurrent by nature).
• CodeWhale and goose’s pain is concurrency correctness + clean distribution. The agent main loop must simultaneously handle an SSE stream, parallel tools, sub-agent completion, user steer—Rust’s ownership model makes these harder to get wrong, and Drop semantics even gift a “hard cancel” (see 3.5). Single-binary distribution is a huge plus for a tool “to be installed on someone else’s machine.” The cost is compile time of 650 000 lines of Rust and the contributor barrier; CodeWhale’s AGENTS.md even specially teaches newcomers how to run targeted tests to dodge a full compile.

A counter-intuitive observation: language choice correlates strongly with “who the team can hire.” Nous / HKUDS lean Python research ecosystem, so the hermes/Raven/nanobot family is a Python kernel; Block and the CodeWhale community lean systems engineering, so they pick Rust; Anthropic wants extreme product iteration speed, a TypeScript monolith is fastest. Tech selection was never a purely technical decision.

3.2 Streaming pipeline: from byte stream to screen, six forks

The model’s answer is spat as a stream (one SSE event after another); the agent must receive, parse, display, and when arguments are complete execute tools, all at once. This pipeline “from the provider’s byte stream to the user’s screen” is the most real-time, most bug-prone place in an agent. Seven houses share a skeleton; they fork at three points.

Fork 1: SDK or raw stream? Claude Code’s choice is hardcore—it deliberately does not use the Anthropic SDK’s BetaMessageStream, and instead beta.messages.create({stream:true}) takes the raw SSE and accumulates it itself (src/services/api/claude.ts:1818). Source comments state the reason: the SDK does a partial JSON parse on every input_json_delta, which is O(n²) and stalls under large tool arguments. This is a miniature of “first party knows its own API best.” opencode is the opposite: the main path walks Vercel AI SDK’s streamText().fullStream, then normalizes into its own LLMEvent (session/llm.ts:373)—one layer of abstraction in exchange for multi-provider generality. nanobot sits between: talks openai/anthropic official SDKs directly, but maintains ~40-house registry and OpenAI-compatible adapter layer itself, refusing LiteLLM magic.

Fork 2: how to accumulate partial tool arguments? This is the most consistent design in the whole field: all seven use “string accumulate + parse once when complete.” When the model spits tool arguments they are JSON fragments ({"pa ... th":"/foo"}); nobody parses half a JSON:

This high convergence says one thing: this is the optimum educated by reality. Whoever tries to parse half a JSON will explode when a provider wraps lines, fields arrive out of order, or several tools run in parallel. hermes’s comments even specially mark MiniMax/Ollama special cases; Raven / nanobot comments record the evolution from “assume a single tool in order” to “respect index, support parallel multi-tool”—scars left by stepping in holes.

Fork 3: what about thinking / reasoning blocks? Here Claude Code again exposes first-party depth: Anthropic’s signed thinking blocks must be echoed back byte-for-byte to continue the conversation trajectory, so it specially accumulates signature_delta and explicitly does not count them in output-length stats (messages.ts:3078, so the thinking animation does not inflate token metering); when swapping API keys it also stripSignatureBlocks peels signatures (signatures are bound to the key, messages.ts:5061). goose meets the multi-provider version of the same problem: it hangs thinking blocks on the tool-call message rather than making them independent messages; the comment’s motive is “avoid independent thinking messages merging with tool-call and getting a 400 from Anthropic for duplicate signed blocks” (agents/agent.rs:2346). Same pit: first party solves it “inside job,” provider-agnostic solves it “accommodate the rule”—foreshadowing Chapter 4’s “first-party dividend.”

flowchart LR
    P["Provider SSE 字节流"] --> A{"分岔一
SDK 还是裸流"}
    A -->|裸流·第一方最懂| CC["Claude Code
自管状态机
避开 O(n²) parse"]
    A -->|SDK·多provider通用| OC["opencode/goose/nanobot
归一化或直连官方 SDK"]
    CC & OC --> B["分岔二：工具参数
字符串累积 + 收齐解析一次
（七家完全一致）"]
    B --> C{"分岔三
thinking 块"}
    C -->|签名块里应外合| CC2["CC：不计输出长度
换key剥签名"]
    C -->|迁就provider规则| GS["goose：挂到tool-call
防重复signed block 400"]

3.3 “When to fire”: execute as soon as arguments are complete, or wait until this turn is fully received?

The previous section said “parse when arguments are complete,” but “execute the tool the instant parse finishes” versus “wait until the model has finished this whole turn, then execute uniformly” is where seven houses disagree, and it directly decides startup latency of the first tool.

Claude Code is the most aggressive: query.ts the instant it receives an assistant message with tool_use immediately streamingToolExecutor.addTool (query.ts:837), at which point the stream may still be spitting later content—the tool is already running. This is pressing “first token to tool start” latency to the minimum. The cost is complexity: if the stream later fails or needs fallback, the whole batch of executors must be discard()ed, then synthesized error results patched back to the model (StreamingToolExecutor.ts:174). This set is also hidden behind a gate config.gates.streamingToolExecution; turn it off and it falls back to the old “collect then runTools” path (query.ts:1380).

opencode walks the AI SDK’s scheduling: tools after arguments are complete are executed by the SDK (session/llm.ts:276 comment "AI SDK owns tool dispatch")—that is “execute when arguments are complete,” but not “execute on a half fragment.” goose, CodeWhale similar—once that tool’s arguments are complete it can enter the parallel pool.

How each house thinks: this choice is essentially complexity in exchange for latency. Claude Code, as a first-party product that must polish extreme experience, is willing to bear the discard/synthesized-error complexity for “after Enter, the tool starts a few tenths of a second earlier”; provider-agnostic projects prefer to let the SDK or a unified pipeline own scheduling, sacrificing a bit of latency for simpler implementation and cross-provider consistency. Latency is a product metric, complexity is an engineering cost; which way the scale tips depends on whether you treat “experience” as a moat.

3.4 Session persistence and crash recovery: three storage mentalities

An agent must be able to --resume last time’s chat; if the process crashes it must not amnesia, so the session must land on disk. What format it is stored in exposes each house’s understanding of “what a session is.”

There is a clear split: the JSONL school (Claude Code, Raven, nanobot) wants simple, human-readable, append naturally good for prompt cache (history not changed by one character); the SQLite school (opencode, hermes, goose) wants queryable, transactional, able to build full-text indexes and a usage ledger. CodeWhale took a third road—atomic JSON files + checkpoint, wanting JSON’s simplicity, then patching crash safety with “atomic write + fsync”; the cost is that randomly rewriting history is expensive (fork/undo must rewrite the whole).

Most worth lifting out on its own is hermes’s “persist first, then act” (conversation_loop.py:5361, plus a dedicated contract test test_tool_call_incremental_persistence.py). Its logic: a tool may execute hermes restart and kill its own process; if you execute first then persist, after restart it “forgets it just initiated this tool call,” and the conversation trajectory breaks. So the iron law is first write the assistant’s tool-call message into SQLite, then execute the tool. This is the order bought with blood by software that must “run unattended for months on someone else’s machine”—a tool used only locally, interactively, would never think to defend against this.

How each house thinks: notice a shared choice of opencode and goose—event / projection split. Business code does not write the DB directly, it emits events (events.publish), a projector lands events as SQLite state (opencode projector.ts). goose goes further, tagging messages with two booleans user_visible / agent_visible (conversation/message.rs:661); after compaction, originals marked “user-visible, model-invisible,” summaries marked “model-visible, UI-hideable.” This “treat state change as an event stream” idea is the natural extension of their “server-as-ontology” architecture—because multiple clients must subscribe to the same state, an event bus is a necessity. Claude Code’s monolith does not need this layer; writing JSONL directly is fastest. Architectural shape decides the mental model of persistence.

3.5 Concurrency and cancel: six implementations of read-parallel write-serial; hard cancel vs cooperative cancel

In one turn the model may want several tools at once. Fully parallel collides (two tools writing one file); fully serial is slow. The seven-house consensus is “read-only tools may parallel, write tools serial,” but implementation and “how to shout stop at something already running” differ enormously.

Parallel scheduling: who can parallel, decided by what?

• Claude Code has two schedulers (a detail easy to mix up): on the streaming path StreamingToolExecutor, concurrency-safe tools parallel, unsafe exclusive, no hardcoded cap; the non-streaming runToolsConcurrently is what has the default cap 10 (toolOrchestration.ts:152). “Is concurrency-safe” defaults fail-closed to false (Tool.ts:750), and can be a function judged dynamically from arguments. Another neat idea: only Bash error triggers sibling-tool cancel (siblingAbortController, StreamingToolExecutor.ts:356); Read failure does not implicate siblings—because Bash often has “command-chain” semantics.
• CodeWhale uses FuturesUnordered as a parallel pool (turn_loop.rs:2214); the parallel condition is the tool declaring supports_parallel (default false, spec.rs:1217); shell additionally has a semaphore MAX_PARALLEL_SHELL_EXEC=4. What can parallel are read-only File/Grep/WebSearch/read-only shell and the like.
• goose uses stream::select_all to merge each tool future and advance in parallel (agent.rs:2266), outer select! with a 100ms sleep (biased) so it can poll cancel.
• hermes is the finest, with three states: parallel / sequential / segmented (the safe subset of a batch of tools parallel, a write tool sets a barrier serial, run_agent.py:6443); file tools whose paths overlap can parallel but not the same subtree.
• Raven / nanobot instead execute tools serially within the same turn (await tools.execute), even though the model can emit several tool_calls in parallel. They give concurrency to the “cross-session” and “sub-agent” dimensions.

Cancel: hard cancel vs cooperative cancel is this section’s largest philosophical split.

flowchart TB
    subgraph HARD["硬取消派（能强杀正在跑的工具）"]
        R1["Rust 系：CancellationToken 三层贯穿
CodeWhale drop(FuturesUnordered) 即杀掉所有在跑 future
turn_loop.rs:2333 注释：不是等协作取消，是直接 drop"]
        R2["opencode：Fiber.interrupt ↔ AbortController
Effect 结构化中断 + acquireRelease 清理"]
        R3["Claude Code：AbortSignal 直达 HTTP 层
ESC 真掐断连接；后台 agent 独立 controller 不被连累"]
        R4["nanobot：/stop → asyncio.Task.cancel
硬取消 + checkpoint 优雅落盘"]
    end
    subgraph SOFT["协作取消派（只能等它自己检查标志）"]
        S1["hermes：每轮开头查 _interrupt_requested
检查点分布在 API 前/重试sleep中/退避循环
卡死的工具不能强杀，只能靠超时"]
        S2["Raven：asyncio.Task.cancel 向上冒泡
Lane 即取消单元；AgentLoop 内几乎不 catch CancelledError"]
    end

CodeWhale’s hard cancel is the most typical: on cancel it directly drop(tool_tasks), the comment is blunt—"Dropping FuturesUnordered drops every still-active tool future ... instead of merely waiting for cooperative cancellation" (turn_loop.rs:2333). This is ability gifted by Rust Drop semantics: dropping the future equals cancel, plus an RAII guard so after cancel the terminal is not stuck in cooked mode.

hermes is the other pole: cooperative interrupt. The main loop each turn starts by checking _interrupt_requested (conversation_loop.py:837 and several other checkpoints); a tool halfway with no checkpoint can only wait for it to finish or time out. hermes itself admits this cost in its trade-off list: “a stuck tool cannot be force-killed, only timed out.” But it buys one benefit: it will not kill a half-written damaged file—force-killing a tool mid-write may leave a corrupted half file; cooperative cancel guarantees the tool either has not started or has finished completely.

How each house thinks: hard cancel vs cooperative cancel is essentially the trade-off of “response speed” versus “state integrity.” Claude Code wants the satisfaction of “press ESC, stop immediately,” so AbortSignal punches through to the HTTP layer and truly cuts the connection; hermes wants “unattended, leave no mess,” so it would rather be a bit slower and stay cooperative. And this again correlates strongly with language: Rust’s Drop makes hard cancel almost free; Python cooperative cancel requires laying checkpoints yourself. A language’s capability boundary quietly shapes a product’s interrupt philosophy.

3.6 Error handling: classifiers, feed-back, error-notebooks

Models will talk nonsense, providers will rate-limit, networks will drop, context will overflow. How errors are handled is the hardest metric distinguishing “toy” from “production.” Here there are three consensus layers, each one deeper.

Consensus 1: errors must be classified; you cannot retry uniformly. The most mature are Raven’s and goose’s error classifiers:

• Raven’s classify_error splits errors into three actions: retryable (rate-limit→retry), should_fallback (swap model), should_compress (providers/base.py:16). The most brilliant is lifting context overflow out on its own—on overflow, degrading the model is meaningless; what you should do is compact. Many projects get this distinction wrong.
• goose’s ProviderError branches are finer: ContextLengthExceeded compact at most 2 times then give up (agent.rs:2532), CreditsExhausted pops a top-up link, Refusal terminates immediately and forbids retrying the same conversation (:2617).
• Claude Code forks by product identity, a first-party trait: 529 foreground retries, background sources immediately drop so they do not amplify cascade; 429 by default retryable, but Claude.ai subscription users by default do not retry (because it is mostly a quota window, blind retry is useless, withRetry.ts:765); 413 even splits two meanings—status 413 is “request body too many bytes,” while the copy prompt is too long is “too many tokens,” the latter walking compaction rescue (errors.ts:560).

Consensus 2: feed tool errors back to the model, let it change itself. Seven houses agree—tool failure does not throw and explode the session; the error is fed back as an ordinary tool_result. Raven is the most humane: on tool error uniformly append [Analyze the error above and try a different approach.] (agent/tools/registry.py:48), literally “teaching” the model to change method. Claude Code uses structured XML tags <tool_use_error>...</tool_use_error> + is_error:true (toolExecution.ts:669). opencode’s “teachable refusal” goes further—on a permission deny it can attach a natural-language feedback CorrectedError, turning refuse into teaching.

Consensus 3: write the pits you have stepped in into the code, so they are not repeated. CodeWhale made this a culture—every historical bug leaves an #issue numbered comment, a numbered error-notebook:

This “error-notebook culture” together with its “never corrupt state” philosophy—session atomic write + fsync (session_manager.rs:372), malformed trust files parse as an empty list rather than crash (workspace_trust.rs:49), a poisoned mutex also into_inner and keeps running (engine.rs:903), release keeps unwind so a single-tool panic does not kill the session—together constitute a sample of “what a production-grade Rust agent should look like.” Claude Code also has a pile of defensive pairing repairs (ensureToolResultPairing patches missing results, peels orphans, dedupes tool_use ids across messages, messages.ts:5120); it just hid them in the code rather than writing them as issue comments.

How each house thinks: maturity of error handling correlates strongly with “how long it runs.” The longer it runs, the more unattended, the heavier error handling. hermes, nanobot and Raven must live in IM long-term online, so they have the most complete fallback chains and cooldown; CodeWhale must run on all kinds of strange machines, so it accumulated an error-notebook; Claude Code must serve a sea of users’ subscription and API two billings, so error classification forks by product identity. An agent’s volume of error-handling code is roughly equal to the number of times the real world has beaten it.

4.1 A “gene table”: who pays, what they sell, therefore how they write code

This table is the key to understanding every technical difference. Three of the sharpest causalities:

1. Only a model vendor will lock a model. Claude Code locking Anthropic is not technical conservatism; it is commercial necessity—Anthropic building this agent’s purpose is to make you use Claude more. Locking instead lets it squeeze every knob of the Anthropic API dry (see 4.3). Conversely, none of the other six houses build the main model themselves (Nous has the Hermes series but does not force it), so “model-agnostic” is a hard need for them—you cannot say “I am neutral” and bind one house at the same time.
2. Whatever you sell, you make that the architectural protagonist. EverMind is a memory company, so Raven makes context engineering a 6-stage explicit pipeline, makes compaction a lossless archive, hangs EverOS by default—memory is its commodity, of course it must be the protagonist. Nous lives on Portal subscriptions and training data, so hermes ships trajectory-compression tools and has special cases for Portal. HKUDS sells “readable, self-contained,” so nanobot presses the core to loop/runner and pushes all capability to the edge. A product’s commercial kernel stubbornly shows up in the technical module it works hardest on.
3. Projects that do not monetize dare take architecture to the most radical place. goose was donated to a foundation, has no monetization pressure, so it dares bet “everything is MCP, engine-as-server,” the route with the highest ecosystem ceiling but short-term performance cost (it even had to invent Builtin/Platform two “cheat” shapes to claw performance back). CodeWhale is a pure community project, so it dares use 650 000 lines of Rust to grind safety and cache. nanobot as academic open source dares write “keep the core small” as iron law and refuse LiteLLM. Only a project without a KPI has the qualification to make a long-termism technical high-stakes bet.

4.2 Who the client’s protagonist is decides where the architecture’s center of gravity sits

The product position “what is the agent’s UI” directly decides where the architecture grows. Seven houses’ “protagonist clients” are completely different, so the architectural center of gravity leans with them.

flowchart TD
    Q["产品问自己：用户主要从哪里用我？"] --> A["终端/编辑器
（写代码的人）"]
    Q --> B["消息软件
（Telegram/微信/飞书）"]
    Q --> C["桌面 GUI + 第三方宿主
（非程序员 + 生态）"]
    A --> A1["Claude Code：单体 TUI，五层同进程
CodeWhale：双二进制消息管道
→ 重心在终端体验与主循环精度"]
    B --> B1["hermes：Python大脑 + ~20平台适配器
nanobot：MessageBus + 17平台 + WebUI
Raven：Spine调度脊骨 + 12平台
→ 重心在'会话键映射'与'无人值守安全'"]
    C --> C1["goose：引擎即服务器 ACP
opencode：服务器即本体 HTTP
→ 重心在'协议'与'多客户端一致性'"]

• Protagonist is the terminal (Claude Code, CodeWhale): all the craft goes into main-loop precision, streaming render, ESC emergency-brake, those “terminal feels.” Claude Code even forked the whole of Ink for this.
• Protagonist is messaging software (hermes, nanobot, Raven): the architectural center of gravity is two things others do not much worry about: one, session-key mapping—the same brain must simultaneously take a dozen platforms’ DMs / groups / topics; two, unattended safety—in IM nobody is sitting at the computer pressing “allow,” so nanobot / Raven simply give up per-call approval and bet the sandbox (this is the product root of Chapter 2’s permission duel “sandbox school”). Their position is “the agent is a member of your address book,” not “a tool you open.”
• Protagonist is GUI + third parties (goose, opencode): you must first have a protocol. goose’s goose serve is ACP over HTTP/WebSocket; desktop, Zed, any third party are clients; opencode is more extreme, even the same-process TUI walks the full HTTP protocol (cli/cmd/tui.ts:210 Worker + in-memory fetch), the reason being “local single-machine and remote team should be the same code path.” The cost is equally real—goose must give its own GUI a GOOSE_SERVER__SECRET_KEY against impersonated access (gooseServe.ts:336), the protocol must be maintained for life, cross-language types still need a codegen pipeline to stay in sync (goose uses schemars to generate JSON Schema → OpenAPI → TS, Justfile:165).

How each house thinks: this choice “is best thought through on day one,” because turning a monolith into a server after the fact is almost a rewrite. opencode’s sentence “the server is the ontology, the protocol is the product” holds because it wrote to a protocol from the first commit. Claude Code’s monolith later had to patch “being integrated” (SDK, ACP bridge are all later adds), but its single-machine experience is still the benchmark—architectural advancedness and product completeness are two different things.

4.3 “First-party dividend” and “provider-agnostic tax”: a technical bill you can actually add up

The most technical section of Chapter 4. What did Claude Code locking Anthropic actually buy, and what tax did the other six houses pay for “model freedom”? This is not a slogan; it is a bill you can point to, line by line, in source.

Claude Code’s first-party dividend (these optimizations cannot even be written in a multi-provider architecture):

Together these are a concrete of “depth”: when you serve only one API, you can inside-job with it down to billing headers, cache scope, internal fields. ToolSearch’s defer_loading depending on Anthropic’s unique tool_reference capability is the same logic.

The other six houses’ “provider-agnostic tax” (equally pointable in source):

• Adapter tax: opencode’s provider/transform.ts two-thousand-plus lines, all absorbing each house’s model quirks (who supports which effort grade, Copilot’s billing fields, Azure’s URL modes). nanobot instead feeds ~40-house registry itself—this is a tax that can never be finished writing—every new provider is one more conditional branch.
• Least-common-denominator compromise: when some API has a unique capability (say Anthropic’s signed thinking), a multi-provider architecture either gives it up or writes a pile of special cases. goose, to accommodate Anthropic’s “duplicate signed block gets 400” rule, has to hang thinking on the tool-call (agent.rs:2346)—forced accommodation.
• Crutch cost: goose, meeting a small model that does not support native tool calling, has to write toolshim using an interpreter to hand it a “crutch” (providers/toolshim.rs:1), accumulate the full payload then parse, and also turn off true streaming. This is the implementation tax paid for “any model can be used.”

How each house thinks: the conclusion of this bill is—lock-and-go-deep and agnostic-and-go-wide are two depths that cannot both be had. Claude Code’s cache engineering, ToolSearch, silky fallback, are all grindable only because “we serve only one house”; the cost is fate-binding (vendor raises prices, rate-limits, replaces a generation, the user has no exit) and hard exclusion of non-Anthropic users. The six that go wide buy user freedom and bargaining power (local models can even keep data on-machine), at the cost of those two never-finished taxes. Interestingly every house is quietly leaning toward the other side: opencode built its own Zen model gateway (wanting a bit of “depth” back), Claude Code also added SDK/bridge (wanting a bit of “width”). In the long run, whoever first makes “near-first-party depth optimization” inside a “provider-agnostic” architecture can eat both sides’ dividends—this is the next real technical highland of the model-agnostic camp.

4.4 Open-source governance form will reverse-shape the code

The last easily ignored product logic: who the project belongs to, how people collaborate, seeps into code style.

• Foundation governance → type contracts and documentation discipline. After goose was donated to AAIF, governance is written in GOVERNANCE.md (Contributors → Maintainers → Core Maintainers, deadlocks broken by founders); in code this shows as strong protocol boundaries (ACP + codegen type sync) and the value “most hackable.” Neutral governance forces it to make interfaces normative, because they must be used by contributors worldwide.
• Pure community + AI assistance → error-notebook and compatibility-first. CodeWhale’s .mailmap maps Claude/Copilot/Cursor/Qwen bot commits onto maintainer names; CONTRIBUTORS.md emphasizes harvest PRs (even if they cannot be merged as-is, keep the attribution). This “AI participates in development” reality, together with its #issue-comment error-notebook culture—because contributors flow, AI will re-commit old mistakes, writing the pit into a comment is the only defense. It is compatible with six houses’ skill directories, recognizes everyone’s AGENTS.md/CLAUDE.md, also the product logic of “a community project uses compatibility to buy users.”
• Company-led pre-alpha → honest stubs. Raven is led by EverMind, forked from nanobot, still pre-alpha, so the code is full of honest labels: /yolo stubs honestly marked supported: false rather than deleted (_stubs.py:40), NOTICES.md even records the evaluation conditions for “when we would abandon this hermes fork,” CONTEXT.md annotates every term with “what not to call it.” This “honest to the teeth” engineering culture is the product posture of “a company must be responsible for an open-source project that is not yet mature.”
• Academic open source → readable core and design iron laws. nanobot writes "Less structure, more intelligence" and “keep the core small” into .agent/design.md, preferring channels/providers to duplicate rather than abstract too early—this is the natural choice of a lab project facing student contributors: the code must be readable, changeable, fully self-contained.
• Closed-source first-party → gates as product boundary. Claude Code’s feature() / GrowthBook gating, USER_TYPE=ant whole-tree, telemetry migrating from Statsig to GrowthBook dual-cache (growthbook.ts:792), is essentially the inevitable form of a closed-source product that must “serve a sea of users, still leave employees a debug back door, still remotely tune experiments.” Many of its “implicit product boundaries” hide at these feature() call sites.

How each house thinks: governance form and code form are isomorphic. A neutral foundation births protocolization, a pure community births compatibility and an error-notebook, company leadership births honest stubs or gates, academic open source births readable iron laws. Read an open-source agent’s code style and you can almost reverse-derive what kind of organization sits behind it.

flowchart LR
    T["团队基因
谁出钱"] --> B["商业逻辑
靠什么活"]
    B --> M["模型策略
锁定 vs 无关"]
    B --> A["架构重心
终端/IM/服务器"]
    G["治理形态
公司/社区/基金会"] --> S["代码风格
门控/错题本/协议/残桩"]
    M & A & S --> R["最终技术形态
= 产品逻辑的下游"]
    style R fill:#e8f5e9

Duel 1: the permission-model route war—the trade-off of safety versus interruption

How each house thinks: every agent faces the same horror story—the model may execute rm -rf, may send secrets onto the net, may be injected instructions by a malicious page. The question is: where is the gate set, and who stands it. Claude Code trusts no prior judgment; dangerous operations always give a human a chance to veto; opencode and hermes trust “the law the user wrote in advance”; CodeWhale simply structurally eliminates the possibility (if there is no tool that can overreach, what is there to approve); nanobot / Raven admit that in always-on IM there is simply no “person” to press a button, and hand trust to isolation.

Comparison of solutions: popup-ask (Claude Code five-gate verdict + fallback popup) → rules-first (opencode three-state globs, hermes three-level whitelist + YOLO frozen on import) → structural safety (CodeWhale capability tags derive approval, Plan does not register write tools, constitution.json only adds locks never grants power, provenance downgrade; goose’s Chat forbidding tools and readOnlyHint also count as a lightweight edition of this school) → sandbox isolation (nanobot blacklist + workspace + SSRF + bwrap; Raven upgrades boxlite microVM; hermes six backends pick isolation by task) → LLM classifier (grok-build: PermissionClassifier judges risk in real time, Auto mode 3/20 cumulative cap then fallback popup) → out-of-band approval / inbox hang (OpenWorker: needs_user does not sit waiting in the loop, it turns the request into an idempotent inbox item and hangs the turn—attended inline card, unattended into a cross-session inbox, first answer from any UI takes effect, after restart resume does not double-run; plus §25 standard rules, connectors skip ask by exact target, shell always asks).

Pros and cons: the popup school’s sense of control is strongest, but interruption cost grows linearly with usage time, and it depends on “a person in front of the machine”—Claude Code when a remote channel is active simply disables ask tools (a popup would hang the session dead). The rules-first school amortizes cost onto config; a skilled user is almost zero-interrupted, but a new user has nowhere to start, and rules always lag new threats. The structural-safety school is once-and-for-all, auditable, highest safety ceiling, but lowest flexibility—it answers “can it,” not “should it this time.” The sandbox school is the only correct answer for unattended, but a blacklist is destined best-effort; a misconfigured isolation boundary is running naked. The LLM-classifier school intelligentizes approval itself, but introduces a new attack surface—the classifier may be fooled by adversarial samples, and still needs a cap as backstop.

Our evaluation (who it suits): this is not a single-choice question; it is a spectrum. High-frequency interactive coding scenes, Claude Code’s popup school has the best experience—its “always allow” precipitates each of your approvals into rules, the more you use it the closer to the rules school; automation/CI scenes, rules-first + structural safety is the correct answer (CodeWhale’s execpolicy + constitution combo is designed for pipelines); always-on IM assistant / unattended, the sandbox school is the only choice that does not self-deceive (for a light Python factory setting read nanobot, for a microVM upgrade read Raven); when you run an agent on a strange codebase, the structural-safety school (Plan mode does not register write tools) gives you protection the prompt school can never give; grok-build’s LLM-classifier school is the most exploratory route, worth taking as a research sample of “next-generation permission systems.” And OpenWorker’s “inbox-hang school” is the answer to the new scene “unattended + a person can take over at any time”—it does not chase making approval intelligent; it makes approval a durable, answerable from any UI, restart-does-not-lose queue, so the same run seamlessly switches between “a person is here” and “a person is not”; plus “external risk skip-ask by exact target, shell always asks” §25 grading, it dares let an agent unattended send Slack and change calendars for you—a question no other house’s permission model has faced head-on.

quadrantChart
    title 权限路线象限：打扰成本 × 安全上限
    x-axis 低打扰 --> 高打扰
    y-axis 防呆（防误操作） --> 防恶意（防注入/越权）
    quadrant-1 重兵把守
    quadrant-2 严防死守但最烦
    quadrant-3 佛系
    quadrant-4 省心但防不住高手
    "结构安全派 CodeWhale": [0.35, 0.85]
    "沙箱派 nanobot/Raven": [0.15, 0.7]
    "弹窗派 Claude Code": [0.8, 0.75]
    "规则派 opencode/hermes": [0.5, 0.5]
    "goose SmartApprove": [0.45, 0.6]
    "收件箱挂起派 OpenWorker": [0.3, 0.68]

Duel 2: two philosophies of context engineering—token cost versus information fidelity

How each house thinks: the context window is the agent’s only “workbench”; tool results pile up like parcels; something always has to be thrown. The summary-and-discard school (six houses including nanobot) holds: the value of old detail decays exponentially, spending tokens on fidelity is not worth it—concentrating into gist is enough, the workbench is freed. The lossless school (Raven) holds: the facts squeezed out are precisely what long tasks need—if “goals, pending topics, decisions already made” are lost, the agent will redo work or even contradict itself, so compaction should be “archive + cite + distill and re-inject,” not “throw away.”

Comparison of solutions: inside the summary school there are again three grades of fineness—the plainest is hermes/nanobot’s “auxiliary model writes minutes + micro-compact”; the middle is Claude Code’s “fork clone + 9-section template + 413 passive rescue” and goose’s “invisible marks + bridging lines”; the finest is opencode (tail keep constrained by token budget, can cut from the middle of a turn, overflow-type replays the last user message) and CodeWhale (zero-cost mechanical trim first, pin the working set, on failure prefer not to compact). The lossless school has only Raven’s Curator: the small model only looks at a Manifest index and produces a plan; landing is executed and validated by deterministic code; on error there is still a Fail-Safe that does not depend on an LLM at all—it even defends against “the small model is unreliable” (and Curator is exactly an upgrade of nanobot’s lossy Consolidator path).

Pros and cons: the summary school wins on simple, cheap, battle-tested—each house’s implementation has already been polished in large-scale real use; the defect is “a summary is lossy”: the file paths, error stacks, intermediate conclusions that were compacted may be exactly what you need three hours later; and compaction itself busts cache (CodeWhale is therefore especially stingy with compaction). The lossless school wins on fidelity and auditability (Archive loses not one character, Working State is readable and checkable), at the cost of extra money for a small model, significantly higher system complexity, and the benefit only cashes in on “long enough tasks”—in a short session its Fast Path is zero LLM calls, equivalent to carrying this complexity for nothing.

Our evaluation (who it suits): the summary school represents reality; the lossless school represents direction. On today’s main battlefield (coding tasks within dozens of turns), fine-grade summary (CodeWhale/opencode’s rank) is already good enough, unbeatable cost-performance; and when agents walk toward “unattended tasks that run for hours,” the problem Raven posed will become everyone’s problem—the houses are in fact quietly leaning toward “lossless”: Claude Code’s tool results landing on disk is essentially a prototype of “archive + cite.” Advice for beginners: first read and understand the summary school (the standard answer of the stock world; nanobot’s micro-compact + Dream is a light readable sample), then take Curator as the best sample for understanding next-generation context engineering.

Duel 3: openness of the extension ecosystem—the trade-off of standardization versus experience

How each house thinks: no team can write every tool the world needs, so the question becomes: in what shape does third-party capability come in. goose’s answer is the purest: everything is MCP, even built-in capability walks the protocol, the whole ecosystem has only one socket standard. Claude Code’s answer is the most “product manager”: MCP handles tool ingest, but above that they still build a plugin marketplace (git repo + sparse clone + official market), holding “discover, install, manage” experience in their own hands. hermes’s answer is the most “platform”: everything is a plugin—messaging platforms are plugins, model vendors are plugins, kanban is a plugin, the core only does the loop. opencode’s answer is the most “programmer”: open Hooks to the bottom (even permission ask, request params, shell environment are hookable), then compatible with Claude Code’s skills and memory files to lower migration cost. CodeWhale makes “compatibility” the strategy itself (skill directories scan six houses). nanobot uses entry_points + channel plugins + ClawHub to keep the core small. Raven deliberately narrows: at pre-alpha only two contribution points are open.

Pros and cons: everything-is-MCP (goose) architecture most unified, ecosystem ceiling highest (MCP servers already in the world plug and play), the cost is one process per extension overhead and failure surface—goose itself had to invent Builtin/Platform two “cheat” shapes to claw performance back. Own marketplace (Claude Code) experience best, distribution strongest, but the ecosystem is bound under a single vendor’s governance. Plugins/Hooks fully open (hermes/opencode) flexibility highest, but plugin-API stability is a long-term burden—every category of hook opened is a contract to maintain for ten years. Skill files (seven-house consensus) are the smartest compromise: no code written, only tokens occupied, progressive disclosure, eating the “user customization” dividend at lowest cost.

Our evaluation (who it suits): standardization decides the ecosystem’s floor; own systems decide experience’s ceiling. If you are an ordinary user, Claude Code’s marketplace + skills is the lowest onboarding cost; if you are an enterprise/team, goose’s MCP + recipe combo is the best deal—recipe lets “best practice” be reviewed, shared, cron’d like a script, the only design among the seven that made “workflow” a circulating asset; if you are a developer who wants to build ecosystem, first write an MCP server (one investment, seven houses general), then write a plugin for a specific host (eat the experience dividend). One sentence: writing an MCP server is “a deposit”; writing a host plugin is “wealth management.”

Duel 4: architectural shape—terminal program vs local infrastructure

How each house thinks: this question is essentially “is your agent a product, or a kind of infrastructure.” Claude Code and CodeWhale answer “product”: one process (or a pair of binaries) takes experience to the extreme; between UI and core even a protocol is not needed. opencode and goose answer “infrastructure”: the agent is a local server; TUI/GUI/editor/CI are all only clients—opencode even lets the same-process TUI walk the full HTTP protocol, the reason being “local single-machine and remote team should be the same code path.” hermes, nanobot and Raven’s answer sits between: the core is a “brain service,” but the client’s protagonist is not an editor, it is messaging platforms (Telegram / WeChat / Feishu); the agent is a member of your address book, not a tool you open—nanobot uses MessageBus to decouple storefront from back shop, Raven upgrades that to Spine.

Pros and cons: a terminal program (monolith) iterates fastest, debugs most intuitively, performance loss smallest; Claude Code can take “ESC emergency-brake all the way to the wire” to this precision because the whole chain is same-process; the cost is “being integrated” needs after-the-fact makeup (SDK, ACP, bridge are all later adds). The dividend of server/gateway shape is build once, plug in everywhere: goose’s desktop and Zed ride the same goose; nanobot / Raven’s dozen IM platforms share one bus or one Spine. The cost is equally real: the protocol must be maintained for life (Raven’s message model alone is 911 lines), process management adds a failure surface (goose must give its own GUI a SECRET_KEY against impersonated access), single-machine experience may instead lose to a monolith.

Our evaluation (who it suits): this choice is almost impossible to have both, and is best thought through on day one—the sentence in opencode’s analysis “the server is the ontology, the protocol is the product” holds because from the first commit it wrote code to a protocol; after-the-fact transforming a monolith into a server equals a rewrite. An extreme tool for individual developers, learn Claude Code; a platform for teams/ecosystems, learn opencode and goose; an always-on assistant / message gateway, learn hermes, nanobot and Raven’s gateway idea (to read the lightest Python core, prefer nanobot). An observation for beginners: serverization/gatewayization is the large trend, but the monolith Claude Code is still the experience benchmark—architectural advancedness and product completeness are two different things.

Duel 5: model strategy—lock a single vendor and go deep vs provider-agnostic and go wide

How each house thinks: Claude Code and grok-build both bet “a model’s distinctiveness is worth using in depth”: CC’s ToolSearch depends on Anthropic’s unique tool_reference, cache scope and billing headers inside-job; grok-build locks xAI Grok, multimedia tools (image gen/edit/video) deep-bound to xAI-only capabilities, Goal Mode five-piece kit designed around Grok’s reasoning depth—these optimizations cannot even be written in a multi-provider architecture. Seven open-source projects bet “the model is a part, not the product” (CodeWhale README original): the user should have the freedom to vote with their feet; the agent’s value is in the loop, tools, and engineering, not in binding which brain.

Comparison of solutions: the deep representatives are Claude Code (making an essay of every Anthropic API feature) and grok-build (Goal Mode + multimedia tools designed around Grok in depth); among the wide representatives, opencode uses provider/transform.ts two-thousand-plus lines to absorb each house’s model quirks, hermes uses “customize the prompt by model family” to dissolve differences (GPT family given patch format, Claude/Gemini family given replace format), goose uses toolshim to hand a “crutch” to small models that do not support native tool calling, CodeWhale lets 36 providers run the same runtime and toolset, nanobot uses a home-grown ~40-house registry talking official SDKs directly (Raven outsources to LiteLLM), OpenWorker sits directly on Andrew Ng’s team’s aisuite—outsourcing the whole of “unified provider + each call adapts PDF/vision by current model capability, mid-session model switch only changes a field” to this abstraction layer, writing not one line of quirk code itself.

Pros and cons: lock-and-go-deep’s optimization depth is irreplaceable—prompt-cache engineering, ToolSearch, silky model-fallback switching, all grindable only because “we serve only one house”; the cost is fate-binding: vendor raises prices, rate-limits, model generation changes, the user has no exit, and non-house-model users are hard-excluded. Note that the “lock-and-go-deep” camp is now two houses: Anthropic-direction CC and xAI-direction grok-build, each taking their house model’s unique capabilities to the extreme. Go-wide’s user freedom and bargaining power are largest (local models can even keep data on-machine), but two taxes must be paid: one, adapter tax (thousands of lines of quirk code like transform.ts / home-grown registry, and never finished writing), two, least-common-denominator compromise—when some API has a unique capability, a multi-provider architecture either gives it up or writes a pile of conditionals; optimization depth is naturally limited.

Our evaluation (who it suits): if you are a heavy Claude user, there is nothing to agonize over—Claude Code has ground every detail around your model down to the bone. If you are a heavy Grok user and need multimedia generation or hours-scale long autonomous tasks, grok-build’s Goal Mode is currently the most mature explicit-state-machine scheme. If you are cost-sensitive, want free combination (cheap models for chores, strong models for hard attacks), or must privatize deploy, provider-agnostic is a hard need: for engineering rigor pick opencode, for local models pick hermes/CodeWhale/goose; to study “how to write an abstraction layer that is not cramped in a multi-model era,” transform.ts, hermes’s model-family custom prompts, and nanobot’s home-grown registry vs Raven’s LiteLLM split, are all the best textbooks. In the long run, whoever in the “go wide” camp first solves the contradiction of “depth optimization” versus “provider-agnostic” can eat both sides’ dividends.

7.1 What it actually is: one sentence and three numbers

Open Design (hereafter OD) is the open-source stand-in for Claude Design. Anthropic’s April 2026 Claude Design was the first time a large model directly delivered finished design artifacts, but it is closed-source, pure-cloud, locked to Anthropic’s models and skills. OD turns the same agent-native loop—discover the brief → lock a direction → stream output → review → deliver—into a filesystem any CLI agent can read.

7.2 One table to see how far its coordinates sit from the first nine

🧠 The most interesting point: CodeWhale (i.e. DeepSeek TUI, before the upstream rename), hermes-agent, opencode, grok-build, all analyzed in this series, all appear in OD’s runtimes/defs/ directory, each an object literal of a few hundred bytes to a few KB. Those tens-of-thousands-of-lines agents you have read, in OD’s eyes, are one argv-build rule plus one stream-format tag.

7.3 Three designs none of the first nine have

① Adapter-as-data: press the cost of “supporting N CLIs” from O(N) to O(1)

Among the first nine, whoever has to connect multiple backends (goose’s 52+ providers, nanobot’s ~40-house home-grown registry, Raven’s LiteLLM) is handling model providers—the protocol is highly homogeneous (all chat-completions). OD has to connect complete agent CLIs: 25 different argv conventions, 7 stdout formats, 3 session-resume mechanisms, permission flags all different.

Its solution is to write adapters as pure data objects (runtimes/types.ts:101-253, ~45 fields):

An adapter is not a class that implements the agent loop. It is a plain data object… There is no per-agent subclass and no run() / cancel() method to implement.

Of the 45 fields only buildArgs is a function, and it is pure (input prompt and options, output argv array). Probe, start, invoke, cancel, parse all live in the shared engine. Result:

• Adding a CLI of a known wire format = one object literal + one line in the registry; the smallest def is only hundreds of bytes
• Nine ACP adapters share the same transport
• Zero per-agent branches in the engine

Contrast goose’s “everything is an MCP extension”: goose unifies all capability into one protocol, at the cost that the outside world must first adapt to MCP; OD is the reverse—accept the outside world’s heterogeneity, absorb the difference with one layer of data spec. The former asks the ecosystem to accommodate itself; the latter accommodates the ecosystem.

② Turn “aesthetic quality” into a programmatic gate

This is a capability unique in this series. The first nine’s quality gates are all functional: tests pass, compile passes, tool-call format correct, P0 checklist all green. What OD does is “does this thing look like AI slop”:

Layer 1 lint-artifact.ts (1 000 lines / 16 rules)—drop subjective judgment into executable code:

The last is where the craft shows: letter-spacing: 1px is enough on 12px type (0.083em), far from enough on 48px type (0.021em), so font-size in the same rule must be converted; letter-spacing: var(--caps-tracking) must pierce token evaluation; light theme 0.08em, dark theme overridden to 0.02em must be judged separately. There is also a comment that is a textbook case of regex engineering—changing the character class from [^}]* to [^{}]* (match only the innermost rule), otherwise ALL-CAPS headings inside @media would miss the whole block.

Layer 2 Design Jury—five jurors (Designer / Critic / Brand / Accessibility / Copy) weighted composite, ships only at ≥8.0/10, at most 3 rounds. Two design decisions worth remembering:

• Designer weight is 0: “their dimensions are aesthetic preferences rather than ship gates”—keep the seat so qualitative opinion enters the record, but do not let subjective aesthetics block ship;
• Five jurors = five turns of the same CLI session, not five processes—“prevents the ‘panelist disagrees with itself across processes’ failure mode,” and auth/env/logs do not need five copies.

And neither layer hard-blocks: a P0 hit does not stop landing on disk; a review that misses the bar walks ship_best. This is the mature trade-off of “there is a gate, but it does not lock the user dead.”

③ Prompt cache-band ordering: take hermes’s “prefix is sacred” one step further

hermes-agent’s signature is prefix cache is sacred—never insert content in the middle of an already-cached prefix. OD on top of that does three more things:

1. Tag every segment by change frequency, split into four bands: globally static (designer charter) → session-stable (mode/locale) → project-stable (design system/skills/metadata) → turn-volatile (deck/media signal-triggered blocks);
2. The stability of the trigger signal decides the block’s position, not the importance of the content. The same “platform-contract block”: triggered by metadata fixed at project creation → project-stable band; triggered by conversation text (the user mid-flight says “change it to the iOS edition”) → must be pushed to the turn-volatile suffix, because “an early insert would break the cached prefix for every section after this line”;
3. Cache-hit attribution: describeStablePromptCache() on a miss diffs segment by segment which one drifted, and deliberately does not report full-set change in a “no baseline” situation—that would drown the signal you actually care about.

7.4 Its cost: three trade-offs heavier than the first nine

Trade-off 1: actively giving up the permission gate (unique in this series)

What OD feeds child processes: --permission-mode bypassPermissions (Claude) · --force (Cursor) · --permission-mode dangerous (Devin) · --yolo (Qoder/Trae) · --allow-all-tools (Copilot) · --auto (DeepSeek) · --dangerously-allow-all (Amp).

The reason is self-consistent: the daemon runs them in an environment with no TTY; an interactive approval prompt would hang the run dead. The docs are also frank: “The effective project cwd is an execution root, not a uniform Open Design sandbox… users must treat these runs as trusted agent execution.”

Its security budget is all spent on the boundary (loopback default + SSRF exact-host allowlist + short-lived single-use HMAC for desktop import + sandboxed iframe + .od-skills real copy rather than symlink), not on execution. Reasonable for personal local use; for team shared deploy, needs a very serious evaluation.

Trade-off 2: two prompt assemblers must stay byte-sync

Daemon-side prompts/system.ts (2 075 lines) and contracts-side (1 064 lines) are two independently implemented copies of the same semantics—the former serves local CLI execution, the latter serves BYOK direct connect. The repo has at least six comments reminding “keep both in sync” “keep this whole block BYTE-IDENTICAL.” This is known and explicitly managed technical debt, but it is real.

Trade-off 3: the content library’s volume itself is a maintenance burden

151 design-system packages × at least 3 files each, 164 skills, 115 templates, 277 official plugins, 183 examples—2 246 Markdown, 2 493 HTML, 322 MB. Quality guards are written in quantity (pnpm guard, pnpm lint:craft, package quality guards, derived-file consistency, token contracts, component fixtures, source evidence, preview coverage), but the speed of content rot and the speed of content growth are the same order of magnitude.

7.5 Updated position quadrant

quadrantChart
    title 十大 Agent 定位象限（Open Design 独占「宿主」区）
    x-axis 锁定单一厂商 --> provider 无关
    y-axis 终端程序 --> 本地基础设施
    quadrant-1 开放平台型
    quadrant-2 深度绑定的基础设施
    quadrant-3 单一厂商的极致工具
    quadrant-4 开放的终端工具
    "Claude Code": [0.12, 0.18]
    "grok-build": [0.10, 0.25]
    "CodeWhale": [0.72, 0.22]
    "opencode": [0.85, 0.68]
    "hermes-agent": [0.80, 0.78]
    "Raven": [0.68, 0.82]
    "nanobot": [0.75, 0.72]
    "goose": [0.90, 0.88]
    "OpenWorker": [0.82, 0.58]
    "Open Design": [0.96, 0.94]

Open Design lands in the far upper-right, and its “provider-agnostic” is agnostic of another order of magnitude: the other nine are agnostic of models; OD is agnostic of the entire agent.

7.6 Duel 6: “build the engine” or “build the socket”

Chapter 5 told five duels (permission route / context philosophy / ecosystem openness / architectural shape / model strategy). After Open Design joins, a sixth appears, and it is more fundamental than the first five.

To judge which of these two roads is right, one number is enough: OD’s adapter layer is only ~3 000 lines; the prompt assembler 2 000 lines + aesthetic linter 1 000 lines + 151 brand packages + 11 craft rules + 330 lines of behavior script. 80% of its engineering volume is spent on “what is good design,” only 20% on “how to call a CLI.” If your domain also has a body of “hard to put into words but can be encoded” expertise, building the socket is right; if not, what you build is only a shell.

7.7 Supplementary advice for beginners

Chapter 6 gave nine-house selection advice by audience. After adding OD, three more:

• What you want to build is a “content/experience” AI product (design, writing, data reports, PPT) → read Open Design first. It will tell you: do not start by writing the main loop.
• You are already building a coding agent and want to know how to let others integrate it → read OD’s runtimes/defs/ directory, see how others describe you. If your CLI does not support stdin-delivering the prompt, does not emit a structured stream, has no stable session-resume identifier, in this system you are “the hardest one to wait on” (see DeepSeek adapter’s triple Windows command-line guards).
• You are evaluating whether to deploy a design agent for a team → first read §7.4 trade-off 1. OD is the only project in this series with no execution-layer permission gate.

8.1 Origin: to read a fork, read the diff

This series has a precedent: Raven’s Python runtime forks nanobot, and the reading then was “look at later surgery against upstream.” MiMo × opencode is the same pattern, only the surgery amplitude is much larger—large enough to deserve a 19-chapter standalone analysis.

Scale: 5 222 files / 83.8 MB, 12.5k stars / 1.27k forks / 838 open issues, repo created 2026-06-10 (a month and a half). License MIT + a separate USE_RESTRICTIONS.md.

8.2 Its theme: do not trust the model’s self-report

Every house in this series has a sentence that can summarize its theme. MiMo’s is especially clear, because it was made into four layers, six devices:

flowchart TB
    subgraph S["步级（每一步都查）"]
        A1["空参数工具调用检测
软→硬 2 级"]
        A2["重复动作签名
键序归一化 + 排除叙述文本"]
        A3["文本复读 + n-gram
剥开场白后比对"]
    end
    subgraph T["回合级"]
        B1["步数上限：禁工具 + 强制交代"]
    end
    subgraph C["会话级"]
        C1["Goal 独立裁判
temperature=0 · 只读 transcript"]
        C2["Try-Best 检测器"]
    end
    subgraph D["产物级"]
        D1["checkpoint-validator + retry"]
    end
    S --> T --> C --> D

Depth comparison with the other ten:

8.3 Three designs none of the first ten have

① Goal independent judge: split “acceptance” and “construction” completely with two model calls

After /goal sets a stop condition, the main loop refuses to stop until an independent judge model has read the transcript and ruled the condition met (or genuinely impossible).

The judge is a separate model call that only reads the transcript — it does not do the work, so its verdict stays cold relative to the working agent's optimism. （session/goal.ts:17-21）

The most critical sentence in the judge prompt:

the assistant claiming the goal is impossible is evidence, not proof; independently confirm the condition is genuinely unachievable rather than deferring to the assistant's self-assessment.

Without this sentence, the model only has to say “this cannot be done” and the judge lets it through; the whole mechanism is dead.

Four matching escape hatches: fail-open (“a flaky judge can never trap the user”) · impossible · MAX_GOAL_REACT = 12 · only takes effect on the main agent.

🔍 Exactly the opposite of Open Design’s Design Jury: OD’s five jurors are five turns of the same session (share context to keep consistency, save auth and logs); MiMo’s judge is an independent call, deliberately not shared—because what it wants is “cold.” Same question, two correct answers in opposite directions.

② Take “reshape by model” from a prototype to the extreme (inherited + greatly expanded)

⚠️ Attribution must be said first: family-split prompt routing and the GPT tool-gating predicate expression both come from upstream OpenCode—treating them as Xiaomi originals is the most common misread. Item-by-item evidence is in MiMo Code source analysis Chapter 20 (a real file-level diff of both sides’ source).

Xiaomi’s real contribution is “walk this road to a place upstream did not walk”: add 5 families, rewrite the 3 highest-hit files, add dual-ID fallback (because its model ingest paths are far more than upstream), expand gating from “swap one screwdriver” to “swap a whole toolbox.”

The reason is aligning with the training distribution: Codex-family models in OpenAI’s own harness were trained on this ABI; giving them Claude-style tools instead makes them more likely to call wrong.

This is a frontal negation of the “universal harness” assumption:

The cost the docs themselves admit: prompt routing and tool routing are two independent string-rule sets, “not yet unified into a model-capability negotiation layer.” In live test gpt-oss-120b will show the inconsistency of prompt walking GPT, tool surface not GPT ABI.

③ Sandbox engine swap: acorn handwritten interpreter → QuickJS WASM (rewrite)

⚠️ The idea “run a script in a restricted sandbox to orchestrate tools” also comes from upstream (tool/code-mode.ts, tool name execute). But the implementation was wholly swapped, and this replacement itself is the engineering decision worth remembering:

Why it was worth swapping: a handwritten JS interpreter is a bottomless pit—every place not implemented is a behavior difference, every place implemented wrong may be an escape, and 3 465 lines have to be maintained long-term. After swapping a real engine, risk moves from “semantic correctness” to “resource management”; the latter has a determinate checklist, the former does not.

And expanding the exposure from MCP tools to host tools raises permission risk one grade—which is why it forced the matching design below:

And the boundary is stated clearly: “QuickJS only isolates exec code. bash is still a real shell, not a container sandbox.”

8.4 Several engineering details worth remembering on their own

This repo’s comment density is high; several details’ general value exceeds the project itself:

8.5 Updated position quadrant

quadrantChart
    title 十一大 Agent 定位象限
    x-axis 锁定单一厂商 --> provider 无关
    y-axis 终端程序 --> 本地基础设施
    quadrant-1 开放平台型
    quadrant-2 深度绑定的基础设施
    quadrant-3 单一厂商的极致工具
    quadrant-4 开放的终端工具
    "Claude Code": [0.12, 0.18]
    "grok-build": [0.10, 0.25]
    "CodeWhale": [0.72, 0.22]
    "MiMo Code": [0.78, 0.42]
    "opencode": [0.85, 0.68]
    "hermes-agent": [0.80, 0.78]
    "Raven": [0.68, 0.82]
    "nanobot": [0.75, 0.72]
    "goose": [0.90, 0.88]
    "OpenWorker": [0.82, 0.58]
    "Open Design": [0.96, 0.94]

MiMo Code lands down-left of opencode: equally provider-agnostic, but product center of gravity clearly closer to “terminal program.”

This displacement has hard evidence (based on a file-level diff of commit 076b790 vs upstream 62e4641; concrete numbers may have small deviations from different version-detection methods): MiMo substantially cut server/ and acp/ code volume, while significantly expanding cli/ (including i18n). The server ambition cut was doubled into terminal experience.

8.6 Duel 7: “universal harness” or “one shape per model”

Judgment basis: if your users will only use 1–2 frontier models, a universal harness is enough; if you seriously support a dozen families of uneven capability, “one prompt to rule them all” is burying with the weakest. The number of model families MiMo supports decided it had to walk the second road.

📌 Note that the two sides of this duel are actually “upstream vs downstream”: OpenCode already opened the family-split head (10 files), but its center of gravity is server and protocol; MiMo pushed the same road to 20 files and expanded to the tool surface. Same repo bloodline, two teams’ investment amplitude on the same question differs by an order of magnitude—this more than comparing it with unrelated projects shows where the marginal return of “reshape by model” sits.

8.7 Three trade-offs

8.8 An interesting ecosystem relationship

• Open Design treats mimo as an engine (it is one of OD’s 26 adapters, streamFormat: json-event-stream, MCP inject walks MIMOCODE_CONFIG_CONTENT)
• MiMo Code’s 26 built-in skills include claude-code, codex, grok-build—it can in turn call these external CLIs as tools (and only exposes them when the corresponding executable is already installed)
• MiMo’s memory index can be configured to include ~/.claude/projects—read Claude Code’s project memory; workflow and skills also scan .claude/ directories

🧠 In this ecosystem there is no absolute host and object. Every house is treating the others as tools, and being treated as a tool.

9.1 It belongs to none of the first eleven’s classes

A set of numbers that make the point: 8 months, 69 573 stars, real business code only 24 428 lines of Python. About 1 550 stars per thousand lines of code—Open Design about 20, MiMo Code about 3.

🧠 Its value is not in code volume. This is the series’ first sample of “the idea’s value far exceeds the engineering value.”

9.2 Three things none of the first eleven have done

① Knowledge graph ↔ simulation bidirectional closed loop

The first eleven’s memory systems (OpenWorker’s SQLite facts, MiMo’s FTS5, Raven’s EverOS dual-track, hermes’s closed-loop learning) are all unidirectional: the agent writes memory, the agent reads memory.

MiroFish’s graph is written together by a whole simulated world:

flowchart LR
    A["种子材料"] -->|本体+摄取| G[("Zep 时序图谱")]
    G -->|实体→人设| S["OASIS 模拟"]
    S -->|活动带帖子原文回写| G
    G -->|GraphRAG 检索| R["报告"]
    S -->|采访活着的 Agent| R

The two back-edges are the key. zep_graph_memory_updater.py batch-writes simulation activity carrying post original text back to the graph (BATCH_SIZE=5, counted per platform, MAX_EPISODE_CHARS=9_500). Without this back-edge, the report agent can only read “the world before simulation.”

② Interview agents that are still alive

The interview_agents docstring at zep_tools.py:1270 writes:

需要获取模拟 Agent 的真实回答（非 LLM 模拟）

This capability is jointly supported by three things: do not close the door when the run finishes (run_parallel_simulation.py explicitly writes “after completing the simulation do not immediately close the environment, enter wait-for-command mode”) + filesystem IPC interview channel (simulation_ipc.py) + LLM picking people and drafting questions (:1549 / :1632).

📌 Other multi-agent projects when done throw the log to an LLM to summarize; MiroFish lets the report agent go back and ask the people involved.

This is turning a one-shot process into a sustainably queryable asset—it turns the product from a “prediction-report generator” into an “explorable parallel world.”

③ Treat social-science parameters as core product config

The first eleven’s “config” is all engineering parameters: timeouts, concurrency, retry, token budget, permission grades.

MiroFish’s core config is sociological parameters:

Note the last three rows are two sets of values by platform. These five numbers turn “Twitter is fast and shallow, Reddit is slow and deep and more cliquey”—a judgment everyone has as intuition but is hard to quantify—into parameters that can drive a simulation, and the directions are all right.

🔑 Copying its 24 000 lines of code is easy; what you cannot copy is experience like “pre-dawn activity should be set 0.05, 22:00 to 23:00 should have a first-level intermediate step.”

9.3 It took “outsourcing” to the extreme

requirements.txt has only 12 packages in full. No LangChain (though the docstring writes that), no vector database, no message queue (uses filesystem IPC), no ORM.

Contrast Open Design’s practice is interesting—both are “do not build the engine yourself,” but in opposite directions:

🧠 Shared lesson: first validate the idea, then consider replacing dependencies. If the MiroFish team first spent half a year home-growing a simulation engine and a graph database, they might not have shipped even today.

9.4 Duel 8: “one very capable agent” or “a thousand agents that look very like people”

This school of MiroFish’s soft underbelly is very clear: it cannot be verified. Code a coding agent writes can run tests; a design agent’s output can pass a linter; “how Wuhan University public opinion will go” has no ground truth. Its persuasiveness can only come from explainability of process—you can see who said what in which round, how information spread, which node was the turning point, rather than a black-box conclusion.

This also explains why “do not close the door when the run finishes + can interview” is not icing; it is a necessity of this route: you cannot verify the result, so you must let the process be questionable.

9.5 Updated position quadrant (swap a pair of axes)

The previous chapters’ quadrant axes (provider lock-in / terminal vs infrastructure) do not apply to MiroFish at all. Swap two axes before it can sit:

quadrantChart
    title 十二大 Agent：Agent 数量 × 成功标准
    x-axis "少数 Agent，各司其职" --> "大量 Agent，平等互动"
    y-axis "追求任务正确" --> "追求现象逼真"
    quadrant-1 "群体智能 / 仿真"
    quadrant-2 "创作与生成"
    quadrant-3 "编码助手 / 工具型"
    quadrant-4 "编排与工作流"
    "Claude Code": [0.16, 0.14]
    "MiMo Code": [0.22, 0.11]
    "opencode": [0.13, 0.09]
    "grok-build": [0.11, 0.13]
    "goose": [0.19, 0.17]
    "CodeWhale": [0.14, 0.08]
    "hermes-agent": [0.24, 0.19]
    "nanobot": [0.21, 0.16]
    "Raven": [0.26, 0.28]
    "OpenWorker": [0.30, 0.22]
    "Open Design": [0.38, 0.64]
    "MiroFish": [0.90, 0.92]

The upper-right has only MiroFish one. This is not saying it is better; it is saying it is answering another question.

Eleven projects crowd the lower-left comparing whose agent is more capable—this itself is a signal: “emergent behavior of many mediocre agents” may be an empty lot nobody has seriously worked.

9.6 Its cost: several places looser than the first eleven

9.7 It has one place cleaner than all of the first eleven: full-stack i18n

This is an implementation unrelated to the theme, but worth copying away on its own.

locales/languages.json is a language registry (7 kinds, each with label and llmInstruction). Frontend i18n/index.js (27 lines) uses Vite glob to take the intersection of registry ∩ actual translation files, so the switcher only shows languages that actually have translations, will not show “selected but useless.” And backend utils/locale.py:8 walks '..','..','..' out of backend, reads the same directory.

llmInstruction is injected at 7 prompt-construction points—and every injection point is immediately followed by an exception “but these fields must be English”:

IMPORTANT: The 'stance' field value MUST be one of the English strings:
'supportive', 'opposing', 'neutral', 'observer'.
Only natural language text fields should use the specified language.

🔑 The easiest-to-step, hardest-to-debug pit of multilingual LLM apps: tell the model “answer in French,” it will write stance: "supportive" as "favorable", downstream if stance == 'supportive' mismatches directly—and it only appears when you switch off the default language.

Discipline: natural-language fields follow the user language; enum values, type names, field names are forever English. MiroFish wrote this exception at every injection point, missed none.

One JSON registry simultaneously drives frontend menu + backend logs + LLM output language + missing fallback, in total under 80 lines of code.

9.8 One sentence for whoever has read this far

The first eleven projects tell you how to make one agent well. The question MiroFish poses is:

If you do not use one very capable agent, but a thousand agents that look very like people, what can you do?

The answer is: you can, before the thing happens, run it through once.

Whether this answer is right, 8 months 69k stars gave a preliminary market judgment. But its real inspiration is—when everyone is optimizing a single agent’s capability ceiling, beside the track there may still be a whole empty lot nobody is standing on.

Writing notes: Chapters 1, 2, 5, 6’s facts rest on this repository’s nine single-project analysis documents (Claude Code deep dive, eight under 项目分析/, including the newly added grok-build source analysis and openworker source analysis); line-number citations are re-cited from those documents’ marks. Chapters 3 and 4’s technical details are a second deep-dig check of each source repo on that basis (covering language/runtime, streaming pipeline, persistence, concurrent cancel, error handling, business model six axes); newly added line numbers can be walked back to the corresponding commit: Claude Code (claude-code/src/), opencode (62e4641), hermes-agent (d9165d7), Raven (85c7a5b), CodeWhale (88a158e), goose (d17d65f), nanobot (6a9157f), grok-build (xai-org/grok-build), OpenWorker (andrewyng/openworker, db93d75, package name coworker). Wherever the second check “not found / uncertain,” this lecture never writes it as a determinate conclusion, or labels it as-is; no invention. Special note: OpenWorker is a “general-task colleague” rather than a coding agent; this lecture folds it in as a cross-border sample; some dimensions in a coding context (e.g. tool “scale,” prompt-cache “engineering”) have weaker comparability for it than the other eight, and its different emphasis is marked at the corresponding places. Chapter 7’s facts rest on open-design source analysis (nexu-io/open-design, commit c893b60, 2026-07-28); Chapter 8’s facts rest on MiMo Code source analysis (XiaomiMiMo/MiMo-Code, commit 076b790, 2026-07-27); Chapter 9’s facts rest on MiroFish source analysis (666ghj/MiroFish, commit 60757b3, 2026-07-23). All three documents have been checked file by file and marked file:line. Special note: MiroFish is not a coding agent, nor a “doing-work” agent; most dimensions of the first six chapters are not comparable for it, so Chapter 9 started another set of comparison axes and did not forcibly fold it into Chapter 1’s overview table. Projects iterate very fast; line numbers will drift in new versions, but module boundaries and design principles stay stable.