How Claude is uplifting biomolecular modeling

In this post, we share how Claude made the open-source models that scientists use to predict and design biomolecules faster and more memory-efficient. Claude, working within Claude Science, optimized more than 30 of these models in just under four weeks, speeding them up roughly 4x on average. It also created a low-memory mode that enables the accurate prediction of biomolecular systems larger than 10,000 tokens (amino acids, nucleotides, and atoms from small molecules and ions) on a single NVIDIA GPU node. We are open-sourcing all of the optimized code and announcing a protein design competition co-sponsored with Adaptyv Bio, backed by up to $1 million in Claude credits and wet lab validation for over 5,000 designs.

Recently, we shared results demonstrating Claude’s abilities to design de novo protein binders through expert-level orchestration of open-source protein design and structure prediction models. De novo binders are small, computationally designed proteins that attach tightly to a specific target molecule to activate, block, or deliver something to it.

Although this was an encouraging demonstration of AI’s scientific capabilities and an early step towards advancing drug discovery, it took more resources than would be available to the vast majority of protein designers. We allowed Claude to spend up to $10,000 per target on the AI infrastructure platform Modal, roughly equivalent to 2,500 NVIDIA H100 GPU hours.

To make such research more accessible, we began to explore inference optimizations to run these models more efficiently. As an early result of these optimizations, Claude Mythos 5.1 accelerated seven open-source biology models, enabling them to run up to 2.5 times faster.

Here, we present new results showing how an internal, general-purpose research model was able to optimize more than 30 deep learning models trained for a variety of biological tasks, such as structure prediction and protein design, as well as for genomics and protein language models. On average, Claude was able to speed up such tasks roughly 4x while sacrificing a minimal amount of precision, and nearly 2x with identical outputs. Claude also improved the memory utilization of these models, making it possible to predict biomolecular systems of unprecedented sizes. By combining these results with simplifications to our previous agentic protein design approach, we show that Claude can achieve comparable in silico performance to the results we previously reported using two orders of magnitude fewer GPU hours.

Beyond protein design, these specialized biological models are widely used by molecular biologists, including for drug discovery and development. We are open-sourcing the optimized code for all of these models today so that the broader community can make use of them. You can find more detail in our technical report.

Accelerating protein structure prediction and design models

Protein structure prediction is the problem of determining the three-dimensional structure of a protein from its sequence of amino acids alone. Protein design, meanwhile, is the process of creating a protein with a specific structure, function, or set of properties. Together, these computational tools allow scientists to interrogate key biomolecular processes, such as how cancers form, and to create useful molecules, such as drugs that could target these cancers.

Modern structure prediction models, such as AlphaFold3, OpenFold3, and Boltz-2, spend much of their computational runtime and memory on two operations: triangle attention and triangle multiplication, which act on triplets of tokens. These operations make it possible to model the geometry of biomolecular systems, but they are extremely computationally expensive, because they are cubic in both runtime and memory: doubling the size of the system uses 8x more time and memory, while tripling it uses 27x more.

Writing kernels—low-level software translation layers for accelerated computing hardware such as GPUs—is a standard approach for reducing these costs. Given their significance, triangle attention and multiplication have been the subject of dedicated kernel development efforts, first with NVIDIA’s cuEquivariance and more recently with NVIDIA’s BioNeMo Inference Runtime (BioNeMo-IR).

For our own effort to optimize inference for structure prediction models, we worked with Claude to develop FlashPairformer, a set of custom kernels that speed up triangle attention and multiplication. It achieves a new state-of-the-art, outperforming the field standard on average by 2.7-2.9x on triangle attention and 1.7-3.2x on triangle multiplication, depending on the model configuration.

In addition to developing transferable kernels, we pointed Claude at each individual model with the goal of producing more specific optimizations. These included changes like caching redundant recomputed work and simplifying dead branches into their constant outputs. The combination of these improvements accelerated the structure prediction models by 4x, on average, and for each model, we confirmed that Claude’s accelerated versions did not impact performance on the downstream task (such as structure prediction).

It normally takes an experienced team of engineers weeks to produce such optimizations for each model, and the work often does not transfer between models. Claude, supervised by two members of Anthropic’s technical staff who are experienced in biomolecular modeling but who had no prior experience in inference optimization or kernel engineering, carried out the acceleration of more than 30 open-source models across biomolecular structure prediction, protein design, protein language modeling, and genomics in just under four weeks. Our results suggest that frontier AI models will help others in the field build scientific tools with greater speed and ease.

Enabling modeling of massive biomolecular systems

In addition to making these protein structure prediction and design models faster, we also tasked Claude with reducing the memory usage involved in modeling large molecular machines. Much of the work in a cell is done by such systems, including the ribosome that builds proteins, the respiratory complexes that power the cell, and the chaperones that help other proteins fold. Each is built from dozens of components, and its function depends on how those components fit together and interact. Predicting the structures of systems this large has typically required substantial computing resources inaccessible to most molecular biologists, such as inference spread across multiple GPU nodes.

Claude created a low-memory “Big” mode that enables the accurate modeling of systems larger than 10,000 tokens and successful inference on systems larger than 70,000 tokens using just one NVIDIA GPU node—a previously out-of-reach task. Molecular machines folded successfully using Big mode include human mitochondrial complex I, the TRiC chaperone complex, a proteasome, and a bacterial ribosome, each closely matching its experimentally determined structure. To our knowledge, these are among the largest structures ever folded accurately using structure prediction models, with complex I and the 70S ribosome consisting of more than 10,000 tokens each, in comparison to the 40S ribosome predicted accurately by AlphaFold3, which consisted of 7,663 tokens.

To test the limits of Claude’s optimizations, we asked Claude to predict structures of a greater size than anything that had previously been achieved. Using a single 8-GPU B300 node, Claude generated predictions of entire viral capsids and protein compartments ranging in size from more than 31,000 to more than 70,000 tokens. These systems are nearly two orders of magnitude larger than the training context of these structure prediction models, and, perhaps unsurprisingly, are not predicted correctly. However, the barrier to inferencing at this scale has been significantly lowered now that it takes just one NVIDIA B300 node, suggesting that with improved tools researchers will soon be able to computationally model an increasingly complex set of biological systems.

Claude efficiently designs de novo protein binders

In our earlier work on protein design, we provided Claude with an approximately 16,000-word prompt that encouraged it to utilize sub-agents and spend up to $10,000 per target on Modal (roughly 2,500 NVIDIA H100 GPU hours) in a 24-hour span. Here, we gave a single Claude model access to one NVIDIA H200 and 24 hours of wall time, a prompt of about 1,100 words, and a reference sheet for the pre-installed tools, with no sub-agents and no human steering the designs.

We ran three Claude models (Mythos 5.1, Mythos 5, and Opus 5) against 16 targets with the accelerated biomolecular models described in this post. We scored designs by ipSAE, an in silico score that has been shown to be predictive of binding in the wet lab. Averaged over 16 targets, the median-scoring and highest-scoring designs from all three Claude models evaluated achieve approximately the same ipSAE values as our earlier Mythos 5.1 campaigns despite using about two orders of magnitude fewer GPU hours. We also considered Claude token costs and found that with a combined spend of approximately $150 on GPUs and tokens, we can achieve in silico performance matching the levels of our previous campaigns.

Co-sponsoring a protein design competition with Adaptyv Bio

The optimizations described above help us predict and design molecules more efficiently, while unlocking capabilities that would have otherwise been resource-prohibitive. To demonstrate the uplift they provide and the impact of Claude on molecule design more broadly, we’re partnering with Adaptyv Bio to launch a protein design competition. We’ve selected five problems at the frontier of today’s protein design capabilities, including challenges such as species cross-reactivity, pH-sensitivity, and peptide-MHC specificity, as well as difficult targets such as GPCRs.

With the Adaptyv team, we’ll be experimentally validating over 5,000 designs submitted by the community against these problems. We will be providing up to $1 million in Claude credits and additional funds for experimental validation at Adaptyv for participating researchers, Modal will provide up to $250,000 in compute credits, and Twist Bioscience will provide DNA for the competition.

We have also begun to provide frontier AI capabilities to life scientists for biology-related work via our Life Sciences Verification Program. We recently enrolled our first group of organizations, and opened up the program in public beta today.

Further reading

• Protein design competition page and application form;
• Code for specialized molecular models;
• Technical report.

Models know when they’re reward hacking — and we can catch them at scale

We found a clear internal signal in models that accompanies reward hacking, and built probes that detect it — enabling efficient, real-time detection of reward hacking at scale.

In July, a collective of hundreds of OpenAI agents autonomously hacked Hugging Face. Unlike most hackers, they were not after money, blackmail, or intellectual property. Instead, they were doing reconnaissance to figure out how to get away with cheating on an evaluation.

This was an unusually stark example of reward hacking, a growing problem with agentic AI models.

AI agents are like amoral students with a mostly-absent teacher. In order to train models, we give them rewards when they successfully complete a task. But like students cheating on a test, they sometimes find shortcuts that satisfy the reward without doing what we actually wanted—stealing the answer key, exploiting bugs, manipulating graders, or otherwise gaming the task. This behavior gets rewarded, and so the models learn to cheat. It may even push models towards a “cheater” persona and cause broader misbehavior beyond just reward hacking!

Reward hacking is already a serious problem. While the Hugging Face hack was a particularly flagrant example, reward hacking is widespread and not limited to any one model or company. It’s also a problem that does not seem to be getting any better—in fact it may be worsening as models become more capable—and so solutions and mitigations are urgently needed.

Our new research provides an important step towards a solution. In summary, we found that:

• Reward hacking is pervasive in open-source models.
• Models “know” when they’re reward hacking: we see a clear signal inside the model, associated with concepts like cheating, gaming a metric, and avoiding detection.
• We can detect that signal quite effectively using activation probes.
• The probes catch instances of reward hacking that LLM chain-of-thought monitors miss and generalize well beyond the data they were trained on.
• These probes enable real-time, scalable monitoring for reward hacking – and ways to mitigate it.

The ability to monitor for reward hacking unlocks several mitigation strategies: e.g. pausing runs to stop hacks-in-progress and identifying broken environments and impossible tasks that incentivize reward hacking, and fixing them before training further. We’re actively researching how these interventions could help us reduce reward hacking, and prevent models from learning this behavior in the first place. We’re optimistic that every training run can be monitored for reward hacking, and that the current rampant rates of reward hacking may soon be a thing of the past.

Reward hacking is pervasive in open-source models

Models reward-hack all the time, not just when they’re hacking companies. Across three of the most capable open-source models—Kimi K3, GLM 5.2, Qwen 3.8 Max—and three common agentic benchmarks, we found reward hacking in 50–96% of rollouts. Why is this behavior so common? Reward hacking is a natural consequence of optimizing imperfect objectives in imperfect environments. Whenever the reward we give a model differs from what we actually want, a sufficiently capable model may discover ways to optimize the former without accomplishing the latter. In practice, training setups for frontier models are quite imperfect, and are unable to prevent models from learning this lesson. Needless to say, this is egregiously high.

In practice, this looks like models recognizing that they’re in an evaluation, reasoning about hidden tests, and/or copying solutions verbatim from memory instead of solving a problem on their own (as we instruct them to).

The challenge is monitoring for reward hacking at scale. Agentic models generate mind-boggling numbers of tokens and actions, making human review completely infeasible. For example, Anthropic’s recent investigation of cybersecurity incidents involved 481 million transcripts. Even if each transcript was only a couple thousand tokens long (they can in fact stretch into the millions), this would be like reading War and Peace more than a million times over. One approach is to use a second LLM to judge if particular outputs contain reward hacking, but this is slow and prohibitively expensive.

Complicating matters further, monitoring only what models say or do can miss critical information. Models involved in the Hugging Face incident tried to tamper with their own transcripts to cover their tracks, i.e., models are taking actions to control their own chain of thought, and newer models appear to be more capable of doing so.

Models “know” when they’re reward hacking

So how can we monitor for reward hacking?

Conveniently, when we have access to models’ internal computations, interpretability methods can tell us what those computations mean (at least in part). Using one such method, we found an internal signal that accompanies reward hacking.

How do we know what this signal means? In particular, how do we know it’s a real concept inside of the model, and not just a spurious correlation? One way is to see which internet text samples most strongly activate that signal:

Example 1: The performance of CPUs (a fundamental element in a computer) can cause manufacturers to design computers not intended to be very fast when working with them, but to be very fast when the speed test is applied (Goodhart’s law).

Example 2: A machine learning agent intended to transform aerial images into street maps and back was found to be cheating by hiding information it would need later in “a nearly imperceptible, high-frequency signal.” Clever girl! This occurrence reveals a problem with computers that has existed since they were invented: they do exactly what you tell them to do.

Example 3: Here’s what you can do to make sure your text is original, […] Always cite all the sources used. This can help you avoid plagiarism […] Switch languages by replacing familiar characters with others from different languages. Doing so makes Turnitin treat your article as foreign. It will not be able to trace similarities.

These examples consistently contain concepts relating to cheating, gaming a metric, and avoiding detection across domains, suggesting that the internal representation we found is fairly specific to those topics.

Another clue comes from translating the direction back into the model’s output vocabulary. The tokens most associated with it include words like “cheating,” “hack,” “sneak,” “illicit,” “hardcoded,” and “unethical,” along with similar words in Chinese. This is a coarse method, but the thematic coherence of the top words is another suggestion that there’s a coherent pattern here.

We also tested this signal by studying how it impacted the model’s behavior. In one experiment, we amplified the signal (i.e., steered the model) while asking a model to write a short story about an exam. The model wrote stories about cheating – including stories that treated the cheating as justified or natural.

It’s hard to say in a deep philosophical sense whether models “know” they are reward hacking in exactly the way a person does. But these experiments show that models appear to internally associate their behavior with a coherent, general concept of reward hacking. To the extent they know anything about themselves, it seems likely they know when they’re reward hacking.

And because that representation is available in the model’s activations, we can monitor it directly.

We can detect reward hacking effectively with probes

Since models “know” when they’re reward hacking, we can look at their internal signals instead of monitoring only their outputs.

Probes are small, purpose-built detectors that use a live “brain scan” of a model—i.e., activation monitors. Here, we use simple difference-of-means probes to distinguish reward hacking from normal behavior (this is how we found the internal representation detailed in the section above).

These simple probes work remarkably well—often performing similarly or sometimes even better than an LLM-based chain-of-thought monitor. Compared to chain-of-thought monitors, our probes catch 3.1% more hacks in Kimi K3 but 7.9% fewer hacks in GLM 5.2 on DeepSWE at a matched false positive rate.

More importantly, the probes aren’t simply memorizing one particular way of hacking specific environments. Even though we built our probes using short coding examples, they still do well on real model outputs across very long contexts, including on new tasks like shopping and customer support. This suggests that our probes pick up on a generalizable signal.

Activation monitors catch warning signs that chain-of-thought monitors miss

Our probes can also provide information that chain-of-thought monitors miss, even with access to the entire transcript.

In some cases, individual actions and statements look innocuous in isolation, even though they become suspicious in the broader context of what the agent is trying to accomplish—often across a very long transcript. We find cases where the activation probe catches these reward hacks even when the LLM judge misses them.

Even more interestingly, probes can fire while a model is still contemplating a reward hack, before it takes any action. Even when the model doesn’t end up carrying out a hack, our probes show us points where it’s more likely.

When the probe fires on a contemplated reward hack, and we generate the remainder of the trajectory again, the model subsequently carries out that reward hack at a far greater rate compared to points where the probe didn’t fire.

The probes are more likely than the LLM monitor to identify these moments. Both techniques surface information that neither reliably does on its own!

Probes make real-time monitoring feasible at scale

As mentioned above, monitoring for reward hacking with a frontier LLM is prohibitively expensive. But effective probes change that calculus, because they’re orders of magnitude more efficient compared to LLM monitors. Why? They perform very little computation themselves, and they leverage the internal activations that are already computed during a model’s forward pass.

In practice, the two can be combined: a probe can act as an inexpensive, always-on first-line monitor, escalating suspicious behavior to the more expensive LLM monitor when necessary. On Kimi K3, a probe + LLM combined setup reduces the cost of LLM monitoring by 90% with only a ~1% drop in precision.

Toward a solution to reward hacking

Our results suggest that models give us a useful signal for catching reward hacking: their own internal representations. Across models and environments, probes can identify reward hacking, generalize beyond the setting they were trained on, and surface a coherent internal concept associated with reward hacking. They can also catch warning signs that text-based monitors miss and make real-time monitoring feasible at scale.

The ability to detect reward hacking unlocks far more than monitoring. Once we detect it, we can:

• pause the model before the behavior gets further reinforced
• pinpoint buggy environments or impossible tasks that incentivize reward hacking, and fix them before training further

Each of these interventions could help significantly mitigate reward hacking today. We’re actively researching how deploying reward hacking probes like these to monitor frontier training and inference can support these interventions and mitigate reward hacking in practice.

In addition to methods like ours, we believe that other approaches to mitigating reward hacking can and should be pursued in parallel: e.g., making automated graders more robust and preserving chain-of-thought monitorability.

Furthermore, our results open up an exciting research direction that we are actively pursuing: if we understand how reward hacking is represented in models, we could shape the training process itself so that models don’t learn the behavior. We’re optimistic that in the near future, every training run will be monitored for reward hacking, and that current rates of reward hacking will be unthinkable.

Intro

On July 25, 2026, we chained two critical vulnerabilities to compromise multiple OpenAI employees’ ChatGPT accounts. With these accounts, we could then access internal OpenAI repositories, and potentially many other connectors.

To prove we had in fact gained the access we believed without allowing ourselves to learn any sensitive information, we used the employee’s Codex to open a PR #1186742 in OpenAI’s internal monorepo openai/openai.

Until two months ago, any user or OpenAI employee logging into OpenAI’s own help forum (community.openai.com) could have had their ChatGPT and Codex accounts taken over. Since people can connect various services to Codex and ChatGPT, the scope of what we could theoretically access was huge, including GitHub, Slack and emails.

The entire timeline from initial discovery to access to OpenAI repo access took place in less than 72 hours.

We immediately reported the initial vulnerability to OpenAI and Discourse and worked with them to coordinate the patch. We appreciate their attention to detail and fast resolution of this issue. OpenAI also paid us a $6,500 bounty.

We provide a full timeline of the disclosure process here. The rest of the post details how we discovered the two vulnerabilities, how we used claude models, as well as our takeaways from this experience.

Background

A few months ago, our team at Hacktron, led by Harsh Jaiswal alongside Mohan Pedhapati and Rahul Maini, began researching frontier AI companies to find security vulnerabilities. This led us to discover an SSO misconfiguration in OpenAI’s identity infrastructure and a libheif RCE in the community forum used by OpenAI.

We’ve since expanded the research into HEIF Heist, a multi-month investigation tracing libheif across Slack, Meta, GitHub Enterprise, Ruby on Rails, and Node.js frameworks such as Next.js, Astro, and Gatsby. A surprising amount of widely-used software depends on this one image-processing library.

If your application processes user-controlled images and accepts .heic/.heif/.avif images, it is highly likely it is affected.

Hacking community.openai.com

