Skip to content

Point a context at a role, or pin it to a model

PUT
/api/v1/config/router/contexts/{id}
curl --request PUT \
--url http://localhost:11044/api/v1/config/router/contexts/example \
--header 'Content-Type: application/json' \
--header 'X-Embabel-Api-Key: <X-Embabel-Api-Key>' \
--data '{ "model": "example", "role": "example" }'

Send role or model, not both. Send neither to return the context to the deployment default; its reasoning effort is kept.

id
required
string

A context id, as GET /config/router lists it

Replaces the context’s setting in this world’s config. Send role (a role id from GET /config/router) or model (one of the chat models it lists), trimmed, not both; either keeps the context’s temperature and reasoning effort. Send neither, or both blank, to return the context to the deployment default, keeping only its reasoning effort. Both at once, or an unknown role or model, answers 400

Media typeapplication/json

Body of PUT /config/router/contexts/{id}: a role or a model for the context, not both; neither returns it to the deployment default

object
model

The model the context is pinned to

string
role

The role the context uses

string

Example generated

{
"model": "example",
"role": "example"
}

Changed; takes effect on the next request

Media type*/*

The change was applied and the world’s config saved; it takes effect on the next request

object
ok
required

Always true. A client that only branches on the status code can ignore it; one that reads the body does not have to special-case the shape

boolean

Unknown context, role or model

Media type*/*

The change was refused and nothing was saved. The status code says which kind of refusal: 400 for something unknown or invalid, 409 while a context still uses the role

object
detail
required

Why it was refused, written to be shown. Carries the router’s own sentence, which names the context, role or model at fault

string
ok
required

Always false

boolean