Sora 2 è il primo modello testo‑in‑video generalmente disponibile di OpenAI, accessibile in modo programmatico sia tramite l’API ufficiale di OpenAI sia tramite un numero crescente di route di aggregatori. Il modello di pricing è insolito rispetto ai modelli di testo (la fatturazione è per secondo di video generato anziché per token) e le domande pratiche che gli sviluppatori pongono prima di integrare sono diverse rispetto a quelle per un’API LLM. Quanto costa davvero una clip? Quanto tempo richiede la generazione? Quali sono i rate limit? Cosa cambia se si accede a Sora tramite un aggregatore invece che direttamente da OpenAI?
Questo articolo è il riferimento che avremmo voluto avere quando abbiamo iniziato a definire le nostre funzionalità di generazione video. Il pezzo è strutturato per lo sviluppatore che ha superato la fase “Sora è interessante?” e deve ora rispondere a “quanto costerà, cosa comporta integrarlo e cosa devo sapere prima di impegnarmi?”.
Lettura rapida: Sora 2 (il modello standard) costa $0.10 al secondo di video generato a 720p. Sora 2 Pro costa $0.30 al secondo a 720p o $0.50 al secondo a 1024p. Una clip tipica da 10 secondi costa $1.00 sul modello standard e $5.00 su Pro in HD. Il tempo di generazione è asincrono; aspettati 30–90 secondi di tempo effettivo per una clip da 5–10 secondi. L’accesso richiede un account OpenAI a pagamento con livello di utilizzo minimo 2.
Lo stato dell’accesso all’API Sora nel 2026
Sora 2 è stato lanciato nell’API di OpenAI il 7 ottobre 2025 e l’accesso è stato disponibile in modo continuativo da allora. L’identificatore del modello è sora-2 (con un ID snapshot corrente sora-2-2025-12-08) e la variante a fedeltà più alta è sora-2-pro. Entrambi supportano la generazione testo‑in‑video e immagine‑in‑video, con uscita audio sincronizzata. Dal 10 gennaio 2026, l’accesso consumer al livello gratuito tramite il prodotto ChatGPT è stato interrotto, concentrando l’uso di Sora a livello developer su abbonamenti ChatGPT a pagamento o accesso diretto all’API.
Esistono tre modalità per usare Sora in modo programmatico:
- API diretta OpenAI. Il percorso canonico. Fatturazione per secondo, solo a pagamento, richiede una ricarica minima di $10 per raggiungere il livello di utilizzo 2 che sblocca l’accesso al modello Sora. Sia SDK sia REST API sono supportati.
- Azure OpenAI. Il percorso enterprise di Microsoft, che rispecchia le tariffe ufficiali di OpenAI con l’aggiunta dei costi dell’abbonamento Azure e funzionalità di conformità aziendale. Stessa tariffazione per secondo; superficie operativa diversa.
- Aggregatori. Servizi che espongono Sora dietro una propria API unificata. La maggior parte degli aggregatori trasferisce la tariffazione per secondo di OpenAI alla pari; il valore è operativo (un’unica credenziale, una sola fattura, lo stesso SDK del traffico dei modelli di testo). Alcuni aggregatori offrono propri schemi tariffari, che trattiamo più avanti nell’articolo.
Prezzi di Sora 2 per secondo di video
I prezzi di Sora sono strutturati per livello di modello e risoluzione di output, con una tariffa per secondo che moltiplicata per la durata della clip dà il costo di generazione. Verificato sulla pagina ufficiale dei prezzi di OpenAI a maggio 2026:
| Modello | Risoluzione | Durate supportate | Prezzo per secondo | Clip da 10 secondi |
|---|---|---|---|---|
| Sora 2 (standard) | 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 |
Note sulla struttura dei prezzi. La tariffazione è in base all’output, non all’input; non esiste fatturazione basata sui token di input per Sora come per i modelli di testo. Il conditioning con immagine (passare un’immagine di riferimento per ancorare la generazione) non modifica la tariffa per secondo. Le opzioni di durata per ciascun livello di modello sono fisse: non puoi richiedere una clip da 7 secondi sul modello standard, solo 4, 8 o 12 secondi.
Due implicazioni pratiche che vale la pena esplicitare. Primo: il modello di prezzo è più vicino a un costo di render video che a quello di un LLM. Il costo è guidato dalla durata dell’output, non da quanto è complesso il prompt o da quanti token contiene. Secondo: la differenza di costo tra Sora 2 e Sora 2 Pro in HD è 5x per secondo: una clip da 10 secondi costa $1.00 sullo standard e $5.00 su Pro a 1024p. Scegliere il livello giusto per l’attività è la leva di costo più importante che hai, ed è utile essere deliberati su quali carichi richiedano davvero la maggiore fedeltà di Pro.
Rate limit e quote
I rate limit di Sora sono organizzati attorno al sistema di livelli di utilizzo standard di OpenAI. I dettagli salienti specifici per Sora:
- Requisito minimo di livello: Livello 2, raggiunto ricaricando almeno $10 di credito API. Il livello 1 (predefinito per i nuovi account) non include l’accesso ai modelli Sora.
- Limiti di generazione concorrente: Secondo la documentazione sui rate limit di OpenAI, la generazione video concorrente è limitata per livello, tipicamente a un piccolo numero di generazioni in corso ai livelli inferiori, con scalabilità all’aumentare del livello. Il tetto esatto è impostato per account ed è visibile nella dashboard di OpenAI. Per carichi ad alto volume, pianifica l’accesso di livello 3 o 4 fin dal primo giorno.
- Richieste di quota: Limiti di concorrenza più elevati oltre i tetti predefiniti del livello possono essere richiesti tramite il modulo per l’aumento dei rate limit di OpenAI. L’approvazione è specifica per il carico e non è immediata; per lanci in produzione con picchi di domanda prevedibili, richiedi l’aumento diverse settimane prima del lancio.
Vale la pena saperlo: i rate limit su Sora sono gestiti separatamente rispetto ai rate limit dei modelli di testo sullo stesso account. Un team che esegue traffico Sora intenso non influisce sul budget di rate disponibile per le chiamate a GPT-5.5. Viceversa, un grande traffico GPT-5.5 non consuma il budget di Sora. Considerali come due capacità separate da pianificare.
Tempi di generazione: cosa aspettarsi davvero
Sora è asincrono per progettazione. Invi una richiesta di generazione, ricevi un ID job e fai polling (o ricevi un webhook) per il completamento. Il tempo effettivo tra richiesta e completamento dipende dalla durata e dalla risoluzione dell’output, dal carico corrente sull’infrastruttura OpenAI e dal fatto che il job sia in coda dietro altri sul tuo account.
Aspettative realistiche basate su comportamenti osservati:
| Output | Tempo effettivo tipico | Note |
|---|---|---|
| Sora 2 standard, 4s @ 720p | 20–45 secondi | Percorso più veloce; ideale per iterazione |
| Sora 2 standard, 8s @ 720p | 40–90 secondi | Durata più comune in produzione |
| Sora 2 standard, 12s @ 720p | 60–120 secondi | Contenuti social più lunghi |
| Sora 2 Pro, 10s @ 720p | 60–150 secondi | Qualità premium; costo ~3x rispetto allo standard |
| Sora 2 Pro, 15s @ 1024p | 120–240 secondi | Full HD, code più lunghe osservate nei picchi |
| Sora 2 Pro, 25s @ 1024p | 200–360 secondi | Durata massima; prezzo scala linearmente |
Due conseguenze operative:
- I budget di latenza lato utente vanno ripensati. Se il tuo prodotto si aspetta che la generazione video sembri reattiva a un’azione dell’utente, l’intervallo 30–90 secondi per clip brevi significa che ti serve una UX che gestisca l’attesa: indicatori di progresso, lavoro parallelo che l’utente può fare mentre il video si genera, o pre‑generazione per scenari prevedibili. Trattare Sora come una chiamata API sincrona è l’errore architetturale più comune.
- Polling contro webhooks conta. Un polling ingenuo (loop serrato sullo status endpoint) spreca sia il tuo budget di rate limit sia il compute del modello. Usa backoff esponenziale con jitter, o imposta callback webhook se il tuo ambiente lo supporta. Il pattern di polling che funziona bene in produzione è: polling a intervalli di 10 secondi per il primo minuto, poi intervalli di 30 secondi oltre, con un timeout rigoroso al limite superiore atteso del modello per la durata richiesta.
Parametri supportati e struttura del prompt
La superficie API di Sora è intenzionalmente semplice rispetto a modelli di generazione immagini come DALL‑E 3. Ci sono meno manopole da girare, ma quelle che esistono contano. I parametri salienti:
- model: sora-2 o sora-2-pro. La scelta determina sia il prezzo sia le opzioni disponibili di durata/risoluzione come mostrato nella tabella prezzi sopra.
- prompt: Testo libero che descrive la scena. Sora gestisce regia cinematografica (angolazioni, movimento, illuminazione), azioni dei personaggi e dettagli ambientali. Il modello è sensibile alla struttura del prompt: iniziare con l’impostazione della scena, poi l’azione, poi le indicazioni tecniche produce risultati più affidabili rispetto a un singolo paragrafo denso.
- image: Immagine di riferimento opzionale per la generazione immagine‑in‑video. La reference funge da ancora del primo frame; il modello genera il movimento a partire da quel punto. Utile per demo di prodotto, continuità dei personaggi e qualsiasi scenario in cui l’aspetto statico del soggetto è non negoziabile.
- duration: Durata in secondi. Vincolata alle opzioni discrete per il modello scelto (4/8/12 per sora-2, 10/15/25 per sora-2-pro). Il costo scala linearmente con la durata.
- size: Risoluzione. 720x1280 (verticale) o 1280x720 (orizzontale) sul modello standard; su Pro si aggiungono 1024x1792 / 1792x1024. Il rapporto d’aspetto è implicito nella scelta della size.
Assenze degne di nota. Sora attualmente non espone il controllo del seed tramite l’API pubblica (quindi la riproducibilità tra esecuzioni non è garantita), né espone controlli di stile individuali come fanno Midjourney o altri modelli di immagini. Il modello è opinato; la leva principale è il prompt engineering, non la regolazione dei parametri.
Un semplice esempio di richiesta di generazione Sora 2 con l’SDK Python di OpenAI:
| from openai import OpenAIimport timeclient = OpenAI(api_key="YOUR_API_KEY")# Crea il job di generazione videojob = client.videos.create(model="sora-2",prompt=("Un'inquadratura grandangolare di una montagna innevata all'alba. ""La camera scorre lentamente verso sinistra mentre la prima luce colpisce la vetta. ""Cinematografico, golden hour, illuminazione di qualità 4K."),size="1280x720",duration=8,)# Attendi il completamentowhile True:job = client.videos.retrieve(job.id)if job.status == "completed":video_url = job.output[0].urlbreakelif job.status == "failed":raise RuntimeError(f"Generazione non riuscita: {job.error}")print(f"Stato corrente: {job.status}")time.sleep(10)print(f"Video pronto: {video_url}") |
|---|
Esempi di costo calcolati
La tariffazione per secondo rende i costi prevedibili, ma solo quando è chiaro il profilo del tuo carico. Tre scenari rappresentativi:
Scenario 1: Una breve demo di prodotto per la landing page di un SaaS
Una clip da 5 secondi che mostra l’UI del prodotto in azione, generata una volta e usata come video hero sul sito marketing. Ti aspetti di iterare 5–10 volte per ottenere una clip soddisfacente prima della pubblicazione.
Costo su Sora 2 standard a 720p: 5s × $0.10 = $0.50 per generazione. Con 8 iterazioni per arrivare al taglio finale: $4.00. Costo su Sora 2 Pro a 1024p per la versione finale pubblicata: 5s × $0.50 = $2.50 (singolo take). Costo totale del progetto: circa $6.50 per le iterazioni più la finale in HD.
Scenario 2: Un batch di 50 clip per una campagna marketing
50 clip uniche da 8 secondi, ciascuna basata su una diversa descrizione di funzionalità, tutte su Sora 2 standard a 720p. Nessun budget di iterazione; accetti la prima generazione.
Costo: 50 × 8s × $0.10 = $40.00. Aggiungi un budget di iterazione del 30% per le clip che non riescono al primo colpo (50 × 0.30 = 15 retry × 8s × $0.10 = $12). Totale: circa $52.00 per la campagna.
Scenario 3: Una funzionalità di video generato dagli utenti in un prodotto consumer
Gli utenti della tua app generano clip da 6 secondi on‑demand, su Sora 2 standard a 720p. Utilizzo medio: 1.000 clip al giorno. Addebiti agli utenti $0.50 per generazione e accetti il differenziale di costo come margine unitario.
Costo per clip utente: 6s × $0.10 = $0.60. Con un prezzo utente di $0.50, il carico è in perdita al livello standard: ogni generazione costa $0.10 in più rispetto a quanto l’utente paga. Il livello standard 720p richiede un prezzo utente di almeno $0.65 per il pareggio prima dell’overhead infrastrutturale. A 30.000 clip al mese: fattura mensile Sora di $18,000. Questo è il tipo di verifica dell’economia unitaria che vale la pena fare prima di lanciare qualsiasi funzionalità video rivolta agli utenti.
La conclusione sui tre scenari: la generazione video è davvero conveniente per i carichi marketing e i contenuti una tantum, dove il numero di iterazioni è limitato e conta il costo per asset finale. È sensibilmente più impegnativa per funzionalità rivolte agli utenti su larga scala, dove il costo per generazione deve coprire il prezzo pagato dall’utente più l’overhead di prodotto. Sii esplicito su quale carico stai prezzando prima di impegnarti.
Accesso diretto a OpenAI vs accesso tramite aggregatore
Con Sora disponibile attraverso più percorsi, la domanda pratica per la maggior parte dei team è quale integrare. La risposta onesta dipende dal resto del tuo stack.
Cosa non cambia
Qualità dell’output, tempi di generazione a livello di modello, parametri supportati e tariffazione per secondo sono tipicamente identici indipendentemente dal percorso, poiché la maggior parte degli aggregatori trasferisce i prezzi di OpenAI alla pari e il modello è lo stesso. Se scegli un percorso solo sulla qualità dell’output, la scelta è indifferente.
Cosa cambia
- Superficie di fatturazione. L’accesso diretto a OpenAI fattura tramite il tuo account OpenAI; gli aggregatori fatturano tramite il proprio sistema di crediti o abbonamenti. Per i team che già gestiscono la fatturazione OpenAI per l’uso dei modelli di testo, la via diretta non aggiunge nulla di nuovo. Per i team che eseguono carichi multi‑provider (LLM da Anthropic, modelli immagine da Black Forest Labs, video da Sora), un aggregatore consolida tutto su un’unica fattura.
- Osservabilità. La dashboard di OpenAI presenta chiaramente l’utilizzo Sora a livello di richiesta. Le dashboard degli aggregatori variano su quanto bene gestiscono specificamente i carichi di generazione video; alcune hanno osservabilità video dedicata; altre trattano il video come una chiamata API generica. Vale la pena verificare prima di impegnarsi se l’osservabilità è una priorità.
- Pooling dei rate limit. Su OpenAI diretto, i tuoi rate limit Sora sono legati al tuo account e livello. Su un aggregatore, i limiti sono in alcuni casi condivisi tra la base clienti dell’aggregatore, o assegnati per cliente in altri. Per carichi di produzione ad alto volume, chiedi all’aggregatore come gestisce l’allocazione dei rate limit prima di integrare.
- Postura geografica e di conformità. OpenAI diretto è elaborato tramite l’infrastruttura di OpenAI con le opzioni di residenza dati che OpenAI fornisce. Alcuni aggregatori hanno sede in giurisdizioni con regole di residenza dati diverse; altri instradano le richieste tramite l’infrastruttura statunitense di OpenAI comunque. Per carichi regolamentati, questo è decisivo ed è il tipo di cosa da chiedere per iscritto al team commerciale dell’aggregatore.
Come si inserisce CometAPI
CometAPI espone Sora 2 e Sora 2 Pro insieme a oltre 500 modelli dietro un singolo endpoint compatibile con OpenAI, con un’unica credenziale e fatturazione unificata. I prezzi su Sora tramite CometAPI seguono le tariffe per secondo di OpenAI; il valore operativo è consolidare l’uso di Sora con il resto del tuo traffico di modelli su una sola fattura. Per i team con carichi misti (modelli di testo da più provider, generazione di immagini e video Sora), questo è l’argomento principale. Per i team che usano solo Sora e solo uno o due modelli di testo, il risparmio operativo è minore e l’accesso diretto a OpenAI è una scelta difendibile.
Considerazioni per la produzione
Alcuni pattern che vale la pena impostare correttamente prima che Sora tocchi traffico di produzione:
- Gestione asincrona del ciclo di vita dei job. Tratta ogni generazione Sora come un job long‑running, non come una richiesta. Conserva l’ID del job immediatamente alla creazione; sopravvivi al riavvio del server potendo riprendere il polling dei job in corso; gestisci il caso in cui il job si completi mentre il tuo worker è offline. È igiene standard dei sistemi distribuiti ma spesso trascurata all’inizio perché Sora è la prima API asincrona che il team integra.
- Fallback ai webhook. Se la piattaforma supporta webhook per gli eventi di completamento (l’API OpenAI lo fa), usali. I webhook eliminano la necessità di polling e riducono sia la pressione sui rate limit sia il compute sprecato dei controlli frequenti di stato. Il polling è il fallback per ambienti che non possono esporre un endpoint webhook.
- Modalità di failure che costano denaro. OpenAI non fattura le generazioni fallite, ma i completamenti parziali e le richieste ritentate che riescono al secondo tentativo comportano costi. In produzione, registra il costo di ogni retry e allerta se il tasso di retry supera le aspettative, poiché di solito è un segnale di un problema di policy dei contenuti nei prompt che stai inviando, che è più economico risolvere a livello di prompt che assorbire in fattura.
- Policy dei contenuti e deploy in produzione. Sora è vincolato dalle policy d’uso di OpenAI, che limitano alcune categorie di contenuti. Per i deploy in produzione (soprattutto quelli rivolti agli utenti dove il prompt è in parte sotto il controllo dell’utente), consulta la documentazione ufficiale della policy di OpenAI e progetta di conseguenza i guardrail a monte. Collegarsi alla policy di OpenAI è il riferimento giusto; quella documentazione è la fonte di verità e cambia più spesso di questo articolo.
Cosa costruire per primo
La lettura onesta su quali carichi Sora sono pronti per la produzione oggi, quali sono al limite e quali sono prematuri:
Pronto per la produzione oggi
Carichi di marketing e contenuti creativi in cui l’iterazione è limitata e il costo per asset finale è la metrica giusta. Video demo di prodotto, contenuti per campagne social, video hero per landing page, materiale formativo interno. L’economia funziona, le modalità di failure sono ben comprese e la latenza (30–90 secondi per clip brevi) è accettabile quando la persona nel loop è il team contenuti piuttosto che l’utente finale.
Al limite
Funzionalità di generazione video rivolte agli utenti in cui il costo per clip deve superare il prezzo pagato dall’utente. È fattibile ma richiede un’attenta economia unitaria: limita la durata che gli utenti possono richiedere, usa Sora 2 standard a 720p come impostazione predefinita, applica un prezzo che abbia margine sul costo per clip. La prima ondata del 2026 di app consumer di generazione video rientra per lo più in questa categoria, e quelle con un’economia sostenibile sono state deliberate nel limitare ciò che gli utenti possono generare.
Prematuro
Video long‑form su larga scala (qualsiasi cosa oltre i 25 secondi, dato l’attuale tetto di durata di Sora), scenari in tempo reale ad alto volume in cui la latenza effettiva conta più dei dollari e applicazioni che si aspettano controllo a livello di frame o riproducibilità basata su seed. Sono carichi da rivalutare quando la superficie di capacità di Sora si espanderà, non da forzare oggi.
L’inquadramento: Sora 2 è davvero pronto per la produzione per carichi di contenuti con una persona nel loop. È fattibile per funzionalità rivolte agli utenti con un’economia unitaria deliberata. È prematuro per il video long‑form e per casi d’uso che richiedono parametri che Sora non espone ancora. Costruisci per ciò che è pronto oggi; tieni monitorati quelli che non lo sono ancora.
Provarlo sul tuo carico di lavoro: Tutte le varianti Sora 2 e Sora 2 Pro sono disponibili su CometAPI insieme ai modelli di testo che potresti già utilizzare. Il credito di prova gratuito ti consente di generare alcune clip ai prezzi standard senza alcuna configurazione oltre a puntare il tuo client compatibile con OpenAI all’endpoint CometAPI.