OpenGrid

Pre-production · Apache 2.0

Independent operators.Unified by protocol.

The AI Grid brings compute from independent providers into one intelligent network. Each request is placed by capacity, reputation, and locality, and verified with a signed receipt naming the operator, model, and build that served it.

Protocol
v1.6
Licence
Apache 2.0
Access
Waitlist
coordinatorclientsmachinesclusters
who generates

Machines with owners

A Mac, a workstation, a 1MW modular site — enrolled by whoever owns it. Ownership never transfers to us. The node key is generated on the machine and never leaves it.

how you call it

Nothing to rewrite

An OpenAI-compatible surface your client already speaks. The migration is one base URL.

what comes back

Evidence, not assurances

Every successful call returns a signed record naming the exact model artifact, runtime build and operator that answered.

The evidence

One base URL in. A signed receipt back.

The client you already run keeps working — the request shape, the streaming, the tool calls. What changes is the response: every successful call carries a signed record of which operator answered, which model artifact it loaded, and which runtime build it ran. Checkable after the fact, by you, without asking us.

Illustrative — the endpoint is not open yet

client = OpenAI(
    base_url="https://api.opengrid.computer/v1",  # the migration
    api_key=OPENGRID_API_KEY,
)

Walk through a requestRead the wire contract

Sample receiptCountersigned
receipt_id
rcpt_01JQ8F4T7M2XW9K2A
provider
blr-studio-01 · ap-south-1
provider_key
ed25519:4c9f21a8…7b3e
model_artifact
sha256:7b064f58…557c
runtime_build
llama.cpp-b4023+og.4a71c00
transport
Encrypted relay · TLS 1.3
tokens_in / out
1,204 / 856
signed_at
2026-07-26T09:14:22.418Z
ledger_entry
le_00918442 · merkle 8c1d09fa

The contract

Four questions every session answers.

The wire contract obliges each machine to answer these, in order, with signatures. The full paragraphs — and what each answer rules out — are on the protocol page.

01

Who are you?

A key generated on the machine proves itself against a signed challenge. The private key never crosses the wire.

02

What can you run?

Routes bind to an artifact SHA-256 and an approved engine build — exact bytes, not a model name.

03

How does work reach you?

One signed envelope over TLS 1.3, sealed the same whether the path is direct QUIC or the relay.

04

What did you do?

A node-signed receipt, countersigned only after the edge reconciles it, posted to a double-entry ledger.

Have capacity?

From a Mac to a megawatt.

One protocol covers both ends. An M-series Mac on a desk takes a share of latency-tolerant work; a modular datacenter with power and spare utilisation takes production traffic. Same enrolment, same identity model, same settlement. Your hardware stays yours, and your cluster keeps its own scheduler.

Join the waitlistSee what a request looks like

Your key never leaves the box
The node identity is generated on the machine you enrol.
Signed work, signed settlement
Completed work is countersigned and posted to a double-entry ledger.

The coordinator, the node daemon and the protocol are Apache 2.0. Every claim on this page is specified in the repository, where you can verify it for yourself. Where this stands today: enrolment is invite-only, and routing to managed clusters stays fail-closed until usage can be proven from receipts — the remaining gates ship in the repository, next to the code that enforces them.

Read the source