Status Line для Claude Code CLI. Показывает кэш, git, контекст и лимиты в одном месте / Песочница / Хабр

Решил поделиться и рассказать про свой статуслайн для Claude Code, который наглядно выводит много полезной информации в одном месте.

Status Line — это то, что можно вывести внизу Claude Code терминала, если вы в нём работаете.

Вот так он выглядит в моём терминале — линия снизу.

А ниже я расскажу подробнее, из чего он состоит и зачем туда смотреть

Ссылку на репозиторий оставлю внизу статьи

Из чего состоит ⤵️

✔️ Модель и effort — сразу видно, на чём работаешь: Fable / Opus / Sonnet / Haiku, версия, размер контекста и уровень reasoning effort.

✔️ Папка и ветка Git — текущий проект и branch. Умеет сокращать длинные имена проектов и показывать, что сессия запущена не там, где ты сейчас находишься.

✔️ Состояние репозитория — modified / added / deleted / renamed / untracked / conflicts в одной компактной строке. Конфликты подсвечиваются красным, потому что это единственное состояние, которое блокирует коммит.

Визуализируется через сокращения в стиле VS Code

Код	Значение
`3M`	3 files modified
`1A`	1 added
`1D`	1 deleted
`1R`	1 renamed
`2?`	2 untracked
`1!`	1 conflict

✔️ Ahead / behind относительно origin — есть ли очередь на пуш и стоит ли подтянуть изменения перед началом работы.

✔️ Drift между CLAUDE.md / AGENTS.md / GEMINI.md — я использую и Claude Code, и Codex, и Gemini, у них разные главные контекст‑файлы. Статус-лайн показывает, когда они разъехались, чтобы все агенты имели одинаковый контекст.

✔️ Контекстное окно — это база. Бар + токены 480k/1M. С ранними предупреждениями, когда сессия подходит к зоне, где Claude скоро захочет compact.

✔️ Prompt cache — hit ratio, сколько токенов читается из кэша, сколько пишется, и когда протухнет TTL. Помогает понимать, сколько стоит каждый запрос и была ли инвалидация кэша.

✔️ Rate limits 5h и 7d — сколько лимитов осталось и время до reset.

Дальше — подробный разбор каждого пункта: что показывает, зачем это нужно и какие решения пришлось принять внутри.

Как это вообще работает

Claude Code умеет вызывать внешнюю программу для отрисовки статусной строки.

Claude Code запускает скрипт.
Подаёт ему на stdin JSON с состоянием сессии: модель, рабочая директория, session_id, контекстное окно, rate limits.
Читает stdout и печатает эту строку внизу терминала.

Без API и плагинов. Скрипт — это node statusline.js, который читает JSON и пишет одну строку с ANSI‑кодами.

Подключается в ~/.claude/settings.json

{
  "statusLine": {
    "type": "command",
    "command": "node \"/absolute/path/to/statusline.js\"",
    "refreshInterval": 60
  }
}

Разбор статус-лайна по сегментам

В своём стандартном виде он состоит из одной строки шириной 100 символов.

1. Модель и effort — Fb5:hg

Claude Code может отдавать нам имя модели — например, Opus 4.8 (1M context). В полном виде названия моделей занимают от 7 до 21 символа.

Первую секцию я сжал до такого вида:

Семейство Claude моделей сокращается до двух букв: My, Fb, Op, So, Ha
Версия модели — приклеивается вплотную: Op4.8
Уровень reasoning effort — lo / md / hg / xhg / mx
В скобках показывается размер контекста — (1m)

Итого Opus 4.8 (1M context) с high effort превращается в Op4.8:hg (1m). Получилось сделать 13 символов вместо 21

А рядом с названием модели показывается /effort, так как это модификатор модели

2. Папка и ветка — tweaks ▸ claude‑…tusline (current_branch)

Показывает имя текущей директории и ветку, в которой мы сейчас работаем. Выкидывает центральную часть названия, если статус лайн становится слишком большим по ширине.

claude-code-statusline → claude-…tusline

Если Claude в процессе работы перейдёт в другую папку, то статус-лайн это тоже подхватит.

Claude Code присылает два пути: project_dir (где сессия была запущена) и current_dir (где мы сейчас). Обычно они совпадают. Но если сделать cd в подпроект, то они разойдутся. А сессия, её транскрипт и её память остаются привязаны к месту запуска. Что может путать, поэтому я и придумал механизм.

tweaks ▸ claude-code-statusline (current_branch)

3. Состояние репозитория — 3M 1A 1D 1R 2? 1!

git status --porcelain, разложенный по корзинам в стиле VS Code

Код	Значение
`M`	modified
`A`	added / staged
`D`	deleted
`R`	renamed
`?`	untracked
`!`	конфликт

Всё, кроме конфликтов, рисуется приглушённым цветом. Потому что это единственная категория, которая физически блокирует коммит. Остальное просто показывает, что идёт работа.

4. Моё любимое — ahead / behind (↑2 push и ↓1 pull)

Уже с момента старта сессии показывает расхождение локальной ветки с origin/ — сколько коммитов ждут пуша (жёлтым) и сколько прилетело в remote и ждут, пока их подтянут (красным).

