Rechazos en streaming

A partir de los modelos Claude 4, las respuestas de streaming de la API de Claude devuelven stop_reason: "refusal" cuando los clasificadores de streaming intervienen para gestionar posibles infracciones de políticas. Esta función de seguridad ayuda a mantener el cumplimiento del contenido durante el streaming en tiempo real.



Formato de respuesta de la API

Cuando los clasificadores de streaming detectan contenido que infringe las políticas de Anthropic, la API devuelve esta respuesta:

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



Restablecer el contexto después de un rechazo

Cuando recibas stop_reason: refusal, debes restablecer el contexto de la conversación antes de continuar. Puedes eliminar o reformular el turno que provocó el rechazo, o borrar por completo el historial de la conversación. Si intentas continuar sin restablecer el contexto, seguirás recibiendo rechazos.



Guía de implementación

A continuación se muestra cómo detectar y gestionar los rechazos de streaming en tu aplicación:

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-opus-4-8",
    ) as stream:
        for event in stream:
            # Verificar si hay un rechazo en el delta del mensaje
            if event.type == "message_delta":
                if event.delta.stop_reason == "refusal":
                    reset_conversation()
                    break
except Exception as e:
    print(f"Error: {e}")



Tipos de rechazo actuales

Actualmente, la API gestiona los rechazos de tres formas diferentes:



Prácticas recomendadas

• Monitorea los rechazos: Incluye comprobaciones de stop_reason: refusal en tu gestión de errores
• Restablece automáticamente: Implementa el restablecimiento automático del contexto cuando se detecten rechazos
• Recurre a otro modelo: Configura la alternativa del lado del servidor o el middleware del SDK para que las solicitudes rechazadas se reintenten en otro modelo de Claude en lugar de mostrar un rechazo al usuario
• Canjea el crédito de alternativa en reintentos manuales: Si implementas el reintento tú mismo, pasa el token de crédito de alternativa del rechazo para que el reintento no pague dos veces el costo de la caché de prompts
• Proporciona mensajes personalizados: Crea mensajes amigables para el usuario para mejorar la experiencia cuando ocurran rechazos
• Rastrea patrones de rechazo: Monitorea la frecuencia de rechazos para identificar posibles problemas con tus prompts



Notas de migración

Si implementaste la gestión de rechazos cuando esta función se lanzó por primera vez, o la estás añadiendo a una integración existente, verifica lo siguiente:

• Los rechazos son respuestas, no errores. Un rechazo llega como una respuesta HTTP 200 exitosa con stop_reason: "refusal", por lo que el monitoreo basado únicamente en tasas de error no lo detectará. Rastrea los rechazos como una señal independiente.
• Los modelos más recientes devuelven más detalles. En Claude Fable 5, un rechazo también incluye un objeto stop_details que identifica la categoría de política detrás de la negativa. Consulta Rechazos y alternativas para ver la estructura completa de la respuesta.
• Reintenta en un modelo diferente. Reenviar una solicitud rechazada al mismo modelo generalmente resulta en otro rechazo. En lugar de solo restablecer el contexto, reintenta en un modelo alternativo con la alternativa del lado del servidor, el middleware del SDK o un reintento manual, y canjea el crédito de alternativa cuando implementes el reintento tú mismo.
• Revisa los resultados de lotes en busca de rechazos. Una solicitud rechazada en un Lote de mensajes se devuelve como un resultado exitoso con stop_reason: "refusal", no como un resultado con error.
• Centraliza la gestión en stop_reason. La API continúa consolidando la gestión de rechazos en torno a stop_reason: "refusal", así que bifurca según la razón de detención en lugar de según el comportamiento específico del modelo.



Próximos pasos