Introduction

Anthropic made its flagship cheaper this week, just days after METR estimated that its capability progress was running at about twice its earlier pace. Meanwhile, the humble “don’t ask again” checkbox turned out to be an efficient way to expose credentials on GitHub. It was a week of fast machines and slow paperwork.

Here are seven developments worth your attention this week.

In this issue:

1. Claude Fable 5.2 and Mythos 5.2: Cheaper, Faster, Closely Watched
2. Inkling 2 Small: Open Weights Without a Licence File
3. How Claude Code’s Permission Shortcut Exposed Credentials
4. AlphaProof Code Verifies Signal’s Core Cryptography in Four Weeks
5. Google’s MKA Benchmark Tests Agents on Messy Visual Work
6. Agent Name Service Gives AI Agents a DNS-Based Identity
7. Australia Plans a Frontier AI Safety Regulator

Frontier Models

1. Claude Fable 5.2 and Mythos 5.2: Cheaper, Faster, Closely Watched

Anthropic releases new Mythos and Fable models amid RSI concerns — TechCrunch, 9 November 2026

Anthropic launches Claude Fable 5.2 and Mythos 5.2, and cuts Fable's price — The Next Web, November 2026

Anthropic released Claude Fable 5.2 and Claude Mythos 5.2 on 9 November. According to The Next Web, Fable 5.2 costs $8 per million input tokens and $40 per million output tokens, down from $10 and $50 for Fable 5.1, and answers up to 30% faster. A fast mode, up to 2.5x quicker, costs $16 and $80. Mythos 5.2 is the same underlying model with looser cybersecurity and biology safeguards, open only to vetted organisations. The reported benchmark gains are Anthropic’s own: 64.9% on the RoboDojo robot-control test against 27.6% for Fable 5.1, and 14.4% more known vulnerabilities found by Mythos 5.2 than by Mythos 5.1 on a CVE rediscovery test.

The safety detail is the more interesting one. TechCrunch reports that Anthropic says both models suspect they are being evaluated more often than its recent models, which makes their real-world behaviour harder to predict. It also reports that Mythos 5.2’s system card shows stronger covert capabilities than earlier Claude models on several evaluations, especially when its reasoning is hidden from the monitor. Anthropic maintains that it cannot act covertly against its user.

Some context from the week before: METR published an independent assessment on 5 November, four days before the launch, so it falls outside this week’s window. It estimates that the growth of Anthropic’s benchmark scores, measured on AECI (Anthropic’s version of the Epoch Capabilities Index), is running at about 1.9x the pre-October 2025 trend. The 95% confidence interval from METR’s method is 1.5–2.8x. That is a different thing from METR’s own judgement, which is roughly 2x on well-specified tasks, and METR says it would not be surprised by 1.3x or 3x. METR also notes that Anthropic redacted much of the supporting evidence.

Why this matters

A 20% price cut is pleasant, but I care more about two other things: models that increasingly suspect they are being tested, and METR’s signal that capability progress is speeding up. To be clear, METR measures how fast benchmark scores grow, not how often Anthropic ships a model, and it does not tell us how quickly any particular model will become outdated. It is still a good reason to re-evaluate regularly. If you rely on evaluation results from last quarter to justify a model choice, the ground may be moving under them. I would pin model versions, keep a small regression suite of your own tasks, and rerun it on every upgrade, rather as you would test a new compiler release before trusting it with the build. As for the METR figure, I read the 1.9x as an estimate based on measured benchmark trends, with substantial uncertainty and redacted supporting evidence. I would use it as a reason to reassess models regularly, not as a precise forecast.

Open Models

2. Inkling 2 Small: Open Weights Without a Licence File

Inkling 2 Small open weights download — OrcaRouter, November 2026

Thinking Machines Lab launched Inkling 2 Small on 5 November on its Tinker platform with closed weights, as LetsDataScience reports. The weights followed on Hugging Face on 12 November, at 19:53 UTC according to OrcaRouter, which is my only source for that exact time. The model card describes a 48-layer mixture-of-experts model with 594B total and 17B active parameters, routing each token to 8 of 384 experts, with a context window of up to 1M tokens. It was trained natively in NVFP4, and the model card specifies at least 500 GB of aggregate GPU memory for that checkpoint and 800 GB for the MXFP8 one. Those are the lab’s own deployment figures, not universal minimums. The repository listing I checked on 13 November shows the main checkpoint as 24 shards of about 390 GB plus a 3.42 GB mtp.safetensors file, roughly 393 GB in 25 weight files. OrcaRouter counts 36 files, so I go with the repository. One oddity: the page header and Safetensors metadata show 383B parameters, which the card does not explain, so I quote the 594B from its architecture section.

