Oxide Computer As Brains of the Fleet

Oxide Computer announced a $445 million Series D on October 9th. The reasoning was refreshingly pragmatic: the company has become profitable, demand continues to outstrip supply, and it needs to get ahead of both manufacturing capacity and the component supply chain.

That milestone got me thinking: If I had an Oxide rack, what would I actually build with it?

Not another GPU rack. Not a Kubernetes demo. Not an absurdly expensive place to run a chatbot.

I'd build the brain of an AI fleet.

The GPU Rack Is Not the Whole AI System

When reasoning about AI infrastructure, I find it useful to split two questions apart:

1. Where does the model execute? The expensive, accelerator-bound work of generating tokens.
2. Where does the system decide what to execute, with which data, under whose authority, and at what cost? The coordination, governance, and memory that turns inference into something useful.

Most people focus almost entirely on the first question. I'd focus on the second.

The accelerators would do the heavy lifting. The Oxide rack would host the services that transform raw model calls into governed, durable, and auditable AI workflows. Things like agent orchestration, model routing, retrieval, tool gateways, evaluations, identity, policy, audit trails, usage accounting, and deployment automation.

I wouldn't ask, "How many tokens per second can this rack produce?"

I'd ask, "How many useful, accountable AI workflows can this rack coordinate without losing track of state, permissions, or money?"

Why Oxide

The appeal of Oxide isn't just "sell me compute". It's that Oxide bakes compute, NVMe storage, networking, and a clean, API-driven control surface into one coherent system. You get on-demand virtual machines, isolated virtual networks, block storage, and programmatic provisioning straight out of the box.

That boundary is exactly what I'd want. I'd rather have my AI platform consume infrastructure primitives like instances, disks, networks, and quotas than spend the first quarter rebuilding rack management just to deploy a workflow engine.

Declarative Kubernetes With Talos and Omni

To keep that boundary clean, I'd pair Oxide with Sidero Labs' Talos Linux and Omni.

Talos is a minimal, immutable, API-managed operating system. No SSH, no shell, no package manager. Everything is declared. Omni sits on top to provision, upgrade, back up, and manage the entire Talos fleet from a single control plane.

Sidero has already demonstrated this exact pairing: Omni uses an Oxide infrastructure provider to generate a Talos image, upload it to Oxide, boot instances, and enroll them via join configuration. You can even define separate machine classes for control-plane and worker nodes.

This is the kind of provisioning loop I want:

Declare cluster
      |
      v
Omni calls Oxide's infrastructure provider
      |
      v
Provision Oxide instances and boot Talos
      |
      v
Machines join Omni
      |
      v
Kubernetes becomes available
      |
      v
Deploy the AI platform from versioned configuration

Oxide owns the physical and virtual infrastructure. Omni owns the Talos and Kubernetes lifecycle. Kubernetes owns workload reconciliation. And my AI control plane owns the meaning of that work: requests, budgets, model choices, tool permissions, evaluations, and durable execution state.

None of those planes should need to leak into the others.

The AI Control Plane

If the goal is to build a "brain", it needs distinct systems working in concert. I'd keep trust boundaries explicit from day one.

1. A Model Gateway With Authority

Every request would flow through a single AI service gateway. Model routing would be a policy decision, not a string passed around by applications.

Each request would carry context: tenant and caller identity, data classification, latency target, approved model or capability class, token and spending limits, tool permissions, and evaluation/trace requirements.

The gateway would select from eligible endpoints: my owned GPU fleet, a hosted model API, or a smaller local model if it fits. Crucially, eligibility comes before optimization. If policy forbids sending a request to a certain region, provider, or deployment, the router won't override it just because another endpoint is idle.

For every routed request, I'd want a concrete answer to: "Why did this workload run there?"

2. Durable Agent Workflows

Chat sessions are too ephemeral for real work. I'd treat agents as durable workflows with explicit state machines.

Instead of "run this agent in a pod until it times out", I'd model steps like:

Accept request
      |
      v
Validate identity, permissions, and budget
      |
      v
Retrieve permitted context
      |
      v
Execute a bounded reasoning/tool step
      |
      v
Persist result, intent, and execution metadata
      +----> Request approval if policy requires it
      +----> Retry recoverably
      +----> Branch to next step
      |
      v
Evaluate outcome and return result

Workers must be disposable. If a pod crashes mid-workflow, restarting it should resume from the last known state, not from the beginning. For any external side effect—payments, emails, deployments—I'd require idempotency keys, recorded intent, and reconciliation.

Most importantly, agents would only ever receive the minimum authority required for the task at hand. Production databases, fleet management APIs, and infrastructure credentials would live well outside their execution boundary.

3. Governed Retrieval