↓ pull сделал красным не просто так. Так как ↓ pull — это уже сделанная в origin работа, которой у меня нет. Если начну коммитить поверх изменённого origin, то могу получить конфликты.

Обновляется на каждый fetch.

5. ⚠ md drift

Я работаю с разными агентами. И эти агенты on_session_start читают разные файлы памяти:

Claude Code → CLAUDE.md
OpenAI Codex (и почти все agent‑spec‑совместимые инструменты) → AGENTS.md
Gemini (который уже Antigravity) → GEMINI.md

И так как в моих проектах может оказаться каждый из агентов, то во всех трёх файлах должен лежать один и тот же контекст. Как только они расходятся, то один агент работает по новым правилам, а другие все ещё по старым. Что не есть гуд. Например, я обновил CLAUDE.md и забыл про остальные два. И теперь Codex всё время будет нарушать правило, которое я ранее записал в Claude.md.

Статус-лайн же превращает это невидимое расхождение в индикатор. Если эти три файла разошлись, то в строке загорается красное ⚠ md drift. А если с файлами все ок или их нет, то сегмент не показывается.

Также я создал себе хук sync-md.js, который автоматически синкает изменения внутри Claude.md с Agents.md + Gemini.md

6. Контекстное окно — ██░░░ 480k/1M

Показывает, сколько всего токенов находится в Context Window в данный момент. Чем больше, тем хуже, медленнее и дороже становятся ответы. Поэтому это один из главных параметров, за которым стоит следить. Плюс я использую цветовую кодировку.

Использовано	Цвет
< 50%	default
50–65%	жёлтый
65–80%	оранжевый
≥ 80%	красный + 💀

Независимо от размера окна, после 250k токенов загорается жёлтый — даже на 1M‑контексте, где это всего лишь 25%. Просто потому что это та точка, за которую лучше не заходить даже при 1M контекстном окне.

7. Prompt cache — cache 87% ↓75k +360 1h:42m

Prompt cache — это то, за счёт чего агентные сессии вообще остаются для нас рентабельными по деньгам. Но его нигде не выводят, кроме внутренних системных файлов, откуда я его и беру.

Про кэширование у меня вообще были отдельные статьи, тоже очень любопытно.

В типичном агентном loop 95–96% всех input‑токенов — это cache reads.

Т.е. без статус-лайна я не знаю, какой у меня cache hit и сколько времени осталось до его инвалидации.

Зачем вообще смотреть на cache

Кэш хранит префикс контекста между запросами: system prompt, определения инструментов, историю диалога. При повторном запросе с тем же префиксом ты платишь полную цену только за дельту — за то, что реально добавилось.

Экономика такая
Цифры — доли от базовой цены input‑токена.

Операция	5-минутный кэш	1-часовой кэш
Запись в кэш (write)	125%	200%
Чтение из кэша (read)	10%	10%

То есть чтение из кэша дешевле обычного инпута в десять раз, а запись — наоборот, дороже обычного инпута. И главное, на что я смотрю в этой секции, — это сколько минут жизни кэша осталось.

Каждая пауза дольше TTL превращает следующий запрос в полный re‑write всего префикса. Отошёл на 61 минуту и дописал одну строчку — придётся заплатить 200% за весь контекст заново.

Например, на Fable 5 на перезапись 350к токенов может уйти 5–6% 5ч лимита на 100$ подписке.

Из чего состоит cache строка

87% — hit ratio, то есть read / (input + write + read). Чем ближе к 0%, тем дороже для вас вышло сообщение. Плюс по наблюдению за hit ratio можно отслеживать, нет ли у вас проблем с инвалидацией кэширования в середине диалога;
↓75k — показывает, сколько токенов было прочитано из кэша. По цене 10% от input;
+360 — токенов записано в кэш (дороже обычного инпута, но окупится на следующем запросе). Часто равно output токенам последнего прогона;
1h:42m — системный TTL‑бакет кэша и сколько до его протухания. В Claude Code TTL по умолчанию 1 час. Но можно выставить и 5 минут.

Цвет hit ratio

≥90% — ярко‑зелёный
≥75% — зелёный
≥50% — жёлтый
ниже — оранжевый
0% — жирный красный

8. Rate limits: 5h:35%(2h15m) и 7d:42%(4d)

Два окна лимитов подписки: пятичасовое и недельное. Процент использования плюс обратный отсчёт до сброса. Цвет — та же шкала, что и у контекста (default → жёлтый → оранжевый → красный).

Форматирование обратного отсчёта разное. Для 5h важны минуты: 2h15m. Для 7d минуты уже не так важны, поэтому там я просто вывожу дни 4d. Когда остаётся меньше двух суток, то формат переключается на 1dXh. А за 24 часа до недельного сброса статус лайн переключает недельное время на часы — 24h, а не 1d0h.

Если вам будет полезно, то его установка прописана в GitHub. Ещё опционально можно поставить 3 хука‑компаньона в optional-hooks/

детектор дрейфа MD при старте сессии;
автосинк CLAUDE.md → AGENTS.md + GEMINI.md ;
и проверка расхождения с origin с фоновым fetch.

Ни один из них для работы самого статус-лайна не нужен.

Ссылка на GitHub со статус-лайном 🫡

https://github.com/ilia‑pluzhnikov/claude‑code‑statusline, там уже 83 звезды.