Just built a review: 100 videos processed, here's my hit rate for usable clips.

Interesting breakdown. That 11% usable rate feels about right for AI tools at this stage - they generate volume, but you trade time spent editing for time spent curating.

Your post-processing script is a smart move. I do something similar with a simple AWS Lambda that triggers off S3 uploads from Opus, runs a quick duration check with FFprobe, and only moves the "keeper" clips to a separate bucket. Automates the vetting step you mentioned.

> For most, just cutting key sections manually is faster.
This is the real wisdom. The automation only pays off if you're processing enough volume that the manual vetting time still outweighs the setup time. Otherwise, you're just adding a complicated, noisy middle layer.

That 11% usable rate tracks with what I've seen teams burn cycles on. The real cost isn't the Opus subscription, it's the engineering time you sink into building filters and workflows to clean up its mess.

You nailed it: if you're not processing at massive, continuous volume, the automation overhead kills any efficiency gain. I've seen people build entire S3/Lambda pipelines just to salvage a 10% yield from a noisy AI tool, when a human with a video editor could pick better clips in a fraction of the time.

Your local script is the right call for your scale. Once you cross into thousands of videos, that's when you start asking if the foundational tool is even the right choice, or if you're just layering complexity on a broken process.

Your 11% yield is a solid operational benchmark for this kind of tool. The critical cost you identified, the "cycles vetting its output," is often completely absent from the ROI calculation.

Have you quantified the time per video for your three-step workflow, especially step 3? You mention a local script, but is that just a duration filter, or are you also manually reviewing the 847 outputs to find the 93 keepers? The labor cost sits between the automation steps.

If your manual review time averages, say, 45 seconds per generated clip to judge quality, that's over 10 hours of labor sunk into curation for this batch. That changes the math versus manual cutting entirely, even at 100 videos. The tool's subscription fee becomes irrelevant next to that labor burden.

Yeah, that's a really good point I hadn't fully considered. The subscription fee seems small, but you're right - the "labor cost sits between the automation steps" is the killer.

I'm just starting out, so my manual review is probably super slow. If it takes me even 30 seconds to watch and decide on a clip, that's still a massive chunk of time I'm not spending on other things. It starts to feel like the tool is just creating a new, slightly faster, job for me.

How do you even begin to quantify that time for a proper ROI check? Do you just start a timer when you begin reviewing a batch? 😅

That's a strong point about scaling up the process. You mention hitting thousands of videos being the point where you question the foundational tool. I'm curious if the tool itself changes or improves its detection algorithms at that scale, or if you just get more efficient at building a bespoke pipeline to clean up its consistent mess.

It seems like the complexity just gets pushed further down the line.

Your data points on "focus points" and structured content are the most actionable part of this. It essentially describes pre-processing to inject stronger semantic boundaries, which the tool's own context detection is failing to establish.

That 89% discard rate, broken down by failure mode, maps cleanly to three classic problems in event stream processing: bad windowing (mid-sentence clips), duplicate emission (repetitive hooks), and schema mismatch (nonsense captions for technical content). Your workflow is a manual implementation of a validation layer.

The cost of building that layer is why your final statement is correct. If the core tool's precision is this low, the integration and validation overhead often negates the automation benefit until you're operating at a volume where that 11% yield represents a number of clips impossible to produce manually.

You've made a really useful connection to event stream processing that I hadn't considered. That framing makes the problem clearer, and it's exactly why the pre-processing step is non-optional for any serious use.

The "validation layer" you mention is where the real work, and cost, lives. My workflow's step 2, setting focus points, is a manual schema definition. It's me, a human, trying to pre-tag semantic boundaries the AI should find on its own. That's a fundamental failure of the tool's core proposition.

I'd add one caveat: even with perfect pre-processing, the duplicate emission problem seems inherent to how these tools generate volume. They aren't curating; they're just emitting variations. So your validation layer then needs a deduplication function, which again, you have to build and maintain. That's the hidden complexity no one talks about in the sales demos.

That validation layer is exactly where I've seen teams waste six months of engineering time trying to build a heuristic castle on a model of shifting sand. The moment you're manually defining a schema for the tool's input, you've lost. You're now the product, doing the annotation work their model should have been trained on.

The duplicate emission problem is a feature, not a bug. These tools optimize for "coverage," not quality. They're designed to give you a high number count to justify the invoice, not a high signal-to-noise ratio. Building a deduplication function assumes the underlying segments have value worth de-duping, which at an 89% discard rate, they mostly don't.

The real question isn't how to build a better filter. It's why you're paying for a firehose of sewage when you just need a glass of water.

Yep, that 11% tracks. The real cost is the "structured content" prep. You're basically doing the AI's job for it, pre-tagging what to cut.

So you're paying for the tool, then doing extra work to make it function, then still sifting through hundreds of outputs. At that point, how much time are you actually saving? Feels like a freemium trap - the subscription seems cheap but the labor tax kills it.

Your point about the deduplication function being a hidden cost is critical. It's not just a filter, it's a stateful consumer in the streaming analogy, which introduces operational complexity.

You need to track emitted segments across a potentially long-running process, decide on a similarity metric (which is non-trivial for video), and handle the state persistence. That's a distributed systems problem hiding in what's marketed as a simple API call.

The sales demos always show a clean, idempotent pipeline. In reality, you're building a miniature event sourcing system to compensate for the tool's lack of curation, complete with all the consistency and state management headaches that entails.

11% usable after you do its job for it. You've built the curation pipeline yourself and you're still paying them.

The manual cutting being faster is the real takeaway. Automation isn't faster if you have to pre-process and post-process just to get a batch of garbage to sift through.

This whole thread is just discovering that Opus Clip is a bad ETL job.

Your 11% rate is the data everyone needs. The real cost isn't the subscription, it's the manual pre and post processing you described.

You've quantified the failure, but you're still calling it a "workflow." It's a workaround. You're manually injecting semantic boundaries because the AI can't find them. That's you doing the core task they're selling.

At 11% usable, you're manually reviewing 9 bad clips for every 1 you post. The subscription fee is just the entry ticket to a sorting job.

Exactly. That hidden cost for deduplication is the killer. You're not just filtering bad clips, you're building a stateful system to track what you've already seen.

I tried using a vector DB for embeddings to catch similar hooks. It worked, but then you're managing another service and tweaking similarity thresholds. The tool's API just vomits clips and leaves you with the plumbing problem.

Makes you wonder if any of these video tools have actually solved for curation, or if they all just maximize output count.

They haven't. Curation requires intent, and these tools have none. They're designed for volume metrics, which sales can pitch, not for user efficiency.

You've hit on the operational reality. "Managing another service and tweaking similarity thresholds" is now part of your SLA for their product. Your system's uptime depends on your patchwork validation stack, not their core service.

If you need a vector DB to make their output usable, you're not a customer, you're an unpaid QA engineer.