Factorio Ratio Calculation Basics and How to Determine Assembler Machine Count

If you've noticed that certain parts run short whenever you expand your red and green science lines or electronic circuit production, it's time to move beyond guesswork and start counting with formulas. This guide walks you through production ratio thinking for vanilla 2.x, assuming no modules, and covers everything from post-tutorial through mid-game when you want stable mass production.

There aren't many rules to memorise. Items per second = recipe output × crafting speed ÷ recipe time, and machines needed = target output ÷ output per machine (rounded up)—these two formulas apply to almost every recipe regardless of which assembler you're using.

When I was scaling up green science, I thought the bottleneck was the circuit board itself running dry. In reality, copper cable was the culprit. Once you start tracking these ratios properly, the pinch points become obvious, and you can expand by design rather than scrambling whenever something runs short.

Three Core Premises You Need First

Terminology: Recipe Time, Crafting Speed, Output Count

Three terms need to be settled from the start: recipe time, crafting speed, and output count. Vagueness here leads to different people coming up with different machine counts for the same recipe.

First, the recipe time shown in-game is time based on crafting speed 1. Manual crafting counts as speed 1, so the displayed time is your baseline—what it takes to craft by hand. The actual crafting time in a machine is displayed time ÷ crafting speed, not the raw number shown. This is the same principle as with 'Time and Game Ticks'.

Next is crafting speed. In vanilla, Assembling Machine 1 has speed 0.5, Machine 2 has 0.75, and Machine 3 has 1.25. That's why you need different machine counts for the same recipe. The same recipe might show the same time, but Machine 1 runs at half speed while Machine 3 runs faster than baseline, so throughput per machine changes.

Finally, output count is how many items one craft produces. These three elements alone determine the formula—output per machine per second equals output count × crafting speed ÷ recipe time. This is the precise wording of what I mentioned earlier; once you map the terminology correctly, everything clicks.

I stumbled here early on. I swapped in an Assembling Machine 1 and thought it was slower than manual work, but that's because its speed is 0.5—so the same recipe literally takes twice as long. The numbers make sense once you put them in a formula.

Time/ja

wiki.factorio.com

Declaring Target Version and Preconditions

This article assumes vanilla 2.x. Factorio's calculations change significantly with mods and expansions, so being vague here leads to "I built it exactly like the guide says but it doesn't work." Space Age is a separate expansion and is treated as supplementary here rather than core.

The second precondition is no modules, no beacons. Productivity modules boost output from the same input; beacons broadcast module effects to nearby machines at half strength. Once these enter the picture, the machine count for "an Assembling Machine 3 line" becomes something else entirely. For ratio fundamentals, stick to raw machines—it's far easier to understand. Modules and beacons belong in an advanced section with conditions clearly marked.

Locking these preconditions in place keeps numbers consistent. When you talk about "expanding red science" or "doubling circuits," knowing which assembler you're using and whether there are any bonuses lets you calculate exact machine counts. Good factory design depends less on the formula itself and more on keeping the input conditions identical.

Space Age/ja

wiki.factorio.com

The Link Between Manual Crafting and Assemblers

Manual and machine crafting follow the same calculation rules. Both use "recipe time," "crafting speed," and "output count"—it's one continuous concept. Manual work is speed 1 equivalent; machines apply 0.5, 0.75, 1.25 multipliers on top of that. In other words, once you learn the rules, you don't need to relearn them when automating.

That said, this guide assumes assemblers as the focus. Why? Because ratio calculation only becomes truly necessary when scaling automated lines.

The differences between assembler tiers matter here too. Assembling Machine 1 doesn't support fluid recipes, while Machines 2 and 3 do. Modules also only work in Machines 2 and 3. In short, the "get-things-automated" machine of early game and the "fine-tune ratios" machine of mid-game are different roles even if they look similar.

Early on, I often swapped manual work for Assembling Machine 1 and felt shocked when things got slower instead of faster. It wasn't the design—it was that I'd translated manual-crafting pace directly into machine expectations. Once I separated those concepts, the distinction between "Machine 2 fixes this issue" and "I genuinely need more machines" became clear. Think of ratio calculation less as "memorise a formula" and more as "translate hand-crafting feel into machine speed."

