AI/ML Infrastructure Release Notes

Release notes for AI compute platforms, inference clouds and ML tooling

Get this feed:

Products (18)

Latest AI/ML Infrastructure Updates

Sep 14, 2026
Date parsed from source:
Sep 14, 2026

First seen by Releasebot:
Sep 15, 2026
Gemini Enterprise Agent Platform by Google

September 14, 2026

Gemini Enterprise Agent Platform adds Anthropic’s Cyber Verification Program for Claude in Preview, giving verified organizations access to supported Claude models for legitimate defensive cybersecurity tasks. The release also includes CodeMender stability, config, and bug fixes.
Fixed

CodeMender updates (v0.7.0)

This release introduces updates to CodeMender:

Network stream resilience: Improved CLI session stability with automatic reconnection and transient error recovery during long-running scans and remediation workflows.

Configuration uniformity: Standardized directory exclusion rules across configuration files and CLI scanning flags under scan_config.exclude_dirs.

Bug fixes:

Fixed an issue where cm report incorrectly categorized DISMISSED findings as OPEN in the summary table.

Resolved sandbox permission denial errors by preventing child worker processes from attempting to create internal session logs on disk.

Hardened sandbox command policy to prevent directory traversal and file inspection outside the designated repository root into adjacent directories.

For more information, see CodeMender documentation.

Feature

Cyber Verification Program for Claude is available in Preview

Anthropic's Cyber Verification Program (CVP) is available in Preview on Gemini Enterprise Agent Platform. CVP enables verified organizations to use supported Claude models (Claude Opus 4.7, Claude Opus 4.8, Claude Sonnet 5, and Claude Opus 5) for legitimate defensive cybersecurity tasks with default dual-use restrictions lifted.

For more information, see Cyber Verification Program for Claude.
Original source
Sep 13, 2026
Date parsed from source:
Sep 13, 2026

First seen by Releasebot:
Sep 13, 2026
Baseten

Model API Deprecation (GLM 4.7, Kimi K2.7, Kimi K2.6, Inkling, Inkling Small, DeepSeek v4 Pro)

Baseten deprecates GLM 4.7, Kimi and DeepSeek models, with stronger alternatives recommended before September 25.

GLM 4.7, Kimi K2.7, Kimi K2.6, Inkling, Inkling Small, and DeepSeek v4 Pro will be deprecated at 5pm PT September 25th.

At that time the model IDs will become inactive and return an error for all requests. As open source models advance rapidly, we prioritize serving the highest quality models and deprecate models when stronger alternatives are available.

We recommend the following models as alternatives, all of which offer superior intelligence for each specific use case. Just swap in the new Model ID(s) prior to the deprecation date.
Original source
All of your release notes in one feed

Join Releasebot and get updates from Google and hundreds of other software products.

Create account
Get updates with:
Sep 11, 2026
Date parsed from source:
Sep 11, 2026

First seen by Releasebot:
Sep 13, 2026
Together AI

September 11, 2026

Together AI adds DeepSeek-V4.1-Flash to serverless with 1M context, FP8, function calling, structured outputs, and new pricing.

New serverless models

The following models are now available on serverless:

deepseek-ai/DeepSeek-V4.1-Flash: 1,000,000 context length, FP8 quantization, function calling and structured outputs. Pricing: $0.30 input / $1.20 output / $0.006 cached input (per 1M tokens).
Original source
Sep 11, 2026
Date parsed from source:
Sep 11, 2026

First seen by Releasebot:
Sep 13, 2026
Baseten

OIDC and AWS AssumeRole for training jobs

Baseten adds OIDC and AWS AssumeRole for training jobs, letting teams pull private container images and download model weights or training data without long-lived cloud credentials. The update supports ECR, S3, Google Artifact Registry, Container Registry, and Cloud Storage.

Training jobs can now use OIDC or AWS AssumeRole during setup to pull private container images and download model weights or training data without storing long-lived cloud credentials in Baseten.

OIDC supports Amazon ECR and S3, Google Artifact Registry and Container Registry, and Google Cloud Storage. Training OIDC tokens let you scope access to your Baseten organization, team, training project, or individual job.

For AWS resources, you can use AWS AssumeRole without registering an OIDC provider. Baseten assumes an IAM role in your account using your organization's unique external ID. AWS AssumeRole supports private images in Amazon ECR and weights or data in Amazon S3.

For setup instructions, see OIDC authentication, AWS AssumeRole, private training images, and weights and data authentication.
Original source
Sep 11, 2026
Date parsed from source:
Sep 11, 2026

First seen by Releasebot:
Sep 13, 2026
Baseten

Model API costs