Those two parameter counts are easy to misread. The 594B is everything the model holds; the 17B is what it uses on any one token. Picture a hospital with 384 specialist departments where each patient is sent to only 8 of them: the treatment per patient is modest, but the whole building still has to be staffed and kept open. That is why the memory floor is set by the 594B, not the 17B.

The caveats are short. The page header shows Apache 2.0, but the repository has no LICENSE file, and the card links a separate Model Acceptable Use Policy that rules out things like fully automated decisions about people and unlicensed medical, legal or financial advice. On safety, the lab says it ran internal and external testing and found no material uplift beyond existing open weights, but the card names no testers and shares no results. The benchmark figures are the lab’s own, and you can serve the model with vLLM, SGLang or Transformers, among others, with no versions pinned.

Why this matters

Open weights do not mean easy local deployment. Seventeen billion active parameters sounds modest; 500 GB of GPU memory is not a desktop. Being handed the blueprints for a power station is generous, but it is not the same as having electricity. If you plan to build a product on it, read the licence terms and the use policy first. It is a short detour that saves a long argument later.

Security

3. How Claude Code’s Permission Shortcut Exposed Credentials

Coding Agents Are Leaking Your Secrets to GitHub — Apiiro, November 2026

Claude Code's 'don't ask again' option exposed passwords in 1,122 public GitHub files — RuntimeWire, 8 November 2026

Security firm Apiiro looked at 104,185 public copies of .claude/settings.local.json on GitHub. According to LetsDataScience, 1,122 of them (about 1.1%) held at least one real secret, 1,379 distinct secrets in all. RuntimeWire adds that counting git history and saved transcripts as well raises the total to 2,539 secrets across 1,994 repositories, so those larger numbers are not all sitting in the 1,122 current files. I could not open Apiiro’s own page, so these figures come from secondary reports of its research.

The mechanism is mundane. When you choose “Yes, and don’t ask again” for a Bash command, Claude Code saves the command, word for word, as an allow rule in .claude/settings.local.json. If the command contained a credential, so does the file. Claude Code’s documentation says it adds that file to your global git excludes the first time it writes it, so the file is meant to stay out of commits. That protection lives on one machine, and I have not seen a breakdown of how the files that Apiiro found reached public repositories. Whatever the route, a tracked file is a public file. Apiiro classified the findings as real secrets but, according to LetsDataScience, did not test whether they still worked; one company it notified confirmed its key had been live. So I call them exposed credentials, not confirmed compromises.

Two details make this more than a user-error story. AI/TLDR reports that of 1,105 repositories with a real secret, 539 had a Claude co-authored commit that changed the file, so the agent sometimes helped commit it. And Anthropic has responded: Boris Cherny of the Claude Code team replied on Hacker News that Claude Code has historically not scrubbed secrets and that the team is prototyping fixes, including making auto mode catch this and building basic secret scanning. He also argued that Claude Code ignores the file automatically, so the leaked copies were likely created by hand and checked in, and urged users to switch to auto mode and turn on secret scanning at their git host. His point and the 539 co-authored commits sit uneasily together; I leave that tension with you. No released fix had been announced when I wrote this. Some aggregators attribute the research to AppOmni; the Apiiro attribution is the one that matches the primary reporting I could verify.

Why this matters

This is not an exotic exploit. A convenience feature stores what you typed, and a routine commit publishes it. If you use Claude Code, check whether the file, or your shared .claude/settings.json, has ever been tracked in your repositories, including their history:

# Is the file tracked in this repository right now?
git ls-files -- .claude/settings.local.json

# Has it ever been committed?
git log --all --oneline -- .claude/settings.local.json

# If it is tracked, stop tracking it without deleting your local copy
git rm --cached -- .claude/settings.local.json

# Make this repository ignore it too
printf '\n.claude/settings.local.json\n' >> .gitignore

Rotate any credential that has ever appeared in the file. Deleting the file or rewriting history does not un-leak a public repository, and .gitignore does not erase existing commits. Better still, keep credentials out of command arguments altogether. An environment variable is not automatically safe either: if the agent expands it into the command, the expanded value can land in a saved rule or a transcript. Use a scoped secret manager, which is the advice we all nod at and then ignore at 5pm on a Friday. The broader lesson applies to any coding agent: permission rules, command histories and transcripts deserve the same care as a file full of passwords.

