Sora 2 es el primer modelo de texto a video de disponibilidad general de OpenAI, accesible de forma programática tanto a través de la API oficial de OpenAI como de un conjunto creciente de rutas de agregadores. El modelo de precios es inusual en comparación con los modelos de texto (la facturación es por segundo de video generado en lugar de por token), y las preguntas prácticas que los desarrolladores se hacen antes de integrar son diferentes a las del API de un LLM. ¿Cuánto cuesta realmente un clip? ¿Cuánto tarda la generación? ¿Cuáles son los límites de tasa? ¿Qué cambia cuando accedes a Sora a través de un agregador en lugar de directamente con OpenAI?
Este artículo es la referencia que desearíamos haber tenido cuando empezamos a delimitar nuestras propias funciones de generación de video. La pieza está estructurada para el desarrollador que ya superó “¿Sora es interesante?” y ahora necesita responder “¿cuánto costará, qué implicará integrar, y qué debo saber antes de comprometerme?”
Lectura rápida: Sora 2 (el modelo estándar) cuesta $0.10 por segundo de video generado a 720p. Sora 2 Pro cuesta $0.30 por segundo a 720p o $0.50 por segundo a 1024p. Un clip típico de 10 segundos cuesta $1.00 en el modelo estándar y $5.00 en Pro a HD. El tiempo de generación es asíncrono; espera 30–90 segundos de tiempo de reloj para un clip de 5–10 segundos. El acceso requiere una cuenta de OpenAI de pago con nivel de uso 2 como mínimo.
El estado del acceso a la API de Sora en 2026
Sora 2 se lanzó en la API de OpenAI el 7 de octubre de 2025 y el acceso ha estado disponible de forma continua desde entonces. El identificador del modelo es sora-2 (con un ID de snapshot actual de sora-2-2025-12-08), y la variante de mayor fidelidad es sora-2-pro. Ambos admiten generación de texto a video e imagen a video, con salida de audio sincronizada. A partir del 10 de enero de 2026, se descontinuó el acceso de consumo del nivel gratuito a través del producto ChatGPT, lo que ha concentrado el uso de Sora de nivel desarrollador en suscripciones de pago de ChatGPT o acceso directo a la API.
Hay tres vías para usar Sora de forma programática:
- API directa de OpenAI. La ruta canónica. Facturación por segundo, solo de pago, requiere una recarga mínima de $10 para alcanzar el nivel de uso 2 que desbloquea el acceso al modelo Sora. Se admite tanto SDK como API REST.
- Azure OpenAI. La ruta empresarial de Microsoft, que refleja las tarifas oficiales de OpenAI con la adición de los gastos generales de suscripción de Azure y funciones de cumplimiento empresarial. Misma tarificación por segundo; superficie operativa diferente.
- Agregadores. Servicios que exponen Sora detrás de su propia API unificada. La mayoría de los agregadores trasladan la tarificación por segundo de OpenAI a la paridad; el valor es operativo (una credencial, una factura, el mismo SDK que tu tráfico de modelos de texto). Algunos agregadores ofrecen sus propias estructuras tarifarias, que tratamos más adelante en el artículo.
Precios de Sora 2 por segundo de video
La tarificación de Sora está estructurada por nivel de modelo y resolución de salida, con una tarifa por segundo que se multiplica por la duración del clip para obtener el costo de generación. Verificado en la página oficial de precios de OpenAI a mayo de 2026:
| Modelo | Resolución | Duraciones admitidas | Precio por segundo | Clip de 10 segundos |
|---|---|---|---|---|
| Sora 2 (estándar) | 720p | 4s, 8s, 12s | $0.10 | $1.00 |
| Sora 2 Pro | 720p | 10s, 15s, 25s | $0.30 | $3.00 |
| Sora 2 Pro | 1024p (1792×1024) | 10s, 15s, 25s | $0.50 | $5.00 |
Notas sobre la estructura de precios. La tarificación es por salida, no por entrada; no hay facturación basada en tokens para Sora como sí ocurre con los modelos de texto. El condicionamiento por imagen (pasar una imagen de referencia para anclar la generación) no cambia la tarifa por segundo. Las opciones de duración para cada nivel de modelo son fijas: no puedes solicitar un clip de 7 segundos en el modelo estándar, solo 4, 8 o 12 segundos.
Dos implicaciones prácticas que vale la pena explicitar. Primero: el modelo de precios se parece más a una factura de renderizado de video que a una de LLM. El costo está impulsado por la duración de salida, no por cuán complejo sea tu prompt ni por cuántos tokens contenga. Segundo: la diferencia de costo entre Sora 2 y Sora 2 Pro en HD es de 5x por segundo: un clip de 10 segundos cuesta $1.00 en estándar y $5.00 en Pro a 1024p. Elegir el nivel adecuado para la tarea es la palanca de costo más grande que tienes, y vale la pena ser deliberado sobre qué cargas realmente necesitan la mayor fidelidad de Pro.
Límites de tasa y cuotas
Los límites de tasa de Sora están organizados en torno al sistema de niveles de uso estándar de OpenAI. Los detalles relevantes para Sora específicamente:
- Requisito de nivel mínimo: Nivel 2, alcanzado recargando al menos $10 de crédito de API. El nivel 1 (predeterminado para cuentas nuevas) no incluye acceso al modelo Sora.
- Límites de generación concurrente: Según la documentación de límites de tasa de OpenAI, la generación de video concurrente está restringida por nivel, típicamente un pequeño número de generaciones en curso en niveles bajos, escalando con el nivel de uso. El techo exacto se establece por cuenta y es visible en el panel de OpenAI. Para cargas de alto volumen, planifica acceso de nivel 3 o nivel 4 desde el primer día.
- Solicitudes de cuota: Límites de concurrencia más altos que los techos predeterminados del nivel pueden solicitarse mediante el formulario de aumento de límite de OpenAI. La aprobación es específica de la carga de trabajo y no es instantánea; para lanzamientos de producción con picos de demanda previsibles, solicita el aumento varias semanas antes del lanzamiento.
Vale saber: los límites de tasa en Sora se agrupan de manera diferente a los límites de tasa de los modelos de texto en la misma cuenta. Un equipo que ejecute tráfico intenso de Sora no afecta su presupuesto de tasa disponible para llamadas a GPT-5.5. A la inversa, un gran tráfico de GPT-5.5 no consume el presupuesto de Sora. Planifica ambos como preguntas de capacidad separadas.
Tiempo de generación: qué esperar realmente
Sora es asíncrono por diseño. Envías una solicitud de generación, recibes un ID de trabajo y consultas (o recibes un webhook) para la finalización. El tiempo de reloj entre la solicitud y la finalización depende de la duración y resolución de la salida, la carga actual en la infraestructura de OpenAI y si el trabajo está en cola detrás de otros en tu cuenta.
Expectativas realistas basadas en el comportamiento observado:
| Salida | Tiempo de reloj típico | Notas |
|---|---|---|
| Sora 2 estándar, 4s @ 720p | 20–45 segundos | Ruta más rápida; bueno para iteración |
| Sora 2 estándar, 8s @ 720p | 40–90 segundos | Duración de producción más común |
| Sora 2 estándar, 12s @ 720p | 60–120 segundos | Contenido social de formato más largo |
| Sora 2 Pro, 10s @ 720p | 60–150 segundos | Calidad premium; ~3x el costo del estándar |
| Sora 2 Pro, 15s @ 1024p | 120–240 segundos | Full HD, colas más largas observadas en horas pico |
| Sora 2 Pro, 25s @ 1024p | 200–360 segundos | Duración máxima; el precio escala linealmente |
Dos consecuencias operativas:
- Los presupuestos de latencia de cara al usuario necesitan replantearse. Si tu producto espera que la generación de video se sienta sensible a una acción del usuario, el rango de 30–90 segundos para clips cortos significa que necesitas una UX que gestione la espera: indicadores de progreso, trabajo en paralelo que el usuario pueda realizar mientras se genera el video, o pre-generación para escenarios previsibles. Tratar Sora como una llamada de API síncrona es el error de arquitectura más común que cometen los equipos.
- Sondeo versus webhooks importa. El sondeo ingenuo (un bucle ajustado golpeando el endpoint de estado) malgasta tanto tu presupuesto de límite de tasa como el cómputo del modelo. Usa retroceso exponencial con aleatoriedad (jitter), o configura callbacks de webhook si tu entorno los admite. El patrón de sondeo que funciona bien en producción es sondear a intervalos de 10 segundos durante el primer minuto, luego intervalos de 30 segundos a partir de ahí, con un tiempo de espera estricto en el límite superior esperado del modelo para la duración solicitada.
Parámetros admitidos y estructura del prompt
La superficie de la API de Sora es intencionalmente simple en comparación con modelos de generación de imagen como DALL-E 3. Hay menos diales que girar, pero los diales que existen importan. Los parámetros relevantes:
- model: sora-2 o sora-2-pro. La elección determina tanto la tarificación como las opciones de duración/resolución disponibles según la tabla de precios anterior.
- prompt: Texto libre que describe la escena. Sora maneja dirección cinematográfica (ángulos de cámara, movimiento, iluminación), acciones de personajes y detalles del entorno. El modelo es sensible a la estructura del prompt: empezar estableciendo la escena, luego la acción, y luego la dirección técnica produce resultados más fiables que un único párrafo denso.
- image: Imagen de referencia opcional para generación de imagen a video. La referencia actúa como ancla del primer fotograma; el modelo genera movimiento hacia afuera desde ese punto de partida. Útil para demostraciones de producto, continuidad de personajes y cualquier escenario donde la apariencia estática del sujeto no sea negociable.
- duration: Duración en segundos. Limitada a las opciones discretas para el modelo elegido (4/8/12 para sora-2, 10/15/25 para sora-2-pro). El costo escala linealmente con la duración.
- size: Resolución. 720x1280 (vertical) o 1280x720 (horizontal) en el modelo estándar; añade 1024x1792 / 1792x1024 en Pro. La relación de aspecto es implícita en la selección de size.
Ausencias notables. Sora no expone actualmente control de semilla a través de la API pública (por lo que la reproducibilidad entre ejecuciones no está garantizada), ni expone controles de estilo individuales como sí hacen Midjourney u otros modelos de imagen. El modelo es prescriptivo; la ingeniería de prompts es la palanca principal, no el ajuste de parámetros.
Un ejemplo simple de una solicitud de generación con Sora 2, usando el SDK de Python de OpenAI:
| from openai import OpenAIimport timeclient = OpenAI(api_key="YOUR_API_KEY")# Crear el trabajo de generación de videojuegos = client.videos.create(model="sora-2",prompt=("Una toma gran angular de una montaña nevada al amanecer. ""La cámara se desplaza lentamente hacia la izquierda cuando la primera luz alcanza la cumbre. ""Cinematográfico, hora dorada, iluminación de calidad 4K."),size="1280x720",duration=8,)# Consultar hasta la finalizaciónwhile True:job = client.videos.retrieve(job.id)if job.status == "completed":video_url = job.output[0].urlbreakelif job.status == "failed":raise RuntimeError(f"La generación falló: {job.error}")print(f"Estado actual: {job.status}")time.sleep(10)print(f"Video listo: {video_url}") |
|---|
Ejemplos de costos detallados
La tarificación por segundo hace que el costo sea predecible, pero solo una vez que tengas claro el perfil de tu carga. Tres escenarios representativos:
Escenario 1: Una demostración corta de producto para una landing de SaaS
Un clip de 5 segundos mostrando la IU del producto en acción, generado una vez y usado como video principal en el sitio de marketing. Esperas iterar 5–10 veces para obtener un clip con el que estés satisfecho antes de publicar.
Costo en Sora 2 estándar a 720p: 5s × $0.10 = $0.50 por generación. Con 8 iteraciones para llegar al corte final: $4.00. Costo en Sora 2 Pro a 1024p para la versión final publicada: 5s × $0.50 = $2.50 (una sola toma). Costo total del proyecto: aproximadamente $6.50 por las ejecuciones de iteración más la final en HD.
Escenario 2: Un lote de 50 clips para una campaña de marketing
50 clips de producto únicos de 8 segundos, cada uno basado en una descripción de función diferente, todos en Sora 2 estándar a 720p. Sin presupuesto de iteración; aceptas la primera generación.
Costo: 50 × 8s × $0.10 = $40.00. Añade un 30% de presupuesto de iteración para los clips que no salgan a la primera (50 × 0.30 = 15 reintentos × 8s × $0.10 = $12). Total: aproximadamente $52.00 para la campaña.
Escenario 3: Una función de video generado por el usuario en un producto de consumo
Los usuarios en tu app generan clips de 6 segundos bajo demanda, en Sora 2 estándar a 720p. Uso promedio: 1,000 clips por día. Cobras a los usuarios $0.50 por generación y aceptas el diferencial de costo como margen unitario.
Costo por clip de usuario: 6s × $0.10 = $0.60. Con un precio al usuario de $0.50, la carga pierde dinero en el nivel estándar: cada generación cuesta $0.10 más de lo que paga el usuario. El nivel estándar 720p requiere un precio al usuario de al menos $0.65 para cubrir costos antes de gastos de infraestructura. A 30,000 clips por mes: factura mensual de Sora de $18,000. Este es el tipo de verificación de economía unitaria que vale la pena realizar antes de lanzar cualquier función de video de cara al usuario.
La conclusión en los tres escenarios: la generación de video es realmente asequible para cargas de marketing y contenidos puntuales, donde el recuento de iteraciones está acotado y lo que importa es el costo por activo final. Es significativamente más desafiante para funciones de cara al usuario a escala, donde el costo por generación debe superar el precio pagado por el usuario más la sobrecarga del producto. Sé explícito sobre qué carga estás presupuestando antes de comprometerte.
Acceso directo a OpenAI frente a acceso mediante agregadores
Con Sora disponible a través de múltiples rutas, la pregunta práctica para la mayoría de equipos es contra cuál integrarse. La respuesta honesta depende del resto de tu stack.
Lo que es igual
La calidad de salida, el tiempo de generación a nivel de modelo, los parámetros admitidos y la tarificación por segundo suelen ser idénticos independientemente de la ruta, ya que la mayoría de los agregadores trasladan los precios de OpenAI a la paridad, y el modelo en sí es el mismo. Si eliges una ruta únicamente por calidad de salida, la elección es equivalente.
Lo que es diferente
- Superficie de facturación. El acceso directo a OpenAI factura a través de tu cuenta de OpenAI; los agregadores facturan mediante su propio sistema de créditos o suscripciones. Para equipos que ya gestionan facturación de OpenAI para uso de modelos de texto, la ruta directa no añade nada nuevo. Para equipos que ejecutan cargas multi-proveedor (LLMs de Anthropic, modelos de imagen de Black Forest Labs, video de Sora), un agregador consolida todo en una sola factura.
- Observabilidad. El panel de OpenAI muestra claramente el uso de Sora a nivel de solicitud. Los paneles de los agregadores varían en qué tan bien manejan cargas de generación de video específicamente; algunos tienen observabilidad de video diseñada ad hoc; otros tratan el video como una llamada de API genérica. Vale la pena verificarlo antes de comprometerse si la observabilidad es una prioridad.
- Agrupación de límites de tasa. En OpenAI directo, tus límites de tasa de Sora están vinculados a tu cuenta y nivel de OpenAI. En un agregador, los límites se agrupan entre la base de clientes del agregador en algunos casos, o se asignan por cliente en otros. Para cargas de producción de alto volumen, pregunta al agregador cómo manejan la asignación de límites de tasa antes de integrar.
- Postura geográfica y de cumplimiento. OpenAI directo se procesa a través de la infraestructura de OpenAI con las opciones de residencia de datos que proporciona OpenAI. Algunos agregadores tienen sede en jurisdicciones donde las reglas de residencia de datos difieren; otros enrutan las solicitudes a través de la infraestructura de OpenAI en EE. UU. de todos modos. Para cargas reguladas, esto es decisivo, y es el tipo de asunto que vale pedir por escrito al equipo de ventas del agregador.
Cómo encaja CometAPI
CometAPI expone Sora 2 y Sora 2 Pro junto con más de 500 modelos detrás de un único endpoint compatible con OpenAI, con una credencial y facturación unificada. Los precios de Sora a través de CometAPI siguen las tarifas por segundo de OpenAI; el valor operativo es consolidar el uso de Sora con el resto de tu tráfico de modelos en una sola factura. Para equipos que ejecutan una carga mixta (modelos de texto de múltiples proveedores, generación de imágenes y video de Sora), este es el argumento central. Para equipos que usan solo Sora y uno o dos modelos de texto, el ahorro operativo es menor y el acceso directo a OpenAI es una elección defendible.
Consideraciones para producción
Algunos patrones que vale la pena tener bien implementados antes de que Sora toque tráfico de producción:
- Gestión asíncrona del ciclo de vida del trabajo. Trata cada generación de Sora como un trabajo de larga duración, no como una solicitud. Persiste el ID del trabajo inmediatamente al crearlo; sobrevive a un reinicio del servidor pudiendo reanudar el sondeo de trabajos en curso; maneja el caso en que el trabajo se complete mientras tu worker está offline. Esto es higiene estándar de sistemas distribuidos, pero a menudo se omite al principio porque Sora es la primera API asíncrona que el equipo integra.
- Webhook como preferencia. Si la plataforma admite webhooks para eventos de finalización (la API de OpenAI los admite), úsalos. Los webhooks eliminan la necesidad de sondeo y reducen tanto tu presión de límites de tasa como el cómputo desperdiciado de chequeos de estado frecuentes. El sondeo es el fallback para entornos que no pueden exponer un endpoint de webhook.
- Modos de falla que cuestan dinero. OpenAI no factura las generaciones fallidas, pero las finalizaciones parciales y las solicitudes reintentadas que tienen éxito en el segundo intento sí incurren en costo. En producción, registra el costo de cada reintento y alerta si tu tasa de reintentos excede lo esperado, ya que eso suele ser una señal de un problema de política de contenido con los prompts que envías, lo cual es más barato solucionar en la capa de prompt que absorber en la factura.
- Política de contenido y despliegue en producción. Sora está limitado por las políticas de uso de OpenAI, que restringen ciertas categorías de contenido. Para despliegues de producción (especialmente aquellos de cara al usuario donde el prompt está parcialmente bajo control del usuario), revisa la documentación oficial de política de contenido de OpenAI y diseña mecanismos de protección aguas arriba en consecuencia. Enlazar a la política de OpenAI es la referencia correcta; esa documentación es la fuente de la verdad y cambia con más frecuencia de lo que este artículo lo hará.
Qué construir primero
La lectura honesta sobre qué cargas de Sora están listas para producción hoy, cuáles están en el límite y cuáles son prematuras:
Listo para producción hoy
Cargas de marketing y contenido creativo donde la iteración está acotada y el costo por activo final es la métrica correcta. Videos de demostración de producto, contenido para campañas en redes sociales, videos hero para landing pages, material de formación interna. La economía funciona, los modos de falla están bien entendidos y el perfil de latencia (30–90 segundos para clips cortos) es aceptable cuando el humano en el loop es el equipo de contenido en lugar del usuario final.
En el límite
Funciones de generación de video de cara al usuario donde el costo por clip debe superar el precio pagado por el usuario. Es viable pero requiere economía unitaria cuidadosa: acota la duración que los usuarios pueden solicitar, usa Sora 2 estándar a 720p como valor predeterminado, cobra un precio que tenga margen sobre el costo por clip. La ola de principios de 2026 de apps de generación de video para consumidores está mayoritariamente en esta categoría, y las que tienen economía sostenible han sido deliberadas al limitar lo que los usuarios pueden generar.
Prematuro
Video de formato largo a escala (cualquier cosa por encima de 25 segundos, dado que ese es el techo de duración actual de Sora), escenarios de alto volumen en tiempo real donde la latencia de reloj importa más que los dólares, y aplicaciones que esperan control a nivel de fotograma o reproducibilidad basada en semilla. Estas son cargas para reevaluar cuando la superficie de capacidades de Sora se expanda, no para forzar hoy.
El marco: Sora 2 está realmente listo para producción en cargas de contenido con un humano en el loop. Es viable para funciones de cara al usuario con economía unitaria deliberada. Es prematuro para video de formato largo y para casos que requieren parámetros que Sora aún no expone. Construye para lo que está listo hoy; sigue de cerca lo que aún no lo está.
Probándolo en tu carga: Todas las variantes de Sora 2 y Sora 2 Pro están disponibles en CometAPI junto con los modelos de texto que ya puedes estar usando. El crédito de prueba gratuito te permite generar algunos clips a precios estándar sin ninguna configuración más allá de apuntar tu cliente compatible con OpenAI existente al endpoint de CometAPI.