Одна цифра в двух смыслах: читаю whitepaper Сбера про AI-Disrupt PDLC со своей телеметрией в руках

В мае Сбер выпустил whitepaper “AI-Disrupt PDLC” – документ о том, как перестраивать жизненный цикл разработки вокруг намерения человека. В сентябре Олег Бунин разобрал его на Хабре ^[1], отделив инженерную рамку от продуктовой витрины.

Меня в этом документе зацепили числа про стоимость агентной работы, потому что у меня на диске лежит телеметрия: я веду всю работу агентными инструментами, и логи пишутся сами. Я скачал обе версии whitepaper – короткую и полную на 175 страниц – посчитал свой расход и сел сравнивать.

Главное, что я нашел, относится к самому документу: одна и та же цифра употреблена в нем с двумя разными базами сравнения, и расхождение между прочтениями четырехкратное. Об этом ниже, сначала про данные.

Данные и как они получены

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 дней, с 23 августа по 21 сентября 2026 включительно – по времени каждого ответа, а не по дате начала сессии, так что длинные сессии, начатые раньше, попадают в окно своей частью.

Две грабли для тех, кто будет считать сам – на обе я наступил в первой версии подсчета:

• Claude Code повторяет блок usage в каждой строке одного ответа. Ответ из нескольких блоков пишется несколькими строками, и в каждой один и тот же usage. Если складывать построчно, выход на этом окне завышается в 1,7 раза, а по основным файлам сессий без субагентов – в 2,1. Считать надо один раз на message.id.

