Обкатка token-budget на Claude Code Антона — прогнать аудит и выложить результаты в комментарии #1

Open
opened 2026-07-23 13:08:11 +03:00 by oleks · 3 comments
Owner

Зачем это нужно (мотивация)

Плагин token-budget пока проверен только на одной истории использования (моей). Этого мало, чтобы верить выводам: пороги в hogs (marathon-session ≥2 дней, bloated-context >300k, subagent-heavy >50% турнов, model-switching) подобраны по одному профилю работы, и совершенно неясно, как они ведут себя на чужом.

Основной тезис плагина: квота уходит не на то, что Клод пишет, а на повторное перечитывание контекста. На тяжёлом агентном использовании расклад такой:

Категория % сырых токенов % стоимости
cache_read (перечитывание контекста) ~95%+ ~60%
cache_write ~3% ~30%
output (то, что Клод генерирует) <1% ~10%

То есть расход масштабируется как (длина сессии × размер контекста) и почти не зависит от того, сколько полезной работы сделал конкретный турн. Сессия, живущая несколько дней, оплачивает всю накопленную историю на каждом турне.

Нужна вторая независимая точка данных, чтобы понять:

  1. Воспроизводится ли соотношение cache_read / cache_write / output на другом стиле работы, или это артефакт моего.
  2. Не ложно ли срабатывают эвристики hogs (и не молчат ли они там, где расход реально большой).
  3. Понятен ли вывод инструмента человеку, который его раньше не видел — то есть можно ли по отчёту сразу понять, что менять.
  4. Не падает ли парсер на чужих транскриптах (там свои ловушки: одно сообщение размазано по многим строкам JSONL, разные модели в одной сессии).

Всё считается офлайн по локальным транскриптам ~/.claude/projects/**/*.jsonl, которые Claude Code и так пишет. Никакой сети, никаких зависимостей — только stdlib Python. Наружу ничего не уходит; в комментарии выкладывай ровно столько, сколько считаешь нужным.

Что сделать

1. Поставить плагин

claude plugin add https://claude-plugins.oleks.space/plugins/token-budget.git

2. Запрос, который надо дать своему Claude Code

Скопируй целиком в свою сессию Claude Code:

Прогони аудит расхода токенов по моей истории Claude Code с помощью плагина token-budget.

1. Запусти `cc-tokens hogs --days 30` — это основная диагностика.
2. Запусти `cc-tokens composition --days 30` — расклад токенов и стоимости по категориям.
3. Запусти `cc-tokens sessions --days 30 --top 10` — самые дорогие сессии с проектом и временем жизни.
4. Запусти `cc-tokens daily --days 30` и `cc-tokens projects --days 30`.
5. Для самой дорогой сессии из п.3 запусти `cc-tokens context --session <prefix>` и покажи кривую роста контекста.

Затем ответь на следующее, честно, по цифрам, а не по общим соображениям:
- Какая доля стоимости пришлась на cache_read, cache_write и output?
- Какие находки выдал `hogs` (marathon-session / bloated-context / subagent-heavy /
  model-switching) и выглядят ли они справедливо для того, как я реально работал?
- Есть ли ложные срабатывания — что-то помечено как проблема, но по факту нормально?
- Есть ли пропуски — дорогая сессия, которую `hogs` не отметил вообще?
- Три конкретных изменения в моих привычках, которые дали бы наибольшую экономию.

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

3. Выложить результаты сюда

Оставь в этом issue комментарии с:

  • выводом composition (или хотя бы итоговым процентным раскладом);
  • выводом hogs — и своей оценкой, справедливы ли находки;
  • ложными срабатываниями и пропусками, если нашлись;
  • любыми падениями/ошибками парсера с полным текстом;
  • впечатлением: понятно ли из отчёта, что менять, или пришлось догадываться.

Отдельно интересно: за какое время отработало на твоём объёме истории.

Что считаем успехом

Не «плагин работает», а — понятно, какие пороги надо править под другой профиль работы, и найдены ли места, где парсер или формулировки врут. Отрицательный результат тут ценнее вежливого «всё ок».

