n8n YouTube Clipping Automation — the Version That Actually Works

Why Groq, and where it breaks

Groq's speed is the whole reason this pipeline is usable — waiting minutes per clip on a slower model kills the point of automating it. But Groq has a hard 25MB cap on audio file size, and a real podcast episode blows past that without any preprocessing. The fix was splitting/compressing before the transcription call, not after it failed.

The 70-minute episode that broke everything

The bigger issue showed up on a 70-minute episode: sending the full transcript to Groq in one shot blew through the account's tokens-per-minute cap and the whole run died mid-way. The fix wasn't a bigger plan or a different model — it was splitting the transcript into smaller batched groups and throttling the calls between them, so the pipeline stays under the rate limit instead of hoping it doesn't hit it. Boring fix, but it's the difference between "works on my 10-minute test video" and "works on the actual 70-minute episode I need clipped."

Three smaller bugs that were still worth fixing

None of these were dramatic on their own, but they're the kind of thing that makes automated output look obviously automated if you don't catch them:

• Clips as short as ~15 seconds were slipping through early on — nothing wrong technically, they just looked bad. Raised the floor to 20 seconds and the output got noticeably more watchable.
• A duplicate-title bug where two different clips from the same episode ended up with identical generated titles — an edge case in how titles were generated per-batch instead of per-episode.
• General cleanup on how candidate moments were scored, so the "best" clips picked were actually the ones worth posting, not just the ones that happened to score highest on a narrow metric.

Why I'm not pretending this is unique

People are already paying for versions of this workflow, which tells you the demand is real — but it also means the generic pitch ("AI clips your videos!") is already fully saturated. The part that's actually mine is the specific pipeline: which model, how the transcript gets chunked, and the four bugs above that only show up once you run it against real, long, messy source material instead of a clean demo clip.

The actual settings behind those fixes

I re-read the current clip-processor workflow (18 nodes, triggered by a POST webhook) so the fixes above come with their real numbers rather than descriptions.

• Staying under the 25MB audio cap. An ffmpeg step strips the video and re-encodes the audio as mono MP3 at 16 kHz and 32 kbps before it goes to whisper-large-v3 (requested as verbose_json to get timed segments). 32 kbit/s is 4 kB of audio per second, so 25 MB covers a little over 100 minutes. Anything longer would still need to be split.
• Merging Whisper segments before the LLM sees them. Whisper segments are a few seconds each, so a Code node merges consecutive ones into chunks of 12 to 28 seconds, and it prefers to break where a segment ends with ., ! or ?. The original fine-grained segments are kept for captions and for snapping the chosen clip times to real boundaries.
• Grouping under the token limit. The chunks are then packed into groups of at most 14,000 characters, and the LLM is called once per group. The code comment records an observed cap of about 8,000 tokens per minute for that model on the account's on-demand tier, and the group size is sized to stay under it.
• The LLM call itself. Model openai/gpt-oss-120b, temperature 0.4, reasoning_effort low, max_tokens 1200, with retry on fail set to three tries three seconds apart. The prompt asks for roughly one moment per six minutes of source video, at least 5 and at most 12. Why low reasoning effort and a token ceiling matter is covered in the Groq rate-limit article.
• The 20-second floor. The moment parser sets a constant minimum of 20 seconds; a moment shorter than that is extended to at least 20 seconds and snapped to a segment end. If the model returns no usable moments for a group, the parser falls back to generated moments with generic comments instead of failing the run.

What to check before trusting a run

Look at the transcript step first: if the segment list is empty or truncated, everything after it is guesswork. Then compare the number of clips with the source length (about one per six minutes is the target here), and watch a couple of them end to end, because the scoring picks moments by a rubric, not by whether the cut lands cleanly.

Related fixes for the same pipeline

The audio-size problem has its own write-up in the Whisper 25MB limit article, and the model that stopped working mid-project is in the model deprecation incident.