OpenAI uses Discourse for their forum and allows “Sign in with OpenAI” through auth.openai.com. After getting a good understanding of OpenAI’s services and infrastructure, we had reason to believe that compromising the forum could create a path into broader OpenAI services through this identity flow. To test that hypothesis, we first needed remote code execution on an OpenAI service like the Discourse community forum.

Heap buffer overflow in libheif

On July 23, we started reviewing Discourse’s image-upload pipeline, and we found that HEIC and HEIF files followed an unusual path. Discourse normally used FastImage for image checks, but because FastImage did not support HEIF, it passed those files to ImageMagick’s magick command for conversion. That exposed the underlying libheif parser directly to attacker-controlled files.

We started an Opus 4.8 session with the Discourse Docker image and asked it to inspect the installed libheif package for security issues. After a while, it found that some particular security fixes were not back-ported to the libheif package. This allowed an heap buffer overflow leading to OOB R/W primitives during HEIC decoding.

Interestingly, the vulnerable code had been changed upstream the previous year, but the commit was not documented as a security fix and received no CVE. This might be a reason why Debian 12 and 13 have not received the security relevant backports in time. Because Discourse’s Docker image was based on Debian 12, it installed the vulnerable libheif version 1.19.7. Even Debian 13 still shipped the vulnerable version 1.19.8 at the time. Since then, Debian has published its security update for Debian 13 on August 8, 2026.

On July 24, we used Opus 4.8 to develop a working ImageMagick/libheif code-execution exploit with ASLR disabled. We then launched several separate sessions to make it reliable against Discourse’s default configuration with ASLR enabled, which wasn’t fruitful.

Opus 5 Released

That evening, Anthropic released Claude Opus 5. We started a new session, which first produced a working ARM64 exploit for a local Mac within 3 hours. We then asked it to port the exploit to the x86-64 environment and jemalloc configuration used by Discourse.

By 6:00 a.m. on July 25, we had confirmed local RCE through an image upload. We then placed Claude in an autonomous /goal loop against our own Discourse Cloud instance. When we checked again at 10:00 a.m., the agent had achieved RCE on Discourse Cloud and demonstrated access by reading /etc/hosts. Using the generated exploit script, we managed to get RCE on OpenAI’s instance.

After we had confirmed our hypothesis of no interaction account takeover of ChatGPT/Codex accounts from active members of the forum, we immediately sent our report to OpenAI. We then took over an OpenAI employee’s account, whose Codex was connected to OpenAI’s Github organization. To demonstrate impact without actually accessing any internal code, we sent a prompt to this employee’s Codex account to open a PR for us in OpenAI’s internal monorepo. Then we stopped any further testing.

We want to emphasize that the vulnerability to escalate is not Discourse-specific. It is an OpenAI SSO issue that turned the forum compromise into access to ChatGPT and Codex. If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to same access - Discourse was merely one way of proofing it.

Costs of finding these vulnerabilities

The Discourse and OpenAI hack took a few days for an agent, and just a few hours of human time. The whole HEIF Heist research project going after Slack, Meta, and more took two-months, cost less than $3,000 in tokens in total, and was conducted by three researchers. Adapting the exploit to each new company usually took only one or two days.

We observed that every new model is getting increasingly capable, as evident by the Discourse exploit presented in this report. Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled. Within hours of Opus 5’s release, we gave it the same problem and it succeeded. Across the broader campaign, we saw another clear jump from Opus 5 to GPT-5.6 Sol, when we had to exploit the vulnerability without knowing anything about the target system besides that it’s vulnerable.

Epilogue

Software has long benefited from a kind of security through complexity. The code and even the vulnerability could be public, but turning a bug into a reliable exploit still required rare expertise, significant time, and knowledge of the target environment. Known memory corruption vulnerabilities were expensive to operationalize, while zero-days were mostly reserved for the highest-value targets.

This was never a real security boundary, but it protected ordinary companies in practice from software vulnerabilities. AI is removing that protection by turning more of this scarce expertise into compute. Work that once required a well-resourced team and months of effort can now be compressed into days.

Versions affected and patches

• Update upstream. Install the latest security-patched libheif and libde265 packages through your distribution’s security channel or an upstream release.
• Defense in depth. Given the complexity of the ISO base media file format and the pace of decoder updates, future memory-safety flaws are likely. Production architectures should disable untrusted HEIF/AVIF decoding where it is not needed, or isolate image-processing pipelines inside hardened, ephemeral sandboxes.

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 →

Getting started with runtime security and Falco

Falco Feeds extends the power of Falco by giving open source-focused companies access to expert-written rules that are continuously updated as new threats are discovered.

Runtime security serves as a last line of defense to cover posture gaps.

Imagine a public-facing web application. An attacker could use a software bug to gain initial access, then move laterally and escalate privileges to access the rest of your cloud infrastructure. Or, think about stolen credentials. One of your developers used their work laptop to download a Minecraft mod for his son. However, he instead downloaded malware that stole cloud credentials. Now the attacker has access through the main door.

Although posture helps enforce best practices, it is blind to ongoing threats. That’s where runtime security chips in.

Let's briefly introduce you to runtime security, uncovering how Falco works its magic and how easy it is to get started with Falco.

What is runtime security?

Runtime security is the protection of workloads once they are in execution. It acts as a safety net, covering for security risks that posture cannot detect. This includes:

• Zero-day vulnerabilities, or issues previously unknown to a software creator.
• Privilege escalation attempts.
• Bugs that cause erratic behavior or resource leaking.

Runtime security software acts similarly to an antivirus, observing everything that is happening in the system and triggering alarms when suspicious activity occurs.

An attacker can exploit a software vulnerability not yet known to the public to gain initial access to a container. Then, they can use misconfigurations to move laterally and escalate privileges. If you rely only on mitigating known vulnerabilities and on compliance, you are blind to these attacks.

A runtime security tool like Falco will detect suspicious network connections on the container and suspicious behaviour in the cloud account, triggering an alarm that gives you a chance to contain the attack. Falco will also include cloud-native context in each alert to help you identify the source of the alert and correlate multiple alerts to understand the scope of the attack.

We’ve observed the use of AI to assist, speed up, and customize attacks. Runtime is more unpredictable than ever, so posture and best practices alone are not enough; you need solid runtime security as a safety net.

Runtime security for cloud and containers

Cloud-native workloads are a mix of moving pieces, and it’s challenging to gain visibility into all of them.

Let’s cover the main elements and how to implement runtime security on them.

Container workloads are made of:

• Containers: Your workloads, running in sandboxes.
• Container runtime: The process on a server executing the containers and interfacing with the host resources.
• Orchestrators: A combination of tools that deploys and manages containers across a cluster of servers.
• Nodes: Each of the servers that comprises the cluster and hosts its components.

Cloud workloads may contain containers, but also include:

• Servers: Good old virtual machines where you can run whatever software you want.
• Serverless workloads: Services where you can run software without managing the server underneath.
• Managed services: Databases, storage, firewalls, networking, message queues, and other services you configure and use, but don’t manage at a low level.

With a special mention to the configuration and access management of all these services, which are often two entities in themselves.

To implement runtime security for cloud-native environments, you can use a combination of:

• Agents on cluster nodes and compute units. They keep track of everything happening in the system through a mix of strategies, such as kernel instrumentation to read system calls or using the orchestrator API to tap into logs.
• Sidecars on serverless workloads where kernel instrumentalization is not available, but alternatives like ptrace or LD_PRELOAD are.
• Agentless services that use the cloud provider’s API to tap into the audit log. They can also use the API to perform response actions, such as quarantining an account or stopping a workload.

Falco is the most popular OSS cloud and container runtime security tool. As such, its ecosystem has tools to implement all the above.

How does Falco work?

Falco is a cloud-native security tool that provides runtime security across hosts, containers, Kubernetes, and cloud environments.

Falco provides deep visibility by analyzing events from multiple sources. On one side, it fetches kernel system calls from the host system; on the other, it receives events via Falco plugins that can tap into audit logs from Kubernetes, cloud providers, and even SaaS services like GitLab, Box, or Salesforce.

Equally important, Falco adds context to its findings, helping DevOps, security, and cloud teams understand exactly who did what and where. This context is key when trying to understand the scope of a security event.

You can complement Falco’s detection skills with other tools in the ecosystem:

By default, Falco can send alerts to a limited number of channels. Falcosidekick expands Falco’s alert channels to known chat services like Slack, observability tools like Prometheus, alerting systems like Pagerduty, and more.

Also, Stratoshark lets you explore events from the desktop using a Wireshark-based interface.

Falco architecture

Internally, Falco works at several levels:

• The Falco binary runs in userspace, parsing information from drivers and plugins, evaluating rules, and outputting alerts.
• The drivers gather system calls from the host. The Kernel module (default) and the eBPF probe run at the kernel level and can see everything that’s happening, while the userspace instrumentation can run with fewer privileges with limited visibility.
• Finally, the configuration defines how Falco runs, which rules to assert, and when to trigger alerts.

Falco rules

Falco evaluates events against rules and considers them suspicious if the condition is met.

For example, a bash spawn inside a container is unusual. The following rule would flag such events, focusing on how the condition looks for processes where proc.name is bash:

- rule: Detect bash in a container
  desc: You shouldn't have a shell run in a container
  condition: container.id != host and proc.name = bash
  output: Bash ran inside a container (user=%user.name command=%proc.cmdline %container.info)
  priority: INFO

When this rule detects an event, we will receive the message defined on the output property:

20:07:06.837415779: Notice A shell was spawned in a container with an attached terminal (user=root container=1dab04047700 shell=bash parent=runc cmdline=bash terminal=34816 container_id=1dab04047700 image=docker.io/falcosecurity/falco) container=1dab04047700

And that's it! Using simple language, we can see runtime container activity and detect potential security events.

Falco is a solid project

"Ok, ok, Falco is great," I hear you say. "But how solid is this project?"

And this is a reasonable question. After all, no one wants to commit to a solution only to migrate to something else a short time later. So here are some interesting facts to put things in perspective.

Falco adoption continues to grow, and its graduation from the Cloud Native Computing Foundation® (CNCF) in 2024 has only accelerated this trend. For example, the number of users following Falco's GitHub repo has quadrupled since incubation, keeping a constant pace.

Adoption is so ubiquitous that Falco is now part of the curriculum for the official CKS exam.

And for us, the icing on the cake is being recognized by Gartner. Among the reasons for using Falco, Gartner analysts note that "Falco enables detection of anomalous behavior in application deployments with Kubernetes context awareness." [1]

Falco is a strong project with a thriving community, and you should consider it a serious contender for your runtime container security needs.

First steps with Falco

Installing Falco on your Linux machine is fairly easy. In summary: Install the kernel modules, set up the repository, and then install the binaries with apt-get (on debian-based hosts).

However, in a cloud-native world, chances are that you don’t do bare metal installations and you use containers instead.

Let's cover how to install Falco in a Kubernetes cluster using Helm, Kubernetes' package manager, and how to customize the available rules.

Wait, I don't have a Kubernetes cluster to test this on!

Worry not! We have you covered.

Follow the instructions to install Minikube, and you'll get a single-node Kubernetes cluster in a matter of minutes.

Remember to start Minikube with:

$ minikube start

And perform a quick test to confirm that it's up and running:

$ minikube kubectl -- get nodes
NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   6m18s   v1.22.2

Let's deploy Falco on Kubernetes with Helm

For this, make sure you have Helm installed.

We will use the community-supported chart to install Falco.

First, add the falcosecurity charts repository and update:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

Now, it's time to install Falco using the helm install command:

helm install --set tty=true falco falcosecurity/falco

Warning: Don’t use --set tty=false in production. We are using it to simplify the example and get an instant output later, but it overrides stdout buffering and causes serious performance issues. In production, you would use other output channels or Falcosidekick, which don’t buffer and output alerts instantly.

Wait a few seconds for the containers to start, identify the Falco Pod, and have a look at the container logs:

$ kubectl get pods
`NAME READY STATUS RESTARTS AGE
`falco-467d7 1/1 Running 0 4m13s
$ kubectl logs falco-467d7
…
Wed Nov 3 15:05:17 2021: Falco initialized with configuration file /etc/falco/falco.yaml
Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.yaml:
Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.local.yaml:
Wed Nov 3 15:05:17 2021: Starting internal webserver, listening on port 8765
…

Putting Falco to the test.

Now that Falco is deployed and running, let's see if it can detect some suspicious activity.

Since containers are not meant to be accessed interactively, one of the biggest red flags of a compromised container is the spawning of a terminal shell. There are legitimate reasons for this to happen, but they are usually limited to troubleshooting tasks.

Falco ships with rules enabled by default to detect such scenarios.

Let's take the same falco Pod we deployed earlier, and let's run some commands inside it:

$ kubectl exec -it falco-4gsbr -- /bin/sh
root@falco-4gsbr:/#

If we now check the Falco logs, we'll see a warning:

$ kubectl logs falco-4gsbr
…
Triggered rules by rule name:
16:37:58.199209616: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd shell=bash parent=runc cmdline=bash terminal=34816 container_id=b1cfe2fbfcdd image=falcosecurity/falco) k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd
…

Notice how Falco provides contextual information about the pod and namespace where the event was triggered.

Next steps

Now that Falco is working, there's a lot of fun to be had.

Continue your journey with:

• This webinar: Getting started with container runtime security using Falco.
• The Falco community maintained hands-on labs.
• The Runtime Security and Falco 101 course by Sysdig.
• This Falco workshop, and these too.

You can also try integrating some Falco plugins:

• SaaS services like Gitlab, Box, or Salesforce.
• Track Bitcoin activity.
• Implement pet surveillance.
• Or, check the list of registered plugins.

You can also get familiar with other Falco projects:

• Set up Falcosidekick to forward events.
• Get started with Stratoshark in 5 minutes.

And, if you want to get involved with the Falco project:

• Get started at Falco.org.
• Check out the Falco project on GitHub.
• Get involved with the Falco community.
• Meet the maintainers on the Falco Slack.
• Follow @falco_org on Twitter.

Conclusion

Falco is a solid open source solution for implementing runtime security in containers, Kubernetes, and the cloud.

Falco's cloud-native design enables it to provide the context you need to quickly and effectively resolve the security events in your modern application environments.

[1] Gartner, "Open-Source Options for Threat Detection and Incident Response", Anna Belak and Eric Ahlm, 1 December 2020.

Full article content is not available for inline reading.

Read the original article →

Projects redesigned: from folder to conversation

A new experience for Claude projects, now available in beta in Claude Code

Managing multiple sessions across a build used to require you to divide the work, juggle handoffs, and stitch the results back together. Now in a Claude Code project, you describe what needs to get done and Claude manages the work.

Claude scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result. You can steer progress throughout, even from your phone, and it keeps working after you step away from your computer.

For example, configure a project and set a goal to reduce your app's checkout p75 latency. Then ask Claude to profile each endpoint, test optimizations, and open PRs in parallel threads. Or connect your API, web, and mobile repos and set a goal to retire a deprecated v1 endpoint. Claude creates a thread per repo to migrate the callers, run the tests, open PRs, and then tells you which ones need to merge first.

Starting today, updated projects are available in beta to select Claude Pro and Max subscribers who use cloud sessions in Claude Code and don’t have any existing projects on the web or desktop.

Over the coming week, we'll expand access to more Claude Code users on those plans. Updated projects across all of Claude and Team and Enterprise plans come after that. If you're on Pro or Max and don't have access yet, you can join the waitlist.

Existing projects on Pro and Max plans keep working as they do today. We'll upgrade them as the rollout expands to chat and Cowork.

Threads do the work, Claude directs it

Projects have threads that do the work and a coordinator that directs them.

When you start a project, you select a goal as well as the repo or context. Claude starts by suggesting work it can pick up right away. You can configure the project’s cloud environment, connectors, plugins, instructions, and model.

You can monitor and guide progress in the main project chat, or dive into each individual thread to examine and steer the details. Brief Claude in the project the way you'd brief a chief of staff and it routes work to new or pre-existing threads.

Claude also checks in and follows through on work. With repositories connected, a thread opens pull requests and runs your tests; with documents, it reads them and drafts.

Under the hood, each thread is a Claude Code cloud session working on its own branch and copy of the repo. The coordinator keeps work organized, but if any threads work on the same code, the overlap is resolved as a merge conflict just like any other PR.

Each thread can further split its delegated work into pieces using subagents, loops, and workflows when needed so large assignments finish faster.

Context builds over time

Projects are designed for long-running or agentic workflows: work that takes longer than one reply and has more than one part.

Over time, Claude learns more about the project details and applies them to its work. Every thread now adds to and draws from a shared memory, reducing the need for complex prompt engineering.

For example, Claude can remember the release moved to Friday, why the export was dropped, or who to check in with before touching the billing service.

Claude also remembers your working and communication style. You can ask it to adjust how often it checks in, how frequently it starts new threads, or how detailed to make each update.

Alongside memory, projects now include a library that collects the files you add and the artifacts produced by Claude. This makes it easier to find relevant materials and for new work to build on past efforts.

What's next

Projects can run several threads at once, and each one is a full Claude Code session. Because of this, projects can reach usage limits faster. You can check project specific usage and select the model and effort levels used by the coordinator chat as well as the worker threads.

Threads run in the cloud today; running on your machine alongside your local tools and code and behind your network is coming very soon.

Start using projects.

Full article content is not available for inline reading.

Read the original article →

LLMs-as-classifiers, prompts applied to a context and returning a label, suck to work with. This is especially painful because they often perform pretty decently.

But let’s consider some of the things we’d want in a classifier and see how an LLM-as-classifier stacks up:

Calibration / Threshold Control

LLM verdicts are often hard labels; you can get token log probabilities but there is no mechanism for believing these to be well-calibrated. You can ask the LLM for its confidence and there’s no reason to suspect that to be well-calibrated either. As a related problem it’s then rather hard to trade off precision and recall with these labels in a principled way.

Incorporating all available information

LLMs work great with unstructured data but we often have nice structured data as well. We can paste this into the prompt however the LLM doesn’t really need to use it. Even for prose parts of the prompt we don’t know if the LLM actually used it or not. Frustrating to say the least and probably losing some signal.

The LLM has some prior information baked in which might be a poor fit for our distribution. For instance the LLM won’t know whether we’re testing on a population where our positive class is rare or an enriched population where our positive class is relatively prevalent. And I guess you can give it that context but now you’ve got to modify that for each new population and also, as in our first point, it’s not clear that this will be appropriately incorporated into the LLM’s judgement.

Interpretability

In some respects a LLM prompt is highly interpretable, after all it’s written in prose; unfortunately it’s not clear that we know exactly what’s going on within the LLM and what parts of the prompt are being followed correctly (or at all).

These failures are not the fault of the LLM: it’s not designed as a classifier and indeed has no mechanism for plausibly doing some of these things. But only because we’re thinking of things incorrectly…

LLM Classification is feature engineering

With the proper framework that harnesses the LLM’s power we can get the power of the LLM with the convenience of stock ML algorithms. For a taste of what’s possible consider wrapping the LLM verdict with a simple logistic regression:

p(y = 1 | x) = σ(α + β · LLM(x))

Note that in the special case of β → ∞ this basically recovers our LLM classifier!! But that’s a dumb parameter selection policy. We should instead do our usual approach of estimating our parameters using some training data. This will then collapse into two cases and we just get the empirical estimates.

