Из чего складывается счёт
У Fable 5.1 четыре тарифицируемые статьи, а не две. Обычный входящий токен — 10 долларов за миллион. Исходящий — 50. Запись в кеш — 12,5 за пятиминутный кеш и 20 за часовой. И чтение кеша — 0,25 доллара за миллион, самая низкая ставка в линейке Claude.
Рассуждение модели тарифицируется как исходящие токены, и это на Fable 5.1 существенно: мышление здесь отключить нельзя, а на тяжёлой задаче оно может занимать больше места, чем сам ответ. Поэтому расчёт «умножу ожидаемую длину ответа на цену выхода» систематически занижает реальный счёт.
| Статья | Fable 5.1 $/1M | Fable 5 $/1M | Opus 5 $/1M |
|---|---|---|---|
| Входящие токены | 10 | 10 | 5 |
| Запись в кеш, 5 мин | 12,5 | 12,5 | 6,25 |
| Запись в кеш, 1 час | 20 | 20 | 10 |
| Чтение кеша | 0,25 | 1,00 | 0,50 |
| Исходящие токены | 50 | 50 | 25 |
Почему чтение кеша важнее цены входа
В коротком диалоге кеш почти не влияет на счёт: контекст маленький, повторов мало. В агентном сценарии всё наоборот. Агент на каждом шаге отправляет заново системный промпт, описания инструментов и всю накопленную историю — и это тот самый стабильный префикс, который обслуживается из кеша.
Возьмём типичную сессию: стабильный префикс на 120 тысяч токенов, пятьдесят шагов агента. Без кеширования это 6 миллионов входящих токенов по 10 долларов за миллион — 60 долларов только на повторной отправке одного и того же. С кешированием тот же объём читается по 0,25 доллара за миллион и обходится примерно в полтора доллара плюс разовая запись в кеш.
Тот же расчёт на Fable 5 дал бы около 6 долларов за чтение — вчетверо больше при идентичном коде. Это и есть главная экономическая разница между версиями, и она проявляется только там, где кеширование настроено.
- Стабильный префикс в агентных сценариях — основной объём входящих токенов.
- Кеш снижает стоимость этого объёма в десятки раз.
- Не настроен кеш — сниженная ставка Fable 5.1 не даёт ничего.
Как не разрушить кеш случайно
Кеш работает по совпадению префикса: любое изменение байта в начале запроса обесценивает всё, что идёт после. Порядок такой: сначала инструменты, потом системный промпт, потом сообщения. Стабильное должно идти первым, изменчивое — последним.
Классические тихие убийцы кеша: текущее время или дата в системном промпте, идентификатор запроса в начале, неупорядоченная сериализация JSON в описании инструментов, набор инструментов, который меняется от запроса к запросу. Ничего из этого не вызывает ошибку — просто счёт вдруг оказывается в разы больше ожидаемого.
Проверяется это одним показателем: в ответе есть счётчик токенов, прочитанных из кеша. Если он равен нулю на повторяющихся запросах с одинаковым началом — кеш не работает, и надо искать, что именно меняется в префиксе.
На Fable 5.1 есть отдельная приятная деталь: смена уровня усилия посреди диалога больше не сбрасывает кеш, если передавать её отдельным системным сообщением, а не менять на верхнем уровне запроса.
- Стабильное — в начало запроса, изменчивое — в конец.
- Время, случайные идентификаторы и плавающий набор инструментов рвут кеш.
- Нулевой счётчик чтения из кеша — сигнал, что префикс нестабилен.
Уровень усилия — второй по силе рычаг
После кеширования самый заметный рычаг — уровень усилия. Он напрямую определяет, сколько модель потратит на рассуждение, а рассуждение тарифицируется по цене выхода, то есть 50 долларов за миллион.
Разумная практика: не задавать усилие глобально, а подбирать под маршрут. Кодинг и длинные агентные задачи отзываются на высокий уровень заметным приростом качества. Чат, классификация, извлечение полей, высокочастотные операции — почти нет, и там низкий уровень экономит деньги без потери результата.
Верхний уровень окупается только на действительно сложных задачах. Поднимать его имеет смысл тогда, когда замеры показывают, что уровнем ниже качество упирается в потолок — а не по умолчанию, на всякий случай.
- Рассуждение тарифицируется по цене выхода.
- Усилие подбирается под маршрут, а не задаётся глобально.
- Верхний уровень — только там, где замеры показали нехватку.
Каскад из моделей часто дороже одной модели
Распространённая идея экономии — гонять простые ходы на дешёвой модели, а сложные на Fable 5.1. Звучит логично, но у такого каскада есть скрытая стоимость: кеш привязан к модели. Переключились на другую модель — кешированный префикс не переиспользуется, и весь стабильный контекст оплачивается по полной ставке заново.
Плюс к этому на Fable 5.1 блоки мышления привязаны к сгенерировавшей их модели: при переключении они отбрасываются, и следующая модель не видит рассуждения предыдущей.
Прежде чем строить каскад, попробуйте более простой вариант — ту же модель на пониженном уровне усилия. Одна модель означает одно пространство кеша и один набор блоков мышления, и на практике это часто выходит и дешевле, и лучше по качеству, и заметно проще в поддержке.
- Кеш привязан к модели — каскад теряет его на каждом переключении.
- Блоки мышления между моделями не переносятся.
- Сначала измерьте одну модель на низком усилии, потом стройте каскад.
Считайте стоимость задачи, а не запроса
Главная ошибка при сравнении моделей — считать цену одного запроса. Дешёвый запрос, после которого нужны ещё три итерации и ручная правка, дороже одного дорогого, который решил задачу с первого раза. Это и есть аргумент в пользу Fable 5.1 там, где она уместна: не «дешевле за токен», а «дешевле за завершённую задачу».
И обратный аргумент ровно той же природы: в повседневной разработке задача чаще всего решается с первого раза и на Sonnet 5. Там двукратная переплата за токен не превращается ни в какую экономию — она просто переплата.
У нас расход считается по каждой модели отдельно, включая сниженную ставку на чтение кеша у Fable 5.1, и виден в личном кабинете. Это позволяет сравнить маршруты на своих настоящих данных, а не на оценках из статьи — включая нашу.
- Единица сравнения — завершённая задача, а не запрос.
- Fable 5.1 окупается там, где цена ошибки выше цены токенов.
- Расход по каждой модели виден в кабинете отдельной строкой.