До сих пор каждый запрос к Claude API нёс в себе всю переписку целиком: сервер заново получал историю и заново её обрабатывал. Для коротких чатов это незаметно, для агентов с сотнями тысяч токенов — главный источник задержки и лишнего сетевого трафика.
Message Threads меняет транспорт, а не модель. Клиент отправляет только то, что добавилось с прошлого сообщения, а сервер держит нить в памяти между запросами. По оценке Anthropic, на запросах объёмом от 500 тысяч до миллиона токенов это сокращает время до первого токена примерно на 35%.
Что важно знать
- Нить хранится в памяти в зашифрованном виде и истекает после пяти минут простоя: если пауза больше, историю придётся отправить заново.
- Расход токенов не меняется: модель по-прежнему читает всю историю, экономия — в передаче и обработке запроса.
- Работает на платформе Claude, а также через AWS, Microsoft Foundry и Google Cloud.
Больше всего выигрывают кодинг-агенты, агенты computer-use и пайплайны, которые обрабатывают много документов и изображений: там контекст растёт быстро, а паузы между шагами короткие.
Как это встраивать
Для команд, которые уже строят агентов, есть практический нюанс: пятиминутное окно означает, что нельзя полагаться на нить как на хранилище состояния. Если между шагами возможна пауза на человека или ожидание вебхука, логику восстановления контекста нужно продумать заранее — иначе выигрыш в задержке обернётся повторной отправкой истории.
В остальном это редкий случай, когда оптимизация не требует менять промпты или архитектуру: достаточно перейти на новый режим и проверить, что клиент корректно обрабатывает истечение нити.
Until now every Claude API request carried the entire conversation: the server received the history again and processed it again. For short chats that is invisible; for agents with hundreds of thousands of tokens it is the main source of latency and wasted network traffic.
Message Threads changes the transport, not the model. The client sends only what was added since the last message, and the server keeps the thread in memory between requests. Anthropic estimates that for requests between 500,000 and one million tokens this cuts time to first token by about 35%.
What to know
- The thread is held in memory encrypted and expires after five minutes of inactivity: any longer pause means resending the history.
- Token usage does not change: the model still reads the whole history; the saving is in transmission and request handling.
- It works on the Claude platform and through AWS, Microsoft Foundry and Google Cloud.
Coding agents, computer-use agents and pipelines that process many documents and images benefit most: context grows quickly there, and pauses between steps are short.
How to adopt it
For teams already building agents there is a practical caveat: the five-minute window means the thread cannot serve as state storage. If a human approval or a webhook wait can appear between steps, design context recovery in advance, or the latency win will turn into resending history.
Otherwise this is a rare case where the optimisation requires no prompt or architecture changes: switch the mode on and verify the client handles thread expiry correctly.