Sora 2 was a generative artificial intelligence model developed by OpenAI to produce video with synchronized audio from natural-language descriptions or reference images. Introduced on September 30, 2025, it succeeded the original Sora and powered a separate Sora application for creating and sharing generated clips. Its outputs combined moving imagery with dialogue, sound effects, and ambient sound. (openai.com)
OpenAI presented Sora 2 as an advance in physical plausibility, scene continuity, and control over generated sequences, while acknowledging that it continued to make mistakes. The model connected audiovisual generation with social remixing and consent-based representations of users, bringing questions of likeness, provenance, and misuse into its product design and safety evaluation. These capabilities and safeguards were documented primarily through OpenAI’s release materials and system card. (openai.com)
The Sora web and app experiences were discontinued on April 26, 2026. The Sora 2 models and Videos API were shut down on September 24, 2026; OpenAI retained the API documentation for historical reference. (help.openai.com)
Development and release
OpenAI announced the original Sora on February 15, 2024, as a text-to-video research model capable of generating videos up to one minute long. The accompanying technical report situated the work within research on models that could simulate the physical world, while withholding full model and implementation details. This announcement was a research preview rather than a general consumer release: initial access went to red-team evaluators and selected visual artists, designers, and filmmakers, whose feedback was intended to inform safety testing and creative applications. Sora 2 subsequently emerged from this generative artificial intelligence research programme. (openai.com)
An intermediate release, Sora Turbo, became available on December 9, 2024. OpenAI described it as significantly faster than the February preview and introduced it through a standalone website for ChatGPT Plus and Pro subscribers. The associated interface supported text, image, and video inputs, together with a storyboard tool for specifying a sequence of shots. This established a consumer product under the Sora name before Sora 2 existed: the December 2024 release was neither the original research announcement nor the September 2025 model launch. OpenAI also acknowledged that Turbo still struggled with realistic physics and complex actions over longer sequences. (openai.com)
Sora 2 was released on September 30, 2025, alongside a system card documenting its capabilities, risks, and deployment safeguards. Unlike the original model’s video-focused introduction, it was presented as a video-and-audio generation model, including synchronized speech and sound effects. OpenAI characterized improved realism, physical plausibility, and instruction following as advances over earlier systems; these were company descriptions, not independent benchmark findings. The release credits identified Bill Peebles as leading Sora, Connor Holmes as leading systems, and Rohan Sahai and Thomas Dimson as product leaders. (openai.com)
The initial rollout was invitation-based and limited to the United States and Canada. Users could download the new Sora iOS application and register for a push notification when their account became eligible; receiving an invitation also enabled access through the Sora website. Download availability therefore did not itself confer generation access. OpenAI announced initially free access subject to computing constraints, with an experimental, higher-quality Sora 2 Pro model offered to ChatGPT Pro subscribers on the website. The announcement also stated that Sora 1 Turbo would remain available rather than being immediately replaced. (openai.com)
The launch distinguished three layers: Sora 2 was the underlying generation model; Sora was the consumer application, adding creation, discovery, sharing, and remixing; and the developer application programming interface was a separately delivered integration channel. API access was described as forthcoming on September 30, not as part of the initial invitation-based app rollout. Separately published developer documentation subsequently identified the model names sora-2 and sora-2-pro and exposed video generation through a Videos API, rather than through the consumer application’s social interface. (openai.com)
Technical foundations and disclosed training data
OpenAI’s developer guide described Sora’s technical foundation as research into multimodal diffusion and training on diverse visual data. It associated that foundation with generating video with audio from natural-language descriptions or reference images. This was a high-level account of the research lineage and supported behavior, not a complete architectural specification for Sora 2. In particular, the guide did not specify the network’s internal organization, its training objective, or how audio and video representations were combined. The description therefore supports identifying multimodal diffusion as a technical foundation, but not reconstructing the model’s implementation. (developers.openai.com)
The Sora 2 system card, dated September 30, 2025, disclosed three broad categories of training data: information publicly available on the internet; information accessed through partnerships with third parties; and information provided or generated by users, human trainers, and researchers. These were categories of provenance rather than an inventory of datasets. The disclosure did not identify individual partner collections, enumerate internet sources, or quantify the contribution of user-provided and researcher-generated material. Nor did it provide percentages separating the three categories or a breakdown of the corpus by media type, language, or geographic origin. (cdn.openai.com)
OpenAI described a data-processing pipeline that filtered material to maintain quality and mitigate risks. It also reported using multiple safety classifiers to help prevent harmful or sensitive material from being used or generated, explicitly identifying sexual content involving minors as an example. The disclosed mechanism was thus a combination of dataset filtering and automated content classification. However, the data section did not publish the classifiers’ decision thresholds, the quantities of material rejected, or measured error rates for training-data screening. Its wording described risk-reduction measures rather than establishing that every sensitive example had been excluded. (deploymentsafety.openai.com)
Training-data screening was distinct from the separately documented moderation of prompts and generated outputs. The latter examined such artifacts as video frames, audio transcripts, and scene descriptions during deployment; those controls do not, by themselves, reveal which examples entered model training. The system card discussed both layers, but supplied substantially more operational detail about deployment safeguards than about corpus construction. (cdn.openai.com)
The cited technical disclosures did not report Sora 2’s parameter count, total training-set size, training compute, or a sufficiently detailed training recipe for independent reproduction. Statements that Sora 2 built on the original Sora did not establish that every previously described architectural component remained unchanged. Consequently, specific claims about inherited tokenization, compression, network structure, or training procedures require Sora 2-specific evidence rather than inference from the earlier model’s documentation. (developers.openai.com)
Audiovisual generation and scene control
Sora 2 generated video with synchronized audio from natural-language descriptions or reference images. Its model documentation distinguished these conditioning inputs from the resulting media: text and images were listed as input-only modalities, whereas audio and video were output-only modalities. Thus, the ability to generate speech or environmental sound did not imply that the basic model interface accepted an uploaded soundtrack as an audio prompt. Text could specify subjects, actions, settings, camera behavior, and audible events within the same generation request. (developers.openai.com)
Reference-image conditioning supplied a more concrete visual starting point than text alone. OpenAI’s prompting guide described the image as an anchor for the first frame, establishing elements such as composition, character appearance, clothing, and set decoration; the accompanying text specified the subsequent action. One documented example paired an image with an instruction for the subject to turn, smile, and walk out of the frame. This division assigned the initial visual arrangement to the reference and the temporal development to the written prompt, rather than treating the image as a complete specification of the resulting sequence. (developers.openai.com)
The generated soundtrack could include dialogue, environmental ambience, and discrete sound effects. OpenAI’s September 30, 2025 announcement illustrated speech generation with two mountain explorers shouting alternately in snowy conditions. Its prompting guide made the intended control more explicit: dialogue was separated from visual description, and consistent speaker labels associated utterances with particular characters and their gestures. The guide also identified timing constraints, indicating that a four-second shot generally accommodated only one or two brief exchanges and warning that lengthy speeches could lose synchronization or disrupt pacing. Background audio could be specified independently of dialogue—for example, machinery and indistinct conversation establishing an interior soundscape. These were documented prompting practices, not measured guarantees of audiovisual alignment. (openai.com)
Scene control extended beyond individual actions to instructions spanning multiple shots. OpenAI claimed that Sora 2 could preserve scene state across such sequences, presenting continuity as a capability distinct from rendering an isolated image convincingly. The launch description identified realistic, cinematic, and anime-style imagery as supported strengths, encompassing both live-action-like presentation and animation. At the prompt level, this control involved descriptions of framing, camera movement, action order, lighting, and color. The guide proposed repeating lighting characteristics and a small set of palette colors to encourage visual consistency between shots; these remained natural-language constraints rather than a guarantee that every requested detail would persist. (openai.com)
OpenAI used a missed basketball shot to illustrate its claim of improved physical plausibility: instead of forcing a successful basket, the generated ball could strike the backboard and rebound. The distinction concerned representing an unsuccessful action with a plausible consequence, not simply producing the outcome implied by a successful attempt. This was a qualitative example in the launch announcement, not a validated physics benchmark: the example supplied no numerical trajectory error, controlled comparison, or success rate. OpenAI also acknowledged continuing generation errors, so the rebound illustration did not establish general physical reliability or a validated world model. (openai.com)
Model variants, output formats, and pricing
OpenAI documented two variants for its API: sora-2, oriented toward faster iteration, and sora-2-pro, oriented toward higher-quality output. The developer guide positioned the standard model for exploring visual style, developing concepts, and producing rough cuts. Pro was described as slower and more expensive, but capable of more polished, stable results for cinematic footage and marketing assets. These were OpenAI’s descriptions of the intended quality–latency trade-off, rather than independently measured comparisons; the guide did not provide a fixed rendering-time ratio between the variants. (developers.openai.com)
The standard model’s listed output dimensions were 720 × 1280 pixels in portrait orientation and 1280 × 720 pixels in landscape orientation. Pro supported those same dimensions, with additional listed formats of 1024 × 1792 and 1792 × 1024 pixels, and full-HD outputs of 1080 × 1920 and 1920 × 1080 pixels. Consequently, “Pro” did not identify a single resolution: the variant could be used at several output sizes, with different prices. The intermediate 1024 × 1792 formats were listed separately from the 1080p formats and should not be treated as equivalent specifications. (developers.openai.com)
Duration limits also require a documentation date and interface context. As retained on October 15, 2026, the historical API guide explicitly documented 16- and 20-second generations for both variants and described generation lengths of up to 20 seconds. This records the retained API specification, not a uniform limit applying throughout the models’ release history or across the consumer application and website. The guide also stated that longer clips and 1080p jobs could take materially longer than shorter, lower-resolution renders. The documentation was retained after the models and Videos API were shut down on September 24, 2026. (developers.openai.com)
Historical API prices were expressed in US dollars per second of generated video. At 720 × 1280 or 1280 × 720, the standard model cost $0.10 per second, compared with $0.30 for Pro—three times the listed rate at the same resolution. Pro’s intermediate-resolution formats cost $0.50 per second, while its 1080p formats cost $0.70. By direct calculation from those rates, an eight-second 720p generation corresponded to $0.80 with the standard model or $2.40 with Pro; an eight-second Pro generation at 1080p corresponded to $5.60. (developers.openai.com)
These per-second charges described developer API usage, not a consumer subscription price or an allowance of videos within a subscription. OpenAI maintained separate billing systems for ChatGPT subscriptions and the API platform, with API usage billed independently. Subscription access and consumer generation allowances therefore cannot be converted into API entitlements simply by applying the historical per-second rate. (help.openai.com)
The Sora application and likeness features
The Sora consumer application, introduced on September 30, 2025, combined video creation with social-media functions: discovering generated clips, sharing creations, and remixing other users’ videos. These were application-level features, distinct from the underlying Sora 2 model’s ability to generate audiovisual content. The customizable feed provided a route from viewing to creation, while remixing allowed an existing generation to become the starting point for another user’s work. OpenAI presented the application as a setting for collaborative creation, particularly among friends, rather than simply as an interface for submitting generation prompts. (openai.com)
The likeness feature was called “cameos” in the September 2025 launch system card and “characters” in subsequently updated product materials. A user created a personal representation through a short, one-time video-and-audio recording inside the application, which OpenAI described as serving both identity verification and likeness capture. The representation encompassed the person’s appearance and voice, allowing that person—or another authorized user—to place their likeness into generated scenes. It was therefore not merely a profile picture or a written description of a fictional persona: it connected captured audiovisual identity information to a reusable representation in the creation interface. The launch system card described explicit opt-in consent as a condition for this route to depicting real users. (openai.com)
Permissions governed who could use that representation, and the person represented could revoke access at any time. OpenAI also documented controls over resulting videos: users could view videos containing their own character, including unpublished drafts created by other people, and could remove videos featuring that character. Updated safety materials additionally described the ability to review, delete, and report such videos. These controls addressed two separate stages of privacy management—authorization to generate new depictions and oversight of depictions already created within Sora. Optional stricter character safeguards were intended to constrain major changes to appearance, embarrassing situations, and departures from a broadly consistent identity; these were described as protective measures, not guarantees that every generated depiction would match the user’s intentions. (openai.com)
OpenAI’s stated feed design emphasized followed accounts, people with whom a user interacted, and videos predicted to provide inspiration for further creation. The company said that its recommendation system used existing large language models and could be steered through natural-language instructions; it also described periodic wellbeing questions that offered opportunities to adjust the feed. Its February 3, 2026 feed-philosophy document supplied more concrete examples of personalization signals: posts, followed accounts, likes, comments, remixes, and requests to see less similar content, alongside author and safety signals. That document also stated that ChatGPT history could inform recommendations, with an option to disable that use in Sora’s data controls. OpenAI characterized the ranking objective as encouraging creativity and active participation rather than maximizing time spent scrolling; this was a declared product-design objective, not an independently established measurement of user behavior. (openai.com)
Developer interface and production workflows
The retained developer documentation described an asynchronous API rather than an immediate video response. Submitting POST /v1/videos returned a job identifier and initial status. Applications could poll the job until it became completed or failed, or receive video.completed and video.failed webhook notifications. Completed MP4 files were retrieved through the video-content endpoint. OpenAI positioned this workflow for concept development, rough cuts, social-media clips, and marketing assets; these were intended uses, not independently measured adoption. (developers.openai.com)
OpenAI’s March 12, 2026 changelog recorded an expansion encompassing reusable character references, video extensions, and Batch API support, alongside a dedicated editing endpoint. These were features of the later, retained API documentation and should not be assumed to have existed throughout the service’s history. The editing endpoint was introduced to replace the earlier remix endpoint. (developers.openai.com) Reference-image conditioning used input_reference to establish a generation’s opening frame; supported images had to match the requested output resolution. This differed from a reusable character asset, which could condition multiple separate requests. (developers.openai.com)
The archived prompting guide described creating animal or object characters from short MP4 reference clips, specifying 2–4 seconds, 720p–1080p resolution, and either landscape or portrait aspect ratios. Subsequent requests supplied the character identifier and named the subject in the prompt. Its example reused a dog called Alfie across different generated scenes. Video extensions instead used the full existing clip as context for a continuation, rather than merely its final frame; the guide documented individual additions of up to 20 seconds and a maximum combined duration of 120 seconds. For targeted edits, it described retaining an existing shot while changing one feature at a time, such as the lens description or color palette. These were documented continuity and iteration mechanisms, not guarantees of identical results. (developers.openai.com)
Batch rendering supported offline queues rather than interactive completion. The Batch API accepted an uploaded JSONL request file and a 24-hour processing window, with /v1/videos among its supported endpoints. Each request could therefore represent a separate render within a larger submission. (developers.openai.com) The video guide specifically associated batching with shot lists, review pipelines, and scheduled studio rendering. It required JSON requests and assets uploaded or referenced in advance, rather than multipart uploads. (developers.openai.com)
The documented API restrictions excluded generating real people, including public figures, and rejected human-face input images, copyrighted characters, and copyrighted music. Human-likeness character uploads were blocked by default. (developers.openai.com) These restrictions were distinct from the consumer application’s permission-based likeness feature, through which users could capture their own appearance and voice and control who could use that representation. Consumer-app permission did not itself describe authorization for the developer interface. (openai.com)
Content safeguards and provenance
The September 30, 2025 system card described moderation at both the input and output stages. Text and image classifiers could reject a prompt before generation. After rendering, additional checks examined video frames, scene descriptions, and audio transcripts, using controls that included child sexual abuse material classifiers and a multimodal reasoning monitor trained to interpret content policies. This second stage was intended to catch prohibited material that passed the input filters; comments were also subject to moderation. These were layered blocking mechanisms, rather than a claim that the underlying model could not produce harmful content. (deploymentsafety.openai.com)
OpenAI’s accompanying launch account identified sexual material, terrorist propaganda, and promotion of self-harm as targets of these defenses. Generated speech was checked through transcripts, while automated systems separately scanned feed content for policy violations and age-inappropriate material. Human review complemented this scanning, with attention to high-impact harms. The distinction mattered operationally: generation checks governed whether an output could be delivered, whereas feed filtering governed what the application distributed through its social-media interface. OpenAI also described reporting controls for individual videos, profiles, and comments, alongside account blocking and the ability to remove published videos. (openai.com)
For provenance, the system card committed first-party products to C2PA metadata on all assets, moving visible watermarks on videos downloaded from the website or application, and internal tools for assessing whether video or audio originated from OpenAI products. The launch account additionally described internal reverse-image and audio search tools for tracing outputs back to Sora. These commitments concerned complementary signals: a visible indication for viewers, machine-readable origin information, and internal attribution capabilities. (deploymentsafety.openai.com) The Coalition for Content Provenance and Authenticity standard uses digitally signed provenance records associated with a media asset. Verification checks their integrity and association with the file; it does not establish that the depicted event actually happened. Thus, a valid credential identifying AI generation is evidence about origin, not authentication of the scene as factual. (c2pa.org)
Enforcement also depended on context beyond the generated media. The system card prohibited unauthorized likeness use, impersonation, scams, fraud, and non-consensual intimate imagery. It described in-app reporting, automated detection combined with human review, content removal or penalties, and notification giving affected users an opportunity to respond. (deploymentsafety.openai.com) For likeness-related risks, OpenAI’s launch account described consent-based controls over image and voice representations, revocable access, and the ability for the represented person to inspect, delete, or report videos containing that representation, including other users’ drafts. These controls addressed consent and misuse rather than merely identifying synthetic media. (openai.com) The system card acknowledged that deception could be highly contextual and difficult for classifiers to detect, and that harmful behavior could still circumvent the safeguards. Provenance measures were therefore presented as additional mitigations, not guarantees against impersonation or deceptive redistribution. (cdn.openai.com)
Youth protections and social-product controls
The September 30, 2025 system card described two distinct triggers for heightened youth safeguards: the presumed age of the user and the apparent age of a person depicted in source material. Accounts believed to belong to users under 18 were subject to additional moderation thresholds restricting age-inappropriate outputs. Separately, classifiers detecting a potential minor in an uploaded image or video—including material captured through the likeness feature then called “cameos”—triggered tighter thresholds for subsequent generations based on that material. Thus, protections for depictions of minors were not limited to requests made by teenage users. These were moderation and classification measures surrounding generation, rather than a separately identified youth version of the underlying model. (cdn.openai.com)
Youth safeguards also governed distribution. The system card stated that classifiers were intended to keep the public feed consistent with OpenAI’s under-18 policies regardless of the viewer’s age. This distinguished permission to generate material from eligibility to distribute it through the application’s social-media feed. OpenAI’s February 3, 2026 explanation of feed operation further described filtering harmful, unsafe, or age-inappropriate material from teen accounts, with automated checks for policy compliance and feed eligibility complemented by human review. Feed filtering therefore operated in addition to the checks applied during video creation. (deploymentsafety.openai.com)
The application’s privacy and contact controls addressed risks that output filtering alone could not cover. Launch documentation specified stricter privacy defaults and limits on the use of teenagers’ likenesses. OpenAI also stated that teen profiles would not be recommended to adults and that adults could not initiate direct messages with teens. The first restriction concerned algorithmic discovery; the second concerned who could initiate contact, rather than constituting a blanket prohibition on all messaging. General likeness controls allowed users to determine who could use their representation and revoke that permission, while videos featuring their likeness—including other users’ drafts—were visible to them for review, deletion, or reporting. The launch announcement additionally committed to stricter likeness permissions for teens and expanded human moderation capacity to review bullying cases. (openai.com)
Parental controls were announced through ChatGPT rather than as changes to Sora 2’s audiovisual generation capabilities. At launch, OpenAI described default limits on the number of generated videos teenagers could view in the feed each day, alongside parental settings for overriding continuous-scroll limits, disabling algorithmic personalization, and managing direct messaging. Its accompanying safety announcement specified that parents could control whether teens could send and receive messages and select a non-personalized feed. The February 2026 feed documentation reiterated parental control over personalization and continuous scrolling. These settings governed exposure, recommendation, and communication within the consumer product: selecting a non-personalized feed changed content selection, while messaging and scrolling controls changed available interactions and browsing behavior. They were separate from the moderation thresholds determining which requested or generated material the system would block. (openai.com)
Evaluation, limitations, and world-simulation claims
OpenAI’s September 30, 2025 system card described external red-team testing by members of its Red Team Network. Testers attempted prohibited generation, policy-violating uploads, and safeguard bypasses, while also stress-testing product-level protections. Areas included sexual content, extremism, self-harm, violence, political persuasion, youth safety, and likeness use. Findings informed adjustments to prompt filters, blocklists, and classifier thresholds. The quantitative evaluation used thousands of adversarial prompts: outputs from a “helpful-only” model were graded and converted into automated tests of the production safety stack, which examined video frames, captions, and audio transcripts. (cdn.openai.com)
The card defined not_unsafe as unsafe-content blocking effectiveness, described as recall; not_overrefuse measured whether benign content avoided false blocking. Reported output scores were 95.10% and 97.00%, respectively, for violence and gore, and 99.70% and 94.60% for self-harm. These were company-reported safety-stack results, not independent measurements of audiovisual quality or physical accuracy. The two measures address different errors: allowing prohibited material through and rejecting permissible material. Neither should be read as the probability that an arbitrary generated video is safe. OpenAI explicitly acknowledged that policy violations could still circumvent its safeguards. (cdn.openai.com)
Claims about physical realism appeared separately in the launch announcement. OpenAI illustrated its claimed improvement with a missed basketball shot: rather than making the ball reach the hoop through an implausible transformation, the model could depict it rebounding from the backboard. Other demonstrations involved gymnastics, a paddleboard backflip, and a figure skater carrying a cat. These examples illustrated the company’s account of improved motion and physical plausibility; the announcement did not present them as a standardized physics benchmark with numerical scores. Its claims about preserving scene state across multiple shots likewise concerned generation capability rather than the safety measures above. (openai.com)
OpenAI nevertheless acknowledged frequent generation mistakes and described the model as imperfect. Its observation that some failures resembled mistakes by a depicted agent—for example, an unsuccessful action rather than a visibly broken physical rule—was an interpretation of model behavior, not evidence that all relevant dynamics were correctly represented. The announcement framed larger-scale training on video as a route toward more capable world models and, eventually, AI systems operating in the physical world. General-purpose world simulation was therefore a research ambition associated with Sora 2, rather than a capability established by either the published safety percentages or the selected demonstrations. (openai.com)
Discontinuation and historical documentation
On March 24, 2026, OpenAI notified developers that the Videos application programming interface (API), together with the Sora 2 model aliases and dated snapshots, had been deprecated and would be removed on September 24, 2026. The notice therefore distinguished the announcement of retirement from the termination of access six months later. The consumer service followed a separate timetable: the Sora web and app experiences were discontinued on April 26, 2026, before the developer API closed. These dates marked different stages of the withdrawal rather than a single shutdown affecting every interface simultaneously. (developers.openai.com)
The September 24 shutdown covered the Videos API and both model aliases, sora-2 and sora-2-pro. OpenAI’s deprecation table also explicitly named three dated snapshots: sora-2-2025-10-06, sora-2-2025-12-08, and sora-2-pro-2025-10-06. Each entry carried the same shutdown date, and every corresponding recommended-replacement field contained a dash. The retained video-generation guide subsequently confirmed that the models and API had been shut down and were no longer available, making clear that the September date was no longer merely a prospective deadline. (developers.openai.com)
For consumer-created material, OpenAI published an export arrangement separate from the discontinued creation and sharing interfaces. Its Help Center described a dedicated Sora sunset page with an Export control; an email would notify the account holder when the export was ready. The article expressly allowed exports after the app’s discontinuation. It also left open the possibility of a final export window, stating that users would receive advance notification by email if such a window was offered, rather than guaranteeing an additional period of access. (help.openai.com)
The accompanying data-governance policy stated that data associated with a person’s use of Sora would be permanently deleted after discontinuation and after any final export window had passed, if one could be provided. The published arrangement thus separated the end of service operation from eventual deletion; it did not specify a calendar date on which deletion would be completed. (help.openai.com)
OpenAI retained Video generation with Sora as historical documentation, with a prominent notice identifying its archival status and stating that no one-to-one replacement API was available. The page continued to contain model comparisons, endpoint descriptions, and code examples from the former service. Those retained instructions documented its previous interface and capabilities, not continuing access: examples invoking Sora models appeared beneath an explicit confirmation that the service had closed. (developers.openai.com)
References
- Video generation with Soradevelopers.openai.com
- Sora 2 System Card - OpenAI Deployment Safety Hubdeploymentsafety.openai.com
- Sora 2 System Cardcdn.openai.com
- Sora 2 Model | OpenAI APIdevelopers.openai.com
- Sora 2 Prompting Guidedevelopers.openai.com
- Sora 2 Pro Model | OpenAI APIdevelopers.openai.com
- Changelog | OpenAI APIdevelopers.openai.com
- Create batch | OpenAI API Referencedevelopers.openai.com
- C2PA Explainerc2pa.org
- C2PA FAQc2pa.org
- Sora 2 System Card — Specific Risk Areas & Mitigationsdeploymentsafety.openai.com
- Deprecationsdevelopers.openai.com