Checking gate status…

● Local control plane · orbio API

One gate.
Every key.

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.

–Keys available
–Sticky key
–Uptime
4Failure classes

Reading /health…

Where the gate stands

Four chapters: what runs today, how to watch it, what was just built, and what is not public yet.

  1. Chapter 00

    The gate is live

    All of this runs today on this box and is covered by offline tests.

    • A key pool loaded from keys.json, sticky on the last key that worked.
    • A failover matrix that cools a failing key and retries the next one in the same request:
    40230 minbalance
    40124 hauth
    42960 srate limit
    5xx5 minupstream
    • Streaming pass-through: SSE relayed chunk by chunk, never buffered.
    • Balance polling for every key, every 10 minutes.
    • A usage ledger in SQLite with spend estimated per key and per model.
  2. Chapter 01

    Watch it in real time

    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.

    Open the dashboard

  3. Chapter 02

    Holder access is built

    • Token-gated access built
      Holders of the operator's token on Robinhood Chain sign a message with their wallet and get their own API key, with a per-wallet rate limit and daily spend cap. It switches on when the token launches. See the access page
    • Telegram alerts wired
      Low balance, all keys down and, with holder access on, a runway warning. Off by default: set TG_BOT_TOKEN and TG_CHAT_ID to switch them on.
    • A public URL on a domain planned
      TLS in front, GATE_TOKEN required, so holders can reach the gate and the dashboard opens from a phone.
    • Per-project budgets planned
      A spend cap per client, enforced by the gate before a request goes upstream.
  4. Chapter 03

    Not announced

    Nothing to share yet.

What it does

Seven parts, each small enough to read in one sitting. Exact routes and numbers are in the docs.

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.

Automatic failover

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.

Unbuffered streaming

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.

Balance monitor

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.

Usage ledger

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.

Optional Telegram alerts

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.

Token-gated access

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.

See the access page

Dev updates

Notes from the build

What shipped, newest first.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.