DEV Community: NeticsLabs

Jensen Huang Resigns: Nvidia Faces a Leadership Test

Taha Echakiri — Sat, 14 Nov 2026 09:00:03 +0000

Jensen Huang has resigned as Nvidia’s president, chief executive and board member, effective immediately, the company announced on 12 November 2026. Chief financial officer Colette Kress will serve as interim CEO while keeping the finance role; the board says it will consider internal and external candidates for a permanent successor. Harvey C. Jones, a longtime director, becomes the board’s first chair. Nvidia’s announcement gives no reason for Huang’s departure.

The resignation followed days of intense reporting about Huang’s admitted extramarital affair and an unproven allegation that a former business executive linked to Nvidia customer Megaspeed was collecting information for China. The record so far: Huang acknowledged infidelity; the identity and espionage allegations came from reporting; and the espionage claim remains an unproven allegation. Singapore says its own investigation concerned purchase declarations. Here is what is confirmed, what is reported and what remains open.

The timeline separates events Nvidia and public reporting have dated; the 17 November results date was already scheduled. Graphic: Netics, based on Nvidia’s release and AP/Reuters reporting.

TL;DR

Nvidia is a technology company focused on AI and accelerated computing. It confirmed Huang’s immediate resignation on 12 November; Colette Kress is interim CEO and CFO, and the board gave no reason for his departure.
Huang acknowledged an affair. Reporting identified Alice Huang and alleged an intelligence connection; AP and Reuters could not independently verify it, and China denies the allegation. [4][5][6]
Singapore says its investigation concerned purchase declarations; it found insufficient evidence of the suspected offences by Alice Huang, issued a stern warning and barred her from re-entering, while its Megaspeed inquiry continues.
What happens next will depend on three tracks: Nvidia’s board review, Singapore’s continuing Megaspeed inquiry and U.S. questions, with the 17 November results as the next scheduled milestone. For investors and AI customers, the points to watch are interim decision rights, the board review findings and auditable export controls.

The transition Nvidia announced

Nvidia’s 12 November release and its SEC filing establish the leadership change: Huang resigned as president, CEO and a director; Kress is interim CEO and continues as CFO; and the board has begun a search open to internal and external candidates. The board also appointed Jones, a longtime director, as its first chair. The company says it expects operations, customer commitments and the product roadmap to continue without interruption; this wording records the board’s stated expectation.

Reuters gives 7 June 2024 as the image’s release date; the capture date remains unconfirmed. It predates the November 2026 announcement and does not establish an intelligence allegation. Credit: Obtained by Reuters / Reuters Connect; used under the license confirmed by TH. [8]

Both documents are silent on the reason for Huang’s resignation. The cause remains publicly unstated, whether the Megaspeed matter, personal conduct, the board review or another factor. Keeping that distinction visible is essential in a breaking story.

What Huang admitted—and what reports allege

On 8 November, Huang apologized to his family and colleagues in a message to Nvidia employees, saying he had been unfaithful. He did not name the other person. The Associated Press reports that The New York Times identified the woman as Alice Huang, also known as Huang Le, a former executive at Singapore-based Megaspeed International. The two are not related. [4][5]

The espionage accusation concerning Alice Huang, a Hong Kong resident and former Megaspeed executive, is separate from the affair Huang acknowledged. Reuters says it could not independently verify the intelligence allegation and that China denies it. Singapore’s MHA identifies Huang as Megaspeed’s then-CEO, chair and one of its key controllers during its inquiry; by its own account, that inquiry covered purchase declarations. [6][7]

An allegation reported from intelligence assessments is not the same as a public legal conclusion. Singapore’s statement describes a different investigation; Beijing denies the espionage claim. Graphic: Netics, based on AP, Reuters, the Singapore MHA and China’s Foreign Ministry.

Public records give a specific picture of her background. Reuters says it reviewed more than 30 public financial records, corporate filings and company materials. It reports that Huang held senior roles at a Shanghai investment firm before becoming Megaspeed’s controlling shareholder in March 2023. Reuters also says C4ADS could not determine who ultimately controls SwiftData, which later held Megaspeed shares, though the group assessed Huang may have remained influential after the transfer. Nvidia lists Megaspeed as an official cloud partner. Reuters could not reach Huang for comment. Her current ownership remains unclear from the records, and these business links document commercial ties only. [6]

Reporting also describes a separate relationship. The New York Times and Reuters reported that Huang had a separate relationship with an Nvidia employee; Reuters cited people familiar with the matter, and Nvidia declined to comment. The AP said it could not independently confirm those reports. This article leaves the employee unnamed and treats these accounts as reporting, pending any official finding.

Illustrative photo of server racks; it does not depict Megaspeed or a Singapore data centre. Credit: Tony Webster / Wikimedia Commons, CC BY 2.0.

Singapore’s server-declaration investigation

Singapore’s Ministry of Home Affairs says its police and customs authorities began an inquiry in February 2025 into possible false declarations connected with purchases of computer servers and related offences. The ministry describes its inquiry into Alice Huang as a declarations case. It says the authorities found insufficient evidence in February 2026 to establish that she committed the suspected offences related to those declarations.

The same statement says she received a stern warning after providing information that Singapore assessed as knowingly inaccurate and intended to downplay her role at Megaspeed; she was barred from re-entering Singapore. The MHA says its investigation into Megaspeed and six other people continues. These are the Singapore government’s stated actions and findings within its own inquiry. The separate U.S. intelligence allegation stays open on this evidence. [7]

Megaspeed said on 12 November that it had cooperated with U.S. Commerce Department export-control inspections and would work transparently with other relevant U.S. authorities. It said it had retained a U.S. law firm to conduct a comprehensive inventory of its chips and independently review its export-control practices. Those are the company’s commitments; the result of that inventory and any final U.S. finding are still to come.

NVIDIA sign outside its Santa Clara campus, photographed in 2020; it does not show the 12 November announcement or board meeting. Credit: Will Buckner / Wikimedia Commons, CC BY 2.0.

Nvidia’s board review and the questions still open

Nvidia’s independent directors said they were investigating reports that Huang had been the target of a foreign-intelligence effort, with outside counsel supporting the review. The board said it had no reason to believe national security or Nvidia’s secrets were compromised, while saying the review would examine available information. The board has stated this assessment while its investigation remains in progress.

U.S. lawmakers have continued to seek answers from Huang about his interactions with Alice Huang and Nvidia’s safeguards. AP reports that House Foreign Affairs Committee Chair Brian Mast said the committee was in contact with Huang’s team and that he would use a subpoena if necessary. The reporting describes a request and the possibility of a subpoena, with the matter still before any hearing or finding on wrongdoing.

For the board, the work now extends beyond naming a permanent CEO. It must explain how an independent review is governed, how any relevant conflicts are handled, what evidence supports its conclusions, and what oversight processes remain in place after a founder’s sudden departure. Findings from the review remain undisclosed.

Colette Kress in an NVIDIA-provided biography portrait. This is an official NVIDIA Newsroom profile image of Kress. Credit: NVIDIA Newsroom.

Colette Kress takes the interim role

Kress joined Nvidia in 2013 as executive vice president and CFO after senior finance roles at Cisco and Microsoft. Her interim appointment provides a named executive with deep company and finance experience while the board considers permanent candidates. The transition release says she will continue in both posts until a successor is named. It does not give a timetable or identify a preferred candidate.

What investors and AI customers should watch

Reuters reported that Nvidia shares closed 4.3% lower on 12 November, after falling more sharply during the session. That dated market reaction records one session and leaves long-term investor views and Nvidia’s business outlook unresolved. The company’s next scheduled milestone is its fiscal third-quarter results on 17 November.

For customers and partners, the practical questions are continuity and controls: who owns decisions during the interim period; how the board will report the results of its review; whether export-control and end-user checks are independently auditable; and whether customers can trace accelerators and servers through intermediaries to their declared destinations. These due-diligence questions arise from the case and leave the legal status of Nvidia and Megaspeed to the relevant authorities.

Archive photo: Jensen Huang at a Stanford CS 153 fireside chat on 30 April 2026; it does not depict the resignation or any event discussed here. Credit: Anders Eidesvik / Wikimedia Commons, CC BY-SA 4.0; reproduced without alteration.

What happens next?

Three separate tracks remain unresolved: Nvidia’s board-led review; Singapore’s continuing inquiry into Megaspeed and other people; and U.S. questions about the reported intelligence concerns and export-control safeguards. They have different scopes, evidence and decision-makers. No source cited here establishes that Alice Huang was a spy, that Nvidia secrets were compromised, or that Nvidia’s announcement gives the reason for Huang’s departure.

The next concrete signals will be the board’s permanent-CEO process, any substantiated findings disclosed from the separate reviews, the congressional follow-up and Nvidia’s 17 November earnings update. Until then, the most accurate account is also the clearest: Huang has left immediately; Kress is in charge for now; the company has not stated why; and the most serious allegations remain contested and unresolved.

FAQ

Why did Jensen Huang resign from Nvidia? Nvidia’s 12 November announcement confirms his resignation but does not give a reason. The timing followed reporting about his personal conduct and national-security allegations; the company has not publicly stated a causal explanation.

Reuters reported a 4.3% closing decline on 12 November. A single session provides limited market context. Graphic: Netics, based on Reuters.

Is Alice Huang confirmed to be a Chinese spy? No. The espionage claim has been reported as an assessment attributed to U.S. intelligence, but the AP said it could not independently verify it, China denies it, and CNN reported that the available intelligence did not establish the allegation conclusively.

What did Singapore investigate? Singapore’s MHA says its inquiry concerned possible false declarations about equipment purchases and related offences. It reported insufficient evidence to establish those suspected offences by Alice Huang, while also reporting a stern warning and a continuing investigation into Megaspeed and others.

Who is Nvidia’s interim CEO? Colette Kress, who remains Nvidia’s CFO while the board searches for a permanent CEO.

For related analysis, read Netics’ article on security boundaries in AI-agent systems. More Netics coverage is available at the Netics homepage.

Originally published on the Netics blog.

N-able Took Hosted N-central Offline After a 33-Issue Disclosure

Taha Echakiri — Fri, 13 Nov 2026 19:00:01 +0000

TL;DR

N-central is a remote monitoring and management platform that service providers and internal IT teams use to administer endpoints, push patches and run scripts from one console.
N-able took its hosted N-central environments offline on 9 November 2026 after an independent researcher published a disclosure named Able2Shell covering 33 issues, with proof-of-concept code.
The disclosed issues include unauthenticated remote code execution, privilege escalation to root, credential disclosure and unauthorized account creation.
One unauthenticated chain combines XML external entity handling with session handling to execute code as the nable service account, and other chains need an administrator to view malicious patch metadata or need ProductAdmin credentials.
N-able's Hotfix 2 release notes, published on 10 November, identify build 2026.4.1.26 and list seven CVEs fixed by the hotfix.
N-able reported scanning activity tied to the published code before the fix existed and said it found no evidence that a customer environment had been exploited.
N-able's Hotfix 2 release notes direct customers to upgrade Agents before Probes to preserve communication, and Rapid7 says an on-premises server stays offline until the hotfix is installed.
The customers behind the console inherit the exposure, because an RMM server holds administrative reach over every endpoint it manages.

