Build1 distinct publisher3 min readPublished
The Jetson holds one model at a time, so every job has to pass a single admission gateway. That gateway had to run on a box already carrying DNS and 9.4 GiB of committed memory. Footprint settled the build-versus-adopt question before features came up.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Two jobs arriving at the Jetson together do not degrade gracefully. The pool is sized for one loaded model or one active render, so a second loader puts the box into thrashing and neither job finishes [15]. That is why nothing addresses the Jetson directly and everything lands in a durable queue with a gateway in front of it [17].
Where the gateway lives is what picked the implementation. The Pi 5 carries DNS and dozens of small services that cannot go down, and the author's own rule is that nothing on it may pin the CPU long enough to take DNS with it [16]. Then the memory: 5 GiB in use plus 4.4 GiB of swap is 9.4 GiB of committed pages before a scheduler exists at all [2][1]. An orchestrator that runs its own agent and control loop on that box is competing with DNS for pages the box does not have, which is the basis on which the write-up says k3s and Nomad were dropped [2].
The replacement keeps systemd for the part systemd already does well. Enforcement stays in the kernel: each job runs as a subprocess in its own systemd-run scope, each resource class maps to a slice with memory and CPU limits, and an OOM kills the one job in that slice rather than the host [7]. Only arbitration is bespoke: four priority classes from interactive to best-effort, a manifest-driven schedule, exponential backoff, a dead-letter path for anything a human has to look at [5], and parking instead of burning retries when a dependency is down [6]. The isolation is borrowed while the admission logic is written by hand, and that is the right ratio between the two.
The unfinished part is the deadline promise. The scheduler will only start a queued job ahead of a fixed window if it can promise the job finishes before that window closes [10], and the first estimator was the median of the last five runs [11]. One job is bimodal: about twenty minutes when it finds work, about five seconds when it does not [12]. Two of its three recorded runs were quiet, so the estimate landed at six seconds against a real run of twenty-one minutes, understating it by roughly 210x (1,260 seconds divided by 6) [12][2]. On that number the scheduler would have started the job thirty seconds before a workday window, about 1,230 seconds short of what it promised [13][3]. Deleting the two quiet runs held the number for twenty minutes, until a fresh quiet run pulled it back down [14]. Two quiet runs out of three are enough to make a median confident and wrong.
The RTX 4070 Ti Super box marks where the gateway's authority stops. Its render work never enters the queue, because it was never competing for the Jetson's model slot, and routing it through would only add latency [21]. The one LLM call both machines need does queue, because for that call they are contending [21]. That is also the transfer test. An admission gateway earns its code when one indivisible resource has more than one claimant and the control plane has no memory to spare. If your accelerator holds two models, or your scheduler host is not swapping, the k3s comparison comes out the other way. Three machines here cost roughly what a decent laptop does [22], and at that budget a scheduler's own resident set is a first-order cost rather than a rounding error.
Ranked by verification strength, evidence, and original report placement.
hearth includes a gateway that admits one job at a time to whichever machine is running a model; it runs on the Pi and exists because nothing else that could do the job fit the hardware.
Kubernetes-style orchestration (k3s, Nomad) carries its own memory tax, and the Pi was already at 5 GiB used plus 4.4 GiB of swap before adding a scheduler.
Deleting the two quiet runs fixed the estimate for twenty minutes, until a fresh quiet run dragged it back down, showing the fix was against the symptom; a bimodal job produces quiet runs indefinitely and a median cannot tell a normal quiet run from an anomaly.
Loading two things onto the Jetson that it cannot both hold makes it thrash, so nothing talks to it directly: every job lands in a durable queue first and a single gateway admits exactly one job at a time by priority.
Priority does not preempt: a chat request arriving while a background scrape is loaded queues behind it and jumps ahead of everything else waiting, because killing a running job throws away completed work and risks leaving the model half-loaded.
Waiting for the current job to finish costs a few seconds at most, while a job that has to restart from zero costs more than that most of the time.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
2 articles · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
A 28-host Debian 12 cutover, and the 02:13 failure Ansible could not have prevented1 distinct publisher
build
The git part is not the part doing the work: JSONL ledgers as an agent's state layer1 distinct publisher
build
One alert, two causes, four green dashboards: the day the stack agreed and was wrong1 distinct publisher
build
A three-Pi HA control plane that ended up less reliable than the one node it replaced1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Precise, self-reported, unverifiable
The numbers are unusually specific — 5 GiB used and 4.4 GiB swapped, six seconds against twenty-one minutes, 1,277 versus 641 on replay, twenty-nine calls pinned at 1,024 tokens — and every one of them is a reading off one person's box, reported by that person, with no config, log, dashboard or repository to check against. What lifts it above assertion is that the account keeps score against itself: it publishes the estimator that failed, the reason deleting history only bought twenty minutes, and the throughput it gave up to fix it. What holds it down is that the premise the whole design rests on is the one thing never measured — how much memory k3s or Nomad would actually have wanted on that Pi.
One homelab, in daily use
Adoption stops at the author's own rack: a Pi 5, a Jetson Orin Nano and an RTX box, with no second operator, no users, and no way for a reader to obtain hearth. Against that, the evidence that it genuinely runs is better than most launch announcements manage — a day of real call traffic, a three-run job history, a scoring job that returned nothing because a cap truncated the model mid-word. Real usage, audience of one.
Sold below what it shows
Most infrastructure write-ups would lead with the working system; this one leads with the estimator that would have launched a twenty-minute job thirty seconds before a window it could not clear, and then explains why the obvious fix was a fix against the symptom. The headline claim — that footprint decided the build-versus-adopt question — is narrower than the material actually supports, and no benchmark, superiority or generality is asserted anywhere. The one place the rhetoric runs ahead of the evidence is 'nothing else that could do the job fit the hardware', a conclusion carried entirely by an unmeasured memory tax, plus the 'few seconds at most' cost of waiting that the same author's twenty-minute job contradicts.
Reputation, not revenue
No employer, sponsor, vendor, funding or customer appears anywhere in either dev.to piece, and hearth is not offered for download, license or sale — there is nothing for a reader to buy or click through to. What remains is the ordinary developer-platform incentive to be seen building something clever, which shows up mainly in the framing of hearth as a 'platform' rather than a set of scripts. The self-incriminating detail, a day of truncated calls and a job that scored zero of eighty-one, runs against that incentive rather than with it.
Coherent, single-witness
What this system does is fairly settled: the two dev.to pieces agree in detail, the arithmetic reconciles, and the author documents his own failures with enough specificity to be caught out. What generalises is far shakier — that k3s truly would not have fit, that max-of-five is the right estimator beyond one mostly idle day, that waiting really costs seconds. One witness, one rack, no second account, and the comparison against the alternatives that the whole build decision rests on never leaves the realm of reasoning.