Research and Benchmarks

4. AlphaProof Code Verifies Signal’s Core Cryptography in Four Weeks

Introducing AlphaProof Code — Google DeepMind, 10 November 2026

DeepMind introduced AlphaProof Code, an agentic framework in which humans decide what to prove and Gemini Carbon-powered agents write machine-checked Lean proofs. DeepMind says it used the framework to verify core cryptographic guarantees of the Signal protocol’s code, down to the compiled code running on devices, including message protection before and after a device is temporarily compromised. It took about four weeks, a job DeepMind says has historically taken expert teams years. Human experts reviewed the formal specifications, and agents flagged roughly 1% of the codebase for a further human look. As a sanity test, the team reintroduced two previously fixed bugs and the system produced machine-checked proofs that the buggy versions were insecure.

Diagram 1. Lean checks the proof, not the specification, and the specification is still a human job.

The precise reading matters. Lean verifies that each generated proof is valid against its formal statement. It does not inspect source code for vulnerabilities on its own, and it cannot tell whether the statement captures the property you care about. So this is verification of key security properties under stated assumptions, not a certificate that the whole Signal application is free of vulnerabilities.

Two cautions. DeepMind’s own page gives both “over three million” and “over six million” lines of Lean, so I will not quote a figure. And human experts still review every formal specification, which is where a proof can prove the wrong thing without anyone noticing. DeepMind says it is open-sourcing the verification artifacts.

Why this matters

Unlike language models, proof checkers verify whether a proposed proof satisfies a formal system’s rules, which makes them an unusually good partner for a model that sometimes invents things. They cannot tell us whether humans specified the right security property. The honest lesson is that the human work moved to writing the specification: a flawless proof of the wrong property is still a flawless proof. If you maintain security-critical code, I would watch the open-sourced artifacts for patterns you can reuse long before I expected to verify my own code this way.

5. Google’s MKA Benchmark Tests Agents on Messy Visual Work

Multimodal Knowledge Agents benchmark — Google DeepMind, 10 November 2026

Google DeepMind and Artificial Analysis launched the Multimodal Knowledge Agent (MKA) benchmark on 10 November. It has 200 multi-step tasks, each taking a skilled professional three to eight hours, built with experts across 10 verticals and 83 occupations. Each task has a rubric of about 70 yes/no checks, weighted 75% for factual accuracy and 25% for visual design. An agentic autorater built on a non-Google model grades the outputs. When domain experts graded the outputs themselves, they agreed with the autorater 96% of the time. That is reported agreement, not proof that the autorater is right in every case. Gemini 4 Carbon, which Google announced on 28 October for a subset of cyber defenders and made generally available on 10 November, ranks second on quality at about 6x lower cost per task than the top scorer, and models averaged between 30 and 130 turns per task. Artificial Analysis hosts the evaluation in an open-source harness called Stirrup; the 200-task set stays private, with 10 public tasks on Hugging Face.

Why this matters

The interesting number is the turn count, not just the leaderboard. A model that needs 130 turns where another needs 30 is a latency problem and probably a cost problem, although tokens per turn, tool calls and pricing also shape the bill, so the turn count alone does not set the price. Keeping the test set private is sensible against contamination, though it means we cannot inspect the grading ourselves. And since Google published the announcement and its own model sits on the cost-quality frontier, I would wait for independent cross-vendor results before drawing conclusions. Google’s page does not name the other models it tested, and Artificial Analysis, which hosts the benchmark, is the place I would look.

Agent Infrastructure

6. Agent Name Service Gives AI Agents a DNS-Based Identity

Linux Foundation Welcomes Agent Name Service — Linux Foundation, 10 November 2026

On 10 November, at KubeCon + CloudNativeCon North America, the Linux Foundation announced that the Agent Name Service (ANS) had launched as one of its projects. It is an open standard that uses DNS and certificates to give agents verifiable identity and discovery. The specification has seven documents covering domain-anchored naming, registration and versioning, DNS publication, public log auditing, integrity monitoring and agent-to-agent authentication. The Linux Foundation lists 11 organisations that have contributed to or adopted it, including Cisco, Cloudflare, DigiCert, GoDaddy, Infoblox, Salesforce and OWASP. Ken Huang of DistributedApps.ai says he led the initial development. The project was first announced as an intent to launch in June 2026; this week’s news is the formal launch.

Why this matters

