Еженедельный отчет по AI-кодингу: активность, а не оценка продуктивности

Неделя работы с Claude Code и Codex оставляет на машине кучу следов. По ним можно точно сказать: когда сессии были активны, какой провайдер их генерировал, какие модели задействовались и как распределялись токи по дням.

Но это не доказывает, что код правильный, неделя выдалась продуктивной или что потраченная сумма из API — реальные деньги. Вот эта граница и делает еженедельный отчёт полезным.

Работайте с локальными календарными днями

Читаемый отчёт должен покрывать сегодня плюс предыдущие шесть календарных дней. Заголовок, дневные столбцы, итоги по провайдерам и строки моделей — все в одних границах.

Если на графике календарные дни, а строки моделей считают по скользящему 168-часовому окну, возникнут расхождения. Строка может превысить заголовок, хотя каждый отдельный расчёт выглядит логичным. Часовой пояс и поведение на границе полуночи — это бухгалтерские правила.

Суммы токенов описывают активность, а не продуктивность

Входные, выходные токены, создание кэша и чтение из кэша — это разная работа. Я храню две суммы:

• общее количество прошедших через провод токенов — все категории, которые записаны локально;
• сумма входных и выходных — без кэш-трафика.

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

Сравнивайте провайдеров, не придумывая эквивалентности

Разбивка по провайдерам показывает, сколько активности записано от Claude Code и сколько от Codex. Но нельзя заявлять, что один токен от каждого провайдера равен по трудозатратам, задержке, качеству или нагрузке на квоту.

Квота провайдера — отчётное состояние. Локальная активность токенов — восстановленная бухгалтерская книга. Хорошо показывать и то, и другое. Плохо — использовать одно, чтобы заполнить пробелы в другом.

Храните контекст модели для каждого события

Сессия может переключать модели. Позднему событию токена нужен контекст модели, активной в тот момент, а не та, что стоит в начале файла.

Неизвестные именованные модели должны оставаться видимыми и без цены. Угадывание похожей модели делает невозможным аудит исторических отчётов.

Ранг по токенам и ранг по стоимости API — разные вещи. Модель с дешёвыми чтениями из кэша может лидировать по объёму, в то время как другая ведёт по оценочной стоимости.

Мой пятиминутный обзор за неделю

Я использую отчёт для одного операционного решения:

1. Проверяю, что присутствуют все семь локальных дней.
2. Ищу пробелы, всплески повторов или устаревшие данные провайдера.
3. Сравниваю состав провайдеров и моделей, не оценивая качество.
4. Читаю оценочную стоимость API только с датой тарифа, под которым она показана.
5. Записываю одно изменение в процессе на следующую неделю.

Этим изменением может быть сокращение фоновых запусков, исправление повторяющейся ошибки аутентификации или сдвиг времени начала долгой сессии. Само число не улучшает процесс. Решение улучшает.

Шеринг — отдельное действие

Локальный отчёт по умолчанию остаётся локальным. Agent Island формирует отчёт из записей, уже хранящихся на машине; содержимое транскриптов не загружается в сервис Agent Island.

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

Еженедельный отчёт заслуживает доверия, когда говорит, что означает каждая цифра и чего она не может доказать.