[Перевод] На что кодинг-агенты тратят наши токены

На прошлой неделе я попросил Claude устранить однострочный баг. Ему понадобилось 23 тысячи токенов. Потом тот же баг я попросил устранить Gemini. Он потратил 350 тысяч токенов. Да уж, на такое невозможно закрывать глаза.

Поэтому я написал Context Lens — трассировщик контекста, перехватывающий вызовы LLM API, чтобы показать, что же на самом деле находится в окне контекста с разбивкой по этапам. Я подключил его к четырём инструментам кодинга и дал им одну и ту же задачу. Результаты оказались настолько разными, что я решил написать об этом статью.

Вопрос

При работе с этими моделями мы платим за токены. Токены — это довольно сложная тема. По сути, это блоки информации; 1 токен приблизительно равен 4 символам английского текста. Чем больше токенов передаётся в модель, тем больше мы платим.

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

Итак, нам нужно быть аккуратными с нашим окном контекста, а для построения этого окна используются токены. Я задался вопросом: как инструменты справляются с этим ограничением? Насколько умно они его обрабатывают?

Подготовка

Я запланировал серию экспериментов, и это первый из них. Он немного искусственный, но запаситесь терпением.

Я намеренно внедрил баг в Express.js: изменил порядок проверки на null в res.send(), из-за чего res.send(null) вместо пустого тела возвращает строку "null" с content-type: application/json. Для этого я взял реальный репозиторий Express с историей из 6128 коммитов. Я закоммитил баг, поэтому он находится в репозитории.

Каждый инструмент получил один и тот же промпт:

Модели, которые я использовал:

Все четыре модели устранили баг, и исправление прошло все 1246 тестов. Результат оказался одинаковым, но шли инструменты разными путями.

Сравнение

Вот, что демонстрирует Context Lens при сравнении наилучших прогонов каждой из четырёх моделей:

Розовым показаны определения инструментов, зелёным — результаты инструментов, синим — системный промпт, а оранжевым — беседа с пользователем.

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

Боже мой (Gemini, до тебя мы тоже доберёмся).

Opus на удивление постоянен. Результаты трёх прогонов сгруппированы в интервале 23-25K, есть один выброс на 35K (ему потребовался более широкий git diff, вернувший 9,8K токенов вместо обычных ~500 байт).

Разброс Codex оказался больше, чем я ожидал: от 29,3K до 47,2K в четырёх прогонах, в зависимости от конкретности команд тестирования. Но диапазон всё равно уже, чем у Sonnet и Gemini.

Результаты Sonnet сгруппированы в интервале 42-44K с одним выбросом в 69,6K.

Gemini оказался исключением. Для начала должен сказать, что здесь есть два тонких момента. Во-первых, Gemini — единственный помощник с окном контекста на 1 миллион токенов. Во-вторых, его стоимость на токен существенно ниже.

Как бы то ни было, любопытно здесь то, что прогоны Gemini и с наименьшим, и с наибольшим показателем используют 10 вызовов API, но тот, что с наибольшим, использует гораздо бóльшие считывания, применяя совершенно иную стратегию. И тренд идёт вверх как будто совершенно произвольно; нет никакого эффекта закрепления, нет схождения. Каждый прогон просто выбирает собственный путь, скидывает данные в окно контекста и двигается дальше.

Содержимое

Context Lens разбивает каждый этап на категории. Вот разбивка на пике контекста:

Почти 70% окна контекста Opus — это определения инструментов. То есть 16,4K токенов описывают инструменты наподобие Read, Write, Bash, Edit и различные способности субагента, и повторно отправляются на каждом этапе. Сам Opus едва использует контекст для чего-то другого; он идёт по настолько прямому пути по кодовой базе, что на результаты инструментов тратится всего 1,5K. Этот фиксированный оверхед присутствует всегда. На примере моей задачи это становится крайне заметно, потому что определения инструментов доминируют над всем остальным.

Такова расплата за архитектуру Claude. Спасает здесь кэширование: после первого этапа вызовы Opus составляют 95% попаданий кэша, поэтому каждый последующий вызов платит только за новую дельту. Кроме того, Claude использует субагенты Haiku для маленьких задач (маршрутизации, суммаризации); любопытно, что у них нулевые пересечения с кэшем основных вызовов Opus, несмотря на то, что они выполняются в одной сессии. Большинство этих вызовов субагентов имеет малый размер (400-900 токенов), но один вызов Haiku получил почти полный контекст беседы на 19K. Ну, по крайней мере, Haiku дёшев.