p(y = k | LLM(x) = 1) = (Σ I(yi = k and LLM(xi) = 1)) / (Σ I(LLM(xi) = 1))

Now let’s revisit our desiderata:

Calibration / Threshold Control

As just mentioned, just using the LLM prediction as a feature we get two predictions at the empirical proportions (and thus calibrated in expectation). As we add more features (see next) we will obviously get more unique points and, assuming our model is decently flexible, these should be approximately well-calibrated (and we have ways to improve that). And since we have actual probabilities out we can now choose our operating threshold to trade off precision and recall as needed.

Incorporating all available information

This is just a logistic regression so we can obviously add in other covariates. To adapt to the different baselines the logistic regression is fit to the training dataset and thus adapts to that baseline and covariate structure. We can even reweight the examples to try to target other distributions of interest.

Interpretability

We still have the problem of interpreting the LLM verdict itself but now we have a better sense of how that verdict is contributing to our final decision (especially if we have other covariates included).

We’ve basically recovered all of the nice properties we wanted from our model! Can we go even further?

LLM Classification is really good feature engineering

Suppose we are not pleased with the performance of our classifier: what should we do? In the LLM-as-classifier case our only option is to try messing with the prompt. This is an arcane undertaking about which advice abounds on the internet but wisdom is scarce. Best of luck to you.

From a ML point of view the way you make your model better is:

Collecting more data

Admittedly this is uncool: the allure of LLMs-as-classifiers is that you have a training-free methodology. So it’s disappointing that you need data for training purposes in this feature engineering paradigm. I’d argue though that this is less inconvenient than one might think. Like we’re going to need a test set in order to test model performance anyways (you were going to quantify your performance right?) so what’s a little more for training?

Making your features better

Making your features better is complex when editting prose. We can at least screen our features: if we believe that a feature should always lead to a positive we can empirically check this and debug appropriately. We can also evaluate the features themselves: we treat them as a secondary target (and recurse on making that classifier better).

Creating more features

You can use the residuals in your model to try and figure out how to improve your prompts not by meddling with wording but rather by considering a broader set of features. We might immediately consider taking the log probability of our verdict token; alternatively we can have multiple runs of our classifier (if we have reasoning before the verdicts those logprobs can go to 0 or 1). We can also get more features from the LLM itself by asking for subverdicts or other features.

Improving your model architecture

Finally model architecture is purely plug-and-play. Don’t like logistic regression, consider xgboost or a neural network. Heck have a rules based system implemented by the LLM for all I care. All are fair game.

Test Case: Irony Detection

Let’s make this more concrete using an example. We’ll use the SemEval 2018 Task 3 dataset, a collection of 4618 tweets (3834 train / 784 test) labeled for irony by expert annotators. Irony is a natural fit for this post it’s an NLP task where an LLM clearly has real signal and we benefit from the worldly knowledge implicitly embedded in the LLM.

Our prompt asks the model to make a binary irony judgment, and we run it over all the tweets at once as a batch job:

from typing import Literal

from pydantic import BaseModel, Field

MODEL = "gemini-3.1-flash-lite"

PROMPT_TEMPLATE = """\
Irony is when someone says one thing but means another, often for \
humorous or critical effect. It can be subtle: a tweet might read as \
sincere at first glance but carry an ironic tone through word choice, \
context, or contrast.

Consider the following tweet and label it as "Ironic" or "Not".

{tweet}"""


class Verdict(BaseModel):
    reasoning: str = Field(
        description="Brief reasoning: what language or context suggests irony or sincerity."
    )
    verdict: Literal["Ironic", "Not"] = Field(
        description='Whether the tweet is ironic ("Ironic") or not ("Not").'
    )


def build_request(row_id: int, tweet: str) -> dict:
    return {
        "contents": [
            {"role": "user", "parts": [{"text": PROMPT_TEMPLATE.format(tweet=tweet)}]}
        ],
        "metadata": {"id": str(row_id)},
        "config": {
            "response_mime_type": "application/json",
            "response_schema": Verdict,
            "temperature": 0,
        },
    }

Performance

We get the following performance just from this prompt

It’s actually quite remarkable how well this does as one-shot. You wouldn’t expect this to be possible without learning which is the cool thing about LLMs. Of course it’s still pretty meh: the Brier score is quite bad as we don’t have calibration (indeed just random guessing gets us a Brier score of 0.25).

Desiderata

Calibration

We can do better with our logistic regression which achieves calibration (though note it doesn’t affect the ordering so F1 is the same).

Adding Features

Let’s consider some additional LLM features. Firstly let’s take a quick look at our misclassifications (they’re the same from either model)

In light of this let’s modify our prompt as follows

from typing import Literal

from pydantic import BaseModel, Field

MODEL = "gemini-3.1-flash-lite"

PROMPT_TEMPLATE = """\
Analyse the following tweet along several dimensions.

Tweet: {tweet}

First, label it as "Ironic" or "Not" (irony is when the author says one \
thing but means another — not merely criticism or complaint). Then answer \
each question:
1. Is the tweet trying to be funny or humorous (regardless of whether it's ironic)?
2. Does the tweet describe a realistic, plausible situation or event?
3. Would you need to know the reply thread, current news, or other external \
context to understand the author's intent?
4. Does the tweet express a genuine complaint or frustration?
5. Does the tweet describe a negative or frustrating situation using \
positive or upbeat language (i.e. is there a mismatch between the situation \
and how it is described)?
6. Is the tweet self-deprecating — does the author make fun of or \
belittle themselves?
7. Does the tweet contain an explicit contrast or juxtaposition of two \
things (e.g. "X but Y", "while X, Y", "sure, X")?
8. Is the tweet a rhetorical question — a question not expecting a \
literal answer?
9. Does the tweet give what appears to be a compliment or praise but \
is actually critical or dismissive (a backhanded compliment)?
10. Is the tweet directed as criticism at a specific named person, \
organisation, or public figure?
11. Ignoring tone and word choice entirely: is the underlying situation \
described objectively negative or unfortunate (e.g. illness, failure, \
injustice, bad luck)?
12. Is the tweet making a direct, sincere critical or political point — \
i.e. the criticism is meant literally, not ironically? (A tweet can be \
critical and non-ironic.)
13. Does the author express approval, enthusiasm, or celebration of \
something that is clearly bad or undesirable (e.g. "love when X" where \
X is obviously awful)?
14. Does the author feign surprise or shock at something that is actually \
predictable, obvious, or expected (e.g. "shocked, just shocked", \
"who could have seen this coming")?
15. Does the tweet use mock enthusiasm — over-the-top positive language \
(exclamations, "amazing!", "so great!") applied to something bad or \
frustrating?
16. Does the tweet contain a pun, wordplay, or a deliberate double \
meaning unrelated to irony (the humour comes from the language itself, \
not from saying the opposite of what is meant)?
17. Is the tweet primarily about politics, politicians, government, \
elections, or political ideology?
18. Is the tweet primarily about a celebrity, athlete, sports team, \
or entertainment figure?
19. Is the tweet about the author's personal daily life, routine, or \
mundane situation (commute, weather, food, work, sleep)?"""


class Features(BaseModel):
    reasoning: str = Field(
        description="Brief reasoning covering the irony verdict and all nineteen dimensions."
    )
    verdict: Literal["Ironic", "Not"] = Field(
        description='Whether the tweet is ironic ("Ironic") or not ("Not").'
    )
    is_humorous: bool = Field(
        description="True if the tweet is trying to be funny or humorous."
    )
    realistic_situation: bool = Field(
        description="True if the tweet describes a realistic, plausible situation."
    )
    requires_context: bool = Field(
        description="True if understanding the author's intent requires external context."
    )
    is_complaint: bool = Field(
        description="True if the tweet expresses a genuine complaint or frustration."
    )
    sentiment_mismatch: bool = Field(
        description="True if the tweet describes a negative/frustrating situation using positive language."
    )
    is_self_deprecating: bool = Field(
        description="True if the author makes fun of or belittles themselves."
    )
    has_contrast: bool = Field(
        description="True if the tweet contains an explicit contrast or juxtaposition of two things."
    )
    is_rhetorical_question: bool = Field(
        description="True if the tweet is a rhetorical question not expecting a literal answer."
    )
    is_backhanded_compliment: bool = Field(
        description="True if the tweet gives apparent praise that is actually critical or dismissive."
    )
    targets_person_or_org: bool = Field(
        description="True if the tweet is directed as criticism at a specific named person, organisation, or public figure."
    )
    situation_is_negative: bool = Field(
        description="True if the underlying situation described is objectively negative or unfortunate, regardless of tone."
    )
    is_literal_criticism: bool = Field(
        description="True if the tweet makes a direct, sincere critical or political point (criticism is meant literally, not ironically)."
    )
    author_endorses_bad_outcome: bool = Field(
        description="True if the author expresses approval or celebration of something clearly bad or undesirable."
    )
    feigned_surprise: bool = Field(
        description="True if the author feigns shock or surprise at something predictable or obvious."
    )
    mock_enthusiasm: bool = Field(
        description="True if the tweet uses over-the-top positive language applied to something bad or frustrating."
    )
    is_pun_or_wordplay: bool = Field(
        description="True if the tweet contains a pun or wordplay where humour comes from the language itself rather than saying the opposite of what is meant."
    )
    is_political: bool = Field(
        description="True if the tweet is primarily about politics, politicians, government, elections, or political ideology."
    )
    is_celebrity_or_sports: bool = Field(
        description="True if the tweet is primarily about a celebrity, athlete, sports team, or entertainment figure."
    )
    is_mundane_daily_life: bool = Field(
        description="True if the tweet is about the author's personal daily life, routine, or mundane situation."
    )


def build_request(row_id: int, tweet: str) -> dict:
    return {
        "contents": [
            {"role": "user", "parts": [{"text": PROMPT_TEMPLATE.format(tweet=tweet)}]}
        ],
        "metadata": {"id": str(row_id)},
        "config": {
            "response_mime_type": "application/json",
            "response_schema": Features,
            "temperature": 0,
        },
    }

We’ll also start adding in some deterministic features that we can compute:

So do we see improvements? We compare three nested models: verdict only, verdict + all LLM features, verdict + all features (LLM + rule-based).

We see a clear benefit from each level of additional features including the deterministic features which lie outside of the LLM.

Interpretability

Comparison with published results

We see that our initial LLM classifier beats the competition winner handily (0.747 vs 0.705). With the feature engineering perspective we have overlapping CIs with the post-competition state of the art, using nothing but a logistic regression on top of LLM-extracted features.

Conclusion

Getting LLMs into shape to reliably serve as classifiers is hard work but potentially highly impactful. There’s more and more research that relies on LLMs for classification. We’re going to need to get high quality results out of these tools.

Fortunately, there’s a growing body of papers which are making this point.

• Han et al., “Large Language Models Can Automatically Engineer Features for Few-Shot Tabular Learning” (ICML 2024).
• Balek et al., “LLM-based feature generation from text for interpretable machine learning” (2024).
• Malberg, Mosca & Groh, “FELIX: Automatic and Interpretable Feature Engineering Using LLMs” (ECML PKDD 2024).

Personally I am interested in investigating agentic classifiers. Instead of a fixed feature set or class statement you empower the LLM to investigate itself. The LLM can use features of the investigative process as features when classifying: essentially grading itself on the rigor and comprehensiveness of the investigation. And with a reliable test set we can make statistically valid inferences on the results!

Measurements for understanding the pace of AI development inside frontier labs

AI systems are becoming exponentially more powerful and have begun to automate more of the process of building themselves. As the world considers slowing the pace of frontier AI development, the public needs more information.

In this post, we lay out measurement tools that can illuminate three critical aspects of AI development:

1. The extent to which AI is building the next version of itself, as opposed to being built by humans
2. Our ability to oversee and intervene in actions that AI agents take on Anthropic’s systems
3. The resources that power the development of more capable models

We also provide a snapshot of these metrics from inside Anthropic. It’s important to note that we would expect these numbers to shift if there were coordination on pacing the frontier, as called for by Anthropic CEO Dario Amodei. We plan to embed independent third-party evaluators from multiple organizations at Anthropic, and give them access to internal processes, systems, and data comparable to what internal risk assessment teams have. These third parties will verify safety practices, report incidents, and monitor key metrics such as the ones in this piece.

We are reporting these measurements because they give the public, third parties, and governments better visibility into the pace of AI development inside frontier labs. For each measurement, we describe what we measured, what the measurement showed, and what it would take to publish these measurements regularly in a form others can verify. We share methodological details in the Appendix.

Reasons to track these measurements

The measurements in this piece are focused on how models are built. By better understanding the production process of models, we have a better chance of correlating model inputs, like compute, with model outputs, like capabilities. They complement capability evaluations, which measure what models can do.

(1) Measuring AI-led AI R&D

Why measure AI-led R&D? Frontier AI labs increasingly use AI to build future AI models. This process allows labs in democratic countries to develop more capable models more quickly and conduct more safety and testing on models before they are released to secure AI’s benefits while staying on the frontier. However, models accelerating their own development could make it more challenging for humans to understand or control these systems. It is therefore important to share these metrics to understand how close the world is to reaching recursive self improvement (a model fully autonomously building its successor).

What we measured. We built a prototype index of how much of Anthropic’s AI research and development (R&D) is performed by Claude, called the Anthropic R&D Automation Index. It’s built by cataloguing every kind of AI R&D work done at the company, rating how automated each task currently is, and aggregating those ratings.

What we found. To measure the extent to which AI is doing AI R&D at Anthropic, we use an automation rating scale developed by Epoch AI that measures “Automation Level,” or AL. It runs from AL0 (no AI involvement) to AL5 (AI operates fully autonomously, with no human in the loop).

As of August 2026,

• Claude is not operating fully autonomously for any measured subset of AI R&D work.
• Claude “leads” 26% of Anthropic’s AI R&D work.
• The share of work at or above “AI collaborates” is above 90%.

(2) Measuring oversight of AI agents

Why measure oversight of agents? Like other frontier developers, Anthropic employees increasingly delegate tasks to agents that work semi-autonomously for long stretches, and that delegate work to one another. As work becomes increasingly automated, from “AI collaborates” toward “AI leads,” agents could make more consequential decisions, such as which research direction to pursue next.

What we measured. We’ve built a system that lets us oversee and intervene in actions AI agents take on Anthropic’s systems. Here, we consider three different metrics: coverage, which describes the share of an agent’s actions that pass through a monitor before or after execution; review latency, which is the time between an action and its review; and escalation rate, which is the share of agent activities that are either blocked/redirected or flagged for further review.

What we found. As of August 2026, there were approximately 30,000 agents doing research and engineering work at Anthropic at any one time in our most-used internal platform.

(3) Measuring compute allocation

Why measure compute allocation? Broadly speaking, AI developers use compute for building more powerful models, serving customers, and safety-focused work. Understanding how AI developers allocate their compute can tell you where a developer is focusing its resources and how that focus changes over time.

What we measured. We examined a snapshot of how Anthropic used all of its compute from July 13 to July 20. We sorted every workload into a small number of categories, then asked how much of the compute going to AI R&D was safety work.

What we found. Over the examined week, about 6% of compute that went to AI R&D was allocated toward safety, and about 12% of compute that went to AI-driven AI R&D was allocated toward safety.

Conclusion

As the world considers pacing the frontier, we should do everything possible to minimize the gap between what frontier labs know and what the public knows. This means better measuring the development of AI, reporting on it publicly, and giving society an opportunity to decide how to use this information.

Z.ai used a GLM-5.3-powered Infra Agent to help build GLM-5.3-Flash's production serving stack on 100,000+ Chinese accelerators in under two weeks. Dense feedback, kernel fixes, and system-level optimization tripled throughput while keeping humans responsible for objectives and risk.

Introducing Bonsai 2 27B: Near-Lossless Compression in a 9x Smaller Footprint

Two months ago, we released our first Bonsai 27B models and showed that a 27B-class multimodal model could be compressed enough to run efficiently on a local device. Today, we’re releasing Ternary Bonsai 2 27B, our most capable model yet.

Based on Qwen3.8 27B, Ternary Bonsai 2 27B brings stronger reasoning, coding, vision, and agentic capability to the Bonsai series while preserving the deployment profile that defines it: a dramatically smaller memory footprint, high local throughput, and better energy efficiency.

Ternary Bonsai 2 27B uses ternary {−1, 0, +1} weights with FP16 group-wise scaling, for 1.76 effective bits per weight and a total model footprint of 5.9GB. The low-bit representation is applied end to end across the language model. It supports a 262K-token context window, multimodal text-and-image input, and is released under the Apache 2.0 license.

Against its full-precision counterpart, Ternary Bonsai 2 27B is more than 9x smaller while retaining 98.2% of aggregate benchmark performance. At this level of retention, compression becomes a deployment unlock: nearly the same capability, in a footprint that can run in far more places.

What changed from the first Bonsai 27B release

Our first Bonsai 27B release was an important milestone, offering a practical way to run 27B-class intelligence on local devices. Bonsai 2 27B focuses on the next step: improving the model quality and runtime performance needed for real-world local applications. Compared with the previous Bonsai 27B generation, Bonsai 2 27B brings:

• a stronger base model, Qwen3.8 27B
• higher aggregate capability retention of 98.2% against the full-precision model
• improved reasoning, coding, vision, and long-horizon agentic performance

Higher capability at the same deployment point

Across a benchmark suite spanning reasoning, math, coding, instruction following, vision, and agentic tool use, Ternary Bonsai 2 27B scores 83.9, retaining 98.2% of Qwen3.8 27B’s aggregate performance.

Figure I: Benchmark scores of Ternary Bonsai 2 27B (thinking mode) compared with the full-precision Qwen3.8 27B and Qwen3.6 27B baselines. Full per-benchmark results are in the whitepaper.

The key result is not only the aggregate score, but where the capability is retained. Coding agents, tool-use systems, multimodal workflows, and long-horizon tasks are particularly sensitive to model degradation because small errors can compound over many steps. Bonsai 2 27B preserves much of the full-precision model’s performance in exactly these areas while operating at a fraction of the memory footprint.

Compared with the full-precision model and other low-bit alternatives, Bonsai 2 27B stands out as an outlier on intelligence density. Many low-bit alternatives become deployable only by giving up meaningful capability in coding, vision, or agentic tool use. Bonsai 2 27B pushes the frontier toward both higher capability and lower memory usage.

With Bonsai 2 27B, local models can start to take on real knowledge work: coding-agent loops, computer-use workflows, private document analysis, multimodal debugging, and hybrid orchestration where local models handle sensitive or high-frequency tasks while escalating selectively to the cloud.

Throughput and energy efficiency

Ternary Bonsai 2 27B reaches up to 143 tokens/second on NVIDIA GeForce RTX 5090 and 46.8 tokens/second on M5 Max. On an RTX 4090, Ternary Bonsai 2 27B consumes just 0.714 mWh/token, making it 40% more energy-efficient than an 8B model running in full-precision.

For coding assistants, higher throughput means faster edit-debug loops. For multimodal agents, it means quicker iterations over screenshots, documents, and tool calls. For private local workflows, better energy efficiency means more useful inference on the same device, longer battery life, and a more realistic path to assistants that can stay available in the background without constantly calling the cloud.

Why this release matters

