Zellij vs tmux: The Modern Terminal Multiplexer

tmux has been the default terminal multiplexer for a decade and a half. It is battle-tested, universal, and unavoidable on any serious Linux box. It is also, depending on how much honesty you want, charmingly crusty or actively user-hostile: a config language derived from set commands, modal prefix keys that conflict with every shortcut in every editor, and a plugin ecosystem glued together by git clone into ~/.tmux/plugins. It works, but the UX has not aged gracefully.

Zellij is the attempt to rethink it. Written in Rust, shipped as a single binary, discoverable without a config file, scriptable with a real configuration language, and designed around WebAssembly plugins that can be written in any language that compiles to Wasm. It is the first multiplexer in a generation that takes the UX problem seriously, and in 2026 it has matured from “promising” to “I can replace tmux with this on my daily driver.”

This post is a practical side-by-side. What each tool actually does, where they differ, what workflows each is good at, and whether you should switch. Answer upfront: Zellij is a better tool for new users and for local development; tmux is still better for server-heavy, SSH-heavy, long-running session workflows. The interesting thing is how fast that second category is shrinking.

What a multiplexer does

Both tools solve the same three problems:

1. Multiple shells in one window. Split panes horizontally and vertically, tabs across the top, zoom a pane to full screen.
2. Session persistence. Detach from a session, close the terminal, come back later and reattach with everything still running.
3. Remote-safe shells. Start a multiplexer on a server over SSH, run a long job, drop the connection, the job keeps running.

The second and third features are why multiplexers matter. A bare terminal session dies when the connection drops. A tmux session running on a server survives network outages, laptop sleeps, and cross-building — you reattach and pick up where you left off. That model is the floor for any multiplexer; both tools clear it.

Everything else — the key bindings, the config language, the theme system, the plugins — is how they differ.

The 60-second comparison

That last row matters more than people admit. apt install tmux works on every Linux box everywhere back to 2010. Zellij often has to be added via a tarball, cargo install, or a third-party repo. If you SSH into a hundred machines, tmux is “already there”; Zellij is “I hope they added it.”

The UX gap: what Zellij does better

The flagship Zellij difference is the visible keybinding hints. Launch Zellij and the bottom of the screen shows a bar of modes — PANE, TAB, RESIZE, MOVE, SCROLL, SESSION — each with a key to enter it. Enter a mode and the bar updates to show the keys available in that mode. You don’t need a cheat sheet. You don’t need to memorize arcane prefix combinations. The tool teaches you itself.

This matters in three specific ways:

1. Beginners can actually use it. A new developer installs Zellij, launches it, and within ten minutes knows how to split panes, create tabs, resize, and switch between them. tmux requires a half-hour of reading and a few hours of muscle memory before you stop fumbling.
2. Intermittent users retain skill. Tools you use weekly but not daily (homelab admins, scientists, data folks) forget tmux bindings constantly. Zellij’s hints mean you don’t have to remember.
3. Pairing and remote support. Showing someone Zellij is frictionless — they see what you see. Showing someone tmux means teaching them the prefix sequence before anything makes sense.

The cost is visual noise. Experienced users dismiss the status bar (Ctrl-p z toggles zoom mode which hides chrome) because they’ve memorized the bindings. For them, the hints are clutter. Zellij knows this and is configurable.

Key bindings: the real friction point

tmux’s Ctrl-b prefix is historically awkward because it conflicts with readline’s move-back-one-character. Everyone remaps it. The usual remap is Ctrl-a, which conflicts with readline’s move-to-start-of-line. Everyone accepts this tradeoff.

Zellij defaults to direct modal keys without a prefix: Ctrl-p enters pane mode, Ctrl-t enters tab mode, Ctrl-s enters scroll mode. Press the mode key, then the action. The flow is:

Ctrl-p n   # new pane
Ctrl-p x   # close pane
Ctrl-t n   # new tab
Ctrl-t 2   # switch to tab 2
Ctrl-s     # scroll mode (then hjkl to scroll)
Ctrl-o d   # detach session

Better: Zellij has an optional non-colliding bindings preset that avoids interfering with common shell/editor shortcuts. And in the latest versions, there’s a “tmux mode” that emulates tmux bindings almost perfectly — dropping you into Zellij with Ctrl-b + the old keys all working. For tmux veterans, this is the path of least friction to switch.

Still, the honest truth: experienced tmux users will find Zellij’s defaults slower for the first few weeks, and in some workflows permanently. If your hands have encoded <prefix>% for vertical split over ten years, you don’t want to switch to Ctrl-p n any more than a vim user wants to use arrow keys. Zellij’s defaults are better for new users but not always for veterans.

Config languages: KDL vs set-option

tmux’s config is a pile of set-option, bind-key, and run-shell lines. It works but is not pleasant:

set -g prefix C-a
unbind C-b
bind C-a send-prefix

set -g status-bg colour234
set -g status-fg colour137
set -g status-left "#[fg=colour232,bg=colour154] #S "

bind | split-window -h
bind - split-window -v

