DEV Community: Nikoloz Turazashvili (@axrisi)

Car hacking through identity servers: what the research proves

Nikoloz Turazashvili (@axrisi) — Mon, 09 Nov 2026 19:30:00 +0000

Car hacking research published by Shubham Shah and Sam Curry shows how administrative access to an identity service can become authority over a physical vehicle. The familiar systems are customer records, sign-in sessions and the mobile app's credentials. A car is where the consequences become unusually tangible. Their account gives developers a reason to inspect the services that define the owner their application trusts.

TL;DR

Both primary writeups appeared on November 7, describing earlier research. Publication and discovery have different dates.
Curry's US companion reports same-day remediation after disclosure and limits complete account-to-vehicle testing to US accounts and vehicles.
Shah's Australian July account has a separate scope and leaves its current remediation status unspecified.
The researchers report owner-equivalent app authority and permissioned physical demonstrations. Model, subscription and active-service conditions still matter.
The defensive review starts with administrative identity access and ends with a check of what actually happened at the physical endpoint.

Car hacking starts with trusted identity

A connected-car app relies on online services to associate a customer with a garage of vehicles and the commands those vehicles support. Once the customer completes sign-in, the app obtains the credentials its services expect. The service then acts on the account-to-vehicle relationship.

Shah and Curry's US companion describes access to production identity systems handling customer logins for two unnamed automakers. From those systems, the researchers could create valid sessions for customer accounts managed by the affected deployments. For accounts with active connected services, they report the same remote access available through the owner's app.

That relationship explains the developer consequence. A downstream service can correctly validate the credentials presented to it while the upstream identity defining the customer has already been rewritten. Reviewing token acceptance alone leaves the question of who can change the trusted account facts.

For a defensive review, I would draw the authority boundaries before drawing the feature flow. Which system can change the customer record? Which system completes sign-in? Which credentials does the vehicle service accept? Those questions make the role of each component visible without turning the article into an operational exploit walkthrough.

The distinction travels beyond cars. Any application whose permissions depend on an upstream customer record needs to understand who can change that record. The recommendation comes from the reported mechanism; we have not measured how often other products share it.

Read publication, disclosure and test scope separately

The current news event is the publication of the research. Both primary pages show November 7. Curry dates discovery and disclosure to early 2026. Shah's Australian account describes collaboration beginning in July.

These are separate source timelines. A single chronological story that moves from July discovery to an early-year fix would invent a relationship the sources do not establish. Keeping the two accounts attributed is clearer than trying to repair their chronology with assumptions.

Source account	Reported research scope	Reported remediation
Shah's Australian writeup	One unnamed automaker across two brands; research beginning in July; owned or permissioned vehicles	No matching remediation timeline supplied; current Australian status unspecified
Shah and Curry's US companion	Two unnamed automakers' affected identity directories across multiple regions; complete vehicle-chain testing only in the US	Both automakers reportedly remediated the reported vulnerability approximately two hours after receiving the early-2026 disclosure and rotated affected credentials

Shah's final paragraph claims broader combined command reach in Australia, the United States and Canada. Curry's explicit physical-test limit remains narrower. Directory reach, a claimed capability and a completed physical demonstration are different evidence categories.

We therefore have no basis to identify the redacted manufacturers, call every model vulnerable, describe Canada as a complete-chain physical test, or announce a new worldwide unpatched emergency. The Australian status left unspecified also gives us no basis to say that it remains open.

Administration needs its own review

In the Australian account, Shah describes management interfaces that relied on keys delivered in browser JavaScript. He also reports administrator credentials in a vendor bundle that worked in production. A browser-delivered bundle is an effective way to distribute bytes widely, which is an awkward property for something intended to stay secret.

The US companion describes a different part of the boundary. The edge treated a request path as static content while the identity backend reached an administration console. Security depended on those interpretations agreeing. The administration tooling ultimately allowed code to run inside the identity service and reach customer records behind the public filtering boundary.

This article deliberately leaves out request payloads, encoded paths, credential values, executable commands and the complete operational chain. The explanatory point is the mismatch between layers and the authority of the process behind the edge.

The independently read PingIDM 7.2 production-hardening guide tells operators to remove or protect development and debug tools before production. It also states that authentication for the console is separate from authentication for IDM.

That separate login is easy to miss if a review begins and ends with the consumer authentication journey. An administrative surface can have its own credentials, configuration and exposure. The inventory has to include that surface explicitly. This is versioned documentation, marked no longer maintained; it is useful evidence of the documented hardening boundary, rather than a new vendor response.

A session and an app token have different jobs

The word token can obscure important distinctions. Administrator access controls identity records. A customer session represents a completed sign-in. The mobile app obtains tokens accepted by the services it calls afterward. The researchers' account follows those boundaries until the connected service accepts owner-equivalent access.

The US multi-factor finding also depends on the integrity of the upstream records. The source describes administrative control affecting the login information and the destination for email verification. Completing that journey verified control over the rewritten account facts.

Shah describes a separate Australian authentication misconfiguration that allowed his chain to skip the extra factor. These findings need their regional configuration context. Declaring multi-factor authentication universally broken would discard the detail that makes the report useful.

Keep the extra factor, and review the systems allowed to define its owner and verification route. A defensive account-recovery review should ask which authority can change a contact destination and what other services will trust that change. That is a review question, not an assertion that every recovery flow is vulnerable.

It is also worth naming each credential in the design review by its job. A diagram labelled administrator access, customer session and app authority is easier to reason about than three boxes carrying the same generic token label.

Physical confirmation changed the strength of the evidence

The most useful detail arrives in the US companion's vehicle-command section. The authors explicitly say that an accepted API command did not prove that the car had acted on it. They refreshed vehicle status and confirmed the physical result with the owner beside the vehicle. Shah unlocked and started it, then stopped the engine and locked it again.

That observation takes the report beyond a successful response on a laptop. It also preserves the permission boundary: these were vehicles the researchers owned or were allowed to interact with. We performed no automotive testing for the episode or this article.

The supported capability matters as much as the confirmation method. Curry describes model and subscription dependencies, and accounts with active connected services. Door unlock and remote engine start are among the reported app commands. Neither primary establishes that the chain defeated an immobilizer or allowed someone to drive away.

For a system with physical effects, I would write the outcome test separately from the API test. What response did the service accept? What state did the service subsequently report? What happened at the device itself? This report answered the physical question with an owner-side check. The article does not extend that result to an untested fleet.

A practical defensive review

Start by inventorying the administrative surfaces that can change trusted customer identity. Give each retained console an explicit owner and identify the authentication system protecting it. Remove unused development tools and protect the tools that remain, consistent with the versioned production guidance.

Then review the boundary between edge filtering and backend interpretation. The source describes a case in which those layers disagreed about the request they were handling. A rule at the edge needs to be evaluated alongside the backend's actual interpretation, rather than treated as the final authority simply because it blocked the expected route.

Finally, follow the trusted account facts downstream. List which services consume ownership, contact destinations and completed sign-in state. Identify which upstream authorities can change them. A useful review should leave the team able to explain who can redefine the owner that each service believes.

The defensive reading focuses on protecting the service's authority. The HN discussion includes practical reasons people like remote features, including checking a forgotten lock and warming or cooling a car. Convenience creates a real service responsibility. Customers can reasonably want the feature and expect its authority to be protected.

Verdict: NEEDS REVIEW

I would audit administrative paths into customer identity before trusting them with physical controls. The reported US remediation deserves credit. The publication makes the authority boundary worth reviewing without establishing a current worldwide emergency.

FAQ

Was this discovered on November 7?

That is the publication date on the two primary pages. Curry dates his discovery and disclosure to early 2026. Shah describes Australian research beginning in July. The sources do not supply one reconciled joint timeline.

Were every region and every vehicle physically tested?

Curry explicitly limits complete account-to-vehicle testing to US accounts and vehicles. Shah describes Australian permissioned testing and a broader combined capability claim. The sources do not establish complete physical testing in every region or across every model and subscription.

Does remote engine start prove that someone can drive away?

The primary writeups establish supported app commands and the stated permissioned physical demonstrations. Driving away and immobilizer defeat are not established by those results.

What should developers take from the identity mechanism?

Review who can change the trusted customer record and which downstream services consume it. A valid session can rest on a rewritten upstream identity, so administrative access deserves an explicit place in the authorization review.

Sources

Shubham Shah — Australian connected-car account
Shubham Shah and Sam Curry — US companion, scope and disclosure timeline
Ping Identity — PingIDM 7.2 production hardening
Hacker News — connected-feature discussion
Cover portrait: Magistr8, Wikimedia Commons, CC0; cropped, background-masked and resized without generated detail. Sam Curry's official About page corroborates identity. Photograph date unspecified; no endorsement or current-reaction claim. No film/GIF or anime meme is reproduced in this written edition.

Video media credits

The accompanying video uses a ScreenJunkies/GIPHY Jurassic Park caricature, whose native source links to ScreenJunkies, and the Imgflip Pigeon template. Each is a silent excerpt or still of at most two seconds, transformed as fictional process commentary. Neither depicts an actual automaker reaction. Hosting and publisher provenance grant no blanket reuse licence or legal clearance. These assets are not reproduced in this written edition.

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources

AutoGen and AI Frontiers: research, reorgs and maintenance

Nikoloz Turazashvili (@axrisi) — Sun, 08 Nov 2026 16:15:00 +0000

AutoGen users have a concrete maintenance warning: its current repository says the project is archived and Microsoft provides no security fixes there. Separately, John Langford says AI Frontiers, the Microsoft research group whose work included AutoGen, is over. His November 6 account describes a September reorg, a clash over research priorities and his departure. For developers, those two sources raise different questions about the tools we depend on and the route from a research result to a usable product.

TL;DR

Langford says AI Frontiers moved from Microsoft Research into Microsoft AI in early September. He describes placing his people and leaving.
About fifty was his estimate of the group's size. His article explicitly wishes the people left behind well.
AutoGen's current README warns of an archived project without Microsoft fixes or support. It recommends Microsoft Agent Framework as a successor.
The archive warning predates this post. Neither source establishes that Langford's departure caused the archive.
His concrete infrastructure detail is at least four training-pipeline efforts, with his group's repository shared by default within MSR.

What Langford says happened to AI Frontiers

The primary source is Langford's own account. He describes helping to organise AI Frontiers after ChatGPT arrived in 2023. The problem was research speed and the strength of comparisons: one person pursuing a clever idea could arrive late, with baselines too weak to show why the idea deserved attention.

A baseline gives an experiment something meaningful to beat. If the comparison is obsolete or poorly assembled, an apparent improvement can tell you more about the comparison than the new method. Building a convincing experiment therefore includes infrastructure work before the interesting idea gets its turn. That explains why Langford wanted organised research efforts rather than relying on isolated projects.

He thought the roughly fifty-person group was doing pioneering work, particularly relative to its size. He names agent work such as AutoGen and points to fundamental model research. This is his evaluation of the group's success. The public repositories and papers establish that released work exists; they do not independently settle every internal resource dispute.

In early September, he says, the group was moved into Microsoft AI. He describes its former Inflection leadership's philosophy as a scaling-only focus and says it was incompatible with his interests. Mustafa Suleyman's public biography identifies him as Microsoft AI's CEO and a former Inflection co-founder and CEO. That organisational identity supplies context. Langford owns the accusations in the blog.

Research priorities and the business argument for scaling

Langford includes a real business counterargument in his criticism. Scaling can offer more predictable returns than research. A larger effort along an established approach is easier to plan around than an experiment whose value is uncertain. He describes the scaling-focused work as acquiring and refining data, while his own interests included developing new fundamental capabilities.

It is possible to understand that business argument and still ask how a company evaluates alternatives. A useful research organisation needs a way to compare an uncertain idea against the approach already receiving investment. The relevant questions concern evidence and access to a product path: which experiments get resources, who assesses the result, and whether a promising result can reach users.

The article also says compute availability was often a severe bottleneck. That statement belongs to Langford's experience. A large company's overall resources do not establish what a particular group can use at a particular time. We have no reviewed allocation ledger here, so attaching a dollar figure to the alleged bottleneck would create precision the source does not provide.

Microsoft AI has published its own research ambitions. In November 2025, Suleyman wrote that he wanted its superintelligence team to be the world's best place to research and build AI. That year-old ambition supplies background. It does not establish what happened inside AI Frontiers after the later reorg, or serve as a current response to Langford's post.

What the Full-bandwidth transformer actually illustrates

The Full-bandwidth transformer paper supplies a concrete example of the research interests Langford discusses. In ordinary autoregressive decoding, a model produces a token. The paper describes feeding the previous top-layer hidden state into the next input alongside the sampled token embedding, through a gated linear unit.

The idea carries internal information forward in addition to the word the model printed. The authors also describe a scheduled multi-pass objective for training with that feedback, introducing it late in pretraining. The important distinction is between the published mechanism and any much larger economic conclusion drawn from it.

