DEV Community: Reel Mint

Open source AI shorts generators: the repos worth running in 2026

Reel Mint — Fri, 06 Nov 2026 07:05:18 +0000

Most open source AI shorts generators fall into two families: faceless stock-footage pipelines and long-video clippers. Here are five on GitHub with the facts I checked today, what each one does and doesn't do, and where they fall down for code content.

Full disclosure first: I build ReelMint, a closed-source video studio for developers making vertical Shorts, so I have a stake here. This post is for someone who typed "open source ai shorts generator" into a search box and wants to know which repos are real, what they need to run, and whether any of them fit technical content. Stars, licences and last-commit dates below come from the GitHub API on 3 November 2026. Feature details come from each repo's README on the same day. I did not install or benchmark any of them, so I describe what they claim to do, not how well they do it.

What an open source AI shorts generator does (and doesn't)

The category splits into two families, and mixing them up is the most common mistake in search results.

Topic to video (faceless pipelines). You give a topic. An LLM writes a script, a TTS engine reads it, stock footage is matched to the sentences, captions are burned in, and an MP4 comes out.
Long video to clips. You give a podcast or a YouTube URL. Whisper transcribes it, an LLM picks highlight moments, and the tool crops them to 9:16.

What both families leave to you: editing a finished result, keeping a consistent brand look across videos, and judging whether the content is any good. Most also leave the publishing step half-built, and that last point matters more than it looks (see the YouTube policy section below).

The repos worth running (verified)

All figures below were read from https://api.github.com/repos/<owner>/<repo> on 3 November 2026. Star counts move daily, so treat them as a snapshot.

MoneyPrinterTurbo (harry0703/MoneyPrinterTurbo): MIT, Python, about 137,900 stars, last push 2 Nov 2026. It takes a topic or keyword and generates the script, matches stock footage, adds voiceover, subtitles and background music, and renders an HD video. The README lists a web UI and an API, Docker support (docker compose -f docker-compose.release.yml up, UI on port 8501), and LLM options including OpenAI, Anthropic, Gemini and DeepSeek. Edge TTS needs no key; other voice providers need their own. The README says the minimum is 4 CPU cores and 4 GB RAM with no GPU. It lists publishing to TikTok, Instagram and YouTube Shorts as a feature but gives no setup details, so check that part yourself before relying on it.

OpenShorts (mutonby/openshorts): MIT, Python, about 7,400 stars, last push 2 Nov 2026. This is the long-video family: it detects moments, reframes with face tracking, adds subtitles and can dub. It also has an AI actor tool and a title and thumbnail tool. Self-hosting is docker compose up --build, then you enter keys in Settings. The README names Gemini as required for the AI features, fal.ai for the AI actor shorts, ElevenLabs for voice and dubbing, and Upload-Post for social posting (TikTok, Reels, YouTube Shorts). It ships an MCP server, at localhost:8000/mcp when self-hosted. There is also a hosted version; the README lists a free plan of 20 minutes a month with a watermark and paid plans from $12 a month.

ShortGPT (RayVentura/ShortGPT): MIT, Python, about 8,100 stars, last push 10 Feb 2025. The repo describes itself as an experimental framework for YouTube Shorts and TikTok channel automation, covering script, voiceover, footage, captions and rendering. I am not calling it abandoned. I am reporting that the last push was in February 2025, and that the README says documentation is still coming. The README does not list required keys, though it names OpenAI, ElevenLabs and Pexels as technologies used.

AI-Youtube-Shorts-Generator (SamurAIGPT/AI-Youtube-Shorts-Generator): MIT, Python, about 5,700 stars, last push 3 Nov 2026. It is a long-video clipper pitched as an open source alternative to Opus Clip. Give it a YouTube URL and it uses Whisper, an LLM for highlights, and automatic cropping to produce ranked 9:16 clips. API mode needs a MUAPI_API_KEY; local mode needs an OpenAI or Gemini key plus ffmpeg. The README does not mention uploading to YouTube. It also promotes a hosted per-clip API from the same ecosystem.

MoneyPrinterV2 (FujiwaraChoki/MoneyPrinterV2): AGPL-3.0, Python, about 32,300 stars, last push 15 Sep 2026. It bundles several automations, including a scheduled YouTube Shorts automator, a Twitter bot and affiliate tooling, configured through config.json and requiring Python 3.12. The AGPL licence matters if you plan to run a modified version as a service. I could not confirm the upload credentials it needs from the README.

Comparison list

MoneyPrinterTurbo: topic to video, MIT, key for an LLM (Edge TTS free), stock footage, active as of 2 Nov 2026.
OpenShorts: long video to clips plus extras, MIT, Gemini required, optional fal.ai, ElevenLabs and Upload-Post keys, has an MCP server, active as of 2 Nov 2026.
ShortGPT: topic to video framework, MIT, last push Feb 2025, documentation incomplete.
AI-Youtube-Shorts-Generator: long video to clips, MIT, one API key (MuAPI, or OpenAI/Gemini in local mode), no upload described.
MoneyPrinterV2: multi-automation toolkit, AGPL-3.0, config-file driven, last push 15 Sep 2026.

I also looked for n8n and Make templates that wrap these steps. I did not verify any specific template well enough to list it, so I left them out rather than guess.

Automating YouTube Shorts: what YouTube's policy actually says

Developers asking about "youtube shorts automation" usually worry about getting a channel flagged. The relevant text is YouTube's channel monetization policies page, support.google.com/youtube/answer/1311392, which I read on 3 November 2026. A July 2025 update on that page renamed the policy from "repetitious content" to "inauthentic content".

What I took from it, in my own words. Automation and AI are not banned. The page says that if you use automated tools or templates, the final product still has to show your creative vision and give viewers educational or entertainment value. The things it names as a problem are content that looks made from a template, and AI content made with generic or unoriginal templates that gives the impression of mass production. Channels whose videos are interchangeable are described as not eligible to monetize. Note the scope: this is about eligibility for the YouTube Partner Program. Content that breaks the Community Guidelines is a separate matter and can be removed. I found no numeric threshold, such as a maximum number of uploads per day, and I won't invent one.

The practical reading for a pipeline: a script written by an LLM from a bare keyword, stock clips, a default voice and the same layout on every video is the pattern the page describes. A video built from your own repo, your own terminal output and your own explanation is not interchangeable with the next channel's. That is a judgement about the content, which no repo can make for you.

Where open-source pipelines fall down for technical content

The topic-to-video family matches stock footage to sentences. Ask it for a video about a Postgres index and you get b-roll of servers and someone typing, not the query plan. There is no step where a real code snippet, a terminal session or a chart is rendered as the visual. The long-video family has the opposite problem: it needs a long recording to exist already, and it crops talking heads, not syntax-highlighted code that must stay legible at 9:16.

Three more gaps show up for developers specifically. First, editing: when scene four has the wrong variable name, you re-run the pipeline or open the MP4 in a separate editor. Second, consistency: nothing carries a code theme, font or colour palette from one video to the next. Third, accuracy: an LLM writing narration over stock footage has nothing checking that the code on screen is the code being described, because no code is on screen. Our own take on the editing problem is in editable AI Shorts generators, and the content side is in YouTube Shorts for developers.

Where ReelMint fits (and that it isn't open source)

ReelMint is not open source. It is a hosted product; you cannot read or self-host the code. What it is: a Remotion-based render pipeline where every generated scene is editable in a visual editor, with code cards, terminal cards and chart animations as scene types. It is driven by an MCP server that Claude Desktop, Claude Code and Cursor can connect to, with 130+ MCP tools. It is BYOK, meaning you bring your own OpenAI, Anthropic, ElevenLabs and similar keys, and there is a free tier. It publishes to YouTube Shorts. Instagram Reels publishing is pending Meta App Review, so I am not counting it.

On time, the only number I will stand behind: on the MCP path, a 60 to 90 second reel took me 45 to 60 minutes elapsed, of which 10 to 20 minutes were hands-on. That is one person, the person who built it, so a newcomer will be slower.

When ReelMint is not the right pick

You need to read or modify the source, or run everything offline on your own hardware. Use MoneyPrinterTurbo or OpenShorts.
You have a long recording and want clips from it. Use OpenShorts or AI-Youtube-Shorts-Generator. That is not what we do.
You want zero-cost faceless channel output from a keyword and do not care about technical accuracy. A stock-footage pipeline is closer to that job.
You need a proof or equation animation. That is Manim territory, not ours.

Is there a free open source AI shorts generator?

Yes. MoneyPrinterTurbo, OpenShorts, ShortGPT and AI-Youtube-Shorts-Generator are all MIT licensed per the GitHub API on 3 November 2026, and MoneyPrinterV2 is AGPL-3.0. Free to use does not mean free to run: most need at least one LLM key, and some need voice, video or posting keys, billed by those providers.

Can I automate YouTube Shorts with an API?

Partly. OpenShorts documents a REST API and an MCP server, and MoneyPrinterTurbo documents API docs at port 8080 in its Docker setup. Both can generate clips programmatically. Uploading is a separate step handled by YouTube's own APIs or a service like Upload-Post, which OpenShorts uses. I did not test any of these end to end, so verify the upload path before building on it.

Will YouTube penalise auto-generated Shorts?

YouTube's policy page does not ban automation or AI. It says the final video still has to show your creative vision and have educational or entertainment value, and it describes template-made, mass-produced, interchangeable content as ineligible for monetization. It reads as a monetization policy, not a ban on uploading. I found no stated upload-volume threshold.

If your content is technical, the easier route to non-interchangeable videos is to put real code and real output on screen. You can try that with the code explainer Shorts maker on the free tier.

Originally published on reelmint.io.

How to add a video to your GitHub README (upload, GIF or thumbnail)

Reel Mint — Fri, 06 Nov 2026 07:04:56 +0000

There are three ways to put a demo in a README, and they behave very differently: one plays inline with sound, one autoplays silently, one is just a picture that links out. Here is how each works, the size limits GitHub documents, and what I could and could not verify.

If you want to add a video to a GitHub README, the short answer is: drag an .mp4 or .mov into a GitHub text box, wait for the link it gives you, and put that link in your README. The long answer is that there are two other routes (a GIF, or a thumbnail that links to YouTube or Loom), and the right one depends on whether you need sound, autoplay or a file bigger than 10 MB. I build ReelMint, a video studio for developers, so I have a stake in demo videos existing at all. This post is the how-to I wanted, with the limits checked against GitHub's own docs on 3 November 2026.

The three ways to add a video to a GitHub README

Upload the file directly. GitHub hosts it and shows a player with controls. Sound works, autoplay does not (more on that below).
An animated GIF. Embedded as an image, so it loops on its own, but it is silent and gets large fast.
A clickable thumbnail. A static image wrapped in a link to YouTube or Loom. It hosts nothing on GitHub and has no size limit you control, but the video plays on another site.

There is also a fourth, less useful option: committing the video file into the repository or attaching it to a release. I cover where that fits in the comparison section.

Method 1: upload the video file directly

GitHub's docs on attaching files say you can attach a video by dragging and dropping it into the comment box, and list the supported video formats as .mp4, .mov and .webm. After the upload, "the text field is updated to show the anonymized URL for the file". That page covers issues, pull requests and comments. It does not mention READMEs, so the README steps below combine the documented upload with what other maintainers have reported working.

The steps:

Open any GitHub text box that accepts attachments. A comment on an issue or pull request in your own repo is the safest one. Do not submit the comment.
Drag your .mp4 into it and wait until the text box shows a URL on github.com. Contributors on public repos report the form https://github.com/user-attachments/assets/ followed by a UUID. GitHub's docs only call it an anonymized URL, so treat that exact shape as observed rather than guaranteed.
Copy the URL, then paste it into your README on its own line, or inside a video tag.
Commit, then open the rendered README on github.com and confirm it shows a player. Check this in a private window too.

Either of these goes in your README.md:

https://github.com/user-attachments/assets/REPLACE-WITH-YOUR-UPLOAD-ID

<video src="https://github.com/user-attachments/assets/REPLACE-WITH-YOUR-UPLOAD-ID" controls width="720"></video>

The size limits are the part people get wrong. GitHub's docs state 10 MB for videos uploaded to a repository owned by a user or organization on a free plan, and 100 MB on a paid plan. Images and GIFs are capped at 10 MB, and other files at 25 MB. Note the wording: it is the plan of the repository owner, not of the person uploading.

Two behaviours worth knowing, both reported by maintainers rather than documented by GitHub. First, the asset URL is not a public link: one project found that a thumbnail linking straight to a user-attachments URL gave anonymous visitors a 404, because GitHub serves these only when embedded in rendered Markdown. Second, the HeyGen Hyperframes project tried an MP4 in a video tag, found GitHub strips autoplay and loop so it needs a click, and switched its README hero to an animated WebP image instead.

The docs also say files in public repositories can be accessed without authentication, while for private and internal repositories only people with access to the repository can view them. So an upload into a public repo's comment box is effectively public, even if you never submit the comment.

Method 2: animated GIF

A GIF is just an image, so it needs no special handling. Commit it to the repository and reference it with a relative path, which GitHub's docs recommend over absolute links for images in the repo:

![Demo of the CLI](docs/demo.gif)

<img src="docs/demo.gif" alt="Demo of the CLI" width="720">

The upside is real: it autoplays and loops without a click, and it renders everywhere Markdown does, including npm and package registries that drop video tags. The Hyperframes PR above noted that most non-GitHub renderers, npmjs.com among them, strip the video tag.

The downsides: no audio, a 256-colour palette that makes gradients and syntax highlighting look rough, and large files for anything longer than a few seconds. Because GitHub caps images and GIFs at 10 MB on upload, a long terminal session will not fit through the upload path, though a GIF committed into the repo is subject to the repository file limits instead: GitHub warns above 50 MiB and blocks files larger than 100 MiB.

If you are making the GIF from a terminal session, a tool such as vhs can write one directly. Its README lists GIF, MP4 and WebM as output formats and requires ttyd and ffmpeg on your PATH. More on that in the last section.

Method 3: clickable thumbnail to YouTube or Loom

This is the oldest trick and still the only one with no size cap: a normal image, wrapped in a normal link. The pattern is a Markdown image inside a Markdown link:

[![Watch the 60-second demo](https://img.youtube.com/vi/VIDEO_ID/hqdefault.jpg)](https://www.youtube.com/watch?v=VIDEO_ID)

Replace VIDEO_ID with the 11-character ID from your YouTube URL. I checked the img.youtube.com thumbnail URLs for hqdefault.jpg and maxresdefault.jpg against one public video today and both returned 200. maxresdefault.jpg is not generated for every video, so hqdefault.jpg is the safer default. For Loom, take a screenshot of the first frame, commit it to your repo, and use that path as the image, because I did not verify a stable public thumbnail URL for Loom.

What you give up is inline playback: the reader clicks, leaves GitHub and lands on the video site. What you get is a platform that handles hosting, streaming, captions and a link you can share elsewhere.

Which method should you use?

Short demo, sound matters, under your size limit: upload the file (Method 1).
A 5 to 15 second loop, no sound needed, must work on npm and elsewhere: GIF (Method 2). If it is too heavy, an animated WebP via an img tag is the alternative Hyperframes chose, though I did not test WebP support beyond their report.
Longer than a couple of minutes, or over your plan's cap: thumbnail link to YouTube or Loom (Method 3).
You need autoplay with a real video: none of the three reliably gives it as an MP4. Use a GIF or WebP.

On the fourth option: you can commit a video file to the repo, but a relative path in a video tag has been reported not to render in a README, and GitHub warns at 50 MiB and blocks above 100 MiB, with a recommended repository size of ideally under 1 GB. Release assets are a better home for large files, since each file can be up to 2 GiB with no limit on a release's total size, but the README link then points at a download, not an inline player. I did not test whether a release-asset MP4 plays inline, so do not count on it.

Making the demo video itself

Everything above assumes you already have a file. Three honest ways to get one:

Screen recording. Free, fast and exactly what happened. The cost is retakes and no way to fix a typo after the fact. We compared the options in best terminal recording tools for CLI demos.
vhs for terminal demos. You write a .tape file (Output demo.gif, Type, Enter, Sleep) and run vhs demo.tape, so the recording is reproducible and lives in version control. It is built for terminals, not for explaining architecture.
ReelMint for a narrated demo. You give it your README, it drafts a script, and each line becomes an editable scene such as a typed terminal, a code card or a diagram. An agent like Claude Code or Cursor can drive it over our MCP server at https://studio.reelmint.io/api/mcp, with 130+ MCP tools behind it. Our write-up turning a GitHub README into a demo video shows the flow, and the README to Short page is the product page.

When ReelMint is not the right pick

Plenty of the time it is the wrong tool. If you want a 10 second looping clip of one command running, record it with vhs or a screen recorder; that is faster and shows the real output. ReelMint produces a composed, narrated video, not a capture of your actual terminal, and it is built around vertical 9:16 Shorts, so for a widescreen README banner a screen recording is the better fit. Also, a first reel is not instant: our own measurement for a 60 to 90 second reel is 45 to 60 minutes elapsed, 10 to 20 minutes of it hands-on, from one person who built the product.

Where it does fit: a project with a story to tell in 60 to 90 seconds, a README that already works as a script outline, and a plan to publish the same video on YouTube Shorts as well as in the repo. You can try the free tier with your own API keys; see pricing.

Can a GitHub README autoplay a video?

Not reliably as an MP4. GitHub's docs do not document autoplay for video, and maintainers report that GitHub strips autoplay and loop from video tags in Markdown, so viewers have to click play. GIFs and animated WebP images, being images, do animate on their own.

What is the GitHub README video size limit?

GitHub's attaching-files docs set 10 MB for videos uploaded to repositories owned by a user or organization on a free plan and 100 MB on a paid plan. Images and GIFs are capped at 10 MB, other files at 25 MB. Files committed into the repo follow different limits: a warning at 50 MiB and a block at 100 MiB.

Should I use a GIF or an mp4 in my README?

Use an mp4 uploaded through GitHub when you need sound, sharper text or a longer clip, and accept that it needs a click. Use a GIF when you want a silent, instant loop that also renders on npm and other sites that strip video tags. For anything past a minute, link a thumbnail to YouTube or Loom instead.

If you are launching an open-source project, promoting an open-source project with a demo video covers what to do with the video once the README has it.

Originally published on reelmint.io.

Open source AI video generators, APIs and MCP studios: a developer's guide

Reel Mint — Fri, 06 Nov 2026 07:04:34 +0000

"AI video generator" means four different things to a developer. Here is how video-model APIs, programmatic render APIs, self-hosted open models and agent-driven studios differ, with prices and licenses I checked today.

Searching for an open source AI video generator, or any AI video generator for developers, turns up four different kinds of tool, and most roundups mix them into one list. A web search while I wrote this turned up API-vendor pages and listicles, but no guide that separates what you call, what you render from a template, what you self-host and what an agent drives. I build ReelMint, which sits in the last group, so I'll flag that where it matters and keep the comparison to things I could check today (3 November 2026). Prices below are list prices I read on each vendor's page that day; they move, so treat them as a snapshot.

What "AI video generator for developers" actually means (4 kinds)

The useful split is by what you hand over and what you get back.

A. Video-model APIs. You send a prompt or an image, a model returns a clip of a few seconds. Photoreal or stylised footage, billed per second or per clip. Examples: Runway, Luma, Kling and Google's models, plus hosts such as fal.ai and Replicate.
B. Programmatic render APIs. No generative model decides the pixels. You describe a video as JSON or code (text, images, clips, audio, timing) and a service renders it. Examples: Shotstack, json2video, Creatomate, Remotion Lambda.
C. Open-source generators you self-host. The same kind of model as group A, but the weights and code are yours to run on your own GPU. Examples: Wan, HunyuanVideo, CogVideoX, Open-Sora, LTX.
D. Agent-driven studios. An LLM such as Claude drives a whole video workflow (script, scenes, voice, render, publish) through tools, usually over MCP. ReelMint is in this group. We covered the idea in what MCP video generation is.

Groups A and C make clips. Groups B and D make structured videos where text, code and charts must be legible. Picking the wrong group is the most common mistake, so decide that before you compare vendors.

Video-model APIs

These are what most people mean by "text to video for developers" or "video generation api". You call an endpoint, poll for a job, download a clip. Three things I checked that change the picture from a year ago.

First, OpenAI's Sora API is gone. OpenAI's deprecations page lists the Videos API and the sora-2 and sora-2-pro models as removed on 24 September 2026, with no replacement listed. Any tutorial that starts with a Sora API call is out of date.

Second, Google's Veo previews in the Gemini API shut down on 22 October 2026. The Gemini API video docs list three Veo 3.1 preview models as shut down and recommend migrating to Gemini Omni Flash (gemini-omni-1.1-flash), pointing to the Gemini Enterprise Agent Platform for the GA Veo 3.1 models. The pricing page lists Omni Flash video output at $17.50 per 1M tokens and estimates roughly $0.10 per second of 720p video. I could not find a Veo per-second price there, so I am not quoting one.

Third, prices are now easy to compare on aggregators. Runway's API pricing sets a credit at $0.01 and lists gen4.5 at 12 credits per second ($0.12/s) and gen4_turbo at 5 credits per second ($0.05/s); it also resells other models (for example veo3.1 at 40 credits per second with audio, 20 without). On fal.ai, Kling v2.6 text-to-video is listed at $0.07/s and Kling v3 at $0.14/s, billed per output from prepaid credits. Replicate bills most public models by hardware time (an H100 is $0.001525 per second) and lists some video models per output second, such as wavespeedai/wan-2.1-i2v-720p at $0.25 per second. Luma has a public API with per-clip pricing at lumalabs.ai/api/pricing, but that page contradicted itself between its table and its FAQ when I read it, so check it yourself. Kling has a developer platform at kling.ai/dev but showed no prices to me.

What these are good for: B-roll, product shots, stylised scenes. What they are bad at: clips are short, text inside the frame is unreliable, and you pay again for every retake. For what a finished Short costs end to end, see what AI video generation actually costs rather than multiplying a per-second price by a guess.

Programmatic render APIs

This is the group developers underrate. If your video is data plus a layout (a changelog, a leaderboard, a code snippet, a per-user recap), you don't need a generative model at all. You describe the video and a renderer produces it, identically, every time. Searches for "programmatic video generation" land here.

Shotstack. You describe an edit as JSON and POST it to a render endpoint. Per its getting-started docs, the stage path is free with a watermark and the v1 path consumes credits. On its pricing page I saw pay-as-you-go at $10 once for 50 minutes (20 cents a minute) and Starter at $39 a month for 250 minutes.
json2video. Its tagline is "Send JSON, get an MP4". The pricing page shows a free plan of 600 credits with a watermark, and Professional at $49.95 a month for 12,000 credits, where one credit is one second of video.
Creatomate. Built around a REST API that turns a template into a video from one request, per its docs. I could not read dollar prices off its pricing page, so I'm leaving them out.
Remotion Lambda. Not a hosted product but a way to run Remotion renders on your own AWS account. Remotion's cost page gives a one-minute video example at $0.017 warm in us-east-1 for Lambda compute only, and tells you to measure your own composition. Remotion's license is source-available rather than a standard open-source one (GitHub reports it as "Other"), with a company license for larger for-profit teams, so read it before you commit. Our Remotion vs Manim post goes through the terms.

The trade: you design the layout yourself, and nothing in this group writes the script or the narration for you.

Open source AI video generators you can self-host

If you want group A's output without per-second billing, you run the model. I read each GitHub repo and its license through the GitHub API today:

Wan 2.2 (Wan-Video/Wan2.2): Apache-2.0, last commit 21 September 2026.
LTX (Lightricks/LTX-2): the LTX-2.x community license, not Apache. Its license file sets revenue thresholds, with $10,000,000 in annual revenue mentioned, so read it if you are a company. The older LTX-Video repo is Apache-2.0 but marked legacy and no longer under active development in its README. LTX-2 last commit 18 October 2026.
HunyuanVideo (Tencent-Hunyuan/HunyuanVideo): the Tencent Hunyuan Community License. It excludes the European Union, the United Kingdom and South Korea from its territory and requires a separate license above 100 million monthly active users. Last commit 8 October 2026.
CogVideoX (zai-org/CogVideo): code is Apache-2.0, but the README says the CogVideoX-5B weights carry their own license. Last commit 4 November 2025, so check it is still maintained for your needs.
Open-Sora (hpcaitech/Open-Sora): Apache-2.0, last commit 9 April 2026.

The honest cost of this group is a GPU and the time to operate it, which a license table doesn't show. "Open source" also varies a lot here, as the list above shows: two of five carry custom licenses that restrict some uses. If you are shipping a product, the license matters more than the benchmark.

Agent-driven video studios (MCP)

Group D flips the question. Instead of you calling an API from your code, your coding agent calls the tools. ReelMint is an MCP server at https://studio.reelmint.io/api/mcp that Claude Desktop, Claude Code and Cursor can drive, with 130+ MCP tools covering script, scenes, voice, render and publishing. Under it is a Remotion-based render pipeline, so scenes are real components (code cards, terminal cards, chart animations, character scenes), and every generated scene stays editable in a visual editor rather than coming back as a flat file. It is bring-your-own-key: you plug in your own model and voice keys, covered on the BYOK page, and there is a free tier on the pricing page. It publishes to YouTube Shorts; Instagram Reels publishing is pending Meta App Review.

For a measured number: on the MCP path, a 60 to 90 second reel took the founder (me) 45 to 60 minutes elapsed, of which 10 to 20 minutes was hands-on instruction. That is one person, who built the product, on one path, so a newcomer will be slower. Our guide to judging MCP servers for video lists the criteria I'd apply to any of them, ours included.

What this group is: a pipeline for narrated explainers and Shorts. What it is not: a source of photoreal footage.

How to choose

A decision list, in the order the questions usually resolve:

Pick A (video-model API) if you need generated footage: product shots, atmosphere, stylised B-roll. Budget for retakes and expect to composite text yourself.
Pick B (render API) if the video is data plus layout and must be identical on every run: changelogs, dashboards, per-user recaps. You can call it from a cron job or CI, and there is no model to drift.
Pick C (open source) if you have GPUs, volume that makes per-second billing hurt, or data you can't send out. Read the license for your use first.
Pick D (agent-driven studio) if you want an agent to take a topic to a narrated, editable Short with code, terminal or chart scenes, and you'd rather edit scenes than regenerate clips.

Most real projects combine two groups. A common pairing is a render API or Remotion for the structured parts and a video-model API for a few seconds of footage.

What ReelMint is not for

ReelMint is the wrong pick if you need photoreal people, product footage or cinematic shots: use a group A API (Runway, Luma, Kling) or a group C model. It is the wrong pick if you want a renderer you call from your own backend with a template per customer: Shotstack, json2video, Creatomate or Remotion Lambda are built for that. It is the wrong pick if you need on-premise generation with no third-party calls: that is group C. And it is aimed at vertical Shorts and explainers, so it is not the tool for long landscape video.

Is there a free AI video generation API?

Not a free generative one that I could verify. The free options I found are in the render group: Shotstack's stage sandbox is free with a watermark, and json2video's free plan gives 600 credits with a watermark. For free generative video you can self-host an open model, where the cost moves to your GPU.

What is the best open source AI video generator?

It depends on your license and hardware, and I can't honestly name one winner. On license alone, Wan 2.2 and Open-Sora are Apache-2.0 in their repos, while LTX-2 and HunyuanVideo use custom community licenses with restrictions. On recency, Wan 2.2, LTX-2 and HunyuanVideo each had commits within the last two months. Check the model card for the weights license, which can differ from the code.

Can I generate videos from a CI pipeline or a script?

Yes, with groups A, B and C. Render APIs such as Shotstack and json2video take a JSON description over HTTP, so a CI job can build a release-notes video on every tag, and Remotion Lambda does the same inside your own AWS account. Video-model APIs work the same way but add job polling and per-clip cost. Our changelog video guide shows the pattern for release notes.

Originally published on reelmint.io.

Code animation tool: five ways to animate code on screen for a video or a Short

Reel Mint — Fri, 06 Nov 2026 07:04:12 +0000

Making code move on screen splits into five different jobs, and most tools do only one of them. Here is a map of the options, what each exports, what I could verify today, and when a plain screen recording beats all of them.

Full disclosure: I build ReelMint, which makes vertical code Shorts, so I have a stake here. I went looking for a code animation tool that a developer could pick in ten minutes and found a search results page of small GitHub and itch.io projects plus stock-footage sites. No one had laid the options out by what they actually produce. This is that map. Every price and feature below was read from the tool's own page on 3 November 2026, and where a page did not say, I say so instead of guessing.

What a code animation tool actually needs to do

Four things separate a code animation from a code screenshot with a fade on it:

Typing or reveal: code appears in the order a person would write or read it, instead of arriving as a finished block.
Highlighting: a line, range or word is emphasised while the rest dims, so the viewer knows where to look.
Transitions between versions: when line 4 changes, the surrounding code shifts and the new text appears, rather than the whole snippet cutting to the next one. This is also what a code diff animation is.
An output you can use: an MP4 or GIF for a video, a vertical frame for a Short, or an embed for a slide deck.

A tool can be strong on one and absent on another. The five groups below differ mostly in which of these they give you for free and which you build yourself.

Five kinds of code animation tools

1. Browser animators and code screenshots. Carbon (carbon.now.sh) and ray.so (made by Raycast) turn a snippet into an image. Their pages describe images of code and neither mentions animation or video, so treat them as static. They are still useful as the input step: a clean code image is a fine starting frame. For animation in the browser, Snappify says it makes code presentations and animated videos, and also offers embeddable snippets, an API and VS Code and IntelliJ extensions. Its video export is labelled experimental, and its plan table lists MP4 and GIF export, though the page text I could read does not say which tiers include them. A tool called CodeMotion.dev was launched on Product Hunt in March 2024 as a one-click snippet animator with MP4 and GIF export, but the site at that address today describes a different product (an AI project-planning workspace), so I could not confirm it is still available as a code animator.

2. Code-first libraries. If you are comfortable writing a video as a program, four options handle code natively. Remotion has a Code Hike template that adds code snippets to a video and animates between them, with many languages, TypeScript error annotations and many themes; start it with npx create-video@latest --code-hike. Motion Canvas has a CodeBlock component whose edit method animates insertions, removals and replacements, shifting the surrounding code into place, and which dims unselected text by default; its repository's last commit was 2 July 2026. Manim Community Edition has a Code mobject that renders a listing with Pygments colours, an optional window-style background and line numbers on by default; I could not find a typing effect on that page. Reveal.js can animate code in a slide deck: give each version of a block the same data-id and enable data-line-numbers, and Auto-Animate transitions between them. For how the first three compare, see Remotion vs Manim.

There is also a small open-source CLI named CodeMotion (github.com/fay-saal/codemotion, MIT) that renders a source file as a typewriter video, or a git diff as a line-by-line red and green reveal, to MP4 or GIF. It had 2 stars and 3 commits when I looked, so read the code before relying on it, but the idea is exactly right for a code diff animation: codemotion diff app.js compares HEAD~1 to HEAD by default.

3. Terminal and typing recorders. If the thing you are showing is a command line, scripted recording beats animating it by hand. VHS from Charm reads a .tape file, emulates typing with Type, pauses with Sleep, sets size with Set FontSize, and outputs GIF, MP4 or WebM; it is MIT licensed and requires ttyd and ffmpeg. asciinema records a session and the agg tool converts the recording to an animated GIF (agg is GPL v3 or later, so check that suits you). We compared these in best terminal recording tools for CLI demos. This is the most direct answer to code typing animation when the code is a shell session.

4. Editors with text animation. ScreenFlow (Mac only) lists built-in text animations and a title library; its page shows a purchase price starting at $199 and a free trial that adds a watermark. Descript and CapCut are general editors. I could read Descript's pricing (a free plan, then paid plans starting at $16 a month on annual billing, or $24 monthly, as I read the page), but none of the three pages I fetched mentions syntax highlighting or code-aware transitions. That means you animate code here the way you would animate any text: paste a code image or text, then add a typewriter or wipe by hand. It works for one short snippet and gets slow for ten.

5. Agent-driven. The newest option is to describe the explainer to an AI agent and let it assemble the scenes. ReelMint does this for vertical Shorts: its code cards are syntax-highlighted, type, highlight and diff as scenes, with narration synced to the script, and every scene stays editable in a visual editor. An agent such as Claude Desktop, Claude Code or Cursor can drive it through an MCP server. There is also a free code card generator that makes a static PNG in your browser with nothing uploaded. Instagram Reels publishing is pending Meta review, so I will not promise it; publishing to YouTube Shorts is supported.

Comparison

Prices are as shown on each page on 3 November 2026. A dash means the page did not say, so I did not either.

Carbon: browser image tool. Output: image. Price: not stated on the page. Code-aware: highlighting yes, animation no.
ray.so: browser image tool. Output: image. Price: not stated on the page. Code-aware: highlighting yes, animation no.
Snappify: browser animator. Output: video (experimental), GIF and MP4 rows in plan table, image, embed. Price: free, $5, $9 and $32 a month on monthly billing. Code-aware: yes, animated slides.
Remotion Code Hike template: code-first. Output: MP4. Price: free for individuals and small companies, company license for larger for-profits (see /blog/remotion-vs-manim). Code-aware: highlighting yes, transitions between snippets yes.
Motion Canvas CodeBlock: code-first. Output: video via its editor. Price: open source. Code-aware: highlighting, insert, remove and edit animations, selection dimming.
Manim Code: code-first. Output: video. Price: open source (MIT). Code-aware: highlighting yes, typing effect not found on its page.
Reveal.js Auto-Animate: slides. Output: HTML embed. Price: open source. Code-aware: line-level transitions between matching blocks.
VHS: terminal recorder. Output: GIF, MP4, WebM. Price: free (MIT). Code-aware: terminal text, no diff.
asciinema + agg: terminal recorder. Output: GIF. Price: free (GPL). Code-aware: terminal text, no diff.
ScreenFlow: editor. Output: video. Price: from $199. Code-aware: no, text animation only.
Descript: editor. Output: video. Price: free plan, paid from $16 a month on annual billing. Code-aware: not stated.
ReelMint code cards: agent-driven. Output: vertical video, publish to YouTube Shorts. Price: free tier, then bring your own provider keys (see /pricing). Code-aware: highlighting, typing and diff scenes, editable.

Making animated code readable on a phone

Most code animation fails on a phone, not in the tool. Here are the rules I use; they are our house rules from making code Shorts, not figures from a study, so adjust them when your own retention data disagrees.

Cap the visible code. House rule: 12 to 18 lines on a 1080 by 1920 frame. If the snippet is longer, split it across scenes and show only the lines being discussed.
Set a font size you can read at arm's length. House rule: keep code text at or above roughly 40 px on the 1080-wide frame. In a terminal recorder this means raising the font setting (the VHS README example uses Set FontSize 46) rather than shrinking the code to fit.
Keep lines short. A line wider than about 30 to 35 characters at that size will not fit the width, so rename variables and break long calls before recording, not after.
Highlight, then explain. Dim everything except the line you are about to talk about, hold for the sentence, then move the highlight. Motion Canvas dims unselected text by default for exactly this reason.
Animate changes, not whole blocks. When a line changes, show the old text leaving and the new text arriving so the viewer sees what changed. Re-showing the full snippet makes them hunt for the difference.
Leave the platform's interface zones clear. Titles, captions and buttons cover parts of a Short, so keep code away from the very top and bottom edges.

Which code animation tool should you pick?

You need a one-off GIF of a command: VHS, or asciinema with agg.
You want an animated snippet for a talk or a post, with no code: Snappify, after checking which plan includes video export.
You want full control and already write TypeScript: Remotion with the Code Hike template, or Motion Canvas if you prefer a purpose-built animation timeline.
Your video is math or Python: Manim.
You present in a browser: Reveal.js Auto-Animate.
You want a narrated vertical Short about a snippet, with scenes you can edit afterwards, and you would rather describe it than program it: ReelMint code cards. Start with the code explainer Shorts maker, and see YouTube Shorts for developers for the format.

When a screen recording is better

Animation is the wrong tool when the viewer needs to see the real thing. A live debugging session, a walkthrough of a large codebase, a ten-minute tutorial that follows one project, or anything where the cursor moving through a real editor is the lesson: record the screen. ReelMint is not built for long screencasts; it is for short, vertical, narrated explainers, and it will not beat OBS or ScreenFlow at an hour-long course lecture. If you are making that, look at course creator workflows or just record. A good screen recording with clear zoom and a tight edit also beats a weak animation every time. Use animation when you want to control exactly what the viewer sees and when.

How do I animate code typing for a video?

For a terminal, write a VHS tape file with Type and Sleep commands and output MP4 or GIF. For a source file, use a code-first tool: the Remotion Code Hike template, Motion Canvas's CodeBlock edit method, or a hosted animator like Snappify. If you do not want to program it, a ReelMint code card types the snippet as a scene and syncs it to narration.

What is the best free code animation tool?

It depends on the output. For terminal demos, VHS is free and MIT licensed. For code in a video, Motion Canvas and Manim are open source, and Remotion is free for individuals and small for-profit teams (check its current licence). Snappify has a free plan, but I could not confirm from its page which export formats it includes. ReelMint has a free tier with bring-your-own keys.

Can I animate a code diff?

Yes. Motion Canvas's edit, insert and remove calls animate a change between two versions of a block, and the Remotion Code Hike template animates between snippets. The small CodeMotion CLI renders a git diff as a line-by-line red and green reveal. In ReelMint, a code card can show a diff as an editable scene.

Originally published on reelmint.io.

Motion Canvas vs Remotion: which one should you build video with?

Reel Mint — Fri, 06 Nov 2026 07:03:51 +0000

Generator functions and signals on one side, React components and frames on the other. A head-to-head on the axes that decide it, with the same small scene sketched in both.

Motion Canvas vs Remotion is a question that comes up when you want to write video as code and have narrowed it to two TypeScript options. Full disclosure: I build ReelMint, which is built on Remotion, so I have a stake. I checked both projects' repositories, docs and licenses on November 3, 2026, and I mark below what I did not run myself. Short version: Motion Canvas is an animation tool with its own timeline model and editor, Remotion is React rendered frame by frame to video. They overlap less than the search results suggest.

What each one is

Motion Canvas is, in its own docs' words, a tool for building animations in code. You write scenes as generator functions and the animation plays as you yield instructions. It works with TypeScript or JavaScript, the guide recommends TypeScript, and the quickstart scaffolds a project with npm init @motion-canvas@latest. Its GitHub repository is MIT licensed.

Remotion is a framework for making video with React. A video is a component that reads the current frame and returns markup, and Remotion renders it by stepping through frames and encoding the result. Anything the browser can draw is available: HTML, CSS, SVG, canvas, npm packages.

Mental model: generator functions and signals versus components and frames

In Motion Canvas you describe a sequence of events. You add nodes to the view, hold references to them with createRef, and yield* tweens one after another. To run things at once you wrap them in all(). Values that change over time live in signals created with createSignal, and a text node can take a function so the label updates whenever the signal does. The scene reads like a script: do this, then this, then these two together.

In Remotion nothing persists between frames. Each frame is a pure function of useCurrentFrame(), and you express motion as math on the frame number, usually with interpolate() or spring(). There is no sequence of events to write; there is a picture for every frame number. If you know React this is familiar. If you think in timelines, the Motion Canvas model will feel closer to how you plan an explainer.

The practical consequence: sequencing (A, then B, then A and C together) is easy in Motion Canvas and takes deliberate offsets in Remotion, where you place Sequence components or compute frame ranges. Layout, data-driven UI and reusing existing React components go the other way.

A worked example: a counter ticks up and a bar grows over 3 seconds

Motion Canvas first. This is a sketch built from the patterns on the official docs pages (generators, createRef, createSignal, all, tweening a signal). I did not run it, and import paths have changed between major versions, so check the current docs before pasting:

import { makeScene2D, Rect, Txt } from "@motion-canvas/2d";
import { all, createRef, createSignal } from "@motion-canvas/core";

export default makeScene2D(function* (view) {
  const count = createSignal(0);
  const bar = createRef<Rect>();

  view.add(
    <>
      <Txt fill="white" fontSize={120} text={() => Math.round(count()).toString()} />
      <Rect ref={bar} y={160} height={40} width={0} fill="#3b82f6" />
    </>,
  );

  yield* all(count(100, 3), bar().width(600, 3));
});

The same scene in Remotion, also unrun. It is a 90-frame composition at 30 fps, and extrapolateRight: "clamp" is the option shown in the interpolate() docs for holding the end value:

import { AbsoluteFill, interpolate, useCurrentFrame } from "remotion";

export const CounterBar = () => {
  const frame = useCurrentFrame();
  const opts = { extrapolateRight: "clamp" } as const;
  const count = interpolate(frame, [0, 90], [0, 100], opts);
  const width = interpolate(frame, [0, 90], [0, 600], opts);
  return (
    <AbsoluteFill style={{ background: "#0b0b0f", alignItems: "center", justifyContent: "center" }}>
      <div style={{ color: "white", fontSize: 120 }}>{Math.round(count)}</div>
      <div style={{ marginTop: 40, height: 40, width, background: "#3b82f6" }} />
    </AbsoluteFill>
  );
};

// <Composition id="CounterBar" component={CounterBar} width={1920} height={1080} fps={30} durationInFrames={90} />

Look at the shapes. The Motion Canvas version states intent: count to 100 and grow the bar to 600 wide, both over 3 seconds, together. The Remotion version states a mapping: for every frame between 0 and 90, here is the number and the width. Remotion is longer here, but the pattern does not change when the bar becomes a chart, the number becomes a styled code block, or the scene becomes a phone-shaped layout.

Editor and preview

Both ship an editor. Motion Canvas runs its editor at localhost:9000 after npm run serve; it previews the animation and updates when you save a file. Remotion Studio opens with npx remotion studio, lives in the @remotion/cli package, and is described in the docs as allowing fast editing and playback of compositions. I did not benchmark either for hot-reload speed, so I won't rank them. The difference I can state from the docs is the unit being edited: Motion Canvas edits an animation timeline, Remotion Studio plays compositions that are React components.

Output and rendering

This is the clearest difference in output. In the Motion Canvas rendering docs, clicking RENDER saves each frame as an image to the project's output folder, as PNG, JPEG or WebP, and the page suggests converting frames to video with a tool like ffmpeg or importing the sequence into a video editor. The page does not describe a built-in video export, so check the current docs and release notes in case that has changed.

Remotion renders video directly. npx remotion render <composition-id> <output-location> uses the H.264 encoder by default, and --codec accepts h264, h265, av1, vp8, vp9, prores and audio-only codecs such as mp3, aac and wav. Audio follows the same split. In Motion Canvas you import an audio file in project.ts, set the audio property in makeProject, and shift it with audioOffset (seconds); the docs page does not say how audio is exported. In Remotion you place the file in public/ and add an audio component with staticFile(), trimming and volume are props, and the audio ends up in the rendered file.

If your end product is an MP4 for YouTube Shorts, Remotion has fewer steps between code and finished file. If your end product is a frame sequence you will composite elsewhere, Motion Canvas is already there.

Licensing

Motion Canvas: the GitHub API reports an MIT license on the repository (checked November 3, 2026). Remotion is source-available with a two-tier license. The LICENSE.md in the Remotion repository says you are eligible to use it for free if you are an individual, a for-profit organization with up to 3 employees, a non-profit or not-for-profit organization, or evaluating it without yet using it commercially. Larger for-profit organizations need a company license. The file also says the license will change slightly in Remotion 5.0. Read the current terms on Remotion's license page before committing a team. I'm not a lawyer and this is a pointer, not advice.

Maintenance and community

Numbers from the GitHub API and web checks on November 3, 2026:

Motion Canvas (motion-canvas/motion-canvas): 19,662 stars, 177 open issues, not archived, MIT. Latest commit July 2, 2026 (a docs domain update). Latest GitHub release: v3.17.2, published December 14, 2024. motioncanvas.io returned HTTP 200.
Remotion (remotion-dev/remotion): 70,298 stars, 191 open issues, not archived. Latest commit November 3, 2026. Latest release: v4.0.540, published November 2, 2026.

Note that GitHub's open-issue count includes pull requests, so treat both figures as rough. I am not drawing a conclusion from the dates; they are what a reader can check themselves. If you plan to build a lot on either, read the recent commits and release notes.

Is Motion Canvas still maintained?

As of November 3, 2026, the motion-canvas/motion-canvas repository is not archived, motioncanvas.io responds, the most recent commit was on July 2, 2026, and the latest GitHub release is v3.17.2 from December 14, 2024. Those are the facts I could verify. Check the repository's recent activity yourself for the current picture.

Is Motion Canvas free for commercial use?

The repository carries the MIT license according to the GitHub API, and MIT permits commercial use with the license notice kept. Read the LICENSE file in the version you install, and note that this covers the code, not any fonts, audio or footage you put in a project.

Can I use Motion Canvas with React?

Motion Canvas scenes are written in TSX, so the syntax looks like React, but they are not React components. Scenes are generator functions that build nodes like Txt and Rect, and they render to a canvas, not the DOM. I did not find a documented way to drop an arbitrary React component into a scene, so if you need your existing React components in the video, Remotion is the direct route.

Motion Canvas alternatives if it's not for you

Remotion, if you want React components, layout work and a direct MP4 render.
Manim, if the content is math or geometry. See our Manim alternatives roundup, and our Remotion vs Manim comparison for the Manim side in detail, including Motion Canvas vs Manim.
Tools built on Remotion, if you want a pipeline rather than a framework. A Claude Code workflow is covered in our Claude Code and Remotion post.

Which should you pick?

You think in sequences and want an animation-first timeline: Motion Canvas.
You think in React components and layout: Remotion.
You need a finished MP4 with audio from one command: Remotion. A frame sequence you finish elsewhere is fine: Motion Canvas.
You are a for-profit company above 3 employees: read Remotion's company license terms first. Motion Canvas is MIT.
You want an LLM to write the scenes: see below.

On agent-friendliness, I have no measurement of which one a model writes correctly more often, and I won't invent one. What I can point to is documentation: Remotion's docs include a section on prompting videos with coding agents and a set of Agent Skills installed with npx skills add remotion-dev/skills, as I confirmed in the Remotion vs Manim post on October 31, 2026. I did not look for an equivalent for Motion Canvas on November 3. Whichever you pick, run the code and look at the frames; generated animation code often needs a pass. Generator-based tweens and signals are also a smaller, newer API surface, and the import-path changes between versions are a place an agent can go wrong.

Where ReelMint fits

ReelMint is built on Remotion. It adds a visual editor for every generated scene and an MCP server at https://studio.reelmint.io/api/mcp that Claude Desktop, Claude Code and Cursor can drive (130+ MCP tools; see /mcp). You bring your own provider keys (BYOK), there is a free tier, and it publishes to YouTube Shorts. Instagram Reels publishing is pending Meta App Review, so I won't promise it. Its strengths are code cards, terminal cards and chart animations for developer Shorts.

It is not the right pick for math or academic animation. There are no equation-morphing primitives. For that, use Manim. And if you want frame-level control of an animation as code, with an animation-first timeline, Motion Canvas or Remotion directly will serve you better than a higher-level tool. For a typical 60 to 90 second reel through the MCP path I measured 45 to 60 minutes elapsed, of which 10 to 20 minutes is hands-on; that is one measurement by the person who built it.

Originally published on reelmint.io.

Remotion alternatives: what to use instead, depending on why you're leaving

Reel Mint — Fri, 06 Nov 2026 07:03:28 +0000

People search for a Remotion alternative for four different reasons, and the right answer changes with each one. Here are the real options, with repo facts and license terms checked on 3 November 2026.

Disclosure first: I build ReelMint, and ReelMint is built on Remotion. Our render pipeline is Remotion underneath, so I am not selling you a way out of it. What I can offer is a map of why people look for a Remotion alternative and what exists for each reason, including the cases where the honest answer is a different tool, or Remotion itself.

Everything with a date below was checked on 3 November 2026 against the live repository, license page or pricing page. Where I could not check something, I say so. For the Python and math side of this question, I won't repeat myself: see Remotion vs Manim and the Manim alternatives roundup.

Why people look for a Remotion alternative

Four reasons cover nearly every case I have seen, and they point to different tools:

License. Remotion is free for some users and paid for others, and a company that grows past the free tier needs a plan.
No React. Remotion videos are React components. If your team writes Python, Go or plain TypeScript, that is a tax on every video.
Need a GUI. You want to drag a clip, fix a typo in a title and re-export, without opening a code editor.
Need an agent or an API. You want Claude Code, Cursor or a backend job to produce videos, ideally without owning a render farm.

Speed and render cost sometimes make a fifth reason. I have not benchmarked any of these tools against each other, so I won't rank them on it. Measure on your own hardware with your own scene.

Is Remotion free for commercial use?

Often yes, not always. As of 3 November 2026, the LICENSE.md in the Remotion repository says you are eligible for the free license if you are "an individual", "a for-profit organization with up to 3 employees", "a non-profit or not-for-profit organization", or "evaluating whether Remotion is a good fit, and are not yet using it in a commercial way". It adds that "a company license is required for for-profit organizations of a certain size".

Remotion's own pricing page, read the same day, words it as "individuals and companies up to three people" for free, and a Company License for "collaborations and companies of 4+ people". It lists two paid tracks: Remotion for Creators at $25 per month per seat, and Remotion for Automators at $0.01 per render with a $100 per month minimum. The LICENSE.md also says the license will change slightly in Remotion 5.0. Read the current terms at remotion.dev/docs/license before you commit a team. I am not a lawyer, and this is a pointer, not advice.

Remotion alternatives by reason

If the problem is the license: a Remotion open source alternative

Two code-first tools are MIT licensed. Motion Canvas is a TypeScript animation tool with a browser editor for previewing and syncing to audio. We compared Motion Canvas with Remotion head-to-head. On 3 November 2026 the motion-canvas/motion-canvas repository showed 19.6k stars, an MIT license, was not archived, and its latest commit was 2 July 2026. Revideo describes itself as a rendering engine for creating videos in code, with a headless render API and a React player for previews. Its repository (now at midrender/revideo) showed 4.2k stars, an MIT license, and a latest commit on 15 July 2026.

Both use a generator-function style: you write scenes as TypeScript that yields animations in order, instead of React components keyed to a frame number. That is a different mental model, not a drop-in replacement. Porting a large Remotion project means rewriting it, so this route suits new projects more than migrations. Commit dates are not a health report. Check each project's open issues before building a business on it.

A different way to read the license problem: for a lot of teams, paying is fine. Remotion's terms exist to fund the project, and the paid tracks above are priced per seat or per render. Compare that against the engineering cost of switching before you assume free is cheaper.

What is the best Remotion alternative that doesn't need React?

It depends on what you are making. For TypeScript without React, Motion Canvas and Revideo are the closest code-first options. For a declarative, no-code-framework approach, Editly assembles a video from a JSON5 spec or a small JavaScript API on top of ffmpeg. Its repository showed 5.6k stars, an MIT license and a latest commit on 12 May 2025, so it is stable rather than fast-moving. For Python and math content, Manim, covered in the posts linked above.

If you want no framework at all, scripting ffmpeg directly is always available. It handles cuts, overlays, subtitles and concatenation well, and it gets painful the moment you want animated layout, because ffmpeg has no layout engine.

If you need a GUI: timeline editors and template APIs

Code-first tools make a poor fit when a non-developer must edit the result. There are two honest families. The first is template-based video APIs such as JSON2Video and Creatomate: you design a template, then fill it with data over an API. JSON2Video's pricing page listed, on 3 November 2026, a $49.95 one-time pack of 7,200 credits described as up to 120 minutes of rendered video, and a free entry tier of 600 credits. Creatomate listed a monthly Essential plan with 2,000 credits and a 50-credit trial. I did not read the full fine print of either, so confirm what a credit buys for your resolution before you budget.

The second family is After Effects with Lottie export. Lottie is a playback format for vector animation, not a general video renderer, so it fits UI motion and small loops, not a 60-second narrated explainer. The airbnb/lottie-web player showed 32.3k stars and an MIT license on 3 November 2026. Theatre.js (Apache-2.0, 12.8k stars) is a motion design editor for the web rather than a video encoder, and its latest commit was 14 August 2024, so treat it as a tool for animating in the browser, not an off-the-shelf video pipeline.

If you need an agent or an API: keep Remotion, change who drives it

Here the answer is often not to leave Remotion at all. Remotion's docs have a page on prompting videos with coding agents, naming Claude Code, Codex, Kimi Code and OpenCode, with an install step of npx remotion skills add. A coding agent can write Remotion compositions today.

What an agent loop still lacks is a persistent project: scenes you can read back, patch one at a time, preview and re-render without regenerating the whole file. That is the gap ReelMint fills. It keeps Remotion rendering underneath, exposes 130+ MCP tools at https://studio.reelmint.io/api/mcp that Claude Desktop, Claude Code and Cursor can drive, and keeps every generated scene editable in a visual editor. It runs on your own provider keys (BYOK) and has a free tier. If you want the wiring, see connecting Claude Code to a video pipeline and what MCP video generation is.

Comparison list: language, license, last commit, output

All figures from GitHub's API and each project's own pages on 3 November 2026. "Last commit" is the repository's most recent push date.

Remotion: TypeScript and React. Source-available with a company license above the free tier (terms above). 70.3k stars, latest commit 3 Nov 2026. Output: video and images, any dimensions.
Motion Canvas: TypeScript, generator scenes. MIT. 19.6k stars, latest commit 2 Jul 2026. Output: video through its editor and render pipeline.
Revideo: TypeScript, generator scenes, headless render API. MIT. 4.2k stars, latest commit 15 Jul 2026.
Editly: JSON5 or JavaScript on ffmpeg. MIT. 5.6k stars, latest commit 12 May 2025. Output: video or GIF at any dimensions, including 9:16.
Manim Community: Python. MIT. 42.2k stars, latest commit 2 Nov 2026. Output: landscape by default, math-focused.
Theatre.js: TypeScript, in-browser editor. Apache-2.0. 12.8k stars, latest commit 14 Aug 2024. A motion editor, not a video encoder.
JSON2Video and Creatomate: hosted template APIs, usage-priced, closed source.
ReelMint: MCP server and visual editor on a Remotion render pipeline. Free tier, BYOK. YouTube Shorts publishing is available; Instagram Reels publishing is pending Meta App Review.

Which Remotion alternative is right for you?

License is the blocker and you write TypeScript: try Motion Canvas or Revideo on a small project before committing.
You do not want React and you assemble clips: Editly, or ffmpeg directly.
Non-developers need to edit the output: a template API, or a tool with a visual editor.
You want vector UI motion rather than video: Lottie.
You want an AI agent to produce vertical Shorts you can still edit: ReelMint, or Remotion plus a coding agent if you are happy owning the React project.
Your content is math: Manim, per the posts linked at the top.

Can an AI agent drive Remotion?

Yes. Remotion documents the workflow itself, and I covered a hands-on version in Claude Code and Remotion for motion graphics. The limit is not whether the agent can write the code but whether the result stays maintainable: a one-shot generated composition is hard to patch scene by scene. A persistent, tool-driven project helps there, which is the job of an MCP server rather than a prompt.

When Remotion is still the right call

Stay on Remotion if you already write React, your team is within the free license or happy with the paid one, and you want full frame-level control. It has the largest community of the code-first tools above by star count, and its latest commit was the day I wrote this. Nothing on the alternatives list gives you its component model and web ecosystem together. And if you only want a finished Short, with no code ownership, ReelMint is the wrong pick for some people: a template API or an editor-first tool will get a non-technical user there with less setup. Our fit is developers who want an agent in the loop and an editable result. Start from the code explainer Shorts maker or the pricing page and judge for yourself.

Originally published on reelmint.io.

Asciinema alternatives: what you lose and gain with each one

Reel Mint — Fri, 06 Nov 2026 07:03:01 +0000

People look for an asciinema alternative because of one missing thing, not because asciinema is bad. Here is each replacement sorted by the thing you are actually after (video, GIF, SVG, a repeatable script or a narrated Short), with output format, OS, license and last-commit date checked on 3 November 2026.

I build ReelMint, a video studio for developers making vertical Shorts, so I have a stake in terminal demos. I also use asciinema, and I am not trying to talk you out of it. If you searched for an asciinema alternative, you almost certainly hit one specific wall: you needed a video or a GIF and got a text recording. This post sorts the alternatives by which wall you hit. For a wider comparison of recording tools in general, our roundup of terminal recording tools for CLI demos covers the field; this one is narrower and about replacing asciinema specifically.

Everything below with a date was checked against the tool's GitHub repository or README on November 3, 2026. Where I could not confirm something, I say so instead of guessing.

What asciinema does well, and the three things people replace it for

asciinema is a terminal session recorder and streamer. Its README describes recording to a lightweight text-based asciicast file, for example asciinema rec demo.cast, and it can also live-stream a session. As of November 3, 2026 the repository is active (last commit October 27, 2026), written in Rust, and licensed GPL-3.0. It runs on GNU/Linux, macOS and FreeBSD, and the README says Windows is not supported.

That text-first design is the reason it plays back crisply at any size. It is also the source of the three common reasons people leave:

No video output. The README contrasts asciinema with screen recorders that produce heavyweight .mp4 and .mov files. It records .cast, not video. Neither the README nor the CLI docs page I read mention an MP4 or GIF export.
No editing step. The docs pages I read describe recording, streaming and playback, not editing. If a take goes wrong, the path I could verify is to record again.
Dependence on the player. A .cast file plays in the asciinema web player, which the docs say you can use on any HTML page. That works for docs and READMEs that allow JavaScript. It does not help on a platform that wants a video file, which includes YouTube, LinkedIn and most social feeds.

The alternatives, sorted by the job you need done

Pick the job first. The tools below fall into four groups, and most of the comparison is about which group you are in.

Job one: keep asciinema, add a GIF. agg is the asciinema project's own GIF generator. It converts asciicast v1, v2 and v3 recordings to animated GIF, using the gifski encoder, with built-in color themes, adjustable fonts, playback speed and an idle-time limit. It outputs GIF only. If your only complaint was that a README does not play a .cast, this is the smallest change that fixes it, and you keep your recording workflow.

Job two: a repeatable script that renders GIF, MP4 or WebM. VHS from Charm is the strongest answer to the no-video complaint. You write a .tape file (Type, Enter, Sleep, and Set for font and size), run vhs demo.tape, and get the output you declared. Its README lists GIF, MP4, WebM and a PNG frame sequence, and prebuilt binaries for Linux, macOS and Windows. It needs ttyd and ffmpeg on your PATH, or you can use its Docker image. Because the session is scripted rather than recorded live, the same tape gives the same result each time, which also makes it easy to regenerate in CI.

# demo.tape
Output demo.mp4
Set FontSize 28
Set Width 1200
Type "npm install -g yourtool"
Enter
Sleep 2s

# render it
vhs demo.tape

Job three: record a real session and get a GIF, with themes. terminalizer records a session to a YAML file, then renders it as an animated GIF or a web player, on Linux, Windows and macOS. The caveat is maintenance: its last commit was August 29, 2024, and its README says it expects Node.js v4 to v16 and that GIF compression is not implemented. That is not a verdict that it is broken, only what I could verify. t-rec takes a different approach and screenshots the terminal window (or another window) at 4 to 15 fps, producing a GIF and optionally an MP4. It runs on macOS, Linux, NetBSD and, in preview, Windows, and depends on ImageMagick. Its last commit to the default branch was July 8, 2026, a preview release.

Job four: an SVG animation. termtosvg records a session as an SVG animation. The repository is archived on GitHub, with its last commit on June 16, 2020, so treat it as finished. It suits a sharp, small README animation if you accept an unmaintained tool; otherwise pick agg.

Plain screen recording. OBS or QuickTime pointed at a terminal window gives you any video file, with no new tool to learn. The trade-off is that it is one take of pixels at your window's size and aspect ratio, so a typo means a re-record.

Terminal built-ins. I looked for a recorder in iTerm2 and Warp worth listing here, and could not confirm either well enough to compare them fairly, so I am leaving them out rather than guess.

Comparison: format, OS, license and last commit

One line per tool. Dates are the latest commit on the default branch as of November 3, 2026.

asciinema: output: .cast text recording (no video); OS: Linux, macOS, FreeBSD; license: GPL-3.0; last commit: 2026-10-27.
agg: output: GIF from asciicast; OS: I could not confirm a list (installs via Cargo or Docker); license: GPL-3.0; last commit: 2026-10-27.
VHS: output: GIF, MP4, WebM, PNG frames; OS: Linux, macOS, Windows; license: MIT; last commit: 2026-09-24.
terminalizer: output: GIF or web player; OS: Linux, Windows, macOS; license: MIT; last commit: 2024-08-29.
t-rec: output: GIF, optional MP4; OS: macOS, Linux, NetBSD, Windows (preview); license: GPL-3.0; last commit: 2026-07-08.
termtosvg: output: SVG animation; OS: not checked; license: BSD-3-Clause; repository archived, last commit: 2020-06-16.
OBS / QuickTime: output: any video file; OS: varies by app; license: varies by app; no repository checked.
ReelMint terminal scene: output: a vertical video project published to YouTube Shorts; web app plus an MCP server; hosted product, free tier, bring your own AI keys.

Which asciinema alternative should you pick?

You want a GIF in a README and already use asciinema: add agg.
You want MP4 or WebM, or the demo regenerated on every release: use VHS.
You must capture a real session, including a TUI, and want a GIF: try t-rec or terminalizer, and check their maintenance dates above first.
You want a small SVG animation and accept an archived tool: termtosvg.
The destination is a phone-sized video with a voiceover: none of the recorders above reflow a desktop terminal into 9:16, so see the next section.

Is there an asciinema alternative with narration or captions?

Not among the recorders I checked: their documentation describes terminal output, not narration, and I found no captions feature in any of them. For a narrated terminal clip, the usual route is to record or script the terminal, then add voice and captions in a separate video editor.

That gap is the one ReelMint is built for. Instead of recording a shell, a terminal demo scene takes the command and the output as text, types them out on a 9:16 canvas, and sits alongside narration in the same editor. Because the command is text, fixing a renamed flag is an edit and a re-render. It also means nothing from your real shell, such as a stray key or hostname, can end up on screen. You can drive it from Claude Desktop, Claude Code or Cursor over an MCP server, and it publishes to YouTube Shorts. It runs on your own provider keys (BYOK) with a free tier.

When ReelMint is the wrong pick, and when to just keep asciinema

ReelMint does not record. If the point of your clip is proof that something really ran, such as a benchmark, a live deploy or an interactive TUI responding to keystrokes, you need a real recorder: asciinema, VHS or a screen capture. A typed scene can only show what you tell it to show.

If your demo lives in documentation, keep asciinema. A .cast file is small, text-based, copyable and plays at any size in the web player. For a README that needs to run on GitHub, where scripts do not execute, add agg for the GIF rather than switching tools. Move on only when the destination changes to somewhere that demands a video file.

Can asciinema export to mp4 or gif?

Not by itself, as far as the README and CLI docs I read show. asciinema records .cast files. The asciinema project publishes a separate tool, agg, that converts those recordings to animated GIF. For MP4, the closest direct option in this list is VHS, which renders from a script rather than from a .cast file.

What is the best asciinema alternative for a GIF in a README?

It depends on whether you already have recordings. If you do, agg turns an asciicast into a GIF without re-recording. If you are starting from scratch and want it regenerated on every release, VHS can output a GIF from a .tape script and is actively maintained (last commit September 24, 2026). For an animated, vertical, narrated version of the same demo, see how to turn a README into a demo video.

Originally published on reelmint.io.

How to turn a GitHub README into a demo video (without hiring an editor)

Reel Mint — Wed, 29 Jul 2026 14:54:17 +0000

Your README already contains the script. Here's the approach that turns it into a watchable 60-second demo from editable scenes — and the place it quietly falls apart.

Your README already contains the script. The install command, the quickstart, the one API call that shows what the project does — that's the outline of a good 60-second demo. The hard part was never the words. It was turning them into something watchable without booking an editor or fighting a timeline for an afternoon.

Here's the approach that works, and the place it quietly falls apart.

Why the README is the right source

Most “make a video from text” tools start from a blank prompt, so you get generic filler — a smooth voice saying nothing your project actually does. A README is the opposite: it's specific. It names the real command, the real flag, the real function. If you ground the script in it, the video says what the repo says, not what a model guessed.

That grounding is the whole trick. Point the generator at the README (or paste it in), and the script should come back with your actual install command, your actual import, your actual quickstart — not “simply install the dependencies and get started in seconds.” When it drifts into that kind of language, that's your signal the grounding isn't working and you're back to filler.

The shape of a good repo demo

Sixty seconds, roughly four beats:

The problem, in one line. What does this exist to fix? The README's first paragraph usually already says it.
Install. One command, shown as a terminal that types itself out.
The one thing it does. The quickstart — the smallest example that proves the point — as a syntax-highlighted code card, not a screen recording of your editor.
Where to go next. Docs link, GitHub stars, the install command again. Two seconds, then out.

The reason to render these as components rather than screen-record them is boring but important: a screen recording of a terminal is unreadable on a phone, and it's frozen the moment your CLI changes. A typed-out terminal component and a code card are legible at 9:16 and editable after the fact.

A worked example: a CLI in four beats

Take a concrete shape: a command-line tool that tails logs from several servers at once. Its README has an install line, a quickstart, and a GIF nobody can read on a phone. The four beats become:

Hook: “You're still SSHing into three boxes to read one request's logs.” The problem line, addressed to the viewer, lifted almost verbatim from the README's first paragraph.
Install: the one npm command as a terminal scene that types itself, holds on the success line for a beat, and moves on. Four seconds.
The one thing: the quickstart command, then the payoff — merged, colorized output — as a second terminal beat. If your payoff is config or code rather than output, it's a code card instead.
Out: “Docs and repo below.” The install command on screen one more time, then end. No outro music, no subscribe animation.

Notice what isn't in it: your face, a screen recording, an intro. A README demo is a proof, not a vlog. The fastest version that shows the thing working beats the polished version that shows you. If you catch yourself planning a thumbnail before you've proven the quickstart on screen, you're making the wrong video first.

The hook is the only genuinely hard part

Everything else in the four beats is transcription — the README already wrote it. The hook is the one line the README doesn't contain, because READMEs open with what a project is, and a Short has to open with why anyone should care. The patterns that work for dev tools are unglamorous: the problem stated as something the viewer is doing right now (“you're still…”), a before/after (“this deploy took 40 minutes; this one takes 2”), or a specific number that raises a question. The pattern that fails is the feature list — “X is a fast, lightweight, extensible…” — because it answers a question nobody asked yet.

Spend your editing time there. If you rewrite one thing the generator drafted, rewrite the first line. A decent mechanical check: read the hook alone, with no context — if it doesn't raise a question a stranger would want answered, it's a description, not a hook.

Grounding, mechanically

In ReelMint the grounding isn't a vibe, it's a step. Connect the repo's docs — or paste the README — as a knowledge-base source, and script generation searches it before writing a line, so the draft quotes your actual command instead of inventing one. A script check runs before anything renders: hook strength, duration against your target, phrasing your narrator will trip on. And any scene can be previewed as a three-frame film strip — start, middle, end — in seconds, so you catch the wrong flag while it's still text.

None of that requires an agent — it's the same pipeline from the web editor. But if you live in a terminal anyway, the whole loop is driveable from Claude Code over MCP: point it at the repo, ask for the four-beat draft, and review the scenes it proposes.

The part that saves you later

Here's the difference that matters six weeks from now, when you rename a flag or bump a version. If the demo was a recording, it's stale and you re-record. If it was built from editable scenes, you open the one scene with the old command, fix the text, and re-render. The video tracks the repo instead of rotting away from it.

That's also why “one afternoon” collapses to “about an hour — ten to twenty minutes of it yours.” You're not performing a take; you're reviewing a document that happens to render as video.

Keeping it alive after you ship

Publish is where a repo demo usually dies: it goes on the channel, the repo moves on, the video rots. Two mechanics change that. Re-publishing an updated render replaces the existing YouTube video instead of uploading a duplicate — so the link in your README and the view count both survive the fix. And because the scenes hold text, “update the demo for v2” is a diff-sized edit, not a production.

If the project ships on a cadence, the video can too: a Short per release, drafted from the changelog, is exactly the dull, regular work worth handing to an agent — with you approving each draft before it goes anywhere. Releases become a series rather than one orphaned demo, and the channel compounds the same way the repo does: one small, correct addition at a time.

Where it honestly falls apart

Two failure modes, stated plainly.

The first: a thin README makes a thin video. If your README is three sentences and a badge, there's nothing to ground a script in, and no tool fixes that — you'll get something generic because the source was generic. Write the README first; the video is downstream of it.

The second: the demo is not a substitute for the real thing. A code card is the right way to show an API call, but if your project's whole value is an interactive UI, a component-built explainer only takes you so far — at some point you want a real screen recording of the actual product, and that's a different tool. Be honest with yourself about which kind of project you have.

This space is also getting crowded fast — there are now several tools that read a repo and spit out a video (a couple are genuinely good). The differentiator worth caring about isn't “can it generate a video,” it's “can I edit the fourth scene without redoing the other three.” That's the question to ask any of them.

Why sixty seconds, and why vertical

Because that's where the audience is that hasn't already starred your repo. A landing-page video reaches people who found you; a Short reaches people who didn't — Shorts and Reels are recommendation surfaces, and a sharp problem-line hook is exactly the kind of thing they test in front of strangers. The format constraints are real, though: 9:16 means a terminal can show one command legibly, not a tmux session; sixty seconds means one idea, proven once. Treat the constraints as an editor. If your demo doesn't fit, that's usually the demo trying to be a tutorial — make the tutorial too, separately, and let the Short do the one job of making someone curious.

And once it exists, spend it: embed it on the repo page, link it from the release notes, put it in the docs' getting-started. The same sixty seconds that works as a Short is the best above-the-fold answer to “what is this project?” you'll ever ship.

Doing it

If you want to try the editable-scenes version: point the studio at your README, let it draft the four-beat script, then open each scene and make it true — fix the command, swap the snippet, tighten the hook. Render when it's right, publish to your channel. The README did most of the work; you're just making sure the video didn't round off the details that make your project yours.

Originally published on reelmint.io.

AI Shorts generators you can actually edit (not a black box)

Reel Mint — Wed, 15 Jul 2026 05:59:44 +0000

The question that decides whether an AI video tool is worth it isn't “how good is the first result” — it's whether you can fix the third scene without redoing the other four. Here's how to tell the two apart.

Every AI Shorts generator demo looks good, because the demo is the one video where nothing went wrong. The real test comes ten seconds later, when the third scene has last quarter's number in it, or the wrong command, or a name spelled the way the model guessed instead of the way you spell it. What you can do at that moment — fix the one thing, or regenerate the whole video and hope — is the entire difference between tools. It's worth choosing on that, not on the demo.

Two kinds of “AI video,” and only one lets you edit

Under the marketing, AI video tools fall into two camps. The first hands you a finished file — baked pixels. You typed a prompt, it rendered an MP4, and every frame is now flattened together. If something's wrong inside it, there is no “inside” to open; there's just the file. The second builds a project — scenes, text, timing, data that stay separate — and only turns it into a video when you say so. The first is a black box. The second is editable. Both call themselves “AI video generators,” which is why the label tells you almost nothing.

The distinction sounds academic until the first time you need a small fix on a video that's otherwise fine. With baked pixels, “change one word” means regenerate — new prompt, new roll of the dice, and now the parts that were good might come back different too. With an editable project, you open the scene, change the word, re-render, done. Same video, one correction.

The five-second test

You don't need to try a tool to know which camp it's in. Ask what happens after it generates:

Can you open a single scene and change just that scene, or is the output one MP4? If there's no scene list, it's a black box.
When you fix something, does the rest of the video stay exactly as it was, or does “regenerate” re-roll everything? Editable tools keep what you didn't touch.
Is the text real text you can retype, or pixels baked into the frame? A code snippet or a chart label you can't select is a snippet you can't correct.
Six weeks from now, when a version number or a flag changes, do you edit the old video or re-record it? Editable projects track your source; recordings rot.
Can you see the steps — script, scenes, render — as separate things, or just a “generate” button and a spinner? Visible seams are what let you, or an agent, catch a mistake before it's baked in.

A tool that answers “one MP4, regenerate, baked pixels, re-record, one button” isn't bad — it's a black box, and you should know that going in. A tool that answers the other way is editable, and it costs you a little more up front (there are scenes to look at) in exchange for never being trapped by your own output.

Why this matters more for technical content

If you're making a lifestyle montage, baked pixels are mostly fine — nobody pauses to check whether the B-roll is accurate, because there's nothing to be accurate about. Technical content is the opposite: the details are the point. A demo of an API with the wrong endpoint is worse than no demo. A chart with the axis mislabeled is a chart that lies. A terminal showing a command that doesn't exist teaches the wrong thing.

That's the case where “regenerate the whole thing” stops being an inconvenience and becomes a wall. You can't ship a video that's 95% right when the 5% is a wrong flag, and you can't fix the 5% if the tool only speaks in finished files. So the editable-versus-black-box split matters most exactly where AI video is otherwise most useful: explaining code, tools, and data, where being correct isn't optional.

The honest case for black boxes

We build an editable tool, so treat this with appropriate suspicion — but black boxes genuinely win some jobs. If you want fifty near-identical clips and you don't care about any single one being exactly right, a generate-and-post pipeline is faster and you should use it. If your content has no facts to get wrong — vibes, trends, a face talking over stock footage — editability is overhead you'll never cash in. And a black box gets you to a first result faster, because there's nothing to review; that's a real advantage when the goal is volume, not any particular video.

The tradeoff is simple to state. Black boxes optimize for the first video being fast. Editable tools optimize for the hundredth video, and every correction after the first, being cheap. Pick the one whose math matches the work you actually have.

What “editable” looks like when it's real

Concretely, in our studio a scene isn't a clip — it's layers you can open: a background, the animation, the text, the timing, each independently editable right up to the moment you render. The text in a code card is real text, not pixels; the numbers in a chart are your data, not a picture of data. Change the command in scene three and scenes one, two, and four don't move. That's the property the whole thing is built around: a fix is never a redo.

It's also what makes agent-driven video safe to leave running. When an AI agent drives the pipeline over MCP, it's proposing edits to a project you can inspect — not handing you a sealed render and asking you to trust it. You, or the agent under your review, can reopen any scene. The agent removes the tedium of assembling forty small pieces; you keep the pen on the details that have to be right.

How to tell, in your own case

Point whatever tool you're weighing at something real — a README, a CLI you want to demo, a feature you want to explain — and generate one video. Then try to change exactly one thing in the middle of it without touching the rest. If you can, it's editable, and it'll keep earning that back every time your content changes. If you can't, you've got a black box, and now you know to save it for the jobs where that's fine.

The generating was never the hard part. Plenty of tools generate. The one worth keeping is the one you can still fix at 11pm the night before it ships.

Originally published on reelmint.io.

Best MCP servers for video (2026): how to actually judge one

Reel Mint — Wed, 15 Jul 2026 05:59:43 +0000

You searched for the best MCP server for video expecting a ranked list. Here's why a list would mislead you — and the handful of criteria that let you judge any of them, including the one that launches next week.

You probably came here for a leaderboard: server A beats server B, pick the winner. I'm going to give you something more useful and less flattering to write, because a ranked list of MCP video servers is wrong the day after it's published. This space barely existed a year ago and several servers launched through 2026; by the time a “top 5” post is indexed, the order has changed and half the capability claims are stale. Worse, most “best X” posts are affiliate pages wearing a lab coat.

So instead: the criteria that actually separate a real MCP video server from a thin wrapper. Learn these once and you can judge any server yourself — ours included — without trusting anyone's ranking.

First: is an MCP server even what you want?

Be honest about this before comparing anything. An MCP server earns its keep when video is one step in a workflow you already drive from an agent — Claude Code, Cursor, Claude Desktop — and you want the agent to make the video without you leaving that workflow. If you just want to make a video and you're not living in an agent, a plain web app is often the better tool, and no amount of MCP changes that. (If the term itself is fuzzy, start with what MCP video generation actually is, then come back.)

Does it expose the pipeline, or a single “generate” tool?

This is the fastest tell. Open the server's tool list. A thin wrapper around a text-to-video model exposes one or two tools — “generate_video” in, a file out. A real pipeline exposes the seams: draft the script, author scenes, pick a voice, render, publish — each a separate tool the agent calls in order. The difference matters because an agent can only intervene where there's a seam. One giant “generate” tool gives it nothing to correct; a pipeline lets it fix scene three without redoing the video.

Does each tool return state you can inspect, or just “success”?

Ask what a tool hands back when it finishes. If it returns “ok” and an id, the agent is flying blind — it can't tell that a scene rendered wrong, so it sails past the mistake. If it returns the real thing (the scene contents, a preview, the lint result), the agent can catch its own errors the way you would. This is the single most important property of an agent-driven tool, and it's invisible until something goes wrong. We learned it the hard way building ours: our first tools returned “success,” and the agent happily marched past broken scenes because it had nothing to notice with.

Is the output an editable project, or a baked file?

The same question that separates any AI video tool applies here. When the agent finishes, do you get scenes you can reopen and correct, or a finished MP4 where a wrong flag means regenerate-and-pray? For technical content this is decisive, and it's worth its own read. An MCP server that returns baked pixels is a black box with a protocol bolted on.

Who owns the publish step?

Look at how it publishes. The right shape is: the agent stages a draft to your own channel, and you approve. The wrong shape is an agent that posts on its own, or one that publishes to somewhere you don't control. “Drafts overnight, you approve in the morning” is the boundary that makes the whole thing safe to leave running — the agent removes the tedium, you keep the last decision.

Bring your own keys, or locked to their models?

Check whether you supply your own model and voice keys or you're locked to the vendor's stack at the vendor's margin. Bring-your-own-keys means you pick the models, you see the real cost, and there's no markup hiding in a per-video credit. It's also a decent proxy for whether the company trusts you with the internals or wants you dependent on a black box.

Does it actually work in your client today?

MCP is young. A server can look great in a README and still be fussy to connect in Claude Code, Desktop, or Cursor, because client support is real but still settling. Before you commit, connect it and run one small thing end to end. A server that's a pain to connect is a server you won't use.

The one tell that cuts through all of it

If you only do one thing: look at the tool list and the return values. A thin wrapper shows one or two tools that hand back a file. A real pipeline shows many named tools that hand back editable artifacts. Everything above is downstream of that one distinction — seams you can inspect and edit, versus a sealed box with a nicer label.

Where we stand, honestly

We build ReelMint this way, so score us against our own criteria and hold us to them. The pipeline is exposed as separate tools; each returns the real state so the agent can catch its own mistakes; scenes stay editable, not baked; publish stages a draft you approve; it's bring-your-own-keys with no markup. Where we're rough: MCP is young and client support is still settling, so the exact connect step differs a little between Claude Code, Desktop, and Cursor, and you'll occasionally meet a tool schema that's fussier than it should be. That's the honest state of the whole category right now, not just us — it's early, which is exactly why it's a good time to learn the criteria rather than trust a ranking.

How to judge one in ten minutes

Skip the reviews. Connect the server to an agent you already use, ask for one small thing — a Short from a README, a demo of a CLI — and watch the tool calls scroll by. Count the tools. Read what they return. Try to change one scene without redoing the rest. You'll know more about whether a server is real from that single run than from any comparison post, this one included.

Originally published on reelmint.io.