Captions are the product, not a setting

There is a version of an AI reel generator that stops one step early. It writes you a script, renders some footage, hands you an audio file and says: over to you. Everything it produced is real work, and none of it is postable. The last step — putting words on the screen, in time with the read — is the one that decides whether the thing gets watched.

The muted-scroll problem

Short-form video is mostly consumed with the sound off. People scroll in bed, in queues, in meetings they should be paying attention to. If the important detail of your reel — the open-house time, the price, the discount code — exists only in the audio, a large share of your audience never receives it. They see pretty footage, understand nothing, and keep scrolling.

That is not a captioning problem you can solve at the end. It changes what the pipeline has to produce. The script cannot be one blob of text that gets read aloud and also pasted on screen, because spoken language and written language are different registers. Nobody says "POV colon" out loud. Nobody writes a full sentence on screen when three words will do.

Three outputs, not one

So the script stage in ReelSeconds returns three separate things:

• The voiceover — natural spoken language, no hashtags, no stage directions, nothing a narrator would refuse to say.
• The on-screen hook — written-only, short, allowed to use the conventions of the feed.
• The visual prompt — a description of footage, with no text in the scene at all.

Keeping them apart is unglamorous plumbing, and it is the difference between a reel that reads like content and one that reads like a tool's output. It is also why the narrator in our examples never says "POV" while the frame does.

Timing you do not have to fix by hand

The second half of the problem is sync. The usual approach is to generate audio, transcribe it back with a speech-to-text model, and hope the transcript lines up. That round trip introduces exactly the errors it was meant to remove: names get mangled, timings drift a beat late, and someone ends up nudging caption blocks in an editor.

The voice stage here returns word-level timestamps alongside the audio. The captions ride on those timings directly. There is no re-transcription, so there is nothing to drift. The example reel on our home page carries 41 word-level timestamps across 8 caption lines, and none of them were touched after generation.

Why they are burned in

The last decision is the least popular one: captions are rendered into the video frame, not attached as a separate track. Platform auto-captions exist, but they are inconsistent between apps, sometimes off by default, and they take styling decisions out of your hands. A burned-in caption looks the same everywhere the file goes — including when someone downloads your reel and reposts it, which is the best thing that can happen to a listing.

The cost of that choice is that captions are not editable after the fact. If the wording is wrong, you re-run the reel. At ten credits a run, that trade is worth making: a reel you can post without opening an editor is worth more than a reel you can adjust in one.

The general rule

Every feature in this pipeline gets judged against one question: does it move the output closer to a file you can upload without further work? Word-level timing does. Burned-in captions do. A timeline editor, a library of transition effects and a model picker do not — they move the work back to you, which is the thing you were trying to avoid.

That is the whole design brief. Captions are not a setting on the way to a video. They are part of what makes the video finished.