Four hours. That’s how much extra time one Remotion builder says the QA step was adding to every video, because Claude critic subagents were staring at every single frame. A new skill called SageCut, shared on r/PromptEngineering by u/Individual_Cold_4119, changes who looks at what.
What’s new
SageCut is a free, MIT-licensed skill for Claude + Remotion video workflows. Disclosure first: the author is a co-founder of Levanto, the company behind Sage, and the plugin needs a Sage API key with paid API calls. It has only been tested on Remotion motion graphics so far, so don’t assume it behaves the same on live footage, screen recordings, or heavily animated footage with fast cuts.
Their numbers, from six A/B tests in their own workflow: the same output at about a quarter of the QA time and a tenth of the cost. The demo video has 3,153 frames, and Sage’s pass over them cost $0.16. That figure doesn’t include Claude’s repair work, so your real bill will be a bit higher once fixes start. These are one person’s results, not a benchmark. Still, the shape of the savings makes sense. Most frames in a motion graphics video are near-duplicates of the frame before them, and paying a premium model to re-inspect each one is where the hours went.
The twist
The clever part isn’t a smarter critic. It’s a smaller job for the critic. Instead of asking one expensive model to judge everything, the review is split by what each tool is good at. Code measures. A cheap vision model answers yes/no questions. Claude only touches the frames that matter, and it still does the fixing.
Think of it like a newsroom. A spellchecker catches typos, a fact-checker verifies claims, and the editor only reads the pieces that got flagged. Nobody asks the editor to proofread every comma. The editor’s time goes to the decisions only an editor can make, which here means repairs and taste calls.
The mini-workflow
- 🔧 Code measures the quantifiable stuff: text size, blank or frozen frames, delivery specs like resolution, frame rate, and duration. A frozen frame is just “pixels didn’t change for N frames,” which a few lines of script can catch for free.
- 👁️ Sage reads the frames and answers yes/no questions about them. Example questions: “Is the title fully inside the safe area?” or “Is any text overlapping another element?” Each answer is cheap and easy to log.
- 🎯 Claude critics get only the selected frames to inspect and fix. Instead of 3,153 frames, they might see a few dozen, each with a note about why it was flagged.
- ⚖️ If the measurements and Sage disagree, the workflow opens that frame for a closer review. That disagreement is the signal. For instance, if code says the text is large enough but Sage says it’s hard to read, something like low contrast against the background may be hiding there, and a size check alone would never catch it.
Pro tips
- Sort every check by one question: can a script produce a number for this? If yes, it belongs in code. Only judgment calls (does this look right?) need a model’s eyes. Run through your current QA checklist line by line with this filter. Most people find that more than half of it was never a judgment call to begin with.
- Write the model’s questions as yes/no. They’re cheaper to run, easier to compare with your code measurements, and easy to turn into a disagreement trigger. “Is the logo visible?” beats “Describe what you see in this frame” every time, because you can diff a boolean against a measurement and you can’t diff a paragraph.
- A commenter, u/MiserableFlatworm337, raised a sharp point: escalating only on disagreement can’t catch misses where both checks agree and both are wrong. Their fix is to audit a small random sample of frames that both checks passed, and track the defects found there alongside time and cost. I’d add that sample to any version of this setup. Even a handful of random frames per render gives you a running miss rate, and if that rate creeps up, you know your cheap checks need new questions.
- Log every flagged frame with the reason it was flagged. After a few renders you’ll see which checks fire constantly and which never do, and you can tune or drop the useless ones.
Why it matters beyond video
You don’t need Remotion to steal the pattern. Any agent skill with a review step (screenshots, PDFs, generated pages) can hand the deterministic checks to code and give the expensive model a narrower, more concrete task. A page-generation skill could check for broken links, missing alt text, and horizontal overflow in code, let a cheap model answer “does the hero section look cluttered?”, and send only the doubtful pages to Claude. A PDF report builder could verify page count, font embedding, and margins by script, then ask a vision model whether charts and labels collide.
The author is also asking how others decide what belongs in code checks versus what needs a model to look. Worth a reply in the thread if you’ve got a rule of thumb.
Skill and setup: github.com/levantolabs/sagecut-release. Video and results: x.com/bigironchris/status/2110402795060822460
Got a review skill that burns tokens on frames or pages nobody needed to see? Try the split, then tell the crew what you moved into code. 🏴☠
Frequently Asked Questions
Q: What should go in code checks, and what should the model look at?
Anything you can measure belongs in code, like frame dimensions, audio levels, and text boxes overlapping each other. Code is fast, cheap, and gives the same answer every time. Save the model for subjective calls, like whether a transition feels jarring or whether text is readable against its background. Those are the spots where a measurement can’t tell you much on its own.
Q: Does escalating only on disagreement miss problems?
Commenters see this differently. One sees the disagreement trigger as the main source of savings, since a cheap filter handles clear cases and Claude only sees the ambiguous ones. Another points out that if both checks miss the same defect, nothing disagrees and nothing gets escalated. Their suggestion is to audit a small random sample of frames that passed both checks, and to track defects found, review time, and cost together.
Q: Has this only been tested on Remotion?
So far, yes. The author has tested it only on Remotion motion graphics, so results on other video pipelines are unknown. The core split, where code measures things and a model answers narrow questions, isn’t tied to Remotion, and one commenter who does general automated video work says getting the review scope right is the hard part. Start by listing the checks you can already measure in code, then decide which subjective questions still need a model.
My Remotion QA skill was making Claude look at every frame. Splitting up the checks helped a lot.
by u/Individual_Cold_4119 in PromptEngineering