abtop

If you’ve ever opened three terminal windows running three Claude Code sessions and lost track of which one is stuck, which one is bleeding tokens, and which one is about to hit a rate limit, abtop is the dashboard you wanted. It’s a Rust TUI built explicitly on the btop / htop pattern: real-time, dense, keyboard-driven, and read-only.

The thing the project gets right that most observability tools don’t is that it never asks for an API key. It looks at local process state and session files only - there is no “log into the dashboard” step, no key in a config file, nothing to leak.

How it discovers sessions

The data path is local-first by design:

• Open files and processes via ps and lsof to find which agent CLIs are running where.
• Session metadata read from disk - tool names and file paths are surfaced; the contents of prompts and files are never displayed.
• The only indirect network call is claude --print, used to summarise active Claude Code sessions.

That last point matters - it means abtop’s Claude Code panel is always one shell-out away from the truth, not a snapshot from when you launched the dashboard.

What it shows

Per session, the panels expose:

• Token usage - cumulative + delta, per session
• Context window % with warnings as you approach the cap
• Rate limit quotas in real time
• Open ports - useful for spotting orphaned dev servers an agent forgot to clean up
• Child processes - the tree of subprocesses each session spawned
• Git status - dirty / clean / branch
• Current task - what the session is working on
• Status detection - running / waiting for input / idle / error
• Memory status (Claude Code only)

Coverage today is Claude Code and Codex. Subagents and the memory panel are Claude Code only - Codex doesn’t expose the same hooks yet.

Quick start

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/graykode/abtop/releases/latest/download/abtop-installer.sh | sh

Or via Cargo:

cargo install abtop

Pre-built binaries are on the GitHub Releases page if you’d rather pin a version.

The author recommends a 120x40 terminal. Anything below 80x24 and panels start hiding themselves to fit.

Hotkeys

• ↑ / ↓ or k / j - select session
• Enter - jump into the selected session (works only inside tmux)
• x - kill the selected session
• X - kill all orphan ports
• t - cycle theme
• 1 through 5 - toggle individual panel visibility
• Esc - open / close config
• q - quit

The Enter jump and the tmux dependency that comes with it is the killer feature for anyone running multiple agents under tmux - it turns the dashboard into a navigation layer over your existing session topology.

When to reach for it

• You routinely run more than two agents in parallel.
• You want to spot stuck or rate-limited sessions before they cost you another hour.
• You’re already running everything inside tmux - abtop layers on top cleanly.

When not to

• Single-session workflows. The dashboard’s value scales with session count; one agent doesn’t need a control plane.
• Native Windows. WSL works, native does not - the project leans on POSIX process handling.
• Codex-only setups, if you specifically wanted memory or subagent visibility - those panels are Claude Code only.

Limits worth knowing

The orphan-port detection (X to kill them all) is the kind of nuke-from-orbit feature that’s wonderful right up until the moment it kills the dev server you actually wanted. Triple-check before you press capital-X.

There’s no historical view - abtop is a real-time monitor, not a metrics store. If you want trends over time, pair it with a tool that reads session files directly (Codeburn is the obvious counterpart).