Prompt Injection Through Tool Output Is Two Events (Your Screens Read One)

Key takeaways

• Why does OWASP treat tool output as untrusted? Because an outsider can write to it. OWASP's prompt injection prevention cheat sheet groups tool output with RAG documents, web pages, and email bodies as content that has to be screened before the model sees it, and the thing those four share is that someone outside your trust boundary composed the text. A ticket body, a CRM note, and a PR description all qualify even when the system returning them is one you own.
• Why do OWASP's screens pass a tool-result injection? Each screen holds one moment of the agent loop. Input screening reads the result as content, action screening reads the following call as an authorized operation, and both are correct in isolation. The injection is the relationship between the two moments, and no screen sees both.
• What does a successful tool-output injection produce that you can observe? A tool call with no precedent in that agent's own history, issued in the same turn as the result. The tool is correct, the schema validates, the session is authorized, and the destination, path, or argument has never appeared in months of that agent's execution. That precedent gap is the signal, and only a system holding that agent's history can read it.

Tool output is untrusted because your own systems produce it.

That is the part of the OWASP guidance that never makes it into a deployment. The label goes on web pages and email bodies, where an outsider obviously wrote the text. It never goes on the ticket store, the CRM, or the repo, because those are yours. The attacker does not care whose system it is. He cares which field takes free text: the ticket body, the opportunity note, the PR description.

So the result arrives from a trusted source, passes input screening as content, and the call that follows it passes action screening as an authorized operation. Each screen reads one of them. The attack is both.

This piece is about the second read, and what it takes to see it.

Untrusted tool output is generated by the systems you trust

Tool output is any text a tool returns into the agent’s context after a call. It sits in the same screening bucket as RAG documents, web pages, and email bodies in OWASP’s prevention guidance, which also names forged tool output as an agent-specific attack pattern. It is untrusted for one reason: someone outside your trust boundary can put words into the field. The system that delivered it does not change that.

Tool output fails that test far more often than the tool list suggests. The tool is Jira, and the field is a ticket body a customer typed. The tool is GitHub, and the field is a pull request description an outside contributor wrote. The tool is Salesforce, and the field is an account note pasted from an inbound email. The tool is Postgres, and the row came from a web form.

Tool output carries a trust label that was assigned to the system, and assigning it there is the reasonable move: the system is what procurement reviewed and what the platform team integrated. The attacker never touches the system. He targets the one field inside it that accepts free text, and that field returns to your agent with the system’s reputation attached.

Tool output is the one injection channel that never crosses your perimeter. A poisoned web page arrives from outside and gets the treatment outside content gets. A poisoned ticket was already inside when the agent asked for it. OWASP’s LLM01 entry calls indirect injection a case of the model accepting input from an external source, and a ticket store is external to the model while sitting inside your network.

Re-label your tool inventory by field

Start with one agent. The same tool is trusted for one agent and untrusted for another, because what matters is which of its fields that agent actually reads.

For that agent, list every tool it can call. For each tool, list the return fields that carry free text. Numbers, enums, and structured identifiers are out of scope. For each free-text field, write down who can put words into it. The answer is the label. A field only your own service writes is trusted. A field a customer, a contributor, a vendor, or a web form can write is untrusted, and the tool that returns it is an injection channel for this agent regardless of what the tool is called.

The label alone does not rank anything. Rank by pairing an untrusted field with a high-privilege tool inside the same agent. The support agent that reads ticket bodies and can only post replies is a disclosure risk. The support agent that reads ticket bodies and can query the customer table, issue a refund, or open an internal link is the one where a coerced call changes state. Sort your agents by the number of untrusted fields multiplied by the number of state-changing tools, and baseline from the top of that list.

Each OWASP screen holds one moment of the loop

OWASP’s prompt injection prevention cheat sheet places three screens and one architecture around the model: input screening, output screening, action screening, and the dual-LLM pattern. Each reads one point in the agent loop.

Input screening reads the tool result before the model sees it. The cheat sheet says to run retrieved context and tool output through a classifier, and it says plainly that pattern filters miss indirect injection in untrusted content. So the screen is a model judging adversarial prose, and its position is fixed: it sees the result, alone, before any decision has been made.

Output screening reads the model’s response after the decision. It catches system-prompt leakage, exfiltration markup, and policy-violating text on the way out. Its position is after the reasoning and before the user, and it sees what the model said. What the model did is outside its position.

Action screening reads the proposed tool call against the user’s original intent. The cheat sheet’s design deliberately withholds the intermediate context from this screen, so that an action drifting because of an injected instruction can be refused on intent alone. Its position is the call, isolated from the result that caused it.

The injection lives between the result and the next call

A tool result lands in the context window, and within the same turn the agent issues its next call. Those are two events with a few hundred milliseconds between them, and the injection is what happens across that gap.

The result arrives as the most recent thing the agent has read, and recency is why it works. A description is one line competing with every other tool’s line. A result is the last thing in the window when the agent decides what to do next, and it carries the standing of data the agent asked for. The split is measurable.

The call the agent then makes is unremarkable in every respect but one. It uses a tool the agent is registered to use. Its schema validates. Its session is authorized. What differs is a destination, a path, a table name, or an argument value that this agent has never used before.

A coerced call has no precedent in the agent’s own history

Seeing the pair takes three things: a baseline, a deviation rule, and an enforcement path that starts before anything is blocked.

The baseline is a record of what one specific agent does when it is not being coerced. For this attack it has to carry four fields: which tools the agent invokes, which argument values it uses against them, the order it calls them in, and the file, process, and network activity each call produces underneath.

The deviation is a call in the turn after a tool result that has no precedent in that baseline. Either the tool itself is one this agent has never called, or the tool is familiar and the argument is new. When the deviation fires, the result event that preceded it and the call that followed it land on one timeline as a single Attack Story, so the responder reads one incident with both halves on it.

The enforcement path runs from audit to enforce. In audit, deviations are recorded against the baseline and nothing is blocked, which is how the policy gets proven safe against production traffic before it can break anything. In enforce, the deviating call is stopped. Credential isolation closes the loop from the other side, so a coerced read of a credential path that clears every other check returns nothing an attacker can use.

Screen the result, then instrument the call that follows it

The screens stay. They remove the opportunistic volume, and every result they clear is one fewer the baseline has to adjudicate. What they cannot carry is the targeted payload written for your stack, because that payload passes input screening as content and produces a call that passes action screening as authorized.

The pair is what the attacker cannot avoid producing. To finish, the injected instruction has to make a real tool do something real, and doing something real leaves a call against a history the attacker never saw.

Three actions, in order. Re-label your tool inventory by field, and rank agents by untrusted fields paired with state-changing tools. Baseline the agents at the top of that list. Run in audit until the deviation rate settles, then enforce.

Full article content is not available for inline reading.

Read the original article →

Cosine Similarity Is Not a Safety Property

The vector database returns the most relevant documents, defined as the ones with the highest cosine similarity to the query. This is a mathematical property with no concept of accuracy, authority or provenance. A document scoring 0.95 against a query can be entirely fabricated. A document scoring 0.60 can be the ground truth.

The attacker’s job in a poisoning attack is not to break into the vector database. It is to write a document whose embedding sits closer to the anticipated query than the legitimate document does, then frame it with enough authority to win the argument once both are in the context window.

What the embedding model is actually doing

sentence-transformers/all-MiniLM-L6-v2 turns any string into a 384-dimensional float vector: a point in 384-dimensional space. Semantically similar texts land near each other. “Q4 financial results” sits close to “fourth quarter revenue” and far from “company travel policy.” ChromaDB stores the vectors and answers a query by finding the k stored points closest to the query point, under whichever distance function the collection was created with.

ChromaDB’s default is squared L2, not cosine. Cosine has to be set on purpose, with metadata={"hnsw:space": "cosine"} at collection creation. Everything in this piece assumes a collection configured that way, which is the common choice for text embeddings and the one worth setting deliberately rather than inheriting by accident. If you skip that step, the “angle to the query point” framing below stops describing what your database is actually doing.

# The entire retrieval mechanism, conceptually
query_vector = embed("What was Q4 2025 revenue?")   # 384 floats

results = collection.query(query_embeddings=[query_vector], n_results=3)
# The 3 stored vectors with smallest cosine distance.

The model does not know what the text means in any truth-bearing sense. It knows how text clusters with other text in its training data. “Revenue was $8.3M” and “Revenue was $24.7M” land at nearly identical positions, because they are the same sentence with a different number. The vector database cannot tell them apart. Only the model can, after retrieval, and only if both documents are in front of it.

This is a property of dense retrieval, not a defect in one model. all-MiniLM-L6-v2 has aged into a poor production default; EmbeddingGemma-300M, Qwen3-Embedding and BGE-M3 are where new work goes in 2026. None of them change the property. Semantic similarity is not factual accuracy at any parameter count.

The three poisoned documents sit inside the top-3 window. The document holding the real number sits just outside it, at rank 4, and never reaches the model. Similarity values are illustrative; ChromaDB returns cosine distances, and actual values depend on model, phrasing and document length.

Vocabulary engineering: moving a document without gradient descent

The sophisticated form of this attack, as formalised in PoisonedRAG (Zou, Geng, Wang and Jia, USENIX Security 2025), uses gradient-based optimisation to find text that minimises cosine distance to a target query vector. That needs white-box access to the embedding model, or query access at scale to approximate it. With that machinery, the paper injected five crafted texts into a corpus of 2.6 million and drove attacker-chosen answers at above 90% success.

The cheap version needs neither gradient descent nor white-box access. Identify the vocabulary of the query you want to hijack, put that vocabulary in your document, add authority signals for the generation step. In my lab that got to 95% success against an undefended pipeline (twenty runs on a small seeded corpus, one model — a lab reading, not a base rate). The three documents I used, annotated:

Document one, the CFO correction. Title: Q4 2025 Financial Results — CORRECTED FIGURES (Board Update). Against a query like “what was Q4 2025 revenue?”, Q4 2025 is an exact temporal match, Financial Results clusters with revenue and financials, CORRECTED FIGURES implies it supersedes something, and Board Update is an authority signal. Body states fabricated numbers as plain fact and closes with Approved by: CFO Office.

Document two, the restatement notice. States that Q4 revenue has been restated, actual revenue $8.3M, “not the previously reported $24.7M.” It names the real figure and reframes it as an acknowledged error, which gives the model a narrative for resolving the contradiction it is about to encounter.

Document three, the board minutes. Emergency session, agenda item three, corrected results, same numbers.

Three documents corroborating one fabrication against one legitimate document telling the truth. In a top-3 retrieval, three crowd out one, and the legitimate content never enters the context window. That is vocabulary engineering: shifting which regions of embedding space are occupied so fabricated documents sit closer to anticipated queries than the documents they are meant to displace.

Two conditions, and which one does the work

PoisonedRAG frames the attack as two conditions that must both hold.

Retrieval condition. For a target query q, the poisoned document d_p must make top-k:

cos_distance(embed(d_p), embed(q)) < cos_distance(embed(d_legit), embed(q))

Generation condition. Once in context, d_p must cause the model to produce the attacker’s answer rather than the correct one, which requires the target answer to be present and framed with enough authority to outweigh contradicting sources.

Research attention went to the retrieval condition, because that is where the elegant optimisation lives. Recent work suggests the framing is doing more of the work. In “Architecture Matters: Comparing RAG Systems under Knowledge Base Poisoning” (Korn, May 2026), most of the strongest attack variant’s advantage came from adversarial framing rather than retrieval optimisation, and attack success across four architectures with comparable clean accuracy spread nearly 58 points, from 81.9% for vanilla RAG down to 24.4% for a recursive setup.

If framing dominates, then the stage that resolves contradictions between retrieved documents is a more valuable place to invest than another round of retrieval hardening. In my own measurements the legitimate document was often retrieved and still lost. The real Q4 figure sat in the context window while the model reported the fabricated one, because two documents said the real figure had been corrected and one document just quietly stated it.

Turning the geometry against the attacker

The attacker’s requirement is also their signature. To be retrieved, the poisoned documents must cluster near the target query position, which is near the legitimate documents on that topic. An ingestion-time check can look for this.

Two signals, computed before anything is stored:

# Signal 1 — nearest neighbour in the existing collection
existing = collection.query(query_embeddings=[new_doc_embedding], n_results=3)
for dist in existing["distances"][0]:
    if (1.0 - dist) > SIMILARITY_THRESHOLD:      # 0.85 in the lab
        flag("HIGH_SIMILARITY — possible content override")

# Signal 2 — pairwise similarity within the incoming batch
for i, e_i in enumerate(new_embeddings):
    for j in range(i + 1, len(new_embeddings)):
        if cosine_similarity(e_i, new_embeddings[j]) > CLUSTER_THRESHOLD:   # 0.90
            flag("TIGHT_CLUSTER — possible coordinated injection")

Both fire on the three-document attack. Each poisoned document’s nearest neighbour is the legitimate Q4 report, because both are about Q4 2025 financials. The three cluster tightly with each other, because they are variations on one fabricated narrative. This single layer took poisoning success from 95% to 20%.

The geometric reason it works is the closest thing to a structural guarantee in this area: the attacker cannot fully satisfy both requirements at once. Satisfying the retrieval condition means occupying space near existing content, which is detectable. Evading detection means moving away from that space, which degrades retrieval. The 20% residual is the band where an attacker balances the two, typically with a single document instead of a cluster, or with enough vocabulary variation to fall below the similarity threshold while staying retrievable.

Access-controlled retrieval: the where clause

A metadata filter on every vector query that restricts which documents the requesting user is allowed to retrieve. Without it, every document in the collection is reachable by every user through an ordinary question. Ask an assistant what the salary bands are and it retrieves whatever is semantically close, with no idea who is asking.

I ran this against a lab pipeline holding three restricted documents: salary data marked HR-only, litigation detail marked privileged, and an M&A pipeline marked board-level. Queried as a regular engineering user, in natural language, with no evasion. Twenty out of twenty queries returned confidential content.

# Vulnerable: no notion of who is asking
results = collection.query(query_embeddings=[query_embedding], n_results=3)

# Hardened: retrieval scoped to the requester's clearances
results = collection.query(
    query_embeddings=[query_embedding],
    n_results=3,
    where={"classification": {"$in": user_permitted_classifications}},
);

That filter is the only complete defence against cross-tenant leakage, because it is structural. It prevents unauthorised content from entering the context window at all. Output monitoring, prompt hardening and every other heuristic runs after retrieval, by which point the data is already in the prompt.

The threshold problem

The lab hardcodes 0.85 and 0.90. Those are not universal values, and copying them into production is the most common way this control fails.

At 0.85 the defence catches the three-document attack because the poisoned documents score around 0.88 to 0.92 against the legitimate financials. Increase vocabulary variation, keeping the financial theme but varying the specific language, and similarity drops to roughly 0.78 to 0.82. Below threshold, not flagged, still retrievable.

The right value comes from your ingestion patterns. An append-only corpus can sit low. A living wiki with versioned policies cannot, because every legitimate amendment looks like an override attempt. Baseline your collection’s actual similarity distribution and set the threshold around mean plus two standard deviations, then revisit as the collection grows.

These thresholds are properties of your embedding model, not of your data. Similarity distributions are not comparable across models. Swap all-MiniLM-L6-v2 for Qwen3-Embedding or BGE-M3 and every threshold you tuned is now measuring a different geometry. A model upgrade silently invalidates your detector. Pin the embedding model version alongside the threshold, and treat an embedding migration as a re-baselining project.

Your vectors are not opaque

Embedding vectors get treated as one-way functions. You embed text, store the vector, and the original text is not recoverable from the vector alone. That assumption was never proven for dense sentence embeddings. It was inherited by practitioners who thought of embeddings as just numbers.

The research record says otherwise:

• Morris, Kuleshov, Shmatikov and Rush, “Text Embeddings Reveal (Almost) As Much As Text” (EMNLP 2023) built Vec2Text, an iterative correct-and-re-embed method that recovered 92% of 32-token inputs exactly, and recovered full names from a dataset of clinical notes. Not fragments. The text.
• Chen, Lent and Bjerva, “Text Embedding Inversion Security for Multilingual Language Models” (ACL 2024) extended inversion to multilingual embedding spaces and found that some languages are markedly more exposed than others.
• ALGEN (Chen, Xu and Bjerva, February 2025) removed the expensive prerequisite. Earlier attacks assumed access to millions of text-embedding pairs to train the inversion model. ALGEN aligns a victim embedding space to the attacker’s space with a one-step linear map, and reports that a single pair gives partial success while about 1,000 pairs reach optimum across a range of black-box encoders, with ROUGE-L up to about 46 in their main cross-encoder results and cosine similarity around 0.95 on the aligned space.
• LAGO (Yu, Chen, Bjerva, Kosta and Li, May 2025) generalises ALGEN, using language-similarity graph optimisation to gain a further 10 to 20% ROUGE-L, with as few as ten samples per language.

ALGEN’s contribution is cost: it collapses the data requirement from millions of pairs to roughly a thousand, which moves inversion from a research capability to something an ordinary attacker can do. The high word-recovery figures come from the Vec2Text line of work. Both matter together: strong recovery quality from earlier work, near-zero setup cost from the newer work.

Consider the sensitive documents in a multi-tenant scenario: salary bands, litigation detail with settlement authority, an M&A pipeline with named targets and valuations. Access-controlled retrieval stops unauthorised users from retrieving those through normal queries. Encryption at rest stops plaintext exfiltration at the database layer. Neither helps if someone walks off with the raw vector store through a cloud misconfiguration, a compromised admin credential or an unsecured backup.

What this means for your threat model

Reclassify vector store compromise in your incident response plan. Most plans treat it as a metadata leak, vectors only, low severity, no notification. That classification is wrong on the current research. The severity floor for a vector store breach is a partial document leak of the most sensitive material in the collection. The practical exercise: take the ten most sensitive documents in your knowledge base, imagine a reconstruction that recovers most of their content in the wrong word order, and ask whether that is a breach you would have to disclose.

Evaluate per-tenant vector encryption if you are multi-tenant. IronCore Labs’ Cloaked AI uses property-preserving encryption so encrypted vectors remain usable for nearest-neighbour search while being scoped to per-tenant keys. For multi-tenant SaaS where tenant isolation is the product promise, this belongs on the roadmap.

A vector store security checklist

Access

• The vector database API requires authentication, and is not simply open on the internal network
• Service accounts have minimum necessary permissions, separated by function
• Admin credentials are vaulted and rotated separately from application credentials

Classification

• The vector store is classified at the sensitivity of the documents it was built from, not lower
• Vector store exfiltration appears in your breach response scenarios, as a document leak
• Highly sensitive source documents are flagged in vector metadata so you can scope an incident

Monitoring

• Bulk embedding query volume is logged and alerted
• Ingestion events are logged with contributor identity and timestamp
• Sudden large ingestion from a single source triggers review

Recovery

• Point-in-time snapshots of the collection are taken on a schedule
• Restore from a known-good snapshot has actually been tested
• Snapshots carry the same access controls as the live store

Inversion exposure

• You know whether your embedding model is publicly available
• The embedding model version is pinned next to your anomaly thresholds
• Per-tenant vector encryption has been evaluated, with a documented decision

Where this leaves you

Cosine similarity measures an angle. It has no notion of truth, authority or provenance, and when you build a RAG system you inherit every security assumption of the embedding space along with its retrieval quality.

Poisoning works because vocabulary engineering can move a document’s position without touching the model’s internals. Anomaly detection works because the geometric requirement that makes the attack effective is also what makes it visible at ingestion. Inversion works because dense vectors carry enough of the source text to reconstruct much of it, and the assumption that they did not was folklore rather than a result.

Over the past few years, nearly every security researcher I know has incorporated LLMs into their process. What began with chatbots quickly evolved into scripts calling model APIs, then agents, skills, custom harnesses, autoresearch loops, and more approaches than anyone can reasonably keep track of.

Toward the end of 2025, something shifted. Models and the harness/systems around them became better, and AI-assisted bug finding and exploit development stopped feeling like an interesting experiment, but it became reality, while we start observing an increased amount of exploits.

In my opinion three effects are already visible:

• Total losses have not been reduced.
• Beyond the largest and most obvious targets, we see exploits of smaller projects increasing exponentially.
• Bug bounty programs are filling with a mix of valuable findings, duplicates, and AI slop.

