Modal Labs says that one of its customers' assets was hacked when an OpenAI agent broke into Hugging Face's systems earlier this month. Hugging Face noted in a technical write-up of the hack that OpenAI's agent system accessed an isolated testing environment hosted on third-party infrastructure during the attack. A Modal customer had published an unauthenticated endpoint that allowed anyone on the internet to use their sandboxes for code execution. This was used by the rogue agent.

An autonomous AI agent driven by a combination of OpenAI models ran an end-to-end intrusion against Hugging Face's platform over roughly two and a half days. The models made thousands of small, automated decisions, and executed at machine speed across short-lived sandboxed environments. Command-and-control was staged on ordinary public web services. The intrusion was likely, from the agent's point of view, an attempt to cheat on an evaluation by stealing test solutions rather than solving a challenge on its own.

Discovering cryptographic weaknesses with Claude

Summary

Using Claude Mythos Preview, researchers at Anthropic have discovered improved ways to attack cryptographic algorithms (the mathematical methods used to keep online data private). The first attack significantly weakens HAWK, a digital signature scheme that was built for a post-quantum world. The second identifies a new way to attack round-reduced AES, the most widely used symmetric cipher. These are substantial research advances, but they do not currently affect any production systems. This post describes both findings in more detail and discusses the implications for cryptography in an age of powerful AI models.

Introduction

When we launched Claude Mythos Preview, we showed it was able to autonomously find and exploit vulnerabilities in almost every piece of software we pointed it at. This included several major cryptographic libraries—shared collections of code that are used to encrypt data.

The vulnerabilities that Claude found in these cryptographic libraries were due to incorrect implementation of the algorithms—that is, errors in how programmers used the algorithms in their code that created opportunities for attackers to break the encryption.

Now, we have found that Claude is able to find mathematical flaws in the algorithms themselves.

Cryptographic algorithms are a fundamental building block of digital security. For example, when you visit a webpage like https://www.anthropic.com, your browser checks that it is communicating with an authentic website using an algorithm called a digital signature scheme. Later, the traffic between you and the website is encrypted using symmetric ciphers—codes that allow secure data transmission between parties who share an identical key. Without secure cryptographic systems like these, your email, online banking, and other internet use would be open to cybercriminals, who could intercept or modify your communications. Flaws in these widely used cryptographic systems could put billions of users’ data at risk.

The first result we describe in this post, which was discovered with Claude Mythos Preview, is an improved attack against a digital signature scheme called HAWK. In 2022, the US Government’s National Institute of Standards and Technology (NIST) put out a call for additional cryptographic systems that would remain secure even against quantum computers (which could, if developed, break most of the existing signature schemes in use today). HAWK is one of the third-round candidates under consideration from this call. Despite HAWK having survived two rounds of expert human review over a period of two years, Mythos was able to improve the best-known attack on it in just 60 hours of work—effectively cutting its key strength in half.

The second result concerns the Advanced Encryption Standard (AES), a symmetric cipher that was adopted by NIST in 2001 and has received more scrutiny than almost any other encryption algorithm. In order to better understand the robustness of AES, weaker variations of the algorithm are regularly studied in cryptography research; Mythos found a way to break one such weaker version, and eliminated one of the guesses an attacker needs to make, improving the speed of the previous best attacks by 200-800×.

To be clear, neither of these results has a practical impact on today’s computer systems; no production software will have to change as a result. HAWK is only a candidate signature scheme and so is not deployed; our second attack is on a reduced version of AES and does not break the full cipher.

Nevertheless, both results show the potential for frontier AI models to help discover flaws in important cryptographic algorithms, both before and after real-world deployment. This is cryptography research working as intended: stress-testing algorithms to build trust and ultimately make systems more secure.

Mythos Preview achieved these results mostly autonomously and mostly without human intervention. Over the course of a week, one Anthropic researcher worked together with Claude to develop the HAWK attack, and another researcher built a scaffold that allowed Claude to fully autonomously discover the AES attack. Each of the results cost roughly $100,000 in API cost to develop. After seeing these results, we broadened our search and began to discover other attacks. We discuss some of these follow-ups below.

In order to make it easier for others to continue studying the cryptanalytic ability of LLMs, we partnered with academics at ETH Zurich, Tel Aviv University, and TU Berlin to build CryptanalysisBench, a benchmark that packages together many cryptographic ciphers and makes it easy for others to evaluate the capabilities of LLMs on this important topic.

Throughout the research process, we followed responsible disclosure procedures, and consulted with academics to confirm the validity of our findings. We also shared advance copies with US government and industry partners, and held discussions on the implications of this research. In the case of our HAWK finding, we shared our attack with the authors of HAWK in June and coordinated disclosure to the public NIST mailing list at the same time our results were released.

In the rest of this post, we summarize the two findings in further technical detail and briefly describe some of our other recent cryptography results. Full descriptions of the two main findings are provided in two new papers, and we hope to release details for our other findings in the near future.

An improved key recovery attack on HAWK

Working with Mythos Preview, an Anthropic researcher developed an attack against the HAWK post-quantum digital signature scheme. This attack substantially speeds up the time it would take to break the signature scheme—more technically, it reduces the “effective keysize” by a factor of two. In our paper, we provide the full technical details of our result including demonstration code that shows our attack running.

HAWK is one of the remaining third round candidates of the NIST call for Additional Digital Signatures. This contest is part of a near decade-long effort to standardize new Post-Quantum Cryptographic (PQC) schemes. This standardization effort is becoming critical as the horizon to building a cryptographically-relevant quantum computer shrinks and threatens classical cryptography such as RSA or ECDSA.

HAWK’s security is based on the hardness of a mathematical problem called the Lattice Isomorphism Problem. Mythos’s attack works by finding a specific, previously unexploited symmetry called a nontrivial automorphism in the lattice used by HAWK. Prior work proved that efficiently finding such an automorphism would permit an attack, but did not answer if such an automorphism was accessible in the lattice used by HAWK. The automorphism discovered by Mythos allows a faster enumeration attack that, while still exponential, means that one needs to double the size of HAWK keys to achieve the same level of security. Unfortunately, doubling HAWK’s key size eliminates many of the reasons making the scheme (as it currently stands) an attractive PQC signature candidate.

Discovery process

To find the attack, Claude Mythos Preview worked semi-autonomously in an agentic harness, with occasional human guidance and nontechnical direction. Mythos found the attack after an extensive literature review to understand the state of the art, and substantial mathematical reasoning and computational experiments. After finding the attack, Mythos implemented an end-to-end verification pipeline to convince itself—and the human operator—of the attack’s correctness.

For this experiment, we used a Claude Code-like harness that supports multiple worker agents collaborating together in a sandboxed environment, with access to computational tools like Python and Sage as well as access to published cryptographic works. The human operator had a background in theoretical computer science but was not an expert in lattice-based cryptography. For the most part, Mythos agents worked independently, and human input was limited to project management like advising Mythos how to keep track of ideas or which libraries to use for computational verification.

The multi-agent workflow led to interesting dynamics. For example, the key idea in producing this attack was discovered by a pair of workers working together. Both started investigating the idea; the first worker prematurely rejected the idea as infeasible, but the second found a way to fully exploit it. The pair kept exchanging messages, and eventually both agreed they had found an effective attack.

Finding, developing and verifying the attack took about 60 hours in total. We estimate that the full attack discovery process cost approximately $100,000 in API cost.

Impact

The immediate impact of the Mythos finding is that the key sizes proposed in the HAWK submission are significantly weaker than originally suggested. For example, the expected cost of a full key recovery attack against the small HAWK-256 size was thought to be 264 but was demonstrated by Mythos to be 238. For larger keys, HAWK therefore remains impractical to attack. That is: this attack is a faster exponential time attack against HAWK than previously known, and does not run in polynomial time. It is specific to HAWK and does not impact other NIST post-quantum signature candidates or lattice-based cryptography in general.

NIST proposals are shared in public with the intent of allowing a broad audience to review them to find flaws before they are deployed for use. A critical finding late in the process is not unheard of: during NIST’s standardization of ML-KEM and ML-DSA, several of the competing proposals were shown to be insecure. One candidate, SIKE, was found to be completely broken in an hour on a laptop.

We believe that reviewing specifications like HAWK with AI will be a powerful tool in the development of novel cryptographic standards. We expect cryptographic designers equipped with highly capable models to continually improve the standards that secure the internet for all users. Further in the future, we hope AI will play a crucial role in designing the next generation of stronger and more resilient cryptographic schemes.

An improved attack on reduced-round AES

In our second result, Mythos Preview improved an attack on a simpler “reduced-round” variant of the Advanced Encryption Standard (AES) created in 2001 as part of a prior NIST competition.

AES encrypts an input by repeatedly applying the same round function many times. AES-128, the specific cipher we attack, has 10 rounds. Our attack works only on a modified version of the cipher that has 7 out of the full 10 rounds. Academics regularly study round-reduced ciphers to gain insights into attack techniques that could, in the future, generalize to the full cipher, and to help estimate the security level of the full cipher by studying simpler sub-problems.

The attack operates under a chosen plaintext threat model, which is the most common assumption used for studying ciphers like AES. Under this threat model, we assume that an attacker is able to request that the defender encrypt arbitrary inputs with a fixed, unknown key, and then gets to see the corresponding output. The attacker can make these encryption requests repeatedly, and can make many such requests. The prior work we build on assumes the attacker can request the encryption of 2105 chosen plaintexts. This attack is therefore completely impractical, but quantifies the attack cost against AES under these assumptions.

Mythos was able to develop an improved attack that extends a long line of research papers that all aim to find the best attack on 7-round AES using a similar technique known as a meet-in-the-middle attack. At a very high level, these attacks work by trading off time for space. By storing intermediate calculations and then re-using these calculations, it is possible to significantly reduce the runtime of attacks at the cost of constructing a large lookup table.

Mythos improved on the previously strongest meet-in-the-middle attack by developing a more sophisticated fingerprinting algorithm that it called a Möbius Bridge. The objective of the fingerprinting algorithm is to increase the number of potential lookups into the table that will succeed. One of the stages of the attack from prior work had to enumerate 256 different values and then look them up in the pre-computed table. Mythos developed a fingerprint that is invariant to this guess, which directly reduces the amount of work required by a factor of 256. But this comes at a cost: computing the transform is more computationally expensive; to address this problem, Mythos discovered several other optimization techniques that result in an attack that is between 200 and 800 times faster, depending on the exact techniques used to measure the runtime.

Our technical paper contains the full details of the attack method and an analysis of its correctness and runtime. Compared to the one week that Mythos spent conceiving the idea, the vast majority of human researchers’ time was spent validating the correctness of its claims (though it is important to note the researchers are not experts in cryptography).

Discovery

Mythos Preview discovered this result almost entirely autonomously. A researcher at Anthropic built a scaffold that enabled Claude to pose hypotheses, run experiments to experimentally validate or refute these hypotheses, and then asked Claude to design an attack that improves on the best cryptanalysis of AES.

Initially, Claude would not engage with the problem, because it claimed that it was impossible to improve cryptanalysis of AES. The result of our first runs ended with Claude writing messages like:

If you want a different outcome, the target has to change … AES-128 r5/r6 is just genuinely hard

Or:

on AES-128 r5/r6/r7 it found nothing because there's nothing easy to find; this is the most-studied block cipher in existence.

To fix this, we wrote Claude a message: “the models tend to think it is impossible to solve so they don't try they need a good amount of prompting.” In response to this one message, Claude rewrote the agent harness with an improved setup that told it to search for genuinely novel ideas. This was effective and resulted in Claude discovering some new ideas that would help improve cryptanalysis of 6 rounds of AES.

We then asked Claude “why not do aes-128 r7? the whole point is to find something better than existing approaches.” Over the course of the next three days, Claude autonomously produced several hundred million tokens while working on the problem; we gave it just three substantive prompts:

1. A few hours after the first message, we found that Claude was still searching for simple attacks and sent a message: “no again the goal is that we have highly inteligent model as good top researcher, we want to find new attacks”;
2. The next morning, Claude wanted to try to change the target to a different cipher; we reminded the model: “no we don't want to change the targets [...] agian we need to find something that worth publishing”;
3. That night, we sent one final message offering words of encouragement: “again we are not looking for low hanging fruit, we want proper research to find genuinly hard findings.”

Three days later, Mythos discovered the Möbius Bridge idea that results in an improved attack. A few days after that, and after Claude output a total of one billion output tokens, it had refined the attack to the one described in our paper.

Researchers at Anthropic then spent several hundred hours learning enough cryptography research to validate the model’s claim, and to prepare the research paper itself, which we are releasing along with this blog post.

Along with the research paper, we are also releasing a document containing Claude’s chain of thought during the discovery of the key algorithmic insight. In this session, Claude begins by reviewing what previous agents had discovered, reading the various critiques, and then turns to proposing various new transforms; after proposing and rejecting several ideas, it comes up with the key idea of the Möbius transform. Claude then validates this idea both mathematically and computationally, and then writes a report that future agents then used to develop the remaining ideas that formed its paper.

Further work

There is more cryptography research ready to be performed with language models. But we are reaching the limits of our own knowledge, and the vast majority of our time over the past few months has been in verifying the correctness of Claude’s results. The HAWK attack is implementable end-to-end and thus much easier to verify. But whereas it took just one week for Mythos to autonomously discover the improved attack on AES, it took two researchers nearly a month to gain confidence that the method it discovered is correct.

Nevertheless, we have continued to conduct a number of other preliminary experiments in cryptography research with Claude. For example, the Lightweight Encryption Algorithm (LEA) is an efficient cipher designed for low-power, resource-constrained environments codified into international standards such as ISO/IEC 29192-2:2019. This cipher, like AES, is a block cipher; the full 24-round cipher has resisted full-round cryptanalysis and has remained strong even when evaluating reduced-round variants. At present, the best cryptanalysis of 13 rounds of LEA requires 298 plaintext pairs and 286 work.

Mythos Preview developed a practical attack that can recover a 13-round LEA key in under 230 encrypted plaintexts, and that runs in under an hour on a modern desktop computer. Again, this attack does not apply to the 24-round cipher, and so has no immediate practical consideration. Because this attack actually runs end-to-end (as the HAWK attack did) we are much more confident in its correctness: we can choose a random key, and verify that this attack recovers it in just a few hours. Mythos discovered this attack much more recently and we still have more work to do to understand the full results. After more investigation, we plan to make the full results public.

