Anthropic сокращает задержку Claude в длинных диалогах примерно на 35%

У длинных диалогов с Claude есть неприятная инженерная особенность: история постоянно растёт, а приложение снова и снова отправляет её вместе с очередной репликой. Представьте агента, который уже обсудил с пользователем требования, прочитал несколько файлов и выполнил десяток действий. Чтобы попросить его сделать следующий шаг, разработчику приходится ещё раз передать весь накопленный разговор. Это увеличивает объём запроса и время до начала ответа.

Anthropic предложила для таких сценариев message threads — потоки сообщений в публичной бете API. Полная история передаётся один раз, после чего приложение отправляет только новые сообщения. Компания утверждает, что на очень длинных сессиях это примерно на 35% сокращает ожидание перед ответом Claude. Для разработчика смысл простой: меньше повторной передачи одного и того же контекста, особенно в агентах, которые живут дольше одного запроса.

Как это выглядит на практике

Допустим, агент помогает разработчику исправить ошибку. Сначала он получает описание задачи, изучает код, обсуждает возможную причину и предлагает изменения. Затем пользователь пишет: «Запусти тесты и проверь результат». В обычной схеме приложение может снова собрать и отправить весь разговор — от первого сообщения до последнего. С message threads исходная беседа уже связана с потоком, поэтому к ней добавляется только новая команда.

Это не означает, что модель получила бесконечную память или перестала учитывать контекстное окно. Речь идёт прежде всего о способе передачи и хранения последовательности сообщений на стороне API. Для короткого чат-бота из двух реплик разница может быть незаметна. Для исследовательского агента, помощника программиста или внутреннего корпоративного ассистента с длинной рабочей сессией выигрыш уже способен повлиять на ощущаемую скорость продукта.

Где здесь польза, а где маркетинг

Заявленные 35% относятся к ожиданию ответа в очень длинных сессиях, а не к ускорению каждого вызова Claude на треть. Anthropic не обещает такого результата для коротких диалогов. Поэтому переносить цифру на весь продукт нельзя: эффект нужно измерять на собственных сценариях, с реальной длиной истории, набором инструментов и характером запросов.

Цены и лимиты API при запуске функции остаются прежними. Значит, message threads не стоит воспринимать как автоматическую скидку. Даже если приложение передаёт меньше повторяющихся данных, из опубликованного описания не следует, что счёт за обработку контекста обязательно уменьшится. Главная заявленная выгода сейчас — задержка, а не стоимость.

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

Что делать разработчику

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

Если задержка заметно снизится без новых проблем с состоянием, функцию можно постепенно расширять на другие агентские процессы. Если ваши диалоги короткие, срочно менять архитектуру незачем. Message threads решают конкретную проблему длинных сессий: они убирают постоянную пересылку уже известной переписки. Это полезное инфраструктурное улучшение, но его ценность определяется не красивой цифрой, а измерениями внутри вашего продукта.