Assembling machine 1 - Factorio Wiki

wiki.factorio.com

Core Formula: Determining Machine Counts

Deriving the Formula and Matching Units

The two main formulas are items per second = recipe output × crafting speed ÷ recipe time and machines needed = target output ÷ output per machine. The crucial part isn't the formula itself—it's matching units before plugging in numbers.

Factorio recipe times are shown assuming crafting speed 1. So when a machine processes a recipe, you don't use the raw displayed time; you adjust for the machine's crafting speed. Machine 1 has speed 0.5, Machine 2 has 0.75, Machine 3 has 1.25—same recipe, different throughput per machine. Think of it like calculating raw iron consumption: first work out how much one machine produces per second, and everything else becomes clear.

When your target is in items per minute, don't divide it directly. Divide by 60 first to get items per second, then plug that into your per-machine formula. Conversely, if you calculate per-machine output in items per second and want to see it per minute, multiply by 60. Early on I was sloppy here and the math looked right but the machine count was always off by a factor. Almost always a unit mismatch.

With modules off, the formula is straightforward: recipe output, recipe time, and assembler crafting speed determine everything. Add modules and the preconditions shift. Productivity modules adjust the output side, while speed modules or beacons change the crafting speed side. The formula doesn't disappear—you just reapply corrections and recalculate. Machine 3 can reach surprisingly high speeds even in vanilla, so an "identical recipe" late-game might need very different machine counts, but the thinking remains the same.

Rounding Rule: Always Round Up, Plus a Bit of Breathing Room

Once you calculate machine count, always round up. 2.1 machines becomes 3; 5.01 becomes 6. Why? Because production equipment is discrete. You can't build 2.1 machines.

If you round down when you're "just a bit short," the shortage accumulates across the entire line. In my factories, I've only seen inventory drain slowly when I cut corners on rounding—after a while, a downstream assembler stutters, buffers get thinner, the whole thing slows. "Almost enough" doesn't hold up over time. The factory wears down gradually because you're genuinely undersupplied.

Beyond rounding up, adding a little slack in practice is powerful. This isn't changing the formula; it's building in tiny surplus during design—making sure upstream and mid-product stages have a bit of breathing room. Belt compression varies with how items feed in; 1:1 splitters are the norm but actual flow wanders. Theory-perfect designs starve easily in practice.

Setting Target Values for Mid-Products

To find machine counts, you must decide what you want per second first. Working backwards from the finished product works, but bottlenecks typically appear at mid-products like circuits or copper cable. Setting your target around that mid-layer stability—"how much mid-product per second?"—makes design clearer.

The logic is simple: if you're thinking in per-minute terms, set your finished-product target in items/minute and lay out required mid-products the same way. Convert everything to items/second, divide by per-machine output, and you've got your machine count. This reveals bottlenecks you'd miss looking only at the end product. When I scaled green science, the problem wasn't final assembly—it was one step upstream. The ratios made that obvious.

Mid-products run more stably when your target is slightly above what the finished product strictly needs. Downstream consumption often branches across multiple lines; splits and temporary uneven draws happen. Copper cable, with needs scattered everywhere, runs dry fast at theory-perfect numbers. If you set the mid-product target a bit high, inventory stays healthier and future expansions reuse the setup easily.

Again, the baseline is modules off. Productivity modules reduce mid-product requirements; speed modules and beacons shift per-machine output dramatically. That's advanced territory but the principle stays: decide "what raw recipe on raw machines" first, then layer in corrections later. Once Machine 3 high-speed operation enters the picture, the maths looks fancier but the skeleton is still mid-product targeting.

Worked Example: Copper Cable and Electronic Circuits

Step 1: Copper Cable Output Per Machine

Let's build up how many machines make copper cable and how many make circuits, starting from single-machine throughput. The formula stays the same: grab the recipe's output count, craft time, then multiply by the assembler's crafting speed.

If using Machine 1, speed is 0.5; Machine 2, speed 0.75; Machine 3, speed 1.25. So copper cable per machine per second is cable output × machine speed ÷ recipe time.

The key insight here is not to overthink circuit machine count yet. If you build cables first by feel, you'll guess "more cables = safer" and end up chaotic. The real answer needs the downstream side: how much do circuits actually consume? Mid-products in isolation are meaningless; what matters is who eats how much.