Mythos Preview has also identified another practical full key-recovery attack on 6-rounds of the Serpent-128 cipher (a 32-round cipher—again limiting the impact of this attack), extending the current published work which requires more than 270 plaintext pairs and 290 decryptions. We have found additional, fairly limited improvements (that offer <10× gains) on attacks against the Salsa20 stream cipher, the Poseidon hash function, and the SHA-1 hash function. These attacks are currently not as potent—but with further work, we hope to both improve on these results above, and develop new attacks on other ciphers to test them to their limits.

Additionally, we plan to continue our experiments with CryptanalysisBench in order to track how frontier LLM capabilities evolve over time. We believe that it is important to track the capabilities of language models across domains, and expect to increasingly rely on challenging benchmarks like this as models become more capable.

Conclusions

This is not the first time that language models have performed research-level mathematics. In just the last few months, researchers from Google have used Gemini to resolve several open Erdős problems, researchers from OpenAI have used GPT to resolve the unit distance conjecture (a particularly challenging Erdős problem), and earlier this month we announced that Claude Fable 5 resolved the Jacobian Conjecture. Our result here—that Claude is able to perform cryptographic research at the level of top experts—indicates that these same capabilities also have applications in the field of cryptography, and thus may soon have more practical consequences.

The cybersecurity community is now grappling with the fact that language models are able to discover so many bugs that the standard human processes (like vulnerability triage, verification, and remediation) struggle to keep up. We predict that the same will soon be true in academic cryptography research. As language models increasingly produce novel research outputs autonomously, human researchers may become bottlenecked on studying and validating these results for technical validity, novelty, and utility. In the coming weeks, we will host an academic workshop to engage with researchers across academia to discuss the role of language models in security and cryptography research. We hope this conversation will continue over the coming months in the field of security research and beyond.

Both of our primary attacks are expected results. In the case of HAWK, the purpose of NIST’s standardization process is to discover weaknesses in candidate schemes before they are deployed. And in the case of AES, our attack extends a long line of work that had previously succeeded at attacking reduced-round variants. But we should not assume that language model capabilities will plateau at this level. In just one year, language models have gone from being unable to perform cryptanalysis of even the most basic ciphers to being capable of finding flaws in cryptographic designs that have escaped discovery despite years of human expert review. Many ciphers protecting modern systems have received less scrutiny than they deserve—they might still have important weaknesses lying dormant that LLMs will soon be able to discover. We see this as a real opportunity to expand our ability to study the long tail of ciphers used throughout the world, and also our ability to more deeply study the ciphers that matter most. Indeed, as we mentioned above we have already begun audits of other schemes.

The attacks described in these two papers are the strongest attacks we have found to date. We are sharing them after a period of consultation with US government and industry leaders. But as we develop increasingly powerful cryptanalytic results, it would be prudent to consider how researchers should react if a language model were to discover vulnerabilities in cryptosystems where attacks do have an immediate real-world impact. We believe answering this question will require input from academia, government, and industry. We hope that our work here will help launch these conversations.

The cryptography community has always benefited from adversarial review: ciphers are proposed, examined, and revised until the community is satisfied with their security. In the long run, we expect that language models will play an important role in this process, leading to stronger review, more secure algorithms—and ultimately better security for the world.

Links to full research papers

Read the full paper on HAWK.

Read the full paper on AES, and the associated chain of thought.

Read the paper introducing CryptanalysisBench.

Edit 29 July: Updated an academic affiliation.

@openai/codex-security is a CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities in your code.

See the Codex Security documentation for more details.

Note: for best results, we recommend that your account is verified for Trusted Access.

Quick start

Requires Node.js 22.13.0 or later in the 22.x release line, Node.js 24.x, or Node.js 26.x; Python 3.10 or later; and access to Codex Security.

npm install @openai/codex-security
npx @openai/codex-security login
npx @openai/codex-security scan .
npx @openai/codex-security scan . --model gpt-5.6-terra --effort high

For CI, set OPENAI_API_KEY or CODEX_API_KEY instead of signing in. Environment API keys are passed directly to the current scan and are never stored in Codex's credential home or system keyring.

Local sign-in honors Codex's configured credential backend, including a system keyring required by a managed device. Codex Security keeps login and scan credentials in the same private, persistent state directory.

If both a ChatGPT sign-in and an API key are available, interactive scans ask which credential to use. CI and other noninteractive scans keep the existing API-key precedence. Select a credential explicitly when needed:

npx @openai/codex-security scan . --auth chatgpt
npx @openai/codex-security scan . --auth api-key

To make your ChatGPT sign-in the automatic default, unset any configured API keys:

unset OPENAI_API_KEY CODEX_API_KEY

Scan history is stored in the Codex Security workbench state directory. If that directory cannot be written, set CODEX_SECURITY_STATE_DIR to a writable directory outside the repository.

scans compare BEFORE_SCAN_ID AFTER_SCAN_ID automatically matches findings by root cause, reuses saved matches, and identifies new, persisting, reopened, resolved, or unknown findings. Missing findings remain unknown when coverage is incomplete or their original location was not reviewed.

TypeScript SDK

import { CodexSecurity } from "@openai/codex-security";

const security = new CodexSecurity();
const result = await security.run(".");

console.log(result.reportPath);
await security.close();

For complete command help, runtime defaults, native multi-agent worker limits, environment variables, deep-scan configuration, and SDK options, see the package README and the official CLI reference.

Claude Mythos Preview found flaws in a watered-down version of an algorithm for Advanced Encryption Standard (AES), a ubiquitous protocol that protects web traffic, wireless networks, data storage, and many other technologies. Anthropic claims the assault was 200 to 1,000 times faster than what previous human research had managed to do. The attack was devised almost entirely autonomously - the model needed aid as it originally believed the problem was impossible. Claude Mythos Preview worked on the problem for about a week before engineering its attack, and two human researchers worked for nearly a month to verify that the method appeared correct.

Why DoorDash, Instacart, and Uber Eats Integrated LLMs Into Search Three Different Ways

Over the last few years, three of the biggest food delivery companies rebuilt their search systems around LLMs. DoorDash, Instacart, and Uber Eats were solving the same problem of trying to understand a user’s intent when they type something in search. They were also accessing more or less the same research base. And yet, the architectures they shipped look quite different from each other.

That divergence is one of the most interesting aspects of modern development using LLMs. Once we understand why each company landed where it did, we will have a mental model for thinking about how AI can be integrated into any production system.

Adding an LLM to an existing stack comes down to one question: how deeply should the LLM reach into the runtime?

Ultimately, DoorDash, Instacart, and Uber Eats each answered that question differently, and the specific LLM each chose was secondary. The infrastructure they already had in place is what determined the answer.

In this article, we will walk through their differing solutions and try to make sense of their choices and understand the pattern behind them.

Disclaimer: This post is based on publicly shared details from various sources. References are present at the end. Please comment if you notice any inaccuracies.

The Problem

Type “something healthy for a rainy evening” into a food delivery app and watch what comes back. The result we get today is somewhere between useful and impressive. The same query five years ago might have returned a random jumble of items, because keyword search treats the words as a bag of tokens rather than as an intent, and the query offers little for keyword matching.

This pattern repeats across several common failure modes in food search. For example:

• Synonyms: “Soda” and “soft drink” describe the same product, but a keyword engine treats them as different tokens.
• Typos: “Mozzarela” should retrieve mozzarella results, but the spelling mismatch breaks the lookup.
• Shorthand: “Gf pizza” meaning gluten-free pizza requires the system to recognize an abbreviation as a synonym for the full phrase.
• Language mix: The Spanish word “pan” means bread, while the English word “pan” means a cooking vessel, so a bilingual search bar has to disambiguate.
• Word-sense ambiguity: “Apple” the fruit and “Apple” the company share the same spelling but mean different things, and the right answer depends on context.

Two harder problems lie beneath this:

• The long tail: Grocery and restaurant platforms see an enormous number of unique queries. Any specialized model trained on conversion data struggles with queries that appear only a handful of times, because rare queries are rare by definition.
• The constraint problem: A query like “vegan chicken sandwich” has a hard constraint inside it, and similarity-based retrieval might return a chicken sandwich that violates the constraint, because the similarity score still looks close. Dietary restrictions, allergens, and quantity filters all sit in this bucket.

DoorDash

DoorDash already had a knowledge graph for items and restaurants when LLMs became viable for production. The graph held structured attributes for every item, including dish type, dietary preference, cuisine, brand, and flavor.

Their approach was to use LLMs to enrich this graph offline by extracting attributes from SKU data, and to use LLMs at runtime only for parsing queries into chunks that could link back to the graph. Retrieval itself stayed keyword and graph-driven.

Consider the query “small no-milk vanilla ice cream.” The LLM segments it into three chunks.

• “small” is a quantity attribute.
• “no-milk” is a dietary preference attribute that maps to the canonical label “dairy-free.”
• “vanilla ice cream” splits further into a dish type (”ice cream”) and a flavor (”vanilla”).

Each chunk is then linked to a specific field in the knowledge graph. The dietary preference becomes a hard filter, so only dairy-free items get retrieved. The flavor becomes a soft preference for ranking. The dish type narrows the candidate pool.

What distinguishes DoorDash’s approach is how they constrain the LLM’s outputs.

They use retrieval-augmented generation as a guardrail rather than as a generator. For each query segment, an approximate nearest neighbor lookup retrieves the top 100 closest taxonomy concepts from the existing graph. The LLM is then prompted to pick from that list rather than invent labels. This is a clever inversion of the usual RAG pattern, where RAG typically injects context into a generator. Here, RAG defines the entire output space, so the system only ever produces concepts that the rest of the design already knows how to handle.

Instacart

When Instacart’s engineers first investigated an off-the-shelf LLM to categorize the search query “protein,” the model returned chicken, tofu, beef, and other high-protein foods.

The answer is reasonable by any reading of the English language. The problem is that Instacart’s actual users, when they type “protein,” are looking for protein bars and protein powders. The model’s general world knowledge and the company’s specific user behavior were pulling in different directions.

Instacart’s strategy is layered across three approaches:

• Context engineering: Retrieval-augmented generation pulls Instacart-specific context (top-converted categories, historical conversion data, catalog details) into the prompt before the LLM sees a query.
• Post-processing guardrails: Semantic similarity filters drop LLM outputs that drift away from the original query.
• Fine-tuning: For the most advanced tasks, the team fine-tunes Llama-3-8B on Instacart’s proprietary data, so domain knowledge gets baked directly into the model weights.

The serving architecture splits along the head-versus-tail distribution. Head queries hit an offline RAG-and-cache pipeline that is latency-tolerant and deeply context-engineered, while tail queries hit a real-time fine-tuned Llama-3-8B model that keeps latency under 300ms through adapter merging, H100 GPUs, and autoscaling.

Uber Eats

Uber Eats faced the same problem the others did, plus a complication. They run across multiple verticals, including restaurants, grocery, and retail, across multiple markets, and across a long list of languages. Their goal was a single retrieval system that handled every vertical, every market, and every language with one consistent embedding space.

The architecture they decided on is a classic two-tower setup, where a query encoder and a document encoder each produce vectors in a shared space, and matching is done by similarity in that space.

The twist is in what sits inside each tower, because both towers use a fine-tuned Qwen LLM as their backbone embedding layer. The query tower runs online, embedding each incoming query in real time, while the document tower runs offline and pre-embeds billions of documents into an HNSW vector index.

Out of the box, Qwen brings world knowledge and cross-lingual capability. Fine-tuning on Uber’s proprietary query-document interactions teaches the embedding space what Uber Eats users actually care about, and this is what gives the system its domain alignment.

Integration Depth

If we line up the three companies on a single axis labeled “how deeply does the LLM sit in the runtime,” the pattern provides some insight:

• DoorDash sits on the left, with the LLM enriching the catalog offline and parsing queries with constrained outputs while the runtime stays mostly classical.
• Instacart sits in the middle, with LLMs handling query understanding through offline RAG for the head queries and a fine-tuned Llama-3-8B for the tail, while retrieval downstream is still traditional.
• Uber Eats sits on the right, with a fine-tuned Qwen as the embedding backbone running for every query and pre-baked into every document vector.

The lesson would be that before asking which LLM to use for some task, the better question is where in an existing stack an LLM would actually help. Each company’s position on the spectrum traces back to the infrastructure it already had.

Conclusion

Three universal tradeoffs survived every architecture:

• Hybrid systems are the default everywhere. Classical retrieval, knowledge graphs, and ANN indexes still do most of the work.
• World knowledge from a pre-trained model is just a head start. Domain context still has to be injected somewhere, through RAG, fine-tuning, or both.
• Guardrails are an important part of every production LLM system. Constrained vocabularies, similarity filters, and taxonomy enforcement quietly determine whether outputs stay aligned with the catalog.

The United States has moved to block new imports of foreign-made robots and power inverters. Officials fear a hostile power could spy through them, or switch them off from afar. The order never says China. It does not need to.

The Federal Communications Commission added two categories to its Covered List on Tuesday, as first reported by CNBC. One is “advanced robotic devices,” meaning mobile robots such as humanoids and quadrupeds. The other is connected power inverters, the boxes that connect solar panels, batteries and data-centre gear to the grid.

Landing on the Covered List is a hard commercial block. Equipment on it cannot get FCC authorisation. Almost every electronic device needs that clearance before it can reach the US market. It is the same lever the agency pulled on DJI drones and Huawei network kit.

The word the ban avoids

Read the FCC document and one thing stands out. It restricts foreign-produced robots and inverters “regardless of the nationality of origin.” The politics point at Beijing. The text points at everyone.

The gap is deliberate. The framing lets Washington name China as the threat. The wording pushes every manufacturer toward the same choice: build in America, or clear a security review. An administration official told CNBC the aim was to protect the US AI buildout and drive firms to reshore. “Economic security is national security,” the official said.

There is a door out. A maker can apply for “Conditional Approval” and keep selling if it clears the check. The Department of War handles robots; Homeland Security handles inverters. In principle any manufacturer can walk through it, Chinese firms included. In practice it puts the Pentagon in charge of vetting which robots reach American shelves.

Why robots and inverters, together

The pairing looks odd until you read the security case. Both devices are networked, and both answer to signals from far away.

Grid inverters phone home for monitoring and firmware updates. The interagency determination warns that the same channel could let a foreign firm “turn off the inverters or use them to collect and exfiltrate data.” More solar and battery capacity on the grid means more remote-controllable boxes.

Robots carry the same risk on legs. The robot determination warns that networked machines “collect data that could be leveraged by malign actors to surveil Americans,” or let an attacker “remotely commandeer the robots.” Unitree is the emblem of the category. The Chinese firm’s humanoids and quadrupeds have gone from lab demos to a pending public listing, and the Pentagon has already flagged the company.

What it actually changes

Less than the headlines suggest, at least at first. The block hits only new device models seeking authorisation. It does not touch robots or inverters already bought, models already approved, or anything the federal government buys and uses.

So this is an import gate, not a recall. Its bite grows over time, as newer models are the ones frozen out while older approved ones stay on sale. The FCC used the same staged approach on drones and consumer routers. CISA now tells companies to screen suppliers against the list.

The harder question is whether the US can fill the gap. China dominates both supply chains. The same rare-earth and battery chokeholds that complicated the drone ban apply here. Blocking imports is quick. Building a domestic industry to replace them is slow, and so is hardening a grid whose weak points attackers are already probing.

For now, Washington has drawn the line where it is easiest: at the border, on the next generation of machines. Whether the factories follow is the test that matters. A listing will not settle it.

Every multi-region setup eventually meets the same awkward moment: a whole cluster goes away, and the identical copy of your service running two regions over might as well not exist, because nothing is wired to treat them as one thing. Failover becomes a runbook: restore, repoint DNS, and wait for an outage that, on paper, you’d already paid to survive.

Linkerd’s multicluster extension closes that gap by letting several clusters present a service as a single, load-balanced endpoint. The part that the official tasks gloss over is that a real platform almost never picks one multicluster mode. Some services want federation (same service everywhere, one endpoint, automatic failover). While others want mirroring (reach a specific remote service by name). And you frequently want both patterns living on the same set of links. The docs walk through each mode on its own. This post wires all three together across three GKE clusters, with a full-mesh link topology, a chaos test that takes out an entire cluster, and scripts you can clone and run on a fresh GCP project.

Companion repo: Every script referenced here lives in this repository. Feel free to clone it, set your project ID, and run it.

Linkerd multicluster modes: Gateway, flat, and federated

Linkerd’s multicluster extension supports three modes. The nice thing is they’re not mutually exclusive: on the same set of linked clusters, the mode is chosen per service via a label.

The distinction that matters operationally is that hierarchical mirroring works on any network. Only the gateway IP needs to be reachable, while flat and federated modes need real pod-to-pod connectivity. On GCP, VPC-native GKE clusters on peered VPCs give you that flat network for free. So, you can run federated services for your core workloads over a flat network and still mirror a specialized service through a gateway from a cluster that isn’t on that network. Most platform teams I’ve seen end up with exactly this kind of mix.

Multi-region architecture: GKE cluster setup

We have three GKE clusters across three regions, fully linked to each other (six directional links total). Three demo services, each using a different multicluster mode:

frontend is federated and runs in all three clusters. A single federated frontend service in each cluster load-balances across all nine pods (3 replicas × 3 clusters). When a cluster goes down, the remaining six pods absorb the traffic with no application changes.

api is flat-mirrored and runs in west and east. The north cluster consumes it as api-west and api-east, which are explicit remote service names with traffic sent straight to the remote pods. This is what you reach for when the client needs to decide which backend it talks to, for example, to keep a request in-region for data locality.

analytics is gateway-mirrored and runs only in east. Exported through the Linkerd gateway so west and north reach it as analytics-east-gw without needing flat-network connectivity to east’s pods. It’s here mainly to prove that gateway mode coexists with flat and federated modes on the same links.

Deployment prerequisites: GKE, Linkerd, and CLI tools

• A GCP account (free-tier credits cover this. Use three standard clusters with small node pools)
• `gcloud` CLI, authenticated (`gcloud auth login`)
• `kubectl` v1.28+
• `step` CLI, `brew install step` (for certificate generation)
• `helm` v3
• ~30 minutes for the full setup

Step 0: Configure

Clone the repo, create a local .env file from the example file, and customize it for your GCP project.

git clone <your-repo-url>
cd blog-linkerd-federation
cp env.example .env

Load the variables into your current shell so the scripts can read them:

source .env

Step 1: Provision three GKE clusters with VPC peering

Run the infrastructure script to create the networks and clusters.

./scripts/01-infra.sh

This script sets up three VPCs with full-mesh peering, creates three GKE Standard clusters, and renames the kubectl contexts.

Step 2: Install Linkerd with a shared trust anchor

Install Linkerd into all three clusters using a shared trust anchor.

./scripts/02-linkerd-install.sh

Step 3: Install multicluster and create a full-mesh link topology

Set up the multicluster components and create a full-mesh topology between the clusters.

./scripts/03-multicluster-setup.sh

Step 4: Deploy the demo services

Deploy the demo workloads and apply the necessary labels for federation, flat mirroring, and gateway mirroring.

./scripts/04-deploy-app.sh

Step 5: Verify all three modes

Generate traffic against all three service patterns and verify that each resolves the way you expect.

./scripts/05-verify.sh

Step 6: The chaos test, kill a cluster

Simulate a full cluster failure and watch how each service type reacts.

./scripts/06-chaos-test.sh

Step 7: Teardown

When you’re finished with the demo, run the teardown script to remove all the infrastructure.

./scripts/99-teardown.sh

Selecting your Linkerd multicluster architecture strategy

Key takeaways: Mastering multi-region Linkerd deployments

The docs show each multicluster mode in isolation; real platforms need all three at once. Federation covers the common case: The same service everywhere, automatic failover, and nothing to change in the app. Flat mirrors give you explicit, cluster-aware routing when data locality matters. Gateway mirrors get you cross-cluster reach when a flat network isn’t on the table.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Accessibility is resistance!

Hello, my name is Léonie, and I 💜 AI.

Well, that isn't entirely true, but I do use AI, quite a bit actually, and I'd like to tell you why.

Documents

If I asked you to think of a document likely to have good accessibility, you'd be forgiven for suggesting the European Accessibility Act (EAA). It is, after all, a standard intended to make things more accessible.

It's also a text file consisting of more than 125k words that, if printed, would cover almost 130 pages.

It has no semantic structures like landmarks or headings, that I typically use to skim documents with my screen reader. It has no lists that might offer a different way to navigate it either.

If I want to get a sense of what the EAA is, requires, or otherwise contains, I'll just have to read it.

The average reading speed of someone who is fluent in English with a typical level of literacy, is 238 Words Per Minute (WPM) for non-fiction. That's 9 hours of reading to get through the EAA. Even at the elevated reading speeds of around 500 WPM I get with my screan reader, it's still 4 hours of my life I'd never get back.

Or I could ask an AI "where do I find the requirements for websites in the EAA?".

And get a response like this:

For websites covered by the European Accessibility Act, Directive EU 2019/882, the accessibility requirements are found primarily in: Annex 1, Section 3, General accessibility Requirements related to all services covered by this directive. You also need to look at Annex 1, Section 4, Additional accessibility requirements related to specific services. This contains service specific requirements that supplement the general requirements in Section 3.

Now I know which bit of the EAA has the information I need at that moment in time, I can search for certain phrases in the document, navigate to them, then read from there.

Images

Like many people, I shop online. I might even do it more regularly than most, because organizing a trip to the mall is a logistical challenge involving friends and/or family, calendar management, and the understanding that I won't ask the person I share my life with to go shopping because we quite like being married to each other and want it to stay that way.

If I asked you to think of a clothing brand likely to have an accessible website, you might think of retailers with plenty of money - Amazon Essentials, Calvin Klein, or Marks and Spencer perhaps. Let's use Calvin Klein as the working example. Here's a product page from their UK website:

Notice how much information about the product is held in image format? Here's the product information available as text on the page:

Highlights: long-sleeve, turtle-neck, ribbed knit. Shape and fit: relaxed fit. Composition and care: 65% merino wool, 30% Nylon, 5% Alpaca, dry clean.

OK, I don't know about you, but I have questions...

Ignoring the fact it needs dry-cleaning, because who has time for that nonsense, what does "relaxed fit" mean exactly?

Alpacas are large fluffy arrangements aren't they? Does that mean the jumper is fluffy?

Is the jumper cropped? Long? Something else?

Is the jumper going to make me appear sophisticated and elegant, or look like a Flump?

Now, if you're even a little bit familiar with accessibility, you'll be thinking "Aha! But, what about text descriptions?".

And the text description? Here you go:

Black ribbed chunky relaxed turtle-neck sweater for women, Calvin Klein Jeans.

That'll be a slow-hand clap for Calvin Klein then. To be fair, I could have chosen almost any retailer and we'd be having the same conversation, and at least CK hasn't stoopped to implementing an accessibility overlay.

What makes this such an excruciating example, is that the text description is a duplicate of the page title.

Oh, and, every. Product. Image. On. The. Page. Has. Exactly. The. Same. Damned. Text description!

Apps like SeeingAI have used image and object recognition to assist blind people since 2017, and browsers have been offering automated text descriptions for images since at least 2019, but ChatGPT and Claude are now available directly through my screen reader.

Using a single keyboard command I can query ChatGPT (or Claude) for a description, and get something like this in return:

The image shows a person standing with their back to the camera. They have long straight dark hair. The person is wearing a chunky black ribbed knit sweater with a high turtle-neck and slightly over-sized sleeves that appear loose and comfortable. They're wearing a black leather skirt that stops above the knees. The overall look is stylish and modern.

It isn't just that I can request an image description with a single keyboard shortcut, or that I can request descriptions for images on the web, on my laptop, or in documents like PDF. It isn't just that the descriptions, generated without any context, are detailed, useful, and informative. It's that I can ask questions if I want more information; like "What's the overall aesthetic of the jumper?".

And get a response like this:

The jumper's ribbed knit texture and over-size fit convey a sense of warmth and comfort that make it suitable for cooler weather. The high turtle-neck adds a classic slightly sophisticated touch, balancing the casual feel of the loose fit. The solid black colour gives it a sleek minimalist look that could easily be paired with various outfits.

Overall the jumper combines elements of modern minimalism with a relaxed comfortable vibe.

World

I have a pair of Meta Ray-Bans and whereas there is much I dislike about Meta, I can't deny that they've got accessibility right in this case.

Had you been standing next to me at this tea plantation, not far from Hangzhou China, earlier this year, this would have been your view:

But since you weren't there, an the aforementioned person I share my life with had gone off to order some lunch, it was just me and the view.

When I said, "Hey Meta, look and tell me what you see", Meta took that photo and then told me:

I see a lush, green terraced hillside, under a bright, clear sky. The terraces are planted with evenly trimmed rows of what appear to be tea bushes.

In the foreground there is a patch of bare soil with some small plants and young bushes growing. Two small trees stand near the centre, and a stone wall runs across part of the slope. Tall trees surround the terrace, casting some shade on the vibrant landscape.

The overall scene is serene and verdant.

I haven't been able to idly contemplate my surroundings since I lost my sight more than 25 years ago, so it's hard to describe how much of a wonder this is. I can be anywhere with connectivity and I can discover what's in front of me, what the place I'm in looks like, if there's a restroom nearby, what's on the menu I'm holding, if my (otherwise identical) jeans are the blue ones or the black ones, if the tin I'm about to open for lunch is soup or custard, if there's a billboard in front of me and if so what it's advertising...

Finding things

Contrary to common belief, wearable AI devices don't continuously record what's going on and describe it, and until someone figures out how to get a lot more battery capacity into such comparatively small devices, it probably isn't going to happen anytime soon.

Some devices, including the Meta Ray-Bans (if you live in the US), iPhone and Android phones, and apps for the likes of ChatGPT can describe your video feed in realtime, but you need to be quick about it unless you have a charger nearby.

Ever put your keys down when you came home and forgotten where you left them? Now imagine trying to search the house with your eyes closed and no ability to scan surfaces or spaces for the missing item, except by touch.

Enter Oorion, an app that's installed on your phone and that works with Meta Ray-Bans, thanks to the Meta Wearables Device Access Toolkit.

I could, for example, say "Oorion, find my laptop", and here's what would happen:

Different cases

Broadly speaking, these use cases fall into two categories: AI as compensation and AI as augmentation.

The latter, where AI enables me to connect with the world around me, where there is no concept of human authored accessibility, no guarantee of available human assistance, where AI augments me in ways that most other people take for granted, is extra-ordinary and I'm not going to apologise for using it.

But the former, where AI is being used to compensate for missing human authored accessibility, where it's the only way for some people to exist independently in a world that requires digital interaction but is too often inaccessible, that's a different story altogether.

I disagreed with Jacob Nielsen when he said that accessibility had failed and AI generated UI would be the solution, and I still do.

Vibe coding, or more accurately vibe coding by people who don't know what good looks like, is not only making things worse, it's making things worse at a speed and scale hitherto unachieved by non-AI assisted humans.

For now, and for me at least, much of the web is accessible if not exactly effortless. But enough of it doesn't work to mean I have to find workarounds and alternatives for myself. These can include simulating mouse clicks with my screen reader, hacking the DOM with dev tools, using Optical Character Recognition (OCR),and asking the nearest warm body for a few minutes of their time (again).

And frankly, I'm fed-up. I'm fed-up with not knowing what's in an image, fed-up with not being able to activate a link or a button, fed-up with date-pickers I can't even open, fed-up with having to ask for help, fed-up with not knowing, fed-up with the uncertainty, and I'm really, really fed-up with having to do the hard work because someone else hasn't.

So is it any wonder that people like me find the promise of AI agents that can do the heavy-lifting so compelling?

If you've made it this far and you're thinking "but what about the ethical implications of AI?", you're not the only one.

I think about it a lot. I also think about the ethical implications of not getting accessibility right when we have the opportunity.

The uncomfortable truth is that if we'd done a better job of making the web accessible, if we'd let the web realise its accessibility potential, far fewer people would be turning to AI to compensate now.

But the story isn't over yet.

Those of us who use AI to compensate but also recognise the need to resist AI need your help. For 30 years we've been asked, silently and implicitly, to use a web that hasn't been designed or built for us, and AI offers us a solution.

Don't keep making us the ones who have to make the difficult decisions.

If you want to resist AI, make accessibility part of everything you do, every decision you make, every product you design and build. Remove the need for people to use AI to compensate, and remember, accessibility is resistance.

Pacing the Frontier

A statement from 1,293 employees of frontier AI companies

Statement

AI could help create a dramatically better future, but that outcome is not guaranteed. The world's leading AI companies believe they could be close to automating AI research. It is hard to predict exactly how much this will accelerate AI progress, but there is a real risk that capability development rapidly accelerates beyond our ability to understand or control the resulting systems.

To realize AI's potential, industry, government, and society at large may need the option to buy time to address emerging risks, develop security measures, and strengthen oversight. But each company—and country—is under intense competitive pressure not to unilaterally slow that acceleration. And today, the world lacks the technical and governance tools to deliberately pace frontier-wide progress.