Baseten adds Management API access to Model API spend with daily billing subtotals and cost history lookup.
You can now retrieve your Model API spend through the Management API. The new GET /v1/billing/model_apis endpoint returns exact subtotals for each calendar day, rated from your usage.

curl --get "https://api.baseten.co/v1/billing/model_apis" \ -H "Authorization: Bearer $BASETEN_API_KEY" \ -d "start_date=2026-09-04" \ -d "end_date=2026-09-11"

Cost history begins August 5, 2026 at 20:45 UTC.

For more information, see our docs.
Original source
Sep 11, 2026
Date parsed from source:
Sep 11, 2026

First seen by Releasebot:
Sep 11, 2026
OpenRouter

Zero Data Retention (ZDR): What It Means for AI APIs

OpenRouter adds Zero Data Retention controls for privacy focused routing, letting users enforce provider-side prompt and response retention rules through account settings, guardrails, or the provider.zdr request field while clarifying how ZDR differs from logging, caching, and training.
Tl;dr

ZDR prevents an eligible inference provider from retaining your prompts and responses.

Your data still reaches the provider and is processed by the model.

On OpenRouter, you can enforce ZDR through account settings, guardrails, or the provider.zdr request field.

ZDR applies to provider inference. Your logs, enabled tools, plugins, and other storage features require separate controls.

What is zero data retention (ZDR)?

Zero Data Retention is a data-handling policy under which an AI provider processes your request without persisting the prompt or response. ZDR governs provider-side retention. It doesn’t mean your data remained inside your network or that every service involved in the request followed the same policy.

We evaluate data policies at the endpoint level because a provider’s general policy may differ from the policy attached to a particular model endpoint. When we can’t confirm an endpoint’s policy, we take the conservative position and classify it as retaining and training on data.

ZDR answers one of three separate questions:

Retention at rest: Whether the provider stores prompts and responses after the response returns. ZDR covers this.

Data in transit: Your request still travels to the provider, and the model still processes it. ZDR doesn’t change that.

Training on data: Whether a provider uses your inputs to improve its models. That’s a distinct control, though providers often pair it with ZDR.

A “no training” policy doesn’t necessarily mean ZDR. A provider may decline to train on your data while retaining it temporarily for another reason. The reverse relationship is stronger. An endpoint that doesn’t retain your data can’t later use that data for training.

ZDR routing is also separate from our own logging policy. We don’t store prompt or response content unless you opt in to input and output logging. We still retain request metadata such as token counts, latency, model, and cost so you can view usage and activity information.

What ZDR covers and what it doesn’t

ZDR has a specific boundary. It covers provider-side retention for eligible inference endpoints. It doesn’t become a universal privacy policy for every system your request touches.
Data-handling question Covered by ZDR? What it means Provider stores your prompt after inference Yes A ZDR endpoint doesn’t persist the prompt Provider stores the model response Yes A ZDR endpoint doesn’t persist the completion Provider trains on the retained prompt Indirectly prevented There is no retained prompt available for training Data reaches the model No The provider must process the input to generate a response Processing stays in a specific country or region No Use data residency or in-region routing OpenRouter stores request metadata No Metadata can be retained without prompt or response content Your application logs prompts No Your own logging and storage policies still apply A plugin or tool retains data No Tools have their own operators and data policies An endpoint retains data for abuse or legal review No We don’t treat a retaining endpoint as ZDR
“We do not train on your data” may still allow temporary retention for abuse detection or legal obligations. That endpoint doesn’t meet our ZDR definition. You can still use it under a no-training policy, but you shouldn’t describe the request as zero retention.

ZDR enforcement also applies only to inference provider routing. A web search plugin, external tool, or other service you enable can receive request data under its own retention terms. Review those policies separately before using them in a workflow with strict retention requirements.

Your application remains another retention layer. A ZDR request can still leave a complete prompt in an error tracker, an analytics event, a database row, or an application log. Provider-side ZDR doesn’t delete any of those copies.

Check caching separately

We consider provider-side in-memory prompt caching compatible with ZDR because the prompt isn’t written to persistent storage. Cached representations remain in provider memory long enough to reuse the prompt and improve performance.

Our response caching feature has different behavior because it temporarily stores generated responses. Account-level ZDR disables response caching, but the per-request provider.zdr field doesn’t affect response-cache eligibility. A system that requires zero storage across every layer should therefore review its response-caching configuration separately.

ZDR versus related AI privacy controls

ZDR is one of several privacy controls. Each control answers a different question.

ZDR vs. “no training on your data”

These often ship together, but they answer different questions. “No training” governs whether your inputs improve a model. ZDR governs whether the provider stores those inputs after the response returns. A provider can promise not to train on your data while still holding it briefly for abuse checks or legal reasons. If you need both, enforce both.