• Субагенты лежат отдельно, в <session-id>/subagents/*.jsonl. Обход только верхнего уровня их не видит, и сессии с субагентами выглядят дешевле, чем есть.

• У Codex похожая ловушка: поле last_token_usage повторяется в служебных событиях без нового запроса. Надежнее брать приращения накопительного total_token_usage.

Работа смешанная: разработка, управленческая рутина, разбор документов, переписка, плюс автоматические прогоны по расписанию. Один человек, 30 дней. К границам этих данных я вернусь отдельным разделом.

Цифра, которая спорит сама с собой

В полной версии документа мультиагентная надбавка названа дважды.

Раздел 2.9, про паттерны мультиагентных систем:

Цена такой схемы существенная. Мультиагентный режим потребляет примерно в 15 раз больше токенов, чем одиночный агент. Это плата за координацию, передачу контекста между ролями и повторные вычисления.

Раздел 5.2, про токеномику:

По данным Anthropic, агенты потребляют примерно в 4 раза больше токенов, чем чат-взаимодействия, а мультиагентные системы – примерно в 15 раз больше.

Во втором случае база – чат: одиночный агент дает 4x, мультиагент 15x, откуда мультиагент к одиночному агенту выходит 15/4, то есть 3,75x. В первом случае те же 15x отнесены прямо к одиночному агенту – к чату это было бы 60x.

Разница между прочтениями четырехкратная, и для планирования это два разных решения: соотношение приведенных ориентиров по 5.2 – чуть меньше четырех раз, по 2.9 – пятнадцать.

Цифра 15 при этом не принадлежит Сберу: в 5.2 она атрибутирована Anthropic, и в исходной публикации ^[2] она тоже про сравнение с чатом. Похоже, в 2.9 ее пересказали с потерей базы сравнения. Документ не объясняет, что речь о разных режимах или выборках, поэтому как минимум формулировку стоит согласовать.

Что на этот счет показывает моя телеметрия

Мои сессии делятся естественно: в 29 из 320 были субагенты (509 запусков, 561 файл транскриптов), в остальных 291 работа шла одним агентным контекстом. То есть знаменатель у меня – одиночный агент, как в формулировке 2.9. Расход субагентов приписан родительской сессии.

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

Поэтому вывод узкий: если взять средний расход моей сессии без субагентов и умножить на 15, прогноз для сессий с субагентами недооценит их примерно вдвое. Это говорит об ошибке ^[3] такой модели прогноза, а не о величине мультиагентной надбавки: бюджет, который учитывает размер задач, отправляемых на мультиагентную схему, может сойтись и с меньшим коэффициентом.

Кэш: расчет совместим с ориентиром

Короткая версия, раздел 4.4:

Кэширование системных инструкций – до 10-кратного снижения стоимости входных токенов при повторах

Речь о стоимости входных токенов, с условием “при повторах”. Считаю только вход, по официальному прайсу Anthropic на сентябрь 2026 и по каждой модели отдельно: у разных моделей разный множитель чтения кэша (0,1 от цены входа у большинства, 0,05 у Opus 5.5, 0,025 у Fable 5.1), а запись в кэш стоит 1,25 или 2 цены входа в зависимости от срока хранения – в моих логах около 72% токенов записи приходится на часовой кэш.

Почти восьмикратно при заявленном “до десяти”. Это тарифный пересчет, а не эксперимент: он показывает, что наблюдаемое значение совместимо с ориентиром документа.

Чего мой расчет не показывает: что основной вклад дают именно системные инструкции. Доля чтения кэша у меня 97% по всему входу, а что в нем инструкции и что рабочий контекст, телеметрия не различает.

Бюджеты на сессию: данные для калибровки ориентира

В короткой версии заданы конкретные бюджеты:

Защита от роста потребления токенов строится на трех уровнях бюджета: per-task (в зрелой команде ~50K токенов), per-session (~200K) и per-horizon (~500K, кумулятивно по всем сессиям). Превышение 80% любого бюджета – автоматический запрос подтверждения у оператора.

А в полной версии, в 5.2, уточнено, что это “калибровочные значения по внутренним наблюдениям Сбера, настраиваются под организацию”, и что бюджет на горизонт – “кумулятивный бюджет на всю задачу через все сессии”.

Сравниваю с собой по сумме входа и выхода на сессию. Уже внутри окна расход превышает 200K у 89 сессий из 320, то есть 28%, включая все 29 сессий с субагентами; порог подтверждения в 80% (160K) превышают те же 89. Для сессий, начатых раньше окна, это нижняя оценка: их полный расход не меньше. При этом медианная сессия без субагентов расходует около 42 тысяч токенов входа и выхода вместе – впятеро меньше порога.

Распределение показывает, на каких сессиях выбранный порог срабатывал бы: у меня это практически все длинные агентные цепочки и почти никогда короткие прогоны. Срабатывание предохранителя само по себе не дефект – он ровно для этого и нужен. Такие данные – материал для калибровки, которую документ прямо предусматривает.

FinOps: на этих данных прогноз не проверяется

Короткая версия:

К 2027 году без системного контроля затраты на агентов могут составить 40-60% ИТ-бюджета.

Это возможный сценарий при отсутствии контроля, и мои данные проверить его не могут: у меня нет ИТ-бюджета, то есть знаменателя.

Что я могу показать – разницу между моделями оплаты. Мой объем за эти 30 дней по прайсу API стоил бы $13 027 (вход плюс выход, только Claude; codex в эту сумму не входит). Фактически я работал по подпискам: Claude за $200 в месяц – это в 65 раз меньше расчетной суммы, плюс Codex за $100, который в расчет по API не входит. Для тех, кто платит по токенам, раздел документа про circuit breakers, бюджеты и маршрутизацию написан как раз под их контур. Но переносить цифру “40-60% бюджета” на небольшую команду стоит, сперва посмотрев, по какой модели она платит.

Разные инструменты в одном конвейере

Я работаю двумя инструментами сразу: Claude Code делает, Codex CLI проверяет независимым проходом. Расход у них такой:

Сессий у Codex больше, расход – в разы меньше. Это разные работы, создание против независимого ревью, поэтому сравнением стоимости одинаковой задачи мои числа не являются. Иллюстрируют они другое: словосочетание “агентная разработка” не задает ни порядок расхода, ни его структуру – один контур держит большой рабочий контекст и перечитывает его на каждом шаге длинной цепочки, другой получает самодостаточный бриф и отвечает одним проходом.

С этим созвучен принцип документа “Среда важнее модели”, вынесенный в названия трех разделов (1.2, 2.3, 4.2). У Сбера он про качество результата, у меня – про расход, так что это общая идея, а не подтверждение моих чисел.

Границы этих данных

• n = 1. Один инженер, 30 дней. Не команда, не организация, без контрольной группы.

• Часть транскриптов не сохранилась. Считал то, что лежит на диске; сколько сессий за окно пропало, я не знаю, и полнота выборки не гарантирована.

• Состав работы смешанный, включая автоматические прогоны по расписанию; доля чистой разработки не выделена.

• Сравнение с субагентами не контролируемое: в нем смешаны схема, размер задачи и состав моделей, сессий с субагентами 29 – причинный эффект мультиагентности из моих данных не выводится.

• Пять моделей Claude в одном котле, с разными ценами и множителями кэша; задачи между ними распределялись по ходу дела.

• Стоимость API расчетная. $13 027 – это прайс, умноженный на мои токены; реального счета на эту сумму не было. Codex в денежном расчете не участвует.

• Все, что я читал – два опубликованных PDF. Внутренней практики Сбера я не видел, и о том, как их цифры получены, сужу по тексту.

Что из этого следует

Главная находка – текстовая: мультиагентная надбавка в документе названа дважды и с разной базой сравнения, 15x против одиночного агента и 15x против чата. Для планирования это разница вчетверо, и ее стоит согласовать в следующей редакции.

Остальные сопоставления дали более скромный результат, и мне кажется, это честно. Экономия на кэше по моему расчету совместима с ориентиром “до 10x”. Распределение расхода по сессиям показывает, где выбранный порог срабатывал бы, и годится как материал для калибровки, которую документ предусматривает. Прогноз по доле ИТ-бюджета на моих данных не проверяется. А простое умножение на 15 от среднего расхода одиночного агента в моем профиле недооценивает сессии с субагентами, но причину – надбавка это или размер задач – мои данные не различают.

И общее наблюдение. Телеметрия агентной работы лежит на диске у каждого, кто ею пользуется; чтобы посчитать свою, нужен час и немного Python – и внимание ^[4] к двум граблям из начала статьи. Если бы такие замеры публиковали чаще, разговор об эффекте AI в разработке опирался бы на распределение чисел из разных источников.

Скрипт подсчета готов выложить, если будет интерес ^[5] – он простой и повторяемый.