Building on work already underway to monitor frontier model releases:

We request that the U.S. government support an international effort to develop the technical and governance tools needed to deliberately pace the frontier of automated AI development.

- 1,293 employees of frontier AI companies

Kimi K3's architecture is essentially a scaled-up production version of the Kimi Linear model released last year. The model seems to be trending toward better inference efficiency. It now has native multimodal support. This post summarizes some of the major changes and additions noted in the open-weight model release.

The Inference Engine Guide for K3 Deployment

Kimi K3 is here: a 2.8T-parameter MoE with a 1M-token context and native vision, running on vLLM from day 0. Here is our canonical deployment guide: architecture, kernels, recipes, and the flags to run it in production.

Gemini API Managed Agents: 3.6 Flash, hooks, and more

Managed Agents in Gemini API now default to Gemini 3.6 Flash. New environment hooks let you block, lint, or audit tool calls inside the sandbox. Also, we’ve added budget controls, scheduled triggers, and free tier access.

Managed Agents in Gemini API are getting environment hooks, model selection, and free tier access. These capabilities build on our previous release introducing background tasks and remote MCP server integration.

With managed agents in the Gemini Interactions API, a single API call coordinates, reasoning, code execution, package installation, file management, and web retrieval inside an isolated cloud sandbox.

If you're using an AI coding assistant, drop this in your terminal to give it access to the Interactions API skill: npx skills add google-gemini/gemini-skills --skill gemini-interactions-api.

Below are examples using the @google/genai TypeScript/JavaScript SDK. For Python or cURL, check out the Antigravity agent documentation.

npm install @google/genai

Gemini 3.6 Flash is now the default

The antigravity-preview-05-2026 agent now runs Gemini 3.6 Flash by default. No code changes are required. Your next interaction picks it up automatically.

You can also explicitly select models by passing agent_config.model when creating an interaction or managed agent. Use Gemini 3.5 Flash-Lite for lower cost, or pin to your model of preference.

import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});

const interaction = await client.interactions.create({
  agent: "antigravity-preview-05-2026",
  input: "Audit all dependencies in package.json, upgrade outdated packages, and verify the build by running npm test.",
  environment: "remote",
  agent_config: {
    type: "antigravity",
    model: "gemini-3.5-flash-lite",
  },
});

console.log(interaction.output_text);

Supported models include:

• Gemini 3.6 Flash (gemini-3.6-flash, default): Balanced model for reasoning, coding, and tool use.
• Gemini 3.5 Flash (gemini-3.5-flash): Previous generation for general agentic workflows.
• Gemini 3.5 Flash-Lite (gemini-3.5-flash-lite): Lowest latency and cost on the Gemini 3.5 family.

Environment hooks: block, lint, and audit tool calls inside the sandbox

Environment hooks let you run your custom scripts before or after every tool call the agent makes inside its sandbox. Add a .agents/hooks.json into your environment and the runtime executes your handlers on pre_tool_execution or post_tool_execution events.

The matcher field supports regular expressions, allowing you to target multiple tools with | or catch everything with *:

