How and where to use niuron
Every resource below is either an API endpoint you call from code, or a page in /app once you’re signed in. This is a conceptual walkthrough with real examples — not an exhaustive API reference.
Chat completions API
POST /v1/chat/completions is the one endpoint that does everything — classify the request, pick a model, execute it against the winning provider, and return an OpenAI-shaped response. Point your existing OpenAI SDK at https://api.niuron.ai/v1 with a router API key (create one in /app/api-keys) and nothing else about your client code changes.
curl https://api.niuron.ai/v1/chat/completions \
-H "Authorization: Bearer ar_live_..." \
-H "Content-Type: application/json" \
-d '{
"model": "auto",
"messages": [{"role": "user", "content": "Explain routing in one sentence."}]
}'model: "auto"lets the router score every eligible model on cost, latency, quality, and reliability and pick the winner. Pin a specific canonical name instead (e.g.gpt-4o,claude-sonnet-5) to skip that decision — the response shape is identical either way.response.modelreports the canonical name actually used, not the provider’s raw model string — safe to log or re-request explicitly.stream: trueworks the same way it does against OpenAI — server-sent events, one chunk at a time.
/app/chatChat playground
A chat UI in the dashboard that runs through the exact same classify-route-execute pipeline the API uses — useful for trying the router, comparing models, or debugging a prompt without writing a curl command. Authenticated by your dashboard session, not an API key.
- Pick a model (or leave it on
auto) when starting a new conversation — it’s fixed for that conversation once the first message goes out. - Every reply shows which model and provider actually answered, and can be copied, regenerated (re-runs only the latest reply against fresh context), or deleted.
- Conversations persist per user, not shared across your team.
- It’s real usage, not a sandbox — every message is a real provider call and shows up in request history and billing the same as an API call.
- Responses arrive complete, not streamed token-by-token, in this first version.
Caching
Two independent layers, both applied before a provider is ever called:
Byte-identical requests (same tenant, same messages, same routing strategy) return the stored response instead of re-calling a provider. Redis-backed, keyed per request, TTL-bound — the safe default with no accuracy trade-off.
Paraphrased requests that embed close enough (pgvector cosine similarity, 0.95 threshold by default) can hit too — opt-in, since a wrong semantic hit is a wrong answer, not just a slow one. Enabled per deployment, not per request.
Every request’s cache outcome (hit or miss, and which layer) is visible per row in request history, and rolled up as a hit rate on the overview.
/app and /app/requestsObservability
Rolled-up stats: total requests, cache hit rate, p95 latency, and cost, with an hourly trend chart.
Every request, one row each: requested vs. selected model, provider, cache hit/type, latency, actual cost, routing score, and status. This is where an API call and a chat playground message both land — same pipeline, same log.
Account management
Create and revoke API keys — the secret is shown once, at creation. This is what authenticates every /v1/chat/completions call.
See which providers are enabled, and register credentials — scoped to your tenant, or shared as a default.
Current plan, usage over the last 30 days, and upgrades — handled through Stripe Checkout. Invoices and payment methods live in Stripe’s own billing portal, linked from here.
Nothing here needs reading before you can try it.