Sora 2 er den første allment tilgjengelige tekst-til-video-modellen fra OpenAI, tilgjengelig programmessig både via den offisielle OpenAI API-en og et voksende sett av aggregator-ruter. Prismodellen er uvanlig sammenlignet med tekstmodeller (fakturering per sekund av generert video i stedet for per token), og de praktiske spørsmålene utviklere stiller før integrering er andre enn for en LLM-API. Hva koster et klipp egentlig? Hvor lang tid tar genereringen? Hva er ratebegrensningene? Hva endrer seg når du aksesserer Sora via en aggregator i stedet for direkte fra OpenAI?
Denne artikkelen er referansen vi skulle ønske fantes da vi begynte å definere våre egne videogenereringsfunksjoner. Stykket er strukturert for utvikleren som har passert «er Sora interessant?» og nå må svare på «hva vil det koste, hva krever integrasjonen, og hva må jeg vite før jeg forplikter meg?»
Kortversjon: Sora 2 (standardmodellen) koster $0.10 per sekund generert video i 720p. Sora 2 Pro koster $0.30 per sekund i 720p eller $0.50 per sekund i 1024p. Et typisk 10-sekunders klipp er $1.00 på standardmodellen og $5.00 på Pro i HD. Genereringstiden er asynkron; forvent 30–90 sekunder reell tid for et 5–10 sekunders klipp. Tilgang krever en betalt OpenAI-konto på minst brukernivå (tier) 2.
Status for Sora API-tilgang i 2026
Sora 2 ble lansert i OpenAI API 7. oktober 2025, og tilgangen har vært kontinuerlig tilgjengelig siden. Modellidentifikatoren er sora-2 (med et nåværende snapshot-ID på sora-2-2025-12-08), og høyere-fidelitetsvarianten er sora-2-pro. Begge støtter tekst-til-video og bilde-til-video-generering, med synkronisert lydutgang. Per 10. januar 2026 ble forbrukertilgang på gratiskonto gjennom ChatGPT avviklet, noe som har konsentrert Sora-bruk på utviklernivå til enten betalte ChatGPT-abonnementer eller direkte API-tilgang.
Det finnes tre veier for å bruke Sora programmessig:
- OpenAI direkte API. Den kanoniske ruten. Fakturering per sekund, kun betalt, krever minimum $10 påfyll for å nå brukernivå 2 som låser opp Sora-modelltilgang. Både SDK og REST API støttes.
- Azure OpenAI. Microsofts enterprise-rute, som speiler OpenAIs offisielle satser med tillegg av Azure-abonnementsoverhead og enterprise-compliance-funksjoner. Samme per-sekund-priser; annen operasjonell overflate.
- Aggregatorer. Tjenester som eksponerer Sora bak en egen, samlet API. De fleste aggregatorer viderefakturerer OpenAIs per-sekund-priser til paritet; verdien er operasjonell (ett legitimasjonssett, én faktura, samme SDK som tekstmodelltrafikken din). Noen aggregatorer tilbyr egne tariffstrukturer, som vi diskuterer senere i artikkelen.
Sora 2-prising per sekund video
Sora-prising er strukturert etter modellnivå og utgangsoppløsning, med en per-sekund-sats som multipliseres med klippets varighet for å gi genereringskostnaden. Verifisert fra OpenAIs offisielle prisside per mai 2026:
| Modell | Oppløsning | Støttede varigheter | Pris per sekund | 10-sekunders klipp |
|---|---|---|---|---|
| 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 |
Merknader om prismodellen. Prisingen er basert på utdata, ikke inndata; det er ingen token-basert inndatafakturering for Sora slik det er for tekstmodeller. Bildekondisjonering (å sende et referansebilde for å forankre genereringen) endrer ikke per-sekund-satsen. Varighetsvalgene for hver modell er faste: du kan ikke be om et 7-sekunders klipp på standardmodellen, kun 4, 8 eller 12 sekunder.
To praktiske implikasjoner som er verdt å være eksplisitt på. For det første: prismodellen ligner mer en videorenderingsregning enn en LLM-regning. Kostnaden drives av utgangsvarighet, ikke av hvor kompleks prompten din er eller hvor mange tokens den inneholder. For det andre: kostnadsforskjellen mellom Sora 2 og Sora 2 Pro i HD er 5× per sekund: et 10-sekunders klipp koster $1.00 på standard og $5.00 på Pro i 1024p. Valg av riktig nivå for oppgaven er den viktigste kostnadsdriveren du har, og det lønner seg å være bevisst på hvilke arbeidslaster som virkelig trenger Pros høyere fidelitet.
Ratebegrensninger og kvoter
Sora-ratebegrensninger er organisert rundt OpenAIs standard brukernivåsystem. De mest relevante detaljene for Sora spesifikt:
- Minimumsnivå: Nivå 2, nås ved å fylle på minst $10 i API-kreditt. Nivå 1 (standard for nye kontoer) inkluderer ikke Sora-modelltilgang.
- Samtidige genereringsgrenser: I henhold til OpenAIs rate limit-dokumentasjon er samtidig videogenerering begrenset etter nivå, typisk et lite antall pågående genereringer på lavere nivåer, skalerende med brukernivå. Den eksakte taket settes per konto og er synlig i OpenAI-dashbordet. For høyvolumsarbeidslaster, planlegg for nivå 3 eller 4 fra dag én.
- Kvotebegjæringer: Høyere samtidige grenser utover standardtakene kan begjæres via OpenAIs skjema for økte rategrenser. Godkjenning er arbeidslastspesifikk og ikke umiddelbar; for produksjonslanseringer med forutsigbare etterspørseltopper, be om økningen flere uker før lansering.
Verdt å vite: ratebegrensninger på Sora pooles annerledes enn ratebegrensningene for tekstmodeller på samme konto. Et team som kjører tung Sora-trafikk påvirker ikke tilgjengelig ratebudsjett for GPT-5.5-kall. Omvendt spiser stor GPT-5.5-trafikk ikke av Sora-budsjettet. Planlegg de to som separate kapasitetsspørsmål.
Genereringstid: hva du faktisk kan forvente
Sora er asynkron av design. Du sender en genereringsforespørsel, får tilbake en jobb-ID og poller (eller får webhook-tilbakeringing) for fullføring. Reell tidsbruk mellom forespørsel og fullføring avhenger av varigheten og oppløsningen på utdataene, nåværende last på OpenAIs infrastruktur, og om jobben står i kø bak andre på kontoen din.
Realistiske forventninger basert på observert atferd:
| Utdata | Typisk tidsbruk | Merknader |
|---|---|---|
| Sora 2 standard, 4s @ 720p | 20–45 sekunder | Raskeste løype; god for iterasjon |
| Sora 2 standard, 8s @ 720p | 40–90 sekunder | Vanligste produksjonsvarighet |
| Sora 2 standard, 12s @ 720p | 60–120 sekunder | Lengre sosialt innhold |
| Sora 2 Pro, 10s @ 720p | 60–150 sekunder | Premium kvalitet; ~3x kostnaden av standard |
| Sora 2 Pro, 15s @ 1024p | 120–240 sekunder | Full HD, lengre kø observert ved topplast |
| Sora 2 Pro, 25s @ 1024p | 200–360 sekunder | Maks varighet; pris skalerer lineært |
To operasjonelle konsekvenser:
- Brukervendte latensbudsjetter må tenkes om. Hvis produktet ditt forventer at videogenerering føles responsiv på en brukerhandling, betyr 30–90 sekunder for korte klipp at du trenger en UX som håndterer ventetiden: fremdriftsindikatorer, parallelt arbeid brukeren kan gjøre mens videoen genereres, eller pregenerering for forutsigbare scenarioer. Å behandle Sora som et synkront API-kall er den vanligste arkitekturfeilen team gjør.
- Polling versus webhooks betyr noe. Naiv polling (en tight loop som treffer statusendepunktet) sløser både ratebudsjetter og modellens compute. Bruk eksponentiell backoff med jitter, eller sett opp webhook-tilbakeringinger hvis miljøet ditt støtter det. Pollingmønsteret som fungerer godt i produksjon er å polle hvert 10. sekund det første minuttet, deretter hvert 30. sekund etter det, med en hard timeout ved modellens forventede øvre grense for den forespurte varigheten.
Støttede parametere og prompt-struktur
Soras API-overflate er bevisst enkel sammenlignet med bildegenereringsmodeller som DALL-E 3. Det er færre knotter å skru på, men de som finnes betyr noe. De viktigste parameterne:
- model: sora-2 eller sora-2-pro. Valget styrer både prising og tilgjengelige varighets-/oppløsningsvalg som vist i pristabellen over.
- prompt: Fri tekst som beskriver scenen. Sora håndterer filmatisk regi (kameravinkler, bevegelse, lyssetting), karakterhandlinger og miljødetaljer. Modellen er sensitiv for prompt-struktur: å begynne med sceneetablering, deretter handling, så teknisk regi, gir mer pålitelige resultater enn ett enkelt tett avsnitt.
- image: Valgfritt referansebilde for bilde-til-video-generering. Referansen fungerer som første-ramme-anker; modellen genererer bevegelse utover fra dette startpunktet. Nyttig for produktdemoer, karakterkontinuitet og scenarier der subjektets statiske utseende ikke kan kompromitteres.
- duration: Varighet i sekunder. Begrenset til diskrete valg for den valgte modellen (4/8/12 for sora-2, 10/15/25 for sora-2-pro). Kostnad skalerer lineært med varighet.
- size: Oppløsning. 720x1280 (portrett) eller 1280x720 (landskap) på standardmodellen; legger til 1024x1792 / 1792x1024 på Pro. Sideforholdet er implisitt i størrelsesvalget.
Merkbare mangler. Sora eksponerer for øyeblikket ikke seed-kontroll via den offentlige API-en (reproduserbarhet på tvers av kjøringer er derfor ikke garantert), og eksponerer heller ikke individuelle stilkontroller slik som Midjourney eller andre bildemodeller gjør. Modellen er opinionated; prompt-engineering er den primære spaken, ikke parameterjustering.
Et enkelt eksempel på en Sora 2-genereringsforespørsel, med OpenAI Python SDK:
| from openai import OpenAIimport timeclient = OpenAI(api_key="YOUR_API_KEY")# Opprett videogenereringsjobbenjob = client.videos.create(model="sora-2",prompt=("Et vidvinkelbilde av et snødekt fjell ved soloppgang. ""Kameraet glir sakte til venstre idet det første lyset treffer toppen. ""Kinematisk, gyllentime, 4K-kvalitets lyssetting."),size="1280x720",duration=8,)# Poll for fullføringwhile True:job = client.videos.retrieve(job.id)if job.status == "completed":video_url = job.output[0].urlbreakelif job.status == "failed":raise RuntimeError(f"Generering mislyktes: {job.error}")print(f"Nåværende status: {job.status}")time.sleep(10)print(f"Video klar: {video_url}") |
|---|
Gjennomarbeidede kostnadseksempler
Per-sekund-prising gjør kostnaden forutsigbar, men først når du er klar over arbeidslastens form. Tre representative scenarier:
Scenario 1: En kort produktdemo for en SaaS-landeside
Et 5-sekunders klipp som viser produkt-UI i aksjon, generert én gang og brukt som hero-video på markedsføringsnettsiden. Du forventer å iterere 5–10 ganger for å få et klipp du er fornøyd med før publisering.
Kostnad på Sora 2 standard i 720p: 5s × $0.10 = $0.50 per generering. Med 8 iterasjoner for å lande den endelige versjonen: $4.00. Kostnad på Sora 2 Pro i 1024p for den publiserte endelige versjonen: 5s × $0.50 = $2.50 (én kjøring). Total prosjektkost: omtrent $6.50 for iterasjonene pluss HD-finalen.
Scenario 2: En batch på 50 klipp for en markedsføringskampanje
50 unike 8-sekunders produktklipp, hvert basert på en annen funksjonsbeskrivelse, alle på Sora 2 standard i 720p. Ingen iterasjonsbudsjett; du aksepterer første generering.
Kostnad: 50 × 8s × $0.10 = $40.00. Legg til 30 % iterasjonsbudsjett for klippene som ikke treffer på første forsøk (50 × 0.30 = 15 nye forsøk × 8s × $0.10 = $12). Totalt: omtrent $52.00 for kampanjen.
Scenario 3: En brukergenerert videofunksjon i et forbrukerprodukt
Brukere i appen din genererer 6-sekunders klipp på forespørsel, på Sora 2 standard i 720p. Gjennomsnittlig bruk: 1,000 klipp per dag. Du tar $0.50 per generering og aksepterer kostnadsdifferansen som enhetsmargin.
Kostnad per brukerklipp: 6s × $0.10 = $0.60. Med brukerpris på $0.50 er arbeidslasten tapsbringende på standardnivå: hver generering koster $0.10 mer enn brukeren betaler. 720p standardnivå krever brukerpris på minst $0.65 for å gå i null før infrastrukturoverhead. Ved 30,000 klipp per måned: månedlig Sora-regning på $18,000. Dette er typen enhetsøkonomisjekk som er verdt å gjøre før lansering av enhver brukervendt videofunksjon.
Hovedpoenget på tvers av de tre scenariene: videogenerering er genuint rimelig for markedsføring og engangsinnholdsarbeidslaster, der antall iterasjoner er begrenset og kostnad per endelig ressurs er det som betyr noe. Det er merkbart mer utfordrende for brukervendte funksjoner i skala, der kostnad per generering må overstige brukerbetalt pris pluss produktoverhead. Vær eksplisitt om hvilken arbeidslast du priser før du forplikter deg.
OpenAI direkte tilgang versus aggregator-tilgang
Med Sora tilgjengelig gjennom flere ruter, er det praktiske spørsmålet for de fleste team hvilken rute man skal integrere mot. Det ærlige svaret avhenger av resten av stakken din.
Hva som er likt
Utdatakvalitet, genereringstid på modellaget, støttede parametere og per-sekund-prising er typisk identiske uansett rute, siden de fleste aggregatorer viderefører OpenAIs prising til paritet, og modellen er den samme. Velger du rute utelukkende på utgangskvalitet, er valget hipp som happ.
Hva som er forskjellig
- Faktureringsflate. Direkte OpenAI-tilgang fakturerer gjennom OpenAI-kontoen din; aggregatorer fakturerer gjennom eget kreditt- eller abonnementssystem. For team som allerede håndterer OpenAI-fakturering for tekstmodellbruk, legger direkte rute ikke til noe nytt. For team som kjører multiprodusent-arbeidslaster (LLM-er fra Anthropic, bildemodeller fra Black Forest Labs, video fra Sora), konsoliderer en aggregator alt på én faktura.
- Observabilitet. OpenAIs dashbord viser Sora-bruk på forespørselsnivå ryddig. Aggregatordashbord varierer i hvor godt de håndterer videogenereringsarbeidslaster spesifikt; noen har formålstilpasset videoobservabilitet; andre behandler video som et generisk API-kall. Verdt å sjekke før du forplikter deg hvis observabilitet er en prioritet.
- Rate-limit-pooling. På direkte OpenAI er Sora-ratebegrensningene dine knyttet til OpenAI-kontoen og nivået ditt. Hos en aggregator pooles grensene i noen tilfeller på tvers av aggregatorens kundebase, eller tildeles per kunde i andre. For høyvolums produksjonsarbeidslaster, spør aggregator hvordan de håndterer tildeling av rategrenser før integrering.
- Geografi og compliance. Direkte OpenAI behandles gjennom OpenAIs infrastruktur med de dataresidens-valgene OpenAI tilbyr. Noen aggregatorer er basert i jurisdiksjoner der dataresidensreglene er annerledes; andre ruter forespørsler gjennom OpenAIs amerikanske infrastruktur uansett. For regulerte arbeidslaster er dette avgjørende, og det er noe som er verdt å be aggregatorens salgsteam bekrefte skriftlig.
Hvordan CometAPI passer inn
CometAPI eksponerer Sora 2 og Sora 2 Pro sammen med 500+ andre modeller bak ett OpenAI-kompatibelt endepunkt, med ett legitimasjonssett og samlet fakturering. Prisingen på Sora via CometAPI følger OpenAIs per-sekund-satser; den operasjonelle verdien er å konsolidere Sora-bruk med resten av modelltrafikken din på én faktura. For team som kjører blandede arbeidslaster (tekstmodeller fra flere leverandører, bildegenerering og Sora-video), er dette hovedargumentet. For team som kun bruker Sora og bare én eller to tekstmodeller, er den operasjonelle besparelsen mindre og direkte OpenAI-tilgang et forsvarlig valg.
Hensyn i produksjon
Noen mønstre det er verdt å få riktig før Sora går i nærheten av produksjonstrafikk:
- Håndtering av asynkrone jobbers livssyklus. Behandle hver Sora-generering som en langtlevende jobb, ikke en forespørsel. Persistér jobb-ID umiddelbart ved opprettelse; overlev en serveromstart ved å kunne gjenoppta polling for pågående jobber; håndter tilfeller der jobben fullføres mens arbeiderprosessen din er offline. Dette er standard distribuert-system-hygiene, men hoppes ofte over i starten fordi Sora er den første asynkrone API-en teamet har integrert.
- Webhook som primær, polling som fallback. Hvis plattformen støtter webhooks for fullføringshendelser (OpenAI API gjør det), bruk dem. Webhooks fjerner behovet for polling og reduserer både ratepress og bortkastet compute ved hyppige statuskontroller. Polling er fallback for miljøer som ikke kan eksponere et webhook-endepunkt.
- Feilmoduser som koster penger. OpenAI fakturerer ikke for mislykkede genereringer, men delvise fullføringer og nye forsøk som lykkes på andre forsøk påløper kostnad. I produksjon bør du logge kostnaden for hvert nytt forsøk og varsle hvis retry-raten overstiger forventningene, siden det som regel signaliserer et innholdspolicy-problem med promptene du sender, som er billigere å fikse i promptlaget enn å absorbere på fakturaen.
- Innholdspolicy og produksjonsutrulling. Sora er bundet av OpenAIs brukspolicyer, som begrenser visse kategorier av innhold. For produksjonsutrullinger (spesielt brukervendte der prompten delvis er under brukerens kontroll), gå gjennom OpenAIs offisielle innholdspolicydokumentasjon og design upstream-guardrails deretter. Å lenke til OpenAIs policy er riktig referanse; den dokumentasjonen er sannhetskilden og endres oftere enn denne artikkelen.
Hva du bør bygge først
Den ærlige vurderingen av hvilke Sora-arbeidslaster som er klare for produksjon i dag, hvilke som ligger i grenseland, og hvilke som er premature:
Produksjonsklart i dag
Markedsførings- og kreativt innhold der iterasjon er begrenset og kostnad per endelig ressurs er riktig mål. Produktdemovideoer, innhold til sosiale kampanjer, hero-videoer for landingssider, internt opplæringsmateriell. Økonomien fungerer, feilmodusene er godt forstått, og latenshistorien (30–90 sekunder for korte klipp) er akseptabel når mennesket i loopen er innholdsteamet snarere enn sluttbruker.
I grenseland
Brukervendte videogenereringsfunksjoner der kostnad per klipp må overstige brukerbetalt pris. Dette er gjennomførbart, men krever nøye enhetsøkonomi: begrens varigheten brukere kan be om, bruk Sora 2 standard i 720p som standard, ta en pris som har margin over kostnaden per klipp. Bølgen av forbrukervideoapper tidlig i 2026 ligger stort sett her, og de med bærekraftig økonomi har alle vært bevisste på å begrense hva brukere kan generere.
For tidlig
Langformvideo i skala (alt over 25 sekunder, siden det er Soras nåværende varighetstak), høyvolum sanntidsscenarier der reell latens betyr mer enn kroner, og applikasjoner som forventer kontroll på rammenivå eller seed-basert reproduserbarhet. Dette er arbeidslaster å revurdere når Soras kapabilitetsflate utvides, ikke å tvinge inn i dag.
Rammeverket: Sora 2 er genuint produksjonsklar for innholdsarbeidslaster med et menneske i loopen. Den er gjennomførbar for brukervendte funksjoner med bevisst enhetsøkonomi. Den er for tidlig for langformvideo og for brukstilfeller som krever parametere Sora ennå ikke eksponerer. Bygg for det som er klart i dag; følg med på det som ikke er klart ennå.
Test det på arbeidslasten din: Alle Sora 2- og Sora 2 Pro-varianter er tilgjengelige på CometAPI sammen med tekstmodellene du kanskje allerede bruker. Gratis prøvekreditt lar deg generere noen få klipp til standard prising uten annet oppsett enn å peke din eksisterende OpenAI-kompatible klient mot CometAPI-endepunktet.