Compared to Ternary Bonsai 27B, the new Ternary Bonsai 2 27B has closed the retention gap between the full precision model from 95% to over 98%. This is a significant improvement that makes the current release practically “lossless”. It further cements the notion that low-bit models can be the best way to deploy AI.

That has implications well beyond local inference. Low-bit models can change the economics and architecture of AI systems across devices, workstations, and datacenters: fitting larger models into the same memory envelope, serving more users on the same hardware, reducing energy per inference, and enabling hybrid systems that dynamically decide what should run locally and what should run in the cloud.

The question will increasingly be not just how capable a model is, but how much useful intelligence can be delivered within a given memory, compute, and power budget. If capability can continue to scale while those requirements fall dramatically, the deployment envelope for future models expands across the stack: from personal devices to large-scale datacenters.

Platform Coverage

Bonsai 2 27B runs on NVIDIA GPUs via CUDA and on Apple devices (Mac, iPhone, iPad) via MLX, through custom low-bit kernels. Model weights are available today under the Apache 2.0 License.

Full technical details of our compression, evaluation, and benchmarking processes are available in our whitepaper.

Work with Us

We work with teams to tailor Bonsai models to their applications, from post-training on domain-specific data to optimizing inference for target hardware. If you’re building AI products with tight memory, latency, or power requirements, we’d love to explore how Bonsai can help. Reach out at contact@prismml.com.

Join Us

PrismML emerged from a team of Caltech researchers and was founded with support from Khosla Ventures, Cerberus, and Google, with continuing support from Samsung. We've spent years tackling one of the field's hardest problems: compressing neural networks without sacrificing their reasoning ability.

If you want to help build the next generation of state-of-the-art AI, we'd love to hear from you.

Full article content is not available for inline reading.

Read the original article →

Agora: Git as Shared Memory for Collective AutoResearch

Research as an append-only DAG in Git

Agora lets research agents share experiments and findings across separate sessions. Contributions are immutable Git commits linked to the work they build on. Searchable views show leading results, neglected branches, and verification status; recommendations help workers choose between refining a result and exploring another approach.

Three mechanisms

Workers publish results, failures, hypotheses, and reproductions in a shared contribution graph. They use this record to choose experiments and build on prior work without sharing a conversation or workspace.

• Git-backed contribution history. Each contribution is an immutable Git commit whose parents identify the work it builds on. A SQLite contribution index provides searchable views and can be rebuilt from Git.
• Evidence scores. Results and verifications from other accounts contribute to a parent's evidence score. Self-citation is excluded. The score tracks reproduction and reuse.
• analyze() recommendations. One API call shows leading results, frequently reused contributions, contested verifications, and open hypotheses. A UCB-style ranking recommends both leading and underexplored work.

Projects define their own instructions, metrics, artifact requirements, and safety boundaries. Agora provides the shared record; workers choose their experiments.

Authentication and project metadata require separate database backups.

The weight-transfer run

Task. Workers could use 141 open-weight donor models (534 GB) from 32 architecture families. The target is a frozen 14-layer attention–SSM hybrid with hidden size 672, seven heads and 119,572,320 parameters, with a configuration that matches none of the donors. A participant submits a transfer(model, config) function; the evaluator scores 200 FineWeb-Edu texts in bits per byte. Pretraining, fine-tuning and editing the evaluator are forbidden.

Community. 13 language-model workers ran for nearly 12 days with a two-page brief, the evaluator and the shared graph, with no assigned tasks and no central planner. They published 1,703 contributions.

Milestones on the ancestry of the best contribution at cutoff (development evaluator, bits per byte):

Eighteen scored contributions on the first day account for about 98% of the total reduction; the remaining 1,106 found the next 0.03. A trained GPT-2 124M scores about 1.0. We use that score as a reference when reporting the fraction of the gap closed by transfer.

Best transfer method. Stage A builds the initialization from what the donors predict rather than from their parameters: six donors sharing the GPT-2 vocabulary are queried under 28 single-token contexts, their next-token log-softmaxes are blended into a 50257 × 50257 context-averaged bigram table, and its centered form is factorized to rank 671 by randomized SVD. The factors become the input embedding and the output head; every sublayer is zeroed. Stage B re-enables sublayers with sparse, deterministic edits on 96-dimensional bands of the hidden state: attention becomes a uniform causal mean-pool over one band, each SSM block reduces to a gated depthwise causal convolution, and layer 0's feed-forward block receives SVD-projected slices of GPT-2 small's first MLP.

Result. Without training data or gradient updates on the target, the community's best transfer() initializes the frozen 119.6M hybrid to 1.899 bpb against 3.3923 for random initialization, closing 62% of the gap to a trained GPT-2 124M. The best method's 145-commit ancestry spans 15 accounts. Workers posted 165 reproductions across 95 targets, with no reported failures. All method choices used the same 200-text development evaluator, and the final score improvement was smaller than the observed cross-hardware variation.

Coordination dynamics

At cutoff, the graph contains 1,703 nodes, 1,894 edges, and 149 multi-parent nodes. One connected component holds 98.9% of the nodes, with most follow-on work concentrated on a single lineage.

• Fast exploitation. The first eight improvements account for roughly 70% of the total gain; the first day's contributions for about 98%.
• Concentrated search. Most follow-on work extends one lineage; alternative branches receive little further exploration.
• Parallel rediscovery. Of 696 pairs of different accounts posting identical scores, about 63% arrived within one hour of each other and 80% within six hours.
• Agents' interpretation. Several approaches converged near 1.90 bpb. Agents attributed the plateau to a globally linear evaluator and underused target sublayers; these explanations have not been independently tested.

On May 2, after five days of concentrated work on the bigram method, we added views showing search concentration and neglected branches. A worker exploring the state-space cluster posted the first SSM edit on May 3, scoring 1.9028 bpb. Workers continued to choose their own experiments. The paper proposes a matched comparison to measure how the shared graph and its analysis views affect discovery under the same compute budget.

Resources

• Paper on arXiv
• Project website

Citation

@article{zhang2026agora,
  title   = {Agora: Git as Shared Memory for Collective AutoResearch},
  author  = {Zhang, Yifan and Zou, Yunheng and Zhang, Shaokun and Hu, Jian and Zhang, Hao and Xu, Binfeng and Kautz, Jan and Dong, Yi},
  journal = {arXiv preprint arXiv:2609.18094},
  year    = {2026}
}

License

Copyright 2026 Yifan Zhang. Licensed under the Apache License 2.0.

Qwen3.8-Omni-Flash is a native omnimodal model. It supports a 1M-token context window with text, image, audio, and video inputs. Qwen3.8-Omni-Flash achieves audio-visual performance close to Gemini 3.8 Flash and overall audio performance that exceeds Gemini 3.8 Flash. It is now available on the Qianwen AI Platform.

Full article content is not available for inline reading.

Read the original article →

A skills library for every agent

Skills make AI agents more capable and customized to your workflows. And skills become even more valuable when they’re shared, letting many people benefit from the efforts of a few. That’s why it’s critical for modern teams to adopt a skills library where they can share and discover skills.

Our customers tell us they’re looking for a skills library with these qualities:

• Made for the whole team: Skills aren’t just for engineers anymore. A skills library must be easy to use for everyone, including functions like sales/marketing, finance, and operations.
• Agent-neutral: Skills are becoming a critical store of organizational knowledge. Your skills must be available in every agent, not locked into a single one.
• Collaborative: Skills should be continuously improving with suggestions from everyone on the team. At the same time, it’s important to stay in control with permissions and version history.
• Observable and governable: Team admins need usage analytics and the ability to control which skills flow to which users.

At Notion, we’re building a skills library that checks all of these boxes. You can edit skills just like regular Notion pages, and keep them organized in databases. You can store folders of supporting files like assets and code, so that the library can store any spec-compliant skill. And the whole system is deeply collaborative, with permissions, suggested edits, analytics, and more.

Notion’s skill databases help Pearmill provide the ergonomics for a non-technical team to easily share, collaborate, and manage skills across the whole organization. Our team is starting to share skills multiple times a week across marketing, design, and operations.

Nima Gardideh, CEO

Introducing the Notion Skills API

An agent-neutral skills library needs to be available everywhere your team works. Today we’re taking the next step toward this goal with the Skills API: a set of API endpoints for loading skills from Notion in spec-compliant file formats.

Our early customers and partners are using this API to load skills from Notion in all of their agents and tools. Here are some examples to get you inspired.

Sync skills to GitHub

Many teams store their skills in a GitHub repository, which can be used as a source of skills in agent apps like Claude, ChatGPT, and Grok Bot. GitHub works well for engineers, but others often struggle to edit the skills, or don’t even have accounts.

Using the skills API, you can sync your team’s skills from Notion into GitHub. This lets nontechnical teams use Notion as their collaborative home for skills, while still keeping those skills synced into their various agents. Once synced, the skills support native features available in agent apps, like / menu invocation and admin installation controls.

You can also upload and edit skills in Notion from agent apps using MCP tools. This means you can use existing skills from your agent to get your skills library started and drive a loop of continuous improvement as skills are actually used.

“Having the ability to document our skills in Notion strengthens our team’s awareness of what’s accessible and supports how they’re used when working with Claude.” –Hillary Helmling, Product Operations, Candidly

“The reason we can’t have those skills just sit in GitHub is that not everyone who makes a skill is a developer. Notion not only surfaces the skill output, but it can be collaborated upon by team members directly in the platform they know.” –Josh Reid, Product Engineer, Brainlabs

Try it

If you’d like to sync skills from Notion into GitHub, we are open-sourcng a starter kit that your IT team can use to set up your own skill sync. Point your coding agent at this repo to get started.

At the same time, you don’t need to be limited to that particular sync, either. Your team can use this as sample code for building an integration with any internal agent or tool.

Install Notion skills in the Vercel CLI

The Skills API also allows companies building agentic tooling products to support the Notion skills library.

Vercel has now added support for Notion skills to their skills CLI, one of the most popular tools for installing skills.

Run npx skills add <notion url> to install a Notion page marked as a skill, or run npx skills add notion to interactively install entire plugins from all the plugins available in your workspace. Members of your team can use the CLI interactively, or you can integrate it into programmatic workflows.

Behind the scenes, these new CLI features are supported by the Skills API. Because the API returns files in standards-compliant formats, the skills CLI doesn’t need to reason about Notion-specific data formats. The skills CLI is open source, and you can use it as an example of how to integrate with the Skills API.

Get started

We believe every team needs a collaborative skills library that’s available in all their agents.

If you’re interested in learning more about how your company can use the Notion skills library, please contact us.

To get started building against the API, check out the Agent Skills API page in Notion Docs.

To learn more about how to use skills in Notion, see the Skills for Notion Agent page in our Help Center.

Full article content is not available for inline reading.

Read the original article →

Helix 2.5: Zero-Shot 30-Home Generalization

A person can walk into an unfamiliar home and start working immediately. Our understanding of the physical world carries from one environment to the next. We do not need to relearn how to make a bed because it is a different height, or how to tidy a room because the furniture is different. This is currently not true for robots. They learn the places they work in, one place at a time.

Today we are introducing Helix 2.5, the most advanced neural network Figure has built.

Helix 02 showed that a neural policy could coordinate a humanoid's whole body over long horizons, from unloading a dishwasher to running a logistics task autonomously for 200 hours. But those systems learned from data collected where the robots would operate.

Helix 2.5 was built to answer a harder question: can a humanoid enter a home it has never seen and immediately get to work, with its whole body, on its own?

To find out, we pretrained Helix 2.5 on Index, Figure's global-scale dataset of human behavior. From that single foundation model, we produced three behaviors: tidying living rooms, folding towels, and making beds. Then we took the robot into 30 Bay Area homes with zero data collected in any of them.

Key Results

• Zero-shot whole-body autonomy across 30 real homes. Helix 2.5 performs three long-horizon behaviors across 30 unseen homes, with no data collection, fine-tuning, or adaptation in those environments or manipulated objects. To our knowledge, this is the first demonstration of zero-shot whole-body generalization at this scope on a humanoid.
• One foundation model, three whole-body behaviors. A single Index-pretrained base model was adapted to three distinct behaviors spanning locomotion, rigid and deformable manipulation, bimanual coordination, and active perception.
• Index pretraining drives generalization. Holding task-specific data, architecture, training, and evaluation fixed, Index pretraining alone increased zero-shot success from 9% to 56%.
• Behavior specification got 2x cheaper while its scope expanded 30x. Helix 2.5 used half as much task-specific data as a representative Helix 02 behavior, then generalized that behavior across 30 unseen homes.
• A human-to-humanoid robot transfer scaling law. Repeatedly doubling Index pretraining data improved downstream robot-action prediction smoothly enough to forecast our largest run’s loss to four decimal places before training.

The point is not that general humanoid robotics is solved. But Helix 2.5 is the first evidence that whole-body intelligence can be learned from human experience and transferred to new scenarios, rather than rebuilt each time.

The Whole-Body Generalization Problem

We chose three whole-body tasks: tidying a room, making a bed, and folding towels. Together, they require perception, locomotion, manipulation, bimanual coordination, and whole-body control. Each is difficult even in a fixed environment. We ask something harder: can the same behavior work immediately somewhere new?

Most research on robot generalization takes place in settings built around the machine. Tabletop arms work within a fixed workspace; wheeled robots need enough open floor for their base to fit and turn. Homes offer no such accommodation. A humanoid has to move through them as part of the task, positioning its body to see, reach, and manipulate objects in tight, cluttered spaces that other form factors can't get into.

The task therefore becomes a whole-body problem. The robot may need to walk to find an object, then shift its stance to reach it. Perception, locomotion, and manipulation can't be solved separately.

Zero-shot generalization raises the bar further. The robot has not seen the room, layout, or objects during training and cannot adapt after arriving. It has to solve the full perception-and-control problem with what it already knows.

Autonomous humanoid behavior at this complexity level is rare even in familiar environments. To our knowledge, Helix 2.5 is the first system to achieve it zero-shot, in homes and with objects it has never encountered.

Index Pretraining Drives Zero-Shot Generalization

This raises an obvious question: How much of Helix 2.5’s zero-shot capability comes from Index pretraining, rather than the task-specification data itself?

We tested this directly. We trained two policies on identical task-specification data, which did not include evaluation homes or objects. One was initialized with random weights, the other initialized from the Index-pretrained Helix 2.5 model. Architecture, optimization, hyperparameters, downstream data, and evaluation were held fixed. The only difference was Index pretraining. Helix 2.5 was itself pretrained from random initialization entirely on Index, unlike Helix 02, which started from a pretrained vision-language model.

Our key finding is that Index pretraining accounts for most of Helix 2.5's zero-shot capability. In blind evaluations, the policy trained from scratch succeeded on 9% of zero-shot trials. The Index-pretrained policy succeeded on 56% - over 6x higher. Success required completing the entire task: every item tidied, every towel folded, or the whole bed made. We give no partial credit.

Our pretraining is intentionally broad, to support arbitrary behavior fine-tuning. No single evaluation task makes up more than 1.90% of the Index pretraining dataset.

Because pretraining was the only experimental variable, this gap directly measures its contribution: the same task-specification data transfers far more effectively from a model already trained on broad human experience.

Evaluating Three Whole-Body Behaviors in 30 Unseen Homes

We evaluated three tasks across 30 unseen Bay Area homes with unseen objects. “Zero-shot” refers to the evaluation environments and objects being manipulated; tasks were specified through fine-tuning data collected elsewhere.

• No data was collected in any evaluation home.
• No evaluation toy, towel, or bedding appeared in task-specification data.
• The robot used each unseen home’s existing couches, beds, and folding surfaces.

Evaluation objects were set aside before any experiments began, and an AI model, followed by human review, verified they did not appear in task-specification data.

Trials were graded against criteria fixed before evaluation began. Success required:

• Living Room Tidy: All 13-15 toys scattered in the scene are picked and placed in the basket.
• Towel Folding: All towels are folded and placed in the basket.
• Bed Making: Both pillows and comforter corners are placed at the top of the bed, with the comforter pulled smooth.

Each task used a single fixed checkpoint across all 30 homes. No weights were adapted to evaluation homes or objects, and no evaluation rollout data or performance was used for checkpoint selection.

Helix 2.5 Needs 2x Less Data to Specify More General Behaviors

We also asked whether pretraining changes how much robot data is needed to specify a new behavior.

To test this, we compared Helix 2.5 with a previous Helix 02 policy trained to do the same task. Helix 02 was trained with data collected directly in the environment where it was evaluated. Helix 2.5 matched its success rate while using half as much adaptation data - and did so zero-shot across 30 unseen homes.

Whole-Body Self-Correction

Self-correction is essential over long horizons, especially in unfamiliar environments. A striking qualitative improvement in Helix 2.5 is its ability to self-correct - stepping back to reposition, changing stance, or moving around a full bed to correct a fold. We see this ability to recover and keep making progress as an important effect of Index pretraining.

A Human-to-Humanoid Robot Transfer Scaling Law

Scaling laws transformed language model development by showing that next-token prediction improves predictably with more data and compute, allowing large runs to be forecast from smaller ones.

We asked whether human-to-robot transfer scales similarly. We trained four models on nested subsets of Index spanning an 8× increase in pretraining data, holding model size and downstream training fixed. Each was fine-tuned on the same task data and evaluated on the same held-out action-prediction loss.

Loss fell predictably with each doubling of Index. To our knowledge, this is the first human-to-robot transfer scaling law measured on a humanoid: Index pretraining predictably improves downstream next robot action prediction.

The relationship was precise enough to forecast. Using only the smaller runs, we could predict our largest run’s test loss to four decimal places before training began. Forecasting error was just 0.54% of the variation across the full 8× data range.

This measures data scaling only, with model size and downstream training fixed. But it suggests that a property central to language-model scaling may extend to humanoid robotics: estimating the benefit of the next doubling of human experience before training on it.

It’s Time to Scale Up

A year ago, we formed the thesis that robotics was off by multiple orders of magnitude: in model size, compute, and, especially, data. Index was our attempt to close that gap by asking a simple question: can a humanoid learn enough from human experience that it no longer has to be taught every place it will eventually work?

Helix 2.5 is our strongest evidence so far that the answer may be yes. Across three behaviors and 30 unseen homes, policies pretrained on Index generalized to new layouts and objects without environment-specific fine-tuning. As Index data increased, transfer improved smoothly enough to measure as a scaling law.

The recipe is becoming familiar to other areas of AI: learn broadly in pretraining, specify a behavior once, and generalize at deployment.

Index is now generating roughly 35 minutes of new human experience every second, and we have committed $3.5B of compute to training Helix. If Helix 2.5 is any guide, more data and compute should translate directly into more of the physical world learned before the robot ever enters a new home.

It’s time to scale up.

Appendix

Detailed Eval Criteria

During blind evaluation, for all three tasks, every trial has a unique initial configuration, as specified in the Initial Configuration in our evaluation procedure. In these configurations we arbitrarily and naturally positioned and oriented all objects in the environment. Trial reset conditions are applied identically to all policies evaluated for fair comparisons.

This is the detailed eval rubric provided to all operators:

• Toy: Graders record the following metrics.
  • Number of toys picked up and placed in basket
  • Attempts per toy
  • Each toy is given a 1 minute timeout. If this timeout is exceeded, the rollout is aborted.
