Add MulmoTerminal to AI & Context Efficiency - #5
Conversation
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Thanks, this looks like a good fit for the list, and the proposed placement next to YYLO makes sense. Before I merge, could you please simplify the description a bit and avoid implying that all supported agents expose the same hook-driven Suggested wording:
I’d keep the current insertion point between YYLO and OrcaReplay. |
|
Thanks — you are right about Codex. It does not report blocked-on-input: its approval prompt is drawn in the TUI and never reaches the rollout file, so only Claude Code gets that state. My description was too broad. I used your wording as-is and kept the position between YYLO and OrcaReplay. |
Adding MulmoTerminal to
AI & Context Efficiency, next to YYLO and Orkas.Why this section: the efficiency it targets is attention, not CPU. When several coding agents run at once, the expensive part is not the model being slow — it is a session sitting on a permission prompt while you are looking at a different one. State comes from the CLI's own hooks (
PreToolUse/Stop/Notification), not from parsing scrollback, so "working" and "waiting on you" are different colours instead of both being "output stopped".Closest neighbours already here are YYLO (worktree per task) and Orkas (coordinating agents). This one is the supervision surface for the same kind of work.
MIT,
npx mulmoterminal@latest, ⭐ 213. Disclosure: I am one of the authors.🤖 Generated with Claude Code