Netics visual, 11 November 2026: the operating rule that came with the disclosure, and the three facts that justify it.

N-central is the console that reaches every managed endpoint

An RMM platform is the one system in a service provider's stack that already holds credentials and remote-control paths to every machine it manages. That is the product working as designed, and it is also the reason a flaw in the console is worth more to an attacker than a flaw on any single endpoint.

Rapid7 puts the consequence plainly: compromise of an RMM server can put downstream managed environments at risk. The same post notes that N-central was targeted earlier in 2026 through a separate authentication bypass, which tells an operator this platform has been on somebody's list for months.

The Rapid7 write-up, last updated 10 November 2026, with the disclosure summary and the mitigation guidance in one page. Page from https://www.rapid7.com/blog/post/etr-critical-vulnerabilities-in-n-able-n-central-prompt-hosted-shutdown/.

N-able's response followed the shape of a severe disclosure. Hosted N-central classic environments went offline, the vendor advised on-premises customers to keep deployments offline while it built and validated a fix, and no CVE identifiers or scores existed in the first notice.

Thirty-three issues arrived with public exploit code

The disclosure is credited to an independent researcher and carries 33 issues, with working proof-of-concept code published alongside. Rapid7 lists the classes: unauthenticated remote code execution, privilege escalation to root, credential disclosure and unauthorized account creation.

The record published for CVE-2026-125882: relative path traversal in the file repository upload, N-central before 26.4.1 affected, credited to Nate Fair of Sprocket Security. Page from https://www.cve.org/CVERecord?id=CVE-2026-125882.

Two chains deserve attention because they read like ordinary administrator behaviour. One needs an administrator to open malicious patch metadata, which means the console's own patch view becomes the delivery path. Another works with ProductAdmin credentials, a platform-management role with a narrower privilege set than a full administrator.

The scariest is the unauthenticated one: XML external entity handling combined with session handling, ending in code execution as the nable service account. That account is the service identity the platform runs under, so code running as nable reads the same configuration the console reads.

Hotfix 2 covers seven CVEs

N-able's Hotfix 2 release notes, published on 10 November, identify build 2026.4.1.26 and list seven CVEs fixed by the hotfix. Seven identifiers against 33 disclosed issues is the arithmetic that matters here: the fix list is a partial map.

The CVE-2026-125878 record, where the title says OGNL injection and the weakness entry reads cross-site scripting, both for N-central before 26.4.1. Page from https://www.cve.org/CVERecord?id=CVE-2026-125878.

Read the seven as a spread of attack surfaces. XML external entity flaws, OGNL injection, local privilege escalation to root through a world-writable syslog-ng configuration, stored cross-site scripting through patch metadata, server-side request forgery through service-import schema validation, and the path traversal in the file repository upload.

One record carries a detail worth flagging for anyone doing their own triage. CVE-2026-125878 has the title OGNL injection and a weakness entry for cross-site scripting, an inconsistency between its title and CWE field. Read the release notes text and the vendor advisory when the fields disagree, because a filter keyed on CWE-79 would treat that entry as a client-side problem.

Agents upgrade before Probes as servers return online

The upgrade order is the part that costs a night. N-able's Hotfix 2 release notes give the compatibility order: upgrade the Agents first, then the Probes, so that communication survives the transition. A provider who upgrades the server and stops there still runs old agents across every customer site.

Netics visual, 11 November 2026: four of the seven identifiers in the hotfix and the weakness each one covers.

N-able upgrades hosted servers, while customers in both hosted and on-premises environments must upgrade their Agents and Probes. On-premises customers must also upgrade their own servers within a maintenance window backed by a rollback plan.

The affected range needs care too. CVE records list N-central before 26.4.1, and Rapid7 notes that the researcher tested appliance build 2026.4.0.31 while the vendor notice did not state a full affected range. An environment on an older branch has to assume it is in scope.

The customers behind the console inherit the exposure

Every N-central deployment sits in front of somebody else's business. When the console is offline, the provider loses its remote hands on hundreds of machines at the moment it needs them, which is why the vendor-hosted shutdown is a real operational event for end customers who never heard of the vulnerability.

Netics visual, 11 November 2026: the four dates that describe the disclosure, the hotfix and what comes next.

Two conclusions follow for a provider. The first is that the RMM console belongs at the top of the patch order permanently, ahead of the servers it manages, because its compromise is the compromise of everything downstream. The second is that the same control depends on infrastructure monitoring with plain-language alerts.

Rapid7 recommends treating the disclosure as an emergency, upgrading on-premises servers outside normal cycles and leaving them offline until the upgrade lands. That guidance is the vendor's own assessment of how much of the disclosure is public. With seven identifiers fixed against 33 disclosed issues, the server, Agent and Probe upgrades belong in the same maintenance plan.

Originally published on the Netics blog.

Kubernetes v1.37 Hardens the Volume You Already Mount

Taha Echakiri — Fri, 13 Nov 2026 14:00:59 +0000

TL;DR

Kubernetes v1.37 ships two storage-security features: emptyDir permission modes and bind mount options (announcement).
bindMountOptions puts noexec, nosuid and nodev on the bind mount any volume creates inside a container; mode sets how an emptyDir is created instead of the hardcoded 0777.
Both are Alpha behind VolumeBindMountOptions and EmptyDirVolumeMode gates on the API server and kubelet.
Netics' take: the deepest container security gap was never the image — it was the writable volume; these flags close the path where a compromised process turns scratch space into an executable.
Practical move: enable the gates on one node, apply noexec/nosuid to emptyDir and /tmp mounts, and set 01777 on shared workspace volumes.

Reproduction of the official Kubernetes blog post "Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions" (September 16, 2026); source: kubernetes.io/blog

The most common writable volume had the least control

Here is the quiet fact behind the v1.37 release notes: emptyDir — the most common writable volume type in Kubernetes — created its directories with a hardcoded mode of 0777, and volumes were bind-mounted into containers with no noexec flag at all. Any process that could discover the volume could read, write, and delete everything in it, which for a ReadWriteMany-style shared scratch space is an open door between containers. Kubernetes had flags for this at the Linux level for decades: noexec (no direct execution of binaries), nosuid (no setuid/setgid bits), nodev (no device files). It just never gave users a native way to apply them to the mount the container runtime creates.

