# Opus 5.5 превратила эффективность токенов в вопрос учёта задач

Как оценивать токенную эффективность Opus 5.5 по эквивалентным принятым задачам с учётом повторов, проверки и изменения объёма работы.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-09-22
Первоисточник новости: https://www.anthropic.com/claude-opus-5-5
Канонический URL: https://retrivium.ai/ru/retrospectives/opus55-token-efficiency-task-accounting/

## Эффективность вышла за пределы цены токена

[Запись о выпуске Opus 5 датирована 24 июля 2026 года](https://platform.claude.com/docs/en/models/opus-5/overview). [Выпуск Fable 5.1 и Mythos 5.1 последовал 1 сентября](https://www.anthropic.com/claude-fable-and-mythos-5-1). [22 сентября Anthropic представила Opus 5.5](https://www.anthropic.com/claude-opus-5-5) с утверждениями о цене и работе на задачу. Это разные рычаги: снижение единичной ставки меняет счёт за неизменный объём, а более прямое решение способно изменить сам объём. Совместный эффект нельзя вывести из одного фактора отдельно. Поэтому анализ требует сначала определить, какой результат сравнивается и какие ресурсы действительно относятся к его получению.

## Короткий проход бывает незавершённым

Условная миграция кода заканчивается после основного преобразования, но пропускает требуемый случай совместимости. Токенов мало, однако принимаемый результат ещё не получен. Другой проход тратит больше токенов на обнаружение требования и правильно заканчивает миграцию. Ранжирование только по длине генерации вознаграждало бы неправильный исход. Эффективности задачи нужна стабильная граница приёмки, включающая содержательную проверку. Её определяют до сравнения, чтобы удобная ранняя остановка незаметно не стала успехом. Иначе сокращение работы будет выглядеть как улучшенное выполнение первоначального поручения, хотя условия уже изменились.

## Повторы относятся к тому же исходу

Неудачная попытка с последующим успешным повтором расходует ресурсы, относящиеся к итоговому решению. Учёт только последнего вызова скрывает издержки. Аналогично ручное исправление делает внешне недорогой результат затратным для завершения. Проверяемая запись связывает попытки и исправления с принятым артефактом, не предполагая автоматически известную денежную цену человеческого труда. Цель заключается в правильном отнесении расходов: отличить ресурсы получения результата от ресурсов последнего ответа. Это позволяет обсуждать причины различий, не заменяя полную историю удобным фрагментом, выбранным после получения успешного исхода.

## Сценарий с сохранённым контрактом

Представим условную миграцию библиотеки с фиксированным публичным интерфейсом и существующим набором регрессионных проверок. Для каждого кандидата сохраняются изменения, результат валидации, обращения к инструментам и доступные записи использования. Правило приёмки требует одинакового поведения. Тогда более дешёвый проход, изменивший интерфейс, виден как изменение объёма задачи, а не выигрыш эффективности. Здесь не утверждаются локальный результат или сбережение. Сценарий объясняет, как меньшее количество шагов становится содержательным свидетельством, одновременно не позволяя краткости подменить исходное требование и скрыть потерю нужного поведения приложения.

## Выпуск ставит вопрос измерения

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

## Связанные материалы

- [Учёт ресурсов на уровне задачи](/ru/journal/inference-economics/)
- [Эквивалентные критерии приёмки](/ru/journal/inference-benchmark-method/)