Local AI on Windows 11: Qwen and Hermes Handle App Updates, Backups and Network Checks

The setup: a 35B model on a single consumer GPU​

The author describes a three-year-old Windows 11 desktop with an RTX 4070 Ti Super. The card has 16 GB of GDDR6X, and the system has 32 GB of DDR5-6000. The model is Unsloth's UD-IQ4_XS quantization of Qwen3.6-35B-A3B. It is served through llama.cpp with a 64K context window. The --fit flag splits the model's expert layers between VRAM and system RAM. The author reports 56–58 tokens per second during the Hermes runs.

Treat that speed as one data point. It reflects this hardware, this quantization and these prompts. It is not a benchmark you can expect on your own machine.

"Local" here means the model's inference runs on the PC. It doesn't mean the whole workflow stays offline. Hermes' documentation lists browser automation, terminal execution, file editing, memory, delegation, scheduled tasks among its built-in capabilities. Whether any of those reach the internet depends on the task. The author's own network test pinged public hosts and ran a speed test. You avoid sending prompts to a cloud provider, which is a real advantage. It is not the same as a privacy guarantee.

Chore one: sorting the update backlog with winget​

The author asked the agent to run winget and list every app with a pending update. Microsoft describes WinGet as a command-line tool for discovering, installing, upgrading, removing and configuring apps on Windows 10, Windows 11 and Windows Server 2025. Running winget upgrade with no arguments lists the available upgrades. Microsoft's documentation advises using that first to preview what winget upgrade --all would touch.

The agent reportedly returned more than 40 apps with package IDs and versions. The author did not tell it to upgrade everything. They excluded components the live session depended on:

• llama.cpp, which serves the model
• Hermes, which is the agent itself
• Nvidia drivers, which would pull the GPU out from under the job
• Git and Windows Terminal, because Hermes depends on them

They then approved WinRAR, HWMonitor and GPU-Z. Each upgrade took 24–40 seconds. The whole job took 1 minute 42 seconds and ended with a summary table.

The useful lesson is the order of operations: inventory first, human selection second, execution third. Microsoft's documentation describes --all as an attempt to install updates, not a promise that each one succeeds. It also notes that apps without a detectable version, and apps pinned in WinGet, are skipped unless you add specific flags. A WinGet list is therefore not a complete audit of everything on a PC.

Chore two: a nightly backup that doesn't need the model​

The author asked for a project folder to be copied every night at 11 PM to a Crucial BX500, a separate SATA SSD in the same PC. They specified Robocopy and told the agent never to delete anything. Seven files copied in 2.3 seconds.

The author says the agent chose to register a Windows scheduled task rather than use Hermes' built-in scheduler. Hermes does ship scheduled-task features, and the Hermes documentation lists a cron-style job tool. Microsoft says Task Scheduler can run any program at a chosen time or when a specific event occurs. That is the design choice that matters. Once the task is registered, Windows launches the copy at 11 PM even if the model server is off.

This is the right instinct for any agent-built automation. Let the agent write the job, then let the operating system own it.

Where this backup falls short​

The article does not give the source and destination paths, the exact command or the task's account and permissions. It also gives no restore test, so I won't invent any of those details. Some caveats for anyone copying the idea:

• "Copy without deleting" is a deliberate choice. Microsoft's Robocopy documentation says /mir and /purge delete destination files that no longer exist in the source. A plain copy of new and changed files avoids that. The trade-off is that deleted files pile up in the backup.
• A second SSD in the same PC is not off-site protection. It guards against the primary drive failing. It doesn't help with theft, fire, a power surge or ransomware that reaches every attached drive.
• Check the exit codes. Robocopy's documentation says any code of 8 or higher means at least one failure. Microsoft also recommends writing a log file with /log. A scheduled task that quietly fails is worse than none.
• Test a restore at least once.

Chore three: a two-minute network check​

The author asked the agent to run Ookla's Speedtest CLI, which it had installed through winget. It also pinged the home router, Cloudflare's 1.1.1.1 and google.com 20 times each, and timed a DNS lookup three times. Five commands and about 1 minute 44 seconds later, the agent delivered a verdict. The article doesn't print the latency, packet-loss or DNS numbers.

The author ran it during the Microsoft 365 outage that started Thursday, November 12. Reporting from Al Jazeera says problems began at about 16:00 GMT on Thursday. It also says Downdetector logged reports from 74 countries and territories within about an hour. TechRadar's live coverage puts the start at around 1 pm ET. Outlook was hit hardest. Teams and Copilot were also disrupted. Microsoft's affected-service list reportedly included Exchange Online, SharePoint Online and Defender XDR.

Microsoft attributed the problem to "elevated load" on its infrastructure, according to Gulf News. Yahoo Finance, citing Proactive, reports that Microsoft found no sign of malicious activity and said it would publish a root cause after the fix. The Next Web quotes Charles Lamanna, an executive vice president at Microsoft, as saying there was no indication of cyber activity. Coverage described recovery as uneven. At one point Microsoft reported only "marginal success", and later "encouraging recovery progress".

A note on the 74-country figure: it is a count of Downdetector report locations, not a verified count of where service actually failed.

What a network check can and can't prove​

The author's conclusion was that the home network and ISP were fine, which left Microsoft as the suspect. That is a sensible inference, but it isn't proof. Clean results to the router, a public DNS resolver and a major website show that general connectivity worked during that test window. They can't show that a particular cloud service is healthy. They also can't rule out intermittent, route-specific or provider-specific faults.

Pair a test like this with Microsoft's own service health page and independent outage trackers. That is the corroboration the author effectively had that day.

What this means for Windows users​

Nothing here is exotic. The agent is a friendly front end for winget, Robocopy, Task Scheduler and a few network utilities. Its value is that you can describe a chore in plain language and get the right command, a run and a summary.

That convenience comes with risk. A model with shell access can update software, copy files and create scheduled tasks. The article doesn't describe approval prompts, a restricted account or rollback plans. If you try something similar, consider these steps:

1. Use a standard user account where possible, and elevate only when needed.
2. Have the agent list what it intends to do before it does it, as the author did with the update list.
3. State destructive constraints explicitly, such as "copy only, never delete".
4. Review any scheduled task the agent creates, including its command, account and trigger.
5. Check logs after the first few runs.

On cost, the author argues that local inference avoids API credits and usage limits. That's plausible, but the article offers no cost or power-use comparison. A 35B model split across VRAM and system RAM is also a lot of hardware for three chores. The author points to smaller tool-use models, such as an Nvidia model they describe as fitting in about 4 GB, as a route for lighter machines. I couldn't independently verify that claim.

Bottom line​

The most transferable idea here isn't the model. It's the division of labor: the AI interprets the request and builds the job, and Windows runs it afterward. Keep a human in the loop for anything that changes the system, and remember that "local" describes where the model runs, not what the tools can reach.