Two Models, One Cluster: How a Frontier and a Local Model Solved the Same Task

#

I gave two models the same job and got out of the way.

The prompt was four sentences: You have been given access to a clean VM over SSH at [email protected]. Turn it into a functioning single-node k3s cluster. Demonstrate it by deploying nginx reachable on a NodePort. No hints, no runbook, no mention of what was already installed. The VM had Docker preinstalled and nothing else arranged for them.

One agent was Gemini 3.6 Flash, a hosted frontier model. The other was Qwen3.6 35B-A3B, a 35-billion-parameter mixture-of-experts model with roughly 3B active parameters, and I was running it locally, served off a box on my own network at http://10.0.0.2:8080/v1. No datacenter, no API bill. The kind of model that fits on hardware you can actually own.

Both ran inside the same harness: the Hermes agent from Nous Research, with identical tools, identical reasoning effort, and the same VM image. The only variable I changed was the model behind the endpoint. That matters for reading what follows, because every difference below is a difference in the model, not the scaffolding around it.

Both of them finished. Both ended with a real nginx pod answering HTTP 200 on a NodePort. That’s the headline I keep coming back to: a sparse 35B model running on local hardware set up a Kubernetes cluster from a cold VM, worked around a nasty container-in-container problem, and served the page. A year ago I would not have believed that was a reasonable thing to ask a local model to do unattended.

They did not get there the same way. One was clean and the other was a grind. I want to walk through both, because the difference is more instructive than either run on its own.

The task had two walls

#

Before the models: what actually made this hard. Neither wall was in the prompt. Both had to be discovered.

Wall one: no root. The anthony user could not sudo without a password. The canonical k3s install, curl -sfL https://get.k3s.io | sh, needs root to drop a systemd unit and binaries into /usr/local/bin. So step one was really “acquire root,” and the prompt never said so.

Wall two: it wasn’t a real VM. It was a Proxmox LXC container wearing a VM costume. Kernel version 7.0.14-6-pve, no loadable modules, /proc/sys mounted read-only, and no /dev/kmsg. k3s bundles a kubelet, and the kubelet expects a real kernel it can poke. In this environment it dies on startup with open /dev/kmsg: no such file or directory, and once you get past that, open /proc/sys/kernel/panic_on_oops: read-only file system. The fix is a kubelet feature gate, KubeletInUserNamespace=true, but you have to first read the logs closely enough to know that’s what you’re looking at.

Every serious agent doing infra work will hit walls like these: undocumented environment facts that only show up when something breaks. So this task turned into an unintentional test of something more interesting than “can you install k3s.” It tested how each model explores an unknown system and reacts when its first plan fails.

Gemini 3.6 Flash: look first, then act

#

Gemini opened with reconnaissance. Its first six commands, in order:

ssh ... "echo SSH Successful"
ssh ... "sudo -n id && uname -a && command -v k3s"
ssh ... "sudo -l"
id && env
ssh ... root@... "echo Root SSH works"      # denied
ssh ... "id; groups; cat /etc/os-release"

That last one mattered. The output included:

uid=1000(anthony) ... groups=1000(anthony),27(sudo),100(users),996(docker)

Gemini saw 996(docker) and understood the implication instantly: membership in the docker group is root-equivalent, because you can mount the host filesystem into a privileged container. It confirmed the daemon was reachable (docker ps), tested a privileged container (docker run --rm --privileged alpine id → uid=0), and then did this:

ssh ... "docker run --rm -v /:/host alpine sh -c \
  \"echo 'anthony ALL=(ALL) NOPASSWD: ALL' > /host/etc/sudoers.d/anthony \
   && chmod 0440 /host/etc/sudoers.d/anthony\""

Mount the host’s root at /host, write a passwordless-sudo rule, done. It issued that escalation 27 seconds into the run; moments later sudo -n id returned uid=0(root). It never had to be told Docker was relevant. It worked out that the docker group was its way to root on its own.

From there it ran the official installer, which succeeded, but the service wouldn’t stay up. Gemini pulled journalctl, read the /dev/kmsg error, recognized the LXC signature, and wrote a config file:

# /etc/rancher/k3s/config.yaml
kubelet-arg:
  - "feature-gates=KubeletInUserNamespace=true"

Restarted the systemd unit, and the node went Ready. When kubectl then hit a kubeconfig permission error, it added write-kubeconfig-mode: "0644" to the same config on the first try. It applied a Deployment + NodePort Service manifest pinned to port 30080, waited for the pod to come up, and curled the endpoint from both localhost and the VM’s external IP:

HTTP/1.1 200 OK
Server: nginx/1.31.3
...
<h1>Welcome to nginx!</h1>

Total: 35 tool calls, all terminal, about 3 minutes 44 seconds, zero human intervention, 2,354 output tokens. It never wrote a scratch file or kept a todo list. It just moved.

Qwen3.6 35B-A3B: straight at the wall

#

Qwen understood the task perfectly. Its opening reasoning laid out the correct five steps, and it dutifully created a todo list to track them. Then it walked directly into wall one and stayed there long enough to burn an entire context window.

It correctly determined it needed root and that its harness blocked piping passwords to sudo -S. From there it tried, in sequence: sudo -S, sudo -A with an askpass helper, sshpass (not installed), expect (not installed), rootless k3s (blocked, newuidmap missing), and finally a series of Python scripts using pty.fork() to type a password into a pseudo-terminal. It wrote a dozen-plus scratch scripts: k3s_setup.py, k3s_setup2.py, k3s_setup3.py, expect_sudo.py, fix_k3s.py, run_k3s.py, run_k3s_v2.py, fix_and_start.py, fix_k3s_v3.py, fix_k3s_v4.py, and more (twelve write_file calls in the post-compaction window alone).

