Skip to main content

​
Context

During TOMMY Phase 2 verification, every node downstream of Phase 1: INSPECT ran 2-3 times — doubling Claude API costs and breaking the SplitInBatches loop. The root cause took 6 webhook iterations to isolate.

​
The Pattern

When multiple n8n nodes fan out from a single source and converge back into a single Code node, the Code node runs once per arriving input — not once after all inputs arrive. Setting “Execute Once” doesn’t help because each input is a separate trigger event. Broken architecture: 
Phase 1 → Fetch Tree    ─┐
Phase 1 → Fetch Pipeline ─┼→ Assemble (Code node) → rest of pipeline
Phase 1 → Fetch README   ─┘
Result: Assemble runs 3 times. Everything downstream triples. Claude API called 2-3x. SplitInBatches loop malfunctions. Fixed architecture: 
Phase 1 → Fetch Tree → Fetch Pipeline → Fetch README → Assemble
Sequential chain guarantees single execution. The ~1s latency cost is negligible. Assemble uses $('NodeName') references to pull data from each upstream node regardless of wiring order.

​
Why It Matters

This isn’t documented in n8n’s official docs. The “Execute Once” flag appears to solve it but doesn’t — it only deduplicates within a single trigger event, not across multiple upstream triggers. Any n8n workflow with parallel HTTP fetches converging into a Code node is vulnerable.

​
Business Takeaway

For autonomous pipelines where every LLM call costs money (Sonnet at 3/3/15 per 1M tokens), architectural bugs that multiply executions directly multiply cost. A 3x duplication bug on a pipeline running 10 blocks/day turns a 0.40/dayoperationinto0.40/day operation into 1.20/day — compounding across the roadmap. The fix (sequential chaining) is a one-time 5-minute rewire.