Claude Code statusline: the number that's shared, and the one that isn't

Pane three shows 71% on the five hour limit, in red. You feel the small jolt of panic that number is built to cause, and you tab over to check pane one and pane two before you touch anything.

Both say 71%. Not close. Identical.

Nothing is broken. All three panes read the same clock: that is what the field actually is. Claude Code's status line reports some numbers per session and some for your whole account, on the same line, with no visual sign of which is which. Reading it correctly is the entire skill.

What actually lands in your Claude Code statusline

A status line is a script Claude Code runs for you and shows at the bottom of the interface. Configure it directly in ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

or generate the same file in plain language with /statusline show model name and context percentage with a progress bar.

Either way, Claude Code pipes a JSON object to your script's stdin and displays whatever it prints to stdout. That object carries far more than most scripts use: the model's name, current cost and duration, context window token counts, and, if you subscribe to Claude.ai Pro or Max, your rate limit usage.

That last one is where the trouble starts.

The rate limit number is not your session's alone

cost.total_cost_usd belongs to the session showing it: it accumulates call by call, resets to zero on /clear, and four panes showing four different honest numbers is exactly what four separate budgets should look like.

rate_limits.five_hour.used_percentage and its seven_day counterpart do not work that way. They report how much of your Claude.ai subscription's usage window you have burned, a window that belongs to the account, not the pane. Four Claude Code sessions signed into the same Pro or Max plan print the same percentage in every one, because all four are reading one shared clock.

Nothing in the line marks the difference: a cost figure and a rate limit figure sit side by side, formatted identically, one meaning "this pane" and the other meaning "everything you are running right now." Only the field name tells them apart.

The context window figures sit on the safe side: context_window.used_percentage is this session's own token load, unaffected by any other pane. It is the rate limit block specifically that crosses sessions, and also the one most likely to be red and urgent when it does.

What redraws the line, and what that costs you

The script does not run continuously. Claude Code triggers it on a new assistant message, when /compact finishes, on a permission or vim mode change, and on a refreshInterval timer if you set one. Rapid triggers debounce into one run 300ms later, and the whole thing runs locally: no API tokens spent.

That event model has one sharp edge. If your script shells out to git status or git diff on every redraw, a large repository makes it slow, and Claude Code cancels an in-flight script the moment a new trigger fires, so a heavy script can lose every race during a fast burst of messages and simply go dark. The documented fix is to cache expensive calls in a temp file keyed on session_id, not a process ID, since a fresh PID on every invocation would defeat the cache entirely.

One more failure mode has no error message: the status line needs the same workspace trust as hooks, and an untrusted folder just leaves the line blank until you run claude --debug to see why.

Subagent panels: several agents, one screen, still one engine

Claude Code ships one built-in answer to "show me more than one agent at a glance": subagentStatusLine. Configure it, and instead of the default name . description . token count row for each subagent in the panel under your prompt, your script controls it. It runs once per refresh tick, receives every visible subagent as one JSON object (width, plus a tasks array covering each one's model, tokens and context size), and writes back one line per row it wants to override.

It is genuinely useful, and scoped tightly: one coordinator, its own subagents, one terminal, one engine. It says nothing about the Codex session in your next tab or the Gemini session on a second monitor. The moment your fleet crosses a process boundary, this feature stops seeing it.

Where reading the status line goes wrong

A shared number reads like a private one. The instinct on seeing 71% in red is to protect that pane, when the number is actually telling you about every pane. The session you interrupt is rarely the one that earned the warning.

The model name on screen can go stale. It only repaints on the triggers above, so a mid-session model change or an --agent override will not show up until the next assistant message redraws the line.

A slow custom script fails silently. A non-zero exit or empty stdout leaves the row blank with no explanation, and a script that only lags under load can look fine in a quiet session and go dark exactly when several panes get busy at once.

There is no history, only a snapshot. Close the terminal and every number it showed is gone. Tools like ccstatusline reformat that same snapshot with more widgets; tools like ccusage rebuild a historical view from session transcripts afterward, precisely because the built-in line keeps none. The same one-glance limit applies to cost trends: a single line never shows the whole picture.

A grid that shows every session's line at once

A status line answers "what is true in this pane, right now." The moment you run more than one session, you are back to tabbing between terminals to collect that same answer several times, or building a tmux layout yourself to see them together.

SanuDesk is a desktop app built around that grid instead of asking you to assemble it. Your Claude Code, Codex and Gemini sessions tile side by side, so the state each one is in (mid-task, waiting on review, close to a limit) is something you glance at, not reconstruct pane by pane. A Kanban board sits beside the grid: deploy a card and it opens a fresh session already briefed. Recurring work becomes a Loop, journaled per run, and the whole thing is bring-your-own-model, so switching engines to dodge one account's shared clock costs nothing extra. The grid and board are in the free plan (see pricing).

Check whether your clock is shared, tonight

Open every Claude Code session you currently have running and type /statusline show the five hour and seven day rate limit percentage in each one.

If every pane lands on the same number, you have confirmed it yourself: one clock, however many sessions point at it, and a red warning in any one of them is a fleet-wide fact, not a pane-specific one. If the numbers differ, you are looking at more than one account or API key across those panes, worth knowing on its own.

Download SanuDesk free to see every session's state in one grid instead of four terminal tabs, or check how the grid, the board and Loops fit together on the features page.