A current Sora review has to begin with a fact that makes most older reviews obsolete. OpenAI discontinued the Sora web and app experiences on April 26, 2026. The company says the Sora API will be discontinued on September 24, 2026. There is no consumer product left to recommend, and the remaining API window is an exit period rather than a sensible starting point for a new workflow.
This article does not claim that HUMAI received early access, spent six weeks testing Sora, generated hundreds of clips, or measured a success rate. Those assertions cannot be verified and are excluded. The review below uses current OpenAI documentation, separates the retired app from the still-documented API, and gives existing API users a small test for planning their migration.
The source snapshot was checked on July 18, 2026. Shutdown dates and export instructions can change, so confirm them in OpenAI's Sora discontinuation notice before acting.
The verdict is now about shutdown, not video quality
For a person looking for a browser or mobile video generator, the answer is direct: Sora is no longer available as a product. Historical plan prices, generation allowances, regional rollouts, waitlists, and app features no longer help with a purchase decision. Repeating them would turn an update into an archive of expired terms.
OpenAI's current notice gives former app users an export route and recommends exporting promptly. It also says data associated with Sora use will be permanently deleted after discontinuation and any final export window. Someone who created work in the app should therefore treat asset recovery as the first task, not as a later cleanup item.
| Situation | Current reality | Action |
|---|---|---|
| Former web or app user | The consumer experiences closed on April 26, 2026 | Export your Sora content and verify the archive while the documented route remains open |
| Existing API team | OpenAI says the API closes on September 24, 2026 | Freeze new dependencies, measure the current workflow, and complete a replacement plan |
| New buyer | There is no durable Sora product to adopt | Do not start a production integration whose named service already has a shutdown date |
| Researcher or archivist | Product pages describe retired experiences and may retain historical wording | Record publication dates and distinguish past app behavior from current API documentation |
What the remaining API documentation actually supports
OpenAI's current video generation guide documents two model variants, sora-2 and sora-2-pro. It describes asynchronous jobs that can create a video from text, use an image as the opening-frame reference, reuse eligible non-human character assets, extend a completed clip, edit a clip, and submit offline render queues through the Batch API.
Those are vendor-documented capabilities, not evidence that a particular shot will pass a client's review. The same guide says a render can take several minutes and exposes queued, in-progress, completed, and failed job states. A production assessment needs to include failed jobs, retries, and time spent reviewing results. A polished sample on a documentation page cannot supply those numbers for another team.
The model choice also encodes a tradeoff. OpenAI positions sora-2 for faster exploration and sora-2-pro for higher-quality output, including the documented 1080p sizes. Both support 16- and 20-second generations. The guide advises using the smallest format that meets the job because longer and higher-resolution requests can take materially longer. An exit test should therefore keep model, size, and duration visible in every result row.
Output custody matters during a shutdown. The API guide says a completed video's download URL is valid for at most one hour. It gives Batch-generated videos a download window of up to 24 hours after the batch completes. If an asset is part of a real project, copy it to controlled storage promptly and retain the prompt, parameters, job identifier, review decision, and rights notes beside it.
Run an exit-oriented test with six controlled jobs
An existing API user does not need hundreds of speculative generations to learn what must be preserved. Six controlled jobs can reveal the workflow's dependencies. Define the pass condition before submitting anything. Then record the observed result without converting it into a universal score for Sora.
Start with one short baseline shot. OpenAI's prompting guide recommends treating a prompt like a cinematographer's brief. Specify the frame, subject, action, setting, lighting, and any audio cue. Keep one camera move and one subject action. Model, size, duration, and character references belong in request parameters rather than prose.
| Job | Change | Pass condition to define first | Evidence to retain |
|---|---|---|---|
| Baseline | One subject, one action, fixed camera, short duration | The requested subject, action, frame, and lighting are all recognizable | Prompt, parameters, job states, elapsed time, result, and review note |
| Variation | Repeat the baseline without changing the prompt | The output can differ, but it still clears the same written acceptance gate | Differences that create useful choice or extra correction work |
| Reference | Add an eligible image reference that matches the requested size | The first frame preserves the approved composition anchors | Reference rights, source file hash, output, and visible deviations |
| Motion | Add one timed action beat and one camera move | Both actions remain legible without a continuity-breaking event | Timing errors, unwanted objects, and frames requiring removal |
| Edit | Change one property of a near-pass result | The requested change appears while approved elements remain usable | Edit instruction, preserved elements, regressions, and review time |
| Failure path | Exercise the application's failed-job and expired-download handling safely | The system reports the state, avoids duplicate billing requests, and preserves an audit trail | Error payload, retry rule, operator action, and recovery result |
Use a binary pass for each prewritten criterion, then keep the reasons. A clip can pass composition and fail rights review. It can pass motion and still require too much human repair. One combined star rating hides those distinctions.
Record actual spend from the account's billing data rather than copying an old subscription price into the test. Separate generation charges from review and editing time. Also record how many stored assets, prompts, and application paths depend on Sora. That inventory is more useful for migration planning than an unsupported claim about how often the model succeeds.
Prompt for observable outcomes, then expect variation
The official prompting guide warns that the same prompt can produce different results. That makes repeated generation useful for measuring variance, but it does not justify publishing a success percentage without the prompts, parameters, sample size, acceptance rules, and rejected outputs.
A test prompt should name what a reviewer can see or hear. Replace "cinematic street" with a frame, surface, light source, palette, and camera movement. Replace "moves quickly" with a countable action that fits the clip. For dialogue, keep the line short enough for the selected duration. When a result is close, change one property in an edit instead of rewriting the entire brief.
Short shots make failures easier to locate. A team can join approved clips in an editor after generation, while a long scene can entangle identity, motion, dialogue, lighting, and camera continuity in one expensive review decision. The objective during a shutdown window is to expose dependencies and export usable components, not to prove that a retiring API can carry a new production pipeline.
Keep app history and current API restrictions separate
OpenAI's current API guide lists restrictions that should be checked before a test set is submitted. It says API generations must be suitable for audiences under 18, copyrighted characters and copyrighted music are rejected, real people cannot be generated, human-likeness character uploads are blocked by default, and input images with human faces are currently rejected.
Do not mix those rules with descriptions of the retired consumer app. OpenAI's March 2026 page about creating with Sora safely describes app-era consent controls for images of people, characters, feeds, direct messages, and sharing. The page now carries a notice that the Sora product is no longer available. Its app behavior is historical context, not permission to send the same material through the current API.
The same historical safety page says Sora videos included visible and invisible provenance signals and C2PA metadata. Those signals help, yet distribution still needs a disclosure and asset log. OpenAI's later provenance update explains that metadata can be stripped or lost through transformations. A distribution checklist should therefore preserve the original file, label synthetic footage where context could mislead, and avoid presenting a generated scene as evidence of a real event.
Rights review belongs before generation and again before publication. Record who supplied each reference, what permission covers it, whether the intended use is commercial, and who approved the output. A model accepting a request is not a legal clearance decision.
Finish the Sora exit before September 24
- Export former app data now. Follow OpenAI's current help-center route and verify that the delivered archive opens.
- Inventory every API dependency. Include create, retrieve, download, character, extension, edit, deletion, webhook, and batch paths actually used by the system.
- Copy required assets to controlled storage. Do not depend on short-lived download URLs or a final export period.
- Preserve reproducibility records. Keep prompts, parameter values, job IDs, timestamps, source hashes, review notes, and rights evidence without assuming the same output can be recreated later.
- Stop adding new Sora-only features. Route new development toward a maintained workflow and test the fallback with representative shots.
- Choose a cutover date before the official deadline. Leave time for failed migrations, billing reconciliation, archive checks, and removal of credentials or webhooks.
- Test the post-Sora state. Confirm that the application fails closed, labels unavailable functionality clearly, and does not keep submitting jobs after cutover.
The current Sora verdict is therefore narrow. A consumer should not pay for or wait for access to a product that has already been discontinued. An existing API team should use the remaining time to measure what its workflow depends on, preserve assets, and leave safely before September 24, 2026. That answer is less dramatic than a personal review, but it is the decision the current evidence supports.
