"stream": true pour diffuser de manière incrémentielle la réponse en utilisant les événements envoyés par le serveur (SSE).
Streaming avec les SDK
Nos SDK Python et TypeScript offrent plusieurs façons de faire du streaming. Le SDK Python permet les flux synchrones et asynchrones. Consultez la documentation de chaque SDK pour plus de détails.Types d’événements
Chaque événement envoyé par le serveur inclut un type d’événement nommé et des données JSON associées. Chaque événement utilisera un nom d’événement SSE (par exempleevent: message_stop), et inclura le type d’événement correspondant dans ses données.
Chaque flux utilise le flux d’événements suivant :
- message_start: contient un objet- Messageavec un- contentvide.
- Une série de blocs de contenu, chacun ayant un content_block_start, un ou plusieurs événementscontent_block_delta, et un événementcontent_block_stop. Chaque bloc de contenu aura unindexqui correspond à son index dans le tableaucontentdu Message final.
- Un ou plusieurs événements message_delta, indiquant les changements de niveau supérieur à l’objetMessagefinal.
- Un événement final message_stop.
Les comptes de jetons affichés dans le champ 
usage de l’événement message_delta sont cumulatifs.Événements ping
Les flux d’événements peuvent également inclure n’importe quel nombre d’événementsping.
Événements d’erreur
Nous pouvons occasionnellement envoyer des erreurs dans le flux d’événements. Par exemple, pendant les périodes d’utilisation intensive, vous pourriez recevoir uneoverloaded_error, qui correspondrait normalement à un HTTP 529 dans un contexte non-streaming :
Exemple d'erreur
Autres événements
Conformément à notre politique de versioning, nous pouvons ajouter de nouveaux types d’événements, et votre code devrait gérer les types d’événements inconnus avec élégance.Types de delta de bloc de contenu
Chaque événementcontent_block_delta contient un delta d’un type qui met à jour le bloc content à un index donné.
Delta de texte
Un delta de bloc de contenutext ressemble à :
Delta de texte
Delta JSON d’entrée
Les deltas pour les blocs de contenutool_use correspondent aux mises à jour pour le champ input du bloc. Pour supporter une granularité maximale, les deltas sont des chaînes JSON partielles, alors que le tool_use.input final est toujours un objet.
Vous pouvez accumuler les deltas de chaîne et analyser le JSON une fois que vous recevez un événement content_block_stop, en utilisant une bibliothèque comme Pydantic pour faire l’analyse JSON partielle, ou en utilisant nos SDK, qui fournissent des assistants pour accéder aux valeurs incrémentales analysées.
Un delta de bloc de contenu tool_use ressemble à :
Delta JSON d'entrée
input à la fois. Ainsi, lors de l’utilisation d’outils, il peut y avoir des délais entre les événements de streaming pendant que le modèle travaille. Une fois qu’une clé et valeur input sont accumulées, nous les émettons comme plusieurs événements content_block_delta avec du json partiel fragmenté afin que le format puisse automatiquement supporter une granularité plus fine dans les modèles futurs.
Delta de réflexion
Lors de l’utilisation de la réflexion étendue avec le streaming activé, vous recevrez le contenu de réflexion via les événementsthinking_delta. Ces deltas correspondent au champ thinking des blocs de contenu thinking.
Pour le contenu de réflexion, un événement spécial signature_delta est envoyé juste avant l’événement content_block_stop. Cette signature est utilisée pour vérifier l’intégrité du bloc de réflexion.
Un delta de réflexion typique ressemble à :
Delta de réflexion
Delta de signature
Réponse complète de flux HTTP
Nous recommandons fortement d’utiliser nos SDK clients lors de l’utilisation du mode streaming. Cependant, si vous construisez une intégration API directe, vous devrez gérer ces événements vous-même. Une réponse de flux est composée de :- Un événement message_start
- Potentiellement plusieurs blocs de contenu, chacun contenant :
- Un événement content_block_start
- Potentiellement plusieurs événements content_block_delta
- Un événement content_block_stop
 
- Un événement 
- Un événement message_delta
- Un événement message_stop
ping dispersés dans la réponse également. Voir Types d’événements pour plus de détails sur le format.
Requête de streaming de base
Response
Requête de streaming avec utilisation d’outil
L’utilisation d’outils supporte maintenant le streaming à granularité fine pour les valeurs de paramètres comme fonctionnalité bêta. Pour plus de détails, voir Streaming d’outils à granularité fine.
Response
Requête de streaming avec réflexion étendue
Dans cette requête, nous activons la réflexion étendue avec le streaming pour voir le raisonnement étape par étape de Claude.Response
Requête de streaming avec utilisation d’outil de recherche web
Dans cette requête, nous demandons à Claude de rechercher sur le web des informations météorologiques actuelles.Response
Récupération d’erreur
Lorsqu’une requête de streaming est interrompue en raison de problèmes de réseau, de timeouts, ou d’autres erreurs, vous pouvez récupérer en reprenant là où le flux a été interrompu. Cette approche vous évite de retraiter toute la réponse. La stratégie de récupération de base implique :- Capturer la réponse partielle : Sauvegarder tout le contenu qui a été reçu avec succès avant que l’erreur ne se produise
- Construire une requête de continuation : Créer une nouvelle requête API qui inclut la réponse partielle de l’assistant comme début d’un nouveau message d’assistant
- Reprendre le streaming : Continuer à recevoir le reste de la réponse là où elle a été interrompue
Meilleures pratiques de récupération d’erreur
- Utiliser les fonctionnalités du SDK : Tirer parti des capacités d’accumulation de messages et de gestion d’erreurs intégrées du SDK
- Gérer les types de contenu : Être conscient que les messages peuvent contenir plusieurs blocs de contenu (text,tool_use,thinking). Les blocs d’utilisation d’outils et de réflexion étendue ne peuvent pas être partiellement récupérés. Vous pouvez reprendre le streaming à partir du bloc de texte le plus récent.