Claude Fable 5.1 и Mythos 5.1: две роли в одном релизе

Anthropic выпустила Claude Fable 5.1 и Mythos 5.1, разделив их по характеру работы. Fable предназначена для продолжительных задач с кодом и инструментами, Mythos — для сопоставления документов и аналитических выводов. Главное в новости не обещание универсального скачка качества, а попытка предложить разные рабочие режимы вместо одной модели «на всё». Ниже отделяем заявленное назначение от того, что редакции удалось бы проверить в реальном процессе.

Хронология и содержание релиза

Релиз заявлен 1 сентября 2026 года, а карточки доступа начали появляться поэтапно. В заметке Anthropic Fable описывается как модель, которая дольше удерживает план, возвращается к уже просмотренным файлам и аккуратнее разделяет найденное и предположенное. Mythos позиционируется для исследовательских задач: он должен последовательно читать большой набор материалов и фиксировать связь между промежуточными аргументами.

Из этого не следует, что Fable автоматически исправляет любой репозиторий или что Mythos безошибочно пересказывает длинный архив. Релиз сообщает о направлении оптимизации, а не о гарантии результата. Доступность режимов, лимиты и параметры могут различаться между интерфейсом, API и командным тарифом; дату и канал нужно фиксировать в собственной проверке.

Кому может пригодиться Fable

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

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

Где уместнее Mythos

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

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

Что изменится для команды

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

Не переносите шаблоны запросов между режимами без теста. Требование «покажи источники» полезно для документов, но не заменяет проверку тестов в репозитории. И наоборот, подробный план действий для кода не гарантирует корректной интерпретации внутреннего регламента.

Ограничения, которые важно учесть

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

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

Редакционный тест перед внедрением

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

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

Вывод

Fable 5.1 и Mythos 5.1 интересны разделением рабочих ролей. Первая логично выглядит в ограниченном контуре разработки, вторая — в проверяемом чтении нескольких источников. Релиз не отменяет базовых мер: тестовых наборов, журнала, контроля доступа и человеческого решения. Начинайте с маленького пилота, сравнивайте с привычным процессом и расширяйте использование только там, где результат повторяем и его можно проверить.

Что зафиксировать в день теста

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