For a long time, one terminal was enough. You’d open your repository, launch Claude Code or Codex, assign it a task, and wait for the result. If another important task came up, you’d interrupt the current work or open a second window.
That model starts breaking down when agents stop being interactive assistants and become independent workers.
Today it’s perfectly reasonable to want one agent implementing a new feature while another updates the tests, a third reviews the generated code, and a fourth prepares the documentation. The problem is that very few tools were designed to coordinate that scenario. Most simply assume you’re going to run one agent per terminal.
That’s where Mux comes in.
It doesn’t try to replace Claude Code, Codex, or Gemini CLI. It doesn’t introduce its own model either. Its goal is far more interesting: to become the layer that organizes multiple agents working simultaneously on the same project.
The new bottleneck is no longer the model
Just a few months ago the conversation revolved around which model programmed best.
Claude?
Codex?
Gemini?
OpenAI?
Today that question remains important, but it’s starting to lose prominence to another far more practical one:
How do you coordinate five agents working simultaneously without turning your repository into a mess?
Opening five terminals works… for a while.
Then the problems start.
- Which agent is modifying which files?
- What branch is each one working on?
- Which one finished first?
- Which one broke the tests?
- Where did that session that had been running for two hours end up?
It’s not an artificial intelligence problem.
It’s an orchestration problem.
Mux is not another coding agent
That’s probably the most important point of the project.
Mux doesn’t try to compete with the tools you already use.
Instead of creating a new agent, it manages the ones that already exist.
Currently it can work with tools like:
- Claude Code
- Codex
- Gemini CLI
- OpenAI-compatible models
- Ollama
- OpenRouter
The idea is quite simple.
Instead of opening multiple terminals manually, Mux creates an environment where each agent gets its own workspace, maintains its independent context, and can run in parallel with the others.
The developer stops managing windows and starts managing work.
Each agent gets its own workspace
This is probably the feature that best explains the philosophy of the project.
Imagine you receive a relatively large issue.
In a traditional workflow you’d probably do the tasks one after another.
- Implement the feature.
- Fix the tests.
- Update the documentation.
- Review the code before merging.
With Mux you can assign each task to a different agent.
Workspace A
New feature
Workspace B
Tests
Workspace C
Documentation
Workspace D
Code Review
They all work independently.
None steps on the other’s work.
And you can review the results when they’re actually ready.
That change seems small, but it completely modifies the relationship between the developer and the agents.
You’re no longer directing a conversation.
You’re coordinating a team.
Git Worktrees: the piece that makes all this possible
One of the least known concepts in Git is Worktrees.
Many developers still solve parallel tasks by cloning the same repository multiple times.
Git has been offering a much more elegant alternative for years.
Worktrees let you create multiple working directories that share the same repository history but maintain completely independent branches.
Each agent gets its own environment without needing to duplicate hundreds of megabytes of code.
That means:
- less disk space used;
- less time setting up environments;
- less risk of two agents accidentally modifying the same files.
Mux leverages that capability as a foundation for running multiple agents simultaneously.
Instead of improvising a solution on top of Git, it uses a feature designed precisely for this kind of workflow.
Code review can also be another agent’s job
A particularly interesting feature is that the review process no longer depends exclusively on the developer.
A possible workflow could look like this:
- One agent implements the feature.
- Another agent reviews the generated code.
- A third searches for possible security or quality issues.
- The developer only makes the final decision.
It doesn’t eliminate human review.
It shifts it towards the end of the process, when there’s already a first layer of automatic validation.
It’s an approach much closer to how engineering teams work than simply asking the same agent to do everything.
Running agents outside your machine
Another interesting aspect is support for remote execution.
Not all projects need to run on the same computer where we write code.
Mux lets you use other machines via SSH, which opens up interesting scenarios:
- a dedicated workstation;
- a server with more CPU;
- a machine with GPU;
- a machine shared by the engineering team.
From the developer’s perspective, the workflow barely changes.
The agents still appear within the same work environment.
They’re just running somewhere else.
Installation
Installation is pretty straightforward.
With Homebrew:
brew install coder/tap/mux
Binaries for macOS and Linux are also available from the official repository.
Once installed:
mux login
Then you can create a project:
mux create
And start launching agents from the Mux interface.
The official documentation includes examples for configuring different providers, managing workspaces, running remote agents, and connecting local models via Ollama.
A workflow much closer to a team than to a chatbot
Imagine a fairly everyday case.
A new issue arrives from GitHub.
Instead of opening Claude Code and waiting for it to do everything, you decide to divide the work.
One agent implements the main feature.
Another updates the test suite.
A third reviews the code looking for possible errors.
Meanwhile, a fourth prepares the documentation for the Pull Request.
You’re not writing code during all that time.
You’re not constantly supervising each agent either.
You’re coordinating work.
That small shift in perspective is probably the most interesting part of Mux.
Is it worth it?
Mux is still a young project and will likely evolve rapidly.
Like any new tool, it involves learning a different way of working and probably doesn’t make sense for very small projects or for those still using a single agent occasionally.
But if you’re already using Claude Code, Codex, Gemini CLI, or similar tools intensively, the problem it tries to solve starts to feel surprisingly real.
It’s not an IDE.
It’s not another agent framework.
It’s not a new model.
It’s a coordination layer for a world where running several agents at the same time is starting to be completely normal.
And maybe that’s the most interesting signal of all.
The next evolution of coding agents doesn’t consist only in them being smarter.
It consists in learning to work together.