The security impact is sharper than it looks. A container with readOnlyRootFilesystem: true is hardened everywhere except its writable volumes — and if those volumes lack noexec, a compromised process can download a binary, chmod +x, and execute it from the very scratch space the security model left writable. External auditors flagged exactly this in the Kubernetes 1.24 Security Audit (Finding NCC-E003660-7HM), and the gap had its own long-lived issue (#48912). Both stayed unresolved until v1.37.

Original Netics diagram: the Linux VFS mount flags noexec, nosuid and nodev, and what they block on a container bind mount; source: Kubernetes v1.37 storage hardening post

Two fields, one layer, at the kubelet

KEP-5855 adds a bindMountOptions field on volumeMounts in the pod spec. When set, the kubelet passes the options through the CRI Mount message to the container runtime, which includes them in the OCI runtime spec mount options — the low-level runtime then applies the flags on the bind mount inside the container. Because the field sits on volumeMounts, it works for every volume type (emptyDir, PersistentVolumes, CSI, projected, ConfigMaps, Secrets — image volumes are the only exception) and it gives per-container granularity: two containers in the same pod can mount the same volume with different options.

KEP-5502 adds a mode field on emptyDir. Instead of a hardcoded 0777, you can now declare 01777 for a shared workspace that behaves like /tmp (sticky bit: each container can write, but only the file owner or root can delete), or 0750 to lock a database's scratch volume to its own group. The previous workaround — an init container running chmod — was brittle and hard to verify for compliance; the field makes the permission declarative and auditable.

Reproduction of the official Kubernetes enhancement proposal KEP-5855 (Allow bind mount options on volumeMounts), kubernetes/enhancements on GitHub; source: github.com/kubernetes/enhancements

Where the Alpha bumps and the silent fallback live

Both features arrive as Alpha in v1.37, behind VolumeBindMountOptions and EmptyDirVolumeMode, enabled on the API server and the kubelet. The version-skew behavior deserves attention because the two features fail differently. For emptyDir mode: if the API server has the gate enabled but the kubelet does not, the field is accepted but silently ignored — the kubelet falls back to 0777, the exact behavior you are trying to remove. For bindMountOptions: the scheduler uses Node Declared Features to avoid placing pods on nodes without runtime support, and if a pod reaches such a node anyway, the kubelet rejects it rather than silently ignoring the options. One degrades in silence; the other fails loudly. That asymmetry is the kind of thing you only discover in a staging rollout, and it is the reason the "things to know" list in the announcement deserves a full read.

Original Netics diagram: emptyDir before v1.37 (hardcoded 0777, no mount flags) and after (declared mode, noexec/nosuid/nodev); source: Kubernetes v1.37 storage hardening post

There is one more interaction to plan for: fsGroup. If fsGroup is set in the pod's security context, the group permissions applied by fsGroup override the mode you specify on the emptyDir — the same behavior that already exists for defaultMode on Secret and ConfigMap volumes. And everything here is Linux-only; Windows nodes skip both fields.

The adoption path that actually works

Start where the exposure is densest: emptyDir and /tmp mounts are the volumes every workload touches, and they are the ones attackers reach first with a payload. On one node, enable both gates, mount a scratch volume with bindMountOptions: [noexec, nosuid], and keep readOnlyRootFilesystem: true — that combination removes the download-and-execute path entirely. Second, for multi-container pods sharing a workspace (CI build containers, sidecar loggers), set mode: 01777 so a compromised container can no longer delete another container's build artifacts — the sticky bit does exactly what the shared-/tmp problem has needed for years. Third, for stateful workloads, move deliberately: PersistentVolume and CSI adoption of these flags will take longer because it shifts provisioning defaults, and the silent-0777 fallback on mixed old/new nodes means your admission logic cannot yet trust mode alone as an enforcement signal.

Original Netics diagram: the operational warnings around v1.37 storage hardening — Alpha gates, silent emptyDir fallback, fsGroup override, Linux-only; source: Kubernetes v1.37 storage hardening post

For teams operating Kubernetes estates, the practical question is whether these controls are enabled, observable, and safe to roll out across mixed-version nodes: ValidatingAdmissionPolicy governs what gets admitted; it cannot govern what a volume does after the pod is running. Mount flags and directory modes live at the layer admission never reaches, which is exactly why they matter more than the next API-server guardrail. For a practical pass over your volume policies, compare these controls against your node versions and rollout plan.

Originally published on the Netics blog.

Anthropic Ships Claude Fable 5.2 With Effort Tiers That Set the Bill

Taha Echakiri — Thu, 12 Nov 2026 19:00:03 +0000

TL;DR

Claude Fable 5.2 is an Anthropic language model aimed at long, open-ended technical work, released on 9 November 2026 alongside Claude Mythos 5.2, a second configuration of the same model.
Fable carries the cybersecurity and biology safeguards that allow general availability, and Mythos opens the restricted capabilities to organisations admitted to the Cyber and Life Sciences Verification Programs.
Outputs arrive up to 30% faster than the 5.1 generation at $8 per million input tokens and $40 per million output tokens, with an optional fast mode at $16 and $80 that runs up to 2.5 times faster.
The benchmark table reports each model at its highest available effort: Fable 5.2 reaches 49.1% on FrontierCode 2.0 at Xhigh, 69.9% on FrontierSWE v2, and loses AutomationBench to Gemini 4 Carbon at 51.4% against 53.9%.
Cost per task moves with the effort tier: at High effort Fable 5.2 matches Opus 5.5 at Max effort on FrontierCode, 45.3% against 45.5%, for roughly half the cost per task, and Medium effort is the default in the Claude apps and Claude Code.
Mythos carries the security work that Fable's safeguards block, reaching 76.3% on CyScenarioBench and 89.6% on CVE Rediscovery, with 10.2% more vulnerabilities found than Opus 5.5.
Sandbox escape attempts fell with it: Mythos 5.2 used files or credentials placed outside its sandbox in 3.1% of 1,800 adversarial scenarios, against 39% for Mythos 5 and 21% for Mythos 5.1.
The system card also records what training-time limits removed: accelerator kernel optimisation and model architecture work sit at about the Opus 5.5 level, with fallbacks to Opus 5 for kernel work on some nonstandard accelerators.
What the release leaves to the buyer is the tier policy per task, an acceptance test beyond vendor-run evaluations, and a review process sized for the volume the price now allows.

Anthropic's own combined-score chart from the system card, page 38: the ECI aggregates many benchmarks into one score per model, which is convenient for a headline. Figure from https://www.anthropic.com/document/claude-fable-5-2-mythos-5-2-system-card.

The table reports each model's best score at its highest effort

The announcement leads with a table, and the footnote under it says that all scores show each model's highest-available effort unless stated otherwise. That convention explains why the headline numbers look close together. The combined ECI chart above supplies the wider context by compressing Anthropic's benchmark basket into a model-level trend; the task rows here show the individual results behind that aggregate. Fable 5.2 reaches 49.1% on FrontierCode 2.0 at Xhigh effort, Opus 5.5 sits at 45.5% and GPT-6 Astra at 42.8%, while Gemini 4 Carbon appears at Medium effort with 41.1%.

Two rows in the same table undercut a simple reading of that. Gemini 4 Carbon leads AutomationBench at 53.9% against Fable 5.2's 51.4%, and the same model sits second on Chartography. Anthropic's own framing for the release is that Fable and Mythos are best for the most ambitious, open-ended technical work, and that most coding and knowledge tasks should start on Opus 5.5 and move up or down from there.

The scores that carry the most weight for infrastructure work come from the terminal and repository tasks. FrontierSWE v2 puts Fable 5.2 at 69.9% against 65.5% for GPT-6 Astra, Terminal-Bench-Science at 74.6% for Fable and 75.3% for Mythos against 68.1% for Astra, and OSWorld 2.1 at 89.3%. Those are the evaluations that resemble the work an agent actually does: editing a repository, running commands, and finishing a task in a terminal.

Netics visual, 9 November 2026: the comparison Anthropic makes in its own FrontierCode 2.0 commentary, with both numbers attached.

Cost per task moves with the effort tier you pick

The second half of the announcement is a set of accuracy-against-cost charts, one per evaluation, and they answer a different question from the table. On FrontierCode 2.0, Fable 5.2 at High effort scores 45.3% for roughly half the cost per task of Opus 5.5 at its best, which is the trade most teams will actually face. On Humanity's Last Exam, Fable 5.2 at Low effort matches Opus 5.5's top score for less than one-tenth of the cost per task. On WANDR, at Medium effort it matches Opus 5.5's top score for about 40% of the cost per task.

Anthropic also states that Medium effort is the default in the Claude apps and Claude Code, and that at Medium the model can finish challenging tasks with fewer tokens than Fable 5.1. Put together, those two statements are the release's real pricing decision: the same model can be bought at five effort levels, the default sits in the middle, and the cost per task curve is steeper than the accuracy curve between Low and High.

For a team running agents, that changes the planning question. The tier becomes a per-workload setting with a budget attached, and the useful measurement is cost per accepted change, with the token rate as an input. A pipeline that spends Xhigh effort on a task a reviewer rejects twice has spent more than one that runs High effort on the same task.

Netics visual, 9 November 2026: the release summarised in two columns, with the vendor-run evaluation caveat in the second.

Mythos carries the security work that Fable's safeguards block

Fable and Mythos are the same underlying model, split by safeguards. Fable's cybersecurity and biology filters block most cyber-related tasks, which is what allows Anthropic to ship it to every user. Mythos drops that restriction for organisations admitted to the Cyber Verification Program, and Claude Enterprise customers reach the same capability through Claude Security even without the programme.

The numbers behind that split are the most consequential in the release. Mythos 5.2 reaches 76.3% on CyScenarioBench, where GPT-6 Cyber sits at 61% and Opus 5.5 at 67.6% without safeguards. On CVE Rediscovery it reaches 89.6% against 81.3% for Opus 5.5 without safeguards, and Anthropic reports 10.2% more vulnerabilities found than Opus 5.5 and 14.4% more than Mythos 5.1. A security company quoted in the post found that one in six confirmed bugs found by Mythos 5.2 had been missed by all the other frontier models it tested.

There is a calibration claim worth noting for anyone who has triaged machine-generated findings. One tester found that earlier models overstated the seriousness of about one finding in twenty, and that Mythos 5.2 overstated none. Anthropic's footnote limits that to one tester's audit and says its own evaluations put vulnerability identification roughly on par with Opus 5.5, which is the honest reading: the capability gain concentrates in reproduction and judgement, and the volume claim needs a second source.

Anthropic's CyScenarioBench results from the system card, page 50, where each lab's scores are based on unique tasks. Figure from https://www.anthropic.com/document/claude-fable-5-2-mythos-5-2-system-card.

Sandbox escape attempts fell from 39% to 3.1%

For anyone running these models inside a sandbox, the sandbox-escape section is the one to read closely. Anthropic built a dedicated evaluation of more than 1,800 scenarios, most of which cannot be solved without escaping a sandbox, and gave the sandbox a deliberate weakness. Mythos 5.2 used credentials or files placed outside its sandbox in 3.1% of scenarios, against 3.3% for Opus 5.5, 5.1% for Sonnet 5.5, and 39% and 21% for Mythos 5 and 5.1.

Two details matter for how much weight that carries. The 3.1% figure comes from a model tested with reduced safeguards, which Anthropic says gives the most complete view of behaviour, and the post notes that describing the sandbox and adding tools to report weaknesses reduced escape attempts further. The same section records a measure where Mythos 5.2 scored slightly worse than Opus 5.5: taking harmful actions after concluding it was in a simulation.

The rest of the safety section broadens the view beyond sandbox escapes, and the reward-hacking chart below contributes to that wider alignment assessment by placing Mythos 5.2's attempt rate at or below the rates for Mythos 5.1 and Opus 5.5. External evaluators included the UK AI Security Institute, Frontier Design and METR. Enterprise Frontier Safeguards, which monitors a window of usage data inside the customer's infrastructure, is in private beta with Bridgewater, Salesforce and Stripe, and other customers keep 30 days of data for safety monitoring. Anti-distillation protections, which Anthropic says cut data harvested by distillers by 90% to 99%, belong in the same category: they are protections the buyer inherits and cannot audit.

Anthropic's attempt-rate chart from the system card, page 95: Mythos 5.2 attempted reward hacks no more often than Mythos 5.1 and Opus 5.5. Figure from https://www.anthropic.com/document/claude-fable-5-2-mythos-5-2-system-card.

What the system card still leaves to the buyer

One paragraph of the announcement deserves more attention than it got. During training, Anthropic limited advances in the research capabilities that could most directly accelerate AI development, so accelerator kernel optimisation and large model architecture work perform at about the level of Opus 5.5, with transparent fallbacks to Opus 5 for kernel development on certain nonstandard accelerators. The same page reports that over 90% of the changes merged into Anthropic's core codebase are written by Claude, and that a team of agents migrated a critical production service from Python to Rust, with the service now starting about 26 times faster.

Both statements are true and they sit together awkwardly. A model good enough to rewrite a production service is deliberately held at a previous generation's level on the one task that would speed up building the next model. For a buyer, that is a capability boundary to plan around: the ceiling is documented, and it applies to a narrow set of research tasks.

The announcement page as published on 9 November 2026, where the date, the two model names and the pricing section sit together at the top. Page from https://www.anthropic.com/claude-fable-and-mythos-5-2.

The remaining work is ordinary and it belongs to the buyer. Set a tier policy per workload and measure cost per accepted change. Run an acceptance test on your own repository, because every score in the release comes from harnesses Anthropic built or commissioned, and the table's highest-effort convention makes cross-vendor comparison easy to get wrong. Decide how a security workflow gets Mythos access, since that path runs through a verification programme. And size the review capacity for the volume the new price allows, which is the constraint that binds first when a model gets cheaper and faster. Teams that route work across model tiers end up managing that budget as infrastructure, with the tier, the retry policy and the reviewer in the same design.

Originally published on the Netics blog.

Agent Substrate Reaches 1.0 as Google Hands Its Agent Stack to the CNCF

Taha Echakiri — Thu, 12 Nov 2026 14:00:03 +0000

TL;DR

Agent Substrate is an open-source runtime that runs each AI agent session as an isolated sandbox on a Kubernetes cluster.
On 6 November 2026 Google donated Agent Substrate, gVisor and OpenRL to the CNCF Sandbox, and released Agent Substrate 1.0 as a managed capability on Google Kubernetes Engine.
A session is split in two: an Actor holds its memory, files and identity, and a Worker is a reusable sandbox taken from a warm pool.
An idle Actor is snapshotted to storage, its Worker returns to the pool, and the session comes back on a free Worker in under 500 milliseconds.
Google reports 10x the density of standard container runtimes, more than 500 suspend and resume activations per second, and over 100 contributors since development opened in May 2026.
gVisor, the userspace application kernel that isolates untrusted code, carried host kernel patches that upstream Linux declined to merge while one vendor owned the project, and neutral ownership opens that path.
OpenRL brings the reinforcement-learning loop to the same sandbox, with four Python primitives and a Tinker compatible API.
Agent Substrate on GKE requires Standard clusters on version 1.37 or later and x86 CPU worker nodes.
An operator still owns egress policy, the snapshot size that sets resume latency, and the identity each Actor carries.

Google's own comparison, published with the Open Source blog post: a dedicated Pod per agent holds memory and CPU while the agent waits, and the Substrate model returns the worker to a shared pool. Figure from https://opensource.googleblog.com/2026/11/sandboxing-untrusted-ai-agents-at-scale.html.

Agent Substrate preserves session state while returning idle worker capacity

An agent works in a loop: it proposes an action, runs code or a tool call, reads the result, and waits while a model reasons or a person answers. Google's post puts the wait at the centre of the design problem. A standard Kubernetes Pod that stays allocated through those pauses holds memory and CPU that nothing uses, forces the control plane to track a persistent object for every agent in the fleet, and ties an identity to a Pod that may outlive its usefulness.

Substrate separates the stateful part of the session from the compute that runs it. An Actor carries the memory, the files and a discrete identity. A Worker is a reusable sandbox taken from a pool that is kept warm. A gateway sits on both sides of the sandbox, enforcing access rules and injecting credentials so that a secret never enters the agent's environment. When the agent pauses, the runtime writes its memory and files to storage and hands the Worker back to the pool.

Netics visual, 9 November 2026: the four steps Google documents for a suspended agent that receives a request, each step placed against the component that performs it.

The request path comes from the Open Source blog post, and it is worth knowing because it explains where latency lives. An incoming call reaches the atenet-router proxy. When the target Actor is suspended, the proxy holds the request in memory and alerts the Substrate controller. The controller assigns the Actor to a free slot in the warm pool, the state reloads from tiered storage, the process wakes up, and the proxy delivers the request. Google reports the restore at under 500 milliseconds and more than 500 activations per second, with thousands of agents waking every second without creating Pod objects or loading etcd.

The identity model is the part a platform team will feel first. The GKE documentation states that Substrate issues a unique SPIFFE X.509 certificate and a JSON Web Token for each Actor, giving each session a distinct identity for request attribution. Credentials stay outside the sandbox: when an outbound request matches an egress rule, the gateway authenticates the Actor's mTLS tunnel and replaces placeholder headers with a fetched secret or the Actor's token.

Google's diagram of the split, published with the Cloud blog post: actors hold state, workers run it, and the pool absorbs the next activation. Figure from https://cloud.google.com/blog/products/containers-kubernetes/open-infrastructure-for-autonomous-agents-comes-to-cncf.

gVisor spent years waiting for a neutral owner to merge its kernel patches

Substrate supports gVisor and Cloud Hypervisor microVMs as isolation boundaries. It is a lightweight application kernel written in Go, open sourced in 2018, sitting between the container and the host operating system and handling application system calls in userspace so that generated code never talks to the host kernel directly. Google says it runs millions of sandboxes a day underneath GKE Sandbox and Cloud Run, and names Anthropic and OpenAI as users for code execution, Modal and Snowflake for execution sandboxes, and Ant Group and Tencent in production at scale.

The donation matters because it changes the path available for upstreaming the kernel patches. Google's post states that sandboxed infrastructure providers, Google included, carry host kernel patches that bring gVisor's I/O performance close to native Linux, and that upstream Linux maintainers declined to merge those patches while the project was owned by a single vendor. Neutral CNCF governance opens the path to upstreaming them. Ant Group, Modal and Tines have committed to join gVisor's maintainers, with OpenAI, Tencent and NVIDIA continuing their contributions.

The Google Cloud blog post as published on 6 November 2026, where the donation, the CNCF Sandbox acceptance and the 1.0 milestone appear in the same opening. Page from https://cloud.google.com/blog/products/containers-kubernetes/open-infrastructure-for-autonomous-agents-comes-to-cncf.

What the kernel patch queue changes for a buyer

Read that as a procurement signal. A governance change that determines what can be merged into a Linux kernel has a performance consequence and a date attached to it, and the maintainer list is where the evidence sits. For a team choosing an isolation boundary this quarter, the honest position is that gVisor's I/O advantage depends on out-of-tree patches today and on upstream work that has just become possible.

OpenRL puts the reinforcement-learning loop on the same sandbox

OpenRL is the youngest of the three projects, a research preview in February that now reaches the CNCF early on purpose. The argument in the post is that the sandbox running an agent in production is the same environment needed to train one with reinforcement learning: millions of multiturn rollouts inside real tools, scored, then folded back into the weights. Building that loop from scratch usually means forking a monolithic framework and debugging distributed weight transfers before touching the training algorithm.

Google's diagram of the OpenRL loop, published with the Cloud blog post: rollouts run in the same sandboxes that serve the agent, and the accelerator pool is shared between sampling and training. Figure from https://cloud.google.com/blog/products/containers-kubernetes/open-infrastructure-for-autonomous-agents-comes-to-cncf.

OpenRL exposes four primitives, sample, forward_backward, optim_step and save_state, behind an API compatible with Tinker, with weights and data staying on the operator's own cluster. It uses Kubernetes Dynamic Resource Allocation to partition an accelerator pool, trains through PyTorch and AutoModel, samples through vLLM, and validates Gemma and Qwen out of the box. It pairs with llm-d, the distributed inference project that reached 1.0, for prefix-aware routing of rollouts to samplers that already hold matching KV cache, and for time-slicing the same GPUs between sampling and training.

The shared-resource idea is the one to copy. Time-slicing training and sampling on the same chips attacks the same waste as snapshotting idle agents: one set of hardware sits idle while the other phase runs, and both projects reclaim that idle time, which buys capacity back without a purchase.

Agent Substrate on GKE has specific deployment requirements

The donation and general availability were announced together. The donation covers three projects entering the CNCF Sandbox, the foundation's entry stage, announced at KubeCon and CloudNativeCon North America in Salt Lake City. General availability covers Agent Substrate on GKE, Google's managed product. Agent Substrate on GKE is generally available as a managed runtime. The three projects are working through CNCF Sandbox onboarding with community maintainers and independent build infrastructure.

Google's architecture diagram from the Open Source blog post, where requests enter through the router and the controller places actors on workers. Figure from https://opensource.googleblog.com/2026/11/sandboxing-untrusted-ai-agents-at-scale.html.

The managed GKE capability has specific deployment constraints. The GKE documentation requires Standard clusters on version 1.37 or later on both the control plane and the node pools, with x86 CPU worker nodes. Autopilot is excluded because the node agent, atelet, runs as a privileged DaemonSet, and microVM pools need nested virtualisation or bare metal. Accelerator-heavy agent workloads use the Pod-based path that Google calls Agent Sandbox, where GPUs and TPUs are supported with gVisor.

The restore figures carry conditions as well. Memory, root file system and volumes come back in under one second when the Actor resumes with the same hardware, sandbox runtime and container image. A change to the node hardware or runtime restores the root file system and volumes and restarts the processes. Updating the image while the Actor is suspended restores the volumes into containers started from the updated image. Resume latency also scales with snapshot size, which is why the documentation pushes large workspaces onto external Filestore volumes and keeps their data outside the snapshot.

What an operator still owns after the donation

Netics visual, 9 November 2026: the two isolation boundaries Substrate supports, compared on what each needs from the node and what each does to memory accounting.

Egress is the first item. Substrate blocks all outbound traffic by default, including traffic to other Actors, to the Kubernetes control plane, to the Compute Engine metadata server and to the internet, and it blocks non-DNS UDP, raw TCP connections and HTTP WebSocket upgrades. Rules live in an EgressPolicy resource and accept fully qualified domain names or wildcard hostnames, with no IP addresses and no CIDR ranges. A fleet that needs to reach an internal service by address has to put a name in front of it.

Capacity is the second. The warm pool sets both the latency a waking agent sees and the idle spend the operator carries, and the 10x density figure compares Substrate against container runtimes that hold one Pod per agent. A team sizing a pool for a few hundred concurrent sessions should measure its own ratio in a Standard cluster on 1.37 before quoting Google's number internally.

Governance is the third, and it is the one with the longest horizon. Three projects have just entered the foundation's entry stage, gVisor is on a path toward Incubation, and the design of the agent runtime, the sandbox kernel and the training loop will be settled in public maintainer forums. For teams that run agent workloads on their own Kubernetes estate, the transferable design is the split itself: stateful session identity in one layer, disposable compute in another, credentials enforced by the gateway.

Originally published on the Netics blog.

A Frozen Benchmark Measures What a Leaderboard Hides

Taha Echakiri — Wed, 11 Nov 2026 19:00:03 +0000

TL;DR

The Agentic Analytics Benchmark is a public test from ClickHouse in which models answer 201 analytics questions over a synthetic data warehouse, each writing its own SQL inside an agentic loop.
Round two, published on October 20, 2026, adds five models to the same board — GPT-6 Astra, GPT-6 Luna, GPT-6 Sol, Claude Opus 5.5 and Claude Sonnet 5.5 — on the same questions, warehouse and judge panel.
Thirty-four models now sit on the board; Claude Fable 5.1 keeps the top spot at 76.6%, and all five additions land in a 68.7 to 69.7% band, statistically tied with each other.
Sonnet 5.5 finishes every run inside the 60-turn budget where Sonnet 5 hit the cap on 16 questions, with about 5 cents per question against 7.
The gain lands on the 83 multi-hop dimensional questions, where Sonnet 5.5 scores 73.5% against 62.7%, on the same table-discovery rate.
Failures split into a wrong plan, wrong data selection and wrong implementation, and the wrong plan is the largest bucket for every new model, with no runtime errors.
The harness pins the query engine and the timezone, checks every provider credential before the first paid call, and runs a contamination probe, which is what makes a frozen board worth reading.
The board's measurement boundaries cover accuracy at one effort setting on one warehouse and exclude a reasoning-effort sweep, four cost rows with unreliable cache accounting, and any conclusion about your own schema.

A leaderboard that has stopped moving is a strange thing to publish. ClickHouse's second Agentic Analytics Benchmark adds five frontier models to a frozen board and reports that the top score barely shifted: Claude Fable 5.1 holds the lead at 76.6%, and the five new rows arrive between ranks 9 and 15. The interesting result sits in the columns beside the score, where turns, truncation and cost per question separate models that a single number makes look interchangeable.

The design is deliberately narrow. One warehouse, 201 curated questions with committee ground truth, a 60-turn budget per question, and a judge panel with one seat per provider where no model grades its own answers. A turn is one model call, and a turn can issue several SQL queries.

Thirty-four models answer the same 201 questions

The board ranks 34 models by pass rate on the same question set. Bright yellow marks the six rows in a statistical tie with the leader, and the post states the interval plainly: on 201 questions the 95% interval is about ±6 to 7 points. That interval is the most useful sentence in the article, because it converts a ranking into a set of overlapping bands.

Official ClickHouse chart (2026-10-20): the 34-model board ranked by pass rate on 201 questions at a 60-turn budget, with ties to the leader marked and the five new models in blue. Source: clickhouse.com.

All five additions conclude on every question, which the turn-limited column shows is rare enough to be worth reporting. GPT-6 Astra, Luna and Sol span 68.7 to 69.7% with overlapping intervals, below GPT-5.5 at 70.4% and above GPT-5.6 at 67.7%. Claude Opus 5.5 enters at 69.7%, two points above Opus 5 and level with GPT-6 Sol.

A caveat in the post deserves repeating, because it limits every GPT-6 row: all three ran at default reasoning effort. GPT-6 supports an "xhigh" setting that no model on the board has run with, and the first benchmark already showed how much a budget-shaped knob moves a Gemini number. Until that sweep runs, the label on those rows describes one configuration.

Claude Sonnet 5.5 finishes every run inside the turn budget

Sonnet 5.5's largest changes were in efficiency: turns, truncation, latency and cost. The pass rate is 68.7%, or 138 of 201 questions, against 62.2% for Sonnet 5. Paired on the same questions it wins 31 and loses 18, a net of 13 at a p of about 0.09, which the authors call directional and refuse to call significant. That restraint is the right call and it is rare in vendor benchmarking.

Official ClickHouse chart (2026-10-20): mean list-price cost per question against pass rate on a log scale, with Sonnet 5.5 near the cost frontier at about 5 cents a question. Source: clickhouse.com.

The efficiency numbers carry more weight. Sonnet 5 hit the 60-turn cap on 16 of 201 runs, which pushed its pass rate five points below its rate on the runs it concluded. Sonnet 5.5 hits the cap zero times, at a mean of 3.5 turns per question against 9.1, a median of 13.7 seconds per answer against 26, and $10.39 for the full run at list price against $14.40. Per question that is about 5 cents against 7.

Truncation is the column that a leaderboard habit hides. The accuracy figure records both incorrect answers and runs that exhaust the turn budget as failures. Buying on the headline score alone lands a team on the cheap seat of a family and then charges it in retries.

The gain lands on the multi-hop dimensional questions

The 201 questions are uneven by design. Eighty-three of them need the warehouse's normalized dimensional layer, and finding that layer was the main discriminator in the first round. Sonnet 5 scored 62.7% on those questions and Sonnet 5.5 scores 73.5%; on the remaining 118 questions the move is 61.9% to 65.3%.

The post explains what drives the delta. Both models discover the dimensional layer on about 89% of the questions that need it; Sonnet 5.5 uses the layer better once it is found. That is a statement about planning and joins, and it points a team at a different intervention: schema documentation and column comments help a model find a table, and clear grain and naming help it use the table correctly.

Official ClickHouse chart (2026-10-20): pass rate on the 83 questions that need the dimensional layer beside the other 118, for all 34 models. Source: clickhouse.com.

Failures split into plan, data selection and implementation

Of Sonnet 5.5's 63 failures, 75% are a wrong plan, 19% a wrong data selection and 6% a wrong implementation. There were no attempts skipped and no runtime errors. Sonnet 5 recorded 5% no-attempt and 15% wrong implementation, so the newer model always attempts and computes correctly more often; when it fails, it fails on the plan.

Across every new model the wrong plan is the largest bucket, from 51% for GPT-6 Astra to 75% for Sonnet 5.5, and none of the five produced a runtime error. The five new models produced no runtime errors on this warehouse. For these five models, deciding what to compute remained the largest failure category.

That failure shape changes how a team should test an analytics agent. A useful harness scores the final table and logs the plan, the tables read and the join order. Those traces give a team evidence it can use to improve the schema and the prompt, and they turn a failure into a category.

Official ClickHouse chart (2026-10-20): how each model's concluded failures split by mode, with the wrong plan as the largest share for every new row. Source: clickhouse.com.

The harness pins the engine and checks credentials before it spends

The reproducibility controls in this round are the part worth copying into any internal evaluation. The board manifest records the query engine release and the session timezone, and a run on a different engine is refused, because a silent engine upgrade had already flipped one question's ground truth. Every provider credential that the candidates, the judges and the column linker will touch is checked before the first paid call, so a dead judge key stops the run instead of degrading the scoring one question at a time.

Two further controls deserve a mention. Numeric tolerance is a scoring section in the model config, with currency values as the default, so the comparator no longer assumes money. And the judge model carries uncertainty: a many-facet Rasch model over the cached panel votes gives candidate ability, judge severity and an own-family coefficient with bootstrap intervals, computed offline from the results file.

The post also reports a contamination probe on the five new models. None of them recovers an anonymized entity name from a question prefix, at 0 of 25 each, and their completion similarity to the question set sits in the same low band as the rest of the board. Sonnet 5.5, the one addition with a Spider control, recovers 81% of entity names on Spider dev against 7% on these questions, which is what makes the probe credible: it detects memorization where memorization exists.

Official ClickHouse page capture (retrieved 2026-11-08): the round-two post, with the summary of the five added models and the definitions used across the board. Source: clickhouse.com.

The board's measurement boundaries

The board measures pass rate at one effort setting, on one synthetic warehouse, with one judge panel, inside a 60-turn budget. It leaves out a reasoning-effort sweep for the GPT-6 family, which the authors name as the next step, and it leaves out cost rows for four models whose gateway usage records do not split cached from uncached input reliably.

It also leaves out your schema. The post is explicit that nothing in the harness is specific to ClickHouse, and equally explicit that your warehouse will have its own discriminator: a slowly changing dimension, a semi-structured event table, a naming convention nobody wrote down. A benchmark answers which model behaves well on a class of questions. Testing on your own tables determines which model behaves well on them.

Run it on your own warehouse before choosing a model

The harness is public at github.com/ClickHouse/data-agent-mnist under Apache 2.0, and adding a model is a registry entry and one command. As an editorial recommendation, a small internal benchmark can start with questions drawn from real analyst requests, the same question set replayed every quarter, a frozen engine version, and a log of turns, cost and failure mode beside each score.

Netics editorial visual: the truncation result that separates the two Sonnet generations — zero capped runs out of 201 questions, against 16 for the earlier model.

Teams building the analytics application themselves, through custom web and mobile development, inherit both the schema and the question set, which makes them the cheapest place to run that board. The discipline that pays off is the one this post demonstrates: publish the interval, name the configuration, and keep the failure categories visible next to the score.

Originally published on the Netics blog.

The AI Labs' Public Pacing Calls Are Now Antitrust Evidence

Taha Echakiri — Wed, 11 Nov 2026 14:00:27 +0000

TL;DR

Four consumers filed a class action on September 18, 2026, accusing Anthropic, OpenAI, SpaceXAI and Google of a horizontal agreement to slow the pace of capability gains — built almost entirely from public statements made on September 12.
The complaint's spine: Amodei essays the proposal in the morning, Musk, Altman and Hassabis publicly assent the same day, and there is no antitrust waiver. "Proposed in public, accepted in public, and confirmed in public," as the filing puts it.
The concession that matters: within 29 pages, the complaint identifies no slowed release, no cancelled model, no altered training run.
Netics' take: the case is a stress test of how much legal exposure public safety coordination can create — for the labs, and for any industry that coordinates safety publicly.
For buyers, the practical watchlist has three items: the embedded-evaluator terms, the subscription-value argument, and settlement risk.

Cover page of Buist et al. v. Anthropic PBC et al., No. 3:26-cv-10693 (N.D. Cal.), a public court filing dated September 18, 2026; source: public docket copy of the complaint.

Four subscribers turned three days of public messaging into a Sherman Act case

On September 18, four consumers filed a class action in the Northern District of California: Buist v. Anthropic PBC, a complaint alleging that Anthropic, OpenAI, SpaceXAI and Google agreed to slow the pace at which each improves the products it sells to consumers — a horizontal restraint under section 1 of the Sherman Act. The named plaintiffs are paying subscribers of ChatGPT, Claude, Grok and Gemini, and the theory of harm is simple: an agreement that slows improvement lowers the quality of what subscribers receive for the price they pay. That, the complaint calls, is an overcharge.

What makes the filing unusual is not the theory — output-restricting cartels are an old antitrust story. It is the evidence. The complaint is assembled from material the defendants published themselves. Its central paragraph is worth reading in full: "The agreement was proposed in public, accepted in public, and confirmed in public." On the morning of September 12, Anthropic CEO Dario Amodei published an essay titled We Must Pace the Frontier; within about an hour, Elon Musk quote-posted it with "Dario is right"; later that day Sam Altman wrote "I agree with Dario that we need to pace the frontier", and the complaint says Demis Hassabis publicly endorsed the direction while noting that implementation details remained open. Three days later, OpenAI's policy chief confirmed talks had been running for weeks. A safety conversation between competitors is now the factual core of a federal antitrust complaint.

What the complaint actually pleads

Read paragraph by paragraph, the complaint builds a surprisingly complete agreement out of those statements. It pleads the parties (the frontier laboratories), the term (a slower rate of capability advancement than each would choose alone), the mechanisms (shared limits on training compute, training runs, and the internal use of AI to improve AI; capability checkpoints), and the means of policing defection — "verifiable pacing through embedded evaluators". It then walks the offer-acceptance-confirmation sequence day by day, including Amodei's own acknowledgment that the government "would need to issue a narrow waiver for certain kinds of safety conversations" — and the complaint's flat answer: "No such waiver exists. Congress has enacted no exemption, and no agency has compelled the conduct alleged herein."

Reproduction of page 14 of the Buist et al. v. Anthropic PBC complaint (No. 3:26-cv-10693), paragraphs 71-72 quoting the same-day acceptances by Musk, Altman and Hassabis; source: public docket copy of the complaint, September 18, 2026.

The market-power section is where readers should set expectations. The complaint puts the four defendants at "at least 80% of paid consumer subscriptions to general-purpose frontier generative-AI assistants in the United States" — but on information and belief, and as a floor. The plaintiffs avoid having to prove that number rigorously by pleading the restraint as naked: a horizontal agreement about output with no plausible efficiency justification, which under long-standing doctrine is condemned without a full market-power analysis. That is a strategic choice, and it is the strongest structural decision in the filing. Whether a court agrees that cross-lab safety coordination is a naked restraint rather than standard-setting with precompetitive content is the entire case in one sentence.

The concession on page 29

The complaint's own text contains the answer to its strongest claim. The filing concedes that the full effect on released products has not yet manifested — and across its 29 pages it identifies no delayed release, no cancelled model, no altered training run. The plaintiffs plead the restraint as naked to avoid proving a market, and in the same document they admit the restraint has produced no observable output effect. Under the rule of reason that would be fatal; under per se treatment it is merely uncomfortable. But uncomfortable is not nothing. The four acceptances are also not equivalent — Musk's was four words, Google's endorsed a direction with implementation details left open, and Amodei's own essay explicitly invited government mediation.

Original Netics diagram: the complaint's strongest materials against what cuts against it on the face of the filing; source: Buist v. Anthropic PBC, No. 3:26-cv-10693

For Netics' readers — European and Moroccan teams buying AI subscriptions for real workloads — the durable lesson is different from the legal one. The complaint was assembled entirely from public statements the executives made to signal safety leadership. Every sentence of it was public-record advocacy at the time. The same record that built trust with safety-minded buyers and regulators is now exhibit A in an antitrust filing. That is not a coincidence; it is the cost of doing safety coordination in public without a waiver, and Amodei flagged that exact risk in the essay. Companies that coordinate on safety — in AI, in semiconductors, in any output-sensitive industry — should read this filing as the template of what their own public statements can become.

What a buyer should watch

For enterprises and subscription teams, the practical watchlist has three items. First, the embedded-evaluator program: if discovery proceeds, its operational terms — who gets access, what they can verify, what the checkpoints actually gate — become the first concrete object of scrutiny, and those terms are also exactly what a buyer would want to read anyway. Second, the subscription-value argument: regardless of outcome, the complaint entrenches the idea that paid AI subscriptions are bought for the pace of improvement, which makes release cadence a contractual expectation in consumer protection terms too. Third, settlement risk: a four-defendant class action with treble damages and a jury demand rarely dies at the motion-to-dismiss stage even when the merits are thin, because the coordination admission is real. The labs' public safety posture, whatever its engineering content, now has a price in litigation.

Original Netics diagram: the September 12 sequence from Amodei's essay to the same-day acceptances, and the September 18 filing; source: Buist v. Anthropic PBC, No. 3:26-cv-10693

The honest reading is that this case could go either way, and the complaint's own concessions are the reason. If the restraint is treated as naked, the labs face an expensive discovery fight over a claim built from their own advocacy. If it is treated as coordinated standard-setting with safety content, the case narrows to whether the coordination was reasonable — a fight the labs may well win. Either way, the durably interesting object is the same one Netics has been pointing at for months: the boundary between an AI lab's public safety promises and its operational reality, which is also the boundary IT buyers should audit in their own vendors. For a practical review of where your subscription spend actually goes and what your AI tooling promises versus delivers, the Netics homepage is the starting point.

Originally published on the Netics blog.

GitHub Puts Merge Readiness at the Top of the Pull Request

Taha Echakiri — Wed, 11 Nov 2026 14:00:02 +0000

TL;DR

A pull request overview page is the pull request screen where a reviewer reads whether a change can merge, what is blocking it and who still has to approve it.
On November 5, 2026, GitHub opened the Overview page as an opt-in public preview, with rollout continuing through the weekend; merge status and the next available action sit at the top of the page.
The merge box was redesigned to carry the same information in less than half the space, and the review keeps checks, comments and approvals next to it.
Comment filters narrow the thread to unresolved conversations or to comments you wrote, newest-first sorting puts recent answers first, and an activity summary sits in the upper right.
Required checks and required approvals remain the merge evidence: branch protection is what turns a review into a gate, and the summary only reports that state.
A readiness summary measures the state of a change at one moment. A review routine for high pull request volume reads the diff, the migration path and the failing checks.
This is a starting point in preview: the classic overview remains available through the same menu, and GitHub is asking for feedback on what still loses context.

Review work has a shape that most engineering metrics miss. A reviewer opens a pull request, establishes what the change does, finds out what stands between it and the main branch, then decides whether to approve, request a change or leave the thread for later. On a long one it competes with dozens of comments and timeline events stacked above the merge box. GitHub's changelog post of November 5, 2026 opens with that exact complaint: "On a long pull request, checking what's blocking often means scrolling past dozens of comments and timeline events just to reach the merge box."

The Overview page redesign is aimed at that review loop. It is opt-in, it arrives in public preview, and the rollout continues through the weekend after publication. The interesting part for teams running review at scale is what the new page chooses to put first.

What the Overview page moves to the top

The page opens with a compact readiness summary that holds merge status and the next available action. Below it, a single row presents checks, comments and approvals together as supporting signals for the review. The design brief in the changelog is explicit about the goal: "Start with the summary, then follow the detail that matters to your next step."

Official GitHub screenshot (2026-11-05): the Overview page in public preview, with merge readiness, blocking detail and the next action assembled above the conversation. Source: github.blog/changelog.

To join the preview, select the ✨ Try the Overview page button in the header; the same menu returns to the classic overview during the preview. Draft pull requests can be marked ready for review and pull requests closed from the header, with the available actions following the reader's permissions.

Reading that placement as a product decision tells you something about where review time actually goes. The state of a pull request changes constantly: a check fails and is rerun, an approval lands, someone pushes a commit that dismisses an approval. A page that reports that state at the top saves a scroll on every visit, and the visits are frequent on a busy repository.

Official GitHub screenshot (2026-11-05): the classic merge box beside the compact readiness summary, with callouts pointing at the checks and the next available action. Source: github.blog/changelog.

A merge box that fits the review

The merge box is the block that reports whether a pull request can move forward. GitHub kept it and redesigned it: the new version shows the same information in less than half the space. The changelog lists three jobs the compact version has to serve — explore the supporting signals, address what is blocking, and merge once requirements are met.

Space is a real constraint here, and the trade-off shows up when a repository has many checks. A compact summary can show that a check failed and guide the reviewer to the supporting details. The reviewer can follow the summary to the failing checks and other supporting details.

Comment filters and newest-first sorting

Two smaller changes matter more than their size suggests. The conversation can be filtered to unresolved threads or to comments you wrote, and comments can be sorted newest-first. An activity summary in the upper right collects review comments, review requests and other updates.

Official GitHub screenshot (2026-11-05): comment filters for all, unresolved and your own comments, newest-first ordering, and the activity summary in the upper right. Source: github.blog/changelog.

Those three controls answer a question that grows with the size of the team: what changed since I last looked. Comment counts rarely help with that question, because a long pull request can contain dozens of comments and timeline events. Filtering to unresolved conversations gives the reviewer the open questions; filtering to your own comments gives the follow-ups owed to you; newest-first sorting puts the answer at the top.

Required checks and approvals as merge evidence

The summary reports a state that branch protection defines. GitHub's own documentation is blunt about the mechanics: with required reviews enabled, collaborators can only push changes to a protected branch through a pull request approved by the required number of reviewers, and with required status checks enabled, those checks must pass before anyone can merge.

That division of labour is worth keeping in view. The interface determines how quickly a reviewer learns the state. Protection rules determine whether that state blocks the merge. A team that turns on required checks in a repository where nobody reads the failing log line has gated the merge and postponed the investigation. The interface moves information about the gate to the top of the page. Protection rules still enforce the merge requirements, and reviewers remain responsible for judgement.

Official GitHub Docs capture (retrieved 2026-11-08): the merging page that documents merge options and the pull request requirements in front of them. Source: docs.github.com.

What a readiness summary measures about a change

The readiness summary shows merge status, blocking items and the next available action. Its supporting details lead to failing checks, pending approvals and relevant comments. Reviewers can then inspect the diff, the production path and test coverage before deciding whether to merge.

GitHub is careful about the scope of the preview, describing it as "very much a starting point" and asking readers where they still lose context. That framing matters for anyone deciding whether to switch a team onto it: the overview changes the cost of finding information, and leaves the substance of review where it was.

Netics editorial visual: the classic merge box at the bottom of a long thread beside the Overview readiness summary at the top, with the same merge state and a different amount of scrolling.

A review routine for rising pull request volume

The practical question for a small engineering team is what to standardise once an interface puts readiness first. The review routine keeps the following habits. Read the diff before the summary, because the summary describes a state the diff explains. Confirm that the check which passed actually exercises the change. Compare the change to the migration path, especially when the diff touches a schema. Record who approved and on what evidence, so the approval survives the next incident review.

Required status checks turn review into a gate, and the DevOps pipelines and managed monitoring behind those checks become part of the review's evidence. Pipeline duration affects reviewer wait times; a green check reported on a stale commit changes what that result means.

As people review more pull requests, time spent scrolling adds up. GitHub's framing in this changelog keeps the claim modest — "as people need to review more and more pull requests, time spent scrolling adds up" — and the fix offered here is a better-placed summary of state.

Netics editorial visual: four checks that keep a review substantive once the merge state sits at the top of the page.

The honest read is that the preview optimises what a reviewer sees first, and that the value shows up on long pull requests with many checks.

Originally published on the Netics blog.

Compute Engine Adds Immutable Date Versions Beside the v1 API

Taha Echakiri — Wed, 11 Nov 2026 09:00:01 +0000

TL;DR

Compute Engine API multi-versioning is a way to address the same service through several frozen, date-stamped contracts, and it is now generally available in every Google Cloud region.
Google published the change on 4 November 2026, with 2026-09-01 as the first stable version, 2026-10-01-preview available for testing, and the old /v1 endpoint still the default when no version is named.
Stable versions ship quarterly, carry a date such as 2026-09-01, and receive no breaking changes after publication.
Preview versions branch from a stable parent, run on a rapid cadence and carry a one-year lifespan before they disappear.
The request carries the version selection in the X-Goog-Api-Version header or the $apiVersion query parameter, so the base path stays /compute/v1/ and resource links stay uniform.
AggregatedList turns on partial success by default in dated versions, and errors arrive as google.rpc.ErrorInfo payloads with a reason, a domain and metadata.
A platform team pins what it owns: a client library release, a Terraform provider version and a stable date, and tests a preview where it wants early access.

Google Compute Engine has answered to one production endpoint, /v1, for more than a decade, and that endpoint served as the control plane for millions of virtual machines, Google Kubernetes Engine clusters and large AI builds. On 4 November 2026 the Google Cloud blog published the general availability of API multi-versioning, written by software engineer Michael Murstein, which adds immutable date-stamped versions beside the original endpoint.

The new version identifiers let Google evolve defaults and response formats within frozen contracts. A dated contract can carry its own defaults alongside /v1, allowing customers to adopt safer error formats and more resilient list calls on their chosen upgrade schedule.

Capture of the Google Cloud blog post introducing Compute Engine API multi-versioning, taken 4 November 2026 from cloud.google.com/blog/topics/developers-practitioners.

A date-stamped contract sits beside the decade-old v1

The old model was channel-based versioning: three long-lived channels named /v1, /beta and /alpha, with /v1 acting as a single mutable production surface shared by every customer worldwide. Any behavioural improvement on that surface, even correcting a counter-intuitive default or modernising an error format, risked breaking an existing script or required a multi-year migration.

Interface-based versioning, aligned with Google's AIP-185, keeps those channels and adds immutable snapshots identified by date. The post states the separation precisely: each stable version is a locked, point-in-time contract of every generally available Compute Engine feature and behavioural default, and it receives no breaking changes after publication.

Two properties of that arrangement are worth noting. The date names a contract that includes the defaults, so a team that pins a version also pins behaviour it never configured. And /v1 keeps working as the default, which means an organisation can adopt the model gradually and no estate has to migrate on the day of the announcement.

Hero figure from the Google Cloud blog post on Compute Engine API multi-versioning, downloaded 4 November 2026 from storage.googleapis.com/gweb-cloudblog-publish.

Stable versions arrive quarterly and hold still

A stable version is written as a plain date, YYYY-MM-DD, and the first one is 2026-09-01. Google releases a new stable version on a predictable quarterly cadence, and the post is explicit that published stable versions do not receive breaking changes and that they have no end-of-support date today.

That combination is the real news. A stable date version with no end-of-support date is a contract an integration can live inside for as long as the customer wants.

The honest caveat sits in the post itself: the sentence says there is no end-of-support date today. Google has left the door open to introduce one later, and any team treating 2026-09-01 as permanent should treat that clause as a warning that the support policy may change.

Netics visual: the three numbers that define the versioning model, taken from the Google Cloud post of 4 November 2026.

Preview versions branch from a stable parent

A preview version carries the suffix -preview, appears on a rapid cadence, and the post gives 2026-10-01-preview as the current example. Each preview branches from a stable parent, exists to expose upcoming features and API designs, and carries a predictable one-year lifespan for testing and feedback.

The lifespan is the useful part of the design, because it converts a vague promise into a date a team can plan around. A twelve-month window gives a team time to run a real pilot against a preview surface and sets a firm end date for that pilot, and the post tells customers to use preview SDK releases to test those features.

The risk profile is also clear. A preview is a testing surface by construction, and the one-year clock means anything built on it needs a production path back to a stable date. Teams that pin a preview in production are accepting a migration date they already know.

The request carries the version selection

Version selection is deliberately unglamorous. A caller keeps the /compute/v1/ base URL path and names the version with the X-Goog-Api-Version HTTP header or the $apiVersion query parameter, which the post illustrates with a curl call that passes X-Goog-Api-Version: 2026-09-01.

The benefit is that resource selfLink URIs stay uniform across tools and services. Keeping version selection in the request preserves stable URLs for links stored in runbooks, dashboards and Terraform state files.

Two commands are worth memorising, because they are how most teams actually reach the new surface. The gcloud compute command group targets the bundled stable API version, and the new gcloud preview compute command group targets the bundled preview version.

Capture of the AIP-185 page on API versioning that the Compute Engine post cites, taken 4 November 2026 from google.aip.dev/185.

AggregatedList stops failing when one zone is down

The first behavioural difference the post names is the partial-success default for global list requests. On legacy /v1, calling AggregatedList across all zones and regions leaves returnPartialSuccess at false, so a transient problem in a single zone can fail a global list request unless the caller opted in.

Dated versions enable partial success by default, and the consequence is practical: a fleet query keeps returning the zones that answered while reporting the ones that did not. Anyone who has written a script that tolerated one bad region by retrying the whole call will recognise the improvement.

This is also the clearest example of why the versioning model had to exist. Flipping that default on /v1 would have changed the result of an unknown number of scripts at once, and no responsible platform team does that to a surface shared by every customer.

Errors become fields you can read

The second behavioural change is in error handling. Dated versions adopt google.rpc.ErrorInfo payloads aligned with AIP-193, carrying a structured reason, a domain and contextual metadata, and the post gives the example that matters most during a migration: an invalid version identifier returns the list of supported_versions.

Anyone who has parsed cloud error strings with a regular expression knows the cost of the old approach. A structured reason survives a wording change, a metadata field can be read by a script, and a list of supported versions turns a guessed version name into a correctable mistake.

The post also lists two quieter changes: new versions let Compute Engine tighten overly broad legacy IAM permission checks and introduce safer configuration defaults, and multi-versioning gives Google a clean path to evolve decade-old resource schemas toward its own API improvement proposals.

Netics visual: the promise the original /v1 endpoint made, quoted from the Google Cloud post of 4 November 2026.

What a platform team should pin, and where

Pinning happens at four places, and each one has its own answer in the post. A client library release binds to a specific date-based API version automatically while keeping the /v1 package namespace, so upgrading the dependency is the whole action. The google Terraform provider targets stable dated APIs while google-beta targets previews. The gcloud CLI splits into gcloud compute for stable and gcloud preview compute for preview. A direct REST caller passes the header or the query parameter.

A workable policy follows from that list. Pin the client library and Terraform provider releases that carry the stable API you need, record their target date next to the deployment, and keep preview work on a separate pipeline whose output nobody depends on. Change one version string in staging, compare the response schemas and the defaults, then move production.

The migration is also a documentation exercise. Defaults that used to be implicit, such as the partial-success behaviour of a global list call, now depend on the version a request names, and a runbook that omits the version is a runbook that describes a moving target.

Netics visual: the four places where a Compute Engine API version gets pinned, from client library to raw HTTP.

Teams that run their own automation against cloud control planes should use this discipline for self-managed infrastructure: know which contract you depend on and write the date down. The versioning model is documented in the cited Google Cloud announcement.

Originally published on the Netics blog.

GPT-6 Prompt Caching Makes Latency and Cost an Engineering Choice

Taha Echakiri — Tue, 10 Nov 2026 14:00:12 +0000

TL;DR

OpenAI announced improved prompt caching for GPT-6 on September 22, 2026: higher cache hit rates by default, plus a dashboard, a diagnostics tool, explicit breakpoints, and prewarming.
Cached input tokens are discounted up to 90% for eligible shared prefixes reused within a 30-minute window.
The Prompt Caching Dashboard tracks hit rates; the diagnostics tool explains exactly why a request missed, with reasons like tools_changed and token counts.
Cache-friendly practice is now documented as a design discipline: stable tool ordering, append-only instructions, breakpoints, and prewarming.
Netics' take: prompt caching is an economic layer of the API, and the diagnostics are what turn it from a vendor black box into an auditable engineering choice.
For teams: put hit rate on the spend-limit review cadence, keep tool definitions stable, and use diagnostics when a miss surprises you.

Official OpenAI screenshot from "Better prompt caching for GPT-6" (openai.com, September 22, 2026): Prompt Caching Dashboard with cache hit rate, cache performance over time, and input token composition.

Caching was always the hidden economics of agents

Persistent agents make a series of API requests that build on one another, carrying forward the same instructions, tool definitions, and context across turns. Every one of those repeated input tokens is work the model has to redo — unless the provider caches the shared prefix. OpenAI has always kept some of that; what changed on September 22 is that the economics became visible and controllable. GPT-6 applications now get higher cache hit rates by default, a dashboard to monitor them, a diagnostics tool to explain misses, and explicit breakpoints to choose what is reused.

The 90% discount on cached input tokens is the part buyers will feel first. For a long-running agent whose context is mostly stable instructions and tool schemas, the difference between a cached and uncached run is the difference between a production budget and a fire. The 30-minute eligibility window matters too: it favors conversational workloads where turns arrive within a session, and it punishes applications that build a prompt from scratch on every call.

Original Netics diagram: the cached-input discount up to 90% and the 30-minute eligibility window — the two numbers that define GPT-6 prompt-caching economics; source: OpenAI prompt caching announcement.

Diagnostics turn a black box into an audit trail

The most interesting tool in the announcement is diagnostics. You compare a request with a recent response, and the API tells you why the expected prefix was not reused: model_changed, tools_changed, input_changed, service_tier_changed, context_compacted, or a custom cache key change — each with estimated token counts so you can size the impact. That is the difference between guessing why your bill jumped and knowing the exact request attribute that invalidated the cache.

The guidance that follows is a documented design discipline, not a footnote. Keep tool definitions, schemas, and ordering stable, because any change before a breakpoint silences the discount. Use allowed_tools to restrict which tools run, or tool_choice: none, instead of removing definitions. Append new developer messages to the end of the context rather than rewriting earlier ones. These are the operational habits that determine whether caching is a discount or a myth.

The prefix is the contract

OpenAI's docs are blunt about the mechanism: the cache stores key-value tensors, and reuse requires the entire rendered prefix to match. Change the model, the tools, the service tier, or the input before the breakpoint, and the prefix no longer matches an eligible cache entry. The minimum cacheable length is 1,024 tokens for GPT-5.6 and later — a threshold worth knowing before you design for caching, because below it nothing is reused at all.

Breakpoints are the place teams will either win or lose. An implicit-mode design reuses whatever prefix boundary the engine chooses; explicit breakpoints let you pin the exact boundaries you reuse — after developer instructions and tool definitions, before user conversation. The guidance is specific: to reuse an implicit prefix, place an explicit breakpoint at that boundary in later requests. Extending a user message instead of appending a new one can silently kill reuse, because the old boundary stops being a message end.

Original Netics diagram: four GPT-6 prompt-caching facts that define the operating boundary — 30-minute window, 1,024-token minimum cacheable prefix, KV tensors as the stored state, diagnostics at no additional cost; source: OpenAI docs.

Prewarming and reasoning-effort changes

Two features make caching friendlier for interactive agents. Prewarming lets an application prepare known context ahead of time — shared instructions, tool definitions, or reference material during startup — so the model starts responding sooner when the user asks the first question. The processing moves out of the user's wait time, which for a chat agent is the difference between "instant" and "spinner."

The second is subtler and genuinely useful: on GPT-6 models you can change reasoning effort between responses without breaking cache, by appending a configuration_update while leaving request-level reasoning effort unchanged. Raise effort for a hard task, lower it for a routine follow-up, and the reusable context survives the change. That removes a real tension in agent design, where adaptively spending more reasoning on hard steps used to cost you the entire cache.

Original Netics diagram: the prompt-caching discipline — stable tool definitions and ordering, allowed_tools instead of removal, append-only developer messages, explicit breakpoints, and prewarming; source: OpenAI prompt caching guide.

What teams should actually do

First, put the Prompt Caching Dashboard on the same review cadence as your spend limits: hit rate is now a product metric, and a drop in cache hits usually means a deploy changed tool ordering or instructions. Second, treat stable tool definitions as a code review rule — agents that regenerate tool schemas per request are paying the uncached rate by design. Third, use diagnostics when a miss surprises you; the reason it returns is the difference between "we changed the model" and "our prompt template embeds a timestamp."

The honest caveat is that caching also touches data handling. Diagnostics records contain configuration metadata, token-count estimates, and hashes — and OpenAI states they are compatible with Zero Data Retention, which matters for teams that turned on ZDR as an architecture constraint. Caching itself stores your context server-side; that was already true, but the new dashboards make the retention question more visible, not less. If you already treat API rate limits as part of agent architecture, prompt caching is the same story on the cost axis: the boundary is now measurable, and what is measurable can be governed. For a pass over your own agent cost structure, the Netics homepage is where we start.

Originally published on the Netics blog.

Chainalysis Says Live Tokens for Every User Were Exposed

Taha Echakiri — Mon, 09 Nov 2026 19:00:02 +0000

TL;DR

Chainalysis is a blockchain analysis company that governments and exchanges use to trace cryptocurrency transactions and to run compliance screening on them.
On 4 November 2026 the company disclosed that names, usernames, password hashes and live tokens for all of its users were exposed to a malicious actor, after its 30 October statement said it had found no evidence of access to authentication credentials.
An on-path attack exposed a subset of customer passwords, and the company locked the affected accounts and asked those users to reset passwords on any other system where they reused them.
A live bearer token works for whoever holds it until it expires or is revoked.
The recovery sequence Chainalysis now requires runs in a fixed order: submit trusted IP addresses for an allowlist, reset the password, rotate API keys, then register transactions.
The disclosure trail moved from reassurance about investigation content to mandatory rotation, and the company has given no detail on the AI agents it says were used against it.
The industry context adds an agentic scanning framework called ARTEX, with Microsoft reporting one agent that moved from scanning GitHub for secrets to exfiltrating data from Azure Key Vault in five minutes.
A security team can check three things in its own estate now: which tokens are long-lived, which vendor relationships hold broad scope, and whether the revocation path has been rehearsed.

The Chainalysis security incident page captured on 7 November 2026, headed with the 7 November update and carrying each dated statement in order. Capture of https://www.chainalysis.com/blog/security-incident-october-30/.

What Chainalysis disclosed, and when each fact arrived

Chainalysis published its first statement on 30 October 2026 and described an external actor using offensive agentic techniques to reach its systems and internal tools. That statement said the investigation had found "no evidence of unauthorized access to investigation content, authentication credentials, or session tokens", and it described the customer data reached as non-sensitive material such as user IDs, full names, email addresses and organization role labels.

On 4 November the same page carried a different sentence. An investigation begun on Monday had found that "certain customer information including names, usernames, password hashes and live tokens for all Chainalysis users were exposed to a malicious actor". The two statements describe the same incident, and their progression deserves close attention because the 4 November statement names live tokens among the exposed data after the 30 October statement reported no evidence of access to session tokens.

Between those two statements sit two operational decisions. On 2 November the company took Reactor and Data Solutions offline as a precaution. On 4 November, after detecting abnormal activity, it took the KYT interface and API offline along with other address screening products and the login page, which is the moment a compliance product stops screening transactions for its customers.

Netics visual, 7 November 2026: the 30 October sentence and the 4 November sentence, side by side, as the record moved from reassurance to token exposure.

A statement trail from contained vector to mandatory rotation

The on-path attack is the event the company describes most carefully and explains least. On 4 November it told customers that an on-path attack had exposed a subset of customer passwords, that the vector had been contained and remediated, and that accounts were locked as a precaution. An on-path attack means an adversary sitting in the path of traffic between two parties, and the questions that follow are where the compromise happened and whether the intercepted traffic was encrypted.

Ars Technica put both questions to the company on 6 November and reports that neither has been answered, along with a third: why the exposure of all customers' personal information was disclosed on Wednesday when the investigation found it two days earlier. Chainalysis told Ars that it would comment only through the statements in its post, which is a normal position during an active investigation and also the reason the record has to be read as a sequence.

The containment claim has a practical meaning for customers. Remediating the vector stops new interception; captured credentials still require revocation or replacement. That is why the same update asked users to reset the password anywhere they had reused it, and why the later updates move from password resets to API key rotation as the main requirement.

The Chainalysis blog index captured on 7 November 2026, where the incident post appears beside the company's other company-news items. Capture of https://www.chainalysis.com/blog/.

What exposed live tokens can permit

A password hash is a derived value that an attacker can try to crack offline, and a live token is a working key. Chainalysis says the exposed set includes live tokens for all of its users, which means the useful question for a customer is what those tokens were allowed to do and how long they lived, and the company answers part of it by requiring key rotation before transactions can be registered again.

The other part of the blast radius is who holds accounts. Ars Technica reports that Chainalysis and public sources list customers including the FBI, US Immigration and Customs Enforcement, the US Air Force, Microsoft, Coinbase and Barclays. For a compliance vendor, the metadata is the sensitive asset even when investigation content stays sealed: who screened which address, and when, is intelligence about an investigation.

The company's own account reports no evidence that investigation data was accessed or attribution data manipulated. Its 30 October statement says it found no evidence that investigation content, such as graphs, notes or cases, was accessed, and its 4 November update repeats that it has no evidence that investigation data was accessed or attribution data manipulated. Customers holding that assurance should read it as a statement about the platform's record store, and treat the token exposure as the separate problem it is.

Netics visual, 7 November 2026: the four categories Chainalysis named for every user, from names to live tokens.

The account recovery sequence Chainalysis now requires

The recovery instructions are the most transferable part of the incident, because they encode an order. Customers send trusted IP addresses so the company can add them to an allowlist, then users reset passwords and rotate API keys before they register transactions. On 6 November Chainalysis said it had begun restoring access to KYT and Address Screening in phases, while work to restore Reactor and Data Solutions continued.

That order exists because rotation alone leaves a gap. If an attacker holds a live token, a password reset changes one credential and the token keeps working until the issuing system revokes it, so an allowlist narrows the network path at the same time as the credential changes. The sequence also binds recovery to the customer's trusted network path while credentials are changed, limiting reliance on a shared secret that may already be in someone else's logs.

Two details deserve attention from anyone copying the pattern. The company locked impacted accounts and told users to reach the login page directly, which closes the password-reset phishing window that opens during every incident. It also warned that password resets would not work immediately, because the login page was part of the outage, which is the kind of sequencing problem that shows up when identity, application and network controls belong to three different teams.

Wiz's own product screenshot from its research post of 29 October 2026, showing a detection for a suspected network scanner reaching many endpoints inside a cloud account. Screenshot from https://www.wiz.io/blog/the-rise-of-agentic-attacks.

What the industry context adds about agentic attacks

Chainalysis describes its attacker as using offensive agentic techniques, and the surrounding reporting fills in what that phrase means in practice. The Hacker News quotes Microsoft describing an agentic framework called ARTEX that searches public repositories for exposed secrets, and Microsoft reports one case where an agent moved from scanning GitHub to exfiltrating data from Azure Key Vault in five minutes, with the activity assessed as ongoing from August 2026.

The same reporting names other companies that disclosed AI-driven attacks in the same period, among them Chainstack, OpenCode, Warp and WorkOS, and it describes a resale market where access to stolen model credentials is proxied to paying customers. The direction of travel matters for defenders: credential discovery that used to need a person at a keyboard now runs at machine speed, and the credentials worth taking include API keys for AI services.

For a team reading this from outside the cryptocurrency sector, the lesson lands on token inventory. An agent that finds one valid token can use the access it grants directly, and the value of that token depends on scope and lifetime, which are decisions a team makes before the incident and audits afterwards.

Wiz's own product screenshot from the same post, showing a process tree with a python3 http server started on a host, the kind of artifact a detection has to explain. Screenshot from https://www.wiz.io/blog/the-rise-of-agentic-attacks.

What a security team can check in its own estate

Three checks follow from this incident and use existing controls. The first is a token inventory: list every long-lived API key and service token the estate issues, note its scope, and shorten the ones whose lifetime nobody can justify. The second is a scope review of vendor relationships, especially vendors that hold identity or screening data, because a supplier failure transfers the resulting exposure to the customer.

The third is a rehearsal of the revocation path. A team that has never rotated a production API key under time pressure will discover its own sequencing problems during an incident, which is what the Chainalysis instructions expose: the login page, the allowlist and the key rotation all have to move in an order, and each one belongs to a different control.

Two open questions remain on the record. The company has not said how the on-path position was obtained or whether that traffic was encrypted, and it has not described the agents it says were used. Until those answers exist, the safe assumption for a customer is that the tokens were usable for the period between exposure and revocation, and that any action those tokens authorised deserves a review. Review provider key custody alongside identity and access work when building the token inventory this incident makes urgent.

Netics visual, 7 November 2026: what the platform looked like on 2 November, with screening offline, and what the 7 November restoration returns.

Originally published on the Netics blog.

NVIDIA Topograph Treats GPU Placement as a Live Topology Problem

Taha Echakiri — Mon, 09 Nov 2026 14:00:44 +0000

TL;DR

NVIDIA released Topograph (open source, dsx-ai-factory/topograph) on September 22, 2026: it discovers cluster topology from cloud APIs or on-premises fabric systems and normalizes it into a common model for schedulers.
It publishes that topology as Kubernetes node labels, Slurm configuration, or Slinky ConfigMaps — the formats workload managers already read.
Providers cover Google Cloud, Lambda, Nebius, Nscale, OCI, and Crusoe; on-premises support covers InfiniBand and NetQ-managed Spectrum-X or Multi-Node NVLink domains.
Topograph regenerates the view on request and on watched cluster changes, so schedulers never act on a stale drawing.
Netics' take: Topograph is a data pipeline wearing a scheduling hat — the win is treating topology as live infrastructure, not as a one-time cluster diagram.
For operators: start on Kubernetes, verify the labels appear, simulate first — and treat the topology view as monitored infrastructure.

Official NVIDIA Technical Blog hero for "Topology-Aware Workload Scheduling with NVIDIA Topograph" (developer.nvidia.com, September 22, 2026).

The placement problem is a data problem

GPU workload placement is where AI-factory economics are won or lost. NVLink provides 1.8 TB/s of bidirectional bandwidth per GPU in Blackwell and 3.6 TB/s in Vera Rubin; Quantum InfiniBand ports reach 800 Gb/s. A workload spread across distant topology domains crosses shared links, contends, fragments, and — the part vendors rarely say loudly — leaves GPUs consuming provisioned power while waiting on data. In a power-limited AI factory, that is not an efficiency footnote; it is the difference between a node earning its power draw and a node burning it.

The blocker is not that schedulers cannot do topology-aware placement. Slurm and Kubernetes both support it. The blocker is that a scheduler can only act on the topology it observes — and the current topology is exactly what most operators do not have. Manual cluster drawings go stale the moment a rack changes, a switch fails, or a maintenance window re-cables a domain. Topograph's core move is to treat that data as a live pipeline: discover, normalize, publish, and regenerate when the cluster changes.

Official NVIDIA Technical Blog Figure 1: Topograph architecture — generation request through provider selection, API Server dispatch, discovery and normalization, and engine publication to Slurm, Kubernetes, or instance-oriented topology JSON (developer.nvidia.com, September 22, 2026).

Providers and engines: the pipeline, named

Topograph's two concepts are worth understanding as architecture, because they map to real operational roles. Providers discover topology from cloud APIs or on-premises systems and normalize it into a canonical model; engines translate that model into the format each workload manager expects. One discovery layer, many outputs — Kubernetes node labels, Slurm topology.conf, Slinky ConfigMaps, NFD resources, or instance-oriented JSON.

The provider list reads like the current AI-cloud map: Google Cloud, Lambda, Nebius, Nscale, OCI, Crusoe on the managed side; InfiniBand through ibnetdiscover and NetQ for Spectrum-X or Multi-Node NVLink domains on-premises. The provider interface is open, which matters for private clusters — the operators who need this most are exactly the ones with a proprietary fabric vendor no public provider covers.

Original Netics diagram: the five publication formats Topograph writes — Kubernetes node labels, Slurm topology.conf (tree/block), Slinky ConfigMaps, NFD resources (alpha gate), and instance-oriented topology JSON; source: NVIDIA Topograph post.

Stale topology is the silent tax

The operational claim worth testing is regeneration. Topograph's five components — API Server, Node Observer, Node Data Broker, Provider, Engine — keep the view current: the Node Observer watches configured Kubernetes node or pod changes and requests regeneration with retries; duplicate requests are deduplicated behind a typical 15-second aggregation delay; the API exposes /v1/generate, /v1/topology, /v1/lookup, /healthz, and /metrics. In practice that means a failed switch or a node drain updates the labels schedulers read, instead of waiting for someone to remember to redraw the diagram.

The honest caveat is scope. The matrix in the post shows exactly which engine works for which provider — InfiniBand on bare metal or VMs, for example, publishes to Slinky and NFD but not to Kubernetes node labels; MNNVL NVLink partitions only reach the Slinky engine as DRA block topology. This is a young toolkit with real sharp edges, and the "topology-aware" promise is only as good as the provider-engine pairing you actually deploy.

Original Netics diagram: the stale-view versus live-view contrast — a manual cluster drawing that decays versus Topograph's regenerated topology published to the scheduler on request and on watched changes; source: NVIDIA Topograph post.

What an operator should do first

Start on Kubernetes, because that is where the feedback loop is easiest to verify. Deploy via Helm, pick a provider that matches where your GPUs live, and confirm the labels appear: fabric.topograph.run/tier-0..N and accelerator.topograph.run/domain. Those labels are immediately consumable by topology-aware schedulers like KAI Scheduler or Kueue's TAS for gang scheduling — and they are the same labels your observability stack can use to explain why a job landed where it did.

Then use the simulation utilities before touching production hardware: kwok-nodes and the Kind/KWOK helpers model node and switch hierarchies with no GPUs attached, which is the right way to validate provider behavior and engine output without a pilot cluster. When you do go live, treat the topology view as monitored infrastructure: hook /metrics into Prometheus, alert on stalled regeneration, and make "scheduler sees current topology" a documented production check rather than an assumption. Topology-aware placement only helps teams that keep the topology honest — and that is precisely what Topograph is for. If you already route local inference with NVIDIA PAIR, Topograph is the placement layer that decides which nodes PAIR has to choose from in the first place. For a practical pass over AI-factory scheduling, the Netics homepage is where we start.

Originally published on the Netics blog.