Open Hackers, Fake Firms, Polite Crawlers · Morning Gist
Saturday, October 315 stories · 16 min
Open Hackers, Fake Firms, Polite Crawlers
Today's edition covers open-weight models in practice, from cyber risk to Mistral's trillion-parameter release, plus test sets, cache routing and opting out of AI training.
Picked from 35 new articles across 24 sources · arrow keys for other days
Today in 30 seconds
30s left
GLM-5.3, an open model with Mythos-level hacking skill, has been public for a month. Lambert sees attacks getting faster, not a sudden jump. story 1 ↓
Microsoft now tests Copilot on three fake companies, each with hundreds of synthetic employees, because it can't test on real customer data. story 2 ↓
Mistral Large 4 has 1T parameters. It's the best open model built outside China, but trails DeepSeek and GLM on hard coding. story 3 ↓
NVIDIA packages Dynamo inference for Kubernetes as tested recipes that route requests to GPUs with cached prompts. Dynamo 1.4 no longer needs NATS. story 4 ↓
OpenAI will honor the IETF's robots.txt opt-out signal for AI training "in the coming months," alongside its existing crawler rules. story 5 ↓
Google stock fell 15%, about $500B, its worst drop since the 2004 IPO, after Google said AI Mode is cutting Search revenue.
1/5Interconnects (Nathan Lambert)· Nathan Lambert· Oct 30
Nathan Lambert revisits his claim that open AI models won't wreck cybersecurity
After a month of serious vulnerability disclosures, Nathan Lambert mostly stands by his view that a leaked hacking-capable model would speed up existing cyber trends rather than cause disaster. He concedes that "fine" undersold the turbulence ahead.
Why it matters · Whether open-weight models get restricted depends on predictions like this one, which can now be checked against real attack data.
Know this first
Context from the editor, not the article · 28 sec
1 · Open-weight vs. closed models
An open-weight model's trained parameters are published, so anyone can run it, fine-tune it and remove its safeguards. A closed model is only reachable through the vendor's API, where use can be monitored and cut off.
2 · Claude Mythos and Glasswing
Anthropic announced Claude Mythos in April 2026 as unusually good at finding software vulnerabilities. It previewed the model through Project Glasswing, a restricted program, instead of releasing it widely. Some people described it as a potential cyber weapon.
3 · Zero-days and exploit chains
2/5Microsoft Research· Somya Chatterjee, Harshita Sahijwani, Min Chen, Sushmitha Rajeswari Muppa, Dayquan Julienne, Irene Shaffer, Chandra Inguva, Jenny Chen, Minha Hwang, Sam Ade Jacobs· Oct 30
Microsoft tests Copilot on fake companies built from public data
Microsoft Research built simulated companies, with staff, emails, meetings and documents, to test its Copilot assistant without using customer data. A six-stage pipeline writes the test questions automatically. Microsoft reports no Copilot results.
Why it matters · If you build retrieval or assistant products over private data, you can't test on real users' data, and this post lays out one way to build a stand-in test set.
Know this first
Context from the editor, not the article · 26 sec
1 · Why enterprise evals are hard
An assistant like Copilot answers questions using a company's own emails, meetings and files. Testing it properly needs data that messy, but real customer data is private and can't be used. Public benchmarks don't have that internal company structure.
2 · What a tenant is
In Microsoft 365, a tenant is one organization's isolated workspace: its own users, mailboxes, calendars, documents and settings. Copilot can only see what is inside the tenant it runs in.
3 · Public data sources used
3/5Latent Space· swyx .ai· Oct 30
Mistral releases Large 4, a 1-trillion-parameter open-weights model
Mistral released open weights for Large 4, a 1-trillion-parameter model built for coding agents and cyber defense. Independent tests rank it the top open model from outside China, about six points behind the Chinese leaders.
Why it matters · If you need a frontier-scale model you can host yourself and that doesn't come from China, this is now the strongest option. The evals show how much quality that choice costs.
Know this first
Context from the editor, not the article · 25 sec
1 · Mixture-of-experts models
Large open models are often mixture-of-experts: many sub-networks ("experts"), of which only a few run for each token. Total parameters set the memory bill. Active parameters set the compute per token.
2 · Who leads open weights
Since late 2025, Chinese labs (DeepSeek, Zhipu's GLM, Moonshot's Kimi, Alibaba's Qwen) have released the strongest open-weights models. Western alternatives matter to users such as governments that can't adopt Chinese models.
3 · Artificial Analysis
Artificial Analysis (AA) is an independent firm that runs the same benchmark suite on every model and publishes composite scores. Its Intelligence Index is a common neutral reference point next to vendors' own claims.
4/5NVIDIA Technical Blog· Stefan Schimanski· Oct 30
NVIDIA's AI Cluster Runtime packages Dynamo inference on Kubernetes as tested recipes
NVIDIA's AI Cluster Runtime (AICR) bundles its Dynamo inference server with GPU drivers, schedulers, monitoring and ingress into version-pinned Kubernetes recipes. It then checks the live cluster before any model is deployed.
Why it matters · For agent-style workloads, much of serving cost depends on routing each request to a GPU that still holds that conversation's prompt in its cache. This post shows how NVIDIA wires that routing into Kubernetes.
Know this first
Context from the editor, not the article · 29 sec
1 · What KV caching saves
While reading a prompt, a transformer stores intermediate key/value tensors, called the KV cache. If a later request shares the same opening tokens and lands on a GPU that still holds them, that GPU can skip recomputing that part of the prompt.
2 · Prefill versus decode
Inference has two phases. Prefill processes the whole prompt in parallel and is limited by compute. Decode produces one token at a time and is limited by memory bandwidth. Running them on separate GPU pools is called disaggregated serving.
3 · Kubernetes building blocks
5/5OpenAI· Oct 30
OpenAI will honor a shared robots.txt signal that opts sites out of AI training
OpenAI says it will respect one common robots.txt signal that tells all participating AI companies at once whether a site's content may be used to train generative models. Sites currently need separate rules for each crawler.
Why it matters · Training-data access is becoming a standards question rather than a crawler-by-crawler arms race, and that affects both what models learn from and what site operators need to configure.
Know this first
Context from the editor, not the article · 32 sec
1 · How robots.txt works
robots.txt is a plain-text file at a site's root that tells automated crawlers which paths they may fetch, with rules grouped by crawler name (user-agent). It is a convention, standardized as RFC 9309 in 2022. Compliance is voluntary and nothing enforces it.
2 · Per-company AI crawlers
Each AI company publishes its own crawler names. OpenAI's include GPTBot, which collects training data, plus separate agents for search and for user-requested fetches. Google uses a token called Google-Extended. A site that wants to block training has to list each one.
A zero-day is a flaw that defenders don't know about yet. Real attacks usually chain several steps together: find a bug, build a working exploit, deliver it to victims, then act on the access gained.
Exponential rise in vulnerabilities, the curve Lambert says we are still climbing.1 / 2
Commentators have started calling this month "Black October." It brought a wave of critical vulnerability disclosures, including PHP2Shell and a GitLab flaw, plus a major security incident at the crypto exchange Binance. Against that backdrop, Nathan Lambert, who writes the Interconnects newsletter, revisits a claim that drew heavy pushback. His claim was that if Anthropic's 1 had leaked as an 2 model, "the world would have been more or less fine."
The claim and his evidence
Anthropic previewed Mythos in April through 3, a restricted-access program, as a model with unusually strong ability to find software bugs. Lambert says the framing made it sound like a cyber weapon. His test case is 4. It is an open-weight model, meaning its trained parameters are public and anyone can run it, and he says it matches that capability level. More than a month after its release, he sees no step change in harm. He sees an acceleration of trends that were already underway.
To counter critics who say nobody predicted disaster, he cites April 2026 quotes. Rob Wiblin said a leak "would be an actual disaster." Anthropic wrote that the fallout "could be severe." Zvi Mowshowitz predicted "chaos." Lambert argues that whatever the exact wording, the public and federal government heard "weapon."
Why discovery isn't damage
Lambert treats an attack as a multi-stage pipeline. 5, a research group that tracks AI progress, used GLM-5.3 to build a website that steals files from any Firefox user who visits it. Still, someone has to host that site, lure victims and use the stolen data. He also quotes a practitioner's point that attackers run like businesses with fixed routines. Phishing gangs don't switch to writing exploits just because a 6, a publicly catalogued vulnerability, gets published.
What he concedes
"Fine" was underspecified. Lambert expects an expensive, forced overhaul of how software is secured. He credits safety voices who called this a new era of instability rather than a catastrophe. So far the damage has hit companies running large digital products, not public infrastructure, but he says that could change.
His bigger point
Lambert argues the open-vs-closed question is mostly a distraction:
Closed models are doing most of the work. He guesses, with high uncertainty, that closed models are finding most of the new bugs. Large open models are costly to serve and compute is sold out.
The trend predates ChatGPT. Security analysts like Joshua Saxe show exploits growing exponentially since well before ChatGPT. If AI were the bottleneck on attacks, their charts would show a jump. They don't.
He calls cyber a societal problem that AI labs alone can't fix.
Nathan Lambert, who writes the Interconnects newsletter, is revisiting a prediction made against a bad backdrop. Commentators have started calling this month "Black October." It brought a run of critical vulnerability disclosures, including PHP2Shell and a GitLab flaw, followed by a major security incident at the crypto exchange Binance. Lambert's take from a few weeks earlier drew a steady stream of pushback: an 1 version of Anthropic's 2, released in April, "would've been fine." This post is his reckoning with that claim. He mostly stands by it and gives ground on one word.
The original claim
Anthropic announced Claude Mythos as a model with unusually strong ability to find software vulnerabilities, and previewed it through 3, a restricted-access program. The framing, Lambert says, made Mythos sound like a new class of cyber weapon that could destabilize society in the wrong hands.
His counterevidence is 4, an open-weight model from China's GLM model family. Its weights are public, so anyone can run it without the vendor's monitoring. Lambert says it crosses the same capability threshold "by all measures." More than a month after release, he sees little public evidence that it caused a step change. He extends the argument to Mythos itself: if Mythos had leaked as open weights, cyber incidents would have clearly risen, but the result would look like acceleration, not a discontinuity.
He also frames the other side's position as a falsifiable prediction. People warning about open weights are effectively claiming that current open models will cause new kinds of harm by crippling cyber infrastructure. Lambert thinks they are set up to be wrong. He adds that after years of abstract debate about open-weight risk, the field will finally get real data.
Checking the receipts
Critics told Lambert that nobody in the AI safety community had called an open Mythos a "true disaster." He went looking and quotes three sources from April 2026:
Rob Wiblin, host of the 80,000 Hours podcast (April 10): "If it fell into the hands of criminals or hostile state cyber actors, it would be an actual disaster."
Anthropic's Glasswing announcement (April 7): as capabilities proliferate beyond careful actors, "the fallout—for economies, public safety, and national security—could be severe."
Zvi Mowshowitz (April 9), whom Lambert calls more reasonable: Mythos "would give attackers a cornucopia of 5 exploits for essentially all the software on Earth … It would be chaos."
Lambert's point is less about exact wording than about how such statements land with the public and with federal policymakers, who came away hearing "cyber weapon." On Zvi's "chaos," he notes that so far it has been confined to companies running large digital products. He adds that this could change.
Why finding a bug isn't the same as harm
His main mechanical argument is that a cyberattack is a pipeline, and AI speeds up only some stages. He uses 6, a research group that tracks AI progress, as an example. Epoch used GLM-5.3 to build a website that, when a Firefox user visited it, let the attacker pull files off the user's computer with no further interaction.
That is a serious exploit. But to cause harm, an attacker still has to stand up the malicious site, get targets to visit it, and use what they steal. The model handled the discovery step. The rest of the chain still depends on people, infrastructure and motive.
He backs the motive point with a tweet he found apt. It argues that threat actors behave like businesses with set processes: "A bakery isn't going to start making dog food because there's a dog food shortage." Phishing crews don't drop their playbook to "vibecode" exploits when a critical 7 (a publicly catalogued vulnerability) appears. The people exploiting the new bugs are the ones who were already in that line of work.
Where he concedes
Lambert says he is not a cyber expert and is "nervous" about his position. He says "fine" needed definition. What is coming is a forced, expensive overhaul of how the industry builds and secures software. For readers who already expected a hard period, "fine" fits. For those who didn't, it undersells. He also credits parts of the safety community who described this as a new era of cyber instability without predicting catastrophe. The line he cares about is between "tech companies must work much harder to keep us secure" and "public infrastructure is actually going down." So far events sit on the first side of it. A Wall Street Journal report that cyber first responders are strained looks to him like the system working.
Open vs. closed is the wrong frame
Lambert's main argument is that this is about AI capability and diffusion in general, not openness:
Who is finding the bugs. He guesses most of the new vulnerabilities are being found with closed models, though he says his uncertainty is high. Large open models are expensive to serve and compute is sold out. If an open model shows up in a hack soon, he expects it will come through a poorly secured hosted API, not someone running the weights at home.
Offense-defense balance. He argues open models help defenders, and that well-funded companies will adopt them faster than most attackers, who have fewer resources.
The key unknown. The open question is whether any actor is willing to turn these tools on public institutions to cause physical harm in the U.S. or its allies. Adversaries have probably used them for quiet, large-scale data theft. Mass disruption hasn't appeared.
Concentration. Longer term, he expects open-model serving costs to fall as compute gets more plentiful. Part of his advocacy is meant to prevent a world where a few companies sell both the tools that write vulnerable software and the tools that fix it.
He points to security practitioners such as Joshua Saxe and Chris Hughes. They take an ecosystem view: exploits and cyber damages have been growing exponentially since long before ChatGPT, and October is on that trend. If AI capability were the bottleneck on attacks, ecosystem-level charts like Saxe's would show a visible jump. They show a continuing curve. Lambert expects that curve to eventually flatten out at the top of its S-shape, though he says that will take a long time.
What's left open
The evidence is still early. One month of GLM-5.3 availability is a short window, attribution in hacks is murky, and Lambert's estimate of closed-model involvement is admittedly a guess. His closing claim is a normative one: cyber is a societal problem that AI labs alone, and the "San Francisco centric tech industry," can't solve. He calls it the first of many such transitions.
Remember
Lambert's test: if AI were the bottleneck on attacks, charts of cyber damage would show a jump, not a continuing exponential curve.
Finding a bug is one step; turning it into harm still needs infrastructure, delivery and a motivated attacker.
He guesses closed models, not open ones, are finding most of the new vulnerabilities, though with wide uncertainty.
O*NET is the U.S. Labor Department's database of jobs and the tasks each involves. SEC filings are the reports public companies must file with the U.S. securities regulator, covering structure and finances.
The platform's three parts: synthetic tenants, automated query generation and quality checks.1 / 3
Microsoft Research has described how it tests 1, its AI assistant across Office, email and Teams, without using any customer data. The team builds fake companies with synthetic employees, emails, meetings and documents, and generates test questions about them automatically. The system is called the Industry Evaluation Data Generation Platform. Microsoft now uses it as Copilot's first standardized internal evaluation baseline.
The problem
To check that Copilot summarizes a meeting accurately and cites the transcript correctly, you need test data as messy as a real company. That means reporting lines, project histories and email threads that develop over weeks. Real customer data has all of that but is off-limits. Hand-written test fixtures are too small, and generic benchmarks miss failures specific to one industry.
Fake companies built from public data
The team generates complete synthetic 2. In Microsoft 365, a tenant is one organization's isolated workspace with its own users and data. Three public sources make the tenants realistic:
3, the U.S. Labor Department's occupational database, sets each role's duties and how often each kind of work happens.
Job postings supply realistic job titles and reporting chains.
4, the reports public companies file with the U.S. securities regulator, set company size and business units.
The tenants change over time, so time-dependent questions like "what did the team decide last Thursday?" can be tested. There are three: a pharmaceutical company, a capital-markets firm and a software company. Each has hundreds of users with complete communication histories.
Writing the test questions
A six-stage pipeline produces the queries:
Take generic workplace tasks.
Filter them by industry.
Add domain language.
Use a model to ground each query in the tenant's actual data.
Rewrite it to sound human.
Check it for accuracy and uniqueness.
An internal framework scores the synthetic data on 5, contextual relevance, behavioral realism and content safety.
Results
A composite score of how realistic the data is rose 39% over the team's first approach. Some tenants scored above 0.9 out of 1.0.
Building a dataset went from days of manual work to an automated run. The team estimates savings of about $100,000 per dataset and $300,000 across the project.
The same configuration now produces an identical dataset. The authors rank this above the savings, because it lets teams compare results across releases.
What's missing
All of these numbers measure how realistic the synthetic data is, scored by Microsoft's own framework. None of them measure Copilot. The post reports no Copilot scores, no failures the tenants caught, and no evidence that results on synthetic data predict real-world quality. It also doesn't explain how a test answer is graded. The privacy case is stronger: fully synthetic data needs no privacy review, which is why teams could share it widely. Next, the team wants to evaluate multi-turn agents and systems that take actions.
Microsoft Research has described the system it now uses to test 1, its AI assistant inside Office, email and Teams. The team builds fake companies, fills them with synthetic employees, email threads, meeting transcripts and documents, and then generates test questions about them automatically. The system is called the Industry Evaluation Data Generation Platform. It now sits in an internal catalog as what Microsoft calls the first standardized evaluation baseline for Copilot. The post explains how the test data is built. It reports nothing about how Copilot scored on it.
The problem
A typical Copilot request is something like "summarize this safety review meeting and list the action items." A good answer has to be accurate and complete, and it has to cite the transcript correctly. Checking that takes a test environment as tangled as a real company: reporting lines, project histories, email threads that build up over weeks, and jargon specific to an industry. Real customer data has all of that, but the authors say it "cannot be used for evaluation under any circumstances." Small hand-written test fixtures avoid the privacy problem but miss the complexity. Generic public benchmarks miss failures that only show up in a particular industry.
Synthetic 2 grounded in public data
In Microsoft 365, a tenant is one organization's isolated workspace, with its own users, data and settings. The team generates complete synthetic tenants and anchors them to three public sources, which Microsoft's legal team reviewed:
3, the U.S. Department of Labor's occupational database. It shapes what each synthetic employee's role involves, how often they do each kind of work, and industry workflows such as clinical trial reviews.
Online job postings, for realistic job titles, reporting chains and the makeup of departments.
4, the disclosures public companies file with the U.S. securities regulator. These set company size, business units and financial context.
The tenants also change over time. Meetings pile up, projects move along, email threads develop over weeks, and the org chart shifts. The authors say this matters because many Copilot questions depend on time, such as "What did the team decide last Thursday?" or "What's changed since the last quarterly review?" A static snapshot can't test those.
The team built three tenants:
a pharmaceutical company with regulatory submissions, clinical trial discussions and cross-functional safety reviews
a capital-markets firm with deal pipelines, compliance communications and client portfolio reviews
a software company with sprint planning, code reviews and product launches
Each tenant has hundreds of users with complete communication histories. The post doesn't say which model generates the content or how the simulation is driven.
Generating the questions
Test questions are the second bottleneck. Writing thousands of grounded, industry-specific queries by hand is slow and expensive. The team built a six-stage pipeline:
Start from a large library of generic workplace tasks.
Filter them to the ones that fit the target industry.
Adapt them with that industry's language and context.
Use a model to generate queries grounded in the tenant's actual data.
Rewrite the queries so they sound like a person typed them.
Check each query for accuracy and uniqueness.
Here is an illustrative example of how a query moves through the stages; it is not from the post. A generic task like "summarize a meeting and extract action items" becomes "summarize the safety review" in the pharma tenant. It then gets tied to a specific transcript in that tenant, and finally rewritten as something like "what came out of Tuesday's safety signal review and who owns follow-ups?" The post doesn't explain how the correct answer for each query is defined or how Copilot's responses are graded.
Checking the synthetic data
An internal "semantic evaluation framework" scores the generated tenants on:
Structural fidelity: realistic reporting hierarchies, team sizes and cross-functional links
Contextual relevance: whether the queries and workflows match real enterprise usage
Behavioral realism: whether simulated users communicate and collaborate the way people do
Content safety: no harmful material, no personally identifiable information, and no impersonation of real people
The post introduces these as "three dimensions" and then lists four.
Results
A composite quality score improved 39% over the team's first generation approach. Some industry tenants scored above 0.9 out of 1.0. The gains came from adding real industry signals and from using the composite metrics to drive automated fixes.
Building a dataset went from several days of manual work to an automated run. The team estimates savings of about $100,000 per dataset and $300,000 across the project.
The same configuration now regenerates an identical dataset. The authors rank this above the cost savings, because it lets teams compare results across releases and across teams.
How to read the numbers
The quality numbers are internal scores of how realistic the synthetic data looks, measured by Microsoft's own framework against its own earlier versions. The post doesn't say how "real enterprise patterns" are measured without real enterprise data to compare against. That question sits at the center of any synthetic-data approach, and the post leaves it open. It also doesn't name any Copilot failures the tenants caught, give model scores, or say how well results on synthetic tenants predict satisfaction among real users. The headline promises "real Copilot confidence," but no evidence links the two.
There is a further risk the post doesn't discuss. Tenants and queries are both written by models, so a model-based assistant may find them easier, or differently hard, than the messy human text in real tenants.
The privacy argument is clearer. Fully synthetic, safety-screened data needs no privacy review. That is what made it possible to share across teams and reuse for 5. The authors present this as the reason the platform was adopted widely.
What's next
The team names three problems it hasn't solved: evaluating multi-turn agent interactions, simulating organizations that change over months or years, and evaluating systems that take actions instead of only producing text.
Remember
Simulated organizations need history that changes over time; static snapshots can't test questions like "what changed since last week?"
All the reported gains measure how realistic the synthetic data is. The post shows no Copilot accuracy results.
Fully synthetic data skips privacy review, and the authors say that is what let teams share and reuse it.
The parameters actually used to process each token in a mixture-of-experts model; here 52 billion out of 1.05 trillion.
Image: Latent Space
Mistral has published open weights for Mistral Large 4 ("Le Chonk"), the finished version of a model it previously shipped as a Preview. It targets agentic coding (models that edit code and run tools over many steps) and cybersecurity defense.
What it is
Large 4 is a 1 (MoE) model: each token runs through only 4 of 128 expert sub-networks, plus one shared expert. That gives about 1.05 trillion total parameters but only 52 billion active per token. It reads text and images, accepts 1 million tokens of context and can write up to 256K tokens of output. Mistral says it trained the model from scratch on 3,800 NVIDIA Grace Blackwell GPUs.
The API price is $0.70 per million input tokens and $2.10 per million output tokens, about half the Preview's price. The license lets anyone run the weights. Companies selling the model as a hosted service need a separate commercial license.
How it actually scores
Mistral claims the #1 spot among open models on 2, a coding benchmark from Cognition, and a 64% human-preference win rate over GLM 5.3 and Kimi K3. Independent results are more modest.
3 (AA), an independent evaluator, scores it 26 on its Intelligence Index. That is narrowly the best open model built outside China, but 6 points behind DeepSeek V4.1 Flash and GLM-5.3.
On FrontierCode 2.0 it scores 15%, against 29% for DeepSeek and 22% for GLM-5.3. The article doesn't explain the conflict with Mistral's claim.
Its clearest strength is efficiency. On AA's coding-agent index it scores 48 using 8.5M tokens per task, while GLM-5.3 scores 49 but needs 15.9M.
On AA's factual-recall test, the hallucination rate fell from 41% to 28%, but accuracy is just 26%.
Running it yourself
Tooling was ready on day one:
Serving:4, a popular inference server, serves 8-bit and 4-bit versions. Its built-in draft model, which guesses tokens for the large model to check, speeds output about 2x.
Local use: Unsloth's 1-bit build shrinks the weights from 1.1TB to 223GB and runs on a Mac Studio.
Reinforcement learning: A short run of reinforcement learning with low-rank adapters (5) raised a math benchmark score from about 64% to 75%.
The skeptical view
Commenters argue that Mistral's compute, roughly 5–10x less than Meta's, likely left the model undertrained. Some say DeepSeek V4.1 is smaller, faster and smarter for local use, and that Large 4's real audience is governments and companies that need a non-Chinese model. Mistral's cyber-defense claims have not been independently verified.
Mistral has published open weights for Mistral Large 4, which it nicknames "Le Chonk." This is the finished version of a model that previously shipped as a Preview. Mistral aims it at agentic coding (models that edit code and run tools over many steps) and at cybersecurity defense. Companies can customize it through Mistral Forge, the company's fine-tuning service. The release is covered in Latent Space's AINews digest. It matters because Large 4 is now the strongest open model built outside China. The independent numbers also show how far it still trails the Chinese leaders.
What was released
Large 4 is a 1 (MoE) model. Only part of the network runs for each token. It has about 1.05 trillion total parameters and 52 billion active ones. Each token is routed to 4 of 128 "routed" experts, plus 1 "shared" expert that every token uses. Other specs:
a 1-million-token context window
text and image input, with variable-resolution vision in the style of Pixtral, Mistral's earlier vision model
up to 256K tokens of output
configurable reasoning effort (Mistral describes three modes), function calling and strict JSON-schema output
support for more than 160 languages
Mistral says it trained the model from scratch on 3,800 NVIDIA Grace Blackwell GPUs on European infrastructure.
The API price is $0.70 per million input tokens and $2.10 per million output tokens ($0.07 for cached input), roughly half the Preview's price. The license is a modified MIT-style "Ecosystem Open-Weight License." Anyone can download and run the weights, but businesses that sell the model as a hosted service need a separate commercial license.
Mistral's claims versus independent results
Mistral's own claims:
#1 among open models on 2, a coding benchmark from Cognition
51% on AA's Cyber Index and 96.6% refusal on malicious cyber prompts
cyber-defense testing by CrowdStrike, Cloudflare, Zscaler and others
a 64% human-preference win rate against GLM 5.3 and Kimi K3, reported by a Mistral researcher
Independent evaluators give a more modest picture:
The token efficiency is the clearest real improvement. Agent workloads are billed per token, so finishing a task in half the tokens can matter more than a point of benchmark score.
For scale, AA's new Progress Index puts the median gap between open-weights models and the closed frontier at about four months. China has led open weights since September 2025.
Architecture, per community analysis
Mistral hasn't published the details. A community analysis by Elie Bakouch reads the following from the released weights:
It uses full sparse attention like DeepSeek V3.2 and GLM 5. A small "indexer" picks which earlier tokens each token should attend to, instead of attending to all of them.
Layers alternate between RoPE (rotary position encoding) and 5 (no positional encoding). After layer 35, NoPE layers share one KV cache, the stored keys and values of earlier tokens. From layer 17, RoPE layers share indexers. Both changes cut memory and compute at long context.
SSMax rescales attention scores per head, which helps keep attention sharp over long inputs.
LeRoPE combines YaRN, a standard method for stretching rotary positions to longer contexts, with a learned per-frequency adjustment.
There is no KV compression, unlike DeepSeek's latent-attention approach.
Tooling on day one
Support arrived with the release:
The skeptical read
Commenters on r/LocalLlama raised three main points:
Undertrained: Mistral's roughly 4K GPUs are an estimated 5–10x fewer than labs like Meta have, so the model may be undertrained. One commenter argued that fine-tuning could unlock a lot, as it did for Mistral Medium 3.5.
Not for local use: Another called it uncompetitive for local inference against DeepSeek V4.1, which they described as smaller, faster and smarter.
Who it's for: Several said the model is most valuable to organizations already tied to Mistral, such as governments and industrial users, and less so to hobbyists. Some asked for a return to 3B–30B models.
Open questions
Cyber claims: Mistral's cyber numbers are self-reported. One researcher's claim of finding four zero-days in a messaging app in two hours comes with no public details.
Benchmark conflict: The mismatch between Mistral's FrontierCode claim and AA's 15% is unexplained.
Low accuracy: A 26% score on factual recall means the drop in hallucination rate doesn't make it a reliable source of facts.
Remember
Mistral claims #1 on FrontierCode, but Artificial Analysis measures 15%, behind DeepSeek's 29% and GLM-5.3's 22%.
Matching GLM-5.3 on agent tasks with about half the tokens is its most credible advantage.
A 1-bit quantization fits the trillion-parameter model in 223GB, small enough for a Mac Studio.
Helm charts package Kubernetes software. Custom Resource Definitions (CRDs) add new object types. The Gateway API is the newer standard for routing HTTP traffic into a cluster, replacing the older Ingress resource.
Frontend router path: the Frontend picks a vLLM worker over TCP, and cache events return over ZMQ.1 / 2
NVIDIA has published a walkthrough of 1, an open-source tool for deploying 2, its distributed inference framework, on Kubernetes. AICR packages Dynamo and everything it depends on into "recipes": fixed component versions that NVIDIA has tested together, plus checks that confirm a live cluster matches them. It is a how-to post with no performance numbers.
The problem
A Dynamo model deployment is described by a DynamoGraphDeployment, a Kubernetes custom resource that says how inference engines such as vLLM run in pods. Below it sit many dependencies: the GPU driver stack, node labeling, Dynamic Resource Allocation (DRA, Kubernetes' API for claiming GPUs), a scheduler that can start a job's pods all together (3), node-health monitoring, Prometheus, and optionally a gateway. The NVIDIA recipe for Amazon EKS on GB200/GB300 NVL72 systems pins 17 Helm charts, one of them an alpha release. Dynamo 1.4 also stops installing the 4 message broker by default. Components now find each other through Kubernetes itself.
Cache-aware routing
Agentic sessions keep extending the same long prompt. If a request lands on a GPU that doesn't hold that prompt's 5 (the stored attention state), the GPU recomputes it. Dynamo avoids this by routing on live cache state. Each vLLM worker publishes cache events over 6, a lightweight messaging library, while requests themselves travel over TCP. The router could instead guess cache contents from where it sent past requests. NVIDIA notes that guessing can't see evictions, so it drifts under memory pressure.
There are two ways to deploy this:
Frontend router: a Dynamo Frontend behind a Kubernetes Service scores workers on prefix overlap and load, then forwards the request. This is the smallest setup and, NVIDIA says, the most proven in production.
7 plus the 8: a shared gateway asks Dynamo's EPP which pod should take the request, then forwards it itself. This suits platform teams that want retries and timeouts handled by shared ingress.
Both paths make the same routing decision. What differs is which component moves the bytes to the worker. Dynamo 1.5 replaces the EPP's Go-to-Rust bridge with native Rust, which NVIDIA says reduces per-request overhead. It gives no number.
The workflow
The steps are aicr snapshot, then aicr recipe, then aicr bundle (output for Helmfile, Argo CD or Flux), then deploy, then aicr validate. Validation checks GPU capacity, operator health, gang scheduling, autoscaling, metrics and gateway readiness before the model is installed. Performance testing is a separate step.
The post includes no cache-hit rates and no comparison between the two paths.
NVIDIA has published a walkthrough of 1, an open-source tool for deploying 2, its distributed inference framework, on Kubernetes. The point it makes is simple. Getting a model running needs much more than Dynamo itself. AICR's answer is to ship the whole stack underneath Dynamo as a "recipe": a fixed set of component versions that NVIDIA has tested together, plus checks that confirm a live cluster actually matches it. This is a how-to post with no latency or throughput numbers, but it shows clearly how NVIDIA now expects cache-aware routing to fit into Kubernetes.
The problem: everything below the model
In Dynamo, you describe a serving setup with a DynamoGraphDeployment. This is a Kubernetes custom resource that says how vLLM, SGLang or TensorRT-LLM (three inference engines) should run in pods. That object sits on top of a long list of dependencies, and each one is its own project to install and configure:
a GPU driver stack that matches the nodes (the GPU Operator)
GPU nodes labeled so the scheduler can find them (Node Feature Discovery)
GPUs exposed through 3, Kubernetes' newer API for claiming devices
a scheduler that supports gang scheduling (4). Gang scheduling means all pods of a multi-part job start together or none do.
Problems usually come from version mismatches between these pieces, not from any single one. For AICR v1.0.0's recipe for Amazon EKS on GB200/GB300 NVL72 systems, the post lists 17 pinned Helm charts. Examples include GPU Operator v26.7.1, DRA driver 0.5.0, KAI Scheduler v0.16.9, Grove v0.1.0-alpha.13 and Dynamo Platform 1.4.2. Grove's alpha tag is worth noticing. The recipe also records node selectors, tolerations, checksums and what validation should expect.
Dynamo 1.4 also simplified the stack. Frontends, workers and routing components now find each other through Kubernetes resources, so the dynamo-platform chart no longer installs 5, a message broker, by default. NATS is still available as an opt-in. The DynamoGraphDeployment API moved from v1alpha1 to v1beta1.
Why routing is the interesting part
Agentic workloads keep extending the same long prompt: the system prompt, tool definitions, conversation history and tool results. If turn 12 of a session goes to a GPU that doesn't hold the 6 for turns 1–11, that GPU recomputes the whole shared prefix. A worked example with illustrative numbers: with a 40k-token shared prefix and a 500-token new turn, a cache hit prefills about 500 tokens and a miss prefills about 40,500.
Dynamo supports disaggregated serving, where prefill and decode run on separate GPU pools. On a cache miss, the prefill pool has to reprocess the missing prompt before decode workers start generating. Disaggregation lets operators size the two pools separately for their request mix.
To route well, the router needs to know what each worker actually has cached. In 1.4.2, requests travel over TCP (the "request plane"). Cache state travels on a separate "event plane" built on 7, a lightweight messaging library. Each vLLM engine publishes raw KV-cache events locally (--enable-prefix-caching plus a ZMQ publisher on port 5557). Dynamo's worker runtime normalizes these events and republishes them.
The post also describes an alternative: the router can predict cache state from where it sent each request. The catch is that prediction can't see evictions. Under memory pressure the router's picture drifts away from reality and routing gets worse. AICR's configuration uses the live events instead.
Two routing paths
Path 1: Dynamo Frontend router. A Dynamo Frontend sits behind a plain Kubernetes Service. With DYN_ROUTER_MODE=kv, it tokenizes each request, scores workers on prefix overlap and current load, picks one, and sends the request over TCP. NVIDIA calls this the smallest and most production-proven topology. It suits a team that owns one model endpoint.
Path 2: 8 plus the Dynamo 9. GAIE is a Kubernetes extension that adds model-aware load balancing to Gateway API. Here, a gateway (agentgateway in the example) matches an HTTPRoute to an InferencePool. The Dynamo operator generates that pool from the DynamoGraphDeployment. The pool's selector names the eligible worker pods, and its points at the Dynamo EPP.
The gateway asks the EPP which pod should take the request. The EPP tokenizes the request, runs Dynamo's KV router, and returns its choice. The gateway then forwards the request itself, to a Frontend sidecar in the chosen pod. That sidecar runs with --router-mode direct, so it accepts the choice without routing again. This path suits platform teams that want timeouts, retries and fallback handled by shared Gateway API ingress.
Both paths make the same cache-aware decision from the same worker-published state. NVIDIA frames the difference as one question: who handles the transport to the worker, the Dynamo Frontend or the gateway?
There is one implementation detail. In 1.4, the EPP is GAIE's Go framework with Dynamo's Rust router embedded through 10, Go's bridge for calling C-compatible code. Dynamo 1.5 replaces this with a native Rust EPP. It implements GAIE's lightweight ext_proc interface directly, runs the full router in-process, and is configured with DYN_* environment variables. NVIDIA says this cuts per-request overhead but gives no figure.
The workflow
AICR keeps runtime setup separate from the application deployment:
aicr snapshot captures the cluster. By default it targets nodes labeled nvidia.com/gpu.present=true.
aicr recipe --intent inference --platform dynamo detects the Kubernetes distribution, the GPU and the node OS, and emits a pinned recipe. Offline validation against a different snapshot is optional. It evaluates declarative constraints only and skips behavioral checks.
aicr bundle renders Helm values and manifests, with node selectors and tolerations for GPU and system nodes. It can target Helmfile, a plain deploy.sh, Argo CD or Flux.
helmfile diff / apply installs components in order of their dependencies, running independent components in parallel.
aicr validate --phase deployment --phase conformance runs validator Jobs on the live cluster.
Validation covers GPU allocatable capacity and a working nvidia-smi, GPU Operator and Dynamo operator health, DRA and secure accelerator access, gang scheduling, pod and cluster autoscaling, Prometheus metrics, and gateway readiness. The application is deployed only after these checks pass. Performance validation runs separately, because it takes over the GPUs being tested.
What's left open
The post shows no evidence that the routing works: no cache-hit rates and no comparison of the Frontend path with the EPP path or of live events with prediction. The recipe shown targets EKS on NVL72 systems. The post doesn't say how many other platforms have recipes, or how quickly the pins track upstream releases.
Remember
Dynamo routes using cache events that workers report. Guessing cache contents misses evictions and drifts under memory pressure.
Both routing paths make the same cache-aware decision. They differ in whether Dynamo or the gateway forwards traffic.
Dynamo 1.4 drops NATS by default, and Dynamo 1.5 replaces the Go/CGO endpoint picker with native Rust.
The Internet Engineering Task Force (IETF), the body behind most internet protocol standards, set up an AI Preferences working group in 2025. Its job is to define a shared vocabulary for how content owners state preferences about AI use.
Image: OpenAI
What OpenAI announced
OpenAI says it will honor a common signal in robots.txt, the file at a website's root that tells crawlers what they may do. The signal lets a site say whether its content may be used for "foundational generative AI training," and every participating AI provider would read the same line. It comes from the 1 of the 2, the body that sets most internet protocol standards. OpenAI says other working-group members announced it on the same day, but doesn't name them.
Nothing changes yet. OpenAI plans to implement the signal "in the coming months" and will publish details when it does.
The problem
robots.txt groups its rules by 3, the name each crawler reports. Each AI company runs its own crawlers. OpenAI alone has 4 for training plus separate agents for search and for user-requested fetches. A publisher who wants to stay out of training sets but stay visible in search has to track every provider's crawler names and keep the file current. Miss one and the opt-out has a gap.
A shared signal changes the question from "which bots may fetch this page?" to "what may anyone do with it?" For example, a site could write one rule saying "no AI training" instead of one block per company. That's an illustration only: the post doesn't give the actual syntax.
What stays the same
OpenAI says the new signal adds to its existing controls and doesn't replace them. Rules aimed at GPTBot and its other named crawlers will still be respected, so sites get both a provider-neutral preference and per-crawler control.
Caveats
Training only. The stated scope is foundational model training. The post doesn't say whether the signal affects AI search or fetching pages to answer users' questions.
Voluntary. Like robots.txt itself, nothing enforces it. OpenAI urges other providers to adopt it.
Not final. The IETF standard is still being written, and OpenAI says it will adapt as that work evolves.
Forward-looking. Nothing suggests it applies to content already collected.
OpenAI frames this as support for an open web. A widely adopted opt-out also gives AI companies a clear rule: content without the signal is arguably fair to use. Search engines made the same trade with robots.txt decades ago. Whether it matters depends on how many providers sign on and whether publishers trust it.
The announcement
OpenAI says it will honor a common signal in robots.txt that lets a website state, once, whether its content may be used for "foundational generative AI training." The signal comes from the Internet Engineering Task Force's (IETF) 1, a standards group defining how content owners express preferences about AI use. OpenAI says other members of the working group announced the same signal on the same day. The post doesn't name them.
The company says it will implement the signal "in the coming months" and publish implementation details then. So nothing has changed yet.
The problem it addresses
robots.txt sits at the root of a website and tells crawlers what they may fetch. Rules are grouped by 2, the name a crawler reports. That design worked when a few search engines did most of the crawling. It works less well now that dozens of AI companies run crawlers, each with its own name, and some run several crawlers for different purposes.
A publisher that wants to keep its pages out of training sets but still appear in search has to track every company's crawler names, work out which one does what, and keep the file current as new companies and agents appear. OpenAI alone has 3 for training and separate agents for search and for user-triggered fetches. Miss one name and your opt-out has a gap.
There's a second problem. Blocking a crawler by name ties two decisions together: whether a bot may fetch the page, and what it may do with the content afterwards. A shared signal can state the second preference directly: "don't use this for training."
How it would work
The post doesn't describe the syntax. The working group's drafts have proposed a usage-preference vocabulary that site owners attach to robots.txt rules. Conceptually, instead of:
a site would write one line expressing "no generative AI training," and every participating provider would read it. This is an illustration of the idea, not OpenAI's announced format. Check the working group's final text and OpenAI's follow-up post for the real syntax.
OpenAI says the new signal adds to its existing controls and doesn't replace them. Rules aimed at GPTBot and its other named crawlers will still be respected. That means two layers: a provider-neutral preference, and the older per-crawler access rules for finer control.
What it does and doesn't cover
Scope is training. The stated purpose is foundational generative AI training. The post doesn't say whether the signal affects other uses, such as fetching a page to answer a user's question or to show in AI search results. Those uses run through different crawlers today.
It's voluntary. Like robots.txt itself, the signal only works if providers choose to follow it. OpenAI calls it "a voluntary effort" and "encourage[s] other AI providers to honor the signal." A crawler that ignores it faces no technical barrier.
It looks forward, not back. Nothing in the post suggests the signal affects content already collected or models already trained.
The standard isn't finished. OpenAI says it will "continue to adapt its practices" as the IETF discussions evolve. So the details could change.
Why OpenAI might do this
The post frames the move as support for an open web, where publishers have "clearer, simpler ways" to state their choices. Read more skeptically, a widely honored, standards-based opt-out gives AI companies a defensible norm: content without the signal is arguably fair game, and content with it is excluded. That is the same deal search engines made with robots.txt decades ago. Whether publishers accept it, and how many AI providers sign on, will decide whether the signal matters.
Open questions
The post leaves several things unsaid. It doesn't give the exact syntax, list the other participating companies, or set a firm date. It doesn't say how the new signal interacts with existing GPTBot rules when they conflict, or whether there will be any way to check that providers comply. The promised implementation update should answer some of these.
Remember
The signal covers training use, not crawler access, so a site can block training while staying visible to search.
OpenAI's existing per-crawler rules such as GPTBot still apply, so sites get two layers of control.
There's no syntax, list of participants or date yet, and compliance remains voluntary.
Overall: On AA's Intelligence Index v5 it scores 26. That is 1 point above Muse Spark Open, the best US open model, and narrowly the top open model from outside China. It is 6 points behind DeepSeek V4.1 Flash 1017 and GLM-5.3.
Hard coding: It scores 15% on FrontierCode 2.0, against 29% for DeepSeek V4.1 Flash and 22% for GLM-5.3. That is hard to square with Mistral's "#1 open model" claim. The article doesn't resolve the conflict, and it may come down to benchmark version or comparison set.
Terminal work: It scores 25% on 3 4.0, which tests agents doing tasks in a command-line shell. Muse Spark Open scores 8%.
Agent efficiency: On AA's Coding Agent Index it scores 48 using 8.5M tokens per task. GLM-5.3 scores 49 but uses 15.9M. So it gets nearly the same result for about half the tokens.
Verbosity: It uses 82K output tokens per Intelligence Index task, 39% fewer than the Preview. AA puts it on the open-weights 4, meaning no open model is both cheaper and better. Cost is $2.06 per task.
Hallucination: On AA-Omniscience, a factual-recall test, the hallucination rate fell from 41% to 28%, but accuracy is only 26%.
Vals Index: It ranks #5 among open-weight models and #17 overall, with gains on app-building and legal research.
Serving:6, a popular open inference server, runs the FP8 and NVFP4 (4-bit) checkpoints. It includes a "DSpark" draft model for 7, where a small model guesses tokens and the large model checks them. Output throughput rises 1.92–2.23x.
Local use: Unsloth's 1-bit 8 quantization shrinks the weights from 1.1TB (FP8) to 223GB, keeps 91% top-1 agreement with the original, and runs on a Mac Studio. llama.cpp support has been merged.
Fine-tuning: Hugging Face's TRL library does 9 supervised fine-tuning on a single node of 8×B300 GPUs, using 142 GiB per GPU and processing 32.7K tokens per step in about 8 seconds.
Reinforcement learning: SkyRL ran LoRA RL on the NVFP4 checkpoint across 8 GB200 nodes. The AIME 2024 math score rose from about 64% to about 75% in 75 steps.
Grove, which starts and scales multi-component serving graphs as coordinated groups
node-health signals (NVSentinel, Nodewright), Prometheus for metrics, and optionally a Gateway API ingress (agentgateway)