Zellij uses KDL (KDL Document Language), a structured config format that reads more like a proper programming language:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

keybinds {
    normal {
        bind "Ctrl g" { SwitchToMode "Locked"; }
        bind "Ctrl p" { SwitchToMode "Pane"; }
    }
    pane {
        bind "n" { NewPane; SwitchToMode "Normal"; }
        bind "x" { CloseFocus; SwitchToMode "Normal"; }
    }
}

themes {
    dracula {
        fg 248 248 242
        bg 40 42 54
    }
}

default_layout "compact"

More verbose, but structured, validatable, and tool-friendly. The downside: KDL is a newer format, and every editor needs a plugin to syntax-highlight it.

The critical subjective difference: Zellij’s config is explorable. You can read config.kdl and roughly understand what each section does without a reference. tmux’s config reads like a shell pipeline of single-letter flags — fast for experts, opaque for everyone else.

Layouts: Zellij’s real superpower

Zellij’s killer feature — the one nothing in tmux-land really matches — is layouts. A layout is a declarative description of a workspace: panes, sizes, initial commands, tabs. You save it as ~/.config/zellij/layouts/project.kdl and open it with zellij --layout project.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

layout {
    tab name="edit" {
        pane split_direction="vertical" {
            pane command="nvim" { args "."; }
            pane split_direction="horizontal" {
                pane command="cargo" { args "watch" "-x" "test"; }
                pane command="htop"
            }
        }
    }
    tab name="logs" {
        pane command="tail" { args "-f" "logs/app.log"; }
    }
    tab name="shell"
}

One command, and you’re in a workspace with your editor open, tests auto-running, metrics in a side pane, logs in another tab. This is the concrete workflow improvement that tips “I should try Zellij” into “I shouldn’t go back.” tmux has tmuxinator, tmuxp, smug, and a half-dozen other external YAML-layout tools that do approximately the same thing — but they’re external and fragile, and Zellij’s built-in is better.

For multi-project daily workflows, this alone is worth the switch.

Floating panes

Another Zellij-native feature: floating panes. A pane that drifts over the others, good for quick edits, reference docs, or a scratch shell you want accessible without reorganizing your layout.

Ctrl-p w    # toggle floating pane

tmux has a similar concept via display-popup (added around tmux 3.2) but it’s a different mental model — popups are one-shot modals, not persistent floating workspaces. Zellij’s floating panes feel more like a desktop window manager; tmux popups feel like dialog boxes. Both useful, different purposes.

Session persistence: catching up

tmux’s session model is foundational: tmux new -s work, detach with Ctrl-b d, reattach with tmux attach -t work. Sessions survive network drops, reboots (with some plugins), and everything short of SSH server death.

Zellij historically lagged on this — sessions ran but didn’t survive a daemon crash. As of Zellij 0.40+ (2024), session resurrection works: reboot the machine, launch Zellij, and your sessions are rebuilt, including the layouts. For daily use this has closed the gap with tmux-plus-resurrect-plugin.

What tmux still does better:

• Shared sessions between users. tmux -S /tmp/pair attach is the foundational pair-programming mode. Zellij has a pair mode but it’s newer and less stable.
• SSH into an existing session on the server. With tmux, you SSH to a box, run tmux attach, and you’re in. Zellij on a remote server works but has quirks around terminal compatibility and status bar rendering that tmux simply doesn’t have.
• Running under every conceivable terminal. tmux in a serial console, in a screen -c wrapper, inside a container without a proper TTY — all fine. Zellij expects a modern terminal emulator and behaves worse in edge cases.

Plugins: the interesting future

tmux plugins are shell scripts loaded via TPM (Tmux Plugin Manager). Popular ones: tmux-resurrect, tmux-continuum, tmux-yank, themes like dracula, catppuccin. They’re all install-via-git, written-in-bash, sometimes-break-on-upgrade. The ecosystem is large and organically developed.

Zellij plugins are WebAssembly modules. You can write them in Rust, Go, TypeScript (via AssemblyScript), or any language that compiles to Wasm. The plugin API is principled — plugins receive events, emit render instructions, and have controlled access to the session.

This is a genuinely different model. Examples of what exists or is practical:

• Real status bar widgets with state, not just templated strings.
• In-session file pickers with tree views and search.
• Custom command palettes — think fzf-style fuzzy launchers integrated into the terminal.
• Git integration showing branch, dirty status, stash depth in the status bar with actual logic.
• AI integration plugins — some community plugins pipe selected text to a local LLM.

The catch: the ecosystem is smaller than tmux’s. If you want a popular niche tool (say, tmux-powerline), it probably exists for tmux, may not exist for Zellij, and building it yourself is a Rust-compile project rather than a shell script.

Performance

Both tools are fast enough that you won’t notice them at normal loads.

Under stress — yes | tee | head -n 10000000, a firehose of output — behavior diverges:

• tmux: handles high-throughput output gracefully, but can drop into visible frame-rate drops at extreme load.
• Zellij: smoother at high output rates thanks to a more modern rendering pipeline.
• Both: will make your terminal emulator the bottleneck before they become one themselves.

