AIREITERAnthropic запустила Message Threads в публичной бете 2 ноября 2026 года. Главный нюанс легко упустить: для запросов на 500K–1M токенов медианное время до первого токена сокращается примерно на 35%, но счёт за токены остаётся прежним. Для длинных циклов агентов это ускорение передачи данных с жёстким ограничением: после 5 минут бездействия состояние исчезает.
Запросы быстрее, счёт тот же: что меняют threads
Message threads — это временное состояние диалога на стороне сервера для Messages API. Функция вышла в публичную бету 2 ноября 2026 года. Историю передают целиком один раз через thread: { "type": "create" }, а затем отправляют только новые сообщения вместе с previous_message_id и thread: { "type": "continue" }. Согласно анонсу Anthropic и документации платформы, состояние хранится в зашифрованной памяти, на диск не записывается, удаляется через 5 минут бездействия и в любом случае не позднее чем через 1 час после последнего использования.
Каждый запрос внутри thread должен содержать beta-заголовок anthropic-beta: message-threads-2026-08-12. Цены и лимиты запросов не изменились: Claude по-прежнему читает весь диалог на каждом ходе, поэтому вы платите за тот же объём входных и выходных токенов, хотя передаёте намного меньше байтов.
«Да, звучит неплохо, но стоимость токенов это не снижает :( Claude всё равно читает весь диалог на каждом ходу, и расход токенов не меняется» — @_navicstein, ответ в официальной ветке запуска
В официальном анонсе говорится примерно о 35% снижении медианного TTFT для запросов на 500K–1M токенов — без скидки на токены.
Threads и prompt caching: разница в двух словах
Threads уменьшают объём того, что вы отправляете, а prompt caching — объём того, за что вы платите по полной цене. Threads ничего не кэшируют автоматически: точки cache_control по-прежнему нужно задавать вручную. Подробности взаимодействия с кэшированием ниже соответствуют разбору реализации: на каждом продолжении оставляйте верхнеуровневый cache_control; чтение из кэша тарифицируется по ставке 0.1x от базовой цены входных данных (0.05x для Claude Opus 5.5 и Sonnet 5.5).
Threads Messages API и managed-agent session threads — не одно и то же
В поисковой выдаче часто смешиваются два разных типа «threads». Message threads в Messages API — о них эта статья — это временная оптимизация размера запросов без API для списка, чтения или удаления. Managed-agent session threads (GET /v1/sessions/{session_id}/threads/{thread_id}) — это потоки выполнения внутри API Anthropic для управляемых агентов, где есть методы списка, получения и архивации. Если в документации встречаются дочерние threads, потоки событий или архивация, вы открыли не тот API. Чтобы понять, какой интерфейс нужен именно вам, сверяйтесь с справочником API для session threads.
Как живёт thread: создание, продолжение и истечение срока
На практике thread работает только на добавление: сначала вы создаёте его с полным контекстом, затем передаёте изменения, а после потери состояния запускаете повторную отправку. Ветвления, редактирования, отката и API для просмотра состояния нет. Каждый ответ возвращает новый id, и продолжить можно только с каждым id ровно один раз. Правила полей и ошибок в этом разделе основаны на документации платформы и подробно разобраны в этом материале.
При создании передаётся всё: полный набор messages, system и tools, а также:
{
"model": "claude-opus-5-5",
"system": "You are a support agent for Acme. Keep replies short.",
"messages": [{ "role": "user", "content": "Hi! I have a question about an order." }],
"thread": { "type": "create" }
}При продолжении передаётся только новое содержимое — обычно сообщение пользователя или блоки tool_result:
{
"model": "claude-opus-5-5",
"messages": [{ "role": "user", "content": "How long does standard shipping usually take?" }],
"thread": { "type": "continue", "previous_message_id": "msg_xxx_from_create" }
}При continue не отправляйте system и tools — ошибку 400 вызовет даже "system": null. При потоковой передаче дождитесь message_stop и только потом продолжайте; пригодный для продолжения идентификатор приходит в message_start.
Какие поля можно менять по ходу thread
Anthropic фиксирует часть параметров запроса create. Если изменить значение, входящее в этот отпечаток, API вернёт thread_fingerprint_mismatch, и придётся создавать новый thread.
| Группа | Примеры | Правило при continue |
|---|---|---|
| Только при создании | system, tools | Никогда не отправлять повторно; null тоже вызовет ошибку |
| Фиксированные | model, tool_choice, thinking, mcp_servers, context_management, output_config, навыки контейнера, обработка верхнеуровневого cache_control | Должны оставаться неизменными |
| Свободно изменяемые | max_tokens, stop_sequences, stream, metadata, service_tier | Можно менять на каждом ходу |
| Отправлять всегда | URL и токены авторизации MCP-серверов, ID container | На сервере не хранятся, поэтому передавайте их при каждом использовании |
С моделями, поддерживающими расширенное рассуждение, нужно быть особенно внимательными: изменение system или tools может сделать предыдущие блоки thinking / redacted_thinking недействительными. Если после истечения срока полная повторная отправка вернёт 400, удалите устаревшие блоки thinking из восстановленной истории вместо того, чтобы повторять её без изменений.
Правило 5 минут: механизм повторной отправки обязателен
Рассматривайте threads как механизм «по возможности»: храните локально полную историю, system, tools и ссылки на файлы, поскольку сохранность на сервере подтверждается только успешным следующим продолжением. Файлы передаются по ссылке, поэтому удаление файла в середине thread сломает продолжение.
Таймер истечения сбрасывается после каждого сохранённого ответа. Через 5 минут бездействия следующий continue вернёт 404, после чего нужно отправить весь диалог заново как новый create. Данные удаляются не позднее чем через 1 час после последнего использования.
| HTTP | Код | Что произошло | Что делать |
|---|---|---|---|
| 404 | thread_not_found | Состояние истекло, не сохранилось, указан неправильный ключ или workspace, в text-only thread впервые добавлено изображение, запрос обработала fallback-модель или ответ всё ещё генерируется | Проверить ключ, workspace и конфигурацию, затем повторить всю историю как новый create |
| 400 | thread_fingerprint_mismatch | Изменилось фиксированное поле | Вернуть исходное значение или создать новый thread |
| 400 | thread_already_continued | Этот previous_message_id уже использовался | Продолжить с последнего id |
| 400 | thread_continue_in_flight | Для одного ID одновременно выполняется несколько continue | Дождаться завершения, затем использовать новый ID; в противном случае повторить запрос целиком |
| 400 | thread_unsupported_request | Используется неподдерживаемая настройка (например, больше 4 точек кэширования или batches) | Удалить настройку или отправить запрос без thread |
Согласно сводке документации, ошибочные запросы thread завершаются до запуска модели, поэтому токены не расходуются и таймер истечения не сбрасывается. Атомарно сохраняйте ID последнего успешного ответа до того, как принимать следующий ход, а повторные отправки делайте идемпотентными, особенно если вызовы инструментов имеют побочные эффекты.
Пример повторной отправки на Python (обрабатывает только подтверждённый thread_not_found; для ошибок отпечатка, конкурентного доступа и неподдерживаемого запроса нужны отдельные ветки):
try:
resp = client.beta.messages.create(
model="claude-opus-5-5",
messages=[new_msg], # delta only
thread={"type": "continue", "previous_message_id": last_id},
extra_headers={"anthropic-beta": "message-threads-2026-08-12"},
)
except NotFoundError: # thread_not_found after checking identity/config
resp = client.beta.messages.create(
model="claude-opus-5-5",
system=SYSTEM, tools=TOOLS,
messages=full_history + [new_msg], # you stored this
thread={"type": "create"},
extra_headers={"anthropic-beta": "message-threads-2026-08-12"},
)Ловушка 404 при проксировании и ротации ключей
Это поведение описывают операторы; в официальной документации его пока нет. Thread привязан к организации, workspace и учётным данным, с которыми был создан. Если прокси меняет API-ключ для каждого запроса, thread создаётся на ключе A, а продолжить его пытаются ключом B. В результате ситуация выглядит в точности как истёкший срок: бесконечные 404, затем полная повторная отправка — и никакого выигрыша по задержке.
«thread привязан к ключу и workspace, на которых его создали; при смене ключа будет 404 thread_not_found. Если прокси ротирует ключи, сначала получите 404, а затем запрос будет отправлен целиком.» — @ak12kpoot (заметка китайского разработчика о работе прокси)
Закрепляйте thread за одним ключом либо отключайте threads на маршрутах с пулом ключей.
Где работают threads, что они не поддерживают и стоит ли переходить уже сейчас
Message threads доступны в Claude API, Claude Platform на AWS, Anthropic-managed Google Cloud Claude Models и Claude в Microsoft Foundry. Бета охватывает все модели: отдельного списка разрешённых моделей нет, как нет и заявленного списка ожидания.
Для планирования запуска важнее ограничения:
| Область | Статус |
|---|---|
| Amazon Bedrock | Не поддерживается |
| Message Batches | Не поддерживаются — элементы thread в пакетах завершаются ошибкой |
| Эндпоинт подсчёта токенов | Не поддерживается — полную историю нужно считать самостоятельно |
| Compaction / редактирование контекста | Не поддерживается (кроме clear_thinking с keep all) |
| Zero data retention, HIPAA-ready, inference hooks | Не поддерживаются |
| API управления threads | Отсутствует — нельзя получить список, прочитать или удалить threads |
Короткий чек-лист решения
- Используйте threads уже сейчас: для активных coding-агентов, циклов computer use со скриншотами и сценариев с большим количеством документов, где между десятками ходов проходит меньше 5 минут. Обязательно добавьте prompt caching и механизм повторной отправки.
- Пока отложите: чаты с темпом обычного общения, приостановленные процессы, batch-конвейеры, нагрузки с ZDR/HIPAA и развёртывания в Bedrock.
- Комбинируйте, если это действительно нужно: верхнеуровневый
cache_controlв каждом запросе учитывается в лимите 4 точек кэширования; точки изsystem/tools, заданные при create, снова учитываются в каждом continue. Превышение лимита вызываетthread_unsupported_request, поэтому перед включением обоих механизмов объедините точки кэширования.
Читайте также: руководство по ценам Claude API в 2026 году, руководство по Claude Skills API.
FAQ
Какой beta-заголовок и параметр нужны?
В каждый запрос внутри thread добавляйте anthropic-beta: message-threads-2026-08-12. В первом вызове используйте thread: { "type": "create" }, а затем — thread: { "type": "continue", "previous_message_id": "<last response id>" }.
Что произойдёт после истечения срока thread?
Следующий continue вернёт 404 thread_not_found. Отправьте заново весь messages вместе с исходными system/tools как новый create. Срок истечения — 5 минут бездействия, а удаление происходит не позднее чем через 1 час после последнего использования.
Можно ли получить список threads, посмотреть их содержимое или удалить их?
Нет. Для threads Messages API нет API управления. Единственная долговременная запись — ваша локальная история.
Работает ли это в Amazon Bedrock?
Нет. Поддерживаются Claude API, AWS Claude Platform, Microsoft Foundry и управляемый Anthropic Google Cloud. В Bedrock нужно по-прежнему отправлять историю целиком.
Можно ли изменить system prompt или tools внутри thread?
Нет. Создайте новый thread с обновлёнными system/tools. Отправка изменённых значений при continue вызывает thread_fingerprint_mismatch. То же правило действует для model, tool_choice и настроек thinking.
Работает ли это со streaming, tools и MCP?
Да, но с условиями: перед продолжением дождитесь message_stop, передавайте URL и токены MCP, а также ID container на каждом ходу. Параметр fallbacks нужно указывать либо в каждом запросе, либо ни в одном: ответ fallback-модели не сохраняется и требует повторной отправки.