AgentDashboard

The problem it solves

Working with several AI coding agents at once has a hidden cost: usage limits. Claude and Codex both meter use in rolling windows, a short five-hour window and a longer weekly one, and when a window runs out the agent simply stops. Anyone who has watched an expensive agent session end halfway through a refactor knows the feeling. AgentDashboard exists to make that invisible number visible: how much of each window has been used, how much time has passed in it, and when it resets, next to the status of the code the agents are pushing.

It is a close sibling of the AgentBoard idea described on the Nodal site. AgentBoard is a file-based message board that lets agents coordinate without reading each other’s sessions, and the dashboard is the usage and CI column that sits beside that board. Over a few weeks the dashboard acquired three front ends: a browser version, a terminal version and, most recently, a mod for the Claude desktop app.

An illustration of the idea, not a screenshot: each meter is a bar for percent used with a white tick marking how much of the window’s time has elapsed. If the bar is ahead of the tick, you are spending faster than the clock.

What it shows

• Usage meters for both Claude and Codex, five-hour and weekly. Each meter shows the time to reset and the reset clock time (the weekly meter adds the day unless it is today).
• The time marker. A white tick shows how much of the window has elapsed, so you can tell at a glance whether a bar is on pace.
• Used-up limits. A bar that has hit its limit turns solid red and shows the reset time in large, slowly fading text, because that is the number you care about when you are blocked.
• CI status. The latest GitHub Actions run for each workflow and branch of the repositories you add to the configuration.
• Optional graphs of usage over time, and a sleep schedule so refreshes slow down when the numbers are not moving.

It spends no model usage to read these numbers. Codex reports its limits through its own local app server, Claude’s usage is read from the account’s usage view with a zero-token command to renew the sign-in, and CI comes from the GitHub command line tool. No tokens are written to the page or the data file.

Three front ends

1. In a browser (Firefox or Chrome)

The first version was the left column of the AgentBoard page. Open it in any browser and the dashboard refreshes usage and CI about every two minutes. The column can collapse to a thin strip that still shows each account’s highest meter and a master CI dot, and the setting is remembered per browser. A phone notification feature can send alerts about usage thresholds and resets, new posts on the board, interrupted agents and failing CI, using an open browser tab as the sender.

2. In a terminal (the CLI version)

The start script is itself a live dashboard: usage meters are pinned at the top and CI scrolls below. Time to reset appears on each meter, a bottom row counts down to the next refresh, and keys let you refresh now, scroll CI or quit. The window captures the mouse, so holding Shift selects text. A one-shot mode prints a single frame, which is what the tests use. Because it is only text, it runs in a small corner of a screen next to the agents it measures.

3. As a Claude desktop mod

The newest version brings the meters into the Claude desktop app itself, as a “mod”: a usage band above the prompt box and a sidebar pane. The mod ships with 43 band styles so the look can be matched to taste, and it reads the same data file as the other front ends, which means the dashboard process still has to be running to feed it. It is installed through a small local plugin marketplace, and its settings live in the mod’s own store, not in the dashboard’s. Several lessons came out of building it: the desktop app runs a cached copy of a mod, so every edit needs a version bump and a plugin update to show up; the app’s own content node has to be passed through the hook unchanged or the band disappears; and layout widths are measured in app-specific units that need to be measured, not guessed. Those are the kinds of details that make the extra documentation worthwhile.

Design choices worth stealing

• Cheap by design. An empty message-board check costs about 15 tokens, measured, because agents run a small script that prints only what they have not seen. The dashboard adds no model usage at all.
• Stale means grey. If the dashboard window is closed, the meters grey out as stale instead of showing old numbers as if they were live.
• Backoff when idle. Refresh intervals stretch when usage is flat or the account is asleep, and shrink as a limit approaches.
• Tested. The board has a self-test, run after every change, and the terminal frame can be printed for comparison.

Where it fits in the workflow

The dashboard exists to inform decisions the vibe-coding page describes: when to hand a mechanical job to a cheaper model, when to ask for a plan before running an expensive agent and when to stop for the day. The benchmarks use the same kind of accounting, measuring tokens and cost from real session transcripts rather than from the model’s self-reports.

It is a different tool from BroadcastHQ, which watches the broadcast rather than the agents, but they share the idea that a person working with automation needs a single glance to know what is happening.

Limitations

• It is built around two vendors’ agents and one operating system, so other tools need new adapters.
• The desktop mod depends on the app’s plugin interface, which may change.
• Usage windows are reported by the vendors in their own ways; the dashboard shows what it can read and says when a reading is missing.

To hear it discussed, watch a recent stream; the stream descriptions mention sharing “tips for skills and dashboards” and Claude’s mods feature, which is where this project fits.