Memory: tmux uses a few MB per session; Zellij uses 20-50MB per session. For a multiplexer running one instance that’s fine. For someone running 30 tmux sessions on a 4GB VM over 3 years, tmux’s frugality is real.

Remote / SSH workflows

This is where tmux still has the clear edge, and it’s worth being specific:

• tmux attach is everywhere. Every distro has tmux. apt install tmux && tmux new -s mywork is universal muscle memory.
• SSH control mode (tmux -CC) integrates with iTerm2 natively. iTerm2 on macOS can talk to a remote tmux and render its panes as native iTerm tabs. Zellij has no equivalent.
• Lower-spec remote boxes. A $3/month VPS is fine for tmux. Running Zellij there works but noticeably uses more memory.
• Dotfile portability. A single .tmux.conf works on every system you’ve ever SSHed into. Zellij config needs the Zellij binary to exist, which is less universal.

If your primary workflow is “SSH into servers, run long jobs, detach, reattach,” tmux remains the pragmatic choice. It is not a better tool, but it is everywhere, and ubiquity is a feature.

The case for each tool

Use Zellij if:

• You’re a new developer picking a multiplexer for the first time.
• You work mostly locally — on your laptop, doing development.
• You want declarative layouts for your projects (one command and your workspace is set up).
• You enjoy modern Rust-based CLI tools (ripgrep, bat, fd, eza) and appreciate the UX consistency.
• You value discoverability over terseness.
• You don’t mind installing a binary on each machine.

Use tmux if:

• You SSH into many servers, many distros, many ages.
• You have a decade of tmux muscle memory and your workflow is centered on the prefix key.
• You need to share sessions with other users on a box.
• You use iTerm2 + tmux control mode.
• You run on low-memory VPS or containers where every MB matters.
• You maintain dotfiles that need to work on everything from a Raspberry Pi Zero to a beefy workstation.

The honest answer for most people in 2026: use Zellij on your laptop, use tmux on servers you SSH into. It costs you a single trivial key-mapping shift, and each tool plays to its strength. Nothing says you must pick one.

Migrating from tmux to Zellij

If you decide to switch, the minimum-viable migration:

1. Install Zellij: cargo install zellij, or brew install zellij, or your distro package.
2. Run zellij setup --generate-config > ~/.config/zellij/config.kdl to get a starting point.
3. Enable tmux-compatible keybindings: keybind_mode "tmux" in config.
4. Save one of your common workspaces as a layout.
5. Run Zellij for a week. Resist the urge to switch back when something feels odd — it usually turns out to be an improvement you hadn’t imagined.
6. At the end of the week, evaluate honestly. If tmux still serves you better, you lost nothing.

The reverse migration — going back — takes five minutes. Zellij doesn’t erase your .tmux.conf. It’s a low-risk experiment.

Things Zellij is still missing

In fairness, tmux still does some things better or at all:

• send-keys to scripting. tmux has a very mature send-keys command for scripting interactions. Zellij’s scripting story is improving but less comprehensive.
• Session sharing with permissions. tmux -S with socket permissions is how real pair programming happens on Unix boxes. Zellij’s story is less mature.
• Truly minimal footprint. tmux fits on a FreeBSD jail running on an embedded ARM board. Zellij expects more.
• Crash recovery in weird environments. tmux recovering from a kernel OOM, a partial disk-full, a fraying serial console — it just works. Zellij’s newer codebase hasn’t been exposed to those edge cases as much.

None of these are dealbreakers for a modern development machine, but they’re real. The direction of travel is positive — Zellij closes gaps every release — but you should pick with today’s feature set in mind, not the roadmap.

A note on screen, Byobu, and friends

screen is the original terminal multiplexer from 1987. It still exists and still works. For a few specific use cases (the absolute minimum dependency footprint, ancient AIX/HP-UX boxes), it remains relevant. For daily development in 2026, it shouldn’t be your first choice.

Byobu is a friendly wrapper that can drive either screen or tmux as a backend. It’s tmux-with-training-wheels. If Zellij hadn’t appeared, Byobu might have been the UX-focused multiplexer winner. In the current landscape, Byobu serves a niche where you need tmux’s ubiquity but want a beginner-friendlier default config.

Closing

The multiplexer wars are not that dramatic. tmux is great. Zellij is great. Nothing is stopping you from using both, and a lot of people do. What matters is having an intentional default instead of suffering through whatever happens to be installed.

If you’ve been using tmux for years and it works for you — keep using tmux. There’s no prize for switching tools.

If you haven’t picked a multiplexer yet, start with Zellij. The discoverability alone will save you more time than you’d spend learning either tool from scratch.

If you do both — local dev and remote server work — use Zellij locally, use tmux on servers, and enjoy having the right tool for each context. That’s probably where the community settles within the next few years anyway. Zellij inherits the future of local development multiplexing; tmux keeps its place as the universal, unkillable server companion. Both are good news.