/statusline

description: "Install or remove the aria-knowledge status-line meter — a context-window progress bar plus the rolling 5-hour and 7-day plan-usage percentages, shown at the bottom of the Claude Code CLI. Use when the user says '/statusline', 'add a context meter', 'show context usage in the status line', 'show my 5-hour usage', 'usage meter', 'enable the status line', or 'turn off the status line meter'. Claude Code CLI only (the status line is a CLI feature; the desktop app shows its own native usage indicator). Triggers: '/statusline', '/statusline on', '/statusline off', '/statusline status'."

/statusline — Context + Usage Meter

Wire up (or remove) a persistent status line at the bottom of the Claude Code CLI showing:

Fable 5 H │ ███░░░░░░░ 31% ctx │ 5h 24% ↺1pm │ 7d 88% ↺Tue 1pm

• **model + effort** — the model name, with a compact reasoning-effort suffix when the model supports `/effort`: `L` low · `M` medium · `H` high · `XH` xhigh · `MX` max (e.g. `Fable 5 H`). Reflects live mid-session `/effort` changes; no suffix renders when the current model has no effort parameter.
• **context bar + %** — how full the context window is (input-only percentage, green → yellow → red).
• **5h NN% ↺HH:MM** — rolling 5-hour plan-usage window + when it resets (Pro/Max plans only).
• **7d NN%** — rolling 7-day window (Pro/Max plans only).

The 5h/7d segments render only on Pro/Max subscription sessions and only after the first response of a session. On API-key sessions they're absent and the line shows model + context only.

The meter's last segment is the **account email** (read from `~/.claude.json`), placed last so a width-truncated line only ever clips the email, not the usage — and so you can tell which account a terminal belongs to when running more than one.

Installing the meter also lets the **session's Claude** know these numbers: on each render the meter writes a snapshot, **keyed by account**, to `~/.gemini/antigravity/aria-statusline-state-<accountUuid>.json`, which Claude reads on demand (e.g. before `/handoff` or compaction — see the SessionStart TASK BUDGET guardrail). Per-account keying means a second logged-in account never clobbers the first's usage (which previously caused the alert to fire on the wrong account). A `UserPromptSubmit` hook additionally injects a warning when context/5h/7d crosses `usage_alert_threshold` (80% once aria-knowledge is configured, adjustable in `/setup`; set `off` to disable). All of this is dormant until the meter is installed — and the *injection* specifically is also dormant until `/setup` has written a config file, because `config.sh` resolves all of its defaults only when one exists. On-demand reading of the snapshot works either way.

Why a command and not automatic

A Claude Code plugin **cannot** register a `statusLine` from its manifest — the main status line is read only from the user's `~/.gemini/antigravity/settings.json`. So this skill performs the one-time wiring: it copies the meter script to a stable location and points your settings at it. (`subagentStatusLine` is the only status-line key a plugin may default, and it's a different surface.)

Runtime note

This is a Claude Code **CLI** feature — the meter only renders in the terminal CLI. If the `Bash` tool is unavailable (you're in Cowork or another non-Code runtime), tell the user: *"The status-line meter is a Claude Code feature and can't be configured from this runtime."* and stop. Otherwise proceed.

**Desktop-app caveat:** the Claude Code desktop app has `Bash` but does **not** render this status line — it does not invoke the `statusLine` command and shows its own native usage indicator instead. So in a desktop session the wiring installs cleanly but the meter never appears in the desktop UI, and the usage snapshot (`aria-statusline-state-<accountUuid>.json`) is not refreshed by desktop renders. **Still install when asked** — the wiring is global, so the meter and snapshot work in the user's CLI sessions on the same machine. If you detect a desktop runtime (e.g. `CLAUDE_CODE_ENTRYPOINT=claude-desktop`), proceed with the install but mention that the meter shows in CLI sessions, not the desktop UI (where the app's built-in indicator covers it). (See `docs/non-goals.md` for why a desktop bridge is deferred.)

Argument routing

Parse the argument (default `on` when none given):

• **`on`** (or empty) → run **Install / Refresh**.
• **`off`** → run **Remove**.
• **`status`** → run **Status**.

---

Install / Refresh

Step 1 — Locate the meter script and check dependencies

SRC="${CLAUDE_PLUGIN_ROOT}/bin/statusline-meter.sh"
DEST="$HOME/.claude/aria-statusline-meter.sh"
SETTINGS="$HOME/.claude/settings.json"
[ -f "$SRC" ] && echo "source ok: $SRC" || echo "MISSING SRC"
command -v jq >/dev/null 2>&1 && echo "jq: present" || echo "jq: MISSING"
echo "HOME=$HOME"

• If `MISSING SRC`: tell the user the plugin install looks incomplete and stop.
• If `jq: MISSING`: warn — *"`jq` isn't installed. The meter needs it to read the status-line data; without it the line will show only the model name. Install with `brew install jq` (macOS) or your package manager, then re-run `/statusline`."* Continue anyway (a model-only line still installs cleanly), but make the limitation explicit.
• Capture the literal `HOME` value — you will write an **absolute** path into settings.json (do not write `~` or `${CLAUDE_PLUGIN_ROOT}`; neither is guaranteed to expand in the settings file, and the plugin's own install dir is version-stamped and changes on update).

Step 2 — Copy the meter to the stable path

mkdir -p "$HOME/.claude"
cp "${CLAUDE_PLUGIN_ROOT}/bin/statusline-meter.sh" "$HOME/.claude/aria-statusline-meter.sh"
chmod +x "$HOME/.claude/aria-statusline-meter.sh"
echo "copied to $HOME/.claude/aria-statusline-meter.sh"

Copying (rather than referencing the plugin dir directly) means the meter survives plugin updates and reinstalls. The trade-off: w