One API, served by people.

the API is OpenAI-compatible. if your app already speaks to an OpenAI endpoint, it works here after changing two strings: the base URL and the key.

curl https://stellode.fun/api/v1/chat/completions \
  -H "Authorization: Bearer sk-stld-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "stellode-1.2",
    "messages": [{ "role": "user", "content": "hello" }],
    "stream": true
  }'

existing SDKs need only the constructor changed:

# python
from openai import OpenAI
client = OpenAI(
    base_url="https://stellode.fun/api/v1",
    api_key="sk-stld-...",
)

// typescript
import OpenAI from "openai";
const client = new OpenAI({
  baseURL: "https://stellode.fun/api/v1",
  apiKey: "sk-stld-...",
});

want to feel it first? the same models run in the chat with a daily free allowance.

every request carries a bearer token. keys start with sk-stld- and are shown once at creation — store them like passwords. keys are created and revoked from your account page; a revoked key stops working within 60 seconds.

Authorization: Bearer sk-stld-...

billing is in credits. 1 credit = $0.01, purchased with USDG. credits are non-transferable and never expire. staking the token grants a capped daily allowance of free credits, spent automatically before any paid credits.

three text models and one image endpoint. prices are per message, stated in credits, charged only on completed jobs.

model internals — architecture, weights, serving stack — are not published. what is published: the receipt for every job, and the machine that served it.

base URL https://stellode.fun/api/v1

every completed job produces a receipt: which worker served it, how many tokens, how many credits, when. streaming responses end with a receipt frame before [DONE]:

data: {
  "type": "receipt",
  "job_id": "job_01hx4k9...",
  "worker_id": "wkr_7f3a",
  "model": "stellode-1.2",
  "prompt_tokens": 412,
  "completion_tokens": 286,
  "credits_spent": 10,
  "latency_ms": 1840
}

receipts are publicly fetchable by anyone with the job id — that is the point. you can verify what you were charged and which machine did the work.

curl https://stellode.fun/api/v1/receipts/job_01hx4k9...

a request is a four-step sequence:

1. your prompt reaches the orchestrator. a safety filter runs before dispatch; blocked requests never reach a worker.
2. the orchestrator picks a worker. routing order: model capability match, then reputation score, then lowest queue depth, then latency to your region. jobs time out at 45s and are reassigned, at most twice.
3. the worker serves it. tokens stream back through the orchestrator to your client as SSE.
4. receipt + payout. the job is written to the ledger, the receipt is published, and the worker's share settles after a 60-minute delay window.

workers are checked continuously: known-answer canary jobs at ~2% of traffic, duplicate dispatch on 1% of jobs with output comparison, and a tokens/sec plausibility envelope per model and device. a worker that fails three canaries stops receiving jobs and its pending payout is held, not paid. the settlement delay exists so fraudulent jobs can be clawed back before money moves.

the split on every job is fixed and public:

• 70% to the worker that served it, in USDG.
• 80% instead, if the worker has 1,000,000 tokens staked and matured for 24h.
• the remainder is network margin, swept to the treasury. the treasury splits 50/50: half buys back and burns the token, half pays the token stakers in USDG. details and every contract address live on /treasury.

limits are per key. a limited request returns 429 with a retry-after header — respect it and the limiter resets cleanly.

inference runs off-chain, on real hardware. the money layer is contracts on Robinhood Chain (chain id 4663, an Arbitrum Orbit stack settling to Ethereum; gas is ETH). we don't pretend a GPU runs on a blockchain.

one more disclosure: the chain's sequencer is centralized, operated by Robinhood. we state it here because it's true, not because it sounds good.

prompts are not written to the application database. they do transit the orchestrator, and they do reach a third-party worker machine — that is what this network is. we do not claim end-to-end privacy, because we have not shipped attestation. when that changes, this page will say so.

requests flagged by the pre-dispatch safety filter are logged and rejected before any worker sees them.