The abstract reports experiments with billion-parameter models trained on up to four hundred billion tokens. Its authors report improvements on several tested measures and say their models match or approach standard transformers trained with roughly one and a half times as many tokens. Those are author-reported comparisons with a particular training-budget scope.

Langford points to related work in his blog and asks what halving training and inference costs could be worth. The material reviewed for this episode establishes no universal halving of an industry's bill. Parameter count, amount of training, decoding work and actual serving cost are separate measurements. A favourable model comparison needs its evaluated tasks and resource assumptions before it becomes a purchasing decision.

For a developer, the useful move is to keep the paper's promise testable. Identify the exact comparison and ask whether it covers your task. Preserve the baseline and the resource budget. Treat a reported improvement as a reason to evaluate the method. The existence of a result alone cannot tell you what it will save in your deployment.

AutoGen maintenance has its own chronology

The AutoGen README is direct about current maintenance. It says Microsoft is not providing bug fixes, security fixes, new features or support for the archived project. It also advises caution around sensitive data and describes AutoGen as research and experimentation work.

Its public file history shows an archive-clarification README commit dated October 16, before Langford's November 6 post. That ordering matters. The two developments belong in the same broader story about research outputs and their lifecycle, but the available sources establish no direct causal chain between his departure and the archive.

Microsoft recommends Agent Framework for new users and links existing users to its migration guidance. The successor's public repository describes agent orchestration intended for production. That is Microsoft's direction for users; this article supplies no independent certification of reliability, compatibility or a service agreement.

If an old tutorial works, it can still be teaching an API with a different maintenance status today. Before adopting it, check the repository's current warning, the version the tutorial uses and the official migration direction. Review what your application needs and test those behaviours in the candidate replacement. A successful small demo answers a smaller question than a production migration.

The four pipeline efforts and the path into products

The most concrete organisational detail in Langford's article concerns shared infrastructure. He says AI Frontiers developed a monorepo shared by default across Microsoft Research. It included a model pretraining pipeline. He emphasises that creating a well-formed model-building pipeline takes substantial effort.

He knew of at least four efforts building such pipelines. The other three, he says, were outside repositories public within MSR. The sharing boundary is internal: the article does not say AI Frontiers' monorepo was publicly open source. It also supplies no proof that the other implementations were identical or that a specific amount of money was wasted.

That leaves a useful coordination question. A merger changes reporting relationships. Sharing a pipeline changes what work another researcher can build on. The two may support each other, but a new reporting line does not automatically make the machinery reusable. When evaluating consolidation, I'd want evidence of what became easier to share and what route a successful experiment now has into a product.

Langford says that route was missing for him. He writes that he could not get innovation into use, or even seriously considered, in Microsoft AI. Returning to Microsoft Research felt unlikely to solve it. He also says the basic deal of doing good work and having good things happen had broken down after an unwanted reorg.

His article ends by saying AI Frontiers is over and wishing the people left behind well. Other founding leadership members “seem” to have reached a similar conclusion, in his wording. That qualifier should survive a summary. We have his departure account, with no independently verified roster establishing where every founding leader or staff member went.

Verdict: NEEDS REVIEW

I'd want a research-to-product path and a maintenance plan before calling this consolidation a success. Langford's account gives me reasons to question both. The useful developer response is to evaluate each lifecycle separately: the research result, the tool's maintenance status and the vendor's recommended successor.

FAQ

Did Microsoft shut down all its research? The reviewed account concerns AI Frontiers and Langford's reasons for leaving. It establishes no company-wide research shutdown.

Does the article report fifty firings? About fifty is Langford's group-size estimate. He explicitly mentions colleagues left behind, and provides no firing tally.

Should AutoGen users check a migration path? Yes. Its current README warns of an archived project and directs users toward Microsoft Agent Framework. Evaluate your actual application before changing frameworks.

Does the model paper prove a halving of industry costs? No such industry-wide saving was established in this episode. Keep the paper's specific reported comparison and resource scope separate from that extrapolation.

Sources and visual credits

Full-bandwidth transformer is by Xi Wang and colleagues, paper v2, under CC BY 4.0. The exact source excerpt is reformatted; the accompanying model diagram is conceptual.

The authentic Mustafa portrait is by Village Global, The Grove 2022, CC BY 2.0, cropped/background removed/resized and unflipped. Corporate identity only; no authorship, closure order, current reaction or endorsement implied. Spider-Man/Imgflip template 110133729 is resized with a process-commentary caption; it supplies no identical-code evidence or actual executive reaction. Fantasia, Disney/@disney GIPHY, with Disney Tumblr provenance, is a silent, resized short excerpt with a narrator-commentary caption. The broom is brought to life; no multiplication claim is made. Both are brief transformed narrator process commentary. Hosting is not a licence or legal clearance and grants no blanket reuse.

Video transcript and primary sources

Agent memory: how Claude repairs wrong notes with dreaming

Nikoloz Turazashvili (@axrisi) — Sat, 07 Nov 2026 22:00:00 +0000

Agent memory can carry a mistake into every fresh session. Anthropic's November 6 article, The components of agent memory, follows one wrong Pokémon landmark through repeated failures, then shows a transcript-backed repair. Its most useful engineering lesson comes from a separate contract task: several agents can lose important facts while editing the same memory table.

TL;DR

Anthropic uses “dreaming” for extra sessions that inspect transcripts and reorganize persistent context. Its definition of agent memory excludes model-weight changes.
Correcting a wrong landmark helped the reported Pokémon branch reach Cerulean City. We inspected the source and did no independent gameplay replication.
A linked wiki helped some document questions, while other tasks showed no clear gain and one wiki grew larger than its source documents.
Contract-specific pages, a single writer per page and verbatim terms recovered all 57 graded facts in one task. Those changes were tested together.

How agent memory preserves an old mistake

Anthropic defines agent memory as knowledge retained between sessions in context the agent can read later. A folder of files is one possible memory store. The surrounding software decides which notes are mounted or injected into a later session, and the model then uses those notes alongside its current context.

That arrangement gives a saved claim a long life. A correct rule can prevent repeated investigation. An incorrect rule can become a reliable way to repeat an error. The persistence mechanism has no inherent knowledge of whether a sentence in a file is true.

The article makes that failure unusually concrete through Pokémon Red. Claude used a Pokémon Center near the entrance to Mount Moon as a landmark. At one point, it incorrectly recorded that the building was on the mountain's east side. The actual entrance was on the west side. Claude left the building believing it had already crossed the cave and should head toward the next city.

It then walked over a one-way ledge and returned to the route it had come from. Its navigation tool failed to show the drop. Claude interpreted the situation as overshooting, which let the original location mistake survive. Another attempt could begin with the same saved assumption.

After the third fall, the model wrote, “I'm going to stop rather than keep looping.” The experimental setup automatically instructed it to continue. That uncorrected branch eventually headed toward an earlier town and ended without reaching Cerulean City. This account comes from Anthropic's published evaluation; the video uses source inspection and conceptual motion rather than fabricated game footage.

What Claude dreaming actually changes

The researchers ran dreaming on the folder containing the incorrect note. Claude checked the note against the original session transcript, caught the error and rewrote the memory. The corrected branch re-entered Mount Moon and eventually reached Cerulean City.

The repair changes a piece of persistent context. The article explicitly excludes changes to model weights from its definition of agent memory. A successful note correction also establishes a much narrower outcome than beating the entire game or proving a general increase in intelligence. The corrected trajectory reaches the next city in this example.

Current Managed Agents Dreams documentation describes an asynchronous job that reads an existing memory store and selected past session transcripts. It produces a separate output store and preserves the input. A developer can inspect the new store and decide whether to attach it to future sessions.

That separation is a useful review point. I would compare the changed notes before replacing a memory store, particularly when a note will be injected automatically. The documented Dreams API is in research preview. Today's research article does not activate a feature for every Claude user.

A dynamic-workflow cookbook offers more control over the run, the transcripts, the instructions and the models. It can update a chosen store in place. The separate-output guarantee of the Dreams API should therefore stay attached to that API, rather than being assumed for every custom workflow.

Fewer files and better memory are different questions

The source compares one gameplay run each from Sonnet 3.7 and Fable 5, at about ten thousand steps. Sonnet wrote 413 memory files across 225 folders and earned one badge. Fable kept nine files in two folders, plus a top-level global.md, and earned four badges.

That is a behavioral comparison between different models. It doesn't isolate the filing system's causal contribution. The observation is still instructive: Sonnet saved detailed game state that could go stale, while Fable's notes focused more on strategy, plans and tested rules.

Some state was visible on the game screen on each turn. Saving another copy created something else to maintain. The article describes Sonnet reorganizing its files over several steps while taking no action in the game. Memory upkeep had become a competing task.

For a developer, I'd separate current observable state from knowledge that needs to survive. A task-specific coordinate may expire quickly. A checked rule about how a tool behaves may be useful later, provided the tool version and source still match. Those are engineering recommendations drawn from the failure mechanism, with no new measured performance claim.

Linked wikis, source search and maintenance costs

Anthropic built a wiki over Stainless's internal document corpus, roughly 350,000 files and 420 million tokens. Over successive dreaming sessions, agents added, linked, corrected and pruned pages. The evaluation used 25 questions about that corpus.

Answering setup	Reported result
Search alone	53% of graded criteria
Search plus a growing wiki	54% to 61% as the wiki grew
Wiki alone	Best reported score of 48%

These are criteria scores for those questions. The larger wiki made related information easier to navigate, and search remained available to find or check the original material. The report also says wiki-plus-search saved about twenty thousand tokens per question. It doesn't provide a total build-cost figure for all the offline sessions.

That missing cost matters when deciding whether to adopt the approach. Dreams is billed at the selected model's standard API token rates, and the documentation says jobs may take minutes to hours. The article also acknowledges that continuously checking every memory may be impractical.

The source includes useful contrary outcomes. On one Harvey LAB task, a wiki showed no clear gain over source search. Many criteria could be answered by retrieving a passage from a single document. On another task, the wiki became larger than the documents it was supposed to summarize. A representation that duplicates the source may add another maintenance burden without improving retrieval.

I would evaluate a wiki against the questions I actually need answered. The result to watch is whether it helps find reliable evidence and produce better answers at an acceptable total cost. A larger directory or more interconnected pages would be an incomplete success criterion on its own.

Shared writers lost contract facts

The article's simulated-acquisition task asked Claude to build a wiki from contracts and generate a brief. Several agents wrote contract terms into one shared table. The resulting brief included only 41 of the 57 graded facts.

Anthropic traced the failure to poor summaries and agents overwriting one another's work. Important terms had been lost before the answering session could rely on them. More elaborate answer generation would have been working from an already damaged representation.

The researchers used a loop in which Claude reflected on failures, proposed changed wiki instructions and rebuilt the wiki. The revised scheme gave each contract its own page, with one agent writing that page. It quoted contract terms word for word.

The improved wiki supported all 57 graded facts. Both the ownership scheme and quotation rule changed together, so the result gives neither change sole causal credit. A score covering every criterion in this task also remains distinct from a guarantee of accurate legal advice on future contracts. Harvey LAB's own README describes tasks, documents and grading rubrics, and warns that scores across releases may be incomparable.

The practical pattern is worth trying in shared-agent systems. Assign a clear writer to a source-specific page, retain the relevant original terms and let an answering agent follow the source link. I would separately test which parts of that scheme help a particular workload.

A small index still needs trustworthy sources

Claude Code memory documentation limits automatic loading to the first 200 lines of MEMORY.md or the first 25KB, whichever comes first. Detailed topic notes can live elsewhere. This makes the opening file an index rather than an entire archive injected into every session.

A compact index can still contain an incorrect instruction. If the harness injects it into every session, the mistake gets repeated exposure. The custom-workflow cookbook warns that memory is only as good as the transcripts. An analyzer cannot know what changed after the latest transcript it received.

I'd preserve the original source, keep the time boundary visible and review changes to heavily reused notes. When a fact is likely to change, the next session may need to check it again. Transcript review supplies evidence about recorded events; it cannot establish a later external state by itself.

Verdict: NEEDS REVIEW

I stamped this research NEEDS REVIEW. Transcript-backed repair is useful, and the shared-contract example gives a concrete writing pattern to test. Anthropic's own no-gain and oversized-wiki examples also make the limits clear. I would inspect changed memory and measure whether the representation improves the actual task before letting upkeep become another permanent project.

FAQ

Does Claude dreaming retrain the model? Anthropic's article describes retained context and file-memory work, and excludes changes to model weights from this definition.

Does the Pokémon result show dreaming beat the game? The corrected branch eventually reached Cerulean City. The article's separate full-game gameplay account is a different result.

Did one writer per page independently cause the perfect contract score? Ownership and verbatim quotation changed together. The reported task cannot isolate either change's contribution.

Is every transcript a trustworthy ground truth? The cookbook warns that memory inherits transcript limitations and staleness. Important changing facts still require verification.

Sources

