Corey James- 15actions on the one provisioning tool
- 0inbound ports for a cloud pod to reach the estate
- 30 sbetween budget checks on every container, healthy ones included
- $0the day's budget when no limit row exists
An agent in my estate can stand up a GPU worker with one tool call: a container image, an engine, a provider, and where it should run. The same call starts a container on my workbench over the local socket, on a LAN workstation over mutual TLS, or on a rented cloud pod that dials back into my network with no inbound ports. Before any of that happens, a budget gate checks the day's dollar cap, which is set by a human with a command-line tool that is not on any agent's tool surface. Spend is metered from the second the provider confirms the pod, and a container that outlives the budget is terminated.
One call
The provisioning tool takes an image with an optional pinned digest, an engine directory that must carry its configuration and consumer settings, a provider, a GPU, and for a LAN target the name of a registered host. The sequence is a composition of the substrate. The tool's other actions include draining a node's queues, setting an idle timeout, onboarding and tearing down LAN hosts, syncing engines to them, and listing images and engines.
Runtime injection
There is one runtime binary, built on the host. For local and LAN containers the provider bind-mounts the binary, a loader script as the entrypoint, and the Python shared library it links against, so any image with the loader as its entrypoint can run any function and a function update means rebuilding one binary instead of an image. Cloud pods cannot bind-mount from the host, so the cloud images bake in an outbound tunnel client and a Redis heartbeat; the pod dials back to the private network, and remote GPUs reach the estate's Redis and PostgreSQL with zero inbound ports. An image manifest lists each image's digest, CUDA version, supported GPUs and providers, and environment contract; the Blackwell base image covers consumer and datacentre Blackwell and a second image covers Ada, Hopper and Ampere.
Four loader modes decide what a container becomes.
Any image with the loader as its entrypoint runs any function; an update rebuilds one binary, not an image.
Tunnel credentials and Redis authentication come from provider configuration, never from the caller. Loader modes decide what a container becomes: a one-shot job, a capability node, an agent with all capabilities dropped, or an infrastructure service.
A LAN host in eleven steps
Onboarding a LAN machine is an eleven-step procedure with rollback: a prerequisite probe for systemd, Docker, the NVIDIA container toolkit and a passwordless-sudo user; a private certificate authority, written in-crate, issuing an ECDSA server certificate with the host's name and address in the subject alternative names and a client certificate; Docker's daemon configured for TLS; the engine synced across; and the host registered. After that the host is one more location the same call can target.
The budget
The authority is a table of daily limits keyed by date, with an audit row for every change. A small calendar crate shared by the command-line tool and every consumer defines a budget window from local midnight to local midnight in the operator's time zone, refuses ambiguous daylight-saving midnights, and validates any published window by recomputing it, so a forged or shifted interval is refused. Budgets are per date and never carry over.
The admission rule fails closed. Local and LAN containers cost nothing and still pass through the gate, so setting the day's budget is also the operator's daily arming of all container provisioning; only in-process work skips it. The same gate runs before control-plane jobs that carry a container configuration, before every agent persona container the swarm launches, and before every media-studio start.
- No budget row for todaydeny
- Spend at or above the capdeny
- Any Redis, PostgreSQL or calendar errordeny
- Budget availableadmit
Grey lines: warnings at 80, 90 and 95 percent; at the cap the monitor terminates paid containers, stops billing and dead-letters their jobs.
A ten-second loop accumulates spend per container, per schema and globally in a durable Redis, synced to PostgreSQL through the write-behind queue. A daily projection recomputes today's spend from per-container identities under a publication lock, prorating active containers inside the window and splitting a container that crosses midnight across the two days. Finalisation closes a container's spend into the day's total, a finalised identity cannot be revived by a stale writer, and lowering the day's allowance never resets spend already finalised. On restart, active containers are read back and the gap since their last sync is recomputed.
The health monitor asks the budget plane about each container on every pass. When the budget is no longer available it terminates the container through the provider and marks it exhausted. Orphaned pods the provider stopped but left billable are found and cleaned up.
Why an agent cannot raise the budget
The only code in the estate that writes a daily limit is the human command-line tool. No tool on any gateway writes budgets; agents get read paths and refusals. The check runs inside the provisioning function before any side effect, and nothing an agent passes to the call changes the cap. Every change is audited.
Missing or invalid state can only yield zero or an error, never a larger cap.
Spend you can read
Terminating a node returns its final cost to the caller. The command-line status shows today's budget and spend in the operator's time zone, the remaining amount and percentage, the paid containers currently up, with their rates, the time until exhaustion, the next seven days' budgets and recent changes. Storage costs from the provider are synced and reported separately under a soft monthly cap. Per-container rate, start, end and total cost sit in a PostgreSQL table with schema and function attribution.
Model usage inside governed work is a separate plane, attributed rather than gated: tokens are classified into uncached input, output, cache reads and cache creation, priced against a public catalog at run time and left unpriced when pricing is unavailable, and rolled up by work order, task, role, model and phase. I ruled that model cost is telemetry and strategy, and reserved hard gates for rented capacity and metered third-party APIs. The cost of one real program is in What the work cost, to the penny.
What this demonstrates
Infrastructure that lets agents reach real hardware safely: one call across three locations, zero inbound ports, a budget a human sets and an agent cannot, and accounting that bills from power-on and survives a restart.