Анализ трафика Claude Code: почему ИИ-агенты потребляют лишние токены

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

Современные инструменты разработки на базе искусственного интеллекта стремятся к максимальной автономности, однако платой за это становится значительный объем служебного трафика. Как сообщает пользователь Habr, простой запрос к Claude Code, состоящий из одного слова, спровоцировал отправку на сервер 305 килобайт данных. При этом полезная нагрузка занимала лишь малую часть этого объема, а основной массив данных пришелся на технические инструкции и описания доступных инструментов, многие из которых не требовались для выполнения конкретной задачи.

Детали эксперимента с Claude Code

В ходе тестирования был задан запрос, состоящий из 29 символов, с просьбой ответить одним словом. Система отработала запрос, но объем передаваемых данных составил 305 042 байта, что эквивалентно 113 460 токенам. Для анализа трафика был применен прокси-сервер на языке Python, который позволил сегментировать структуру запроса. Выяснилось, что системный промпт занимает лишь четыре процента от общего объема, тогда как подавляющую часть — 85 процентов — составляют описания 137 инструментов. Значительная доля этих метаданных, а именно 107 описаний, поступила от одного MCP-сервера, который в данной сессии не использовался.

Дополнительную нагрузку в размере 29 тысяч символов создал хук плагина. Кроме того, было зафиксировано, что каждое действие агента сопровождается автоматической отправкой второго запроса, о котором пользователь не запрашивал информацию. Для сравнения, аналогичный тест с использованием Codex CLI показал значительно более экономный результат: объем трафика составил около 29 килобайт при 9 817 токенах, при этом длина системного промпта осталась сопоставимой.

Механизмы формирования запросов

Проблема избыточности напрямую связана с тем, как агенты управляют протоколом Model Context Protocol и списком доступных функций. Агенты стремятся загрузить в контекстное окно максимально полный набор данных об инструментах, чтобы быть готовыми к любой команде пользователя. В результате пользователь оплачивает передачу огромного объема информации, которая не несет смысловой нагрузки для текущего действия. Это ведет к быстрому заполнению окна контекста и нерациональному расходу кэша.

Такой подход контрастирует с более «легкими» архитектурами. Разница в объемах данных между Claude Code и Codex CLI указывает на то, что оптимизация на уровне клиента возможна, однако текущие стандарты реализации агентов отдают приоритет готовности к вызову любого инструмента, жертвуя при этом сетевой эффективностью. Каждый подключенный MCP-сервер при текущей архитектуре добавляет десятки тысяч токенов к каждому запросу, что становится критичным фактором при интенсивной разработке.

Практические выводы для разработчиков

Для специалистов, использующих кодинг-агенты в повседневной работе, данные показатели означают прямые финансовые издержки. Избыточность запросов приводит к тому, что бюджет на использование API расходуется на передачу метаданных, а не на выполнение полезных задач. Особую осторожность стоит проявлять при подключении сторонних MCP-серверов: их наличие в конфигурации агента напрямую увеличивает объем каждого запроса, даже если инструменты из этих серверов остаются невостребованными в текущем сеансе.

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

Перспективы развития инструментов

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