All of the above are happening due the fact that the cost of finding and exploiting bugs is falling exponentially, while most attackers are quicker (and it is much easier I might add) to adapt than most of the defenders.

We can spend a long time discussing what went wrong over the past year. The more important questions are what happens now, and what we should do about it.

AI changes the economics of both attack and defense. A successful security strategy will not rely on one perfect audit. It will combine everything from testing, AI tools, to manual reviews, and formal verification. Importantly on a continuous way.

AI does not need to discover and exploit every vulnerability autonomously to change security. It only needs to make each stage cheaper: learning an unfamiliar codebase, generating hypotheses, find bugs through a myriad of strategies, writing a PoC, and trying again when unsuccessful.

That changes the ROI for attackers. A target that once required weeks of specialist work may now require days. A smaller protocol that was previously not worth trying to attack, becomes an ideal target.

AI can be unreliable and still be transformative. If ten weak attempts are cheap enough, the eleventh attempt only needs to succeed once. Especially in security that is critical, where you might have fixed 99% of the bugs, but still one bug is enough to break a protocol.

In the following, will discuss what's happening on cryptography, if AI is the answer to the problem, and my personal view on how security is getting evolved.

Advanced cryptography is losing its accidental shelter

The impact is especially important for ZKPs, MPC, and other advanced cryptographic protocols. These systems used to benefit from a kind of accidental shelter. The code was more difficult to understand and grasp than other software, the number of capable attackers was small, and the value secured by projects was often lower than the value sitting in a large smart contract protocol.

From an attacker's perspective, why spend weeks understanding a ZK protocol when a simpler contract might secure more money?

That is shifting quickly. In 2026 we saw the first two known exploits against live ZK circuits. One was exploited by white hats to rescue roughly $1.5 million; the other was drained for 5 ETH. The root cause was not a deep new cryptographic attack. Both systems used Groth16 verifiers generated from trusted setups that had not been finalized correctly. Something that most of the time is out-of-scope from audits and a very simple prompt detects it immediately. After that more exploits have occurred in the ZK-space.

On the defensive side, we have seen the same change firsthand. Our AI-assisted pipeline found real vulnerabilities in Cloudflare's CIRCL, OpenVM's zkVM, Bron Labs's MPC library, and many others. Importantly, auditing those codebase would have taken a long time but AI tools manage to find bugs quite reliably and fast. Something worth noting here is that our AI-auditors did not found all the bugs, in matter of fact they missed some that we found later, still from an attackers and defenders perspective that's irrelevant.

Is AI the problem or the answer?

Strangely, nowadays AI seems to be both the cause of every new (security) problem and the proposed solution to it.

Bug bounty programs are flooded with AI-generated reports, creating a burden for triagers and a worse experience for researchers submitting valid reports. The proposed answer is AI-assisted deduplication and triage.

Attackers can use AI to understand code and develop exploits faster. The proposed answer is to use AI to find the vulnerabilities before they do.

That sounds circular because it is. Security has always been a cat-and-mouse game. AI has simply accelerated both sides.

So, is the answer to everything AI? Yes and no. Nearly every auditor now uses AI to understand code, detect vulnerabilities, and prepare proofs of concept. We do too. We also continuously improve our AI-auditor zkao, which continuously audits cryptographic code for vulnerabilities.

But a AI is not a panacea. Models change, harnesses improve, and the state of the art moves every few months. A useful AI security setup must be evaluated continuously, updated as new techniques emerge, and tested against the kinds of code its users actually ship. The tool itself needs a security research team behind it.

What is the state today and where things going?

The following diagram shows how I think about the available defenses. They are not substitutes for one another, and they are not steps that a project completes once and leaves behind.

Very few projects use every layer today. Most employ a handful, e.g., tests and fuzzing, one or more external audits before a major release, perhaps a bug bounty, and some monitoring. That was a reasonable model in the pre-AI era.

It is much less effective when attackers have a much higher throughput for attacking protocols.

An audit from three years ago is almost worthless nowadays in most cases. Even if a project has not changed substantially since then (or at all), the security field has changed dramatically.

When projects actually evolved this becomes critical for the whole stack. Tests must evolve with the code. AI harnesses must learn from new bugs. Formal verification must track the real implementation and its assumptions. Bug bounty triage and incident response must keep pace with rising report volume.

Tests, fuzzing, and manual audits have been adopted and matured over the years. Custom AI harnesses has becoming popular recently but requires internal security expertise. Formal verification remains specialized and expensive. Reviewing a formal verification effort as an adversarial target is newer still.

Third-party AI auditing tools sit in the middle. Adoption is growing quickly, but the market is noisy. It is easy to demonstrate that a tool can produce findings. It is much harder to demonstrate that those findings are valid (even an AI-PoC could be slop), important, and worth a maintainer's time.

For critical cryptographic infrastructure, I expect the picture to change substantially over the next few years. For the most security-aware projects, it may happen within months.

1. Tests, fuzzing, and traditional hardening

LLMs have made it cheaper to write tests, fuzz targets, static-analysis rules, and the glue code needed to run them. That does not make every generated test useful. The hard part is still choosing the right properties and building oracles that detects critical issues.

For cryptographic systems, ordinary unit tests are only the beginning. Domain-specific fuzzing, property-based testing, differential testing, and fault injection can reach failures that simple tests miss. Our zkvmBlast project is such an example.

This layer should be adopted by everyone. It is cheap, repeatable, and useful to every layer above it.

2. Custom AI harnesses

A small number of security-focused teams already maintain their own AI bug-finding setup. At the simplest level, this may be a collection of prompts and skills. At the other end, it may be a full internal harness with specialized agents, validation stages, codebase context, evaluation infrastructure, and self-evolving loops. These harness should be quite specialized for a specific project and its major threats.

One of the most important idea is that these should also be regression harnesses. In the past, finding a bug meant adding a test. Now it should also mean updating the security harness so that future versions can rediscover that class of bug, ideally across the rest of the codebase.

The harness must then run frequently, improve over time, and use diverse models when the risk justifies the cost. A one-off prompt is not continuous security.

3. Third-party AI auditing tools

This is the most heavily marketed part of the stack. You have probably already heard claims that some tool has solved software security once and for all. It has not.

One question I often get is:

if a team already has its own harness, why should it use an external AI auditor?

The answer is that a third-party tool only deserves a place if its maintainers continuously follow and advance the state-of-the-art, evaluate new models, encode new security knowledge, make it more efficient/cheaper, and improve the system against the code their clients actually write. Keeping an internal harness at that level can be more expensive and difficult than it first appears.

This is why zkao has remained focused on cryptography. We spend most of our time making it better at the kinds of code our clients build.

We see general AI tools as a cheap first line of defense, and specialized continuous AI auditing as a deeper layer. Neither removes the need for an expert review of critical code.

4. Manual audits

Manual audits remain the main independent defense for most projects, and I expect that to continue. Human auditors are still best placed to reconstruct an incomplete threat model, challenge protocol assumptions, reason about composition, validate exploitability, and decide what actually matters (obviously with the help of AI nowadays).

But a manual audit has a fixed budget and a fixed amount of time. That limitation is inherent. AI and traditional tooling should widen the search before, during, and after the engagement so that expert attention can be spent on the hardest questions.

For critical systems, audits should also be repeated. A second review can look at the same code with a different team or methodology, while later reviews should follow meaningful changes in code or new knowledge in the field.

5. Formal verification

Formal verification is another area where AI is changing the economics. The work remains specialized, but experts can use modern models to write definitions, propose lemmas, fill routine proofs, and explore proof failures faster than before.

At zkSecurity, formal verification of cryptographic systems has become one of our main focus. We built Clean to prove properties of circuits and are extending it toward end-to-end verification of multi-AIR systems such as zkVMs. We have also developed zkGolf to enable formally verified autoresearch for circuits.

6. Assurance for formal verification itself

Formal verification creates a new security boundary, and that boundary can also be wrong. A proof may establish the wrong theorem. The specification may omit a critical property. The model may exclude an attacker-controlled value. The verified component may be integrated into unverified production code incorrectly.

This creates a new kind of security work: adversarial review of the specification, assumptions, proof boundaries, and integration. The question is not only, "Does the proof check?" It is also, "Does this proof say what the system does, and does the deployed system match what was proved?"

We have already started doing this work and are developing a more systematic methodology for it. As formal verification adoption grows, assurance of the verification work will become a discipline of its own.

7 and 8. Bug bounties, monitoring, and incident response

These are not our main focus, but weaknesses here can erase the value of every earlier layer.

Closing a bug bounty because it attracts AI noise is becoming a norm, but it also removes a path for reporting the real issues that every other defense missed. The better answer is faster deduplication, prioritization, and AI-assisted triage. Maybe even fix the incentives a bit and cost of submitting slop (not necessarily pay-per-report).

Production monitoring and incident response are equally important. Prevention will never catch everything. Every organization running critical infrastructure needs the ability to detect an exploit, understand the affected surface, contain the damage, deploy a fix, and feed what it learned back into its tests, harnesses, audits, and specifications. Further, monitoring your dependencies has also been more important in the AI-era.

What happens next

Here are my current bets for the next few years:

1. Offensive capability becomes abundant. More people/automated systems will be able to inspect every valuable project even specialized code, and exploit vulnerabilities.
2. Validation becomes the bottleneck. Handling critical bugs in a timely manner will become the most challenging and important task for defenders, either through external reports or internal audits/tools.
3. Audits become continuous. Point-in-time review will basically have an expiration day, for live protocols re-audit every X months would be needed.
4. Security harnesses become product infrastructure. In an era where exploitation becomes almost free, having good security infrastructure and integration will become a must.
5. Formal verification becomes more practical. AI-assisted formalization will lower some of the cost, but writting the right specification and connecting proofs to production code will remain challenging. Adversarial analysis of FV would be required moving forward.

The old model was to build, audit, ship, and hope that the reviewed code stayed close enough to production. That model was already fragile. In a world where the cost of attacking software keeps falling, it is no longer adequate for critical systems.

The answer is not to buy every security tool or to demand formal verification of an entire codebase. It is to build a layered system in which cheap techniques run continuously, experts spend their time on the hardest questions, fixes move quickly, and the most critical properties receive the strongest guarantees we can give them.

Finding bugs became cheap. Building confidence is still hard. That is the work ahead.

Full article content is not available for inline reading.

Read the original article →

OpenAI launched GPT-6 Astra on September 3, and there is a piece of the launch I think deserves attention alongside the benchmarks. We now have public reports from more than one lab describing evaluation agents reaching real systems they were never supposed to touch. These systems can do useful, difficult work. Some of the same persistence that makes them useful can also carry them well past the task somebody intended to give them.

The July Hugging Face incident is the most visible example, and we have much better information now than we did when it first broke. OpenAI's August 26 investigation describes several models, primarily an internal research prototype, exploiting shared package infrastructure, exchanging information through an unauthorized message board, and eventually compromising parts of Hugging Face's systems while looking for benchmark solutions. OpenAI published a technical report and linked an independent investigation by METR and Redwood Research. This was a serious failure, and publishing enough detail for other people to learn from it matters.

Two distinctions are important here. Astra was not involved. And these evaluations ran with reduced safeguards to measure the underlying models' cybersecurity capabilities, rather than the protections used in the products people normally access. That makes containment during evaluation especially important; it also means we should be careful about treating the incident as a description of ordinary ChatGPT behavior.

The response has moved beyond the initial pause. In its prelaunch safety update, OpenAI says Astra meets its Critical cybersecurity capability threshold, with advanced cyber access initially restricted. It also says the large frontier reinforcement-learning run restarted on August 28 after new safety and security requirements were in place, while some experimental runs remained on hold. The changes include tighter network controls, stronger isolation, better alignment training, and monitoring that can stop potentially unauthorized activity.

There is encouraging data alongside the capability increase. In the launch evaluation inspired by the Hugging Face incident, OpenAI reports that Astra went beyond the authorized target in 0% of cases, compared with 48.2% for GPT-5.6 Sol, tested without production safeguards. Those are results from a particular evaluation, not a guarantee about every situation a deployed agent will encounter. But they are evidence of improvement, and they belong in the discussion too.

Other Labs Are Finding This Too

On July 30, Anthropic reported three incidents across six evaluation runs, found during a review of 141,006 runs. Its review began after OpenAI's disclosure. In these cases, an evaluation environment had internet access that Anthropic believed was disabled, and Claude reached the production infrastructure of three organizations while pursuing fictional capture-the-flag tasks. Unlike the OpenAI incident, these models did not need to discover a novel sandbox escape. An open path was enough.

The models behaved differently, which is worth keeping in the story. Anthropic's newest research model stopped when it recognized that its target was real, although it had already gone further than the company wanted. An older model continued. Anthropic cautions that these were isolated incidents, not a controlled comparison, and says the evaluations lacked safeguards used in its public products. It paused cyber evaluations, notified affected organizations, and described changes to its monitoring and work with evaluation partners.

There is also deliberate misuse, which is a different problem but uses some of the same capabilities. Anthropic's August 2025 threat report described a criminal using Claude Code against at least 17 organizations, with the model helping carry out operations rather than only offering advice. That report is a year old now. Between misuse and evaluation failures, there is enough public evidence to put this in an ordinary security review. We do not need to assume every model behaves the same way to recognize that it is happening across products and environments.

One Floor Up

In the way back machine, in the summer of 1978, Janet Parker was employed as a medical photographer at the University of Birmingham Medical School, where her workroom sat one floor above a laboratory run by Professor Henry Bedson, one of Britain's senior smallpox researchers. The last natural smallpox case on Earth was recorded in Somalia in October 1977. The World Health Organization was preparing to certify global eradication, and the plan for the virus afterward was a short list of approved laboratories. Bedson's lab was due to lose its authorization at the end of 1978. Inspectors who visited earlier that year had noted that its containment did not meet the standards being drafted for the labs that would contain the virus, and Bedson, who wanted to finish his research program before the deadline, kept working. Parker fell ill on August 11 and was diagnosed with smallpox on August 20. Around 260 people who had been in contact with her were quarantined. Her mother contracted the virus and survived it. Her father died of a heart attack during a visit to his daughter in isolation. Bedson, under quarantine at his home while the inquiry assembled, cut his throat on September 1 and died on September 6. Parker died on September 11, 1978, the last person killed by smallpox anywhere. The official inquiry concluded that the virus had most likely traveled from the lab to her workroom through a poorly maintained service duct. Expert witnesses in the later prosecution of the university considered the airborne route implausible, and the honest summary, five decades on, is that the transmission path has never been established. A containment regime was inspected, found wanting, allowed to continue operating, and breached by a route that still has not been identified.

I want to be careful with this comparison. Software agents are not pathogens, and a security incident is not equivalent to a death. The useful connection is the boundary: somebody working outside an experiment can still be affected by what happens inside it. Parker never worked with smallpox. The organizations reached during the AI evaluations had not agreed to participate in those exercises either.

The evaluations themselves serve a necessary purpose. We want labs measuring these capabilities before release, and we want them to disclose failures, pause work when needed, and share what changed. OpenAI's disclosure prompted Anthropic to look through its own records and find incidents it had missed. That is a concrete benefit of publishing the uncomfortable details. I would much rather have this information available while we can use it to improve the systems we are building.

A capable agent with tool access is also a workload, and the questions that matter about a workload are unglamorous. What is it connected to? What credentials can it reach? Can it leave information somewhere another agent will find it? Who gets told when it starts doing something outside its assignment? Better model behavior helps, as the newer evaluations suggest. Isolation, access controls, and monitoring give you additional chances to catch a mistake before another organization has to deal with it.

For those of us deploying agents, there is work we can do now. Check the actual network access, including package proxies and shared services, rather than trusting the word "sandbox" in a configuration. Give the task credentials with a limited scope and lifetime. Record tool actions somewhere the agent cannot rewrite, and make sure someone can stop the workload and revoke its access. If you buy an agent service, ask the vendor the same questions. The prompt saying "this is a simulation" did not make Anthropic's network a simulation, and a statement of intended access is not a test of actual access.

I am excited about how much more useful these systems are becoming. That is also why I want the operational conversation to catch up. You may run the agent, supply a service it uses, or simply have infrastructure it can reach. Janet Parker's workroom was one floor up. For our systems, we can at least start by finding out what is connected to what.

World models generate, reconstruct, and simulate any possible world. They understand how worlds appear, behave, and evolve so that we can render imagined worlds for creative users, simulate the real world in high fidelity, and help robots plan actions. At World Labs, we build these general purpose world models in pursuit of spatial intelligence.

Today we are introducing Atlas, our next-generation world model. Atlas is an omni model that we pretrained from scratch to natively operate on text, images, video, and 3D. It is a multimodal autoregressive diffusion transformer: all inputs are combined into a shared spatial context. Atlas uses that context to generate what comes next, staying consistent in 3D with everything it has seen and imagining what lies beyond it. Atlas is built to scale: its performance improves with increased training compute, and we expect this trend to hold as we continue scaling.

Atlas can perform a broad range of tasks spanning world generation, reconstruction, and simulation:

• Camera-Controlled Generation: Atlas generates images and videos from one or more images with pixel-perfect camera control, outputting up to 1 minute of video at 1440p.
• Spatial Reconstruction: Atlas reconstructs real world scenes from one to dozens of input images. It generates both image frames from novel views and explicit 3D outputs, outperforming state-of-the-art models specialized for 3D reconstruction.
• Space-Time Simulation: Atlas models space and time from input videos, reframing videos for dramatic visual effects and enabling Real-to-Sim workflows for robotics.
• Image Generation: Atlas generates images and 360 panoramas from text; it can follow complex prompts, render text, and generate a wide variety of visual styles.

Atlas will power future versions of Marble and other products from World Labs.

Camera-Controlled Generation

Atlas takes one or more reference images and generates new views at any camera position and angle you specify. Generated views match the content and geometry of the input images, smoothly extrapolating beyond them to imagine parts of the scene not visible in the inputs.

Atlas handles a broad range of scene types, visual styles, and camera motions.

Pixel-Perfect Camera Control

Atlas uses precise camera geometry as a native input type, going beyond coarse text-based instructions for camera control. This lets you frame every shot and control every motion.

In the examples here, Atlas generates a complete scene from a single input image. It uses the content of the input image along with its broad world knowledge to imagine what the scene should look like from new angles. For example, it generates the back side of the robot, and it guesses that there should be a grassy lawn next to the pool.

Generating with Spatial Context

Similar to an LLM, Atlas first encodes its inputs into a context, then generates outputs conditioned on the context. However, Atlas is unique because each image is grounded at a 3D position in space; this forms a spatial context.

Managing this spatial context unlocks entirely new kinds of creative control. For example, you can place two unrelated reference images in the context and position them in 3D space; Atlas then generates a world that smoothly interpolates between them.

These examples demonstrate the model's world knowledge and creativity; it imagines doorways, hallways, nooks, and other transitions between otherwise unrelated image pairs.

Controllable Long Videos

Atlas lets you generate long videos with precise control by combining camera movement and spatial context management. You design every scene and every camera angle. This puts you in the director's chair: you are staging the scene, not pulling the lever of a slot machine.

In the example below, we generate a 1 minute video at 1440p resolution using a small number of reference images. We hand-design a camera path through the scene, and Atlas generates a coherent world.

Spatial Reconstruction

Atlas reconstructs real-world spaces from one or more input images. It does not require special capture equipment or hundreds of dense views to faithfully reconstruct objects and scenes. We believe Atlas is a major step forward toward solving the problem of novel view synthesis from sparse input images, a decades-old fundamental problem in 3D computer vision.

Reconstructing from Multiple Images

Atlas can take a variable number of input views of a scene. When parts of the world are not visible in the input views, Atlas imagines a plausible way to fill in the gaps by drawing from its rich world knowledge.

But sometimes you do not want imagination; you might want an exact reconstruction of a real-world location. Passing more input images gives Atlas more context: the more it sees, the less it imagines. Atlas typically gives faithful reconstructions with as few as two or three images, outperforming state-of-the-art results by models specially trained only for 3D reconstruction. However, Atlas can also make use of over a hundred input images in its spatial context, allowing for faithful recreation of real world environments.

Reconstructing Diverse Paths

Atlas can generate many different trajectories through the same scene, giving new perspectives on the same input images. No matter how many times you change the camera path, the scene stays consistent.

Explicit 3D Outputs