When you work out specific numbers, always cross-check these details from the official wiki:

• Output count per craft
• Recipe time
• Ingredient counts

Reference (verify against source): Copper Cable — https://wiki.factorio.com/Copper_cable/ja ; Electronic Circuit — https://wiki.factorio.com/Electronic_circuit/ja .

This article focuses on understanding the plug-in order and backflow logic, but for publication, insert verified actual values (for example: copper cable 1 craft → X units, craft time Y seconds, circuits need Z cables per unit, craft time W seconds) from the primary sources above.

Step 2: Circuit Machine Appetite for Cables and Throughput

Now the downstream side: circuits. Same process—output count, recipe time, and machine speed give you circuits per machine per second. The crucial link is how many cables each circuit needs. Once you know cables per circuit unit, you can connect "circuits/sec per machine" to "cables/sec consumed by that machine."

Mathematically it's straightforward. If one circuit machine makes E circuits/second and each circuit needs C cables, then that circuit machine eats E × C cables/second. Now upstream cable production and downstream circuit consumption are in the same units and directly comparable.

This order works because the downstream side usually drives the design. "I want more circuits" is an easy goal; "I want cables/second" feels abstract until circuits demand them. Set the downstream goal, derive the upstream need from consumption, and hidden bottlenecks pop out. When I expanded green science, the real problem wasn't the final step—it was one stage back. The ratio table showed that immediately.

In my factory, I once doubled the circuit line while leaving cable machines alone. Inventory evaporated. The circuit side kept running but sputtered cyclically because I'd never counted how many cables those circuits ate per second. Every time this happens, the culprit is forgetting how much one circuit machine consumes upstream.

Step 3: From Target Output to Necessary Machines

Now for actual machine counts. The flow: set a circuit target, calculate how many circuit machines it takes, multiply by how much those machines consume, reverse-engineer cable machine count.

Say you want G circuits/second. If one machine produces E circuits/second, you need G ÷ E circuit machines. Round up. Now that count is fixed. Each circuit machine eats W cables/second, so total cable demand is circuit machine count × W cables/second. If cable machines produce K cables/second each, cable machine count is total demand ÷ K machines.

The power of this is that upstream and downstream machine counts become one connected chain. Add two circuit machines—how many more cables? Swap Machines 1 for 2—how does each count shift? Speed differences (Machine 1 at 0.5, Machine 2 at 0.75, Machine 3 at 1.25) are baked right into the answer. Unlike guessing, ratios move together.

Develop the habit of checking the full line at once. Placing 4 circuit machines while leaving cables at 2 is a red flag. It won't break immediately, but within minutes the line will stutter occasionally, inventory thinning gradually. The theory and actual layout don't match—classic slow-death symptom.

Design Tip: Why Close Placement and Direct Handoff Win

Copper cable → circuits is a textbook pinch-point, partly because cables are high-volume mid-product bulk. Belt transport becomes a problem. Basic belts supposedly carry 900 items/minute, but pushing volume through cable-shaped items chews bandwidth.

Placing cable machines next to circuit machines—or better, using inserters for direct handoff—cuts transport load dramatically. Make cables on-site and feed them straight into circuits. That way your main bus only needs to move copper plates, not finished cables. Suddenly the logistics improve.

I once had cables made in a separate block and bused in. Theory said the ratios worked. In practice, gaps appeared in the cable stream at the wrong moment and circuits stuttered. Moving cable machines right next to the circuit block—zero transport distance—stabilised everything instantly. The numbers didn't change but the behaviour flipped. Transport was the bottleneck, not production.

Beginner's Rounding: Start With "A Bit Extra"

Until ratio logic feels natural, don't chase perfect numbers. If theory says you need n circuits and m cables, round both up, then add one extra cable machine for good measure. This gives mid-products a slight safety margin—critical for high-demand items like cable.

This approach makes operation easier to diagnose. Downstream stops = undersupply is real. Upstream slowly accumulates = you have margin. Perfectly-balanced design forces you to watch belt compression and feed bias simultaneously. Oversizing slightly lets you separate "did I calculate wrong?" from "is transport the issue?"