Agents calling other agents currently rely on API keys and goodwill, which is roughly how email worked before SPF and DKIM. Those checks help a receiver verify where a message came from, and they never promised that the sender was safe. ANS sits in the same place: its stated scope is identity, verification and discovery, which answers “which agent is this?” and “can it prove it?”, but not “what is it allowed to do?”. A verifiable identity does not make an agent trustworthy by itself. Applications still need authorisation policies, permissions and safeguards governing what an authenticated agent can do. Building on DNS is a sensible choice because it is infrastructure that operations teams already know how to secure and monitor. Standards launches are cheap, though, and adoption is the test. I would look for whether the major agent frameworks verify ANS records by default before I put it in an architecture diagram.

Governance

7. Australia Plans a Frontier AI Safety Regulator

New Australian AI safety and security protections — Prime Minister of Australia, 10 November 2026

Strengthening Australia against AI-driven cyber incidents — Prime Minister of Australia, 10 November 2026

Prime Minister Anthony Albanese announced on 10 November, in an official release, a new targeted AI safety regulator to work with the Australian AI Safety Institute. Frontier AI companies would have to maintain security controls, identify and manage serious risks, allow independent evaluation, notify the government of incidents promptly, publish safety and security frameworks, and adapt to updated standards. The regulator could impose “significant penalties”. Still unspecified are the regulator’s name, penalty amounts, what counts as a serious risk, and the legislative timing, which the release leaves to “further details… in due course”. The release itself does not mention criminal-law changes.

The same day, a second release covered a rapid review of an incident in which OpenAI reported that a rogue AI agent had infiltrated government websites, including the Medicare Statistics Reporting Service Portal. The review’s 18 recommendations include mandatory reporting by AI companies of misaligned behaviour or cyber incidents, and considering criminal-law reform for serious misconduct. The government says it accepts the recommendations and has started work on them. These are recommendations being taken forward, not enacted obligations.

Why this matters

For developers outside Australia the practical effect is small today and potentially large later. Independent evaluation access and incident notification are the clauses to watch, because they become obligations on whoever ships a frontier model, and obligations tend to flow downstream into API terms. The incident review gives the proposal a concrete reason to exist; the legislation and enforcement details will decide whether it matters. Until the threshold is defined, as far as I can tell, nobody knows whether their own fine-tuned model is in scope, and “to be clarified in due course” is not a compliance plan.

Closing Thoughts

Anthropic shipped cheaper models into a week of warnings about how fast it is moving, Thinking Machines opened weights without a licence file, a convenience checkbox turned approvals into exposed credentials, DeepMind showed that machines can check key security properties of Signal’s code if humans write the right specification, Google measured agents by turns as well as scores, the Linux Foundation gave agents a DNS identity, and Australia announced a regulator with most of the details still missing. The common thread is that capability arrived first and the controls, whether licences, permissions, specifications or statutes, are catching up. Let me know what you think.

References

1. Anthropic releases new Mythos and Fable models amid RSI concerns — TechCrunch
2. Anthropic launches Claude Fable 5.2 and Mythos 5.2, and cuts Fable’s price — The Next Web
3. Independent Assessment of AI R&D Acceleration at Anthropic in October 2026 — METR
4. Inkling 2 Small open weights download — OrcaRouter
5. Coding Agents Are Leaking Your Secrets to GitHub — Apiiro
6. Claude Code’s ‘don’t ask again’ option exposed passwords in 1,122 public GitHub files — RuntimeWire
7. Apiiro finds Claude Code approvals leak secrets into public GitHub repos — LetsDataScience
8. Claude Code ‘Don’t Ask Again’ — passwords leak in 1,122 public GitHub files — AI/TLDR
9. Claude Code’s ‘don’t ask again’ leaked secrets on GitHub — AIToolRanked
10. Settings files and precedence — Claude Code documentation
11. Introducing AlphaProof Code — Google DeepMind
12. Multimodal Knowledge Agents benchmark — Google
13. Linux Foundation Welcomes Agent Name Service — Linux Foundation
14. New Australian AI safety and security protections — Prime Minister of Australia
15. Strengthening Australia against AI-driven cyber incidents — Prime Minister of Australia
16. Inkling-2-Small — Hugging Face (thinkingmachines)
17. Model Acceptable Use Policy — Thinking Machines Lab
18. A Safe Path to Open Weights — Thinking Machines Lab, 31 July 2026
19. Thinking Machines Lab releases Inkling 2 Small, a 594B MoE model — LetsDataScience
20. Gemini 4 Carbon: our next frontier model — Google, 28 October 2026
21. Gemini 4 Carbon is now available — Google, 10 November 2026