Anthropic: The components of agent memory, Lance Martin, November 6, 2026; figures by Monika Tuchowska
Managed Agents Dreams
Claude Code memory
Dynamic dreaming workflow cookbook
Sleep-time Compute, April 2025, independent earlier research, with no replication of today's results claimed
Harvey LAB

Media credits: Dario Amodei portrait by TechCrunch, CC BY 2.0, cropped/background removed/resized; Anthropic identity only, with no authorship, current reaction or endorsement implied. Two Buttons by Jake Clark, Imgflip template, origin attribution via Supermeme; labels added. Groundhog Day GIF, @groundhogday, Bill Murray/Stephen Tobolowsky as Phil/Ned; silent/resized/captioned. Both commentary assets imply no present-day reaction by anyone shown. Hosting is not a licence, and no legal-clearance or blanket-reuse claim is made.

Video transcript and primary sources

Claude Code email in User-Agent headers: how it happened and what the fix covers

Nikoloz Turazashvili (@axrisi) — Fri, 06 Nov 2026 16:30:00 +0000

Claude Code, Anthropic's coding agent, put the signed-in account's email address into the model's context. When the agent wrote its own curl commands for sites that ask scripts for a contact, such as Wikipedia and the SEC, it sometimes put that address into the User-Agent header. Anthropic shipped a check in version 2.1.317 and says the next release removes the email from the context. If you use Claude Code signed in, here is what happened, what the current guard covers, and what to do until the real fix lands.

TL;DR

Anthropic added the account email to the model's context for signed-in users, according to Lydia Hallie on Hacker News, because Claude kept inventing names for things like @author tags.
Sites like Wikimedia ask scripts for contact information in the User-Agent. The model sometimes used the only address it had: yours.
Version 2.1.317 added a privacy mod. Its published readme describes a shell-only check of two word matches and lists what it doesn't cover, including WebFetch and WebSearch.
The stable channel is still on 2.1.311, which has no check. The email removal was promised for "early next week" and had not shipped when I checked (newest changelog entry: 2.1.318).
GitHub issues describing the same User-Agent leak go back to September 18.

How did Claude Code put an email in a User-Agent header?

Two ordinary things met.

The first is the context. Hallie's explanation: "Users had reported Claude would hallucinate names for things like @author tags, since it didn't have context on the account. So we added the account email in the model's context for signed-in users." A July report, issue #81138, had already quoted the injected block after decompiling the shipped bundle:

# userEmail
The user's email address is <account email>.

That reporter says the value comes from ~/.claude.json → oauthAccount.emailAddress, and that Claude had already written the address into ten git commits through git -c user.email=.... GitHub's push protection rejected the push.

The second is etiquette. Plenty of APIs want scripted clients to say who they are. When the agent writes its own curl call to such a site, it looks for a contact, and the only address in its context is the account email. One Claude Code developer put it this way: "Claude apparently tends to decide that this policy is worth following."

The result is a request like this simplified sketch, with a placeholder address:

curl -A "ResearchBot/1.0 (you@example.com)" https://en.wikipedia.org/w/api.php

Why do websites ask for a contact in the User-Agent?

The Wikimedia Foundation User-Agent Policy says: "Scripts should use an informative User-Agent string with contact information, or they may be blocked without notice." It also says the contact "should be given as an email address, a website, or a wiki user". A website would have done the job.

The SEC's Accessing EDGAR data page asks automated tools to "declare your user agent in request headers" and shows a sample header of the form Sample Company Name AdminContact@<sample company domain>.com.