My early attempts always aimed for exact ratios and failed. Numbers worked on paper but the line would die on-site. Eventually I learned: place extra early, dial back later. Unstable ratios teach better than perfect ones. Once a line runs reliably, you can trim—but you learn what "working" looks like first.

Belt Throughput and Checking Line Doesn't Clog

Converting Tiles/Second to Items/Second

Even correct machine counts don't guarantee the whole line flows if belt throughput isn't checked. The basic formula is belt throughput = tiles/second × density × lane count. Basic belts move 1.875 tiles/second; density is 4 items/tile per lane; belts have 2 lanes, so perfect saturation = 1.875 × 4 × 2 = 15 items/second.

Once you memorise this, "will one belt handle this?" becomes instant. Yellow belt: 15/sec baseline. Red belt (fast): 30/sec. Blue belt (express): 45/sec. If you need 18 items/sec, yellow falls short but red handles it comfortably. I always cross-check per-material requirements against these three tiers. Skip this and you get the classic failure: theory says it works, reality has one side stuttering.

Main bus design especially needs translating required quantity into belt lanes. Once you know items/second, deciding if one belt suffices, two are needed, or on-site production is better becomes straightforward. Machine counts are about capacity; belts are about flow. Align both in items/second and suddenly your whole design reads clearly.

Transport belts/Physics/ja

wiki.factorio.com

Telling Full from Partial Compression and Recovery

The catch: 15 items/second assumes the belt is completely saturated. Gaps between items mean you're below theory. That "theory-perfect design running short" often traces back to input belt never reaching full compression.

Spot it visually: watch a belt segment. Continuous flow = saturated; visible gaps = gaps exist. Watch out especially after splitters and during merges—compression breaks there easily. One branch consuming slower, a sloppy merge, inserters biased to one lane—any of these mean total supply is there but the belt surface looks thin. If downstream keeps stuttering, check input compression before recalculating.

In my experience, "math says it's enough but the line chokes" usually means the belt entering was never saturated. Fix compression and suddenly the starving downstream wakes up—numbers unchanged. You've just restored the belt to its theoretical capacity. Cable lines in particular suffer this; even small gaps collapse reliability.

Recovery is simple: solidify the outflow, check merged flow stays even, check feed lanes don't bunch to one side. Watch that mid-product entry builds full compression. A thin input belt will cycle-starve downstream, especially high-demand lines. Fixing compression solves more field issues than recalculating capacity.

Splitter 1:1 Splits and Belt Lane Targets

Splitters do 1:1splits by design: one input feeds two outputs evenly in theory. So a saturated single belt feeding a splitter becomes two thinner belts, not two full belts. This isn't multiplication; it's distribution. Expect 15 items/second split into 7.5 each, not 15 each.

The mental model: splitters even out flow, they don't amplify it. Misunderstanding here leads to "split it to two lanes so I've got margin"—nope, you've still got 15 total.

Belt lane targets come from dividing requirement by theoretical capacity. Needing 30/sec means red (30/sec baseline) works; 45/sec needs blue. For yellow thinking, anything above 15/sec strains a single lane. In practice, leave margin: theory-edge designs snarl at the first compression dip or split bias. Aim for comfort—enough that merges and splits don't collapse saturation.

Practically: convert requirement to items/second, see if it fits under yellow (15), red (30), or blue (45) limits, round to the nearest "works safely" option, and design around that. Build in splitters and belt tiers, assume you'll need margin, and the whole system breathes. Ratio math finds underproduction; belt matching prevents the field weirdness of "correct theory, broken practice."

Balancer mechanics/ja

wiki.factorio.com

When to Use Assembling Machines 1, 2, 3—and Why Counts Change

Speed's Effect on Machine Count

Same recipe, same output target, different machine speed = different count. Machines run at 0.5 (M1), 0.75 (M2), 1.25 (M3). Plug speed into the formula—higher speed, less machines needed.

The maths: Machine 1 baseline, Machine 2 is 1.5× faster, Machine 3 is 2.5× faster. Recipes needing 10 M1 machines become roughly 7 M2 machines or 4 M3 machines (accounting for rounding). Gear shifts look like straight machine count cuts.

