10 — The Status Line — Keeping the Meter Visible at All Times

"Just terminal decoration" was my first read on the status line, and I ignored it until a runaway session. The reframe: the status line is a persistent, scriptable bar that surfaces the two things I need to watch continuously — live session cost and context fill — so I catch drift without running a diagnostic command. [1] It's observability for the loop, not cosmetics.

The framing that clicked is the contrast with /cost and /status. Those are snapshots — I run them, read a number, move on. The status line is the same information made _always-on_, pinned to the bottom of the terminal so the meter is in my peripheral vision the whole session [1][2]. Once I saw it that way, customizing it stopped being fiddly personalization and became a cost-and-quality practice: if context rot and runaway bills are the risks, the first defence is simply being able to see them happening.

The difference between a snapshot and an always-on readout is the difference between noticing drift and preventing it. /cost tells me what the damage is _after_ I remember to ask; the status line shows the meter moving _while_ the loop is running, which is the only moment when an intervention (/compact, a subagent delegation, a Ctrl+C) still helps.

What it shows, and why those things

The roadmap frames the status line as the place to keep essential data visible at all times — real-time session costs, context usage percentages — helping manage budget and context rot without manual diagnostic commands [1]. The segments worth pinning are exactly the two meters from the previous post:

• Context usage percentage. How full the window is. When this climbs past roughly 70-80%, I'm in the zone where /compact or a subagent delegation is overdue. Seeing it live means I react before quality degrades.
• Session cost. Live USD spend for the active session (on API billing). Watching this accrue is what makes a runaway session obvious — if a single task is burning dollars, something in the loop is re-reading too much.

Beyond those two, common segments are model name (so I know whether I'm on the cheap or the strong model), git branch (so the agent's edits land where I expect), and any project-specific signal I want to track.

The diagram is the whole discipline in one picture: four segments, but only one — the climbing context fill — is the one that should change my behavior in the moment. The rest are confirmations.

How it's customized

The status line is configurable through the status line settings — /status opens the dashboard, and the customization is documented in the status line docs [1][2]. The roadmap points at the bar as persistent (always at the bottom) and scriptable, which is the part that made it click for me: I'm not limited to a fixed set of readouts. A script can drive segments, so I can surface anything a shell can compute — a test-status indicator, a deploy lock, a custom metric from the project.

The practical discipline is the same as with CLAUDE.md: keep it short and load-bearing. A status bar with ten segments is noise; the value is in the two or three numbers I actually act on.

How I use this

The habit these notes left me with is treating the status line as my early-warning system, not my dashboard. I pin exactly three things: context fill percentage, session cost, and the active model. When context fill climbs, I compact or delegate; when cost climbs faster than the task warrants, I know the loop is re-reading something it shouldn't; when the model is wrong for the job, I see it and /model to switch. The bar means I almost never run /cost or /status mid-session anymore — the information is already in view, and catching drift early is the whole point.

References

[1] Anthropic, "Customize your status line," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/statusline

[2] Anthropic, "Interactive mode — /status, /statusline," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/interactive-mode