cd /news/developer-tools/i-m-building-kumo-a-terminal-multipl… Β· home β€Ί topics β€Ί developer-tools β€Ί article
[ARTICLE Β· art-91034] src=dev.to β†— pub= topic=developer-tools verified=true sentiment=↑ positive

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.

read4 min views1 publishedAug 10, 2026

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, 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. I'm sharing this because building it has been genuinely fun, and I'd love for you to try it too.

── more in #developer-tools 4 stories Β· sorted by recency
── more on @kumo 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain β€” perfect for shipping the agent you just read about.

$git push zahid main
β†’ Live at https://your-agent.zahid.host βœ“
Get free account β†’ Pricing
from €0/mo Β· no card required
LIVE [news/i-m-building-kumo-a-…] indexed:0 read:4min 2026-08-10 Β· β€”