How to Switch to an OpenAI-Compatible API: 3 Things to Change, 4 Things to Test

Which 3 settings do you change?

Checked 2026-11-03. Everything else in your request, such as messages, tools, and temperature, normally stays the same.

What does the code change look like?

This is the Python example from the LanoX homepage, copied as published on 2026-11-03. Only 2 lines differ from a standard OpenAI client: base_url and api_key. The model ID is whatever your account lists.

from openai import OpenAI

client = OpenAI(
  base_url="https://api.lanox.ai/v1",  # Change this line
  api_key="<LANOX_API_KEY>",
)

response = client.chat.completions.create(
  model="gpt-5.6-sol",
  messages=[{"role": "user", "content": "Hello"}],
)

print(response.choices[0].message.content)

The homepage adds: "Point the Base URL to LanoX, add your API Key, and keep the OpenAI-compatible request structure." In real code, read the key from an environment variable and never commit it.

Which API format is your project using?

"OpenAI-compatible" can mean more than 1 format. Find out which one your code calls before you switch, because a gateway may support some and not others.

The docs state: "Text supports OpenAI Compatible and Claude Messages."

On native versus compatible, the docs FAQ says: "A model's native API is defined by its provider and may include provider-specific features and parameters. A compatible API matches the request and response format expected by existing clients, making those clients easier to reuse. Support for streaming, tool calls, structured output, and multimodal inputs can differ, so check each feature your application needs." (checked 2026-11-03)

Does the base URL include /v1?

It depends on the client, and getting it wrong is 1 of the most common setup errors. On LanoX (checked 2026-11-03):

Follow the linked guides for step-by-step client setup. This article covers what to check, not configuration screens.

How do you get the exact model ID?

Call GET /v1/models with your key before you write a model ID into code. The docs say it "Lists the models available to the current API key" and "The response is filtered by API-key permissions and is not wrapped in a data/code/codeMsg business envelope." (checked 2026-11-03). The docs list 13 response parameters, including these:

The docs' example response shows rpm_limit 60 and tpm_limit 100000. Those are sample values, not limits we promise, so read the response for your own key. Check supported_endpoint_types for each model; do not assume every model accepts every format. Use the model catalog for prices; on 2026-11-03 it listed 58 text models.

What should a first test request look like?

The docs publish this Chat Completions request with a tool definition (copied as published on 2026-11-03; set API_KEY in your shell first):

curl -X POST "https://api.lanox.ai/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "messages": [{"role": "user", "content": [{"type": "text", "text": "Check the weather in Shanghai"}]}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Look up the weather for a city",
        "parameters": {
          "type": "object",
          "properties": {"city": {"type": "string"}},
          "required": ["city"],
          "additionalProperties": false
        },
        "strict": true
      }
    }],
    "tool_choice": "auto",
    "temperature": 0.2,
    "max_completion_tokens": 300,
    "stream": false
  }'

It caps output at 300 tokens, so a test call stays small.

Which 4 features must you test after switching?

Test each one your app actually uses, on the exact model ID you will run in production. We do not publish a per-model feature table, so the test is the answer.

Also confirm 2 records for each test call: the model reported in the response matches the one you requested, and the usage and charge in the console match what you sent. The docs list 4 things to check in the console: "the requested model, actual result, usage record, and final charge."

Who is this switch not a good fit for?

• Projects built on a provider's native SDK. The docs list 2 text formats, OpenAI Compatible and Claude Messages; other native formats would need code changes, not 3 settings.
• Apps that depend on provider-specific parameters. The docs FAQ says native APIs may include features a compatible API does not.
• Teams that need a published feature matrix before testing. We could not find 1 to cite on 2026-11-03; you have to test the 4 features yourself.
• Production systems with no room for a test run. Switch a staging environment first.