Apify bills memory multiplied by time, so a container held open at 4096 MB costs eight times per second what the same code costs at 512 MB, whether or not anything uses the headroom [8]. The four Actors in question have no browser and no Playwright, one dependency, plain `fetch`, and detail lookups that run in a sequential rate-limited loop [9]. The author's summary is "four gigabytes to hold one HTTP response at a time" [9]. 4096 divided by 512 is 8, and that multiplier lands on the whole wall clock, not on some peak the heap never reaches [20].
The re-run closes it from both ends. Cost moved roughly linearly with the memory setting while time stayed flat [11], and on a real workload of 51 rows in 108 seconds throughput was identical across settings [12].
What has to be true for that to transfer: your working set has to actually fit in 512 MB. Nothing here measures a browser-based Actor, so the finding is scoped to browserless fetch loops, which is exactly what these four are [9]. If your Actor drives Chromium, the 8x is still the billing rule, but the flat-in-time result is untested.
The spread was reported as 96x across $0.008 to $0.730 [3]; after the memory fix it is 33x [13]. That means one config field inflated the apparent spread by a factor of about 2.9 [21]. Note also that 0.730 divided by 0.008 is 91.25, not 96 [22], so the headline multiple came from figures behind the rounded table rather than from the table itself.
Defaults did not drive the cost here; architecture did. Requests per row remains the largest architectural driver and accounts for the entire 33x that survives the fix [14]. What the memory setting corrupted was the ranking: four Actors sat at the top for a reason that had nothing to do with their code, and the first draft explained their position with a well-supported argument about their code [19]. The author's own framing is the useful one, that a derived number hands you a value and a ranking, and a misconfigured input gives you a confidently wrong ranking rather than a slightly wrong value [18]. The ranking is the part you reason about.
Which is where per-event pricing comes in. Eleven Actors had prices named per unit of value before anyone knew what a unit cost to produce [17]. Two things make that hard to fix after the fact. On the free plan, runs and their datasets are kept for a limited window and then removed, and figures from two weeks earlier were simply gone [15]. And a single run is not a measurement, because per-run overhead lands entirely on however many rows that run happened to produce [16].
One field is the fix, not eleven separate edits. The 4096 value is the kind that lands in a scaffold template and then in every Actor built from it, and the author has no memory of choosing it [10]. So the memory field belongs in the same review as the price, and the template is where you set it.
