Сохранённое мышление

На Claude Fable 5.1 изменение предыдущих ходов в разговоре (подсказки system, tools или любого более раннего сообщения) влияет на ответ API. По умолчанию это приводит к тому, что API отклоняет запрос с ошибкой, если только вы не выберете вместо этого отбрасывание затронутых блоков мышления из того, что видит модель (prefix_mismatch_behavior: "drop_block"). Проверка применяется по умолчанию для новых учётных записей, созданных 31 августа 2026 года в 00:00 UTC или позже. Более подробная информация приведена в разделах Как это работает и Кого это затрагивает.

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

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

Нужно ли вам что-либо делать, зависит от того, что управляет историей вашего разговора:

• Вы используете официальный продукт или SDK Claude: Claude Code, claude.ai, Claude Managed Agents или Claude Agent SDK. Они сохраняют префикс нетронутым за вас.
• Вы вызываете Messages API напрямую, из вашего собственного цикла агента или любой другой настройки. Вам следует проверить свой код и убедиться, что массив messages обрабатывается как доступный только для добавления. Эти распространённые шаблоны редактируют префикс и делают недействительным мышление после редактирования:
  • Обрезка или отбрасывание более старых ходов
  • Суммирование более старых ходов на клиенте и сохранение недавних
  • Внедрение напоминания в более ранний ход и его удаление при следующем запросе
  • Перестроение подсказки system при каждом запросе (текущее время, бюджет токенов, флаги режима)
  • Добавление или удаление записей в tools в середине сессии

Как это работает

Для новых запросов API проверяет:

• Модель та же или новее. Блок читается моделью, которая его создала, и более поздними моделями, но не более ранними. Разговор, который переходит на более новую модель, сохраняет свои рассуждения. Разговор, который переходит на более старую модель, не проходит проверку модели для этих блоков, и API отбрасывает их для этого запроса. См. Сохранённое мышление для точного списка по каждой модели.
• Ничего перед блоком не изменилось. Подсказка system верхнего уровня, набор инструментов в tools и каждое сообщение перед блоком. При серверной компактификации проверяемый префикс начинается с самого последнего блока компактификации.
• Цепочка более ранних блоков мышления не прервана. Более ранние блоки thinking и redacted_thinking не являются частью префикса, но каждый блок мышления записывает предыдущий, через ходы. Вы можете удалить блоки мышления из начала истории. Удаление одного из середины делает недействительным каждый блок мышления после него.

Блок, который не проходит проверку модели, всегда отбрасывается. Для несоответствия префикса вы выбираете, что происходит, с помощью thinking.block_binding.prefix_mismatch_behavior, который требует бета-заголовка thinking-binding-controls-2026-08-01:

• "drop_block": API удаляет блок и каждый блок мышления после него в разговоре, и запрос выполняется успешно. Отброшенные блоки не тарифицируются. Ответ перечисляет их в массиве input_transformations верхнего уровня (в событии message_start при потоковой передаче).
• "error": API отклоняет запрос с ошибкой 400 invalid_request_error, которая называет первый неудачный блок.

По умолчанию используется "error". Заголовок позволяет вам установить поле и добавляет input_transformations в ответы.

Кого это затрагивает

Claude Fable 5.1. См. Сохранённое мышление для списка моделей.

На Claude Fable 5.1 API применяет проверку для новых учётных записей. Новая учётная запись — это та, которая создана 31 августа 2026 года в 00:00 UTC или позже. То же определение применяется на Claude API и на облачных платформах. Более поздние модели будут применять проверку для всех пользователей.

Запрос, который устанавливает prefix_mismatch_behavior, включает применение независимо от возраста учётной записи, что является способом тестирования из более старой учётной записи. Чтобы проверить, применяется ли к вашей учётной записи проверка по умолчанию, отправьте запрос, который редактирует историю, без бета-заголовка: ошибка 400, которая называет заголовок, означает, что проверка применяется.

Как определить, затронута ли ваша интеграция

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

