Sticky key pool
Requests stay on the last key that worked; the gate only moves when that key fails. The current key and every cooldown are stored in SQLite, so a restart changes nothing. The order in keys.json is the failover order.
Checking gate status…
● Local control plane · orbio API
OrbioGate is a local control plane for the orbio API. Your tools talk to one address on this machine; behind it sits a sticky key pool with automatic failover, streaming pass-through that never buffers, and a balance watch that polls every key.
Reading /health…
Four chapters: what runs today, how to watch it, what was just built, and what is not public yet.
Chapter 00
All of this runs today on this box and is covered by offline tests.
Chapter 01
The dashboard shows each key's balance with a 24-hour sparkline, its cooldown and requests today, a live feed of the newest requests with status and latency, spend per key and model, and the model catalog with search. It refreshes every 10 seconds and pauses while the tab is hidden.
Chapter 02
Chapter 03
Nothing to share yet.
Seven parts, each small enough to read in one sitting. Exact routes and numbers are in the docs.
Requests stay on the last key that worked; the gate only moves when that key fails. The current key and every cooldown are stored in SQLite, so a restart changes nothing. The order in keys.json is the failover order.
402 or “balance cannot cover” cools a key for 30 min, 401 for 24 h, 429 for 60 s, 5xx or a network error for 5 min. The same request is retried on the next key before the client sees anything. Other 4xx are the client's problem and pass through.
Server-sent events are relayed chunk by chunk as they arrive, with the upstream status and content-type untouched. Body, headers and query string pass through; only the auth header is swapped for a pool key.
Every key's balance is polled every 10 minutes. A balance that goes up (a top-up) clears a balance cooldown early; a 401 on the poll parks the key as dead until it is reset.
Each request is logged to SQLite: key label, model, status, latency, bytes. Spend is estimated from the balance's usage delta between polls and split across models by response size. Requests are kept 14 days, balance snapshots 30.
A low-balance alert (under BALANCE_ALERT_USD, default $5, at most once per key per 6 h) and an all-keys-down alert (at most once per hour). Nothing is sent until TG_BOT_TOKEN and TG_CHAT_ID are set.
Holders of the operator's token on Robinhood Chain claim their own API key by signing a message with their wallet: no transaction, no gas. The balance is re-checked every few minutes and the key stops when it drops below the minimum. Each wallet has its own rate limit and daily spend cap, and holder requests run through the same key pool and failover. Off until the token launches.
Dev updates
What shipped, newest first.
Site v3.0.0: a responsive nav with a mobile menu, balance sparklines and loading skeletons on the dashboard, a docs sidebar with copy buttons, and a step-by-step access page.
Token-gated access: holders of the operator's token claim their own API key on the access page by signing a message, with a balance re-check, a rate limit and a daily cap per wallet. It stays off until the token launches.
Site v2: the web layer is English and multi-page now. This landing page, the docs, a styled 404 and one shared stylesheet served by the gate itself.
The dashboard: balance and cooldown per key, spend per key and model, a live feed of the newest requests and the full model catalog with a strict FREE filter.
The gate: a sticky key pool, failover on 402 / 401 / 429 / 5xx inside the same request, unbuffered SSE, balance polling and a SQLite usage ledger, with 24 offline tests.