Free 480p Previews: Iterate Before You Pay for the Export

Most people edit like every render is a real render, because on most timelines that used to be true — every scrub-and-check cost something, so caution became the habit. That habit is actively costing you nothing to keep and nothing to break in Versely's editor, and most users never find that out, because nobody tells them the render they're about to trigger is free.

Two renders that aren't the same charge

The editor's edit_video tool takes one parameter that quietly splits every render into two completely different economic events: preview. Set it true, and the render comes back at 480p, free, gated only by a short per-user cooldown so the pipeline isn't hammered by rapid-fire requests. Leave it false — the default if you don't specify it — and the render is the real thing: full resolution, the actual finished file, charged at the standard single editor_export price. Same tool, same clips, same edit decisions. The only thing that changes the bill is which mode you asked for.

That's a genuinely different economy from what most editing habits assume. A twenty-revision session that ends in one export costs exactly one export's worth of credits — the twenty previews along the way are free. A one-revision session that gets exported three times because a typo got caught after the fact costs three exports. The variable that determines your spend isn't how much you changed your mind. It's how many times you asked for the finished file.

What actually flips the charge on

Worth being precise about this, because "preview vs export" sounds like it might scale with complexity and it deliberately doesn't. A two-clip trim with no captions and a forty-clip assembly with music, overlay text and a full caption track cost the same single export charge — the price is per finished file, not per element in the timeline. Complexity is free at the preview stage and free at the export stage too, in the sense that it doesn't multiply the charge; the only multiplier that exists is how many times you press export for real.

The technical requirements are worth knowing before the first attempt rather than after a failed call: clips need to be real HTTPS URLs — file:// paths and other local schemes get rejected outright, so anything still sitting only on a device needs to be a hosted asset first. A successful call, preview or final, returns the same shape: a video_url for the result, credits_charged so you can see exactly what that specific call cost (zero, on a preview), and preview_notes for anything specific to that pass.

Why this changes how you should actually edit

Once the free-preview mechanic is actually internalized, the sane workflow inverts from the instinct most people bring in. Instead of over-planning a cut before touching the tool — storyboarding every decision in your head to minimize renders — the better move is to render early and often at preview quality, using the 480p pass as a genuine working draft rather than a last resort. Swap a clip, render a preview, watch it back at real speed instead of scrubbing a static timeline. Try the alternate music bed, render again. None of that costs anything except the small wait for each pass and the modest cooldown between them.

The discipline this replaces is the expensive one: exporting early "just to see it," then exporting again after every small fix because a full-resolution file felt like the only way to properly judge a cut. That instinct is understandable — it's the correct instinct on a system that actually charges per render — but it's the wrong instinct here, and it's the single most common way people spend more credits than the editor actually requires.

The cooldown, and why previews aren't literally infinite

The free preview isn't unlimited in the sense of "generate forever with zero friction" — there's a per-user cooldown between preview passes, which exists to keep the pipeline from being hammered by rapid automated requests rather than to meaningfully limit a real editing session. In practice this reads as a short pause between consecutive preview renders, not a cap on how many you can run across a working session. It's worth knowing the cooldown exists so a burst of rapid-fire preview attempts doesn't read as a bug when it's actually the safeguard working as intended — space consecutive previews out slightly rather than firing them back to back, and it's a non-issue.

Pairing previews with reusable drafts

The free-preview mechanic gets more valuable once it's paired with the editor's other structural feature: a saved draft. save_editor_project persists a timeline's full state — clips, trims, texts, music, captions — as project state you can reload with get_editor_project and keep iterating on, rather than rebuilding the same edit from scratch every time footage changes. That matters directly here, because the natural workflow for anything recurring is build once, preview repeatedly for free while the structure is dialed in, save the draft, then swap only what changes next time — new week's footage into the same intro-and-caption-style shell — before rendering the one export that actually matters. Saving a video edit as a reusable draft is the mechanism; free previews are what make the "keep iterating before committing" half of that workflow costless.

A Versely walkthrough

A full iterate-then-commit session, as it actually plays out in chat:

"Build a six-clip edit with this music bed and captions, render a 480p preview so I can check the pacing."

That's edit_video with preview: true — free, fast, real enough to judge timing and flow. Adjust a clip order, swap the music, ask for another preview; each one is the same free pass. Once the cut is actually right:

"That looks good — export the final version."

That flips preview to false (or simply omits it), and the single editor_export charge applies to the finished file. If the same structure needs to run again next week with new footage, save it first — save a video edit as a reusable draft — so next time is a footage swap and one export, not a rebuild. The full mechanics of this pricing model, worked through with a numeric example, live on editor previews and final export; current export pricing sits on pricing if a wider comparison across content types is useful before a big batch. For anything where the export count itself is the thing to budget — a week of daily recurring edits, say — check your credits before generating is the pre-flight step worth running before committing to the schedule rather than after.

FAQ

Does every preview really cost nothing?

Yes — a 480p preview render (preview: true) is free, subject to a short per-user cooldown between consecutive requests. The charge only applies to a real export at full resolution.

What actually determines how many credits an edit costs?

The number of real exports, not the number of edits or the timeline's complexity. A simple two-clip trim and an elaborate forty-clip assembly with music and captions both cost one export charge each — the variable is how many times you export for real, not what's in the timeline.

Why would a preview render fail?

The most common cause is a clip source that isn't a real HTTPS URL — file:// paths and other local schemes are rejected outright. Anything still only on a device needs to be hosted before it's usable as a clip source.

What's the point of saving a draft if previews are already free?

A saved draft persists the whole timeline structure — clips, trims, texts, music, captions — so a recurring edit becomes a footage swap and one export instead of a full rebuild each time. Free previews make the iteration cheap; a saved draft makes the structure reusable, and the two combine into the actual efficient workflow.

Build your next edit at preview quality until the cut is actually right, then export once — check the mechanics and start iterating for free.