Presets

Calling one

A presetPresetA saved setup — a model, an instruction, and its settings — that you can call by name. It lets you change which model your app uses without touching the app. is a saved request configuration. You call it by putting its name where the model id goes.

{
  "model": "@preset/support-triage",
  "messages": [{"role": "user", "content": "My card was charged twice."}]
}

The point is that changing which model answers, or how the system prompt is worded, stops being a deploy. Someone can retune it at 2am from the dashboard without touching the application.

A preset can carry:

• the model id it resolves to, and a fallback chain;
• a system prompt, optionally templated;
• parameters: temperature, top_p, top_k, max_tokens, max_completion_tokens, stop, frequency_penalty, presence_penalty, seed, response_format and provider. Anything else it might have stored is ignored at call time.

The merge rule

This is checked by presence, not by value: a caller who explicitly sent temperature: null has expressed a preference, and the preset does not second-guess it. A system prompt is prepended to your messages, and only when you did not send a system message of your own — an application that sends one means it.

Versions and pinning

Unpinned means the current version, which is the reason the feature exists. Suffix a number to freeze it:

{ "model": "@preset/support-triage@3", "messages": [ … ] }

Pinning is for the caller who cannot have a prompt changed underneath them between now and their next release — a job that must produce comparable output across a week, or a comparison being run against a predecessor. An unknown version is an error that lists the versions that do exist, rather than quietly serving the current one.

Variables

A preset’s system prompt can declare named variables, written {{name}} in the template and supplied per request:

{
  "model": "@preset/support-triage",
  "variables": { "tone": "formal", "product": "Multigrid" },
  "messages": [{"role": "user", "content": "My card was charged twice."}]
}

variables is ours and is removed before the request reaches a provider — in two places, because for a while it was removed in only one: the preset resolver strips it, and so does the adapter, so sending variables alongside an ordinary model id rather than an @preset/… reference no longer forwards a field we invented to a provider that will reject it. Rendering only happens when the preset’s system prompt is actually going to be used, so a caller who supplied their own system message is never asked for the variables of a template nothing will read. A missing required variable is a 400 naming the preset and the variable, not a prompt with a hole in it.