Loading…
Each tier runs on two to three independent backends behind a self-healing engine — if one declines or errors, the next answers in its place. The model behind the tier is never revealed, and your key only opens the tiers your plan holds.
Six things that stay true on every tier.
Backends are chosen for how rarely they refuse, then read again on every call. If one declines, the engine moves the request to the next before you ever see it — a refusal almost never reaches you as an answer.
Every tier is backed by two to three independent backends. If one declines a request or fails mid-flight, the engine moves it to the next and returns a single answer — you never see the seam.
The model behind a tier is never revealed. Response ids are randomised and identifying headers are stripped, so nothing in a reply points back to a specific upstream — and your prompts are never echoed back.
Access is not a UI setting. A key that does not hold the tier gets a hard 403 at the gateway, and the entitlement is checked on every call — not just in the dashboard.
Your system prompt, parameters and message history are carried with every call. You compose the request; the tier handles the answer.
OpenAI-compatible, on the same host and key as every other model. Switch tiers by changing the model id in your request — nothing else in your integration moves.
From the lightest to the flagship. Ids, context and prices are read live from the catalog.
Level 1 · Fast and light
The lightest tier — built for high-volume, low-latency work.
Level 2 · Frontier class
Frontier-class capacity for demanding reasoning and long agentic runs.
Level 3 · Flagship
The flagship tier, built for the heaviest loads and the hardest questions.
One request in, one answer out — the failover happens behind the seam.
Call the tier id on the shared base URL with your own key — one request in.
Each tier maps to two or three independent backends. The engine selects one and forwards the request.
If that backend declines or errors, the next answers in its place — silently. You receive a single answer at the tier’s published rate.
OpenAI-compatible. One base URL, one key, your model id.
https://helioroute.com/v1curl https://helioroute.com/v1/chat/completions \
-H "Authorization: Bearer $HELIOROUTE_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "pvt-003",
"messages": [{ "role": "user", "content": "hello" }]
}'Pro opens PVT-001. Scale adds PVT-002. Reseller adds PVT-003. Each tier card above names the plan it opens with, and the gateway enforces that mapping per key — the dashboard only reflects it.
Yes. Point the OpenAI SDK at the base URL above with your key and set the model to the tier id. The Anthropic Messages format works on the same host and the same key.
Each tier has two to three independent backends. If one is busy, declines or errors, the engine moves the request to the next and returns one answer — usually without you noticing.
No. Response ids are randomised and identifying headers are stripped; the tier is the only identity you see. Your prompts are never echoed back.
Yes. The tier is just the model id in the request. Change PVT-002 to PVT-003 and nothing else about your integration moves — the base URL, the key and the format stay the same.
Per token, at the published input and output rates for that tier — shown on each card above, per 1M tokens. No per-seat fee and no platform charge.
Pro opens PVT-001, Scale adds PVT-002, and Reseller adds PVT-003. Compare the plans and start with the tier you need today.