Затем подтвердите это с помощью API. С бета-заголовком thinking-binding-controls-2026-08-01 и claude-fable-5-1 установите thinking.block_binding.prefix_mismatch_behavior в "drop_block" и запустите обычную многоходовую сессию через вашу интеграцию. Этот запрос является вторым ходом такой сессии, отправляя обратно ход ассистента из первого ответа точно так, как он был получен:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: thinking-binding-controls-2026-08-01" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 16000,
    "thinking": {
      "type": "adaptive",
      "block_binding": { "prefix_mismatch_behavior": "drop_block" }
    },
    "system": "You are a coding agent.",
    "messages": [
      { "role": "user", "content": "Fix the failing test." },
      {
        "role": "assistant",
        "content": [
          { "type": "thinking", "thinking": "", "signature": "EqQBCkYIBxgCKkD..." },
          { "type": "text", "text": "I need to see the test first. Which file is it in?" }
        ]
      },
      { "role": "user", "content": "tests/test_auth.py" }
    ]
  }'

Каждый ответ затем несёт массив input_transformations верхнего уровня. Логируйте его на каждом ходу:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

• Пустой на каждом ходу: ваша интеграция сохраняет историю нетронутой.
• reason: "prefix_binding_mismatch": что-то перед блоком по path изменилось между этим запросом и предыдущим. Сравните system, tools и messages вплоть до этого хода, чтобы найти это.
• reason: "model_binding_mismatch": разговор перешёл на модель, которая не может прочитать блоки более ранней модели (маршрутизатор, резервный вариант). Это не ошибка в вашей интеграции. Продолжайте отправлять блоки и позвольте API отбросить то, что текущая модель не может прочитать.

Это работает из любой учётной записи, потому что установка поля включает запрос в применение. Чтобы вместо этого громко падать в CI, установите "error". Ошибка 400 начинается с:

messages.1.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block".

Без бета-заголовка в запросе сообщение продолжается: That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header. Сообщение обычно заканчивается предложением, называющим то, что изменилось, например, что подсказка system или список tools отличается от того, что было при создании блока.

См. Устранение неполадок мышления для каждого варианта этой ошибки.

Что считается редактированием

Между двумя последовательными запросами:

Обновите вашу интеграцию

Каждый шаблон заменяет один вид редактирования истории функцией API, которая имеет тот же эффект на модель без изменения более ранних байтов.

Добавляйте ходы ассистента точно так, как они были возвращены

Сохраняйте массив content из каждого ответа и отправляйте его обратно без изменений как ход ассистента, каждый тип блока в порядке получения, включая блоки thinking, чьё поле thinking пусто. Не пересериализуйте через промежуточный тип, который отбрасывает неизвестные типы блоков или пустые поля.

Добавляйте инструкции с помощью системного сообщения в середине разговора, а не путём редактирования system

Если ваш код перестраивает подсказку system верхнего уровня при каждом запросе (текущее время, бюджет токенов, флаг режима, вновь обнаруженный контекст проекта), каждый блок мышления в разговоре не проходит проверку. Заморозьте system в начале сессии, и когда что-то меняется, добавьте сообщение role: "system" в той точке messages, где это становится истинным:

{
  "role": "system",
  "content": "The user switched the workspace to read-only mode. Do not write files until told otherwise."
}

Модель обрабатывает его с полномочиями системной подсказки, и всё перед ним не изменено. Бета-заголовок не нужен на Claude Fable 5.1. В цикле инструментов размещайте его после сообщения пользователя tool_result, никогда между tool_use ассистента и его tool_result (см. Ограничения).

Отправляйте напоминания на каждый ход как системные сообщения с областью действия на ход

Наиболее распространённое редактирование истории — это подталкивание на каждый ход: строка, добавляемая после каждой партии результатов инструментов («запрашивайте независимые чтения вместе», «вы давно не обновляли пользователя») и удаляемая при следующем запросе, чтобы напоминания не накапливались. Её удаление и есть редактирование.

Вместо этого отправляйте подталкивание как системное сообщение в середине разговора с clear_at: "next_user_message" после сообщения пользователя tool_result (бета-заголовок mid-conversation-system-clear-at-2026-08-21). Этот массив messages — запрос после двух раундов инструментов. messages[3] — подталкивание из предыдущего запроса, оставленное на месте, а messages[6] — копия этого запроса:

[
  { "role": "user", "content": "Fix the failing test." },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_01",
        "name": "read_file",
        "input": { "path": "tests/test_auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_01", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_02",
        "name": "read_file",
        "input": { "path": "src/auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_02", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  }
]

Сообщение пользователя, содержащее только tool_result, считается «следующим сообщением пользователя», поэтому messages[3] уже очищено: оно ничего не отображает и не стоит входных токенов, но оно всё ещё в массиве, поэтому мышление в messages[4] остаётся действительным. messages[6] — это то, что модель видит на этом ходу. В более поздних запросах оставляйте оба на своих местах и добавляйте следующую копию после следующего сообщения tool_result. Сообщения с областью действия на ход несут только text и не принимают cache_control. Поместите точку прерывания кэша на предшествующий ход пользователя. См. Системные сообщения с областью действия на ход.

Без беты добавляйте подталкивание как блок text после блоков tool_result в том же сообщении пользователя и оставляйте более ранние копии на месте. Модель действует по самой новой.

Изменяйте инструменты с помощью tool_addition и tool_removal, а не путём редактирования tools

Если набор инструментов меняется в середине сессии (инструмент разблокируется после аутентификации, опасный инструмент отзывается после переключения режима), не редактируйте tools. Объявите полный набор в начале сессии и используйте изменения инструментов в середине разговора, чтобы предложить или отозвать инструмент с этого момента (бета-заголовок mid-conversation-tool-changes-2026-07-01). Инструмент, который ещё недоступен, получает defer_loading: true и более поздний блок tool_addition, той же формы, что и этот tool_removal:

{
  "role": "system",
  "content": [
    { "type": "tool_removal", "tool": { "type": "tool_reference", "name": "delete_branch" } },
    { "type": "text", "text": "Branch deletion is disabled for the rest of this session." }
  ]
}

Инструмент, чью схему вы узнаёте в середине сессии (сервер MCP, обнаруженный во время выполнения), может быть добавлен в tools с defer_loading: true и предложен с помощью tool_addition. Неиспользуемый отложенный инструмент не является частью префикса, поэтому его добавление безопасно. Добавление обычного инструмента — нет.

Обрезайте контекст на сервере, где можете

Клиентская обрезка и суммирование — второе по распространённости редактирование: отбросить или суммировать самые старые ходы и сохранить недавние дословно. Блоки мышления недавних ходов были созданы, пока удалённая вами история ещё была на месте, поэтому они не проходят проверку. Серверные эквиваленты не считаются редактированием, потому что проверка сравнивает разговор так, как вы его отправили:

• Компактификация суммирует более старые ходы в блок компактификации, когда контекст приближается к установленному вами порогу, и проверяемый префикс перезапускается с этого блока. Её параметр instructions принимает вашу собственную подсказку суммирования («сохраняйте каждый тикер, размер позиции и заявленное предположение»).
• Редактирование контекста очищает старые результаты инструментов (clear_tool_uses_20250919) или старые блоки мышления, начиная с самых старых (clear_thinking_20251015), по правилу.

Пользовательская компактификация на клиенте

Эта проверка не запрещает клиентскую компактификацию. Правило уже: не сохраняйте блок мышления за префиксом, который вы переписали.

Простая компактификация — рекомендуемая форма и не требует изменений. Когда разговор становится слишком длинным, суммируйте его в одно сообщение и начните следующий запрос с этого резюме плюс новый ход пользователя, не воспроизводя более ранние ходы или блоки мышления: messages становится [{"role": "user", "content": "<summary of the session so far>\n\n<the next instruction>"}]. Более раннего мышления не остаётся, поэтому ничего не падает, и модель мыслит заново на компактифицированном разговоре. Модели Claude обучены на долгосрочных задачах с этой схемой, и она работает сопоставимо с более сложными для большинства рабочих нагрузок. Она сбрасывает кэш подсказок в точке компактификации, как и любая компактификация.

Две другие распространённые формы падают как написано и требуют по одному изменению каждая:

• Компактификация с сохранением хвоста суммирует более старые ходы и сохраняет самые недавние ходы дословно. Блоки мышления сохранённых ходов были созданы против полной истории, поэтому они падают за резюме. Исправление: удалите thinking и redacted_thinking из каждого хода ассистента, который вы переносите, сохраняя text и tool_use, или отправьте prefix_mismatch_behavior: "drop_block" и позвольте API удалить их.
• Фоновая компактификация строит резюме вне критического пути и подменяет его, пока разговор продолжается, поэтому каждый ход, созданный тем временем, имеет мышление, которое предшествует подмене. Исправление: отправляйте "drop_block" в каждом запросе, который всё ещё несёт блоки мышления, созданные до подмены (или удаляйте эти блоки сами; input_transformations в первом ответе после подмены перечисляет точно, какие именно), или компактифицируйте синхронно.

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

Не компактифицируйте в середине раунда инструмента: ход ассистента, чей tool_use всё ещё ожидает tool_result, должен вернуться с нетронутым мышлением, чтобы модель завершила раунд со своими рассуждениями (см. Сохранение блоков мышления).

Ссылайтесь на файлы по ID, а не по URL, который меняет содержимое

Для блока image или document с источником url извлечённые байты являются частью проверяемого префикса, а строка URL — нет. Конечная точка «последнего скриншота» или отредактированный документ делают недействительным более позднее мышление. Ротирующийся подписанный URL для того же файла — нет. Для содержимого, на которое вы ссылаетесь через ходы, загрузите его один раз с помощью Files API и используйте file_id, или отправьте base64.

Решите, что происходит при несоответствии

Как только ваша интеграция станет доступной только для добавления, выберите prefix_mismatch_behavior для продакшена. Он управляет только несоответствиями префикса. Блок, который текущая модель не может прочитать (после переключения маршрутизатора или серверного резервного варианта), всегда отбрасывается и сообщается в input_transformations, когда отправлен бета-заголовок.

• "error" (по умолчанию), если несоответствие префикса может означать только ошибку в вашем коде. Вы узнаёте об этом из ошибки 400 при тестировании, а не из молча отброшенных блоков. В Message Batches API неустановленное значение по умолчанию отбрасывает неудачные блоки вместо того, чтобы провалить элемент пакета; установите "error" явно, если хотите, чтобы элементы выдавали ошибку.
• "drop_block", если вы предпочитаете отбросить затронутые блоки, а не провалиться. Логируйте input_transformations.

Если вы ловите ошибку 400 в продакшене, повторная отправка того же запроса её не устранит. Повторите с prefix_mismatch_behavior: "drop_block" (и бета-заголовком), который удаляет именно те блоки, которые падают, включая любые в ходе ассистента, чей tool_use всё ещё ожидает свой tool_result. Отбрасывание применяется только к этому запросу, поэтому продолжайте отправлять "drop_block" (и бета-заголовок) до конца сессии. Без беты удалите каждый блок thinking и redacted_thinking из истории, оставляя блоки text и tool_use каждого хода на месте, и повторите один раз. Затем исправьте редактирование, которое это вызвало.

Функции API, используемые на этой странице

Чтобы объединить заголовки в одном запросе:

anthropic-beta: thinking-binding-controls-2026-08-01,mid-conversation-system-clear-at-2026-08-21,mid-conversation-tool-changes-2026-07-01

Те же бета-имена применяются на Amazon Bedrock и Google Cloud. См. Бета-заголовки о том, как отправлять их с каждым SDK.

Контрольный список

• Если официальный продукт или SDK Claude (Claude Code, claude.ai, Claude Managed Agents, Claude Agent SDK) управляет историей вашего разговора, остановитесь здесь.
• Последовательные тела запросов побайтово идентичны в system, tools и общем префиксе messages.
• Полная сессия под prefix_mismatch_behavior: "drop_block" не логирует записей prefix_binding_mismatch.
• Ходы ассистента возвращаются побайтово так, как были возвращены, со всеми включёнными типами блоков.
• system и tools верхнего уровня зафиксированы для сессии. Изменения идут в сообщениях role: "system" и блоках tool_addition / tool_removal.
• Напоминания на каждый ход — это системные сообщения с областью действия на ход (или завершающие текстовые блоки), которые добавляются заново и никогда не удаляются.
• Контекст обрезается компактификацией или редактированием контекста, или клиентской компактификацией, которая не оставляет блоков мышления за переписанным префиксом и никогда не разбивает раунд инструмента.
• Файлы между ходами — это file_id или base64, а не изменяемые URL.
• Установлен продакшен-prefix_mismatch_behavior, и его ошибки 400 или отброшенные записи отслеживаются.

Следующие шаги