I often stay with M1 early: red and green science, basic parts—M1 handles it. Once mid-game arrives and I upgrade to M2, the old "machine count" evaporates. Replace M1 with M3 while leaving the same count and suddenly downstream runs fat while upstream dries up—not broken, just overfed. Speed jumped; count didn't.

All assembler details belong in the wiki. In practice: start with M1 for "just automate," then when research and power let you upgrade, same recipe, new machine type = recalculate. Don't assume counts stay constant across tiers.

Assembling machine/ja

wiki.factorio.com

Fluid Recipes and Module Support Gaps

Speed isn't the only difference; capability differs. M1 can't do fluid recipes; M2 and M3 can. Modules only work in M2 and 3. So M1 isn't "slow mode"—it's fundamentally narrower.

Comparison table:

Impact isn't cosmetic. Once you need fluid recipes mid-game, M1 drops out entirely. Once module efficiency kicks in, design philosophy shifts to M2 or M3. At that point, recalculation becomes necessary—and not just for speed but for the new preconditions modules introduce.

Modules are a whole layer. Vanilla M3 with productivity-3 modules and speed-3 beacons (12 beacons) reaches crafting speed 11.25—a different universe from the base 1.25. The ratio table changes completely. Late-game setups look absurdly "low-machine" because they're module-adjusted. Ignore this and your design diverges dramatically.

Update Checklist

The trap: swap machines, forget ratios, watch everything break. Especially M1→M2 or M2→M3 throws the whole line off. Above tiers sometimes seem "overbuilt" even though materials stop arriving correctly. One fix is check ratios at each step.

Upgrade sequence:

1. Recalculate per-machine output with new speed
2. Recalculate machines needed for each stage
3. Identify fluid recipes that need M2+ (drop M1 stages)
4. Isolate module-using stages and recalculate separately
5. Cross-check belt lanes against new consumption

Updates matter because one stage speeding up shifts everything downstream. Early-game M1 ratios only apply to M1. Mid-game onward, treat each tier as a separate problem. Recipe's the same; machine type changes the maths entirely.

Common Failures: Ratios Match but Supply Still Short

Diagnostic Checklist: Belt → Inserter → Machine → Power

When maths says it's enough but you're short, don't assume miscalculation. Usually one of belt saturation, inserter throughput, machine malfunction, or power loss is the real culprit. I diagnose top-down: belt, then inserter, then machine, then power. Upstream-first cuts diagnosis time.

Belt saturation first: you need fully compressed lanes. Merge bias, post-splitter thinness, curved underfeeding—any gap kills real throughput below theory. Especially dense lines like circuits show this immediately: belt looks slow even when moving.

Inserter next: overlooked but critical. Ratio maths assumes "supply instantly reaches the machine." Real world has pickup distance, placement awkwardness, single-lane narrowness. A long inserter or crowded feed can become a bottleneck alone. I've fixed "production weak despite good theory" by switching one inserter to stack inserter. One item per swing versus five suddenly matters.

Machine-side: production-bar resets when recipes change. If you rebuild with different recipes, the bar empties and output limps until it refills. Early-game feels fine; late-game module stacking means this startup lag is real. Designs assume steady state, not transitions.

Module mismatch: mixed conditions kill ratios. Part of the line with speed modules, another with productivity, old M2s mixed in—counts instantly diverge. Different setups mean different real speeds; once you've mixed them, "theory" fractures. I've found the quickest fix is standardise all conditions in one stage before adding variance.

Power and upstream: belt and inserters can move smoothly but if copper plates dried up, downstream starves regardless. Furnaces, fuel, coal—these block supply flow. Looks like mid-product shortage but actually upstream's throttled.

Symptom-Based Fixes: Input Drying / Output Clogging / Cycle Stutters

Different symptoms point different ways. Input thins: upstream fails, belt unsaturated, or inserter weak. Belt shows one lane full and one thin? Merge or splitter design. Belt fully saturated but machines slowly starve? Inserter can't feed fast enough. Furnace-side copper running low? Upstream is the real issue.

Output clogs: machine too strong or ejection too slow. High-speed setups often fail at extraction—you speed the crafting but forgot inserters now pick up faster than before. Stack inserters and better ejection usually help. Or it's a downstream bottleneck masking as local clog.

