Skip to main content

​
Краткий ответ

Ошибка выглядит так:
Хотя указан код 429, это не лимит запросов. Блок рассуждений в истории диалога не прошёл проверку подписи провайдера. При каждой повторной попытке отправляется та же история, поэтому автоматические повторные попытки на стороне клиента всегда завершаются сбоем. Решение: начните новый диалог. Вам не нужно менять агента, модель или настройки ключа.

​
Типичные симптомы

При использовании Claude Code, Claude Agent SDK или режима Claude Agent в таких клиентах, как Cherry Studio, с включенным thinking:
  • В основном диалоге ответ так и не появляется. Клиент отображает сообщения вроде «too many requests» или «retrying in 9 seconds (5/10)» и прекращает попытки после 10 повторов.
  • В логах консоли действительно отображаются успешные тарифицированные запросы для этого ключа, но все они представляют собой небольшие запросы с малым количеством tokens. Это вспомогательные запросы, которые клиент отправляет с помощью своей модели Small (заголовки, проверка намерений и т. д.). Они не передают историю сообщений, поэтому выполняются успешно.
  • Нажатие «continue» или перефразирование в том же диалоге приводит к той же ошибке. Новый диалог работает сразу же.

​
Почему это происходит

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

Отсутствующая или пустая подпись

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

Измененное содержимое рассуждений

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

Смена модели в ходе диалога

Если модель A создала блок рассуждений, а вы продолжаете тот же диалог с моделью B, модель B может не принять подпись, оставленную моделью A.

Смена ключей или групп в ходе диалога

Если вы измените ключ или группу token посреди диалога, последующие запросы могут быть направлены по другому маршруту, и ранее созданные подписи могут не пройти там проверку.
messages.1.content.0 в ошибке указывает на первый блок содержимого первого ответа ассистента в истории, то есть на блок рассуждений из первого раунда диалога. Если он поврежден, каждый последующий шаг в этом диалоге завершится сбоем.

​
Как это исправить

1

Начните новый диалог

Создайте новый диалог в вашем клиенте, загрузите файлы заново и повторите запрос. Используйте того же агента, модель и ключ. Это самое быстрое и надежное решение.
2

Используйте одну модель и один ключ на диалог

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

Не редактируйте историю вручную

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

Обновите ваш клиент

Если после нескольких реплик в новом диалоге ошибка возникает снова, клиент, скорее всего, отбрасывает сигнатуры при сохранении истории. Обновите его до последней версии и передайте шаги для воспроизведения разработчикам клиента.
Если вы вызываете API из собственного кода: при повторной отправке истории либо сохраняйте каждый блок thinking в точности как есть (включая поле signature), либо удалите весь блок целиком. Никогда не оставляйте текст рассуждений, отбрасывая сигнатуру. При использовании официального SDK передавайте массив content из предыдущего ответа обратно в messages без изменений.

​
Часто задаваемые вопросы

Нет. Содержимое запроса некорректно; это никак не связано с частотой запросов. Снижение интенсивности запросов или повторная попытка позже не помогут. Если вы видите Invalid signature in thinking block, начните новый диалог.
Нет. Проверка подписи завершается сбоем до того, как модель успевает что-либо сгенерировать, поэтому эти запросы бесплатны и не отображаются в логах консоли. Записи о тарификации, которые вы видите, относятся к успешным запросам — обычно это небольшие вспомогательные запросы клиента.
Отключение thinking в рамках того же диалога может не помочь, поскольку блоки thinking, уже присутствующие в истории, всё равно отправляются. Надежнее начать новый диалог. Если для задачи не требуется thinking, вы также можете переключиться на модель без суффикса -thinking, начав новый диалог.
Обратитесь в службу поддержки, указав приблизительное время возникновения ошибки (с часовым поясом, например 17:00 (UTC+8)), клиент и его версию, а также название модели. Мы сможем найти запросы этого диалога по времени и помочь разобраться в ситуации.

​
Связанная документация

Руководство по Claude Effort и Thinking

Включение и отключение thinking, события потоковой передачи и передача сигнатур обратно

Нативный формат Claude: потоковые и непотоковые ответы

Структура блоков thinking и signature_delta

Claude Code

Настройка APIYI в Claude Code

Каковы лимиты параллельных запросов API?

Подробно о параллельных запросах и лимитах запросов