
Manifolds, balancers, and clocking: how to feed machines without the math
A manifold is one belt feeding machines in series, and it works because a full machine stops pulling — you rarely need a balancer, and idle time at startup isn't a bug.

A manifold is one belt feeding machines in series, and it works because a full machine stops pulling — you rarely need a balancer, and idle time at startup isn't a bug.
A manifold is a splitter or merger built in a straight line, feeding one machine after another off a single belt — no balancing, no math. It works because a full machine simply stops pulling resources, so whatever's left keeps moving down the line to the next one. A balancer forces every branch to get an equal share instead, and you only need that when a manifold's own fill order becomes a real problem.
Line up a row of buildings — constructors, smelters, refineries — and tap the same belt into each one with a plain splitter, one after another. That's a manifold. Each splitter sends items straight ahead by default and only spills sideways into a machine when that machine still has room; once a machine's input buffer is full, it stops accepting items and everything moves on to the next tap. Nobody is doing the division: the belt fills machines in order, closest to the source first, and the arrangement self-corrects around whatever's actually being pulled.
This is also why a manifold looks "wrong" the first time you build one. Machine one fills up first, machine two starts a moment later, and machine six at the far end might sit empty for a while — but it isn't a sign of a badly built line. It's the mechanic working exactly as intended.
A load balancer nests splitters so that every downstream belt gets an equal share, on purpose, instead of first-come-first-served. It costs more buildings and floor space than a manifold doing the same job, and the Satisfactory Wiki is blunt about it: avoid balancers where a manifold covers the same throughput, because most factories don't need the guarantee a balancer buys you.
Reach for one when the difference between "eventually even" and "even from the first second" actually matters — a train station loading multiple wagons that all need to leave full at the same time, or a setup where uneven fill would starve a specific branch you can't afford to lose, like a coal generator row that can't tolerate one segment running dry while another hoards fuel. Outside cases like that, a manifold reaches the same steady state with a fraction of the parts.
If you just built a line of refineries on a manifold and the ones further down the belt aren't running yet, that's the same fill-order behavior, not a broken build. Splitters push items forward first and only let a machine pull in what it needs once it has room, so machines closer to the source claim their share and start producing while the belt is still catching up to the machines further along. Give it time: as long as the belt's total throughput and the input/output balance of the recipes involved can actually support every machine on the line, the last one in the row starts up too, once everything upstream is full and passing its overflow along.
The one case where it never catches up is when the belt itself can't carry enough per minute for every machine on the line — then no amount of waiting fixes it, and the fix is a faster belt tier, or fewer machines on that manifold, not patience. Checking recipe inputs and outputs against belt capacity in recipes is worth doing before blaming the line.
Underclocking sets a machine's clock speed below 100%, and it doesn't need a Power Shard to do it — just pull the slider down in the building's control panel. The reason it's worth doing is that power draw and output don't scale together: according to the Satisfactory Wiki, power consumption follows initial power × (clock speed / 100)^1.321928, not a straight line, so cutting clock speed costs you proportionally less power than the output you give up. A Constructor running Iron Rods at 50% clock speed draws about 1.6 MW against 4 MW at 100% — a fraction of the power for half the output, not half the power for half the output.
That's the practical use case: trim a machine down to exactly the input or output rate a recipe chain needs, instead of running it at 100% and wasting the surplus, and the power bill drops faster than the production does. It also matters in the other direction — running things at 250% clock speed for the same reason means you pay disproportionately more, not proportionally more, for the extra output.
Overclocking is the same slider pushed past 100%, and unlike underclocking it's gated: each building needs a Power Shard in its control panel to unlock every 50% of clock speed above the base rate, up to three shards for a maximum of 250%. The same non-linear formula runs in reverse here — going from 100% to 250% multiplies output by 2.5, but multiplies power draw by roughly 3.36, per the wiki's own math. That exponent, 1.321928, replaced an earlier, steeper 1.6 value in a past balance patch, which is why overclocking now costs less than it once did — but it has never been a straight one-to-one trade, at any point in the game's history.
The practical read: overclock the bottleneck machine that's actually limiting a production line, since that's where the extra output is worth the extra power, and underclock everything else that's only running at 100% because nobody bothered to trim it.