OpenAI compatibility

​

Two-line migration

from openai import OpenAI

client = OpenAI(
    base_url="https://api.runinfra.ai/v1",   # <- change
    api_key="YOUR_RUNINFRA_API_KEY",           # <- change
)

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

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.runinfra.ai/v1",   // <- change
  apiKey: "YOUR_RUNINFRA_API_KEY",          // <- change
});

const response = await client.chat.completions.create({
  model: "your-model-id",
  messages: [{ role: "user", content: "Hello" }],
});

curl https://api.runinfra.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_RUNINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model-id","messages":[{"role":"user","content":"Hello"}]}'

​

Endpoints supported today

​

What to change in your code

​

Response parity

• Chat completions return id, object, created, model, choices[], usage.
• Responses return OpenAI-shaped response events and non-streaming JSON for the supported adapter fields.
• Streaming deltas match OpenAI’s SSE format, terminated by data: [DONE].
• Image generation returns OpenAI-shaped image data for verified image deployments.
• Tool calls return tool_calls on the assistant message with function.name / function.arguments.
• Structured output accepts response_format: { type: "json_object" } and response_format: { type: "json_schema", json_schema: {...} }.
• Usage metadata follows the endpoint shape: token usage for LLMs, embedding counts for vector calls, and modality-native units for image and audio routes.

​

Verified libraries and clients

​

Known differences

• OpenAI model names (gpt-4o, gpt-4.1-mini) don’t alias to RunInfra models. Pass the model id your deployment serves.
• /v1/responses is a chat-completions compatibility adapter. It does not implement state, include, reasoning, hosted tools, conversation-item, or background-job semantics.
• Model-specific sampling parameters (logit_bias, logprobs, seed determinism) depend on the serving backend behind your deployment.

​

Unsupported parameters

​

Error code mapping

​

Fallback behavior

• Numeric out-of-range (e.g. top_p=1.5): clamped to the legal range, logged in the backend response header X-Param-Adjustments.
• Unsupported feature (e.g. logit_bias on a backend that does not support it): the parameter may be ignored by the serving backend, and X-Param-Adjustments lists what was dropped when the gateway can detect it.
• Unsupported model capability (e.g. tool calling on a non-instruction-tuned model): returns 400 invalid_request_error with a message naming the missing capability.

​

Next steps