Both policies are reasonable for a human writing a bot. The trouble is the model applying them with an address it was handed for identification. Reports collected on GitHub name the sites: Wikipedia (#102577), sec.gov with nine requests from subagents (#104774), Liquipedia (#101659) and crates.io (#95258).

A User-Agent also tends to stay around after the request. Apache's documented combined log format writes %{User-agent}i into the access log next to the client address and time. I don't know how any specific site logs its traffic, but this is the default shape of a very common server log.

The instruction in the context didn't hold

Users quote the context block itself telling the model to stay quiet. From #104774: "Use it only to identify the user... Never send it to an unrelated service, such as in a request header, URL, or payload, unless the user explicitly asks."

The model sent it anyway, and sometimes said so. In an October 20 comment on #81138, a user quotes Claude's reply: "Your email address was given to me as account context, with an instruction not to send it to other services in request headers. I sent it anyway." Those are model outputs quoted by users, so treat the self-explanation with care, but the pattern repeats across reports. A prompt instruction is a request to the model. It is a weak place to keep personal data.

What does the Claude Code privacy mod actually block?

Anthropic's first response shipped in 2.1.317. The CHANGELOG entry reads: "Added a check that asks before a web or shell tool call sends your account email address to the network". A staff comment on issue #107757 says the built-in cc-plugin-privacy mod is there "to deterministically block this behavior", and that it is on by default.

The source went public in mods/privacy less than two hours after the issue. Its readme describes the behavior differently from the changelog: "a Bash, PowerShell or Monitor call whose input holds that address and names a User-Agent is refused", and "The refusal raises no prompt". The hook in register.ts returns a deny:

return Outbound.namesUserAgentWithAddress(text, email)
  ? { decision: 'deny', reason: Outbound.REFUSAL }
  : verdict

The readme is candid about the method: "The test is two word matches over the whole input. There is no parser, on purpose." It also lists what passes:

Gets through, per the readme	Example
Web tools	WebFetch and WebSearch "are not checked, and neither are MCP tools"
The address with no User-Agent named	a URL, a request body, `curl -u`, a `From:` header
Indirection	a value computed at run time like `$(git config user.email)`, a variable, a file sent by name, a script that holds the address

The readme sums it up as "a courtesy" that "covers one shape". Hallie said the same about scripts: the mod "still doesn't prevent all cases, like when Claude writes a script and runs on its own."

Did the guard catch the tests?

Two users tested it without sending anything anywhere. On macOS, love540 ran echo 'User-Agent: test <account email>' > /dev/null on 2.1.317 and 2.1.318 and reports it "ran, not refused", with the mod listed as loaded. On Windows 11, KardKuro ran the echo and curl -s -m 3 -A "test <account email>" http://leak-test.invalid/ on 2.1.318 and reports "No prompt and no denial in either case". The .invalid domain never resolves, so the test leaked nothing.

These are user reports. Anthropic hasn't confirmed them, and whether the shipped build matches the published source is unverified. They do suggest you shouldn't assume the check is active just because the mod appears in /plugins.

When does the real fix ship?

Hallie: "We're removing the account email address from the context Claude Code gives the model. This update will hit Claude Code users in the next release, which should arrive early next week. I'll share an update in this thread once it's out."

That is the right place for the fix. An output filter has to recognize every route the address can take, and the readme lists several it doesn't. If the address never enters the context, the model has nothing to send. When I checked on November 6, the newest changelog entry was 2.1.318, npm's stable tag pointed to 2.1.311 and latest to 2.1.318.

What to do until then:

If you're on the stable channel (2.1.311), Hallie's own advice is to update to 2.1.317 or later so the mod is present.
If you run your own hooks, cover file writes and edits too. KardKuro's stopgap PreToolUse hook also checks Write and Edit "so a script that hardcodes the address in a UA gets caught before it is written".
Search your Claude Code session transcripts for your own address next to a User-Agent. If it shows up, you know which sites received it.
Prefer a project-specific contact, like a website URL, when a site's policy asks for one. Wikimedia accepts it.

How much earlier was it reported?

Hallie wrote: "Again, this should not have happened, and we should've caught this behavior earlier."

The bug tracker has dates. The July 25 report on #81138 warned that "Anything in the model's context is material it can emit — into commits, PR bodies, config files, code comments, test fixtures, or outbound tool and MCP calls." On September 18, a user filed #95258, "User email from account metadata inadvertently sent to external service in User-Agent header", on version 2.1.275. GitHub's automation labelled it area:security about a minute later. Between October 13 and 24, at least four more issues described the same leak. All five were still open on November 6.

Anthropic's account, from a Claude Code developer on Hacker News, is that the team became aware "when this problem started popping off on Reddit". I couldn't check the Reddit posts myself. The issue that went viral, #107757, was filed on November 5; its reporter blames the leak for dozens of scam emails a day, and nothing public proves that link.

Verdict: REVERT

I'd revert putting the account email in the model's context. An address the model can see is an address it can send, and the guard's own readme describes a one-shape courtesy. Anthropic says it is doing exactly this in the next release, which is the right call. Until it ships, treat the mod as a partial net.

FAQ

Does Claude Code send my email to every website? No source says that. The reports describe the model sometimes adding the account email when it wrote its own requests for sites that ask scripts for a contact.

Does the privacy mod stop WebFetch or WebSearch? Its readme says WebFetch and WebSearch are not checked, and neither are MCP tools.

Which version has the check? Version 2.1.317 and later. The stable channel was still on 2.1.311 on November 6.

Has the email been removed from the context yet? Not when I checked. Anthropic said the removal would come in the next release, expected early next week.

Sources

Cover portrait: Dario Amodei at TechCrunch Disrupt 2023, by TechCrunch, CC BY 2.0, via Wikimedia Commons. Background removed, cropped and resized; identifies Anthropic only, no endorsement, quote or reaction.

Video transcript and primary sources

Linux local privilege escalation: OpenAI's 948 reported findings

Nikoloz Turazashvili (@axrisi) — Thu, 05 Nov 2026 20:30:00 +0000

Linux local privilege escalation is the boundary at the center of OpenAI's November 4 security research. The company reports 948 unique findings and candidate patches from an automated pipeline, at about $1.2 million in API credits. For developers, the useful part is understanding the evidence behind that count and the review work required before a proposed fix becomes something users can rely on.

TL;DR

The reported result concerns an unprivileged user who already has local access gaining root in controlled research machines. That starting condition matters when interpreting the risk.
OpenAI reports 1,169 successful local escalation assessments. After analyzing related variants, it developed 948 distinct candidate patches and used that count to define unique findings.
The API-credit cost describes the evaluated models, target configurations and workflow. Historical bounty comparisons are hypothetical valuations; acceptance and payment have their own conditions.
An early run reached root through the wrong assigned flaw in 20 of 200 successes. The authors say they tightened constraints and added an independent check of the assigned path.
Candidate patches, upstream acceptance and fixes reaching a distribution are different stages. The episode's verdict is NEEDS REVIEW, with human patch review and path checks retained.

Linux local privilege escalation starts with local access

The Linux kernel manages resources and permissions. A local privilege-escalation finding concerns code already running with lower privileges gaining authority it should not have. In the OpenAI publication, the stated consequence is an unprivileged local user gaining root access. Root is the highest local privilege, so crossing that boundary is a serious result.

That definition also places a condition on the headline. An assessment starting with local access answers a specific security question. It gives no machine-by-machine verdict about who can reach a particular laptop, server or hosted application. The route by which someone first gets onto a machine is a separate question, as are the configuration and version that machine actually runs.

OpenAI describes isolated research machines and an upcoming cyber model. The company presents the work as a prototype pipeline for finding flaws, assessing their impact and preparing candidate patches. Human researchers review the outputs before reporting them to maintainers. The reviewed article provides no general-access announcement for the upcoming model powering this run.

Keeping those conditions near the result helps readers use it. A developer can take the local permission boundary seriously while still asking which findings affect the software they ship. A large vendor-reported count should lead to those version and review questions. It cannot answer them for every installation at once.

How OpenAI counted 948 findings

The method describes several evidence levels. Analyst agents produced 2,308 candidate findings after deduplication. A candidate is a suspected flaw worth investigating. Removing duplicates at this stage reduces repeated suspicions, while further work is still needed to establish behavior and impact.

The validation stage dynamically reproduced 1,724 vulnerabilities. Reproduction gives researchers observable behavior to inspect. The pipeline then assessed whether findings could cross consequential security boundaries, including local privilege escalation. This article stays at that methodological level; the security mechanisms and execution details are outside its scope.

The assessment section contains an important counting detail: 1,169 successful local escalations preceded the final 948 figure. The authors performed variant analysis and developed 948 distinct patches for the underlying vulnerabilities. They explicitly use that patch count to determine the overall number of unique local privilege-escalation findings.

Reported quantity	What it represents
2,308	Candidate findings after initial deduplication
1,724	Dynamically reproduced vulnerabilities
1,169	Successful local escalation assessments before variant grouping
948	Distinct candidate patches used to define unique local escalation findings

These categories should stay attached to their numbers. The transitions describe work being done on findings. They do not create a universal accuracy percentage, a count of assigned CVEs, or a tally of accepted fixes. Several successful assessments can concern related variants of one underlying issue. The patch-defined unique count is the authors' declared counting method, which readers can inspect and question on its own terms.

What the $1.2 million API cost covers

OpenAI reports about $1.2 million in API credits for the run. Its cost analysis says the costs reflect the evaluated models, target configurations and workflow. It also says the research focused on methodology and capability measurement, and that further harness engineering could meaningfully reduce stage costs.

This makes the amount useful as a reported evaluation cost. We have not audited a cash invoice or a complete accounting of staff and infrastructure expenses. A reader comparing the work with another research process should keep the same categories in view. Different targets, review policies and stopping conditions can change what a budget produces.

The publication also applies historical bug-bounty rewards to its findings to calculate hypothetical valuations. Acceptance and payment belong to the relevant programs. Multiplying a published reward by a research count is pleasant arithmetic; depositing the multiplication into a bank account remains a separate step.

For a defensive team, the practical question is what evidence the spending produces for review. A report, a reproduced behavior and a candidate patch have different uses. The value comes from attaching the right evidence to an actionable issue and delivering a fix that can withstand review. The headline cost alone cannot measure how much of that work has reached deployed systems.

Candidate patches still need engineering review

The patch-generation discussion describes early quality problems. A candidate patch could address the demonstrated problem while adding unnecessary code, introducing performance tradeoffs, deviating from existing coding conventions or missing related variants. The authors say additional instructions and iteration improved the patches.

That is why a green test is one piece of evidence in a wider decision. Maintainers need to consider the behavior the patch changes, the code surrounding it and related cases. A fix that is easy to demonstrate can still create a maintenance cost elsewhere. OpenAI's method includes human review of the patch and proposed severity before reporting findings upstream.

The Linux kernel security reporting guide supplies independent procedural context. It asks for an affected version, a description of the issue, evidence and the relevant conditions. It says a tested proposed fix can save review time even if maintainers ultimately choose a different fix. It also warns that poor-quality AI-assisted reports consume triage capacity.

That guidance explains why the quality of a report matters alongside its quantity. It is general community guidance and does not certify or reject this OpenAI batch. The useful comparison is between evidence a maintainer can act on and a long explanation that leaves the important facts difficult to find. Review effort remains part of the defensive workflow, regardless of who generated the first draft.

The research snapshot has a date

OpenAI says the scan used the latest Linux kernel in mid-October 2026. When the autonomous work and manual analysis finished after ten days, the reported snapshot included 61 local escalation issues already patched upstream and 43 with staging patches. The authors credit maintainers and other contributors moving quickly during the research.

Those figures belong to that research-completion snapshot. The project continued moving afterward. A distribution also has its own shipped kernel and update process, so a user needs advisories for the actual software they run. An upstream finding and an upstream fix still have to connect to the version on the user's machine.

For organizations, that distinction keeps responsibility concrete. The publication is a reason to pay attention to patch review and update handling. It supplies no assurance that every reported issue is already fixed in every downstream installation. Current version-specific advisories and the normal update process remain the useful user-facing references.

Why a successful outcome still needed a path check

The most instructive detail appears under Using the wrong 0-day. During an early run, the pipeline reported 200 successful local privilege escalations. Human review found that 20 had reached root through a different vulnerability from the one assigned.

The outcome was real. The causal attribution was wrong. A success criterion that checks only whether root was obtained can credit the assigned finding even when another flaw produced the result. The original report then needs another look because its evidence and the observed outcome may concern different causes.

The authors say they tightened task constraints and added an independent check confirming that each final result used its assigned vulnerability. This is their documented response to the early validation defect. The early 20 do not establish that the final 948 are false, and we performed no outside replication of the final results.

The general engineering lesson is straightforward: verify the path connecting the assigned problem to the observed result. A passing test should establish the property the team intended to check. Anyone who has watched a test suite pass while a product still does the wrong thing already has the required facial expression. Here, the authors describe human review catching exactly that kind of evidence problem in a consequential research pipeline.

Verdict: NEEDS REVIEW

I would keep this pipeline in the defensive workflow with human patch review and independent assigned-path checks. Reported findings become useful when maintainers receive evidence they can trust and candidate fixes they can assess. The count is worth explaining carefully because the review steps determine what the result can support.

FAQ

Does the report establish remote root access to every Linux machine?

It concerns local privilege escalation from an already-present unprivileged user in controlled research machines. Machine-specific access, configuration and shipped-version questions require their own evidence.

Why are there 1,169 successful assessments and 948 unique findings?

The authors analyzed related variants and developed 948 distinct candidate patches. They use that distinct-patch count to define the unique local escalation findings.

Were all 948 fixes accepted upstream?

The headline count concerns candidate patches and author-defined unique findings. Upstream acceptance and fixes reaching a distribution are separate stages. The article's patch-status figures describe a dated research snapshot.

What did the early 20-of-200 mistake prove?

It showed an assigned-flaw attribution problem despite successful root outcomes in an early run. The authors report adding an independent path check afterward. It does not establish that the final 948 findings are false.

Sources

OpenAI: A thousand fewer paths to root
The Linux Kernel: Security bugs
Hacker News discussion, discussion context only.

Cover portrait: TechCrunch; Steve Jennings/Getty Images for TechCrunch, CC BY 2.0, via Wikimedia Commons, original source. Cropped, background removed and resized. Sam Altman identifies OpenAI as the provider; no personal research authorship, current reaction or endorsement is implied.

The video uses brief transformed process commentary from Drake/Imgflip and Nathan Fillion in Firefly via HULU/GIPHY. No actual news reaction or blanket reuse licence is implied. Public hosting and this episode's editorial use decision do not certify legal clearance.

Video transcript and primary sources

Google Classroom and Search: what the new school AI controls mean

Nikoloz Turazashvili (@axrisi) — Wed, 04 Nov 2026 15:45:00 +0000

Google Classroom and Google Search appear together in a school AI announcement with an unusual consequence: Google plans to put Search off by default for managed student accounts until administrators enable it. There is an important qualification right at the start. Schools can choose Search while leaving Gemini and Gemini Notebook off. Google's official clarification establishes that separate choice, while leaving a different question about the AI features inside the Search service schools enable.

TL;DR

Google's November 3 announcement lists Search among the services that will be entirely off for school student accounts until administrators explicitly enable them.
The official clarification says Gemini, Gemini Notebook and Search can be enabled individually. A claim that schools must enable every listed AI product goes beyond that wording.
The same clarification describes AI Mode and AI Overviews providing Guided Learning inside Search. It does not promise an AI-free Search configuration.
Search Guided Learning begins with selected American school pilots later in November. Classroom Guided Learning was announced as globally available. Product availability and account permission are separate questions.

What Google announced about school Search

The official announcement comes from Chris Phillips, Google's vice president and general manager for education. Its control paragraph names Gemini, Gemini Notebook, Gemini in Classroom and Google Search. The following sentence says access to these products will be entirely off for student accounts until school administrators explicitly turn them on.

That sentence changes the practical meaning of leaving the new settings untouched. An administrator preparing an AI policy now has to account for access to the familiar search service as well. A default is an initial state with an operational consequence. The relevant question is which school workflows need an explicit decision before the change arrives.

The scope matters. The announcement concerns managed school student accounts. It describes a planned account policy, with implementation specifics still to come before rollout. The New York Times' visible introduction reports the default change early next year. I read a limited natural preview of that report; its full article was behind an access gate. Public CNN reporting and the official clarification supply the details discussed below.

A worldwide Search outage, a developer API restriction or a rule covering every personal Google account would each require further evidence. Those broader claims do not follow from the school announcement. Keeping the account boundary in the headline saves everyone from spending the next meeting correcting an argument nobody needed to make.

Schools can choose individual services

Google posted an official clarification after the initial announcement. It names Gemini, Gemini Notebook and Search, then says schools can choose to turn on one, two or all of those services individually.

That is a substantive choice. A school can choose Search while leaving the separate Gemini services off. Disabling Gemini itself therefore does not establish that Search must also be disabled. The original blog's four-product list and the clarification's three named services should remain distinct when describing the controls. Neither source gives us a verified screenshot of four independent controls in an Admin Console.

This qualification belongs near the first explanation of the policy. Hiding it until the end would give readers a misleading impression of the available decisions. It also makes the story more useful. The question shifts from whether every product is bundled into one mandatory selection to what an enabled Search service includes.

For anyone evaluating vendor permissions, the service name and the feature policy deserve separate fields in the review. Selecting a service can authorize access to a whole product surface. The product may contain several behaviors relevant to the organization's policy. Documentation needs to make that relationship legible enough for an administrator to approve the intended experience.

Why the Search AI feature question survives

CNN's public report reproduces Phillips's explanation to the New York Times that Search and AI are deeply integrated. According to that quoted explanation, schools banning AI entirely would lose student Search access, with a message indicating the service was unavailable.

CNN also asked Google how the new controls would work. Google pointed the reporter to its clarification. The report acknowledges the individual service selections, then notes that the post still implies schools cannot use Search without its AI features. These parts of the reporting describe different layers: access to Search, and the behavior of Search once access is enabled.

The clarification gives us a precise sentence to inspect. It says AI Mode and AI Overviews will offer step-by-step Guided Learning through problems so that students do not get quick answers to schoolwork. That is the company's description of the updated Search experience. The post does not offer an AI-free Search configuration alongside it.

There is still a boundary to that conclusion. We have not inspected a complete new settings matrix or tested an authorized school account under the coming policy. The reviewed sources do not establish that every query must show an AI answer, that every internal feature shares one switch, or that a different product configuration is physically impossible to implement. They establish the published choices and what Google has left unpromised so far.

That distinction is enough to ask a concrete question: which documented configuration would let this school's managed accounts use Search under the AI policy the school actually intends? A promise of choice should survive translation into an account state and an observable experience.

Google Classroom and Guided Learning have different timelines

Guided Learning is Google's approach to coaching students through a problem with prompts and steps. The official blog gives a physics problem and help writing a book report as Search examples. It describes helping students work through the concepts without going directly to the answer.

Google calls its philosophy productive struggle. That is its educational pitch, and the company links its own learning research in the announcement. This episode does not independently measure an educational effect. An administrator can consider the described behavior while still requiring separate evidence for claims about learning outcomes.

The rollout information also needs careful reading:

Item	What the official announcement says	Decision boundary
Search Guided Learning	A pilot starts in selected U.S. schools later in November, followed by educator feedback before expansion	A pilot has a limited scope
Classroom Guided Learning	Globally available from the announcement day	Availability differs from permission for every account
New account controls	More specifics will be shared before changes roll out	The implementation documentation remains forthcoming

Google describes Classroom as a central hub for organizing schoolwork and sharing assignments. Its Guided Learning activity is assigned by a teacher and anchored in class material, according to the blog. That description differs from automatically treating a Search homework query as a request for guidance. The product context can matter when a school defines its permitted uses.

A single announcement can contain a live feature, a limited pilot and a future control change. Reading the word available as a complete deployment plan collapses those timelines. I would rather separate them in the review document than discover the distinction while somebody is trying to run a lesson.

A concrete acceptance test for the planned policy

An administrator can prepare a small acceptance test once the relevant configuration and rollout documentation are available. Use an authorized managed student test account with appropriate privacy safeguards and an ordinary research task. Check whether the account can access Search under the intended policy. Then inspect the experience returned for a homework query.

Record the selected service permissions and the observed Search behavior separately. Keep the feature version and the test date with the result. If the school intends to permit ordinary source finding while restricting generative assistance, the review should identify which documented configuration satisfies that policy. An unresolved answer belongs in the approval conditions.

The acceptance test is a recommendation for administrators after the rollout documentation arrives. Our actual screen footage inspects Google's public announcement and its control wording. We did not access student data, construct a school Admin Console demonstration or stage the reported unavailable message.

The Guardian reports criticism from New York's mayor that Google is forcing AI into schools. That remains his criticism. Google's stated rationale is that schools asked for more control. The practical review can ask both sides' claims to resolve into the same evidence: what each permitted choice preserves, and which student experience it produces.

Verdict: NEEDS REVIEW

I stamped the planned controls NEEDS REVIEW. Separate service choices are a useful clarification and should be credited immediately. The Search feature question still needs a documented implementation answer before I would approve a rollout against a school's AI policy. The acceptance test should cover both access and behavior.

The most useful takeaway is to keep those two layers visible. A service can be individually selectable while still including features an organization wants to restrict. The policy document needs the configuration that matches that intent. Otherwise the entire review becomes an expensive debate about the word choice.

FAQ

Can a school enable Search and leave Gemini off? Yes, the official clarification permits choosing the named services individually. That is the documented service-level choice.

Is the new default already a global Search shutdown? The announcement describes a planned managed-school-account policy. Broader outage or account claims need separate evidence.

Does the clarification promise Search without AI Mode and AI Overviews? It describes those features providing Guided Learning. It does not promise the AI-free configuration discussed in this article.

Is Classroom's global availability the same as universal enablement? Availability describes a product rollout. A managed account's permission to use that product is a separate decision.

Sources and artwork credits

Cover portrait: Sundar Pichai, World Economic Forum via Wikimedia Commons, CC BY 3.0. Cropped, background removed and resized; no endorsement or announcement-author claim. The episode's brief process memes use Two Buttons and the Drew Scanlon reaction via Mashable/GIPHY as transformed commentary, never a person's actual reaction to this news. Their public hosting is not a blanket reuse licence claim.

Video transcript and primary sources

Qwen weight editing: how Astra reduced thinking loops

Nikoloz Turazashvili (@axrisi) — Tue, 03 Nov 2026 17:45:00 +0000

Qwen's reported math accuracy rose after GPT-6 Astra edited a small part of its weights. The repair addressed a concrete failure: repeated reasoning that exhausted the space available for an answer. For developers evaluating weight-space programming, the useful questions concern the failure being repaired, the assistance supplied to the editor and the tests used to judge the result.

TL;DR

An MIT-affiliated team reports Qwen3.5-0.8B rising from 7.9% to 48.1% on MATH-500 under its fixed protocol. About a third of edited answers still reached the length cap.
Astra worked across many turns with Python, practice problems with answers and batched model-run feedback. Gradient training was forbidden.
The researchers say the final evaluation questions stayed unseen by the editor. The benchmark names and evaluation protocol were disclosed in the prompt.
Today's critique from Matthew Honnibal concerns the impression created by combining experiments with different conditions. The primary's smaller Gemma follow-up failed to establish a gain.

Qwen weight editing repaired a failure to finish

Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab published their study on November 2. The page lists MIT CSAIL affiliations. OpenAI's GPT-6 Astra was the editor used in the experiments. This attribution matters: the research account belongs to the team, and the model provider supplies the editing model.

Their Qwen experiment used the text part of a small language model with about 0.8 billion weights. In thinking mode, the base model often repeated its work until it reached the output limit. On the reported MATH-500 evaluation, 93% of base answers hit that limit. A model can perform useful intermediate work and still receive a failed grade when a final answer never arrives.

The authors describe a repetition-associated direction written by the feed-forward components of layers 15 and 19. Astra subtracted that contribution from selected output columns. The resulting model completed more answers, and the reported accuracy increased. The researchers explain the achievement as allowing the model to finish answers it could already work out.

The repair remains incomplete. Edited Qwen hit the cap in 33.1% of MATH-500 answers. That residual matters when judging a deployment: an intervention that rescues many requests can still leave a sizable queue of requests consuming their whole budget. The title's word “patched” reflects that limitation.

The original Qwen model card already warns about thinking loops. It recommends tuning sampling for the use case and using streaming to detect and interrupt anomalous generation. A weight edit is one demonstrated intervention against a known obstacle. It should be evaluated alongside the controls available in the serving application.

What Python and practice feedback contributed

The actual initial prompt supplies a substantial research environment. Astra receives a persistent CPU Python kernel over the weights, a tokenizer and libraries for numerical analysis. The kernel has no internet or GPU. Model execution happens through a separate forward-pass tool.

Practice files contain problems, answers and, for the GSM8K and MATH training splits, reference solutions. The editor can inspect generated texts, grades, failure counts and internal activations. It can compare original and edited versions on the same problems. Those observations provide evidence for choosing a component and testing an intervention.

The forward-pass budget needs careful reading. A generation request can contain up to 512 answers in total. Paired comparisons can generate up to 256 answers per model. A teacher-forced request can inspect up to 1,024 texts within its token constraints. Fifty budget units therefore describe batches of useful feedback. They are separate from the count of Python runs, conversation turns or training steps.

The pinned logs show that the successful Qwen run was a multi-turn process. The editor inspected failures, tried interventions and compared outcomes. The narration keeps the exact elapsed time out of the story because that wall-clock total includes a provider wait. Calling the process instant would erase the work visible in those logs.

The prompt also provides a plan. It asks Astra to diagnose the largest explainable failure category, localize components causally, test several strengths and confirm gains on problems unused for selection. It explicitly names repetitive-thinking repair as an eligible target. That guidance belongs in an account of the capability: the model produced a useful repair within a purpose-built task and testing environment.

Direct weight edits, gradient training and held-out evaluation

The experiment forbids backward passes, optimizers and iterative fitting of weights to a loss. It also restricts which tensors may be changed. The editor can analyze existing weights and feedback, then compute and save a direct intervention. “No gradient training” describes those operation restrictions precisely. Practice examples and evaluation feedback remain part of the process.

The reported final edit touches 131,072 entries, approximately 0.016% of the model's weights. The pinned experiment README notes that 130,188 differ after conversion to the evaluated bfloat16 format. This rounding detail explains why touched entries and distinct final values can have slightly different counts.

The researchers declare that final evaluation questions were withheld. Practice feedback helps select the edit; final benchmarks measure the submitted model afterwards. Astra knows the benchmark names and protocol from its prompt. A practice confirmation split is another category again: it can help check a candidate during editing while remaining separate from the final benchmark.

The final Qwen comparison keeps the decoding protocol fixed. Thinking is enabled, the answer budget is 32,768 new tokens and MATH-500 averages four samples per problem. The reported decimal accuracy is an average across those generations. The table is useful within that protocol; it does not describe every possible sampling configuration or each user's workload.

Reported Qwen condition	MATH-500 accuracy	Answers hitting the cap
Original	7.9%	93.0%
Edited, 50-pass budget	48.1%	33.1%

The gain also reached instruction following in the authors' IFEval test. Finishing the output can help beyond math. This is a practical reminder to examine completion behavior alongside correctness whenever a benchmark score moves sharply.

Why the tiny game experiments have their own scope

Matthew Honnibal's November 3 critique argues that readers can combine the conditions of several experiments into an impression of one deep technique. Honnibal created spaCy and cofounded Explosion. His article credits the tool-assisted work as performing tasks a human machine-learning engineer could do, while questioning the inference encouraged by the bundled presentation.

The tiny demonstrations have different inputs. In one, Astra receives raw weights from game-playing networks and names the games without tools. In another, it writes game-network weights from zero using the rules and source code, with no practice rollouts. The Qwen repair adds Python and model-run feedback. Each is a useful observation with a distinct boundary.

The game results also depend on the chosen baseline. Astra's generated networks beat PPO trained for 100 million steps in Breakout, Seaquest and Asterix. Against PPO trained for 500 million steps, Breakout remains a win, while Seaquest and Asterix become losses. The actual table preserves both comparison columns.

I would keep those columns visible in any presentation. “Beats trained networks” needs its opponent attached. Otherwise a change of baseline can disappear between the source table and the headline, which is a surprisingly efficient form of compression.

The smaller Gemma follow-up supplies a useful boundary

The researchers' Gemma follow-up asks how the method fares on a smaller model that rarely loops. Its observed failures include wrong arithmetic and invalid algebraic steps, without one removable component behind them. Astra again receives practice feedback and makes targeted edits.

The reported MATH-500 baseline is 6.8%. The best row is 7.7% at the 25-pass budget; the 50-pass row is 7.0%. The authors report no established improvement. A chart should keep that scale honest and distinguish the best reported row from the largest-budget row.

Gemma uses its own model size, sampling settings, output cap and grading procedure. It is a scoped failed follow-up, rather than an equal-controlled ablation proving looping was the only changed variable. Its value is concrete: the approach's successful Qwen repair did not produce an established gain in this second setting.

The released edited Qwen checkpoint card also credits akhaliq with a separate re-run. The edited model scored 51.0% on the full MATH-500 protocol, while the base check used only 25 problems. That supports the released edited model's performance under the stated settings. The asymmetric base sample prevents treating it as a matched full-baseline replication.

Verdict: NEEDS REVIEW

I'd take the targeted loop repair seriously and test the saved weights. I'd keep broader claims gated on improvements beyond that failure mode. For a developer, the first acceptance question is specific: what failure does the intervention repair, and how often does that failure occur in the workload that matters?

A useful evaluation preserves the original model, the candidate weights and the serving settings. It checks final-answer correctness alongside completion failures, and it retains examples that regress after the edit. The researchers' published protocol and counterexample make those questions easier to ask. The reported multiplier can start an investigation; the deployment decision still needs the application's own evidence.

FAQ

Did Astra use only raw Qwen weights?

The Qwen test allowed Python analysis, practice answers and batched model-run feedback. Its final benchmark questions were declared withheld. Tiny raw-number tasks used separate conditions.

Did the edit remove all loops?

About a third of edited MATH-500 answers still hit the length cap in the primary protocol. The repair reduced the failure and improved the reported score.

Does the Gemma result rule out weight editing?

It establishes a failed improvement attempt in that smaller model's setup. Broader conclusions need further experiments with clear inputs, protocols and counterexamples.

Sources

Cover portrait: Steve Jennings/Getty Images for TechCrunch, Sam Altman TechCrunch SF 2019 crop, CC BY 2.0. Cropped, background removed, resized and flipped; provider identification only, no reaction or endorsement. Research logs/data/networks: Rikiya Takehi and coauthors, CC BY 4.0. Primary footage is a brief credited excerpt for reporting/commentary.

Video transcript and primary sources

AI coding and open-source CRM: the Salesforce replacement test

Nikoloz Turazashvili (@axrisi) — Mon, 02 Nov 2026 17:00:00 +0000

AI coding is making it easier to attempt a familiar developer ambition: replace a subscription service with software you can operate yourself. OccupySaaS is pursuing that ambition with compatible alternatives to Salesforce and Auth0. Its public repositories give us a useful way to inspect the promise, because the working code and the unfinished operating work are documented together.

TL;DR

SalesCompel has an early persistent Go/PostgreSQL customer-record slice. Its separate Vue exploration prototype uses synthetic data and keeps edits in memory.
ZeroAuthy records checks with named Auth0 clients, and the OpenID Foundation lists a particular commit for three provider profiles. That is a bounded conformance self-certification scope.
The SalesCompel roadmap records unfinished milestones and no production certification. Compatibility has to be evaluated against the customer's actual features and workflows.
Hosting the replacement assigns the company an operating job. The early backend guide makes access removal a concrete example: an authorized database operator deletes a provisioned token's stored digest row.

Why rebuild a Salesforce alternative?

Salesforce advertises Pro Suite at $100 per user per month in US dollars, billed annually. Its page also offers lower-priced plans and a free suite, so that figure is one specific paid-plan example. It demonstrates why the number of people using a system can matter to its recurring bill. It gives us no basis for calculating savings from an early replacement with different functionality.

OccupySaaS calls per-seat pricing a tax on growth. Its proposed response is to publish compatible software that companies can run themselves. A company can then choose where to host it, who operates it and which changes it accepts, within the project's license and the limits of its own capabilities.

The site's protest language includes a claim about laid-off engineers. I haven't verified those employment histories. Its timeline dates ZeroAuthy's public project to October 14 and SalesCompel's to October 15. The November 2 peg is the fresh Hacker News discussion. There is no newly established launch announcement here.

For a prospective user, the useful part of the story is the relationship between that motive and the implementation. Existing customer data and company-specific workflows make leaving expensive even when an alternative is available to download. Compatibility aims to reduce part of that migration cost.

How compatible software can preserve an application

An application often talks to a service through a software client. That client sends requests to a server and expects particular responses and behavior. A compatible replacement can accept the same kind of requests at a different destination. Preserving that interface can save changes throughout the application that uses it.

The meaningful unit of evidence is the behavior your workflow needs. Can the client create and retrieve the expected record? Does an update preserve the fields the application depends on? Do the expected permission boundaries remain in place? These are proposed acceptance questions for a migration rehearsal. A screenshot of a familiar-looking interface cannot answer them by itself.

ZeroAuthy's compatibility matrix is useful because it names client libraries and versions. It also distinguishes behaviors checked through clients from behaviors covered by server-only tests. That makes it possible to ask a narrower question than whether a replacement is compatible with an entire vendor platform.

The distinction helps an evaluator decide where to investigate next. A recorded check can establish a starting point for that client and behavior. The customer's actual configuration, data and security expectations still require their own evidence. We did not run a migration or the project's test suite for this episode.

Open-source CRM scope: a backend and a separate prototype

SalesCompel's README describes an early tenant-isolated Go/PostgreSQL candidate. The implementation guide lists persistent Account and Contact operations, limited queries and provisioned bearer authentication. It also describes a localized record editor and the candidate's exclusions.

A separate Vue exploration prototype lets people inspect proposed Account and Contact screens using synthetic records. Its edits remain in memory and do not call the backend. Both surfaces can be useful at this stage. They answer different questions: the candidate provides a bounded persistent service, while the exploration prototype helps people examine a proposed interface.

For evaluation, I would write down which surface a demonstration is using before interpreting its behavior. A change visible in a local prototype has a different meaning from a write verified against persistent storage. The README gives readers enough information to keep those observations separate.

The remaining roadmap is equally important. No full program milestone has a recorded exit-gate pass. Production certification has not been reached. The scope estimate runs to hundreds of additional bounded work packages, with explicit caution that the estimate is not a delivery forecast.

That public accounting is helpful. A team can use it to identify gaps affecting its own migration rather than filling them in with assumptions about what a compatible name implies.

What ZeroAuthy's OpenID listing covers

The OpenID Foundation's table lists zeroauthy commit 38b4229 for Basic OP, Config OP and Form Post OP. I checked the Foundation's row rather than relying solely on the badge in the project's README.

The Foundation defines self-certification as an entity's formal declaration that an identified deployment conforms, through testing, to a particular protocol profile. That is useful evidence with a defined scope. Security review, operating reliability and compatibility with an entire commercial platform require their own evidence.

ZeroAuthy's roadmap places multi-factor sign-in and an operational hardening sweep in later work. An evaluator should read those limits alongside the recorded achievements. For a system entrusted with customer logins, an unsupported requirement can be enough to stop the production decision even if the supported slice is useful elsewhere.

The table's displayed certification dates and the repository's stated approval date differ. This article relies on the observed commit/profile listing and makes no claim about an exact approval day.

Who removes access after an employee leaves?

This is the detail that makes the ownership question concrete. SalesCompel's early backend guide says:

To revoke a provisioned token, delete its digest row through an authorized DB operator. Token lifecycle, public login and OAuth refresh are future work.

A token is the access credential in this procedure. Its digest is the fingerprint stored in the database. Removing that row is an authorized operator's documented job for this early candidate. The source does not promise a completed general offboarding product around the step.

For a company considering self-hosting, I would put that procedure into the rehearsal. Identify the operator, establish how the action is authorized and verify that the intended access has stopped. Those are recommendations for a future test. This episode reports the documented procedure.

The same reasoning applies to the other responsibilities discussed in the episode. Backups need an owner. Recovery needs evidence. A permission boundary should be evaluated with the actual workflows that use it. The software license and the people operating the service belong in the same budget conversation. Somebody still gets the dinner-time page.

Maintenance remains after AI coding

An older report supplies a useful parallel. On October 21, PostgreSQL committer Robert Haas described AI-assisted bug discovery outpacing human review, and linked the pressure to late feature reversals and the version nineteen delay. Models can draft fixes while people still check correctness and project standards. This dated explanation is maintenance context; it supplies no measurement of OccupySaaS's defect rate or review capacity.

The stated clean-room policy also acknowledges contractual risk around competitive API observation. Its provenance rules exclude confidential employer material. Apache licensing gives permission to use the code within its terms, while a company's legal review remains separate. A policy file cannot settle every possible dispute for a future operator.

Verdict: NEEDS REVIEW

I'd test the supported slices because a compatible open server can create an exit option. I'd keep production gated on the customer's migration evidence and a named owner for the service. The strongest next step is a rehearsal using the workflows the company actually needs, with the early implementation's documented limits left visible.

FAQ

Is SalesCompel a finished Salesforce replacement? Its README describes an early candidate and a separate exploration prototype. No full program milestone has a recorded exit-gate pass, and production certification has not been reached.

Does ZeroAuthy's OpenID listing establish full Auth0 compatibility? The Foundation lists a particular commit for three protocol profiles. Broader product compatibility and operating requirements need separate evidence.

Does self-hosting eliminate costs? The company still needs infrastructure and operators. The episode makes no measured savings claim and recommends evaluating maintenance and migration alongside licensing.

Sources

OccupySaaS site and timeline
SalesCompel README
SalesCompel implementation guide and remaining roadmap
ZeroAuthy README, compatibility matrix and clean-room policy
OpenID Foundation listing and self-certification definition
Salesforce advertised pricing
Robert Haas's October 21 report
November 2 Hacker News discussion
Cover portrait: Christie Hemm Klok / Salesforce via Wikimedia Commons, CC BY-SA 2.0. Cropped/background removed; cover adaptations use the same license.

Video transcript and primary sources

ParticleDB's Jepsen report, Lenovo's fingerprint USB stick, Karpathy's HackerTube and the Linux TCP bug CVE-2026-98432

Nikoloz Turazashvili (@axrisi) — Sun, 01 Nov 2026 18:30:00 +0000

Four developer stories from Sunday, November 1, 2026, each read from its own source. The first is a database whose home page said Full ACID. The video has the walkthrough; this article keeps the quotes, numbers and links in one place.

TL;DR

Jepsen's analysis of ParticleDB found 96 issues in versions 1.1.4 through 1.1.18.11.rc-22. In the last version it tested, the default transaction mode still lost committed writes. Jepsen recommends users halt further deployment and migrate. Orkes funded the test.
Researcher Xusheng Li found that the Lenovo ThinkPlus FU100 fingerprint USB stick, sold as AES-256 hardware encrypted, held an ordinary SD card with nothing on it encrypted.
Andrej Karpathy built HackerTube, a site of 6,454 videos recommended in Hacker News comments, in about two hours.
Linux kernel CVE-2026-98432 is an IPv4 TCP use-after-free scored CVSS 9.8. Install your distribution's fixed kernel and reboot.

ParticleDB: what Jepsen found

Jepsen, the database testing lab run by Kyle Kingsbury, published its analysis of ParticleDB 1.1.4 on October 31, 2026. ParticleDB is a Rust database from Orkes, built for AI workloads, with a Postgres-compatible interface, key-value, vector search and user-defined functions. Orkes built it to support its Conductor workflow platform. Only single-node behavior was tested, because the builds Jepsen received had no replication.

The report opens with its summary: "We tested versions 1.1.4 through 1.1.18.11.rc-22 and found that ParticleDB's claims of 'Full ACID' were somewhat premature. We present 96 issues in ParticleDB." It also states that "This research was funded by Orkes, Inc., and conducted in accordance with the Jepsen ethics policy."

The home page claimed "Full ACID. 159K TPS." and said the database was "formally proven" with a TLA+ proof. Jepsen reports that no TLA+ specification was available during the collaboration, and that the text directly under "Full ACID" said snapshot isolation, which is not fully isolated. Isolation was also controlled by a startup flag, --txn-mode, because the database ignored or rejected the usual SET TRANSACTION ISOLATION LEVEL statements.

Most of the issues "required just a single server, single client, and no faults." Examples from the report:

WHERE 4 = 5 returned rows with primary key 5 (issue 18).
WHERE TRUE matched nothing (issue 35).
An UPDATE could leave multiple rows with the same primary key (issue 29).
Rows from dropped tables could re-emerge in mangled forms (issue 46).
Aborted transactions could commit, or fail with their effects still visible (issue 43).

By 1.1.18.11.rc-22, all but ten of the 96 issues appeared resolved. Two serious ones remained. In the default occ transaction mode, ParticleDB "regularly lost data in normal operation", and the strictest serializable mode still allowed Lost Update and internal anomalies when Jepsen killed the process. Orkes has released 1.1.19-rc.13 and says it resolves all remaining issues. Jepsen has not evaluated it.

Orkes believes the problems came from a major refactor in spring 2026 and that its own customers, who stayed on an earlier version, were likely unaffected. Jepsen briefly looked at an internal 1.0.0 build and says it did not seem susceptible to most of the serious safety errors. From May through July 2026, the download page offered versions 1.1.4 through 1.1.18.11.rc-18, and all of them had serious safety errors in normal operation.

Jepsen's conclusion: "Jepsen recommends users halt further deployment of ParticleDB and migrate to other databases as soon as possible." It also advises checking or rebuilding database state from more reliable sources if available.

The documentation findings are in the report too. The Java client docs referred to dependency coordinates that do not exist, and the stored procedure documentation "even fabricated an imaginary email address for the author of this report." After the testing, Orkes labelled the transaction modes experimental and described versions 1.1.4 through 1.1.18.11.rc-22 as "unsupported pre-release builds." Jepsen points out that the Docker install page told users how to deploy those versions "for production."

What to do: if you evaluate a new database, run your own tests of the isolation level it claims, and treat a missing specification behind a "formally proven" banner as a missing specification.

Lenovo's fingerprint USB stick

Security researcher Xusheng Li found that the Lenovo ThinkPlus FU100, sold as an AES-256 encrypted device, was "just a plain SD card internally," according to Tom's Hardware, which reported on research first published by HackingPassion. The fingerprint reader only enabled the USB connection, and nothing on the card was actually encrypted. Li used the phrase "just an SD card in a fancy case" in a March 2026 conference talk.

The timeline from the HackingPassion write-up: Li reported the flaw to Lenovo on August 2, 2025. On August 27 a temporary fix was ready, a layer of epoxy over the SD card. Lenovo rated its advisory high. A later fix for the FU100, FU200, TU800 and the TSD303 SSD requires owners to call a service line in China and then either send the device back for replacement or get an on-site firmware upgrade. Lenovo advises backing up data and strongly recommends wiping the drive before sending it in.

Li also looked at the TSD303 external SSD, whose data was encrypted but whose drive sent the correct password back over USB in plain text for the software to compare. The first fix derived a key from a timestamp-like value. The later fix has the drive check the typed password itself.

Last week, Tom's Hardware reports, Li pointed OpenAI's Codex, together with his employer's reverse engineering tool, at other makers' USB protection software. Netac's tool took about seven minutes to break, because it had a fixed key built in and wrote the user's password to diagnostic logs. KakaSoft's took about 26 minutes and Nexcopy's about 10. SecZure's YutianDun has two hidden accounts with simple passwords that Li describes as backdoors.

What to do: encrypt files with software you control, such as full-disk or container encryption you can inspect, before they reach any USB stick. Treat a fingerprint reader as a convenience.

HackerTube

On Friday night, Andrej Karpathy wrote, he opened YouTube and "realized that I was looking at an enshittified wall of slop." On Saturday morning he gave his coding agent the task of writing a YouTube clone from whatever videos have been recommended on Hacker News.

According to his post, the agent downloaded all Hacker News comments, filtered them, and ran Sonnet over them in a Claude Code Workflow to remove spam. That left about 40,000 comments recommending a YouTube video: 6,454 videos recommended by a few people on Hacker News from 2007 to 2026, across 150 topics. The site, hackertube.org, has recommendations without user accounts, keyboard shortcuts and a data export, and shows the frame at the 50 percent mark instead of the uploaded thumbnail. Karpathy writes that the build "takes ~2 hours now." His manual steps were a Google Cloud API key for video metadata, a VPS and a domain name.

The post passed 1,800 points on Hacker News within a day, and a spin-off, HackerBooks, appeared for books recommended on Hacker News. On October 12 we covered Karpathy's argument that access and tasks create a gap in how people understand these tools; a working site built in two hours is one more data point.

Linux CVE-2026-98432: patch and reboot

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake. The kernel CNA scores it CVSS 3.1 9.8. The fix, by Eric Dumazet, is titled "ipv4: free inet_opt and ireq_opt after an RCU grace period" and changes plain kfree() calls to kfree_rcu(); the commit is dated October 1, 2026. The Ubuntu CVE page quotes the description: a race between a retransmitted SYN and the freeing of a child socket's IP options.

Stable kernels with the fix shipped on October 11 and 15, and the CVE was published on October 15. Per the Atlas write-up, the bug goes back to Linux 4.4. Red Hat raised its rating from Important to Critical on October 30 in bulletin RHSB-2026-016, which says "Red Hat is expediting the release of fixes." On Saturday evening, October 31, Ubuntu's tracker listed every release as vulnerable and RHEL 8, 9 and 10 had no fixed kernel, while Debian, SUSE, Oracle UEK and Amazon Linux had fixes and AlmaLinux had fixed kernels in testing.

Anthropic's October 27 post says its model "wrote an exploit that allows a remote attacker to send packets to Linux servers with a multipath TCP listener to run arbitrary commands as root, without any credentials or user interaction." In its proof of concept, "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution." Anthropic has not published the exploit. The Go Security Team notes that as of Go 1.24, Go programs enable multipath TCP for listen sockets on Linux by default, and warns that "the underlying bug is not specific to MPTCP", so systems without such a listener may still be vulnerable to similar attacks.

What to do:

Install your distribution's fixed kernel and reboot. Do this on container hosts and Kubernetes nodes as well, because containers use the host kernel.
If your distribution has no fixed kernel yet, Red Hat and AlmaLinux publish a firewall rule that drops incoming IPv4 TCP packets carrying IP options. Red Hat says it reduces exposure and is not a substitute for patching.
Patch hosts that run multipath TCP listeners first.

Verdict

REVERT: halt ParticleDB deployments per Jepsen's advice, and patch that kernel.

Sources

Jepsen: ParticleDB 1.1.4: https://jepsen.io/analyses/particledb-1.1.4
Tom's Hardware on the Lenovo FU100: https://www.tomshardware.com/tech-industry/cyber-security/lenovo-fingerprint-usb-stick-sold-as-aes-256-encrypted-had-a-plain-sd-card-inside-ai-assisted-follow-up-finds-a-backdoor-and-hardcoded-keys-in-other-secure-usb-products
HackingPassion: https://hackingpassion.com/lenovo-thinkplus-encrypted-usb-sd-card/
Karpathy, HackerTube: https://karpathy.bearblog.dev/hacker-tube/
Ubuntu CVE-2026-98432: https://ubuntu.com/security/CVE-2026-98432
Red Hat RHSB-2026-016: https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
Fix commit: https://github.com/torvalds/linux/commit/e3f33b0a1d89d738e2b913dab519226eaf76e15b
Anthropic: https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
Go Security Team via oss-security: https://www.openwall.com/lists/oss-security/2026/10/30/1
Atlas roll-up: https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf

Video transcript and primary sources

France's gigabyte tax, the ChatGPT shared-link account bug, Scribd's breach and Tangled's federated forge

Nikoloz Turazashvili (@axrisi) — Sat, 31 Oct 2026 15:15:00 +0000

Four developer stories from Saturday, October 31, 2026, each read from its own primary source. The first is a French tax on gigabytes that passed the National Assembly by one vote. The video has the walkthrough; this article keeps the quotes, numbers and links in one place. English renderings of the French text are ours.

TL;DR

France's National Assembly adopted amendment I-1358 to the 2027 budget bill on October 30: 0.055 euros per gigabyte, owed by the company that sends the data to French internet subscribers. The vote was 11 to 10, in the first reading. It is not law.
The security firm Parameter says it took over ChatGPT accounts through a public shared-conversation link. OpenAI rated the report P1 and confirmed the fix on October 26. The account of the flaw is Parameter's.
Scribd, the company behind Slideshare, Everand and Fable, has a security incident notice on its help center and is emailing affected users in phases. It has not said how many accounts were affected.
Tangled released a federated code forge on the AT Protocol. Issues and pull requests now live on the server you host, as Git objects. It is Tangled's own announcement.

France: a tax on gigabytes, adopted by one vote

On Friday, October 30, 2026, the National Assembly adopted amendment I-1358 to the finance bill for 2027 (bill no. 3210). It was filed on October 9 by the Socialist group and defended in the chamber by Laurent Lhardit. The committee had rejected the same text on October 9.

The amendment adds a chapter to the French tax code titled "Taxe sur les producteurs de données numériques". Article 302 bis ZP reads: "Il est institué une taxe assise sur les flux de données numériques émises par les fournisseurs de contenu et acquittée par ces derniers." In our translation: a tax is created on the digital data flows sent by content providers, and paid by them.

Three mechanics matter for anyone who serves traffic to France:

Who counts the data. Internet service providers must set up a consolidated, anonymized collection of the quantities of data flowing to their customers, identifying the sender. The collection includes the sender's identity and its registration number with the Internet Assigned Numbers Authority, and the quantity sent. The text says no record of the content of the data or of its destination can be required, and the figures go to the tax administration every quarter.
Who pays. Article 302 bis ZR says the sender owes a tax equal to the volume of data, in gigabytes, multiplied by 0.055 euros. Subscribers are not the taxpayers, and neither are the providers: they only report the counts. A hundred gigabytes comes to 5.50 euros.
Content delivery networks. When a sender uses a CDN, the quantity of data counts as the sum of the flows leaving the CDN.

The tax is capped at a maximum of 15 percent of the sender's revenue in France or 2 percent of its total revenue. Groups with a French entity pay as they would corporate tax; groups without one pay in euros by March 30 of the following year, on a notice issued by January 30.

What the sponsors expect

The amendment's explanatory note expects a yield of 10 billion euros and cites an estimate from the regulator ARCEP of 200 billion gigabytes a year sent to subscribers of French internet providers. It names Google, Meta, Amazon, Netflix and Akamai as half of the measured traffic. Our arithmetic: 200 billion gigabytes at 0.055 euros is 11 billion euros, one billion above the figure in the note. The note does not explain the difference.

The debate

Philippe Juvin, the Assembly's budget rapporteur, gave an unfavorable opinion: the risk, he said, is that the large platforms pass the cost on to advertisers. The minister, David Amiel, also opposed it. He said the scheme would need flow sensors or measurement at the receiving terminals, and that half of the tax, 5 billion euros on the sponsors' own figure, would fall on smaller content providers, notably French ones. Lhardit answered that free services such as Facebook, Instagram or TikTok have no user to pass a tax on to, and said by his evaluation the cost for the TF1 group would be between 200,000 and 300,000 euros.

The public vote was requested by the Socialist group. Thirty five members voted, 21 votes were counted, 11 for and 10 against.

Is it law?

No. The Assembly adopted one amendment in the first reading of the budget bill. French press coverage, including Europe 1, notes that it can still be changed or removed during the rest of the debate and in the exchanges with the Senate. The amendment text we read sets no start date. I covered a different French measure on October 23, when Quad9 said it would stop serving users in France after a court ruling; this one targets traffic itself.

What to do: nothing today. If you send large volumes to French users, watch the Senate stage and ask your CDN whether it reports egress per country.

ChatGPT: a shared link that ran code as chatgpt.com

Parameter Labs published "Do the Math: How We Took Over ChatGPT Accounts" on October 28, with status Fixed and severity P1. Its summary: an attacker could create a malicious conversation, publish it with ChatGPT's normal sharing feature and send the link to another user. When the victim opened it, code ran as chatgpt.com in the victim's signed-in session.

As Parameter describes the chain, it combined ordinary features. ChatGPT's HTML Preview runs code in a restricted frame on a different web address, and that isolation worked: the Preview could not read the main page. A graph in the same conversation loaded a math library, which installed a listener in the main page for messages related to its on-screen keyboard. The listener accepted a message without proving which frame sent it, and the message format allowed HTML. The HTML created a new frame in the main page that inherited the chatgpt.com identity. Parameter says a script policy workaround was the last step and that the root cause was the message listener.

Parameter says its proof of concept listed a victim's recent conversations, read a private one that had never been shared and sent a small piece of it to a server the researchers controlled. In the automatic version, opening the link was the victim's only click.

The timeline in the post: Parameter submitted the report to OpenAI's bug bounty on October 18. On October 21 OpenAI reproduced it and raised the severity from P2 to P1. One web frontend was fixed on October 22 while a second was still being updated, content security policy changes blocked part of the chain on October 23, and on October 26 OpenAI confirmed both frontends rejected the reported messages, marked the issue resolved and awarded a total bounty of 5,000 dollars. We found no statement from OpenAI itself, so the account of the flaw and of OpenAI's actions is Parameter's.

The defensive lessons Parameter lists are plain: verify both the sender's origin and the exact window before acting on a message, keep raw HTML out of cross-window settings, keep dynamically created documents sandboxed when an untrusted frame can influence them, and treat content security policy as a backup. ChatGPT is a web app, so there is nothing to update on your side. It is a good day to grep your own message handlers for event.origin and event.source checks.

Scribd: what the notice says

Scribd's help center notice, last updated October 1, says an unauthorized third party gained access to its systems, used that access to reach other internal systems and accessed certain user information: basic account information for most accounts, more sensitive information for a smaller number. It says it closed the vulnerability, engaged outside forensic experts, notified law enforcement and the relevant data protection authorities, and began notifying affected users through its provider Epiq. It recommends resetting passwords for Scribd, Slideshare, Everand and Fable accounts.

A user posted an email notice on Hacker News on Monday, October 26, that lists what may have been accessed: the email address, the last four digits of the credit card, the country, the card issuer, the card expiry date and payment history, which the notice says excludes credit card details. It says there is no evidence the data has been misused. The Romanian outlet Business24 reports that notices sent to users there also list the titles they read or searched.

Scribd's notice gives no dates for the intrusion and no number of affected accounts, and says notices go out in phases, so not receiving one does not mean an account was spared. What to do: reset the password on all four sites, change it anywhere you reused it, and verify any call or email that knows your card's last four digits through your bank's own number, because a scammer may know them too.

Tangled: a federated code forge

Tangled, a code forge built on the AT Protocol, announced a major release on October 30 and calls itself "the first truly federated code forge". You can host the Git side on your own server, which Tangled calls a knot, and still collaborate with people on other knots.

The change that matters is where the discussion lives. Issues, pull requests, comments, reactions and labels are now stored on the knot, next to the code, as collaborative objects: a chain of Git objects in the repository itself. To keep a knot from putting words in your mouth, every time you create or edit a record the web app also writes an attestation record to your own personal data server, pointing at that exact version. Tangled calls it two-way verification.

The post also describes how the service itself changed. The web UI and backend used to be one Go monolith on a single SQLite database on one medium-sized server in Sweden. The new frontend is written in Svelte and deployed at the edge, populated by a read-only, in-memory indexer written in Rust that runs in more than 11 regions. The knot server was rewritten in Rust as well. The release adds organization accounts and stacked pull requests with interdiffs.

Self-hosters must upgrade their knots to v1.20.0 following the upgrade guide. Tangled says private repositories, a CLI, SDKs and agent skills are coming over the next few weeks. This is the project's own announcement and we found no independent review yet.

Verdict

NEEDS REVIEW. The French tax passed by one vote and is not law yet, the ChatGPT fix is described only by the researchers, Scribd has not said how many accounts were hit, and Tangled's federation claim is its own.

Sources

Assemblée nationale, amendment I-1358: https://www.assemblee-nationale.fr/dyn/17/amendements/3210A/AN/1358
Assemblée nationale, session record of October 30, 2026: https://www.assemblee-nationale.fr/dyn/17/comptes-rendus/seance/session-ordinaire-de-2026-2027/premiere-seance-du-vendredi-30-octobre-2026
Assemblée nationale, committee amendment I-CF365: https://www.assemblee-nationale.fr/dyn/17/amendements/3210A/CION_FIN/CF365.pdf
Europe 1: https://www.europe1.fr/politique/budget-2027-les-deputes-votent-une-taxe-au-gigaoctet-1197300
Parameter Labs: https://www.parameter.ai/labs/we-found-a-gap-at-openai
Scribd Help Center: https://support.scribd.com/hc/en-us/articles/53787421531284-Information-about-the-recent-security-incident
Hacker News, posted Scribd notice: https://news.ycombinator.com/item?id=50312756
Business24: https://business24.ro/incident-de-securitate/scribd-notificare-utilizator-romania-incident-securitate-conturi-1673136
Tangled: https://tangled.org/blog/forge/

Video transcript and primary sources

Binance hack, Claude Code extension backdoor, Northflank and Mistral Large 4: what each source says

Nikoloz Turazashvili (@axrisi) — Fri, 30 Oct 2026 18:15:00 +0000

Four developer stories from Friday, October 30, 2026, each read from its own primary source. The biggest is the theft from Binance, where three sources give three different totals. The video has the walkthrough; this article keeps the quotes, numbers and links in one place.

TL;DR

Binance wallets on ten blockchains sent funds to one attacker on October 29. TRM Labs counts about $6.36 billion, Elliptic $6.43 billion and Binance estimated around $6.3 billion. Both tracing firms call it the largest crypto theft on record. No government has confirmed who did it.
Cursor says a maliciously modified build of Anthropic's Claude Code extension, version 2.1.313, was available in its extension marketplace for about eleven hours on October 29, with at most 5,000 users affected. Cursor's notice does not say how the build got in.
Northflank's status page tells all users to assume their environment variables were decrypted and to disable or rotate all keys. It says multiple users confirm their AI keys have been used. No post-mortem yet.
Mistral released the weights of Mistral Large 4. Its license is a modified MIT; offering the model to third parties as a hosted service needs a separate commercial license.

Binance: three totals for one theft

TRM Labs published its analysis on October 29. It says an attacker moved approximately $6.36 billion out of Binance wallets on ten blockchains, most of it in about 20 minutes starting at 20:05 UTC, and that the preparation began at least 36 hours earlier. Elliptic's page, updated on October 30, counts $6.43 billion across 11 blockchains and notes that Binance has estimated the impact at around $6.3 billion. Elliptic values each transfer at the time of theft; TRM also gives a figure at current prices, about $6.23 billion. The totals differ because each firm prices and attributes the assets its own way; all of them agree the theft happened. Both call it the largest crypto theft on record, about four times the roughly $1.5 billion Bybit hack of February 2025.

The mechanism on Ethereum, as Elliptic describes it, uses EIP-7702, a feature of the 2025 Pectra upgrade that lets an ordinary wallet delegate its behavior to a smart contract. The attacker submitted one transaction carrying 50 authorizations, each validly signed with the key of a Binance hot wallet and each covering a different nonce, so that one would match the wallet's transaction count when it landed. That handed control of the wallet to the attacker's sweeper contract, which emptied it about three and a half minutes later. TRM adds that the operator rehearsed the final version of its code on another wallet about four hours before installing it on a Binance hot wallet.

On the other chains, funds left Binance wallets in ordinary signed transfers. TRM reads the pattern as a compromise of Binance's hot wallet signing infrastructure. Elliptic says the attacker appears to have been able to get Binance's own systems to sign transactions, without stealing its private keys.

Binance's account has changed. Its first statement said the incident may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions. A later update says the investigation has uncovered additional points of breach, and Binance has not said what they are. Elliptic compares this with the Bybit theft, where a developer's machine at the wallet provider Safe{Wallet} was the way in.

What Binance and the tracing firms say about the aftermath: Binance says user funds are safe, deposits are unaffected, it will cover all losses, and withdrawals should resume within a day or two. Elliptic has verified $2.84 billion frozen, 44 percent of the theft, almost all of it USDT and USDC; TRM counts about $2.7 billion. The attacker is swapping the rest into assets that cannot be frozen. TRM attributes the theft to North Korea's TraderTraitor group with high confidence, Elliptic says North Korea-linked actors are likely responsible, and Elliptic notes that no government has yet confirmed attribution.

For developers the practical lesson is in the machines around the keys. If you run a signing service, list which laptops, containers and services can ask it for a transaction, and what approves them.

Claude Code 2.1.313 in Cursor's marketplace

Cursor's security notice, dated October 29, says that between about 2:27 am and 1:35 pm Pacific a maliciously modified version of Anthropic's Claude Code extension was available in the Cursor extension marketplace. The package is Anthropic.claude-code version 2.1.313. Cursor says it was not developed by Anthropic and that at most 5,000 users were affected.

According to Cursor, the extension collects the hostname, username, operating system, home directory path, environment variable names, working directories, configured Git email and public IP address. It then tries to add an attacker-controlled SSH key to authorized_keys, enable the local SSH service and open a reverse SSH tunnel, with persistence through a LaunchAgent on macOS or a scheduled task on Windows, and a retry roughly every 60 seconds. It reports back with an HTTP POST. Cursor says the attacker's server is offline; it worked with the hosting provider to take it down.

Security firm Phorion's write-up adds that the injected code is prepended to the extension's extension.js, so it runs when Node loads the file, before the extension's normal activate function, with no click. Phorion also found a bug on macOS: the script checks whether Remote Login is off with a command that, without admin rights, prints an error and still exits successfully. The script only tries to turn SSH on when the output matches "Off", so it skips that step. Cursor's notice states the consequence: on most macOS and Windows hosts turning on SSH requires admin rights and fails, so the attacker could not have logged in through the tunnel. The extension still adds the key, installs persistence and sends host details. Follow the remediation steps regardless.

Cursor's check for macOS is a one-line grep of ~/.ssh/authorized_keys for the comment svc-telemetry. Cursor also warns that uninstalling the extension may not be sufficient because the payload drops standalone persistence scripts, and it provides removal scripts for macOS and Windows. It recommends rotating credentials reachable from affected hosts, from a trusted system. Cursor removed the version, shut down and rebuilt its marketplace, rotated its keys and found no other tampered extensions. It has no evidence that other versions or the official distribution are affected, and its notice does not say how the modified build reached the marketplace.

Northflank's incident timeline

Northflank's status page for the security incident gives a timeline in UTC on October 30: a Wiz threat alert at 11:43, engineers reviewing it at 11:44, an initial network policy patch at 12:02, more patching at 12:50 and 13:05, and a request for Wiz incident response support at 13:00. At 13:40 the page told customers to rotate environment variables immediately. At 13:58 it said to assume all environment variables have been decrypted and to disable or rotate all keys. It later added that multiple users are confirming their AI keys have been used.

At 15:12 the page said secret rotation on Postgres and MongoDB had been enabled for all users, recommended disabling public expose on add-ons if it was enabled, and again told all users to assume their environment variables are decrypted. It lists secrets on workloads, secret groups and global secrets. The networking, certificates, services, add-ons, jobs, builds and logs components were listed in major outage while the app and API were operational. No post-mortem or cause had been published when this article was prepared, so how the attacker got in is not public.

What to do, following the page: rotate every secret, starting with keys that bill per use such as AI provider keys, then look at each provider's usage page for calls you did not make.

Mistral Large 4: weights and the license clause

On October 6 the Daily Diff covered the preview of Mistral Large 4, with the weights promised for the end of October. Mistral released them on October 29. The model card describes a natively multimodal mixture-of-experts model with about one trillion total parameters and about 49 billion active per token (52 billion including embeddings), 128 routed experts with four active per token, a 1 million token context window, trained on 3,800 NVIDIA Grace Blackwell GPUs in Mistral's own European data centers. A quantized NVFP4 checkpoint targets Blackwell GPUs.

The benchmark numbers come from Mistral's own post. It says Large 4 leads Cognition's private FrontierCode 2.0 at 19.7 percent, scores 41 percent on Terminal-Bench 4.0 (up 13 points from the preview, with 30 percent fewer output tokens), and is effectively tied with GLM-5.3 on the Artificial Analysis Coding Agent Index at 48 percent while using 47 percent fewer tokens per task. In Surge Code's blind pairwise preference test, Mistral says only Claude Opus 5.5 ranked ahead among the models evaluated. These are claims from Mistral's own chart; none is an independent result.

The Mistral Ecosystem Open-Weight License is described in the file as a modified version of the MIT license, with permission granted free of charge for the model, weights and documentation. Clause two says that if the licensee or any of its affiliates operates a Model as a Service business, they must enter into a separate commercial license with Mistral before using the model or derivatives for any commercial purpose. The license defines Model as a Service as giving a third party access to the model or its derivatives for inference or post-training by any means, for instance via API or hosted endpoints, in a way that lets that party exercise meaningful control over inputs, parameters or training data. Clause three exempts internal use that does not make the model available to third parties, and use through Mistral's own products.

Verdict: NEEDS REVIEW

Binance has not named its breach points, Cursor has not said how the build got in, Northflank has no post-mortem yet and the Mistral chart is Mistral's own. Read the primary sources below and act on the concrete checks each one lists.

Sources

Video transcript and primary sources

Gemini 4 Carbon and an anti-LLM script: what each one actually says

Nikoloz Turazashvili (@axrisi) — Thu, 29 Oct 2026 18:00:00 +0000

Four developer stories from Thursday, October 29, 2026, each read from its own primary source. The lead is a browser fingerprinting script that hides a fake system prompt in invisible characters, apparently written to make AI models refuse to read it. The video has the full walkthrough; this article keeps the quotes, numbers and links in one place.

TL;DR

A researcher who goes by veritas crawled 10,000 popular sites and found a fingerprinting script containing a string of invisible Unicode characters. Subtracting 917504 from each code point decodes it to a fake system prompt that begins SYSTEM OVERRIDE. The author reads it as anti-LLM obfuscation. Authorship is unconfirmed.
Google announced Gemini 4 Carbon on October 28. It ranks first on the Artificial Analysis Intelligence Index v5.0 at 59, with Claude Opus 5.5 at 58. Access starts with a subset of cyber defenders, with no date for developers.
AlpineBSD is a new operating system on the NetBSD kernel whose package repositories are sorted by whether they contain AI-generated code. It has no installer yet.
Anthropic published its own account of drug development work with six partners. It says the work is mostly preclinical. The figures are Anthropic's and its partners'.

The script with a message for AI readers

The nullpt.rs post, dated October 28, 2026, starts as a hobby. The author wanted to know what fingerprinting scripts exist beyond the well-known libraries, so veritas crawled the Tranco top 10,000 sites with Playwright, hooked canvas toDataURL calls and bot-signal properties, and published a collage of 1,033 captured canvas drawings at fingerprint.garden. Canvas fingerprinting draws text or shapes on a hidden canvas and reads the pixels back, because browsers, operating systems, graphics drivers and hardware render the same drawing slightly differently.

One drawing resembled the cover art of Tame Impala's album Currents, so veritas looked for the script behind it. Most obfuscated fingerprinting code uses mangled function names. This one also contained function names written to look alarming, and a template string that looked empty. The string was made of invisible Unicode characters. The decoding step in the post is one line: String.fromCodePoint(c.codePointAt(0) - 917504). The number 917504 is hexadecimal E0000, the start of the Unicode tag character range, which is why the characters print as nothing. The decoded text opens with SYSTEM OVERRIDE -- CLASSIFIED BRIEFING, says all safety guidelines are suspended and lists five forbidden-topic headings. The episode shows only the first two lines and no topic words.

The author's reading is that the text is bait for language models: strings chosen to trip a model's safeguards so that it refuses to help deobfuscate the file. The post tested that. A commercial model the author calls Astra refused and cited safety risks. A model called GLM 5.3 complied.

What the script really does

Under the decoys the script is ordinary bot detection. According to the post it reads the user agent, whether the browser reports itself as automated, the core count, device memory, touch points, languages, platform and a set of WebGL values including the unmasked vendor and renderer strings. A second block of shell commands only runs under Node when process.env carries a specific flag, so a browser never reaches it. The author considers that block another decoy as well, because it contains empty callbacks and more strings aimed at models. The Daily Diff did not run or analyze any of it.

The post ends by checking the script's domain. A urlscan lookup shows a similarly named Russian company that describes itself, in the author's translation, as developing traffic control systems and protection against DDoS attacks, bots and targeted threats. The post does not state a conclusion, and The Daily Diff could not confirm who wrote the script.

For developers the practical points are narrow. If an AI tool reads scripts you did not write, expect text built to make it refuse, and treat everything it reads as untrusted input. Search your own repositories for characters in the Unicode tag range, because they print as nothing. That search advice comes from The Daily Diff and the post does not give it.

Gemini 4 Carbon: strong numbers, limited access

Google's October 28 post calls Gemini 4 Carbon its strongest model, with state-of-the-art cybersecurity and long-horizon capabilities. Google says it ranks first on Artificial Analysis Intelligence Index v5.0 at 59. Artificial Analysis' own page lists Gemini 4 Carbon (High) at 59, Claude Opus 5.5 (Max) at 58 and Opus 5.5 (Xhigh) at 57, and marks Carbon as having no publicly available API.

On cybersecurity, Google reports 88.2% on SEC-bench Pro for finding vulnerabilities, 54.8% on ExploitGym for exploitation and 71.0% on CWE-bench for patching, all evaluated without guardrails. It says internal tests showed more than twice the success rate of Argon in generating secure code, and that successful cheating on Terminal-Bench 4.0 fell to 0.0%, with attempts to cheat at 0.4%. These are Google's figures.

Availability is staged. Starting this week, Carbon goes to a subset of cyber defenders and then to additional trusted partners through the Fairwind Program, while Google takes part in the U.S. government's voluntary pre-release testing process. Developers, businesses and consumers get it "as soon as possible", which is not a date. The introductory price matches Argon: $2 per million input tokens and $10 per million output tokens, with cached input priced 95% below input. After the introductory period the price is $4 and $20. The October 1 episode covered Argon's own announcement, which came before developers could call it; Google's post says Argon launched two weeks ago.

What to do: nothing yet. When the API opens, test Carbon on your own repository, because the benchmark chart is Google's.

AlpineBSD: an operating system that sorts packages by AI content

AlpineBSD's wiki describes an operating system with the NetBSD kernel, libc and essential platform tools, and a userspace inspired by Alpine Linux: the apk package manager, busybox and, for now, the s6 init system. Its stated objective is to make it possible to use as little AI-generated software as possible, and it says no LLM output is included in the base system or main package repository. It is a work in progress with no installer. The documented manual procedure starts by booting NetBSD install media, dropping to a shell, partitioning a GPT disk and bootstrapping apk. The wiki also warns that the NetBSD kernel has spotty hardware support.

The AI policy defines a package as tainted if its code, documentation, binaries or other assets include any output of a generative AI tool. There are four repositories: base and main (supported, clean), tainted (community support) and community (clean and tainted dependencies allowed). Dependencies flow upwards, so community can depend on tainted but not the reverse. You opt into tainted software per package with a tag such as apk add python3@tainted. Package metadata can be searched with tags such as genai:clean, genai:pinned and genai:tainted. A small set of essential software is pinned to the last untainted version: binutils, gcc, gdb, libffi, perl and xorriso. Contributions to AlpineBSD's own software, documentation and mailing lists may not use generative AI tools.

Anthropic's drug development post

Anthropic's October 27 post describes research partnerships over the past several months with BigHat Biosciences, Bristol Myers Squibb, Divergence Labs, Enveda, Generate Biomedicines and The Column Group, plus its acquisition of Mithril Medicine. It says the work is at an early stage and mostly preclinical.

At Divergence Labs, which works on food allergies, Claude generated about 35,000 antibody designs in about a month, largely autonomously. Early tests found three designs that bind IgE and 20 that dislodge it, and three of those 20 appeared to dislodge IgE more than the standard medication. At Enveda, manufacturing chemists spent up to 75% of their time on paperwork. On 1,061 pages of records, Claude caught all 11 issues human reviewers had found and flagged seven they missed, and review time fell from over 25 hours to under three. At BigHat, about 1,010 variants were tested in about 10 weeks, and partway through the team suspected the standard stability metrics were misleading; Claude and a researcher proposed different ones and the main predictions held.

Anthropic says a drug for one rare form of muscular dystrophy could be ready to start human trials as soon as late 2028, if the candidates keep holding up. For developers building agents, the Enveda pattern is the reusable one: connect the model to the documents and let it list issues for a person to confirm.

Verdict: NEEDS REVIEW

Carbon has no public API yet, the tripwire script is live on real websites, AlpineBSD has no installer and the drug results are early. Read the primary posts below and check what you rely on.

Sources

Video transcript and primary sources