Claude Fable 5.1: почему снижение тарифа не гарантирует дешёвую задачу

Два утверждения в одной публикации

The Decoder передаёт заявление Anthropic о снижении расходов благодаря более дешёвому чтению кэша. По сообщению издания, остальные основные тарифы API не изменились. Следовательно, размер возможной экономии связан со структурой нагрузки, а не только с названием модели.

В обновлении статьи приводится возражение Artificial Analysis: на максимальном уровне усилий Fable 5.1 использует больше выходных токенов и обходится дороже предшественника на измеряемую задачу. Это существенная оговорка, которую нельзя выбрасывать при пересказе рекламного процента.

Источник также сообщает об улучшениях в программировании и исследовательских испытаниях. Однако рост показателя качества не отвечает автоматически на вопрос о бюджете: покупатель может получить более сильный результат, но заплатить за него больше.

Проверить собственную структуру запросов

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

В журнале запуска нужны фактические объёмы входа, выхода и чтения кэша. Рядом следует сохранять режим усилий, версию инструкции и итог приёмки. Без этих полей одинаковые на вид счета могут относиться к совершенно разной работе.

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

Сопоставлять режимы, а не только названия

Для пилота предлагаем заранее выбрать допустимую задержку и уровень качества. Затем сравнить несколько режимов модели в этих ограничениях. Максимальные усилия стоит включать там, где дополнительное рассуждение действительно помогает пройти приёмку сложного результата.

Если простое задание одинаково успешно решается в более лёгком режиме, дополнительный расход следует показать отдельно. Если сложная задача проходит только в дорогом режиме, это тоже полезный вывод, но называть его общей экономией было бы неверно.

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

Что включить в решение закупщика

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

Для исследовательских задач отдельно проверяйте источники, а для программирования — работоспособность изменения. Общий рейтинг модели не заменяет эти процедуры. Убедительный текст объяснения и успешное завершение конкретного задания должны оцениваться независимо друг от друга.

В статье различаются условия доступа к Fable и Mythos. Поэтому перед планированием сравнения нужно подтвердить доступность именно выбранного продукта в нужном канале. Нельзя переносить результаты или ограничения одной версии на другую по сходству названий.

Условие перехода

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