Claude Code тратит три четверти своего токенового бюджета только на чтение кодовой базы, согласно анализу 219 реальных сессий, проведенному Red Hat. Этот вывод опровергает привычное предположение о том, что ИИ-агенты для написания кода тратят время впустую на генерацию кода, и указывает на то, что разработчикам следует сосредоточиться на проблеме управления контекстом, а не только на скорости моделей.

Данные, стоящие за этим утверждением

Red Hat изучила 219 взаимодействий с Claude Code от Anthropic и рассчитала использование токенов за каждый ход. В рамках выборки медианный ход выделял 75% токенов на обработку окружающего кода и документации, и только 25% — на генерацию новых строк. Поскольку большинство провайдеров ИИ тарифицируют входные и выходные токены по одинаковой ставке, именно «читающая» часть транзакции составляет основную часть затрат.

Почему стоимость «чтения» имеет значение

Стратегия оптимизации

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

Контроль затрат

Когда ИИ-ассистент перечитывает состояние того же репозитория при каждом запросе, количество входных токенов стремительно растет. Проекты с большими окнами контекста могут столкнуться с резким увеличением счетов, даже если объем генерируемого кода остается скромным.

Инженерный фокус

Разработчики инструментов часто стремятся к повышению качества моделей, упуская из виду то, как строятся промпты. Анализ показывает, что «контекстная инженерия» (context engineering) — обрезка, кэширование и суммаризация кода, подаваемого модели, — приносит больший ROI, чем постепенные обновления моделей.

Практические шаги по снижению накладных расходов на чтение

  • Удаляйте нерелевантные файлы — исключайте из промпта файлы, которые не нужны для текущей задачи. Меньше промпт — меньше входных токенов.
  • Кэшируйте повторяющиеся чтения — сохраняйте интерпретацию моделью стабильных частей кодовой базы и используйте её в последующих ходах вместо повторной отправки того же текста.
  • Сжимайте результаты работы инструментов — когда внешние инструменты возвращают большие объемы данных (например, отчеты линтера), суммируйте их перед тем, как передать обратно в Claude.
  • Используйте инкрементальные диффы — отправляйте только изменения с момента последнего хода, а не всё содержимое файла.

Эти тактики направлены на то, чтобы предотвратить повторное чтение ИИ одного и того же снимка репозитория при каждом взаимодействии, что снижает как задержку, так и стоимость.

Контраргумент: скорость всё же важна

Некоторые разработчики утверждают, что быстрая модель по-прежнему имеет значение, так как она снижает задержку для тех 25% токенов, которые генерируются. В средах, чувствительных к задержкам — например, в плагинах IDE, которые должны отвечать мгновенно, — важна каждая миллисекунда. Профиль, в котором преобладает чтение, не отменяет преимущества более быстрой модели; он просто снижает её относительную значимость.

На что обратить внимание в будущем

Исследование Red Hat основано на ограниченном наборе сессий, поэтому более широкая выборка может выявить иное распределение токенов для других языков или размеров проектов. Если будущие данные подтвердят показатель в 75% на чтение, мы можем увидеть переход к инструментам, которые автоматически обрезают и кэшируют контекст, или даже к архитектурам моделей, оптимизированным для быстрого поглощения контекста.

Итог: В написании кода с помощью ИИ самый дешевый способ повышения производительности — это давать модели меньше данных, а не заставлять её писать быстрее. Цифры Red Hat говорят сами за себя: обрезайте, кэшируйте и суммаризируйте свои промпты, и вы увидите ощутимую экономию как времени, так и денег.