Public API

Call the model from your own code

No signup, no waitlist. Request a key, send it with your messages, and you get the same streaming replies the chat page shows — programmatically, from a script or an app of your own.

Quickstart

Three requests

Get a key, spend it on a reply, then check what is left of the day's quota. Replace <base-url> with the address on the deployment page — it changes when the tunnel restarts, the same address the chat page itself resolves at runtime.

terminal
# 1. get a key — instant, no signup
$ curl -X POST <base-url>/v1/keys

{"api_key": "sk-sutra-…", "daily_limit": 100,
  "note": "Save this now — it is shown only once…"}

# 2. spend it on a reply
$ curl -N -X POST <base-url>/v1/chat \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-sutra-…" \
  -d '{"message": "Explain photosynthesis in one sentence."}'

data: {"token": "Photo"}
data: {"token": "synthesis"}
data: {"done": true}

# 3. check what is left today
$ curl <base-url>/v1/usage \
  -H "Authorization: Bearer sk-sutra-…"

{"used_today": 1, "daily_limit": 100}
Reference

Three endpoints

EndpointAuthDoes
POST /v1/keysnoneMints a new API key. Shown once — it cannot be recovered.
POST /v1/chatBearer keyStreams a reply over Server-Sent Events, one token event at a time, ending in {"done": true}.
GET /v1/usageBearer keyRequests spent today against the key's daily limit.

Request body for /v1/chat

FieldTypeDefault
messagestring, required—
max_tokensint512
temperaturefloat0.5
Limits

Why there are two of them

This runs on one GPU, shared by the chat page, the demo, and every key holder at once. No cap on a self-serve key would let one caller take all of it.

3 keys per IP, per day

Stops one visitor from minting unlimited keys to route around the limit below.

100 requests per key, per day

The actual quota. Resets at 00:00 UTC. GET /v1/usage reports what is left without spending a request to find out.

A wrong or missing key gets 401. A key over quota gets 429 with the reset time in the message. Both come from the same check, atomically with charging the request — two calls racing on a key's last unit of quota cannot both slip through.

Prefer the chat page?

/chat needs no key at all — it is the same model, with a UI in front of it instead of an SDK.

Open the chat