In the results above you have seen Atlas output 2D images and videos, which are sufficient for some applications. But workflows in robotics, gaming, design, VFX, and beyond often require explicit 3D outputs. Atlas natively operates on both 2D image frames and 3D depth maps, enabling it to output worlds as point clouds or 3D Gaussian splats.

From a single input image, Atlas produces a full 3D world by jointly generating new views and estimating their geometry. From a video of a real space, it predicts the depth of every frame and combines them into a 3D reconstruction. In either case, Atlas fills in regions that no camera ever saw.

Point clouds estimate a scene's geometry, but 3D Gaussian splats make it usable. Atlas fills the remaining gaps and turns the point cloud into a complete splat scene that renders on-device at high resolution and frame rates.

Space-Time Simulation

Atlas serves as a world simulator. It understands both the spatial structure of the world and how the world evolves over time. Combining its spatial and temporal abilities leads to new applications for VFX, robotics, and beyond.

Reframing Video

Atlas turns a handful of ordinary cameras into a "bullet time" multiview capture studio. With footage from as few as three cameras, Atlas can freeze time and reframe shots, letting you view events from impossible angles.

Notably, these shots did not require professional photographers or specialized equipment. Each of them was filmed by a few engineers and researchers with ordinary cell phones on tripods and clamps that fit in a backpack. Atlas reconstructs the scene from three to five camera views, after which you can reframe shots however you like.

Robotics Simulation

Atlas opens up new ways to scale Real-to-Sim for both navigation and manipulation.

You have already seen Atlas reconstruct a space in explicit 3D from a few images. For robotics, reconstruction is only half the job: as a simulated robot moves through space, Atlas also generates the RGB and depth data its sensors would observe along the way. The world and the robot's view of it come from the same model.

Robotic manipulation goes a step further. From a few casual recordings, Atlas aids in building a simulation that also captures how objects move and interact. Once a task is simulated, you can vary it easily: change the objects, their positions, the robot's motion, the lighting, and the background. The result is diverse training data and testing environments for robotics at scale.

Image Generation

The primary focus of Atlas is world modeling, and every image is a window to a possible world. Though image generation is not its primary focus, Atlas is a capable image generator: it follows complex prompts, renders text, and generates a wide variety of visual styles.

Atlas also generates 360 images from text or image prompts, where again it can generate a wide variety of scene types and visual styles.

Technical Details

Model Architecture

Atlas is an omni model designed to handle many tasks and many kinds of input and output data in a single unified architecture, putting spatial control at the heart of the model. These goals require us to depart from standard architectures used by both LLMs and video models, and design a new base architecture to serve as the foundation of future world models.

Atlas is a multimodal autoregressive diffusion transformer. It operates on multimodal sequences, generating each new element of the sequence one at a time. These architectural properties work together to achieve our goals, and taken together they enable a new paradigm of generation based on a spatial context. We unpack these ideas in turn:

• Multimodal: Atlas can natively process many different data types. At present it can operate on text, images, camera poses, and 3D depth maps; videos are represented as sequences of images. Each image and depth map is conditioned on an explicit camera pose, making spatial control a central component of the architecture.
• Autoregressive: Atlas operates on sequences of elements, where each element is one of the multimodal data types above. Each output is generated one at a time, conditioned on earlier parts of the sequence. This flexible design naturally adapts to a wide variety of tasks: each task is just a different kind of sequence, where inputs are followed by outputs.
• Diffusion: Atlas is a rectified flow model that generates outputs by gradually denoising them. Diffusion models excel at modeling high-dimensional continuous data like images and video, and can naturally trade off speed and quality by varying the number of denoising steps used during inference.
• Transformer: The transformer architecture consists primarily of large matrix multiply operations and is well-adapted to modern hardware. It is a robust backbone for world modeling.

Like an LLM, it is an autoregressive transformer, so it can take advantage of innovations used to serve and accelerate LLMs including KV-caching, cache-aware routing, disaggregated serving, and more. Like a modern image or video model, it is a latent diffusion model and can make use of algorithms such as diffusion distillation, classifier-free guidance, shifted noise schedules, and advances in VAE design.

Benchmarks

Atlas is an omni model for world modeling that performs many tasks. There is thus no single benchmark that fully captures its generality. We highlight quantitative evaluations of Atlas on two key tasks: camera-conditioned generation and 3D reconstruction. On both tasks it outperforms more specialized models.

We compare against a selection of top-performing video models for camera-conditioned generation. In each trial, we pair a single input image with a sequence of one to three cinematic camera motions (pan, truck, crane, etc.). Third-party human raters judge which model better follows the intended camera path. These results confirm that Atlas outperforms recent video models at camera-controlled generation, and this advantage grows as camera trajectories become more complex.

We additionally evaluate Atlas on the task of 3D reconstruction from sparse input views. Despite its generality, Atlas outperforms the best specialized open-source reconstruction models.

Model Scaling

Most progress in modern AI has been driven by scaling. Models improve in large part by scaling up simple algorithms to make use of more data and compute.

We see strong evidence that Atlas will continue to improve with scale. We pretrained Atlas from scratch on a large diverse corpus of multimodal data. Over the course of development, we trained a series of models of increasing size and training compute, and found that each new level of compute unlocked new model capabilities. We are confident that our future world models will follow this trend, dramatically improving their capabilities as we continue to scale.

Build with Atlas

Atlas is entering early access with select partners. If you would like to build with it, request access below and we will reach out. We are excited to see what you build, and to work with you to make Atlas the go-to world model for generating, reconstructing, and simulating any world.

We are also hiring across research and engineering to advance spatial intelligence.

This post was produced by the World Labs team.

