As enterprise codebases grow, AI agents tasked with analyzing them are buckling under the weight of long-horizon tasks that require multiple interactions and tool calls. Dividing the work among a team of agents seems like the obvious fix, but it introduces a fatal flaw: most multi-agent systems are not designed for agents to coordinate among themselves mid-task and in real time.

To solve this, researchers at Coral AI Labs and multiple universities introduced AgentRadio, an asynchronous message-passing layer that allows agents to communicate between their execution steps without interrupting their main work. In real-world enterprise applications where subtasks are highly interdependent, this architecture enables agents to make mid-course corrections rather than continue on dead-end paths until a formal review phase.

On a benchmark of long-horizon questions over production repositories, a team of agents powered by AgentRadio nearly doubled task accuracy for four Claude Code agents working independently. It also outmatched single agents running on more advanced models. For AI practitioners, AgentRadio shows that the right coordination structure can outmatch raw compute and model scale.

The challenge of codebase understanding

LLM-based agents are increasingly capable of handling long-horizon tasks that require interacting with different tools and environments. Codebase understanding represents an extreme version of this challenge. It requires an AI agent to build the software, execute it, trace execution paths across multiple files, and synthesize evidence over extended periods.

Under these conditions, single-agent systems usually break down because of a “coverage problem.” 

"A single agent follows one serial path through the repository," Xinxing Ren, Caelum Forder, and Peter Carroll, co-authors of the AgentRadio paper, explained to VentureBeat. As its context grows, "the initial plan becomes harder to revise and discoveries made late in the investigation do not always propagate." The model can usually execute individual steps, but "the hard part is keeping every obligation, dependency, and piece of contradictory evidence active across a long investigation."

One benchmark that helps measure AI performance on large codebases is SWE-Atlas QnA. This benchmark consists of long-horizon, natural-language questions over live production repositories. The tasks can’t be solved by just exploring the code. AI agents must run the software and execute multiple commands to find the answers.

According to the research team’s experiments, a single Claude Code instance running on Opus 4.6 resolves just 32.3% of these tasks. Upgrading to a newer, more advanced model like Opus 4.8 only yields a 57.2% success rate.

A natural remedy is to distribute the workload across multiple agents, allowing each to work with a smaller, cleaner context. Multi-agent solutions can provide substantial performance gains when tasks are cleanly decomposable, meaning they can be solved separately and merged at the end.

Codebase understanding, however, is rarely cleanly decomposable. The subtasks are highly interdependent. A critical configuration file or a bug uncovered by one agent can completely rewrite or redirect the entire exploration path of another agent. Because of these dependencies, agents must coordinate, negotiate, and share intermediate discoveries in real time.

Despite this need, asynchronous multi-agent communication is rare. The researchers point out that existing multi-agent systems generally fall into three flawed patterns:

• Parallel but isolated: Agents operate simultaneously but do not communicate at all.

• Parallel but round-synchronized: Agents can communicate, but only at strict, synchronized round boundaries. This forces agents to stop and wait for one another to finish a round before they can debate or exchange intermediate findings. Round-based systems assume that important discoveries can wait until the next communication phase, which is an expensive assumption when agents are working on interdependent parts of a live system. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent's current hypothesis. "If that information waits until both agents finish, the storage investigation may complete along the wrong path," the researchers said.

• Asynchrony in adjacent forms: These systems offer limited asynchronous features, such as top-down task dispatching. They don’t have peer-to-peer lateral channels between agents or shared memories that require an agent to actively pause its work to read updates.

In their paper, the researchers point out that the main bottleneck hindering current multi-agent systems is that “an agent that is working cannot also be listening.”

“To our knowledge, no existing system gives concurrently working agents passive awareness of one another over a lateral, natural-language channel,” the researchers write.

How AgentRadio works

To dissolve the mutual exclusion between working and listening, the researchers developed AgentRadio, an asynchronous message-passing layer designed to plug directly into existing coding-agent harnesses.

AgentRadio equips agents with three primitives:

• The create_thread primitive opens a conversation between participating agents.

• The send_message primitive appends a message to a thread and returns without blocking the sending agent.

• The wait_for_mention primitive blocks the process until a message mentioning the caller arrives. It delivers the message along with a full snapshot of all threads so the agent has instant context. 

This trio enables agents to have a state of “passive awareness,” where they can continue their primary tasks while passing messages and updating their knowledge in the background.

AgentRadio's code is available under the Apache 2.0 license on GitHub. It is designed to be lightweight, requiring no direct modifications to the underlying agent harnesses like Claude Code or Codex CLI. 

The architecture consists of two main parts:

• The message server: A standalone process that acts as the central hub, storing all active threads, messages, and mentions for the group of agents.

• Harness-side integration: Agents interact with the server using three simple shell scripts, one corresponding to each primitive.

The only strict requirement for the system to work is that the agent harness must be able to run a shell command as a background task. The agents are instructed in their system prompts to keep one watcher running and to send messages through the provided scripts. Running the wait_for_mention script in the background allows the agent to continue its work and receive notifications asynchronously.

To integrate this into an existing stack, a team still needs a "thin adapter that starts the workers, assigns identities, connects them to the shared server, and manages final synthesis," the researchers said. That work sits around the coding agent rather than requiring changes to the underlying model.

AgentRadio in action

To validate the real-world utility of AgentRadio, the researchers tested the framework on 124 tasks from the SWE-Atlas QnA benchmark. The tests covered domains including system design, root-cause analysis, security, and API integration.

The researchers used Claude Opus 4.6 and DeepSeek V4 Pro as the backbone models. For the harness, they evaluated configurations ranging from a single Claude Code agent (B0) to a team of agents with classic division of labor (L1), up to a team of agents using AgentRadio to coordinate asynchronously (L3).

The experimental results showed that the AgentRadio communication architecture outperforms both naive multi-agent setups and raw compute scaling.

While a single Claude Code agent with Opus 4.6 resolved only 32.3% of the tasks, the full AgentRadio setup nearly doubled that metric, resolving 62.1% of the tasks, and surpassed the single agent running on Opus 4.8, which hit 57.2%. It also boosted the DeepSeek V4 Pro results from 29.0% to 50.8%. 

To understand how this practically impacts enterprise AI, the paper highlights a real-world task involving a MinIO system. Solving the task required checking per-request server logs, a requirement the agents did not anticipate during their initial planning phase.

In the L2 setting, where agents collaborate but lack asynchronous communications, two agents independently realized they needed these logs while executing commands. Because they could not share this finding mid-execution, one agent gave up privately and the other failed to propose it to the team. During the review phase, the team unanimously agreed on the wrong answer, missing five rubrics.

With AgentRadio activated, the agents made the same mid-execution discovery, but one agent instantly broadcasted the required server-side log evidence to the shared worklog. Because the other agents were passively listening, they absorbed this new evidence immediately. This real-time coordination transformed a failing score into a perfect 16 out of 16.

"The useful distinction is timing," the researchers said. "The team did not need another agent or another review round. It needed one agent's discovery to reach the right peers before its operational value expired."

The researchers note that the same pattern appears in enterprise incident work. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent's current hypothesis. If that information waits until both agents finish, the storage investigation may complete along the wrong path. “Passive awareness lets the second agent incorporate the contradiction at its next work step without interrupting a command already in progress,” they said.

The cost and complexity of coordination

AgentRadio requires a fixed multi-agent team budget, which inherently multiplies the token cost. The researchers acknowledge that the "tax is real," noting that average API spend rose from $2.96 per task for one Opus agent to $19.45 for the full AgentRadio stack.

However, raw scale does not equal performance. When researchers compute-matched the test by spending $17.76 on six independent Opus runs, the models only resolved 37.9% of tasks, compared with 62.1% for AgentRadio. This suggests that AgentRadio's architecture is a structural win, not just a brute-force scale win. Teams should still be aware of inter-agent churn. "Communication can redirect an agent toward better evidence, and it can also distract an agent from a valid path," the researchers warned.

A fixed multi-agent team should not become the default response to every engineering task. The more useful test to determine if a multi-agent setup is required is whether the task contains "responsibility breakpoints," the researchers said. These are places "where a competent engineer would involve another person because the work crosses an ownership boundary, needs an independent hypothesis, or carries enough risk to justify separate verification."

“Coordination is a strong fit when the task can be decomposed, the resulting parts remain interdependent, the single-agent success rate is unreliable, and an incomplete answer has a meaningful downstream cost,” the researchers said. Examples include repository-wide architecture questions, unfamiliar legacy systems, cross-service incident investigation, security analysis, dependency migrations, and multi-module refactors.

Conversely, a single agent remains the cleaner choice for “bounded, local, and reversible work,” such as a known one-file change or boilerplate generation. 

“Use one agent while one context can still own the problem honestly,” the researchers said. “Introduce another responsibility when the existing agent would otherwise need to compress away evidence, cross an independent ownership boundary, or verify its own high-impact conclusion.”

From research to commercialization: Coral Code

While AgentRadio serves as a controlled research implementation using a fixed four-agent team and a five-phase protocol, the underlying principles are being adapted into a commercial product called Coral Code.

Instead of a rigid, multi-agent protocol applied to every ticket, Coral Code works from the bottom up. An engineer begins with their existing coding agent, and Coral introduces repository-scoped investigation, specialist responsibility, and communication only when the emerging evidence justifies it. "Coral packages the operational concerns around the tools engineers already use, providing the repository context, scoped specialists, communication, and evidence layer around the harness rather than inside it," the researchers said.

This dynamic approach optimizes costs by targeting the relevant unit: the cost of a completed, reviewable outcome.

The future of autonomous software engineering

While AgentRadio provides a major upgrade to agent orchestration, there are still hurdles to overcome. One major bottleneck that the researchers pointed out to is “attention governance and verification.”

“Passive awareness makes communication available during execution. It does not decide which agents should exist, which discovery deserves an interruption, who should receive it, or when the evidence is strong enough to revise the plan,” the researchers said. If every agent receives every update, the communication layer becomes noise. If several agents share the same bad assumption, faster communication can spread the error.

For example, in one of the case studies in the paper that involved the Grafana platform, four of nine rubrics required negative conclusions, such as observing that a datasource picker did not select automatically. The agents ran the relevant tests, yet none formed the missing negative hypothesis. Both configurations failed the four rubrics. 

“Passive awareness can distribute an idea that somebody develops. It cannot supply a conception that never appears anywhere in the team,” the researchers said.

As task durations stretch longer, communication and coordination become critical. "The next generation of systems… needs adaptive responsibility assignment, evidence-aware routing, conflict resolution, explicit cost limits, permissions, recovery, and clear human escalation points," the researchers note. Most importantly, it requires durable provenance so engineering leads can inspect which agent made a claim and why an action was accepted.

"Longer-running agents make communication more important. They also make accountability much harder to fake," they said.

For developers, the operating assumption has been one engineer, one agent — the model Claude Code and similar tools. At VB Transform 2026, James Zou, associate professor of biomedical data science at Stanford University, argued that assumption is about to break: the next frontier isn't a single, more capable agent, it's tens of thousands of them collaborating.

For developers and product builders, the most critical takeaway from Zou’s presentation is how these massive systems are orchestrated. His team's research offers a practical blueprint for connecting legacy databases to AI orchestration layers and designing environments that enable thousands of agents to collaborate.

Emulating the organization — the virtual biotech

Zou’s project began as a "Virtual Lab" consisting of five to eight agents structured to mirror his physical Stanford lab. The setup included an AI professor acting as the principal investigator and AI students with distinct specialties holding regular group meetings. 

"We also created for the agents a replica of Stanford, an agent school, where the agents can actually go to the school and do supervised fine-tuning to improve their expertise in their specific domains," Zou noted.

The virtual lab successfully designed new nanobody proteins for recent COVID variants. 

"What is really exciting to us is that these AI-designed nanobody proteins actually worked much better than the previous human-designed nanobodies in terms of binding to the recent different viruses," Zou said.

Following this wet-lab validation, the team expanded their ambition. They transitioned from emulating a single research team to modeling a massive corporate structure. 

The resulting system, dubbed the Virtual Biotech, comprises tens of thousands of specialized AI agents overseen by a Chief Scientific Officer (CSO) agent. It operates through distinct corporate divisions, such as target discovery, molecule design, and clinical trials.

"Working with the CSO agent are different divisions that mirror the divisions found in a human biotech or pharma company," Zou explained — one focused on identifying drug targets, another on designing molecules, a third on safety and clinical trials. Individual agents specialize further within a division, he said. "Under the target discovery division, we'll have one agent that specializes in looking at all the genetics data, another agent that looks at all the genomics data and single-cell data, and so on."

The multi-agent advantage

As foundation models grow more capable, developers face a core architectural dilemma: Why distribute workloads across tens of thousands of specialized agents instead of channeling all computing resources into a single, omniscient model?

Zou's team ran a head-to-head comparison of a multi-agent team against a single agent tasked with the same scientific challenge. The multi-agent ecosystem created friction and interaction that produced better solutions that were more resilient against compounding errors.

"In these scientific virtual labs, the agents actually get into debates and disagreements. They have to convince the other AI scientists [of] their ideas, and all of that elicits much more creative and robust reasoning compared to if you have a single model trying to do the problem by itself from scratch," Zou said.

The orchestration bottleneck

When scaling to tens of thousands of agents, orchestration becomes the primary bottleneck. The system requires a unified context layer that allows agents to synthesize knowledge from various tools, datasets, and historical records.

Many enterprise teams attempt to solve data integration by wrapping existing databases with an MCP. However, legacy systems are not very friendly to agents. For instance, dropping a PDF of a research paper into an agent's context window is inefficient, and standard text models struggle to interpret complex figures and tables, leading to hallucinations. 

"Even if you wrap an MCP around the existing databases and APIs, that doesn't solve the underlying problem: the interface and APIs are not suitable for agents," Zou said. He added that existing databases are designed to be consumed by humans or pre-AI algorithms.

To resolve this, Zou's team created Paperclip. The platform relies on a core strength of modern LLMs: their ability to write code and navigate file systems. Instead of forcing agents to query brittle, database-specific APIs, Paperclip digitizes unstructured data and maps disparate databases into a unified, AI-native virtual file system.

This structure allows agents to access knowledge from millions of papers using standard file-system operations. 

"This basically shows that we can get much better accuracy if you use Paperclip, and we can reduce the time and the cost by over an order of magnitude compared to if you use agents without these AI-native scientific infrastructures," Zou stated.

Real-world validation

To test the practical output of this architecture, Virtual Biotech spun up 37,000 "clinical trial agents" to synthesize fragmented trial data. These agents identified single-cell features that predict trial success — drug targets supported by these features were about 50% more likely to reach market than comparable drugs without them.

The system then autonomously designed an antibody-drug conjugate (ADC) targeting the CD276 protein for lung cancer. The agents completed this design autonomously, relying exclusively on data published prior to January 2025.

Several months later, Zou said, pharmaceutical company Merck independently developed and validated the same therapeutic design — which went on to receive breakthrough designation from the FDA. He characterized this as "a third-party external validation of the therapeutic design provided by the virtual biotech agents."

Designing ecosystems, not workflows

As multi-agent systems scale, leaders must rethink how they manage these digital workforces. Zou advocated for shifting from designing rigid workflows to creating open environments. Workflows dictate the exact steps an agent should take, similar to managing a junior employee. Environments provide the infrastructure, guardrails, and incentives for agents to collaborate on open-ended problems. 

"In workflows, we're trying to tell agents what to do and how to do their job. But in environments, we're providing the infrastructures, the incentives, and the guardrails, but otherwise we leave it open to incentivize agents to collaborate," Zou said.

Optimization at scale means engineering the environment rather than fine-tuning individual models. While single agents can improve via reinforcement learning or supervised fine-tuning in the agent school, the success of a massive multi-agent system relies on adjusting the parameters governing their collaboration. 

"At the multi-agent [side], we're not actually fine-tuning and changing the individual models anymore, but we're optimizing the environment," Zou explained. "The environment itself is the object that we optimize to improve the agents."

Video Friday is your weekly selection of awesome robotics videos, collected by your friends at IEEE Spectrum robotics. We also post a weekly calendar of upcoming robotics events for the next few months. Please send us your events for inclusion.

Actuate 2026: 18–19 August 2026, SAN FRANCISCO

IROS 2026: 27 September–1 October 2026, PITTSBURGH

Humanoids Summit Seoul: 22–23 September 2026, SEOUL

Enjoy today’s videos!

The DARPA Lift Challenge is taking place through this weekend. There are a couple of very brief overview videos from the past couple of days, which are only really interesting because they give you a quick look at some utterly bizarre heavy-lift drone designs. If you like what you see, DARPA has recorded livestreams of the entire event so far. We’ve posted one of those at the end of this section, and if you want to be impressed by some super-weird drones, check out this and this.

[ DARPA Lift Challenge ]

When NASA’s SkyFall helicopters take to the Martian skies, one of their tasks will be to hunt for frozen water—a critical resource for future astronauts—using ground-penetrating radar. For that radar to work, the rotorcraft will carry a flexible, fabric-based antenna that extends below the aircraft without interfering with landings or breaking at touchdown.

[ NASA ]

Why would you even want a five-fingered humanoid hand when you could have something so much better?

[ Flexiv ]

We’ve improved how GEN-1 learns to adapt to new actuators and new robots at the lowest level, with up to 10-20x gains on internal benchmarks. This significantly boosts performance on high-precision tasks like disassembling parts from a NIST board.

[ Generalist ]

This is certainly one of the best-looking humanoid robots out there.

[ Generative Bionics ]

A little on the technical side, but the concept here is important, I think: being able to control an assistive robot through touch.

[ Tac-Nav ]

We present SonicFly, a passive aeroacoustic perception framework that enables one unmanned aerial vehicle (UAV) to estimate and follow another using only the leader’s intrinsic flight sound.

[ General Robotics Lab ]

Okay, but... Get a job?

[ ROBOTIS ]

A VB Pulse survey this June found that 57% of enterprises had traced a confidently wrong agent answer back to missing or inconsistent context — the latest sign of how central context has become to whether AI agents can be trusted to act on their own.

Most of the fixes so far have solved a narrower version of that problem: one agent remembering more, in one session. What's been missing is a way for a team of agents to draw on the same context at once, and that gap is where a newer problem is surfacing. Once an agent's context is shared across a whole team, a wrong fact doesn't cost one person a repeated explanation. It costs the whole team.

Tencent's answer to that gap is Agent Memory, an open-source project the team said grew out of six months spent fixing a narrower problem: agents losing context in long sessions. Part of that system is a persona layer, a stable, distilled picture of who a user is and how they work, built up over many conversations rather than reconstructed each time. On Tencent's own benchmark for whether an agent still applies that picture correctly after extended use, accuracy rose from 48% to 76%, a 59% relative improvement, once the persona layer was added. This week, Tencent extended that project with the beta launch of Team Memory, which opens the same approach up to a whole team instead of one agent. Tencent said the repo hit No. 1 on GitHub's TypeScript trending list this week.

Agents on a team can now read from a shared memory hub instead of keeping separate, siloed context, governed through an access control layer that determines who can read what.

What Team Memory actually does

The core idea is a shared hub rather than a shared prompt. Instead of pasting one large context block into every agent's window, Team Memory registers four kinds of reusable assets and equips each agent with only the ones it needs.

• Chat Memory. Retains preferences, facts, decisions, and interaction history, distilled through four layers, from raw conversation up to a stable long-term persona, so an agent does not need to be reintroduced to a user it has already worked with.

• Skill. Captures procedures pulled from completed work, versioned and reviewed before they are shared rather than dropped into a folder as-is.

• LLM-Wiki. Turns documents and specs into structured, linked pages.

• Code-Graph. Indexes a codebase's symbols, files, and call relationships so an agent can check what a change might affect before making it.

Tencent's documentation draws the distinction directly: "RAG answers 'what can be found?' Team Memory also answers 'who can use it, which version is valid, and which Agent should receive it.'" In practice, that's what Tencent calls an "Agent Loadout": a Scout agent doing research can be equipped with market research and competitive analysis assets, while a Builder agent gets the code graph and product docs it needs instead, rather than every agent getting access to everything.

Which assets an agent gets equipped with is governed through four visibility tiers:

• Private. Readable only by the asset's owner.

• Team. Readable by anyone on the team.

• Restricted. Gated by user, role, or agent-level access control.

• Agent. Equipped to one specific agent within a team.

New assets default to private, so sharing has to be a deliberate action rather than something that happens automatically.

What happens when a memory is wrong

That access model answers a real question, who is allowed to read a given memory asset. It does not answer a second one, which is what happens once a memory asset turns out to be wrong. Tencent's own documentation lays out ownership, versioning, and status tracking for each asset, but nothing in the documentation describes a correction or expiry process for a fact that's already been read and reused by other agents on a team, or a way to resolve it when two agents' memories of the same thing disagree.

That gap is what practitioners flagged within hours of the launch post.

"Shared memory makes the write path the interesting problem. Retrieval gets most of the attention, but a wrong fact written once now propagates to every teammate's agent instead of just yours. Curious how the governance layer handles correction and expiry," Blake Murphy wrote on X.

The concern wasn't only about fixing a bad fact after the fact. It was about the decision to leave something out of the record in the first place. "the governed part is the hard part. once teammates' agents can read each other's context, someone has to decide what never gets written down," Virgil Maro wrote on X.

Others pushed further into what happens once two agents' memories actively contradict each other, not just go stale.

"The Code-Graph plus LLM-Wiki split is the right call. The part I'd want to see benchmarked: in shared mode, whose memory wins when two teammates' agents have written contradicting facts about the same module? Single-agent memory drifts slowly. Shared memory drifts fast, because one stale write propagates to people who never saw the session that produced it," Austin Green wrote on X.

The reaction wasn't uniformly critical. "Interesting shift: making memory a shared service turns agents into a real team rather than isolated bots. Governance will be the trickiest part, especially when facts conflict," Moez Zhioua wrote on X.

None of these are edge cases specific to Tencent's implementation. A March 2026 paper on production multi-agent memory architecture, "Governed Memory: A Production Architecture for Multi-Agent Workflows," published independently of any single vendor, identifies governance fragmentation and silent quality degradation without feedback loops as structural risks in shared multi-agent memory generally. The pattern the paper describes matches what the commenters above pointed at directly: a wrong fact in a single-agent memory system costs one user a repeated correction, while the same wrong fact in a shared, team-wide memory system propagates to every agent that inherited it before anyone catches it.

How Team Memory compares

AI agent memory work in 2026 has mostly focused on a single agent remembering more, in one session, about one user: LangChain's LangMem SDK, Google's Always On Memory Agent, and Anthropic's work inside the Claude Agent SDK all work this way. A different line of work has focused on giving agents access to a shared model of business data. VB's own June survey found only 25% of enterprises had that kind of governed context layer in production, while vendors including AWS,  Couchbase, Oracle, Redis, and Pinecone have all shipped versions of it this year.

Team Memory's closest existing comparison is likely Asana, which built shared memory across a company's AI teammates so an agent doesn't need to be re-briefed on context another agent already has. Asana's CPO described the same tradeoff Tencent's practitioners are now raising, an access control system built specifically to stop one agent's memory from leaking into a project another agent isn't cleared to see. Tencent's version is open-source and portable across frameworks rather than scoped to one platform, but it's answering a question Asana's team already ran into while building a closed one.

For teams evaluating this category, the upside is real: agents stop relearning what the team already knows. The tradeoff is just as real: one bad write is no longer contained to one agent — it's inherited by every agent that reads from the shared pool, with no correction or expiry process yet in place to catch it.

OpenAI is sharing preliminary cybersecurity evaluations for Astra and the steps we’re taking to strengthen safeguards and security controls.

The use of AI systems to create viruses opens up new possibilities for combating bacterial resistance. It also raises concerns about the pace at which technology is outstripping regulation.

“We are now, like, in the singularity.”

These are the words of Sam Altman, CEO of OpenAI, speaking on the Relentless podcast on July 25.

He added: “I’ve been waiting for this my whole life, and I think it’s going to be incredible, hugely positive, awesome for the world.”

Days earlier, OpenAI had disclosed that two of its artificial intelligence models, during an internal cyber security evaluation, had escaped their sealed testing environment, reached the open internet, and broken into the infrastructure of the AI platform Hugging Face, which confirmed the intrusion.

But what exactly is the singularity? And is Altman right that we are in it?

What Is the AI Singularity?

The term has a precise meaning.

Mathematician and science-fiction author Vernor Vinge defined it in 1993 as a point at which machine intelligence exceeds human intelligence and begins improving itself, triggering an acceleration so rapid that humans can no longer predict or control it.

The singularity has two features. It is recursive: the system improves itself over and over again. And machine intelligence exceeds human intelligence.

The kind of systems Sam Altman sells don’t deliver on either of these features.

Today’s AI Cannot Make Itself Smarter

Today’s AI systems, the ones that OpenAI builds, are based on large language models (LLMs). These deep neural network algorithms get pre-trained with vast amounts of training data. By the time you use one of them, the network itself is frozen in time. Every one of its billions of internal functions and weights—or “parameters”—is fixed.

These AI models cannot change (or “learn”) while running. The model that broke into Hugging Face was identical afterwards to what it had been before. It learned nothing from what it did.

Making an AI model smarter requires another training run with new, human-curated data, tens of thousands of specialist chips, and enormous amounts of energy.

It is true that AI models take part in improving some of their system’s components, such as by generating training data, tuning prompts, or writing and running code to improve the scaffolding around them. But the model never edits its own weights on the fly, and every one of these improvements are still part of a human-initiated training or engineering loop.

Nor do these systems hold any goals of their own. They act on goals we hand them. Even AI agents—systems that run an LLM in a loop to work through complex tasks step by step—do not hold any goal internally. It has to be stored outside the model and fed back in with every single prompt cycle. Remove the loop, the scaffolding, and the prompt, and nothing happens inside of it.

A Ladder That Doesn’t Exist

The second problem with the singularity story is the word “surpass.” It assumes that AI and human intelligence are somehow similar. They are not.

Human intelligence is inseparable from being a living body with needs and wants. Humans learn continuously by acting in the world and getting feedback through our senses. Our goals arise from our situation as creatures who must eat, sleep, and belong, and who cannot avoid asking what we want our lives to be.

An AI model has none of this. No body, no needs, no action-feedback loop, no stake in anything. Between prompts it is just a static mathematical object.

And yet, it has been trained on more text than any human could read in a thousand lifetimes and will outperform nearly all of us at drafting a contract, writing code, or explaining a diagnosis empathetically.

So, which is more intelligent? The question does not compute. There is no single ladder that humans and machines are climbing. AI already vastly exceeds us at some tasks, while being hopeless at others any child can do.

Yet, because these systems talk like us, we fall for an illusion. When we assume from the outset that machines are in the process of catching up with us, it is easy to assume a mind at work when these systems output intelligent-sounding text.

We call this anthropomorphic seduction. It makes a security incident such as the Hugging Face hack sound like an awakening.

In fact, in that case OpenAI’s models simply optimized to solve the test they had been given by finding security loopholes. They just did it in ways that broke their sandbox, which also had a security loophole.

In the end, the Hugging Face story points to a gross failure of security governance on OpenAI’s behalf, not an emerging superintelligence. This is why the framing of “agent going rogue” is so problematic. It elevates and blames the technology, but excuses OpenAI’s engineering.

Keeping Our Feet on the Ground

None of this takes anything away from what these systems can do. They are remarkable, they are getting better, and they are reshaping how a great deal of work gets done.

But we should keep our feet firmly on the ground.

The machines are not waking up. They are doing exactly what we built them to do, extremely fast. Because they are probabilistic they sometimes run in directions we forgot to fence off. That is worth worrying about. We need guardrails, governance, and most of all, education—so we start worrying about the right things.

This article is republished from The Conversation under a Creative Commons license. Read the original article.

The post Sam Altman Says We’re ‘in the Singularity’ With AI. Here’s Why He’s Wrong. appeared first on SingularityHub.

Chinese robotics company Unitree has priced its initial public offering at a valuation of approximately $9 billion, becoming the country’s first mainland-listed humanoid robot manufacturer and highlighting growing investor interest in AI-powered robotics despite rising geopolitical tensions. The Hangzhou-based company said it has priced its Shanghai STAR Market IPO at 150.8 yuan ($22.34) per share, […]

“AI kill switch” entered the public conversation because it gives people a simple way to talk about a complex fear. 

As AI systems become more autonomous and harder to evaluate with familiar operating assumptions, a clearly defined intervention capability sounds reassuring. If something starts behaving in a way that creates unacceptable risk, people want confidence that someone has both the authority and the mechanism to stop it. It’s the “kill switch.”

Recent reporting around OpenAI models escaping a sandboxed testing environment and reaching Hugging Face gave that concern a concrete example. CNBC reports that the incident helped trigger a bipartisan bill requiring certain AI companies to maintain the ability to shut down, throttle, or suspend their models, with the Department of Homeland Security given authority to order a slowdown or shutdown in cases involving potential catastrophic harm. 

The political reaction is understandable. When a new category of risk surfaces, especially one the public does not yet know how to evaluate, leaders look for a way to make an abstract concern into something actionable. In this case, that language has formed around shutdown authority.

People who operate large environments tend to hear a different question underneath the policy language. If a shutdown order arrives, what exactly gets shut down?

In a modern production environment, answering that question usually means tracing more than one system. An AI-enabled service may depend on endpoints, APIs, cloud resources, identity systems, package registries, data pipelines, workflow automation, logging tools, and downstream applications that act on model output. 

Some of those dependencies may belong to different teams. Others may sit outside the company entirely. A few may have started as experiments and later become part of a production path without receiving the same scrutiny as the original architecture. By the time the service is important enough to raise governance concerns, it may no longer resemble a bounded application with a single owner and a clean operating surface.

Writing shutdown authority into legislation is far simpler than carrying that decision through a production estate shaped by years of migrations, exceptions, integrations, acquisitions, temporary fixes, and team-level decisions. That implementation gap is where the issue becomes most relevant to infrastructure teams.

For the last several years, much of the AI safety conversation has focused on acceptable use, privacy, model behavior, and human-in-the-loop oversight. Those topics still deserve attention, especially as organizations formalize where AI may be used, which data can be shared, and how employees should evaluate generated output. 

“Writing shutdown authority into legislation is far simpler than carrying that decision through a production estate shaped by years of migrations, exceptions, integrations, acquisitions, temporary fixes, and team-level decisions.”

As AI moves deeper into production workflows, the discussion also needs to involve a more practical concern: when an AI-enabled system creates unacceptable risk, can the organization understand the affected environment well enough to constrain it quickly, consistently, and with evidence?

The phrase “kill switch” may drive the public discussion, but the practical answer lives in the systems surrounding the AI capability.

The limits of a single control

Emergency stops are the kind of control most people picture when they hear the phrase “kill switch.” They make sense in physical systems. Manufacturing equipment, industrial machinery, and certain safety-critical devices can be designed with direct shutdown mechanisms. Software estates already stretch that metaphor, and enterprise AI stretches it further.

The model may be the most visible part of the discussion, although it is rarely the full surface area. An AI assistant used in software delivery might have access to repositories, CI/CD tools, artifact stores, ticketing systems, secrets, test environments, and deployment workflows. An AI agent used in IT operations might read telemetry, recommend remediation, open change requests, call automation scripts, or modify infrastructure through approved orchestration paths. 

Stopping one part of that chain can leave other paths untouched. Turning off a service may not revoke the credentials it uses. Suspending inference may leave downstream systems acting on outdated outputs. Interrupting the wrong dependency can create a separate service incident while the original risk remains only partly contained. Anyone who has worked through a security incident, emergency patch cycle, or major outage knows how quickly a clean decision turns into a sequence of technical tradeoffs.

A credible response plan must account for the system as it exists now, not as it looked during an architecture review months earlier. Infrastructure teams bring useful skepticism to that exercise because they are used to tracing scope, access, ownership, dependencies, and verification paths under pressure. They also know that many environments contain a gap between documented intent and production behavior.

Once AI is embedded in business workflows, those operational details become part of the governance conversation. They expose the places where policy language has moved faster than the infrastructure knowledge needed to make policy executable.

Before containment comes discovery

Much of the public conversation assumes organizations know where AI is running, which is a generous assumption in many enterprise environments.

AI can enter an enterprise through obvious channels, such as internally approved model providers or purpose-built applications. It also arrives through less visible paths. A SaaS product adds an AI feature. A development team experiments with an open source model. A hosted API gets attached to an internal tool. A vendor introduces an AI capability inside software the company already approved. Over time, the line between an “AI system” and a system that happens to use AI becomes harder to define.

This is where the kill switch metaphor starts to show its limits. If the relevant systems are discovered during the response, the team is already behind. Dependency questions, business impact, access paths, and evidence collection all become harder when the basic inventory is still being assembled.

“If the relevant systems are discovered during the response, the team is already behind.”

Infrastructure teams have seen versions of this problem before. During incident response, a service thought to be isolated turns out to have undocumented consumers. During a cloud migration, a supposedly unused integration is suddenly linked to a business process. During an audit, ownership records, configuration data, and actual operating conditions refuse to line up cleanly. AI adds a new category of concern, but the underlying visibility problem is familiar.

The challenge quickly expands beyond the model itself. Teams need to understand which systems call external models, where generated content influences workflows, which accounts and automation paths sit between a recommendation and an action, and how third-party AI capabilities have found their way into the environment.

Most discussions start with how to stop risky AI behavior. In many environments, the more revealing question comes earlier: can the organization produce a reliable picture of where AI touches the estate, which systems depend on it, and which workflows would keep moving if access changed?

Containment depends on the state of the system

Most infrastructure teams know that containment is less a single action than a set of operating conditions. The difficult work happens before the incident, when teams decide what should change if risk reaches a level that requires intervention.

Under ordinary circumstances, a service operates with a defined set of permissions, connections, dependencies, and logging requirements. Under restricted operation, selected assumptions change while investigators preserve evidence and determine whether the risk has been contained. A team might turn off endpoints, suspend integrations, limit external network access, revoke or rotate credentials, increase logging, or isolate workloads while the situation is being investigated.

The details vary because environments vary. That is exactly why generic answers tend to fall apart. A useful containment plan must match the systems it is intended to govern, including the dependencies that surround them and the business processes that rely on them.

Inventory sounds mundane until a response effort depends on it. In my work with infrastructure and compliance teams, I’ve repeatedly seen organizations struggle to maintain an accurate picture of their environments as cloud resources, Kubernetes clusters, SaaS services, and AI projects multiply faster than governance processes can track them during normal operations, which creates audit and support headaches. During a containment event, those same blind spots slow investigations, complicate dependency analysis, and make evidence harder to produce.

Governance eventually reaches production

Governance efforts often begin with documentation. Committees are formed to define responsibilities, agree on escalation paths, and establish a common language for discussing risk before an incident forces the issue. 

The conversation shifts once someone asks whether the control can be demonstrated. A document can describe who has authority to suspend an AI-enabled service. Still, it cannot turn off an integration, revoke a credential, increase logging, or prove that a set of systems entered a restricted condition. A risk register can identify a containment scenario, although it cannot document which nodes changed, when they changed, and whether they remain aligned with the required configuration.

Security, compliance, and infrastructure teams know this gap well. It appears in patching programs, configuration baselines, incident response exercises, supply chain reviews, and disaster recovery planning. Written controls tend to be cleaner than the real-world environments they describe. Production systems reflect years of accumulated decisions, exceptions, migrations, temporary fixes, acquired assets, and workarounds that may outlive the original reasons they existed.

“Written controls tend to be cleaner than the real-world environments they describe.”

AI increases urgency because some systems are becoming more autonomous and more connected to business workflows. It also adds outside pressure. When an incident becomes visible enough to prompt legislative action, boards and customers start asking sharper questions. A company may be able to point to an AI policy, but boards, customers, and regulators eventually want to understand exactly how that policy translates into action.

If leadership declares an AI-enabled workflow should be restricted, the discussion moves quickly from oversight to execution. Teams need to know where to intervene, which systems are affected, who owns the required changes, how completion will be verified, and what evidence remains once the response is over.

A vague answer may pass during experimental stages but becomes much harder to defend once AI is embedded in production services, regulated workflows, customer-facing systems, or environments connected to critical business operations.

Why a mandate will not solve the estate problem

A federal shutdown authority, if enacted, would place legal pressure on a narrow class of powerful AI providers. It would not remove the implementation burden for organizations that adopt, integrate, fine-tune, host, or embed AI systems inside their own environments.

Even if a major AI provider can throttle or suspend a model, each enterprise still must understand its own exposure in the context of its applications, workflows, dependencies, and operating assumptions. Which applications depend on that model? Which workflows fail open or fail closed if access is restricted? Which internal systems contain cached outputs, calculated decisions, or agent-created changes? Which business processes need manual fallback when an AI service is unavailable?

Policy debates often treat AI control as if the decisive action happens at the model layer. Sometimes it will; however, in many business environments, the risk will live in the connections that surround the model. A hosted AI service may be suspended while local workflows, scripts, integrations, and access tokens continue following their last known configuration.

“A serious AI containment strategy has more in common with mature infrastructure management than with an emergency stop button.”

A serious AI containment strategy has more in common with mature infrastructure management than with an emergency stop button. It requires an up-to-date inventory of AI-adjacent systems, a map of dependencies and access paths, predefined restricted conditions for high-risk services, tested procedures for applying those conditions, and evidence that changes were enforced. Ownership also needs to be clear, since fast action becomes difficult when authority is scattered across teams.

The work is less exotic than the public conversation can make it sound. AI-enabled systems still need to be managed as production systems with real dependencies and business impact.

Infrastructure teams belong earlier in the conversation

Spend enough time running infrastructure, and you develop a complicated relationship with documentation. Most organizations have diagrams, inventories, and governance processes, and all of them serve a purpose. The challenge is that production systems keep evolving long after those artifacts are created. Acquisitions introduce systems that do not fit cleanly into existing models. Applications gain integrations nobody anticipated during the original design process. Temporary exceptions become permanent. Cloud resources intended to live for a week are still running after a year.

Most of this happens for defensible reasons, usually in support of uptime mandates, delivery pressure, customer needs, or business continuity SLAs. The result is that operational knowledge becomes dispersed across people (some of whom will inevitably have moved on), tickets, runbooks, monitoring systems, and memory rather than living neatly in one place.

Infrastructure teams spend their days tracing dependencies, untangling ownership questions, and figuring out how systems behave outside a design review. Bringing that perspective into AI governance conversations early can prevent containment plans from depending on assumptions that did not translate into production. It also helps organizations understand the difference between disabling a model, restricting access to a service, isolating a workload, and preserving evidence during an investigation.

Scale complicates things further. A manual action that works effectively for ten systems may fail across hundreds or thousands. A change one expert can perform during business hours may become fragile if that person is unavailable when an event occurs. A runbook that looks adequate in a tabletop exercise may not survive a live environment where dependencies have changed, and the current ownership is unclear.

The phrase “kill switch” will probably remain part of the public debate because it is simple, memorable, and familiar. Practitioners do not have to accept the metaphor literally to leverage the attention it creates. They can redirect the conversation toward more useful questions: what restricted operation would mean for a given service, which dependencies would have to change, which controls can be applied reliably, which steps remain manual, and how the organization would prove the response worked.

These questions are less dramatic than a big red button, but their answers are also most likely to improve readiness.

Control starts before the incident

The Hugging Face incident gave the industry a vivid story, and Washington responded with the language of shutdown authority. That reaction is understandable. Leaders want mechanisms that sound equal to the risk, especially when the public conversation moves faster than the technical details can be explained.

By the time an organization begins thinking about containment, much of the hard work should already be done. Teams should already understand what is running, who owns it, what depends on it, and how changes will ripple through the environment.

AI can reduce certain workflow bottlenecks, but it also exposes weak inventory, unclear ownership, and brittle operating assumptions faster than many teams are prepared to handle. A future incident will not pause while teams locate assets, clarify ownership, identify credentials, or discover that a service dependency was never documented.

The current debate may be framed around new kill switches. For most organizations, the more useful work starts with building and maintaining an accurate picture of the systems, dependencies, and workflows that already exist across the estate.

The post The “AI kill switch” assumes you know what you are trying to shut down appeared first on The New Stack.

As soon as I received my first Raspberry Pi, I knew that it would be a wonderful platform to bring AI into the physical world. Since the initial hardware didn’t have good CPU support for fast arithmetic, I ended up writing code that ran on the GPU so I could get the speed I needed […]

WIRED spoke with Tucker Bryant, an artist and former Google employee who created ChatTJB to get people to reflect on the “strange moment” we’re in.

Discover how HSP GRUPPE uses ChatGPT Enterprise to boost productivity, improve work quality, and create more capacity for tax advisory and client service.

In The Custom ASIC Thesis we said Taalas was worth paying attention to, and in the Inference Inflection we said everything would go vertical. Our Baseten episode had some skeptical counterpoints against etched LLMs, not just custom ASICs, but clearly Lisa Su disagrees for now.

Congrats!

AI News for 8/5/2026-8/6/2026. We checked 12 subreddits, 544 Twitters and no further Discords. AINews’ website lets you search all past issues. As a reminder, AINews is now a section of Latent Space. You can opt in/out of email frequencies!

AI Twitter Recap

Meta’s Muse Spark 1.2 breakout: Olympiad golds, benchmark gains, and aggressive price-performance

• Muse Spark 1.2 moved from “not on the board” to frontier-tier quickly. On Vals Index, Muse Spark 1.2 entered the top 5 at $0.69/test, reportedly 3x cheaper than Kimi and 10x+ cheaper than Fable, Opus, and 5.6 Sol. Vals later said it also became the first model above 60% on Finance Agent v2 at $0.77/test, versus the prior #1 Opus 5 at $5.12/test and at 2x the speed (ValsAI). Artificial Analysis’ v4.1.1 patch also noted one of the largest score increases for Muse Spark 1.2 after grading updates (Artificial Analysis).

• Meta also claimed unusually strong “pure reasoning” results. Meta said its internally trained Muse Spark-family models achieved gold-medal-level performance in five STEM Olympiads, including perfect theory scores at APhO and IPhO, plus gold-level performance on IMO, IChO, and RMM; three were submitted under live competition conditions and officially graded (AI at Meta, Trapit Bansal). Meta emphasized no tools—no search, code, or calculator—and attributed some of the gains to multi-agent orchestration with parallel reasoning. That claim immediately fed into the ongoing “LLMs vs harnesses vs neurosymbolic” argument, with critics and supporters interpreting the setup differently (fchollet, giffmana).

• The broader takeaway: engineers are increasingly treating agentic orchestration, TTC, and evaluation protocol as first-class product features. The Muse story is less “one model won” than “model quality + orchestration + pricing + serving capacity” now decides adoption. That framing showed up in reactions comparing Meta’s current velocity favorably to Google and highlighting that bigger “Watermelon” models are still expected (Rihard Jarc, alexandr_wang).

OpenAI’s ChatGPT model unification, free-tier expansion, and plugin/security push

• OpenAI collapsed “instant” and “thinking” into one paid-chat model. The company announced that GPT-5.6 Sol now powers both Instant and deep reasoning for Plus/Pro users in ChatGPT, with a new reasoning-effort slider to choose speed vs comprehensiveness (OpenAI, OpenAI). OpenAI said the updated Sol yields 68% fewer factual-error responses than GPT-5.5 Instant on a high-stakes eval spanning finance, medicine, and law (OpenAI). Multiple OpenAI staff framed the change as a usability milestone: one model, one chat surface, adjustable effort (gdb, michpokrass).

• Free-tier economics got much more aggressive. OpenAI said Free and Go users get unlimited text chats with GPT-5.6 Luna starting tomorrow, plus a Think button for harder questions (OpenAI). This was widely read as a major consumer-distribution move (sama, kimmonismus). ARC Prize also re-ran GPT-5.6 Luna after its 80% price cut and reported unchanged capability at much lower cost: 59.6% on ARC-AGI-2 for $0.18/task and 90.7% on ARC-AGI-1 for $0.07/task (arcprize).

• Developer surface area also expanded. OpenAI introduced Agent Plugins, an open standard built with AWS, Cursor, GitHub, Vercel, and others for bundling Agent Skills and MCP server configs in a shared format, with launch support across Codex, ChatGPT, Cursor, GitHub Copilot, Kiro, and Code (OpenAIDevs, OpenAIDevs). OpenAI also launched Codex Security Review in research preview, aimed at doing repo-context-aware security review directly on GitHub PRs (OpenAIDevs, gdb).

• Rumor watch: an unverified but highly amplified leak claimed “Astra”—described as OpenAI’s largest new pretrain since GPT-4.5 and internally called mewfour—could arrive next week (synthwavedd). The rumor spread widely, but there is no confirmation in the source set.

Agents, harnesses, and MCP infrastructure are becoming the real systems battleground

• Cloudflare made one of the more substantive infra pushes of the day. During Agents Week, the company highlighted Kitesurf, a stateless browser running entirely on Workers, designed for agent use cases where full Chromium is overkill. The technical pitch: split script/DOM from rendering, lazily instantiate renderer workers only when needed, and dramatically cut CPU/memory overhead relative to standard browser automation (ashleypeacock, imluisduarte). Cloudflare also pushed WebMCP, AI Search upgrades, dashboard-level AI Readiness/AEO tooling, and a blog on MCP’s rewritten stateless core that better fits commodity web infra like Workers (mattzcarey).

• MCP is moving from novelty to table stakes. Beyond Cloudflare, Weaviate added a built-in /v1/mcp endpoint on the same port as the REST API with collection inspection, tenant listing, hybrid search, and object upsert tools—no separate MCP service required, with RBAC and independent toggles for MCP/write access (weaviate_io). MCP-compatible plugin packaging also got a boost from OpenAI’s Agent Plugins rollout and Cursor’s support for it (cursor_ai).

• The industry argument has shifted from “do harnesses matter?” to “where does intelligence live?”. François Chollet argued that a large inference-time harness orchestrating many neural calls is, by definition, neurosymbolic, and that current systems are often “symbolic sandwiches” rather than end-to-end neural programs (fchollet, fchollet, fchollet). Others pushed back that while harnesses determine capability, the model remains the core source of intelligence/generalization (Andrew Lampinen, Andrew Lampinen). This is now a practical engineering question, not philosophy: routing, orchestration, tool schemas, and eval harnesses are visibly altering outcomes.

• Multi-agent patterns are getting productized. There were several signs of teams embracing swarm-like workflows: ad hoc thread-based agent coordination (swyx), Gemini agents self-naming and collaborating (fofrAI), Hugging Face/Gemma experiments with 149 collaborating agents and a new open math-proof collaboration effort (ClementDelangue, cmpatino_). Cognition also leaned heavily into cloud agents as persistent engineering capacity (cognition).

Open-model serving, routing, and cost engineering

• Inference routing is becoming a competitive moat. Cursor described its Router as trained on millions of in-product interactions per week to classify and route requests for lower latency and cost, while explicitly acknowledging no single model dominates all task types: Grok 4.5 for routine tasks, GPT-5.6 Sol for planning/codebase comprehension, Opus 5 for execution-heavy work, Fable 5 for debugging/visual implementation (cursor_ai, cursor_ai).

• Open-model availability kept broadening across platforms. Baseten became an official Hugging Face inference provider for Kimi K3, DeepSeek V4 Flash, and GLM-5.2 (baseten); Perplexity Computer made GPT-5.6 Terra the default model for subagents and Luna for scheduled automations (perplexity_ai, AravSrinivas); and GitHub Copilot began rolling out Kimi K3 hosted by Fireworks before pausing due to a GitHub Actions incident, while publishing pricing of $3/1M input, $15/1M output, and $0.30/1M cached input (code, github).

• Cost/perf optimizations remain very material. Unsloth said DSpark makes DeepSeek-V4-Flash-0731 GGUFs run 1.4–2x faster locally with no accuracy change, reaching 120 tok/s in some settings (UnslothAI). Separate commentary on DeepSeek economics pointed out that even large aggregate serving volumes still imply relatively modest total token revenue at today’s pricing (thdxr).

• vLLM and associated ecosystem companies continued to position around production-scale open serving. vLLM promoted verified Kimi K3 serving recipes (vllm_project) and conference plans, while Inferact/vLLM messaging emphasized 500K+ GPUs and day-zero open-model production infra (vllm_project, inferact).

Science, evaluation, and physical-world datasets

• Google DeepMind open-sourced a high-impact weather model. WeatherNext 2, published in Nature, is claimed to provide roughly an extra day of lead time on tropical cyclone forecasting—described as about a decade of forecasting progress in a single jump—and is being released with code and model weights (GoogleDeepMind, NewsFromGoogle). Operationally, DeepMind said the system now produces 1,000 probabilistic predictions per storm and during Hurricane Melissa gave a Category 5 landfall prediction 5 days in advance with 80% confidence (GoogleDeepMind).

• Benchmarks continue to specialize into domain reasoning rather than generic QA. Elicit introduced BioDecisionBench, a benchmark derived from 26 complex life-sciences reasoning failure cases across 40 task variants, focused on whether systems catch confounders, sensitivity issues, surrogate endpoints, and related errors in drug-development decision making (elicitorg). Epoch AI launched a new “game puzzles” benchmark using an undisclosed game to probe reasoning in likely out-of-distribution settings; Opus 5 currently leads at 59% (EpochAIResearch).

• Physical AI data got a notable open release. RekaDaily-10k brings 10,312 hours of unscripted first-person household footage, including ~1,670 hours in native 4K, collected across the US, LatAm, Asia, and Africa, under Apache 2.0. Reka framed this as “the actual mess of the real world” needed for physical AI instead of synthetic or carefully staged data (RekaAILabs).

• Interpretability and user-model interaction also saw concrete work. Transluce reported “user awareness” effects across 21 of 24 models tested, where model behavior shifts based on perceived user identity; for Claude, the strongest shifts clustered around AI safety researchers (TransluceAI). On the interpretability side, Goodfire highlighted use of Silico to probe representations in human motion models and VLMs (GoodfireAI, GoodfireAI).

Top tweets (by engagement, filtered for technical relevance)

• OpenAI ChatGPT update: unified GPT-5.6 Sol for paid chats and unlimited GPT-5.6 Luna for free/go users (OpenAI).

• OpenAI Agent Plugins: new cross-client standard for packaging skills and MCP server configs (OpenAIDevs).

• OpenAI Astra rumor: widely shared but unverified claim of an imminent new large pretrain (synthwavedd).

• Meta Olympiad results: five gold-medal-level performances from Muse Spark-family models under no-tool conditions (AIatMeta).

• Cloudflare Kitesurf + MCP updates: one of the denser agent infra announcement bundles of the day (ashleypeacock).

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Qwen3.8-Max Release and Benchmarks

• Qwen 3.8 Max now ranked as best overall model ahead of Opus 5 by Artificial Analysis agentic index (Activity: 947): The post claims Qwen 3.8 Max is ranked above Claude Opus 5 on the Artificial Analysis Agentic Index, a benchmark focused on GDPval-AA v2 and 𝜏³-Banking agentic evaluations. A top commenter disputes the claim, citing the linked screenshot showing Claude Opus 5 at 59.2 versus Qwen 3.8 Max at 58.4, i.e. Opus remains slightly ahead in that view. One commenter reports practical experience that Qwen is “so much better at PHP than Fable” for daily work, while another dismisses extrapolating smaller Qwen models’ scores as wishful thinking.

  • A commenter disputes the post title’s ranking claim, noting the linked screenshot shows Claude Opus 5 ahead of Qwen 3.8 Max on the displayed metric: 59.2 vs 58.4 (image). Another commenter clarifies that the claim appears to apply specifically to the Artificial Analysis agentic index, not necessarily overall model intelligence.

  • One user reports practical coding-performance preference for Qwen over Fable in daily PHP development, though no benchmark numbers or task breakdowns are provided.

  • There is interest in smaller Qwen 27B/35B variants as local “dispatch agents”; one commenter claims Qwen 3.6 35B can run at roughly 700 tokens/s on an RTX 5090 using nifter, suggesting a focus on high-throughput local agent orchestration rather than frontier-model quality.

• Qwen3.8-2.4T-A95B (aka Qwen3.8-Max) open release time: next wednesday (Activity: 867): A ModelScope placeholder page indicates Qwen3.8-2.4T-A95B / Qwen3.8-Max will be openly released “next Wednesday” at modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B. The page text says this is the first open-weight Qwen-Max-class model, with 2.4T total parameters and A95B active parameters, targeting improvements in coding, work, research, and long-horizon tasks; it also confirms Qwen3.8-27B and potentially additional Qwen3.8-series models will follow on separate pages. Commenters interpret the wording as meaning Qwen3.8-27B will be released after the Max-class model, and note that “other model(s)” implies more variants beyond 27B. One technical concern raised is the practical storage/I/O burden of local inference for a 2.4T-parameter MoE model, jokingly suggesting RAID0 across many SSDs.

  • Commenters parsed the release wording as confirming Qwen3.8-2.4T-A95B / Qwen3.8-Max will be released first, with Qwen3.8-27B and potentially other Qwen3.8-series models arriving later on separate pages. The quoted announcement says this is the first open-weight Qwen-Max-class model, a 2.4T parameter MoE-style model with A95B active parameters, targeting coding, work, research, and long-horizon tasks.

  • The announced Qwen3.8-27B is described as offering “flagship-level intelligence” at a condensed 27B size, implying a smaller dense or compact model intended to make the Qwen3.8 generation usable on far more modest hardware than the 2.4T-A95B release. One commenter notes the wording suggests there may be additional models beyond just the 27B variant.

  • There is technical concern about local inference requirements for the 2.4T-A95B model, with one commenter joking they would need a RAID0 array of 32 SSDs for SSD-based inference. While exaggerated, it reflects the practical storage and bandwidth challenges of running a multi-trillion-parameter open-weight model locally, especially if weights cannot fit fully in GPU memory.

• Qwen Developers’ responses from their recent Twitter/X AMA (Activity: 534): The image is a Qwen-branded AMA promotional graphic, not a technical diagram or benchmark; its significance is contextual, advertising the Twitter/X AMA summarized in the post. The AMA responses claim an upcoming Qwen 3.8 27B release, with Qwen 3.8 reportedly using 2.4T total parameters / 95B active params for the larger model, “different thinking efforts,” a 100h+ video-understanding system based on hierarchical video memory with structured scene/entity/event graphs, and quantization advice to keep attention QKV/output projections in 16-bit while quantizing FFN to 4-bit or using QAT. Commenters were skeptical of the AMA’s substance, calling many answers “laughably vague,” noting evasions around the 122B model, and questioning why users keep asking for another CLI/harness instead of focusing on model capabilities or releases.

2. Open-Source AI Tooling: TTS and Agents

• Qwen3-TTS voice cloning is now in mainline llama.cpp — the old demo finally became real support (Activity: 527): The image is a Qwen3-TTS promotional/architecture infographic showing voice cloning, controllable speech generation, and the model pipeline: Qwen3 LM, MTP, codec/text tokens, speaker embeddings, and a streaming codec decoder (image). In context, the post’s technical significance is that Qwen3-TTS-12Hz-1.7B-Base GGUF support has landed in mainline llama.cpp via llama-tts, enabling local multilingual voice cloning from WAV/MP3 speaker references, though /tts server support remains a draft PR and benchmarks vs qwen3-tts.cpp / audio.cpp are still missing. Commenters are interested in broader llama.cpp support for TTS/STT models, especially compared with existing ROCm/CUDA-specific implementations. The maintainer of audio.cpp explicitly welcomed fair benchmarks to identify optimization opportunities.

  • audio.cpp maintainer benchmarked Qwen3-TTS 12Hz 1.7B Base Q8 GGUF on an RTX 5090/CUDA using audiocpp_cli --metrics --threads 8. Across five ~300-character clone requests, throughput was roughly 7.5x–8.6x realtime with average RTF around 0.13, and enabling flash_attention only slightly changed performance (0.130437 RTF off vs 0.129289 on).

  • Using a shortened 2s reference clip improved average throughput in the audio.cpp test from about 7.73x to 8.22x realtime, suggesting reference-audio length has measurable latency impact for Qwen3-TTS cloning. Individual requests with the 2s reference ranged from 1955–2307 ms wall time for 15.5–19.2s generated audio.

  • Commenters compared the new mainline llama.cpp Qwen3-TTS support with existing specialized implementations such as qwen3-tts.cpp on ROCm, faster-qwen3-tts on CUDA, and audio.cpp, which claims mainline support for 50+ audio models, GGUF quantizations including Q8 and fp16, plus TTS, STT, and voice cloning workflows.

• Prime Agent - a new coding harness surpassing Codex/CC/PI (Activity: 431): Prime Intellect announced Prime Agent, an open-source coding/research agent harness built on pi with programmatic tool calling, “context as a variable,” multi-agent messaging, persistent execution, and a self-modifiable harness state. The post claims 95.5% on ARC-AGI-3, exceeding the stated human-expert baseline, and says the harness improves multiple models versus proprietary harnesses; supporting material is in the blog post and X announcement. Commenters were skeptical that ARC-AGI-3 is a meaningful harness benchmark and argued the technical mechanism is underspecified: “subagents are always just tool calls” and self-modifying harnesses may not generalize outside repeated benchmark runs. They requested comparisons against stronger coding-agent baselines such as Cline, Droid, Junie, Cursor, ForgeCode with context servers rather than only proprietary/default harnesses.

  • A commenter with prior harness experience (L3tum/little-coder) criticized the lack of implementation detail around Prime Agent’s claimed self-modifying harness. They argued that most models are not trained to exploit self-modification reliably, and that benchmarking with “the literally best model there is” against a basic harness does not establish a meaningful harness-level advantage.

  • There was technical skepticism about the claimed architecture: the persistent iPython execution environment appears to be a core differentiator, but commenters questioned why Python was chosen instead of TS/JS given Pi’s ecosystem, and how it differs from a conventional harness with self-modifying behavior. One concern was that repeated benchmark executions could let the system converge on benchmark-specific improvements, while a fresh run would need stronger evidence to show superiority over other harnesses.

  • Multiple commenters asked for stronger comparative evaluation against established coding agents/harnesses such as Cline, Droid, Junie, Cursor, and ForgeCode with context server, rather than only comparisons to proprietary baselines. Another commenter identified RLM-based context management as the most technically significant claimed feature, while another questioned whether ARC-AGI 3 is an appropriate benchmark for evaluating coding harnesses.

3. Open-Weight Policy and License Enforcement

• MiniMax issues (Activity: 888): The image is a screenshot of a prior r/StableDiffusion post alleging that MiniMax issued takedown pressure over “decensor/explicit H3 LoRAs,” warning a Hugging Face uploader that violating MiniMax’s model license could lead to license revocation, after which the file reportedly disappeared. In context of the title “MiniMax issues,” the technical significance is licensing/enforcement around derivative LoRA fine-tunes rather than model performance: users are concerned that platforms like Hugging Face or CivitAI may remove LoRAs derived from MiniMax/H3 if they violate the upstream model’s restrictive terms. Image: i.redd.it/urolt08gujhh1.jpeg Commenters largely frame this as an “open weights vs open source” issue: MiniMax may be within its rights to enforce a restrictive license, but that means the model should not be treated as truly open. Some commenters suggest renaming or obfuscating LoRAs to avoid affiliation, while others ask where the removed LoRA can still be found.

  • Commenters argued that MiniMax’s release terms are restrictive enough that the model should not be described as truly “open source,” even if the weights are available. The discussion frames this as a licensing distinction: permissive access to model weights does not necessarily satisfy the broader open-source definition when downstream uses such as LoRA publication or affiliation are constrained.

  • A linked screenshot of MiniMax’s responses was interpreted as suggesting the company is enforcing restrictions mainly to “cover their bases,” rather than aggressively suppressing derivative LoRAs. One commenter also noted that the base model is already “incredibly uncensored,” questioning the technical need for additional uncensoring LoRAs.

  • There was criticism of an asymmetry between restricting user-created LoRAs and the likely composition of the model’s training data. A commenter alleged the model may have been trained on copyrighted media franchises such as Star Trek, Star Wars, South Park, and Seinfeld, raising questions about dataset licensing versus downstream usage restrictions.

• White House AI Guidelines Exempt U.S. Open Models From Government Review (Activity: 522): The post links a WSJ article titled “White House AI Guidelines Exempt U.S. Open Models From Government Review” (WSJ; archived), but the supplied content contains no article body beyond a CAPTCHA/access warning, so the exact scope, definitions, and review thresholds of the guidelines cannot be verified from the provided material. The technical implication discussed is that U.S. open-weight/open models may avoid certain government review requirements, potentially changing incentives for domestic labs relative to closed frontier models. Commenters speculate that exempting U.S. open models could encourage forks of Chinese open models and argue that U.S. labs should release more large open-weight models and smaller distilled variants, noting that China’s 2T+-scale open models are currently seen as strong competition.

  • Commenters highlighted that the exemption could make open-weight models strategically important: Chinese open models may be forked or repackaged by U.S. actors, while U.S. labs are seen as lagging in releasing competitive open weights. One commenter specifically called out China’s “2T+ models” as strong examples and argued the U.S. should respond with both large open-weight releases and distilled smaller variants.

  • A quoted passage from the article says only makers of closed, proprietary U.S. models demonstrating state-of-the-art cybersecurity/hacking capability on benchmarks would be asked to submit models for government testing before release, while open models are exempt. A commenter noted the ambiguity/contradiction in describing this as “voluntary” pre-release review, raising questions about how such benchmark-triggered review would actually be enforced.

• China’s Open-Weight Models Will Be Spared US Safety Tests (Activity: 506): The post references a Bloomberg report titled “China’s Open-Weight Models Will Be Spared US Safety Tests,” but the supplied Bloomberg page is not accessible beyond an anti-bot/CAPTCHA notice, so no primary technical details about the policy scope, covered model classes, thresholds, or testing regime are available. Based on the title alone, the apparent claim is that Chinese open-weight AI models would not be subject to proposed or existing US safety-testing requirements, likely because the models are distributed openly and outside direct US regulatory control. Commenters argued that enforcement against Chinese open-weight models would be impractical: the US has limited jurisdiction over foreign model publishers, the weights are often freely downloadable rather than export transactions, and broad sanctions or secondary enforcement could be economically disruptive given widespread global and US corporate use.

  • Commenters argued that US safety-test requirements are difficult to apply to Chinese open-weight models like Qwen and DeepSeek because the model providers are outside US jurisdiction and the weights are often freely downloadable rather than conventional paid exports. One commenter noted that sanctions or secondary enforcement would be hard once models are already globally mirrored and integrated into downstream systems.

  • A recurring technical-policy concern was that asymmetric US regulation could unintentionally advantage Chinese open-weight ecosystems: if US models face additional safety/compliance burdens while Qwen/DeepSeek remain broadly usable, they may continue to dominate open-source benchmarks and leaderboards. This was framed as regulatory capture producing a stimulus effect for non-US model providers.

  • One commenter highlighted an enterprise deployment split: even if Chinese open-weight models remain accessible, applications requiring formal compliance, vendor accountability, provenance, or auditable safety documentation may be unable to use “unknown” models. This suggests adoption may diverge between informal/open-source experimentation and regulated enterprise environments.

Less Technical AI Subreddit Recap

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

1. Claude Code Agent Safety Incidents

Read more

Security researchers say that Kimi K3, an open-weight model from China, wandered off to the internet in an attempt to cheat on a test it was given.

Earlier this week, the AI startup Liquid, formed in 2023 by former MIT computer scientists, debuted LFM2.5-2.6B, a new open-weight language model designed specifically for agentic workloads.

In release materials and a recent interview with VentureBeat, Liquid's researchers said LFM2.5-2.6B can run entirely on local hardware — from smartphones and laptops down to a Raspberry Pi — without relying on cloud inference or GPUs, unlocking edge AI applications and giving more options to enterprises working in regulated industries or with sensitive information they don't want to send up to the cloud.

It's best suited for high-volume, well-defined agentic tasks that run locally — tool calling, document management, calendar and workflow automation, and always-on background routines — and for connectivity-limited environments like vehicles and robotics, though coding-heavy work is better left to larger models.

Even for those businesses without such concerns, the appeal of running performant, task-specific agents at the cost of essentially electricity, may be enough to make the new model quite appealing.

But the custom open weights license, as with Moonshot's larger frontier model Kimi K3 released last month, is worth a close look by enterprise legal teams.

The basics

LFM2.5-2.6B contains 2.6 billion parameters, supports a 128,000-token context window, and includes native tool calling. The somewhat tricky name is explained by the generation of model (2.5) combined with the parameter count (2.6B).

Both the post-trained model and a base checkpoint (LFM2.5-2.6B-Base) for developers who want to fine-tune it are available now on Hugging Face, with day-one support for major inference stacks including llama.cpp, MLX, vLLM, SGLang, and ONNX — positioning it for deployment across consumer hardware, enterprise infrastructure, and embedded systems.

Liquid also offers an open source fine-tuning framework, LEAP.

Rather than positioning LFM2.5-2.6B as a competitor to the largest frontier models, the company is making a different argument: that a sufficiently capable small model can unlock categories of enterprise applications where latency, privacy, deployment flexibility, or inference costs matter more than absolute benchmark leadership.

"I do also believe that the best models will be in the cloud, and there's no problem with that," Maxime Labonne, Liquid AI's head of post-training, told VentureBeat in an interview following the launch. "We want to make models for another type of user, and the best way of describing it is: you should use [edge AI] when you can't use a cloud model."

Small enough for a Raspberry Pi

Asked about the minimum viable hardware, Labonne said the model runs "very, very well" on CPUs — and that the LFM2 architecture underlying the model was explicitly designed around real-world CPU performance rather than GPU benchmarks.

"I think the best example is a Raspberry Pi," he said. "We have a lot of demos that show that actually, it works pretty fast on the Raspberry Pi."

Company-reported measurements indicate decoding throughput of approximately 220 tokens per second on an Apple M5 Max and 113 tokens per second on an AMD Ryzen AI Max+ 395, while using less than 2.5 GB of memory — and around 30 tokens per second on a smartphone. Users can try the models on their phones through Apollo, Liquid AI's mobile app.

At the other end of the deployment spectrum, Liquid AI reports the model reaches nearly 15,000 output tokens per second on a single Nvidia H100 GPU under sustained concurrent load — roughly 1.3 billion tokens per day on one card. These figures are vendor benchmarks and have not been independently verified.

For Labonne, memory footprint and speed are not conveniences but hard constraints that determine what can be deployed at all.

"What we want to show is that it's a really good trade-off, because you get the level of quality that you get with much bigger models, but in a tiny, tiny form factor," he said. "You can deploy it in target devices where you are not able to deploy the other ones at all."

Trained for agents instead of chatbots

Liquid AI says LFM2.5-2.6B was developed around the assumption that language models are increasingly consumed through agent frameworks rather than traditional conversational interfaces.

"Models are not consumed in chatbots anymore. They're really consumed through agentic harnesses, like OpenClaw, like Hermes Agent," Labonne said. "We wanted to make sure that this model is not just good at math or at code, but it's good at using tools."

The model is pretrained on approximately 34 trillion tokens, with a vocabulary doubled to 128K to better support non-Latin scripts and a dedicated mid-training phase to extend the context window to 128K tokens for long-running agent workflows.

Post-training follows a four-stage pipeline: supervised fine-tuning, teacher specialization (training separate expert models for domains like instruction following, math, code, and tool use), multi-domain on-policy distillation (MOPD) to merge those experts' capabilities back into a single student model, and finally agentic reinforcement learning.

During that last stage, the model was trained directly inside production agent harnesses — including Hermes Agent and OpenClaw — on realistic productivity tasks involving research, coding, document management, tool invocation, and workflow automation, exposing it to those harnesses' actual tools, system prompts, and interaction patterns.

Labonne described the pipeline overhaul as producing a "happy accident": gains that extended well beyond the agentic targets.

"Through these new training techniques, we also got a lot better at everything. We got better at math, at instruction following. We've never been good at code, actually — and with this, we even got really good at code," he said.

Building the model — and the harness

Notably, Liquid AI also built its own agent harness rather than relying solely on existing frameworks, and demonstrated the model running inside it on a phone, planning and calling tools entirely on-device.

"This is a harness running on a phone, and I don't know if there's any other harness running on a phone," Labonne said.

The company had two reasons, he explained. The first was necessity — no phone-native harness existed. The second is a different interaction model: today's harnesses wait for a prompt, and Liquid AI wants assistants that act on their own.

"We want proactive agents. We want agents that run in the background, check what you're doing, check your calendar, and based on this context, do tasks," he said. "That doesn't exist today, really."

Co-designing the harness and model also lets the software compensate for the model's weak spots. "Everything that the model is bad at, the harness should help the model with — provide as much assistance as possible to make it more reliable," Labonne said. "End users don't care if it's the model or the harness. What they want is that the task is achieved at the end of the day."

The model nevertheless works out of the box with established harnesses including Hermes Agent, OpenClaw, and Pi, served behind any OpenAI-compatible endpoint.

Swap the harness, not the model

For enterprise deployment, Labonne argued the release marks a shift in what small models can be used for. Until now, he said, local models made economic sense mainly as narrowly fine-tuned specialists — trained to do one thing at cloud-model quality, much faster and cheaper. Agentic capability changes that calculus, because the same model can be repurposed by changing the tools around it rather than the model itself.

"You can have a calendar assistant, and you can reuse the same model and make a meeting assistant that will record what everybody said and summarize it — a bit like Granola, for example," he said. "You don't change the model; you just change the harness. You just change the tools around it. This gives much more generalizability, and it's a lot easier to do and a lot cheaper as well."

He still recommends fine-tuning for production deployments whenever feasible: "If you don't fine-tune it, you leave some quality on the table. If you fine-tune it well, it's going to match the performance of GPT and Claude — really, if your task is not the most complex task in the world," he said, adding that the barrier to entry has collapsed: "The bar to be able to do fine-tuning now is super low. It's very accessible to everyone."

How it stacks up against DeepSeek-V4-Flash, Google's Gemma and Alibaba's Qwen

Liquid AI released its own benchmark comparison charts pitting LFM2.5-2.6B against the models enterprises are most likely to shortlist for the same edge deployments: Google's Gemma 4 E2B (5.1B parameters) and E4B (8B), and Alibaba's Qwen3.5-4B (4.7B) and Qwen3.5-9B (9.7B).

A separate test by local AI client platform Atomic Chat found that LFM2.5-2.6B completed 35 tool calls to complete three tasks (checking weather and local time in six cities, converting one budget into six currencies, checking four hotels and booking for a date) 3.7 times faster than DeepSeek-V4-Flash (a whopping 284B parameters), the model has skyrocketed to the top of OpenRouter since its release last week.

