Generic OpenAI-compatible clients

If a tool isn’t on this list, it almost certainly works as long as it exposes two settings: base URL and API key. The pattern below is what to fill in.

Settings to set

What does not work

• Tools that hard-code https://api.openai.com without a base-URL setting cannot be redirected. Some have a OPENAI_API_BASE environment variable that achieves the same thing.
• Tools that require a specific model ID format (e.g. gpt-4 with no provider prefix) need the model picker reconfigured to accept arbitrary strings — most have a “custom model name” field.
• Tools that send Anthropic-shaped requests on the OpenAI endpoint will be rejected. LowRouter accepts OpenAI-shaped chat-completions requests only — send those instead.

Confirming it works

Before integrating, test from the command line that the tool’s settings are right:

curl https://api.lowrouter.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"auto/mistralai/mistral-large-2512","messages":[{"role":"user","content":"hi"}]}'

If curl returns a completion, the tool will too — once it’s configured with the same URL and key.

Tools we know work without changes

• LangChain (OpenAI and ChatOpenAI classes — set openai_api_base and openai_api_key).
• LlamaIndex (OpenAI and OpenAILike LLMs).
• LiteLLM (proxy and library — set api_base and api_key).
• Vercel AI SDK (createOpenAI from @ai-sdk/openai-compatible).
• Continue.dev (provider: openai-aiohttp with apiBase).
• LM Studio (Server tab → custom backend).

When to prefer the OpenAI path over a tool’s native provider

If a tool has both an “OpenAI” and an “LowRouter / OpenRouter / custom gateway” option, prefer the OpenAI Compatible one. It exposes the fewest surprises: the tool sends a standard chat-completions request, LowRouter resolves the route, and the response is in the shape the tool already expects.