Rechazos en Seedance 2.5: cómo leer el filtro
Diagnostica rechazos de Seedance 2.5 desde el error de tarea, enrutamiento y créditos liquidados sin adivinar la verificación de seguridad que se activó.
¿Por qué falló una solicitud de Seedance 2.5: rechazó la API la carga antes de que existiera una tarea, o más tarde una tarea falló una verificación de seguridad asincrónica? La respuesta ya contiene la evidencia necesaria para separar esos casos.
Esta guía utiliza la ruta exacta, los campos de solicitud, el estado de la tarea, el código de error y el uso liquidado para diagnosticar un rechazo. No infiere el comportamiento de un host a partir de otro o trata una ruta menos restrictiva como un modelo sin filtrar.
Resumen ejecutivo
- Comienza con la creación de tareas, no con el tiempo transcurrido. Un
400sincrónico significa que la solicitud falló la validación antes de que se creara una tarea. Una tarea que luego termina enfaileddebe diagnosticarse desde sus camposerroryusage.[2][3] content_filter: falseno es "sin filtrar". En reAPI selecciona el canal Flexible, mantiene el mismo precio y no desactiva las verificaciones de política aguas arriba.[2]- El error
80006no nombra la fase de moderación. Puede referirse al prompt, una imagen o video de referencia, o la salida generada.[3] - Revisa la factura terminal. El
usage.creditsde una tarea fallida muestra si la reserva se reembolsó completamente o se retuvo un cargo posterior a la generación.[3][4] - Datos de modelo que vale la pena conocer: Seedance 2.5 genera hasta 30 segundos en un único paso y acepta hasta 30 imágenes, 10 clips de video y 10 clips de audio como referencia.[1]
Por qué importan los detalles de enrutamiento
Las diferentes superficies de acceso pueden validar y enrutar el mismo modelo de forma diferente. En reAPI, content_filter es explícitamente un control de enrutamiento en lugar de un parámetro de modelo aguas arriba. El valor predeterminado es true; los clientes de API directa pueden configurarlo en false para usar el canal Flexible menos restrictivo, pero la moderación sigue aplicándose.[2]
Cuatro etapas observables importan durante el diagnóstico:
- Validación de solicitud sincrónica. Los campos incorrectos o los medios no compatibles devuelven un error HTTP antes de crear una tarea.
- Selección de ruta. Las solicitudes compatibles se envían a través del canal elegido por parámetros específicos del modelo como
content_filter. - Ejecución de tarea asincrónica. La tarea se mueve a través de
processingantes de llegar acompletedofailed. - Fallo de seguridad. El error
80006puede representar un prompt rechazado, una referencia o una salida generada; el código genérico por sí solo no identifica qué verificación de seguridad se activó.[3]
Estas son etapas de API observables, no una afirmación de que cada host implemente la misma tubería interna.
Cinco verificaciones que ubican el fallo
Estas verificaciones utilizan campos que la API expone. No requieren un prompt deliberadamente deshabilitado.
Verificación 1: ¿la presentación creó una tarea?
Guarda el código de estado HTTP y el cuerpo de la respuesta del POST. Un 400 sincrónico con un error 2xxxx es validación de solicitud: arregla el campo o formato de medios nombrado. Si la respuesta contiene una ID de tarea, la presentación pasó y el diagnóstico posterior pertenece al registro de tareas.[2][3]
El tiempo transcurrido es contexto de apoyo, no prueba de cuál componente interno tomó la decisión.
Verificación 2: registra la ruta y los campos de enrutamiento
Guarda el endpoint, la ID de modelo exacta, la carga completa y el valor content_filter. En reAPI, omitir content_filter significa true; false selecciona el canal Flexible. Comparar resultados sin registrar ese campo compara dos rutas diferentes.[2]
Verificación 3: valida el contrato de referencia
Utiliza solo material de referencia que posees o tienes permiso para procesar. Confirma que cada URL es HTTP(S) público, su formato de archivo real es compatible y los recuentos de imagen, video y audio permanecen dentro de los límites documentados. Los medios no compatibles devuelven un 400 sincrónico, así que no debe describirse como un rechazo de moderación del modelo.[2]
Verificación 4: inspecciona el error de tarea terminal
Consulta GET /api/v1/tasks/{id} hasta completed o failed. Para una tarea fallida, registra error.code, error.message, la ID de la tarea y la solicitud original. El código 80006 confirma un fallo de política de contenido pero no revela si el prompt, una referencia o el resultado generado lo activó.[3][4]
Verificación 5: inspecciona el uso liquidado
Lee usage.credits de la misma tarea terminal. Cero significa que la reserva se reembolsó; un valor positivo significa que se retuvo un cargo posterior a la generación documentado. No infiera la factura solo desde el mensaje de error.[3][4]
Por qué el error 80006 no identifica el disparador
El contrato de error público agrupa deliberadamente varios resultados de seguridad bajo un código de flujo de trabajo. Un prompt, imagen de referencia, video de referencia o salida generada puede desencadenar 80006.[3] El código no demuestra que un host reescribió el prompt, ejecutó un clasificador de rostros particular o cambió un umbral.
No reintentes la misma carga sin cambios. Primero revisa el texto del prompt sensible y verifica cada referencia. Si el modelo lo admite y estás llamando la API directamente, content_filter: false puede probar la ruta menos restrictiva; aún no desactiva la revisión de seguridad.[2][3]
Hechos de ruta y parámetros que puedes verificar
La ruta es asincrónica. Presenta a POST /api/v1/videos/generations, retén la ID de tarea devuelta e interroga GET /api/v1/tasks/{id}. Consultar no consume créditos.[2][4]
content_filter es enrutamiento específico del modelo. El valor predeterminado es true en la ruta Seedance 2.5 de reAPI. Configurarlo en false cambia el canal, no el precio, y los fallos en esa ruta siguen siendo posibles.[2]
El enum de resolución actual de reAPI es 480p, 720p o 1080p. Verifica el archivo devuelto antes de confiar en una etiqueta de resolución más amplia de un revendedor.[2]
Los límites de referencia son explícitos. El modelo acepta hasta 30 imágenes, 10 clips de video y 10 clips de audio; ByteDance describe la misma capacidad de referencia multimodal en su material de lanzamiento.[1][2]
Preguntas frecuentes
¿Es Seedance 2.5 sin censura?
No. En reAPI, content_filter: false significa un canal de enrutamiento menos restrictivo; la documentación dice explícitamente que no desactiva la moderación y las verificaciones de política aguas arriba pueden seguir fallando en la tarea.[2][3]
¿Por qué funcionó el mismo prompt en un sitio y falló en otro?
Los resultados no son comparables hasta que confirmes el endpoint, la ID de modelo exacta, la carga, las referencias y los ajustes de enrutamiento. Registra esos valores y compara el código de estado HTTP devuelto, el error de tarea y el uso liquidado en lugar de adivinar un filtro interno.
¿Por qué fue rechazado mi personaje generado por IA como una persona real?
El código genérico 80006 no puede responder eso. Solo dice que el prompt, el material de referencia o la salida generada desencadenó una verificación de seguridad. Revisa las tres entradas a la decisión antes de cambiar el prompt.[3]
¿Por qué un prompt que funcionó la semana pasada empezó a fallar?
Reproduce con la ID de modelo guardada, ruta, carga y referencias. Luego compara la nueva respuesta HTTP y el error de tarea con el registro anterior. Sin esos campos, un resultado cambiado no identifica qué cambió.
¿Qué resoluciones admite Seedance 2.5?
La ruta actual de reAPI acepta 480p, 720p y 1080p. Verifica el archivo devuelto antes de construir un contrato de entrega alrededor de cualquier etiqueta de resolución.[2]
¿Cuánto puede durar un clip individual de Seedance 2.5?
Hasta 30 segundos en un único paso.[1]
¿Puedo usar el rostro de una persona real como referencia?
El contrato de solicitud de reAPI permite material de referencia de personas reales y lo revisa automáticamente, pero una carga aceptada no proporciona consentimiento o derechos de similitud. Utiliza solo material que estés autorizado a procesar.[2]
Lee un rechazo en lugar de adivinar uno
Un rechazo es un punto de datos sobre una carga en una ruta. Guarda la respuesta POST, la ID de tarea, los campos exactos de modelo y enrutamiento, el error terminal y usage.credits. Esos registros separan la validación del fallo asincrónico y muestran la carga final sin hacer afirmaciones no fundamentadas sobre una capa de moderación interna.
Referencias
- ByteDance Seed. One-take Creation, Flexible Referencing: Introducing Seedance 2.5. Published 31 July 2026, retrieved August 2026 from seed.bytedance.com/en/blog/one-take-creation-flexible-referencing-introducing-seedance-2-5
- reAPI. Seedance 2.5 API — route, request parameters, reference limits,
content_filter, task flow, and refund behavior. Retrieved August 2026 from reapi.ai/docs/seedance-2-5 - reAPI. API errors — validation codes and
80006content-policy handling. Retrieved August 2026 from reapi.ai/docs/api/errors - reAPI. Tasks API — status, settled usage, polling, and output contract. Retrieved August 2026 from reapi.ai/docs/api/tasks
Autor
Categorías
Más publicaciones
Cómo controlar el movimiento de vídeo IA con un storyboard
Tutorial para convertir movimientos complejos en fotogramas ordenados de storyboard, con prompts, generación de pruebas y revisión de movimiento.
Filtros de seguridad de Seedance 2.0: qué bloquean y por qué
El filtrado de seguridad de Seedance 2.0 funciona en varias capas. Aprende qué bloquea cada una y qué límites permanecen siempre en todas las rutas.
Ejecutar un LLM de 70B en 4GB GPU con AirLLM: la guía honesta
Descubre cómo AirLLM transmite capas desde disco para ejecutar un LLM de 70B en 4GB GPU, qué hardware necesitas, cómo intentarlo y por qué es lento.