On OpenRouter, data_collection lets you filter providers based on whether they store user data non-transiently and may train on it. Setting it to "deny" excludes those endpoints. You can combine it with zdr: true when you want both controls to be explicit in the request.

ZDR vs. data residency and region pinning

Region pinning controls where your request is processed, inside a specific region for GDPR, for example, while ZDR controls whether the data is kept afterward. A provider might process and retain a request in the EU, or process a ZDR request somewhere else entirely.

Use both controls when a policy names a permitted processing location and a retention requirement. We provide in-region routing for the US and EU on Business and Enterprise plans through the us.openrouter.ai and eu.openrouter.ai API domains. This is separate from ZDR enforcement.

ZDR vs. self-hosting

Self-hosting keeps inference inside your own infrastructure. Before choosing it, check whether these controls meet your requirements:

Region pinning: Controls where the request is processed.

ZDR routing: Prevents provider-side storage of prompts and responses.

Per-key or per-workspace guardrails: Separate one customer’s traffic and policy from another’s.

Your own logging: Records what was sent and where.

Self-hosting is required when policy prohibits all third-party processing, including transient inference.

How to route to ZDR-eligible endpoints on OpenRouter

A provider offering ZDR doesn’t automatically make every request ZDR-compliant. You must enforce the policy at the account, guardrail, or request level.

Account-level enforcement in privacy settings

You can enforce ZDR across every request without touching your code, from your account’s privacy settings. ZDR can be required per model group, covering Anthropic, OpenAI, Google, SpaceXAI, and non-frontier endpoints, so you can require it for some model groups and not others. You can also enforce it through guardrails. See the Zero Data Retention guide.

Data policy filtering is a separate switch. It lets you disable providers that store inputs for training. Opt out of training in your account settings and we won’t route to providers that train on your data.

Per-request enforcement with the zdr routing control

For request-level control, set the zdr field inside the provider block. When zdr is true, the request routes only to endpoints with a Zero Data Retention policy. When it’s false or omitted, it doesn’t affect routing.

The related data_collection control takes "allow", the default, or "deny". Set it to "deny" and routing excludes endpoints that store user data non-transiently and may train on it.

The per-request zdr parameter composes as an OR with your account-wide and guardrail settings. If any one of them turns ZDR on, enforcement applies. The request-level flag can only ensure ZDR is on, it can’t override or loosen an account-wide or guardrail rule.

How to verify a vendor’s ZDR claim

Check these five points.

What exact data does ZDR cover? Confirm whether it includes prompts, completions, uploaded files, tool inputs, cached representations, and identifiers.

Does the policy apply per provider or per endpoint? Model features and API endpoints can have different storage requirements. A provider-wide statement may hide exclusions.

What falls outside the policy? Ask about metadata, plugins, tools, prompt caching, response caching, logging, batch APIs, and stateful features.

How is ZDR enforced? Look for an account policy, guardrail, or request-level routing control rather than manual provider selection.

How can you verify continued eligibility? Data policies change. We maintain endpoint-level policy information and publish the current list of ZDR endpoints at https://openrouter.ai/api/v1/endpoints/zdr, so routing decisions can follow the current policy rather than a static spreadsheet.

Conclusion

ZDR reduces provider-side storage risk, but only when your request reaches a qualifying endpoint. Treat it as an enforceable routing requirement.

For sensitive inference traffic, combine the controls that match the actual policy. Use ZDR for retention, data_collection: "deny" for storage and training restrictions, and in-region routing when processing location matters. Then review your application logs, enabled tools, and caching configuration so another layer doesn’t recreate the data you removed from the provider.

Building on our API? Restrict your calls to ZDR endpoints, starting with our ZDR docs and provider routing controls. Reviewing AI data handling for your org? See OpenRouter for Enterprise.

FAQ

What is ZDR (zero data retention)?

Zero Data Retention means an AI provider processes your prompt and returns a response without persisting either one afterward. ZDR governs provider-side storage for eligible endpoints. It doesn’t prevent the data from reaching the model, keep the request inside your network, or control copies created by your own systems.

What is a zero data retention policy for AI?

A zero data retention policy states that an AI provider won’t store prompts or responses after processing them. The policy should identify which endpoints and features qualify, how it’s enforced, and what happens to metadata, caches, tools, and logs. A no-training policy alone doesn’t guarantee zero retention.

What is a zero-retention API?

A zero-retention API processes requests without storing the prompt or response after inference. With OpenRouter, you can restrict a request to eligible endpoints by setting provider.zdr to true. Account-level privacy settings and guardrails can enforce the same requirement across broader groups of requests.

Which LLM is best for privacy?

