Sora 2 è il primo modello di text-to-video generalmente disponibile di OpenAI, accessibile in modo programmabile sia tramite l’API ufficiale di OpenAI sia tramite un numero crescente di route di aggregatori. Il modello di prezzo è insolito rispetto ai modelli di testo (la fatturazione è al secondo di video generato, non per token) e le domande pratiche che gli sviluppatori si pongono prima di integrare sono diverse rispetto a quelle per un’API LLM. Quanto costa davvero un clip? Quanto tempo richiede la generazione? Quali sono i rate limit? Cosa cambia quando si accede a Sora tramite un aggregatore anziché direttamente da OpenAI?
Questo articolo è il riferimento che avremmo voluto esistesse quando abbiamo iniziato a definire le nostre funzionalità di generazione video. Il pezzo è strutturato per lo sviluppatore che è oltre il “Sora è interessante?” e ora deve rispondere a “quanto costa, cosa serve per integrare 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. Un clip tipico da 10 secondi costa $1.00 sul modello standard e $5.00 su Pro in HD. La generazione è asincrona; aspettati 30–90 secondi di tempo reale per un clip da 5–10 secondi. L’accesso richiede un account OpenAI a pagamento con tier di utilizzo minimo 2.
Lo stato dell’accesso API a 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 di sora-2-2025-12-08) e la variante a fedeltà superiore è sora-2-pro. Entrambi supportano la generazione text-to-video e image-to-video, con output audio sincronizzato. A partire dal 10 gennaio 2026, l’accesso consumer al livello gratuito tramite il prodotto ChatGPT è stato interrotto, il che ha concentrato l’uso di Sora di livello sviluppatore su abbonamenti ChatGPT a pagamento o accesso diretto all’API.
Esistono tre modalità per usare Sora in modo programmabile:
- API OpenAI diretta. La route canonica. Fatturazione al secondo, solo a pagamento, richiede una ricarica minima di $10 per raggiungere il tier 2 che sblocca l’accesso ai modelli Sora. Sia SDK che REST API sono supportati.
- Azure OpenAI. La route enterprise di Microsoft, che rispecchia le tariffe ufficiali di OpenAI con l’aggiunta della sovrastruttura dell’abbonamento Azure e funzionalità di compliance enterprise. Stesso prezzo al secondo; superficie operativa diversa.
- Aggregatori. Servizi che espongono Sora dietro una propria API unificata. La maggior parte degli aggregatori trasferisce i prezzi al secondo di OpenAI alla pari; il valore è operativo (una credenziale, una fattura, lo stesso SDK del tuo traffico verso i modelli di testo). Alcuni aggregatori offrono proprie strutture tariffarie, che discutiamo più avanti nell’articolo.
Prezzi di Sora 2 per secondo di video
La tariffazione di Sora è strutturata per livello di modello e risoluzione di output, con una tariffa al secondo che viene moltiplicata per la durata del clip per ottenere il costo di generazione. Verificato dalla pagina ufficiale dei prezzi di OpenAI a maggio 2026:
| Modello | Risoluzione | Durate supportate | Prezzo al 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 tariffaria. La tariffazione è per output, non per input; non esiste fatturazione a token di input per Sora come avviene per i modelli di testo. Il conditioning con immagine (passare un’immagine di riferimento per ancorare la generazione) non modifica la tariffa al secondo. Le opzioni di durata per ciascun livello di modello sono fisse: non puoi richiedere un 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 una fattura di rendering video che a una di LLM. Il costo è determinato dalla durata dell’output, non da quanto è complesso il prompt o quanti token contiene. Secondo: la differenza di costo tra Sora 2 e Sora 2 Pro in HD è 5x al secondo: un clip da 10 secondi costa $1.00 sul modello standard e $5.00 su Pro a 1024p. Scegliere il tier giusto per il task è la leva di costo più importante che hai, ed è opportuno essere rigorosi su quali carichi richiedono davvero la maggiore fedeltà di Pro.
Rate limit e quote
I rate limit di Sora sono organizzati attorno al sistema di usage tier standard di OpenAI. I dettagli salienti specifici per Sora:
- Requisito minimo di tier: Tier 2, raggiunto ricaricando almeno $10 di credito API. Il Tier 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 tier, tipicamente a un piccolo numero di generazioni in corso ai tier inferiori, in aumento con il tier di utilizzo. Il tetto esatto è impostato per account ed è visibile nella dashboard di OpenAI. Per carichi ad alto volume, pianifica l’accesso a tier 3 o tier 4 fin dal primo giorno.
- Richieste di quota: Limiti di concorrenza più elevati oltre i tetti predefiniti del tier possono essere richiesti tramite il form di aumento dei rate limit di OpenAI. L’approvazione è specifica per il carico e non è istantanea; per lanci in produzione con picchi di domanda prevedibili, richiedi l’aumento diverse settimane prima del lancio.
Da sapere: i rate limit su Sora sono raggruppati in modo diverso 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 GPT-5.5. Viceversa, un grande traffico GPT-5.5 non incide sul budget Sora. Pianifica i due come domande di capacità separate.
Tempo di generazione: cosa aspettarsi davvero
Sora è asincrono per progettazione. Invi un richiesta di generazione, ricevi un job ID e fai polling (o ricevi un webhook) per il completamento. Il tempo reale tra richiesta e completamento dipende dalla durata e risoluzione dell’output, dal carico corrente sull’infrastruttura di OpenAI e dal fatto che il job sia accodato dietro altri sul tuo account.
Aspettative realistiche basate su comportamenti osservati:
| Output | Tempo reale tipico | Note |
|---|---|---|
| Sora 2 standard, 4s @ 720p | 20–45 secondi | Percorso più rapido; ottimo per iterare |
| 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 nelle ore di punta |
| Sora 2 Pro, 25s @ 1024p | 200–360 secondi | Durata massima; il prezzo scala linearmente |
Due conseguenze operative:
- I budget di latenza lato utente vanno ripensati. Se il tuo prodotto si aspetta che la generazione video sia reattiva a un’azione dell’utente, l’intervallo 30–90 secondi per clip brevi implica la necessità di una UX che gestisca l’attesa: indicatori di progresso, lavoro in parallelo che l’utente può fare mentre il video viene generato, o pre-generazione per scenari prevedibili. Trattare Sora come una chiamata API sincrona è l’errore architetturale più comune che i team commettono.
- Polling versus webhook conta. Il polling ingenuo (un ciclo serrato sullo status endpoint) spreca sia il budget di rate limit sia il compute del modello. Usa backoff esponenziale con jitter, o configura callback webhook se l’ambiente lo supporta. Il pattern di polling che funziona bene in produzione è fare polling a intervalli di 10 secondi per il primo minuto, poi a intervalli di 30 secondi oltre, con un timeout rigido 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 d’immagini come DALL-E 3. Ci sono meno manopole da regolare, ma quelle che esistono contano. I parametri salienti:
- model: sora-2 o sora-2-pro. La scelta determina sia il prezzo sia le opzioni di durata/risoluzione disponibili come mostrato nella tabella prezzi sopra.
- prompt: Testo libero che descrive la scena. Sora gestisce direzione cinematografica (angoli di camera, 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 la direzione tecnica produce risultati più affidabili di un singolo paragrafo denso.
- image: Immagine di riferimento opzionale per la generazione image-to-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. Limitata 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; aggiunge 1024x1792 / 1792x1024 su Pro. L’aspect ratio è implicito nella selezione della size.
Assenze notevoli. Sora attualmente non espone il controllo del seed tramite la API pubblica (quindi la riproducibilità tra run non è garantita), né espone controlli di stile individuali come fanno Midjourney o altri modelli di immagini. Il modello è opinato; il prompt engineering è la leva principale, non il tuning dei parametri.
Un semplice esempio di richiesta di generazione con Sora 2, usando l’SDK Python di OpenAI:
| from openai import OpenAIimport timeclient = OpenAI(api_key="YOUR_API_KEY")# Crea il job di generazione del videojob = client.videos.create(model="sora-2",prompt=("Una ripresa grandangolare di una montagna innevata all'alba. ""La camera esegue lentamente un carrello verso sinistra mentre la prima luce colpisce la vetta. ""Cinematografico, ora d'oro, illuminazione di qualità 4K."),size="1280x720",duration=8,)# Polling per 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
La tariffazione al secondo rende il costo prevedibile, ma solo dopo che sei chiaro sulla forma del carico. Tre scenari rappresentativi:
Scenario 1: Una breve demo di prodotto per una landing page SaaS
Un clip da 5 secondi che mostra la UI del prodotto in azione, generato una volta e usato come video hero sul sito marketing. Ti aspetti di iterare 5–10 volte per ottenere un 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 cut finale: $4.00. Costo su Sora 2 Pro a 1024p per la versione finale pubblicata: 5s × $0.50 = $2.50 (un singolo take). Costo totale del progetto: circa $6.50 per i run di iterazione più la finale in HD.
Scenario 2: Un batch di 50 clip per una campagna marketing
50 clip unici da 8 secondi del prodotto, ciascuno basato su una diversa descrizione di funzionalità, tutti 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 i clip che non riescono al primo tentativo (50 × 0.30 = 15 retry × 8s × $0.10 = $12). Totale: circa $52.00 per la campagna.
Scenario 3: Una funzionalità di video generati dagli utenti in un prodotto consumer
Gli utenti nella tua app generano clip da 6 secondi on demand, su Sora 2 standard a 720p. Uso medio: 1.000 clip al giorno. Addebiti agli utenti $0.50 per generazione e accetti la differenza 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 tier standard: ogni generazione costa $0.10 in più di quanto paga l’utente. Il tier standard a 720p richiede un prezzo utente di almeno $0.65 per raggiungere il pareggio prima dell’overhead di infrastruttura. 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 sintesi nei tre scenari: la generazione video è davvero accessibile per i workload di marketing e contenuti una tantum, dove il numero di iterazioni è limitato e conta il costo per asset finale. È significativamente più impegnativa per le funzionalità rivolte agli utenti su scala, dove il costo per generazione deve superare il prezzo pagato dall’utente più l’overhead di prodotto. Sii esplicito su quale workload stai prezzando prima di impegnarti.
Accesso diretto OpenAI versus accesso via aggregatore
Con Sora disponibile tramite più route, la domanda pratica per la maggior parte dei team è quale integrare. La risposta onesta dipende dal resto del tuo stack.
Cosa è uguale
Qualità dell’output, tempo di generazione a livello di modello, parametri supportati e tariffazione al secondo sono tipicamente identici a prescindere dalla route, dato che la maggior parte degli aggregatori trasferisce i prezzi di OpenAI alla pari, e il modello è lo stesso. Se stai scegliendo una route unicamente sulla qualità dell’output, la scelta è indifferente.
Cosa è diverso
- Superficie di fatturazione. L’accesso diretto OpenAI fattura attraverso 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 route diretta non aggiunge nulla di nuovo. Per i team che eseguono workload multi-provider (LLM da Anthropic, modelli di immagini da Black Forest Labs, video da Sora), un aggregatore consolida tutto in un’unica fattura.
- Osservabilità. La dashboard di OpenAI mostra in modo chiaro l’uso di Sora a livello di richiesta. Le dashboard degli aggregatori variano nella capacità di gestire specificamente i workload di generazione video; alcuni hanno osservabilità video dedicata; altri 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 per Sora sono legati al tuo account OpenAI e al tier. Su un aggregatore, in alcuni casi i limiti sono condivisi sull’intera base clienti dell’aggregatore, in altri assegnati per cliente. Per workload di produzione ad alto volume, chiedi all’aggregatore come gestisce l’allocazione dei rate limit prima di integrare.
- Impostazione geografica e compliance. L’OpenAI diretto elabora tramite l’infrastruttura di OpenAI con le opzioni di data residency che OpenAI fornisce. Alcuni aggregatori hanno sede in giurisdizioni con regole di residenza dei dati diverse; altri instradano le richieste tramite l’infrastruttura statunitense di OpenAI a prescindere. Per workload regolamentati, questo è decisivo, ed è il tipo di aspetto per cui vale la pena chiedere al team commerciale dell’aggregatore un impegno scritto.
Come si inserisce CometAPI
CometAPI espone Sora 2 e Sora 2 Pro insieme a oltre 500 altri modelli dietro un singolo endpoint compatibile con OpenAI, con una credenziale e fatturazione unificata. La tariffazione di Sora tramite CometAPI segue le tariffe al secondo di OpenAI; il valore operativo è consolidare l’uso di Sora con il resto del tuo traffico verso i modelli su un’unica fattura. Per i team che eseguono un carico misto (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 OpenAI è una scelta difendibile.
Considerazioni per la produzione
Alcuni pattern che vale la pena impostare correttamente prima che Sora tocchi il traffico di produzione:
- Gestione asincrona del ciclo di vita dei job. Tratta ogni generazione Sora come un job long-running, non come una richiesta. Persiste il job ID immediatamente alla creazione; sopravvivi a un riavvio del server potendo riprendere il polling dei job in corso; gestisci il caso in cui il job 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 su webhook. Se la piattaforma supporta webhook per gli eventi di completamento (l’API di OpenAI sì), usali. I webhook eliminano la necessità di polling e riducono sia la pressione sui rate limit sia il compute sprecato dai controlli di stato frequenti. Il polling è il fallback per ambienti che non possono esporre un endpoint webhook.
- Modalità di failure che costano. OpenAI non fattura per generazioni fallite, ma completamenti parziali e richieste ritentate che vanno a buon fine al secondo tentativo comportano costi. In produzione, registra il costo di ogni retry e genera alert se il tuo tasso di retry supera le attese, perché di solito è un segnale di un problema di policy dei contenuti nei prompt che invii, 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 in cui il prompt è in parte sotto controllo dell’utente), rivedi la documentazione ufficiale della content policy di OpenAI e progetta i guardrail upstream di conseguenza. Rimandare 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 workload Sora sono pronti per la produzione oggi, quali sono al limite e quali sono prematuri:
Pronto per la produzione oggi
Workload di marketing e contenuti creativi in cui l’iterazione è limitata e il costo per asset finale è la metrica corretta. Video demo di prodotto, contenuti per campagne social, video hero per landing page, materiale di formazione interna. 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 e non l’utente finale.
Al limite
Funzionalità di generazione video rivolte all’utente 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. L’ondata di inizio 2026 di app consumer per generazione video è per lo più in questa categoria, e quelle con economia sostenibile sono state tutte deliberate nel vincolare ciò che gli utenti possono generare.
Prematuro
Video long-form su scala (qualsiasi cosa oltre 25 secondi, dato che questo è l’attuale tetto di durata di Sora), scenari real-time ad alto volume in cui la latenza di tempo reale conta più dei dollari e applicazioni che si aspettano controllo a livello di frame o riproducibilità basata su seed. Questi sono workload da riesaminare quando la superficie di capacità di Sora si espanderà, non da forzare oggi.
L’inquadramento: Sora 2 è davvero pronto per la produzione per workload di contenuti con una persona nel loop. È praticabile per funzionalità rivolte agli utenti con un’economia unitaria deliberata. È prematuro per video long-form e per casi d’uso che richiedono parametri che Sora non espone ancora. Costruisci per ciò che è pronto oggi; monitora ciò che non lo è ancora.
Provarlo sul tuo workload: Tutte le varianti Sora 2 e Sora 2 Pro sono disponibili su CometAPI insieme ai modelli di testo che potresti già usare. Il credito di prova gratuito ti consente di generare alcuni clip ai prezzi standard senza alcuna configurazione oltre a puntare il tuo client compatibile con OpenAI all’endpoint CometAPI.