pixtuoid: a terminal pixel-art office that watches your coding agents
Terminal pixel-art office for AI coding agents
At a glance
- What is it?
- pixtuoid is a Rust TUI that renders each AI coding agent session as a pixel-art character in a shared office, so you can see who is working, who is blocked on a permission prompt and who finished. It is a monitoring surface, not an agent runner, and the README leaves several operational details unstated.
- Who is it for?
- Adopt pixtuoid if you routinely keep several agent CLI sessions open and lose track of which one is waiting on a permission prompt. Skip it if you run one agent at a time, or if your agent CLI is not in the Sources list, because the whole tool depends on hook wiring it cannot invent.
- 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 received new commits within the last day.
- 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 alt-tab problem pixtuoid is aimed at
The README frames the problem directly: running several coding agents means alt-tabbing between terminals to find out who is stuck, who is waiting on a permission prompt, and who finished ten minutes ago. That is a real cost when you drive three or four agent sessions in parallel, because a blocked agent burns wall-clock time doing nothing while you look at a different window. pixtuoid's answer is to collapse those sessions into one always-visible surface: an overhead pixel-art office where each session is a character at a desk. The audience is narrow and specific. It is for people who already run Claude Code, Codex, Antigravity or Reasonix in separate terminals and want a glanceable status board. It is not for someone running a single agent, and it is not an orchestration layer. Nothing in the README suggests pixtuoid starts, prompts or supervises an agent. It observes sessions that you launch yourself.
How a session becomes a character at a desk
The data flow is hook-based. You launch pixtuoid, press s to open the Sources panel, and connect an agent CLI; the README states that pixtuoid wires up the integration for you with no separate install step. From then on the agent CLI emits events through those hooks, and pixtuoid maps them onto the office. The mapping is visible in the feature list: a session gets its own desk, and when a floor fills up a new floor opens automatically. Characters type while the agent works, raise a question mark when it needs you, and doze under little z's when it is done. Each desk's monitor glows with the tool in use, with Edit blue, Bash orange and Read cyan. Movement uses A*-routed paths between desks, which is the one algorithmic detail the README gives about the rendering layer. The stack is Rust with ratatui, which fits a TUI that redraws continuously with animation. The colour scheme is derived rather than random: shirt and pants take their colours from the working directory, so the same repo always produces the same colours, and hair and skin vary per agent across 16 curated outfits. That is a deliberate design choice, and it is the kind of detail that makes the room readable as an org chart rather than as noise.
Getting it running: install, launch, connect
Two install paths are documented in the Quick Start. Homebrew covers Linux, macOS and WSL2: brew install pixtuoid. npm covers any OS: npm install -g pixtuoid. The README also points to Cargo, prebuilt binaries and Debian .deb packages on the install guide, but does not spell out those commands, so treat the Homebrew and npm lines as the ones you can copy verbatim. Launch is a bare pixtuoid. Then press s for the Sources panel and connect your agent CLI. In another terminal, start that coding agent; the README says a character walks in from the elevator within a second, and disconnecting in the same panel makes it walk back out. The keyboard surface is compact: q quits, p pauses, s opens sources and health, t cycles themes, m toggles sound with + and - for volume, Tab opens the agent dashboard, ? shows help, and the arrow keys, j/k or PageUp/PageDown move between floors. Clicking an agent brings its terminal to the front, or you can press f in the dashboard. When a source shows as connected but broken, the panel flags it and pixtuoid doctor produces a full health report. That doctor command is the first thing worth running after any connection.
The token meter and hover data are the genuinely useful part
The pixel art is the hook, but the instrumentation is what earns a place in a terminal. Paper stacks up on a desk as its session burns tokens, climbing through 250K, 2M and 16M tiers, with a fresh sheet dropped at a big spend and the exact total shown on hover. Hovering an agent also gives session duration, tool-call count and active-time percentage. Tab opens a collapsible tree of every floor's agents, each badged with the CLI it runs, colour-tinted by current activity, with tool-call counts. Read together, those three surfaces answer the questions that actually matter mid-session: which agent has been idle longest, which one is calling tools in a tight loop, and which one has quietly accumulated a large token bill. The active-time percentage is the most interesting number, because a session that has been open for an hour at 8 percent active time is a session that spent most of that hour waiting on something. The README does not explain how active time is computed, so I would treat the figure as indicative rather than exact until you have watched it against a session you understand well.
Where pixtuoid stops being the right tool
The dependency on hooks is the limitation that matters. pixtuoid does not read agent state from a process table or a log file; it relies on the agent CLI exposing hook events and on pixtuoid wiring them correctly. The README acknowledges failure in that path by noting that the Sources panel flags a source whose hooks are connected but broken. A connected-but-broken source is worse than a disconnected one, because the office will show you a character that is not tracking reality. The README also lists Claude Code, Codex, Antigravity and Reasonix with an ellipsis, and the badge links to a sources.json file on the site rather than naming a closed set, so the supported list is not fixed in the repository text. If your agent CLI is not among the sources pixtuoid can wire up, the tool has nothing to display. Two smaller constraints are worth noting. First, the character walks in within a second of the agent starting, which implies a polling or event latency you should expect rather than a hard real-time guarantee. Second, pixtuoid is a viewer: it cannot unblock an agent, approve a permission prompt or kill a runaway session. Clicking an agent brings its terminal to the front, and that is the extent of the control surface.
How this differs from the tmux-and-status-line approach
The obvious alternative is a multiplexer with a status line, typically tmux with a plugin that shows pane titles or a shell prompt that prints agent state. The difference is in what each one knows. A tmux status line can tell you a pane exists and what command it is running, because it observes the process tree. It cannot tell you that an agent is waiting on a permission prompt, or which tool it just called, because that information lives inside the agent's own event stream and never reaches the terminal. pixtuoid inverts the source of truth: it reads the agent's hook events and renders semantic state, which is why it can show a question mark for a blocked agent and a coloured monitor for the current tool. The cost of that inversion is coupling. A tmux status line works with any command you can run in a pane, including a plain shell or a test runner. pixtuoid only works with agent CLIs whose hooks it knows how to install. If your workflow is mostly non-agent processes, tmux is the broader tool. If your workflow is several agent sessions at once, tmux cannot see the state you care about.
Maintenance cost, release cadence and the MIT licence
The release history shows v0.16.0 in late July, v0.17.0 in mid August and v0.18.0 in early September, with the last push to main landing after the v0.18.0 tag. That is a fast minor-version cadence, and it has a practical consequence: the README's install block and feature table are generated from JSON files under site/src by a just gen-readme task, so the documentation tracks the code closely, but a tool moving this quickly can change config keys or panel behaviour between minor releases. Budget for reading the release notes before upgrading rather than assuming a drop-in replacement. The licence is MIT, which is permissive and places few obligations on how you use or redistribute the binary; it also means there is no warranty, and the README's Buy Me a Coffee link suggests the project is funded by donations rather than by a company with a support contract. Do not read that as a criticism, only as a signal about where to look for help: the site's architecture, configuration and contributing pages, plus the repository itself. I am not a lawyer and this is not legal advice, so check the LICENSE file and your own organisation's policy before vendoring or redistributing anything.
Editorial conclusion
Adopt pixtuoid if you routinely keep several agent CLI sessions open and lose track of which one is waiting on a permission prompt. Skip it if you run one agent at a time, or if your agent CLI is not in the Sources list, because the whole tool depends on hook wiring it cannot invent. Before trusting it, run pixtuoid doctor after connecting a source and confirm the hooks report as healthy rather than merely connected.
Community notes