Cycle stutters: short bursts of work then pauses, repeating. Usually means average supply falls short despite peak moments okay. Multiple lines tapping the same source simultaneously is classic—the bus runs fine, one segment dips, and that's enough. Module setups also show this if the bar hasn't recharged fully between crafts. These need either higher headroom on supply or isolation between competing consumers.

Module designs hide issues. Crafting power bar resets, so post-recipe-change you see weak output briefly. Looks like supply died but it's actually the bar rebuilding. Steady-state maths don't account for this.

Operations Trick: Spare Machines and Buffer Chest Placement

Rather than chase theory-perfect counts, build in tiny redundancy where you can. I spare one extra machine in high-demand stages like circuits. Not huge—just enough for absorption. Especially cables: a single spare line pays dividends.

Buffer chests work best placed purposefully: upstream supply where waves happen, and stage boundaries where buses feed local factories. Don't scatter them or they hide the real problem. Use them to absorb brief supply dips, not to mask shortages. The wrong placement disguises weak ejection or poor design.

Consistency matters most. Mixed module conditions per stage mean even spares don't help—you've fractured the design. Lock down conditions: this stage uses speed modules, that uses productivity, and old machines stay out. One decision per line, and the numbers hold. Failures usually mean conditions drifted unnoticed, not maths error.

Advanced: How Modules, Beacons, and Space Age Change the Formula

Plugging Corrections In: Productivity vs. Speed Adjustments

Here you're not tossing the formula—you're adding correction terms. Think stays identical: work out per-machine output, reverse to get count.

Productivity modules boost output per craft while input speed stays the same. Formula-wise, increase the recipe output number. You eat materials slower per unit output produced—classic efficiency win. Heavy-input products (heavy oil, steel) benefit most.

Speed modules boost the crafting speed stat itself. Add that to the base speed. Where productivity multiplies output, speed multiplies rotations-per-second. Combined, they're different axes: output per second on the y-axis (productivity), cycles per second on the x-axis (speed).

Doing both together: boost the output term for productivity, boost the speed for faster cycles. Both drive the final answer but apply to different formula parts. I always test the no-module version first, then layer in productivity, then speed, watching how each shifts the required count. Jumping straight to "both at once" invites arithmetic errors.

Beacon Fundamentals

Beacons broadcast module effects to nearby machines at half strength within a 9×9 range. So a beacon with speed-3 modules doesn't triple the adjacent machine—it kicks the machine an extra 1.5 speed.

Practically: stuffing productivity modules in the machine itself, speed modules in surrounding beacons, becomes the standard high-efficiency build. You're optimising input (productivity) and throughput (speed) separately. Placement determines how many machines one beacon boosts, and that number goes straight into your count—different setups, vastly different counts for identical recipes.

Parsing M3 at Speed 11.25 (Productivity Modules + Speed-3 Beacons + 12 Beacon Setup)

M3 hits speed 11.25 in hardcore optimisation: base 1.25, plus speed-3 modules in beacons. What seems like a speed-9× increase really means per-machine output balloons, so count shrinks. Same recipe needs maybe 1 machine instead of 10.

That single machine bottleneck now carries massive load. Any pause cracks the whole line. Supply must be flawless; extraction must keep up. This is why late-game designs look "under-machined"—they're module-optimised. Supply and power become the real limiting factors, and machine count becomes almost irrelevant. The formula didn't break; you're just riding the extreme end of it.

Space Age Split Into Its Own Section

Rather than blur boundaries, Space Age gets separate treatment. Quality tiers, special effects, and branching recipes don't fit the linear "output × speed ÷ time" model neatly. Once you grok vanilla modules and beacons, Space Age is an extension, but throwing it in now dilutes focus.

Vanilla's modular system is an add-on to linear ratios. Space Age changes assumptions. Sort ratios in vanilla first, then tackle the expansion as a new chapter with its own rules.

Hands-On: Calculation Flow and Checklist You Can Use Today

Using a Three-Line Format

Don't overthink this. Paper or notepad, three lines only: Target/sec → Per Machine/sec → Machines Needed.

Say you're running circuits on M2. M2's speed is 0.75, so grab the circuit recipe output and