If you’ve copied the same model name, system prompt, and temperature into a web app, a batch script, and a notebook, you know the pain: change one parameter and you’re editing three places. OpenRouter’s presets address this by treating your LLM configuration as a named, versioned artifact that lives outside your application code.
What a preset actually stores
A preset bundles model selection (one model or an ordered fallback list), a system prompt, provider routing rules, sampling parameters like temperature and top_p, and tools such as web search or image generation. You reference it in any API request with "model": "@preset/your-preset-name". The config lives in the OpenRouter dashboard, not in your repo, so updating it doesn’t require a redeploy.
This is different from a .env file or a Terraform module in one key way: those still ship with your code and need a new build to change. A preset is stored server-side, so every app that references the slug picks up the new version on its next request.
Creating and using a preset
Start at openrouter.ai/settings/presets, pick a memorable slug, and configure your model, routing, prompt, and sampling settings. Then replace a verbose request body with a single reference:
resp = client.chat.send(
model = "@preset/tech-writer",
messages = [
{ "role": "user", "content": "Explain preset versioning." },
],
)You can still override any field per request—request values win over preset values, and tools are merged rather than replaced. There’s no global default preset for the API; every request must name one explicitly.
Two patterns worth copying
Image prompt enhancement. Pair a text model with the image-generation tool inside a preset. The text model expands a short user prompt into a detailed visual brief covering subject, composition, lighting, palette, and style, then calls the image tool automatically. Every app using @preset/image-enhancer gets the same behavior without duplicating the system prompt or tool configuration.
Pinning a Fusion panel. If you run a Fusion setup—a panel of models alongside a primary model that writes the final answer—store the entire configuration in a preset’s tools. Your web app, evaluation scripts, and Slack bot all reference @preset/fusion-panel. Adjust the panel in the dashboard instead of editing three codebases. This also gives ML engineers a repeatable evaluation config under one stable slug.
Who benefits from this shift
Presets move configuration ownership from “anyone who can ship code” to “anyone with dashboard access.” A product manager can change a system prompt or swap a model without asking an engineer to edit code or trigger a deploy. For larger teams, a preset becomes the single versioned place for model choices, routing, and prompts—replacing constants scattered across repos.
This aligns with a broader pattern we’ve explored before: execution models decide how much your orchestrator can be trusted. Presets don’t change what your models can do, but they change how reliably you can reproduce and update the configuration that drives them.
The tradeoff to watch
Versioning is built in: saving an existing slug creates a new active version, and you can restore an earlier one if a change hurts quality. But there’s no API-level default preset, so every integration must name its preset explicitly. That’s a feature for explicitness, but it means you need discipline to use the same slug everywhere rather than hardcoding parameters in some places and referencing presets in others.
Start with one preset for your most repeated configuration—a system prompt plus model and temperature you use across multiple tools. Then see how much of your request body you can delete.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.