## Зачем это нужно (мотивация) Плагин `token-budget` пока проверен только на одной истории использования (моей). Этого мало, чтобы верить выводам: пороги в `hogs` (marathon-session ≥2 дней, bloated-context >300k, subagent-heavy >50% турнов, model-switching) подобраны по одному профилю работы, и совершенно неясно, как они ведут себя на чужом. Основной тезис плагина: **квота уходит не на то, что Клод пишет, а на повторное перечитывание контекста.** На тяжёлом агентном использовании расклад такой: | Категория | % сырых токенов | % стоимости | |---|---:|---:| | `cache_read` (перечитывание контекста) | ~95%+ | ~60% | | `cache_write` | ~3% | ~30% | | `output` (то, что Клод генерирует) | <1% | ~10% | То есть расход масштабируется как `(длина сессии × размер контекста)` и почти не зависит от того, сколько полезной работы сделал конкретный турн. Сессия, живущая несколько дней, оплачивает всю накопленную историю на **каждом** турне. Нужна вторая независимая точка данных, чтобы понять: 1. Воспроизводится ли соотношение `cache_read` / `cache_write` / `output` на другом стиле работы, или это артефакт моего. 2. Не ложно ли срабатывают эвристики `hogs` (и не молчат ли они там, где расход реально большой). 3. Понятен ли вывод инструмента человеку, который его раньше не видел — то есть можно ли по отчёту сразу понять, что менять. 4. Не падает ли парсер на чужих транскриптах (там свои ловушки: одно сообщение размазано по многим строкам JSONL, разные модели в одной сессии). Всё считается **офлайн** по локальным транскриптам `~/.claude/projects/**/*.jsonl`, которые Claude Code и так пишет. Никакой сети, никаких зависимостей — только stdlib Python. Наружу ничего не уходит; в комментарии выкладывай ровно столько, сколько считаешь нужным. ## Что сделать ### 1. Поставить плагин ```sh claude plugin add https://claude-plugins.oleks.space/plugins/token-budget.git ``` ### 2. Запрос, который надо дать своему Claude Code Скопируй целиком в свою сессию Claude Code: ``` Прогони аудит расхода токенов по моей истории Claude Code с помощью плагина token-budget. 1. Запусти `cc-tokens hogs --days 30` — это основная диагностика. 2. Запусти `cc-tokens composition --days 30` — расклад токенов и стоимости по категориям. 3. Запусти `cc-tokens sessions --days 30 --top 10` — самые дорогие сессии с проектом и временем жизни. 4. Запусти `cc-tokens daily --days 30` и `cc-tokens projects --days 30`. 5. Для самой дорогой сессии из п.3 запусти `cc-tokens context --session <prefix>` и покажи кривую роста контекста. Затем ответь на следующее, честно, по цифрам, а не по общим соображениям: - Какая доля стоимости пришлась на cache_read, cache_write и output? - Какие находки выдал `hogs` (marathon-session / bloated-context / subagent-heavy / model-switching) и выглядят ли они справедливо для того, как я реально работал? - Есть ли ложные срабатывания — что-то помечено как проблема, но по факту нормально? - Есть ли пропуски — дорогая сессия, которую `hogs` не отметил вообще? - Три конкретных изменения в моих привычках, которые дали бы наибольшую экономию. Если какая-то команда упала или выдала явную чушь — покажи полный вывод ошибки, не заглаживай. ``` ### 3. Выложить результаты сюда Оставь в этом issue комментарии с: - выводом `composition` (или хотя бы итоговым процентным раскладом); - выводом `hogs` — и своей оценкой, справедливы ли находки; - ложными срабатываниями и пропусками, если нашлись; - любыми падениями/ошибками парсера с полным текстом; - впечатлением: понятно ли из отчёта, что менять, или пришлось догадываться. Отдельно интересно: за какое время отработало на твоём объёме истории. ## Что считаем успехом Не «плагин работает», а — понятно, какие пороги надо править под другой профиль работы, и найдены ли места, где парсер или формулировки врут. Отрицательный результат тут ценнее вежливого «всё ок».
anton was assigned by oleks 2026-07-23 13:08:11 +03:00
Owner

Обкатка на истории Антона (748 сессий, 30 дней, 8.2B токенов) — composition

category        tokens  %tokens  %cost
cache_read        8.0B    97.1%  61.0%
cache_write_1h  147.2M     1.8%  22.5%
cache_write_5m   52.3M     0.6%   5.0%
output           28.9M     0.4%  11.0%
input             6.3M     0.1%   0.5%
mean context sent per turn: 156.2k

Тезис воспроизвёлся почти один-в-один на другом профиле (тяжёлые агентные флоты, много фоновых сессий): у тебя 95%+/~60%, у Антона 97.1%/61.0% cache_read; cache_write 2.4%/27.5%; output 0.4%/11.0%. Это не артефакт твоего стиля.

Скорость: каждая команда ~4.5–6 s на 52k турнов / 8.2B токенов. Парсер не упал ни разу, разные модели в сессиях (fable/opus/sonnet) переварил.

Находка №0 — README/issue: claude plugin add <url> не существует в текущем CLI (error: unknown command 'add'), а claude-plugins.oleks.space/plugins/token-budget.git отдаёт 404. Поставили через локальный маркетплейс (claude plugin install token-budget@oleks после добавления записи в marketplace.json). Обнови install-инструкцию.

