Claude Code Motion Graphics: What Actually Works in 2026

Search for how to build motion graphics with Claude Code and you'll find the same five steps repeated across a dozen posts: scaffold a project, install the agent skills, describe your animation in plain English, preview, render. Every one of them is correct, and every one stops right where the actual questions begin.

What is in those skills? What do the setup commands quietly not do? When you hand a client a rendered file, what does the licence allow? And what does a project like this actually cost once you're past the demo?

Those are the questions that decide whether this workflow holds up on real work. Here are the answers, verified against the source docs rather than repeated from other blog posts.

Claude Code Motion Graphics: What It Actually Is

The first thing to get straight: Claude Code can invoke rendering commands, but Remotion supplies the video renderer in this workflow.

It writes React and TypeScript. Remotion — a source-available framework for making videos in React — turns that code into frames and encodes them into an MP4. Claude Code is the author; Remotion is the renderer. They're different layers, and conflating them is why people get confused about what's actually being automated.

So the honest description of this workflow is not "AI makes motion graphics." It's "you describe an animation, an agent writes a software project, and a React framework renders it." Everything good and everything frustrating about the approach follows from that.

That framing matters because it sets your expectations correctly. You are not operating a timeline. You're maintaining a small codebase — components, a design system, a render command. People who enjoy this workflow are almost always people who found that framing appealing rather than disappointing.

The pipeline itself is short:

prompt → React component → Remotion Studio preview → render → MP4

Which raises the real question: why does an agent need special teaching to write a React component?

The Real Enabler Is Not the Model

This is the part most guides skip. Remotion publishes an official set of agent skills — structured instructions that teach a coding agent how the framework actually works — and they give the agent framework-specific instructions to follow.

The reason is a missing assumption. Ask a capable model to animate something and it will reach for CSS transitions and @keyframes, because that's how animation works on the web. In a frame-by-frame renderer, those are exactly the wrong tools. The agent isn't lacking knowledge; it's lacking a constraint nobody gave it.

The skills supply that constraint. The remotion-dev/skills repository ships twelve of them, and the list is a good map of what actually goes into a video project:

Install them inside your project directory:

npx skills add remotion-dev/skills

The remotion-markup skill is the one that earns its keep. It's where the timing and animation rules live — the constraints that stop an agent writing animation that previews correctly and renders wrong. If you've already hit that wall, the failure modes and their fixes are covered in detail in Claude Code Animation Not Working? The Real Fix.

The practical upshot: install the skills before you write the first prompt. Retrofitting them means unwinding a codebase built on the wrong assumptions.

💡 Tip: The skills are just files. Open them and read the ones relevant to your project — you'll pick up the framework's rules faster from remotion-markup than from most tutorials, and you'll write better prompts as a result.

Setting It Up

The scaffold command is create-video. Non-interactively, the documented form is:

npx create-video@latest --yes --blank --no-tailwind my-video
cd my-video
npm i

Four details about --yes that the docs state plainly and that most guides leave out:

• Agent skills are not installed. You have to add them yourself with the command above.

• The editor is not opened after scaffolding.

• It fails if you're already inside a Git repository. Scaffold outside your repo, or drop the flag and answer the prompts.

• --no-tailwind only has an effect alongside --yes. Without it, Tailwind is offered interactively and the flag is ignored.

Then start the preview:

npm run dev

That launches Remotion Studio — a browser-based, frame-by-frame preview where you can scrub the timeline and watch changes hot-reload. Use it constantly while iterating.

And when you're ready to output:

npx remotion render MyComp out/video.mp4

One environment note worth checking early: rendering runs through a headless Chromium, which downloads on first use. On locked-down networks that download is the thing that stalls, and it stalls before any of your code runs — a confusing first failure if you don't know to expect it.

⚠️ Warning: create-video --yes failing inside a Git repository catches people out because the error arrives before the scaffolding looks like it has started. If your project directory is already version-controlled, run the command from a parent directory or use the interactive path.

Writing a Prompt That Renders First Time

Vague prompts get vague code, and in a video project vague code is expensive to unwind. Five things in a brief do most of the work:

1. Duration and frame rate — "15 seconds at 30fps". 30fps for web delivery, 60fps when the motion needs to feel smooth.

2. Aspect ratio and platform — 1920×1080 for YouTube, 1080×1920 for Reels and TikTok, 1080×1080 for feed posts.

3. Scene structure — what appears, in what order, and roughly when. "Logo in at 0–3s, tagline 3–6s, CTA holds from 6s."

4. Brand tokens — colours, fonts, spacing, logo placement. Better still, a path to a theme file the agent can read.

5. The constraint — every animation driven by useCurrentFrame(), no CSS transitions, no setTimeout.

That last point is the one that separates a working prompt from a debugging session. Stating it explicitly makes the constraint reviewable; inspect the generated code and render a test rather than assuming the prompt enforces it.

A brief that works looks like this:

Build a 15-second product reveal at 30fps, 1920×1080. Three scenes: logo scales in with a spring from 0–3s, three feature labels stagger in from 3–9s, CTA holds from 9–15s. Use the colours and font stack in theme.ts. Drive everything from useCurrentFrame() — no CSS transitions or keyframes.

Specific, bounded, and it hands the agent the rule it would otherwise have to guess.

