How WebikAI routes a request

This page describes exactly what happens between your API call and the provider — including what we measure, what we charge, and what we don't claim.

1. Your rules come first (hard filters)

Before anything is ranked, we remove every endpoint your policy forbids. Filters you control: allowed / blocked providers (including which providers OpenRouter may use underneath, when we route through it), jurisdiction (US-only, EU-only), data policy (e.g. require zero-retention — endpoints with an unknown policy do not pass a strict requirement), capabilities (tools, structured output, vision, streaming, context length — an endpoint that can't satisfy the request is removed, not risked), and connection mode (your keys, our wallet, or hybrid). If nothing passes your filters, you get a clear error naming the filter — we never silently relax your policy.

2. Then eligibility and funding

A route is only considered if it can actually run: your key exists for that provider and allows that model (BYOK), or an approved managed account covers it (wallet). Managed attempts reserve their estimated cost from your prepaid balance before the provider is called and settle to the actual bill after — an under-funded fallback never blocks a funded route, and a zero balance stops requests instead of going negative.

3. Ranking what's left

Surviving routes are scored by the profile you chose. Think of the profiles as a cost-quality tradeoff slider: Cheapest saves hardest, Premium protects quality first, and Balanced is the default middle. The exact default weights:

Cost uses the full estimated request (input + cached + output tokens at that endpoint's rate) — not just the output price. You can set custom weights per account, workspace, project, key, or request, or skip ranking entirely by pinning an exact model and provider.

The bare auto and auto/smart lanes are different from WebikAI's benchmark-ranked lanes: when your provider policy allows an OpenRouter route and you have an eligible OpenRouter key, they pass the request to openrouter/auto. WebikAI still applies your provider, data-policy, budget, and receipt rules around that call, but the task-difficulty choice comes from OpenRouter's smart router. Use auto/code, auto/cheap, or auto/frontier when you want WebikAI's explainable lane ranking instead.

4. Fallbacks and session routing

If the chosen provider errors or times out, we try the next eligible route and mark the response x-webik-fallback: true. Within a conversation (send x-webik-session-id) we pin the served route so agents keep consistent behavior and prompt-cache hits — unless it fails, regresses, or your policy changes. That makes WebikAI a session router for agents, not just a per-call price sorter.

5. Where the quality scores come from (and their limits)

Two sources. Probes: deterministic test suites (JSON extraction, schema output, exact-answer math, tool-call formation, deterministic coding tasks) run daily against every endpoint at temperature 0, scored pass/fail, published with sample sizes and confidence intervals. Real traffic: rolling error rates, latency, and structured-output failure rates from actual requests through the gateway. A provider whose scores regress against its own trailing history is ranked lower automatically.

What we don't claim. Provider-quality measurement is empirical and relative, not absolute: we can't see inside a provider, differences for mature models are often small, and our probe suites can miss subtle degradation — that's why the score is labeled beta, why we show sample sizes, and why you can always pin providers or set a minimum quantization for OpenRouter routes yourself. When we route through OpenRouter, the inner provider choice combines your constraints (only/ignore lists, zero-retention, quantization floor) with OpenRouter's own quality signals. And our quality system measures whether providers complete legitimate professional work — it is not, and will never be, a tool for ranking providers by willingness to bypass safety policies.

6. Every response carries its receipt

x-webik-request-id · x-webik-model (what actually served it) · x-webik-provider · x-webik-credential (byok/managed) · x-webik-fallback. The dashboard shows the same per request, with the routing reason and estimated vs. actual cost.

7. What it costs

BYOK traffic is never marked up — you pay your provider directly; our fee is the subscription. Managed traffic is provider cost + your plan's published markup (table on the pricing page). If a provider's price feed is missing or invalid, that endpoint is not billable on the wallet at all — it stays BYOK-only until a human verifies the rate. The managed markup funds the governance layer — per-client isolation, rebilling reports, enforced policy, and quality monitoring; pure token access is always cheaper via BYOK, on purpose.