Megabase scaling: from 60 to 1000 SPM

The linear core: machines, power and raw input scale exactly

For any recipe run at a fixed machine tier with no modules, the number of machines needed is

machines = (items_per_second × craft_time) / crafting_speed

Every term on the right is constant for a given recipe and machine. Double the target output and every count doubles; multiply it by 1000/60 = 16.667 and every count multiplies by the same factor. solveChain() applies this formula down the entire ingredient tree for each of the twelve science packs, and the totals below are the sum.

Metric (unbeaconed, no modules)	60 SPM	1000 SPM	Ratio
Crafting entities (assemblers, furnaces, chemical plants)	731	12,183	16.67×
Total power draw of those entities	225.6 MW	3.76 GW	16.67×
Raw item throughput at the leaves (ore, coal, stone…)	304.9/s	5,081.8/s	16.67×

The ratio is 16.667 in every row, not approximately but exactly, because all three are linear sums of linear terms. The 1000-SPM column asks for about 12,183 crafting entities - a number that already explains why a megabase is a planning problem before a single UPS measurement enters the conversation. The power column sums the energy_usage of every counted machine at 100 % duty cycle; it excludes radars, beacons, laser turrets, miner drills and roboports, so the real grid is larger still.

The raw-throughput row is the one that dictates logistics choice. About 5,082 items per second of ore, coal and stone cross the boundary between mines and the factory. A main bus built around yellow belts at fifteen items per second would need more than three hundred of them to carry that flow. No working megabase does this; the volume forces a transition to trains long before SPM reaches four digits.

Where the machines actually go

The headline total conceals how unevenly it is distributed. The solver walks each science pack's ingredient tree to its raw inputs and sums every machine along every branch. Rows below are sorted by the 1000-SPM machine count, with the 60-SPM count shown for comparison.

Science pack chain	Tree depth	Machines at 60 SPM	Machines at 1000 SPM
production science pack	5	230.9	3,849
utility science pack	5	219.5	3,658
electromagnetic science pack	4	91.4	1,523
chemical science pack	4	71.2	1,186
military science pack	3	29.2	487
promethium science pack	6	20.8	346
logistic science pack	4	18.2	303
cryogenic science pack	3	18.0	299
metallurgic science pack	2	12.9	215
automation science pack	2	9.2	153
agricultural science pack	1	6.5	108
space science pack	1	3.3	55

Two structural facts jump out. Production science and utility science together account for the majority of the counted machines, because both chains recurse through productivity modules, processing units, low-density structures and engines - subtrees that are themselves deep. Automation science, by contrast, needs only 153 machines at 1000 SPM: copper cable, gears, packs, four stages deep.

The Space Age planet packs are shallower than their names suggest. Metallurgic science stops at molten metals, agricultural science at bio-chains that the solver marks as multi-output and will not expand without an attribution assumption (see the note below). A shallow solver tree does not mean a cheap pack; it means the cost lives in fluids, planet-specific extraction and foundry machines that the item-ratio walk treats as leaves rather than as assembler rows.

The intermediates that dominate any megabase

Aggregating the solver output across all twelve chains gives a different view: not which science pack is expensive, but which single intermediate product consumes the most machines across the whole factory.

Intermediate	Machines at 1000 SPM
iron plate	3,348
copper plate	2,575
steel plate	1,633
advanced circuit	509
copper cable	449
battery	444
electronic circuit	243
stone brick	222

Smelting dominates the list in a way that surprises builders who think of circuits as the expensive intermediate. Iron plate alone needs more machines than every circuit tier combined, because plate is a leaf input to gears, steel, engines, rails, structures and science infrastructure - and electric furnaces craft it at 3.2 seconds per plate. Copper plate and steel plate sit in the same tier for the same reason. The circuit rows are large in absolute terms but small relative to the smelting column that feeds them.

This is the ratio-solver result that most directly informs layout: a megabase that treats smelting as an afterthought, squeezed between the bus and the science build, will be reorganising it within hours. Dedicated smelting blocks with direct train-fed ore input are not a stylistic preference at this scale; they are what the numbers ask for. For the column arithmetic behind furnace arrays, see the smelting layouts guide.

