The Economics Forcing Function
The SEO Command Center (the autonomous SEO platform we build inside Zyan, our software arm) writes long-form content drafts as scheduled work. When a draft executes on the cloud lane, every model call is metered API spend, and our run ledgers show a single cloud draft billing between $1.64 and $5.02 across observed runs.[2] The same draft executed on a desktop machine the studio already owns, through the model provider's subscription-priced command-line tooling, has zero marginal cost: the machine is on, the subscription is already paid, and the incremental draft adds nothing to the bill.
On August 13, 2026 the difficult case ran end-to-end for the first time: a parked dispatch for a health-content publisher woke a desktop runner, which drafted the article in about 7 minutes and settled at exactly $0.00 measured. This constitutes one fully measured run for that lane, and we state it as n=1.[2] We are equally explicit about what "zero marginal cost" means: the subscription is a real fixed cost with its own usage limits, so the claim is that an incremental draft adds nothing to the monthly bill while capacity remains, not that compute is free. The full economic case in this note rests on two fully measured runs plus published list prices,[4] and we present it at that strength rather than as fleet-scale evidence.
A second pressure pushed in the same direction. In August 2026 a single long model call inside a scheduled edge runtime hung past the platform's kill ceiling and silently degraded report freshness for five days. Raw ingestion was unaffected and no data was lost, but the failure demonstrated that a 20-to-130-second model call does not belong inside a runtime with a hard wall-clock kill. (The full forensic is the companion write-up in this index.) An interim fix that would have bounded and reordered the offending scheduler step was drafted but never shipped; the durable queue described below subsumed it. At incident time the daily scheduler ran roughly a dozen steps; the liveness registry today tracks 33 steps plus 3 sentinels.
The Constraints That Shaped the Design
The owner set three binding constraints before design began, and each one eliminated a conventional architecture:[1]
- No always-on cloud worker. Cost outweighs latency for this workload; a topic refill that waits minutes costs nothing, while a resident worker incurs cost around the clock. This eliminated the standard dedicated-worker deployment.
- No cloud-side polling loop. A poller is a resident process by another name. Nothing in the cloud path may sit in a loop asking whether work exists.
- Work must survive machines that sleep. The preferred executors are desktop machines that close their lids. A job that dies with its executor, or that consumes retry attempts while a laptop sleeps, fails the design.
The constraints compose into a specific shape: work must be durable somewhere that is always on (the platform database), execution must be push-initiated rather than poll-discovered on the cloud side, and the queue must distinguish "waiting for a preferred runner" from "failing." The desktop application itself, already running on hardware we own, checks for parked claims on a short polling interval while awake; that check runs on a machine whose cost is already sunk, which is precisely why the same loop is forbidden in the cloud.
The Design: A Durable Queue With a Push Model
The substrate is deliberately conventional: one durable job-queue table in the platform's Postgres database (Supabase), on the same claim idiom our blog-drafting lane had already proven in production.[1] Each job row carries its kind, its payload, its lane, its attempt count, and its lifecycle status. The mechanics that make it safe:
- Claims are compare-and-swap, not advisory. An executor claims a job with one conditional update guarded on the observed status and lane; zero rows updated means another runner won the race, benignly. Two runners cannot win the same job.
- Each claim mints a rotated, single-purpose callback token. Only a SHA-256 digest rests on the row; the raw token travels once to the executing runner and is valid only for finalizing that specific job. A requeue clears the digest, so a zombie executor’s late callback authenticates against nothing.
- Dispatch is a push, and the push is the wake signal. The enqueue sweep probes for a capable, online desktop runner. Finding none, it immediately dispatches to a scale-to-zero cloud machine on Fly.io, and the dispatch request itself wakes the stopped machine. No poller exists anywhere in the cloud path.
- Park semantics separate waiting from failing. A job parked for a preferred desktop runner is structurally invisible to staleness sweeps and burns no retry attempts; within a grace window the desktop lane gets first claim, after which the job flips to the cloud lane.
- A stale-claim reaper reclaims work from dead runners. A claim held past the staleness bound with no finalize means the executor died mid-job; the reaper requeues it (or terminates it honestly at the attempt cap), anchored on the observed claim timestamp so a live finalize racing the reaper loses safely.
Reserve at dispatch, settle in finally
The first workload moved onto the queue was chosen from the live step ledger, not from intuition: the topic-bank refill, whose single 20-to-130-second model call was the measured overrun behind the August incident. The split is surgical: the scheduled step now only assembles inputs and enqueues (fast, no provider calls, no spend); the executor runs the stored prompt; a finalize verb re-validates and persists through the same seams the old in-process step used. The scheduler kept its honest ledger vocabulary end-to-end, so a dead worker lane ages into a page rather than wearing a green badge.
What Adversarial Review Caught Before Merge
Every substantive change in this platform passes an adversarial review panel before merge, and this lane produced the strongest argument for the practice we have recorded to date. We report four findings:[3]
The settlement path that was dead code. The finalize handler's row query omitted one column (the credit-reservation identifier), which silently turned the entire settlement path into dead code: every cloud job would have been charged at its full estimate by the reaper instead of settling to actual spend. The unit tests were green because the test fake returned fixture rows wholesale; since the fake never modeled the query's column list, no test could observe the omission. The fix was the missing column; the doctrine is permanent.
Test fakes must project the columns the query selects
- A transient error collapsed into a terminal one. The finalize endpoint answered a uniform 403 on any authentication failure. That mapping is correct for dead tokens, but a transient database error while fetching the row fell into the same branch. Executors treat a finalize 403 as terminal-drop (retrying a dead token can never succeed), so a transient database error would have permanently discarded the only delivery of a completed, paid-for result. The response was remapped to a retryable 5xx.
- Duplicate billing events on replay. The queue is at-least-once, so a completed job’s callback can legitimately arrive twice. Usage-event recording originally rode the whole completion path; it now happens only on the path that wins the completion compare-and-swap, so a replay authenticates, learns the job is already finalized, and records nothing.
- The idle queue that looked dead. Worker completions are workload-dependent, and a fully stocked steady state legitimately produces none, which the external watchdog would read as a dead lane and page on. The fix is an explicit idle heartbeat: when the enqueue sweep can prove the lane idle and healthy, it writes the health row itself, and any open job suppresses the heartbeat so a genuinely stuck worker still ages into an honest page.
The First Live End-to-End Run
On August 14, 2026, after the activation merge, we ran the full stack live on the real pipeline: enqueue, push dispatch to the scale-to-zero cloud machine, wake, claim, model call, finalize, settle.[2] This is a single measured run and we report it as one:
The properties of primary interest are the exactness claims, not the latencies: one completion ledger row, one usage event, spend metered under the operator-exempt policy, and the result persisted through the same validation seams as the old in-process path. Deploy readbacks — hosted function version, cloud build, frontend bundle — were all green before we called any of it live. One clean run proves the plumbing; it does not prove reliability, which is what the open observation window below is for.
What Is Not Done, Stated Plainly
- Desktop runners lapse in the background. The desktop application only refreshes its session token while foregrounded, so a runner quietly loses eligibility roughly an hour after the app leaves the foreground. The session-refresh redesign is a design item, not shipped. Until it ships, background refills route to the cloud lane; the system stays correct, but the local-first economics apply only while a desktop machine is actively eligible.
- Fleet reliability is not yet demonstrated. The lane’s definition of done is a seven-day watchdog-green observation window, which is still open as of August 14, 2026. The reliability data we have is at most a day old and thin by construction.
- The economic sample is small. Two fully measured runs plus list prices is enough to justify building the lane; it is not enough to publish a fleet-level savings figure, and we will not publish one until the ledgers can support it.
We publish these because the alternative, announcing the milestone and omitting the seams, is exactly the reporting behavior our own platform's honesty rules exist to prevent.
The Companion Milestone: Measuring Locally Too
The same day the worker lane went live, local geographic rank measurement did as well: a 7x7 measurement grid across a five-kilometer radius around a local service client in southern New Hampshire, each cell querying local results as a customer standing at that coordinate would see them. The pilot's third full scan completed 49 of 49 cells with zero failures.[5] It is the same scan discussed in our founding-data note, where it explained what a flat impressions curve was hiding. August 14, 2026 is the date the two halves met: the platform now measures search visibility at the street level and executes its heaviest AI work on machines we already own. Both milestones are hours old, and both carry open observation windows, which is precisely why we recorded what the ledgers show today.