A local Qwen model took over a server-patching job when the cloud model refused

What they built

Over October 21 and 22, Seppe spent two days patching his company's servers after an emergency PHP release for two critical remote code execution bugs. The job covered seven RunCloud servers with about 30 WordPress sites, several on PHP versions that no longer get official fixes, plus cleaning up compromised sites and backporting plugin security fixes by hand.

He did most of it with the Hermes agent running a cloud model. Midway through the plugin phase, every message got 'Your request was not processed.' The agent's log showed the real reason: the cloud provider's cyber-content classifier was refusing, triggered by the access logs, CVE list and vulnerable-code diffs in the context.

He started Qwen3.8-Flash-Next on his own workstation, switched the model inside the same Hermes session, and the local model picked up the full history, tools and standing rules and finished the work. His takeaway is that a local model is insurance, not a replacement.

Setup

• Workstation with a Ryzen 9 9950X3D, an RTX 5090 and 128 GB of RAM
• Qwen3.8-Flash-Next served by Strata with the Unsloth UD-Q5_K_XL quant as an OpenAI-compatible server on 127.0.0.1:8081, with a 524,288-token context configured
• The Hermes agent framework, which treats the local server as just another provider

How it works

1. Hermes keeps session history, so switching the model with /model kept the inventory, CVE list, downloaded plugin sources and earlier decisions.
2. The local model filtered 47 serious CVEs down to those exploitable without a login, wrote a patcher with exact code anchors and tested it on local copies of each plugin version.
3. Where an upstream fix existed, it diffed vulnerable and fixed releases instead of writing its own patch.
4. A deploy script backed up each server, ran php -l with each site's PHP version, and rolled back automatically on error.

Results & numbers

• From 17:45 to 18:38 the local model made 66 calls as the prompt grew from about 121k to 212k tokens.
• Turns took 3 to 20 seconds with a warm prompt cache; about 20 cache misses took 70 to 115 seconds each.
• It patched 48 plugin copies (39 files) across the servers with no rollbacks, and all 32 sites still returned 200.
• It also moved MySQL to listen on 127.0.0.1 on five servers, finding a RunCloud config file that overrode its first change.

Gotchas

• The refusal was invisible to the agent, which guessed wrongly about the cause; only the log showed finish_reason=content_filter.
• Retrying the same context earns the same refusal, and a refusal is an HTTP 200, so error-rate monitoring won't see it.
• The local patcher had two bugs that it caught in its own test run, and one count in its final summary (56) didn't match the earlier report (48).
• The 92 GiB of weights load in under a minute, but only once other GPU jobs are stopped.

“A local model is insurance.”— Seppe Gadeyne

Do it yourself

1. Run a capable long-context model locally behind an OpenAI-compatible server.
2. Register it as a provider in the same agent framework you use for cloud models, so tools and session history stay identical.
3. Test your local start script now and then so the fallback is ready when you need it.
4. Log model refusals as their own event, separate from errors.
5. Keep backups, linting, before-and-after HTTP checks and rollback scripts in place no matter which model writes the change.

providers:
  strata-qwen:
    name: Strata Qwen3.8-Flash-Next (UD-Q5_K_XL)
    base_url: http://127.0.0.1:8081/v1
    default_model: strata
    models:
      strata:
        context_length: 524288