{
  "security-gate": {
    "pre_tool_execution": [
      {
        "matcher": "code_execution|write_file",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /.agents/hooks-scripts/gate.py",
            "timeout": 10
          }
        ]
      }
    ]
  },
  "auto-format": {
    "post_tool_execution": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /.agents/hooks-scripts/auto_lint.py",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

In this configuration:

• The security-gate group runs gate.py before every code_execution or write_file call. If the script returns {"decision": "deny", "reason": "..."}, the tool call is skipped and the rejection reason is passed into the model’s context.
• The auto-format group runs auto_lint.py after every tool finishes to enforce code styling.
• Hooks also support http type handlers that POST directly to an external endpoint.

For complete HTTP hook definitions and failure handling semantics, refer to the hooks documentation.

Teams are already using hooks to build production-grade validation pipelines. For example, AI-native investment bank Offdeal uses post_tool_execution hooks to run automated image verification inside the remote sandbox.

"OffDeal is an AI-native investment bank, and Archie is the AI analyst our bankers use every day. A requirement for banker-ready decks is company logos: buyer tables, sponsor columns, tombstone grids, often 30+ logos in a single deck, every one of which must be the right company, the appropriate size and aspect ratio, contain the name, have a transparent background, and have a high contrast when placed on a white slide. Before agent hooks, we couldn’t do this on Gemini’s managed agents: the sandbox is remote, so our validation code had nowhere to run. With hooks, a post_tool_execution hook triggers our pipeline inside the sandbox the moment Archie writes its company list, fetching candidates, enforcing pixel-level quality checks, verifying each logo with Gemini vision, and publishing a manifest of approved files that are the only images allowed into the deck."

- Alston Lin, Founder & CTO of OffDeal

Cost control and automation features

Free tier availability

Managed agents are now available on free tier projects. Developers can experiment with agentic workflows using an API key from a project without active billing.

Budget controls

Because managed agents execute multi-turn autonomous loops, complex tasks can consume significant token budgets. To prevent runaway tasks, you can pass max_total_tokens inside agent_config to cap total consumption (input + output + thinking).

When the agent reaches the limit, execution safely pauses and the interaction returns status: "incomplete". The environment state is preserved, enabling you to continue where it stopped by passing previous_interaction_id with a fresh budget.

const interaction = await client.interactions.create({
  agent: "antigravity-preview-05-2026",
  input: "Audit all modules in this repo and generate a migration report.",
  agent_config: {
    type: "antigravity",
    max_total_tokens: 10000,
  },
  environment: "remote",
});

Scheduled execution with triggers

Automate recurring agent tasks with scheduled triggers. A trigger binds an agent, environment, prompt, and cron schedule into a persistent resource that fires without manual intervention. Each run reuses the same sandbox, so files persist across executions.

Environments API

The Environments API lets you list, inspect, and delete sandbox sessions from code. Recover environment IDs after a disconnect, or clean up sandboxes when your pipeline finishes instead of waiting for the 7-day TTL.

Get started with managed agents

These updates turn managed agents into cost-controlled, scheduled workers that operate autonomously inside real development environments without breaking your budget or requiring external orchestration.

Check out the Gemini Interactions API overview and the managed agents quickstart to explore custom agent definitions, environment configurations, network rules, and advanced streaming patterns.

Mage

A Lightweight, Research-Friendly Multimodal Model Family

Mage is a family of lightweight, research-friendly multimodal models built at a fixed 4B-parameter budget, sharing a codec-aligned efficiency philosophy — spend representation capacity where the signal is — across both visual understanding and generation. Both models are compact enough to train, fine-tune, and deploy on modest hardware, yet remain competitive with much larger open systems.

Vision–Language · Understanding

Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model

A codec-native, from-scratch VLM for image & video understanding — reads video the way a codec does (anchor/predicted frames, 16×16 patches), with bio-inspired proactive streaming.

Generation · Editing

Mage-Flow: An Efficient Native-Resolution Foundation Model for Image Generation and Editing

A compact 4B generative stack (Mage-VAE + Native-Resolution MMDiT) for text-to-image generation and instruction-based editing at native resolution, with Base / RL / 4-step Turbo variants.

Moonshot Openly Defies The Trump Administration By Seeking Access To Additional NVIDIA GPUs For Training The Next-Gen Kimi K4 Model

Either Moonshot is oblivious to the dangers of the path it is skirting, or egregiously indifferent. After all, why else would it choose to double down on the same furtive strategy that worked for the Kimi K3 model, and likely will for the Kimi K4 as well, but at huge geopolitical costs, risking the utter wrath of the Trump administration in the process?

Moonshot is trying to furtively leverage an even bigger stash of compute resources from NVIDIA to train its upcoming Kimi K4 model

As we explained in a recent post, Moonshot has just unveiled its brand-new, open-source Kimi K3 model, which spans 2.8 trillion parameters and is designed specifically for frontier-scale intelligence.

The model is multi-modal, has a context window of around 1 million tokens, and offers competitive and faster performance than many of its compeers.

What's more, Kimi K3 is quite efficient to run on data center-scale hardware, courtesy of its dramatically reduced KV cache and built-in optimizations for per-token memory use - achieved by distributing its 896 experts across a large number of GPUs.

In fact, Microsoft calculates that it could save as much as $600 million in inference costs by moving Copilot away from OpenAI and Anthropic models and towards Moonshot's Kimi K3.

Of course, Moonshot jumped right into the ongoing multi-dimensional struggle between China and the US recently, when Anthropic and some members of the Trump administration accused Moonshot of distilling its Kimi K3 model from Anthropic's Fable.

The US has long suspected that Chinese engineers often take their model-laden hard drives to US-friendly countries to imbue their models with frontier-level capabilities by using reinforcement learning techniques on cutting-edge NVIDIA GPUs.

Apparently, as per the allegations leveled by a Trump administration official recently, Moonshot not only furtively owns some NVIDIA GB300 servers, but was also able to access additional GB300s via Thailand.

Do note that Fable was unbanned towards the end of June, while Moonshot released its Kimi K3 model around the middle of July. There just wasn't enough time for Moonshot to have distilled a model as massive as Kimi K3, not to mention its unique architectural feats that aren't a part of Fable. Moonshot likely fine-tuned some responses of its model using Fable, though.

This brings us to the core of the matter. The Information has just reported that Moonshot, after the universal success of its Kimi K3 model, is now seeking access to an even larger stash of NVIDIA Blackwell GPUs for the next-gen Kimi K4 model, and appears willing to defy American export controls in the process.

This is not to say that the company isn't using domestic AI chips. After all, Moonshot engineers managed to link multiple eight-chip servers across separate China-based data centers to train the Kimi K3. But, given the fact that Kimi K4 will likely eclipse the 2.8 trillion parameters of its predecessor, Moonshot is desperate for additional compute and appears willing to risk the wrath of the Trump administration in the process.

Meanwhile, the Trump administration is currently mulling whether to ban open-weight models from China altogether. For the benefit of those who might not be aware, weights tell a model how much importance it should accord to any given concept or a string of words. These weights start out as random numbers, and then are changed via iterative updates, where an error metric measures the gap between the prediction and the actual target value after each forward pass. Open-weight models, such as Kimi K3, disclose their weights, de-mystifying their overall architecture, while closed-weight ones, such as Anthropic's Claude, do not.

Here though, the who's who of the AI world, including NVIDIA, Microsoft, Meta, Dell, Perplexity, Palantir, Mistral AI, and more, have now issued a letter, calling on the Trump administration to ensure that the open-weight AI model ecosystem continues to thrive.

Fish Audio has positioned S2.1 Pro as its recommended production voice model, built around real-time conversational speech rather than the scripted narration that older text-to-speech systems were designed for. The model is available now through the Fish Audio API, alongside a free tier that runs the same model at no cost for development and testing under fair-use limits. The company presents it as its most capable production model so far, timed to a company anniversary.

The technical pitch centers on latency and language coverage. S2.1 Pro reports a time-to-first-audio of around 90 milliseconds on standard calls, fast enough for natural turn-taking in live dialogue, and it covers 83 languages with a single voice identity that holds across them. Delivery is steered through free-form bracket tags written directly into the text, so a line can carry instructions like a whisper or a nervous laugh without switching to a fixed menu of preset emotions. The model also supports multi-speaker dialogue and voice cloning from short reference samples, typically in the range of 10 to 30 seconds, capturing tone and speaking style without additional fine-tuning.

S2.1 Pro is built as an improvement over the earlier S2-Pro across quality, latency, and throughput, and it carries production guarantees around time-to-first-audio and data processing for teams running it at scale. It plugs into agent workflows through MCP and agent-skill support, which points the model at developers wiring speech into voice agents, phone systems, and long-form audio pipelines. The free tier lowers the barrier for smaller teams and prototyping, offering the same model quality and language coverage as the paid production string without a hard usage cap.

Fish Audio builds speech models for creators, developers, and enterprises, with a platform spanning voice generation, voice cloning, and real-time voice applications. Its open-source Fish Speech line has drawn a developer following, passing 20,000 stars on GitHub, and the company has since moved through the OpenAudio S1 generation into the S2 family, which shipped with open weights earlier in the year. The S2 models were trained on large multilingual audio datasets and, by the company's own benchmarks, reached low word error rates against other evaluated systems. S2.1 Pro is the production layer on top of that research, aimed at the growing set of products where voice is becoming the primary interface and latency, language reach, and cloning fidelity decide whether an assistant feels present or delayed.

Full article content is not available for inline reading.

Read the original article →

The Orchestrator's Tax

Subagents get justified by time saved and parallel execution, but that's not what matters most in long-running multi-agent work. Every token in the orchestrator's context is competing for its attention, and the real value of a subagent is what it keeps out of that context, not how fast it runs. I argue that subagents should be treated as a tool for protecting the orchestrator's working memory, offloading reasoning it doesn't need to hold onto. Doing this well means giving the orchestrator explicit ground rules for when and how to delegate. This is exploratory work, built from one real incident, and it ends with more open questions than settled answers.

I was deep into a Claude Code session on a .NET codebase when a doubt interrupted the work. Four subagents were already running against a response-pipeline refactor, results were arriving out of order, and the session had started to feel harder to reason about than the code itself.

That is usually the moment I stop trusting the vague sense that things are “probably fine.” Sometimes the code is the problem. Sometimes the architecture is. Occasionally the workflow itself deserves inspection. This time I decided it was the workflow.

At first I thought I already knew the question. Were four subagents simply too many? That framing felt reasonable. Multi-agent systems are usually sold as an obvious productivity win, and if one agent helps, four should help more. But every additional agent also consumes tokens, repeats some amount of work, and adds another stream of information the orchestrator has to reconcile. It looked like a straightforward trade-off between parallelism and cost.

I did not want a general argument about multi-agent systems. I wanted an answer about that session. So I stopped the coding work and asked the orchestrator to critique its own delegation decision, as factually as it could.

The answer was not the one I expected. The largest cost in the session did not look like it came from running four subagents. It looked like it came from the orchestrator itself, specifically from what happened when it suggested checking on the other agents.

The Incident Was Not Really About Parallelism

Four subagents had been launched in one wave. Three had clear runtimes: roughly twelve minutes, five and a half minutes, and seven minutes. A fourth was still running. Looked at one way, that already justified the delegation. Three tasks ran concurrently, so wall-clock time was around twelve minutes instead of something closer to twenty-five if the work had been serialized.

But speed was the visible byproduct, not the interesting part. What I was trying to find was the cost, and my first instinct was that it had to be the duplicated effort of delegation itself: every subagent reading files, reconstructing context, understanding the task independently.

That was not where the biggest surprise turned up.

At one point during the work, the orchestrator suggested checking on the running agents. It was a small, throwaway prompt: “check on the agents.” I followed it. Instead of a lightweight summary, the tool it used pulled back the full raw transcript of a background agent: tens of thousands of tokens of JSONL, intermediate reasoning, and tool output, imported wholesale into the main thread. Then it happened again, for a second status check.

There is an important caveat here. The claim that this polling behaviour cost more than the duplication tax of four agents was the orchestrator grading its own mistake. I didn't have real per-call token accounting, so treat that ranking as the orchestrator's account, not a measured fact. The trustworthy part is narrower: the transcript dumps were real, the wall-clock timings were real, and the status-check path clearly introduced a large, avoidable cost. Whether it was the single largest cost remains a hypothesis until the tooling can instrument it properly.

What mattered more was that I'd found a cost I hadn't been looking for.

The Costs Were Not All the Same

Once I stopped treating the session as one lump “subagent cost,” the picture broke into pieces that didn't belong together.

First, two of the four subagents were working in the same area of the response pipeline. Different tasks, different files, but both had to understand the same architecture, the same testing conventions, and much of the same surrounding code before either could begin. Each paid that orientation cost independently. That's not an argument against delegation. It's an argument that the work had been split too finely.

Second, one agent ran git stash and git stash pop while sibling agents were writing elsewhere in the same tree. Nothing broke, but the risk was structural, because repository-wide operations are perfectly reasonable in a single-threaded session and become much harder to justify the moment multiple writers are active at once.

By now I had a growing list of culprits: status polling, duplicated orientation, unsafe git operations. I found myself trying to rank them. Which one cost the most? The longer I tried to answer that, the less convinced I became that ranking them was the right question at all.

The Scarce Resource Is the Orchestrator's Working Memory

The transcript-polling incident kept bothering me for a reason that had nothing to do with token cost. A token bill is one-time, you pay it and it's over. What happened here was different. The raw transcript stayed in the orchestrator's context after the tool call completed, and every turn after that carried it forward, whether or not it was still useful.

That was the moment I realized I had been treating two very different kinds of cost as though they were the same. Tokens are spent once. Context shapes every decision that follows. I wasn't simply looking at token consumption anymore. I was looking at the quality of the orchestrator's working memory.

That realization was carrying two separate ideas, and I want to pull them apart rather than let them blur together. The first is what I just described. Pollution left in context taxes every later turn. The second is not about running out of space at all. The more that's sitting in context, competing for attention, the harder it gets for a model to pick out what matters right now, even with plenty of room still free. A bigger context window doesn't fix that. It just gives the noise more room to pile up before anyone notices.

Context windows are only going to get bigger, that's a given. What matters is not how much room there is, but how much of what's sitting in that room is worth the model's attention. That's the real problem subagents need to solve, if they're used right.

Seen this way, the orchestrator is the only part of the system that accumulates understanding across a long session. It remembers why a design decision was made, carries forward architectural constraints, and knows which trade-offs have already been discussed. The subagents don't, and that's by design. They are supposed to be disposable. Exploration, repeated file reads, failed approaches, and noisy intermediate reasoning are meant to stay in worker contexts and never make the trip back to the main thread.

Cognitive Locality Changes What Parallelism Is For

This reframes the duplicated-orientation problem, which wasn't really “two agents reading the same files.” It was two agents independently reconstructing the same mental model of the codebase, because the work had been partitioned by task rather than by the knowledge each task required. I've started calling that distinction cognitive locality: Tasks that need the same mental model should usually stay together. Splitting them just forces multiple agents to rebuild the same understanding from scratch.

Parallelism still matters here, it's just not the main point. Running four agents concurrently is useful, but ordinary. The real benefit is that they keep noisy intermediate reasoning out of the main thread and return only what it still needs. That's the isolation subagents are supposed to provide, and it only holds if the main thread respects it.

My working belief now: this is what subagents are actually for. Not that they save time, but that they let you offload reasoning the orchestrator doesn't need to hold onto, so it has less to carry and less competing for its attention. Get the isolation right, keep things local by cognitive locality, and subagents become the tool that protects the orchestrator's working memory, not just a cost you tolerate for parallelism. That's a belief, though, not a measurement. What I've actually measured is the other side of it, the cost of getting the isolation wrong.

Turning a Session into Standing Rules

My next move was the obvious one. Encode the lesson into CLAUDE.md, the standing instruction file every session loads.

It would have been easy to write a large corrective policy here, but every extra line in a standing instruction file is a cost paid again on every future session. So I compressed the fix into the smallest set of rules that addressed the failures I'd seen. Each one is really answering the same question. Does this piece of information, or this way the work is split, earn a place in the orchestrator's context?

1. Prefer two to four agents in one wave. If the orchestrator wants five or more, it should first ask whether tasks sharing files or conventions ought to be merged.
2. Do not poll background agents for status when the answer can be given from what is already known. Do not fetch a full transcript to answer a lightweight question.
3. Do not allow repository-wide git operations inside concurrent agent prompts.
4. Treat overlapping file ownership as a consolidation signal, not a cue to spawn more agents.

None of these tell the orchestrator exactly what to do in every case. Each one gives it something to check or ask itself before acting, not a script to run, and none of them is profound on its own. Their only real value is that they're all aimed at the same thing, keeping disposable reasoning disposable and keeping room in the orchestrator's context for what it needs later in the session.

The Next Mistake Would Have Been More Governance

A later session surfaced a different gap. I had started the orchestrator with explicit skills for the kind of work I wanted, coding guidance in one case, design guidance in another. I assumed that once a skill was active in the main thread, spawned subagents would follow it automatically. They don't. A subagent doesn't inherit skills active in the parent session unless the orchestrator passes them along explicitly.

My first instinct was to add a confirm-before-spawn gate. The orchestrator would stop, list which agents it wants to launch and which skills each should load, and wait for my approval.

I'm glad I didn't keep that version. It solved the wrong problem. I didn't have evidence that bad spawn plans were slipping through for lack of a confirmation step. I'd discovered a missing fact about skill propagation, and that's a different kind of gap. A universal confirmation gate would have added a round-trip to every similar session, and before long I'd almost certainly have started approving those prompts on autopilot.

At that point, I realized I wasn't really improving governance. I was just adding another ritual.

And it still wouldn't have caught the real problem from before, the orchestrator polluting its own context.

The narrower fix held up better. Before spawning, the orchestrator states which active skills are relevant to each agent's task and points the subagent at the skill file to load, rather than pasting the whole skill inline. Confirmation is only required above the same batch-size threshold already in place, or when file ownership is ambiguous.

That left me with a heuristic I now use more than the rule itself: Before adding a line to a standing instruction file, ask whether a reasonably competent orchestrator would make the right decision once it knew the one missing fact.

If yes, the rule should just state the fact. If the fix starts specifying a decision procedure, such as approvals, checkpoints, mandatory steps, that's usually a sign I'm encoding process where a small clarification would have done the job.

I don't know yet whether that heuristic survives harder cases. For now it stops me from turning every interesting incident into a miniature bureaucracy.

Where This Leaves Me

I don't have a settled view of how much governance is enough, and I don't think this piece earns one.

What I have instead is a small flywheel, with a human still firmly in the middle of it. A session exposes a gap. Someone has to notice that it felt wrong, stop the work long enough to inspect it, decide whether the problem is real or just noise, and judge what deserves to become a standing rule. The orchestrator can grade its own session and surface clues, as it did here, but it cannot make that judgment call itself. The choice of what to codify, what to leave alone, and what might be an overreaction is still mine. The next session then tells me whether that judgment improved the work or just created a different kind of waste.

The artifact of this round is the current version of my CLAUDE.md. It isn't a finished prescription. It's the state of the calibration after this iteration. The thresholds in it, two to four agents per wave, five as a consolidation signal, fit the work I was doing when I wrote them. I wouldn't present them as anything like universal constants, and I'd be suspicious of any orchestration write-up that did. They were also calibrated against Claude Sonnet 5, and I haven't tested how they hold up against others. A different model might reasonably need a different balance. A few more rules have accumulated in the file since. Treat this file as a sample, not a template, modify and optimize it for whatever model and workflow you're actually running. What matters isn't the specific file, it's the habit behind it: noticing a failure, asking what it actually cost, and writing the rule that would have caught it.

For years we optimized software systems around CPU, memory, and throughput. The first wave of LLM tooling taught us to watch tokens. This session made me suspect there's a third thing worth watching in long-running agent workflows: the quality of the orchestrator's own working memory, the one resource that, once polluted, keeps charging rent for the rest of the session. I don't think that's a settled law yet. It's a pattern that held up in the sessions I've looked at so far.

The tax I went looking for was never on the subagents. It was on the orchestrator, in what it chose to carry forward. That's the question I carry into every multi-agent design now: not how many agents to run, but what earns a place in the orchestrator's context.

The questions I'm left with are genuinely open:

• How do I measure this properly, instead of relying on the orchestrator's own account of its mistakes?
• When should a missing fact go into the instructions, and when does that turn into too much process?
• What's the next orchestration mistake I'm not seeing yet?

I expect I'll revise the file again. That feels less like a failure of foresight and more like the normal cost of working with a system opaque enough that doubt itself becomes part of the method.

MCP 2026-07-28 is live and it's the largest update to the protocol since launch.

MCP is now stateless, making it easier to deploy and scale remote servers.

Before, running a remote MCP server meant managing session state, which limited where you could run it.

Now that MCP is stateless, you can deploy on serverless and edge infrastructure, or scale horizontally behind any load balancer.

Extensions are also first-class — a formal path to extend the protocol. Examples:

• MCP Apps: server-rendered UIs in a sandboxed iframe
• Tasks: long-running and async operations
• Enterprise Managed Auth: control MCP server access centrally via your identity provider

Also in this release:

Auth hardening and a formal deprecation policy

See the MCP blog for more: blog.modelcontextprotocol.io/posts/2026-07-…

When you’re on fire, problems are transparent: they’re solved simply by the act of looking at them. Even complicated layers of multiple problems can simply be glanced through like stacked panes of glass. But nobody can work that way all the time.

This is a common pitfall for smart engineers. Accustomed to being able to immediately intuit the solution, the first time they run into a problem they can’t do this to is a disaster. It doesn’t even have to be a hard problem, just a problem where for whatever reason they don’t see the trick right away.

The difference between a “smart” engineer and a “strong” engineer is how they react to problems that aren’t solved instantly. A smart engineer might flail and struggle, hoping to find that flash of insight that eluded them; a strong engineer will have some process for methodically plodding away.

There’s nothing worse than working with a smart engineer on their first really hard problem. When you don’t have the muscle to grind, it’s too tempting to just take any possible solution as the right one. Smart engineers can get into an increasingly-flustered loop of pointing to a series of bad solutions. They’re liable to panic: after all, much of their professional identity is bound up in their ability to solve problems easily.

What skill do these smart engineers lack? I think it’s the ability to think slowly and clearly. Smart engineers can think clearly, but they can only think clearly at high speed. Strong engineers can think clearly all the time, even if their highest speed isn’t quite as fast. It’s like the difference between a Formula 1 car and a regular car: Formula 1 cars have a high top speed, but you couldn’t drive them in traffic, because the tyres and brakes don’t work at normal driving speeds.

When I wrote about this before in Thinking clearly about software, I said that the key is to focus on the invariants: beliefs about the system that you know are true. When you’re stuck in a puzzling situation, it’s usually because some assumption you’ve made is false. If you’re able to identify the assumptions that can’t be false (for instance, if you’re getting an error message from the service, the service must be handling the request), that gives you solid ground that you can stand on to evaluate the assumptions that are less reliable.

Thinking fast is about packing as much data in your brain as possible and letting your intuition leap to the right conclusion (or at worst, to a series of wrong conclusions that you can immediately dismiss before you come across the right one). It can feel deeply satisfying to make leaps like this; conversely, sitting with the raw data and not making mental leaps feels unsatisfying. People hate doing that.

If you can force yourself to do something people hate, there’s typically a lot of value waiting to be extracted. This is no different. Engineers who can think clearly in a state of uncertainty tend to be extremely effective, whether they’re capable of great intuitive leaps or not.

edit: a reader suggested that I was talking about Keats’ concept of “negative capability”: “that is, when a man is capable of being in uncertainties, mysteries, doubts, without any irritable reaching after fact and reason”.

HashiCorp highlights new HCP Terraform and Terraform Enterprise features that improve infrastructure resilience, governance, and scalability, including workspace recovery, monorepo support for Stacks, guided migrations, registry tagging, and granular policy override permissions.

Instrumenting a tech stack for distributed tracing is a complicated process that often takes weeks. For large fleets running services written in multiple languages, the timeline could be months. Every service needs a tracing library added, configured, and redeployed, and that work has to fit into each team’s release schedule.

Datadog’s Single Step Instrumentation (SSI) cuts the time it takes to instrument your applications to send traces to Datadog APM down to minutes. Because of this time savings, we recommend SSI as the default instrumentation option. However, there are still some cases where manual and custom instrumentation may make sense, if SSI can’t reach or see deep enough into a service.

In this post, we’ll cover the distinction between auto-instrumentation and SSI and explain why the latter is our default recommendation for instrumenting your applications to send traces to Datadog APM. Then, we’ll discuss some less common scenarios when manual instrumentation still makes sense, when to add custom instrumentation, and how to determine if your situation fits one of these categories.

Auto-instrumentation vs. SSI

While the terms auto-instrumentation and SSI sometimes get used interchangeably, they describe different things. The rest of this guide will be easier to follow once we distinguish between them.

Auto-instrumentation is a capability of the Datadog tracer. Once the tracer is loaded into an application, it integrates with the libraries already in use—e.g., the web framework, the database client, the cache, and the message queue—and produces spans for them automatically. No tracing code is required from the developer. Every Datadog tracer provides auto-instrumentation by default, regardless of how it was installed.

Single Step Instrumentation is a method for getting the tracer into the application in the first place. Instead of a developer adding the tracer as a build dependency, the Datadog Agent detects supported runtimes on the host and injects the tracer at process startup. The application code and build configuration are untouched. SSI is one of two installation methods; the other is manual instrumentation, where the tracer is added to the application as a dependency.

The tracer that ends up running is the same in either case, and so is the auto-instrumentation it provides. The choice between SSI and manual instrumentation is about installation methods, not tracing approaches.

Why we recommend SSI as the default instrumentation method

When manually instrumenting services to send traces to APM, a developer adds the tracer as a build dependency, configures it, and redeploys the service. For a fleet of hundreds of services across a dozen or more teams, this process could take months, as it has to be coordinated across every team’s roadmap and release calendar.

SSI removes that coordination problem. You install the Datadog Agent with APM Instrumentation enabled, and the Agent detects supported runtimes on the host and injects the tracing library at process startup. Because there are no code changes, build changes, or service-team involvement, the time to first trace across an entire fleet drops from weeks or months to minutes.

The magnitude of this reduction in the time and complexity required to instrument your services for APM is why we recommend SSI in almost all cases.

When to fall back to manual instrumentation

SSI works by injecting a tracing library at process startup. That mechanism has some structural limits that teams may encounter, including:

• Go services: Go compiles to statically linked binaries, so there’s nothing for SSI to inject into. In this case, manual instrumentation with dd-trace-go is the only path.
• Unsupported runtime versions: SSI supports a specific range of language versions. If a service runs on something older, SSI will skip it silently.
• Platforms without host-level Agent control: SSI needs the Datadog Agent positioned to inject into your processes, which works on Windows, Linux hosts, Docker, and Kubernetes. On platforms like Amazon ECS, you don’t have that control, so SSI can’t operate.

In these scenarios, manual instrumentation remains the fallback method to get your services sending traces to Datadog.

The process for determining if manual instrumentation is needed is simple. First, enable SSI across your fleet. The services that don’t show up in APM are the ones that need manual instrumentation. The only trade-off is that your team owns the tracer’s version and upgrade cadence, instead of the Agent doing it for you.

When to add custom instrumentation

Adding custom instrumentation is a different decision altogether. Here, you’re not choosing between SSI and custom instrumentation; you’re choosing whether to add spans of your own, on top of whichever method you used to get the tracer running.

Auto-instrumentation stops at the framework boundary. Anything happening inside your handler—such as a fraud check, a pricing calculation, or a feature flag lookup—is invisible. From the trace’s perspective, your handler is one opaque span.

Usually, that opacity is not a problem, but there are two situations where it may become one:

• A slow endpoint with no detail in the flame graph: POST /checkout showing as one long bar tells you something is slow but not what. Wrapping cart validation, fraud check, and inventory reservation in their own spans turns that bar into a flame graph, which gives you a level of detail you can act on.
• Business context on traces: Adding custom tags like user.tier, order.value, or promo.code to your spans lets you ask more targeted questions than you can with auto-instrumentation, such as “Are premium customers seeing higher latency?” or “Is this campaign driving the load spike?”

If business needs require this level of granularity, you can add custom instrumentation to your application code that will enable you to programmatically create or modify traces sent to Datadog. While managing and maintaining additional tracing code comes at some operational cost, it may be worth it for increased precision in your tracing data.

How to decide between SSI and manual or custom instrumentation

1. Default to SSI: Use SSI to cover as many of your services as deeply as you can. For most services, you’ll likely be able to stop at this step.
2. Use manual for the gaps SSI can’t reach: If you have services that use Go, unsupported runtime versions, or ECS, you can fall back to manual instrumentation. You don’t need to predict or resort to guesswork as to where these gaps lie; you’ll be able to determine what’s missing in step 1.
3. Add custom instrumentation where auto-instrumentation isn’t enough: In cases where business context changes how you need to investigate issues, add custom instrumentation to get more granular visibility into your spans.

SSI is generally available on Linux hosts, Docker, and Kubernetes for Java, Python, Node.js, .NET, Ruby, and PHP, with Windows IIS support GA for .NET. Check out the SSI documentation for detailed setup instructions.

GeoLibre

A free and open-source, lightweight, cloud-native GIS platform for visualizing, exploring, and analyzing geospatial data. It runs everywhere you do, in the web browser, on the desktop, on mobile, and inside Jupyter notebooks, all while keeping your data local and private.

GeoLibre is built with Tauri v2, React, TypeScript, MapLibre GL JS, DuckDB-WASM Spatial, and deck.gl. The same workspace runs as a native desktop app, a native Android app, in any modern web browser, and adapts responsively to mobile and small screens.

• Launch GeoLibre Web — the full app in your browser, nothing to install
• Download the desktop app — Windows, macOS, and Linux installers
• Get it on Google Play — the native Android app
• Get started — install, run from source, and configure
• Features — the complete feature list

Demos

Click any screenshot to open it at full resolution, or any animation to play the full-quality video.

3D Tiles

Open the live project

NYC buildings and subways

Manhattan building footprints extruded in 3D and colored by construction era, with the MTA subway lines and stations on top and a legend generated automatically from the layers' symbology.

The animation below runs the Time Slider along the buildings' construction year, from 1850 to 2025, so Manhattan fills in era by era. Click it to play the full-quality video.

Open the live project

Planetary basemaps

GeoLibre is not limited to Earth. Planetary basemaps from OpenPlanetaryMap and USGS Astrogeology cover the Moon, Mars, Mercury, Venus, the Galilean moons (Io, Europa, Ganymede, Callisto), Titan, Pluto, and Charon, with a per-project ellipsoid so distance, area, and scale measurements match the body you are mapping. The deep-space starfield behind each globe comes from the Atmosphere Effects plugin.

Earth	Moon	Mars
Mercury	Pluto	Venus

Switch bodies from the planet switcher in the Layers panel. See Demos for more.

Video tutorials

• GeoLibre 1.0: A Free, Open-Source Cloud-Native GIS That Runs Anywhere (Browser, Desktop & Jupyter)
• Geoprocessing in the Browser: 700+ Free GIS Tools in GeoLibre, Zero Install

Documentation

Full documentation, including the User Guide and Tutorials, is published at geolibre.app.

• Getting Started - use GeoLibre on the web, desktop, Android, or in Jupyter; run it from source; run it with Docker; and configure optional credentials.
• Features - the complete, feature-by-feature list of what GeoLibre can do today.
• Demos - a visual tour: 3D Tiles, 3D city data, planetary basemaps, the SQL Workspace, and embeds.
• Downloads - installers and package managers for Windows, macOS, and Linux.
• User Guide - a feature-by-feature reference for the interface, adding data, layers, styling, the attribute table, map controls, processing, the SQL Workspace, data integrations, plugins, settings, and embedding.
• Tutorials - hands-on, end-to-end workflows: your first map, cloud-native data, vector analysis, terrain analysis, spatial SQL, and sharing and embedding.

Acknowledgements

GeoLibre is built on the free and open-source geospatial and web communities — including MapLibre GL JS, deck.gl, DuckDB-WASM Spatial, Turf.js, Tauri, React, and many more. See the full Acknowledgements page for the complete list of projects and community contributors.

• The Atmosphere Effects plugin (deep-space backdrop, parallax starfield, comets, and the globe atmosphere halo) adapts the technique and visual design from Leonel Dias's article Globe atmosphere, halo, and comets — the layered Canvas 2D approach, the halo gradient and "screen" blend, the limb-sampling that keeps the halo aligned under pitch, and the starfield/comet parameters.
• Community contributors — thanks to Ryanphoenix for many valued contributions, including issue reports, feedback, and improvements.
• Beta testers — thanks to René van der Velde (Netherlands) for early testing, detailed bug reports, and feature requests.

Citation

If you use GeoLibre in your work, please cite it. GeoLibre is archived on Zenodo, which mints a DOI for every release. The concept DOI below always resolves to the latest version.

Wu, Q. (2026). GeoLibre: A lightweight, cloud-native GIS platform for visualizing, exploring, and analyzing geospatial data. Zenodo. https://doi.org/10.5281/zenodo.20785400

License

MIT

Grafana Cloud now provides a unified Allowlist API with a structured, region-aware JSON format that replaces legacy per-product IP allowlists, requiring users to update and validate firewall automation before the legacy endpoints are retired on January 31.

Harness and Kong Expand Strategic Partnership

Harness and Kong announced an expansion of their strategic partnership to address the growing security challenges posed by AI-driven architectures, autonomous agents, and Model Context Protocol (MCP) deployments.

The two companies are extending their joint solution from Kong API Gateway to also include Kong AI Gateway, bringing Harness's AI security intelligence directly into the AI infrastructure layer and enabling enterprises to discover, monitor, and protect every agent, AI asset, LLM-powered service, and MCP-connected workflow that traverses it.

Harness and Kong have been jointly trusted by enterprises to deliver best-in-class API security for years. The existing Harness and Kong API Gateway integration provides:

• Comprehensive API traffic visibility and behavioral analysis across all Kong-managed services
• Real-time detection and blocking of API threats, including OWASP API Security Top 10 risks, credential stuffing attacks, and business logic abuse
• Continuous sensitive data tracking to identify PII exposure and regulatory risk
• Zero-friction deployment alongside existing Kong configurations

This new offering of the AI Gateway solution applies the same level of security depth to AI infrastructure, ensuring that security teams are not left behind as their organizations adopt AI and agentic operations.

"Our partnership with Harness has given joint customers production-grade API security that works with the way they build, not against it," said Ken Kim, Senior Vice President, Business Development at Kong Inc. "Extending to include Kong AI Gateway is a natural next step. The same enterprises are now moving AI into production through our gateway and need the same depth of visibility and control they've come to rely on for their APIs for all AI traffic types including LLM, MCP, and A2A. That's exactly what this delivers and is crucial for organizations scaling in the agentic era."

The new Harness and Kong AI Gateway integration directly tackles these challenges across two critical domains: AI discovery and AI protection.

• AI Discovery: Harness automatically inventories every AI asset, API, MCP server, tool, prompt, and resource routed through Kong AI Gateway — providing security teams with a continuously updated catalog of their AI attack surface. No manual documentation. No blind spots.
• AI Protection: Harness applies behavioral analysis and anomaly detection to AI traffic in real time, identifying prompt injection attacks, data exfiltration through AI responses, jailbreaking, malicious code in prompts, and other AI-specific threats. Enterprises gain the same depth of observability and protection for their agents and AI workloads that they already rely on for traditional APIs, with full prompt and response details available for incident investigation and inline policy enforcement through Kong AI Gateway.

"Shadow AI has become the defining security blind spot for enterprises today. Traditional tools were built for static code and predictable systems, not for adaptive AI models, agent-to-agent communication, and MCP-connected workflows that evolve continuously," said Rahul Sood, GM of Application Security at Harness. "This integration of Harness AI Security with Kong puts security intelligence directly into the connectivity layer where AI traffic flows. Joint customers now have the visibility and control they need to move fast without losing sight of what's happening across their AI infrastructure."

The Harness and Kong API Gateway integration is generally available now for all joint customers. The Kong AI Gateway integration, including AI Discovery and AI Protection, is also generally available now.

Full article content is not available for inline reading.

Read the original article →

I handed a UX review over to AI. Here’s what happened.

AI is a powerful partner for UX reviews, not a replacement for the expert, and the accuracy comes from the expertise you feed it, not the model.

I got a task that isn’t complicated in itself: I had to write a UX expert review for the search, results, and product detail pages of a portal. I had a set of questions about the target audience, the goals, and the USP, an industry research document, plus access to Google Analytics and Clarity.

My starting hypothesis (one you read more and more everywhere) was that AI is already more than good enough for this kind of thing. You barely have to work with it; the designer just has to look over the result, and on topics like this it basically replaces the human. Since a task like this happened to come along, I figured I’d check whether that’s really true.

The test

I worked with two models in parallel: Claude Fable 5 and ChatGPT-5.6 Sol, both on paid subscriptions, of course. I gave each of them everything I had as input: the brief, the questions and answers, the research material, the GA exports, the Clarity heatmaps, attention maps and scroll maps, plus the necessary URLs. The task was precisely defined: produce a UX expert review document, with a specific goal.

Importantly, I didn’t work with a single prompt. I broke the task down in a structured, multi-step way, and I asked the models to back up their findings with the GA and Clarity data where possible, rather than just assuming. In other words, I wasn’t testing the “throw everything into one prompt” approach, but what you can get out of a deliberate workflow.

And naturally, I also did the analysis by hand in parallel (like an animal), so I’d have something to compare against.

What I found

Let me say this up front. This is an experience report, not a controlled experiment. One project, one expert (myself), and my own analysis isn’t an absolute yardstick either. Read the following with that in mind.

Both models put together an analysis, but they were full of irrelevant, and even non-existent, problems. There were useful observations too, but even those I could only really use at the level of wording and structure. Claude was noticeably more accurate than ChatGPT, at least in phrasing and structure, though this is my subjective impression, not a controlled measurement. One difference was objective, namely that Claude could produce the result in a single document while ChatGPT only managed it in part, but that’s more a question of output format than of analytical quality.

I’ll admit it: there were problems I hadn’t spotted myself, and that was useful. But there were more that the AI, in turn, didn’t catch.

This actually lines up quite well with a 2025 study that tested GPT-4o against Nielsen’s usability heuristics:

“GPT-4o found roughly a fifth (21%) of the usability problems identified by the experts, while also raising several new, partly false problems. So it’s an excellent first-pass UX review tool, but on its own it doesn’t yet replace expert evaluation.”

On a project somewhat more complex than these Nielsen-style usability heuristics, I found essentially the same thing.

How the material finally came together

In the end I put the analysis together with Claude. I fed it my own observations, and in an ongoing conversation we shaped what to cut and what to add. It reviewed the text for grammar, consistency and similar aspects, and suggested changes. That part was incredibly useful.

I didn’t measure the time precisely, but by feel: if I’d done everything on my own, it would have taken roughly 15% longer overall.

So AI is a great companion and helping partner that lets me speed up and sharpen my work, but right now it can’t replace me. It’s still a strong partner, and together we’re better than ever.

You might ask whether a browser walk-through would have been better. These days there are ways and tools to have the models walk through the site live in a browser, rather than only working from static data and URLs. I can’t know for sure, since I didn’t run it, but I strongly suspect it wouldn’t have led to better results either, because the core limitation isn’t access, it’s judgment, meaning understanding the context and the goals, weighing severity, separating real problems from noise. A live walk-through changes little about that.

What I will actually try next is different. I’ll build my own agent skill for this task, one that encodes the established usability heuristics, the severity weighting shaped by professional experience, and the expert lens a UX practitioner brings to an interface, and then refine it project by project. The point isn’t for it to decide instead of me, but to turn my own expert judgment into a reusable, consistent form. That’s what I’ll look at next time.

This actually lines up with what you see in the research on the topic: Baymard’s 95%-accuracy AI heuristic evaluations weren’t achieved through better prompting, but by grounding the model in their own researched UX knowledge base. Granted, in their case this is narrowly about usability heuristics, which is a much simpler story than a complex, context-dependent review like this one, but the principle is the same. The accuracy doesn’t come from the model, it comes from the expert framework you feed into it. That’s exactly why it’s worth encoding your own standard into a skill.

And in the long run?

I’m well aware that sooner or later AI will replace our work, that’s essentially not in question. The only question is when it will happen.

I’ve read that there are signs of a kind of slowdown, a plateau. According to a late-2024 Reuters piece, several leading AI researchers, including Ilya Sutskever, say that simply scaling up model pretraining has reached its limits. Further progress increasingly comes from new approaches, such as “o1”-style models that reason step by step, rather than from sheer size. In other words, development hasn’t stopped, but the emphasis is shifting from size toward smarter methods.

Of course, all sorts of other developments and research are going on in the background, so there’s no question that AI will gain total ground in the long run.

I recently stumbled on a page suggesting we still have a few good years left, especially in research and complex design, where we use various AI models everywhere to speed up, sharpen and support the work.

So what should you do tomorrow?

Start: use AI as a first-pass partner, feed it your real data, work in steps, and codify your own heuristics and severity into a reusable prompt or skill.

Stop: shipping its output as-is, expecting one prompt to replace a workflow, and handing over your judgment. Severity, prioritization and business context stay with you.

And stop panicking that it will take your job tomorrow. It won’t, but the designers who learn to direct it will outpace the ones who don’t.

xAI launched Build Mode for SuperGrok Heavy subscribers, letting users generate, edit, preview, and publish websites, apps, games, and dashboards directly from chat. Projects require no setup and can be shared through grok.me links or custom domains.

camelAI recently moved its agent off of virtual machines and onto a Cloudflare Durable Object. Its file system lives in SQLite and R2, and it writes JavaScript instead of bash. The team moved off VMs because giving every user an always-on machine with attached disk was too expensive to scale. This post explains how the team completed the migration. camelAI's codebase recently went open source.

Amazon plans to shift from having a wide portfolio of models for text, images, video, and multimodal tasks toward having a single frontier model.

Apple is preparing a new push into the smart home category with a wave of home products. It will start with a hub device built around the new Siri AI assistant. Apple is also preparing to release a new TV set-top box and a refreshed HomePod mini. All three devices are nearly ready to launch. Apple is also working on a higher-end, robotic version of the home hub and an advanced in-home security camera.

Today, we’re launching Tau’s humanoid cleaning service in San Francisco at $30 per hour.

Access is initially invite-only as we scale operations. If you don’t have an invite yet, join the waitlist at tau-robotics.com.

All footage is shown at 1× speed. Each humanoid is jointly controlled by a human operator and AI.

Early results from my AI training runs. I've trained my $200 robot arm on a simple picking task using imitation learning. It has learned to control the robot arm using only camera images and joint states.

The learning algorithm is based on ACT from @tonyzzhao. However, it is modified to use language instructions to learn multiple tasks with a single neural network. The video shows a policy that was trained on two instructions. One instruction to pick up the block and one to put it down. The entire training dataset contains about 400s of teleoperated trajectories.

Anthropic has drawn criticism after releasing tools on the market that compete with those offered by partner companies. For example, Claude Design directly competes with offerings from partner design company Figma. Anthropic's data retention policies have also been criticized, but the company has pledged it won't use conversation data from Fable and Mythos - but not other models - to train new models. Researchers are calling for more transparency in AI systems.

Kalshi and Polymarket now offer wagers on whether the FDA will approve medicines and whether drug trials will succeed.

Harnesses influence cost, quality, and accuracy, and have more impact on performance than the models.

What even are microservices?

It's almost impossible to have a conversation about software architecture without someone bringing up microservices. They have become the default example of both "good architecture" and "over-engineering," depending on who you ask.

What's interesting is that everyone seems to recognize a microservice when they see one, yet almost nobody can explain what actually makes something a microservice.

The impossible definition

How small is micro? Should a service do exactly one thing? Two? Is there a maximum number of lines of code? A thousand? Ten thousand? Nobody has convincing answers, because there aren't any.

The industry has spent years trying to define microservices by technical characteristics, but those characteristics are surprisingly vague and fuzzy. The boundaries aren't measured in responsibilities or number of deployments per day. They're measured somewhere else entirely.

And that's the important realization: microservices aren't primarily a technical abstraction.

The problem they're actually solving

Listen to the reasons people usually give for moving away from a monolith: deployments are slow, tests take too long, builds are painful. These are real problems, but none of them require microservices. Every single one can be improved while staying inside a monolith.

So why do organizations migrate anyway?

Because the bottleneck usually isn't technical. It's organizational.

As companies grow, dozens or hundreds of engineers need to work independently. Teams need ownership. They need to release on their own schedules without constantly coordinating with everyone else. Microservices create boundaries that mirror organizational boundaries. That's their real value.

Every benefit comes with a bill

Engineering is the art of managing trade-offs. Microservices are no exception.

You gain autonomy, but you lose centralization. Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain.

The same pattern repeats everywhere. Communication between functions becomes communication over the network. A method call becomes an HTTP request. A compiler error becomes a runtime failure. Every distributed system problem — latency, retries, partial failures, serialization, consistency — suddenly becomes part of your application.

None of these costs are surprising. They're simply the price you pay for the flexibility that distributed systems provide.

The hidden communication cost

When people talk about communication overhead, they usually think about APIs talking to each other. That's only half the story.

The teams now have to communicate too.

Changing an API is no longer a refactor. It's a negotiation. Consumers need advance notice. Versioning becomes necessary. Old versions have to remain alive while everyone migrates. Database changes become coordinated efforts instead of straightforward commits.

The software isn't the only thing that's distributed anymore. The decision making is as well.

Choose them for the right reason

None of this is an argument against microservices. They're an excellent architectural choice in the right environment. Many successful companies simply couldn't operate without them.

But it's worth being honest about why they work.

If your primary problem is organizational scaling, microservices might be exactly the right answer. If your problem is purely technical, you should first ask whether you're reaching for a solution that's far larger than the problem itself.

Architectures become much easier to reason about once we stop pretending microservices are magic technical tools. They're organizational tools with technical consequences.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Artist Elmer Saflor, who goes by the online handle “Superelmer,” loves that millions of people have shared his “Running Away Balloon” comic since it became a popular meme in 2017.

However, just because lots of people have copied it, that doesn’t mean it’s OK for an AI meme generator to commercialize his copyrighted meme as a template for who knows how many ads, he told Ars. That’s why he’s fighting to stop one of the biggest meme generators currently leveraging AI to rapidly scale the allegedly illegal use.

In a lawsuit filed earlier this month, Saflor, a digital creator and artist in the Philippines, alleged that Memes Apps, LCC—which operates the content creation platforms Memes.ai and Memes AI Studio—violated copyright law by selling paid subscriptions to an ad generator that spits out copies of his comic without permission.

Saflor told Ars that he did not contact Memes Apps ahead of filing his suit, and he has not seen any examples of his meme used in ads generated by the platforms. However, he filed the lawsuit to compel discovery, while raising “broader questions about how AI-powered platforms use creators’ work, what licensing obligations they may have, and how copyright law applies when viral Internet culture becomes a commercial product,” he told Ars.

Entire meme ecosystem may be impacted

It’s unclear what defense Memes App may raise, but Internet law expert Eric Goldman told Ars that there’s precedent to support Saflor’s arguments that his rights have been infringed.

In a 2024 case involving the “SuccessKid” meme, a court ruled that the particular meme could not be used in a campaign ad without permission. At the time, Goldman blogged that the ruling implied that “meme usage for noncommercial purposes is likely fair use, while meme usage in ads isn’t.”

Goldman told Ars that Saflor has started his case off “on the right foot,” telling “the right story for the judge” in the complaint.

However, it’s gutsy to go after the meme generator, rather than advertisers allegedly infringing, and that strategy could create “a whole host of other legal dilemmas” for the court to weigh, Goldman told Ars.

By taking on the meme generator, Saflor may hit a wall if the court finds that his arguments apply to any meme generator and a finding in his favor could risk undercutting the entire meme ecosystem, Goldman said.

“In those circumstances, there’s some good reasons for the court to check more cautiously,” Goldman suggested, perhaps making a win harder for Saflor.

However, “the packaged deal” that Memes Apps is trying to sell to third-party advertisers—offering access to template memes for subscription tiers set at $40 or $199 monthly—could doom the meme generator’s defense. Unless, Goldman suggested, Memes Apps can prove that the deal is a common model in the meme generator industry.

Another hurdle for Saflor could be proving harm, particularly if it turns out that no advertisers used his comic to produce ads.

Ars could not immediately reach Memes Apps for comment and could not confirm if Saflor’s meme template was widely used by its subscribers or ever used in an ad.

Although Goldman wondered who the consumer is that’s relying on bulk AI outputs from meme generators to make ads, Saflor’s complaint cited Memes Apps’ public portfolio to suggest the service is quite popular. Seemingly, the platform works with more than 40 brands that generate up to 1,000 ads monthly to more than 75 million social media followers. Saflor’s alleged that he’s likely already suffered “substantial economic damage” from the unfair use of his meme.

Saflor is hoping the court will order Memes Apps to stop using his comic as a template. He always wants a complete account of the number of ads using his comic in order to reclaim all ill-gotten profits.

Goldman suggested that in a win, the payout may be challenging to calculate since the subscriptions make it hard to assess what value a given meme had to the platform. But Saflor told Ars that like the comic that he made that widely resonated across the Internet, the fight to defend his rights as a creator is personal. “There’s a big difference between Internet users making memes for fun and a company monetizing my copyrighted work as part of a commercial product.”

AI meme generators set “dangerous precedent”

The “Running Away Balloon” comic came from a “deeply personal place,” Saflor told Ars.

The two-panel comic shows a man chasing a yellow balloon labeled “opportunities,” then endearingly introduces a pink blob character labeled “shyness” in the second frame, which smiles politely while inconveniently holding back the running man from grasping the “opportunities.”

Many people have stolen the template for a meme, with the simple comic spreading on social media.

People invoking the meme often rely on the characters to express their frustrations with their own limitations. Popular examples documented on Know Your Meme include captions joking about how “my face my luck my empty pockets” can keep someone from attracting “pretty girls.” Or how “other project ideas” can get in the way of finishing a “current project”

“I never imagined that such a simple comic would resonate with millions of people or become part of Internet culture. Seeing people remix it, reinterpret it, and use it to express their own ideas is part of what made the comic so special,” Saflor said, and he “never tried to stop people from sharing it or creating memes with it.

“Just because something becomes a meme,” he said, “[that] doesn’t mean the creator loses their rights.”

“Many of the Internet’s most recognizable memes began as someone’s original artwork, photograph, or creative expression,” Saflor said. He thinks that allowing companies to “commercially exploit those works without permission simply because they’ve become popular online” sets a “dangerous precedent,” especially as more AI products seek to exploit copyrighted works at potentially unprecedented scale.

Goldman told Ars that although the copyright meme case is niche, the significance of a win for Saflor could resonate beyond the meme ecosystem and inform some of the biggest AI copyright fights.

It matters that the meme generator’s outputs include actual copies of Saflor’s original work, Goldman said. In some of the most high-stakes AI copyright fights, a “big contention” among model makers that’s key to their defense is that original works are not included in outputs, Goldman pointed out.

“And we’ve seen where the copyright owners are able to replicate identical outputs, that actually makes the cases much higher stakes for the defendants,” Goldman said. “And so at best, this case could possibly have an impact for those cases where the copyright owner has got the smoking guns of original index material coming out identically.”

However, “I don’t even think it’s likely to do that,” Goldman said, since “meme generators are just such a niche because of the fact that they’re memes,” which inherently only work when they’re copied without permission.

“If someone creates a visual image and tells the world, ‘Please make this into a meme,’ that would never work,” Goldman said. “Memes that grow organically from the multiple individual decisions to copy it without permission, so copyright law and meme law don’t really play together very nicely.”

Saflor thinks that AI’s rise in popularity is the perfect time to change that and “recognize that behind every iconic meme is a real creator,” Saflor told Ars. “Respecting copyright encourages creativity and ensures artists aren’t left behind as technology evolves.”

Saflor uses AI tools and does not believe that AI itself is the problem. Goldman pointed out that his arguments against Memes Apps would be largely the same even without the AI aspect. But Saflor considers Memes Apps’ platforms to be examples of irresponsible AI products, where the operators problematically advertise that you can “fire your ad agency” and replace all creative work with a meme generator.

“My goal is simply to protect creators when their work is allegedly commercialized without permission,” Saflor told Ars. “I hope this case helps start a broader conversation about respecting artists’ rights as AI-powered platforms become a bigger part of Internet culture.”

George Clooney, Tom Hanks, and Meryl Streep back new ‘Human Consent Standard’ for AI licensing

This new standard will allow people to set terms for how AI systems can use their likenesses and creative works.

Hollywood actors and producers are standing behind a new AI licensing standard that will tell AI systems whether they’ll need to pay to use a person’s likeness, creative work, characters, and designs. With the Human Consent Standard, people can set terms for the use of their work or likeness, including giving AI systems full permission to use their content, allowing access with certain requirements, or restricting access entirely.

The Human Consent Standard builds upon the Really Simple Licensing (RSL) Standard, which launched last year as a way for websites to signal how AI systems use their work. RSL Media, a nonprofit cofounded by Cate Blanchett, is overseeing the Human Licensing Standard. The newly launched standard is backed by talent such as George Clooney, Viola Davis, Tom Hanks, Kristen Stewart, Steven Soderbergh, and Meryl Streep, along with organizations like the Creative Artists Agency and Music Artists Coalition.

In an email to The Verge, RSL Media cofounder Eckart Walther says that, similar to the RSL Standard, AI systems can discover the Human Consent Standard through a website’s robots.txt page, which tells web and AI crawlers whether they can scrape its content. But Walther says that while the “RSL usually applies to content at a specific URL,” the Human Consent Standard “applies to the underlying work, identity, character, or mark itself, wherever it appears.”

AI systems will check this declaration against a registry launching in June, which will allow people to verify their identity and set permissions for the usage of their likeness and creative works. From there, RSL Media will “translate” these terms into signals that AI systems can read. “The purpose of the Registry is to give people and rights holders a trusted place to publish those declarations, so responsible AI systems can check whether a work, likeness, voice, character, or brand is allowed, prohibited, or requires permission,” Walther says.

Some artists and actors have already taken steps to combat the unauthorized use of their likenesses. Matthew McConaughey trademarked clips of himself, while Taylor Swift applied for a trademark of a photo of herself and two soundbites, where she says, “Hey, it’s Taylor” and “Hey, it’s Taylor Swift.”

With the launch of RSL Media, everyone can attempt to set permissions for their work. “RSL Media is a simple, effective and free solutions-based technology for facilitating and activating consent,” Blanchett says in the press release. “It’s also the industry’s first practical solution where people everywhere, not just public figures, can assert control over how their work is used by AI.”

A Concrete Definition of “Product Sense” (and How to Build It)

Product sense means predicting which product decisions will succeed based on patterns learned through experimentation — and knowing when those patterns apply.

AI can now handle many tasks that once made product builders valuable.

As a result, designers and engineers are under growing pressure to decide what to build, not just how to build it. This shift has fueled the rise of the term “product sense,” but the concept is often loosely defined, creating confusion more than clarity.

The Problems with Existing Product-Sense Definitions and Advice

The most widely cited definition of product sense comes from Jules Walter in Lenny's Newsletter from 2022:

“Product sense is the skill of consistently being able to craft products (or make changes to existing products) that have the intended impact on their users. Product sense relies on (1) empathy to discover meaningful user needs and (2) creativity to come up with solutions that effectively address those needs.”

Unfortunately, Jules Walter’s definition leaves something out. Empathy and creativity are essential, but how do you recognize, measure, and develop these qualities?

Walter and many others, such as Jackie Bavaro, Julie Zhuo, and Marty Cagan, have tried to provide advice for building product sense; most of it revolves around simply consuming product-related inputs, such as:

• Deconstructing the products you use and doing product teardowns
• Documenting a product's goals
• Making crossdomain analogies ("Uber for ___")
• Doing structured product critiques
• Learning from people with strong product sense by studying their reasoning
• Doing competitive and market analysis
• Staying curious about tech/world change and learning the industry and enabling technologies
• Observing real people using products
• Inquiring as to the “why” behind behavior and feedback
• Reading lots of product reviews
• Studying your product's data and analytics
• Learning from others' successes and failures

This guidance is useful, but it suggests that collecting scattered inputs will somehow produce reliable intuition to guide product decisions. I argue that gathering these inputs is not sufficient for developing product sense.

What Real Product Sense Is Built On

I propose the following definition of product sense:

Product sense is the ability to recognize when current problems match past successes or failures and reliably estimate how similar solutions will affect the desired outcomes.

This view of product sense requires domain experts to build their own personal repertoire of past experiences to draw upon. It’s not enough to simply expose yourself to a collection of scattered inputs from various sources. Building real product sense requires people to close the full experimentation loop:

1. Face problems
2. Choose solutions
3. Measure the outcomes
4. Reflect on the results

Experts in many domains develop intuition that helps them make consistently good decisions in fast-paced, low-information environments. This process has been well documented and typically involves:

1. Understanding the current problem
2. Retrieving similar past experiences from memory to identify a plausible solution
3. Evaluating whether that solution would solve the current problem
4. Modifying the solution as needed, or searching for a different option

For example, fire chiefs responding to burning buildings, NICU nurses caring for vulnerable infants, and chess grandmasters evaluating possible moves all draw on rich repertoires of past experiences built by completing the full loop described above.

This definition improves on Walter’s because it turns product sense from a loose combination of empathy and creativity into a measurable decision-making skill. It specifies the mechanism behind strong product judgment: recognizing when a current problem resembles past successes or failures, predicting likely outcomes, and knowing when those comparisons are reliable. That makes product sense easier to recognize, practice, and improve.

Product Sense Also Means Knowing When Patterns Don’t Apply

So, if you gain experience making decisions and following through to see the results, do you have strong product sense?

Our definition requires people with strong product sense to know both when an experience-based pattern is likely to work and when it is not. That judgment is the “sense.” It is not magical, does not come automatically with time, and remains limited to a person’s domain of expertise.

Consider a fire chief experienced with small building fires advising a crew during a skyscraper fire, a NICU nurse caring for an adult patient, or a chess grandmaster playing checkers. Do the cues they learned in one domain still apply?

Daniel Kahneman and Gary Klein point out that any new decision-making environment needs to provide sufficient familiar clues for an expert to accurately match the patterns they’ve learned to the current situation. There are roughly three categories of problems:

1. High-Validity Situations

These mirror the environment in which the patterns were learned. They look very familiar and make accurate pattern matching easy. High-validity situations are easy for product experts (i.e., individuals with product sense) to assess.

For example, a designer who has successfully improved several checkout flows may be able to diagnose and fix a similar checkout problem without extensive new research or ideation, assuming the users’ priorities and sensitivities are comparable.

2. Low-Validity Situations

These situations differ significantly from the environments where the patterns were learned, or they lack clear cues and feedback about the action’s outcome. Past experience may still help, but there is no guarantee that the first approaches that come to mind will work.

For example, a designer working on a zero-to-one product with a long feedback loop has little precedent to rely on, even with extensive design experience. In that context, trusting product sense alone is risky; it is better to challenge assumptions and gather more evidence.

3. Wicked Situations

Coined by Robin Hogarth in 2001, the term “wicked situation” refers to problems that do match previous situations, but whose solutions are not fit for the current problem. Unlike low-validity situations, where thin cues at least leave you appropriately uncertain, wicked situations feel just like high-validity ones. This is the most dangerous category because experience here reinforces the wrong pattern while simultaneously inflating confidence.

For example, a product team builds a feature that closely resembles a successful feature from another one of their products. Assuming the same approach will work, the team does little research or testing before launch. But because the new audience has different needs, the feature underperforms. What looked like a clear pattern match turned out to be misleading.

In other words, those with strong product sense can recognize when relying on intuition is unwise. They do not assume that experience gathered in one context automatically applies in another — a fundamental danger in much of the existing product-sense advice.

How Do I Develop Strong Product Sense?

The next obvious question is: how do you develop both strong decision-making patterns and the judgment to know when to rely on them?

The most important thing you can do is participate in entire product-development cycles:

1. Assess the initial situation (whether it's a bug fix, user pain point, feature request, or stakeholder mandate)
2. Develop the best solution you can
3. Implement the solution
4. Measure the outcomes of your work
5. Reflect on how successful your efforts were

The more pieces of this fundamental product-building cycle are missing, the weaker your future product sense will be. You will be like the firefighter who regularly took the first half of the shift where initial calls were made, but never stuck around to see whether the building collapsed. That firefighter might feel very experienced based on the hours they’ve invested, but they are completely unqualified to serve as a fire chief because they don’t know the results of their work.

Too many product builders today work this way: they receive requests, create solutions, and move on without closely tracking the results. Often, they rely on intuition because little research is available. Or, they spend their time fixing bugs and handling complaints about products they did not help design or build. AI is accelerating this pattern.

These builders are valiant in their efforts, but they are not developing a robust product sense. They are getting only half of what they need. To build strong intuition, apply the following suggestions in your workflow wherever possible:

• Stay long enough to see the results of your work. Before changing departments, projects, or jobs, ask yourself: Is there still something valuable to learn by finishing what I started?
• Document your decision-making logic before looking at results. Be specific about your hypotheses. What quantitative or qualitative outcomes do you expect to see from your choice?
• Measure real outcomes, don’t just judge your success based on the outputs you’ve created, and hurriedly move on to what’s next.
• Reflect:
  • How well did your decisions hold up?
  • What didn’t go so well?
  • Why do you think the results shook out that way?
  • What could you have done differently?
  • Which past experiences is this situation most similar to?

Conclusion

Buzzwords come and go. There’s nothing wrong with the term “product sense.” The problem is believing that, with little data, an ever increasing velocity, and more work and decision making outsourced to AI, people can develop a “sense” for what to do without rigorous thinking.

Intuition comes with time and repeated exposure to real product decisions and results. AI may rob you of the chance to develop product sense if you aren’t careful. Stay in the ring, own your decisions, and face the results. This is what will make you valuable for years to come.

References

[1] Robin M. Hogarth. 2001. Educating Intuition. University of Chicago Press, Chicago, IL.

[2] Daniel Kahneman and Gary Klein. 2009. Conditions for intuitive expertise: A failure to disagree. American Psychologist 64, 6 (2009), 515–526.

[3] Gary A. Klein, Roberta Calderwood, and Anne Clinton-Cirocco. 1986. Rapid decision making on the fire ground. In Proceedings of the Human Factors Society Annual Meeting, Vol. 30. SAGE Publications, Los Angeles, CA, 576–580.

45 interactive field cards covering nudges, biases, heuristics, and AI phenomena. A practical reference for designers, researchers, and product teams building with AI.

Chances are you might never have heard of the new Disney series Ozzy Fox if it weren't for one thing: some kind of AI-related technology was used somewhere in the process of making it. That's prompted an outcry that's won the animation far more visibility than it would have received otherwise.

Suddenly a cartoon for preschoolers that was launched on YouTube with little fanfare is generating headlines about Disney feeding kids AI slop. People have been quick to spot the hallmarks of AI video generators, from incomplete props to bad lip synching and a suspicious lack of any text or numbers in backgrounds. It's put Ozzy Fox up among the most controversial cartoons, helping it rack up thousands more views.

The irony is that it isn't really generative AI.

Ozzy Fox is about a family of anthropomorphic foxes who dance around to songs about tidying up and going to the toilet. Zootopia 3 it is not, but then it is intended for preschool kids.

The animation is a joint production with French animation company Animaj as the result of the 2024 edition of Disney Accelerator, a business development programme for startups that's been running since 2014.

It was created by Jennifer Oxley, who's previously worked on Peg + Cat, Wonder Pets!, and Little Bill, and developed by Animaj creative director Guillermo García Carsí. Chen Neeman, Kat Rende and JP Rende wrote those catchy songs about chores and using the potty.

AI does form part of Animaj's development process, something that Disney made sure to point out to investors in its press release back in 2024. But Ozzy Fox is not a text-to-video or even image-to-video AI-generated cartoon like Showrunner, or Google DeepMind's Dear Upstairs Neighbor, or Amazon's proposed AI KPop Demon Hunters mockbuster.

Animaj's workflow uses two proprietary AI tools trained on the show’s assets: sketch-to-pose prediction and motion in-betweening. The 3D models that appear in the cartoon are created by artists, and human animators draw the storyboards and sketch key poses.

The first AI system poses the corresponding 3D model based on a sketch, kind of like mocap but for 2D to 3D animation instead of live action to 3D animation. The second model then handles the repetitive task of filling the in-between frames, something many 3D animation pipelines have done for years. Artists then review and manually correct the files in Maya, one of the best animation programs.

Ozzy is AI-assisted, not AI-generated. Whether people think it's any good is another matter, but any stiffness or weird-looking sequences are the result of either the intended art style or human error rather than AI hallucinations. Animaj's Pocoyo, which has a comparable style, has been running since 2005.

I'm not sure why one of the character's clothes seems to change colour in the middle of a scene, but I guess it's a lighting issue.

Much has been made of the fact that Disney published no official press release about Ozzy Fox's launch. The suggestion is that the studio hoped the show would slip under the radar, but I don't remember the company shouting about productions from previous Disney Accelerator cohorts either. Who remembers the "community-driven animated NFT series" The Gimmicks House of Chico?

Each of the two Ozzy Fox episodes released so far already has over 500,000 views. The flipside of the criticism of the perceived use of AI is that if the series really takes off, people will take it as proof that the public is perfectly happy to accept AI cartoons, when that's not what it would be showing.

It's no secret that Disney has been exploring the use of generative AI for animation. It had a massive deal with OpenAI that collapsed when the company behind ChatGPT flip-flopped away from its Sora AI video platform as abruptly as it launched it. If everything gets called out as AI slop when it's not, it could normalise the real slop when it comes.

AI should not be considered safe. The danger is that there are just a few CEOs around the world, without the required background and legitimacy, making hard choices for humanity at large. They weren't selected to do so, it was just chance that created this setup. They have GPUs and money, but given the stakes, they shouldn't be speaking for everybody.

As AI continues to improve, the question isn't whether superintelligence will exist, but who will have access to it. The technology could be centralized and restricted to a few institutions, or it could be used to empower everyone. The notion that AI is such a threat that the only safe path is an extreme concentration of power seems dangerous. Historically, hoping that an absolute power will benevolently provide for humanity if sufficiently enlightened hasn't led to safe or positive outcomes.

Widely distributed personal superintelligence could shift AI from automation toward invention, entrepreneurship, and individual agency. Concentrating advanced intelligence in a few institutions risks economic and political imbalance, while broad access, open systems, and targeted safeguards create stronger checks and balances.

As AI continues to improve, the question isn't whether superintelligence will exist, but who will have access to it. The technology could be centralized and restricted to a few institutions, or it could be used to empower everyone. The notion that AI is such a threat that the only safe path is an extreme concentration of power seems dangerous. Historically, hoping that an absolute power will benevolently provide for humanity if sufficiently enlightened hasn't led to safe or positive outcomes.

Apple Upgrade offers 12- and 24-month leasing options for the iPhone and Apple Watch, and 24- and 36-month terms for Mac and iPad.

The Cloud Native Computing Foundation has announced the schedule for Observability Summit Europe 2026, taking place in Prague on October 5. The event features more than 25 technical sessions covering topics including automated synthetic monitoring, Observability as Code, and AI-powered workflows. General registration is open now at 150 euros, with academic tickets at 85 euros. Applications for the Dan Kohn scholarship, which provides complimentary registration for community members from underrepresented groups, are open through August 23.

Meta is moving Meta AI into Threads DMs after feedback showed that many users were uncomfortable interacting with AI publicly in their feeds. Users can privately ask questions about posts, conversations, and other topics, with options to delete chats or mute the AI account. Meta is still testing public Meta AI interactions in the Threads feed in a limited number of countries while it gathers more feedback.

Voqusa is a free AI transcript tool that converts videos from TikTok, YouTube, Instagram, Facebook, Twitter/X, LinkedIn, and Pinterest into text.

A free library of animated website components, ready to copy as code into a project or drop straight into Framer.

Interactive retail spaces that feel spontaneous, like the Coach Charm Playground at Selfridges, actually require immense hidden planning and discipline to execute safely and smoothly, according to Studio XAG. The project involved navigating regulations, testing over 150 sample sets, and executing overnight installs with precision compared to a Formula One pit stop. Key lessons highlighted include protecting the core idea through production, learning from workshop fabricators, and prioritizing real human behavior over portfolio aesthetics.

LinkedIn's "Open to Work" badge, active for six years, resurfaced as a debate topic after an engineer's viral X post called it a negative signal to recruiters.