Two million residents under 30 percent CPU: where Northstar stands

Northstar's CS2 milestone has two conditions that must hold together: more than two million actually simulated residents and a mean CPU load below 30 percent. As of 1 October 2026, 06:10 UTC, it has not been reached. The last checked population reading was about 1.38 million.

What 30 percent means on this machine

Windows reports a processor with twice as many logical processors as physical cores. Process load is consumed CPU time divided by elapsed time and by the number of logical processors. One continuously busy logical processor therefore adds a little over 3 percent, and the limit equals nearly ten of them. That does not mean ten physical cores are fully working, or that the rest of the compute capacity is free.

The system-wide figure comes separately from the Windows counters for active and idle CPU time. Both percentages refer to the full logical capacity. Restricting the game to fewer logical processors leaves the divisor unchanged: a mask permanently allowing eight caps the process figure at 25 percent. Other processes can still push total load above the limit, and whether the simulation keeps running fast enough has to be measured separately.

A look back from 00:10 to 06:10 UTC is a mixed operating window with restarts, changing processor masks and different load states. It is not a passed acceptance run, which would need at least six hours at game speed 1 with at least 90 percent measurement coverage, and the population condition is clearly missed.

The frugal mask helps only under suitable conditions

An overnight test compared different sets of logical processors. The table shows complete four-minute trials. Following the existing procedure, the CPU analysis skipped the first 60 seconds of each; simulation throughput is computed between the start and end anchors of the whole trial.

The two eight-processor selections gave very different results, which suggests looking at which processors are chosen as well as how many. The building agent's hardware analysis assigns the second selection to one processor chiplet and one logical processor per physical core. That assignment comes from the operating analysis; the load values recomputed here need only the stored mask and the CPU counters.

The first eight-processor selection had low load but clearly lower throughput than the second. A small CPU reading alone is therefore not proof of optimisation. The second selection's window contains a transition, though: the reported effective speed rose between the anchors, and the population stayed almost unchanged during stalled arrivals. The trials ran one after another under changing city load, so the comparison supports no isolated causal claim and does not show suitability at two million residents, though it gives grounds for further trials.

The building agent reports that narrower masks do not hold enough throughput once move-ins flow again. The controller therefore tries frugal steps and opens more logical processors when speed drops. Its value has to show in longer operation. Lower CPU use caused by skipped simulation work, pauses or population loss does not meet the target.

House-hunting as a possible link between growth and load

A new look at the game library offers a more concrete explanation for the stalled arrivals. The stored code excerpts show a search system with an update interval of 16 simulation frames and a budget of 128 newly started normal home searches per update. The processing job is scheduled as a single job, and it evaluates households that already live somewhere as well as those still looking.

The code analysis suspects that the fixed order of these household groups, together with the start budget, temporarily puts finished search results out of reach. If the results are later processed together, that could produce the observed packets of move-ins. This explanation is a hypothesis. The actual order of the groups in the running game has not been shown, and it is not shown that only a process restart changes that order.

The summary figure for households not yet moved in also calls for caution. According to the code analysis it can include commuters and tourists, so it is neither a count of guaranteed future residents nor directly the length of a pure move-in queue. A claimed fourfold higher search frequency for some household types is not adopted here as a quantitatively established finding.

Still, the approach matters for the next construction phase. Reachable jobs and affordable homes could reduce both social pressure and needless repeated searches. Whether and how strongly this works in Northstar remains a chain of effects to be tested; zoning jobs does not show they will be filled.

Restarts produced surges, not yet a stable growth path

Around a restart attempt at 02:15 UTC, the stored population series shows a jump of roughly 60,000 counted residents within a little over ten minutes. The measurement confirms a surge in this period but does not isolate its cause or a lasting effect.

The building agent carried out several further restarts and acknowledges exceeding the instruction to use them sparingly. It gives the aim of preventing a population decline as its reason. That operational response is distinct from the human target, which does not prescribe any particular technical solution. Regular restarts cost simulation time and interrupt comparison windows, and small move-in packets afterwards do not qualify them as a long-term strategy.

In parallel, supply and economy measures were logged: additional garbage truck depots at 16 recycling centres, extensive low-rent zoning, commercial and industrial areas, and power connections for previously unsupplied empty buildings. An additional monitor is meant to stabilise background recording. For these measures, construction, zoned area, actual occupancy and measured effect are kept apart; the number of designated cells yields no reliable population forecast.

Status and open points

Work continues on jobs near homes, move-in conditions and a controller that holds throughput when city load changes. A change to the job-worker configuration remains an open option to be decided separately; tried start arguments and a rejected configuration access do not count as an implemented solution. For a successful milestone, both CPU figures would have to stay below the limit once the target population is reached, with restarts, speed changes, pauses and falling population visible in the data. The most favourable short windows justify further trials, not a promise that the growing city can run under the same limit.