I'm building Kumo, a terminal multiplexer for the AI agent era

A developer has built Kumo, an open-source terminal multiplexer written in Rust and designed specifically for managing AI coding agents. The tool features a sidebar that lists running agents with status indicators, native text selection via a custom VT emulator, and audio alerts when agents block or finish. The project aims to provide a familiar terminal experience similar to Ghostty plus tmux while adding agent-specific workflow enhancements.

Hey I've been building something in Rust these past few weeks and I wanted to share it. It's called Kumo — that's 蜘蛛, spider in Japanese — and it's a terminal multiplexer built around AI agents. I work with AI agents a lot. opencode , claude , tried qwen . I'd have a couple of them working on different parts of a problem, and there was no easy way to keep an eye on them all. Are they still running? Blocked waiting for my approval? Finished? I was switching between windows, squinting at terminals, losing track of who was doing what. So I built one. To be fair, the multiplexer space is in great shape right now. There's herdr , cmux , amux , and friends, plus classics like tmux and zellij that people swear by. And then there's superlogical https://www.superlogical.com/ , Mitchell Hashimoto's new company — the same Mitchell who made Ghostty. I'm a fan of their work. I've tried a bunch of these and they're all good at what they do. It's just that I never felt 100% at home with them — none of them gave me that feeling I get from my own setup of Ghostty + tmux + LazyVim . That combo just feels like my terminal, you know? Warm, familiar, exactly where I want things to be. So Kumo wasn't born as a "better tmux." It started as an attempt to get that same familiar feeling, plus a couple of things I wished existed. A few design choices I ended up caring a lot about: Quick primer: by "agents" I mean AI coding agents — the CLIs you run in a terminal, like opencode or claude , that edit files, run commands, and every so often stop to ask permission before doing something. That's what "blocked" means here. The basics are all there: split panes, sessions, tabs, real text selection. But the heart of it is the sidebar , which lists every running agent with its workspace and a status dot: When an agent blocks or finishes, Kumo pings you with a sound — a distinct chime for each. Blocked agents float to the top and their pane glows orange, so you only get pulled in when you're actually needed. I didn't want to fake the terminal. Each pane is a genuine VT/xterm emulator powered by libghostty-vt — Ghostty's headless terminal core, vendored and compiled at build time. Shells, TUIs, full-screen apps behave exactly like in a native terminal. With portable-pty on the PTY side, drag-to-select works even inside apps that own the mouse, like opencode's own TUI or vim. It's one Rust binary, one TUI on ratatui . Here's the weirdest rabbit hole of the whole project — and honestly, the biggest pain in my ass. Real terminals have a quiet war going on over your mouse. Apps can enable something called mouse reporting — when they do, they own the mouse. Drags are meant for their text selection, not yours. It's why selecting text in vim or less feels different from selecting it in a plain shell. I wanted native selection everywhere: drag, select, copy on release, like a real terminal. So Kumo does both: And the sneaky trick that makes it all work: panes present themselves as plain xterm-256color , advertising no mouse capabilities at all a tiny custom responder . So apps don't hijack your mouse unless they really need it, and native selection just works. The bugs were fun too. Forwarded mouse events kept arriving with a trailing reset escape that apps would choke on — one character to fix, one afternoon to find. And selection was being read from a stale cached view instead of a fresh viewport snapshot, so the highlight wouldn't hug the text like a real terminal. Little things like that, but each one taught me something about how terminals actually think. Honestly? A big chunk of this was vibe-coded — me describing what I wanted to DeepSeek V4 Flash and reading every line it produced as it went. But the real goal was never the product. It was learning: SIGWINCH — building Kumo meant touching all of it.That's the middle ground I've settled into: not trusting it blindly, not writing every byte by hand. Enough understanding to review, enough trust to let it write the first draft. But the main idea is done: a product I feel comfortable using every day, and a way to keep learning while I develop it. That's the whole point for me. It's early days and very opinionated. Right now opencode and claude have full lifecycle detection; other agents are auto-detected but shown as idle. Keybindings are hard-coded remapping is on the roadmap , and a detach/re-attach server is coming. If that sounds interesting, check out the repo at github.com/marcrdgz/kumo https://github.com/marcrdgz/kumo . I'm sharing this because building it has been genuinely fun, and I'd love for you to try it too.