Smart Router

Send model grid-auto and Grid selects a capable lane for the request. It is opt in, per request, and it always tells you which model answered.

Hardcoding one model for all of your traffic makes every request pay the cost of your hardest request. Smart Router is the alternative: you describe the work and Grid selects a lane that can do it.

It is opt in. If you do not ask for it, nothing is routed.

Turning it on#

Set model to grid-auto. Everything else about the request is unchanged.

Python

resp = client.chat.completions.create(
    model="grid-auto",
    messages=[{"role": "user", "content": "Summarise this contract clause."}],
)

Shell

curl https://api.genai.forlex.cloud/v1/chat/completions \
  -H "Authorization: Bearer $FORLEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grid-auto",
    "messages": [{"role": "user", "content": "Summarise this contract clause."}]
  }'

It is a per-request decision, not an account setting. The same key can pin a model on one call and route on the next, which is what makes it safe to adopt gradually: route the traffic where you do not care which model answers, and pin the traffic where you do.

What it optimises for#

Smart Router reads the request, matches it against the curated catalog, and selects a lane capable of serving it. Where a safe semantic cache applies, it can serve from cache instead of running inference again.

The selection target is capability: the right lane for the work. Choosing a capable lane rather than always choosing the largest one is what tends to reduce cost, but capability is what is being optimised, and a request that needs a bigger model will get one.

The resolved model determines the token rate. Your account agreement specifies any routing charge and the applicable rate card. See Pricing and Billing.

Seeing which model answered#

Every routed response names the model that produced it:

Code

x-grid-routed-model: livia-e1-mini

This is the part that matters. A router you cannot inspect is a router you cannot debug, cannot audit, and cannot justify to whoever asks why an answer changed. The header is present on every call, so logging it next to your own request id is enough to reconstruct any response later.

The Console usage dashboard shows the same breakdown over time, by model, by run mode and by period, in tokens.

When to pin instead#

Pin a model when you need determinism or release control.

Routing means the model can differ between two identical requests, because the catalog and the router both change over time. That is the right trade for most traffic and the wrong trade for a regression suite, a benchmark, or an output your users have learned to expect.

Pinning is just naming the id:

Python

resp = client.chat.completions.create(
    model="livia-e1-mini",
    messages=[{"role": "user", "content": "Summarise this contract clause."}],
)

A pinned version does not move when the catalog changes. If you need both, route the bulk of your traffic and pin the paths you have committed to.

Connect#

Connect is how that same router shows up inside coding agents and IDEs. The engine is Smart Router. The product is Connect. Grid remains the factory. Connect is by invitation. It does not change the API contract on this page.