Inferbase vs Portkey
Portkey routes on rules you write over your own providers. Inferbase classifies each prompt and picks the best model, with an auditable decision.
What the routing can see
Both route requests across many models behind one OpenAI-compatible API. The difference is what the routing is allowed to look at.
Routes on who is asking
Conditions match metadata, params, or the path you attach. The prompt itself never picks the model.
Routes on what is asked
No rules to write. Each request is matched to the best model for its task, and recorded.
Control panel, or routing-first
Governance over providers you already run, versus model selection as the product.
Portkey’s value is control: a hosted gateway over the provider accounts you already hold, with observability, budgets, guardrails, and prompt management in one place, and rule-based routing, fallbacks, load balancing, conditional routing, and canary testing, around every request. That is a genuinely strong governance layer.
- The rules cannot see the prompt. Conditional routing matches metadata, request params, or the URL path that you attach; nothing in the gateway reads the request and asks which model would serve it best.
- The model decision is still yours to encode. Every routing outcome traces back to a rule someone wrote and must now maintain as models, prices, and providers change; a routing platform absorbs that churn for you.
- It observes inference, it does not run it. Portkey fronts the provider accounts you hold and bills for the gateway; capacity, quotas, and inference bills stay yours, spread across your providers.
If what you need is governance over a provider estate your teams already run, Portkey is the stronger fit. If what you need is the right model per request, chosen from the prompt itself and served for you with a decision on the record, that is where Inferbase is built to win. Still weighing the categories themselves? Start with our breakdown of gateways versus routers.
Side by side
Where the two line up and where they diverge, without hiding what Portkey does well.
| Inferbase | Portkey | |
|---|---|---|
| Routing decision | The best model for each request | The target your rules select |
| Per-prompt model selection | First-party, benchmark-grounded, the core of the product | No, conditions key on metadata and params, never the prompt |
| Routing building blocks | Quality, cost, or latency as an objective | Fallbacks, weighted load balancing, conditional routing, canary, circuit breakers |
| Fallback on failure | Automatic, ranked within the routed pool | Yes, per-error triggers across providers and models |
| Per-request transparency | Audit record: task, candidates, scores, why the winner won | Deep logs, traces, costs, and alerts, no decision rationale |
| Prompt management and guardrails | No, bring your own | Yes, templates plus a large guardrail library |
| OpenAI-compatible API | Yes | Yes |
| Provider accounts | None needed, one bill | Yours, virtual keys wrap your provider keys |
| Managed serverless inference | Yes, runs the model for you | No, a gateway over your providers |
| Pricing | Free to start | Free tier; Production at $49/mo, metered on recorded logs |
Reflects publicly documented behavior and pricing as of July 2026. Portkey ships fast, check their docs for the latest.
Where each one fits
They solve different problems, so pick by what you are optimizing for: governance over providers you hold, or routing that decides for you.
Portkey is the better fit when
- You want one control panel of telemetry, budgets, and guardrails over provider accounts many teams already use
- You need prompt management and a guardrail library in the same place as the gateway
- You have compliance requirements to run against your own providers, with VPC or private-cloud deployment
- You want to canary new models and providers behind rules you control
Inferbase is the better fit when
- You want the platform to pick the best model per request from the prompt itself, not rules you wrote
- You do not want to hold provider accounts or maintain a rules layer
- You need a routing decision you can audit, per request
- You want routing and serving as one managed system with one bill
Frequently asked questions
Straight answers on how Inferbase and Portkey differ, and when each one is the better choice.
An LLM gateway is one API in front of many providers: every service calls the gateway with one set of credentials, and the gateway holds the provider keys, enforces limits and budgets, logs the traffic and falls back when a provider fails. Most gateways send each request to the model you named, or to whichever host is up for that model; the model decision stays in your config or in rules you write. Inferbase is a gateway that also makes that decision, on the prompt and on evidence.
A router decides which model should answer; a gateway executes the request and governs it with keys, limits, budgets, logs and failover. Some routers only recommend, leaving you to call the provider; some gateways only proxy to the model you named. Inferbase runs the router inside the gateway, so the decision is served rather than recommended and its record sits beside the usage receipt.
That the same call which chooses the model also runs it. You send model="auto" to one OpenAI-compatible endpoint; the router classifies the request, picks the model that clears the bar for the task on your objective, the gateway serves it with two fallbacks ready, and the response comes back with its decision on the record. There is no second system to operate for the inference and no second bill for it.
When a workload mixes tasks and difficulties, which most production traffic does. We publish no savings percentage: one was withdrawn in September 2026 because the baseline price it was measured against is no longer one we can substantiate, and a ratio is only as good as its denominator. What routing does is send each request to the cheapest model that clears the quality bar for it, so the gain is the gap between what you pay now and what the right-sized model costs. A workload that is all one hard task gains less; the routing page shows the run and its caveats, and Routing Preview measures it on your own traffic.
It does, by rules you write. Conditional routing matches on metadata, request params, or the URL path, and sends the request to the target your condition names, with fallbacks, weighted load balancing, and canary testing around it. What the rules cannot see is the prompt: there is no content classification and no learned model selection, so the model choice is still a decision you encoded ahead of time. Inferbase classifies each prompt and picks the best model for that task on the objective you set, with a decision record you can audit.
Portkey’s observability suite is deep and a genuine strength: logs, traces, cost analytics, and alerts across every provider you put behind it. Inferbase’s transparency centers on the routing decision itself, for each request it records the detected task, the candidate models, their scores, and why the winner won. If you want organization-wide telemetry over providers you already run, Portkey is strong; if you want to know why this model answered this prompt, that is the record Inferbase keeps.
Yes. Portkey is bring-your-own-key: its virtual keys wrap the provider keys you hold, inference is billed by your providers, and Portkey charges for the gateway, metered on recorded logs, with a free Developer tier and a Production tier at $49 per month as of July 2026. Inferbase serves the models it routes to, so there are no provider accounts to hold and one bill.
They can coexist. If your organization runs Portkey as a control panel for guardrails, prompt management, and telemetry across many teams, Inferbase can sit behind it as one more OpenAI-compatible endpoint, with model="auto" turning on routing for the traffic you send it. If what you want from the gateway is picking and running the right model, Inferbase covers that without a rules layer to maintain.
Both are OpenAI-compatible, so it is a base URL and key change with the SDK you already use. What you leave behind is the config: no routing rules to write, no virtual keys to manage, and no provider accounts to hold, since Inferbase serves the models it routes to. Set model="auto" to route, or name a model to pin it.
On evidence, then on your objective. Each request is classified for its task family and complexity; the catalog is narrowed to the models that clear a quality bar for that task on benchmark evidence and that fit the request; the survivors are ranked on the objective you set (cost, balanced, quality or latency). A model with no measurement for the task is treated as unknown and does not qualify on guesswork.
Yes. Every routed request writes a decision record: the task the classifier saw, its complexity, the objective, how many models qualified, which won and how clearly, and each fallback attempt if any. When streaming it is the first event on the stream; afterwards it is retrievable by request id from the API and the dashboard.
One line. Point an existing OpenAI SDK at the Inferbase base URL and send model="auto"; chat completions, streaming, tool calls and structured output pass through unchanged, and Anthropic-shaped clients are served on the Messages endpoint. Name a model instead of auto and it is served as named, so an application can pin where it must and route where it can.
A free plan with no time limit and no card: 5,000 requests a month on any model and any key, with Inferbase's own models free for chat, embeddings and rerank within daily limits. Pro is $19 a month with 50,000 requests and no daily limits. Managed inference on Pro is billed at the provider's token price plus a flat 6%; on your own provider keys or cloud account the tokens are billed by your provider, with nothing added. Routed or pinned, a request counts the same.
Put intelligence in the middle.
One gateway in front of every model, with your policies applied and every decision on record. Start on the free plan with 5,000 requests a month, no card required.