Luvus: a Rust terminal multiplexer that watches your coding agents
Mission control for your AI agents
At a glance
- What is it?
- Luvus is a Rust workspace manager that keeps panes alive on a background server while tracking the state of Claude Code, Codex, Kimi and other coding agents. It is a strong fit if you already juggle several agents in terminals, and the wrong tool if you want a plain tmux replacement.
- Who is it for?
- Adopt Luvus if you already run several coding agents side by side and want their blocked, working, done or idle state visible in one TUI without wiring hooks yourself. Do not adopt it if you only need a plain multiplexer, or if your agents are not on the supported list, since live status detection is the whole point.
- Can I use it commercially?
- Yes. Apache-2.0 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 Rust, 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 Luvus targets: too many agents, no shared view
Running one coding agent in a terminal is easy. Running four of them across three projects is not. Each agent owns a pane, each pane has its own scrollback, and nothing tells you which agent is blocked waiting for input versus which one finished twenty minutes ago. Luvus is built for that specific situation. Its README calls it "Mission control for your AI coding agents", and the feature list is organised around the idea that a workspace, not a single shell, is the unit you manage. Persistent workspaces, agent awareness, worktrees, quality gates and a Git dashboard are all listed as first-class features. The target user is an engineer who already runs Claude Code, Codex, opencode, Kimi or similar tools and wants one place to see all of them. It is not aimed at someone who wants a faster shell prompt. The repository topics (agent-orchestration, coding-agents, workspace-manager) point the same way.
A background server holds the session, clients attach to it
The architecture described in the README separates the session from the terminal you are typing in. A background server keeps tabs, panes, layouts, terminal state and named sessions alive, so closing a client does not kill the work. That is the same split tmux and Zellij use, and it is what makes the remote story work: you can attach over SSH, and several clients can connect at once with independent viewport sizes. Agent state is layered on top. The README states that live status needs no agent integration, and the supported-agents table separates two levels of fidelity. Live status is available for every listed agent. Precise events, delivered through a hook, are marked only for Claude Code, GitHub Copilot CLI, Codex, opencode, Kimi, Grok and Oh My Pi. Antigravity CLI and Hermes CLI get session-only hook events. Pi, Muse Code, Fx, Cursor, Kilo Code, Devin and OpenCode 2 Preview show live status but no hook events. The table also marks session resume support, with a few agents limited to exact-ID resume or a resume command. That distinction between detection and precise events is the most important thing to read before you plan automation around Luvus.
Universal Harness Protocol and the module surfaces
Luvus exposes a versioned method registry it calls the Universal Harness Protocol, or UHP 1.0. The README describes it as the single registry for building harnesses and orchestrators, with owner-only local IPC, snapshots, event streams, exact input and semantic waits. Those five capabilities are what a script needs to drive an agent deterministically: read a snapshot of state, subscribe to events, send exact keystrokes, and wait for a semantic condition rather than sleeping and hoping. If you have ever written a shell loop that greps a log to guess whether an agent finished, semantic waits are the feature that replaces it. Around that, modules extend the interface with actions, events, settings, startup hooks, panes, sidebar docks and Top or Bottom Luvus Bar widgets. The interface itself is configurable: two sidebars you can move and resize, remappable keys and prefix, presets, 8 languages, and local or community themes. The orchestration features sit on the same base: worktrees, dependent task coordination, file path reservation, agent assignment, timezone-aware recurring schedules, quality gates and merge of completed work.
Installing and first commands
Installation is a one-line script per platform. On macOS and Linux the README gives curl -fsSL https://luvus.dev/install.sh | sh, with a Homebrew alternative of brew install RizRiyz/luvus/luvus. On Windows PowerShell it gives irm https://luvus.dev/install.ps1 | iex. A crates.io badge in the README points at the luvus crate, so a Cargo install path exists, though the README does not spell out the command. The quick start lists three commands: luvus to launch or reattach to your session, luvus doctor to check your setup for git, gh and ssh, and luvus update to check for and install a newer release. The workflow the README describes is short: run Luvus in a project, split a pane, and start an agent, which Luvus detects automatically. There is one platform-specific note worth heeding. On macOS you are told to disable Select the previous input source under System Settings, Keyboard, Keyboard Shortcuts, Input Sources to free Ctrl+Space. That is a real conflict with a default macOS binding, not a cosmetic tip. The README points to luvus.dev/docs for keybindings, modules, and the full CLI and API reference, so the exact key names for pane operations are not in the repository README itself.
Where Luvus stops being the right tool
The supported-agents table is the first limitation, and it is a hard one. Live status is listed for a long set of agents, but precise hook events are not. If your workflow depends on knowing exactly when an agent ran a command or edited a file, only Claude Code, GitHub Copilot CLI, Codex, opencode, Kimi, Grok and Oh My Pi are marked with precise events in the README. Antigravity CLI and Hermes CLI are marked session only. Pi, Muse Code, Fx, Cursor, Kilo Code, Devin and OpenCode 2 Preview are marked No. A second limitation is the table footer: Gemini, Aider, Amp, Droid, Qwen and Kiro get live status but no session resume. If resuming a long agent session matters to you, those tools will not give it through Luvus. Third, the README does not state memory or CPU overhead for the background server, nor does it describe what happens to running agents when the server is upgraded. A version bump in the server that owns terminal state is exactly the kind of event where you want a documented migration path, and the README only mentions migrate from previous releases as a feature bullet. Finally, if you do not run coding agents at all, the agent layer is dead weight and tmux or Zellij will do the same job with a smaller surface.
How it differs from tmux and Zellij
tmux and Zellij are the obvious comparison, and the difference is not the multiplexing. Both of those give you persistent sessions, splits and remote attach, which is most of what Luvus does at the terminal level. Luvus adds a layer that knows what is running inside the pane. The README lists blocked, working, done and idle as the detected states, along with session titles, tokens, cost and context use, plus optional sound alerts. It also lists a Git-aware file tree, a Git and GitHub dashboard for status, branches, commits, contributors, pull requests, issues and repository activity, and worktree orchestration with file path reservation and quality gates. None of that exists in tmux or Zellij, and it is not something you assemble from a status line script in an afternoon. The trade is scope. tmux is a general terminal tool that will outlive any particular agent vendor. Luvus is opinionated about the agent workflow, which is why it ships a table mapping each agent to its detection level. If your agents change every quarter, that table is a maintenance surface you inherit.
Maintenance, releases and the Apache-2.0 licence
The release cadence visible in the repository is fast. Three releases are listed between 2026-08-26 and 2026-09-01, roughly one every few days, and the last push is dated 2026-09-10. That pace is normal for a project at v0.13.x and it means you should expect to run luvus update regularly rather than pinning once and forgetting. The README provides luvus doctor for checking git, gh and ssh, which is the command to run first when something breaks after an upgrade. Development notes live in CONTRIBUTING.md, and contributors adding native agent support are pointed at a documentation page titled Adding Agent Support, which suggests agent integrations are expected to come from outside the core team. Security reports go through SECURITY.md. The licence is Apache-2.0, which permits commercial and private use and includes an express patent grant. That is the whole of what the supplied material supports on licensing; it says nothing about trademarks or about the separate licence terms of the agents Luvus drives, and those are questions for your own legal review rather than something this repository answers.
Editorial conclusion
Adopt Luvus if you already run several coding agents side by side and want their blocked, working, done or idle state visible in one TUI without wiring hooks yourself. Do not adopt it if you only need a plain multiplexer, or if your agents are not on the supported list, since live status detection is the whole point. Before committing, run luvus doctor to confirm git, gh and ssh are present, then check the supported-agents table for whether your agent gets precise hook events or only session-level detection, because that difference decides how much you can automate.
Community notes