Belts: how many lanes the raw flow needs

The 5,082 items per second of raw material has to move from mines to consumers. beltsNeeded() divides that rate by each belt tier's per-second capacity (speed × 8 items per tile × 60 ticks, two lanes). The numbers below are theoretical minimums; a real factory needs more because every split, balancer and siding temporarily uses belt capacity that does not arrive at the consumer.

Belt tier	Items / second	Lanes for 1000 SPM raw flow
transport belt	15	338.8
fast transport belt	30	169.4
express transport belt	45	112.9
turbo transport belt	60	84.7

Even on turbo belts at sixty items per second, the theoretical lower bound is about 85 lanes - and that is a lower bound, not a design. A main bus carrying every raw material on belts would need dozens of lanes in each direction and balancers at every tap, which is precisely why megabases switch to trains for bulk ore. Belts still move intermediates within blocks, but the mine-to-factory leg is rail. The train layouts guide covers the block geometry; the train throughput reference gives wagon-to-belt equivalents.

What does not scale linearly

The machine count is linear. The cost of simulating those machines is not, because the simulation is not a flat list of independent assemblers. Each of the mechanisms below connects entities to each other, and the update cost of a connected system depends on how the connections are arranged, not only on how many entities there are.

Fluid systems

Every pipe, underground segment, tank, pump and connected machine is part of a fluidbox, and the game evaluates flow through connected fluidboxes as a system rather than tile by tile. Adding a pipe to an existing network does not add one independent unit of work; it enlarges a system that has to be solved as a whole. Long, winding pipelines are markedly worse for simulation cost than short, straight feeds with underground sections, because the solver traverses the connected graph each tick. This is why megabase builders prefer trains or barrels for long-distance fluid movement and keep on-site pipe runs short, even though a long pipeline is technically valid.

Logistic robots

Each logistic robot is an entity with a job, a position and a target, but its per-tick cost is not isolated. When many robots share a roboport network, the system has to match pending requests against available robots, route them around each other, and queue them for charging when they return. A charging roboport can only service a small number of robots at once; when more return than the ports can handle, robots wait, the queue grows, and fulfilment latency rises in a way that has no equivalent in a belt build where items do not compete for a charging slot. The logistic robots guide covers roboport spacing and charging for this reason. Robots remain excellent for short-range, low-volume, high-mix jobs; they are a deliberate trade-off against belts for bulk throughput.

Circuit networks

A circuit network is a graph of connected wires. Every combinator and every entity that sends or receives signals is a node, and each tick the network propagates signal changes across its connected wires. A single arithmetic combinator toggling one signal on a network that spans thousands of poles forces every receiver on that network to evaluate the change. Networks that are small during the early game - a few lamps, a few chests - can quietly grow to cover an entire block without the builder adding a single combinator, simply by extending red or green wire. The circuit network guide covers segmentation; for megabase purposes the rule of thumb is that one network per controlled system, joined only where signals actually need to cross, is cheaper than one factory-spanning mesh.

Trains and pathfinding

Trains solve a path from their current stop to their next stop when they depart, and they repath when their route becomes blocked. The cost of that search depends on the size of the rail graph and the number of intersections the search has to consider. Doubling the count of trains does not double pathfinding cost in isolation; it increases the frequency of repath events and the contention at junctions, and a poorly signalled intersection that merely slows a dozen trains can stall a hundred. This is the reason city-block layouts use regular, predictable signalling rather than ad-hoc junctions - the geometry keeps every path search short and local. The city block design guide covers the grid pattern.

Pollution and biters

Pollution spreads across chunks and is absorbed by trees and spawners. A biter attack forms when enough pollution reaches a spawner, and the wave size depends on cumulative pollution absorbed, not on the factory's instantaneous output. A factory that has expanded onto many chunks simultaneously generates more attack events than one that expands in a controlled direction, even if both burn the same amount of coal. This is not a UPS number; it is a mechanism. It is also a reason that perimeter defence at megabase scale is a layout problem (clear arcs, walled chokepoints, concentrated turret coverage) rather than a matter of stacking more guns. The defending your base guide covers wall and turret geometry; combat units gives the per-tier HP and speed data that turret counts are planned against.