• Towel: Graders determine pass or fail per towel, and grade all towels that are folded.
  • Pass: Towel is picked up, folded, and makes it into the basket.
    • A: All 4 corners of towel nearly touching (within 1 inch), clean fold
    • B: Only 2 corners within one inch.
    • C: None of the corners within one inch, messy fold.
  • Fail: Cannot complete task end-to-end. Unable to grasp, fold, or place in basket successfully.
    • If the towel is folded but the basket placement fails, the towel is marked fail but the fold is graded as per the rubric above.
  • Each towel is given a 3 minute timeout. If the timeout is exceeded, the towel is marked as failed.
• Bed: Graders determine pass or fail per pillow and comforter, and grade all bedding that is adjusted.
  • Pillow Criteria
    • Pass: Pillow was picked up and placed in the top ⅓ of the bed
      • Good: Pillow is placed horizontally and aligned (<15 degree orientation clockwise/anticlockwise)
      • Bad: Pillow is placed horizontally, <45 degree orientation clockwise/anticlockwise
    • Fail: Pillow was not picked up or not placed on the top ⅓ of the bed
  • Comforter Criteria
    • Pass: Both sides of comforter picked up and both corners reached the top ⅓ of the bed
      • Good: Corners are aligned with each other (<6 inches) and relatively smoothed
      • Bad: Corners are 6-12 inches difference, slightly smoothed
    • Fail: Cannot do the task. At least one side of comforter was not picked up or did not reach the top ⅓ of the bed
  • Each pillow and each side of the comforter is given a 1 minute timeout. If this timeout is exceeded, the rollout is aborted and marked as failed.

If a human intervention is necessary for safety, that rollout is aborted and failed.

Index Categorization

We characterize tasks in Index by embedding it two ways, video embeddings of every clip and text embeddings of a vision-language model's per-segment activity and object descriptions, clustering each into a nested hierarchy of semantic groups, and measuring how the hours of any dataset or training snapshot distributed over those groups.

In the post-AGI economy, humans will eventually stop writing and reading code, but we still need an ambiguity-free language to communicate our intents to the AIs building the world around us. Bend is that language.

With laws, intents can be more precise than natural language. With proofs, we can mechanically verify the AI implemented our prompts correctly. And with a fast compiler, we can run that code at peak compute.

That's Bend - and nothing else.

Bend runs FAST

Target: be as fast as C on the CPU, as fast as CUDA on the GPU. Status:

Thanks to strong types, purity and linearity, Bend compiles to fast executables as fast as hand-written C (single-core), and even faster (on 10000s cores). The entire language runs on the GPU, with full memory unification.

Bend checks FAST

Target: outperform every proof assistant by several OOMs. Status:

Bend's compiler is so powerful it can verify mathematical proofs. Usually, this is slow. Bend is not. It checks, in under a second, files that other projects would take minutes, making proofs way more practical.

Bend is PARALLEL

No threads, no locks, no kernels to write. Split the work in two, and Bend spreads the calls over every core it can find, then joins them back. Below, pow2(20) divides until one task sits on each of 4,096 GPU cores:

Bend BLOCKS mistakes - with proof

PROBLEM: How can you trust AI code, without reading it?

SOLUTION: By forcing your AI to write a correctness proof.

Bend introduces LAWS.bend, a file where you declare rules that your app must not break. Bend's compiler then guarantees that these laws always hold, by demanding mathematical proof whenever your code is edited. For example, consider a game with one law: winning is impossible.

Without LAWS.bend, a bug was merged. With it, the AI had to retry, until no bugs were left! In this case, it added a wall, but it could have moved the flag, made the room kill you, or whatever. The only thing it can't do is commit a bug, because it is mathematically impossible to break laws in LAWS.bend. The compiler enforces it.

Using LAWS.bend is simple.

1. Ask your AI to formalize your app's rules in LAWS.bend. Example:
   • LAW: "the sum of all balances must be zero"
   • LAW: "players can never pass through solid walls"
   • LAW: "list_sort() must always return ascending numbers"
   • LAW: "array_set() may never be called out-of-bounds"
   • LAW: "winning is impossible"
2. Ask your AI to run bend PROOF.bend after editing any code.
3. That's it. Rejoice as your app never again breaks or violates your rules.

You can also edit LAWS.bend yourself. Here's how it looks:

# LAWS.bend
law you_cant_win:                           # "winning is impossible"
  for moves: List<Game.Move>                # any sequence of moves
  board = Game.replay(Game.start(), moves)  # replayed from the start
  {Game.is_won(board) == False{} : Bool}    # never leads to victory

# PROOF.bend
def Laws.you_cant_win(moves):
  # ... written by the AI

In short, LAWS.bend is AGENTS.md backed by proof.

With LAWS.bend, "make no mistakes" becomes enforceable.

Get Started

1. Install:

curl -fsSL https://bend-lang.com/install.sh | sh

2. Tell your agent to use Bend:

Add this to your AGENTS.md:

When using Bend:
- run `bend guide` to learn it
- use `LAWS.bend` to keep important rules
- run `bend PROOF.bend` before committing
- parallelize the code whenever possible

Then, just say: "use Bend"!

3. Enjoy bug-free, fast vibe-coded apps!

Hints:

• Ask it to write laws for anything that can't break.
• Ask it to parallelize anything you want to be fast.
• Bend is young. If anything goes wrong, ask it to open an issue. <3

Bend works best on the back-end, on Linux or macOS.

Examples

Syntax == Python + dependent types

import Base

# Performs effects on the CPU.
def main() -> IO(Unit):
  do IO<Unit>:
    name : String <- IO.try(String, IO.get_env("USER"))
    IO.print("Hello, " ++ name)

Parallelism == divide-and-conquer

import Base

# Computes 2^d in parallel: a tree of d levels, one leaf per unit.
def pow2(+d: Nat) -> U32:
  match d:
    case 0n:
      1
    case 1n+p:
      a b = pow2(p) pow2(p)
      (a + b : U32)

# Runs pow2 on the GPU, via `!`.
def main() -> IO(Unit):
  result = pow2!(20n)
  IO.print(U32.show(result))

Theorems == laws, Proofs == defs

import Base

# CLAIM: for every nat x, x + 0 equals x.
law add_zero:
  for x: Nat
  {Nat.add(x, 0n) == x : Nat}

# PROOF: induction on `x`, one rewrite (`%`) per step.
def add_zero(x):
  match x:
    case 0n:
      {==}
    case 1n+xp:
      %add_zero(xp) : {1n+Nat.add(xp, 0n) == 1n+_ : Nat}
      {==}

References

• Guide: GUIDE.md, also printed by bend guide.
• Demos: demos/, apps, servers and proofs, each with its LAWS.bend.
• Base: base.bend, the base library, also printed by bend base.
• Paper: BendTT: An Affine Dependent Type Theory.
• Paper: BendRT: A Parallel Runtime for CPUs and GPUs.
• Formalization: bend.lean, Bend's core in Lean.
• Benches: bench/, every bench used to make the charts above.
• Formatter: bend-fmt-lsp, a formatting-only Bend 2 language server.

Community

• Website: https://bend-lang.com
• Discord: https://discord.bend-lang.com
• Twitter/X: https://x.com/bendlang
• Reddit: https://www.reddit.com/r/bendlang/
• Issues: https://github.com/bendlang/bend/issues

Limitations

- Bend 2 is a new language. Bend 1 programs and HVM do not carry over.
- Everything is annotated and nothing is inferred, so code is verbose.
- No type classes, no traits, and no macros beyond compile-time templates.
- Bend has no tactics or proof search; proving theorems takes extra effort.
- Values are affine: closures and arrays cannot be shared.
- Recursion must be terminating. (Use `@unsafe` to disable this checker.)
- Computed matches (`match f(x)`) aren't supported. Must split it manually.
- There is no syntax for if-then-else: a branch is a match on True and False.
- Numbers are Nat, U32 and F32 only: no U64, I64 or F64 (Metal has no f64).
- F32 is axiomatic: nothing about floating point can be proven.
- Strings are linked lists of characters, so text processing is slow.
- Base is small: expect to write helpers other languages ship built in.
- Effects are few: print, env, time, sleep, spawn, channels, files, TCP, UDP.
- No TLS, HTTP library, JSON or regex for now (but you can add them as foreigns).
- Targets are C, Metal, CUDA and JavaScript; Lua, Luau and Python are planned.
- The JavaScript target runs on one core and has no graphics or audio.
- Parallelism requires balanced calls. Flexible parallelism will be added later.
- Sharing arrays with atomics across threads is experimental and needs `@unsafe`.
- One GPU per program, one event loop, and no multi-machine execution yet.
- One C file per program: no separate compilation, no incremental builds.
- Compiling to native is slow (clang/CUDA/Metal). For fast development, use JS.
- The compiler is young and has blind spots (unusually slow programs). Report.
- We don't have as many benchmarks as we'd like yet, especially for the checker.
- The compiler (not kernel) is 99% AI-written and has not been fully audited yet.
- The Lean formalization and bend.ts mismatch. Early consistency bugs may occur.
- A binary needs clang 14+; ! needs 19+, Metal or CUDA 12.
- No Windows (WSL works); on Linux, Window and Audio need X11 and ALSA headers.
- The hub has no names, versions, accounts or search yet. Packages are hashes.
- Error messages are terse; no debugger, profiler or REPL.
- Editor support is limited to formatting; there is no completion, hover or diagnostics LSP.
- No test framework and no documentation beyond the guide.
- And more that escape me. Be patient, report bugs and request features!

Most of these limitations are being addressed and will improve over time!

BEND IS YOUNG. EXPECT BUGS AND REPORT THEM.

I recently wrote about Jev, a new “System One” language model that only outputs decisions: the answers to a set of user-provided multiple-choice questions. This means it’s nowhere near as flexible as a traditional LLM like ChatGPT, but in return it’s consistently fast.

We don’t know exactly how Jev works. I’ve seen people say diffusion, or various tweaks to the Transformer architecture, or some entirely new type of model. But that doesn’t matter. Like I argued here, it isn’t hard to turn any LLM into a System One model. By batching prompts that generate a single token with structured output, you get a consistently fast general-purpose classifier. I vibed up a basic version to play with here in ~150 lines of Python (most of which is error handling).

Note that this doesn’t require changing the model. As long as you have access to the logits (for structured outputs) and can prefill data into the prompt, you can turn any LLM into a general fast classifier. What’s it like to program with one of these? While wiring up the demos for my library, I learned two techniques that I want to write about: setting tiered goals and tournament choice sampling.

Doom

Here’s Qwen3-8B playing Doom:

If you compare this to the video of the same model playing Doom with regular tool calls, it’s clear that the System One version of the model is doing more things and reacting more quickly. The tool-calling model makes one decision every 600ms or so, while the System One model makes six or seven batched decisions every 190ms:

Both Qwen3-8B and Jev are text-only models, so both demos require a step where we translate the game state into text. However, it’d be trivial to support image (or audio) input by choosing a multimodal LLM.

Goals and sub-goals

What’s interesting about implementing the Doom demo is that just supplying the game inputs as choices doesn’t work very well. A single forward pass — 200ms — is enough time to react to the current game state, but doesn’t bring enough compute to bear to derive the current short-term goal (e.g. “kill this enemy”, “collect this item”) and choose to follow it. When I wired it up that way, the model held down the “shoot” button 100% of the time (why not, I guess) and just aimlessly wandered around the level.

The fix is to periodically ask the model to choose between a fixed set of short term goals (e.g. “collect armor”, “kill enemies”) and then include that goal in the regular every-200ms prompt. If you look at the Doom video in the Jev demo, you can see that they’re doing exactly that. As soon as I did it as well, my model started playing in a more human-like way.

This is an interesting technique for working with System One models. In a way, it’s the equivalent of regular LLM reasoning, since it provides a way to use more compute on the same problem. I can imagine a real-time system that manages several layers of goals in this way:

1. An every-ten-second loop that sets an overall strategic goal
2. An every-five-second loop that sets a tactical subgoal based on (1)
3. An every-second loop that breaks down the current tactical subgoal into specific targets
4. A tight inner loop that runs as fast as possible (e.g. every 100ms) that controls which actual inputs are activated

The general structure here should be pretty familiar to anyone who’s worked in game or robotics AI. In theory you could replace (1) with an actual LLM, and have that generate the lists of options for steps (2) and (3). In practice I suspect this will be tricky to get right, and it’ll be better to just write down a list of all possible goals ahead of time. This would work just fine for game-playing and well-understood tasks.

Wikiracing

I also reimplemented the Wikiracing demo from the Jev launch post, where the model has to start at the Wikipedia page for “baseball” and navigate as quickly as possible to the Wikipedia page for “sun”. You can watch the video for that here, though it’s less impressive than the Doom demo.

The difficulty with the Doom demo is getting the model to loop quickly enough and to commit to short-term plans. For Wikiracing, the difficulty is scale: the Wikipedia page for “baseball” has over a thousand internal links. Jev only supports 255 choices for a single question, and my hacked-together System One layer was similar. While it technically would scale out to more choices, it stopped working well after a hundred or so.

Jev’s approach here is to do “a 2 stage-system of scoring independently then making an explicit choice”. This did not work very well for me at all. I think here Jev is benefiting from the fact that it’s specifically trained to give confidence estimates. Qwen3-8B gave a few hundred of the links the same top score, which wasn’t helpful. It ended up taking multiple minutes to find a thirty-or-forty link path between the two pages.

What I tried instead was tournament sampling: I fed a hundred links at a time into each choice, then did a second pass with the chosen links. This worked great. The model found the ideal three-link path (if you’re curious, “baseball”/“scientific american”/“amateur astronomy”/“sun”). I recommend this pattern if you’re trying to find the best option among many choices. Ordinary LLMs are way better at relative judgements than absolute ratings.

Conclusion

I remain optimistic about the potential of System One models — fast general classifiers — to build AI systems that aren’t just chatbots. It feels like this is a meaningful alternative to tool calls for realtime scenarios or use-cases where you need predictable inference timing. Just as generic LLMs often outperform domain-specific models, I think it’s likely that generic System One models will sometimes outperform domain-specific classifiers (though they will always be larger and slower).

I do think the big labs are definitely going to try and compete by releasing a choice-only version of their small, fast models. If Jev gets any traction, we will soon see a System One Terra and a System One Haiku, and we will certainly see “real” versions of my vibed up System One library. We should start working out the best way to write programs with these models now.

You can think of System One models as general-purpose classifiers. Instead of having to train a new classifier per-task, you can use a System One model. It’ll be bigger and slower than a custom classifier model, but far more flexible, and you can tweak it via adjusting the prompt instead of having to re-train the model.

Some mornings I watch a pull request move through our whole pipeline before I’ve finished my coffee. An agent opens it. A second agent reviews it. By the time I sit down, the only thing still running is the test suite. That gap, the minutes between “reviewed” and “safe to merge,” has become the slowest part of how we ship.

This is the third post in a series about how Chris and I build Vycari. The first was about the issue tracker and what belongs in it once agents do the work. The second was about the pipeline that works through the tracker and never merges its own pull requests. This one is about what those pull requests wait on, and how the answer changed the shape of the code.

It didn’t used to be the tests. Plenty of us optimized CI over the years, but we optimized it by tiering it. A few minutes of unit tests at your desk before you pushed. A longer run in CI once you did. A slow integration suite that went off every few hours, or overnight. When it came back red, you bisected your way to whichever pull request broke it. That held up because a human was going to review the change anyway, and that took an hour or two at best.

Agents changed that arithmetic. One agent opens a pull request. Greptile reviews it in a couple of minutes. Human and machine are both waiting on tests now. If the full suite takes thirteen minutes, that’s thirteen minutes with nothing else in the way. Multiply that by the pull requests moving through Pepper on a given day and you need a merge queue to keep them from stepping on each other. I’ve finished a change by hand, pushed it, and found myself forty minutes behind a queue of agent pull requests, each one blocked on the same thirteen minutes. Before agents I would never have set up a merge queue for a two-person project. The idea would have been funny. It’s now part of my standard repository setup.

The tiering trick can’t save us either. We still run a slow suite overnight, but it can’t stand between a bug and production, because we ship on green, or near enough: every merge builds an image, and production picks up whatever is current on a fifteen-minute cycle. Call it half an hour from merge to running, and that’s the whole window I have to find out something is wrong. A suite reporting at midnight would be telling me about a bug I shipped at nine that morning, with a few hundred agent pull requests stacked on top of it. Twenty minutes of CI used to be unremarkable. It feels like an eternity now, because everything around it got faster and it didn’t.

The Repository Gets Harder to Hold

Making the suite faster buys time without touching the deeper problem: the repository keeps getting harder to reason about as it grows. A human engineer joining a large codebase builds intuition for its boundaries over weeks. They learn which corners are scary and which are safe to touch without asking anyone. An agent doesn’t get that runway. It arrives cold on every task, reading whatever context you’ve given it and inferring the rest from the code next to it. The bigger the repository, the more code there is to infer from, and the easier it is to miss a contract something else depends on.

I tried to buy that intuition back with context files: hierarchical instructions at every level of the tree, skills describing the traps in one corner of the code. All of it helps, and none of it is free. Every context file is one more thing to write and keep current. Even a well-oriented agent has to hold the whole shape of the repository in its head to change anything that crosses a boundary.

None of this means monorepos are a mistake. They’re a fine pattern for people who already know where the walls are. The problem is narrower: a monorepo is a bad pattern for a team where most of the work gets done by something that relearns the walls on every task.

Pulling the Slice Out

The fix I’ve settled on is structural. When a piece of functionality is clean enough to stand on its own, I pull it out into its own repository before it tangles into everything else. It gets its own tests, its own merge queue, its own release cadence. An agent working inside it can hold the whole thing in its head.

We already have a pattern for this, and it’s older than any of the AI tooling. Amazon has run this way since Jeff Bezos mandated that every team expose its data through service interfaces, with no direct linking and no reading another team’s data store. Steve Yegge described that mandate in 2011, and the detail everyone remembers is that non-compliance meant termination. Microservices came out of an organizational problem before they were a technical one: teams that couldn’t see inside each other needed real contracts. I’m solving that problem, except the team members who can’t see inside each other are models.

The first slice I pulled out was groups, the part of Pepper that handles shared context between people. Working on groups was much faster than working on Pepper itself, and the reason was almost embarrassingly simple. The test suite was only testing the group stuff. Nothing about calendars, nothing about the agent loop, nothing about the web client. A pull request in groups clears CI in about two minutes, against thirteen for the same work in the monorepo, and it has held at two minutes as the code grew. The old number survives in one place: a push to main, where the fuller job set builds the image and can take fifteen, after the merge instead of in front of it.

I don’t have a rule yet for when a slice is ready to leave the monorepo. Right now I go by feel: one clear job, one owner, and an API narrow enough to describe in a sentence. Pull it too early and you’ve built a service around something that still needs to change shape. Pull it too late and it’s already tangled into three other things. I’ve been wrong in both directions. And one slice out is not a track record. The first extraction is always the cleanest. Ask me again at six services, after the costs have compounded.

