For most of computing history, a personal computer had one user. You opened apps, closed them, and the machine waited. That assumption is quietly breaking down. Agents now run alongside normal work — opening browsers, spawning dev servers, writing files — and the computer’s resources are shared between us and them, continuously, whether we’ve thought through the arrangement or not.
The Mac mini’s $899 headline price is a good place to sit with this shift for a moment.
The price you see is not the config you need
Apple’s entry-level M6 mini ships with 16 GB of unified memory (a design where the CPU, GPU, and other chips share a single pool, unlike conventional PCs where the graphics card has its own separate video memory) and 256 GB of storage. For a lot of everyday computing, that’s enough. For a machine that runs agents throughout the day alongside a browser, an editor, and background services, the evidence points in a different direction: 24 to 32 GB of RAM is a more realistic starting point, and 512 GB of storage is a sensible floor — with 1 TB or more if the work involves large video files or downloaded AI models.
That gap matters because the advertised price and the price of the machine you’ll actually want can be quite far apart. The exercise worth doing is pricing the specific configuration that fits the actual workload, not the one on the product page.
Agents as roommates, not guests
The useful mental shift is to think of agents not as occasional visitors but as co-occupants. A guest arrives, does something, and leaves no trace. A roommate uses the kitchen, leaves dishes, keeps the TV on, and takes up space in the fridge. Agents are closer to the latter.
A dev server started for a project and never closed is still consuming memory an hour later. A build cache written to disk is still there a week later. A model kept resident in memory so responses stay fast holds that memory even when it hasn’t been asked anything in two hours.
This is not a criticism of agents — it’s just the reality of how compute-intensive software behaves. The thing that’s changed is that we now routinely run several of these processes in parallel, often without having agreed on any rules for resource sharing.
Measure before buying
The most useful single action before making a hardware decision is running Activity Monitor (macOS’s built-in system monitor) during actual work — not on an idle desktop. Memory pressure, swap usage (when macOS borrows storage to supplement RAM), and the specific processes at the top of the CPU list during a real session tell a clearer story than any benchmark.
The active-load problem and the retained-files problem are worth separating. A running dev server is the first kind. A 50 GB crash-report folder or 100 GB of accumulated Git checkpoint objects are the second kind. Both eat resources, but the interventions are different, and conflating them makes both harder to address.
A practical starting point: ask an agent to do a read-only audit — inspect what’s running and what’s been written, produce an ownership-attributed report, and stop there before any remediation. That audit often surfaces the actual constraint before any hardware spend.
One job at a time, then measure again
There’s a tempting assumption that the number of open chat windows corresponds to the number of things running locally. It usually doesn’t. Many cloud inference calls (where the model computation happens on a remote server, not on the local machine) still leave local processes running: dev servers, file watchers, build tools. A faster chip at home doesn’t speed any of that up, and a higher core count doesn’t translate directly into a safe agent count.
A more reliable pattern is to start with one heavy job running locally, measure actual memory pressure during that job, and only then try running two simultaneously. That sequence produces real data. Opening three agent sessions and hoping for the best produces a crash at a bad moment.
The cost calculation that actually matters
Hardware choices look different when the first-year cost is laid out in full: incremental hardware price plus accessories, power, backup and storage services, and — most importantly — the hours spent on setup and recovery when something goes wrong.
A break-even analysis for a more expensive configuration looks like this: if a $1,600 premium over a baseline machine saves roughly 18 hours of friction over the year, the implied value of that time is around $89 per hour. If it saves only four hours, that threshold jumps to $400 per hour. The time estimate matters far more than the spec sheet.
Putting rules where agents can read them
One underused option is writing resource-sharing conventions directly into project instructions — the files agents already read before starting work. Result locations, queue rules, cleanup scope, stop conditions. These act as the “house rules” for the shared machine. Agents that know where to save results and which processes to retire when done are easier to run alongside real work than agents that don’t.
As agent workloads grow heavier and more continuous, the machines running them will need clearer management, not just more memory. The hardware decision and the operational hygiene decision are both worth making deliberately — and in that order.
Text summarized and optimized using Anthropic’s models and reviewed by a human.