Sonnet платит тот же «налог» Claude, что и Opus (18,4K определений инструментов, 43%), но поскольку он выполняет чтение более широко, показатели результатов инструментов (16,9K, 40%) почти совпадают с ним. Одно лишь чтение полного тестового файла занимает 15,5K от этого показателя. Из всех четырёх помощников у Sonnet самая сбалансированная разбивка; иными словами, он платит обе цены: и фиксированный оверхед, и затраты на чтение.

Gemini противоположен Opus: у него полностью отсутствует оверхед определений инструментов (инструменты определяются на стороне сервера, а не в промпте), но он очень агрессивно выполняет чтение. Крайне агрессивно: 172K токенов на результаты инструментов. Context Lens зафиксировал результат одного инструмента, потребивший 118,5K токенов, то есть 66% от всего контекста. Я начал изучать его, и выяснилось, что Gemini сбрасывает в беседу всю историю git файла, состоящую из сотен коммитов. Ага, спасибо, Gemini.

Codex находится где-то по середине. Всего 6% определений инструментов (2K tokens), 72% результатов инструментов. Но его результаты таргетированы: операции поиска ripgrep, извлечений sed, конкретные диапазоны строк. Он относится к той же процентной категории, что и Gemini, но тратит небольшую долю от его абсолютного количества токенов.

Стратегии

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

Opus: детектив

Opus получает промпт «раньше это работало» и принимает его близко к сердцу: если что-то поломалось, то должен быть коммит, который это поломал. Он запускает git log, находит недавний коммит, затрагивающий res.send, выполняет git diff HEAD~1 , чтобы точно понять, что поменялось, считывает 20 релевантных строк lib/response.js для проверки, применяет исправление и прогоняет тесты. Шесть вызовов инструментов за 47 секунд.

Здесь меня впечатлило то, насколько мало кода считывает Opus. Он прочитал 20 строк в одном файле, и на этом всё. История git дала ему весь необходимый сигнал, поэтому он не смотрит на тесты, не выполняет grep и навигацию. После этой начальной точки контекст почти не увеличивается, потому что добавить практически нечего.

Вопрос вызывает только 16,4K инструментов, которые он таскает на каждом этапе. Сама по себе модель действует хирургически, но похожа на хирурга, выполняющего операцию на мозге, держа на спине рюкзак с садовыми инструментами.

Sonnet: студент

Sonnet применяет более методичный подход. Он начинает со считывания тестового файла (test/res.send.js, 15,5K токенов за одну операцию чтения), затем считывает исходный код, затем применяет git show для сравнения текущей версии с предыдущей. Он создаёт ментальную модель снизу вверх: что должно происходить, что происходит, что поменялось.

Это можно увидеть в режиме сообщений. На этапе 3 считывается тестовый файл (15,5K токенов, максимальная единовременная операция чтения). Этап 4 сообщает «я нашёл баг!» (Sonnet всегда такой энергичный и счастливый) и проверяет исходники. Этапы 5 и 6 используют git show для конкретных строк, чтобы подтвердить изменение. Затем он устраняет баг и проводит тестирование.

Этот подход выбрал бы скрупулёзный разработчик-джун: прочитать спецификацию, прочитать реализацию, проверить историю, а потом действовать. В этом нет ничего плохого, но чтение тестового файла целиком стоило 15,5K токенов; Opus не делал этого, потому что сразу перешёл к git.

Codex: Unix-хакер

Codex — совершенно иной типаж. Вместо Read и Edit он использует более низкоуровневые инструменты exec_command (оболочка) и apply_patch (редактор унифицированных diff). Всё выполняется через Bash.

То есть он ведёт себя, как Unix-хакер: rg для поиска, sed -n '145,165p' для считывания конкретных диапазонов строк, apply_patch с унифицированным diff для внесения изменений. В режиме сообщений видно, что он запускает параллельные команды оболочки (два вызова exec_command на одном этапе), чего не делает ни один другой инструмент.

Кроме того, он полностью игнорирует git. Он просто получает при помощи grep релевантные паттерны, считывает минимальное количество строк, патчит исправление и выполняет тесты.

Благодаря этому Codex оказывается самым предсказуемым из изученных нами инструментов. К тому же его методика «grep и sed» кажется мне правильной, поэтому он стал моим любимчиком. В данном случае был более прямолинейный путь через git, но Codex очень надёжен и предсказуем, и при этом почти ничего не тратит впустую. Любопытно, как он проявит себя при тестировании на более сложных задачах.

