Потоки сообщений ускоряют Claude Code на 2–4 минуты за рабочую сессию

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

Практический эффект заметен, но чуда здесь нет. Anthropic сообщает о сокращении медианного времени до первого токена на 35% для запросов размером от 500 тысяч до 1 миллиона токенов. Автор ZDNET взял журналы примерно 980 обращений к Claude Code и оценил, сколько выиграл бы при новой схеме. Получилось от двух до четырёх минут за четырёхчасовую рабочую сессию со 100–225 вызовами модели.

Где исчезает задержка

Представим агента, который уже несколько часов разбирает большой репозиторий. В его истории лежат исходники, результаты тестов, ответы инструментов и десятки предыдущих решений. Раньше очередная команда вроде «исправь оставшиеся две ошибки» могла сопровождаться повторной передачей всего этого пакета. Теперь по сети уходит в основном новая команда и изменения после предыдущего обращения.

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

Важно и то, что приведённые 2–4 минуты — не результат прямого сравнения одинаковых сессий до и после обновления. Это расчёт на старых журналах с применением заявленного Anthropic сокращения задержки. Он хорошо показывает порядок выигрыша, но не заменяет контролируемый замер. Сеть, регион сервера, размер контекста и характер вызовов могут заметно изменить результат.

Быстрее — не значит дешевле

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

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

Что проверить разработчику

Если Claude Code используется короткими подходами по несколько запросов, изменение можно вообще не заметить. Если агент часами работает с большим репозиторием, постоянно вызывает инструменты или пересылает изображения, выигрыш складывается из десятков небольших сокращений задержки.

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