Если Claude Code показывает API Error: 400 due to tool use concurrency issues, не начинайте с замены API key, покупки дополнительной квоты, смены провайдера или вывода о сбое Anthropic. Сначала считайте это признаком поврежденной истории инструментов: в текущей сессии Claude Code или в массиве messages вашего клиента больше не совпадают tool_use, tool_result или связанные thinking-блоки. Пользователь Claude Code должен сохранить видимый контекст и откатиться через /rewind или двойной Esc. Разработчик собственного клиента Anthropic должен проверить, что каждый предыдущий tool_use получил соответствующий tool_result в следующем user message, причем результаты стоят перед обычным текстом.
| Поверхность | Первый владелец проверки | Безопасное первое действие |
|---|---|---|
| Claude Code CLI | поврежденная история tool/thinking | сохранить контекст, выполнить /rewind или Esc два раза, затем проверить одним простым tool action |
| VS Code, Cursor или IDE-расширение | сохраненная расширением история или мост клиента | сравнить тот же простой tool action в CLI и IDE, не начинать с переустановки |
| Собственный Anthropic API client | неверная сериализация tool_result | сопоставить каждый tool_use_id, вернуть все результаты вместе и до текста |
| Другой текст 400 | schema, role, system или extra input validation | идти по точному сообщению валидации, а не по ветке concurrency |
| 429, 529, 500, connection, auth, billing | другой класс ошибки Claude | использовать ветку лимитов, перегрузки, сервера, сети или аккаунта |
Проверка после восстановления должна быть скучной. В Claude Code попросите прочитать один файл, вывести один каталог или выполнить короткую команду. В API-клиенте проверьте очищенную форму messages: роли, типы блоков, идентификаторы инструментов, количество результатов и порядок блоков. Если форма неверна, новая сессия или новый ключ проблему не исправят.
Что означает именно этот 400
Фраза tool use concurrency issues легко сбивает с толку. Она звучит так, будто пользователь просто запустил слишком много инструментов одновременно. В этом случае более полезная трактовка уже: API получил состояние диалога, которое не может продолжить. Claude Code связывает точную ошибку с mismatch в tool use или thinking block, а обычный HTTP 400 в Claude API относится к invalid_request_error, то есть к формату или содержанию запроса.
Разрыв появляется двумя путями. В Claude Code длинная сессия может пережить остановленный tool run, прерванный stream, редактирование истории или состояние IDE-расширения, где следующий запрос ссылается на инструментальный блок, который уже нельзя корректно закрыть. В собственном Messages API клиенте чат может выглядеть понятным человеку, но быть недопустимым для модели: один tool_result отсутствует, результаты разделены по нескольким user messages, текст поставлен перед результатами, либо tool_use_id не совпадает.
Поэтому нормальный чат иногда продолжает отвечать, а file read, edit, bash или search ломаются. Обычный текст не требует пары tool call / result. Инструментальный turn требует строгой структуры. Если лечить это как network issue, billing issue или generic bad request, вы будете проверять не тот слой.
Восстановите сессию Claude Code без потери работы
Сначала сохраните человеческий контекст. Запишите текущую задачу, изменяемые файлы, последнюю команду или tool action, точный текст ошибки, время с часовым поясом и поверхность, где ошибка появилась. Это не нужно превращать в полный transcript. Цель другая: сохранить то, что можно безопасно перенести, если сессию все-таки придется начать заново.
Затем проверьте, где именно ломается действие. Если ошибка появилась в CLI, зафиксируйте версию Claude Code и обновитесь, если версия очевидно старая. Если ошибка появилась в VS Code, Cursor или другой оболочке, запустите один простой tool action в CLI. Разница между CLI и IDE важна: она помогает понять, повреждено ли состояние расширения или вся текущая conversation history.
Используйте /rewind, чтобы вернуться до поврежденного tool turn. Claude Code также описывает двойной Esc как способ отката в диалоге. После отката не давайте большой смешанный prompt, где нужно читать, редактировать, запускать тесты и искать документацию одновременно. Дайте одну чистую команду: прочитать файл, вывести директорию или выполнить короткий безопасный shell command. Если она проходит, продолжайте работу маленькими связными шагами.
Новая сессия нужна только после провала этого восстановления. И даже тогда не переносите весь старый transcript. Перенесите краткое резюме задачи, список файлов, последний доверенный результат и очищенную ошибку. Копирование поврежденной истории инструментов часто переносит саму причину 400 в новую сессию.
IDE, Cursor и VS Code требуют отдельной проверки
В IDE-ветке ошибка часто выглядит особенно странно: обычные ответы появляются, а любая операция с файлами возвращает 400. Это не доказывает, что пользователь сам вызвал несколько tools параллельно. Иногда IDE-расширение хранит частичное состояние, мост между editor и CLI меняет порядок сообщений, remote environment отдает не ту версию клиента, или расширение воспроизводит старый поврежденный turn.
Практичный порядок такой. Сначала запишите поверхность: Claude Code CLI, VS Code, Cursor, remote SSH, WSL, terminal multiplexer или другой wrapper. Затем сравните один и тот же маленький tool action в CLI и IDE. После этого проверьте версии Claude Code и расширения. Перезапуск, update или reinstall имеют смысл, но только после того, как вы сохранили evidence и не уничтожили рабочую CLI-сессию.
Если IDE ломается, а CLI работает, продолжайте срочную работу в CLI и отдельно изолируйте extension path. Если и CLI, и IDE ломаются внутри той же сессии, сначала откатывайте сессию. Если новая чистая сессия с тем же маленьким действием снова падает, тогда уже собирайте bug packet для поддержки или maintainer issue.
Старые обсуждения иногда советуют downgrade конкретной версии расширения. Относитесь к этому как к историческому контексту. Устойчивое правило другое: сравнить поверхности, сохранить evidence, выполнить официальный путь восстановления и только потом менять extension installation.
Если вы пишете Anthropic клиент, смотрите на messages
В собственном agent framework, IDE integration или backend tool runner проблема обычно сидит не в поведении пользователя, а в форме messages. Предыдущий assistant turn может содержать несколько tool_use blocks. Ваш runner может выполнить их параллельно или последовательно. Но следующий user message должен вернуть полный набор соответствующих tool_result blocks.
Три правила нельзя нарушать. Во-первых, каждый tool_use.id должен получить один matching tool_result.tool_use_id. Во-вторых, результаты для одного assistant turn должны вернуться вместе в следующем user message. В-третьих, если в этом user message есть и результаты, и обычный текст, tool_result blocks должны идти раньше текста. Текст вроде “я получил результат” перед результатами может сделать человеческий transcript понятным, но API request недопустимым.
| Ошибка клиента | Почему это ломает запрос | Исправление |
|---|---|---|
отсутствует один tool_result | assistant запросил инструмент, но результат не закрыт | вернуть результат для каждого ID или удалить всю поврежденную tool-пару из replay history |
| результаты разделены по нескольким user messages | модель ждет единый result set после assistant tool turn | объединить все результаты этого turn в одну user message |
текст стоит перед tool_result | результатные блоки должны идти первыми | поставить все tool_result blocks перед любым текстом |
| history compaction удалил часть tool blocks | сжатая история нарушила парность | сжимать только целые пары tool_use/tool_result или начинать с human summary |
Логируйте форму, а не секреты. Для отладки достаточно видеть roles, block types, ids, result count and order. Не логируйте API keys, tokens, private file contents, customer data или proprietary payloads. Хороший validator рядом с tool runner может остановить неверный request до отправки.
Параллельное выполнение разрешено, но сериализация строгая
Параллельность и формат возврата — разные вопросы. Claude может попросить несколько инструментов в одном assistant turn. Ваш код может выполнить их одновременно, потому что это быстрее, или последовательно, потому что внешняя система хрупкая. Для API важно другое: когда результаты возвращаются в диалог, они должны образовать полный, упорядоченный, matching set.
Поэтому совет “просто не запускайте параллельно” недостаточен. Если serializer теряет один ID, вставляет summary before results, делит ответы по messages или меняет старую history, ошибка останется даже при последовательном исполнении. И наоборот, корректно собранные parallel results могут быть валидны, если они возвращены вместе и перед текстом.
disable_parallel_tool_use стоит использовать только при реальном ограничении клиента: side-effect tools, fragile external systems, отсутствие надежного aggregator, или необходимость гарантировать последовательную запись. Это не заменяет правильный tool_result порядок. Даже один tool call требует matching result в правильном месте.
Для production-клиента полезен короткий checklist: каждый assistant tool_use.id имеет matching result; нет лишнего tool_result; все results для одного turn находятся в следующем user message; tool_result blocks идут перед text; replayed history не удаляет thinking, tool или result blocks, на которые модель еще опирается.
Почему длинные сессии и прерывания возвращают ошибку
Длинная Claude Code сессия накапливает не только текст, но и машинное состояние. Если tool action был остановлен, stream оборвался, IDE сохранила половину turn, пользователь вручную отредактировал history или framework сжал messages, следующий запрос может стать структурно недопустимым. Это выглядит как внезапная 400, хотя причина была создана несколькими шагами раньше.
При повторении ошибки спрашивайте не “почему Claude снова параллелит инструменты”, а “что произошло с transcript перед ошибкой”. Была ли остановка? Было ли редактирование? Был ли compaction? Копировали ли старую историю в новую сессию? Менялся ли набор tools? Не вставлял ли клиент обычный текст перед result blocks?
| Ситуация | Вероятный риск | Более надежное восстановление |
|---|---|---|
| tool run был остановлен | в history остался частичный tool state | откатиться до tool turn и проверить одним действием |
| history вручную очищали или сжимали | удалены обязательные tool/thinking blocks | начать с human task summary, не с transcript |
| падает только IDE | сломан extension state или bridge | сравнить CLI, сохранить version и minimal failing action |
| приложение replay-ит stored messages | serializer меняет order или ids | валидировать exact message array перед API call |
Повторные prompts вроде “try again”, “avoid concurrency” или “use one tool at a time” могут иногда обойти симптом, но не чинят поврежденную history. Надежное решение — восстановить checkpoint или исправить serializer.
Другие 400 и другие ошибки Claude надо отводить отдельно
Точный текст ошибки решает ветку. Если response содержит другой 400, например unsupported role, extra inputs are not permitted, invalid system placement, malformed JSON или недопустимый параметр модели, это тоже request-format issue, но не тот же tool-history mismatch. В таком случае /rewind может помочь только если поврежденная history реально участвует; чаще нужно чинить request schema.
| Симптом | Подходящая ветка |
|---|---|
| 400 с extra inputs, unsupported role, invalid system или malformed JSON | schema validation и параметры запроса |
| 400 после tool calls, edited history или long session | tool/result или thinking-block mismatch |
| 429 или rate limit reached | лимиты аккаунта, workspace, модели или provider quota |
529 overloaded_error | capacity issue и bounded retry |
| 500 или 504 | server error, timeout, request evidence и status check |
API Error: Connection error | network, VPN, proxy, DNS, TLS или SDK timeout |
| auth, billing, credits | аккаунт, проект, организация, оплата или credential route |
Status page полезна, но не является proof для этого exact 400. Сохраненный снимок 4 июля 2026 показывал Claude API и Claude Code operational. Это не доказывает, что локальная IDE-сессия или ваш messages array корректны. Проверяйте status при массовом сбое, но возвращайтесь к error body и tool history.
Что сохранить перед issue или support ticket
Хороший пакет доказательств помогает другому инженеру воспроизвести проблему без доступа к вашим секретам. Укажите Claude Code version, IDE extension version, поверхность выполнения, точный текст ошибки, timestamp with timezone, тип операции, ordinary chat behavior, результат /rewind или двойного Esc, сравнение CLI versus IDE и sanitized message shape для API-клиента.
Не отправляйте API key, token, private file contents, customer data или полный confidential transcript. Для serializer bug важна структура: какие tool_use ids были в assistant turn, какие tool_result ids вернулись в следующем user message, были ли results split, missing или placed after text.
Та же дисциплина снижает повторение ошибки. Не редактируйте старые tool turns руками. Не вставляйте natural-language summary перед tool_result. Не делите results одного assistant turn на несколько messages. Не считайте green status доказательством правильной request shape. Если нужна новая сессия, переносите human summary и безопасные ссылки на файлы, а не сломанную историю.
FAQ
Что выбрать: /rewind, Esc два раза, /clear или новая сессия?
Сначала /rewind или двойной Esc, потому что они возвращают вас к состоянию до поврежденного tool turn и сохраняют больше полезного контекста. /clear и новая сессия нужны только после провала маленькой проверки в той же сессии.
Почему обычный чат работает, а file tools падают?
Потому что текстовый ответ не требует tool/result pairing. File read, edit, bash и search зависят от tool state. Если ids, order или block types не совпали, tool action может падать, а обычный ответ продолжать работать.
Это точно слишком много параллельных инструментов?
Нет. Ошибка может появиться после настоящего multi-tool turn, но также после interrupt, edited history, extension cache, missing result, split result или text before tool_result. Чинить нужно transcript structure.
Нужно ли менять API key?
Не первым шагом. Новый ключ не исправляет malformed message history. Меняйте credentials только если error body или account evidence указывает на auth branch.
Стоит ли отключить parallel tool use?
Только если ваш клиент не умеет безопасно собирать multiple results или tools имеют side effects. Даже после отключения parallel execution порядок tool_result остается обязательным.
Нужна ли Claude Status?
Да, но как sanity check. Если несколько маршрутов одновременно падают, проверьте live status. Если точный error остается 400 tool-history mismatch, восстановление все равно идет через rewind или message-shape repair.
Что писать в GitHub issue или ticket?
Версию, поверхность, точный error text, время, operation type, работает ли ordinary chat, помог ли /rewind, CLI versus IDE, и sanitized message shape. Секреты, приватные файлы и полный transcript не прикладывайте.
Когда прекратить спасать текущую сессию?
После /rewind и одного-двух простых tool checks, которые воспроизводят тот же exact error. Сохраните evidence, начните чистую сессию с human summary и не импортируйте поврежденную tool history.
