Стриминг Claude API — обзор ключевых возможностей

Если вы хотите, чтобы Claude работал быстро, включите стриминг. Вместо ожидания 15–25 секунд одного полного ответа пользователи часто видят первый токен примерно через 300–800 мс.

Вот краткая версия:

• Я бы использовал стриминг SSE, когда хочу, чтобы ответы появлялись по мере генерации
• Я бы держал вызовы Claude за backend-прокси, чтобы защитить API-ключи
• Я бы следил за TTFT (временем до первого токена), max_tokens и обрывами, чтобы контролировать UX и расходы
• Я бы парсил потоковые события по порядку: message_start, события блоков контента, message_delta, затем message_stop
• Я бы буферизировал JSON-фрагменты инструментов до окончания блока контента
• Я бы планировал обрывы соединений, потому что Claude не возобновляет потоки нативно

Выделяется несколько цифр:

• Haiku 4.5: около 410 мс TTFT
• Sonnet 4.6: около 720 мс TTFT
• Opus 4.7: около 980 мс TTFT
• Стандартные таймауты прокси в 30–60 секунд могут обрезать длинные ответы
• Часто нужны более длинные таймауты чтения — 120–300 секунд
• Пакетные задания могут стоить на 50% дешевле стандартных тарифов за токены

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

Вот что важнее всего:

Поэтому, настраивая это, я бы думал о стриминге как о решении в области UX и инфраструктуры, а не просто о флаге API.

Разработка с Claude API — Часть 4 — Стриминг ответов

Как стриминг Claude API работает на уровне протокола

Включение стриминга не меняет саму модель. Оно меняет то, как доставляется вывод. Вместо ожидания одного полного ответа Claude отправляет небольшие порции по мере их готовности.

Какой эндпоинт и настройки запроса включают стриминг

Стриминг использует тот же эндпоинт Claude Messages API, /v1/messages, что и обычный запрос. Единственное отличие — добавление "stream": true в тело запроса ^[1][3]. Этот флаг переводит соединение со стандартного потока запрос-ответ на Server-Sent Events (SSE), где сервер отправляет порции по мере их генерации.

Официальные SDK для Python и TypeScript включают потоковые хелперы, которые сами обрабатывают парсинг событий и сборку сообщения. Когда поток завершается, вызов .get_final_message() в Python или .finalMessage() в TypeScript возвращает готовый ответ вместе с количеством токенов и причиной остановки ^[1][4].

Эти настройки запускают поток. Следующий элемент — поток событий, который приходит по соединению.

Какие события приходят во время потока

Поток следует заданной последовательности именованных событий. Каждое событие несёт данные, необходимые вашему клиенту, чтобы правильно восстановить полный ответ.

Это данные, которые ваш клиент буферизирует и показывает в реальном времени. Для вывода обычного текста добавляйте каждый text_delta в локальный буфер по мере поступления событий. Именно так итоговая строка ответа собирается по частям. Входные данные вызовов инструментов работают немного иначе: они приходят как фрагменты input_json_delta, поэтому их следует сначала буферизировать и парсить только после content_block_stop ^[1][6].

Когда APIMart актуален для стриминга Claude

Если стриминг Claude находится внутри мультимодельного приложения, APIMart может дать вам единое место для маршрутизации доступа к Claude и стриминга через унифицированный LLM API. Обычно это важнее всего, когда вы хотите один и тот же потоковый процесс на веб- и мобильных клиентах.

Как добавить стриминг Claude в веб- и мобильные приложения

SSE, HTTP-стриминг или WebSocket-обёртки: что выбрать

Как только вы поняли, как Claude отправляет потоковые события, следующий шаг — доставить эти события веб- и мобильным клиентам. Главный вопрос прост: какой транспорт лучше подходит вашему приложению?

Для большинства браузерных приложений SSE — выбор по умолчанию. Он хорошо работает с большинством прокси и CDN, а история поддержки в браузерах проста.

WebSockets всё ещё могут иметь смысл. Если ваше приложение уже зависит от двунаправленной живой связи, они могут отлично подойти. Но для стандартного чат-приложения они часто добавляют больше движущихся частей, чем того стоят.

Почему backend-прокси обычно самая безопасная архитектура

После выбора транспорта поместите обработку потока за свой сервер. Держите запросы к Claude за backend-прокси, чтобы защитить свои API-ключи для различных моделей ^[9][5].

Этот прокси-слой также подходящее место, чтобы:

• вставлять системные промпты
• применять лимиты частоты запросов на пользователя
• логировать тайминг первого и последнего токена

Установите X-Accel-Buffering: no, чтобы остановить буферизацию прокси ^[2][8]. Также подключите сигнал отмены клиента к потоку. Так, если пользователь останавливает генерацию, запрос отменяется сразу, а не тратит токены на ответ, который никто не прочтёт.

Ещё один подвох: стандартные таймауты в 30–60 секунд могут обрезать длинные ответы ^[9][2]. В продакшене используйте таймауты чтения около 120–300 секунд для более длинных генераций.

Как выглядит хороший клиентский UX во время живого ответа

Как только поток защищён и ретранслируется, задача смещается к UI. Именно здесь стриминг ощущается либо плавным, либо неуклюжим.

