Presets

Copying the same model, system prompt, and sampling parameters into every request is error-prone — one drifted temperature or a stale system prompt and your evals no longer reproduce. Presets bundle a default model, system prompt, sampling parameters, and optional routing rules into a named configuration you reference from any request, so the important settings live in one place instead of scattered across your codebase.

Overview

Create a preset once, then reference it in the model field with either the classic @preset/<slug> syntax or the branch-based @presets/<slug> syntax. The preset's config is merged into each request that names it.

# Use a preset directly
curl https://anyrouter.dev/api/v1/chat/completions \
  -H "Authorization: Bearer sk-ar-your-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "@preset/code-reviewer",
    "messages": [{"role": "user", "content": "Review this code: ..."}]
  }'

# Override the model while keeping the rest of the preset config
curl https://anyrouter.dev/api/v1/chat/completions \
  -H "Authorization: Bearer sk-ar-your-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.4-mini@preset/code-reviewer",
    "messages": [{"role": "user", "content": "Review this code: ..."}]
  }'

How it works

Preset config fields

Each preset has a slug, name, optional description, and a config object with these fields:

Merging behavior

When a request uses a preset, the preset's config is merged with the request:

• Request fields override preset defaults — any field in the request replaces the preset value. provider.min_context takes the stricter (higher) floor, and require_params lists are unioned.
• Model resolution — if the request uses <model>@preset/<slug>, that model wins; otherwise the preset's first model is used.
• System prompt — prepended to messages only when the request has no existing system message.
• anyrouter/auto — when the preset's model is anyrouter/auto, the stored provider floors (exacto, tools, minimum context) apply at member-pick time.

Reasoning controls on built-in routes

anyrouter/auto, anyrouter/free, anyrouter/cowork, anyrouter/hermes, and anyrouter/latest resolve to concrete catalog models at request time. A reasoning control is applied to each resolved route, not to a made-up preset-wide model:

• reasoning_effort is the flat Chat-style field. Responses uses nested reasoning.effort, with reasoning.enabled: false as its endpoint-specific disable form. For flat Chat and converted Messages, none is a disable sentinel and is never clamped. Messages uses thinking.type; a non-native conversion maps enabled to high and disabled to none, while native Anthropic routes keep the Messages body.
• The selected route's reasoning.levels / default (or its per-upstream override) determines the exact flat value sent upstream. An effort outside that set is clamped to the nearest lower supported level, or the model default for an unknown token. An omitted effort stays omitted; default is a clamp fallback, not automatic injection.
• Fallback branches are clamped independently. A route that cannot serve the request may fail or fall through according to the normal upstream policy; it does not inherit another branch's effort list.
• Preset-level require_params is a hard candidate constraint where preset candidate selection is used. Preset, key, and request provider lists are unioned at the preference layer, but provider/key requirements are not a universal hard filter on every concrete dispatch; built-in virtual resolution uses tool-related entries (and request tools) to select tool-capable members. provider.require_parameters is the separate strict request-parameter switch. min_context takes the stricter value, key ignore is unioned, and key/request only lists intersect. If no supported_parameters list is declared, the current router is permissive rather than claiming universal support. The selected route's per-upstream list is the authority; no universal toggle, budget, or interleaved-thinking capability is inferred for a preset.

Fallback with multiple models

Add multiple models to a preset for automatic fallback. The first is primary; if it fails, the router tries the next:

{
  "models": ["anthropic/claude-sonnet-4.6", "openai/gpt-5.4-mini"],
  "temperature": 0.2
}

If anthropic/claude-sonnet-4.6 is unavailable, AnyRouter automatically falls through to openai/gpt-5.4-mini.

BYOK routes

For providers you use through BYOK, a preset can pin a branch to a specific upstream. Reference these with @presets/<slug> — the selected branch keeps model and upstream together, so a BYOK branch tries your key's upstream instead of first trying managed providers for the same model.

Route z-ai/glm-4.7-flash through your Z-AI Standard API key pool:

{
  "version": 2,
  "kind": "chat",
  "mode": "fallback",
  "paid_fallback": false,
  "branches": [
    {
      "id": "br_zai_glm_byok",
      "weight": 100,
      "priority": 1,
      "route": {
        "model_id": "z-ai/glm-4.7-flash",
        "upstream_id": "zai"
      }
    }
  ]
}

For a Z-AI Coding Plan key, use the same model id with upstream_id: "zai_coding":

{
  "version": 2,
  "kind": "chat",
  "mode": "fallback",
  "paid_fallback": false,
  "branches": [
    {
      "id": "br_zai_glm_coding_byok",
      "weight": 100,
      "priority": 1,
      "route": {
        "model_id": "z-ai/glm-4.7-flash",
        "upstream_id": "zai_coding"
      }
    }
  ]
}

To route a model through your OpenRouter account, first save an OpenRouter key in Dashboard → BYOK. Then create or edit a preset, choose the model, select OpenRouter in BYOK route, enable the route, optionally enable paid fallback, and save:

{
  "version": 2,
  "kind": "chat",
  "mode": "fallback",
  "paid_fallback": false,
  "branches": [
    {
      "id": "br_openrouter_byok",
      "weight": 100,
      "priority": 1,
      "route": {
        "model_id": "openai/gpt-5.4-mini",
        "upstream_id": "openrouter"
      }
    }
  ]
}

This branch uses the AnyRouter catalog model id in model_id (such as openai/gpt-5.4-mini) and pins the route to OpenRouter with upstream_id: "openrouter". Call the preset with @presets/<slug> from chat completions.

Configure

Create and manage presets two ways:

1. Dashboard — visit /dashboard/presets to create, edit, and organize presets, including the BYOK-route builder described above.
2. API — use the Presets API to create them programmatically.

Once saved, reference the preset from any request via @preset/<slug> (config bundle) or @presets/<slug> (branch routing).

Use cases

• Consistent eval setups — pin every eval to a specific preset so results don't drift when upstream providers change.
• Team templates — share presets across your org for common tasks (code review, summarization, classification).
• Fallback handling — configure multiple models so requests succeed even when a primary provider has an outage.

Related

• Presets API — create and manage presets programmatically.
• Routing — how the router picks and falls back across upstreams.
• Managing API Keys — the sk-ar-… keys presets are called with.