Также бонусные очки начисляются ему за самую большую скорость: всего 34 секунды.

Gemini: профессор

Gemini — ужасный обжора, когда дело касается контекста. У него совершенно нет оверхеда определений инструментов, но он компенсирует это поглощением целиком в своё окно контекста файлов, историй git и результатов тестов.

Он начинает с поиска grep res.send (этап 2), затем считывает целиком файл lib/response.js (этап 3, 6,5K токенов). Далее он проверяет историю git (этап 4), которая возвращает лог коммитов для файла, и после этого всё начинает идти наперекосяк: этот единичный результат инструмента весит 118,5K токенов. Он решает считать git log -p lib/response.js, но не урезает вывод, поэтому просто скидывает в окно контекста историю на сотни коммитов.

Зато потом Gemini делает то, чего не делают другие инструменты: применяет TDD к самому себе, вне зависимости от существующего тестового набора. Он модифицирует тестовый файл, добавляя assertion для корректного поведения, прогоняет тесты, чтобы подтвердить их провал, применяет исправление, подтверждает прохождение тестов, а затем откатывает своё изменение в тестах и снова запускает весь набор. В моём промпте не говорилось об откате изменений в тестах, он сам решил, что это временный скаффолдинг.

Такой подход надёжен, но каждый этап добавляет контекст, который никогда не уменьшается. Gemini имеет огромное окно контекста и относительно низкие затраты на токен (а также кэширование), но тем не менее. Чтение тестового файла (3,6K), запуск модифицированного теста (17,1K) и повторный запуск всего тестового набора (16,9K) влетают в копеечку.

Если Opus — это хирург, то Gemini — пикап, хоть и очень маневренный. Похоже, его методика заключается в создании такого большого стога сена, что иголка просто обязана в нём появиться. Разумеется, может быть, что на это оптимизирована модель, учитывая её огромное окно контекста. Но нужно сказать, что каждый раз всё происходит по-разному: 179K, 244K, 350K в трёх прогонах. Мы не знаем наверняка, какая из версий Gemini будет нам помогать, но точно знаем, что она съест все наши печеньки.

Пустые траты

Ни один из этих подходов нельзя считать «всегда правильным». В этой задаче подход Opus определённо лучший просто потому, что сигнал находится прямо в истории git. Но если убрать историю git, то Opus не сможет пойти по короткому пути. Codex даже не заметит разницы. Gemini, вероятно, всё равно проглотит весь файл и вывалит весь тестовый вывод, потому что почему бы и нет.

Но думает ли какой-нибудь из этих инструментов о бюджете контекста? Похоже, Opus думает (возможно, случайно), ведь он выбрал наиболее эффективный источник информации. Остальные просто потребляют всё, что найдут. Ни один из них не урезает результат и не очищает контекст проактивно. А презрение, с которым Gemini считывает 118K за один этап, заставляет меня сравнить это с ужасно дорогим свиданием.

Похоже, что управление контекстом на стороне инструментов практически отсутствует. Разница в эффективности возникает целиком из-за стратегии исследования, а не из каких-то намеренных попыток управления окном контекста. Может быть, это сделано специально; эти инструменты сейчас ведут гонку за звание «лучшего», а не самого эффективного. Кэширование применяется для того, чтобы мы не тратили слишком много, но оно не помогает против порчи контекста (context rot).

Будущее

У меня есть предварительные результаты для пяти различных конфигураций git (отсутствие git, чистый репозиторий, полная история, ограниченная история), позволяющие увидеть, как доступный контекст меняет стратегию каждого инструмента. Opus становится менее эффективным без направляющей его истории git, у Sonnet без git возникают большие проблемы (58 вызовов API, 3 с лишним минуты, 79.9K токенов). Codex едва замечает разницу.

Интересной ситуация становится в задачах, заполняющих окно контекста, когда повадки чтения Gemini могут заставить его сжимать или урезать территорию, а у Opus 90% окна по-прежнему остаётся свободным. Но всё это уже тема для отдельного поста.

Попробуйте сами

Context Lens выложен в open source:

npm install -g context-lens context-lens claude # or codex, gemini, pi, aider, etc.

Он демонстрирует разбивку в реальном времени, diff между этапами и сигнализирует о проблемах, например, о слишком больших результатах инструментов. По сути, это вкладка «Сеть» devtools, только для вызовов LLM API. Если вам нужно что-то более легковесное, то попробуйте ContextIO — тулкит для мониторинга, редактирования и логирования вызовов LLM API.