How to build an AI subtitle generator for your business with OpenAI Codex

Rule of thumb: if you caption a handful of your own videos a month, do not build this. Rev’s 45 free minutes or Descript’s free hour covers you, and the rented models are more accurate than the one that runs in a browser. If you caption for clients, for a team or for other people’s uploads, the minutes are the bill, and owning the studio turns a meter into a fixed cost. The honest middle case is a product whose users need high accuracy on difficult audio, and there the right answer is to build the studio and swap in a larger speech model, accepting a longer first download in return.

* Unlike most apps in this catalogue, this one keeps large files: the videos people upload live in storage until you delete them. Supabase Free includes 1 GB of file storage and 5 GB of egress a month, and pauses a project after a week without activity. Pro, from $25/mo, includes 100 GB of storage and 250 GB of egress, then charges $0.0213 per GB stored and $0.09 per GB served, and keeps a daily backup for 7 days. A retention rule that deletes a video a month after its last export is the cheapest decision on this page.

Prices and rates from supabase.com, developex.com and learn.chatgpt.com, checked September 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   Write AGENTS.md before anything is scaffolded

   Codex loads AGENTS.md at the start of every task, so the rule that matters most on this build (transcription never leaves the browser) is loaded before any code exists to break it.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind and the Supabase JS client, and this project is a subtitle studio. Fix the vocabulary (videos, tracks, captions, exports) and record two standing constraints: transcription runs in the visitor’s browser through a Web Worker and is never sent to a server, and translation is the only call that leaves the app, through one server-side function. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore.

   The no-server-transcription line is the one worth writing down. It is a reasonable-sounding thing for any assistant to suggest later, and it would quietly reintroduce the cost this whole build exists to avoid.

2. 02

   Have Codex prove the speech model before anything depends on it

   One task, one throwaway page, one captioned clip. Read the change and then actually run it against a long video. This is the step where you learn what your practical ceiling is.

   PromptGet the speech model running in the browserCopy

   Add @huggingface/transformers and build a single throwaway page that proves in-browser transcription works end to end: pick a local video, press a button, and get a list of lines with start and end times. Run the model in a Web Worker, load onnx-community/whisper-tiny with device set to webgpu and fall back to wasm when WebGPU is unavailable, decode the audio in the browser and feed it to the model in thirty-second chunks, and report the model download and the transcription as two separate progress bars. When it works, tell me what you observe about the first-load time, memory, and how the browser behaves on a file over twenty minutes.

   Ask for observations, not just code. What you want out of this task is a number for your length ceiling and a feel for the first-load wait, and the only way to get either is to run the thing.

3. 03

   Have Codex write the schema and the storage rules, and read the SQL before it runs

   The data model is small and the rule is simple, which is exactly why it is worth reading rather than approving on trust. Everything later reads these tables.

   PromptWrite the data model and storageCopy

   Write the migrations for this app and show me the SQL before running it. A videos table owned by a user with the file’s storage path, duration and detected language. A subtitles table with one track per video and language holding its captions as timed segments plus a status and progress for translation. Tables for usage_tracking, activity_logs and system_settings, and a rate_limits table keyed by account and action. Create a private storage bucket for uploads with policies that let an account read and write only its own folder. Leave sign-in and row-level security for the next task, but design every table with an owner column so the rules will be one line each.

   Reading the SQL here costs ten minutes. Finding a track that was saved against the wrong video costs an afternoon.

4. 04

   Narrow permissions, then add sign-in, roles and the access rules

   This task touches authentication, which is exactly the kind of change worth scoping Codex down for rather than leaving whatever settings you use for routine edits.

   PromptAdd auth, roles and access rulesCopy

   This task touches authentication, so narrow your permissions to just this one. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session, a profiles row per account and a useUser hook. Add an app_role enum of visitor, user, admin and demo with a user_roles table kept off the account itself, since anything stored there is editable by its owner, plus a SECURITY DEFINER has_role function. Finish with row-level security on every table: a user reaches only their own rows, an admin reaches everything, and every insert and update carries an explicit WITH CHECK that the row is not being filed under someone else. Show me how to verify a second account gets nothing back for the first account’s videos.

   The ownership rule here is simpler than on most templates, which is exactly why it should be watertight. No complicated case exists to hide behind.

