Claude Fable 5.1 или GPT-6 Astra для базы знаний: считаем стоимость 20 обращений и границу экономии

Материал команды RaketaPay. Мы занимаемся оплатой зарубежных сервисов; в этом разборе рассматриваем расходы на API, а не оцениваем интеллект ^[1] моделей.

У Claude Fable 5.1 чтение кэша в четыре раза дешевле, чем у GPT-6 Astra. Звучит как готовый аргумент для выбора. Но в нашем расчетном сценарии весь сеанс дешевеет лишь на 16,7%. А если Fable расходует на каждый ответ на 1425 оплачиваемых выходных токенов больше, преимущество исчезает.

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

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

Какую задачу разбираем

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

В такой базе могли бы лежать спецификация API, описание статусов, правила обработки вебхуков, инструкция по возвратам и журнал изменений. Это пример состава базы, не собранный нами корпус. Мы не утверждаем, что конкретный набор этих документов занимает 100 тысяч токенов.

Для финансовой модели зададим общую основу из документов и постоянной инструкции на 100 тысяч токенов. К ней в каждом обращении добавляется вопрос на 2 тысячи токенов. Оплачиваемый выход — 5 тысяч токенов. Всего обращений 20.

История разговора не накапливается: каждый раз передаются одна и та же основа и новый вопрос. Нет поиска в интернете, вызовов инструментов, повторных попыток и отдельно тарифицируемого хранения. Сравниваем стандартную обработку, без Batch, ускоренных режимов и региональных надбавок. Все суммы — в долларах США, до налогов и расходов на оплату.

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

Одинаковый текст у разных провайдеров может занимать разное число токенов. Равные объемы здесь нужны, чтобы отдельно увидеть влияние ставок. Для бюджета реального проекта их придется заменить собственными показателями API; по длине видимого ответа оплачиваемый выход определять нельзя.

Почему четырехкратная скидка не уменьшает счет вчетверо

Базовые ставки входа и выхода у выбранных моделей совпадают. Различается цена повторного чтения общей основы. В таблице указана стоимость миллиона токенов в USD; для Astra выбран 30-минутный кэш, для Fable — пятиминутный.

Источники ставок: карточка GPT-6 Astra ^[2] и тарификация Anthropic ^[3]. Это цены прямых API, не подписок ChatGPT или Claude и не предложения посредника.

Сначала контрольный расчет без кэша. За 20 обращений получаем 2,04 млн входных токенов и 100 тысяч выходных:

2,04 × $10 + 0,1 × $50 = $25,40.

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

Разница — $1,425, или примерно 16,7% от счета Astra. Итог Fable при округлении до центов — $7,13, но промежуточные вычисления лучше вести без округления.

Вся экономия появилась в одной строке: повторном чтении. За выход обе модели получили бы по $5. Поэтому фраза «кэш дешевле в четыре раза» описывает тариф отдельной операции, а не стоимость всей работы.

Где расчет может разойтись с реальным счетом

Самое сильное допущение здесь — 19 успешных чтений. Они не возникают от одной надписи «используем кэш» в архитектурной схеме.

Постоянные инструкции и документы следует держать в начале запроса, а изменяющиеся сведения — после них. Но стабильного начала недостаточно: граница кэширования должна соответствовать общей части. Если записать весь первый запрос вместе с уникальным вопросом, следующий вопрос не обязан переиспользовать нужный префикс. В актуальной документации OpenAI ^[4] это отдельно разобрано; у Anthropic нужно корректно разместить cache_control ^[5].

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

Время между обращениями тоже важно. Выбранный кэш Fable имеет минимальный срок действия пять минут с обновлением при использовании. У выбранного режима Astra — минимум 30 минут. Нельзя автоматически ожидать одинакового количества попаданий, если сотрудник задает вопросы с длинными паузами. Более длительное хранение существует, но оплачивается по другим ставкам.

Посмотрим, насколько это влияет на наш пример. Оставим Astra одну запись и 19 чтений. Если у Fable общую основу пришлось записать дважды, а прочитать 18 раз, итог Fable составит $8,35. Если записать трижды и прочитать 17 раз — уже $9,575. Первоначальное преимущество сменится переплатой относительно $8,55 у Astra.

Это не прогноз поведения ^[6] провайдеров. Это ответ на конкретный бюджетный вопрос: сколько повторных записей выдерживает выбранная смета.

