AI/ML Infrastructure Release Notes

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

Get this feed:

Products (19)

Latest AI/ML Infrastructure Updates

Oct 29, 2026

Date parsed from source:
Oct 29, 2026
First seen by Releasebot:
Oct 30, 2026

Baseten

joey-1 decision model available on Baseten

Baseten releases joey-1 through Model APIs, bringing typed decision outputs for text classification, request routing, and rubric-based scoring. The open-source 2B model supports multiple questions per request, with shared input prefixes helping reduce costs.

joey-1 is now available through Baseten Model APIs, and its weights are open source on Hugging Face. It's a 2B-parameter decision model post-trained from Qwen3.5-2B that classifies text, routes requests, and scores content against a rubric with typed answers your application can use directly.

Include several questions in one request to get choices, yes/no probabilities, and scores. Questions about the same state reuse its input prefix, so they cost less together than in separate requests.

Call decision-models/baseten-joey-2b-latest through the System One endpoint with your Baseten API key:

import os
import requests
resp = requests.post(
    "https://inference.baseten.co/v1/systemone",
    headers={
        "Authorization": f"Bearer {os.environ['BASETEN_API_KEY']}",
    },
    json={
        "model": "decision-models/baseten-joey-2b-latest",
        "state": "I was charged twice for my subscription. Please refund the duplicate charge.",
        "questions": {
            "route": {
                "type": "choice",
                "instructions": "Which team should handle this request?",
                "criteria": {
                    "billing": "Billing, payments, and refunds",
                    "technical_support": "Technical troubleshooting",
                },
            },
            "refund": {
                "type": "noul",
                "instructions": "Is the customer asking for a refund?",
            },
            "urgency": {
                "type": "score",
                "instructions": "How urgent is the request?",
                "criteria": [
                    "Routine request",
                    "Needs attention today",
                    "Immediate emergency",
                ],
            },
        },
    }
)
print(resp.text)

For more information, see our docs.

Original source

Oct 29, 2026
Date parsed from source:
Oct 29, 2026

First seen by Releasebot:
Oct 30, 2026
transformers by Hugging Face

v5.22.0: Mistral Large 4 (Le Chonk)

transformers adds support for Mistral Large 4, a multimodal model with a 1M-token context, advanced reasoning and agentic tools. The release also enables adapter training on FP8 weights, reduces memory use during MoE backpropagation, and includes library fixes and improvements.
New Models

Mistral Large 4 (Le Chonk)

Mistral Large 4 is Mistral's largest and most capable model to date: a 1 trillion-parameter natively multimodal Mixture-of-Experts model with 49 billion active parameters per token (52 billion including embeddings and output layers), trained from scratch on 3,800 NVIDIA Grace Blackwell GPUs in Mistral's own datacenters in Europe.

Mistral Large 4 unifies instruction following, reasoning, coding, and agentic workflows in a single set of weights. While a generalist model, it shows especially good performance on workloads such as cybersecurity, finance, and law, and it surpasses frontier closed models on visual grounding. It is natively fluent in 160+ languages, including every official language of the European Union.

Key Features

Mistral Large 4 includes the following architectural choices:

~1T total / ~52B active parameters: granular Mixture-of-Experts with 128 routed experts (4 active per token) and 1 shared expert.

1M context length, for long-context workloads.

Multimodal input: accepts text and image input, with text output. Pixtral-style vision encoder trained to handle variable image sizes and aspect ratios.

Instruct and Reasoning functionalities with function calls, reasoning effort configurable per request.

Mistral Large 4 offers the following capabilities:

Reasoning Mode: three reasoning efforts — low, medium, high (default) — so the same model can answer a quick chat reply or work through a complex agentic run.

Vision: analyzes images, charts, technical drawings, and documents, with state-of-the-art visual grounding among open weights.

Multilingual: natively fluent in 160+ languages, including all official languages of the European Union.

System Prompt: strong adherence and support for system prompts.

Agentic: native function calling, JSON output, and strict JSON schema enforcement.

Cybersecurity: state of the art among open-weight models for security work, while refusing malicious requests.

Large Context Window: supports a 1M context window.

The model is released under the Mistral Ecosystem Open-Weight License: a modified version of the MIT license, for both commercial and non-commercial use — operating a Model-as-a-Service business requires a separate commercial license with Mistral.

Recommended Settings

Reasoning Effort:

'low' / 'medium' / 'high' — default is 'high'.

Use reasoning_effort="high" for complex prompts and agentic usage, 'low' for fast chat replies and 'medium' for day to day usage.

Sampling: for all reasoning efforts, we recommend the following sampling parameters:

temperature=1.0

top_p=0.95

System Prompt: define a clear environment and use case, including guidance on how to effectively leverage tools in agentic systems.

Tools: keep the set of tools well-defined and limit their number to the minimum required for the use case.

Context: the checkpoint supports a 1M context window.

Breaking changes

🚨 Separate EP logic into its own file (#49679) by @3outeille

Quantization

FP8 quantized models can now be used for adapter training (such as LoRA with PEFT). Backward passes were added to the dense and grouped FP8 matmuls, and is_trainable is now True. Backward also dequantizes experts in chunks and skips autograd at inference, which cuts peak memory in the MoE layer backward from about 28.9 GiB to 2.8 GiB at 8k tokens. Separately, the AMD CI image now install

FP8 backward: chunked expert dequant, skip autograd.Function at inference (#50117) by @ArthurZucker in [#50117]

Train adapters on top of FP8 weights (#50031) by @qgallouedec in [#50031]

[AMD CI] Install onnxscript, bitsandbytes and peft in the AMD image (#50046) by @Abdennacer-Badaoui in [#50046]

Bugfixes and improvements

Processor unnecessary warnings (#49812) by @zucchini-nlp in [#49812]

Fix boolean padding in ClapFeatureExtractor (#23648) (#49960) by @rudy-07 in [#49960]

[Fix] Count cropping of an uninitialized layer as a no-op (#50104) by @remi-or in [#50104]

[loading] Allow PermuteForRope to act on single tensors while renaming (#50092) by @Cyrilvallez in [#50092]

Add Nemotron 3.5 Transcribe (#50084) by @eustlb in [#50084]

[Nemotron3Diarization] add left context support (#49283) by @eustlb in [#49283]

[Janus] Fix processor iterating a string prompt character by character (#50044) by @tarekziade in [#50044]

fix(config): forward token kwarg to get_config_dict in PreTrainedConfig.from_pretrained (#50081) by @ydshieh in [#50081]

Fix rope_scaling setter for configs that assign it during init (#50080) by @hmellor in [#50080]

[timesfm] Fix fp16 overflow on pad_val in _forward_transform (#50021) by @tarekziade in [#50021]

Update dev version (#50068) by @albertvillanova in [#50068]

Pin the shared Hub MIC fleet dataset (#49802) by @tarekziade in [#49802]

[docs] NVIDIA/Intel/CPU (#49650) by @stevhliu in [#49650]

Document how to handle non-persistent buffer initialization in custom models (#49880) by @Tialo in [#49880]

Remove legacy benchmark/ and disable automatic benchmark runs (#50040) by @tarekziade in [#50040]

Remove deprecation cycle for candidate generators (#50034) by @Cyrilvallez in [#50034]

Fix test pil import leak (#49915) by @guarin in [#49915]

fix: preserve NumPy integer label dtypes in default data collators (#49900) by @BlazeSR10hawk in [#49900]

[ESMFold2] Don't build the MSA encoder for checkpoints without one (#49890) by @jimburtoft in [#49890]

[minimax_m3_vl] Gate the integration tests on total accelerator memory (#50025) by @tarekziade in [#50025]

Fix: Add kwargs in LFM2.5 conv layers (#50022) by @younesbelkada in [#50022]

Forward code_revision to every pipeline loader (#49832) by @Rocketknight1 in [#49832]

[moshi] Skip Moshiko integration tests whose checkpoint is gone (#50017) by @tarekziade in [#50017]

Keep a capturing group's escapes when reversing a conversion pattern (#49772) by @IlyasMoutawwakil in [#49772]

perf(ci): skip the lazy blob fetch in git blame on a partial clone (#50007) by @nrenvo in [#50007]

fix(canary): set layerdrop=0.0 in test tester to prevent flaky test (#50012) by @ydshieh in [#50012]

add a WA to Dockerfile for XPU (#50008) by @kaixuanliu in [#50008]

pipelines: defer eager model imports in text_to_audio and token_classification (#50001) by @ydshieh in [#50001]

[exporters] resolve @register_patch paths lazily to avoid eager model imports (#50000) by @ydshieh in [#50000]

[Fix] Remove useless kwargs (#49966) by @remi-or in [#49966]

Fix model's config attr naming (#49898) by @zucchini-nlp in [#49898]

Significant community contributions

The following contributors have made significant changes to the library over the last release:

@tarekziade

Fix _init_weights gaps in 7 audio models and enable test_can_init_all_missing_weights for them (#49386)

Fix image backend equivalence tests for Pillow 13 (#50105)

[Janus] Fix processor iterating a string prompt character by character (#50044)

[timesfm] Fix fp16 overflow on pad_val in _forward_transform (#50021)

Pin the shared Hub MIC fleet dataset (#49802)

Remove legacy benchmark/ and disable automatic benchmark runs (#50040)

[minimax_m3_vl] Gate the integration tests on total accelerator memory (#50025)

[moshi] Skip Moshiko integration tests whose checkpoint is gone (#50017)

@eustlb

Add Nemotron 3.5 Transcribe (#50084)

[Nemotron3Diarization] add left context support (#49283)

Original source
All of your release notes in one feed

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

Create account
Get updates with:
Oct 29, 2026
Date parsed from source:
Oct 29, 2026

First seen by Releasebot:
Oct 30, 2026
transformers by Hugging Face

Patch release v5.21.1

transformers fixes rope_scaling initialization in v5.21.1, restoring remote code loading in vLLM.
Patch release v5.21.1

Fix rope_scaling setter for configs that assign it during init (#50080)

We broke remote code loading in vllm, this fixes it sorry everyone!
Original source
October 2026
Date parsed from source:
Oct 29, 2026

First seen by Releasebot:
Oct 29, 2026
CoreWeave

Container runtime selection on CKS

CoreWeave offers private preview access to Kata Containers on CKS, isolating GPU workloads in virtual machines.

Container runtime selection on CKS is available in private preview. Use Kata Containers to isolate GPU workloads in a virtual machine. See Container runtimes on CKS for supported platforms, limitations, and setup instructions. Contact Support to request access.
Original source
Oct 28, 2026
Date parsed from source:
Oct 28, 2026

First seen by Releasebot:
Oct 30, 2026
OpenRouter

How we rebuilt provider routing for better, faster inference

OpenRouter releases a smarter provider routing algorithm that balances price, speed, reliability, and response quality. The new router improves time to first token and throughput while reducing capacity errors, with no code changes required, though costs may rise slightly.
Today we’re announcing the biggest improvement to our provider routing algorithm since the founding of OpenRouter.

Until now, our default router mostly rewarded providers for one thing: a low price. The new router rewards the inference that is actually best for you: cheap, but also fast, high-throughput, and reliable. Providers that deliver more value automatically win more traffic, so every provider has a reason to keep improving. That means the inference you get through OpenRouter keeps getting faster, more reliable, and more cost-effective, and you don’t have to change a line of code.

It’s already working. The new algorithm has unlocked significant improvements in TTFT (16.9%), throughput (16.3%) and capacity errors (a remarkable 46% reduction!), with only minor increases in cost (6.0%). That’s before providers have had any time to optimize for the new algorithm. See our full experimental results for more details.

How it works

It measures what you actually get. For every model, it tracks each endpoint’s realized price, latency, throughput, and error rate, and picks the best blend of cost and performance for each request.

It reacts in real time. When an endpoint has trouble, traffic moves away from it until it recovers.

It rewards better inference. Providers that innovate are automatically rewarded with more traffic.

Routing is still cache-aware, so once we’ve sent you to a provider, your session stays put as long as the cache is warm.

Want price-only routing? You can still have it. See pinning and sorting providers in What stays the same.

Where we were: the limitations of Price-Only Routing

Most traffic (~77% of requests) on OpenRouter goes to models served by more than one provider. When a request doesn’t include an explicit sort or provider list, we need to pick a provider to send it to. Until now, we made that choice based almost entirely on input token price. The less expensive a provider was, the greater percentage of traffic it would receive, and any failed request was re-routed to the next cheapest option.

This price-only approach got users the lowest prices in the ecosystem, but it created some unintended consequences:

Cheap won even when it was bad. Fallbacks caught failures, but users waited through them, and speed improvements weren’t rewarded.

Static rankings. The algorithm was blind to real-time performance variations, so a provider had to degrade to the point of being de-ranked entirely before it was reflected in traffic distribution.

Vanishing margins. The only way for providers to win traffic was to cut price, putting pressure on them to reduce their investments in the very infrastructure that ensures reliability and quality.

Pricing games. The price we ranked by was almost all prompt input price, so a provider could keep traffic share with weird pricing cocktails like listing an artificially low input price and then making back the difference with overpriced cached or completion tokens.

We wanted to ensure a marketplace where competing providers won traffic by serving better inference, not just cheaper inference.

The New Algorithm: optimizing for what a good answer “costs”

The new routing algorithm constantly monitors the performance of each provider to calculate a real-time Routing Cost that captures what a user pays for a good answer. The Routing Cost encompasses the price in actual dollars and cents, the cost of time spent waiting for a response, and the cost of retries when a provider fails or provides an unusable response.

To put it simply: what does one try cost, and how often does it work?

What one try costs: price plus waiting

For each request, the router estimates how many input and output tokens it will use from the model’s recent traffic. That one estimate sets both parts of a try: the price you would pay and the time you would wait.
Effective price
Effective price is the price that the provider would actually charge you, calculated from recent measured traffic. It reflects the provider’s real cache hit rate and the model’s average mix of input and output tokens, so it can differ a lot from the list price. This ensures that a provider can’t win traffic by hiding expensive cached or output tokens behind a low input price.

The router prices your request at each provider’s effective price, and prioritizes the cheapest options.
Throughput
Throughput is what trades off against price: a faster provider can charge more and still win your request. It’s measured as output tokens per second end-to-end, so it includes the time to first token plus the time it takes the provider to stream the entire output response. The router adds that wait to the Routing Cost using a conversion rate set per model, based on what its providers typically charge and how fast they are.
Time to first token
Time to first token (TTFT) is how long you would wait before the response started streaming. It adds to the Routing Cost on its own, even though it already counts toward throughput, because interactive use depends on it most. In an agent session, the model may make many tool calls in a row, and each one waits for a first token.
Rate limits
A rate limit (HTTP 429) means the provider is out of capacity and turned your request away. You would have to wait for the rejection, then your full request would go to another provider. The router adds that wait plus a penalty to the provider’s Routing Cost, weighted by how often it rate limits requests, so the effect is usually small. Repeated rate limits matter more through the traffic caps and backoff described below.

How often it works: reliability and quality

A failed try still costs its price and its wait, so the Routing Cost calculates the expected cost of having to retry until one works. If 1 in 5 tries fails, you pay for 1.25 tries per good answer.
Reliability
A reliability error is a request that fails because of the provider. You would lose the attempt and have to retry, so each error carries a heavy penalty in the Routing Cost.

If a provider’s error rate climbs far above the other providers for the same model, the router stops sending it requests until it recovers.
Quality
Quality measures whether a provider’s responses are usable. Today the main check is whether tool calls come back well formed, and we’re adding more. Each bad response raises the provider’s Routing Cost, because a cheap wrong answer is expensive.

A provider flagged for broken tool calls, or for benchmark accuracy well below what the model should score, drops far behind and only gets a small amount of test traffic until the flag clears.

Close gets close: how traffic is shared

Sending every request to the single best provider would overload it, so traffic is shared. Faster providers can carry a higher Routing Cost and stay competitive. Everything inside the competitive edge shares most of the traffic, and being a little behind the best costs a little. Past the edge, traffic share drops off fast.

Three guardrails sit on top:

Floor: every provider keeps a trickle of traffic, so we can notice when struggling endpoints improve. New endpoints start from the model’s typical numbers, so they don’t need a traffic history.

Back off: a provider that starts failing or rate limiting gets less until it recovers.

Cap: the router learns how much load each provider can take before it returns 429s, and spills the rest to others. Add capacity and the cap rises on its own.

What stays the same

Requests that set provider.order bypass the new routing logic, with providers ordered as specified (default is price-based as before). Setting provider.only or provider.ignore will use the new algorithm to select from the remaining providers if there are more than one.

An explicit provider.sort (price, throughput, or latency) uses that sort instead of the new algorithm. See the provider routing guide for all the details.

Only the first request in a conversation will have a provider algorithmically selected. An ongoing conversation is pinned to its original provider so that the prompt cache stays warm. If that provider becomes unavailable, the conversation will fall back to another provider automatically.

If a try fails, the request is retried with the next highest ranked provider.

How we measured it

In order to measure the impact of the new routing algorithm, we had to go beyond a standard A/B test, because changes in routing behavior can’t easily be isolated from the control group. For example, if the new algorithm did a better job of routing traffic away from a struggling provider, the old algorithm’s requests to that provider would find more capacity available and get faster, skewing the results. Further compounding the difficulty is the enormous variability in request shape and volume patterns. A single whale user that spins up an automated flurry of high effort requests to a single provider can artificially inflate the metrics for that provider regardless of which algorithm we used to route their requests.

So we ran a switchback experiment: We split each day into 3-hour blocks and flipped each matched pair of blocks between the new and old router, with a one-hour burn-in period of discarded data each changeover, and measured the per-model impact across a representative sample of open source models over one full week.

Results

Over the week of the experiment, we split over 24 million requests with 103 billion input tokens evenly between the old and new routing algorithms, measuring the impact on key performance metrics.
Measure Legacy New Algorithm New vs legacy 95% interval TTFT p50 1,007 ms 837 ms 16.9% lower 13.9% to 19.8% lower TTFT p95 4,601 ms 3,733 ms 18.9% lower 15.7% to 21.9% lower Throughput p50 62.4 tok/s 72.6 tok/s 16.3% higher 13.8% to 18.9% higher Cost per K requests $1.25 $1.32 6.0% higher 5.1% to 7.0% higher Cost per M tokens $0.301 $0.324 7.3% higher 4.9% to 9.6% higher Caller TTFT p50 1,130 ms 941 ms 16.7% lower 13.8% to 19.7% lower Caller TTFT p95 6,032 ms 4,504 ms 25.3% lower 21.6% to 29.0% lower Whole request p50 (time to last token) 4.00 s 3.24 s 19.0% lower 14.2% to 23.6% lower Whole request p95 41.5 s 34.9 s 16.0% lower 12.2% to 19.7% lower Hit at least one 429 7.1% 3.8% −3.3 pt 46% fewer -2.5 to −4.2 pt 35% to 59% fewer Needed a retry 10.4% 6.9% −3.5 pt 34% fewer -2.6 to -4.4 pt 25% to 42% fewer Time spent in failed attempts, per req 349 ms 242 ms −106 ms 30% less -35 to −181 ms 10% to 52% less
Frequently asked questions

Do I need to change my code to use the new routing?

No. Requests with no explicit provider sort and no provider order use the new router automatically. Your API key, request body, and model IDs stay the same.

How do I keep price-only routing?

Set provider.sort to price in the request body, append :floor to the model slug, or set your default provider sort to price in account settings. Any explicit sort bypasses the new router.

Does the new routing override my provider order or only list?

provider.order bypasses the new router and routes in the order you specify. provider.only and provider.ignore still filter the candidate set, but the new algorithm picks among the providers that remain.

Will the new routing cost more than price-only routing?

It can, since it will sometimes pick a faster or more reliable provider over the cheapest one. In our live experiment, cost per request increased by 6.0%, while realizing a 16.9% improvement in TTFT, a 16.3% improvement in throughput, and a 46% decrease in 429 error rate.

How does a provider get more traffic under the new routing?

Improve the signals the router scores: effective price, time to first token, throughput, error and rate-limit rates, and output quality.
Original source
Oct 28, 2026
Date parsed from source:
Oct 28, 2026

First seen by Releasebot:
Oct 30, 2026
Baseten

Per-replica metrics

Baseten adds per-replica CPU, GPU, and memory metrics across workspaces to help teams spot outliers and inspect worker performance.

You can now compare CPU, GPU, and memory usage across individual replicas in every workspace to spot outliers hidden by aggregate graphs. Turn on Per replica in the Metrics tab, or open a worker’s metrics directly from its logs with a matching time range.

For more information, see our docs.
Original source
Oct 28, 2026
Date parsed from source:
Oct 28, 2026

First seen by Releasebot:
Oct 29, 2026
Gemini Enterprise Agent Platform by Google

October 28, 2026

Gemini Enterprise Agent Platform updates regional Agent Registry guidance, while the accompanying CodeMender 0.17.0 release adds troubleshooting tools, accessible output, CI/CD improvements, and security fixes.
Change

Use a single regional Agent Registry instance for Gemini Enterprise apps

For Gemini Enterprise apps, we recommend associating each Agent Gateway with a single regional Agent Registry instance in the same project and region as the gateway. Use the us-central1 registry for global and us apps, and the europe-west1 registry for eu apps.

This note updates the September 9, 2026 entry. For more information, see Register your agents and destination resources.

Fixed

CodeMender updates (v0.17.0)

This release introduces updates to CodeMender:

Support bundle diagnostics: Introduce cm support-bundle to collect environment metadata, configuration policies, health reports, and session logs into a compressed archive for streamlined troubleshooting.

Plain output mode: Add the persistent --plain flag (configurable via the CM_PLAIN environment variable or output.plain in config.yaml) to suppress decorative emojis, ANSI escape sequences, and Unicode borders for compatibility with screen readers and CI/CD log pipelines.

Dedicated exit codes for setup failures: Assign distinct exit codes (such as code 10 for credential issues) to configuration and authentication failures, preventing CI/CD pipelines from confusing environment setup issues with security findings.

Tailored CI/CD credential guidance: Provide environment-specific authentication guidance when running inside automated CI/CD systems such as GitHub Actions, GitLab CI, Buildkite, and Jenkins instead of interactive login prompts.

Single-line JSONL statistics: Add the --jsonl flag to cm stats to output single-line JSON records with model and team attribution for seamless integration with Cloud Logging and log aggregation pipelines.

Granular sandbox and policy flags: Replace the overloaded --unrestricted flag with orthogonal flags (--sandbox=false) and configurable command policies to decouple container sandboxing from execution safety controls.

Sandbox configuration protections: Mount .git/hooks, .git/config, and .codemender read-only within writable execution sandboxes during cm fix and cm verify to prevent modifications to repository security policies.

Bug fixes:

Added a security warning when commands are executed with both sandbox isolation disabled and interactive approval skipped.

Enforced allowedRoots path boundaries across host discovery and remediation file operations to prevent traversal via dangling symlinks.

Supplied exact finding line ranges to remediation agents during cm fix to eliminate manual file scanning overhead.

Updated cm report import to properly treat findings without location data as file-level findings rather than defaulting to the first line.

Ensured cm session cancel routes requests to the session's original region regardless of local environment overrides.

Fixed finding status tracking in cm verify so unexploitable verdicts update the local state database rather than leaving findings open.

For more information, see the CodeMender documentation.
Original source
Oct 28, 2026
Date parsed from source:
Oct 28, 2026

First seen by Releasebot:
Oct 29, 2026
Unsloth

Scheduled + Optimizations + Halloween

Unsloth releases new DeepSeek and FLUX models for local use, alongside image and video chat, FSDP2 multi-GPU training, and one-command MCP setup. The update also adds scheduled tasks, multi-LoRA batching, FLUX image editing, saved presets, and performance improvements.
DeepSeek-V4.1-Flash-1017 and FLUX.3 Image Klein are here! Run both locally in Unsloth. Also new: images and videos in chat, multi-GPU training with FSDP2 (alpha) and one-command MCP setup for coding agents.

Highlights

Faster Unsloth: 2x faster first launch, plus speedups for tool calls, model lists, dataset prep and MiniMax-H3 loads

Scheduled tasks: Run a prompt on a schedule with a local model or an API

Multi-LoRA batching: up to 4 compatible queued fine-tuning jobs train together

SGLang thinking + auto-compact: Resume and JSON output now work on vLLM and SGLang too

Browser use switch: let models control the built-in browser from its new tab page

MiniMax-M3.1-Flash: MiniMax's 428B MoE (23B active) Guide

Trick or treat: 🎃 11 Halloween themes

FLUX 3 Editing: FLUX 3 now supports editing of images with prompts

Perf improvements: Large Mac perf gains, less lag, reduced binary sizes

Saved presets: Save your Run settings as named presets for each model

Original source
Oct 27, 2026
Date parsed from source:
Oct 27, 2026

First seen by Releasebot:
Oct 30, 2026
OpenRouter

CSAM Screening Across OpenRouter

OpenRouter introduces in-flight CSAM screening for inference requests, including Zero Data Retention traffic. Flagged content may be retained for human review and legal reporting or preservation, with updated terms clarifying that ZDR content is not retained for unrelated purposes.
OpenRouter will screen all inference requests for child sexual abuse material (CSAM) as they pass through our service. Screening happens in flight, during request processing. Content flagged as potential CSAM may be retained for human review, with reporting and preservation where required by law.

How CSAM screening will work

Known CSAM detection. In-flight screening will include comparing applicable content against hashes (digital fingerprints) of previously identified CSAM.

Review of suspected new CSAM. We may begin retaining content flagged as potential CSAM for human review, including content that does not match a known hash. A flag indicates suspected material; it is not itself a determination that the content is CSAM.

Hash matching detects known material, while classifiers can identify suspected material that has not yet been added to a hash database. The National Center for Missing & Exploited Children (NCMEC) recommends hashing and image classifiers as basic child-safety measures for services handling images and video, including generative AI services (NCMEC’s guidance).

Screening also applies to ZDR traffic

CSAM screening will also apply to requests covered by OpenRouter’s Zero Data Retention (ZDR) policy.

We’re updating our documentation and related terms to make OpenRouter’s own retention commitment explicit:

For inference content covered by OpenRouter’s ZDR policy, we do not retain prompts or responses after processing, except when you explicitly choose to have us store them or when retention is needed for CSAM review, reporting, and related legal preservation.

These CSAM provisions do not authorize general retention of ZDR inference content for unrelated purposes. OpenRouter’s commitment not to use inputs or outputs for model training continues (OpenRouter’s Privacy Policy).

Reporting and preservation requirements

CSAM reporting and preservation duties are established legal obligations. ZDR does not remove those duties.

Under U.S. law, covered providers must report to NCMEC’s CyberTipline as soon as reasonably possible after obtaining actual knowledge of facts or circumstances indicating specified apparent offenses. Reported contents and certain related contextual material must be preserved for one year after submission. That requirement applies to reported material, rather than every item flagged for review (18 U.S.C. § 2258A(a) and (h)).

Provider policies may differ

Model labs and providers may use different screening and retention methods. Some may retain content for a period of time to run automated safety checks before anything has been flagged. Those practices are separate from OpenRouter’s in-flight screening and are governed by the applicable model and provider policies.

OpenRouter documents provider policies so users can understand the requirements that apply to their requests. Review those policies when choosing a model or provider, especially if your organization has specific data-retention requirements.

Looking ahead

AI is opening up exciting possibilities, and the practices surrounding frontier models are evolving quickly. We’re updating our documentation and related terms to describe OpenRouter’s in-flight screening, possible retention of flagged content, and how provider policies are represented. As always, we will keep you informed.
Original source
Oct 27, 2026
Date parsed from source:
Oct 27, 2026

First seen by Releasebot:
Oct 29, 2026
Gemini Enterprise Agent Platform by Google

October 27, 2026

Gemini Enterprise Agent Platform adds preview access to Gemini Robotics ER 2 and general availability for Grok 4.7.

Feature

Gemini Robotics ER 2 (Preview)

Gemini Robotics ER 2 (gemini-robotics-er-2-preview) is available in Preview. Gemini Robotics ER 2 is an embodied reasoning vision-language model built on Gemini 3.5 Flash for robotics applications, including spatial reasoning, agentic code execution, task orchestration, and video understanding.

Feature

xAI's Grok 4.7 is generally available

Grok 4.7 is now generally available (GA) for production use on the global endpoint and the US multi-region endpoint.
Original source

AI/ML Infrastructure Release Notes

Products (19)

Latest AI/ML Infrastructure Updates

joey-1 decision model available on Baseten

v5.22.0: Mistral Large 4 (Le Chonk)

New Models

Mistral Large 4 (Le Chonk)

Key Features

Recommended Settings

Breaking changes

Quantization

Bugfixes and improvements

Significant community contributions

Patch release v5.21.1

Patch release v5.21.1

Container runtime selection on CKS

How we rebuilt provider routing for better, faster inference

How it works

Where we were: the limitations of Price-Only Routing

The New Algorithm: optimizing for what a good answer “costs”

What one try costs: price plus waiting

How often it works: reliability and quality

Close gets close: how traffic is shared

What stays the same

How we measured it

Results

Frequently asked questions

Per-replica metrics

October 28, 2026

Change

Use a single regional Agent Registry instance for Gemini Enterprise apps

Fixed

CodeMender updates (v0.17.0)

Scheduled + Optimizations + Halloween

Highlights

CSAM Screening Across OpenRouter

How CSAM screening will work

Screening also applies to ZDR traffic

Reporting and preservation requirements

Provider policies may differ

Looking ahead

October 27, 2026

Feature

Feature