5. 05

   Give the editor its own task, and translation the next one

   The editor is the largest single piece of interactive code in the build. Keep it in one task and read what comes back. Translation is the first call that leaves the app, so it gets its own task with the key handling built in.

   PromptBuild the library and the editorCopy

   Build the library and the editor as one task. The library: an upload that stores the video in the bucket and creates its row, a list of the signed-in person’s videos with their status, and a detail page that runs the transcription from step 02 and saves the result as the video’s first track. The editor: the video playing above a horizontal timeline of captions, each draggable to retime and editable in place, with split and merge, keyboard shortcuts, undo and redo, and autosave shortly after the last change, all driven from one caption state so the timeline, the list and the preview never disagree. Add a styling panel whose changes show over the video immediately. Walk me through the state shape before you build the components on top of it.

   Asking for the state shape first is worth the extra round trip. Almost every timeline bug is a state bug, and they are far cheaper to catch in a description than in a diff.

   PromptAdd translation and exportCopy

   Add one server-side "ai" edge function that calls my AI provider with the key held in function secrets, refuses any caller without a valid session, and logs every call to usage_tracking with the account, the video and the token counts. Add a "Translate" action on a track: send its captions to that function ten at a time with their timestamps, ask for the same lines in the chosen language with the timestamps untouched, return immediately, write progress to the new track’s row as batches finish, and poll it from the editor. Then exports: a function producing .srt, .vtt and .txt from any track with no AI involved, and a captioned-video export in the browser that draws the styled captions over the video on a canvas and records a WebM. Tell me plainly what that export needs from the storage bucket, and what making the bucket public would mean for who can open a video by its link.

6. 06
   Destination

   Hand the last pieces to a cloud run, then test it yourself

   Rate limits, the admin console and the demo account are self-contained and well specified, a reasonable set to hand to a cloud run while you do something else, provided you read the change before it merges.

   PromptAdd limits, admin, demo, and testCopy

   Three remaining pieces, all self-contained. Rate limits of ten uploads, twenty transcriptions, thirty translations and fifty exports per account per hour, counted in the rate_limits table rather than in memory, with quota costs read from system_settings. An admin console over users, videos, usage and settings, reachable only by the admin role. And a demo role: any sign-up ending in @demo.com receives it automatically and a function wipes that account’s videos, tracks, logs and usage after an hour of inactivity. When they are in, run the app and take it end to end yourself: sign up as a demo account and caption a short clip, translate it, export a .srt and a captioned video, then sign up as a second real account and confirm it sees none of the first account’s videos, and fix whatever does not hold up.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks everything above it: the database service key and your AI provider key live on the server and nowhere else, which means never inside the app people download and never inside a repository. If either gets out, treat it as compromised and rotate it the same day.

Two questions decide this, and speed is not one of them. Does the plan allow commercial use, which Vercel’s Hobby tier does not. And does a link straight to one video open the editor for somebody who has never visited, because a link to a specific video is exactly what a person pastes to a colleague. The speech model does not touch your host at all: the browser fetches it from its own home on the first visit and keeps it.

Add one server-side "ai" function that talks to my AI provider, with the key held in server secrets and never anywhere the browser can reach, and make it refuse any caller who is not signed in. Then add a "Translate" action on a subtitle track: send the lines to that function ten at a time with their timestamps, ask for the same lines in the target language with the timestamps untouched, and save the result as a new track linked to the original. Return immediately, write progress to the track row as batches finish, and have the editor poll it so the person sees a bar rather than a spinner. Log every call with the account, the video and the token counts.

Change language detection to work from the first thirty seconds of the transcript rather than from the file name. Send that text to the ai function and ask for a two-letter language code, show the result in the editor as an editable field with a note saying it was detected, and use the person’s choice for translation from then on. Fall back to the file name only when no transcript exists yet.

Add a "Tidy captions" action that sends the track to the ai function and asks for the same lines with punctuation and capitalisation fixed, filler words removed, and any line longer than 42 characters split at a natural break, keeping every start and end time and never changing the meaning. Show the result as a proposal the person accepts or rejects line by line, and keep the original track untouched until they accept.

Add a panel on the export screen that sends the finished transcript to the ai function and returns a short summary, five to eight chapter markers with timestamps, and a handful of tags. Present all of it as editable drafts the person can copy, and let them regenerate any one part on its own without redoing the rest.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.