Переезд на новую версию модели обычно выглядит как правка одной строки: старый идентификатор заменили на новый, прогнали тесты, выкатили. С Claude Fable 5.2 такой сценарий работает ровно до первого длинного диалога, в котором агент успел подумать, вызвать инструмент и вернуться к рассуждению. Там пайплайн внезапно получает ответ с кодом 400, а повторный запрос с тем же телом ничего не меняет. Причина не в сети и не в нагрузке. Блоки рассуждения теперь жёстко привязаны к тексту, который стоял перед ними, и малейшая правка этого текста делает блок недействительным.
Девятого ноября 2026 года Anthropic выпустила Claude Fable 5.2 и Claude Mythos 5.2. Цены снизились, контекст остался миллионным, у Fable появился режим ускоренной генерации. Но для агентных систем, особенно для RAG-цепочек, которые на каждом шаге подмешивают в контекст свежие документы, главные новости спрятаны в правилах обращения с thinking-блоками.
Что вышло девятого ноября и чем Fable 5.2 отличается от Mythos 5.2 для рабочего пайплайна
Две модели построены на одних и тех же весах. Claude Fable 5.2 (идентификатор claude-fable-5-2) доступна всем и на Claude API не требует отдельного одобрения. Claude Mythos 5.2 (claude-mythos-5-2) отдана только организациям, прошедшим проверку по программам верификации Anthropic, например по программе для кибербезопасности. Разница между ними в защитных механизмах: у Fable они включены для задач из области кибербезопасности и биологии, у Mythos убраны. Дальше речь в основном о Fable.
Характеристики у пары общие: окно контекста в 1M токенов, до 128k токенов на выходе, адаптивное мышление включено всегда. Если в запросе нет поля thinking, модель всё равно думает. Усилие по умолчанию на API стоит на уровне high, всего уровней пять: low, medium, high, xhigh и max. Граница знаний модели - июнь 2026 года.
Цена снижена: $8 за миллион входных токенов и $40 за миллион выходных против $10 и $50 у Fable 5.1, то есть на 20 процентов. Ложных срабатываний защиты стало примерно на 55 процентов меньше, чем у предшественницы, а для RAG-агентов, которые читают сырые документы из внешних источников, это означает меньше необъяснимых отказов посреди цепочки. Версия 5.1 вышла 1 сентября.
Сама замена модели занимает секунды:
model = "claude-fable-5-1" # было
model = "claude-fable-5-2" # стало
Вот на этом лёгкая часть миграции заканчивается.
Как жёсткая проверка префикса для thinking-блоков решает судьбу каждого запроса и что именно её ломает
У каждого thinking-блока в ответе есть невидимая биография: API запоминает, какой system-промпт, какой набор tools и какие сообщения предшествовали рождению блока. Когда блок возвращается в следующем запросе, сервер сверяет прошлое с настоящим. Совпало байт в байт - блок принят. Отличается хоть что-то - запрос отклоняется с ошибкой 400 типа invalid_request_error, где названо первое несовпавшее место. Пломба на упаковке работает так же: пока вокруг всё нетронуто, она цела, а стоит вскрыть коробку, и пломба уже ничего не гарантирует.
Сама проверка не нова. На Fable 5.1 она действовала лишь на части аккаунтов, а в руководстве по миграции прямо предупреждали, что для будущих моделей её включат везде. С выходом 5.2 так и случилось: жёсткий префикс-чек работает на всех аккаунтах, и команды, которые надеялись, что их это не заденет, получают 400 в первый же день.
Что считается безопасным изменением между двумя запросами? Добавить сообщения в конец истории. Добавить инструмент с флагом defer_loading: true, на который ещё никто не ссылался. Убрать thinking-блоки из начала истории, все до некоторой точки. Поменять любой параметр за пределами system, tools и messages: max_tokens, output_config, tool_choice, metadata и прочее. Всё это блоки не инвалидирует.
Что ломает? Правка, перестановка или удаление любого раннего сообщения, будь то реплика пользователя, ассистента или системная вставка. Текстовый блок, добавленный в раннюю реплику пользователя, или блок, убранный из неё. Любое изменение верхнеуровневого system, строкой он задан или массивом блоков. Сюда же относится изменение набора tools.
У такой ошибки есть неприятная особенность: она постоянна для конкретного тела запроса. Повторная отправка, пауза и экспоненциальная задержка в цикле повторов ничего не исправят, а только потратят время и лимиты.
Зато у жёсткого условия есть приятный побочный эффект. Требование неизменного префикса совпадает с условием попадания в кэш промптов: то, что держит блоки действительными, держит тёплым и кэш. Дисциплина "только в конец" окупается дважды, потому что пропадают ошибки 400 и стабилизируется счёт за входные токены. Любая правка раннего сообщения заставляет заново платить за весь префикс. При 40 000 токенов префикса это $0,32 за шаг по полному тарифу вместо цены чтения из кэша.
Где RAG-агенты ломают историю диалога чаще всего и как подмешивать найденные документы без правок задним числом
В RAG-цепочке история растёт по знакомой схеме: вопрос пользователя, поиск по базе, ответ модели, вызов инструмента, второй поиск, уточнение. Каждый шаг тянет за собой соблазн "почистить" контекст. Чаще всего префикс рушится из-за пяти привычек, которые в таких системах считаются обычной гигиеной:
- найденные фрагменты документов записываются в system-промпт, который пересобирается заново на каждом шаге;
- в ранее отправленное сообщение пользователя дописывается контекст от ретривера или, наоборот, убирается устаревший;
- старые реплики заменяются кратким пересказом, чтобы уложиться в бюджет токенов;
- список tools собирается динамически, и его состав или порядок меняются от шага к шагу;
- в начало system-промпта попадают служебные метки вроде текущего времени, идентификатора запроса или имени пользователя.
Общее лекарство одно: история пишется только в конец. Найденные документы приходят отдельным сообщением или результатом вызова инструмента, добавленным после всего прежнего. Время и идентификаторы живут в последнем сообщении, а не в начале. Набор tools фиксируется на старте сессии, а редкие инструменты подключаются через defer_loading, и пока на них никто не ссылался, префикс остаётся в силе. Напоминания и поправки для модели тоже идут новым сообщением в конец, а не правкой system-промпта: ранние реплики остаются байт в байт прежними и продолжают попадать в кэш.
Отдельный разговор про сжатие истории. Окно в 1M токенов сдвигает баланс: многие агентные сессии теперь целиком умещаются без пересказов, и сжатие превращается из рутины в редкое осознанное событие. Когда оно всё же нужно, правильный порядок такой: пересобрать историю, вычистить из неё все thinking-блоки, смириться с одним холодным запросом и дальше снова только дописывать. Новые блоки привяжутся уже к новому префиксу.
Режим drop_block на переходный период и привязка thinking-блоков к модели и аккаунту
На переходный период у API есть встроенная страховка. С бета-заголовком thinking-binding-controls-2026-08-01 и полем prefix_mismatch_behavior со значением drop_block сервер не отклоняет запрос, а выбрасывает несовпавший блок вместе со всеми thinking-блоками после него и продолжает работу. Что именно выброшено, сообщает массив input_transformations в ответе, с причиной prefix_binding_mismatch.
import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create(
model="claude-fable-5-2",
max_tokens=16000,
betas=["thinking-binding-controls-2026-08-01"],
thinking={
"type": "adaptive",
"block_binding": {"prefix_mismatch_behavior": "drop_block"},
},
system=SYSTEM_PROMPT,
tools=TOOLS,
messages=history,
)
for item in getattr(response, "input_transformations", None) or []:
log.warning("thinking block dropped: %s", item)
У этого режима есть цена, о которой легко забыть. Молча выброшенное рассуждение - это тихая деградация агента без единой ошибки в логах. Поэтому каждый элемент input_transformations стоит превращать в метрику с оповещением. Для тестового контура полезнее противоположное значение error: оно останавливает сборку сразу, пока проблема ещё живёт в ветке, а не у клиента.
Отдельная тема - смена модели по ходу диалога. В мультимодельных пайплайнах действует асимметрия, и она важнее, чем кажется. Fable 5.2 и Mythos 5.2 читают thinking-блоки друг друга и блоки более ранних моделей: Opus 5.5, Sonnet 5.5, Haiku 5.5, Fable 5.1, Mythos 5.1 и старше. Обратного чтения нет: ни одна другая модель не прочитает блоки Fable 5.2. Диалог, начатый на Haiku 5.5 и переданный Fable 5.2 для сложного шага, сохраняет всё рассуждение. Диалог, переданный от Fable 5.2 обратно на Opus 5.5, Fable 5.1 или запасную модель, теряет блоки: API их отбрасывает, запрос при этом проходит успешно, а отброшенные блоки не тарифицируются. Глубокое рассуждение лучше собирать ближе к концу цепочки, а не в середине, потому что возврат от лёгкой модели к Fable 5.2 не вернёт отброшенные блоки.
Вторая привязка касается аккаунтов. Блоки, созданные Fable 5.2 и Mythos 5.2, работают только в том аккаунте, где появились, или в связанном с ним. Если история диалога лежит в общей базе, а запросы уходят с ключей разных организаций, блок, пришедший с чужого ключа, не сработает. Решение простое: привязать диалог к одному аккаунту на всё время жизни и записывать идентификатор аккаунта рядом с историей.
Экономика fast mode в токенах и секундах на примере агентного цикла
Fast mode включается одним полем speed со значением fast в запросе Messages API, заголовок бета-версии не нужен. Ускорение генерации заявлено до 2,5 раза по числу выходных токенов в секунду. Цена ровно вдвое выше стандартной: $16 за миллион входных токенов и $80 за миллион выходных. Фактический режим обработки виден в поле usage.speed, там стоит fast или standard.
response = client.messages.create(
model="claude-fable-5-2",
max_tokens=4000,
speed="fast",
system=SYSTEM_PROMPT,
tools=TOOLS,
messages=history,
)
print(response.usage.speed)
Ограничения стоит знать заранее. Ускоряется только генерация, а время до первого токена остаётся прежним. С Batch API и Priority Tier режим не работает. Поэтому для коротких ответов выгода мала, а для фоновых заданий её нет совсем: там время никто не ждёт.
Чтобы решать по цифрам, а не по настроению, хватит одной формулы. Ускорение в 2,5 раза сокращает время генерации на 60 процентов, потому что 1 - 1/2,5 = 0,6. Значит, сэкономленные секунды равны 0,6, умноженным на число выходных токенов и делённым на скорость генерации. Цена за это равна полной стоимости шага по стандартному тарифу, поскольку оба тарифа выше ровно вдвое.
Для расчёта взято условное значение 50 токенов в секунду в стандартном режиме, реальную скорость нужно замерить на своём трафике. Шаг агента: 40 000 входных и 2 000 выходных токенов. В стандартном режиме он стоит $0,32 за вход плюс $0,08 за выход, итого $0,40. В fast те же токены обходятся в $0,80. Генерация занимает 40 секунд против 16, экономия 24 секунды за лишние $0,40. Выходит около $1 за каждую сэкономленную минуту. Для интерактивного чата, где человек смотрит на мигающий курсор, это недорого. Для ночной выгрузки, где минуты никому не нужны, это пустая трата.
Теперь о месячном счёте. Допустим, 100 000 шагов в месяц с теми же 40 000 токенов на входе и 2 000 на выходе. На Fable 5.1 шаг стоит $0,50, и месяц обходится в $50 000. На 5.2 в стандартном режиме шаг стоит $0,40, а месяц $40 000. Если всё перевести в fast, счёт вырастет до $80 000. Но если ускорять лишь десятую часть шагов, ту, что лежит на критическом пути ответа пользователю, получится 10 000 шагов по $0,80 плюс 90 000 шагов по $0,40 дают $44 000. Это всё равно на $6 000 дешевле старого счёта. Скидка в 20 процентов как раз и оплачивает выборочное ускорение.
Прежде чем платить вдвое за скорость, стоит проверить более дешёвый рычаг, уровень усилия. Мышление включено всегда, а токены рассуждений тарифицируются как выходные. Для рутинных шагов вроде выбора источника или проверки формата уровень low вместо high сокращает рассуждения без смены модели. Изменение output_config к тому же числится среди безопасных правок: thinking-блоки после него остаются действительными.
Порядок раската миграции на 5.2, который не оставляет сюрпризов для пользователей и бюджета
Порядок раската простой. Сначала в тестовом контуре включается режим error для несовпадений префикса, и любой код, правящий историю задним числом, всплывает на первых прогонах. Затем заводится метрика доли кэшированных токенов, то есть отношения cache_read_input_tokens ко всему входу: на стабильном префиксе она растёт от шага к шагу, а провал на графике указывает на чью-то правку начала диалога.
Скидка в 20 процентов, миллионный контекст и ускоренный режим делают 5.2 выгодным выбором, а жёсткая проверка префикса превращает аккуратность в работе с историей из пожелания в условие работы. Новая модель дешевле, но взамен просит порядка: история диалога теперь пишется только в конец, а всё, что нужно сказать модели позже, говорится новым сообщением.