Показывайте индикатор «Thinking...» или спиннер сразу, как только пользователь отправит промпт. Это покрывает задержку до первого токена. Как только приходит первый content_block_delta, уберите индикатор и начните рендерить текст.

Затем добавляйте каждый text_delta по мере поступления, чтобы ответ появлялся с эффектом печатной машинки. Чтобы интерфейс не подтормаживал, объединяйте обновления через requestAnimationFrame, чтобы не запускать слишком много перерисовок. Автопрокрутка должна следовать за ответом во время генерации, но должна отступать, если пользователь прокручивает вверх, чтобы прочитать более старый контент.

Всегда включайте кнопку «Stop», подключённую к AbortController, чтобы она могла отменить Fetch-запрос. Это должно чисто завершить поток, не стирая текст, который уже на экране.

Если соединение обрывается, оставьте частичный вывод видимым. Для восстановления сохраните этот частичный текст и перезапустите с промптом-продолжением, поскольку Claude не возобновляет оборванный поток нативно ^[3][1].

Как управлять задержкой, стоимостью и надёжностью в продакшене

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

Как стриминг меняет воспринимаемую задержку

Главная UX-метрика здесь — Time to First Token (TTFT): время, пока не появится первое слово. В потоковом приложении именно этот первый видимый токен формирует всё ощущение продукта. Если он появляется быстро, приложение кажется отзывчивым. Если тянет — пользователи это замечают.

Бенчмарки показывают явные разрывы между моделями Claude: Haiku 4.5 достигает примерно 410 мс TTFT, Sonnet 4.6 — около 720 мс, а Opus 4.7 выходит примерно на 980 мс ^[3]. Простое правило — использовать самую быструю модель, которая всё ещё проходит вашу планку качества.

Размер промпта тоже важен. Более крупные контекстные окна могут поднять TTFT до 1–3 секунд ^[5]. Так что если в вашем системном промпте есть лишние инструкции, старые правила или раздутые примеры, их сокращение может сделать приложение заметно шустрее.

Как отслеживать использование токенов и контролировать затраты в USD

Стриминг и пакетная обработка стоят одинаково за токен. Меняется только то, когда приходит вывод. Количество токенов включено в сам поток: событие message_start включает usage.input_tokens, а событие message_delta ближе к концу включает итоговые накопленные usage.output_tokens ^[1][4]. Ваш бэкенд должен сохранять эти итоговые данные об использовании после завершения потока, чтобы биллинг оставался точным.

Устанавливайте max_tokens в каждом запросе. Это даёт жёсткий предел и не даёт длинным генерациям взвинчивать расходы ^[1][11]. Также следите за обрывами клиента на стороне сервера. Если пользователь ушёл, а генерация продолжается, вы всё равно жжёте токены без причины ^[5][7].

Для заданий, которым не нужен живой вывод, математика меняется. Хорошие примеры — пакетная суммаризация, офлайн-обработка и ночная генерация отчётов. В этих случаях Batch API даёт скидку 50% на обычные тарифы за токены ^[5][10].

Claude 3.5 Sonnet стоит около $3,00 за 1 миллион входных токенов и $15,00 за 1 миллион выходных токенов при стандартном стриминге ^[8]. С Batch API асинхронные нагрузки стоят вдвое меньше.

Эти цифры использования также помогают с биллингом и мониторингом лимитов частоты. Больше стратегий по управлению высоконагруженными запросами смотрите в наших советах по стоимости AI API.

Как предотвратить обрывы потоков и безопасно восстановиться

У Claude нет серверной функции возобновления ^[1][3]. Если поток обрывается, отправьте частичный вывод в новом запросе и попросите Claude продолжить с точки обрыва.

Повторяйте только те сбои, которые, вероятно, устранятся сами.

После этого финальный шаг — выбрать, какие функции стриминга важнее всего.

Заключение: какие функции стриминга Claude важнее всего

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

Стриминг важен, потому что доставка первого токена делает Claude быстрым и отзывчивым.

Поток событий SSE даёт вам текстовые дельты, счётчики использования и сигналы об ошибках в реальном времени ^[1][3].

Используйте backend-прокси, чтобы защитить ключи, отключить буферизацию и обрабатывать обрывы ^[2][8]. Для мультимодельных приложений APIMart может централизовать стриминг Claude, логирование и биллинг.

В продакшене важнее всего быстрый TTFT, отслеживание использования и устойчивость прокси.

Частые вопросы

Когда использовать стриминг вместо обычного ответа Claude API?

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

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

Пропустите его для коротких простых запросов или пакетных заданий, где пропускная способность важнее задержки.

Что делать, если поток Claude обрывается посреди ответа?

Если поток Claude обрывается, Server-Sent Events сами по себе не продолжат с того места, где остановились. Ваше приложение должно обработать эту часть.

Когда соединение обрывается, вы можете либо повторить полный запрос, либо показать частичный вывод, который уже сохранили. Используйте блок try/except, чтобы поймать APIConnectionError или APIStatusError, и храните ссылку на контент, накопленный к этому моменту.

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

Как снизить затраты на стриминг без ущерба для UX?

Сосредоточьтесь на тюнинге промптов и эффективном управлении сессиями. Устанавливайте жёсткие лимиты max_tokens, держите промпты короткими и добавьте опцию ранней отмены, чтобы пользователи могли остановить генерацию, как только получат нужное.

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