n8n Automation Hub
The token limit that only shows up on long input
After fixing the audio-size limit on the transcription step (a separate bug, same episode), the pipeline got one step further and failed again — this time at the LLM call that picks the best moments from the transcript. Groq returned Request too large ... TPM: Limit 12000, Requested 21251. A seventy-minute transcript's raw text, even after merging Whisper's output into clean sentence-boundary chunks, is simply too many tokens for one call under that model's per-minute limit.
The obvious fix: send it in pieces
The transcript-parsing node already grouped Whisper's segments into sentence-boundary chunks. The fix extended that: group those chunks further into batches under a roughly 6000-token budget, and instead of returning one big blob of text, return one item per batch. n8n processes multiple input items through the next node automatically, one at a time — so the single downstream LLM node, completely unchanged, now just runs once per batch instead of once total. A seventy-minute episode turned into about three batches instead of one oversized request. A small delay between calls (65 seconds) was added too, since Groq's rate limit is a rolling account-wide window, not a per-request check — three requests fired back-to-back could still trip the same limit even though each one is individually small enough.
Splitting the input didn't just distribute the risk — it multiplied the assumptions
The very next node in the chain reconstructs each moment's absolute timestamp and other metadata by reaching back to the transcript-parsing node's output for the item it belongs to. That code had always been written as $input.item... — fine, even correct, when there was exactly one input item, because “the item” was never ambiguous. The moment there were three items instead of one, that same code had no way to know which batch a given LLM response actually belonged to.
The fix was to loop over every response explicitly and use n8n's own pairedItem lookup ($('Node').itemMatching(idx)) to trace each result back to its originating batch, instead of assuming there was only ever one. This is the kind of bug that a single-item pipeline can carry silently for months — it was never wrong before, because the situation that would expose it had never occurred.
Bug three: numbering that assumed there was only ever one group
With lineage tracking fixed, the pipeline ran further — and then rendered clips that silently overwrote each other on disk. Every batch's clip-numbering code started counting from 1 independently, with no shared counter across batches, because that code had also been written back when there was only ever one batch to number. Batch one's clip 3 and batch two's clip 3 both rendered to the exact same filename, and the second write quietly clobbered the first with no error from anything in the chain.
The fix: derive each clip's number from its batch index as well as its position within the batch (batchIndex * 100 + i + 1), so clip numbers across the whole episode never collide regardless of how many batches it took. The same reasoning applied to the fallback path used when an LLM response fails to parse — its fallback timestamps also had to be offset by the batch's own start time instead of assuming the video started at zero.
What finally counted as “done”
Each of the first two fixes looked complete in isolation — the pipeline ran further than it had before, with no error, which is exactly what makes a partial fix easy to mistake for a finished one. The episode wasn't confirmed genuinely working until a full re-run produced 15 correctly-numbered clips (three batches of five) with zero filename collisions and every clip's timestamp traceable back to the right source batch. Splitting one call into many isn't just a request-size change — it turns every downstream assumption that quietly depended on “there is only ever one of these” into a bug waiting for the next multi-item run to expose it.