OpenAI compatibility
Grid speaks the OpenAI protocol so your existing client works. This page says what is covered today, so you can check before you depend on it.
Compatibility is a floor, not a feature. It is here so that moving to Grid costs you two lines rather than a rewrite, and so that leaving would cost you the same. What Grid asks you to evaluate is portability, routing and the meter, not the shape of the request body.
Using the OpenAI SDKs#
Set the base URL and use the client you already have. Authentication is a bearer token in
the standard Authorization header, so nothing about the auth flow changes.
import os
import openai
client = openai.OpenAI(
base_url="https://api.genai.forlex.cloud/v1",
api_key=os.environ["FORLEX_API_KEY"],
)
import OpenAI from 'openai'
const client = new OpenAI({
baseURL: 'https://api.genai.forlex.cloud/v1',
apiKey: process.env.FORLEX_API_KEY,
})
If you prefer environment variables, OPENAI_BASE_URL and OPENAI_API_KEY work as they
normally do, which lets you point an existing application at Grid without touching its
code at all.
Endpoints#
| Endpoint | Status |
|---|---|
POST /v1/chat/completions | Supported |
GET /v1/models | Supported |
GET /v1/models/{model} | Not available yet |
POST /v1/completions | Not confirmed |
POST /v1/embeddings | Not confirmed |
POST /v1/batches | Not available. Grid Batch is a separate surface, see Run modes |
GET /v1/models returns the OpenAI list envelope, so SDK helpers that enumerate models
work unchanged:
{
"object": "list",
"data": [
{ "id": "livia-e1-flash", "object": "model", "created": 1700000000, "owned_by": "Forlex" },
{ "id": "livia-e1-mini", "object": "model", "created": 1700000000, "owned_by": "Forlex" }
]
}
The list is the authority on what you can call. Prefer reading it at runtime over hardcoding a model id, both because the catalog is curated and because it is the one source that cannot be out of date.
Parameters on chat completions#
| Parameter | Status |
|---|---|
model | Supported. A catalog id, or grid-auto for Smart Router |
messages | Supported |
stream | Supported |
tools, tool_choice | Supported |
logprobs, top_logprobs | Not available yet |
Parameters not listed here are not documented as working. That is a statement about what we have verified, not a statement that they fail. If you need one confirmed before you build on it, ask and we will answer specifically rather than generally.
Where Grid differs#
Two differences are worth knowing before you write error handling.
Authentication failures return a plain text body. A request with a missing or invalid
key answers 401 with content-type: text/plain, not the JSON {"error": {...}} envelope
the OpenAI SDKs expect. The SDKs will surface the status code correctly but may not parse it
into a typed error object. If your code branches on a parsed error body, handle the status
code as well.
Serverless can answer 503 on a cold lane. The OpenAI API does not scale to zero, so
this is a state your existing retry logic may not cover. See
Errors and cold start.
Response headers#
Grid adds x-grid-routed-model, naming the model that produced the response. It is present
whether or not you used routing, which makes it the single thing to log if you want to be
able to reconstruct an answer later.