I replaced my home lab scripts with a local AI model, and scripts won every time

Published Aug 21, 2026, 6:00 AM EDT Anurag is an experienced journalist and author who’s been covering tech for the past 5 years, with a focus on Windows, Android, and Apple. He’s written for sites like Android Police, Neowin, Dexerto, and MakeTechEasier. Anurag’s always pumped about tech and loves getting his hands on the latest gadgets. When he's not procrastinating, you’ll probably find him catching the newest movies in theaters or scrolling through Twitter from his bed. Most of the automation in my home lab has always been handled by scripts. The problem is that scripts are rigid. If I want an automation to behave differently based on available storage, the state of a service, or the output of another command, I have to account for every condition while writing it. Technically, an AI model can do a lot better job here because it understands context better. “Technically”, because I did try to replace my handy scripts with a local AI model, Qwen3.5 9B to be precise, and it did not do as good a job as I expected. I handed my routine scripts to Qwen3.5 9B It did a good job when it did it I started with a few jobs that were already running through cron. One script checked whether my Docker containers were running. Another monitored storage and warned me when a drive was getting full. I also had a script that removed old log files before they started taking up too much space. These scripts could only respond in ways I had already defined. For instance, the storage script can warn me about low space, but it cannot inspect the drive and tell me what has suddenly grown. The container script can restart a service, but it can’t read the logs first and decide whether restarting was the correct response. I ran Qwen3.5 9B through an agent harness with shell access to my home lab. I then replaced the cron commands with scheduled prompts. Each prompt described the result I wanted and set limits on what the model was allowed to change. The model was able to run the same commands as my scripts, read their output, and decide what to do next. The results were not bad. It was able to execute the automations as I wanted them to, and whenever this worked, the result was a lot better than the script, but I also noticed a lot more failures than I did with my scripts. For example, Qwen could check the containers and bring back one that had stopped. When storage usage increased, it could inspect the drive and identify which directory was responsible. That saved me from writing extra conditions into each script. However, Qwen did not always follow the same process. Sometimes it inspected the system correctly but stopped before taking the requested action. On other runs, it completed the task but skipped a check mentioned in the prompt. Scripts get the job done without fail They fail very rarely Once a script is working, I don’t have to think about it again unless something breaks, which happens very rarely. Cron starts it at the scheduled time, and the script follows the same path on every run. There is no interpretation involved. Take a backup script as an example. I can make it stop if the destination drive is not mounted. That rule remains in place every time the script runs. It will not choose another directory because it thinks completing the backup is more important than following the original instruction. Scripts still fail when something in the system changes. If a directory moves, the script usually stops at the same command on every run. I can reproduce the error and fix the line responsible for it. Once fixed, I do not have to wonder whether the script will interpret the same situation differently tomorrow. They also require very little from the system. A small Bash or Python script starts quickly and completes its task without loading several gigabytes of model weights into memory. You’d appreciate this a lot in home lab, where the same machine may already be running several services. You can consider using n8n as well It's a lot easier to maintain If writing and maintaining scripts is the problem, n8n is a much better alternative than handing the entire job to a local model. I can build the workflow visually and change its behavior without rewriting a Bash or Python file every time. For context, the container-monitoring workflow I discussed above is fairly simple to create using n8n. You need a Schedule Trigger that starts it at a fixed interval, and an SSH node checks the service. You can then use an IF node to decide what happens when the check fails. The path is visible on the canvas, so you know exactly what n8n will do before you activate it. I am not very good with code, so I find n8n easier to maintain. n8n also records every execution, which makes it easy to check where an automation stopped. With the local model, you will need to read through its response and tool calls to understand why it has taken a different route. I can still use Qwen3.5 9B inside an n8n workflow when a job genuinely requires interpretation. For example, the model can read an error log and produce a short explanation. n8n can then send that explanation to me without giving the model permission to restart anything on its own. Local LLMs have a long way to go I have managed to find some use for local LLMs when paired with a good agent harness and, sometimes, a cloud model. However, local LLMs on their own have not managed to show me why I should be using them. The problem is not local LLMs. The problem is how capable a local LLM I can run on my laptop or NAS, and the answer is: not very capable. I can probably run a 14-billion-parameter model on a MacBook with 16GB of RAM. If you have a better MacBook, such as a MacBook Pro with an M5 chip, you could probably run a 32-billion-parameter model as well. Beyond that, you’d need a much better rig to run even a decent model. I think that’s where the limitation of local LLMs comes from for the average consumer.