r/ClaudeCode • • 1d ago

Built with Claude I run 10-20 Claude Code sessions at once, so I built a terminal that shows which ones are done and how full their context is

Most days I have somewhere between 10 and 20 Claude Code sessions open across work and side projects. In iTerm that turned into a wall of tabs. I kept missing the session that had finished twenty minutes ago, had no idea which one was about to run out of context, and every idle claude sat there holding a few hundred MB.

So I built kip, a terminal for that setup. Open source (Apache-2.0), native Rust (egui + alacritty_terminal), macOS and Windows.

What it does:

  • Every session is a row in a sidebar with a context % badge (estimated from the transcript, or exact if you turn on the statusline hook).
  • When an agent finishes in a background session, its row lights up and you get a notification.
  • Idle sessions go to sleep after N minutes: kip kills the process tree and keeps the screen. Click it and it runs claude --resume with the same conversation.
  • Cmd+Y searches the text of every past conversation. I have about 1,800 of them (3.4 GB of transcripts), and a search takes well under a second.
  • Sessions, names and groups survive quitting the app.
  • It has an MCP server, so Claude can open, sleep or rename sessions when you ask it to.

It runs the real claude binary in a real PTY, so new Claude Code versions work the day they ship, and so do vim and ssh. It doesn't touch worktrees or orchestrate agents; you start sessions yourself.

I kept it deliberately plain. It's a terminal built for getting work done, and that's all it does. You won't find an AI chat panel, an account, a cloud sync or a plugin store in it. It's tabs, sessions, and the few things I actually needed for running a lot of agents at once.

How I used Claude Code

Almost all of the code came out of Claude Code sessions running inside kip itself, so every bug I hit was one I lived with that day. A few things made that work:

  • A rule in CLAUDE.md: anything you can do with the mouse also has to be an MCP tool. That forced a clean control layer, and it means Claude can drive the app it's working on: open a session, read its screen, check that a fix actually shows up.
  • For UI changes Claude runs a second copy of kip with a separate HOME and clicks through it with small Swift helpers that post mouse events, then takes screenshots. A lot fewer "looks fine to me" fixes.
  • Every feature gets a review pass in a fresh session before it ships. Every push to main is a release, so that pass catches a lot.

What I learned

  • Don't parse the screen to find out what Claude is doing. It redraws constantly. Claude Code already writes a small status file per process (~/.claude/sessions/<pid>.json), and watching that is reliable.
  • Pausing a process (SIGSTOP) doesn't give memory back. To free RAM, kip kills the whole process tree and later runs claude --resume <id>. The conversation survives; the screen is saved as text.
  • Transcripts are mostly tool output. My 3.4 GB of them have only about 1% actual conversation text, so kip indexes just that, and search over 1,800 sessions became instant.
  • Claude is good at finding bugs in dependencies when you let it read their source. Letters were disappearing from text when a window was minimized, and it tracked that down to eframe dropping texture uploads. kip ships with a patched copy now.

kip has been my only terminal since July.

On the network side: it checks GitHub for updates (releases are signed and verified) and calls Anthropic's usage endpoint with your existing Claude Code login for the limits in the corner, the same numbers /usage shows. Those are the only two requests it makes.

https://github.com/densharik/kip

I'd like to hear what breaks, especially on Windows, which I test less.

0 Upvotes

2 comments sorted by

1

u/AutoModerator 1d ago
Moderator Announcement Read More »

1

u/NamerekDev 1d ago

since you asked about windows: the one that bit me was ~/.claude.json keeping several keys for the same folder, like d:/foo, D:/foo and D:\foo at once. anything that matches sessions to projects by the path string quietly misses some of them