Why the render happens on your own machine
Butter Motion is split in two. The planning of a generation runs online, because that is where the model lives. The render, the part that turns the plan into an actual video file, runs on your computer, in a small background service the installer sets up.
That split is not an implementation detail. It decides what the product can and cannot do for you.
What it means in practice
- Your footage never leaves your machine. The plugin does not upload your sequence, your project or your media to produce a clip. The only thing that travels is the text of your prompt and the plan that comes back.
- No watermark and no render queue. The render is not a shared service you wait in line for. It starts when your machine is ready to start it.
- Real editing formats. A solid clip comes back as MP4 (H.264). A transparent one comes back as MOV (ProRes 4444) with an alpha channel, which is what Premiere needs to key an overlay cleanly over your footage. Details in Background and transparency.
- The file lands next to your project. By default renders go to a
_ButterMotionfolder beside your.prproj, then get imported into a Butter Motion bin. See Rendering to the timeline.
What actually leaves your computer
Two things, and it is a short list on purpose.
The text of your prompt goes out, because that is the brief. If you attached a reference image, that image goes out too, since the model has to see what it is animating. Nothing else does. Not the sequence, not the project file, not the media it points at, not the audio, not the client's rough cut sitting in the same bin.
What comes back is a plan: the description of the animation your machine is then going to build. The render reads that plan and writes a video file to your drive. Apart from a reference image you chose to attach yourself, nothing from the edit leaves the room.
For anyone working under an NDA that is the part worth being able to say out loud in a meeting. The material you were trusted with stays on the drive you were trusted with, and what does go out is a decision you make one attachment at a time.
Clips you generate are yours, including in commercial and client work. No watermark, no separate license to buy.
Where the local half comes from
Neither Premiere nor the panel installs that background service. A small desktop app does. You sign in there once, it downloads and sets up the plugin inside Premiere, and after that it sits quietly showing your plan and credit balance and telling you when a new version is out. The install is per user and needs no administrator rights on either macOS or Windows.
If an install breaks, the same app offers Reinstall and Copy diagnostics, the second of which collects a text summary of your app version, plugin state, operating system and a recent slice of the log, which is exactly what support needs. See The Butter Motion app.
Which parts need the network, and which do not
A generation moves through visible stages: queued, generating, checking layout, rendering, done. The line between online and local sits between the third and the fourth.
Queued, generating and checking layout are the online half. The model plans the animation, and the result gets checked so nothing comes back empty or cut off at the edges. Rendering is yours: your CPU, your disk, your wait. So you need a connection when you press send, and you do not need one for the render, or for re-rendering something you generated last week.
Two things follow from that split, and both are useful to know:
- The queue survives a restart. Close the panel, quit Premiere mid-generation, and the jobs keep going. The feed shows them again when you come back. Jobs run one at a time, so a card that says it is waiting with tasks ahead is not stuck.
- Losing the connection mid-run is not a lost generation. If the server had already accepted the job, the card gets a grey WAITING badge instead of a red failure. The work finishes on the server side and the result is delivered on its own when you are back online. There is no Retry button there on purpose, because retrying would pay for the same thing twice. See Queue and generation feed.
What it costs you
Local rendering is not free in every sense. It uses your CPU and your disk.
- Time. A render takes minutes, not seconds, and a heavier scene takes longer than a title card. If your machine is already busy exporting a sequence, both jobs get slower.
- Disk space. ProRes 4444 with alpha is a large format by design, because it stores 10 bit color plus transparency. At 4K that runs roughly 0.5 to 0.8 GB for every five seconds, so a set of lower thirds for a full cast quietly costs several gigabytes. Not enough disk space covers cleaning up.
- A supported machine. Premiere Pro 2022 or newer, on macOS 14 Sonoma or newer with Apple Silicon, or Windows 10 or newer, 64 bit. Modest but real, and listed in System requirements.
The disk part is handled better than you would expect. Before a render starts, Butter Motion estimates the file size, compares it with the free space on the target drive, and asks rather than failing halfway: it tells you roughly how much the render needs and how much the drive has, and lets you go ahead anyway if you think the estimate is pessimistic. Separately, a strip appears above your generations once the drive drops below 5 GB free. A render that does not happen costs you nothing, since credits pay for generations, not for files.
Re-rendering a result you already generated does not cost credits. Credits pay for generations, not for files. The full rules are in How credits work.
Why not render in the cloud
A cloud render would remove the wait on a slow laptop. It would also mean uploading media, queueing behind other people's jobs, and paying for someone else's GPU time inside your subscription price. For an editor who is already sitting in front of a machine that renders video for a living, that trade is a poor one.
The part that genuinely needs a data center, planning the animation, is the part we run there. The part that does not, we leave with you.
Generation needs an internet connection, because the plan comes from the model. Rendering a result you already have does not.
Two failures that look alike and are not
Once you know where the seam is, the panel's error messages stop being interchangeable.
No connection means the panel could not reach our servers at all. The request never went out, so nothing was charged. Check the network and hit Retry.
Butter Motion isn't responding is about the local half: the background service on your own machine, the thing that does the rendering. Your internet is fine and irrelevant. See Butter Motion isn't responding.
And a generation that fails on our side is refunded automatically, without asking. The exception is a prompt the content policy declines, which is not a technical failure: the request did go through, so those credits are spent. A generation failed walks through each case.
What this changes about how you work
You can treat generated clips like any other media in the project. They are on your disk, in your project folder, in a bin, with normal codecs. Nothing expires, nothing lives behind a login, and archiving the project archives the graphics with it.
That last point is worth sitting with if you hand projects over. By default the file goes into _ButterMotion next to the .prproj, which means zipping the project folder takes the graphics along. You can point renders at a custom folder instead, on a scratch drive for example, and the panel remembers it. If no project is open at render time the file falls back to your Desktop, so opening the project first is a small habit worth having.
The Renders tab is your history of finished files, and it is stored on your computer rather than in the cloud, like the files themselves. That cuts both ways: it is there without a login, and deleting a render there deletes the file from disk. Presets are the opposite, they sync to your account, which is why a saved design follows you to the next project.
Six months later, when the client wants the same film with one number changed, the graphic is where you left it. That is the practical end of the whole architecture.