Privacy depends on the endpoint and routing policy, rather than the model name alone. The same model can be available through providers with different retention rules. Filter the model catalog for eligible endpoints, then enforce ZDR, data-collection, and residency requirements through your routing configuration.
Original source
Sep 10, 2026
Date parsed from source:
Sep 10, 2026

First seen by Releasebot:
Sep 13, 2026
Baseten

DeepSeek V4.1 Flash available on Baseten

Baseten adds DeepSeek V4.1 Flash to Model APIs, bringing a 552B-parameter multimodal model built for agentic coding workflows with built-in reasoning and tool calling through an OpenAI-compatible endpoint.
DeepSeek V4.1 Flash is now available through Baseten Model APIs. The 552B-parameter multimodal successor to DeepSeek V4 Flash 0731, it is purpose-built for agentic, coding workflows, and has reasoning and tool calling built in.

Send requests to deepseek-ai/DeepSeek-V4.1-Flash through our OpenAI-compatible endpoint with your Baseten API key:

curl https://inference.baseten.co/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BASETEN_API_KEY" \ -d '{ "model": "deepseek-ai/DeepSeek-V4.1-Flash", "messages": [ {"role": "user", "content": "Explain the Navier Stokes smoothness problem."} ], "reasoning_effort": "high" }'

For more information, see our docs.
Original source
Sep 10, 2026
Date parsed from source:
Sep 10, 2026

First seen by Releasebot:
Sep 11, 2026
OpenRouter

OpenRouter Fusion: How It Works and When to Use It

OpenRouter introduces Fusion, a compound model that sends one prompt to multiple expert models, compares their answers with a judge, and returns a single final response. It targets harder research and analysis tasks, trading extra cost and latency for better quality.
OpenRouter · 9/10/2026

OpenRouter Fusion is our compound model. It takes one prompt and turns it into a short debate among several models. We send your prompt to a panel of expert models at once, and a judge compares every response so the calling model can write a single final answer.

With Fusion, you trade some speed and tokens for quality. This page covers what Fusion does, what it costs, when it beats a single model, and when it doesn’t.

Tl;dr

What Fusion does. It gives a model access to a multi-model deliberation tool. A panel answers in parallel, a judge maps agreement and disagreement, and the calling model writes the final response.

What it costs. An invoked Fusion call adds panel and judge completions. The default three-model panel costs roughly four to five times as much as one completion on the same prompt and often takes two to three times longer.

When to use it. Use Fusion as a selective escalation path for complex research, expert critique, and decisions where an incorrect answer creates more cost than a few additional model calls.

What is OpenRouter Fusion?

Fusion is a compound inference system that gives a model access to multi-model deliberation. When the model invokes Fusion, several models answer the prompt in parallel. A judge compares their responses and produces structured analysis, which is then used to produce the final answer.

That makes Fusion different from a single model call. A single call follows one model’s reasoning path. Fusion can bring several reasoning paths, source selections, and interpretations into the same response.

Fusion and auto-routing serve different jobs. Auto-routing picks one model for your request by classifying the prompt’s task type and choosing the model the OpenRouter community spends the most on for that kind of task. Fusion combines many models and blends their answers, and it can produce a stronger answer than any single panelist would give.

How OpenRouter Fusion works

Fusion adds a deliberation loop inside a normal model request.

The pipeline has four stages:

The calling model evaluates the prompt. When you use Fusion, we resolve the alias to a model and attach the Fusion tool. The model can answer directly or invoke Fusion when the task warrants more analysis.

The panel works in parallel. Between one and eight participant models independently answer the prompt. Each panelist can use OpenRouter web search and web fetch to find current sources.

The judge compares the responses. Our docs call this role the analyst. The judge identifies consensus, contradictions, partial coverage, unique insights, and blind spots. It returns that comparison as structured analysis.

The calling model writes the answer. The original model receives the judge’s analysis and uses it to produce the response returned to your application.

The judge’s job is comparison rather than simple voting. Three models repeating the same unsupported claim don’t automatically make that claim correct. The judge can also surface a useful point that appears in only one response or identify a gap that every panelist missed.

Where the quality gain comes from

Fusion benefits from diversity between models and variation between separate runs. Different models may choose different methods, notice different constraints, or retrieve different sources. Even two runs of the same model can follow different reasoning paths and make different tool calls.

We tested that second effect by pairing Claude Opus 4.8 with another Opus 4.8 run and using the same model for synthesis. The fused configuration scored 65.5% on our DRACO benchmark run, compared with 58.8% for a solo Opus 4.8 run. That 6.7-point improvement suggests that the comparison and synthesis process contributes meaningful value even without model diversity.

