Refusals en streaming

Découvrez comment gérer les refusals en streaming avec Claude 4 et les versions ultérieures

À partir des modèles Claude 4, les réponses en streaming de l'API de Claude retournent stop_reason: "refusal" lorsque les classificateurs de streaming interviennent pour gérer les violations potentielles de politique. Cette nouvelle fonctionnalité de sécurité aide à maintenir la conformité du contenu lors du streaming en temps réel.

Pour en savoir plus sur les refusals déclenchés par les filtres de sécurité de l'API pour Claude Sonnet 4.5, consultez Understanding Sonnet 4.5's API Safety Filters.

Format de réponse API

Lorsque les classificateurs de streaming détectent du contenu qui viole les politiques d'Anthropic, l'API retourne cette réponse :

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Hello.."
    }
  ],
  "stop_reason": "refusal"
}

Aucun message de refusal supplémentaire n'est inclus. Vous devez gérer la réponse et fournir un message approprié destiné à l'utilisateur.

Réinitialiser le contexte après un refusal

Lorsque vous recevez stop_reason: refusal, vous devez réinitialiser le contexte de la conversation en supprimant ou en mettant à jour le tour qui a été refusé avant de continuer. Tenter de continuer sans réinitialiser entraînera des refusals continus.

Les métriques d'utilisation sont toujours fournies dans la réponse à des fins de facturation, même lorsque la réponse est refusée.

Vous serez facturé pour les tokens de sortie jusqu'au refusal.

Si vous rencontrez fréquemment des raisons d'arrêt refusal lors de l'utilisation de Claude Sonnet 4.5 ou Opus 4.1, vous pouvez essayer de mettre à jour vos appels API pour utiliser Haiku 4.5 (claude-haiku-4-5-20251001), qui a des restrictions d'utilisation différentes. En savoir plus sur understanding Sonnet 4.5's API safety filters.

Guide de mise en œuvre

Voici comment détecter et gérer les refusals en streaming dans votre application :

client = anthropic.Anthropic()
messages = []


def reset_conversation():
    """Reset conversation context after refusal"""
    global messages
    messages = []
    print("Conversation reset due to refusal")


try:
    with client.messages.stream(
        max_tokens=1024,
        messages=messages + [{"role": "user", "content": "Hello"}],
        model="claude-sonnet-4-6",
    ) as stream:
        for event in stream:
            # Check for refusal in message delta
            if hasattr(event, "type") and event.type == "message_delta":
                if event.delta.stop_reason == "refusal":
                    reset_conversation()
                    break
except Exception as e:
    print(f"Error: {e}")

Types de refusal actuels

L'API gère actuellement les refusals de trois façons différentes :

Type de Refusal	Format de Réponse	Quand cela se produit
Refusals du classificateur de streaming	`stop_reason`: `refusal`	Pendant le streaming lorsque le contenu viole les politiques
Validation des entrées API et des droits d'auteur	Codes d'erreur 400	Lorsque l'entrée échoue les vérifications de validation
Refusals générés par le modèle	Réponses texte standard	Lorsque le modèle lui-même décide de refuser

Les futures versions de l'API étendront le modèle stop_reason: refusal pour unifier la gestion des refusals dans tous les types.

Bonnes pratiques

Surveiller les refusals : Incluez des vérifications stop_reason: refusal dans votre gestion des erreurs
Réinitialiser automatiquement : Implémentez une réinitialisation automatique du contexte lorsque des refusals sont détectés
Fournir une messagerie personnalisée : Créez des messages conviviaux pour une meilleure expérience utilisateur lorsque des refusals se produisent
Suivre les modèles de refusal : Surveillez la fréquence des refusals pour identifier les problèmes potentiels avec vos invites

Notes de migration

Les futurs modèles étendront ce modèle à d'autres types de refusals
Planifiez votre gestion des erreurs pour accommoder l'unification future des réponses de refusal

Was this page helpful?

ConstruireCapacités du modèle

Refusals en streaming

Découvrez comment gérer les refusals en streaming avec Claude 4 et les versions ultérieures

Pour en savoir plus sur les refusals déclenchés par les filtres de sécurité de l'API pour Claude Sonnet 4.5, consultez Understanding Sonnet 4.5's API Safety Filters.

Format de réponse API

Lorsque les classificateurs de streaming détectent du contenu qui viole les politiques d'Anthropic, l'API retourne cette réponse :

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Hello.."
    }
  ],
  "stop_reason": "refusal"
}

Aucun message de refusal supplémentaire n'est inclus. Vous devez gérer la réponse et fournir un message approprié destiné à l'utilisateur.

Réinitialiser le contexte après un refusal

Les métriques d'utilisation sont toujours fournies dans la réponse à des fins de facturation, même lorsque la réponse est refusée.

Vous serez facturé pour les tokens de sortie jusqu'au refusal.

Guide de mise en œuvre

Voici comment détecter et gérer les refusals en streaming dans votre application :

client = anthropic.Anthropic()
messages = []


def reset_conversation():
    """Reset conversation context after refusal"""
    global messages
    messages = []
    print("Conversation reset due to refusal")


try:
    with client.messages.stream(
        max_tokens=1024,
        messages=messages + [{"role": "user", "content": "Hello"}],
        model="claude-sonnet-4-6",
    ) as stream:
        for event in stream:
            # Check for refusal in message delta
            if hasattr(event, "type") and event.type == "message_delta":
                if event.delta.stop_reason == "refusal":
                    reset_conversation()
                    break
except Exception as e:
    print(f"Error: {e}")

Types de refusal actuels

L'API gère actuellement les refusals de trois façons différentes :

Type de Refusal	Format de Réponse	Quand cela se produit
Refusals du classificateur de streaming	`stop_reason`: `refusal`	Pendant le streaming lorsque le contenu viole les politiques
Validation des entrées API et des droits d'auteur	Codes d'erreur 400	Lorsque l'entrée échoue les vérifications de validation
Refusals générés par le modèle	Réponses texte standard	Lorsque le modèle lui-même décide de refuser

Les futures versions de l'API étendront le modèle stop_reason: refusal pour unifier la gestion des refusals dans tous les types.

Bonnes pratiques

Surveiller les refusals : Incluez des vérifications stop_reason: refusal dans votre gestion des erreurs
Réinitialiser automatiquement : Implémentez une réinitialisation automatique du contexte lorsque des refusals sont détectés
Fournir une messagerie personnalisée : Créez des messages conviviaux pour une meilleure expérience utilisateur lorsque des refusals se produisent
Suivre les modèles de refusal : Surveillez la fréquence des refusals pour identifier les problèmes potentiels avec vos invites

Notes de migration

Les futurs modèles étendront ce modèle à d'autres types de refusals
Planifiez votre gestion des erreurs pour accommoder l'unification future des réponses de refusal

Was this page helpful?