Inspiration
I have a GPU in my desk that sits idle most of the day, and I kept paying monthly for tools that did less than it could.
Every piece of the workflow was a different subscription. One service to generate video. Another to transcribe. Another to clean up the transcript. A fourth to make a thumbnail. Each one wanted $15-30 a month, each one wanted my footage uploaded to their bucket, and most of them charged per minute of output so experimenting was expensive by design. If you want to try six variations of a shot, six times the money.
The models these services run are, in a lot of cases, open weights. Wan, HunyuanVideo, LTX-Video, SDXL, Whisper. I could run them. The reason I wasn't running them is that there was no interface just a pile of scripts, each with its own arguments, its own environment, its own way of failing.
StudioLite is the interface. Everything in it runs on the machine in front of you.
What it does
Text or image to video, using local diffusion models. Story Mode plans a multi-scene film from a genre and mood, writes a screenplay, and renders each scene with narration and music. ReelForge does the short-form pipeline end to end: script, images, TTS, subtitles, ducked background music. Images Studio handles SDXL generation, editing, upscaling, and background removal. Then there's a transcription suite that does files, live microphone, and continuous OCR of whatever is on your screen.
Plus the unglamorous stuff you actually need constantly: trim, merge, compress, speed, GIF, thumbnail, stabilize, blur a face, overlay a logo.
Nothing leaves the machine. No account, no key, no metering.
How I built it
FastAPI backend, Next.js frontend, and a Streamlit UI that came first and never went away. That last part wasn't a plan so much as an accident I decided to keep Streamlit let me build twenty tools fast, but it fought me the moment I wanted real-time feedback on a long GPU job. So the Next.js UI got built for the creative workflows where responsiveness matters, and Streamlit kept the long tail. Both talk to the same Python engines. Two front-ends is more surface area than I'd choose on day one, but throwing away working tools to satisfy an architecture diagram is a bad trade.
Every heavy operation is a background job. Nothing blocks a request, because video generation can take minutes and FFmpeg jobs are unpredictable.
I built a lot of this with Codex, and the thing that made it work was not treating it as autocomplete. I kept the backlog in GitHub Issues and pointed Codex at the issue list with gh, then let it plan a batch and implement across both sides of the stack at once the job worker in api_server.py, the client binding in web/lib/api.ts, and the control in EditPanel.tsx. Those three files have to agree with each other or the feature silently doesn't exist, and keeping them in sync by hand is exactly the tedious work I'm bad at.
The part that surprised me was the verification. Codex ran a route-registration check, tsc --noEmit, and lint on changed files, then actually executed the new FFmpeg workers against a real MP4 instead of declaring victory at "it compiles." That caught a vidstab path bug on Windows that no static check would have found it only appeared when the worker ran for real.
I used GPT-5.6 for the release audit, which is a different kind of problem. Feature work tells you when it's wrong. License compliance doesn't.
Challenges
A font almost sank the whole thing. Getting ready to open source it, I ran the audit expecting a formality. The subtitle font I'd been burning into every video was "The Bold Font" Copyright (c) 2015 by Sven Pels. All rights reserved. Personal use only. Trademarked name. I'd shipped it in the repo. Not maliciously, just carelessly: I grabbed a font that looked right for captions and never checked. Swapped it for Anton under the SIL Open Font License. Ten minutes to fix, and it would have been a real problem if it had gone public unchecked.
That audit also turned up PyMuPDF under AGPL-3.0 and FFmpeg's LGPL/GPL split, both of which needed to be disclosed rather than buried. All of it is in THIRD_PARTY_NOTICES.md now.
VRAM is the constant enemy. Video diffusion memory scales with frame count, and consumer cards run out fast:
$$M \approx F \times H \times W \times C \times b$$
where $F$ is frames and $b$ is bytes per parameter. You can't shrink $F$ without shortening the clip, so the lever is $b$ INT8 quantization takes $b$ from 4 to 1 and makes the difference between a clip rendering and the process dying. StudioLite detects available VRAM and picks a strategy instead of asking the user to guess.
The screenshot debugging session that ate an evening. I needed panel screenshots for the README. Drove a headless browser, clicked through all eight panels, saved eight files and every single one showed the same panel. Tried a different click method. Same result. Eventually I checked the console properly and found the dev server's hot-reload socket was failing its handshake, so React was never hydrating. The page was rendered HTML with no JavaScript attached to it. My clicks were landing on nothing. Ran a production build, pointed the script at that, and all eight came out correct on the first try.
Classic. Two hours on the automation, and the automation was fine the whole time.
What I learned
The license audit changed how I think about "just use a dependency." I'd internalized MIT-or-Apache as the default and stopped reading, which is how a proprietary font ends up committed to a repo you're about to make public. Now I check before adding, not before releasing.
On working with Codex: the leverage came from the verification loop, not the code generation. Code that compiles is cheap. Code that's been executed against a real file is worth something. Pointing it at an issue tracker instead of feeding it isolated prompts also kept the work coherent it could see what the feature actually needed to touch.
And keeping the messy Streamlit UI around was the right call. It's not elegant. It works, people use it, and "we're rewriting it properly" is how tools die.
What's next
Closing the gap between the two front-ends so Next.js covers everything. Better scene continuity in Story Mode character consistency across cuts is still the hardest unsolved piece. And an installer, because right now setup assumes you're comfortable with Python environments, and that's a wall for the people who'd get the most out of this.
It's MIT licensed and open source. Contributions welcome.
Log in or sign up for Devpost to join the conversation.