abtop: a terminal dashboard for Claude Code, Codex CLI and OpenCode sessions
Like htop, but for AI coding agents. Monitor Claude Code & Codex CLI sessions, tokens, context window, rate limits, and ports in real-time.
At a glance
- What is it?
- abtop is a Rust TUI that discovers local AI coding agent sessions from process and file state and shows token usage, context window percentage, rate limits, child processes and listening ports in one screen. It is read-only and needs no API keys, but its per-agent feature coverage is uneven and OpenCode support depends on an external sqlite3 binary.
- Who is it for?
- Adopt abtop if you routinely run several Claude Code or Codex CLI sessions across projects and want one read-only screen for context window percentage, rate limits and orphan ports; skip it if OpenCode is your only agent, since context window, current task and rate limit columns are unsupported there, or if you need load average on Windows, where the README states LOAD is reported as 0.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem abtop addresses: several agent sessions, no shared view
The README frames the motivation with four situations: running three or more agents across projects, hitting rate limits, an agent that spawned a server and never killed it, and a context window filling up. Each of those is normally answered by switching terminal windows or panes and reading whatever each agent CLI prints. abtop puts them on one screen. The audience is developers who already run Claude Code, Codex CLI or OpenCode as separate processes on the same machine, and who want to see session state without attaching to each one. The project describes itself as read-only, with no API keys and no auth, which sets the scope: it observes local state rather than talking to a provider. That also defines who it is not for, namely anyone who wants remote or hosted fleet monitoring, since discovery works from local process and file state.
How discovery works: process state, config roots and a SQLite file
The README states that Claude Code, Codex CLI and OpenCode sessions are discovered from local process and file state, which is what allows several active profiles to coexist on macOS, Linux and Windows. For Claude Code, the config directory is resolved automatically (on Windows from %USERPROFILE%\.claude), and abtop also auto-discovers ~/.claude and ~/.claude-* roots that contain both a sessions/ and a projects/ directory. Extra roots go in claude_config_dirs. OpenCode takes a different path entirely: abtop reads the local SQLite database at ~/.local/share/opencode/opencode.db, with %LOCALAPPDATA%\opencode and %APPDATA%\opencode probed as fallbacks on Windows, and that path requires the sqlite3 command in PATH. Ports come from process children, and on Windows the listening-port source is netstat -ano rather than a platform API. So the data flow is: enumerate agent processes, map them to config or database roots, read session records from those roots, then merge in child processes, ports and host metrics for display.
Feature coverage differs by agent, and the gaps matter
The support table is the most useful part of the README because it is honest about asymmetry. Claude Code has every row: session discovery, token tracking, context window percentage, status detection, current task, rate limit, git status, children and ports, subagents, and memory status. Codex CLI matches on discovery, tokens, context window, status, current task, rate limit, git status and children and ports, but has no subagent or memory status support. OpenCode gets only session discovery, token tracking, status detection, git status, and children and ports. Context window percentage, current task and rate limit are marked unsupported for OpenCode. If OpenCode is your primary agent, three of the columns that make abtop interesting are missing, and the sqlite3 dependency adds a failure mode the other two do not have.
Installing and running abtop
Three install paths are documented. The shell installer is curl --proto '=https' --tlsv1.2 -LsSf https://github.com/graykode/abtop/releases/latest/download/abtop-installer.sh | sh. Cargo users run cargo install abtop. Windows has a native PowerShell installer, powershell -c "irm https://github.com/graykode/abtop/releases/latest/download/abtop-installer.ps1 | iex", and pre-built binaries are on the releases page. The README notes that on Linux you should ensure sqlite3 is installed to enable OpenCode monitoring, and that on Windows OpenCode discovery needs winget install SQLite.SQLite; without it abtop prints a one-time warning to stderr. Running is a single command: abtop launches the TUI, abtop --once prints a snapshot and exits, abtop --json prints one JSON snapshot for scripts and tools, abtop --setup installs the rate limit collection hook, abtop --theme dracula picks a theme, and abtop --mouse enables click and scroll navigation. The recommended terminal is 120x40 or larger, with 80x24 as the minimum, and panels hide when the window is small. Mouse capture is off by default so terminal drag selection keeps working.
Configuration, themes and the keys you will actually press
Configuration lives at ~/.config/abtop/config.toml. Documented keys are theme, hidden_agents, claude_config_dirs and language. hidden_agents takes a case-insensitive list, so hidden_agents = ["codex"] hides Codex CLI from the view. claude_config_dirs takes extra profile roots such as ~/.claude-personal and ~/.claude-work-team. language accepts en or zh, and when it is unset abtop auto-detects from LANG, switching to Simplified Chinese for any value starting with zh. There are 12 built-in themes, four of them colorblind-friendly (high-contrast, protanopia, deuteranopia, tritanopia) plus light and white variants for bright terminals; t cycles themes at runtime and the choice is saved back to the config file. Key bindings are arrows or k and j to select, Enter to jump to the session terminal, x to kill the selected session, X to kill all orphan ports, 1 through 5 to toggle panel visibility, Esc for the config page, and q to quit. Terminal jump supports cmux, tmux and iTerm2 on macOS.
Where abtop stops being the right tool
The kill keys deserve attention. The README lists x for killing the selected session and X for killing all orphan ports, which sits awkwardly beside the project's read-only framing: the display is read-only, the key bindings are not. Treat X as destructive until you have watched which processes abtop classifies as orphaned. Platform limits are stated plainly: Windows has no load average, so LOAD is reported as 0, which makes that panel useless there. OpenCode users lose context window, current task and rate limit, and depend on an external sqlite3 binary that may be absent or shadowed in PATH. Discovery is local-state only, so a session inside a container or on a remote host will not appear. Finally, the minimum terminal size is 80x24 and panels hide below the recommended 120x40, so on a small split pane you are looking at a reduced view rather than a compact one.
Compared with btop, and with reading each agent's own output
The README positions abtop against btop, and the difference is the data source rather than the interface style. btop reads kernel counters: CPU, memory, disk and network. abtop reads agent-specific state: Claude Code and Codex session files, the OpenCode SQLite database, child processes and listening ports. That means abtop cannot show anything about a machine with no agent sessions running, and btop cannot show context window percentage or rate limit quota. The other alternative is the status line each agent already prints. Those are authoritative for the session you are looking at but require you to be in that window; abtop's value is the aggregate view and the orphan port list, not deeper per-session detail. If you only ever run one agent in one terminal, abtop adds a process and a rendering layer for information you already have on screen.
Licence, maintenance and what to check before adopting
abtop is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained; that is a summary of the identifier, not legal advice, and you should read the LICENSE file in the repository for the operative text. On maintenance, the material shows v0.5.1 on 2026-06-29, v0.5.2 on 2026-07-05 and v0.5.3 on 2026-07-07, with the last push to main on 2026-09-10, so the release cadence is recent and the branch is active rather than archived. The upgrade cost is low by design: cargo install abtop or re-run the installer script, and configuration is a single TOML file with four documented keys, so a theme or language choice survives upgrades. The real maintenance exposure is external. OpenCode discovery breaks if the database moves from ~/.local/share/opencode/opencode.db or if sqlite3 leaves PATH, and the per-agent feature table will drift as the agent CLIs change their on-disk formats.
Editorial conclusion
Adopt abtop if you routinely run several Claude Code or Codex CLI sessions across projects and want one read-only screen for context window percentage, rate limits and orphan ports; skip it if OpenCode is your only agent, since context window, current task and rate limit columns are unsupported there, or if you need load average on Windows, where the README states LOAD is reported as 0. Verify first that sqlite3 is on PATH if you want OpenCode discovery, that your Claude profile roots are either the auto-discovered ~/.claude and ~/.claude-* patterns or listed explicitly in claude_config_dirs, and that your terminal is at least 80x24.
Community notes