--- title: "10 — The Status Line — Keeping the Meter Visible at All Times" uid: customize-status-line tags: ["observability", "status-line", "roadmap:claude-code", "ui", "terminal", "claude-code"] excerpt: "The status line is observability for the loop, not cosmetics: a persistent, scriptable bar surfacing live cost and context fill so you catch drift without running a command." date: 2026-08-13T03:28:21+0000 source: https://www.aveshina.my.id/en/blog/customize-status-line --- "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. ```figure ``` 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](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](https://code.claude.com/docs/en/interactive-mode) ```quiz Q: What is the core purpose of the status line? - Decorative terminal styling - A persistent, scriptable bar that surfaces live cost and context fill so you catch drift without running a command correct: 1 explain: The status line is observability for the loop. It keeps the two meters that matter — context fill and session cost — visible at all times, so drift is caught early. Q: How does the status line differ from /cost and /status? - They show completely different data - /cost and /status are on-demand snapshots; the status line shows the same kind of data always-on, pinned to the bottom correct: 1 explain: The commands give a number when run; the status line makes that data continuous and peripheral, so the meter is in view the whole session. Q: Which two readouts most directly serve cost-and-quality management? - Git branch and model name - Context usage percentage and live session cost correct: 1 explain: Context fill warns of impending rot (compact/delegate before quality drops); live cost warns of runaway re-reads. Branch and model are useful but secondary. Q: Why is keeping the status line short a discipline, not a limitation? - Because long bars crash the terminal - Because a bar with many segments becomes noise; the value is in the few numbers you actually act on correct: 1 explain: The status line is an early-warning system, not a dashboard. Two or three load-bearing readouts beat ten segments you stop reading. ```