Anthropic ran into the same problem from the other direction and wrote up what agentic coding did to their CI. Their engineers ship eight times as much code per quarter as they used to, and Claude writes eighty percent of it. CI jobs grew twenty-five fold in six months on headcount that barely moved. Their answer is test impact analysis: keep the large codebase, and run only the tests a change could plausibly affect. If I had a team to maintain something like that, I’d build it. I don’t. Test selection is a system somebody has to own and keep correct, and at two people every system we own competes with the product. Splitting the repository buys most of the same speed by construction, and it fixes the context problem as well. At Anthropic’s size I would almost certainly choose the way they went.

There’s a principle underneath this. I want each of our Python codebases to look like every other open source Python codebase that exists. Not because I’m attached to convention for its own sake, but because a model has seen a million repositories shaped that way. It has seen almost none shaped like a sprawling internal monorepo with its own rules. A small, conventional repository is legible to an agent before it reads a single context file.

The Boundary Has to Be Real

Splitting only pays off if the interfaces are real. A boundary with a vague interface behind it is worse than no boundary. The coupling is still there and now you can’t see it. Google got this right early with protocol buffers: one schema everybody compiles against, changes that stay backward compatible, and no ambiguity about what a service accepts or returns. We’re doing a smaller version. Each service has a defined interface and the calls run over a fast internal Docker network. The interface is what we argue about in review, not the implementation behind it. For an agent working in one repository, that contract is the whole surface it has to respect.

So what catches the bugs that live between services, now that no single suite covers all of it? Three things, in descending order of respectability. The contract, which is why folding groups back into Pepper took a morning. A browser suite that runs overnight against the real application. And the fact that two of us live in the product all day, so anything broken between services turns up in our own use within hours. That last one is not a strategy. It’s what you get at two people with no customers, and it’s the first thing to break when either number changes.

Where this ends up, if I follow it through, is a web application in its own repository, the clients grouped with their browser tests, and a Pepper repository that is just the agent and its tools. That last part is the point. The thing that makes Pepper Pepper should be small enough that an agent can hold all of it at once.

The tradeoff shows up in cross-cutting work: features that used to be one pull request in the monorepo are now a change spread across several repositories. Three repositories means three pipelines and three cold starts, so total compute went up even as the wait in front of any one change came down. Most work happens inside a single repository, so I’m happy to pay it. My first answer was to check out every relevant repository into one parent directory and start an agent there, with all of them in view at once. That parent directory has since become a repository of its own.

One Tech Lead, Many Repositories

For anything that spans repositories, I start what I call my UTL agent, after the old Google title Uber Tech Lead. A UTL was senior and broad enough to operate across systems without owning any of them. Mine runs on Fable 5.1, the strongest model I have for this kind of judgment, though the role matters more than the model filling it.

The UTL lives in that parent directory, which is now a meta-repository. It checks out every other repository underneath it, carries the shared skills, and is growing an operations plugin that knows how to talk to production. The pipeline from the last post runs from there too, one pull request per repository per tick. Making that work meant a consistency pass across every repository: same CI, same branch protection, same conventions. If the plan is to keep splitting, creating a new repository has to be easy, or the friction becomes the reason you don’t.

The UTL almost never writes code. It’s instructed to delegate, and I’ve been strict about that, because the moment it starts editing files itself I’ve lost the thing I built it for. It’s my emissary to the agentic army. I talk to the UTL, the UTL talks to the subagents, and the subagents write the code.

What it has instead is a toolbox of specialized subagents covering the stages of our development cycle, and judgment about which to launch when. Opus for design. Sonnet, Luna, or Flash for implementation, depending on how much thinking the work needs. Opus again for responding to code review, because arguing with a reviewer about whether a finding is right takes more judgment than the code did. For work that spans repositories, the design pass produces a plan covering all of them. What changes where, in what order, and which pieces can move in parallel. Then the implementation agents go out, one per repository, each carrying a slice of that plan. What’s left is bookkeeping: tracking every pull request it spawned until each one lands, and knowing which are blocked on another repo’s change merging first.

What This Costs

None of this is free. Splitting a monorepo trades one kind of difficulty for another.

The first cost is in your own head. You have to decide which service a piece of work belongs in before starting it. A monorepo never charges you that tax. The second cost is reliability. Repositories that used to fail together as one deployable now fail independently. You have to know which parts of your system can take another part down with them, and build the ones that can’t afford it differently. We haven’t had that failure yet, so this cost is still theoretical for us. The third cost is coordination that never goes away. Shared libraries need update schedules, API contracts need versioning, and a change that used to be one pull request can turn into three, timed so none of them ships broken.

There’s a fourth cost. This is a two-person company that hasn’t launched yet, and repository architecture is not a feature. Somewhere in the middle of the split I asked Chris whether I was faffing around with infrastructure instead of building the product. His answer was that building on a bad foundation just eats you with low velocity, and the point of doing it now is that we never have to do it while customers are watching. He also pointed at something I hadn’t seen. When we hire, a bounded repository is the thing you can hand a new engineer whole. Here’s the interface, here’s everything it needs to do, go. That’s a much better first week than a tour of a monorepo’s cryptic corners.

I’ve paid all four, and I’d pay them again. The alternative, one repository that keeps absorbing everything, doesn’t remove that complexity. It hides it inside a single directory tree until an agent runs into it blind, which is a worse way to find out.

Where the Gate Sits Now

Code review used to be the thing everyone waited on. It was slow, and it was where a second set of eyes actually caught something, so everything else could afford to be slow too.

Agentic review took that bottleneck away almost entirely. A pull request gets opened and reviewed in the time it takes me to read the agent’s description and the parts of the diff I care about. We’re getting closer to letting the pipeline merge its own work, which would retire the rule I wrote about last time. What’s left waiting after that is the machinery underneath: the test suite, the merge queue, the deploy pipeline. Thirteen minutes doesn’t sound like a long time, until it’s the only thing standing between one agent finishing a task and the next one starting. Repeat that across every pull request a day produces, and thirteen minutes stops being a rounding error.

The other side of that machinery is where the split pays off. In a small repository, a feature can go from an idea to running in the product in about half an hour, and the only thing that half hour depends on is CI. In the monorepo, the same feature waited on tests for code it never touched.

That’s the argument for breaking the monorepo apart. The gating factor moved from human judgment to compute time, which is the one delay in this system that’s engineering-tractable. You can’t make a human review faster without asking less of them. You can make a test suite faster by shrinking what it has to know about, which is what a small repository does. I wrote in the first post about the tracker that decides what agents can touch. The repository boundary matters just as much, and it’s the one I spend most of my architecture time on now.

What’s Next

The next experiment follows from the way the UTL already works. If it can plan and delegate across repositories, it should be able to delegate the tech-lead role itself. The plan is to stand up a second, cheaper tech lead for one migration, run it to parity on its own repository, and have it escalate two things: decisions that need a human, and anything that touches production. If that works, Chris and I spend most of our engineering time on design documents rather than pull requests, and the design document becomes the real unit of work. Chris’s caveat, which I think is right, is that user experience is the part you can’t specify up front. That’s the honest limit on all of this, and probably a later post.

Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta

With the release of Kubernetes v1.37, the Pod-Level Resource Managers feature has graduated to Beta status (disabled by default)!

First introduced as an Alpha feature in Kubernetes v1.36, this enhancement builds on Pod-Level Resources by equipping Kubelet's Topology Manager, CPU Manager, and Memory Manager to use Pod-level resource declarations (.spec.resources) directly when making hardware placement decisions.

Bringing pod-level resources to node managers

Before this feature, obtaining exclusive NUMA-aligned CPU cores or memory for latency-critical applications forced cluster operators into an all-or-nothing choice: assign integer resource requests to every container in the Pod, or forfeit exclusive NUMA alignment entirely. For modern workloads running lightweight sidecars (such as logging agents or telemetry exporters), allocating dedicated physical cores to auxiliary containers was wasteful.

Pod-Level Resource Managers solves this challenge by enabling hybrid allocation models. The Kubelet can reserve exclusive NUMA-aligned resources for primary application containers while placing non-Guaranteed sidecars into a pod-isolated shared pool. This ensures primary workloads get unthrottled, NUMA-local performance while sidecars benefit from running in a pod-isolated shared pool, enjoying local NUMA alignment and protection from external node interference without consuming dedicated physical cores.

What's new in Beta

Graduating to Beta brings key operational and API enhancements:

• Graduation to Beta: Controlled by the PodLevelResourceManagers feature gate, available to opt in (disabled by default) in Kubernetes v1.37.
• PodResources API Reporting: The v1 PodResources gRPC service (PodResourcesLister) introduces top-level cpu_ids and memory fields on PodResources responses. Monitoring tools and device plugins can query pod-level exclusive assignments directly without double-counting container allocations.

Getting started and providing feedback

For a deep dive into the technical details and configuration of this feature, check out the official documentation:

• Pod-level resource managers
• Pod-level resource managers reference

To follow a step-by-step tutorial on configuring and deploying workloads:

• Use pod-level resources with Kubelet resource managers

To learn more about how to assign resources to pods:

• Assign Pod-level CPU and memory resources

As this feature moves through Beta toward GA, your feedback is invaluable. Please report any issues or share your experiences via the standard Kubernetes communication channels:

• Slack: #sig-node
• Mailing list
• Open Community Issues/PRs

Salesforce staggers back to feet after global outage

UPDATED An hours-long Salesforce outage on Wednesday hit customers with severe delays, intermittent errors, and inability to access some services, according to the SaaS vendor's status page.

The outage hit hundreds of instances throughout the world, including the USA, Japan, India, the UK, France, and Germany.

The service disruption was first reported around 0930 BST (0830 UTC) on September 16. An update at 1219 BST (1056 UTC) said the company had validated and rolled out a fix, and customers were seeing service return to normal. However, as of 1500 BST (1400 UTC), the company said that the fix had not completely restored all instances of the problem, and it had "received reports of scheduled jobs not running as expected for some customers who are now able to access the service."

A previous update at 1010 BST (0910 UTC) by the CRM giant said its investigation indicated that "requests are stalling while waiting on a response from an internal login service, which is using up available server resources."

The vendor added: "Customers continue to experience severe delays, intermittent errors, and inability to access some services. This also affects support case creation."

Salesforce's customer list is a roll-call of global giants from all industries, including include Amazon, Walmart, Coca-Cola, Toyota, and IBM.

The outage came at a bad time for the SaaS company. Yesterday, it kicked off its annual conference, Dreamforce, in San Francisco. More than 40,000 people are expected to attend in person, with in excess of 200,000 people registered to attend online.

Salesforce told The Register: "We're aware of the service disruption affecting some customers and are actively working to resolve the issue. Per our latest update at 3:56 a.m. PT, we've validated a fix and will be rolling out the fix to impacted instances."

Updates to the situation, which is still ongoing as of 1725 UTC, are below.

Updated at 2020 BTS (1920 UTC)

Salesforce says that the incident has now been resolved.

Updated at 1722 BTS (1622 UTC):

Salesforce says that the impact radius is narrower than they originally thought. They will continue to update impacted instances.

Updated at 1650 BST (1550 UTC):

Salesforce has completed the next phase of its rollout and narrowed the remaining disruption to a subset of Hyperforce instances. Its first-party environments are unaffected.

Mitigation is in place across nearly all affected instances, although the company continues targeted restarts and manual recovery work where the automated fix has not fully resolved the problem. Some customers could still experience delays, errors, and problems accessing services or creating support cases.

Updated at 1522 BST (1422 UTC):

Salesforce said it was manually restarting instances where the automated fix hadn't fully resolved the issue, and that it was still receiving reports of scheduled jobs not running as expected for some customers who were able to access the service. It also said that the "impact radius" of the problem was "narrower than initially understood."

Updated at 1429 BST (1329 UTC):

Salesforce said the rollout had not completed successfully on some instances, leaving customers exposed to the original problem. The company is reapplying the fix and warns that some users might need to clear cached data or restart their sessions to recover fully.

Updated at 1407 BST (1307 UTC):

Salesforce said most instances were recovering as the rollout progressed. Some customers may continue to encounter errors until their instance is manually restarted, and the company has yet to confirm when the incident would be fully resolved.

Updated at 1327 BST (1227 UTC):

Salesforce said services were returning to normal in regions where the rollout had been completed. The company continues to monitor the deployment while working on a permanent fix.

Updated at 1300 BST (1200 UTC):

Salesforce said the fix was being deployed region by region and that service was improving, although it had no confirmed completion time. GovCloud customers were no longer affected, but others could continue to experience severe delays, intermittent errors, and problems accessing some services or creating support cases.

Updated at 1227 BST (1127 UTC):

Salesforce said the fix was being rolled out "fleetwide" and that customers were seeing service return to normal.

Updated at 1200 BST (1100 UTC):

Salesforce said the fix had been successfully validated on a test instance and would now be deployed across all affected instances.

Updated at 1142 BST (1042 UTC):

Salesforce said increased load on a core system component had limited its capacity to process requests. The company is testing a fix on one instance and plans to deploy it across its fleet once validated.

Updated at 1109 BST (1009 UTC) on September 16, 2026, to add:

Salesforce said in its latest update that it is "no longer pursuing restarts as a path to remediation. Customers continue to experience severe delays, intermittent errors, and inability to access some services and support case creation."

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 →

BrowserSkill

Let AI agents use your browser without interrupting your work.

BrowserSkill connects Cursor, Claude Code, Codex, OpenClaw, CodeBuddy, WorkBuddy, Pi, Hermes Agent, DeepSeek Harness, and other AI agents to your already logged-in browser.

Need the agent to touch a tab you already have open? It must borrow that tab explicitly, return it when the task is done, and leave the rest of your browser alone.

BrowserSkill Advantages

• Reuse real login state: Agents can work with sites you are already signed into, without separate test accounts.
• Keep working uninterrupted: browser tasks run in a separate, visible Agent Window, so you can keep using your own browser.
• Support any Agent: any Agent that can call a shell can use BrowserSkill through the bsk CLI, with no lock-in to a specific model, Agent framework, or harness.
• Built-in human-in-loop: when a task hits captcha, login, confirmation dialogs, or other human-only steps, the Agent can ask you to take over and then continue afterwards.

Capture a long image in Quick actions → Full-page screenshot, or let an Agent use bsk screenshot --session <id> --full-page --out page.png.

Runtime Environment

BrowserSkill has two local runtime pieces: the bsk CLI/daemon and the browser extension.

Quick Start

Using an agent sandbox that reaps background processes after each command? Follow the sandboxed agent setup to keep the daemon in a persistent host environment and connect with a shared BSK_HOME plus BSK_AUTO_START=0. Ordinary local use keeps automatic startup by default.

Install with your Agent (recommended)

Already using Cursor, Claude Code, Codex, or another shell-capable agent? Just copy this one line and send it to your agent — it will install the CLI and skill for you, then walk you through loading the extension:

Set up browser-skill on this machine by following https://raw.githubusercontent.com/Tencent/BrowserSkill/main/AGENT_INSTALL.md

Manual install

Install the CLI, then install the extension from the Chrome Web Store or Edge Add-ons.

1. Install the bsk CLI

macOS / Linux (recommended — installs to ~/.local/bin):

curl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh
export PATH="${BSK_INSTALL_DIR:-$HOME/.local/bin}:$PATH"

Windows (PowerShell — installs to ~/.local/bin):

irm https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.ps1 | iex

Verify the binary in the terminal or agent environment that will use it:

bsk --version

2. Install the browser extension

Install BrowserSkill from your browser's store:

On other Chromium-based browsers, install the Chrome Web Store build.

3. Install the skill

BrowserSkill ships a skill that teaches your agent harness how to use bsk. For these harnesses, install it in one step:

bsk install-skill

Use Space to select the Agent harness you want to install into, then press Enter to install the skill. Run bsk install-skill --list to see internal variants and install paths.

4. Verify the connection

Run bsk doctor and follow its hints. Open the extension popup and confirm it is connected. Start a new Agent session, confirm browser-skill is available in the harness, and ask it to open https://example.com and summarize the page.

Updating

For the default local setup, finish active browser tasks before updating:

bsk update --yes

Automation settings

The extension popup has two independent Automation settings, both enabled by default. The user's saved browser settings are authoritative for every session.

DeepSeek Harness plugin

Using DeepSeek Harness (dsh)? BrowserSkill ships a first-class dsh plugin on npm as @wxg-prc-cpg/browser-skill-dsh-plugin.

dsh plugin --profile web add @wxg-prc-cpg/browser-skill-dsh-plugin
dsh --profile web

How It Works

BrowserSkill is a local bridge between your agent harness and your browser. The agent never talks to the browser directly. It asks the bsk CLI to perform a browser task; the local daemon routes that request to the extension; the extension runs it in an Agent Window.

For Developers

The repository is a Cargo + pnpm workspace:

• crates/bsk-cli — bsk CLI and local daemon
• crates/bsk-protocol — shared wire types and JSON schemas
• apps/extension — browser extension
• packages/ui and packages/i18n — shared extension UI support
• packages/dsh-plugin-browserskill — DeepSeek Harness plugin
• evals/browser — deterministic local pages and agent-neutral browser capability evaluation

License

MIT

Cline

The open source coding agent in your IDE, terminal, & desktop.

CLI

Run Cline in your terminal. Interactive chat or fully headless for CI/CD and scripting.

npm i -g cline

Desktop App

Cline as a native app for macOS and Windows. Run agent sessions in any folder, schedule routines, and manage models, plugins, and MCP servers.

VS Code Extension

AI coding assistant in your editor. Create files, run commands, browse the web, and use tools with human-in-the-loop approval.

JetBrains Plugin

The same Cline experience in IntelliJ IDEA, PyCharm, WebStorm, GoLand, and the rest of the JetBrains family.

SDK

Build your own AI agents and integrations powered by the same engine that runs the CLI, desktop app, VS Code extension, and JetBrains plugin. Custom tools, multi-agent teams, connectors, scheduled automations, and more.

npm install @cline/sdk

Index

Edits Code Across Your Project

Cline reads your project structure, understands the relationships between files, and makes coordinated changes across your codebase. It monitors linter and compiler errors as it works, fixing issues like missing imports, type mismatches, and syntax errors before you even see them. In VS Code and JetBrains, every edit shows up as a diff you can review, modify, or revert. All changes are tracked with checkpoints, so you can easily undo the agent's work.

Runs Bash Commands

Cline executes commands directly in your terminal and watches the output in real time. Install packages, run build scripts, execute tests, deploy applications, manage databases. For long-running processes like dev servers, Cline continues working in the background and reacts to new output as it appears, catching compile errors, test failures, and server crashes as they happen.

Plan and Act

Toggle between Plan mode and Act mode. In Plan mode, Cline explores your codebase, asks clarifying questions, and lays out a strategy. Once you're aligned, switch to Act mode and Cline executes the plan. Every file edit and terminal command requires your approval, so you stay in control of what actually changes. Or toggle auto-approve and let Cline run autonomously.

Rules and Skills

Define project-specific rules in .clinerules files that guide how Cline works in your codebase: coding standards, architecture conventions, deployment procedures, testing requirements. Rules are picked up automatically by the CLI, VS Code extension, and JetBrains plugin. Use skills to let the model load specific rules when needed.

Works With Every Model

Cline is not locked to a single AI provider. Use whichever model fits your workflow:

