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. Use the Anthropic SDK base URL instead.

Confirming it works

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

curl https://lowrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"lowrouter/auto","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.