Model Presets
A preset saves a model together with its system prompt and generation settings. Call it by name instead of repeating them in every request:Where presets work
Create a preset
In the dashboard
Open the Presets page and choose Create preset. Names can’t be empty or contain/ or \.
With the Management API
Create a Management API token withmodel_presets:write, which also allows reading, or model_presets:read for read-only access. Inference API keys can’t manage presets.
Rules for this API:
- Names use letters, digits, hyphens and underscores, start with a letter or digit, and are at most 80 characters.
PUTreplaces the whole preset, so any field you leave out resets tonull.- You can create up to 100 presets this way, and each request body can be up to 16 KiB.
- These presets show as read-only on the Presets page. A name already used by a dashboard preset can’t be overwritten.
Fields
Provider objects, BYOK credentials and fallback model lists can’t be saved in a preset. Whether a model supports a given setting is checked when you make the request.
How a preset combines with your request
Preset values are defaults, and fields you send in the request win:- A field sent as
nullcounts as not sent, so the preset value applies. - Sending
max_tokens,max_completion_tokensormax_output_tokensreplaces the preset’s output limit. thinkingobjects are merged, and your keys win.- Provider or routing choices in your request win over the preset’s routing preference.
On
/v1/chat/completions, a system message doesn’t remove the preset’s system prompt, and on /v1/responses neither do instructions. On some routes the preset’s prompt can take the place of your own, so use a preset without a system prompt if you need full control.
Presets are defaults, not a security control. Existing key, team and privacy restrictions still apply.