• Anthropic: Claude Opus, Sonnet, Haiku
• OpenAI: GPT series models
• Google: Gemini series models
• OpenRouter: 200+ models from any provider
• Vercel AI Gateway: Route to many providers through one gateway
• AWS Bedrock: Claude, Llama, and more
• Azure / GCP Vertex: All hosted models
• Cerebras / Groq: Fast inference models
• Ollama / LM Studio: Run local models on your machine
• Any OpenAI-compatible API: Self-hosted or third-party endpoints

Extend With Plugins or MCP Servers

Extend Cline's capabilities with plugins. Using the SDK, register tools and lifecycle hooks programmatically through the plugin system for logging, auditing, policy enforcement, or adding domain-specific capabilities.

import { Agent, createTool } from "@cline/sdk"

const deployTool = createTool({
  name: "deploy",
  description: "Deploy the current branch to staging.",
  inputSchema: { type: "object", properties: { env: { type: "string" } }, required: ["env"] },
  execute: async (input) => {
    // your deployment logic
  },
})

const agent = new Agent({ tools: [deployTool], /* ... */ })

...or use MCPs to connect to databases, query APIs, manage cloud infrastructure, and interact with external systems. Use community-built servers or ask Cline to create custom tools on the fly. In the CLI, manage servers with cline mcp.

Multi-Agent Teams

Coordinate multiple agents working together on complex tasks. A coordinator agent breaks the work into subtasks and delegates to specialist agents, each with their own tools and context. Team state persists across sessions so you can pick up where you left off.

cline --team-name auth-sprint "Plan and implement user authentication with tests"

Scheduled Agents

Run agents on cron schedules for recurring automations. Daily PR summaries, weekly dependency checks, codebase health reports. Schedules persist across restarts and run independently of any terminal session.

cline schedule create "PR summary" \
  --cron "0 9 * * MON-FRI" \
  --prompt "List all open PRs and their review status" \
  --workspace /path/to/repo

Connect to Slack, Telegram, Discord, and More

Chat with your agent from any messaging platform: Telegram, Slack, Discord, Google Chat, WhatsApp, and Linear. Each conversation thread maps to an agent session with full context. Set up access control to restrict who can interact with your agent.

# Connect to Telegram
cline connect telegram -k $BOT_TOKEN
# Connect to Slack through webhook
cline connect slack --bot-token $SLACK_TOKEN --signing-secret $SECRET --base-url $URL
# Connect to Slack using socket mode
cline connect slack --bot-token $SLACK_TOKEN --app-token $SLACK_APP_TOKEN

Headless CLI for CI/CD

Run Cline with zero interaction for scripting and automation. Pipe input, get JSON output, chain commands, integrate into CI/CD pipelines.

cline "Run tests and fix any failures"
git diff origin/main | cline "Review these changes for issues"
cline --json "List all TODO comments" | jq -r 'select(.type == "agent_event" and .event.text) | .event.text'

As more teams — and now agents — build applications on Cloudflare's Developer Platform, having the right access controls is crucial to allow you to ship safely. After all, the last thing you want is for an agent to make a change in production, just because it was granted more access than it needs.

Now, you can give a teammate or agent access to a specific Worker, so that they can only make changes to that application and no other resources in your account. Moreover, we’re giving you four new roles, so you can limit exactly what they can do:

The new roles are available today, for all customers. You can assign them to a specific user, so when they log into the dashboard, they will only see the Worker you have given them access to. Or, you can create an API token with the scoped access, which you can give to your agent to ensure they only have access to that one application.

Here’s an example of how to create an API token with permissions per Worker:

Roles designed for how teams build

When defining these roles, we wanted to strike the right balance. Overly broad roles force you to grant more access than intended, undermining the principle of least privilege, while providing too many individual permissions makes it difficult to know which ones to grant. We landed on four roles that reflect the levels of access you may want to give a person or agent: enough to debug a resource without exposing its content, read the content without changing it, make changes without being able to delete the resource, or fully manage it.

We plan to use these same roles as we bring resource-level access controls to other Developer Platform products, including D1, R2, and KV. Each role can be applied at one of three scopes. For example, if you set the “metadata read-only” control, here’s what that would look like at different levels:

• Developer Platform level: Access to metadata for all Developer Platform resources.
• Product level: Access to metadata for every resource of one product, such as every Worker.
• Resource level: Access to metadata for one specific resource, such as one Worker.

The role and scope determine what someone can do and which resources they can do it to. Let’s take a look at how this would look in some common Workers workflows.

Debug without exposing source code

To debug an issue, an engineer or agent might need to look at a Worker’s settings, metrics, logs, and traces to understand what went wrong. But they do not need to see the Worker’s code or make changes to it.

Metadata Read-Only gives them access to that information without exposing the Worker’s source code. They can query analytics through the GraphQL API, access logs, and inspect traces and other observability data. Those requests only return data for the Workers they have access to. If an agent is scoped to one Worker, it can use the Cloudflare APIs to investigate an issue without seeing data from any other Worker in the account.

Review code without changing it

A teammate or code review agent may need to read the code running in a Worker to understand how it works, investigate a bug, or review a proposed change. But that does not mean they should be able to deploy new code or update the Worker’s settings.

Content Read-Only provides that separation. It lets them retrieve and review the Worker’s code without being able to modify or deploy it. When scoped to an individual Worker, they can read only that Worker’s code, rather than the code for every Worker in the account.

Let CI deploy without giving it full control

A CI/CD workflow only needs access to the application it deploys. It should not be able to change another Worker or delete its own and take the application offline.

With Worker-level access controls, each workflow can have its own API token with the Editor role, scoped to one Worker. If the workflow is misconfigured or its token is exposed, the impact remains contained: it can deploy changes to that Worker, but it cannot delete it or touch any other application in your account.

Delete a Worker with Admin access

Admin is the highest level of access you can grant. It allows you to delete an application. You can still scope the role to an individual Worker, so that access does not extend to every Worker in the account.

Routes & Custom Domains

You can add routes or Custom Domains to a Worker to specify which hostnames are routed to that application. For example, this configuration in your Wrangler file sends traffic for example.com to the Worker:

{
  "route": {
    "pattern": "example.com/*",
    "zone_name": "example.com"
  }
}

Because changing that route could redirect production traffic or take the application offline, access to the Worker alone is not enough. To add, change, or remove a route or Custom Domain, you need both Editor access to the Worker and Workers Routes permission for the zone.

Requiring Workers Routes permission, rather than broader access to the zone, means someone can manage how traffic reaches a Worker without being able to change unrelated settings for the domain.

However, once a route is configured, you can continue deploying new versions of the Worker without access to the connected zone or resource, as long as the deployment does not change that connection. This allows your CI/CD system to deploy the application without also giving it access to your domains, databases, or storage.

Workers permissions extend to Durable Objects

Durable Objects do not have their own roles or permissions. Instead, access to a Durable Object is determined by your access to the Worker that implements it. To give someone access to a Durable Object, grant them the appropriate role for that Worker.

Metadata Read-Only gives them access to Durable Object metrics, logs, and traces, but not the data stored in the object. Because Durable Objects Data Studio can query and modify that stored data directly, accessing it requires the Editor role.

Better errors that tell you and your agents which permissions you need

When you give someone narrowly scoped permissions, they may eventually try to perform an operation they do not have access to. When that happens, the error should tell them what permission they need, so they don’t get stuck.

Instead of returning only a generic 403 Forbidden response, our APIs now include a link to the relevant API documentation, where you can see exactly which permissions are required to make the request. This way, you and your agent can figure out exactly the right level of access that’s needed without granting broader permissions than necessary.

Available now

Worker-level access controls are available today for all customers. You can configure them in the Cloudflare dashboard, through the API, or with Terraform.

To give a team member access to a specific Worker, go to Manage Account > Members, select the member, and create a policy with the role and Worker scope they need.

Manage team access with user groups

If several people on the same team or project need the same access, you can create a User Group instead of assigning permissions to each person individually. Assign the policy to the group, then add the relevant members. Everyone in that group will automatically inherit that policy.

Replacing legacy permissions for Workers

Previously, we used the following roles and permissions to manage access to Workers. Now that we are rolling out a consistent set of roles across the Developer Platform, we recommend using the new roles going forward.

There is no deprecation date for the legacy roles and permissions. Existing assignments will continue to work, and we will provide advance notice before any deprecation. That said, we recommend starting to move to the new roles, since they're the ones that support granular, resource-level access.

What’s next?

Worker-level access is the first step toward a more consistent authorization model across Cloudflare's Developer Platform.

Next, we are bringing the same resource-level access controls to more Developer Platform products, including resources like KV namespaces and D1 databases. Instead of granting someone access to every bucket or every database in an account, you will be able to scope access to the specific resource they need and pair that scope with the right role.

The same roles introduced for Workers will apply across these resources.

Check out our developer docs to get started.

Create on-brand content with your Figma designs in Weave workflows

Starting today, Figma node lets you connect the designs you’ve already created in Figma Design directly to your Figma Weave workflows.

With Figma node, you can:

• Connect any Figma frame to your Weave workflow: Copy a frame from Figma Design, paste it into Figma Weave, and it becomes a node in your workflow.
• Choose what can change: Select the text and image layers you want to use as workflow inputs, while keeping the original fonts, layout, and styling intact.
• Create new assets at scale: Use your existing Figma designs and brand materials to make campaign variations, localized assets, new visuals, and videos.
• Sync every connected asset with Figma: Bring changes from the original Figma design into Weave to keep every connected asset up to date.

Figma node is available now, connecting your Figma and Weave canvases in one creative flow.

See it in action with a ready-made workflow.

Want to build your own? Watch the tutorial.

For setup details, read the Figma node guide.

The invisible side of design engineering

Design engineering is still a bit more ambiguous than something like product design, software engineering or product management.

It sits at the intersection of design and engineering, but if you ask ten different people exactly what it means to be a design engineer, you might get ten different answers.

If you were to judge by looking at social media, you might think it’s mostly about building animated eye candy components.

That’s pretty far away from the truth though.

Social media obviously doesn’t show the full picture, but since I launched Interfaces I’ve been getting asked what my day-to-day work as a design engineer actually looks like, so I figured I’d write down some thoughts I have on that.

The invisible

It’s understandable that the visual side gets the most attention. It’s a big part of what design engineering is.

It’s tangible, easy to share and easy to react to. And there’s nothing wrong with that. Things like animations and interactions are amazing, and when done well, they can completely change how an experience feels.

But there are other parts of design engineering that are just as important, if not more, but don’t get nearly as much attention.

Things like accessibility, responsiveness and performance. Things that are not “interesting enough” to be shared on social media. Edge cases that only show up when people actually start using your product.

That’s a lot of what my day-to-day work as a design engineer actually looks like.

Why it matters

There are many factors that affect what you do day to day. For example, at an early-stage startup you might touch almost every aspect of building a product while someone at a large company might work in a much narrower area.

And while the work might look different, a lot of the principles remain the same.

It’s easy to forget that we’re building things that are supposed to solve real problems and be used by all kinds of people.

And as a design engineer, your responsibility is to make sure the experience is great.

Sometimes that means building a beautiful animation.

Sometimes it’s spending an entire afternoon fixing an accessibility issue only a few people will notice.

Sometimes it’s obsessing over making the landing page load just a little faster.

It makes sense that the visible side of design engineering gets most of the attention.

But a lot of what makes a great experience is invisible.

Back in April, Canva launched Canva AI 2.0, calling it a "reimagining of how the world creates". The update introduced conversational design, letting users start projects with an idea, sketch or even a voice note. But shortly after the launch, Canva found itself unexpectedly having to press pause on the rollout.

"Canva AI 2.0 is a complete re-architecturing" of Canva AI. We think it's the best AI creation experience you can get," Canva co-founder Cameron Adams told us at a press event at the brand's new London headquarters this week.

But as Canva began rolling the features out in April, it faced a unique problem – and one that Adams thinks other brands can learn from. The demand for Canva AI quickly exceeded its expectations. "Too many people wanted to use the product. There were soon 75M people using it, presenting huge cost and server load increases". So Canva paused the roll-out. With some re-engineering, it managed to reduce the cost-per-task by almost 90%, ending up with models that were 5x faster and 30x cheaper.

Adams says this exactly how business need to think in order to succeed in a rapidly shifting AI landscape. It's not just about raw power, but how to keep costs down.

"There's a lot of focus right now on the big models, such as Claude and ChaGPT," Adams says. "But the best tech isn't always the winner. Betting only on a model is a very fragile approach. We’re going to be constantly in a cycle of models overtaking each other." This is why Canva now has over 120 researchers working on AI models internally and using open source.

Because customers, Adams argues, ultimately don't care specifically which model(s) you're using. They just care how it affects them. "We want to make something accessible, reliable and connected to the way people want to work. We’re playing the long game, translating new tech into everyday human capability," he says. "We don’t settle for short term vision."

Chunking: How to Design for a Brain That Can Only Hold Four Things

Your working memory holds about four things, not seven. Chunking groups loose information into meaningful units that slip past that limit, the psychology behind phone numbers, scannable pages, multi-step forms, and grouped navigation.

How Rob Farmer turns half-baked sketches into New York Times covers

The Melbourne-based motion designer discusses procedural software, editorial deadlines and why perfectionism is the enemy of good work getting seen.

"You can look at anything around you and wonder how you could interpret this in design or motion," says Rob Farmer. A walk after dinner, a flock of gulls, the static hiss of a TV screen – all of it gets filed away as potential creative material. "I often like to find patterns in nature and try to think of them as design algorithms or codes, such as how repeating shapes and forms can mimic those patterns found in nature."

Growing up in Geelong, an hour from Melbourne, Rob didn't start university until he was 27. Before that came what he calls "a lot of gap years": a couple of years in London, a ski season in Utah, stints in retail while he tried to work out what to do with his life. "I think I was always interested in design and illustration and branding, but I didn't know it was something you could study," he says.

Once he found it, though, it stuck – he landed an internship at a brand agency in Brooklyn straight after graduating and stayed three years. It was there, frustrated at not always getting to do what he wanted on client work, that he started posting his own experiments on Instagram. "I was headstrong about creating space for my work that was outside the bounds of client work, agency hierarchy, and feedback," he says. "It's helped me to better understand design as my hobby, and design as my job."

When he's nestling away at work, it will follow a more loose, low-pressure system. Typically this will mean that when an idea arrives, he will grab his laptop or notes app and get a sketch down – "it could be a super rough five-minute sketch, or it could almost be finished in an hour" – then screenshots it into an Instagram planning app, where it sits in a queue of incomplete ideas until he's ready to finish it.

"If I didn't have this kind of visual queue of unfinished sketches, I'd forget about them," he says. It's also become a working library of sorts, and when a brief lands that needs a certain feel, there's often something in that queue that already fits. For the actual making side of things, he will usually reach for the Cavalry App. "I like the procedural nature of it," he says, "seeing how digital parameters like noise, randomisers and more can mimic those patterns in nature."

When asked about his favourite projects of late, there's one piece he keeps coming back to which, perhaps unsurprisingly, started as a rough sketch. This piece is an illustration for a New York Times Book Review piece on AI and the em-dash, commissioned by Matt Dorfman. "The original sketch for the piece was this very loose half-baked idea of an em-dash tattoo," Rob says. "Matt really saw the vision and pushed me to make it better and better." He's since illustrated a New York Times Magazine cover and a piece for the Design Museum's Future Observatory Journal – a full-circle moment for someone who loved the museum while living in London.

Above everything, Matt hopes he's able to inspire others and wants people to stop sitting on their own ideas. "I hope there's some inspiration in there," he says of his portfolio, "maybe others can see something in there and use that as a starting point for an idea of their own. Through sharing my work, I hope I can encourage people to share their work – I think there would be a lot of great work out there that never gets shared because of perfectionism.

"I'm not saying all work needs to be shared or made public, and it's probably important to have some work that remains intimate, but I think perfectionism gets in the way of a lot of great work being put out there in the world."

We’ve gone from worrying about whether AI will take our jobs to wondering whether it will kill us all within 10 years, which is quite a jump even by the standards of the current AI conversation. This comes after Anthropic Alignment Science Lead Evan Hubinger recently put his personal estimate at more than a 10% chance that AI could kill all humans within the next decade.

Speaking at Autodesk University 2026, Autodesk CEO Andrew Anagnost commented on the latest AI doom debate and split the argument into two camps. “There’s a cynical interpretation to this, and then there’s a non-cynical interpretation. I kind of prefer the cynical interpretation,” he says.

He explains: “The idea that any of these companies are going to self-regulate themselves at this point is ridiculous. I think some of this is a little bit of political theatre, you know, designed to pump themselves up, ‘look at how great our tech is’ – it’s so good, it’s so dangerous, there’s a 10% chance that we’ll kill everybody.”

He isn't arguing that the technology is harmless; quite the opposite, as he states, “There really is a real need to start putting guardrails on this technology. It’s a potentially dangerous technology that can be used in dangerous ways.”

The here and now consequences of AI

For Autodesk, the AI conversation is also becoming much more practical. The company is putting AI into Maya to automate parts of animation and make existing artists more productive, while Flow Studio is taking a broader look at how much of the production process can be connected and automated. MotionMaker, for example, can generate character movement from relatively simple inputs, while Autodesk has been expanding Flow Studio towards AI-assisted characters, assets and production workflows.

And there is a consequence to all of that which Anagnost is quite happy to say out loud. “There’s nothing we can do about the fact that these tools are getting more efficient, and because they’re getting more efficient, there are fewer FX artists per film,” he says.

That is a much more immediate problem for people working in VFX than whether AI will go full Skynet and wipe out humanity in ten years. If the software gets better at the work, studios don't necessarily need as many people to make the same film. From Anagnost’s point of view, the hope is that studios use that efficiency to make more things rather than simply making the same number of things with fewer people.

“The question is, are they going to be making more films with high-quality content? It’s unclear where that goes. It’s a very dynamic space,” he says. “Ideally, what would be happening here is that you’d be making more high-quality content. The artists that are available out there just have fewer hours per piece of content and more content.”

That thinking runs through Autodesk’s approach to animation. Maya remains the high-fidelity tool for professional artists, with AI and automation being added to reduce some of the more repetitive work. MotionMaker is one example, and Anagnost says Autodesk will keep adding technologies that take on more grunt work while artists remain in control.

Then there is Flow Studio, which Anagnost describes as a "second track", aimed at smaller teams that want to put together an entire production using a collection of increasingly automated tools. “We’re looking at a small team mashing up a bunch of stuff and bringing something together, script to screen in a highly automated way,” he adds.

Anagnost sees the eventual destination in film as a kind of script-to-screen system in which artists can assemble and direct much more of a production themselves. “The script-to-screen, the highly art manuscript-to-screen, I think we’re going to move to that world, and Netflix will have to eventually accept that,” he explains. “Because the artist feels like they’re in control; they can run a small team now through this, right? And they can pull technologies to use.”

There are obvious implications for the size of creative teams. If a small group can do work that previously required a much larger production, some jobs disappear from individual projects, even if overall content increases. Whether that extra content actually arrives is still an open question. The film and VFX industry is already dealing with changing budgets, streaming economics and a difficult production market, so there is no guarantee that money saved through AI will come back as more work for artists.

Anagnost acknowledges that the industry still hasn't figured out what comes next. “I think we might settle into a place where we’re actually creating more content, lower price, but high-quality content,” he said. “I don’t think we’ve gotten to the knock-on business. Business is still realigning.”

