Using the Gateway

Not built. api.thirtyspokes.ai does not exist. There are no accounts, no API keys, and no payments. This page documents the intended design and — just as importantly — which parts of it are still undecided. Nothing here is a commitment.

The intent

One API key, one base URL, every frontier model behind it. Your existing OpenAI or Anthropic client keeps working — same calls, same response shapes.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.thirtyspokes.ai/v1",   # the only line that changes
    api_key=THIRTY_SPOKES_KEY,
)

r = client.chat.completions.create(
    model="auto",                                 # the wheel picks the spoke
    messages=[{"role": "user", "content": "..."}],
)

Two ways to address a model:

`model`	Behaviour
`"auto"`	The network routes the request to the spoke best suited to carry it
`"<any spoke>"`	Pin a specific provider model by name

Streaming, tool use, and structured output are intended to pass through unchanged.

The empty center

The hub holds no model and performs no inference. That is the design constraint, not a slogan: a gateway that ran its own model would have an incentive to route to it. Because we hold nothing, we can connect everything.

And a gateway run by one company is just another gatekeeper — which is why Thirty Spokes is designed to run as a Bittensor subnet, where miners compete to route and no single operator decides which models you reach or what they cost.

The gap between the competition and the gateway

This is the honest part, and it is the main reason this page is short.

The subnet mechanism that exists today (KOTH) selects the best routing agent by running it against a fixed benchmark suite inside the miner's TEE. It answers the question "whose router is best?" rigorously and un-forgeably.

It does not yet answer "how does a live user request get served by that router?" Those are different paths with different requirements:

	Benchmark competition (exists)	Live serving (undesigned)
Who runs the agent	the miner, in its own TEE	?
Latency budget	minutes per epoch	milliseconds per request
Who pays inference	the miner, own key	the user
Verification	one attested proof per epoch	per request? sampled?
Failure mode	disqualification next epoch	a user gets a bad response now

Serving live traffic through the reigning router is a separate layer that has not been designed. Anyone claiming otherwise — including a previous version of our own marketing copy — is ahead of the code.

Decided vs open

Decided	Open
Drop-in OpenAI/Anthropic compatibility	Who operates the gateway (validators? the owner? anyone?)
`model="auto"` plus pin-a-spoke by name	Authentication and account model
The hub holds no model, does no inference	Payment rails and pricing
The pool is an owner-pinned allow-list	Per-request verification (if any)
Miners compete on quality per dollar	How the reigning agent is deployed for serving
	Latency budget and routing overhead

We would rather ship this page with an "open" column than invent a pricing table.

A necessary caveat on value

Our own measurements say that on general traffic an achievable router does not beat the best single model on accuracy — and the best single model is frequently the cheapest one. The honest value proposition of a routing gateway is cost at intermediate quality targets, not "beat the frontier."

If you are evaluating whether to build on this, read Findings first. It is the argument against our own product, published with the code that produced it.

What you can run today

The mechanism is real even though the gateway is not:

Quickstart — run the whole competition offline in two minutes
Build a Router — write an agent and score it with the dev kit
Mine the Subnet — publish a bundle and compete