Multi-model ensembling is an established technique. Fusion’s product value is operational. You can add a panel, judge, tools, and synthesis loop through one model slug or server tool instead of building and maintaining that orchestration yourself.

Fusion vs. a single model

Fusion can improve difficult answers, but it does so by performing more work.

Quality depends on the task

On DRACO, a deep-research benchmark by Perplexity AI, a budget Fusion panel using Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro scored roughly 64.7% against about 65.3% for Claude Fable 5 on its own. Fable-based results reflect 93 of 100 tasks because of content filters, so direct comparisons are slightly uneven.

DRACO measures deep research, not raw coding or general chat. Fusion’s synthesis tends to help most on research and analysis prompts, where several viewpoints genuinely sharpen the answer. Don’t assume the same margin carries to every task.

More tokens, but cost per task can still win

Fusion pays for several model calls plus the judge, so a single request uses more tokens than a single-model call. Cost per call isn’t always the number that matters, though. Cost per correct answer often matters more.

If one Fusion call returns the right answer while a cheaper model needs three attempts, a rerun, and a human to check it, Fusion can come out cheaper across the whole task. Count the total cost of reaching the result, not the price of one request. Our Fusion model page has current costs.

Latency runs two to three times longer

Fusion calls often take two to three times as long as a standard single-model call. The panel runs concurrently, so you’re not waiting on each model in sequence, but you still wait for the slowest panelist and then for the judge. That delay usually rules out chat, autocomplete, and other real-time paths.

Non-deterministic by design

A panel plus a synthesis step can return different results run to run. That’s by design. It’s fine for a one-off research task, but it becomes a problem when you need repeatable output, like evaluation suites, regression tests, or any check that compares today’s result against yesterday’s.

When to use Fusion and when to skip it

The strongest production pattern is selective escalation. Let a model handle routine work directly and invoke Fusion for the smaller set of prompts that deserve additional scrutiny. For per-step escalation to a single stronger model, see the Advisor server tool.

Use it for high-stakes, research-style prompts where being wrong is expensive

Research questions, expert review, comparisons, and due-diligence summaries, anywhere accuracy is the priority and a later correction costs real time or money. In practice, think of summarizing a competitive field from a dozen current sources before you commit to a strategy call.

Use it when you’d otherwise poll several models by hand

If your current workflow is asking three models the same question and comparing the answers yourself, Fusion is doing exactly that job. The judge also compares answers more consistently than a manual review.

Skip it for latency-sensitive or high-QPS interactive paths

When a user is waiting for a response, the two-to-three-times latency is too long. In practice, this means a customer chatbot or inline code completion.

Skip it for reproducibility-sensitive workloads

Evals, regression suites, and anything that needs stable results across runs. Non-determinism makes those comparisons unreliable. In practice, a CI pipeline that checks whether an LLM’s output changed.

Skip it for simple, well-scoped tasks a single mid-tier model already handles

If one mid-tier model returns correct answers today, a panel just adds cost and delay for no real gain. In practice, classification, extraction, short rewrites, and format conversion.

How to use OpenRouter Fusion

You can test Fusion in the web interface or call it through any supported inference endpoint.

The no-code path

Open the Fusion lab, select a preset, and enter a prompt that benefits from multiple perspectives.

Start with a prompt you already know is difficult. Compare the fused result with the answer from your current production model. Look for fewer factual errors, broader coverage, clearer disagreement handling, or less human editing.

The interface also lets you build a custom panel before moving the configuration into your application.

The Fusion API

The simplest API path is to replace your current model slug with openrouter/fusion. With no additional configuration, Fusion uses the default Quality panel and lets the model decide whether deliberation is necessary.

The example below selects the general-budget preset, overrides its judge model, and requires Fusion to run:

import os from openai import OpenAI client = OpenAI( base_url = "https://openrouter.ai/api/v1", api_key = os.environ["OPENROUTER_API_KEY"], ) response = client.chat.completions.create( model = "openrouter/fusion", messages = [{ "role" : "user", "content" : "Compare three approaches to multi-tenant data isolation.", }], tool_choice = "required", extra_body = { "plugins" : [{ "id" : "fusion", "preset" : "general-budget", "model" : "~openai/gpt-latest", }] }, ) print(response.choices[0].message.content)

The preset chooses a curated panel. The nested model field selects the judge and, when you use the Fusion model alias, the model that writes the final response. Explicit analysis_models or model values override the corresponding preset settings.

tool_choice: "required" forces the model to invoke Fusion instead of letting it decide.

The available general-purpose presets currently include:

general-high for the strongest all-around panel

general-budget for cheaper panelists with a frontier judge

general-fast for a panel optimized around similar response times

