Concepts

Forward Intelligence and Grid#

Forward Intelligence operates a high-performance AI factory. Grid is how you call it: serve, route, fine-tune.

You buy Forward Intelligence and you operate Grid. Where these docs say "the Console" they mean the Forward Intelligence console, and where they say "the API" they mean Grid.

Forlex Labs is the third name you will see. It covers models, fine-tuning, evaluations and the programmes around them. It is not a nav product. Training is three paths (custom, API, managed), runs as jobs rather than requests, and is not billed the same way, so these docs keep it separate. It is arriving by invitation: the training page is where methods, waitlist, and custom quotes live.

Connect is how Grid shows up inside coding harnesses. Smart Router is the engine inside it. Connect is not a second factory.

Model portability#

Model portability is the property that a change of model is not a change of integration.

In practice it means three things. You can call any model in your catalog by id through the same endpoint. You can pin a version so it does not move under you. And you can move a workload between run modes without rewriting the call.

It is the reason Grid speaks the OpenAI protocol rather than a protocol of its own. A protocol you already have is one you can leave, and that is what makes staying a choice.

Run mode#

A run mode is how capacity is provided for a request. Grid has four: Serverless, Batch, Dedicated and Private. They differ in how capacity is allocated and committed, not in the API you call.

Run modes covers each.

Lane#

A lane is a specific model on specific capacity, ready to serve. One model can have more than one lane, and two lanes for the same model can differ in the run mode behind them.

The word matters mainly when reading about routing: Smart Router selects a lane, not just a model, which is why the response tells you which model actually answered.

Pinning#

Pinning means naming a model id in the request instead of letting Grid choose. It is the default: if you do not ask for routing, nothing is routed.

Pin when you need deterministic behaviour or release control. A pinned version does not change when the catalog does.

The meter#

Tokens measure inference traffic across Serverless, Batch, Dedicated and Private. Serverless and Batch price those token meters. Dedicated and Private can bill GPU-hours or a contractual capacity commitment; the proposal states whether model usage is included or additional.

Compare the total cost of the workload using its traffic, capacity commitment and included resources. Invoices settle in the currency on your contract. Pricing shows the published references, and Billing and metering explains the units.

Cold start#

Serverless scales to zero. A lane with no traffic releases its capacity, and the next request has to wait for it to come back.

Grid reports this as 503 with a Retry-After header rather than queueing your request indefinitely, so your client decides how long it is willing to wait.

This is a documented state, not an error in your code. Any client that talks to Grid Serverless needs retry with backoff. Errors and cold start explains the handling.

Resolved model#

The resolved model is the model that actually produced a response.

When you pin, it is the id you asked for. When you use Smart Router, it is whatever the router selected, and it comes back in the x-grid-routed-model response header on every call. Log it next to your own request id and you can reconstruct any answer later.