Answer the docs. Read the bill.
Documentation answered with a citation, coding agents routed step by step, and every call on record with the model that served it and what it cost.
The same question, the hundredth time
The answer is on page four of the docs.
It arrives in the support queue anyway, every day.
The agent ran for an hour on the strongest model.
Most of its steps were reading files.
The model provider's invoice doubled.
Nobody can say which feature spent it.
The work is uneven.The bill should be too.
The situations, and the guide that builds each
Every one is a build guide: the architecture, the policy, the code that was run, and what was measured.
Documentation questions, answered with a citation
A chat on your docs that answers from your own pages with the passage it used and hands off to a person when it should. The guide is the design our own site runs as Ask Copilot.
Build guide: Customer support assistant
Coding agents that route every step
A loop where the plan asks for quality and the tool steps ask for latency, inside a pool of tool-capable models, with every run on record and capped per session.
Build guide: Coding agents
Questions over code, runbooks and tickets
Retrieval over your internal knowledge with the generation call routed per question and the context sized to what retrieval returned. Keep your search; route the answer.
Build guide: RAG over a knowledge base
Agents with a governed tool surface
The tools an agent may call are an allow-list in a policy, MCP servers are declared, and writes wait for a person. Your client calls the tools, or Inferbase calls the declared servers.
Build guide: Agents with tools and MCP
Order forms and contracts into your systems
Customer documents into fields that match your schema, with idempotent retries and a review queue for what validation rejects.
Build guide: Document extraction to JSONWhat changes for software and developer tools
Documentation that answers the same questions daily, agents that edit code, and a bill that should follow the work rather than the hardest request.
The bill follows the work
A docs lookup goes to a small fast model and a plan to a strong one, decided per request. The response says which model answered and what it cost, so spend is read per feature from receipts.
One API, the SDK you have
OpenAI and Anthropic SDKs, the Responses API and the Agents SDK work with the base URL changed. Your code sends model auto; the policy decides the rest.
Agents are bounded
Tool allow-lists, declared MCP servers and caps on requests and spend per session end a loop that does not end itself, and every run is on record with its tool calls.
Every decision is readable
The routing event names the task, the model and its margin, and the request id reads back the eligible pool and the fallback chain. Debugging a bad answer starts with a record.
Figures with a source
Every number here was measured by us and says when. Where nothing was measured, nothing is claimed.
| Support evaluation on our own documentation | 31 of 31 cases | The quickstart's own run, 2026-10-09 |
| One support answer from a documentation passage, verified call | $0.000011 | Customer support assistant guide, run against the API on 2026-10-13 |
| A short coding-agent loop, plan plus tool steps | about 60 s | Coding agents guide, run against the API on 2026-10-13 |
| Time to decide (classify and rank), live traffic | p50 18 to 31 ms | Gateway classifier timer, 2026-10-13 |
Questions from software and developer tools teams
Yes. It retrieves passages from your published docs and the prompt confines the answer to them, with a citation to the passage used. Off-topic questions are refused in one sentence, and an evaluation holds it to that after every change.
Through the routing object on each request: the plan sends optimize quality and the tool steps send optimize latency. Both narrow the policy for that call only, and the pool holds only models whose tool support is confirmed.
The policy's caps on requests and spend per session. A run that reaches the request cap gets a 429 and one that reaches the spend cap a 402, and the orchestration reads either as its stop.
The OpenAI and Anthropic SDKs, the Responses API used by the OpenAI Agents SDK, and frameworks that take an OpenAI-compatible base URL all work with the URL changed. Inferbase's routing and usage events arrive as extra chunks clients skip.
Each request can carry a source tag and a session id, and the response carries its cost in micro-dollars. Usage groups by both, so spend is read per feature and per agent run.
The ones in the policy's allow-list. Start with any tool and read what the agent sends, run the list in dry run, then enforce it; a tool outside the list is refused before any model is chosen.
Yes. Connect them under Connections and build the policy pool from them, from managed models, or both. The code does not change; the policy decides whose credential serves each call.
The routing decision takes tens of milliseconds. A streamed answer's first token arrived in 1.5 to 3.5 seconds under the latency objective on 2026-10-14; agents are measured in minutes per task, because each step waits on a model.
Whichever models in your policy pool win on the objective for each request. Add a model and it joins the next request; pin one for a step that must not change. The response always names the model that served.
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.