You can also attach the openrouter:fusion server tool to your own outer model. That path is useful when the same model needs access to Fusion alongside your application’s other tools.

See the Fusion Router documentation for the full request formats and the Presets guide for reusable configuration management.

Conclusion

Fusion gives difficult prompts more than one attempt and gives your application a structured way to compare those attempts. That can improve research, critique, and high-cost decisions where a fast first answer isn’t enough.

The additional scrutiny has a measurable price. The panel and judge add tokens, cost, latency, and output variance. Those costs are justified when they reduce retries, manual comparison, or the risk of acting on an incomplete answer.

Start with one hard prompt from your real workload. Compare Fusion with your current model using cost per accepted result, not model price alone.

Try it with the Fusion Router, or read the Fusion benchmark announcement for the full DRACO methodology and results.

Frequently asked questions

How does OpenRouter Fusion work?

OpenRouter Fusion lets a calling model send a prompt to several panel models in parallel. A judge compares the responses and returns structured analysis covering consensus, contradictions, partial coverage, unique insights, and blind spots. The calling model uses that analysis to write the final answer.

What is model fusion in AI?

Model fusion can refer to combining model parameters or combining outputs from several models. OpenRouter Fusion uses output-level deliberation during inference. It gathers independent responses, compares them through a judge, and gives the resulting analysis to the model that writes the final response.

Is OpenRouter Fusion better than Fable 5?

Fusion outperformed Fable 5 on its own in several frontier-panel configurations on the DRACO deep-research benchmark by Perplexity AI. A budget panel scored 64.7%, compared with Fable 5 at 65.3%, while a frontier panel scored 69.0%. Fable-based results reflect 93 of 100 tasks because of content filters. These results apply to deep research and don’t establish that Fusion replaces Fable across long-horizon or general workloads.

Does OpenRouter Fusion have an API?

Yes. You can call the OpenRouter Fusion API with the openrouter/fusion model slug or attach Fusion as an openrouter:fusion server tool. The fusion plugin configures the panel and judge for either entry point but does not start a Fusion run on its own. Both entry points use the same underlying panel, judge, and final-answer pipeline.
Original source
Sep 10, 2026
Date parsed from source:
Sep 10, 2026

First seen by Releasebot:
Sep 11, 2026
OpenRouter

How to Use OpenRouter Presets: Config-as-Code Guide

OpenRouter introduces presets, a versioned config-as-code way to reuse models, prompts, routing, sampling settings, and tools across apps. Users can reference a preset in API calls, update it once in the dashboard, and have changes flow everywhere without redeploys.
Tl;dr

A preset stores a model or fallback array, a system prompt, provider routing, and sampling parameters under one name.

Use it in any request as "model": "@preset/your-preset-name".

Update it in the dashboard, and every app that uses it changes, no need for a code update.

What is an OpenRouter preset?

An OpenRouter preset is a named, versioned config that stores your model choices, a system prompt, provider routing preferences, and sampling parameters. We let you use it in any API request through its slug. This keeps your LLM setup out of your application code.

Think of a preset the way you would think of a .env file or a Terraform module, where a config lives outside your application logic and gets referenced by name rather than copied into it. The difference is where it lives and who can change it. A .env file still ships with your repo and needs a redeploy to update. We store the preset in the OpenRouter dashboard instead, so changing it immediately updates every app that references it.

A single preset can hold:

Model selection, one model or an ordered list of fallback models.

System prompt, the instructions added before every request.

Provider routing, sort by price or latency, and include or exclude providers.

Sampling parameters, temperature, top_p, and other settings.

Tools, including OpenRouter server tools such as web search, image generation, advisors, and subagents.

Preset vs. hardcoding your request body

Hardcoded request | @preset/name
Where config lives: In each codebase | Once in the dashboard
Change the system prompt: Edit and redeploy each app | Edit the preset; no redeploy
Model fallbacks: Repeat the array everywhere | Define it once in the preset
Who can change it: Anyone who can ship code | Anyone with dashboard access

How to create your first preset

Step 1: Open the preset editor

Go to openrouter.ai/settings/presets and create a preset. Pick a slug you’ll remember, because you’ll use it as @preset/your-slug.

Step 2: Choose model and routing

Pick one model or add an ordered list. If the first model fails from a rate limit, outage, or too much context, we try the next one. You set the fallback order once in the preset instead of repeating it in every request.
Set provider routing here too, as seen in the screenshot above. You can sort by price or latency, or block a provider from your requests.

Step 3: Add a system prompt and sampling settings

Add your system prompt and set temperature, top_p, and any other sampling parameters. These become the defaults for every request that uses the preset.

Step 4: Reference it from an API call

Set the model field to your preset. Compare these requests.

Before, with every parameter in the request:

