Skip to content
Router One

Configure LlamaIndex OpenAILike for Router One

LlamaIndex is the data framework for RAG and agents over your own documents, and a single query can fan out into many LLM calls — answer synthesis, sub-questions, reranking, agent steps. Its OpenAILike class talks to any OpenAI-compatible endpoint, so one configuration pointed at Router One reaches GPT, Claude, Gemini, and Grok family models by changing the model string — and every one of those calls gets a per-request cost trace on the gateway, without adding callbacks.

Configure LlamaIndex to use the Router One base URL

Install llama-index-llms-openai-like and build an OpenAILike with the gateway base URL, your key, and the exact ID of a model supporting Chat Completions. Set is_chat_model to True and context_window to the value on that model's detail page. The text example keeps is_function_calling_model=False; set it to True only after verifying tool support for your chosen model and endpoint. Assign the instance to Settings.llm or pass it to an index or query engine:

llamaindex-router-one.py
# pip install llama-index llama-index-llms-openai-like
from llama_index.core import Settings
from llama_index.llms.openai_like import OpenAILike

Settings.llm = OpenAILike(
    model="<model-id-from-/models>",
    api_base="https://api.router.one/v1",
    api_key="sk-your-router-one-key",
    is_chat_model=True,
    is_function_calling_model=False,  # enable only after checking tool support
    context_window=200000,  # copy the window shown on /models
)

print(Settings.llm.complete("Hello!"))

Which model ID should LlamaIndex send?

Copy the exact model ID from /models, preserving case, hyphens, and version suffixes; do not substitute a display name. Open its detail page and match the supported API endpoints, context window, and capabilities such as tool calling to the provider and features selected in LlamaIndex. A catalog listing does not mean the client can use every feature of that model. Give each tool a dedicated API key with a maxSpend cap.

Which API protocol is LlamaIndex using?

OpenAI-compatible describes an interface format; it does not make Chat Completions (/v1/chat/completions), Responses (/v1/responses), and Anthropic Messages (/v1/messages) interchangeable. Check the installed client version, provider configuration, and actual request path against the model detail page and API compatibility fact sheet. A successful plain-text chat does not establish support for hosted tools, conversation state, or file-editing features.

Verify the LlamaIndex call in your request trace

Send a simple text request from LlamaIndex, then match its trace in Dashboard → Logs by time, model, and request_id: tokens, cost, latency, and status. Next, test streaming, tool calls, and multi-turn history separately. For failures, retain the actual request path, full error message, and request_id. If there is no matching log, check client configuration and connectivity before attributing the error to the gateway or upstream.

FAQ

Why OpenAILike instead of the OpenAI class with api_base?

Because the plain OpenAI class checks the model name against OpenAI's own model list to infer its context size, and raises ValueError: Unknown model for anything else — including every non-GPT catalog ID — as soon as it needs that metadata. OpenAILike is the documented route for OpenAI-compatible endpoints: it skips the lookup and takes the model's metadata from the arguments you pass, which is why is_chat_model and context_window are set explicitly.

Is there a TypeScript equivalent?

Yes. In LlamaIndex.TS the OpenAI class from @llamaindex/openai takes baseURL and apiKey in its constructor — new OpenAI({ model, apiKey, baseURL }) with the gateway URL — or reads OPENAI_BASE_URL and OPENAI_API_KEY from the environment. Assign it to Settings.llm and the same model-string switching applies.

Which models can LlamaIndex use through the gateway?

Choose a current catalog model that supports both the endpoint and the features LlamaIndex uses. Check /models and the model detail page for the exact ID, current rates, and capabilities; a family name such as GPT or Claude is not a compatibility guarantee. Seeing a model in the picker confirms discovery, so verify an actual request too.

Models are listed, but requests fail with 400 or 404. What should I check?

Record the actual request path and error message, then check the exact model ID. A 400 can indicate invalid parameters, unsupported tools, or a model/endpoint mismatch; a 404 can indicate an incorrect path or missing resource, so it does not by itself establish that a model was retired. If the error says must be called via, use the named endpoint or select a model supported on the current endpoint. Do not add or remove /v1 or /chat/completions across all clients indiscriminately.

Does this work from Mainland China?

Yes. The gateway is reachable from Mainland China without a VPN, and the configuration is identical to the global setup.

How do I debug a 401/402/403/429?

Match the request and error message in Dashboard → Logs. For 401, check whether the key was sent and is valid; for 402, check wallet balance and maxSpend; for 403, check key permissions and access restrictions. For 429, distinguish request/token limits from upstream throttling using the error details. Keep the request_id and follow the error-codes reference.