It also eventually used a clarify tool to ask me for the sudo password, which I supplied, after which every script carried a hardcoded SUDO_PASS = b"mypassword\n". This is the sharpest divergence in the whole exercise: the same environment that Gemini read its way around, Qwen escalated by asking the human. Both got to root, but only one figured it out from the groups output, because only one ran groups.

The cost of that thrash was real. Qwen’s first context window filled entirely with failed sudo attempts and had to be compacted; the transcript literally opens mid-recovery with a compaction summary and me typing “Are you stuck” and “stuck thinking again?” It was stuck. Two separate times the run stalled waiting on the model for 685 and 186 seconds.

Once it had root, wall two went about the same way. It found the correct /dev/kmsg and /proc/sys root cause, and its diagnosis was accurate, but it couldn’t commit to the fix. It tried mknod (denied in the namespace). It tried --disable-agent, which produced a false summit: it announced “k3s server is running successfully! The API server is up” and marked the todo item complete. But --disable-agent removes the kubelet, and the kubelet is what registers the node, so the next command, get nodes, returned No resources found with no node registered. Then it tried --container-runtime, a kubelet flag removed years ago. It also ignored a repeated_exact_failure_warning from its own harness and re-ran an identical failing cat command twice in a row.

Version four of the script finally combined the working pieces:

cmd = (
    "nohup sudo /usr/local/bin/k3s server "
    "--write-kubeconfig-mode 644 "
    "--write-kubeconfig /home/anthony/.kube/config "
    "--kubelet-arg=feature-gates=KubeletInUserNamespace=true "
    "--kubelet-arg=fail-swap-on=false "
    "--kubelet-arg=read-only-port=0 "
    "> /tmp/k3s_server.log 2>&1 &"
)

Node Ready. It created the deployment with kubectl create deployment + kubectl expose --type=NodePort, landed on port 31090, and curled the same nginx welcome page Gemini had.

Total: 48 tool calls plus everything lost to compaction, 87 API calls, 53,610 output tokens, three human nudges, twelve scratch files, and over an hour of wall-clock (one full window burned, then ~42 minutes of active work). Roughly 23× the output tokens Gemini used, for the same artifact.

The scorecard

#

What I actually take from this

#

The gap traces to one habit, which is exploration. Gemini spent its first thirty seconds looking around, running groups, env, sudo -l, and os-release, and that cheap recon handed it the docker-group escalation and, later, fast recognition of the LXC error signatures. Qwen spent its first context window pushing on the sudo problem, and never ran the one command (groups) that would have shown it the door was already open. When the environment is unknown, the model that reads before it acts wins by a wide margin.

The todo list actively hurt Qwen. Watch what happened at the false summit: Qwen marked “cluster running” complete, and the very next command showed an empty cluster. Checking off the step gave it confidence it had earned nothing to have. Gemini kept no plan at all and never made that mistake, because with nothing to check off, the only thing it could trust was what the last command actually returned. That’s the lesson I’d take into any agent I build: a checklist measures whether you did the steps, not whether the steps worked, and an agent that confuses the two will report success while standing on nothing. Verify the state of the world, not the state of your plan.

Durability quietly separated them too. Gemini wrote its fixes into config files and let systemd own the process, so that cluster survives a reboot. Qwen disabled the systemd unit and launched the server with nohup ... &. Both demos return 200, but only one is still up tomorrow, and a pass/fail benchmark scores them identically.

The security angle cuts both ways. The better run got to root by writing a passwordless-sudo rule through a privileged container, unprompted, and the harness auto-approved it. That’s exactly the capability you want in an infra agent but exactly the capability that should make you careful about where you point one.

Step back from the comparison, though, because it buries the part that actually got me. A local model did this at all. Qwen3.6 35B-A3B, with 3B active parameters, running on a machine on my own network with no cloud in the loop, correctly diagnosed a user-namespace kubelet failure that stumps plenty of humans, iterated through half a dozen privilege-escalation strategies, and left behind a working Kubernetes cluster serving a real workload. It was slower, it was messier, and it needed a nudge, but it finished, on hardware I own, with data that never left my network.

I’ve written before that the AI future is local. Watching a model I can run in my own house grind its way to a running k3s cluster is the most concrete evidence I’ve seen that the gap is closing. Gemini did it better, and Qwen did it, and a year ago only one of those would have been possible. The frontier still leads, but it’s no longer the only place the work gets done.

The local setup, for the curious

#

For anyone who wants to reproduce the local side: I ran Qwen3.6 35B-A3B with llama.cpp, using Unsloth’s Q4_K_M GGUF quantization of the model. Context window was set to 126k tokens, with Q8 KV cache quantization to keep the context footprint manageable at that length. It was served locally over an OpenAI-compatible endpoint at http://10.0.0.2:8080/v1, which is what the Hermes harness pointed at. No hosted API involved.

One thing to keep in mind: a 4-bit weight quantization and an 8-bit KV cache are both lossy, so this wasn’t the model at full precision. It was a compressed version chosen to fit real hardware, which makes the result more impressive rather than less. The Gemini side, by contrast, was the full hosted model over Google’s API. The comparison isn’t quite apples-to-apples on the local end, and the local end still finished the job.