A huge amount of "agent capability" comes down to what context they're allowed to see. I'd put document ingestion, normalization, versioning, and retrieval on Oxide's CPU and NVMe capacity.

Every document would carry provenance, access rules, and a version. Retrieval would be authorization-aware end-to-end. When an agent receives a chunk of context, it should also be able to see where it came from, which version it is, and why it was permitted.

The bar I'd hold: it's not enough to ask, "Is this relevant?" I need to be able to answer, "Was this agent allowed to see this, and is this the current version?"

4. Tool Gateways and Constrained Execution

Agents need tools, but tools are also the highest-risk surface. I'd route every tool invocation through a scoped gateway that enforces per-workflow permissions, rate limits, audit logging, and input/output validation.

For coding agents in particular, I'd give them their own disposable execution environments. Let them run builds, tests, linters, or browser automation there. Keep those environments fully isolated from production systems and from the control plane itself.

5. Evaluation-Driven Releases

I'd treat evaluations as a first-class platform service, not an ad-hoc notebook. Any material change would be required to pass through it: new models, prompts, retrieval configs, tools, agent workflows, or routing policies.

My evaluation suite would go well beyond "did it give a good answer?". For agentic systems, I'd explicitly measure task completion rate, tool correctness, permission adherence, failure recovery, latency, and cost per completed task.

The release artifact wouldn't just be an image or a config file. It'd be a bundle: model selection, prompt versions, retrieval configuration, tool contracts, policy, and the evaluation results that justify promotion. If it doesn't earn its way in, it doesn't ship.

Own the Steady State, Rent the Exceptions

I'd be deliberate about placement. Owning an Oxide rack doesn't mean every workload must justify its existence by running there.

My starting heuristic would look like this:

I'd also take advantage of the fact that Omni can manage nodes across multiple infrastructure providers. Sidero's model allows a single cluster to mix Oxide VMs with bare-metal GPU nodes where it makes operational sense. If the GPU fleet shares the right network, fault domain, and ops model, I'd consider it. If not, I'd keep them as separate clusters behind explicit inference APIs. One control plane doesn't require collapsing every scheduling domain.

Design for Failure From Day One

A single rack is still a single failure domain. Three control-plane VMs don't magically become three independent sites.

I'd validate Oxide's VM anti-affinity/placement behavior early, then explicitly plan for instance, sled, rack, and site failures.

Omni's etcd backups are valuable, but they only cover part of the picture. I'd also need:

• Off-rack copies of application databases, workflow state, audit logs, and indexes.
• Protected recovery access to fleet credentials and signing keys.
• Versioned, reproducible configuration for infrastructure, Talos, Kubernetes, and the AI platform itself.
• Documented bootstrap path to restore Omni if needed (including its own state).
• Tested restore drills. If I can't restore a critical workflow end-to-end without the original running environment, the plan isn't complete.

On the licensing front, Talos Linux is MPL-2.0. Omni is source-available under BSL 1.1. I'd lean towards self-hosting Omni to keep the ownership boundary tight, while staying honest about operational responsibilities.

Start Small: One Vertical Slice

I'd resist the urge to "platform everything" on day one. Instead, I'd ship the smallest complete system that proves the thesis.

Goal: Take one real task from request to accountable completion, with full governance and recoverability.

My checklist would be:

1. Bootstrap: Provision Talos VMs on Oxide via Omni and wire up management/app boundaries.
2. Groundwork: Deploy identity, observability, secrets management, and versioned config delivery.
3. Gateway: Stand up the model gateway with policy-based routing.
4. Orchestration: Deploy the durable workflow engine and its state store.
5. Inference: Connect exactly one external GPU inference endpoint.
6. Retrieval: Wire up one governed data source with authorization, provenance, and versioning.
7. Tools: Run the workflow through a scoped tool gateway inside a disposable execution environment.
8. Measure: Track task success, latency, cost, permission correctness, and failure behavior.
9. Break it: Deliberately kill workflow workers, restart nodes, and inject failures. Prove it resumes correctly.
10. Restore: Restore the workflow's critical state from off-rack copies without relying on the failed live system.

Only after I could do all ten reliably would I onboard a second workflow, a second model class, or expand the accelerator footprint.

Turning Tokens Into an Accountable System

The most interesting thing about owning programmable infrastructure like Oxide is the ability to decide what kind of AI system you want to operate.

I'd let the GPU fleet focus on what it does best: generating tokens as efficiently as possible. I'd let the Oxide rack be the place that remembers, reasons about authority, enforces policy, and keeps the system honest when things inevitably go wrong.

In short: Accelerators produce tokens. The control plane produces trust.

If I had an Oxide rack, I'd spend it building the latter.