About insensical
Another terminal multiplexer. On purpose.
insensical: making no sense. in sensical: making sense. Same name, both meant.
insensical is a terminal multiplexer with a native window, built for running a bunch of coding agents at once and knowing which one needs you. Here's where the name comes from, what it is, why I built it, how it works and who it owes.
The name
One name, two opposite meanings.
I picked it for two reasons. Read it as one word and it says this makes no sense. Read it as two and the same name says it does.
1 · one word
insensical
in·sen·si·cal adjective
Making no sense; foolish, or absurd.
As in: building yet another terminal multiplexer when there are already so many out there. If that's what you're thinking, the name's already on your side.
2 · two words
insensical
in sen·si·cal what it's for
It makes sense to have a workspace for real multitasking, where you never lose track of any of it.
And the rule that comes with it: the parts, however entertaining individually, must cohere meaningfully. Floating panes, a dock, a sidebar, agent states. None of it counts until it adds up to one tool.
What it is
A server, a window and a command line.
You've got a lot of terminals and a lot of agents going, grouped into projects. insensical keeps them running, shows you what each one's up to, and tells you when one needs you. It runs on Linux and macOS, and it's free.
The daemon
A background server that owns every program and its terminal. Close the window and nothing stops. Open it again and it's all still there.
The window
Panes, tabs and splits are real interface elements, not characters drawn inside one terminal. A sidebar lists every project, its tabs and its panes, each with its state.
The command line
isc talks to the same server. Anything the window can do, a script can do too. No window needed.
Why it exists
Two problems the others leave with you.
01
Agents work in parallel. Your attention doesn't.
Run ten agents and you spend the day checking panes. Which one's done? Which one broke? Which one has been sitting there for twenty minutes waiting for a yes?
In insensical every pane tells you if its program is working, waiting for you, done or failed. The window counts the ones that need you, and one key jumps you to the most urgent.
02
A multiplexer shouldn't stand in the way.
tmux, zellij and screen read everything a program prints and draw it again as their own text, which your terminal then reads a second time. Your fast terminal ends up only as fast as the multiplexer in front of it.
And anything the multiplexer doesn't understand just gets dropped: notifications, progress reports, graphics, newer keyboard protocols.
The usual way
claude
prints its output
The multiplexerread once
reads it, then draws it again as its own text
Your terminalread twice
reads the redrawn copy, not the original
insensical
claude
prints its output
The daemon
passes the bytes on, untouched
The windowread once
reads exactly what the program wrote
How it works
It doesn't redraw your terminal.
insensical has its own window, so it never has to squeeze a program's output into someone else's terminal.
- 1
The daemon owns every program
It starts each program, holds its terminal, and is the only thing that writes to it. It keeps the layout too: your projects, their tabs and where every pane sits.
- 2
A window attaches with a snapshot
When a window opens, the daemon hands it each terminal as it stands, ready to draw. That's why the window opens instantly, no matter how long your programs have been running.
- 3
Then it gets the program's own bytes
After that, the window gets whatever each program prints, byte for byte, and keeps its own terminal from it. Nothing gets redrawn or re-encoded on the way, so nothing gets lost.
- 4
Each pane has one record of its state
Whatever an agent writes to its terminal and whatever its hooks report lands in one place per pane. The sidebar, the count and the notifications all read from it, so they never disagree.
Credit
It stands on Mitchell Hashimoto's work.
insensical wouldn't exist without three things he made and shared in the open: the engine every pane runs on, the design that inspired it, and the argument for building it this way in the first place. Thanks, Mitchell.
The engine
libghostty
Every pane in insensical is a terminal run by libghostty-vt, the engine inside Ghostty, which he created and which its contributors keep making better. Reading what a program prints, keeping the screen, the snapshot a window attaches with: all of that is theirs.
The inspiration
Superlogical
The architecture is inspired by the one he described for Superlogical: a server that owns each terminal, clients that each keep their own copy of it from the raw bytes, and panes that are native interface elements. insensical takes that idea and builds its own protocol, its own interface and its own take on projects and agents around it.
“A custom binary protocol where the server is maintaining N replica distributed terminal state machines.”
The argument
The post on performance
In the video where he walks through that architecture, he sets out what a multiplexer in the middle costs: every byte read twice, state kept twice, and a fast terminal held to the pace of the slower program in front of it. That's the case this whole project rests on.
Also. Parts of the interface take their cues from the design posts Alasdair Monk shared while building Superlogical, and the window is drawn with gpui, the toolkit from the makers of Zed.
To be clear. insensical is an independent project. It isn't affiliated with or endorsed by Mitchell Hashimoto, Ghostty or Superlogical, and its mistakes are its own.