API Playground

What the playground restricts, and why

The console talks to a real node — possibly a production one, like k16. The rule that decides what runs live is simple: a route executes in the browser only if failing to notice a mistake there costs nothing. Everything else renders a curl command instead, so you read it before it runs anywhere.

The rule

✅

Executes live

Every GET — nothing a GET does is supposed to change state — plus the two POST routes whose worst case is cheap and reversible: creating a chat completion, and creating a new API key.

🔒

curl only

Anything that revokes access, moves funds, changes what network or model the node is on, writes a file to disk, or turns on sending prompts to a third-party API. The console builds the exact command and you run it in your own terminal.

Every route, by policy

Route	Policy	Reason
`GET /v1/models`	Live	Read-only, no key needed
`POST /v1/chat/completions`	Live	Worst case: one paid or free completion, same as using the chat panel
`GET /v1/nodes`	Live	Read-only
`GET /v1/agent`	Live	Read-only, no key needed
`POST /v1/agent/launch`	curl only	Changes whether this machine is on the P2P network
`GET /v1/swarm/manifest`	Live	Read-only
`POST /v1/swarm/manifest`	curl only	Re-signs the manifest and can trigger a real model load
`GET /v1/routing-log`	Live	Read-only
`GET /v1/keys`	Live	Read-only (already needs a key to call)
`POST /v1/keys`	Live	Additive and reversible — a new key can be revoked
`DELETE /v1/keys/:id`	curl only	Revokes access; could be the key the console itself is using
`POST /v1/keys/revoke-all`	curl only	Revokes every key, including the panel's own
`GET /v1/quota`, `/v1/budget`, `/v1/budget/report`	Live	Read-only
`GET /v1/receipts/:id`	Live	Read-only, no key needed
`GET /v1/wallet`, `/v1/wallet/balances`, `/v1/wallet/history`	Live	Read-only
`POST /v1/wallet/send/quote`, `/v1/wallet/send`	curl only	Moves real funds; `send` needs `confirmar: "MAINNET"` on mainnet
`POST /v1/wallet/create`	curl only	Generates key material; the 24-word phrase is shown once
`POST /v1/wallet/network`	curl only	Changes which chain the node talks to; requires a restart
`POST` / `DELETE /v1/wallet/tokens`	curl only	Edits what the wallet watches
`GET /v1/files`	Live	Read-only
`POST /v1/files/upload`, `/v1/files/fetch`	curl only	Writes bytes to this node's disk and Hyperdrive
`GET /v1/upstream`	Live	Read-only
`POST /v1/upstream/opt-in`	curl only	The one switch that can send a prompt to a third-party API

CORS: why a live request might fail anyway

The console runs as a page on this origin and calls the Base URL you give it — typically your node on the LAN, such as k16. That is a cross-origin request by definition, and the browser will only let the response through if the node's gateway sends back an Access-Control-Allow-Origin header that permits it.

If the console reports a network error rather than a status code, this is almost always why. Two ways to fix it:

Open this documentation site from the same origin as the node — e.g. served by pyrusllm serve itself, or reverse-proxied alongside it.
Configure the gateway to send a permissive Access-Control-Allow-Origin for the routes above. Until that is in place, every request generated here still works as a curl command, which is not subject to CORS.

Testing against k16

Set Base URL to wherever k16's gateway listens — its LAN address and port, e.g. http://k16.local:8787 or an IP:port — and paste in a key created from that node's My Node panel or via POST /v1/keys run directly against it. The connection fields are saved only in this browser's localStorage, so the key never leaves your machine except in the request itself.