Экономия токенов в Code Mode

Команда Agent Swarm протестировала идею "code mode" на своей рабочей нагрузке в продакшене и опубликовала расчёты. Главный результат, который они выносят вперёд, - сокращение объёма данных, попадающих в контекст модели, на 99.2%. Это замер вендора на собственном продукте и собственных данных, что авторы признают и частично компенсируют, показывая все промежуточные цифры. Методология здесь - самое интересное; громкую цифру из заголовка независимо воспроизвести нельзя.

Предыстория обозначена сразу. В статье Anthropic об исполнении кода с MCP задача требовала 150 000 токенов при прямых вызовах инструментов против 2 000 через сгенерированные API в песочнице - сокращение на 98.7% благодаря тому, что промежуточные результаты остаются в среде исполнения, а агент видит только то, что вы логируете или возвращаете. Cloudflare выпустила ту же идею в сентябре под названием Code Mode и позже зафиксировала падение с 1.17 млн токенов до примерно 1 000 на 2 500+ эндпоинтах API. Вклад Agent Swarm не в самой идее - они и так включают правило в системный промпт каждой сессии (system.agent.context_mode), предписывая агенту писать скрипт вместо отправки N вызовов при обработке десяти и более элементов или массовом ветвлении, - а в её измерении по мерке Anthropic на реальных данных.

Рабочая нагрузка

Объект исследования - workflow-triage, скрипт, написанный двумя их собственными агентами, который может вызывать любой агент в swarm'е. Он сканирует все workflow и расписания cron и помечает каждый как мёртвый, сбоящий или рабочий. Это 26 вызовов к их каталогу в продакшене из 24 workflow и 60 расписаний: один workflow_list, один schedule_list и по одному workflow_listRuns на каждый workflow. При прямом выполнении все 26 необработанных JSON-ответов попадают в контекст агента и остаются там до конца диалога. При запуске в виде скрипта те же 26 вызовов происходят внутри изолированного подпроцесса в песочнице, а назад возвращается один итоговый объект.

Никаких фреймворков здесь нет, о чём авторы говорят сами. Скрипт представляет собой цикл с пулом параллельности на шесть потоков, вызовами Date.parse, сортировкой и возвратом значения. Единственное, что делает его режимом кода, - это место выполнения вызовов: каждый результат ctx.swarm.workflow_listRuns попадает в локальную переменную и никогда не оказывается в стенограмме диалога.

Цифры и что именно измерялось

Вариант со скриптом измерен точно: один вызов, durationMs: 13120, результат на 25 811 символов, около 6 450 токенов из расчёта четыре символа на токен (токенизатора под рукой у них не было), примерно $0.02 по тарифу Claude Sonnet 5 в $3 за миллион входных токенов.

Вариант с прямыми вызовами сначала измерен, а затем экстраполирован, и авторы прямо указывают на место склейки. Два вызова со списками были выполнены по-настоящему: workflow_list({}) вернул 16 304 символа, а schedule_list({}) - 72 105 символов. Для запусков по отдельным workflow они взяли выборку из четырёх штук разного масштаба: 6 запусков на 98 706 символов, 26 запусков на 293 036, 53 запуска на 157 720 и 227 запусков на 525 968. Суммарно это дало 1 075 430 символов на 312 проверенных запусков, то есть в среднем 3 447 символов на запуск. Экстраполяция этого среднего на 920 запусков, зафиксированных скриптом по всем 24 workflow, даёт около 3.17 млн символов. Вместе с двумя вызовами списков получается примерно 3 259 649 символов или около 815 000 токенов: $2.44 по тому же тарифу и разница в 126 раз.

Две оговорки делают сами авторы, а ещё одна касается арифметики. Они отказались реально запускать все 26 прямых вызовов, поскольку это затянуло бы 3.2 миллиона символов JSON прямо в сессию, где писалась статья, - то самое решение, которое их правило предписывает принимать агенту. Они также отмечают, что параметр limit: 25 в вызове workflow_listRuns ничего не ограничивает: самый загруженный workflow вернул все 227 запусков, так что полученная оценка для прямого пути - это нижняя граница, а не верхняя. Оценка в $2.44 является нижней границей и по другой причине: она считает стоимость токенов однократно, будто всё попало в контекст за один шаг, тогда как в реальном цикле на 26 шагов каждый результат отправляется во входных данных на каждом последующем шаге. Авторы признают, что не могут обосновать точный множитель без запуска неэкономной версии, и честно останавливаются на этом.

Арифметическая оговорка, которую они не упоминают, кроется в структуре среднего значения по выборке. Размер ответа на один запуск в их собственной выборке варьируется от примерно 16 451 символа (98 706 на 6 запусков) до 2 317 (525 968 на 227) и обратно пропорционален числу запусков: у самых нагруженных workflow размер данных на один запуск наименьший. Сведение этих цифр в единое среднее в 3 447 символов с умножением на 920 запусков смещает экстраполяцию в сторону редких workflow с тяжеловесными ответами, поэтому оценка для прямого пути, скорее всего, завышена. Это противоречит аргументам о нижней границе, а не дополняет их, и итоговый знак суммарной погрешности по опубликованным данным определить невозможно.

Сравнительная таблица по моделям - это просто пересчёт тех же двух объёмов токенов по тарифам пяти провайдеров на входные токены прямого API из их актуального кэша цен, проверенного на дату публикации: claude-opus-4-8 по $5.00/млн ($0.032 против $4.08), claude-sonnet-5 по $3.00 ($0.019 против $2.44), claude-fable-5 по $10.00 ($0.065 против $8.15), gpt-5.5 по $5.00 ($0.032 против $4.08), glm-5.2 по $1.40 ($0.009 против $1.14). Поскольку обе колонки масштабируются одинаково, таблица лишь показывает уровни цен, не добавляя новых доказательств: как отмечают сами авторы, экономия заключается в количестве токенов, а не в ценообразовании.

Что это решает, а что нет

Сам механизм бесспорен и не нуждается в их измерениях, чтобы быть верным: за данные, которые не попадают в стенограмму, не нужно платить, и они не забивают контекстное окно. Это тот же подход, что и в agent-built-deterministic-tools, где LLM один раз пишет детерминированный анализатор, а вся дальнейшая работа агента ограничивается его выводом: workflow-triage буквально и есть такой артефакт, написанный агентами и теперь вызываемый как инструмент. Это также проясняет часть о доступе к сервисам в mcp-vs-skills: низкоуровневый набор инструментов MCP здесь заменяется, а не используется напрямую.

Неучтённая в расчётах часть - взаимодействие с prompt-caching-in-agents. Их нижняя граница в $2.44 предполагает, что 26 результатов при прямом пути оплачиваются один раз, и авторы утверждают, что реальный цикл стоил бы заметно дороже, так как каждый результат повторно попадает во входной контекст на каждом шаге. При работающем кэшировании промптов эти повторные отправки тарифицируются со скидкой за чтение из кэша, а не по полной стоимости входа, - это как раз тот множитель, который они отказались называть. Но есть и обратный эффект: вызов скрипта - это одно добавление к стабильному префиксу, поэтому режим кода лучше утилизирует кэш, чем ветвление на 26 шагов, и ни один из этих эффектов в таблице не отражён. А с точки зрения потребления ai-token-budget-explosion описывает компании, у которых вообще нет применимых измерений затрат на задачу, - и этот пост представляет собой небольшой, предвзятый, но исключительно подробно задокументированный пример попытки такого измерения.

portal-shunt-token-routing применяет тот же приём с удержанием данных вне стенограммы к чтению файлов, отправляя их более дешёвой модели через хуки Claude Code.