Seven little robots. One very big future. Autopilot handles repairs. Take over anytime by holding a yellow alert.
Gathering operational data
Gen 1 · build a lab to start research
Output/hour: teal 60s, coral 5s · repairs/min: purple
Starting robots excluded. Teal averages 60 seconds; coral averages 5 seconds. Purple shows repaired robots/min on the right axis (60s window).
Teal online · coral offline
Last 60s · weighted by robot-seconds
Starting local logging…
Saved in this browser and uploaded to Eidos every five real seconds for analysis. Logs contain game state and controls; they are not game saves. Every run includes its source version, seed, economics, learning values, research, buildings, repair teams, and robot state changes. Telemetry is sampled every 0.1 simulated seconds; positions every simulated second. Actions are timestamped. Brief events between samples may be missed.
Export to keep a permanent copy. Clearing browser data removes these logs; storage errors are reported here. Closing abruptly may lose the last pending write.
Interactive experiment. More buildings can consume the power and supplies a factory needs to work. This simulation lets you inspect those tradeoffs. Expansion and power management use experimental rules; the learning component only adjusts customer-work allocation. Explore Eidos case studies.
Seven robots begin with one factory and one power station. Factory construction uses one worker initially, grows through every tenth newborn to a maximum of 20, and costs 300 robot-seconds plus materials. Each completed factory permits another factory project. EQ prioritizes repairs and construction using value and travel estimates. Autopilot is on by default; hold a broken robot to intervene. Repairs use nearby helpers within the shared 10% budget, with at least one helper for small fleets. Travel and repair take robots away from production.
Research can fail. Labs unlock at three factories. Up to 10% of workers build and staff labs, with at most 10 staff per lab. Work produces training data, not automatic intelligence. Each experiment needs research effort and data, then 20 research points of validation. Costs rise as 120 × (1 + 0.3 × prior experiments)^1.4. Outcomes are 25% failed validation, 35% software, 25% hardware, and 15% power technology. These probabilities and costs are game assumptions. Software improvements deploy to existing compatible robots; hardware designs require factories of that version. Higher research output can shorten intervals, but does not guarantee accelerating progress.
Hardware has tradeoffs. Factories lock their version when construction starts. Old factories still manufacture old designs; refits need a powered factory supporting the desired version. Every third hardware design is a compact specialist: smaller, cheaper in materials and chips, and fast, but less reliable and less accurate at general customer work. Industrial designs are larger and more reliable. Software raises shared validated capability independently of hardware.
Power requires installation. Each factory or completed lab uses one slot, with factories receiving power first. The starting station supplies three net slots. Research unlocks higher capacity, but robots must install each retrofit using 120 robot-seconds and materials. New stations cost 600 robot-seconds. A power technology discovery does not instantly change installed stations. Construction can work off-grid to restore service.
Useful work is different from more robots. A real online contextual bandit chooses whether 20%, 50%, or 80% of manufacturing effort serves customers. It updates learned action values every 60 active seconds from net earnings per second, using three order-backlog contexts and exploration of uncertain choices. The model resets with the game. Its decisions affect customer work versus robot production; repair and building policies still use rules. Improvement is not guaranteed, and live trials are not a controlled comparison. The one-minute horizon captures some delayed deliveries but not the full long-term return on research. Orders arrive from outside; suppliers replenish finite stocks of materials and chips. Demand and supplier throughput increase slowly with earned revenue, not directly with fleet size. Customer goods take 8 effective robot-seconds and 0.25 materials per unit, and pass through a 10-second inspection delay. Only accepted deliveries generate revenue: 5 illustrative credits each. Consumed materials cost 1 credit, chips cost 3, robot upkeep costs 0.002 credits per robot-second, factories 0.02 per second, completed labs 0.03, power stations 0.01, and repair operators 0.02. Net earnings subtract all these costs, including inputs used for new robots and buildings, immediately; this is a simplified cash-surplus measure, not accounting profit. Initial assets are endowed, inventory is charged when consumed, and financing is not modeled. Robot-hour earnings include broken and idle robots. Rejected goods return to the order queue. Shared software defects can reduce quality across the fleet without stopping robots; inspection detects them and a 12-second patch-validation period restores quality.
The charts distinguish robot births, repaired robots, verified deliveries, and fleet availability. Availability is weighted by robot-seconds over the last 60 active seconds; being online does not guarantee useful or correct work. Paused and hidden time do not advance the simulation. Above 10,000 visible robots, weighted groups preserve headcount, production mix, and quality averages; mechanical failures and refits affect represented groups. Inspection uses expected fractional outcomes for batches. This is an illustrative model of feedback and constraints, not a calibrated forecast of AI progress.
Zoom with the wheel; Shift-drag pans. Labels stay above the scene. Workshop recordings: credits and license.