Mac Mini para agentes de IA: cuánta memoria necesitas y cómo usar la que tienes.

[0:00] I'm just going to say it. You're not the only user of your computer anymore. If you run agents all day, they're probably using it more than you are. Now, I know what you're thinking. My Mac's getting old, I need a bigger one. You might also be watching because you're pricing a Mac mini or a Mac Studio, or maybe there's an Nvidia machine you're comparing. Here's the problem. A faster chip and more memory will not stop the agent load that you're driving from growing and growing and growing. Your agents open browsers, they start service, they write files, they leave a lot of it behind on the machine when the job is done.
[0:30] Basically, you have a messy roommate and nobody set the house rules. So, we have to set them together here. Let's do it. And don't worry, I wrote those roommate house rules down for you. There's a guide on Substack that goes with this video with three prompts you can hand straight to your agent. One to find what is eating your machine, one to clean up only what you approve, and one to design a really regular checkup so that your memory load and all of the stuff that makes your computer slow doesn't creep back. The link is in the description below, and if you're connected to Nate's
[1:00] MCP, your agent can actually just pull those prompts right now, straight from the library and get to work. You don't even have to go to the Substack, you can just hit the MCP. So, by the end of this video, you're going to know which computer fits your agent workloads, how to get more useful work from the machine that you have on your desk right now, and how to make sure that your agent human setup, your roommate arrangements, are reliable as you add more agent jobs. There're going to be four principles I use to connect these decisions. Let's start off with a doctor checkup on your back. If you're on your Mac and you open
[1:31] up Activity Monitor and you click Memory, you can actually literally see the memory pressure graph while the work you care about is running with agents. And it it comes in colors, right? Green means it's doing okay, yellow and red mean the machine is struggling. Mine are often in yellow and red, to be honest. Look at which applications are using memory. A high number in the RAM used bar doesn't tell you you need another computer, per se, but it sure does tell you you need to look at your system. Then, if you're still [clears throat] doing your checkup, look at storage next. Look at system settings, general,
[2:02] and storage. And RAM is the working space for what you're doing. So, storage is going to hold your files, it's going to hold your software. macOS can use storage for swap memory, which temporarily holds memory contents like a credit card hold, so the two don't get in the way. But, fundamentally, you need to think about how you allocate that memory so that you are not essentially trying to build on top of a bunch of agent holds across a bunch of harnesses. And that's one of the things I see. Like, when you have Claude in Chrome, and you have a bunch of working
[2:32] memory in another browser. I use Zen. When you have a bunch of working memory in Codex, and a bunch in Claude, and then you have another AI tool, maybe it's a a transcription tool. All of it adds up. It's memory pressure. Now, this is something the labs have paid attention to. Tibo at OpenAI recently shipped a Codex improvement that reduces how much memory Codex uses. That's definitely been a problem. But, these point fixes from the labs are not enough, especially if, like most of us, you're running multiple harnesses. I know a lot of folks in the community
[3:02] here are running local models like Qwen, they're running models like Claude, they're running Codex. We have to have a system that works with all of them. And that's what this is about. This brings us to the first principle. You got to know where the work happens. Suppose you ask OpenAI's Codex or Anthropic's Claude code to build a little website for you. Very typical ask, right? The model might be answering from a data center, but that doesn't mean there's not pressure on your system. Your computer is still running the development server, the browser that checks the website, the
[3:33] build tools. All of that is local, and you feel it, right? If you give another agent a different project at the same time, it's going to start from a different set of tools, and it's all going to hit your local computer. I felt this when I was using uh Claude to build Blender videos at the same time as I was having my Codex do other work. Like, it just chews on your memory. And so if you're getting memory warnings, include the local tools you have in your diagnosis and expect local tools to be your principal path to resolution. It doesn't mean you have to stop your agent
[4:03] work. We're not saying that, but you have to think about how you do it and you have to get into the details. You want to make sure that you're not just buying a graphics card you think will be a point solution to this problem. As I keep saying, you can buy your way into more capacity, but you can't buy your way out of the problem cuz agents are going to keep getting more capable. So bottom line, treat the memory problem as local and something you have to resolve with your agents before you add more. If you're running a model locally, you have to think through the compute requirements for that model. And if you're running a mixed setup, which I
[4:33] think in practice a lot of people are, you have to understand, by looking at the settings I just described, what is hitting your memory from a particular application. When is Qwen hitting your memory locally versus when are Codex and Claude hitting your memory. You should be able to see that. Let's go back to our website story. Imagine the agent finishes the website and you move along, but the development server and the browser, they're still open in the background. What people don't realize is your human attention has moved on, but those tools are still using passive
[5:03] resources. They still have that credit card hold on your memory. The project has dependencies. It has build files taking up your storage. You have to actually shut everything down when you want those files to go away or when you want to stop that hold on your working memory. And you might think most of what Nate's talking about is just agents, but to be honest, some of it is from the bugs that come with Agentic software. In one public Codex report, a user described a crash report folder that grew to over 50 gigs just describing crashes. Another described
[5:34] more than 100 gigs of Git objects associated with turn checkpoints. Th- These are particular setups. I'm not saying this is your issue per se. I'm saying pay attention to the detail on your computer. Pay attention to your specific setup. This is why I'm emphasizing audit first, and then you can figure out a strategy with your agent to fix it. This is absolutely a useful job for an agent because the short version of the diagnostic prompt, the thing you give to your agent is this, right? You just tell it inspect my computer. Please don't change anything.
[6:05] Please identify the largest memory users, the ones that are memory sucks, and the relevant directories. Please explain what each belongs to and propose specific fixes that help me do my actual work. Now, I have a full prompt over on Substack and a guide that goes into more detail because really you need to have a comprehensive hygiene program. But fundamentally, you want to start with a report like that because just cuz a folder is being used, it doesn't tell you whether it's being used usefully. You have to actually dig in, right? For
[6:35] example, suppose you do an inspection and you find out you have a bunch of development servers running at once. Hey, that's me. I've done that on multiple side projects. Before ping one, figure out what it's serving. If the project is finished, if the server is no longer needed, was it an experiment, right? Then close it and see if the memory pressure eases up. See if the storage pressure eases up. Establish what you can regenerate and then figure out the cleanup method. If this all sounds really boring, I got news for you. We've had to live with computing
[7:06] constraints since the 1980s and we're back to it now because we have agents who are rooming with us on these computers and we just have to figure out how to be good roommates. Another example of where you might look is around SSD memory issues. Solid state drives, they're very fast to write and rewrite. There was an excessive logging issue there with Codex earlier this year. One of the reporters measured roughly 37 terabytes of SSD writes over 21 days. That's a lot. Logging fixes were shipped by Codex in June and a later release added some reclamation of the unused log database space, and
[7:37] that's progress, but also if that's an issue, it reminds me and it should remind you that these are pieces of software that are evolving and we should be paying close attention to how they're using the physical components of our machine. And of course, there's also growth that comes from just having agents that are more capable. More useful features working as intended. Look at the growth we've seen in coding agents since January. You can create work trees, you can have separate working directories. The directory can have its own dependencies and build caches. And Codex has settings for
[8:08] managing all of those environments. And before you sort of pick one and decide your settings, you should actually think through how do you want to do this build project and where? And this is where I'm going to have a side note on using cloud versus local environments. I'll just show my cards. I like local as long as I can because local lets me switch between harnesses and between AI tools really easily. I can just point it at a file directory and say go use that. And so there's no way out of thinking this
[8:38] through. Whether you're using cloud or whether you're using local. My rule of thumb here is to give every single agent a stop sign. Give it something that makes it be done. And then put the results somewhere I can find. Right? Like that's something you want to think about because I think a lot of the time we start things and we leave them unfinished. They may be unfinished in the sense that the Chrome tab is up with your working project. They may be unfinished in the sense that the chat is up and it's got some development server running. But ultimately, if you don't have a reason
[9:09] to stop, all of the AI agents have been RL VR, have been trained to keep going. And so they'll just keep eating your local machine. More capacity gives you more room, but it does not solve that problem. You have to figure that one out. So that's principle number two. The third principle as you handle all of this is to manage simultaneous demand. Suppose you have a dozen docs to process and you put 12 jobs in the queue. This is all very realistic. I do this, right? And you run one or two heavy steps at a
[9:40] time. The agent is actually able to profile that load and plan the whole assignment without launching every browser and conversion tool and local model requests simultaneously, and it can do it and it should do it. You just have to ask it. So, I would say in that world, you just have to tell the agent, "Can you dial up to optimize for my load? Start with one active job, maybe then move to two, check how the work finishes, check the memory requirements." Your agent is a good partner here. It's compute native. It can check this stuff. If adding jobs
[10:10] slows everything down, you've learned that you've pushed your current computing to the limit and you need to back off a little bit. And this is why CPU core count does not translate directly into agent count. Like, there's no simplistic answer here. Two agents waiting for cloud responses may end up doing very little locally, but two agents running a big build or rendering a video are going to eat whatever CPUs you have on hand. So, more cores can help when the software is able to use them, and more memory can help when active work needs that space, but you
[10:41] can't just optimize for that number without thinking about it, without thinking about the load you're actually using the machine to work on. If you are investing in big hardware, you can get more out of that hardware with the same process, right? Separate the stages of the job, let several agents research and plan while the big local build happens one at a time in a queue, and you end up matching the schedule to your resources rather than making every task compete for them at once. And if you think, I'm going to keep saying it, you can have
[11:11] your agents doing it. That's part of why I built the prompts I built, because this is too much to manage for yourself. Then, look at work that doesn't need to happen, right? Have the agent inspect an existing project before scaffolding up another environment. Reuse a browser where that's appropriate. Keep your outputs in a predictable folder structure that you and your agent understand. Ask it to identify the processes that should remain running afterward. And ultimately, keep what you're learning in project guidance so you can reuse it. If you're using local models, the software
[11:41] settings are going to matter here, right? Docker Desktop has limits for its virtual machine. It has an idle resource saver. Model servers have controls for how you handle context and parallel requests and how long models remain loaded. Those are all relevant for your load on your machine. And so, in the guide, I'm going to get into Ollama, LM Studio, Docker, and how you set that up because, if you can't guess, I'm really passionate about getting the most out of your machine. And if you're running local models, guess what? You still have to size the request, and you have to handle simultaneous work for the task. A larger
[12:13] context is going to use more memory if it's a local model. Multiple requests are going to add up. Keeping a model loaded up all the time, it can reduce the weight on the next request. It reduces your latency. It's still going to suck up memory between jobs. You're going to have to work with your agent to pick the trade-off depending on how you use it. This gives us a reason for the hardware purchase conversation. The work that you do that needs more capacity, when you have maxed out your machine, you've done the audit, you've checked the load profiling, now you're talking
[12:44] about getting more hardware, and you're talking about whether you can do it efficiently. You have an ROI conversation with yourself, or maybe you just are whimsical and you buy it. I know I have an ROI conversation with myself cuz these things are expensive. One thing I will say, as you think about getting a new computer, if you buy a new one, keep the old one. Keep it running. Because if you can keep it running and give it over to agents, you can do a lot of jobs that may be slower and offload a lot of compute and use tools like Tailscale to do that. So, if you're starting up the hardware search, let's
[13:14] start before we get to brands and talk memory usage where agents are today. My starting assumption, unless you're a super heavy user, is to work with 24 to 32 gigs of memory right now. Sixteen can be workable. You will have to actively work on it more. The larger range gives you more room to have ordinary applications, the stuff you use, and agent tools that you want open together. This is not something that I can say is going to be hyper-optimized for Codex or Claude, but that's actually not how I buy hardware right now. I buy it for me
[13:44] and assume I'll have different harnesses over time. On the storage side, I'm looking at half a terabyte of space as a starting point and a terabyte when I'm working with big videos, big projects, big files. If you're building websites, if you're generating a lot of film, you want to use your actual work behaviors to guide how much storage you're going to need. And just to note, you might wonder, "Why is Nate talking about Mac and not Windows?" I'll be really honest, as I've said repeatedly before, the AI
[14:14] revolution is six or eight months ahead on Mac compared to Windows. Windows machines are getting AI, but they're not getting it as fast, and it's partly because the labs are all running Macs, partly because Mac chips are better optimized for AI, net-net. And so, when I talk about Macs, I'm basically giving you tips that you can apply in other environments, but the pointy end of the pain, the thing that most of us are struggling with, the machines I see hurting are coming from people who are using Macs because they're leaning in on agents and they're giving them a lot of
[14:44] workloads. And so, that's why I'm specific about Macs here. On the Mac side of things, if you're shopping for a Mac, Apple lists the M6 Mini for $899, and that base machine does have that 16 gigs I talked about and a quarter of a terabyte, 256 gigs of storage. It is a little bit slim on the new purchase configuration I just described, but you can make that work. The M6 Mini is another play, that one can be configured with up to 32 gigs of memory, and the M5 Pro Mini starts at $1699, and it goes up
[15:17] to 64 gigs of memory, which is even more. And the Pro needs, you know, you need to decide you really want it, right? You're going to commit to more active memory, you're going to commit to sustained local work, probably with local models, and I I want you to think that through. I I made a video on Macs before, and and I realized I talked about them as purchase objects. I talked about them as things you would shop for, and a little bit about the AI workloads. But the reason I'm making this video now is that the more we lean into agents, the more it's a entangled relationship.
[15:48] The more it is I have to understand what my agents are doing to make a good purchase decision. And so that's why we're making sure that we understand that in this video. Now, if you're a traveler, a MacBook can make sense because, you know, obviously you slip it in, you can go anywhere you want. I think you want to make sure, if you get a MacBook, that you get something that is not going to hamper you on the road. And this is where like Tailscale is actually a remote way to control and manage other machines. So you could use Tailscale to manage a Mac mini, manage
[16:18] an old laptop while you have your working laptop with you. But even in that case, what I find is the computer in front of me needs to work for the work in front of me. So make sure you think that through. Now, the chip guys, including Apple, are talking big big game about neural processing units, or NPUs. And they're talking about it as if that's the answer on AI. I'm here to tell you, you can use it for your workload. It is not a magic silver bullet. You are still buying hardware to get work done, and you have to think
[16:48] about whether it's going to get the work done or not. And it you're optimizing the whole system, the way memory works, the way storage works, the way processing works. You're not just optimizing for one magic chip and calling it done. So don't be sort of sold on magical features here. You have to actually understand how these work together, and a good audit, as I keep saying, is going to help you get there and assess intelligently whether you're short on your CPU core, whether you're short on your memory, whether you're short on your storage. If running models locally is one of your goals, and I know a bunch of you are passionate about it,
[17:19] the memory available to the accelerator and the software that that supports is going to be really key for figuring out how you configure your system. If you have a higher memory Mac Studio, if you have an Nvidia system, maybe you have an AMD unified memory machine, think about how those different memory arrangements enable you to run different loads. And I would actually have a whole conversation with your existing system, your existing agents, where you actually talk through the technical detail of how your current
[17:49] workloads are eating your memory, how they're eating processing cores, and then start to simulate that against different technical arrangements, so that you can understand where you actually are going to get the most bang for the buck. If you're going to go with Mac, a higher memory Apple Silicon Mac is going to let you run local models as well, and you're also going to be able to run your own native Mac applications. If you're in the Nvidia ecosystem, an Nvidia GeForce RTX approach is super strong. Like, it's basically designed to help you run local models, but it
[18:20] expects CUDA, which is Nvidia's computing platform. And if your work depends on GPU tools and your hill climbing and your fine-tuning your models, that all works great, right? If you are that kind of nerd, and I know a bunch of you out there are, fantastic. Moving on from Nvidia, if you're in an AMD-based environment, which anecdotally not too many people are, you want to be able to put together a very high-memory setup to make sure that a conventional Windows or Linux PC is going to run well. There are also folks who have Omaki on there, and that works great. I
[18:50] did a whole video on Omaki and how it's agent native. That absolutely applies there. Nvidia Spark has its own software requirements. I could go on. My goal here is basically to get you to think about the level of machine maintenance that you're comfortable doing, and the level of profiling you want to do. The more room you have, the more you can be a little bit looser and lazier with how you profile, and the more you can be a little bit more comfortable using your computer while the agent or
[19:20] agents also use it. In general, I would say the least technical choice is Mac, and from there you're just getting more technical. And by the time you get to Nvidia, by the time you get to AMD, if you're installing a operating system like Ubuntu, like you're a builder, you're a technical person, you feel comfortable with that. You should get excited about it because you're going to get a lot more control. It's like manual transmission versus automatic in a vehicle. If you're like, "Nate, I want to go deeper. I want to understand a deeper sort of local model buying trade-off." I have that in the computer guide for Substack. The important
[19:51] distinction here is that memory needed to hold a local model is an additional requirement. So, think about your local model strategy. If you're trying to purchase a big memory machine, make sure you're doing it for a good reason. Either you're running a lot of cloud models and they're using a lot of local files and tools, or you're running a big local model. Ultimately, you've got three choices and most people have two. You can either keep the machine you have, that's definitely an option we all have. You may have to actively profile it
[20:22] more. I talked about that earlier in this video. You can upgrade in some cases. In a lot of cases, they're locking that off and making it harder. Mac certainly makes it harder. Or you can buy a new machine, and then you can use your old machine for agent stuff. All of those are options. I just want you to make a choice that is intentional and anticipates where agents are going. So, the fourth principle here, and I know you wondered where that was going. The fourth principle is to make sure that you have an ongoing maintenance plan. A machine that you use interactively needs to get your
[20:54] attention when that machine is struggling. A machine that you leave running in the background with Tailscale can just kind of chew through stuff, and it has a different maintenance and attention requirement. So, when we talk about AI and we talk about how we manage this over time. I am a big fan of making sure that you give your agent a regular job to keep your computer healthy. This, by the way, goes for those agents we use that are on virtual machines. I have an entire Grok Bot agent that is dedicated
[21:24] to keeping my Linux Grok Bot healthy. Like, it's a Linux install, it has to be healthy, and the Grok Bot just obsesses over that. You can take a line from that onto your local machine. You could ask the agent to track directories to make sure that it understands when something changes enough to get you to pay attention, to preserve active work, to prioritize human usage over agent usage, and put agent usage in the background. Or you can switch that if you want, but I tend to like being able to do stuff on my computer. And all of that can be done
[21:54] with a high degree of confidence because the agents are compute native. And that is one of the larger underlying things that has changed in the last year, hasn't it? We always had LLMs in the age of AI since Chat GPT. We have not always had the confidence that these agents are smart enough to effectively help us manage compute loads. Now we do. Just a note, I've mentioned Tailscale a couple of times. If you've been confused on what it is, it is a way to manage
[22:25] machines over a private network. In other words, Tailscale provides a private connection anywhere in the world, and you can work with your computer remotely, and you can do it safely. And so, a lot of us use Tailscale with a local machine at home, and wherever we are in the world, we can give that machine with the agent's instructions, and it just is really easy to manage. It's not too difficult to set up. One of the ways you can actually save hundreds of thousands of dollars on compute is to remember you probably have an old computer lying around, an old Mac mini lying around, an old Windows
[22:56] laptop, an old Mac laptop lying around, whatever it is. And you can say, "I'm going to hook it up. I'm going to use Tailscale to manage it, and I'm going to make it an agent computer, and the agent can just own and drive and do work for me there. That's a lot cheaper than buying a new one. And if you're a hardware geek, Raspberry Pis have been around for a while. They're tiny little boards, and they play a a similar but smaller role in this world. You can use Raspberry Pis to drive e-ink displays. I certainly do that at home, and you can use them to expose small local services while your laptop is elsewhere. Again, Tailscale could be helpful there.
[23:27] Ultimately, it is going to be your call how much compute you want to allocate. Part of why I am doing this video is I want to save you money. If you are using your computer to the max, you are less likely to need to buy more. And if you buy more, you are going to be smarter about it. And so, think of it this way. We are trying to understand how to make the most of the roommate arrangement we have with our agents today. We have the house we have. We have the rooms we have. We are trying to make sure before
[23:58] we buy a new house, metaphorically speaking, before we buy a new computer, that we are making the most of what we have. And if we have an old disused shed in the back, which is my favorite metaphor for an old disused computer on your floor somewhere, we're going to use that. We're going to make sure that we have that, and that's part of our living space, that's part of our computing space for agents, before we run out and purchase more. Cuz I know we all like unwrapping presents under the tree, but I also like making sure that I am not being wasteful with my bucks. And so, I want to make sure that you have the tools you need to actually make a smart
[24:29] purchasing decision, and to keep and use what you already have with a lot of confidence. Okay. So, let's give you some takeaways that you can go with. Obviously, if you want deeper detail, it's way deeper than I can do in a video. Go to the Substack guide. You can literally feed it to your agent, and your agent can run with it. It's going to cover all of the different tools I talked about. It's going to cover the audit in the guide. It'll be very helpful if you're trying to effectively make more out of the compute you have. Other than that, if your computer is struggling as mine was, run that diagnostic check and make sure that you
[25:00] understand the memory usage, the storage usage. Make sure you understand the pressure on your CPU cores. Make sure you understand what is driving that and make sure you understand how to profile your work. Profile is a fancy word for basically saying sequence the work so you don't put a bunch of load all at once and it's super peaky and it just blacks out the machine. I had a memory crash just last night because I opened one new program as a human and it was fine before. Those things happen, but they happen less often if we're actually good about not overloading. But
[25:32] generally speaking, we want to be smart about managing our demand so we we do simultaneous demand. So the next time you sit at your computer, I want you to think about it as I have roommates. I have many agents that are roommates and we have to negotiate living arrangements. We have to negotiate who's taking up space. We have to understand how we're all using this so it's productive. It is basically who's washing the dishes for AI and you on your computer. Who's dealing with the hygiene? No one wants to talk about washing the dishes in roommate conversations. It's the boring bit, but
[26:02] it's super important to keeping the house running. My goal here with this video has been to make sure you understand the core primitives, like memory, like CPU, like storage. You understand how agents are using them, how you are using them, and ultimately you have a plan to use them better or if you're shopping to make a smart purchase for what's next. Good luck and go Hawks.