Summary: OpenRouter Presets turn reusable model choice, fallbacks, system prompts, provider routing, sampling parameters, and tools into named, versioned server-side configuration referenced by an @preset slug. Dashboard updates apply on the next request without redeploy, request-level overrides still work, and tools merge, but every request must name its preset. The approach shifts configuration control to people with dashboard access and requires keeping references consistent.
Copy the same model name, system prompt, and temperature into a web app, a batch script, and a notebook, and you’ve set up a familiar annoyance: change one parameter, edit three places. OpenRouter’s presets exist to fix that. The idea is to treat the configuration behind your LLM calls as a named, versioned artifact that sits outside your application code.
What lives inside a preset
Reach into a preset and you’ll find model selection (a single model, or an ordered fallback list), a system prompt, provider routing rules, sampling parameters such as temperature and top_p, and tools — web search or image generation, for instance. Any API request points at it with "model": "@preset/your-preset-name". Since the configuration is kept in the OpenRouter dashboard rather than your repo, changing it takes effect with no redeploy.
Here is where it parts ways with a .env file or a Terraform module. Those still travel with your code and need a fresh build before anything changes. A preset lives server-side; the next request from each app that names the slug picks up the current version.
Making and referencing a preset
Head to openrouter.ai/settings/presets, choose a slug you’ll remember, and set up your model, routing, prompt, and sampling. From there, a long request body collapses into a single reference:
resp = client.chat.send(
model = "@preset/tech-writer",
messages = [
{ "role": "user", "content": "Explain preset versioning." },
],
)Overrides per request still work: where a request and a preset disagree, the request wins, and tools are merged rather than replaced. One thing the API doesn’t offer is a global default preset — each request has to name its own.
Two patterns worth adopting
Prompt enhancement for image models. Put a text model and the image-generation tool together inside one preset. The text model takes a short user prompt and expands it into a detailed visual brief — subject, composition, lighting, palette, style — then calls the image tool on its own. Any app that references @preset/image-enhancer inherits that behavior, with no need to duplicate the system prompt or the tool configuration.
Freezing a Fusion panel. Suppose you run a Fusion setup: a panel of models working alongside a primary model that composes the final answer. Store the whole configuration in a preset’s tools, and your web app, evaluation scripts, and Slack bot can all point at @preset/fusion-panel. Changing the panel becomes a dashboard edit instead of edits across three codebases. ML engineers also gain a repeatable evaluation config behind one stable slug.
Who comes out ahead
What shifts here is ownership of configuration. Rather than belonging to “anyone who can ship code,” it moves to “anyone with dashboard access.” A product manager can rewrite a system prompt or swap in a different model without waiting on an engineer to touch code or kick off a deploy. For bigger teams, the preset turns into the one versioned home for model choices, routing, and prompts — standing in for constants that used to sit scattered across repos.
This fits a broader pattern we’ve written about before: execution models decide how much your orchestrator can be trusted. Presets don’t alter what your models can do. What they alter is how dependably you can reproduce and update the configuration that drives them.
The tradeoff that comes with it
Versioning is there by default: saving over an existing slug creates a new active version, and if a change hurts quality you can restore an earlier one. What you don’t get is an API-level default preset, so every integration has to name its preset out loud. That is a feature where explicitness is concerned, but it takes discipline to reference the same slug everywhere instead of hardcoding parameters in some spots and using presets in others.
A reasonable first step: build one preset around the configuration you repeat most — a system prompt plus the model and temperature you keep reusing across tools. Then count how much of your request body you can delete.