from openrouter import OpenRouter client = OpenRouter(api_key=OPENROUTER_API_KEY) resp = client.chat.send( model="anthropic/claude-opus-4.8", provider={"sort": "price"}, temperature=0.7, messages=[ {"role": "system", "content": "You are a concise technical writer..."}, {"role": "user", "content": "Explain preset versioning."}, ], )

After, with a preset reference:

resp = client.chat.send( model="@preset/tech-writer", messages=[ {"role": "user", "content": "Explain preset versioning."}, ], )

You can also create a preset through the API with a POST request to the preset endpoint. We save the fields that belong to the preset config and ignore transient fields like messages, stream, and prompt.

You can override preset settings in each request. If the request body includes temperature, that value wins over the preset value. The merge is shallow, so request fields replace matching preset fields, and we keep any preset fields you leave out. tools is the exception: we combine the preset’s tools with the request’s tools, and a request tool replaces a preset tool with the same name. You can also use a separate preset field ("preset": "@preset/tech-writer") or the combined form ("model": "anthropic/claude-opus-4.8@preset/tech-writer"). The preset field needs the full @preset/ prefix. A bare slug is ignored.

Can you set a default preset?

Not for the API. Presets have versions. Saving an existing slug creates a new version and makes it active, but there is no global default preset for the API. Every request must name a preset. The Chatroom does have a Default Preset setting under Settings > Preferences that applies to new chat messages.

For the API, put your default behavior in a preset and use that preset everywhere. If you want short answers, add that rule to the preset’s system prompt (“Answer in three sentences or fewer unless asked to expand.”) and set the sampling parameters. Every service that uses @preset/short-answers will follow those defaults unless a request overrides them.

Using a preset by name gives you steady behavior you can change in one place. The same pattern extends to more complex setups. Here are two worked examples.

Use case 1: An image-prompt-enhancement preset

Image models often do better with detailed prompts. Instead of adding that detail by hand each time, pair a text model with the image-generation tool in a preset. The text model refines each prompt before it goes to the image model.

The preset stores a text model, a system prompt that turns a short request into a full visual brief covering subject, composition, lighting, palette, and style, and the image-generation tool.

Once the preset is saved, test it directly in the Chatroom by opening the preset and selecting “Test in Chat.” Send a short prompt like “a cozy reading nook by a rainy window,” and the preset applies its system prompt and image tool. The text model expands your short prompt into a full visual brief, then calls the image tool automatically.

The preset stores the tools array and tool_choice along with the model, system prompt, and sampling parameters.

Every app that uses @preset/image-enhancer gets the same behavior. The preset-enhanced images cookbook walks through the full process.

Use case 2: Pinning a Fusion configuration as a preset

A Fusion setup runs a panel of models alongside your primary model, and the primary model writes the final answer using the panel’s outputs. Store the entire setup in a preset, then use it via a single reference.

Store the openrouter:fusion tool, with its analysis_models panel and analyst model, in the preset’s tools, then call @preset/fusion-panel from anywhere. Your web app, evaluation tools, and Slack bot all use the same panel. You adjust it in the dashboard instead of editing three codebases. For the exact fields a Fusion configuration uses and how the panel works, see the Fusion docs.

This also gives ML engineers a repeatable evaluation config with the same models, sampling settings, and routing under one stable slug.

Managing presets over time

Each time you save a preset with an existing slug, our system creates a new version and makes it active. API requests that use the preset get the active version.

Change the system prompt in the dashboard, and every app using that slug picks up the change on its next request. No redeploy. If the change hurts quality, restore an earlier version in the dashboard. New requests use it right away.

A product manager can change the system prompt or model in the dashboard without asking an engineer to edit code or ship a new build.

Presets across apps and teams

One preset can serve an API integration, a batch job, and a third-party app that supports the OpenAI-compatible API. Because presets use the standard model field, any client that can set a model string can use one.

For larger teams, a preset gives you one versioned place for model choices, routing, and prompts. It replaces constants scattered across several repos.

If you’re using an organization account, all members can access organization presets, which makes them a good way to share best practices across teams.

Conclusion

Three things to remember:

A preset stores a model, system prompt, routing rules, and sampling settings under one name. Use it as @preset/name in any request.

Updating a preset changes every app that uses it, with no redeploy. You can restore an earlier version if needed.

The same shared config can power image-prompt enhancement and Fusion panels across many apps.

Create your first preset at openrouter.ai/settings/presets. Then try the preset-enhanced images cookbook.

Frequently Asked Questions

How do I change the model in OpenRouter?

Change the model in the preset at openrouter.ai/settings/presets. Every call that uses @preset/your-preset-name will use the new model on its next request. Without a preset, you have to change the model field in each request body.

