k3s is fine. The layer above it isn't.
The bottleneck is placing thousands of small, bursty AI jobs across a strange, mixed fleet, and learning from every run so placement gets better. That's a scheduling, capacity and scaling-policy problem, which is your home turf.
Canary releases, but for models.
The shadow network. Small local models learn to impersonate Jev, our fast judgment model, on narrow tasks: tool calling, routing, classification. Each one runs in shadow until its evals reach at least 95%. Only then does it take real traffic.
The training data is five years of AI and harness conversation logs. They're labelled and replayed through the shadow network to find what each small model is good at, then fine-tuned.
The workload is thousands of short experiments (replays, evals, fine-tuning runs, builds, test suites), with about 20 agent "leads" submitting jobs at the same time.
The rule: autoscale typed capabilities against capacity offers, not sessions. z0intelligence#131
Two k3s nodes, two phones, and a queue nobody uses.
Kueue is installed with three ClusterQueues, factory, lanes and z0, but they're empty. Jobs actually run through a host-lane wrapper: fleet-build checks heat, memory and disk, then starts a systemd-run scope on the build laptop. They never become Kubernetes Jobs.
The phones run Linux inside PRoot on Android: no cgroups, no netlink, no systemd. They can't run a kubelet, so they're host-lane workers with battery and thermal gates.
Nine failures, most of them already solved by Kubernetes.
Each card shows what happened, what we did, and the Kubernetes-native answer we suspect exists. That last part is our guess, and it's what we'd like you to correct.
Six places we'd rather not reinvent.
Five questions. Tell us where we're wrong.
Under each question is what our own agents' research leaned toward. It's research only: none of it is deployed, and it's exactly the kind of reasoning we'd like you to check.