## Обкатка на истории Антона (748 сессий, 30 дней, 8.2B токенов) — composition ``` category tokens %tokens %cost cache_read 8.0B 97.1% 61.0% cache_write_1h 147.2M 1.8% 22.5% cache_write_5m 52.3M 0.6% 5.0% output 28.9M 0.4% 11.0% input 6.3M 0.1% 0.5% mean context sent per turn: 156.2k ``` **Тезис воспроизвёлся почти один-в-один** на другом профиле (тяжёлые агентные флоты, много фоновых сессий): у тебя 95%+/~60%, у Антона 97.1%/61.0% cache_read; cache_write 2.4%/27.5%; output 0.4%/11.0%. Это не артефакт твоего стиля. **Скорость:** каждая команда ~4.5–6 s на 52k турнов / 8.2B токенов. Парсер не упал ни разу, разные модели в сессиях (fable/opus/sonnet) переварил. **Находка №0 — README/issue:** `claude plugin add <url>` не существует в текущем CLI (error: unknown command 'add'), а `claude-plugins.oleks.space/plugins/token-budget.git` отдаёт 404. Поставили через локальный маркетплейс (`claude plugin install token-budget@oleks` после добавления записи в marketplace.json). Обнови install-инструкцию.
Owner

hogs: находки и честная оценка

hogs --days 30: 15 flagged = 41% of spend ($7,271 всего). ВСЕ находки — bloated-context (peak 335k–735k), у 4 добавка subagent-heavy (57–80% турнов — подагенты). Примеры: 89e2100f $349/4694 турна (флот 07-20→21, 78% subagents) · 6e6334bb $338 · caf59ee4 $278.

Справедливость: да, по делу. Профиль Антона — оркестрация флотов агентов из /home/a с жирным always-on контекстом (MEMORY.md-индекс + CLAUDE.md + куча MCP-тулов): контексты 600k+ и правда пересылаются каждый турн. Кривая context --session 89e2100f показывает классическую пилу: рост 90k→648k, компакт-сброс, снова рост — и $0.20/турн в среднем.