What is OpenRouter model usage?

We give you one API endpoint for hundreds of models from Anthropic, OpenAI, Google, Meta, and other providers. Pick a model per request or use a preset, then pay each model’s token rate. See the models list for current options and prices.

What is the API limit for OpenRouter?

Rate limits vary by model and provider. A preset doesn’t change them. A preset only stores config, the model, prompt, routing, and sampling settings. The same limits apply whether you use a preset or put the parameters directly in each request. See the limits docs for current figures.

Is OpenRouter compatible with OpenAI?

Yes. We offer an OpenAI-compatible API. Presets use the standard model field, so any OpenAI SDK client can use them by setting "model": "@preset/your-preset-name".

Can a preset include fallback models?

Yes. A preset can hold an ordered list of models. If the first fails from a rate limit, outage, or too much context, we try the next one. You set the order once in the preset instead of in each request.

Can I override a preset’s settings per request?

Yes. Parameters in the request body win over preset values. The merge is shallow, so request fields replace matching preset fields, and we keep any preset fields you leave out. Tools are combined, with request tools replacing preset tools of the same name.

Do presets work through the API or only in the Chatroom?

Presets work through the OpenAI-compatible API. You can use @preset/slug in the model field, a separate preset field set to @preset/slug, or the combined model@preset/slug form.
Original source
Sep 10, 2026
Date parsed from source:
Sep 10, 2026

First seen by Releasebot:
Sep 11, 2026
Baseten

Regional deployments

Baseten adds region-specific replica placement for deployments to support compliance, data residency, and lower latency.
Restrict every replica in a deployment to a specific Baseten region. Select a region through the dashboard, Baseten CLI, or Management API to meet compliance or data residency requirements or reduce latency.

baseten model push --region eu

For more information, see our docs.
Original source

AI/ML Infrastructure Release Notes

Products (18)

Latest AI/ML Infrastructure Updates

September 14, 2026

Fixed

CodeMender updates (v0.7.0)

Feature

Cyber Verification Program for Claude is available in Preview

Model API Deprecation (GLM 4.7, Kimi K2.7, Kimi K2.6, Inkling, Inkling Small, DeepSeek v4 Pro)

September 11, 2026

New serverless models

OIDC and AWS AssumeRole for training jobs

Model API costs

Zero Data Retention (ZDR): What It Means for AI APIs

Tl;dr

What is zero data retention (ZDR)?

What ZDR covers and what it doesn’t

Check caching separately

ZDR versus related AI privacy controls

ZDR vs. “no training on your data”

ZDR vs. data residency and region pinning

ZDR vs. self-hosting

How to route to ZDR-eligible endpoints on OpenRouter

Account-level enforcement in privacy settings

Per-request enforcement with the zdr routing control

How to verify a vendor’s ZDR claim

Conclusion

FAQ

What is ZDR (zero data retention)?

What is a zero data retention policy for AI?

What is a zero-retention API?

Which LLM is best for privacy?

DeepSeek V4.1 Flash available on Baseten

OpenRouter Fusion: How It Works and When to Use It

OpenRouter · 9/10/2026

Tl;dr

What is OpenRouter Fusion?

How OpenRouter Fusion works

Where the quality gain comes from

Fusion vs. a single model

Quality depends on the task

More tokens, but cost per task can still win

Latency runs two to three times longer

Non-deterministic by design

When to use Fusion and when to skip it

Use it for high-stakes, research-style prompts where being wrong is expensive

Use it when you’d otherwise poll several models by hand

Skip it for latency-sensitive or high-QPS interactive paths

Skip it for reproducibility-sensitive workloads

Skip it for simple, well-scoped tasks a single mid-tier model already handles

How to use OpenRouter Fusion

The no-code path

The Fusion API

Conclusion

Frequently asked questions

How does OpenRouter Fusion work?

What is model fusion in AI?

Is OpenRouter Fusion better than Fable 5?

Does OpenRouter Fusion have an API?

How to Use OpenRouter Presets: Config-as-Code Guide

Tl;dr

What is an OpenRouter preset?

Preset vs. hardcoding your request body

How to create your first preset

Step 1: Open the preset editor

Step 2: Choose model and routing

Step 3: Add a system prompt and sampling settings

Step 4: Reference it from an API call

Can you set a default preset?

Use case 1: An image-prompt-enhancement preset

Use case 2: Pinning a Fusion configuration as a preset

Managing presets over time

Presets across apps and teams

Conclusion

Frequently Asked Questions

How do I change the model in OpenRouter?

What is OpenRouter model usage?

What is the API limit for OpenRouter?

Is OpenRouter compatible with OpenAI?

Can a preset include fallback models?