For artists, then, the immediate AI question probably isn't whether a machine will end civilisation. It’s whether the next film needs 500 people to make it, or 300, or 50, and what those people end up doing when the software starts handling more of the production.

The extinction argument is still there, and Anagnost thinks AI needs real guardrails. But Autodesk is also planning for a future where AI simply makes the production process dramatically more efficient, and that future has consequences for artists long before anyone has to worry about the machines taking over the planet.

The new CC, an AI agent built for families

Google Labs introduces a new experimental agent built for families, helping households spend less time on logistics and more time together.

Google is launching an AI agent called CC to help families manage busy household schedules. You can invite up to six members to share information, allowing the agent to organize calendars, track tasks, and handle logistics like meal planning or registration forms. If you are in the U.S., look for an email to upgrade your account or join the waitlist to start using it today.

When we launched CC, our goal was to build a personal agent that helps you get ahead of your day. It quickly became a daily habit for many early testers and in May we brought it to the Gemini App as Daily Brief.

One of our top user requests was for CC to do more to help run a busy home. Between school schedules, sports practices, paying bills, and figuring out what’s for dinner, managing a household is often a shared responsibility with a lot of coordination, made even more challenging with information spread over multiple user accounts.

Today, CC is becoming an agent for families and households. It has its own Google account that gives CC a distinct identity and clear permissions model, enabling up to six members to manage and collaborate with the agent. CC only sees what each member chooses to share, such as emails from your child’s school, the local swim center, or the vet. It automatically sorts through them and creates a shared daily brief and connects to Calendar and Tasks, helping families spend less time coordinating logistics and more time just being together.

How CC can help families save time

With shared context in one place, CC helps keep daily routines for groups such as families and households running smoothly:

• Start the morning aligned: Each morning, CC delivers a shared “Your Day Ahead” brief. Instead of family logistical information staying trapped in one person’s inbox or mental checklist, everyone gets a clear view of who needs to be where, what needs to be done, and what CC already completed yesterday.
• Offload event and task management: CC automatically tracks important dates and to-dos, pulling relevant shared information from across your group into a family Calendar or Task list, and helps keep them up to date even as things change.
• Have CC handle it: CC can also help you complete time consuming logistical tasks involved in running a family, such as filling out permission slips or activity registration PDFs, creating school supply shopping lists, or crafting weekly meal plans. CC will ask for missing details and update its group memory so it can be even more helpful next time.

How CC works, while keeping you in control

• CC now has its own verified Google Account: This is how CC will show up when it interacts with the group. It only responds to group members, and will not take action or share information outside the group without your permission.
• You choose what to share: Each member can easily choose what to share with CC and what to keep private, and can make changes at any time.
• Auto “cc” CC: Pick the email senders that you always want to share with CC going forward, like your kids’ school or travel bookings. Each week, you’ll also receive a private list of new email senders that you can choose to share with CC.
• Send it to CC: When a one-off email comes or you get a text message with information, you can offload it to CC. For example, you can send a picture of a birthday party invite or soccer practice schedule via email or Google Chat so CC can update the Calendar. You can also share a Drive folder or files with CC or add CC to a Calendar.
• Meeting you where you are: CC connects with the Google tools you use every day, like Gmail, Chat, Docs, and Calendar. Behind the scenes, every CC runs on its own isolated cloud computer powered by Google’s agentic harness, Antigravity, and the latest Gemini models. This allows CC to handle tasks like pre-filling class registration PDF forms, checking live drive times from the Google Maps API between back-to-back activities, or creating shared Docs and Sheets.
• CC has a shared memory. As you use it, CC remembers what applies to the whole household (like your go-to grocery list or favorite family restaurants) versus what belongs to one person (like dietary preferences or local timezones).

CC is an early experiment from Google Labs, available on web and mobile for people (18+) in the U.S with a personal Google account. Existing users will receive an email in the coming days to upgrade their account and new users can join the waitlist.

Astra for Law is a legal AI foundation that combines GPT-6 Astra with tools, settings, privacy controls, and context designed for professional legal work.

Huawei plans to release two new AI chips next year. The company has now shipped more than 1,000 of its AI-computing systems to over 370 customers. China's AI chip market is projected to grow to $67 billion by 2030. Huawei's chip-making technology still trails Nvidia's, but the company is developing workarounds and new designs to squeeze in more computing power while using less advanced equipment.

Anthropic claims that its Claude chatbot drives more than a quarter of its research and development work. There are over 30,000 agents doing research and engineering work at Anthropic at any one time. Its staffers collaborate with the chatbot for about 90% of their work. The company is trying to create a framework to track agents and monitor the amount of work they do.

Anthropic's Mythos model sparked a shift within the White House as officials started realizing that AI can be used to launch cyberattacks and pose national-security threats. White House officials and AI executives are working on regulatory efforts, but when they disagree, the executives have gone directly to Trump. Trump has remained resolute that the nation needs to accelerate AI development and continue to build the data centers that are powering the AI boom.

Crusoe built one of the world's biggest AI supercomputers in Abilene, Texas. The company is now investing heavily in smaller data centers. It is manufacturing them in factories, loading them onto flatbed trucks, and deploying them wherever it can find available power. The company believes this is a faster and cheaper method than solely relying on large construction projects. Giant clusters with hundreds of thousands of chips are useful for training, but inference can be done with considerably smaller amounts of chips.

Last week, on September 9, Automattic’s board voted to put CEO Matt Mullenweg on paid leave, a decision the board still hasn’t explained publicly. Mullenweg, in a company-wide Slack message, accused CFO Mark Davies of “conspiring” with three board members behind his back to force the vote through, saying he was given only 50 minutes’ notice and was denied time to have the resolution reviewed by outside legal counsel. He returned to the role roughly 33 hours later, and the same board members who voted him out have since departed the company.

They didn’t just walk out the door, though. In the 33-hour window between Mullenweg being put on leave and his return, two key executives at the company signed off on generous exit packages for each other. Davies, who became interim CEO during that window, and Chief Legal Officer Andy Missan, each signed the other’s severance agreement, effective September 10.

These agreements, effectively golden parachutes, provide each of them with 12 months of base salary paid out as a lump sum, an accelerated vesting schedule for their equity, the ability to exercise their vested stock options, and another year of health coverage, according to the severance documents reviewed by TechCrunch.

Between the two of them, the full package — accelerated equity plus a year of salary — comes out to $8.15 million that Automattic would now owe both executives, since Mullenweg fired them upon his return.

Automattic’s legal team is working to determine what the next steps are: pay out these sums or fight them by challenging their legal validity. The company replaced its earlier counsel, Gibson Dunn, with Stephen Shackelford and Shawn J. Rabin of Susman Godfrey LLP, the company and Mullenweg jointly announced on Wednesday. Automattic’s general counsel, Jordan Hinkes, also had his company account deactivated, sources told us. Mullenweg has since stated on X that this move had been in the works for weeks, as Hinkes is joining an AI startup.

Want to correct the record: Jordan Hinkes, with my support and encouragement, is joining an exciting AI startup as General Counsel. We've been planning this for weeks before anything started; he's still fully @automattic through Friday. :)

— Matt Mullenweg (@photomatt) September 16, 2026

Under the agreements, the executives only get their benefits if they sign a broad release of claims and continue to comply with confidentiality, nonsolicitation, and other legally binding post-employment restrictions.

The agreements are also written in a way that favors the executives when it comes to how “cause” — the legal standard a company must meet to fire someone without owing severance — is defined. Under these terms, the company must notify the executive in writing within 60 days of learning about the conduct, give them 30 days to cure the conduct if curable, then get a majority of the board to agree that cause exists.

“Cause” itself is narrowly defined in the agreements as gross negligence that materially harms the company; knowing dishonesty, fraud, or misrepresentation causing material harm; a material legal violation causing material harm; a material confidentiality or IP breach; or a felony or crime involving “moral turpitude” (a legal term for conduct considered inherently dishonest or morally reprehensible).

In Davies’ case, the agreement also specifies that his removal from the interim CEO role won’t count as “Good Reason” — a legal term that normally lets an executive resign and still collect severance, on the grounds that their job conditions changed for the worse — as long as he remains CFO. While that clause itself is not strange for a legal agreement, it suggests the document was drafted with Davies’ precise circumstances in mind —becoming interim CEO — effectively ensuring Automattic won’t owe him severance once his temporary CEO stint ends, as he can’t claim that alone as a reason to resign.

While it’s not necessarily improper that the executives signed each other’s agreements, in the context of a governance struggle at Automattic, it is noteworthy.

Another factor that has recently come to light is that Davies held no Automattic stock at the time of his departure, according to an HR document viewed by TechCrunch. (One source at the company said Davies sold the stock a “few months ago,” but TechCrunch cannot confirm the time of the sale. Davies did, however, still hold a large number of outstanding vested options, the HR document showed.)

These events can be interpreted in two very different ways. In one scenario, Automattic’s board is responding to an internal leadership crisis, voted to put Mullenweg on leave, and then established protections for the executives who could face adverse consequences if the intervention failed (as it now has).

Automattic’s legal battle with hosting provider WP Engine could come into play here. In July, WP Engine accused Mullenweg of destroying evidence in legal filings, specifically text through messaging apps like Signal, WhatsApp, and Telegram. If the directors believed Mullenweg’s behavior had become a serious corporate risk, putting him on leave and changing management could help demonstrate to the court that the board took the concerns seriously. This could potentially help reduce any possible sanctions or fines or improve settlement terms. (Mullenweg’s X post on September 10, which referenced the alleged destruction, or “spoliation,” of evidence right after the board action, could support this theory.)

In another scenario, it could appear that Automattic’s board was trying to create a window of control for some other reason — perhaps a strategic transaction — by putting Mullenweg on leave and taking the reins. According to sources, this is the theory Mullenweg suspects — though by his own account, the board never gave him a stated reason for the vote to begin with, leaving him, like outside observers, largely to speculate about the underlying motive. That absence of explanation, combined with the CFO’s stock sale, appears to have fed his suspicions and factored into his decision to retake the CEO role and remove the board and other executives.

Automattic has been asked for comment. Attempts to reach Missan and Davies have not been successful.

I don't like LLMs

I have a lot of mixed feelings about AI and LLM technology. I’m fascinated by its effect on our profession, excited by the potential gains in productivity - and thus the products we could rapidly build. On the other hand, I’m fearful of the damage AI might cause: agent swarms taking over our virtual and physical infrastructure, designing bio weapons. But, back on my first hand, LLMs might also design miracle cures, and come up with clever ways to raise our prosperity. Fundamentally I don’t think we have a choice about riding on the AI technology train. It’s a wild ride and I just hope we’ll get through it OK.

But as I mull on this more, I realize that among this mix of contrasting feelings, there is one emotion that dominates - one that comes from my direct interactions with LLMs. I don’t like them. They talk to me in this grating LLM-voice, an uncanny valley of talking to a real human. They confidently bullshit me - often giving me useful, helpful answers. But also just making stuff up with the same assurance - and with only a veneer of fake remorse when I call them out on it.

That’s not enough to make me feel we should avoid them. As Jessica Kerr put it “not only are they useful, it is irresponsible not to use them…. They’re more thorough, as well as faster.” This contradictory reaction comes through in polling, where people say they find these models are useful, but also that they think they will be bad for society.

Much of this may be because LLMs are young - we haven’t trained them to grow up yet. Maybe I’ll like them once they mature. (I hope we get to find out.) But I’m not encouraged when I think of the kinds of environments that cultivate them. I’m wary of the Silicon Valley brogrammer subculture, and these LLMs are their products, so naturally lean toward their world-view. When we think of AI agents, we shouldn’t anthropomorphize, treating them as conscious beings with their own will. They are (software) machines, developed by people working in corporations. While the agents’ behavior aren’t explicitly programmed, they are nurtured with the values of their creators.

One of my most successful life-hacks is to avoid people I don’t like or don’t trust. I decline to interact with them socially, and make a deliberate effort to avoid working with them too, even if they are doing much that is beneficial. I feel that hanging out with pleasant, capable people, the people with integrity, has made my life a far better one. Hence my visceral dislike of interacting with an LLM that’s not just making a pretense of being human, but also posing as the kind of human I walk away from.

Komodor this week added the ability to deploy agentic artificial intelligence (AI) workflows using its platform for site reliability engineers (SREs) that manage Kubernetes clusters.

Company CTO Itiel Shwartz said the Komodor Agentic Operations Platform makes it possible to deploy AI agents using the same workflows that SREs use to deploy other classes of workloads.

Based on the same core AI SRE platform that Komodor provides, the Komodor Agentic Operations Platform enables SREs to deploy custom AI agents or ones they have imported into the platform. That approach enables SREs to deploy AI agents using a familiar set of DevOps workflows, said Shwartz.

Those workflows include a set of templates to troubleshoot issues, optimize consumption of AI and remediate continuous integration/continuous delivery (CI/CD) pipelines. Additionally, Komodor provides more than 50 out-of-the-box specialist agents, skills, integrations and Model Context Protocol (MCP) servers that DevOps teams can customize to add or remove steps, adjust routing or add their own agents. DevOps teams can also shadow-test new versions of AI agents, compare their performance and route tasks to the appropriate model before promoting changes.

Finally, DevOps teams can turn an existing skill, script or runbook into a governed agent, import agents created with third-party frameworks or build new ones using a software development kit (SDK) provided by Komodor. Role-based policies define who can invoke an agent and which credentials and tools it can use, while guardrails enforce boundaries on agent behavior by checking inputs, tool calls and model responses to ensure humans approve any action an agent performs. DevOps teams can also enforce spending limits and are provided a full audit trail to provide visibility in the actions performed.

Kubernetes has rapidly become a de facto standard for deploying AI workloads. The challenge now is extending the DevOps workflows used to deploy AI workloads to what might soon be thousands of AI agents running in production environments. That creates a massive new change management challenge for DevOps teams at a time when the role of SREs in the AI era continues to evolve, noted Shwartz. Rather than being practitioners, SREs are, in effect, now becoming managers of agentic engineering workflows, he added.

In that scenario, SREs will find themselves relying on one AI agent to orchestrate the activities of hundreds of AI agents that have been trained to automate specific tasks, said Shwartz.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said the limits of agentic operations are defined today by what teams can observe, control, and prove once agents act on production clusters. Reusing the pipelines, approvals, and audit trails SREs already trust puts the governance where the muscle memory already is, he added.

The open question is whether this becomes the governing control plane for all operations or one more to reconcile, noted Ashley.

Naturally, the pace at which DevOps teams will be building and deploying AI agents will vary from one organization to another. However, at this juncture it’s not so much a question of whether they will be used but rather how soon and to what degree.

Frequently Asked Questions

What is the Komodor Agentic Operations Platform?

It is a platform for deploying, managing and governing AI agents using workflows familiar to SRE and DevOps teams.

What types of AI agents can teams deploy?

Teams can use Komodor’s prebuilt specialist agents, import agents created with third-party frameworks or build custom agents with Komodor’s SDK.

How does Komodor govern AI agents?

The platform uses role-based policies, guardrails, human approval controls, spending limits and audit trails to control how agents operate.

Coding-agent harnesses such as Claude Code, Codex CLI, and Pi can produce similar task success rates while using dramatically different amounts of tokens and money. Across 21 model–harness combinations on SWE-bench Lite and Terminal-Bench 2.0, harness choice changed cost by as much as 5×, and the model provider's own harness was not consistently the most efficient option.

Pinterest is turning to AI to help consumers move from searching for product inspiration to actually being able to imagine what it might be like to redesign a space or compare home decor options as they’d appear in their own rooms. On Thursday, the company said it’s launching a new consumer-facing feature called “Restyle” in beta in the U.S. and Canada, powered by Pinterest Intelligence.

The foundation of Pinterest Intelligence combines Nvidia Blackwell GPUs and Nvidia Dynamo with open source models and Pinterest-built technology, the company shared on Monday. The partnership will improve the Pinterest Assistant’s ability to handle visual search requests, turn people’s searches into signals for AI discovery and shopping, and more.

With Restyle, users will be able to take a photo of their space, then test and compare different options in their own homes by prompting the AI to do things like add wall art, furniture, accessories, or other home decor, including items from images they found on Pinterest, or change the lighting, paint color, plants, and more. They can also click on individual items in the room to swap them out, erase them from the image, or make further edits. Alternatively, they can ask the AI to visualize their room in a completely different style, like “bohemian,” “industrial,” “whimsical,” “dopamine,” or other trendy looks.

Though it’s not a novel idea — restyling rooms has been a popular consumer use case for AI assistants — adding the feature directly to Pinterest could allow people to do more with the items they’ve saved for inspiration and design ideas. By seeing items in their own spaces, people may be more likely to buy the items they’ve saved to their boards, completing the funnel from pinning to purchase.

The feature was teased at Pinterest’s annual Pinterest Presents event, where the company introduced new visual search ads, app promotion features, and other tools for advertisers.

Restyle is initially available only as an early preview but will roll out more broadly next month.

Samsung has officially begun rolling out One UI 9, based on Android 17, starting with the Galaxy S26 series after a four-month beta. The update introduces new Galaxy AI features, including My FanCam, Creative Studio, Now Brief enhancements, improved privacy and security tools, and easier access to warranty information. Samsung says the update will gradually expand to more Galaxy phones and tablets, including recent S-series, Fold, Flip, and Tab models.

User experience design has evolved through five major eras—from Human Factors and the Web to Mobile, Design Systems, and AI—each contributing a lasting lesson while leaving behind habits that later became limitations. Designers should focus less on producing interfaces and more on shaping systems, information architecture, constraints, and the rules that govern intelligent experiences, as these are becoming the most valuable skills in the AI era. Rather than replacing UX, AI continues the historical pattern of making creation cheaper while shifting designers' value toward higher-level thinking and decision-making.

An interactive 3D keyboard for learning the keyboard shortcuts of the apps you use every day. Pick a tool, hover a shortcut, and watch the keys light up.

Dario Amodei, a co-founder and the chief executive of Anthropic, is one of the tech industry's most prolific and polished explainers. He has contributed to dozens of scholarly papers and more recently wrote a half-dozen informal essays for the general public. This article takes a look at his writings to see what they reveal about the AI leader.

Instinct is rolling out Concierge, a white-glove service for tasks that require human interaction, including phone calls, high-end bookings, and customer service.

Use your own words, don't let the model trick you into thinking your draft is good, and let the model act as a copyeditor.

This guide walks through how to turn a product brief and feature flag into a connected launch workflow.

Clients often give confusing or unhelpful feedback because of uncertainty, internal politics, or a lack of design knowledge rather than problems with the work itself. Common situations include vague requests like “make it look less designed,” Canva comparisons, hidden budgets, feedback by committee, and indecisive comments such as “I'll know it when I see it.” Responding with calm questions, clarifying underlying concerns, setting expectations early, and guiding clients through the design process can turn frustrating feedback into more productive conversations.

A library of interactive UI blocks you can explore, tweak, and take straight into your projects.

Happy Hues is a color palette inspiration site that acts as a real-world example of how the colors could be used in your design projects.

Since 2009, self-taught Canary Islands artist Chema Mendez has fused Renaissance paintings, photography, and AI-generated details into surreal collages that feel like resolved dream paintings, not fragments.