Для проверки нужны показатели использования, а не только общая сумма списания. У OpenAI следует смотреть обычный вход, cached_tokens и cache_write_tokens с учетом структуры usage. У Anthropic отдельно возвращаются input_tokens, cache_creation_input_tokens и cache_read_input_tokens. Названия похожи, но складывать их одинаковым способом без проверки документации нельзя.

Отдельный практический вопрос — как оплатить выбранный API. В RaketaPay можно уточнить возможность оплаты ^[7] конкретного сервиса и доступные способы пополнения. Способ оплаты не меняет тарифы провайдера, его правила доступа или результат этого расчета.

1425 дополнительных токенов обнуляют преимущество

Теперь кэш работает идеально, но выход Fable длиннее.

В нашем расчете сэкономлено $1,425. При ставке $50 за миллион выходных токенов эту сумму израсходуют 28 500 дополнительных токенов за всю сессию:

$1,425 ÷ $50 × 1 000 000 = 28 500 токенов.

Делим на 20 обращений и получаем 1425. Если Astra расходует по 5000 выходных токенов, а Fable — по 6425, оба счета равны $8,55.

Из этого не следует, что Fable многословнее. Мы вообще не сравнивали ответы. Найден порог чувствительности: насколько может вырасти оплачиваемый выход, прежде чем скидка на чтение перестанет помогать.

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

Калькулятор, который можно проверить и изменить

Ниже полный расчет этого сценария на Python. Он не обращается к API и не требует ключей. В нем явно задаются объем основы, число обращений, количество записей, новый вход и выход. Проверки assert охватывают оба размера контекста и границу равной стоимости.

from decimal import Decimal as DM = D(1_000_000)def cost(read_price, *, prefix=100_000, n=20, writes=1,         fresh=2_000, output=5_000, input_price="10",         write_price="12.5", output_price="50"):    if not 1 <= writes <= n:        raise ValueError("writes must be between 1 and n")    reads = n - writes    return (        D(prefix * writes) * D(write_price)        + D(prefix * reads) * D(read_price)        + D(fresh * n) * D(input_price)        + D(output * n) * D(output_price)    ) / Mastra = cost("1")fable = cost("0.25")fable_two_writes = cost("0.25", writes=2)fable_three_writes = cost("0.25", writes=3)fable_break_even = cost("0.25", output=6_425)astra_long = cost("2", prefix=500_000,                  input_price="20", write_price="25",                  output_price="75")fable_long = cost("0.25", prefix=500_000)assert astra == D("8.55")assert fable == D("7.125")assert fable_two_writes == D("8.35")assert fable_three_writes == D("9.575")assert fable_break_even == astraassert astra_long == D("39.80")assert fable_long == D("14.025")for name, value in [    ("Astra", astra), ("Fable", fable),    ("Fable, 2 writes", fable_two_writes),    ("Fable, 3 writes", fable_three_writes),    ("Fable, break-even", fable_break_even),    ("Astra, long context", astra_long),    ("Fable, long context", fable_long),]:    print(name, value)

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

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

Что произойдет с базой на 500 тысяч токенов

Увеличим общую основу в пять раз. С новым вопросом на входе будет 502 тысячи токенов.

Для Astra это выше порога 272 тысячи: ко всему запросу применяются удвоенные ставки входа и кэша, а к выходу — коэффициент 1,5. У Fable 5.1 действует стандартная тарификация в пределах миллионного окна. Эти условия указаны в тех же официальных источниках тарифов.

При одной записи и 19 чтениях получаем:

• Astra: $12,50 за запись + $19 за чтения + $0,80 за новые вопросы + $7,50 за выход = $39,80.

• Fable: $6,25 за запись + $2,375 за чтения + $0,40 за новые вопросы + $5 за выход = $14,025, или $14,03 после округления.

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

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

Как перейти от сметы к выбору модели

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

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

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

Например, десять заданий суммарно обошлись в $20, но проверку прошли только пять. Цена принятого результата — $4, даже если отдельный удачный вызов был дешевле. Это условная иллюстрация метрики, а не результат сравнения Astra и Fable.

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

Если сервис и бюджет уже выбраны, можно обратиться к менеджеру RaketaPay ^[7]: укажите название API и сумму пополнения, чтобы уточнить доступный вариант оплаты.

Что можно решить уже сейчас

При выбранных условиях Fable 5.1 дешевле: $7,125 против $8,55. Но этот вывод держится на одинаковом оплачиваемом выходе и одном заполнении кэша. Два дополнительных заполнения у Fable или 1425 дополнительных выходных токенов на обращение меняют картину.

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

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