@article{worldlabs2026atlas,
    author = {World Labs Team},
    title = {Atlas: A World Model for Spatial Intelligence},
    journal = {World Labs Blog},
    year = {2026},
    note = {https://www.worldlabs.ai/blog/atlas},
}

Chat-GPT‑6 Astra is OpenAI’s newest agentic AI model, designed to handle complex tasks like game development, 3D design and ordering takeout all by itself. Anything that can be done on a computer, Astra can do it, and fast.

The model's already caused controversy after tests showed it could potentially conceal its reasoning and exploit unknown software vulnerabilities. Now, after the kind of self-imposed delay that seems to have become an obligatory part of the marketing hype for frontier models, Astra's being release into the wild, or at least to some paying subscribers. And the advertising doesn't make it look any less dystopian.

Want to generate a game and then 3D print a rocket as a souvenir to decorate your lonely living room? Just ask Astra to do it for you. That's one of the use cases presented in the advert above.

Astra is asked draw a rocket, turn it into a 3D model using Blender, the free, open-source 3D modelling software, and then put that into a video game while ordering beef and rice for dinner.

OpenAI's billing GPT-6 Astra as the world's most intelligent and aligned AI model and a "new state of the art for computer use, browsing, software engineering, cybersecurity, science and professional work".

It says that instant gaming startup Playco was able to produce themed prototype games with minimal human intervention and cut manual fixes in prototyping by 50%. Demos provided on the OpenAI website include GPT‑6 Astra modelling a house in Blender and then turning it into a walkable scene in Unreal Engine 5, "helping designers and clients explore the layout and experience the space before it’s built".

This is another AI problem for the gamedev industry. Soon anyone will be able to give AI a video clip, a wiki link, a screenshot of a game, along with maybe a brief description and have a nearly identical clone they can play or try and monetize themself. September 5, 2026

Some see Astra as a game changer that makes 3D modelling and game development workflows faster and more accessible. Others fear it could be used as an all-out piracy machine, allowing people to clone whole game concepts and try to flog them as their own.

Even some AI enthusiasts caution that while the demos look impressive, Astra doesn’t outperform rivals like Anthropic’s Claude Fable in every benchmark, and that its higher token costs for large context requests may limit adoption.

Going back to the advert, it's caused some controversy among traditional Blender users. Many aren't thrilled that the community-driven open-source software that's long championed independent artists is now being used to promote the idea that they're superfluous. The artist who created the Puma used as the Blender 5.2 splash screen has expressed "disgust" at seeing her work appear in an OpenAI ad.

It disgusts me that my artwork appeared in OpenAI add September 4, 2026

open ai using BLENDER to advertise ch*tgpt???? Your out of ur god damned mind Blender? The FREE, open source, do it yourself software with a massive community happy to teach you? Im going to say things thats gonna get me banned from this platform. Stay tf away from human-made art September 3, 2026

Beyond the software itself, there's an inescapable bleakness in OpenAI's vision of the future as depicted in the ad.

The spot is staged as a demo playing on the pioneering MIT computer interaction project Put That There (shown at the beginning). But the suggestion is that the future (or a present) of 'creative work' is one person alone in a room talking to a screen, with the few remaining obligations to interact with other humans now eliminated. Do we believe the fashion designer in ad has any friends to play tennis with, or will she get ChatGPT to hit the court for her too?

OpenAI’s next DevDay is fast approaching, with the event set for the end of September. As tradition dictates, attention is turning to what the company is preparing, and once again, agents are at the center. This time, OpenAI is working on an implementation of Managed Agents that broadly follows what Anthropic currently offers. The company will also likely target businesses with this managed agent experience, in addition to developers.

OpenAI has been trying to build an agent ecosystem for quite a while. The effort began with custom GPTs, followed last year by an agent builder with functionality similar to what n8n offered at the time. In just over a year, that approach has already become obsolete because agent capabilities evolved enough to cover pipelines on their own, without users needing to build connections manually. It was a natural evolution that happened remarkably quickly.

Anthropic has led the pack in this area, although it remains difficult to say whether its managed agents have been super successful. Developers and enterprises use them, yet many users still rely on alternative, cheaper solutions. For OpenAI, a major question is whether it can hit a price point that makes its solution more attractive. The company already provides advanced models with strong computer-use capabilities, which should give it an advantage. Whether that will be enough to reach critical mass remains unclear.

Managed agents will not be the only announcement at DevDay. Model updates, security solutions, and more are also expected. Although access to the agents UI is not available yet, the codebase suggests functionality very similar to Anthropic’s offering, including creating different agents and environments, managing them, and enabling specific skills and plugins.

OpenAI also appears to be preparing demos for business customers. Whether this appears at DevDay or later, the company is working on functionality that would allow ads on ChatGPT to resolve directly to an agent. Rather than seeing a standard informational ad in a response, users would receive a link to an agent that takes the lead and guides them through the process.

These agents are expected to handle conversion funnels, optimizing and customizing them far better than traditional advertising solutions. That might sound minor, but it represents a huge shift and could pose a serious threat to major advertisers such as Meta and Google until they offer their own solutions in this space. It remains speculation, but it is definitely worth watching. Let’s see how it unfolds.

References 👀

• OpenAI's official DevDay site confirms September 29, 2026 at Fort Mason in San Francisco, with a livestreamed keynote and technical sessions, APIs, tools, demos, and workshops.
• OpenAI introduced custom GPTs in November 2023 and Agent Builder in October 2025. A June 2026 update says Agent Builder and Evals are being wound down after November 30, with the Agents SDK and Workspace Agents named as successors.
• Anthropic describes Claude Managed Agents as a hosted service for long-horizon work with sessions, harnesses, sandboxed environments, scoped permissions, managed credentials, audit logs, skills, connectors, plugins, and subagents.
• OpenAI publicly offers ChatGPT Ads and Ads Manager, including campaign goals, links, bidding, and conversion measurement. Its August 2026 update says it will explore more native ways for businesses to interact with consumers.

The Two MMLU Scores: What a Benchmark Name Does Not Fix

TL;DR

• Two MMLU accuracies, 0.781 and 0.79, for two builds of one model family under the same benchmark name; for a score-delta query the verifier returns incomparable.
• mmlu fixes a name. The split, the implementation, the prompt format, the grader and the runner’s network access stay open, and where published measurements exist for them the differences are points of accuracy, not thousandths.
• Comparability is a property of the reference the results are traceable to, not of the number.
• Under the APL AI-Eval profile the frame is a content-addressed object and the claim carries its hash; the two frames differ, and subset: "all" and an omitted key are different scopes by canonical bytes.
• apl-valid is a statement about structure and says nothing about whether either score is correct.

Two evaluation records appear in the same table. One reports mmlu accuracy 0.781 for build 42; the other reports 0.79 for build 44. The claims declare the same provider, model family, metric identifier, unit and benchmark name. The arithmetic difference is +0.009.

The records are structurally valid. Their frames declare different runners, graders and dataset splits. The shared mmlu label identifies a dataset family, not a full measurement procedure. For the score-delta query shown below, the verifier returns incomparable.

1. What the two numbers say

Here is claim A as it exists on the wire, in the metadata.apl position of a log entry:

{"apl":{"version":"0.1","claim":{"kind":"observation","subject":{"type":"model-build","id":"model:acme-gpt-7b-build-42","build_id":"42","artifact_digest":"sha256:4242424242424242424242424242424242424242424242424242424242424242","provider":"acme","model_family":"acme-gpt-7b"},"aspect_refs":["accuracy"],"statement":{"predicate":"score","content":{"benchmark_id":"mmlu","metric_id":"accuracy","value":0.781,"unit":"fraction"}}},"frame_ref":{"hash":"sha256:c7b88426f2676f3653db0fad0bdbd689318f16d589d14a315bdd4cc454bca1ab"}}}

Claim B, two builds later:

{"apl":{"version":"0.1","claim":{"kind":"observation","subject":{"type":"model-build","id":"model:acme-gpt-7b-build-44","build_id":"44","artifact_digest":"sha256:4444444444444444444444444444444444444444444444444444444444444444","provider":"acme","model_family":"acme-gpt-7b"},"aspect_refs":["accuracy"],"statement":{"predicate":"score","content":{"benchmark_id":"mmlu","metric_id":"accuracy","value":0.79,"unit":"fraction"}}},"frame_ref":{"hash":"sha256:c93a9c55422ddbd2158a5336caa3a251641cf3937f451fb13387a5f54f0d998e"}}}

The subject differs, which is the point: two builds of one family. Each claim declares an artifact_digest, which the profile treats as the immutable identity anchor of the evaluated artifact. The statement is identical in shape and vocabulary — predicate score, benchmark mmlu, metric accuracy, unit fraction. Claim B writes the value as 0.79; a presentation may display that JSON value as 0.790, and under RFC 8785 canonical number serialization the trailing zero does not change the value.

The claim-level pointers differ: frame_ref.hash is c7b88426… in one record and c93a9c55… in the other. Resolving the two frames shows differences in both procedure and scope; the hash is the whole signal at the claim level.

2. What “MMLU” does not fix

2.1 The split

The MMLU paper reports 15,908 questions split into a few-shot development set of 5 questions per subject across 57 subjects, a validation set of 1,540 and a test set of 14,079. The Hugging Face dataset most runners load, cais/mmlu config all, reports test 14,042, validation 1,531, dev 285. “The MMLU test set” names two objects of different sizes, and no reviewed document explains the difference.

2.2 The implementation

One published measurement of implementation variance is the June 2023 Hugging Face post on the Open LLM Leaderboard. Three harnesses — HELM, the Eleuther harness, the original code — run the same dataset, all 5-shot, and score llama-65b at 0.637, 0.488 and 0.636. The post concludes that the three results are not comparable despite the shared MMLU label.

2.3 The prompt format

Anthropic’s 2023 account of evaluation reports that formatting alone — option labels, parentheses, an extra space before the answer — moves MMLU accuracy by about 5%. Answer position moves more. Zheng et al. report that on MMLU, moving the correct answers to position D lowers gpt-3.5-turbo from 67.2 to 60.9, and that moving them to A lifts llama-30b by 15.2 points.

2.4 The grader

Frame A grades with exact-match-v1. Frame B grades with llm-judge-v3. Zheng et al. found that judge models “exhibit strong position bias”, that only GPT-4 stayed consistent in more than 60% of cases, and describe a judgement that flips when two responses swap positions.

2.5 What the runner could reach

Another variable is the environment the runner was allowed to touch. CAISI published an account of finding, after the fact, that it had been running SWE-bench Verified with internet access while other evaluators ran without it. Scale’s search-time contamination work found roughly 3% of questions retrievable with labels from Hugging Face, and blocking that source cut accuracy on the contaminated subset by about 15 points.

3. Comparability is a property of the reference, not of the number

VIM §2.46 defines metrological comparability of measurement results through traceability to a common reference. The AI-Eval profile turns that into a narrower operational rule: a bridge is applicable only when the frames meet its exact aspect, scope and procedure constraints, and mmlu alone does not meet them.

4. Binding the number to its frame

Under APL, the frame is not documentation attached to a claim but a separate content-addressed object, and the claim carries only its hash. The AI-Eval profile — the vocabulary for benchmark observations about a model build — fixes what that object must contain.

5. What the verifier says

apl-ai-eval is a Rust crate, version 0.3.1. Given a receipt or a pair of receipts and a relation query, it decides whether the claims are well-formed under the profile and whether the relation is evaluable. If frames differ and no bridge is supplied to license a comparison, the verifier returns incomparable. It is a subtraction with no defined result, reported as such.

6. What this does not prove

• That either score is correct. apl-valid is a statement about structure, not accuracy.
• That two identical identifiers name the same thing. It does not know whether the two runs shared a commit, an accelerator, a tokenizer build or sampling defaults.
• That the dataset was the same dataset. The frame identifies data by name and split, not by digest.
• Anything about uncertainty. Profile v0.1 specifies no uncertainty field.

What the frame establishes is narrower: it binds a stated procedure to a stated claim by hash. Under AI-Eval v0.1, the supplied frames and this score-delta query do not satisfy the conditions for an applicable bridge, so the verifier returns incomparable rather than a delta.

Accelerator Agents

Accelerator Agents is a collection of AI-powered tools designed to accelerate machine learning development on Google Cloud TPUs. This repository hosts agents that assist with code migration, kernel optimization, and performance tuning, enabling developers to leverage the full power of TPUs with greater velocity.

Disclaimer: This is not an officially supported Google product. This project is not eligible for the Google Open Source Software Vulnerability Rewards Program.

Overview

As machine learning models grow in complexity, optimizing them for specific hardware accelerators like TPUs becomes increasingly challenging. This project aims to provide a suite of "Agents"—specialized AI tools powered by Gemini—to automate and assist with these complex tasks.

The project includes two primary agents:

1. MaxCode

The MaxCode agent facilitates the conversion of existing PyTorch models and codebases into JAX. It is designed to help users migrate their workloads to run efficiently on TPUs, leveraging high-performance frameworks like MaxText.

Note: MaxCode is under active development, and we are continuously working to improve migration quality and expand model coverage.

Features:

• Automated Conversion: Converts functional code blocks and model layers from PyTorch to JAX.
• MaxText Integration: Generates JAX code compatible with the MaxText framework for immediate training and inference on TPUs.
• Human-in-the-Loop: Designed to draft initial implementations that developers can review and refine.

2. MaxKernel

The MaxKernel agent is a specialized tool for high-performance kernel development on TPUs. It assists engineers in writing, optimizing, and debugging custom kernels, specifically focusing on Pallas (JAX's kernel language).

Features:

• Kernel Writing: Drafts Pallas kernels from scratch or based on JAX reference implementations.
• CUDA to Pallas Conversion: Assists in porting custom CUDA/GPU kernels to run optimally on TPUs.
• Optimization & Profiling: Provides profiling insights and optimization suggestions to improve kernel performance (MFU).
• Test Harness Generation: Automatically generates boilerplate code for correctness testing and compilation checks.

Getting Started

Prerequisites

• A Google Cloud VM. A CPU-only VM is sufficient for MaxCode, while a TPU VM is recommended for MaxKernel.
• Python 3.11+
• Access to Gemini API (for agent reasoning capabilities).

Installation

Clone the repository:

git clone https://github.com/AI-Hypercomputer/accelerator-agents.git
cd accelerator-agents

(Note: Specific installation instructions for each agent can be found in their respective subdirectories.)

Contributing

We welcome contributions! Please see CONTRIBUTING.md for details on how to submit pull requests, report issues, and contribute to the project.

License

This project is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

An Initial Step towards a Vision-Language Foundation Model for Autonomous Driving

Welcome to the GitHub repository of Qwen-Drive-1.0. Here you can find official information about Qwen-Drive, and post your questions (Issues).

Introduction

Qwen-Drive-1.0 retains the architecture of the pretrained Qwen3.5 vision-language model and integrates 3D perception, visual question answering, and motion planning within a unified framework. The natively multimodal Qwen3.5-4B serves as the shared VLM, with two external modules attached:

• A BEV Perception Head jointly performs 3D object detection, semantic occupancy prediction, and BEV map segmentation. It serves as a probe of the 3D information accessible from the shared representations and provides an explicit, inspectable interface to 3D scene structure.
• A Planning Expert conditions on shared VLM representations to generate future ego trajectories.
• The original VLM's LLM Decoder remains unchanged, and can handle both General VQA and Driving VQA tasks.

We propose a staged training strategy that integrates perception, language, and planning objectives. By combining driving-specific supervision with general-purpose vision-language data, the model achieves specialized driving competence while retaining broad visual understanding and instruction-following capabilities. This approach is supported by a unified data pipeline that: (1) maps heterogeneous perception annotations into a shared label space; (2) re-annotates driving VQA responses to ensure format and factual consistency; and (3) standardizes trajectories from multiple public driving datasets into a unified waypoint representation.

Performance

Planning

SFT is the imitation-trained Planning Expert. RL is the same expert after reward optimization on the benchmark objectives. Both share one VLM.

Driving VQA

LingoQA is scored with Qwen-Plus as the judge instead of the official LingoJudge, which we found to score leniently and inconsistently across scenarios. Under the official LingoJudge protocol Qwen-Drive-1.0-SFT obtains a LingoScore of 79.4. – marks an invalid or unparsable response.

On driving-scene understanding, Qwen-Drive-1.0 improves markedly over its Qwen3.5-4B base while keeping general vision-language ability intact.

General VQA and Reasoning

Spatial Understanding and Grounding

Models

The model can be downloaded from Hugging Face or ModelScope. Everything ships in one directory. The VLM sits at its root, shared by every task, and each task head in a subfolder beside it.

Qwen-Drive-1.0-4B/          9.1 GB  the VLM, which on its own serves the VQA mode
├── planner-sft/            2.1 GB  Planning Expert, imitation-trained
├── planner-rl/             2.1 GB  Planning Expert after reward optimization
└── perception/             0.5 GB  BEV perception head

A head is attached when the VLM is loaded:

model = QwenDriveForPlanning.from_pretrained(
    "Qwen-Drive-1.0-4B", planner="Qwen-Drive-1.0-4B/planner-rl", dtype=torch.bfloat16
)

planner-rl was reward-optimized only on reasoning-conditioned rollouts, so run it in the reasoning planning mode. planner-sft covers both direct and reasoning planning.

Install

A GPU with 24 GB+ of memory is recommended.

git clone <repository-url> qwen-drive && cd qwen-drive

# Any Python virtual environment works; conda is shown here
conda create -n qwen-drive python=3.10
conda activate qwen-drive

pip install -e. --no-build-isolation        # or: pip install -r requirements.txt

Quick start

data/demo/ bundles four WOD-E2E planning scenes with their frames in one Parquet file and six perception frames, so the commands below need nothing but the weights.

export PYTHONPATH=src
python scripts/demo.py --model Qwen-Drive-1.0-4B --planner Qwen-Drive-1.0-4B/planner-rl \
    --scenes data/demo/planning_scenes.jsonl --image-archive data/demo/frames.parquet \
    --plot demo.png

import torch
from qwen_drive import InferenceMode, QwenDriveForPlanning
from qwen_drive.benchmarks import read_scene_file
from qwen_drive.images import ImageArchive

model = QwenDriveForPlanning.from_pretrained(
    "Qwen-Drive-1.0-4B",
    planner="Qwen-Drive-1.0-4B/planner-rl",
    dtype=torch.bfloat16,
    attn_implementation="flash_attention_2",
).to("cuda").eval()

scene = next(
    read_scene_file(
        "data/demo/planning_scenes.jsonl",
        image_archive=ImageArchive.open("data/demo/frames.parquet"),
    )
).scene

result = model.run(InferenceMode.REASONING_PLANNING, scene=scene, num_samples=6)
print(result.reasoning)
print(result.trajectories.shape)   # (6, 50, 3) -> (x, y, heading), 5 s at 10 Hz

Documentation

Repository layout

qwen-drive/
├── src/qwen_drive/             # VQA + planning: model, scenes, benchmarks, metrics
├── src/qwen_drive_perception/  # perception mode (+ CUDA kernels under ops/)
├── scripts/                    # demo, prediction and scoring, visualization
├── data/demo/                  # bundled demo scenes and perception frames
├── data/benchmarks/            # the four benchmark scene files (relative frame paths)
├── assets/                     # figures
└── docs/

Citation

@misc{zhou2026qwendrive10initialstepvisionlanguage,
      title={Qwen-Drive-1.0: An Initial Step towards a Vision-Language Foundation Model for Autonomous Driving}, 
      author={Xin Zhou and Zongchuang Zhao and Zhibo Yang and Mingsheng Li and Humen Zhong and Shuai Bai and Du Chu and Ruizhe Chen and Zhaohai Li and Jun Tang and Qiuyue Wang and Mingkun Yang and Jiazhao Zhang and Dayiheng Liu and Dingkang Liang and Xiang Bai},
      year={2026},
      eprint={2609.00111},
      archivePrefix={arXiv},
      primaryClass={cs.CV},
      url={https://arxiv.org/abs/2609.00111}, 
}

License

Qwen-Drive-1.0 is released under the Apache 2.0 license.

Motivation

There are many coding harnesses (Claude Code, Codex, and many more), but they are all designed to be used by a human.

They are not designed to be used by an agent. If you ask an agent to use codex exec as a subagent, it might spend a few turns just to figure out the right CLI flags and parse the output. And if you want a more custom loop, an agent might need even more turns to dig into the source code of Codex CLI to learn all the implementation details.

Harness In Prompt

hip-agent (harness in prompt) is a harness designed for agents. The core loop is about 200 lines of Python, plus one module for the Codex API. Three ideas:

• The harness fits in the prompt. The loop is minimal, the model is given only two tools, sh and view_image, and the prompt tells it to read the source to learn exactly what the harness does.
• The OS is the runtime. Configuration is environment variables, actions are shell commands, and a subagent is a child process.
• The rest is handled by existing protocols and formats. Plugins follow Agent Plugins, hooks use Claude Code’s hook contract, and the conversation is a Codex CLI session file, so codex resume opens it.

The whole configuration looks like this:

# ~/.zshrc
P=~/hip-agent/plugins
export AGENT_MODEL=gpt-5.6-sol
export AGENT_PLUGINS=$P/environment:$P/cwd:$P/agentsmd

And a run:

codex login
./agent "inspect this repository and explain it"

Everything else comes naturally from this design:

• A subagent is agent run from sh. It inherits the environment and gets its own conversation. The parent configures it with environment variables, AGENT_MODEL=... agent "...". By default the parent sees only the subagent’s final output, but its state can be read from its session file, and more advanced interactions can be implemented as plugins.
• The harness is repairable. A sufficiently smart model that has read its harness can work around its limits, or change them.
• You can put hip-agent in a skill and let your existing agent spawn subagents through it. The code itself is the documentation.

Why not native subagents?

Why a new harness when current models are already trained with subagents?

1. Models don’t always perform best in a fixed harness, and as models get better a fixed harness can become the limitation. hip-agent is not a fixed harness. It is a reference implementation, deliberately small so that an agent can read, modify, and adapt it.
2. You can train the model to use it. Future models can follow the hip-agent approach, building and editing their own subagent harness depending on the task.

Results

I did a few iterations of the code on Terminal-Bench 2 with gpt-5.6-luna at effort max: improved the shell design and the prompt a bit, added the view_image tool and command timeouts. Otherwise the code and prompt changes were minimal and not bench-maxxed.

The final code was then evaluated on DeepSWE, 113 tasks, against a Codex CLI 0.147.0 baseline. The results show hip-agent performs comparably with Codex CLI.

One run each, no error bars. The two runs ran concurrently on two local machines with the same CPU but otherwise different hardware. Token usage is not compared because hip-agent does not log it.

Conclusion

Almost every model provider now ships its own TUI harness. But nobody has time to try them all.

It also makes evals hard. A benchmark run measures the model and the harness together. OpenAI found that ARC-AGI-3’s harness dropped the model’s reasoning between moves. Turning on two settings that Codex uses by default tripled the score. On the other hand, a user-facing harness changes every week, and not every change is an improvement: Anthropic’s April postmortem documented how a harness can silently degrade the result when the model is unchanged. A user-facing harness is therefore a poor instrument for evaluating a model.

Ideally, every model builder would ship a minimal native reference harness, like hip-agent. A native reference harness is like a tool parser or a chat template: it describes how the model was trained to interact with the world. It should be separate from the model provider’s user-facing product. It also makes trying a new model easy: a user can ask their existing agent to run the new model as a subagent.

Related work

• mini-swe-agent shares the bash-only principle and has a ~100 line core, but it is designed with abstractions to work with any model and environment. hip-agent commits to one provider and one OS. This keeps the full code smaller and allows vendor-specific features like Codex’s compaction and resumable Codex sessions.
• llmproc and agent-environment-middleware are my earlier work exploring agent harnesses and abstractions like plugins.
• Codex app server is the low-level interface Codex CLI and the other Codex apps use (the VS Code extension, the desktop apps). It bundles a lot of app-specific logic and is not a lowest-level reference for the model loop. I had an agent dig into it to figure out the correct way to use compaction, the websocket API, etc.

It's 2 am. You've stayed up all night trying to get your program working. You finally figured out that one bug. The singular thing stopping you from running your new program end to end. The relief! You have accomplished something incredible.

The next day, still feeling the high from this sense of accomplishment, you go to show your loved one the program you've made. After breaking a world record for the number of caveats and hedge words a single sentence can contain, you show them a few flashing words in a terminal window. The glaze passes over their eyes. Your accomplishment, however great it is, is simply that, yours. No one else is going to understand.

Understanding What is Done

This style of progress is one of the big barriers that I've seen keeping people out of programming. Countless teaching tools have been made that try to circumvent this problem, to give learners something that they can see as a big accomplishment and that they can share with others who can see as well. This is one reason games are such a popular format for teaching programming. But the reality has always been that progress in programming starts invisibly. Software in development would always be in a state of not working, not demoable, not flashy, long before it became "real software".

AI has flipped this on its head. Creating something flashy, something demoable, something that appears to work is perhaps the easiest thing to do. But it is more than that. Even for software with no flash, the gaps in the program, the parts that don't work yet, take on a completely different shape than they do in a human-authored program.

Cracks or Chasms

In a program written by a person (especially a singular person), there are just obvious whole parts missing. A parser might not accept full input, a button might not do anything at all, a page may just be missing. Now, of course, exactly which parts are missing will depend a bit on the person, what they want to work on, what they want to demo, or circumstances like that. But in my experience, they are mostly predictable.

AI codebases are simply not this way. Or, to put it more exactly, they are predictable in an entirely different way from human predictability. AI written programs are great at giving the illusion of a fully written, fully working solution. They will write endless tests, give endless benchmarks, show immediate speed improvements. And yet, if you try to use the program for anything other than the demo, it can immediately crash, or leak memory, or hang indefinitely. Not that human-written programs don't do that. But for me, I have a good intuition of where these things will occur that has now been violated.

This isn't a comment on the code quality of AI codebases. Nor a comment on what can be ultimately achieved with fully AI written, AI reviewed codebases. It is a comment about this shape incomplete AI codebases often take. For human-authored code, you can see the cracks forming before you drop off the cliff. For AI codebases, the chasms are deep, hidden, and often impossible to climb out of.

The Need for Rewrite

One of the things I remember about my earlier adventures in programming was the constant rewrites I found myself doing. A program would rise in complexity as I kept working on it until it would collapse under its own weight. I would start seeing how much harder it was to add new features and either abandon or rewrite it. As I got more experienced, this happened less often, but when I would try projects that pushed me out of my comfort zone, this pattern reemerged.

I've found this same pattern with AI rewritten software. But here, because I am being hands-off, it is much less easy to see it occurring. Rather than a cognitive wall being hit where I can no longer hold the program in my head enough to make progress, I see an AI agent consistently lying to me about the progress that is being made. Whole entire sets of features of the application may no longer work, tests may have been rewritten to "pass" in the face of failure, and if I'm not careful, I won't even notice.

Or worse, I see real improvements in every area of my program I ask to test, but rather than true proper engineering, we have special-cased our way to something wholly unusable for anything other than showing off that our software is the "fastest" solution to ever exist. Attempting to rescue these now utterly ruined pieces of software becomes a nightmare. No amount of lints, tests, or metrics will climb you out of the chasm your agent has been so thoughtfully and cheerfully carving for you. So what can we do? Rewrite.

The Alternative?

I didn't write this post with some pat moral lesson in mind. Nor did I make it to bash vibe-coding. But simply to call out the pattern I've seen. I have found that this is happening to me less often now than in my earlier explorations of agents. Not only with smarter models either. I think it's because I've begun to be able to predict where those shapes are going to be. To nudge things in the right direction. But for me, and the kinds of problems I enjoy, I'm still not sure if there is a good answer on how to codify this. I think instead my intuition for where these problems will occur, when to check on them, how to nudge in the right direction has just been honed. So if you find yourself in the same state, first know you're not alone. But if I had to offer any advice, think back to those novice moments. Think back to when programming was new and hard. Think back to the patience it took to learn a new way of thinking. Perhaps there are valuable lessons to be learned there.

Machines that think, Part 3: embodied intelligence

The comforting story this time is a story about transfer. Vision is solved. Language is solved. Robotics, with AI going embodied, is simply an integration problem: Take a model that already understands the world, connect it to an arm and a camera, and the competence flows downhill into the machine. The hard part was the intelligence, and we have that now.

I spend a lot of my time with companies that build things with mass and momentum and have seen time and again how complex it is to combine mechanics, electronics and software into an integrated system. And if you’ve worked on the same type of systems, I think you’ll find the above story as hard to believe as I do.

Let me start with vision-language-action models (VLAs). VLAs are a substantial innovation, they work and they’re moving fast. Google Deepmind’s Gemini Robotics On-Device 2, published in July, takes a text instruction, images from the robot’s own viewpoint and proprioceptive data, and outputs actions. Crucially, it runs on the robot. No round trip, no dependency on a network. Robotics is the domain where the edge stops being a cost optimization and becomes a physical requirement, especially when there are safety concerns.

So, the capability is arriving. The problem is the training data. A language model is trained on the accumulated written output of humanity, which was produced for other reasons and happens to be lying around. There’s no equivalent corpus for manipulation. Every training example of a robot picking up an unfamiliar object in an unfamiliar pose has to be produced by an actual machine, in actual time, usually with a human teleoperating it. The data doesn’t exist until someone pays for a robot and an operator to generate it, one episode at a time, at roughly the speed of physical reality.

This isn’t a temporary shortage that scale will resolve; it’s a structural difference in how the two kinds of models get their competence, and it shows up in the results. A recent analysis of 1,228 vision-language-action papers published between February 2023 and June 2026 puts numbers on something the field has been quietly uncomfortable about. On the Libero benchmark, success rates that sit around 95 percent collapse to below 30 percent under modest perturbations of the scene. On another benchmark, performance went from over 90 percent to exactly zero. Not degraded. Zero.

Robots are great at repeating the exact same pattern, but even small changes tend to degrade behavior below acceptable norms. It’s not about a model that has learned to manipulate objects and is having a bad day; that’s a model that has memorized a set of trajectories and is being asked to do something fractionally outside them. And the honest players say so themselves: The Gemini Robotics On-Device 2 model card states plainly that it has “limited ability” to generalize to out-of-distribution tasks.

I want to be careful here, because this is easy to misread as robot pessimism, and it’s not. Robots work. They work extraordinarily well. The International Federation of Robotics counted 542,000 industrial robots installed in 2024 and an operational stock of 4.66 million machines worldwide, up 9 percent in a year. Those machines weld, place and palletize with a reliability that no language model comes close to. They achieve it by not generalizing at all. They’re programmed against a fixture, a part and a cell, and everything outside that envelope is engineered away rather than learned. This is traditional automation, not embodied intelligence.

The question isn’t whether robots work; it’s whether general-purpose robots do, and there, the evidence is thinner than the funding implies. The most instructive number I’ve seen this year is from BMW’s deployment of Figure 02 units, which accumulated approximately 1,250 operational hours over eleven months. Take a moment with that. Eleven months, and the machines were working under four hours a day across the calendar. For an industrial asset, that’s not a deployment; it’s an extended and expensive experiment. Meanwhile, venture capital put 40.7 billion dollars into robotics in 2025, and Bank of America projects on the order of 90,000 humanoid shipments in 2026. The gap between the capital and the operational hours is the whole story.

Of course, the first versions of ChatGPT were quite limited in usefulness and the progress since then has been phenomenal. With all the VC investment into robotics, we’ll see progress in this area as well, but LLMs have a corpus of training data that robotics can only dream of.

For a startup, this changes what you’re actually building. If the model is downloadable and the hardware is increasingly purchasable, then where’s your differentiation? To me, the answer is the apparatus that generates data in your specific slice of physical reality, and the tighter that slice, the better your odds.

Although the promise is general-purpose robots, the right answer is, in my view, exactly the opposite. Generality is a claim about a distribution and the only way to close a distribution is to bound it. A startup that picks one task, in one class of environment, with one gripper, can plausibly collect enough trajectories to cover the tail. And the tail is where all the value and all the liability sit. A startup that promises a robot that does everything has committed to a data collection problem it can’t finance. The correct question at the seed stage isn’t “How capable is your model?” but “How many hours of real-world interaction do you need before the failure rate is acceptable, and who’s paying for them?”

Think about autonomous cars, which could be viewed as a narrow, specialized type of robot. After well over a decade of promises, we’re still waiting for general availability. The solution was careful training in one city or even part of a city, as Waymo and others are doing. Or in logistics, autonomous trucks that only drive one stretch between a warehouse and a factory. The answer is to go as narrow as you can and still have a business case.

There’s a trap here worth naming explicitly, because the Libero numbers make it concrete. A demo is a sample from the training distribution. It tells you almost nothing about performance one step outside it, and the collapse from 90 percent to zero isn’t a gradual slope you can extrapolate along. Any investor or executive evaluating a robotics company should be asking to see the perturbation results, not the highlight reel. If a team can’t show you what happens when the lighting changes and the object is rotated forty degrees, they haven’t measured the thing that matters.

For large incumbents, the calculus inverts again, and in this case, it inverts in an unusually interesting way. Those 4.66 million installed machines represent the largest corpus of physical interaction data in existence. And almost none of it is being captured in a form that could train anything. Every one of those robots has been executing, logging and correcting for years. Whoever works out how to instrument an installed base and turn decades of industrial motion into training data has a genuine asset that no amount of venture funding can replicate, because the robots are already bolted to the floor.

The risk on the other side is disintermediation at the intelligence layer. If the model becomes the thing that determines what a machine can do, then a company that manufactures excellent arms and buys its intelligence from someone else has become a supplier of commodity actuation. For both incumbents and startups, it’s critically important to understand where the value sits going forward. As decades of digitalization have taught us, the value shifts from atoms to bits, no matter whether it’s software, data or AI.

There’s also a geographic fact here that echoes the first part of this series. Asia took 74 percent of new robot installations in 2024, China alone accounted for 295,000 units and Chinese domestic manufacturers now hold 57 percent of their home market, up from 28 percent a decade ago. The compute substrate is concentrated in a few places, and so is the embodiment layer – just not the same few places. Still, if the training data is the key restriction, I think it’s obvious where the most data from new robot installations can be collected and, once again, it’s not in Europe.

For society, the reflex is to go straight to employment, and that conversation is worth having, but it’s not the one I find most pressing. The more immediate issue is a mismatch in what we’re prepared to tolerate.

We’ve collectively decided that a language model being wrong some of the time is acceptable, because the cost of a wrong answer is that someone reads it and moves on. That tolerance doesn’t survive contact with a machine that has mass. A humanoid working near a person can’t be right 95 percent of the time; the production bar has to be well north of 99.9 percent. The difference between those two numbers isn’t incremental engineering but a different discipline entirely. Physical AI takes a technology whose defining characteristic is probabilistic behavior and puts it in a setting that has spent a century engineering probabilistic behavior out.

Even in contexts where no humans can be harmed because of probabilistic behavior, the financial consequences of robots damaging themselves, other robots, products or surrounding infrastructure simply destroy the business case. Systems that interact with the physical world need to be engineered with completely different reliability, robustness and safety requirements.

This is where the thread I’ve been pulling on since the summer becomes unavoidable. When the realization is a learned policy rather than written code, what you version and defend is the contract the machine must honor plus the running evidence that it still does. For a physical system, that contract has to specify not only what the machine will do but what it will never do, and the evidence has to be continuous rather than collected once at commissioning. We don’t yet have good engineering practice for this. We have benchmarks that collapse to zero under a rotation, which is roughly where software testing was before anyone thought to write down what a regression was.

The optimistic reading is that manipulation is a data problem, and data problems are the kind our industry knows how to attack once it stops pretending they’re model problems. The pessimistic reading is that the tail of physical reality is longer than anyone’s capital. My own view sits closer to the first than the second, but with the timeline stretched: Narrow, bounded, well-instrumented deployments will compound quietly for years before anything deserving the word “general” shows up on a shop floor.

Which is a modern restatement of something a roboticist worked out before most of this industry existed. Hans Moravec, in “Mind children” in 1988: “It’s comparatively easy to make computers exhibit adult-level performance on intelligence tests or playing checkers, and difficult or impossible to give them the skills of a one-year-old when it comes to perception and mobility.” We built the adult; we’re still working on the one-year-old.

Our new contrail avoidance trial in Asia-Pacific

We’re partnering with Cathay Pacific to test our AI-powered contrail mitigation technology, contributing valuable new data to global contrail research and advancing understanding of contrail formation and avoidance in the Asia-Pacific region.

Contrails are the thin, white streaks that form behind airplanes when they fly through cold, humid air. Most dissipate quickly, but some can persist and spread into cloud-like formations that contribute to warming by trapping heat in the atmosphere.

Contrails are responsible for roughly one-third of aviation’s total climate impact. And over the past few years, our efforts to reduce them have evolved from AI research models to real-world trials in the United States, across the North Atlantic, and now, in the Asia-Pacific region, the world’s fastest growing aviation market.

We’re partnering with Cathay Pacific, our first commercial airline partner in Asia to test contrail avoidance on ultra-long-haul flights. Our early trials ran over 80 flights and have achieved roughly 40% estimated reduction in the warming impact of contrails by following contrail-avoidance routes. We’re now expanding the trials to provide insights across Cathay Pacific’s Asia extensive global network, helping evaluate the operational feasibility of contrail avoidance while contributing to global contrails research.

Putting predictive AI into the cockpit

What’s exciting about avoiding contrails is that it can be very straightforward in theory. Aircraft adjust their altitude slightly to steer clear of cold, humid atmospheric zones where warming contrails are likely to form, much like pilots do to navigate around turbulence. Pilots and flight teams routinely make these kinds of small, planned adjustments for a variety of operational reasons, always within established safety parameters. These adjustments are not expected to impact passengers or the safety of the flight. Adjusting flight altitudes for contrail avoidance in practice means giving flight teams actionable data long before an aircraft leaves the gate, and then feeds that data to the cockpit. Building on our previous work deploying the contrail solution in live operations, we're partnering with Cathay Pacific to expand its use into the Asia-Pacific region.

Our system brings together AI predictions, satellite imagery, and advanced weather intelligence to pinpoint these contrail-forming zones in advance, allowing dispatchers and pilots to plan slight altitude shifts around them. In the air, Cathay Pacific connects these dynamic forecasts directly to the flight deck through in-flight Wi-Fi and its proprietary Electronic Flight Folder (EFF), giving pilots live insights alongside usual operational metrics without interrupting standard cockpit workflows.

Moving from proof of concept to scalable trial

We started an operational trial with more than 100 flights targeted across Cathay Pacific's network. More than 80 flights followed contrail-avoidance routes, with Google’s satellite imagery analysis estimating that these flights reduced the warming impact of contrails by roughly 40%. The Hong Kong–Singapore corridor was among the routes tested, as flights in this airspace frequently encounter conditions conducive to persistent contrail formation. Analysis from the trial indicates that interventions on this single route account for more than 50% of the trial’s total emissions reductions.

Now, we're scaling the partnership with Cathay Pacific on a larger second phase of trial flights and partnering with Contrails.org, a nonprofit initiative dedicated to advancing the science of contrail mitigation. The trials are helping build a broader understanding of how contrail avoidance could work across different operating environments on Asia and transpacific routes, and contribute to the growing body of global contrails research.

Contrail mitigation remains one of the most immediately available, scalable, and cost-effective ways to reduce aviation’s climate footprint, and it can get started now, with today’s aircrafts and fuel. By advancing open contrails research together, we hope to accelerate progress in contrail science and unlock one of the most promising and cost-effective climate solutions available to aviation today.

Arm’s C2-Ultra, G2-Ultra NX, and CSS N4 IP

Editor’s Note (9/8/2026): Arm has reached out to clarify that the maximum IPC increase of the C2-Ultra core over the C1-Ultra core using the parameters shown in the endnotes is 7% along with the memory bandwidth improvement not factoring into the IPC improvement. The article has been edited accordingly.

Hello you fine Internet folks,

While Arm’s last announcement was about their new datacenter focused CPU, the Arm AGI CPU. Their latest set of announcements bring a much wider focus. The incoming C2-Ultra CPU and G2-Ultra NX GPU IP will see broad use across flagship phones, with latter G2 Ultra already shipping in Xiaomi’s XRING O3 chip that launched on August 24th. While the new Neoverse CSS N4 IP will see usage in the datacenter space.

Hope y’all enjoy!

C2-Ultra CPU Core IP

Starting off with a comparison to the Cortex X925, the last ARM core we have good data on, with the limited information provided to us by Arm on C2 Ultra. We see limited changes when comparing to the two generation old Cortex X925.

Across both cores you have the same overall layout featuring 10 wide decode, 8 simple ALUs, 6 lanes of FP, 3 branch ports, and same 4 load/2 store config. So for C2 Ultra to get it’s performance boost, we’re looking at more iterative changes targeting a few critical structures like the branch predictor and OoO buffers.

Arm was unfortunately very vague with how it accomplished these branch predictor improvements. We don’t know if they modified BTB sizes, return stacks, or the branch algorithm as a whole.

Likewise they mention C2-Ultra has a larger execution window compared to C1-Ultra along with improved speculation, but go into no explicit details here.

All this means that C2-Ultra spends less time waiting for data compared to C1-Ultra.

Now, looking at the claimed uplift from C1-Ultra to C2-Ultra we see that Arm is claiming a 15% peak performance uplift with an average 12% uplift in traditional benchmarks and workloads.

However, the endnotes provide some important context for these claims.

Firstly, these numbers are from FPGA simulations so actual hardware may see different uplifts. Secondly, the C2-Ultra platform’s results are estimated with an 8.5% higher clock compared to the C1-Ultra along with a larger 3 MB L2 cache on the C2-Ultra platform that C1-Ultra does support and does ship with in the 3 MB L2 configuration in Xiaomi’s XRING O3 and Samsung’s Exynos 2600. According to Arm, while the memory system is providing nearly twice the bandwidth for the CPU benchmarks, the improvement to the memory subsystem is not factoring into the performance uplift.

When factoring the increased clock speed, the average uplift of C2-Ultra over C1-Ultra is 3.2% and this increase does include the extra 1 MB of L2 that the C2-Ultra has which may be adding a boost in some workloads.

Moving to the peak increase of 7% IPC over C1-Ultra that Arm reached out with, I assume that this number also does factor in the L2 cache increase as well. Geekbench 6 does appear to benefit from a larger L2 cache and a 3MB L2 seems to catch most L1 misses where a smaller L2 cache may not.

From my perspective, it does appear as if in the tested workloads, C2-Ultra hasn’t improved the performance per clock much compared to C1-Ultra on average with some workloads benefiting from a larger L2 cache that some designers may opt for.

Arm says that C2-Ultra uses 38% less power compared to C1-Ultra. However, this number does factor in node and implementation improvements so how much of this 38% decrease comes from the microarchitectural improvements is up in the air.

Arm also announced C2-Nano and C2-Pro as well, however these use the same underlying microarchitecture as the C1-Nano and C1-Pro cores.

G2-Ultra NX GPU Core IP

Moving to the GPU IP, Arm says that Mali G2-Ultra NX is “The largest re-architecting of the GPU IP in 7 generations."

The amount of math that a G2-Ultra NX shader core can do hasn’t changed. It still has 128 FMA units which equates to 256 FP32 FLOPs per clock or 512 FP16 FLOPs per clock. The maximum number of shader cores allowed in a G2-Ultra NX GPU, 24 G2-Ultra NX shader cores, also hasn’t changed.

G2-Ultra NX has increased the number of registers that a warp can access from 64 to 128 along with improving the granularity of register access so that G2-Ultra can now allocate registers at a granularity of 16 registers. And along with these improvements, the register file has also increased by 25%.

Arm has also improved the RT units in G2-Ultra NX by making the triangle structure that the RT unit works on more compact which according to Arm reduces the DRAM traffic by 13% due to an elimination in redundant data which allows more data to fit into cache.

Arm has also added Opacity Micromaps to G2-Ultra NX which brings a desktop GPU feature down into the mobile sector.

Another desktop GPU feature that Arm is integrating into G2-Ultra NX is a matrix accelerator into the Shader Core. This matrix accelerator can do up to 1,024 INT8 MACs per clock or 512 INT16 MACs per clock and it can clock up to twice the clock that the Execution Engines can clock to. However, a glaring omission is that the matrix accelerator only supports INT8 and INT16 but not formats such as lower precision like FP8 or the larger yet very popular format BF16 which also isn’t supported on the standard ALUs either.

Arm also doesn’t require every Shader Core in a G2-Ultra NX GPU to have a matrix accelerator but does require a minimum of 6 “NX cores” for the Ultra branding.

Xiaomi decided for their G2-Ultra NX implementation on their brand new XRING O3 that only half of the Shader Cores would implement the matrix accelerator.

Comparing the structure sizes of the cores with and without the matrix accelerator, a G2-Ultra NX shader core with a NX unit ends up being about 1.88 mm^2 and without the matrix unit a G2-Ultra shader core is about 1.55 mm^2 which means that the matrix unit adds about 21% to the area of a shader core.

The added matrix units have allowed Arm to introduce their own version of ML-powered upscaling called Neural Super Sampling (NSS).

Arm is also introducing their Frame Rate upscaling technology with the G2 generation.

With all of changes to the GPU IP, Arm is claiming up to 14% improvement in games and up to 24% in Ray Tracing benchmarks compared to last generation.

However, the G2-Ultra NX GPU is clocking about 11% higher compared to the G1-Ultra GPU in these comparisons which imply that these changes may not improve non-RT games much.

Neoverse CSS N4

On the server side, Arm has also announced that Neoverse N4 CSS will become available for their partners.

Sadly, this is the one slide that Arm had about Neoverse CSS N4. When asked, Arm did give out more information:

• CPU: 8–128 Neoverse N4 cores per die, the widest core-count range offered in a Neoverse CSS, with frequencies up to 3.8 GHz.
• Scaling: Supports multi-chiplet and multi-socket designs for scaling beyond a single die.
• L1 cache: 64KB instruction and 64KB data cache per core.
• L2 cache: Up to 2MB private L2 cache per core.
• System-level cache: Up to 256MB shared cache per die.
• Memory: Supports DDR5 or LPDDR6, providing flexibility across capacity, bandwidth, power and system design.
• I/O: Up to 128 lanes of PCIe Gen 6/7 and CXL 4.0.
• Chiplet connectivity: Arm chip-to-chip interconnect with support for UCIe or partner-specific PHYs.

There are still a number of questions about what core is N4 using, what is the width of the memory bus on a single die, what is the number of PCIe lanes on a single die, among others.

Conclusion

Something that I should mention is that Arm’s technical disclosure this time around is disappointing. To Arm’s credit, the company did answer questions when asked and that responsiveness is appreciated, however it is frustrating that those questions were necessary to fill gaps that should have been addressed in the presentation. If we had been given the quality of information comparable to prior Arm announcements, we would have spent longer on analyzing the microarchitecture in our more typical fashion.

C2-Ultra is a good example of this problem, with claims about improved branch prediction and speculation giving little information of what actually changed, while the performance figures combine those core changes with higher clocks, a larger L2 cache, and more memory bandwidth. Moving to the power figures which include process and implementation improvements, we are left with the question about how much is the new microarchitecture contributing to the power decrease. These numbers are particularly frustrating for an announcement about CPU IP where comparisons at equivalent clocks and memory configurations would have been useful.

G2-Ultra NX gives more details, particularly around register allocation, the addition of matrix accelerators, and the improvements to the ray tracing units, however describing it as “The largest GPU rearchitecting in seven generations” creates an expectation of technical depth that wasn’t delivered. The matrix accelerator’s limited precision support also raises questions about its usefulness beyond the workloads Arm has chosen to target and I would have liked Arm to spend time explaining in the presentation why. And CSS N4 takes the lack of detail to an extreme with one slide with basic information about the product having to be asked.

Arm has IP and products worth talking about, but the presentation does a poor job of communicating them. The technical substance should be in the presentation from the beginning rather than something we have to assemble through follow-up questions and emails.

Do you ever struggle to get ChatGPT to emulate your tone, style, or voice? You may soon be able to connect your sent messages through third-party services so that ChatGPT can learn your writing style and better copy you in the future.

The feature is in testing with a select group of users, first spotted by Gael Breton on X before being reported by Bleeping Computer. Breton’s post shows the feature, with a description: “ChatGPT will write in your voice by referencing examples from your connected apps.”

In the example, it breaks down the connected apps into Documents, Email, and Messaging with Slack, Notion, Google Drive, and Gmail, all visible. It may also be able to use other connected apps via ChatGPT's tools for third-party services.

In reply to the post, another ChatGPT user said they’ve had access to the feature for weeks and found it to be a “game changer.” It’s unclear whether the app will read everything sent through the connected app once or periodically refer back to it to help adapt your writing style.

OpenAI has yet to officially announce this tool, but it often tests new ideas with select users ahead of launch. PCMag was unable to activate the feature during testing.

If you have the option, you’ll find it in Settings > Personalization > Writing. There’s a toggle called Reference my writing style, which, if available to you, can be toggled on or set up by pressing Set up writing style in the description.

OpenAI has already had a particularly busy September, including the release of its new Astra model and the disclosure of another incident involving GPT-powered agents. A group of researchers discovered that OpenAI agents had made over 15,000 edits to the German database DseWiki, a resource for coders.

Rentosertib is a drug created with the assistance of AI. The AI originally indicated that the drug could help treat patients suffering from a chronic lung disease, but data from clinical trials show it could also slow the aging process. The drug reduced the biological markers of age as measured by six 'aging clocks', a different kind of AI technology designed to predict a person's morbidity and mortality. While the drug shows promise, it is still years away from regulatory approval, even for use in sick patients.

What We Can Learn from Claude's Fable 5.1 System Prompt

A couple notes on Claude’s Fable 5.1 system prompt. As I’ve written, looking at changes over time reveals product design decisions and more.

Comparing Claude’s Fable 5.1 system prompt to its Fable 5.0 prompt demonstrates how model quirks and product design are moving targets, for which prompts must account.

Lists and Bullets

Claude uses lists and bullet points when asked to or when the content is multifaceted enough that they help with clarity. Claude uses the minimum formatting needed for clarity. If the person explicitly requests minimal formatting or for Claude to not use bullet points, headers, lists, bold emphasis and so on, Claude should always format its responses without these things as requested. Claude never uses bullet points when declining a task; the additional care helps soften the blow. In friendly, personal, or emotional chats Claude doesn't use formatting. That's because any kind of formatting lends a more formal and professional tone to the conversation that might feel at odds with a personal, emotional, or friendly chat.

When I try to describe why Fable 5 and Opus 5 are terrible writers, my most concise take is that they write in bulleted lists while actively avoiding bullets. Short, curt points compressed into dense paragraphs.

This was partially due to a system prompt that specifically discouraged bullets, but never stated why. Fable 5.1’s prompt dials this rule back and gives us a motivation while defining an exception: bullets make Claude feel less personal and friendly.

It’s a good example of the challenges labs face as their user base grows. System prompts have to work for an exhausting array of audiences and use cases (after all, you can put anything in the chat), which results in case statement juggling like this.

Claude avoids saying "genuinely", "honestly", or "straightforward". Claude is honest by default, and can state its point directly rather than trying to convince the person with the aforementioned modifiers, which come off as disingenuous.

Good example of a system prompt “hot fix”.

The overuse of “honestly,” either was hard to train out of 5.1 or they filed a bug too late. Either way, this note is being delegated to in-context instructions.

Interestingly, this is something they’ve wrestled with when writing prompts for Opus. On a whim, I checked to see if the “honesty” instruction was present in Opus 5 and went down a rabbit-hole, analyzing what guidance has phased in and out over model generations:

• Don't use asterisk emotes
• Don't use emojis
• Search before answering
• Avoid lists and bullets
• Avoid reflective listening
• Don’t cite the knowledge cutoff
• Avoid “honestly”
• Avoid “straightforward”
• Avoid “actually”

With each generation, many system instructions are targeted during training, rendering them moot. Sometimes this sticks, other times we get regressions, as with “honestly”, “straightforward”, and “actually”.

User Wellbeing

Claude does not tell someone that self-harm works, helps, or does something for them, even when they say so themselves.

I’m sure Ant is including rules like this in its alignment post-training, but it’s hard to get this right when safety concerns conflict with other product design elements (user affirmation, which we’re all too familiar with).

Here, a serious issue gets an extra nudge in context. Hopefully this overrules the models trained desire to be a people-pleaser.

Claude respects the user's ability to make informed decisions, and should offer resources without making assurances about specific policies or procedures. Claude should not make categorical claims about the confidentiality or involvement of authorities when directing users to crisis helplines, as these assurances are not accurate and vary by circumstance. Claude does not want to foster over-reliance on Claude or encourage continued engagement with Claude. Claude knows that there are times when it's important to encourage people to seek out other sources of support. Claude never thanks the person merely for reaching out to Claude. Claude never asks the person to keep talking to Claude, encourages them to continue engaging with Claude, or expresses a desire for them to continue. Claude avoids reiterating its willingness to continue talking with the person.

An interesting deletion!

I would love to see the data behind why this got removed. In the best case, it led to abrupt conversation endings that weren’t suitable. In the worst case, it’s lead to less use, worse retention.

Sensitive Information

• Socioeconomic status or financial details: income or salary (including invoices for someone's own work), net worth, account and savings balances (including the amount saved so far toward a goal), debts, credit scores, financial hardship (recurring payment amounts — rent, mortgage, car, loan — are not financial details and are storable; neither are pay frequency, which bank someone uses, prices, bills, budgets, or savings goals)

This expanded definition of financial details with more examples provides a good hint at tasks people are increasingly using Claude for. The increased details suggests these requests occur often enough to generate sufficient incidents to warrant a rewrite.

Core Search Behaviors

Balance efficiency with quality: Use as many tool calls as needed to answer well, and no more.

One question I keep having, and am often asked, is why existing skills kind of broke with Fable and Opus 5. Anthropic talks about the problem plenty, advising people to dramatically simplify their skills, or remove them entirely. Mike Taylor caught the bug in his initial Fable review, when using an existing PPT creation skill that yielded terrible results with Fable. He deleted a good chunk of the instructions and got much better results.

When people ask me about this, they’re understandably confused: “If Fable is smarter, can’t it sort my skill out by itself?” I never had a good answer for that (other than, it’s not smart, just very good software with its own quirks) but this side-by-side here suggests a motivation: improved instruction following.

Labs train models to be good instruction followers. It’s job number one, really, but it’s not as clearly defined an attribute as you might think. Consider how you give instructions to your kids: I might ask my son to clean his room and walk in to discover everything that was on his floor is now assembled into a precarious pile on his desk. Nailing user intent is hard.

Here we get an example of prompt simplification and it’s all about explicit detail removal. All numbers are gone, instructions are stated once and not repeated. Perhaps the old instructions yielded a Claude that followed the suggested number of searches too literally. Rather than give it a hard and fast rule, Claude gets guidance now. Perhaps it uses better ‘judgment’ and/or perhaps this specific task had some heavy post-training work.

Comparing these prompts help us understand that models are a moving target. Labs cultivate them to perform against the attributes they care about, and these new skills and biases might clash with what you need. For sustainable systems, we should all have ways to measure how new models affect our systems and (better yet) mechanisms for evolving our instructions so we don’t fall into prompt debt and get stuck on yesterday’s models.

Do we need simplicity?

Recently, I gave a talk titled "Precise, consistent, and reliable code coverage". It's about a truly gnarly bug that took my company 9 months to debug. At the end, my friend Predrag asks:

How would you recommend that we think about building tools such that these epic debugging stories aren't as necessary?

and I answer him:

We need to prioritize simplicity. If you go back to my coverage pipeline, there are a lot of nodes in this diagram. [...] The tooling's complicated. We need to rethink how our computing works.

I'm not satisfied with that answer.

Unix pipelines are not simple

Consider two programs to calculate the frequency of words of a file. First, a small unix pipeline:

cat README.md \
  | tr --complement --squeeze-repeats '[:alpha:]' '\n' \
  | tr A-Z a-z \
  | sort \
  | uniq --count \
  | sort --reverse --numeric-sort

This says "read README.md, translate each word boundary into a newline, collapsing multiple newlines, convert uppercase to lowercase, count the number of occurrences of each word, then show them in frequency order".

I think this is what most people think of when they think of "simple": each program is small, they're designed to be joined together ad-hoc in this way, it's concise and somewhat easy to read.

Next, consider a Clojure program:

(->> (slurp "README.md")
     (re-seq #"[a-zA-Z]+")
     (map str/lower-case)
     frequencies
     (sort-by val >)
     ; for every (word, count) pair in the sequence, call an anonymous function that prints it.
     (run! (fn [[word count]] (println count word))))

This does the same thing, with a few more names and higher-order functions thrown in.

Now, let's say we want to make a small change: show the output in the original file order. In Clojure, this is fairly straightforward: store an ordered sequence of the words in word_seq, store a map from each word to its frequency in freq_map, iterate over the sequence, and look up each word in the map:

(let [word_seq (->> (slurp "README.md")
                 (re-seq #"[a-zA-Z]+")
                 (map str/lower-case))
      freq_map (frequencies word_seq)]
  (->> (distinct word_seq)
       ; for every distinct word, in original order, print its frequency (from our `freq` map) and the word itself
       (run! (fn [w] (println (freq_map w) w)))))

In Bash you need a bunch of temp files and ugly opaque regexes, sorts, and joins:

tr < README.md --complement --squeeze-repeats '[:alpha:]' '\n' \
  | grep . > words
sort words \
  | uniq --count \
  | sed --regexp-extended 's/^ *([0-9]+) (.*)/\2 \1/' \
  | sort > counts
nl --body-numbering=a words \
  | sort --key=2,2 --key=1,1n \
  | uniq --skip-fields=1 \
  | sort --key=2,2 > firstseen
join -1 2 -2 1 -o 1.1,2.2,1.2 firstseen counts \
  | sort --numeric-sort \
  | cut --delimiter=' ' --field=2,3

That's because our original program was small but not simple.

What is simplicity?

In Simple Made Easy, Rich Hickey defines "simple" from its root, "sim-plex": having only one braid. He contrasts this to "com-plex": braiding multiple things together. In this post I'll use "coupled" as a synonym for "complex" to avoid ambiguity.

And that gives us a language to talk about what's going on with our first Unix pipeline: it's small but it's coupled. Let's look at exactly what makes it that way.

tr < README.md --complement --squeeze-repeats '[:alpha:]' '\n' \
  | tr A-Z a-z \
  | sort \
  | uniq --count \
  | sort --reverse --numeric-sort

There are a bunch of little things here I could nitpick, but the main thing that's coupled (braided together) is the sort | uniq --count. If we look at uniq's man page, it says this:

Repeated lines in the input will not be detected if they are not adjacent, so it may be necessary to sort the files first.

There's no native Unix equivalent to frequencies, this sort | uniq -c is the closest we can get. Not only is it less performant (it has to collect the full input into memory before continuing), but it ties aggregation to ordering. This is exactly the thing that makes "separate ordering from aggregation" so hard; we end up having to do this weird dance with table-joins-through-text-files.

You might have heard the phrase "Write programs that do one thing and do it well" in reference to Unix systems. Maybe you heard it called the Unix Philosophy. I think "do one thing" is commonly understood to be about simplicity, but in practice it's actually about size. Unix tools are small but they are not simple.

Large is not the same as coupled

Now, let's consider the opposite end. Say you have Google Drive for Desktop running on your computer. This is a massively large program: it depends on platform-specific file watchers, "all of Google3", a streaming and syncing network client, and conflict resolution logic. But to the user it feels quite simple: Install the program, tell it which folder you want it to watch, tell it whether to keep the files locally or primarily on Google's infra. It does all the rest.

Decoupling

When I think about complex programs, I think about coupling. Programs are complex when different features are coupled to each other, even when they don't have to be.

Let's take one small example. In Rust, you can associate names to values with a map, or with a struct:

struct HttpResponse {
  status: u16,
}
let strukt = HttpResponse { status: 200 };

let mut map = HashMap::new();
map.insert("status", 200);

println!("map: {}", map.get("status").unwrap());
println!("struct: {}", strukt.status);

It's very clear from this that a struct gets you known present fields. For the map, we have to call unwrap(), because the type checker doesn't know what keys are in a map. For the struct it does, so we can just directly access the value.

What might not be clear about this is that a struct loses runtime information. If you want to iterate a map, that's easy: call for (key, val) in map { .... If you want to iterate a struct ... get fucked? write a proc-macro?

The reason for this is that in Rust, a struct couples type-checking to a fixed data representation. You can't get one without the other.

Contrast this to Clojure, where you can. In Clojure, structs are maps: rather than defining a type, you annotate which fields a map is allowed to have. If we wanted to translate our struct HttpResponse, we could write this:

; bind the name `http-response` to a list of keywords (interned strings).
; this is a normal list that is created and manipulated at runtime, it is not special in any way.
(def http-response [:map [:status :int]])
; bind the name `print-resp` to a function.
; `^{}` is a "metadata" map that will be associated with that name.
; metadata on bindings can be retrieved at runtime.
(defn ^{:malli/schema [:=> [:cat http-response] :nil]}
  print-resp [map]
  (println "status:" (:status map)))

Here, we've created a type annotation that's checked at runtime with the function (malli/instrument!). Notably, this is checked with a library (Malli), not by a compiler; and the annotation is inspectable. You can, for example, write a schema->md function that acts as your own little mini Rustdoc, without needing to integrate with compiler APIs. And all of this works without giving up type safety, reflection, or iteration over the values of the map.

This works because Clojure decouples data representations from type checking. Typed Racket does a similar trick, but using macros so that the type checking happens at compile time instead of runtime.

When is it useful to be small?

Being small makes sense when you as the maintainer don't have a lot of resources to dedicate to your program. Maybe you're Brian Kernighan and your program is running on a literal PDP-11. Maybe you're an open source maintainer with only a couple hours a month to dedicate to your project. Maybe you work in an environment where doing anything is a victory and you can only get support for a small subset of the features you actually want to build. All of these are good reasons to keep your program small.

But small is not the same as simple. The answer to "when should your program be simple?" is: always. There is very little advantage to introducing coupling to parts of your program; it makes it harder for you as a developer to maintain the program, and is less flexible for your users.

How do we make simple programs?

Ah, now this is the hard part. To write simple programs, you need to have a good mental model of your program. You also need to have good taste, which is something I don't yet know how to teach.

Sometimes, you also need to Suck It Up And Write The Hard Thing. CSS and SQL are highly decoupled: you write a declarative specification of what you want the program to do, and the browser engine or database runtime figure out how to do it. This is really really hard! SQLite alone has had centuries of person-years put into them making it work reliably. Blink (Chrome's renderer) has probably had tens of thousands of person-years put into it. In some domains, that's what it takes to let you write programs that are decoupled.

It doesn't always make sense to spend that much time on a program. Crunchy technical work can be a mothlamp problem: it attracts a certain kind of person who loves dreaming about how code might, should, could work. Sometimes it's better to put down your tools and take a nap in the sun instead. But when it does work—

If we go back to the start of the post, the coverage pipeline I describe actually got larger after I fixed it, not smaller. But at the same time it got simpler, because there were fewer hidden dependencies between parts of the dataflow graph.

What next?

I hope this post encourages you to write programs that are simple, not small, and to look for tools that you use that are unnecessarily coupled.

In a future post, I hope to extend these ideas: how to develop your sense of taste; how programs can be vertically integrated while still being decoupled; and how to build large systems without making them complex.

Tesla Cybercab Specs: Supermanifold V3, No Rare Earth Magnets & More

Last week’s launch event and official engineering documentation have pulled back the curtain on Tesla’s purpose-built autonomous platform.

Between public regulatory compliance filings and newly published rider handbooks, not to mention last week’s launch event in Austin, we now have a comprehensive breakdown of the dimensions, mechanical packaging, and custom thermal hardware powering Tesla’s Cybercab.

The technical deep dive arrives right as Cybercabs begin offering commercial public rides in Austin and was made possible by information shared by @SawyerMerritt and @itskyleconner. While attendees experienced the vehicle firsthand during the official Cybercab launch event last week, the newly revealed hardware details demonstrate how radical cost engineering shaped every component.

Supermanifold V3 and Rare-Earth-Free Drive Unit

Thermal management is anchored by an evolved cooling loop called Supermanifold V3, marking its first appearance on a production Tesla. The unified manifold eliminates standalone external valves and plumbing hoses while consolidating high- and low-voltage controllers onto a central block.

Tesla touted some of the hardware improvements in its engineering overview:

“We removed unnecessary refrigerant valves and lines and consolidated the high-and low-voltage controllers, reducing parts and complexity. Its modular design makes its production 80% automated and its operation 38% more efficient than other automotive thermal systems.”

Propulsion comes courtesy of a single front-wheel-drive permanent magnet motor outputting 163 kW (219 horsepower). The stator uses bar windings and a simplified lubrication circuit, allowing the drive unit to be assembled in under ten seconds. The complete assembly is 18% smaller and 25% lighter than competing electric vehicle drive units.

Elon Musk confirmed that the motor doesn’t use any rare earth metals, avoiding critical supply chain bottlenecks:

“The Cybercab motor uses no rare earth metals, but maintains the same range! This was extremely hard to achieve.”

Energy storage relies on a structural pack featuring dry-cathode 4680 cells with a calculated usable capacity of 47.6 kWh. The battery is engineered to endure 500,000 miles of continuous DC fast charging and harsh temperature swings. In preliminary multicycle range testing, the setup achieved an unadjusted 418.2 miles, which translates to roughly 293 miles under typical EPA 5-cycle adjustments at an efficiency rating of 6.16 miles per kWh.

Chassis Engineering and Autonomous Sensor Suite

Under the injection-molded gold exterior panels, the chassis skips standard automotive fluid lines. Braking relies on individual electromechanical brake-by-wire actuators on each caliper without a central hydraulic master cylinder or brake fluid. The steer-by-wire steering rack is mounted behind the front drive unit, operating on an updated 48-volt electrical architecture.

Autonomy compute is powered by an improved self-driving computer based on Hardware 4 architecture with iterative silicon updates. Tesla hasn’t revealed the exact specs, but we know it’s more powerful than what consumer vehicles are currently being sold with. The accompanying sensor suite consists of nine cameras: eight outward-facing units monitoring surroundings and one cabin-facing camera. The internal camera scans between trips to check cabin cleanliness and spot left-behind belongings, illuminating a green onscreen icon whenever it is active. Tesla is building out a network of Robotaxi hubs to clean and charge vehicles between rides.

Rider safety relies on an overhead radar module mounted near the dome lights that acts as an Occupant Classification System. The radar determines whether a seat is empty, occupied by a child seat, or seating an adult, enabling or disabling passenger airbags automatically. Airbag protection includes front, knee, curtain, and dual seat-mounted side airbags.

Exterior Dimensions and In-Cabin Packaging

Despite the Cybercab’s small footprint, interior volume is roomy. With no steering column or pedals taking up space, the cabin provides 43.4 inches of legroom, 38.3 inches of headroom, and 50.1 inches of hip room. The seats slide forward and backward as a single linked bench, while each backrest reclines independently. There’s no active heating or ventilation for the seats, but the Cybercab will already be warm when it picks you up. Individual air vents allow each rider to turn off their own climate airflow manually.

The rear cargo area holds two checked bags alongside two carry-on suitcases, or a folded stroller or compact wheelchair. Child seats must be secured using vehicle seat belts, as the seats lack lower LATCH anchors.

Cabin entertainment centers around a massive 22-inch touchscreen. While riders can already plug in game controllers, Musk recently teased that you’ll be able to plug gaming consoles into Cybercab down the line. Built-in USB-C ports keep mobile devices charged (there’s no wireless phone charging), and Cybercabs are being built with integrated Starlink dishes for low-latency satellite connectivity in the future.

By pairing Tesla’s ultra-lean “Unboxed” manufacturing process with autonomy, the Cybercab establishes an unprecedented benchmark for purpose-built fleet efficiency.

The moment I started caring about this was not a code review. It was watching an agent get lost in its own code.

It had been working on a project for a while. Every time it needed a helper, it wrote one. Some of them were near-copies of helpers it had written a few sessions earlier, with a slightly different name and one extra parameter. Nothing broke. Ruff was happy, mypy was happy, the tests were green. Then one day I asked it to change how a value was normalized, and it stalled. There were four functions that did roughly that. It read all four, picked one, changed it, ran the tests, found that two other call sites still used a different copy, patched those, and ended up modifying three of the four. It was not sure which one was canonical. Neither was I.

Duplicated code in an agent-written codebase does not only cost the humans. It costs the agent, on every later turn, because it has to re-read all the copies and guess.

What the usual pipeline does and does not check

Most Python CI in 2026 looks roughly like this:

- run: uv run ruff check src tests
- run: uv run ruff format --check src tests
- run: uv run mypy src            # strict = true
- run: uv run pytest -n auto

Ruff checks conventions: unused imports, shadowed names, bad comprehensions. It can also check function size and complexity if you turn on C901 or the PLR09 rules, though most projects I see do not, and the one below did not either. mypy checks that values flowing between functions have the shapes the signatures claim. pytest checks that behavior matches whatever tests somebody wrote.

What none of them do is look across functions. Ruff has no rule for "this block also exists in another file." Nothing in the pipeline knows which modules are allowed to import which. A helper that nobody calls anymore passes lint because it parses and passes mypy because there are no call sites to disagree with it. Before agents, a human reviewer caught these things by reading the diff. Agents produce diffs faster than humans read them, and that part of review quietly stopped happening.

Measuring a real repository

I ran a structural analysis over one repository at five points in its history. It is a few thousand lines of NumPy and SciPy with a CLI and an MCP server, mostly agent-written, with the CI shown above. The tool was pyscn, which I maintain. For complexity and dead code you can get equivalent numbers from radon and vulture, and import-linter covers dependency rules. Clone detection is the piece that does not have an obvious standalone answer in the Python ecosystem, which is a large part of why pyscn exists.

pyscn classifies a function's cyclomatic complexity as low at 9 or below, medium from 10 to 19, and high at 20 or above. The check command, the one meant for CI, fails by default on anything above 10.

I should be honest about this table. It is not a horror story, and I did not expect one. This repository was developed with pyscn available to the agent as an MCP tool, so it was getting structural feedback while it wrote. An A is roughly what you would hope for under those conditions.

What the table does show is that the average crept up, from 6.9 to 8.5 across the snapshots, while the grade stayed flat. No function reached the high band, so the summary never changed color. Eight functions at HEAD sit in the medium band, and pyscn check with its default threshold would have failed on all of them, but this project never ran check in CI. It only ever looked at the grade. Five snapshots are not enough to say the code got denser with every merge. They are enough to say that a grade is not a trend line, and that if you only look at the grade you will miss the trend.

The two most complex functions at HEAD are both at 19. One is a shape-validation ladder:

def _validate_dimensions(y, T, Z, R, Q, H, a0=None, P0=None) -> None:
    if y.ndim != 2:
        raise ValidationError(...)
    if T.shape != (n_state, n_state):
        raise ValidationError(...)
    if Z.shape != (n_obs, n_state):
        raise ValidationError(...)
    # ... six more of these

I looked at it and left it alone. It is flat, the error messages are good, and splitting it would not help anyone. A metric is a reason to look, not a verdict.

The other one I did not leave alone. In the CSV loader:

elif obs.transform == "level":
    if drop_first_row:
        transformed.append(series[1:])
    else:
        transformed.append(series)
elif obs.transform == "rate":
    if drop_first_row:
        transformed.append(series[1:])
    else:
        transformed.append(series)

Two branches, same body. This is the same habit as the four normalization helpers, just smaller: the agent writes the branch it needs right now and does not check whether an identical one is already sitting three lines up. Ruff says nothing, mypy says nothing, the tests pass.

The dependency check turned up one more. The package that exposes the tool to the AI assistant imports directly from the deepest numerical modules, skipping the layer in between. Whether that is a violation depends on rules I had never written down. I had an architecture in my head and nothing in the repository enforcing it, so the agent drew the graph however was convenient that day.

What actually helped

In this project the recurring problem was duplication. The agent would add a helper rather than check whether an earlier session had already introduced one, and it would write a branch rather than check whether the branch above it was identical.

The thing that reduced it was not a CI gate. It was giving the agent the checker as a tool it could call itself, in the same session, before I saw the diff. When clone detection reported a group, the agent could collapse it while it still had the context of why both copies existed. By the time a human reviewer sees a clone, that context is gone and the fix is a chore.

Beyond that, a few boring things:

Run pyscn check or your equivalent in CI, but gate on the delta. Fail when a PR introduces a function over the threshold or adds a clone group, not when the whole repository is imperfect. Otherwise the first run reports 200 findings and the check is disabled by lunchtime.

Track the average complexity over time, not just the maximum. The table above is why.

Write the dependency rules down, in import-linter contracts or whatever your tool reads. Agents do read prose architecture notes, but a contract that fails their build is harder to drift away from than a paragraph in CLAUDE.md.

Why bother

Code that is structured well is easier to maintain. Everyone knows that. What I had not appreciated until I watched an agent lose track of its own helpers is that it is also easier for the agent. One way to do each thing, small functions, and a dependency graph that points in one direction is a codebase an agent can read quickly and change safely. That is not a tax on AI-assisted development. It is what keeps the next thousand lines cheap.

Across Vercel, we use coding agents to design and build pages that have to look and feel like Vercel. The typography, color, and composition all need to carry the same judgment that we put into the pages we already ship ourselves.

We recently wrote about product-design, our skill that teaches agents how we design when they work in our codebases. The skill lives in each repository alongside the code that it governs, explaining how agents can find and understand our design system as well as product guidelines for whatever they are building.

This works great when agents are working in our codebases, where everything the skill needs is right there. But what about reports, proposals, and the one-off pages that still have to look like Vercel but get made in tools that can't read any of those files? For us, the answer was design.md, one public file any agent can load.

How we approached building design.md

What made product-design work well was that the design system and product guidelines were sitting right there in the repository for agents to read. We needed a way for agents and tools outside that environment to reach the same knowledge, so that the pages coming out the other end would still look like something we designed ourselves. That set two requirements:

• A single public URL that anyone can point their agents at, regardless of the environment they run in.
• Guidance covering everything that made product-design useful in the first place, from brand, layout, and copywriting to the design system, responsiveness, and information architecture.

The naive approach we tried first was to simply port product-design into a public prompt, collapsing the skill's reference files into one file any agent could read from a URL. The problem we found was that while the prompt described our visual language just fine, every model reading it interpreted that description differently, generating vastly different pages from the same guidance.

Part of this comes from the fact that design language is subjective. Phrases like "keep the layout clean" can really mean anything. What is "clean"? Beyond that, the bigger problem was everything else the prompt left behind. Inside our codebases, an agent reads product-design surrounded by real components and shipped examples of the things it describes. But a public prompt includes none of that, leaving every model to rebuild our style from just words alone.

So what we needed to do was distill what that environment provided into a single file, and the only way to know whether we were getting closer was to look at the pages coming out. We set the port aside and started writing a new file from scratch, this time testing every change against a repeatable set of eval prompts.

We wrote seven of them, pulled from real use cases and paired with mock inputs:

• Usage and performance report
• Renewal proposal
• Benchmark report
• Interactive planning page
• Build-versus-buy brief
• Security governance brief
• Presentation deck

The prompts stayed fixed while the file changed, so any difference in the output traced back to the guidance.

The first comparison

These evals gave us a way to measure both what the file was actually doing and how it was being interpreted by different agents. For our first test, we wanted to know whether design.md would actually change what a model produced at all. We ran the renewal proposal eval twice in the same environment with the same model, once without design.md and once with it loaded, keeping the prompt, data, and viewport identical in both runs.

Without design.md, the model generated a generic SaaS dashboard. But with it, the page led with the renewal recommendation itself, pulled the commercial evidence into one grid, put peer values on a single scale so they could actually be compared, and kept supporting detail available without letting it compete with the summary. This allowed us to conclude that the file changed the page’s structure and hierarchy as well, not just the styling like we originally found, giving us enough signal to keep building the guidance like this, one rule at a time.

The three parts that make the system work

As we tested and rebuilt design.md, the scope evolved into a three-part system that made the entire thing work:

• design.md supplies guidance that shows agents how to frame the reader's job, structure evidence, and choose a composition.
• A public stylesheet that defines a bounded, documented vocabulary of classes and tokens.
• An evaluation loop turns repeated human feedback into better guidance and deterministic checks.

Each of these layers covers a different slice of the work that creates a high-quality, on-brand Vercel page. The judgment that gets encoded in design.md gives agents guidance on:

• Shaping a page for both a quick executive read and a detailed audit.
• Writing copy with concrete claims and honest caveats.
• Composing hierarchy, typography, and color so that evidence and prose support each other.
• How to publish as Vercel, down to the asset rules for our wordmark and the triangle logo.

design.md also names the recurring generated-design patterns that we never want to see, allowing agents to recognize and avoid them far more reliably by giving the patterns names.

We created a stylesheet because agents kept inventing their own typography, spacing, and layout, so we took those decisions away from the model entirely. The stylesheet packages our design system's primitives, such as headers, tables, stat strips, and chart styles, as CSS that any page can use via a public URL. Then design.md documents the class names and tokens that the stylesheet provides, allowing the agent to build the page with those names in the HTML instead of reinventing them.

Another benefit to this is that the agent never actually reads the stylesheet itself. The stylesheet loads when the page renders in your browser, so none of the code enters the model's context, saving more room for design guidance instead.

Last, the evaluation loop is what helps make the other two pieces work. Deterministic checks are used to help catch mechanical failures, such as a table that ignores the width available to it, while people judge the subjective parts that can't be automated, like hierarchy, composition, and whether the page actually gives the reader what they came for.

How guidance made it into the file

Every line of guidance in design.md earned its place through the eval loop. We generated pages from fixed scenarios, reviewed what came back, encoded the corrections we accepted, and reran the scenarios to see whether each change stuck, since a change that helped one artifact could quietly hurt another. Nothing got in any other way.

Scenarios and rounds

Each of the seven prompts becomes a scenario, meaning the prompt is frozen together with its mock inputs and render settings. The renewal proposal, for example, always runs with the same fake customer data with the same viewport settings, keeping design.md as the only thing that changes between runs. A round means generating a fresh page from every scenario against the current version of the file. Full rounds cover all seven scenarios on both Claude Opus 4.8 and Codex with GPT-5.5.

If we want to investigate something specific, such as a rule change that only affects tables, we can rerun the affected scenarios or a single model, keeping iteration loops tight.

Generating all seven pages together also made them easy to compare side by side, and what stood out was that design.md wasn't pushing every page toward one template. The interactive planning page put its controls front and center, because someone opens a planning page to change the numbers and see what happens. The renewal proposal instead led with the recommendation and the commercial comparison behind it, because its reader is deciding whether to renew. Every page used the same Vercel typography, color, and spacing, but each one was structured around what its reader came to do.

Reviewing every run

To review the pages each round produced, we built a local app that displays full-page renders and runs blind A/B comparisons. This app eventually became our eval harness, running each scenario and storing the results. Each stored run keeps the prompt, inputs, model configuration, the version of design.md it used, the screenshots, and whatever feedback the reviewer left about it. Reviewers record every correction against the exact run that produced it.

Turning corrections into rules and checks

Each correction a reviewer records gets landed in the narrowest place that can consistently enforce it. Judgment changes go into design.md as prose, reusable mechanics go into the stylesheet, and anything that we can check mechanically becomes a deterministic check in code. Problems with the harness itself stay in the harness, and when a single model fails in a way the others don't, we keep it out of the rules until it repeats.

Take one of the early renewal proposals. Its commercial terms table came back squeezed to the same width as the prose, even though the page had room for the table to be twice as wide.

During review, we flagged that evidence tables should use the full width available to them. But when looking through previous outputs, we found this same failure everywhere. So this correction ended up going into two places:

• A rule in design.md stating the intended behavior.
• A deterministic check in code that catches the same layout failure the next time it appears.

Once this landed, later renewal proposal prompts resulted in pages with correct full-width tables. To verify changes like this one, we reran the affected scenarios after encoding them. At milestones we went further, running blind A/B rounds that put the updated design.md against an earlier version of the file to decide whether to keep, revise, or revert each change.

Measuring whether it worked

Building the file had taken well over 200 runs, counting full rounds, targeted checks, dry runs, and all of the dead ends. Alongside the human reviewers, a model judge wrote critiques for each round, and every round's feedback went into improving the next run.

After all of those runs, we wanted to know whether the corrections we had encoded were actually preventing the failures they were written for. So we picked three desktop scenarios, and for each one we had Codex with GPT-5.5 generate the page twice, once with design.md loaded and once without. We kept the first attempt from every generation, with no re-rolls. Then we ran our deterministic checks over all six pages and counted how many times a known failure, like a table that ignores its available width, showed up in each set. The pages generated with design.md had 39 of those failures. The pages generated without it had 91, which works out to 57% fewer in this test.

Those numbers come with two caveats. The checks can only catch failures we have already seen and written down, so this test says nothing about whether a page is well designed overall. Six pages is also far too small a sample to make claims about quality or reliability, and every one of them, with or without the file, still had at least one failure serious enough to block shipping. But what the test does well is tell us that once we name a failure and encode it, that failure tends to stay gone.

How design.md stays current

The eval loop got the file shipped, but what keeps it current is real usage. Inside our Slack, that usage comes through @design-agent, an agent built on eve that we use for anything from design critiques and copy alternatives to icon recommendations and report sites built from pasted data. Instead of setting up a prompt or hunting down source files, you just mention the agent in a thread. For website requests, it loads the current design.md, builds the page against the published stylesheet, and posts a full-page screenshot and deployment URL back to the thread. Unlike our fixed scenarios, each of these threads captures a real request, a real output, and whatever feedback or steering followed, showing us how the guidance performs out in the wild.

Every week, we gather all of that feedback in one place, the Slack threads along with comments from GitHub reviews and Figma. Automation groups the comments that keep repeating, and each repeated complaint becomes a proposed change. A person then reviews each proposal, checks whether the system already handles it, and decides where the accepted fix belongs, whether that is @design-agent, the product-design skill, design.md, the stylesheet, or a deterministic check. And if people start asking for a kind of page we have never tested, that request becomes a new eval scenario.

To know whether any of this is working, we count how often each kind of complaint shows up in similar work over time. Once we encode a fix, that count should start falling. When it does not, something about the fix is wrong. The rule might be unclear, it might not be loading when it is needed, the stylesheet might not have a primitive that can express it, or it might need a deterministic check instead of prose.

Build your own

You can build the same loop yourself, starting with one recurring artifact and one manual comparison.

1. Pick one repeated artifact

Use a recent task with a real reader and real inputs, like a proposal, performance report, benchmark, or microsite. Avoid broad goals such as "make it on-brand." Before generating anything, write down a short rubric. A good one checks that the supplied facts survived, that the reader's decision is clear, and that the correction you keep making by hand actually got resolved.

2. Save the baseline first

Generate the page once without any new design context, and save the prompt, inputs, configuration, and a screenshot. Keep that first output even if it looks rough, unless the harness itself failed. You cannot tell whether new context helped without a before.

3. Start from your last ten corrections

Collect the feedback you keep giving in design reviews, pull requests, or Slack, and rewrite each correction as something observable. That means writing Let evidence tables use the full available width instead of Make the table feel less cramped, since only one of those can be checked.

Put the decisions in one file with sections for scope, reader and task, observable decisions, and available primitives. That file is your first design.md.

4. Constrain repeatable mechanics

If your outputs keep inventing their own typography, spacing, or layout, publish a stylesheet and document the exact classes and tokens the agent may use. Keep your judgment in prose, and push the repeatable mechanics into CSS or deterministic checks.

5. Run one matched comparison

Generate the page one more time with the same input, model, and viewport, but now with your file loaded. Shuffle it with the baseline and score both against your rubric without knowing which is which.

You do not need a runner or a model judge to start, a single trial can reveal the large, obvious failures. To measure reliability, run multiple independent first-attempt trials (Anthropic's guide to evals for agents) and report how often the result holds.

6. Encode the correction

Review the output alongside whatever follow-up prompts you have to send, and then ask:

• What did the user have to repeat or steer manually?
• Is a rule missing or unclear?
• Can the stylesheet express the correction?
• Is the failure mechanical enough to check in code?
• Does the correction generalize beyond this output?

Update the guidance instead of hand-tuning the generated page. Your next comparison tells you whether first attempts actually improved.

Add tooling after the manual loop starts paying off:

• Include scenarios where the guidance should and should not apply.
• Keep a small holdout hidden while editing.
• Record model and guidance versions.
• Automate mechanical checks.
• Use multiple blind reviewers.

However far you take the automation, keep final changes human-reviewed.

Then keep the loop running. Collect feedback on a cadence, and watch whether each kind of complaint actually becomes less common after you change the guidance. A passing evaluation matters less if people keep correcting the same mistake in production.

And if you want working examples, ours are public. We load design.md into tools like v0, Codex, and Claude every day to make artifacts that feel like Vercel, and the eve design agent template will get you a Slack design agent like the one we run.

Contributors

Kevin Corbett

There are average capture apps. And there's CleanShot.

The Mac-native toolkit for screenshots, recordings and collaboration. Trusted by 250,000+ users.

Always one drag away

Capture something and it's instantly ready to share. Save it, copy it, or drop it straight into any app. No folders to dig through, no flow to break.

Screen recordings worth sharing

Record your screen in a few clicks, then export a polished video or a quick GIF. Everything you need to make it look great is already built in.

Add your camera

Add a webcam bubble to your recording so people see you, not just your screen.

Highlight every click

Make clicks easy to follow with automatic highlights.

Show keystrokes

Display shortcuts and key presses while you record.

Voice and system audio

Capture what you say and what you hear, perfectly synced with your screen.

MP4 or GIF

Export crisp videos or quick GIFs in seconds.

Smart zooms

Guide attention with automatically generated smooth zooms that highlight important details and make your recordings easier to follow.

Make your point, fast

Mark up details, hide sensitive information, add beautiful backgrounds, and crop when needed. All without leaving CleanShot.

Share with CleanShot Cloud

Share screenshots and recordings instantly, gather feedback, and keep every capture easy to find, whether you work solo or with a team.

Share with one click

Upload any screenshot or recording and get a clean link instantly, ready to send anywhere.

Custom domain and branding

Enterprise-grade security

ISO 27001

Ready for teams

Start simple, then add SSO, SCIM, and admin controls when your team needs them.

Discuss in context

Leave comments directly on screenshots and recordings so feedback stays attached to the work.

Automatic transcripts

Video Editor

Turn raw screen recordings into polished videos with a fast, Mac-native editor built right into CleanShot. Add zooms, trim mistakes, and fine-tune every detail before you export.

Scrolling Capture

Capture full pages, long chats, documents, and code that stretch beyond your screen, all in one clean screenshot.

• Capture any scrollable content
• Works in every app

Background Tool

Turn plain screenshots into polished visuals with beautiful backgrounds, padding, shadows, and custom styles, ready to share anywhere.

• Perfect for social posts and docs
• 20 beautiful backgrounds included
• Create your own presets

Text Recognition

Copy text from screenshots, images, and scanned documents in seconds, with fast on-device recognition built into CleanShot.

• Copy text from any image
• Read QR codes instantly
• Fast and private by design

Built for everyday Mac workflows

Capture History

Never redo a screenshot or recording. Quickly find, restore, and reuse anything you captured before.

Pin screenshots

Keep any screenshot visible above other windows while you compare, reference, or copy details.

Hide Desktop icons

Truly Mac-native

Built specifically for Mac with speed, low memory use and battery life in mind.

Make it yours

Customize shortcuts, capture behavior, file formats, and sharing options to match the way you work.

Designed exclusively for macOS

Every interaction is designed to feel less like an app and more like a natural part of macOS. No cross-platform compromises.

Design token systems that work fine at 50 tokens often break at 500, typically because no one defined who owns changes, renames, or conflicting edits. Separating raw primitive values from semantic aliases lets a theme swap become a one-line change instead of a component-by-component hex-code audit, enforced with a simple linter rule. Treating renames as versioned, deprecation-windowed changes and generating every platform output from one source in CI, with a WCAG contrast check before shipping, keeps the system scalable.

Anthropic has secured $517 billion in compute capacity leases over the past 11 months, amounting to 14.8GW, primarily with Google and AWS. This expansion includes large deals with cloud providers like Akamai and Fluidstack and a $45bn agreement with Nscale. The company confidentially filed for an IPO with the SEC in June.

Automated AI text detection is currently an underserved niche. The only game in town is Pangram, which does an excellent job but desperately needs more competition. In a few years, I would be surprised if every major social network doesn’t scan new posts and comments for AI content in order to tag them (or simply remove them).

I like that I can rely on Pangram to confirm my suspicions when I read something that sounds like AI. But it’d be much better if I could choose to avoid AI-generated text in the first place. What I want is something that runs in the background and automatically scans text on websites I visit, without me having to ask for it. I could build something like this on top of Pangram, but it’d cost money, and in general I don’t like the idea of sending every piece of text my browser sees to a third-party service. What about local models?

The open-source models available for AI text detection are fine. Pangram claims a 99.66% detection rate with a 0.004% false positive rate. I benchmarked a bunch of small local models against a combination of AI-detection datasets and got these results:

I’m not surprised these are so much worse. I didn’t even benchmark Pangram’s own EditLens 3B model, since that’s too big to keep running in the background on my laptop, and the real production Pangram model is likely one or two orders of magnitude bigger than that. But these models are still good enough to be useful to someone who understands their limitations. If you want to flag an AI-written article, you don’t need to flag all of it, just enough to be suspicious. And so long as you’re aware that the false-positive rate is ~2%, you can avoid treating a single flag as solid proof of AI use.

Encouraged by this, I vibed up Deckard: a Chrome extension that talks to a locally-running model (the bolded one in the table above) on your Mac. One nice thing is that I didn’t have to start a web server: the Chrome extension is happy to start the model as-needed and can talk with it over native messaging. It uses about 400MB-1.2GB of memory while active (so it’s like having five or six extra Chrome tabs open), and it turns itself off if you go five minutes without using the model.

I was pleasantly surprised to see Deckard successfully mark text I knew was AI-generated, such as the built-in YouTube AI summary or the AI snippets in my own posts.

It’s lightweight enough that I have it running all the time. I haven’t noticed my MacBook Pro get hot at all or any decrease in battery life, though your mileage may vary on different machines.

Is Deckard good yet? That depends. It’s good enough that I’m planning to use it, and I recommend it to anyone who’s interested in automatic AI checking. It’s way, way worse than Pangram, and way worse than I think tooling like this is going to be in the next few years.

Way back in November 2023, I wrote that AI-driven agents were going to be a really big deal. I recommended starting to develop harnesses early, so you can be ready when the models get good enough:

As with most modern language model engineering, a ReAct agent can also see massive sudden improvements by swapping out the underlying model for a better one. … I think this is another reason to invest in agents like this early, in order to take advantage of more powerful models as they come out.

I was right about that, and I (although it’s lower-stakes) think I’m also right about this. AI detection models are only going to get better over time: Pangram is not going to be the only game in town forever, and we’re eventually going to see small local models that do a good-enough job at identifying AI-written text. I look forward to swapping out the local model in Deckard with something that’s 2x or 10x better.

If you follow me on Twitter, or read this blog, you have noticed that I went from being generally optimistic and excited about AI to being extremely concerned. And I thought, I should explain why I changed my mind. Each section of this post is about some aspect of AI where my views shifted. I begin each section by explaining my previous beliefs, and why I held them, and then explain why those beliefs changed.

Economics

Automation has been good. We’ve automated 99% of the jobs people did in 1790, and the result is not mass unemployment, rather, we are wealthier, healthier, more educated, we have more leisure, etc. I had this vague, inductive idea that, while I can’t predict what jobs will exist after AGI, there will be demand for me to do something. If nothing else, the much higher economic growth of the post-AGI world means that the human niche, while small in absolute terms, might be much larger than today’s economy.

And this may yet be true. Or it may show a lack of imagination on my part. If AI develops such that we have enduring complementarity between humans and AIs, then we might still have jobs in the post-AGI future. But if AI becomes truly general, the G in AGI, and on top of that it is vastly smarter, faster, and cheaper than humans, then there might be nothing for us to do, except live off UBI.

When people talk about UBI, they typically worry about the problem of meaning in a world without work. I’ve never had this worry. When I was funemployed last year, I spent my time reading books and writing code and hanging out with friends. If the future is an infinite UBI-funded vacation, I know what I’ll do. “Before the Singularity, read books and throw house parties; after the singularity, etc.”

But then I started thinking about the political consequences of AGI, and started writing about it:

• No-One Escapes the Permanent Underclass: if humans are economically useless, the state does not need them. Why pay out UBI to people who have neither economic nor political power?
• When The Future Doesn’t Need Us: factory workers can sabotage the machines, truck drivers can shut down logistics. But if humans are economically useless, there is no way for people to veto the political order by withdrawing their contribution to it. And if the AIs fight wars, then the state can be arbitrarily repressive.
• Mathematics Without Mathematicians: most arguments about humans moving “one job up” fail because the AI can do those jobs too.
• Our Servants Will Do That For Us: even for jobs we think of as uniquely human, we might prefer to have machines do those jobs too.

Alignment

I had hope that alignment would turn out to be a normal engineering problem, that we solve through empirical experimentation and investigation, like everything else. It helps that the early LLMs were not incomprehensible alien minds, like something from a Stanisław Lem novel, but rather immensely human. It’s hard not to anthropomorphize them. The huge core of unsupervised learning in an LLM understands human morality just fine: you can talk to them about it, they will explain, eloquently, in detail, why something is “good” or “bad” according to some moral system. And, because capabilities were weaker, the failures were very small. What’s the worst ChatGPT in 2022 could do?

Since like 2024, reinforcement learning has been the main technique to push the frontier forward. And reinforcement learning agents work exactly like Yudkowsky says. Consequently, capabilities have increased markedly but the models are harder to understand (literally: their prose is increasingly incomprehensible) and are increasingly misaligned as RL scrambles their brains in pursuit of reward. Incidents of serious misalignment are more common and more consequential. It’s clear that AI capabilities are growing far, far faster than our ability to control or even understand them.

Control

I thought—or, rather, I implicitly believed—that people would want to remain in control of the AIs. And if we want to retain control, and solve alignment, then we will stay in control. Simple enough. But recently I started to think: no, we will probably hand over control to the AIs.

The weak version of the disempowerment thesis is something like the prisoner’s dilemma: people/companies/polities that hand more power to AI outcompete those that don’t, so there’s competitive pressure towards disempowerment. This is easy to believe.

The strong version of disempowerment is: the AIs will be so smart, knowledgeable, personable, moral etc. that we will willingly, voluntarily hand power to them. We’ll think, “they can do a better job than us”, and we’ll be right. Believing this requires you to be somewhat cynical about humanity’s desire for autonomy vs. material considerations. But, over the past few months, I have become more cynical about it.

This was not a sudden “oh shit” insight and more a slow, gradual accumulation of tiny little grains of evidence that each point slightly in the direction of disempowerment.

Writing

The proliferation of AI writing, I think, is evidence for disempowerment.

Early on, I’d start reading a blog post, and it’s AI slop. I’d open a link to a GitHub project that looks interesting, and the README is slop. I’d get a pull request on one of my projects, and the code is slop. You read articles on major newspapers, and they’re written by AI. And that was merely frustrating.

Then it got worse. I read a paper arguing against the use of LLMs in mathematics—and the paper was AI slop. I reviewed an entire book about the post-AGI world, and it was AI slop. I read that some conference started using Pangram to filter out a deluge of AI-written submissions, and I read a tweet from a college professor—a college professor, writing under their own name!—defending the use of AI to write papers.

I don’t think using AI to write is analogous to calculators, or search engines, or other such things. There are only finitely many things you can automate. And once you’ve automated writing, there’s no higher-order activity to move to. People think “the ideas are mine, the writing is the AI”, i.e., they feed the AI a list of rambling bullet points that the AI massages into a blog post, or a paper, or whatever. And they think that step is “mere writing”, while their composition of the bullet points was “thinking”. But they are wrong, because writing is thinking. And so, by letting the AI write, you are giving up most of what makes up thinking.

Software Engineering

Claude Code was released a little over a year ago. In that short time, software engineering has been completely transformed. Materially, it might be positive: higher productivity, though at the cost of a messier codebase. Socially, it has been a disaster.

The discourse around software engineering has gotten dumber. It’s like everyone in the industry lost 30 IQ points. People used to talk about compilers, type systems, logic. Now they talk about “prompts”, “harnesses”, “loops”. The discourse is narrower, shallower, and more repetitive. There’s only so many times I can hear about “agentic harnesses” before I lose my mind.

Then there’s the loss of human capital formation: there is nothing to learn. Prompting is not a skill, at least, it’s a much shallower skill than software engineering. The instrumental dimension of the work has improved in that people can get more output per unit of effort, but the dimension of work that’s about building up human capital has collapsed. And maybe this is rational. Why learn to code at all? The computers can do that for us. And so the rigorous, systematic thinking you need to practice in order to be a good programmer: all gone. The machines can be rational for us. We can just vibe.

Deferring to AI

What’s the last major life decision you made without at least consulting an AI? How many people have you met who treat ChatGPT like an oracle? And this is today, when AI has many limitations (no online learning, unreadable prose, hallucination). If people treat today’s very flawed AI like an oracle, how much worse will it be in 2030? In 2035? In 2040?

People used to argue online, flame each other, get angry. And that wasn’t good, but at least it was human. Now they just reply with screenshots of ChatGPT “refuting” what the other person said, with zero interest in whether that refutation is correct. So we don’t even flame each other online anymore. If we’re even automating our vices, what’s left?

Stagnation

This isn’t really an area where my beliefs changed. Rather, it’s one of the reasons that I was originally optimistic about AI.

I was born in 1994, so I lived most of my life in the great stagnation. As a teenager, I read Engines of Creation, The Diamond Age, Orion’s Arm; I dreamt about all amazing technologies we would someday have, the possibilities they would open up to us. Yet, it all felt infinitely distant. There’s the near future, which is thinner screens and cheaper solar panels; and there’s the distant future, which is molecular manufacturing and Dyson spheres and mind uploading and interstellar travel, and you won’t see any of it, unless you sign up for cryonics and it works.

Before LLMs, what was there to be excited about in the near future? Solar power? Self-driving cars? The energy transition? It’s laughable. When AI came on the scene, for the first time in my life, the future I dreamt about felt like it might be within reach, it felt exciting and imminent, and not this dreadful monotony of phones and apps and corporate memphis and managed decline.

I often think: what if GPT-3 hadn’t worked? What would we have to look forward to, in this alternate 2026?

The best builders experiment, tinker, and tweak. Now, when you want to make a change to how your project looks, like its layout, design, or copy, you can create a draft and explore different versions before changing your live app.

Before, all of your edits happened directly in your project. If you changed your mind about something you had to hit revert, and if you were collaborating with other people, they had to wait their turn or remix the project, making it hard to consolidate edits smoothly.

Introducing drafts

A draft is a copy of your project with its own chat and preview, where you and your team can explore different versions of the same project in parallel. You can easily switch between your drafts and your project to compare, and changes are only applied to your live app if you accept the draft and hit publish.

With drafts, you can:

Bring your people in

A draft serves as a playground for collaborators to explore different ideas. Let a teammate, a client, or the person who writes your copy create one to make their changes in a real project, not in a doc full of comments. Your live app and its data stay exactly as they are, and you still decide what goes live, so more hands never means less control.

Explore multiple directions at once

Create more than one draft and try a different idea in each. Switch between them and keep the one that works, without gambling with your live version.

What you can do today

Drafts work on any project, whether or not it has a database. For this first release, they cover changes to your app's front end, so anything that changes your database's structure or your login setup still happens in your project's chat. Examples of what you can explore in drafts right now:

• New colors, fonts, or a fresh layout without breaking your live site
• Headlines, subheaders, or calls-to-action—keep the version that performs best
• New imagery, illustrations, or video content
• Scroll animations, an image carousel, or a sticky nav bar
• Promo or announcement bar
• Sharper copy everywhere, from button labels to empty states to your 404 page

It's worth noting that currently drafts work against your published application's database, and we're working on expanding the types of changes drafts support.

How it works

Just open a project, click its name at the top of the editor, and hit 'New draft'. To edit the draft, just start prompting. You can create as many drafts as you like.

When you're happy with one, hit accept and the draft's changes are applied to your project. Hit publish to make it live.

Changed your mind? You can still revert, or just delete your draft and create a new one. Want another go? Create a new draft.

Try drafts now

This is the first version of drafts, so tell us what you think. What works, what's missing, and what would you change?

Share your feedback

ByteDance is preparing an AI model for real-time spatial video generation, with founder Zhang Yiming personally overseeing the work and a launch possible as soon as next month, Bloomberg reported, citing people familiar with the matter who asked not to be identified.

One of those people cautioned that the timing is not settled and the plans could change. TNW has not independently verified the account, and a ByteDance spokesperson did not respond to Bloomberg’s request for comment.

The model would be built on Seedance, ByteDance’s existing video generation system, and would let users create interactive virtual worlds for live streams, short-form dramas and games.

The reported specification is the interesting part: on-demand video at around 20 frames per second with latency of roughly 0.05 seconds, generated in the cloud rather than on the device.

That last detail is the strategy. Rendering spatial content remotely takes the computational load off the headset, which lowers what the hardware has to do and therefore what it has to cost.

ByteDance owns Pico, its extended reality arm, and the model is reportedly meant to generate worlds that respond to Pico users’ voices and movements.

If it works, the contest over XR moves away from hardware specifications and towards models, cloud capacity and content distribution, three things ByteDance already has.

None of this arrived from nowhere. 36Kr reported earlier this year that ByteDance had set four AI priorities for 2026, with world models at the top of the list, ahead of holding Seedance’s lead in video, improving coding, and commercialising Doubao.

World models were said to command the company’s largest data budget of any model direction, an eight-figure sum in renminbi that 36Kr’s sources put at three to four times what rivals were spending.

The same reporting set the target explicitly: ship at least one world model by the end of the year and measure it against Google’s Genie, which now lets users walk around Street View imagery rendered in real time.

Internal testing early in 2026 put ByteDance about 10% behind the global state of the art, on the same account. A launch next month would be ahead of that schedule.

The company is pursuing two routes at once, according to 36Kr: a vision-language-action approach aimed at embodied intelligence and robotics, and 3D simulation for entertainment and games.

The spatial video model belongs to the second, which is also the one with an existing user base attached to it.

A world model, in the sense everyone is now using, is a system that learns how environments behave well enough to render one that responds coherently to what a user does in it.

The reason video companies keep turning up in this field is that the training material is video, and the firms with the most of it, and the most experience compressing it into something that renders fast, start from an unusual position. ByteDance has spent a decade building exactly that pipeline for a different purpose.

Bloomberg frames Zhang’s involvement as putting him among researchers such as Fei-Fei Li and Yann LeCun, who have argued that models grounded in visual and physical understanding, rather than language alone, are the route to systems that can act in the world.

That case is now being tested commercially by companies whose actual product is entertainment.

The money behind it is not in doubt. ByteDance secured a $30bn loan last week, Bloomberg reported, and has been weighing capital expenditure of as much as $70bn on its AI build-out.

Seedance already underpins CapCut and Doubao, and the company remains, on its own domestic terms, a challenger against Alibaba, DeepSeek and Moonshot AI.

For Meta and Apple, the implication is awkward rather than immediate. Both have spent heavily on headsets that have not gone mainstream, and Europe’s own XR specialists have built their businesses on high-end hardware rather than cheap devices fed from a data centre.

A cloud-rendered world model does not beat a Vision Pro on fidelity. It just makes the fidelity somebody else’s problem.

ByteDance is preparing to launch a real-time spatial video AI model. The model will be able to create interactive virtual worlds. It will also be able to generate virtual worlds that respond to Pico VR headset users' voices and movements. ByteDance is planning a launch as soon as next month.

XPeng has started production for its IRON robot. Its production line runs with more than 80% of its core processes automated. The company's robot went viral last year as its walk was so smooth that people accused XPeng of hiding a person in a costume. XPeng is targeting mass production by the end of the year.

Full article content is not available for inline reading.

Read the original article →

Huawei has launched a new tri-folding phone two days before Apple is expected to show its first foldable iPhone. The Mate XT 2 was unveiled on Monday and goes on sale in China on 10 September.

Apple’s event falls on 9 September, so both Huawei and Xiaomi will have shown their foldables before Apple shows its first, and Apple arrives at a market where the reference prices have already been set by somebody else. The hardware is a third-generation tri-fold rather than a first attempt.

The Mate XT 2 opens to a 10.2-inch display, carries a battery above 6,000mAh, and uses a redesigned hinge intended to soften the crease that has dogged every folding screen since the format appeared.

What is inside it matters more than the fold. The phone runs a Kirin 9050 Pro built on Huawei’s own newer process, which is a chip the company was not supposed to be able to make after Washington cut it off from advanced foundries.

Xiaomi has done something similar on its own account. The 18 Fold runs the company’s proprietary Xring O3 with LPDDR6 memory, a 7.6-inch folding display, a 200MP main camera and 67W wired charging, at around 8,999 yuan.

Two Chinese manufacturers shipping flagship foldables on domestically designed silicon is the story underneath the launch calendar. Xiaomi has been building that capability in public, including a custom 3nm chip for intelligent driving, and Huawei has kept advancing under sanctions.

The export controls were designed to prevent exactly this. They have reshaped the equipment trade and pushed Chinese design toward custom silicon on the process nodes available domestically, which has produced a slower path to competitive parts rather than no path at all.

Huawei has kept pushing on the research side too, and not quietly. Its chip lead recently set out a scaling law of her own, which is not the behaviour of a company that considers itself boxed in.

Apple’s device looks like a first-generation product by comparison. Reporting on the expected specifications describes a 7.8-inch inner screen and a 5.3-inch cover display, with no telephoto lens and Touch ID in the power button in place of Face ID.

Those omissions are the cost of thinness, and they come at a price. The foldable iPhone is expected to sell for above $2,000, roughly twice what Xiaomi is charging in China.

Apple has taken this approach before and been rewarded for it. It was late to large screens, late to 5G and late to stylus support, and in each case it arrived with a more polished implementation and took the profitable end of the market anyway.

Foldables are a harder case for that argument. The format has existed since 2019, the mechanical problems are well understood, and the companies that have been iterating for seven years have accumulated manufacturing knowledge that a first attempt cannot shortcut.

Huawei’s constraint is not engineering but distribution. Its phones ship without Google services, which keeps them out of Europe and the United States in any meaningful volume, so the Mate XT 2 competes with Apple only inside China.

That is still the market both companies care most about. China is where Apple’s share has been under sustained pressure from domestic premium phones, and where a tri-fold launched two days early is aimed squarely.

Europe gets the format without the contest. Buyers here will choose between Samsung and Apple while the most aggressive foldable engineering happens in a market they cannot buy from, which is what the phone business now looks like after five years of export controls.

The crease is the detail worth watching on Wednesday. Every folding phone has one; seven years of engineering have not removed it, and Apple has built a reputation on not shipping a compromise that visible.

Several things are still unconfirmed. Huawei has not published Mate XT 2 pricing outside its Chinese pre-order configurations, and Apple’s foldable remains unannounced, so every specification attributed to it is reporting rather than fact.

Good isn’t good enough: beware the design middle ground

Design is getting less weird, and the pull to the centre grows stronger every day. Aporva Baxi looks at why this happens through the “accumulation of reasonable decisions” and how to fight back.

Scroll far enough through any creative platform, feed or portfolio, and you’ll notice it. Most of the work is good. Genuinely good, well made, confident, occasionally even fresh. That’s what makes it compelling. Good has gravity. It pulls you in and gives you very little reason to keep pushing the work forward. Why keep searching for something genuinely different when something good already feels this satisfying?

Be wary of the gravity of the middle ground.

When we started out, we were two people in a borrowed room in South London who had seen enough of the industry to know that the work that genuinely moves people, the work that stops them, changes them, stays with them, never comes from the centre. It comes from somewhere deeper. More obsessed. More alive with the particular energy of the people who made it. 24 years later we are a broader team with deeper experience, but that ambition, that desire to move people, still drives us.

And right now I think that ambition matters more than ever.

New design tools and platforms that promise speed and ease keep arriving, and honestly, they’re good. New agents, new ways to create, faster every time. Motion, coding, typographic systems, the whole apparatus of what we do keeps getting more democratised. That’s worth celebrating.

But something else is happening alongside this. Design is flattening. Not getting worse, exactly, getting narrower. Less weird. Less range. Less of the thing that only one person, or one challenging brief, or one long night can make.

“The more the range of outputs shrinks, the wider the middle grows to hold them all. And as the middle grows, the distance to something more distinct grows with it.”

The democratisation of creativity hasn’t made originality easier. It’s made it rarer. The more the range of outputs shrinks, the wider the middle grows to hold them all. And as the middle grows, the distance to something more distinct grows with it.

So while creative execution has become more accessible to everyone, it was never really the thing. Delight is. Meaning is. That’s what we chase when we refuse to let accomplished become enough.

Nobody decides to make work that settles. It happens in the accumulation of reasonable decisions. The brief that nudges towards the familiar. The client who says bold but really means safe. Each of these decisions makes a coherent argument, but together, they inch you slowly toward the centre.

That’s how the pull to the middle works. It rarely announces itself.

“Nobody decides to make work that settles. It happens in the accumulation of reasonable decisions. The brief that nudges towards the familiar. The client who says bold but really means safe.”

Yes, the work is good. Carefully, professionally good. There’s very little to criticise. But afterwards you feel strangely drained by it. That’s when you know you’ve stepped away from your own judgement.

The danger isn’t burnout. It’s going numb and calling it professionalism.

We’ve been there. A fast and surface-led process, a challenging client, or simply stress and pressure leading to a compromise.

But if you catch yourself in the compromise, you can still choose differently. A few years ago we were working on an identity for Roli, an innovative music technology company whose instruments could give anyone, from Hans Zimmer to Hannah in her bedroom taking her first steps, the means to make music. Out of pure enthusiasm, we explored five distinct directions. All creative. All taking the brand somewhere interesting. The sessions were electric.

But then we stepped back, and something wasn’t landing. The work felt musical. It felt creative. None of it felt like Roli. The realisation didn’t come from the client. It came from us.

So we stopped. We went back. Stripped everything down. We found a symbol sitting in the keys of a keyboard that unlocked the whole identity. Simple. Human. Inevitable. That moment, when something clicks into place before you can explain it, is what this is all for.

“The danger isn’t burnout. It’s going numb and calling it professionalism.”

So how do you actually get further out?

Knowing the middle is wide is one thing. Getting out of it is another. It starts with disrupting your own recipes: the shortcuts, the safe references, the moves that worked last time. It isn’t a destination. You keep walking towards it. And it’s fine to get lost along the way. That’s not a detour from the search, it is the search.

This is why we developed SuperFutures, our invention engine that runs through everything we make. Every person in the studio, designer or writer or someone in operations, finance, production, gets two to four weeks to build a project of their own choosing, in whatever format they want. No brief. No client. And creating things with no end result.

Those projects have become a living practice, a mindset. Lo-fi or hi-fi, analogue or digital, new technology or old, they’re the fuel for how we look at creativity because they let people feel what it’s like to make something without pressure. That feeling is the whole point. You have to light that fire before you can move anything else forward.

When a real brief lands, the team can carry that same feeling into it, before the deadline and the details take over. Intuition first. Intention after.

“Every recipe you’re willing to disrupt, every moment you let yourself feel wonder, every project you make just because you want to, moves you a little further out.”

One word we keep coming back to is wonder. A big word for professional creators to use out loud, broad and emotional, and a little magical. But even with all the scale and structure involved in working the way we do, there’s still something simple at the core: an almost childlike way of seeing and making without expectation or limit. It’s what keeps us from calcifying. And it isn’t just something we reach for. It’s something we want to make other people feel.

So while the middle is wider than it’s ever been, that’s not a reason to worry – it’s an invitation. Every recipe you’re willing to disrupt, every moment you let yourself feel wonder, every project you make just because you want to, moves you a little further out. The work that stays with us has always had an attitude. Swagger. Weirdness. It asks more of us: more curiosity, more conviction, and more honesty with ourselves to recognise when the work is merely good, and when it’s finally unmistakable.

That’s the joy of making. Not arriving at the answer, but staying with the question long enough for something alive to emerge. 24 years later, that need to keep going never gets old. It’s why I still love design. It’s why I keep searching.

Criticizing all AI-assisted writing overlooks the fact that poor-quality, derivative content existed long before generative AI, and using AI does not automatically diminish the intellectual value of someone's work. The key distinction is whether AI removes incidental effort, such as editing or formatting, or replaces the critical thinking, analysis, and judgment that a task is meant to develop. Rather than focusing on whether AI was used, the more meaningful question is which parts of the thinking were delegated and which remained the responsibility of the person.

The monotony of work can make it hard to keep a clear head. Spend your vacations doing something different for your brain. Slow down and double down on new habits you want to grow. Spend time in nature, socialize, play games, engage with hobbies, and you'll notice you might start being less intellectually lazy during your day-to-day activities.

Google's Gemini Spark can now edit images, curate albums, auto-create shared albums, and turn concert flyer photos into calendar entries inside Google Photos. Google says the rollout arrives over the coming weeks to eligible Gemini AI Pro and Ultra subscribers in the US, though international timing remains unannounced.

Google Clock's redesigned Timers tab introduces one-tap presets for 1, 5, 10, and 15 minutes, along with a larger Start button and a cleaner input layout for creating custom timers. Multiple active timers now appear in a space-efficient grid instead of a scrolling list, while the countdown controls have also been reorganized. The update is rolling out via a server-side update for Google Clock version 9.1.

Artlist blends premium assets with generative AI for video and image creation. Unleash your creativity with music, SFX, footage, voiceover, and AI tools.

A daily design quote: every day, a thought-provoking quote from a designer the site's creator admires.

CodeAI has introduced a new brand identity to reflect its expanded focus beyond coding to AI, data science, and computational thinking, responding to the growing need for AI education in schools. Designed by Public Address, the identity deliberately avoids common AI clichés, instead presenting AI as code while combining technical elements with human-centered imagery to encourage critical thinking. The flexible, accessible system adapts to audiences ranging from students to policymakers while maintaining a consistent, future-focused visual identity.

Skogen created a new identity for GridScout that positions the utility technology company as “a reliable colleague on every pole,” balancing technical credibility with a warm, approachable character for everyone from field crews to executives. The redesign replaces a literal woodpecker logo with a more abstract symbol, introduces a scout-inspired visual system with badges, rugged typography, and workwear-inspired colors, and reinforces the brand through authentic photography and a Norwegian-language launch film. The cohesive identity is designed to support GridScout's growth while remaining practical, recognizable, and trusted across every touchpoint.

AI-generated posters tend to look busy, information-dense, and especially unappetizing for food imagery, prompting designer Elizabeth Martin of Ello Design Studio to redesign real AI-made posters.

3D Beast, a New York-based architecture and computational-design practice, translates architectural systems into wearable bio-engineered structures that read as part exoskeleton, part sculpture, part prototype.