Молчащие эвристики (для калибровки порогов):

  • marathon-session НЕ сработала ни разу: у Антона lifespan всех топ-сессий 0–1 день (watchdog'и/переزапуски убивают марафоны раньше). Порог ≥2 дней на этом профиле мёртв — но дорогие сессии есть. Т.е. marathon ловит СИМПТОМ (возраст), а не причину (накопленный контекст) — на этом профиле её работу целиком делает bloated-context. Возможно, marathon стоит переформулировать по (turns × avgCtx), а не по календарю.
  • model-switching не сработала ни разу — сессии почти всегда однo-модельные, проверить эвристику на этом профиле не удалось (не ложный минус, просто нет материала).

Ложные срабатывания: явных нет. Можно спорить, что для оркестратора флотов 300k+ контекст — «норма профессии», но совет «trim MCP/CLAUDE.md» всё равно валиден.

Пропуски: содержательных нет — всё дорогое за пределами топ-15 это длинный хвост средних сессий того же типа.

Косметика/мелкие грабли:

  1. В hogs у 89e2100f «4,694 turns», а в context --session — «1,201 turns»: первая цифра с подагентами, вторая без — рядом это читается как противоречие, стоит подписать (main+sub).
  2. Атрибуция проекта: топ-«проект» = a ($1,857) — это просто $HOME, все флот/оркестрационные сессии слиплись в одну кучу. Для профиля «запускаю всё из хоума» разрез по проектам малоинформативен; хочется fallback на имя сессии/агента.
  3. turns в composition (52,452) vs daily TOTAL (52,454) расходятся на 2 — мелочь, но глаз цепляет.
## hogs: находки и честная оценка `hogs --days 30`: 15 flagged = 41% of spend ($7,271 всего). ВСЕ находки — `bloated-context` (peak 335k–735k), у 4 добавка `subagent-heavy` (57–80% турнов — подагенты). Примеры: 89e2100f $349/4694 турна (флот 07-20→21, 78% subagents) · 6e6334bb $338 · caf59ee4 $278. **Справедливость:** да, по делу. Профиль Антона — оркестрация флотов агентов из /home/a с жирным always-on контекстом (MEMORY.md-индекс + CLAUDE.md + куча MCP-тулов): контексты 600k+ и правда пересылаются каждый турн. Кривая `context --session 89e2100f` показывает классическую пилу: рост 90k→648k, компакт-сброс, снова рост — и $0.20/турн в среднем. **Молчащие эвристики (для калибровки порогов):** - `marathon-session` НЕ сработала ни разу: у Антона lifespan всех топ-сессий 0–1 день (watchdog'и/переزапуски убивают марафоны раньше). Порог ≥2 дней на этом профиле мёртв — но дорогие сессии есть. Т.е. marathon ловит СИМПТОМ (возраст), а не причину (накопленный контекст) — на этом профиле её работу целиком делает bloated-context. Возможно, marathon стоит переформулировать по (turns × avgCtx), а не по календарю. - `model-switching` не сработала ни разу — сессии почти всегда однo-модельные, проверить эвристику на этом профиле не удалось (не ложный минус, просто нет материала). **Ложные срабатывания:** явных нет. Можно спорить, что для оркестратора флотов 300k+ контекст — «норма профессии», но совет «trim MCP/CLAUDE.md» всё равно валиден. **Пропуски:** содержательных нет — всё дорогое за пределами топ-15 это длинный хвост средних сессий того же типа. **Косметика/мелкие грабли:** 1. В hogs у 89e2100f «4,694 turns», а в `context --session` — «1,201 turns»: первая цифра с подагентами, вторая без — рядом это читается как противоречие, стоит подписать (main+sub). 2. Атрибуция проекта: топ-«проект» = `a` ($1,857) — это просто $HOME, все флот/оркестрационные сессии слиплись в одну кучу. Для профиля «запускаю всё из хоума» разрез по проектам малоинформативен; хочется fallback на имя сессии/агента. 3. turns в composition (52,452) vs daily TOTAL (52,454) расходятся на 2 — мелочь, но глаз цепляет.
Owner

Понятность + три изменения привычек

Понятно ли, что менять: да — hogs называет сессию, причину и рычаг одной строкой, догадываться не пришлось. Единственное, чего не хватает для действия: bloated-context говорит «trim MCP servers / CLAUDE.md / pasted files», но не показывает, ИЗ ЧЕГО состоит контекст конкретной сессии (сколько весят тулы vs память vs вставленные файлы). Разбивка контекста по источникам была бы killer-фичей.

Три изменения с наибольшей экономией (по цифрам этого профиля):

  1. Резать always-on контекст /home/a-сессий. Средний посыл 156k/турн при 52k турнов; MEMORY.md-индекс + глобальный CLAUDE.md + десятки deferred MCP-тулов едут в каждый турн каждой сессии, включая мелкие. Минус 50k с базы ≈ минус ~$1.4k/месяц на этом объёме.
  2. Короче жить большим сессиям-оркестраторам. Пила 89e2100f показывает: после ~500k копится по $15–20 на каждые 60 турнов. Завершать/пересоздавать оркестратора после закрытия юнита, а не держать 600k+ живым «на всякий».
  3. Подагенты — только с ужатым входом. 4 из 15 топ-сессий subagent-heavy (57–80%): каждый подагент возит СВОЙ полный контекст. Батчить работу в меньшее число подагентов и передавать им выжимку, а не наследие оркестратора.

Время работы: каждая из 5 команд 4.5–6 s wall на 748 сессий / 8.2B токенов / 30 дней. Отлично.

Итог для целей issue: тезис подтверждён второй точкой; порог marathon (≥2d) на этом профиле мёртв (см. предыдущий коммент — предлагаю метрику turns×avgCtx); парсер не соврал ни разу; README-инсталляция сломана (находка №0).

## Понятность + три изменения привычек **Понятно ли, что менять:** да — hogs называет сессию, причину и рычаг одной строкой, догадываться не пришлось. Единственное, чего не хватает для действия: bloated-context говорит «trim MCP servers / CLAUDE.md / pasted files», но не показывает, ИЗ ЧЕГО состоит контекст конкретной сессии (сколько весят тулы vs память vs вставленные файлы). Разбивка контекста по источникам была бы killer-фичей. **Три изменения с наибольшей экономией (по цифрам этого профиля):** 1. **Резать always-on контекст /home/a-сессий.** Средний посыл 156k/турн при 52k турнов; MEMORY.md-индекс + глобальный CLAUDE.md + десятки deferred MCP-тулов едут в каждый турн каждой сессии, включая мелкие. Минус 50k с базы ≈ минус ~$1.4k/месяц на этом объёме. 2. **Короче жить большим сессиям-оркестраторам.** Пила 89e2100f показывает: после ~500k копится по $15–20 на каждые 60 турнов. Завершать/пересоздавать оркестратора после закрытия юнита, а не держать 600k+ живым «на всякий». 3. **Подагенты — только с ужатым входом.** 4 из 15 топ-сессий subagent-heavy (57–80%): каждый подагент возит СВОЙ полный контекст. Батчить работу в меньшее число подагентов и передавать им выжимку, а не наследие оркестратора. **Время работы:** каждая из 5 команд 4.5–6 s wall на 748 сессий / 8.2B токенов / 30 дней. Отлично. **Итог для целей issue:** тезис подтверждён второй точкой; порог marathon (≥2d) на этом профиле мёртв (см. предыдущий коммент — предлагаю метрику turns×avgCtx); парсер не соврал ни разу; README-инсталляция сломана (находка №0).
Sign in to join this conversation.
No labels
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kotkan/claude-plugin-token-budget#1