Models

The catalog is curated rather than exhaustive. List it at runtime, call a model by id, and bring your own weights when the catalog does not have what you need.

Grid curates models around the workload you want to run. The public inference catalog compares model families, capabilities, indicative rates and training candidates. Entries marked By request need deployment scoping. Soon entries are awaiting launch. Your account model list confirms what you can call today.

The OpenDetector detection catalog has a separate evaluation path for AI-text, prompt injection and jailbreak signals. See Detection for its serving contract. These entries are not chat-completion IDs or automatic routing checks.

The S Series is what we trained first. Public models and your own weights can join your account catalog after serving configuration and access are confirmed.

That is also why these docs do not print a model table. The list you can call depends on your account and changes as we open the invite, so the only answer that is correct for you is the one the API gives you.

Listing the catalog#

Shell

curl https://api.genai.forlex.cloud/v1/models \
  -H "Authorization: Bearer $FORLEX_API_KEY"

JSON

{
  "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 response is the OpenAI list envelope, so any SDK helper that enumerates models works against it unchanged. id is what you pass as model on a request.

Read this at startup rather than hardcoding an id. It costs one call and it is the difference between noticing a catalog change and being surprised by one.

Model origins#

There are three ways a model gets into your catalog, and portability means all three are called the same way.

S Series. Models we publish and serve, named LIVIA Sx. The catalog lists the current generation. This page does not invent Grid ids.

Open weights. Open models we run on Grid capacity. You get them without operating the inference yourself, and you can leave with your integration intact because the id is the only Grid-specific thing about the call.

Your own. Register your own weights or a LoRA adapter and it joins your catalog, callable by id like anything else and eligible for Smart Router if you want it in the mix. A training job produces the same kind of id. Teams with isolation or residency requirements usually run these on Grid Private.

Pinning and change#

A model id in a request is a pin. It is the default, and it is the right default when you need the same input to keep producing comparable output.

What we will not do is move a pinned version under you silently. What we have not published yet is the deprecation policy: the notice period, the migration path, and how long a retiring lane stays callable. That policy is being written, and until it exists we are not going to describe one here. If you are building something that depends on a model staying available for a defined window, raise it with us and we will answer for your specific case rather than in general.

What is not in these docs yet#

Being explicit about the gaps is more useful than filling them with plausible numbers.

Context windows as served. A model's published window is not necessarily the window a Grid lane is configured for. We are not going to quote one until they are confirmed to match.
Per-model rates. Indicative new-account references are on Pricing. Model and serving configuration are confirmed during onboarding. New model listings need availability scoping; existing account agreements retain their effective rates. See Billing and metering.
Rate limits. No published per-key limits yet.