Разбор whitepaper Сбера про AI-Disrupt PDLC: одна цифра и две базы сравнения
Автор Хабра разобрал whitepaper Сбера «AI-Disrupt PDLC» и сверил его цифры со своей телеметрией Claude Code и Codex CLI за 30 дней. Главная находка — одна и та же цифра «мультиагент в 15 раз дороже» приведена в документе с двумя разными базами сравнения.
- В разделе 2.9 whitepaper Сбера 15x отнесены к одиночному агенту, в разделе 5.2 те же 15x — к чату.
- Расхождение между прочтениями четырёхкратное: по 5.2 мультиагент к одиночному агенту даёт 3,75x, по 2.9 — 15x.
- По телеметрии автора сессия с субагентами в среднем в 33 раза дороже сессии без них, кэш удешевил вход в 7,8 раза при заявленных «до 10».

Автор Хабра разобрал whitepaper Сбера «AI-Disrupt PDLC» — документ о перестройке жизненного цикла разработки вокруг намерения человека, выпущенный в мае. В сентябре его уже разбирал Олег Бунин, отделив инженерную рамку от продуктовой витрины. Новый разбор сосредоточен на числах о стоимости агентной работы: у автора на диске лежит собственная телеметрия Claude Code и Codex CLI за 30 дней, с 23 августа по 21 сентября 2026.
Цифра, которая спорит сама с собой
В полной версии документа мультиагентная надбавка названа дважды. В разделе 2.9 сказано, что мультиагентный режим потребляет примерно в 15 раз больше токенов, чем одиночный агент. В разделе 5.2 та же цифра 15x отнесена к чату: одиночный агент даёт 4x, мультиагент — 15x.
Если база в обоих случаях одна, то мультиагент к одиночному агенту выходит 15/4, то есть 3,75x. Если же 15x относится прямо к одиночному агенту, к чату это было бы 60x. Разница между прочтениями четырёхкратная, и для планирования это два разных решения.
Цифра 15 не принадлежит Сберу: в разделе 5.2 она атрибутирована Anthropic, и в исходной публикации речь тоже про сравнение с чатом. Похоже, в 2.9 её пересказали с потерей базы сравнения. Документ не объясняет, что речь о разных режимах или выборках.
Что показывает телеметрия
Автор ведёт всю работу агентными инструментами, и логи пишутся сами. Claude Code сохраняет транскрипт каждой сессии в ~/.claude/projects/<путь>/<session-id>.jsonl, где у ответов модели есть блок usage с полями input_tokens, output_tokens, cache_creation_input_tokens и cache_read_input_tokens. Codex CLI ведёт rollout-логи с накопительным полем total_token_usage.
За 30 дней набралось 320 сессий с ответами в Claude Code и 417 rollout-файлов с usage в Codex CLI. Выходных токенов — 38 830 218 и 4 091 283 соответственно, весь вход — 18 979 609 667 и 843 609 256. Доля чтения кэша во входе — 97,4% и 95,1%.
Сессии делятся естественно: в 29 из 320 были субагенты (509 запусков, 561 файл транскриптов), в остальных 291 работа шла одним агентным контекстом. Средние выходные токены с субагентами — 1 036 922 против 30 101 без них, отношение 34,4x. Медианные — 502 435 против 4 883, отношение 103x. Средний весь вход плюс выход — 502 864 074 против 15 241 862, отношение 33,0x.
Автор оговаривается, что сравнение не контролируемое: субагентов он запускает на крупных задачах, а в группе без них много коротких автоматических прогонов. В отношении 33x смешаны цена мультиагентной схемы и размер задачи. Сессий с субагентами всего 29, так что средние неустойчивы.
Вывод узкий: если взять средний расход сессии без субагентов и умножить на 15, прогноз для сессий с субагентами недооценит их примерно вдвое. Это говорит об ошибке такой модели прогноза, а не о величине мультиагентной надбавки.
Кэш: расчёт совместим с ориентиром
Короткая версия документа, раздел 4.4, обещает «до 10-кратного снижения стоимости входных токенов при повторах». Автор посчитал только вход по официальному прайсу Anthropic на сентябрь 2026 и по каждой модели отдельно: у разных моделей разный множитель чтения кэша (0,1 от цены входа у большинства, 0,05 у Opus 5.5, 0,025 у Fable 5.1), а запись в кэш стоит 1,25 или 2 цены входа в зависимости от срока хранения.
Фактически с кэшем входные токены обошлись в $12 069, тот же объём без кэширования стоил бы $94 320. Экономия — 7,8x, то есть 87,2%. Почти восьмикратно при заявленном «до десяти». Это тарифный пересчёт, а не эксперимент: он показывает, что наблюдаемое значение совместимо с ориентиром документа.
Чего расчёт не показывает — что основной вклад дают именно системные инструкции. Доля чтения кэша у автора 97% по всему входу, а что в нём инструкции и что рабочий контекст, телеметрия не различает.
Скрипт для собственного подсчёта автор приводит в конце статьи на Хабре.
Для профиТехнические детали: архитектура, цифры, ссылки
Методика подсчёта из разбора:
- Claude Code повторяет блок usage в каждой строке одного ответа — складывать построчно нельзя, выход завышается в 1,7 раза, а по основным файлам сессий без субагентов — в 2,1. Считать нужно один раз на message.id.
- Субагенты лежат отдельно, в <session-id>/subagents/*.jsonl. Обход только верхнего уровня их не видит, и сессии с субагентами выглядят дешевле, чем есть.
- В Codex CLI поле last_token_usage повторяется в служебных событиях без нового запроса — надёжнее брать приращения накопительного total_token_usage.
Тарифные множители чтения кэша: 0,1 от цены входа у большинства моделей, 0,05 у Opus 5.5, 0,025 у Fable 5.1. Запись в кэш — 1,25 или 2 цены входа в зависимости от срока хранения; в логах автора около 72% токенов записи приходится на часовой кэш.
Вопросы и ответы
- В чём именно противоречие в whitepaper Сбера?
- В разделе 2.9 цифра 15x отнесена к одиночному агенту, а в разделе 5.2 те же 15x — к чату. При одной базе сравнения мультиагент к одиночному агенту даёт 3,75x, при другой — 15x.
- Совпал ли расчёт кэша с ориентиром документа?
- Да. Автор насчитал экономию входа в 7,8 раза (87,2%) при заявленном в документе «до 10-кратного снижения».
- Чья это цифра — Сбера или Anthropic?
- В разделе 5.2 цифра 15x атрибутирована Anthropic, и в исходной публикации она тоже про сравнение с чатом.



