“model”: “auto”, MKA1 applies the
organization’s auto policy for that endpoint.
By default, auto is a direct alias to a model in the model
registry. Organizations can also configure an LLM judge to select from an
approved set of models. The judge is given signals about the request, the
available models, and the existing conversation so it can choose the model
best suited to the work.
Supported endpoints
Judge-based selection is available for several types of AI request.
Only models suited to the request type are considered. For example, a TTS
model cannot be selected for a Responses request.
How model selection works
The organization defines the models that may be selected. Models that are no longer available are excluded automatically. If only one suitable model remains, MKA1 selects it directly; when several are available, the configured judge chooses among them. If no suitable model remains, or if the configured judge is unavailable, MKA1 returns a transparent error instead of silently changing the policy.Signals used for model selection
MKA1 gives the judge a consistent view of the factors that matter for the current request:- Request and tools: the nature of the task, available tools, requested output, and whether images, audio, or files are present. Models that can work with the original input directly are preferred.
- Model capabilities: supported modalities and file types, available context, and other requirements needed to complete the request.
- Price: comparative model pricing.
- Latency: rolling latency estimates measured by the gateway.
- Evals: relevant evaluations and benchmark results for the available models.
- Conversation continuity: whether staying with the previously selected model can preserve context and reduce cost and latency, including through KV-cache awareness.
balancedconsiders quality, price, speed, capabilities, and conversation continuity together.priceprioritizes the lowest expected cost among models suited to the request.qualityprioritizes task fit and relevant evaluation results.speedprioritizes responsiveness using rolling latency and reliability signals.
Privacy and safety
The judge receives a bounded, sanitized summary of the request and its tool requirements. Credentials and raw binary content are not forwarded. The organization’s normal safety policies still apply, and the judge can select only from models the organization has approved for the policy.Inspect the current policy
The auto endpoints are organization admin operations: the API key needs theread:registry scope to list overrides and
write:registry to change them. Each override’s
mode is either direct or the judge policy name, so
read that field first to know which other fields are present.
Configure an LLM judge
The following example enables judge-based model selection for LLM requests using thebalanced policy. Set policy to
price, quality, or speed to emphasize a
different goal. The judge and every candidate must be valid LLM model
identifiers available to the organization. Model availability is organization-specific;
replace the example IDs with IDs returned by GET /models for your
organization.
mode, plus which of
the configured models currently resolve:
meetkai:functionary-pt, while a request in
Latin American Spanish can route to meetkai:functionary-es-419.
You can configure responses, completions,
transcriptions, and tts independently. Endpoints
without an organization override retain direct model-registry alias routing.
Validate the selected model
Make a normal request using“model”: “auto”:
model field and
names the model that actually served the request in
resolved_model. With a direct policy, that is the registry alias
target. With an LLM judge configured, it is the approved candidate selected
for the request.
Restore direct routing
Set a direct policy explicitly:“model”: “auto” falls through to
the cluster default again: