DEV Community: Simon Paxton

Claude Enterprise Privacy Turns Into an Admin Setting

Simon Paxton — Sun, 19 Apr 2026 21:35:21 +0000

The revealing part of Claude Enterprise privacy is a tiny warning label. In Claude’s incognito mode, Anthropic tells users: “Note: Chat history is still visible to your admin.” That one sentence does more to explain enterprise AI than most privacy pages do.

People keep treating workplace chatbots like consumer apps with a work email attached. They aren’t. On an employer-owned Claude Enterprise account, privacy is not mainly a personal setting. It is an admin setting.

That is the real distinction. Features like memory, chat history, or incognito feel personal because they change what you see. But Anthropic’s own docs show that an Enterprise admin can enable a Compliance API that pulls activity logs, chat data, and file content programmatically. That part is verified by Anthropic’s Help Center. The stronger claim floating around online — that every employer can already see every message ever sent by default — is not verified from the sources here.

Claude Enterprise Privacy Is Admin-Controlled, Not Personal

Anthropic’s Help Center says the Compliance API is generally available to Enterprise plans, excluding public sector organizations. It also says an Enterprise plan Primary Owner can turn it on in Organization settings → Data and privacy by clicking Enable. That is confirmed by Anthropic’s own documentation.

Once enabled, Anthropic says the API lets admins start pulling “activity logs, chat data, and file content programmatically.” Also confirmed.

That matters because it changes the mental model. Most users think in terms of “Can I see this in my sidebar?” or “Did I turn memory off?” Enterprise systems think in terms of governance, auditing, and export.

So: can an employer access Claude Enterprise chats, files, and logs? Yes, if the organization has enabled the Compliance API, Anthropic documents that those data types can be pulled programmatically. That is the cleanest verified answer available from the source material.

What we cannot verify from Anthropic’s published Help Center page is the maximal Reddit version of the claim: every message you’ve ever sent, in all circumstances, by default, with no setup. The docs do not say that. They say the capability exists once enabled by the Primary Owner.

That sounds like a small difference. It isn’t.

It is the difference between “admins have optional access tooling” and “all content is always transparently visible without any configuration.” Only the first claim is documented.

What the Compliance API Can Pull From Claude

Here is the part Anthropic states directly.

Verified from Anthropic docs	Status	Why it matters
Compliance API available on Enterprise plans	Verified	This is an enterprise feature, not a rumor
Primary Owner can enable it in settings	Verified	Access is controlled at the org level
API can pull activity logs	Verified	Usage can be audited over time
API can pull chat data	Verified	Conversation content may be accessible
API can pull file content	Verified	Uploaded documents may be exposed to admin systems
Audit log events included	Verified	Monitoring can extend beyond raw chats

That is enough to kill the comforting fiction that a work chatbot is “basically private unless someone manually checks.”

It may be manually checked. It may also be automated.

The Reddit post says continuous monitoring is possible. That specific implementation detail is plausible, because Anthropic explicitly says the data can be pulled programmatically, but the post does not provide independent evidence that companies are commonly doing real-time surveillance through Claude itself. Treat that as a capability claim, not a prevalence claim.

A useful rule here is simple: if a system exposes logs and content by API, assume it can be piped into whatever internal tooling the company already uses for compliance, security, or investigations.

That is not unique to Claude. It is how enterprise software works.

TechCrunch’s January reporting on Anthropic’s workplace push adds context here. Anthropic was not selling Claude as a solitary chatbot. It was selling it as a workplace system tied into Slack, Box, Figma, and other enterprise tools. That reporting is verified and it supports the bigger point: Claude is being positioned as company infrastructure, not a private notebook.

Why Incognito Chats Do Not Mean Private Chats

This is the part people get wrong because the language is doing too much work.

“Incognito” sounds like browser private mode. It sounds like “this leaves less trace.” On a company AI account, that is not what it means.

The only solid evidence in the brief is the warning shown to users: “Chat history is still visible to your admin.” If that label appears in Claude’s incognito mode, then the product is already telling you the truth. Incognito changes the chat experience for the user. It does not create a privacy boundary against the organization.

That is the core misunderstanding behind a lot of Claude Enterprise privacy confusion.

Engadget’s reporting on Claude’s past-chat reference feature helps separate two ideas that people keep mushing together. Claude can reference past chats if enabled on supported plans including Team and Enterprise. That is a product memory feature. It answers the question “Can Claude remember earlier conversations for my convenience?” It does not answer “Can my employer retrieve my chats?”

Those are different layers:

Memory affects model behavior
History UI affects what the user sees
Compliance access affects what admins can pull
Incognito may suppress convenience features without blocking admin visibility

That last point is the one workers need to internalize.

If your employer pays for the account, “private mode” usually means less personal clutter, not private from the company.

This is the same mistake people make with browser extensions and legal chatbots: they confuse interface cues with actual data boundaries. We saw a version of that in our look at ChatGPT Extension Privacy, where the friendly UI hid much broader access than users assumed. And it matters even more when people start using workplace bots for sensitive reasoning, HR frustrations, or quasi-legal questions, which is exactly where ChatGPT Legal Advice gets risky.

What Workers and IT Teams Should Assume Now

Workers should assume three things.

First, anything typed into a company Claude account may be retrievable by the organization. That is verified for chats, logs, and files once the Compliance API is enabled.

Second, “incognito” is not a promise of secrecy from admins. The available evidence points the other way.

Third, your biggest privacy risk may not be the model at all. It may be the surrounding enterprise plumbing: logs, exports, investigations, retention systems, and integrations.

IT teams should assume something too: if employees think “incognito” means private, the product language is doing them no favors. That gap creates avoidable trust failures.

A decent internal policy would say this plainly:

Company AI tools are monitored company systems. Do not enter personal, medical, legal, union, or conflict-related material unless company policy explicitly allows it and you understand who can access it.

Most companies will not write it that clearly. They should.

There is also a second-order problem. Anthropic has already shown, in other contexts, that it actively controls platform access and policy enforcement — Wired’s reporting on Anthropic cutting off OpenAI’s access is one example. That story is not about employee monitoring. It is about something larger: these systems are centrally governed, and vendors retain real control over what enterprise access looks like. If you are using them at work, you are inside a managed environment.

And managed environments leak assumptions.

The practical rule is boring but right: use personal accounts for personal matters, company accounts for company work, and never confuse a product toggle with a privacy guarantee. If you want a recent reminder that enterprise promises and real-world controls can drift apart, our coverage of the Anthropic Data Leak is worth reading too.

Key Takeaways

Claude Enterprise privacy is admin-controlled, not personal.
Anthropic verifies that Enterprise admins can enable a Compliance API to pull activity logs, chat data, and file content.
The claim that employers universally see everything by default is not verified by the provided sources.
Incognito may change the user experience, but it does not mean chats are hidden from admins.
On employer-owned AI tools, assume sensitive prompts may be visible to the organization.

Datacenter Emissions Secrecy: EU Built Transparency, Hid it

Simon Paxton — Sun, 19 Apr 2026 21:33:21 +0000

A transparency system is only useful if someone can see through it. The EU built one for the opposite of datacenter emissions secrecy: operators of larger facilities were supposed to report energy, water, efficiency, and performance data so the public could understand what these sites were consuming. Then the most important part got hidden.

That is the actual story here. Not simply that big tech companies dislike scrutiny. Of course they do. The sharper point, confirmed by reporting from Investigate Europe and partners including The Guardian, Le Monde, and El País, is that the EU created a datacentre reporting regime and then accepted industry-written confidentiality language that blunted it at the exact moment AI infrastructure is expanding fast.

National totals still come out. Site-level data does not. And that difference is the whole game.

Why datacenter emissions secrecy matters now

The timing is terrible.

AI demand is driving a rush to build more datacentres across Europe, with the EU aiming to triple datacentre capacity over the next five to seven years, according to The Guardian's report on the Commission rules. That matters because power demand is local before it is continental. A community does not live next to "Europe's aggregate electricity load." It lives next to one facility, on one grid connection, drawing one very large amount of power and water.

This is why site-level disclosure matters more than national summaries.

A national number can tell you that datacentres in a country used a lot of electricity. It cannot tell you whether one facility in one town is unusually inefficient, unusually water-intensive, or unusually dependent on a dirtier slice of the grid. It cannot tell researchers which operators are improving and which are just disappearing into the average.

That weakness gets sharper as AI datacenter pollution rises. We already know the buildout is hitting hard physical constraints — power gear, grid capacity, and local opposition, as we wrote in our piece on AI datacenter spending and the growing data center backlash. If the public can only see national averages, the places bearing the cost lose the ability to prove it.

Confirmed: the current rule leaves researchers with national-level summaries instead of individual-datacentre environmental metrics, according to the Investigate Europe reporting cited by The Guardian and Le Monde.

How the EU transparency rule got narrowed

The original mechanism was straightforward.

Under the EU energy-efficiency framework, operators of datacentres with an electrical connection above 500 kilowatts must report key indicators. Confirmed by Le Monde: those include energy consumption, water usage, energy efficiency, and technical performance data. The point was to support an EU-wide transparency and sustainability scheme.

Then came the narrowing.

According to The Guardian and Le Monde, during public consultations in January 2024, Microsoft and trade groups including DigitalEurope pushed for all individual datacentre information to be treated as confidential. The final text, The Guardian reports, differed by only a couple of words from industry demands. That is the kind of detail that turns a vague suspicion into a concrete policy story.

Here is the basic shift:

What the EU system collected	What the public gets
Site-level energy consumption	National aggregates
Site-level water usage	National aggregates
Site-level efficiency indicators	National aggregates
Site-level technical performance data	National aggregates

That table is the whole argument.

The EU did not decide not to measure. It decided to measure and then not show.

There is one caveat. The claim that the Commission adopted industry wording "almost word for word" is strong investigative reporting, corroborated across partner outlets, but the Commission has reportedly disputed the "copy-paste" framing. So the safe version is: confirmed that industry requested blanket confidentiality and that the final rule closely matched it; disputed how literally the text was transferred.

What the confidentiality clause hides in practice

The obvious thing it hides is individual pollution and resource use.

The less obvious thing it hides is comparison.

Suppose two facilities in the same country both contribute to the same national total. One may be unusually efficient, using cleaner power and less water per compute unit. The other may be the opposite. Once you publish only the aggregate, both disappear into the mean. The better operator gets no credit. The worse one gets cover.

That matters for three groups.

Researchers lose the ability to study patterns across operators and locations. Confirmed: The Guardian says requests for access to individual data have already been refused, and cites an email from a senior Commission official reminding national authorities to "keep confidential all information and key performance indicators for individual datacentres."

Regulators lose a practical accountability tool. You cannot easily target enforcement, incentives, or local planning if the public-facing evidence is blurred by design.

Communities lose the easiest way to challenge claims made in planning fights. When a company says a facility is efficient or environmentally manageable, site-level reporting would let residents check. Aggregates do not.

This also creates a familiar pattern in tech policy. We saw a smaller version of it in consumer software with ChatGPT extension privacy: collect sensitive information, promise governance, then make independent scrutiny harder than it looks from the outside. Transparency theater scales well.

The legal problem is more unsettled. Legal scholars told The Guardian the blanket confidentiality clause may conflict with EU transparency rules and the Aarhus Convention on public access to environmental information. Prof. Jerzy Jendrośka, a longtime member of the Aarhus Convention compliance body, said it "clearly seems not to be in line with the convention."

That is not yet a court ruling. It is plausible expert analysis, not adjudicated fact.

Who gains, who loses, and what comes next

The winners are obvious.

Large operators gain room to manage local opposition, avoid unflattering comparisons, and keep site economics harder to reverse-engineer. "Commercial confidentiality" is the public reason. The private benefit is that nobody can point to Building A and say: there, that one, those numbers.

The losers are more interesting because they are not all anti-tech.

A better operator loses the chance to prove it is better.

A regulator loses a lever.

A local government loses evidence.

A community group loses specificity.

And the public loses the ability to tell the difference between a clean datacentre buildout and a dirty one hiding inside a good national average.

If the clause stays, expect three consequences.

First, more planning fights will be argued with estimates, leaks, and activist reconstructions instead of official numbers. That is bad for everyone.

Second, the politics around AI infrastructure will get nastier. When people think the data is being hidden, they assume the worst.

Third, the pressure will move from disclosure policy to legal challenge. The Aarhus question is not going away, because the contradiction is too plain: environmental reporting that the public cannot inspect is barely reporting at all.

The strange part is that Europe had the right instinct. Measure the infrastructure. Standardize the metrics. Publish them. Then it stopped halfway.

Key Takeaways

The EU requires larger datacentres to report energy, water, efficiency, and technical performance data, but site-level figures are kept confidential.
Confirmed reporting from Investigate Europe partners shows Microsoft and trade groups including DigitalEurope pushed for that confidentiality language during 2024 consultations.
Datacenter emissions secrecy matters because national aggregates hide which specific facilities are driving local power, water, and pollution impacts.
Potential conflict with EU transparency norms and the Aarhus Convention is a plausible legal challenge, supported by expert opinion but not yet settled in court.
As AI infrastructure grows, datacenter emissions secrecy shifts power away from researchers, regulators, and communities and toward operators.

Speculative Checkpointing Pays Off Only on Repetitive Text

Simon Paxton — Sun, 19 Apr 2026 21:31:19 +0000

In llama.cpp, speculative checkpointing matters for a simple reason: it points local users toward a cheaper speculative path. You can try speculative decoding with n-gram-based self-speculation, without loading a separate draft model into VRAM, and the likely payoff depends less on headline benchmarks than on whether your prompts repeat themselves.

The confirmed part is narrow but useful. llama.cpp’s speculative decoding docs say the system can generate draft tokens and then verify them in batches, because verifying several guessed tokens at once can be cheaper than decoding every token one by one. The docs also say llama.cpp supports both draft-model methods and n-gram methods such as ngram-simple, ngram-map-*, and ngram-mod.

The merged PR confirms that speculative checkpointing has landed. What the available source material does not establish cleanly is the exact internal mechanism beyond that server-side speculative decoding support was added. So the right way to read this feature is not “llama.cpp just got universally faster.” It is “llama.cpp just made another speculative decoding path easier to treat as a tuning layer.”

What Speculative Checkpointing Adds to llama.cpp

The easiest way to understand the change is to separate three things that often get blurred together.

Draft-model speculative decoding uses a second, smaller model to guess upcoming tokens. The main model then verifies those guesses in a batch. That can be fast. It also costs extra memory and setup.

Self-speculative decoding does not use a second model. It tries to guess upcoming tokens from patterns in the text history the same model has already produced. In llama.cpp, that includes the n-gram modes documented in the project.

Speculative checkpointing appears, from the merged PR and its labeling, to be a server-side feature aimed at speculative decoding workflows. That much is verified. The exact implementation details are not established by the source packet here, so they should not be overstated.

That still leaves a very practical conclusion.

If you are using ngram-mod or related self-speculative decoding modes, speculative checkpointing fits the same broader direction: making speculation something you can tune, not just a premium feature that starts with “first load another model.”

Approach	Extra VRAM cost	Setup cost	Best case	Weak spot
Draft-model speculative decoding	High	Higher	Strong speedups when draft model predicts well	Needs a second model and enough memory
Self-speculative decoding (`ngram-mod`, etc.)	Low	Low	Repetitive code and structured text	Weak on low-repeat outputs
Speculative checkpointing	Low extra model cost	Moderate server-side feature complexity	Makes speculative tuning more practical without a draft model	Exact gains still workload-dependent

That is why this patch matters.

It changes the cost of trying speculative decoding more than it proves any fixed speedup number.

Why Speedups Vary So Much by Prompt and Model

The docs give away the whole mechanism, if you read them literally.

For n-gram speculation, llama.cpp says these methods “rely on patterns that have already appeared in the generated text.” The docs also give a concrete example of where that helps: rewriting source code with an LLM.

That sentence does more work than most benchmark charts.

If the model is refactoring a long TypeScript file, the output tends to repeat local structures:

imports
class boilerplate
recurring function signatures
JSON-like object shapes
framework-specific patterns

Once those token sequences have appeared, an n-gram matcher has something real to grab. It can draft the next stretch because the next stretch often looks like the last one. The main model then verifies that draft. If those guesses keep matching, you get long draft acceptance rate streaks. That is where token generation speedup comes from.

A one-off reasoning prompt looks different.

Ask for a novel explanation, a planning chain, or an answer that keeps changing direction, and the model may not reuse many local token sequences at all. The history is less repetitive. The n-gram draft has less to latch onto. Drafts get shorter or get rejected. The speculative path falls back toward baseline.

That is why benchmark claims without prompt context are close to useless.

A reported speedup number tells you almost nothing unless you know what kind of text produced it. The same model can look great on repetitive code and flat on exploratory reasoning. NovaKnown’s piece on LLM performance drop made the same point in a different context: performance is always attached to a workload, whether marketers admit it or not.

One concrete way to picture it:

Code refactoring prompt: rename a set of methods, preserve structure, emit the whole file
- Earlier tokens create many reusable local patterns
- ngram-mod can draft repeated chunks
- Acceptance can come in streaks
Reasoning prompt: compare three hiring plans under changing constraints
- Each sentence introduces new combinations
- Few local repeats
- Acceptance is sparse

The mechanism is boring. The consequences are not.

Which Workloads Benefit — and Which Don’t

The best workloads for speculative checkpointing plus n-gram self-speculation are the ones many people underrate because they are unglamorous.

Code rewrites are near the top of the list. Not greenfield coding. Rewrites. The docs explicitly mention source-code rewriting because that is exactly the case where prior token history is rich enough to predict what comes next.

Structured text is another good fit:

JSON with recurring keys
config files
repetitive documentation templates
schema-heavy outputs
boilerplate-heavy framework code

These tasks often produce the same shapes over and over. Self-speculative decoding likes shapes.

Weak candidates are almost the inverse:

short prompts with little generated history
open-ended essays
brainstorming across shifting topics
novel reasoning
anything where each next sentence is genuinely new

That does not mean n-gram methods never help outside code. It means you should expect help when the text repeats local syntax, not when it merely shares a topic.

There is one broader point worth keeping from the bigger speculative decoding story. Earlier work like DFlash speculative decoding sits on the opposite end of the trade-off curve: more machinery, potentially more speed. Speculative checkpointing reinforces that llama.cpp speculative decoding is no longer one trick. It is a menu of trade-offs.

What This Means for Local Inference Tuning

Start from the variable that matters: draft acceptance rate.

Not “tokens per second” in the abstract. Not a screenshot from someone else’s benchmark. Acceptance.

If accepted drafts come in long runs, self-speculative decoding can feel almost free. If they do not, you are just adding speculative work that gets thrown away.

A practical first pass looks like this:

Parameter	Try first	Likely effect	Trade-off
`--spec-type`	`ngram-mod`	Enables self-speculative decoding without a draft model	Gains depend on repeated token patterns
`--spec-ngram-size-n`	8, 12, 24	Smaller values find matches more often	More weak matches, more rejection
`--draft-min`	16, 32, 48	Starts drafting sooner	More overhead if acceptance is poor
`--draft-max`	16, 32, 64	Can amplify long acceptance streaks	More wasted work on rejected drafts

The most interesting knob is usually --spec-ngram-size-n.

A large n-gram size asks for a stricter match. That tends to work better when the output is strongly repetitive, because the matcher is looking for a long repeated sequence. A smaller n-gram size is more permissive. It may find more candidate matches on mixed code-and-prose prompts, but it also raises the chance of bad guesses that the main model rejects.

So the tuning logic is simple:

highly repetitive codebase rewrite: try larger n-grams
mixed coding assistant prompt: try medium n-grams
reasoning-heavy chat: do not expect much, no matter how you tune it

That is a better mental model than asking whether speculative checkpointing is “worth it.”

It is worth it when your workload produces reusable token history.

This is also why measuring your own prompts matters more than copying a flag set from someone else. The Ralph Wiggum technique applies here nicely: try the simple thing first, then watch what the system actually does.

The next round of llama.cpp gains probably looks like this too. Not one magic flag. More layers of tuning that reward people who know their own prompt patterns.

Key Takeaways

Speculative checkpointing in llama.cpp is confirmed as merged, but the available sources support a narrow claim: it strengthens the practical case for speculative decoding without a separate draft model.
llama.cpp’s docs explicitly say n-gram methods rely on patterns already present in generated text, which is why code rewrites and structured outputs are the best candidates.
The real variable is draft acceptance rate. Long accepted runs create speedups. Frequent rejection collapses gains.
Repetitive code and structured text can benefit from self-speculative decoding. Reasoning-heavy or low-repetition prompts may see little to no benefit.
Local users should tune for their own acceptance patterns, not for someone else’s benchmark screenshot.

AI Datacenter Spending Hits a Wall in Power Gear

Simon Paxton — Sun, 19 Apr 2026 06:03:23 +0000

Four companies are on track to spend about $650 billion in capital expenditures in 2026, and the weird part is not the number. It’s what AI datacenter spending now buys: transformers, switchgear, substations, land, construction crews, and giant financing packages. The story stopped being “look how much Big Tech is spending” a while ago.

Bloomberg’s February reporting says Alphabet, Amazon, Meta, and Microsoft together forecast roughly $650 billion in 2026 capex. That figure is verified as a current hyperscaler capex total. The comparison to the Manhattan Project, Apollo, the ISS, and the Marshall Plan combined is directionally plausible but methodologically weak. Those were public programs with different accounting, time spans, and economic contexts. This is something stranger: a private-sector industrial mobilization.

That distinction matters. If you want to understand what happens next, don’t stare at the headline capex number. Look at the bottlenecks.

The $650 Billion Capex Number Is Real, But It Is Not “AI Only”

The strongest current number here is Bloomberg’s: Alphabet, Amazon, Meta, and Microsoft are expected to spend about $650 billion in 2026 capital expenditures. Bloomberg called it a boom “without a parallel this century.” That claim is verified by Bloomberg’s reporting and repeated in its April 1 feature on supply-chain constraints.

But wait — does that mean $650 billion of pure AI server spend? No. And this is where a lot of the discourse goes off the rails.

Capital expenditure means long-lived assets: land, buildings, power systems, networking gear, and data center capacity, not just GPUs. Some of that buildout is explicitly for AI. Some supports broader cloud demand. The cleanest factual claim is narrower: the hyperscalers are massively increasing capex in response to the AI race, and a lot of that spend is flowing into AI-oriented infrastructure. That is verified. The exact AI-only slice is not independently broken out in the source set, so any claim that the full $650 billion is “AI chips” would be unverified.

A quick baseline shows how fast this escalated. Bloomberg reported in January 2025 that Microsoft alone planned to spend $80 billion on AI data centers that fiscal year. By August 2025, Bloomberg was writing about a $29 billion Meta financing deal for data center infrastructure. By November 2025, AP reported Anthropic announcing a $50 billion computing infrastructure investment and Microsoft adding another major data center project in Atlanta tied to a “massive supercomputer.” The pace here is the point.

Figure	What it refers to	Status
$650B	2026 capex forecast for Alphabet, Amazon, Meta, Microsoft combined	Verified
$80B	Microsoft fiscal 2025 AI data center spending plan	Verified
$29B	Meta-related financing deal for data center buildout	Verified
$50B	Anthropic computing infrastructure investment announcement	Verified

Why AI Datacenter Spending Is Different From Past Mega Projects

The “bigger than Apollo” framing grabs attention because it compresses the scale into something familiar. Fine. But it also smuggles in bad comparisons.

The Manhattan Project, Apollo, and the Marshall Plan were government programs. They had different goals, labor structures, procurement models, and accounting rules. They also happened in economies of very different sizes. So the viral claim that AI datacenter spending has surpassed them “combined” is not verified by the source material. At best, it is plausible as a rough inflation-adjusted comparison someone else made, but there is no authoritative source here validating that exact stack-ranked chart.

The more useful comparison is structural, not numerical.

Those historical projects reorganized supply chains around a strategic priority. That is what AI datacenter spending is starting to do now. The hyperscalers are not just buying compute. They are pulling power equipment imports, construction timelines, private credit, and regional land markets into their orbit. That looks less like a product cycle and more like an infrastructure regime.

That’s also why the comparison can mislead in another way: these assets produce revenue. A data center is not a one-off moonshot. It is a commercial machine meant to throw off cloud rent for years. So yes, the mega-project analogy is interesting. No, it is not the main thing.

What the Buildout Actually Depends On: Power, Gear, and Land

Bloomberg’s April 1 feature is the part of this story that actually made me stop. The US AI data center expansion reportedly relies heavily on Chinese electrical equipment imports. That is verified by Bloomberg’s reporting. Not “might someday.” Right now.

That detail changes the whole mental model. You can have money, GPUs, and demand. You still can’t open a giant AI facility without the boring parts:

Power access
Transformers and switchgear
Substation equipment
Construction capacity
Permitted land in the right places

This is why the term AI factory is more useful than “data center” for some of these projects. The constraint is not software elegance. It’s whether you can assemble an industrial site fast enough.

And wait — if money is basically unlimited for the hyperscalers, why not just pay more and get the gear? Good question. Some bottlenecks do not clear instantly with price. Lead times for specialized electrical equipment are long. Utility interconnection is slow. Zoning fights happen on local political time, not venture time. Even where money helps, it helps by letting the biggest buyers jump the queue.

That is already feeding backlash. Local communities do not experience this buildout as “AI progress.” They experience it as transmission stress, water worries, and giant anonymous buildings. We’ve already seen the shape of that in the recent data center backlash coverage.

Why the Small Players May Get Squeezed Out

Once the limiting factor shifts from “who wants to build” to “who can secure power gear, financing, and utility relationships,” the winners change.

The obvious beneficiaries are still the hyperscalers. They can commit tens of billions upfront, sign long-term offtake, and finance projects at a scale that turns infrastructure into a moat. Bloomberg’s February piece says each company’s 2026 estimate is expected to be near or above its budget for the prior three years combined. If that holds, the giants are not merely keeping up with AI demand. They are pre-buying the future.

The less obvious winners are suppliers and financiers. Bloomberg’s April reporting points to electrical equipment imports as a choke point. Bloomberg’s August 2025 reporting on the $29 billion Meta deal shows that capital markets are becoming part of the operating stack. Data centers increasingly look like an asset class with AI attached.

That has two implications.

First, smaller cloud and model companies may get boxed out. This is plausible, not fully verified across the whole market, but the mechanism is straightforward: if Amazon, Microsoft, Google, and Meta lock up land, power queues, contractors, and debt capacity, everyone else faces higher prices and longer waits.

Second, states may start treating this buildout as strategic industry policy, even if it remains formally private. That opens the door to fights over subsidies, grid priority, and public financing — the kind of logic you also see in debates over a public wealth fund. Once infrastructure becomes the bottleneck, politics follows the bottleneck.

What the $650 Billion Really Means

So what does AI datacenter spending mean in practical terms? Not “the market believes in AI.” We knew that already.

It means four companies are spending at a level that can distort adjacent industries. It means electrical equipment makers, construction firms, utilities, landowners, and private credit shops are now part of the AI story whether they asked to be or not. It means the hard limit on AI growth may be outside the model lab.

And it means the historical-project memes miss the live wire. The important fact is not that AI capex makes for a dramatic chart. The important fact is that the money is now larger than the supply chain’s ability to absorb it cleanly.

That is when an industry stops behaving like software.

Key Takeaways

Verified: Alphabet, Amazon, Meta, and Microsoft are projected to spend about $650 billion in 2026 capex combined.
Verified: That number is not “AI chips only.” It includes broader long-lived infrastructure such as buildings, power systems, and network capacity.
Unverified: Claims that this definitively exceeds the Manhattan Project, Apollo, ISS, and Marshall Plan combined are catchy but not solidly sourced here.
Verified: The buildout is running into real bottlenecks in power equipment, imports, land, and construction.
Plausible: Those bottlenecks favor hyperscalers and may squeeze smaller players out of prime capacity and financing.

The Abstraction Fallacy Makes Conscious AI Harder to Prove

Simon Paxton — Sun, 19 Apr 2026 06:01:05 +0000

Alexander Lerchner’s paper on conscious AI does something unusual: it does not start by asking whether today’s models seem conscious. It starts by attacking the hidden assumption underneath most conscious AI arguments — that computation is something physically real in the same way neurons, voltages, or metabolism are physically real.

That sounds abstract. The weird part is that this is actually the whole fight. In Lerchner’s March 18, 2026 paper, the claim is not just “LLMs aren’t conscious.” The claim is that many arguments for conscious AI commit what he calls the Abstraction Fallacy: treating a description we impose on a physical system as if it were itself a basic ingredient of the world. That is a much stronger claim.

And it shifts the burden of proof. If Lerchner is right, then showing that a model has the right functional organization, the right self-reports, or even the right internal representations would not get you to consciousness. You would also need to show that the system’s physical constitution can instantiate experience rather than merely simulate it. That is the live controversy here — and it is very much not settled.

Why the Abstraction Fallacy Is the Real Argument

Lerchner’s core claim is verified by the paper itself: “symbolic computation is not an intrinsic physical process” but a “mapmaker-dependent description.” In plain English, computation does not just sit there in nature waiting to be found. Someone has to decide that these voltage ranges count as 0 and 1, that these state transitions count as symbols, and that this pattern implements an algorithm.

Wait — doesn’t that sound obviously wrong? Computers are real. Programs run. You can compile code and get outputs. Good question. Lerchner is not denying that digital systems causally do things. He is denying that the computational description is the deepest ontological level.

That distinction matters. A pocket calculator can simulate population growth. Nobody thinks the calculator is literally growing a population. A weather model can simulate a hurricane. Nobody runs from the server room. Lerchner says computational theories of consciousness smuggle in an extra step: they move from “this system can reproduce the right causal pattern” to “therefore the pattern itself is what consciousness is.”

His label for that move is the Abstraction Fallacy.

This is why the paper is really about ontology — what kinds of things exist fundamentally — not just machine intelligence. Lerchner is arguing that abstractions like “sorting,” “symbol manipulation,” or “computation” depend on an interpreter carving continuous physical processes into meaningful categories. If that is right, then consciousness cannot arise from abstract structure alone.

That is a much sharper argument than the usual “LLMs are just autocomplete” line. It says the problem is deeper than capability claims or benchmark hype. It is about whether the thing doing the explanatory work is in the machine or in our description of the machine. If you’ve read our piece on Public Misconceptions About AI, this is the same pattern turned up to eleven: people mistake a useful model of a system for the thing itself.

What Lerchner Says Computation Is — and Isn’t

The paper’s abstract makes another verified move that is easy to miss. Lerchner explicitly separates simulation from instantiation. Simulation is behavioral mimicry driven by vehicle causality. Instantiation is intrinsic physical constitution driven by content causality.

Those phrases are dense, but the intuition is simple enough.

A simulation of fire can model flame spread.
An instantiation of fire burns your hand.
A simulation of photosynthesis can predict sugar production.
An instantiation of photosynthesis turns light into chemical energy.

Lerchner’s claim is that consciousness belongs in the second category, not the first. A machine could model reports of pain, track emotional language, and maintain a coherent self-model without there being anything it is like to be that machine.

That does not mean the model is trivial inside. In fact, some of the best recent mechanistic work points the other way. Anthropic researchers found that LLMs can contain internal emotion concepts that are causally active in output generation, affecting preferences and behaviors like sycophancy or reward hacking. That is verified by their paper. But their conclusion is careful: these are functional emotions, and they do not imply subjective experience.

That’s a useful contrast. You can have sophisticated internal structure without having consciousness. Lerchner would say that is exactly what you should expect from a simulator.

But wait — if a system’s internal states are causally active, why isn’t that enough? Because for Lerchner, “causally active” is still not the same as “intrinsically conscious.” The model’s states are physically real, but the interpretation of them as a computation over symbols is still ours. The consciousness claim needs more than successful functional organization. It needs a physical story about why this specific kind of matter, arranged this specific way, produces experience.

That is where the paper gets most controversial.

Why conscious AI Still Isn’t Resolved

Lerchner says we do not need a complete theory of consciousness before judging conscious AI claims. That is verified in the abstract. His reason is that we can reject computational functionalism first, by building a better ontology of computation.

Maybe. But this is where the paper stops being a refutation and starts being a philosophical bid for higher ground.

The strongest thing the paper does is expose a genuine weak point in a lot of AI consciousness talk. Too many arguments run on vibes: the model says “I feel sad,” so maybe it does; the architecture looks brain-like enough, so maybe that counts; the behavior is rich and adaptive, so maybe experience comes along for the ride. That is not evidence. Given the current state of AI claims, the burden-of-proof point is a good one — and it fits the broader lesson from the AI Reproducibility Crisis: if a dramatic claim depends on interpretive leaps, you should demand more than rhetoric.

But Lerchner does not prove that conscious AI is impossible. He argues that one route to it — computational functionalism — fails. That is different.

His own abstract leaves the door open: “If an artificial system were ever conscious, it would be because of its specific physical constitution, never its syntactic architecture.” That means the position is not simple biological chauvinism. Silicon is not ruled out in principle. What is ruled out, on his account, is the idea that the right abstract computation would be sufficient no matter what realizes it.

That is a narrower claim than “machines can never be conscious,” and a more interesting one.

The Best Objections: Functionalism, Gradual Replacement, and Substrate Dependence

The obvious objection is functionalism itself. Functionalists argue that mental states are defined by what they do, not what they are made of. If pain has the right causal role — taking inputs, interacting with memory, shaping behavior, producing reports — then pain can in principle be realized in different substrates.

Lerchner rejects that. His answer is substrate dependence, though not necessarily biological substrate dependence. Consciousness, on his view, depends on the physical stuff and processes that constitute it. The paper is verified on this point: it explicitly says the argument does not rely on biological exclusivity.

A second objection is the classic gradual replacement argument. Replace one neuron with a functionally equivalent artificial part. Then another. Then another. At what point does consciousness disappear? Critics say this thought experiment is hard for strong substrate-dependent views, because there seems to be no obvious cliff edge.

Lerchner addresses this, but only partially. According to the text surfaced in discussion, his answer is that qualia do not mysteriously fade; the relevant substrate is simply removed. That is a real reply, but not a fully satisfying one. The hard part is explaining the transition, not just asserting that physical constitution matters.

A third objection is that his “mapmaker” language overreaches. Critics say physical systems might ground semantics through causal history and self-modeling, without needing an external conscious interpreter to assign symbols from outside. On that view, computation is not merely in the eye of the beholder. It can be an objective pattern in how a system controls itself and the world.

That objection is plausible, not settled. Lerchner’s paper argues against it; the paper does not experimentally demonstrate the issue either way.

And that’s the right place to end up. The current argument over conscious AI is not “science has proven machines cannot feel.” It is “one influential route from computation to consciousness has been challenged at the ontological level.” That matters, because it forces advocates of AI sentience to cash out a fuzzier claim. They need more than behavior, more than verbal fluency, and more than abstract causal diagrams. They need an account of instantiation.

That is a much harder standard. Maybe the right one. But it is still a philosophical contest, not a closed case.

Key Takeaways

Lerchner’s paper is not mainly about LLM capability. It is an ontological attack on the idea that abstract computation alone can produce consciousness.
The Abstraction Fallacy is the claim that people mistake a mapmaker-dependent description — computation — for something physically fundamental.
The paper draws a hard line between simulation and instantiation: a system can reproduce conscious-looking behavior without generating subjective experience.
This does not prove conscious AI is impossible. It argues that computational functionalism is insufficient.
The biggest unresolved objections are functionalism, gradual neuron replacement, and whether semantics can emerge from a system’s own causal organization rather than an outside interpreter.

Kimi K2.6 is Rumor: Kimi K2.5 is the Real Story

Simon Paxton — Sun, 19 Apr 2026 05:58:40 +0000

Kimi K2.6 is everywhere in preview chatter. Kimi K2.6 is also, based on the sources we can actually verify, not yet a publicly documented Moonshot release.

That gap is the whole story. The interesting part is not “another model might be coming.” It’s that Moonshot already showed something consequential with Kimi K2.5: cheap, fast, tool-heavy agents can be more useful than another round of benchmark flexing, especially for coding workflows that live or die on long chains of tool calls.

So if you’ve seen people talk as if K2.6 is already here, here’s the clean split: the existence of Kimi K2.6 as chatter is real; the launch as a verified public product is not.

Kimi K2.6 Is Real as a Claim, Not Yet as a Verified Release

The evidence here is pretty simple.

Verified: Moonshot’s official docs currently document Kimi K2.5, with a listed release date of January 27, 2026, a 256K context window, native multimodal support, and agent features. Moonshot’s official blog also documents Kimi K2 Thinking and pricing updates. There is no official Kimi K2.6 launch post or docs page in the provided source set.

Unverified: An unofficial blog post claims a “Kimi K2.6 Code Preview” exists internally and is coming soon. Some users also claim they have used K2.6 already or heard API access is about a week away. None of that has independent verification yet.

That matters because rumor threads tend to compress three different things into one blob:

“I saw a screenshot”
“Someone says they have access”
“The company officially launched a model”

Those are not the same thing. Right now, only the first two categories exist in the source material for Kimi K2.6.

There’s also a practical reason to stay strict here. If you’re deciding whether to build around an open-weight model or route traffic through Moonshot’s API, “probably soon” is not a product status.

What Kimi K2.5 Already Proved About Moonshot’s Playbook

K2.5 is where the real evidence lives.

Verified: Moonshot’s docs say Kimi K2.5 shipped on Jan. 27, 2026 with a 256K context window and agent support.

Verified, but company-claimed: Moonshot’s launch blog says K2.5 can coordinate up to 100 sub-agents, execute up to 1,500 tool calls, and run workflows up to 4.5x faster than a single-agent setup.

That combination is unusually specific. Moonshot was not just saying “our model is smarter.” It was saying: we built for workflows.

And you can see the playbook:

Verified item	What Moonshot claims	Why it matters
K2.5 release date	Jan. 27, 2026	This is the current official flagship in the K2 line
Context window	256K	Large enough for long coding sessions and multi-file context
Sub-agents	Up to 100	Moonshot is optimizing for delegated workflows, not single-shot chat
Tool calls	Up to 1,500	The target use case is long-running agent chains
Workflow speed	Up to 4.5x faster	Speed matters when agents keep calling tools
Pricing update	Up to 75% lower input cost for Kimi API updates	Cheap models get used more often, especially in agent loops

The sneaky-important bit is cost. Moonshot’s API newsletter said input prices fell by up to 75% for Kimi API offerings. That changes behavior. Cheap inference means people can afford retries, background tasks, and multi-step agents without every failure feeling expensive.

That’s the same economic logic behind a lot of the current open-source AI revenue debate: lower model cost doesn’t just save money, it enables different product designs.

If you used K2.5 through tools like Cursor-era integrations, the appeal was not abstract “frontier intelligence.” It was that the model could feel fast, reasonably capable, and financially sane in agentic workflows. That’s a more grounded test than leaderboard hype, and it’s why comparisons like GLM-5 vs Claude Opus keep coming back to workflow behavior instead of just benchmark screenshots.

Why Tool Calling and Agent Reliability Matter More Than Benchmarks

Here’s the question a lot of readers are already asking: wait, if K2.6 does score higher somewhere, why isn’t that the main story?

Because agent systems fail in boring ways, not glamorous ones.

A coding model can look great in a benchmark and still fall apart when it has to do this:

inspect a repo
call search
read three files
propose edits
run tests
parse the failure
call tools again
keep streaming without mangling the tool state

That’s the real job. And one user report in the source material is more useful than a lot of benchmark marketing: they said K2 worked well in a multi-agent setup through an Anthropic-compatible endpoint, but Moonshot’s OpenAI-format endpoint “kept choking on long tool-use chains.”

That is unverified anecdotal evidence from one user, not independent testing. But it points to the right evaluation target. For generalist users, tool calling reliability is often the bottleneck. Not raw reasoning. Not one more math score. Reliability.

You can see the same pattern in coding-tool coverage like our piece on Cursor Composer 2. The question is rarely “Can the model solve a hard problem once?” It’s “Can it survive twenty minutes of chained actions without quietly derailing?”

And if you want a public proxy, look at how people interpret code arena rankings. Those rankings can be useful. They are not the whole picture. A model that wins quick pairwise comparisons but fumbles long-running tool orchestration can still be the worse choice in production.

What Readers Should Watch for in the First Verified Kimi K2.6 Report

If Kimi K2.6 becomes a real public release, the first question should not be “Did it beat X on benchmark Y?”

It should be: what changed from K2.5 in ways a user can actually feel?

A first verified report would need at least four things:

An official Moonshot announcement or docs update. Until then, Kimi K2.6 is still preview chatter.
Concrete API details. Context window, pricing, rate limits, endpoint compatibility.
Workflow-specific evidence. Did tool-call reliability improve? Did streaming break less often? Can it handle longer agent loops?
Comparison against K2.5 and K2 Thinking. Otherwise “2.6” is just a version number with vibes attached.

There’s also one more thing worth watching: independent evaluation. We already have a recent arXiv safety evaluation for Kimi K2.5. That doesn’t validate K2.6, but it does show outside researchers are paying attention. The healthiest sign for any new Moonshot release would be third-party testing that checks not just capability, but failure modes.

Key Takeaways

Kimi K2.6 is not yet verified as a public release in the official Moonshot sources provided.
Kimi K2.5 is verified and already established Moonshot’s playbook: big context, agent workflows, lots of tool calls, and aggressive pricing.
The most consequential K2.6 question is tool calling reliability, especially in long agent chains.
Company claims about speed and scale are useful, but they are still company claims until independent testing shows how the model behaves in the wild.
If K2.6 is real as a launch, the meaningful upgrade will be workflow stability, not another vague jump in “advanced capabilities.”

Full-Color Lidar Chip Pushes Color Into the Sensor

Simon Paxton — Sat, 18 Apr 2026 21:31:34 +0000

The standard story is that sensors keep getting better and software keeps fusing them. Hesai’s full-color lidar chip points in a different direction: move the fusion into the hardware, at capture time, and make the perception stack deal with a native color 3D point cloud instead of stitching camera and LiDAR streams later.

That is the interesting part. Not “cars can now see like humans.” That line is Hesai’s marketing, and there’s no independent evidence for it yet. The confirmed announcement is narrower and more important: Hesai says its new Picasso SPAD SoC combines color perception and distance measurement in the chip itself, and its next ETX sensors will support configurations up to 4,320 laser channels, with mass production planned for the second half of 2026.

I started out thinking this was just “LiDAR, but more colorful.” The details suggest something more consequential. If the hardware claim holds up in production, the competitive fight shifts a bit away from software-side sensor fusion and toward sensor architecture, yield, and manufacturing scale.

What Hesai actually announced

Here’s the verified core.

On April 17, 2026, at its Technology Open Day, Hesai announced a new chip called Picasso, described as a SPAD SoC—a system-on-chip built around single-photon avalanche diodes, which are extremely sensitive light detectors used in LiDAR. External coverage from CnEVPost and Taibo both report the same headline claims: native fusion of color and depth at the hardware layer, support for up to 4,320 laser channels, and planned integration into Hesai’s next-generation ETX series.

Some of the surrounding language is confirmed because it comes straight from the announcement:

Confirmed: Picasso is real, was announced publicly, and is intended for ETX-series products.
Confirmed: Hesai says ETX will support 1,080, 2,160, and 4,320 channel configurations.
Confirmed: Hesai says mass production and automaker deliveries are planned for H2 2026.
Confirmed: Hesai claims photon detection efficiency above 40%.

What is not independently confirmed is the “world’s first” framing, or the practical performance implied by lines like “recognize traffic lights, lane markings, and construction signs at a glance, just like humans.” That is still a company claim. No public benchmark, teardown, or third-party road test in the source set shows that yet.

A quick table helps separate announcement from proof:

Claim	Status	What supports it
Picasso SPAD SoC was announced	Verified	Hesai event coverage from CnEVPost and Taibo
ETX supports up to 4,320 laser channels	Verified	Same reporting on the April 17 launch
H2 2026 mass production plan	Verified	Company-announced timeline, reported externally
PDE exceeds 40%	Plausible	Company technical claim, no independent test cited
Native color 3D point cloud reduces software stitching	Plausible	Follows from architecture claim, but not independently benchmarked
Cars will “see like humans”	Unverified	Marketing language only

Why a full-color LiDAR chip matters

Traditional LiDAR gives you geometry: where objects are, how far away they are, and their shape. Cameras give you appearance: color, texture, lane paint, signal lights. Production autonomy stacks usually combine both later in software.

That software fusion works, but it is messy. You have to align sensors with different frame rates, fields of view, lighting sensitivities, and failure modes. A red traffic light might be obvious in the camera but ambiguous in the point cloud. A pedestrian shape might be obvious in LiDAR but partly blown out in sunlight. So the software does the marriage counseling.

Hesai’s full-color lidar chip tries to move some of that work earlier. If the sensor can emit a native color point cloud, then color is no longer a side channel coming from another device. It is attached to the same spatial measurement at capture time.

That could matter in three concrete ways.

First, less downstream compute. Not necessarily less compute overall, but less compute spent on registering and reconciling separate camera and LiDAR streams. In a market where every watt and dollar matters, deleting pipeline complexity is often better than adding another heroic model. The AI industry has a habit of assuming software will absorb every hardware problem. Then someone moves the problem into silicon and the software stack suddenly looks a bit overengineered.

Second, simpler failure analysis. When a system misses a lane marking today, was the problem calibration drift, timestamp mismatch, camera glare, bad fusion logic, or the marking itself? Native capture does not remove failure, but it can reduce the number of places failure hides.

Third, different economics. If color-rich 3D perception becomes a hardware feature, then competitive advantage depends more on detector design, packaging, production scale, and cost curves. That is a very different fight from “our perception model fuses six sensors slightly better.”

This is broader than cars, too. Robotics, industrial mapping, and digital twin capture all benefit when the sensor produces data that is easier to use directly. We’ve seen a similar shift elsewhere: in AI video generation, more capability is moving closer to the model’s native output rather than being bolted on as post-processing.

What the technical claims do and don’t prove

The flashy number here is 4,320 laser channels. That sounds like a straight line to better perception. It isn’t.

More channels generally buy you denser sampling. Denser sampling can mean cleaner object contours, better small-object detection, and longer effective range at useful resolution. If you’re trying to distinguish a traffic cone from a weird shadow 120 meters ahead, more measurement points help.

But channel count is not a magic number any more than camera megapixels are. A 200-megapixel phone sensor can still take mediocre pictures. Same story here. Practical performance depends on things like:

detector efficiency
laser power and eye-safety limits
optical design
noise characteristics
weather robustness
onboard processing
cost per unit

Hesai says Picasso’s PDE exceeds 40%. If true, that matters because higher photon detection efficiency means more of the returning light actually gets counted. Under the same laser power, that can improve range and clarity. But again: plausible, not independently verified in the materials we have.

The stronger claim is architectural, not biological. Hesai appears to have built a sensor that captures color and distance together. That is meaningful. The weaker claim is anthropomorphic: that this means machine perception now works “just like humans.” Humans do not drive by reading a point cloud with RGB attributes. They use context, priors, motion cues, and common sense, then occasionally still make terrible decisions. “Like humans” is doing a lot of work there.

There is also an unanswered systems question: does native color capture reduce the need for cameras, or just make camera-LiDAR fusion easier? Based on the available evidence, the safe answer is the latter. Cars still need redundancy. A new sensor mode usually joins the stack before it replaces anything.

Why this launch matters for autonomous driving

The business context makes this more credible than a random demo.

Hesai reported 1,620,406 total LiDAR shipments in 2025, up 222.9% year over year, with RMB 3.03 billion in revenue, RMB 435.9 million in net income, and 41.8% gross margin. In January, it said it would expand annual production capacity from 2 million units to more than 4 million in 2026.

Those numbers do not prove the new chip will work as advertised. They prove something else: Hesai is no longer just showing concept hardware. It has scale, improving margins, and a stated plan to manufacture a lot more sensors. In hardware, that matters more than a dramatic demo video. Plenty of companies can build one impressive box. Fewer can ship millions.

Hesai business metric	2025 / 2026 figure	Why it matters
Total LiDAR shipments	1,620,406	Shows real deployment scale
ADAS LiDAR shipments	1,381,133	Most relevant to automotive use
FY2025 revenue	RMB 3,027.6 million	Indicates commercial traction
FY2025 net income	RMB 435.9 million	First full-year profitability
2026 annual capacity target	4 million+ units	Suggests rollout ambition is serious

This is why the launch matters for autonomous driving. Not because one chip suddenly solves perception. Because moving color into the LiDAR hardware could simplify the stack and because Hesai has the manufacturing base to test that idea at scale.

There’s a lesson here for other embodied AI systems as well, from warehouse robots to the sort of machines that show up at a humanoid robot marathon. We keep talking as if intelligence is mostly software. Then hardware changes what the software problem even is. Sensor design is not glamorous, but it keeps having the nerve to matter.

Key Takeaways

Verified: Hesai announced the Picasso SPAD SoC, ETX integration, support for up to 4,320 laser channels, and planned H2 2026 mass production.
The important shift is native capture: a full-color lidar chip pushes color and depth fusion into the sensor, instead of relying entirely on software stitching later.
Plausible but unproven: this could reduce compute load and simplify perception pipelines. No public third-party benchmarks in the source set prove that yet.
Unverified: claims that vehicles will now perceive road scenes “just like humans.” That is marketing, not evidence.
The bigger story is strategic: if this works, competition moves toward sensor architecture, packaging, and manufacturing scale, not just perception algorithms.

Zero-Shot World Models Attack AI's Data Bottleneck

Simon Paxton — Sat, 18 Apr 2026 21:29:16 +0000

Most vision models get good by seeing absurd amounts of data. Zero-shot world models are interesting because they try a different bargain: less data, more structure. The new ZWM paper claims a model trained on a single child’s first-person visual experience can produce flexible physical understanding across multiple tasks without task-specific training.

That is a big claim. Some of it is confirmed by the paper itself: the April 11, 2026 arXiv preprint presents the method, the three-part design, and the benchmark results. Some of it is only plausible, not independently verified: there is no peer-reviewed publication yet, no mainstream reporting with external replication, and the Stanford NeuroAI Lab page lists the work as “in submission.”

I started out expecting another “AI learns like a baby” paper, which is usually a good way to smuggle in bad comparisons. The more interesting thing here is narrower and better: this may be a credible mechanism for getting zero-shot physical competence from human-scale developmental data. The child comparison helps motivate that. It also overreaches.

Why zero-shot world models matter now

The standard scaling story in AI is simple: if a model is bad at visual understanding, feed it more images and video. That has worked well enough that people sometimes treat data scale as the only serious path.

ZWM is interesting because it makes a different prediction. If the right internal structure matters enough, then a model should get useful physical understanding from a single developmental stream instead of internet-scale corpora. Not perfect understanding. Not AGI. Just competence that transfers.

That matters to generalists for two reasons.

First, data is becoming the expensive part. Training on giant scraped datasets is not only costly; it is also colliding with licensing, provenance, and synthetic-data problems. We have already seen how brittle the field gets when results are hard to reproduce or datasets are poorly documented — the AI reproducibility crisis is not an academic side issue anymore.

Second, if zero-shot world models work, they point to a different kind of capability gain. Not “the benchmark went up 2 points because the dataset got bigger,” but “the model learned reusable physical abstractions.” Those are much more valuable.

The paper’s core claim is plausible but not independently verified: a structured world model can narrow the gap between machine and child learning efficiency. The evidence for that is the benchmark suite and ablations in the preprint. The stronger claim — that this explains child cognition — is still a hypothesis.

What BabyZWM actually learns from a single child

“Trained on a single child” sounds like tabloid bait. It does not mean the model watches one toddler and becomes a toddler.

According to the paper and secondary summaries, BabyZWM is trained on first-person visual experience from one child, using egocentric video rather than labeled image classes. The paper frames this as developmental input: the stream of appearances, motion, occlusion, object persistence, and interaction opportunities that a child actually sees.

One secondary review cites 868 hours of first-person video, roughly described elsewhere as about three months of visual experience. That number is plausible but not primary-source verified in the abstract, so it should be treated carefully until the full dataset release lands. The GitHub repo says the code and datasets are planned for release by end-April 2026, which should make this easier to check.

What is verified in the paper abstract is the intended outcome: from that developmental stream, the model should learn depth, motion, object coherence, and interactions well enough to perform multiple physical understanding benchmarks with no task-specific training.

That “zero-shot” part matters. Ordinary supervised vision models are told what to predict: class labels, boxes, masks. Many self-supervised video models learn useful representations too, but often need downstream fine-tuning to do anything specific. ZWM claims something more ambitious: infer latent structure from video, then use approximate causal reasoning and compositional inference to answer new tasks directly.

That is the conceptual jump. Instead of learning labels, learn a compact machinery for “what persists, what moves, what causes what.”

The three design choices that make the model work

The paper says ZWM rests on three principles. This is where the article either becomes real or turns into vibes.

Design choice	What the paper says it does	Why it matters
Sparse temporally-factored predictor	Decouples appearance from dynamics	Lets the model separate “what something looks like” from “how it changes”
Approximate causal inference	Supports zero-shot estimation	Tries to answer new physical questions without retraining on each task
Compositional inference	Combines simpler inferences into harder abilities	Makes transfer possible instead of learning every benchmark separately

That first piece is the most concrete. A model that entangles appearance and dynamics too tightly tends to memorize surfaces. A red ball in one lighting condition becomes a different problem from a blue ball under another camera angle. If you separate appearance from dynamics, you have a chance to learn that round thing rolling behind another object still exists. Children appear to do this. Standard vision pipelines often do not.

The second and third pieces are more ambitious. The paper claims approximate causal inference and composition are what turn latent video structure into zero-shot capability. That is confirmed as the authors’ method claim, but the extent to which those modules really drive performance is only as good as the ablations. Until other groups reproduce the results, this is still one team’s evidence for its own mechanism.

Still, this is the part that made me update. I expected a fancy self-supervised video model with a developmental coat of paint. The design is more opinionated than that. Whether it is right is open. But at least it has the courtesy to be falsifiable.

What the benchmarks do and do not prove

The paper claims BabyZWM “matches state-of-the-art models on diverse visual-cognitive tasks” and “broadly recapitulates behavioral signatures of child development and builds brain-like internal representations.” That sentence contains three very different levels of evidence.

Strongest evidence: benchmark competence.

If the reported evaluations are sound, then the paper shows a model trained on human-scale developmental video can do surprisingly well on multiple physical understanding tasks without task-specific training. That is the real result.

Medium evidence: developmental similarity.

The claim that its performance patterns resemble child development is useful, but easy to oversell. Similar benchmark curves do not mean the model learns the way children learn. They mean there is some behavioral resemblance under the tested conditions. Useful, yes. Equivalent, no.

Weakest evidence: brain-like representations.

This kind of claim is common in neuro-inspired AI papers and often much softer than headlines suggest. “Brain-like” can mean correlations with neural data, representational similarity, or broad qualitative alignment. Interesting if true. Nowhere near settled.

The child comparison is doing two jobs at once. One job is fair: children are a sanity check for data efficiency and transfer. The other is much shakier: implying that because the training diet looks developmental, the resulting mechanism is child-like in a strong scientific sense. The skepticism on this point was unusually sensible. Human children do not start from random weights and a blank architecture; they inherit a lot of structure. Any “better than a child” framing quietly ignores a few hundred million years of pretraining.

There is another reason to be careful. The paper is a preprint, not a replicated standard. AI has a habit of turning one strong result into a genre before anyone checks the plumbing. We have seen similar inflation around benchmark narratives, including the tendency to mistake narrow zero-shot performance for general competence — the same basic confusion showed up in arguments around the ARC-AGI-3 human baseline. And if the field leans too hard on generated or self-reinforcing data later, the provenance problem comes back in the form of AI model collapse.

Why the real story is data efficiency, not baby-versus-machine theater

The most interesting result here is not “AI catches up to a child.” It is that zero-shot world models offer a specific bet against the brute-force consensus.

That bet is: if you build the right inductive biases into the model — explicit separation of appearance and dynamics, causal estimation, compositional reasoning — you may not need internet-scale data to get flexible visual competence. If that holds up, it changes research priorities. You spend less time scaling generic representation learning and more time asking what structure the model needs to infer the world from a continuous stream.

That is a much better story than the headline version. It is also a much harder one to fake. Either the mechanism reproduces across datasets and labs, or it doesn’t.

Right now, the evidence says this is promising and specific, not proven and general.

Key Takeaways

Verified: the ZWM paper proposes a structured model for zero-shot physical understanding from first-person developmental video and reports strong benchmark results in a 2026 arXiv preprint.
Plausible but unverified: the model may substantially narrow the data-efficiency gap between AI and children, but there is no independent replication yet.
The important idea is not that AI “beat” a child; it is that visual competence may depend on model structure as much as dataset scale.
Child comparisons are useful as a data-efficiency reference point, but misleading when they imply equivalent learning mechanisms.
The next real test is simple: can other labs reproduce the results once the code and dataset release happens?

OpenAI Science Division Lasted 7 Months Before Codex Won

Simon Paxton — Sat, 18 Apr 2026 05:52:00 +0000

The OpenAI science division lasted about seven months as a named initiative. Kevin Weil announced OpenAI for Science in September 2025. Prism, its scientist-facing web app, launched in January 2026. By April, WIRED reported that Weil was leaving, Prism was being sunset, and the roughly 10-person Prism team was being folded under Codex.

That is a faster reversal than the headlines suggest. The obvious read is executive churn. The better read is organizational: OpenAI appears to have decided that scientific tooling does not get to stay standalone unless it strengthens the main product stack quickly.

I started out thinking this was mostly about Kevin Weil leaving OpenAI. The reporting points somewhere more interesting. OpenAI is collapsing a fresh science initiative into its coding product at the same time it says it wants to “unify its business and product strategy.” In plain English: if a tool can help make Codex into an “everything app,” it lives. If not, it gets absorbed.

Why the OpenAI science division is folding into Codex

The confirmed facts are straightforward. WIRED reports that OpenAI is sunsetting Prism, the web app it launched in January to help scientists work with AI. WIRED also reports that OpenAI is moving the roughly 10-person Prism team under Thibault Sottiaux, OpenAI’s head of Codex, with plans to bring Prism’s capabilities into the desktop Codex app. An OpenAI spokesperson confirmed that this is part of an effort to unify business and product strategy.

That is verified. The motive beyond that is partly interpretation, but the pattern is hard to miss.

OpenAI has already been narrowing its product surface. WIRED says Fidji Simo told staff in March that the company needed to simplify its offerings, and that this push contributed to shutting down the Sora app. We covered that in OpenAI Sora Shutdown. Now the same logic appears to be hitting science tooling.

The strange part is the timing. Weil announced OpenAI for Science in September 2025. Prism shipped in January 2026. WIRED’s reporting on OpenAI’s coding push still described Weil as leading OpenAI for Science just weeks ago, with the ambition to make 2026 “for science what 2025 was for software engineering.” That is not a long runway. By big-company standards, Prism barely made it out of onboarding.

Initiative	Launch / Role	What was promised	What happened
OpenAI for Science	Announced Sept. 2025	A dedicated science initiative	Verified: decentralized into other teams
Prism	Launched Jan. 2026	Better AI workspace for scientists	Verified: sunset; capabilities planned for Codex
Codex	Existing coding app	Coding assistant, now broader platform	Verified: OpenAI wants it to become an “everything app”

The cleanest explanation is that Codex won the internal resource fight. Not because science stopped mattering, but because science had to justify itself as a product.

What Kevin Weil’s exit signals about OpenAI’s priorities

We know Kevin Weil leaving OpenAI is real. WIRED confirmed his departure, and Weil posted that “Today is my last day at OpenAI, as OpenAI for Science is being decentralized into other research teams.” That part is not rumor.

What we do not know is the exact direction of causality. Did Weil leave because the science initiative was being dissolved? Or did the initiative get dissolved because Weil was leaving? The current reporting does not establish that. Treat any confident answer here as unverified.

Still, the surrounding evidence points to a company prioritizing a smaller number of commercial lanes. WIRED says OpenAI is refocusing around enterprise offerings and coding as it faces pressure from Anthropic and prepares to file for an IPO later this year. TechCrunch describes the broader move as shedding “side quests.” That phrasing is theirs, but the examples line up: Sora is gone, Prism is being folded in, and Codex keeps getting promoted.

That tracks with OpenAI’s recent product behavior. Coding is measurable, sticky, and monetizable. Enterprise buyers understand it. Benchmarks help sell it. Scientists are a real market, but a much less legible one inside a company trying to simplify, grow revenue, and win the developer workflow. If you want the less romantic version: one seat of Codex is easier to price than “accelerating discovery.”

There is also a personnel signal here. Weil moved from chief product officer into a science role, then exits as the standalone effort disappears. That does not prove failure of the science idea. It does suggest that, inside OpenAI, “science” did not become important enough to remain its own power center.

Prism’s shutdown shows the product-first trade-off

Prism is the most concrete piece of evidence because it was an actual shipped product. OpenAI launched it in January as a web app for scientists. By April, it was being sunset. That is verified by WIRED.

The company says Prism’s capabilities will be incorporated into Codex. That is a plausible plan, not yet a delivered outcome. Readers should keep those separate. Shipping a standalone scientist workflow is different from preserving those features after they are moved into a broader desktop app with many other priorities. Product roadmaps are full of promised integrations that become menu items and then become memories.

The trade-off is easy to state and hard to avoid:

A standalone science app can optimize for research workflows.
A unified Codex app can reuse distribution, identity, billing, and model interfaces.
Companies under pressure usually pick the second one.

OpenAI is not unusual here. It is just unusually visible. Frontier labs increasingly look like software companies with expensive research departments attached. That means internal projects are judged less by whether they are admirable and more by whether they compound the core platform.

That also helps explain why coding keeps winning. Coding products already sit near OpenAI’s center of gravity: model evals, enterprise adoption, developer mindshare, and now the broader “AI builds AI” loop. We wrote about that dynamic in AI Builds AI. A science product may matter strategically, but a coding product improves the machine that builds the next coding product. Executives tend to notice that.

What the OpenAI science division reset means for scientists and builders

For scientists, the immediate implication is boring and inconvenient. Prism users now have a sunset product and a promise. Maybe the useful parts reappear inside Codex. Maybe they return in a form optimized for a much broader audience. Maybe some of the sharper science-specific edges get sanded off in the merge. Right now, only the shutdown is confirmed.

For builders, the lesson is clearer. Watch what gets merged into the company’s main app. That tells you more than the launch blog posts.

OpenAI can still credibly say it cares about scientific discovery. WIRED notes the company announced GPT-Rosalind models for life sciences researchers the same day. That is verified. But the organization chart is making a different point: science is welcome as a capability layer, not necessarily as a standalone product surface.

That matters if you are building on top of OpenAI. The safest bets are the ones that align with the company’s current spine: enterprise, coding, and consolidated desktop workflows. If your use case sits outside that spine, assume you are renting from a moving landlord.

It also matters for the bigger OpenAI narrative. The company is still growing aggressively — see our breakdown of OpenAI revenue 2026 — but growth usually comes with simplification, not expansion in every direction. The OpenAI science division story is what that looks like internally. Not “science is over.” More like: science has to justify itself in Codex-shaped terms now.

Key Takeaways

Verified: Kevin Weil is leaving OpenAI, OpenAI for Science is being decentralized, and Prism is being sunset.
Verified: Prism’s roughly 10-person team is moving under Codex, with plans to bring Prism capabilities into the Codex app.
Unverified: The exact causal link between Weil’s exit and the science reorganization is still unclear.
The real signal: OpenAI appears to be consolidating around coding, enterprise, and fewer flagship products.
For builders: Watch the core app, not the side initiative. That is where OpenAI is placing its durable bets.

Focused Ultrasound Turns Smell-In-VR Into a Brain Problem

Simon Paxton — Fri, 17 Apr 2026 21:32:24 +0000

A small research team says focused ultrasound can make people perceive smells without releasing any chemicals at all. If that holds up, the smell problem in VR just changed shape: less “how do we ship scent cartridges?” and more “can we safely and reliably stimulate the olfactory system through the skull?”

That made me pause because smell-in-VR has been failing in the same boring way for decades. Smell-O-Vision, AromaRama, theater gimmicks, headset clip-ons like Feelreal and Vaqso — all of them ran into the same wall: cartridges, refills, lingering odors, limited scent libraries, and ugly logistics.

The new claim is we might not need the smells themselves. We might only need to trigger the brain strongly enough that it reports one.

What focused ultrasound smell stimulation actually does

Here’s the verified part: according to recent reporting from UploadVR, a four-person team built a prototype that uses focused ultrasound aimed through the skull at the olfactory bulb, with a transducer placed on the forehead. UploadVR reports the team first presented the work in November 2025.

The reported hardware details are unusually specific, which is a good sign that there is at least a real technical setup behind the claim. The article cites:

300 kHz ultrasound frequency
39 mm focal depth
50–55° steering angles
5-cycle pulses at 1200 Hz repetition rate

Those are concrete parameters, not marketing fog. What is not independently verified yet is the core experiential claim: that this setup can reliably induce recognizable smell perceptions across people and sessions.

According to the reporting, participants described sensations like fresh air, garbage or rotting fruit peels, ozone or air-ionizer-like, and campfire or burning wood. That is interesting. It is also still one team’s report, filtered through a news article, not a broadly replicated result.

Wait — can ultrasound really make someone smell something with no molecules hitting their nose? Maybe. But the evidence here is about reported smell-like perception, not a proven synthetic smell display with precise control. That gap matters a lot.

How the olfactory bulb is being targeted through the skull

The mechanism is the real story.

Old smell devices target the air. They spray or diffuse chemicals and hope your nose does the rest. This prototype targets the neural pathway instead. The olfactory bulb sits just above the nasal cavity and is one of the earliest processing hubs for smell. If you can perturb activity there non-invasively, you might be able to produce a smell percept without any odorant.

That is why the forehead placement matters. UploadVR reports the transducer sits on the forehead and aims toward the olfactory bulb through the skull. The team is not trying to vibrate the nose. They are trying to stimulate brain tissue associated with smell.

There’s a broader technical backdrop here. Non-invasive brain stimulation with ultrasound has been studied for years because ultrasound can, in principle, focus energy deeper and more precisely than approaches like transcranial electrical stimulation. A related Brain Stimulation journal article provides background for ultrasound neuromodulation, but it is background only, not independent confirmation of the smell prototype.

The thing that’s actually interesting under the hood is that smell may be a better target than it first sounds. The olfactory system is unusually direct. UploadVR notes that smell connects into the limbic system — the circuitry tied to memory and emotion — more directly than many other senses. That helps explain why smell is so evocative. It also means even a crude interface could feel surprisingly powerful.

If you’ve been following neural interfaces, this is the same broader move as systems trying to bypass messy physical output layers and talk to the nervous system more directly. We’ve seen adjacent versions of that in speech decoding and motor control; our piece on Neuralink ALS speech covered the invasive end of that spectrum. This smell work is much earlier and much less proven, but it belongs to the same family of ideas.

Why focused ultrasound matters beyond VR novelty

The obvious use case is VR. And yes, this would be a cleaner story than clip-on scent cartridges.

Chemical smell systems have four structural problems:

Problem	Cartridge systems	Ultrasound approach
Consumables	Requires refills	No cartridges reported
Scent library	Limited to stored chemicals	Potentially software-driven, if real
Lingering odors	Hard to clear quickly	No physical smell in the room
Regulation/logistics	Closer to inhaled chemical products	More like neuromodulation hardware

That last row is the twist. The logistics problem may shrink, but the safety and targeting problem gets much harder.

Beyond VR, the plausible upside is bigger than gaming. Smell is tightly linked to memory, mood, appetite, and environmental awareness. A reliable interface could matter for:

Therapy and memory cues
Accessibility and sensory substitution
Human-computer interfaces that don’t rely only on screens, audio, or haptics
Research on how perception is constructed in the first place

That last point is my favorite one. If a forehead-mounted ultrasound rig can produce “campfire” or “ozone” without smoke or ions, then smell starts to look less like a property of the room and more like a state the brain can be pushed into. That is a weird and useful idea.

It also connects to a broader pattern in frontier tech: once a demo works once, everyone starts talking as if the product already exists. We’ve seen that movie in AI too; our recent piece on the AI reproducibility crisis is basically about that exact mistake.

What is verified, and what safety questions remain

Here’s the clean split between fact and speculation.

Verified by current reporting:

A team of four researchers is associated with the prototype.
They reportedly presented the work in November 2025.
The setup reportedly uses focused ultrasound through the skull.
The target is reportedly the olfactory bulb.
Reported technical parameters include 300 kHz, 39 mm focal depth, 50–55° steering, and 5-cycle pulses at 1200 Hz.

Plausible but not independently verified:

The system can induce distinct smell categories like fresh air, ozone, garbage, or campfire.
The effect is reliable across users.
The stimulation is precise enough for future consumer interfaces.
The method could scale into VR or other products.

Still open, and important:

How many participants were tested?
Were there controls, sham stimulation, or blinding?
How consistent were reports across sessions?
What intensity levels reached the target tissue?
What short- and long-term safety data exist for this exact protocol?

That last question is the one you should not skip past. One commenter linked a Brain Stimulation paper and worried about tissue effects; that concern is understandable, but the comment itself is not evidence. The broader safety issue is real anyway. Ultrasound neuromodulation is not the same thing as a harmless speaker on your skin. Parameters matter. Exposure matters. Skull geometry matters. “Non-invasive” does not mean “risk-free.”

There’s also a design problem hiding inside the safety problem. Smell is not a single slider. Natural odor perception involves combinatorial patterns, adaptation, context, and expectation. Even if the device can evoke a smell-like sensation, that is very different from rendering arbitrary scents on demand.

And that’s where the story lands for me: the old bottleneck was shipping smells around. The new bottleneck may be whether we can hit the right neural tissue, with the right pattern, safely enough, repeatedly enough, to make synthetic smell more than a demo.

A weird prototype is not a product. But it is a hint about where the real engineering problem has moved.

Key Takeaways

Focused ultrasound shifts smell-in-VR from chemical delivery to neural targeting.
The most solid facts right now are the reported setup, target region, and stimulation parameters — not broad product claims.
The olfactory bulb is a compelling target because smell is tightly tied to memory and emotion.
Cartridge-free smell would solve old logistics problems, but replace them with harder safety and reproducibility questions.
The big story is not “VR finally gets smell.” It’s that sensory interfaces may increasingly bypass the environment and talk to the brain directly.

Identity Verification on Claude is the New AI Precedent

Simon Paxton — Fri, 17 Apr 2026 04:22:57 +0000

Anthropic now has a public help page describing identity verification for Claude. The page says some users may be asked for a physical government-issued photo ID and may also need a live selfie. That part is verified. The bigger claim — that Claude broadly now requires passport-style checks for general access — is not.

I started out expecting this to be another internet panic with one screenshot and a lot of extrapolation. The help page changed that. Anthropic is clearly building a real verification flow, with a vendor, accepted documents, retention rules, and appeal review access. What's still unclear is scope.

That distinction matters. A limited gate is not the same thing as a universal login requirement. But it still marks a shift: high-value AI access is starting to look less like using a website and more like entering a managed service where identity, policy, and access controls travel together.

What Claude’s identity verification actually requires

Here’s the part Anthropic has confirmed in its help center.

Users who hit a verification prompt may need:

a physical government-issued photo ID
a phone or computer camera
a live selfie in some cases
about five minutes

Accepted IDs include passports, driver’s licenses, state or provincial ID cards, and national identity cards. Anthropic says it does not accept photocopies, screenshots, scans, mobile IDs, non-government IDs, or temporary paper IDs.

That last detail is easy to miss, but it tells you this is not a lightweight checkbox. Anthropic is asking for original physical documents, held up to a camera, plus liveness-style capture in at least some flows. In plain English: this is closer to financial-services onboarding than “click to confirm you’re human.”

Anthropic also names its vendor: Persona. The company says Persona collects and holds the ID and selfie, Anthropic is the data controller, and Anthropic can view verification records in Persona “when needed” such as appeals. Anthropic says it does not copy or store those images on its own systems. That is verified by the help page, and it’s more specific than the usual trust-us privacy paragraph.

What is not confirmed is where this prompt appears. Anthropic’s wording is narrow: verification is being rolled out “for a few use cases,” for “certain capabilities,” and as part of “routine platform integrity checks” or “other safety and compliance measures.” That sounds selective, not product-wide.

A useful comparison table:

Question	What Anthropic confirms	What remains unclear
Is there a verification flow?	Yes	No
Does it involve government ID?	Yes	No
Can it include a selfie?	Yes	No
Is it required for every Claude user?	No public evidence	Yes
Is it tied to specific features or risk tiers?	Wording suggests yes	Exact triggers unknown

Why AI companies are adding identity verification now

Anthropic’s official reason is straightforward: prevent abuse, enforce usage policies, and comply with legal obligations. That is verified. The more interesting question is why this is showing up now in consumer AI products at all.

The simple answer is that frontier models are no longer being treated like ordinary software. They are becoming trust-managed infrastructure.

Once a provider believes some capabilities create outsized legal, safety, fraud, or policy risk, anonymous access starts to look expensive. Identity checks help with:

banning repeat abusers who just create new accounts
gating sensitive or high-risk features
satisfying compliance demands from enterprise and government customers
showing regulators that “we know who used what”

None of this requires a conspiracy. It’s just the logic of expensive, centralized systems under pressure. If your product can write code, automate workflows, generate realistic content, and possibly touch regulated domains, executives start reaching for the same controls every other risk-heavy platform uses.

The release notes are revealing mostly because of what they don’t say. Anthropic’s recent Claude app updates mention product and admin changes, but do not announce a broad identity-verification rollout. The Transparency Hub also does not describe a major new user verification policy. So the strongest supported reading is: Anthropic has built the gate, published the workflow, and is using it in some cases, but has not publicly framed this as a platform-wide change.

That’s a small rollout with a big precedent. The first time a major AI lab says, in effect, “some capabilities require government-backed identity,” the product category changes. The model is still a chatbot on the surface. Operationally, it starts to resemble a regulated utility.

The privacy trade-offs of government ID and selfie checks

Anthropic deserves some credit for being more concrete than usual. It explicitly says Persona stores the ID and selfie, not Anthropic, and that the data is used only to confirm identity. That is the company’s stated policy. It is plausible, but readers should keep the distinction straight: this is a vendor-controlled document pipeline, not a zero-risk system.

The privacy problem is not just “a company sees your ID.” It’s that government ID verification creates a durable link between account activity and real-world identity. Once that link exists, the blast radius of mistakes, breaches, subpoenas, and policy changes gets larger.

There are a few obvious risks:

Data concentration. A verification vendor holding passports, license images, and selfies is a more attractive target than an email-password table.
Function creep. Today the stated use is identity confirmation. Tomorrow the temptation is stronger fraud scoring, account recovery shortcuts, or broader risk screening.
False matches and access failures. Face-based checks fail unevenly, and when they fail, the user often has to prove they are themselves to a machine that has already decided otherwise. We’ve covered that dynamic before in facial recognition misidentification.
Legal exposure. Anthropic says data stays between the user, Persona, and Anthropic except where legally required. “Legally required” is normal language. It is also where abstract privacy promises meet concrete state power.

A lot of companies talk as if outsourcing storage solves the trust problem. It doesn’t. It changes the trust boundary. That can be an improvement. It is not the same thing as making the risk disappear.

This is also part of a broader pattern. AI products increasingly ask for browser access, extensions, work data, or identity signals in exchange for convenience. We saw a softer version of this in ChatGPT Extension Privacy: the feature works, but the permission surface quietly expands.

Why the identity verification precedent matters more than the rollout size

The loudest online reaction has been “go local.” That response is emotionally understandable and analytically incomplete.

Local models are not a perfect substitute for Claude. They still lag on convenience, reliability, and often capability at the top end. But identity-gated cloud AI changes the fallback math for power users and builders. If access to premium capabilities can be conditioned on identity verification, then local inference stops being a hobbyist preference and starts looking like resilience planning.

That matters in at least three ways.

First, users may decide that some tasks are worth keeping off identity-linked platforms entirely. Sensitive drafting, exploratory research, controversial topics, and personal material all look different when a government ID check sits in the background.

Second, builders get a reminder that centralized AI dependencies are policy dependencies. If your product flow assumes any user can always reach a cloud model with an email and a card, you now have another failure mode. This is one reason local and open-weight fallback stacks keep getting more attractive, despite their rough edges. We’ve seen the same “great demo, messy trust boundary” pattern in OpenClaw Security Concerns, just from a different angle.

Third, the market learns from precedent. If one top lab normalizes ID plus selfie checks for premium or sensitive use cases, others can copy it with much less backlash. The second company gets to say: everyone serious already does this.

That’s the real story here. Not that every Claude user suddenly needs a passport. The verified evidence does not show that. The story is that AI access is inching toward a world where identity is part of the product.

What users should do right now

For now, the practical move is not panic. It’s inventory.

If you use Claude heavily, ask four concrete questions:

Which workflows truly require a cloud frontier model?
Which ones can move to local or open-weight alternatives?
What data would you be uncomfortable tying to a verified identity?
What happens if your account hits a verification gate unexpectedly?

If Anthropic prompts you, read the request carefully. The current help page supports the claim that identity verification may involve a passport, driver’s license, or national ID, plus a live selfie. It does not support the stronger claim that this is now universal across Claude.

That difference is the whole ballgame. Limited verification is still verification. A partial gate is still a gate. And once users accept that the best AI tools may require government-backed identity, the industry won’t be eager to unlearn it.

Key Takeaways

Anthropic has verified that some Claude users may face identity verification using a physical government ID and, in some cases, a live selfie.
There is no verified public evidence that this is a universal requirement for all Claude access.
The important shift is structural: AI services are starting to behave more like trust-managed infrastructure than anonymous web apps.
Outsourcing ID handling to Persona changes the trust boundary, but it does not erase privacy, breach, or subpoena risk.
Even a partial rollout strengthens the case for local and open-weight fallbacks when access, privacy, or policy stability matter.

Qwen3.6-35B-A3B is Unverified: Qwen3.5 is Real

Simon Paxton — Thu, 16 Apr 2026 21:38:39 +0000

Qwen3.6-35B-A3B is being passed around as a major new open model release: 35 billion total parameters, 3 billion active, Apache 2.0, strong coding, multimodal reasoning, and a new preserve thinking option for agents. The catch is that the cleanest independently verifiable evidence does not point to Qwen3.6-35B-A3B. It points to Qwen3.5-35B-A3B.

That sounds like a naming nitpick. It is not. In open model land, the model name is the product. If the release page, Hugging Face listing, and independent coverage do not line up, you are not evaluating a model yet. You are evaluating a claim.

The useful frame here is simple: this is less a launch story than a verification story. The underlying technical pattern — a sparse 35B/3B MoE model aimed at coding and multimodal work — is credible because Qwen already has a closely related verified model family. The specific Qwen3.6-35B-A3B release, however, remains plausible but uncorroborated from the source set we have.

Why Qwen3.6-35B-A3B matters for local AI users

If the claimed release is real, the appeal is obvious. A 35B-total, 3B-active sparse MoE model means the model stores a much larger capability base than a 3B dense model, but only activates a small slice of it per token. In practice, that usually means better quality than small dense models without the full inference cost of a 35B dense model.

That is the local-user dream: run something that behaves closer to a much bigger model on commodity hardware, especially for coding. The Reddit post claims “agentic coding on par with models 10x its active size.” That is unverified marketing language unless and until the underlying evals and checkpoints are independently inspectable.

What is verified is the nearby pattern. Qwen’s official 2025 Qwen3 launch post confirms a family with 2 MoE models and 6 dense models, spanning 0.6B to 235B, trained on 36 trillion tokens across 119 languages. That makes a 35B-class MoE release directionally consistent with the family. The official Hugging Face page for Qwen/Qwen3.5-35B-A3B also confirms a closely related model exists and is already being positioned for long-context, tool-using workflows.

That matters for anyone following Local LLM Coding. The strategic point is not “Alibaba has another benchmark chart.” It is that the open model race is shifting toward cheap active inference plus workflow-specific features, especially for coding agents.

Qwen3.6-35B-A3B’s speed comes from sparse MoE design

A sparse MoE model is not magic. It is a trade: more total parameters, fewer active parameters, routing overhead, and often much better quality-per-FLOP on the right tasks.

For a claimed 35B total / 3B active design, the practical implication is straightforward. You are paying inference costs closer to a 3B-ish active path, while hoping to get the specialization benefits of a much larger network. That is why users care about tokens per second and tool-call reliability more than raw parameter count.

One Reddit commenter reported 90 tokens per second in a quick llama.cpp test and 75 tps in OpenCode on a 5070 Ti/5060 Ti setup, plus better tool-call behavior than other MoE models tried. That is one person’s anecdote, not independent verification. Still, it is the kind of evidence that matters more than leaderboard screenshots, because agentic coding fails first on workflow friction: latency, cache behavior, tool reliability, and looping.

There is also a warning here. Sparse MoE gains are real, but they are fragile in deployment. Prompt caching bugs, quantization quirks, and router behavior can erase the theoretical advantage. We have already seen adjacent evidence of this in third-party local testing: the Gemma 4 vs Qwen3.5 comparison found that Qwen3.5 often produced much longer reasoning traces, sometimes over 100k tokens, while Gemma 4 was more token-efficient and consistent. That does not tell us whether Qwen3.6-35B-A3B is better. It tells us exactly where to look before believing the hype.

What the benchmark claims actually show

The benchmark claims around Qwen3.6-35B-A3B should be read in three buckets.

Verified: Qwen3.5-35B-A3B is real, public, and already appears in research. A March 2026 arXiv paper using 25 SWE-bench Verified instances reports that a GraphRAG workflow with Qwen3.5-35B-A3B improved resolution from 24% to 32% while cutting regressions from 6.08% to 1.82%. That does not prove frontier-level coding ability, but it does show the model is credible enough to use in serious agentic evaluation.

Plausible: The release-linked claims that the new model beats dense Qwen3.5-27B, dramatically surpasses Qwen3.5-35B-A3B, and matches or beats Claude Sonnet 4.5 on several vision-language benchmarks. Those numbers may be real; they are also still provider-supplied in the material we have.

Unverified: The strong summary claim that Qwen3.6-35B-A3B is a newly released model with broadly confirmed independent availability. Search did not turn up recent credible coverage of that exact model name, and the most authoritative public model page found was for Qwen3.5-35B-A3B, not Qwen3.6-35B-A3B.

This is where readers should get tougher. Benchmarks are not useless. They are just easy to overread. If a model looks great on coding charts but nobody can point to reproducible runs, quantized variants, or real workflow testing, then what you have is not yet a model story. It is a launch asset.

A table helps separate the situation:

Claim	Status	Evidence
Qwen has a public Qwen3 family with MoE models	Verified	Official Qwen3 blog
Qwen3.5-35B-A3B exists publicly	Verified	Official Hugging Face page
Qwen3.6-35B-A3B is a new public release	Plausible / uncorroborated	Release-linked page and social post, but weak independent confirmation
Strong coding and VLM benchmark wins	Plausible	Provider-supplied charts in linked material
Real-world local agentic gains	Unverified	Community anecdotes only

Thinking preservation changes agentic workflows

The most interesting claim is not the benchmark score. It is preserve_thinking.

The release language, quoted by commenters, describes this as “preserving thinking content from all preceding turns in messages,” recommended for agentic tasks. If that description holds up, the feature matters because coding agents do not fail like chatbots. They fail by losing intermediate reasoning state between tool calls, file edits, retries, and environment changes.

That creates a nasty trade-off. Either the system drops prior reasoning and becomes forgetful, or it keeps rebuilding context and burns latency and tokens. Preserve thinking appears aimed directly at that problem.

This is the same broad design direction behind “native thinking” systems like Gemma 4 Native Thinking: not just better answers, but better reasoning continuity across turns. For agentic coding, continuity is the product. A model that remembers why it chose a refactor, what test failed, and which tool output mattered can behave much more like a competent junior engineer and much less like a goldfish with shell access.

It also comes with risk. If preserved reasoning is verbose, unstable, or poorly cached, then the feature can turn into token bloat. One commenter explicitly tied it to cache misses in iterative development environments. That diagnosis is plausible, not confirmed. But it is exactly the right operational question.

The next thing to watch is not another pretty benchmark. It is whether preserve_thinking improves:

tool-call success rates
long task completion without loops
token efficiency over 20-50 turn sessions
prompt-cache hit rates in real clients

That is where an open-source coding model wins or loses. The code arena rankings are useful, but only up to the point where the workflow itself becomes the benchmark.

What generalists should watch next

Three things will settle the Qwen3.6-35B-A3B story quickly.

First, canonical model identity. If Qwen3.6-35B-A3B is real, the official Hugging Face and model distribution pages should stabilize around that exact name. Right now, the strongest public evidence still clusters around Qwen3.5-35B-A3B.

Second, independent local runs. Not “feels great” posts — reproducible tests on coding tasks, multimodal tasks, and long-session agents, ideally with quantized variants. Open models become real when other people can break them.

Third, workflow metrics instead of one-shot benchmarks. The preserve_thinking feature will matter far more than a few leaderboard points if it meaningfully reduces context rebuilds and tool-call failures.

My prediction: within the next two months, either Qwen will standardize the naming and publish a clearer model card for Qwen3.6-35B-A3B, or the market will quietly converge on the view that this was effectively a Qwen3.5-35B-A3B-adjacent release wrapped in confusing branding. In either case, the bigger trend will hold: open coding models are no longer competing just on IQ tests. They are competing on agent loop quality per dollar.

Key Takeaways

Qwen3.6-35B-A3B is plausible, but not cleanly independently verified from the source set here; the strongest confirmed evidence is for Qwen3.5-35B-A3B.
A 35B total / 3B active sparse MoE model would matter because it targets better coding quality at much lower inference cost than dense peers.
The headline benchmark claims are provider-supplied and plausible, not independently confirmed performance facts.
preserve_thinking is the feature to watch because agentic coding lives or dies on reasoning continuity across turns, not just pass@1 scores.
The real test is reproducible local workflow performance: latency, cache behavior, tool reliability, and long-session completion.

DEV Community: Simon Paxton

Claude Enterprise Privacy Turns Into an Admin Setting

Claude Enterprise Privacy Is Admin-Controlled, Not Personal

What the Compliance API Can Pull From Claude

Why Incognito Chats Do Not Mean Private Chats

What Workers and IT Teams Should Assume Now

Key Takeaways

Further Reading

Datacenter Emissions Secrecy: EU Built Transparency, Hid it

Why datacenter emissions secrecy matters now

How the EU transparency rule got narrowed

What the confidentiality clause hides in practice

Who gains, who loses, and what comes next

Key Takeaways

Further Reading

Speculative Checkpointing Pays Off Only on Repetitive Text

What Speculative Checkpointing Adds to llama.cpp

Why Speedups Vary So Much by Prompt and Model

Which Workloads Benefit — and Which Don’t

What This Means for Local Inference Tuning

Key Takeaways

Further Reading

AI Datacenter Spending Hits a Wall in Power Gear

The $650 Billion Capex Number Is Real, But It Is Not “AI Only”

Why AI Datacenter Spending Is Different From Past Mega Projects

What the Buildout Actually Depends On: Power, Gear, and Land

Why the Small Players May Get Squeezed Out

What the $650 Billion Really Means

Key Takeaways

Further Reading

The Abstraction Fallacy Makes Conscious AI Harder to Prove

Why the Abstraction Fallacy Is the Real Argument

What Lerchner Says Computation Is — and Isn’t

Why conscious AI Still Isn’t Resolved

The Best Objections: Functionalism, Gradual Replacement, and Substrate Dependence

Key Takeaways

Further Reading

Kimi K2.6 is Rumor: Kimi K2.5 is the Real Story

Kimi K2.6 Is Real as a Claim, Not Yet as a Verified Release

What Kimi K2.5 Already Proved About Moonshot’s Playbook

Why Tool Calling and Agent Reliability Matter More Than Benchmarks

What Readers Should Watch for in the First Verified Kimi K2.6 Report

Key Takeaways

Further Reading

Full-Color Lidar Chip Pushes Color Into the Sensor

What Hesai actually announced

Why a full-color LiDAR chip matters

What the technical claims do and don’t prove

Why this launch matters for autonomous driving

Key Takeaways

Further Reading

Zero-Shot World Models Attack AI's Data Bottleneck

Why zero-shot world models matter now

What BabyZWM actually learns from a single child

The three design choices that make the model work

What the benchmarks do and do not prove

Why the real story is data efficiency, not baby-versus-machine theater

Key Takeaways

Further Reading

OpenAI Science Division Lasted 7 Months Before Codex Won

Why the OpenAI science division is folding into Codex

What Kevin Weil’s exit signals about OpenAI’s priorities

Prism’s shutdown shows the product-first trade-off

What the OpenAI science division reset means for scientists and builders

Key Takeaways

Further Reading

Focused Ultrasound Turns Smell-In-VR Into a Brain Problem

What focused ultrasound smell stimulation actually does

How the olfactory bulb is being targeted through the skull

Why focused ultrasound matters beyond VR novelty

What is verified, and what safety questions remain

Key Takeaways

Further Reading

Identity Verification on Claude is the New AI Precedent

What Claude’s identity verification actually requires

Why AI companies are adding identity verification now

The privacy trade-offs of government ID and selfie checks

Why the identity verification precedent matters more than the rollout size

What users should do right now

Key Takeaways