TensorBreeze Early access

Private AI infrastructure

Every GPU you own. One private AI endpoint.

TensorBreeze turns the GPU machines you already own — Windows or Linux — into one OpenAI-compatible endpoint on your own network. No port forwarding. No Kubernetes.

Request early access See how it works
Workers
NVIDIA · Linux + Windows (WSL2)
Enrollment
Outbound-only, no open ports
Application API
OpenAI-compatible
Status
Early access
Point your app at your fleet
Base URL
http://127.0.0.1:8321/v1
API key
bra_••••••••••••••••
Model
your-model-alias

routed → RTX 5090 · windows-tower · WSL2

Three settings. No TensorBreeze-specific code.

One fleet, many machines

Send the request. Breeze handles the hardware.

Applications talk to one endpoint. Breeze Router matches each request to a healthy GPU with the memory to serve it, and keeps applications insulated from worker credentials and network topology. The Router binds to loopback beside your applications — nothing on your network can reach it — and requests travel to workers over node-initiated tunnels.

your app→Breeze Router · loopback→Breeze Controller→GPU worker · outbound tunnel

  1. 01
    Connect

    Enroll each machine with a one-time claim. Workers connect outward over HTTPS — nothing listens, nothing is port-forwarded.

  2. 02
    Route

    One OpenAI-compatible endpoint with scoped per-app keys and model aliases. Requests land on the GPU that can actually serve them.

  3. 03
    Run

    Models run in narrow, signed service profiles on the machine with the VRAM — your gaming PC included.

Breeze Console

The whole fleet, one pane of glass.

Live utilization, memory, temperature, and process telemetry for every enrolled machine — alongside queueing, placement, and an append-only activity trail. These are real Console views of a demo fleet. Flip through them.

Breeze Console overview with live GPU telemetry for a five-node demo fleet. Breeze Console worker list showing Linux and Windows WSL2 nodes. Breeze Queue with GPU capacity reservations across the demo fleet. Breeze Console activity trail with append-only audit events.

First-class Windows workers

The biggest GPU you own probably runs Windows.

Most orchestration stacks stop at Linux. TensorBreeze treats a Windows machine with WSL2 as a first-class worker — enrolled, monitored, and serving models like any other node, whether it’s a workstation or the PC you game on.

WSL2 aware
A keepalive supervisor handles the realities of GPUs inside WSL2 so you don’t have to.
Tray status
A system-tray menu shows fleet state from the desktop. No terminal required.
No dual boot
Enroll once, keep Windows.

Planned Apple Silicon is next: a macOS worker is on the roadmap, so the GPU in your Mac can join the same fleet.

Running in the real world

A 32B model. A remote RTX 5090. Zero inbound ports.

TensorBreeze’s first production workload is its own proof: an application on its stable host routes chat completions to a 32-billion-parameter model served by vLLM on an RTX 5090 — inside WSL2, on a different machine, behind no open inbound ports. The application changed three settings.

Model
32B parameters, quantized, loaded and serving on consumer hardware.
Serving GPU
RTX 5090 in a Windows machine, reached through WSL2 and an outbound tunnel.
What the app knows
A base URL, a key, and a model name. Tokens and latency are audited; prompts never are.

Designed for private infrastructure

A compromised Controller should not become a shell on every worker.

Workers connect outward and expose narrow inference contracts — never SSH, filesystems, or arbitrary commands. Every capability has its own credential, route, and schema, and everything dangerous ships switched off.

  • Outbound-only workers with per-capability credentials
  • Offline-signed releases with anti-rollback updates
  • Content-free audit: tokens and latency, never prompts
  • Per-application connector credentials and model aliases

What it’s for

Keep apps stable. Make GPUs disposable.

Applications stay on the host you trust; inference goes wherever the VRAM is. Three shapes this takes:

Off the app server
Move AI workloads off the machine serving your product — without new APIs, SDKs, or app changes.
The gaming PC
Turn an idle RTX-class Windows machine into private inference capacity for your team.
Failover built in
A model alias can be served by more than one machine. When one goes away, routing moves — your app config doesn’t.

No magic, on purpose

What TensorBreeze is not.

Clear boundaries are a feature. These are permanent product truths, not temporary limitations.

Not remote CUDA
TensorBreeze never pretends a remote GPU is a local device. Work goes to the machine; the machine does the work.
Not a job runner
No arbitrary commands, no remote shells. Workers run signed, allowlisted service profiles — nothing else.
Not a cloud
Your Controller belongs to your network. Nothing routes through ours.

Apps

A small catalog, on purpose.

Breeze separates client apps from inference providers, giving each integration only the credential and network access it needs. The catalog grows deliberately — reviewed and scoped, not scraped.

Provider

vLLM

Signed model services behind the Router, offline at runtime.

Serving today
Client

Open WebUI

Private chat through a scoped Breeze connector.

Early access
Client

Anything OpenAI-compatible

Your own tools and agents point at the Router like any other endpoint.

By design

Early access

Put every GPU you own to work.

Request early access