The three levers that actually change the arithmetic

The linear result above assumes assembling machine 3 with no modules and no beacons. Three changes alter the machine counts directly:

• Productivity modules add free extra outputs on a fraction of crafts, reducing the machines needed for the modded recipe and every upstream ingredient it consumes. The solver applies a productivity bonus only at the top level of a chain, because compounding it down every subtree would assume modules in machines the player has not configured. Real builds do module furnaces and chem plants too, and the savings compound.
• Speed modules and beacons increase a machine's crafting speed, reducing the count needed for a given throughput. They also increase energy draw, and beacons affect every machine in their area - so the savings per beacon are multiplied by the number of machines it touches. Beaconed arrays of identical machines are a megabase staple because they trade power and modules for a large reduction in entity count. See the beacons and modules guide for the effectivity and transmission arithmetic.
• Direct insertion (also called "beacon-adjacent" or "neighbour crafting") places the consumer of an intermediate next to its producer so items transfer by inserter instead of going through a belt or robot. It removes belt and robot load for that flow without changing the machine count. It is most valuable for the heaviest intermediates on the list above - circuits into processing units, plate into gears, plastic into circuits.

None of these levers is free. Productivity modules raise energy and pollution and slow the machine; speed modules raise energy dramatically; beacons require modules, power and footprint; direct insertion locks two sub-factories into a fixed ratio that is painful to rebalance when science mix changes. The 1000-SPM numbers on this page are the unoptimised baseline; an experienced builder will reduce them substantially, but the relative shape - smelting dominates, production and utility science dominate the pack list, belts cannot carry the raw flow - survives every optimisation.

What this page deliberately does not tell you

There is no "1000 SPM needs X CPU cores" or "runs at 60 UPS on Y hardware" statement on this page. Those claims depend on the game version's specific performance characteristics, on the player's CPU and memory, on the exact construction (a beaconed direct-insert build and a belt-sprawling robot build at the same SPM do not cost the same to simulate), on mods and on map settings. The prototype data here contains no frame-time measurements, and estimating one would be a fabrication.

What the data supports is the linear skeleton: about 12,183 crafting entities, 3.76 GW drawn by those entities at full duty, 5,082 items per second of raw material, and on the order of 85 turbo belts if one tried to carry it that way. Everything after that is mechanics: which subsystems connect entities to each other, and why a factory with a given number of machines can run very differently depending on how those machines are plumbed, powered and controlled. That distinction is the whole of megabase design.

Applies when…

• Machine counts assume assembling machine 3 for assembler recipes, with the solver selecting the appropriate furnace or chemical plant from each recipe's category. No modules or beacons are applied.
• Power is the sum of energy_usage for counted machines at 100 % duty cycle. It excludes miners, radars, beacons, turrets, roboports, lamps and radar; the real grid is larger.
• Belt counts are theoretical lower bounds for the raw item flow at the leaves. Real builds round up and add headroom for balancers, sidings and imperfect compression.
• Fluid production (refining, cracking, sulfuric acid, electrolytes, molten metals) is expanded only where the recipe has a single attributable item output. Multi-output chemistry and ambiguous bio-chains are left as leaves; the fluid infrastructure that supplies them is not included in the machine total.
• Science packs listed are the six vanilla packs, space science and the five Space Age planet packs. Modded packs are not included.
• This page contains no UPS, frame-rate or CPU measurements. The shipped data has no performance telemetry, and none is inferred.
• All figures are for game version 2.1.12. Recipe times, machine speeds and energy values change between versions; re-run the solver against the current data before planning a build.

Related

• Science layouts — arranging the pack producers that these counts feed
• Main bus design — why a belt bus works to a scale and where it stops
• Production ratio calculator — run the same solver for any target rate
• Science pack ratios — per-pack ingredient breakdowns