Munder Difflin: A Local Harness That Turns Terminal Coding CLIs Into a Coordinated Agent Team
A local multi-agent harness that works with your existing Claude Code, Codex subscriptions, allows you to run an office of agents
At a glance
- What is it?
- Munder Difflin is an Electron desktop app that wraps existing terminal agent CLIs, gives each one a mailbox and memory, and puts a router agent called Michael in charge. It is for engineers who already pay for Claude Code or Codex and want parallel agents without a new API bill.
- Who is it for?
- Adopt Munder Difflin if you already hold Claude Code, Codex or similar subscriptions, want several agents working in parallel on one machine, and are comfortable running a pre-release desktop app. Do not adopt it if you need a headless, scriptable orchestrator for CI, or if you cannot accept that agent coordination depends on a router agent making judgement calls.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Subscription CLIs Do Not Talk to Each Other
A single Claude Code or Codex session is a conversation with one model in one terminal. If you want three tasks done at once you open three terminals, and then you are the router. You copy context between them, you decide which one handles what, and you remember what each one concluded. The subscription covers the tokens; it does not cover the coordination.
Munder Difflin targets exactly that gap. Its README describes the project as an "agent harness to run an office of your clones" and states that it wraps Claude Code, Codex, Gemini CLI, Qwen, OpenCode, Crush, Copilot CLI and others, running each as a real process in its own pseudo-terminal. The intended user is someone who already pays for one of those CLIs and wants parallel work without buying a separate agent API. The README is explicit that agents run "with your existing subscription and its hourly limits", so the cost model is your existing plan, not a per-token bill from a new provider.
What Actually Runs Under the Floor: node-pty, xterm.js and a Router
The architecture visible in the README is layered. At the bottom, each agent is a real CLI process spawned into a pseudo-terminal via node-pty. The README says sessions are "byte-for-byte authentic" and rendered with xterm.js, which means the app is not reimplementing the CLI's protocol. It is hosting the terminal.
Above that sits the coordination layer. According to the README, each agent gets long-term memory and a mailbox, a router moves messages between inboxes, and a GOD agent adjudicates and assigns work, escalating to you only when needed. The agent you talk to directly is Michael, described as your clone and the boss of the floor. On top of that is the visual layer: a Pixi.js office floor where sessions appear as avatars that walk to stations and where "envelopes fly desk-to-desk when they message each other".
The stack listed in the README is Electron, React, TypeScript, Pixi.js, xterm.js and node-pty. That combination tells you what kind of program this is: a desktop application with a terminal emulator and a 2D renderer, not a library you import. The README also points to a separate docs/ARCHITECTURE.md file for project structure, so the README itself is a summary rather than a complete specification.
Getting It Running: Download First, Build Only If You Want To
The README gives a direct path: a download link for macOS, Windows and Linux pointing at the latest GitHub release, with the note that macOS builds are signed and notarized and that you do not need to build from source. The repository is TypeScript with an Electron front end, and the README lists a CONTRIBUTING.md, so building from source is a contributor path rather than a prerequisite.
On the agent side, the README lists the CLIs it wraps: claude, agy, codex, grok, kimi, qwen, opencode, crush, pi and copilot, plus "any custom command". The implication is that the harness expects those binaries to be installed and authenticated on your machine already, since it runs them as processes rather than calling their APIs. The README also mentions bring-your-own keys and local models through Ollama, LM Studio or vLLM, which covers the case where you do not have a subscription CLI at all.
One thing the README does not spell out in the supplied text is the exact configuration format for registering a custom command or pointing an agent at a local model endpoint. If you need that before installing, the linked docs and the CHANGELOG are where to look. I cannot confirm the config keys from the material available here, and I am not going to invent them.
The Coordination Model Has a Single Point of Judgement
Michael, the clone agent, is the router. The README says he "routes work between them while you watch" and that the GOD agent adjudicates and assigns. That is a deliberate design choice, and it has a cost: the quality of the whole floor depends on the routing decisions of one agent. If Michael misreads a task, the wrong desk gets the envelope, and the failure is a coordination failure rather than a model failure.
The README frames this as a feature ("he's the boss of the floor; you're still the boss of him"), and for interactive work it probably is. But it means Munder Difflin is not a deterministic scheduler. You cannot write a rule that says task type X always goes to agent Y and expect the harness to honour it, at least not from anything the README describes. If your workflow needs auditable, repeatable dispatch, a plain script that launches CLI processes and pipes files between them will be more predictable, even though it will not have memory or a mailbox.
There is a second constraint implied by the design: every agent is a terminal process. That is what makes the harness work with subscriptions instead of API keys, but it also means each agent occupies a real process with real resource usage, and the README's own framing of agents "walking to stations" suggests a bounded floor rather than unlimited horizontal scaling.
Where the Visual Layer Helps and Where It Gets in the Way
The office floor is the most distinctive part of the project. Sessions become avatars, movement reflects work state, and messages appear as envelopes between desks. For a single developer running five or six agents, that is a genuine improvement over six terminal tabs, because it makes the state of each session visible at a glance.
The trade-off is that it is a GUI. The README describes a desktop app with a Command Center and a live agent terminal panel, and the whole product is built around watching the floor. There is no mention in the supplied material of a headless mode, a CLI entry point, or a server mode that would let you run the same orchestration inside CI or on a remote box. If your use case is "run this overnight on a build server and read a log in the morning", Munder Difflin as described is the wrong shape.
The README does include a Telemetry section, which is worth reading before you point it at private repositories. I cannot tell you from the supplied text what is collected or how to disable it, only that the project documents it. That is the first thing to check.
Compared With a Plain Script or a Hosted Orchestrator
The obvious alternative is a shell script that spawns several CLI processes with different prompts and writes their output to files. That approach is completely transparent, has no dependencies beyond the CLIs you already have, and costs nothing extra. What it lacks is exactly what Munder Difflin adds: agents that can message each other, memory that persists across sessions, and a router that can reassign work mid-flight. A script cannot do those things because each process is isolated by design.
The other alternative is a hosted orchestration framework that calls model APIs directly. Those give you programmatic control and reproducibility, and they scale beyond one machine. The difference in approach is fundamental: a hosted framework pays per token and requires API keys, while Munder Difflin runs your existing subscription CLIs as child processes and inherits their hourly limits. The README leans on that distinction heavily, describing the project as "free, open source and performant" and built to work "with the subscriptions you already pay for". If your subscription limits are generous, that is a real advantage. If you routinely hit those limits, the harness does not remove them, it just gives you more agents competing for the same quota.
Maintenance, Licence and the Pre-Release Question
The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice retained. That is permissive and unremarkable; it does not impose copyleft obligations on your own code. This is not legal advice, and if you plan to redistribute a modified build you should read the LICENSE file yourself.
The repository is not archived and the release history in the supplied material shows v0.5.2 in September 2026, following v0.4.6 and a v0.4.7-rc.2 release candidate in August. The README carries a status badge reading "pre-release". That combination, active releases plus a self-declared pre-release status, tells you the API surface and the app behaviour are still moving. Expect to re-check configuration after upgrades, and expect the CHANGELOG to be the document that matters when something breaks.
The maintenance cost that is easy to miss is the CLI layer. Munder Difflin wraps other people's tools. When Claude Code, Codex or Gemini CLI changes its terminal output or its flags, the harness has to follow. You are taking on a dependency on the release cadence of every CLI you enable, not just on this project's own cadence.
Who Should Install It and What to Check First
Munder Difflin fits a specific person: a developer who already runs one or more subscription coding CLIs, works on a desktop machine, and wants several agents cooperating on related tasks without writing glue code. The memory and mailbox features are the reason to choose it over opening more terminals, and the office floor is the reason it is pleasant to leave running.
It does not fit anyone who needs headless execution, deterministic task dispatch, or a guarantee that agent-to-agent messages follow a fixed protocol. The router is an agent, and agents make judgement calls.
Before installing, verify three things directly from the repository. First, confirm your CLI is on the supported list or that the custom command path works for it. Second, read the Telemetry section and decide whether the default is acceptable for the code you plan to point at it. Third, check the release notes for your platform, since the README states macOS builds are signed and notarized but does not make the same claim for Windows and Linux. If all three check out, the download link in the README is the fastest way in.
Editorial conclusion
Adopt Munder Difflin if you already hold Claude Code, Codex or similar subscriptions, want several agents working in parallel on one machine, and are comfortable running a pre-release desktop app. Do not adopt it if you need a headless, scriptable orchestrator for CI, or if you cannot accept that agent coordination depends on a router agent making judgement calls. Before installing, verify three things from the repository: that your CLI is on the supported list or can be added as a custom command, that the release for your platform is signed (the README states macOS builds are signed and notarized), and what the telemetry section of the README says about what is sent and how to turn it off.
Community notes