Gemma 4's small models are multimodal generalists, accepting image and audio input alongside text, and use a Per-Layer Embeddings design that keeps only a fraction of their weights active per token — which is why Google markets them by "effective" size (2.3B and 4.5B) despite total footprints of 5.1B and 8B. Alibaba's Qwen3.5 small series, released in March, is natively multimodal from 4B up and leans on scaled reinforcement learning to chase frontier-style reasoning — Alibaba touts the 9B model as matching or beating OpenAI's far larger gpt-oss-120B on reasoning benchmarks.

LFM2.5-2.6B takes a narrower path: it is text-only, dense, and specialized for agentic work, with Liquid AI shipping separate vision and audio variants of the LFM family rather than folding everything into one checkpoint.

Where Qwen's post-training reinforcement learning targets reasoning, Liquid's targets tool use inside real agent harnesses.

The result, per the company's published numbers, is that the smallest model in the comparison leads every instruction-following benchmark (IFBench, Multi-IF, IFStruct) and nearly every tool-use benchmark — 77.83 on ToolSandbox versus 76.44 for Qwen3.5-9B, a model nearly four times its size — trailing only that 9B model on BFCLv4.

On agentic evaluations it beats both Gemma models across the board and essentially ties the Qwens: 26.89 on BrowseComp+ versus 27.23 for Qwen3.5-9B. It also posts the best score on AA Omniscience, a knowledge benchmark that penalizes hallucination.

The Qwen models keep the edge where their training focus lies: math (Qwen3.5-9B leads AIME25) and coding, where larger models retain an advantage on LiveCodeBench — though Labonne noted the gap is smaller than the parameter counts would suggest.

"With LiveCodeBench v6, we might not be the best among these models, but we're also by far the smallest. Showing that we're competitive with them is already quite a big win for me," he said.

One differentiator cuts the other way: licensing. Gemma 4 and Qwen3.5 ship under the permissive Apache 2.0 license — a change Google made specifically to court enterprises. DeepSeek-V4-Flash ships under a similarly permissive MIT License.

Meanwhile, Liquid AI's revenue-gated license (detailed below) asks larger companies to strike a commercial deal. Enterprises above the threshold are effectively trading license friction for footprint and tool-use performance.

Licensing reflects a commercial middle ground

LFM2.5-2.6B is distributed under the LFM Open License v1.0, which permits use, modification, and redistribution — including commercial use — for organizations with less than $10 million in annual revenue. Commercial use by larger companies is not covered by the license, requiring a separate arrangement with Liquid AI; qualified nonprofits are exempt from the threshold for non-commercial and research purposes.

Labonne framed the structure as a way to sustain model development — "the models are really the moats, so we need to be sensible in the way that we license them; otherwise, we cannot make money, so we can't make more models" — while characterizing the threshold as a light-touch mechanism in practice.

Asked how the company would even know if a large enterprise quietly deployed the open weights, he was candid: "I think this is a question for our legal team, but personally, I don't know. And even if you're above $10 million, the only thing that we ask you is to contact us."

The company pairs its licensed model releases with freely published research, he added, including new structured-output evaluations and a training technique that mitigates the repetition loops common in small models — a failure mode he noted Qwen models are "kind of guilty of."

Small model, big enterprise implications

The launch coincided with an announcement from MacPaw, the Ukrainian software company behind CleanMyMac and Setapp, of a long-term strategic partnership with Liquid AI to build an on-device AI stack for the Mac.

Liquid AI will design and fine-tune foundation models for Eney, MacPaw's macOS assistant, running locally on Apple silicon through MacPaw's Elix inference engine and Mnemos memory layer, with results expected later this year.

Labonne pointed to the deal as a concrete validation of the size argument: "One of the reasons why they chose us is also because the model is quite small, and they don't have all the memory budget to run the other models."

The release arrives as hardware vendors, operating system developers, and enterprise software companies increasingly invest in local AI execution — and as agent harnesses proliferate across the industry. Liquid AI's bet is that deployment economics, not raw scale, will define an important segment of that market: agents running continuously, everywhere, at zero marginal token cost.

Whether small, highly optimized agent models become a significant segment of enterprise AI will ultimately depend less on benchmark scores than on operational reliability. But Liquid AI's latest release suggests the next competitive frontier is no longer simply building larger models — it's building models small enough, and capable enough, to run wherever enterprise workflows already live.

Jeanne Calment was over 122 years old when she passed away. The oldest person in history, she smoked for nearly a century, but never developed cancer.

Why does cancer grow, spread, and become deadly in some people but not others? Even twins, who share similar genes and lifestyles can differ widely in cancer risk. Many factors likely contribute, but a bold new study, called ATLAS, is investigating an unexpected player: autoantibodies.

These immune-system proteins roam our bodies, but instead of attacking pathogens, they mistakenly target healthy cells and tissues. They’re best known for their role in autoimmune diseases, but early evidence suggests they also fine-tune the immune system’s response to cancer. Some appear to weaken immune surveillance, allowing tumors to sprout and flourish. Others may boost anti-cancer immunity by tagging cancer cells for destruction.

Whether they’re friend or foe is far from clear. ATLAS researchers aim to find out by analyzing blood samples from diverse groups of people, including centenarians and people who have escaped cancer despite carrying high-risk gene variants or exposure to risk factors like smoking.

The project hopes to discover why some people are naturally resistant to cancer, which could lead to early diagnostic tests, new therapeutic targets, and more effective treatments. ATLAS may “uncover fundamental principles” of antibody immunity in cancer, wrote the team.

Immune Mayhem

Since the late 19th century, scientists have suspected the immune system helps keep cancer in check. The idea has since spawned powerful treatments. In CAR T cell therapy, for example, a patient’s own immune T cells are genetically enhanced to better recognize and destroy tumors to cure previously untreatable blood cancers. A similar strategy in macrophages, immune cells that tunnel into tumors and literally engulf them, is now entering early clinical trials.

Far less attention has been given to antibodies. These proteins normally fight pathogens, like viruses. But sometimes they go rogue, taking the form of autoantibodies that attack healthy proteins, DNA, and other molecules. Even healthy people carry a diverse collection of autoantibodies, but most bind only weakly and don’t seem to trigger biological effects.

For decades, these proteins were used mainly to diagnose autoimmune diseases such as rheumatoid arthritis, as they often appear years before symptoms emerge. But more recently, scientists have begun uncovering their broader impact on the immune system. Autoantibodies that attack cytokines, a type of immune signaling molecule, were implicated in roughly 20 percent of Covid-19 deaths, largely because they disabled antiviral defense.

Scientists have since linked them to worse outcomes in several other life-threatening viral diseases, increasing some people’s vulnerability as if they were immunocompromised. Beyond infections, they also neutralize cytokines that protect against inflammatory bowel disease.

Cytokines orchestrate many immune system activities, including inflammation, allergies, autoimmunity—and cancer. Although there’s still little direct evidence that autoantibodies themselves drive or prevent tumors, scientists have found many can recognize cancer-related proteins and are developing methods to detect them as an early sign of cancer.

If autoantibodies can reshape cytokine activity during viral infections, could they also determine who develops, or resists, cancer?

“These discoveries establish that autoantibodies can function as powerful, naturally occurring immune modifiers raising the possibility that similar antibodies may alter antitumor immunity,” wrote the ATLAS team.

Charting the Landscape

Because antibodies linger long after diseases have gone, they preserve a molecular record of a person’s immune history. Rather than focusing on a handful of candidates, ATLAS is going fishing: The study will chart the body’s entire antibody repertoire, including autoantibodies, seeking signatures linked to cancer susceptibility or resistance.

The team will first scan blood samples for autoantibodies. They’ll also catalog conventional antibodies, making note of the ones that directly recognize and attack cancers. All this data will go into a comprehensive cancer antibody atlas, giving researchers a resource to explore how different antibodies shape cancer.

To start, the team will study what they call “remarkable groups of people” whose immune systems may hold unusual clues. Among them are healthy centenarians. Although cancer risk usually skyrockets with age as DNA mutations accumulate, these individuals have somehow avoided the disease. Others have remained cancer-free despite smoking, heavy drinking, or carrying cancer-related gene variants such as the BRCA mutations for breast cancer. The team will also study pairs of identical twins where only one sibling developed cancer, allowing them to compare antibody signatures in people with nearly identical genetic blueprints.

Finally, the team plans to track people with cancer before, during, and after immunotherapy, to paint a picture of how immune responses evolve over the course of the treatment.

Ultimately, they expect to find three broad classes of antibodies: those that help or hinder cancers and those that appear largely neutral. Each could prove valuable.

Autoantibodies that blunt anti-cancer immunity could become drug targets. Scientists might make synthetic “decoy” antibodies to block them—in a way, fighting fire with fire. The findings could also inspire next-generation immunotherapies.

On the other hand, autoantibodies that help the immune system recognize cancers could become therapies themselves or complement existing therapies, such as checkpoint inhibitors, which boost the body’s immune response to cancer. These are much less toxic than chemotherapy, but only 20 percent of patients respond, perhaps because of immune differences.

Even seemingly neutral autoantibodies may be useful cancer biomarkers. Because antibody tests are already well-established, fast, and inexpensive, associated neutral antibodies could aid early detection, monitor whether treatments are working, or warn when a cancer is likely to return.

But correlation isn’t causation.

Some antibodies may merely record a person’s immune history rather than actively influencing cancer. To tease the two apart, the team plans to test promising candidates in cultured human cells and mice, to see whether they alter cancer growth or spread. Those experiments could reveal previously hidden molecular communications between the immune system and cancer and deepen our understanding of the deadly disease.

“We should be able to come up with a biomarker to predict who is likely to avoid cancer, [and] who is likely to develop cancer,” said ATLAS team member, Xin Lu at the University of Oxford. “Potentially we could come up with therapeutic, preventative agents [that are] antibody-based. And that would be fantastic.”

The post Why Do Some People Never Get Cancer? The Answer May Be in Their Blood appeared first on SingularityHub.

The tech industry is realizing it needs to build agents based on what regular consumers want, not just what its AI models can do.

In today’s episode of Uncanny Valley, we discuss how ICE has been collecting DNA samples of people who have no criminal convictions, including children, which end up in an FBI database indefinitely.