What It Is Genuinely Good At

The wins cluster around one property: code can express reusable animation logic; timeline tools also offer templates, expressions, and reusable controls.

For twelve product variants, After Effects supports data-driven expressions, while Remotion supports parameterized components. In either workflow, the template and export process need setup and review. Change the data, the animation changes. That difference compounds every time the client asks for a revision.

Tasks I would evaluate with this approach:

• Data visualisation — charts, counters, progress bars, anything where the visual encodes a value

• Kinetic typography — staggered text reveals with timing expressed as code

• Lower thirds and title cards — parameterised once, reused everywhere

• Batch output — parameterize the template and measure generation, review, and render costs across the batch

• Anything with a long revision tail — change a value, re-render, done

If your work looks like that list, this workflow is a genuine step change. If it doesn't, it mostly isn't — and knowing which side you're on saves a lot of wasted effort.

Where It Still Falls Short

For character animation or complex 3D, evaluate the required controls and correction effort before choosing the workflow.

Character animation. Rigging, walk cycles, and facial expression need careful animation review. A timeline or specialist animation tool may suit that work better.

Complex 3D and simulation. Remotion supports React Three Fiber integration for 3D scenes. Test the rendering, simulation, and editing requirements of your shot; specialist tools may be a better fit for the production workflow.

There's a third limit that's less about capability and more about judgement: knowing which cut lands, how long a beat should hold, whether the pacing feels premium or cheap. That's taste, and keep an accountable reviewer for those timing and style decisions.

The honest summary is that this is a production tool, not a creative director. Compare the total authoring, review, and rendering cost on a representative job. It does not supply the clear idea — and if you skip the part where you decide what you're making, you'll get a fast, cheap, well-rendered version of nothing in particular. The full breakdown of where the split falls is in Claude Code vs After Effects: The 2026 Decision Guide.

The Cost Question, Answered Honestly

There are two separate costs, and conflating them is why conversations about this go nowhere.

The software cost is small and knowable. Remotion is source-available, and for most individuals and small teams the licence is free — more on that below.

The agent cost is variable and genuinely hard to predict. This is the honest answer: there is no clean published figure for what an animation project costs in tokens. Take one well-known example: an issue titled "Excessive token usage due to startup overhead", which argues that Claude Code "injects substantial context" including CLAUDE.md files, memory files, system reminders and deferred tool lists, and that "this overhead is charged to the user's token budget on every conversation." It is a real complaint, whose opening report gives no per-project cost measurement. Later comments contain user-reported figures about caching, not a general motion-project price. The issue was closed as not planned. Anyone quoting a precise per-project figure is extrapolating.

What you can reason about is where the tokens go, because that's observable:

• Repeated renders. Every iteration cycle feeds output back into context.

• Large generated files. Frame components get long, and long files are expensive to re-read on each pass.

• Exploring instead of specifying. A vague brief produces several wrong attempts, and wrong attempts are the most expensive thing in the whole workflow.

Which points at a lever that's entirely in your control: specific prompts and a shared theme file are cost optimisations, not just quality ones. Fewer generation and review passes can reduce usage, but the amount depends on the model, context, caching, and work in each pass.

If token spend is a concern, the highest-leverage change isn't a cheaper model — it's writing better briefs and keeping your animation logic in fewer, smaller files.

The Licence Detail Most Guides Skip

Almost nobody covers this, and it matters the moment you deliver client work. The licence FAQ is clear once you find it:

Free covers an individual for personal or commercial work, non-profits, anyone evaluating, and a team of up to 3 people.

A Company Licence is required at 4 or more people. The FAQ is explicit that headcount is aggregated in some cases — including where a client also owns the project, or where contractors work on it.

There are two options, and they combine:

• Creators — $25 per seat, per month. No minimum seats and no minimum spend when purchased alone. A seat covers one person who writes Remotion code or uses agentic coding tools.

• Automators — $0.01 per render, with a $100 per month minimum spend. Relevant if you're building an automated pipeline or embedding the Player. Developers on automation projects don't need a seat.

If both are active, a combined $100/month minimum applies, and seat spend counts toward it.

Two details that make this more reasonable than it first looks. First, there's no functional difference between the free and paid versions — nothing is locked behind payment. It's priced by who you are, not by what you get. Second, previews don't count as renders. Studio and Player previews are free; a render means a successfully generated video, audio, GIF, PDF, or still. So you're not billed for iterating.

🚀 Pro tip: If you're a freelancer delivering client work, check the headcount question before you quote. An agency with three or fewer people is covered by the free licence; at four it isn't, and if you subcontract, that can pull a project into Company territory. Better to know before the invoice than after.

None of this is onerous, and the pricing model is unusually fair for a tool this capable. It's just information you want before you standardise a studio on it.

Where This Leaves You

The workflow is real and it works. It also isn't magic, and the gap between the two is almost entirely about setup and specificity — install the skills before you prompt, give the agent the frame-determinism constraint up front, keep your design tokens in one file, and render early to catch what the preview hides.

Do those four things and the experience matches the hype. Skip them and you'll join the people writing posts about how the output "looked fine in the preview."

The tooling is the easy part. It's documented, and the docs are good. What determines your results is whether you brief it like a software project — because that's what it is.