Inferbase is a control plane for AI models. Your application sends requests to one OpenAI-compatible API. Inferbase checks each request against the rules you set, selects a model for it, sends it to that model, and records what happened so you can review it.
Read it as a path. A request from your application enters the gateway. Security decides what the request may do. Routing chooses a model from the pool the policy allows, using the catalog's evidence. The gateway serves the request to a managed model or to one on your own provider keys. Observability records the decision, the usage, and anything worth telling you about.
The four capabilities
Everything Inferbase does falls under one of four capabilities. The portal's sidebar and this documentation are organized the same way.
| Capability | What it gives you |
|---|---|
| Catalog | Knowledge about models: capabilities, context windows, prices per provider, and benchmark evidence per kind of task. The public catalog and the GPU tools need no account. Routing uses the same data. |
| Routing | A model choice for every request, made from the pool your policy allows, using the objective you set: cost, quality, latency, or balanced. Every choice is explainable and on record. |
| Security | Control over what a key may do. Routing policies decide which models can serve and how. Guardrail policies inspect prompts, responses, and tool results, and record or refuse what fails. Tool governance decides which tools an agent may declare and call. Roles, budgets, and enforced organization defaults hold it together. |
| Observability | A record of what happened: the routing decision for each request, usage and spend by project and key, logs with latency and status, agent runs with their tool calls, events for budgets and balance, and an audit log. |
These four sit behind one gateway: a single endpoint that accepts OpenAI-shaped requests, serves them to managed models or to models on your own provider keys, and meters the result. Existing OpenAI SDKs work when pointed at the Inferbase base URL. Anthropic SDKs work against the Messages endpoint.
Who this is for
- Developers who call language models from an application and want one endpoint, one key, and a model choice they can explain.
- Teams and enterprises that need rules about which models can be used, what content is inspected, and which tools an agent may call, applied to every key and visible in one place.
- Anyone comparing models or planning self-hosted capacity, who can use the catalog and the GPU tools without signing up.
How the documentation is organized
The sections follow the portal's sidebar, so the structure you learn here is the structure you use in the product.
| Section | Covers |
|---|---|
| Getting started | Your first request, a tour of every part of the portal, the terms used throughout, and the Playground. |
| Concepts | How routing chooses, and how to read a routing decision. |
| Gateway | API keys, connections to your own provider accounts and MCP servers, projects and budgets, and client compatibility. |
| Policies | Routing policies, guardrail policies, and tool governance, each with a step-by-step guide. |
| Observability | Usage, logs, agent runs and tools, events, and the audit log. |
| Organization and account | Roles and members, billing, security and privacy policies, notifications, and your own account. |
| Catalog and tools | The model catalog, comparison, the recommender, and the GPU tools. |
| API reference | Every endpoint, request field, response field, and error. |
Conventions used in these pages
- Portal means the web application at inferbase.ai after you sign in.
- API means the HTTP endpoints under
api.inferbase.ai. - Paths in the portal are written as they appear in the sidebar, for example Policies › Routing.
- Code samples use
inf_your_api_keywhere your key goes.
Last updated September 10, 2026.