В мае 2026 года Сбер выпустил whitepaper «AI-Disrupt PDLC», посвященный перестройке жизненного цикла разработки вокруг намерения человека. В сентябре независимый разработчик и автор блога на Хабре Олег Бунин опубликовал разбор этого документа, отделив инженерную составляющую от маркетинговой. Однако позже другой исследователь, проанализировав собственные логи использования агентных инструментов, обнаружил в whitepaper внутреннее противоречие: одна и та же цифра — 15-кратное превышение расхода токенов мультиагентными системами — приводится с двумя разными базами сравнения. Это расхождение, по мнению разработчика, может вводить в заблуждение при планировании бюджетов на ИИ-агентов.

Суть проблемы в следующем. В полной версии документа на 175 страницах мультиагентная надбавка упоминается дважды. В разделе 2.9, посвященном паттернам мультиагентных систем, сказано: «Мультиагентный режим потребляет примерно в 15 раз больше токенов, чем одиночный агент». В разделе 5.2, о токеномике, та же цифра 15 приводится со ссылкой на данные Anthropic, но уже в сравнении с чат-взаимодействиями: «агенты потребляют примерно в 4 раза больше токенов, чем чат-взаимодействия, а мультиагентные системы — примерно в 15 раз больше». Если база — чат, то мультиагентный режим превышает одиночного агента в 15/4 = 3,75 раза. Если же база — одиночный агент, как в разделе 2.9, то превышение над чатом составило бы 60 раз. Разница между прочтениями четырехкратная, и для планирования это два совершенно разных решения: по одной версии мультиагентные системы дороже одиночного агента менее чем в четыре раза, по другой — в пятнадцать.

Разработчик, ведущий всю работу агентными инструментами, решил проверить, какая из трактовок ближе к реальности. Он использовал телеметрию Claude Code и Codex CLI за 30 дней (с 23 августа по 21 сентября 2026 года). Claude Code записывает транскрипты сессий в формате JSONL, где для каждого ответа модели есть блок usage с полями input_tokens, output_tokens, cache_creation_input_tokens и cache_read_input_tokens. Codex CLI ведет rollout-логи с накопительным полем total_token_usage. При подсчете разработчик столкнулся с двумя ловушками: в Claude Code блок usage повторяется в каждой строке одного ответа, поэтому при построчном суммировании выход завышается в 1,7–2,1 раза; кроме того, субагенты лежат в отдельных файлах, и их обход требует дополнительного шага. У Codex аналогичная проблема с полем last_token_usage, которое дублируется в служебных событиях. В итоге для анализа использовались приращения накопительного total_token_usage. Всего было проанализировано 320 сессий, из которых в 29 запускались субагенты (509 запусков, 561 файл транскриптов).

Сравнение показало, что если взять средний расход сессии без субагентов и умножить на 15, прогноз для сессий с субагентами недооценит их примерно вдвое. Однако разработчик подчеркивает, что это не опровергает величину мультиагентной надбавки как таковой: его данные не контролируемые, поскольку субагенты запускались на крупных задачах, а в группе без них много коротких автоматических прогонов. В отношении 33x смешаны цена мультиагентной схемы и размер задачи. Кроме того, состав моделей различается: субагенты на две трети работают на Sonnet 5, основной контекст сессий с ними — на Opus 5 и Fable 5.1, а сессии без субагентов — в основном на Opus 5. Модели по-разному многословны, и тарифы на выходные токены у них отличаются: средняя цена выходного токена субагентов примерно в 1,8 раза ниже, чем у основного контекста рядом с ними. Поэтому вывод узкий: модель прогноза, основанная на простом умножении на 15, дает ошибку, но это не значит, что сама надбавка неверна — бюджет, учитывающий размер задач, может сойтись и с меньшим коэффициентом.

Отдельно разработчик проверил утверждение о кэшировании. В короткой версии whitepaper (раздел 4.4) сказано: «Кэширование системных инструкций — до 10-кратного снижения стоимости входных токенов при повторах». Расчет по официальному прайсу Anthropic на сентябрь 2026 года с учетом разных множителей чтения кэша (0,1 от цены входа у большинства моделей, 0,05 у Opus 5.5, 0,025 у Fable 5.1) и стоимости записи в кэш (1,25 или 2 цены входа в зависимости от срока хранения) показал почти восьмикратное снижение при заявленном «до десяти». Это тарифный пересчет, а не эксперимент, но он подтверждает, что наблюдаемое значение совместимо с ориентиром документа. Однако телеметрия не различает, какая доля входных токенов приходится именно на системные инструкции, а какая — на рабочий контекст, поэтому основной вклад кэширования в экономию остается недоказанным.

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

Стоит отметить, что цифра 15 не принадлежит Сберу: в разделе 5.2 она атрибутирована Anthropic, и в исходной публикации она также относится к сравнению с чатом. Похоже, в разделе 2.9 ее пересказали с потерей базы сравнения. Документ не объясняет, что речь идет о разных режимах или выборках, поэтому как минимум формулировку стоит согласовать. В более широком контексте это указывает на общую проблему отраслевых отчетов: метрики, полученные в одном контексте, часто переносятся в другой без указания условий. Для читателей же остается открытым вопрос, как правильно калибровать бюджеты на агентные системы — нужны контролируемые эксперименты, в которых одинаковые задачи решаются в одиночном и мультиагентном режимах. Пока таких данных на российском рынке практически нет.