Sokudo vs cmux
cmux gives your agents a native terminal with splits, notification rings, a scriptable browser, and SSH. Sokudo gives them a workplace: named personas on the providers you choose, a Kanban board with a reviewer, a Wiki Engine, and shared knowledge, rules, and memory that can grow from finished runs.
Reviewed · Published by Sokudo · Sources and scope
Pick Sokudo
When you want the workflow built in, not scripted.
Give each agent a name, a role, and a provider, then delegate tickets with dependencies and a reviewer. Every agent starts from the Wiki Engine, knowledge base, rules, and memory, and in workspaces where you turn it on, finished delegated runs can save what they learned and propose rules for your approval. Design on the canvas, query the database, and open SSH hosts in the same IDE.
Pick cmux
A terminal-first workspace you compose yourself.
cmux is a native terminal built on Ghostty, with vertical tabs, split panes, rings that show which agent needs you, a scriptable browser, and SSH workspaces. Launch a supported harness such as Claude Code teams through cmux, and each teammate it spawns appears as a native split. Its own README calls it a primitive, not a solution: the workflow is yours to build.
Where Sokudo pulls ahead.
Both run several coding agents at once, with a browser and remote machines close by. cmux builds outward from the terminal; Sokudo builds the team, the plan, and the project knowledge around it. Here is what each product describes.
| Criterion | Sokudo | cmux |
|---|---|---|
| What you get | An IDE with agents, design, data, and browser tools in one workspace. | A native macOS terminal built on Ghostty, with vertical tabs, split panes, notification rings when agents need attention, and a CLI for automation. [2] |
| Orchestration | Delegate tickets across providers, with implementation agents in their own worktrees and a reviewer. | Run a supported harness such as Claude Code teams through cmux, and the teammates it spawns appear as native splits with sidebar status and notifications. [5] |
| Personas | Custom agent roles, instructions, and model choices. | Runs any terminal agent, and its custom commands can launch one with preset flags. Named roles come from harnesses it integrates, such as oh-my-codex’s specialized agents; personas managed by cmux itself are not described. [7] |
| Work tracking | Kanban tickets, dependencies, and worker review in the IDE. | Each workspace tab shows its git branch, linked pull request, working directory, ports, and latest notification. A ticket board is not described. [3] |
| Wiki Engine | Citation-backed Pages and an interactive Graph of your codebase, read by you and your agents. | A generated codebase wiki is not described in cmux’s docs. [4] |
| Project context | A workspace knowledge base, rules, and memory that agents draw on in later sessions. | Vault searches past Codex, Claude Code, OpenCode, and Pi transcripts so you can bring an earlier session back. A cmux-managed knowledge base, rules, or memory store is not described. [9] |
| Self-improving harness | Finished runs can save learnings to the knowledge base and propose rules that wait for your approval. | A post-run learning loop is not described in cmux’s docs or changelog. [10] |
| Design canvas | Design screens and hand the canvas to agents in the same workspace. | Browser Design Mode lets you edit a page visually, annotate elements, and hand the changes to an agent. [10] |
| Database | Inspect schemas and query data in the database manager. | Database CLIs run in its terminals, and cmux.json commands can script routines such as resetting a local database. A built-in database client is not described. [11] |
| Remote work | Remote SSH sessions and commands alongside the workspace. | SSH workspaces whose browser panes route through the remote network, with agent notifications in your local sidebar and reconnects after drops. [12] |
| Browser | An in-app browser with extension support for previews and wallet flows. | A browser pane beside the terminal that agents can script: navigate, click, fill forms, evaluate JavaScript, and read the console. [14] |
“Not described” means the cited cmux pages do not document an equivalent feature; it does not prove the feature is impossible. Skills and harness integrations install separately. Sokudo capabilities: [1].
Open Sokudo when the job is bigger than a terminal.
Choose Sokudo if
- You delegate to named agents with distinct roles, instructions, and providers, rather than wiring up every run yourself.
- You want tickets, dependencies, implementation, and review on one Kanban board.
- You want every agent to start from a shared codebase wiki, knowledge base, rules, and memory.
- You want finished runs to save learnings and propose rules for you to approve.
- You want a design canvas and a database manager beside the code.
- You use SSH and want app previews with compatible browser extensions in the same IDE.
Choose cmux if
- You live in the terminal and want a native macOS app built on Ghostty that reads your existing Ghostty config.
- You run many agent sessions and want notification rings, unread badges, and a sidebar that show which one needs you.
- You want to script panes, input, and the browser from a CLI and socket API.
- You would rather compose your own workflow from primitives, skills, and custom commands than adopt a built-in process.
- You want free, GPL-licensed source you can inspect and build.
- You want persistent Cloud machines on a paid plan, or the cmux TUI on Linux or Windows: a terminal multiplexer separate from the Mac app.
What you actually get.
Straight answers about Sokudo and cmux.
What is the difference between Sokudo and cmux?
cmux is a native terminal built on Ghostty for running many coding agents: vertical tabs, split panes, notification rings when an agent needs you, a scriptable browser, SSH workspaces, and a CLI to automate all of it. Its own README calls it a primitive, not a solution. Sokudo builds the workflow in: named personas on the providers you pick, a Kanban board with dependencies and review, a Wiki Engine, a knowledge base, rules, and memory, a design canvas, and a database manager.
Can cmux orchestrate multiple agents?
Yes. When you launch a supported harness such as Claude Code teams or oh-my-opencode through cmux, the agents it spawns become native splits with sidebar status and notifications, so every agent in the run stays visible. Its CLI and socket API can also create workspaces, split panes, and send input. Sokudo delegates tickets to a roster of agents with roles, instructions, and models, and keeps implementation and review as separate steps on the board.
What is the Sokudo Wiki Engine?
The Wiki Engine maps your project into citation-backed Pages and an interactive Graph of files, dependencies, and modules. You use it to understand the architecture and how modules fit together. Your agents can search and read the same pages, so people and agents work from one shared guide to the codebase.
How does Sokudo keep project context for agents?
Each Sokudo workspace has three context stores. The knowledge base holds reference material such as architecture notes and conventions. Rules hold the instructions agents should follow. Memory holds durable decisions, preferences, and gotchas, found by meaning rather than keywords. Agents draw on all three in later sessions. cmux’s Vault lets you search past agent sessions by what was said in them and bring one back; its docs do not describe a cmux-managed knowledge base, rules, or memory store.
How does self-improvement work in Sokudo?
When self-improvement is on for a workspace, Sokudo reviews each delegated run after its agents finish. When a run produces something worth keeping, Sokudo saves it to the knowledge base or proposes a rule, and marks the entry as written by an agent. A proposed rule does not take effect until you approve it, and you can turn the feature off for any workspace. It changes the context your agents receive; it does not retrain any model.
Do both tools have a browser?
Yes. cmux splits a browser pane beside the terminal that agents can drive from its CLI: navigate, click, fill forms, evaluate JavaScript, and read console output. Its Browser Design Mode hands visual edits to an agent. Sokudo’s in-app browser previews the app beside the code and supports extensions, including compatible wallets.
Do both tools work with remote machines?
Yes. cmux ssh opens a workspace on a remote host, routes browser panes through its network, and sends agent notifications to your local sidebar. Remote tmux mirroring is in beta, and cmux Cloud adds persistent Linux machines on paid plans, in early access. Sokudo’s Remote SSH Manager keeps SSH sessions and commands alongside the workspace.
When should I choose cmux?
Choose cmux when you want a native terminal built on Ghostty, notifications that show which agent needs you, and a CLI that scripts its panes and browser, with skills that teach your agents to use it. Choose Sokudo when you want named agents, tickets with review, shared project knowledge, a design canvas, and a database manager in one workplace.
The workplace, not the window.
Give each agent a persona. Keep the board, the canvas, the database, the remote machine, and the browser in Sokudo.