Routing

Every metered model in kenari already has a route. There are two parts: automatic routing that works without configuration, and routes you build yourself in the dashboard. Client code does not change in either case: just send the model id, or the route name, in the model field.

Your own routes

A route is a sequence of steps you build in the dashboard (Routes menu). Each step selects one credential and one model. You send the route name as the model field. kenari runs the steps in order and moves to the next step when one step fails or hits a limit. Client code does not change, only the model value changes to the route name. Route names are per account.

Create a route

1. Open the Routes menu in the dashboard.
2. Name the route, for example opus-hemat.
3. Add steps in order. Each step selects one credential (your own key/BYOK or the kenari pool) and one model.

Step order sets priority. The first step is tried first. If it fails or hits a limit, kenari moves to the next step.

Call a route

Use the route name in the model field, exactly like calling a normal model.

curl https://kenari.id/v1/chat/completions \
  -H "Authorization: Bearer kn-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "opus-hemat",
    "messages": [{"role": "user", "content": "Halo"}]
  }'

Common patterns

Pattern	Step 1	Next step	When to use
BYOK first	your BYOK credential	kenari pool	use your own key quota first, with the kenari pool as backup
Cheapest first	cheap model	stronger model	start with the lower-cost model, move up to the stronger one when needed

Note Because a route only changes the model value, you can change step order or add backups without touching client code.

Built-in kenari-free route

Each account has one read-only route named kenari-free. This route points to free models, costs nothing, and is limited per account. The name is reserved: the kenari-free route cannot be edited or deleted.

Automatic routing

Even without building a route, each metered model is routed automatically. For one model, kenari stores several backend providers and chooses a healthy one in the priority order we maintain (among equally ranked backends, the lower-cost one goes first), then moves to the next backend if the first fails, hits a limit, or is slow.

Automatic failover

Backends that error enter a short cooldown, then requests are sent directly to the next backend. You do not need to configure anything.

Sticky lane

Within one session, an account tends to stay on the same backend while that backend is healthy. This makes output more consistent and latency more stable.

Key rotation

If one provider has several keys, kenari rotates them to spread load and avoid limits.

Last backup

The last-resort backend is used only when the other options are unavailable.

Warning Upstream provider identities are never exposed to the caller. See Errors & status for error behavior and status codes.