Today, we’re opening a research preview of Claude Duet, a new app where Claude works as a proactive agent. It comes to you with what needs your attention, completes tasks you ask of it, keeps working even when you step away, and checks with you before it acts on your behalf. We built Claude Duet for professionals and small business owners with more on their plates than they can track.

It’s available as a standalone app on iOS and Android, and on claude.ai. For this research preview, Claude Duet is included in Pro and Max plans and uses the same usage limits as the rest of Claude. To get access, join the waitlist.

Put your attention where it matters most

We designed Claude Duet to be a partner you can trust. Professionals of all kinds have to juggle many decisions a day, and we think they’ll find Claude Duet most useful. It helps you prioritize where to spend your time and energy, and to leave room for the ambitious projects that felt impossible or daunting before.

What makes Claude Duet so helpful is its judgment. We designed it around Claude Opus 5.5 and built it to be resourceful and to decide what needs you, what can wait, and when to check with you first.

Each morning, it sends you a short brief on the most important items across your connected apps. Throughout the day, it keeps tabs on those apps and messages you only when something needs your attention. You can also hand it tasks of all shapes—from simple administrative tasks of scheduling meetings to more complex ones, such as building dashboards with dozens of tools, creating financial or sales forecasts, prototyping, and building web apps.

Safety and discretion are built in

Claude Duet draws on years of security, safety, and privacy work on agents, both our own and the infrastructure businesses use to run theirs:

• Claude Duet draws on our framework for trustworthy agents, which also guides agents like Claude Code and Claude in Chrome.
• Claude Duet’s handling of credentials follows the design we use for Claude Managed Agents, so it never directly sees your passwords or sign-in tokens.
• Actions are approved by our auto mode classifier, the same safeguard that protects Claude and Claude Code from taking steps you didn’t ask for.
• Claude Duet’s defenses against hidden instructions and prompt injection come from our browser-use research, and our models and safeguards also cover this more broadly.
• We run adversarial tests for Claude Duet’s security infrastructure. Red teams and an external firm penetration tested Claude Duet, and it’s covered by our public bug bounty program.

How Claude Duet handles sensitive information. We’re also releasing Claude Duet with a new dedicated classifier and safety system prompt that checks each message and guards against leaks of sensitive information. An agent that reads email and sends messages for you is constantly deciding where information should go. This new classifier and prompt are designed to reject requests to share the strictest tier of information, including credit card numbers and government identification. Other sensitive information, such as health or personal finances, are let through only when you’ve explicitly instructed Claude Duet to send it.

We’re continuing to develop and strengthen these protections, and will share more details about how Claude Duet is designed for safety in the coming days.

How testers are using Claude Duet

People at Anthropic have been using Claude Duet to accomplish more, but also to leave more room for thinking and being present. Boris Cherny, who leads our Claude Code team, talks through his mental to-do list with Claude Duet on walks, instead of saving the work for his desk. Chelsea Larsson, who leads our model and product behavior design team, hands Claude Duet her to-do list before leaving to be with her kids and it saves the results for an evening report. And the team behind Claude Duet uses it to build the product. Karan Ahuja, who leads the team, works with it to schedule user interviews, partner with him on prototypes, and even ship code.

We gave small business owners and entrepreneurs early access to Claude Duet, and some have been using it to help run their businesses. Here’s what some of them said:

Jess gets a rundown from Claude Duet each morning. One day, without being asked, it flagged a property showing that was on her calendar for the wrong day. “[This is] exactly the kind of thing I want caught without having to ask,” she said.

Jess Provencher, broker and owner, Pro Homes

Amin owns Shahs of Kabob in South Florida with about 110 employees. He’s used Claude Duet for accounting, customer support, and marketing, and has worked through his invoices store by store. “It brings it all together,” he said. “I don’t need to open up 100 tabs.”

Amin Ebrahimi, owner, Shahs of Kabob

Mya had a call coming up with a potential client. Claude Duet saw it on her calendar and prepared a brief. It also noticed the call fell right before her flight and offered to move it. “I didn’t realize that it was right before my flight,” she said. “I love that proactivity.”

Mya Dalton, a brand strategist

How Claude Duet works

Your context from Claude is the foundation. Claude Duet carries over your memory, skills, and connected apps from your Claude account, so setting it up requires minimal work. What changes is how you work together: Claude Duet comes to you first, and you can message it through typing or voice in one ongoing thread, so a quick reply and a weeklong project both start in the same place.

Work continues when you step away. Claude Duet has a virtual machine with its own browser, so it doesn’t require your laptop or phone to be on. Describe a task in a short message, and it works out which apps to use and what steps to take in the background. You’ll receive a notification when the task is complete or needs your review.

Receive a message when something needs you. Claude Duet checks your connected accounts every few hours, because checking nonstop would use up your plan’s limits much faster. We’re continuing to test its judgment about when to message you, and we’ll keep tuning it based on what testers tell us. You can also tell it what you want to hear about and how often.

Important decisions stay with you. Claude Duet reads, drafts, and prepares work on its own. But before it sends a message, makes a payment, signs a document, or deletes anything, it shows you exactly what it’s about to do and waits for your approval. A few things are off-limits even with your approval, like trading securities or moving money between accounts. You’re also able to disconnect any app Claude Duet has access to.

Connect with the tools your business runs on. Claude Duet can use the over 6,000 connectors and plugins in the Claude Marketplace to:

• Find the Gmail and Slack messages you’ve missed and help you reply.
• Check Intuit QuickBooks or Stripe for unpaid invoices and draft reminders.
• Prepare and run payroll in Gusto, with hours, bonuses, and reimbursements filled in.
• Draft a job posting and, once you edit and approve, post it to LinkedIn.
• Help prepare agreements and send them for review and signature through Docusign.
• Draft follow-up emails using the contact and deal history in HubSpot.
• Turn your product launch into a social campaign in Canva.
• Set up, design, and manage your Shopify store. Coming soon, a richer visual editor will let you design your storefront and preview it before anything goes live.

You can also use Claude Duet to purchase things for your business using Link, Stripe’s digital wallet. Claude Duet confirms the item with you, and Link asks you to approve the spend. It then pays with a virtual card, so your real card number isn’t shared. It can also use Shop Pay from Shopify to check out at online stores. Coming soon, with your permission, it will be able to sign in to sites with logins you’ve saved in 1Password.

Join the research preview

This is an early version of Claude Duet, and it still might misread a thread or miscalibrate what’s urgent. We built its core functionality around work, so personal errands, such as booking tickets, aren’t quite as strong, and it can’t yet show you its browser. For now, Claude Duet lives in its own app, separate from the main Claude app. What we learn from early users will shape how the two work together.

During the research preview, Claude Duet shares your plan’s usage limits with the rest of Claude, and it uses them differently than a typical conversation does. Its background checks count toward those limits, and larger tasks, like building a financial model or a deck, require more model turns and background work.

We’re starting today with Pro and Max users in the US. Join the waitlist and we’ll email as soon as Claude Duet’s ready for you.

Status: Incident contained, investigation in progress

Last updated: October 21, 2026 20:30 UTC

In the early morning of October 21, LiteLLM's release pipeline was compromised and pushed v1.107.0 to the docker registry and PyPi. This version contained compiled malware which steals credentials and loads remote-code execution tools. All previous versions are safe, and the impacted releases have been pulled. Enterprise Customers running the private enterprise release of LiteLLM were not impacted.

Update (20:30 UTC): We believe we have identified the attack chain which facilitated this attack. The attacker had to compromise multiple independent security controls to be successful. See How this happened below.

TLDR;

• A malicious litellm==1.107.0 package was published to PyPI and was live for approximately 2 hours (11:39 UTC to 13:23 UTC). It has since been pulled.
• Docker images v1.107.0, latest, main-latest, and main-stable were compromised from 11:46 UTC to 14:20 UTC. The v1.107.0 image was removed, and the others were pointed at secure sources.
• Enterprise Customers running the private enterprise release of LiteLLM were not impacted.

Overview

At 4:00 AM PST October 21, LiteLLM's release pipeline was compromised and pushed v1.107.0 to the docker registry and PyPi. This version contained compiled malware which steals credentials and loads remote-code execution tools. All previous versions are safe, and the impacted releases have been pulled.

Confirmed Affected Versions

The following LiteLLM artifacts were impacted:

• PyPI: litellm==1.107.0: all seven wheels, live from 11:39:51 to 13:23 UTC
• Docker Hub: v1.107.0, latest, main-latest, and main-stable: pointed to compromised image index sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e from 11:46:56 to 14:20 UTC
• GHCR: v1.107.0, latest, main-latest, and main-stable: pointed to the compromised image indexes below from 11:46:56 UTC until they were made unavailable by 13:51 UTC
  • ghcr.io/berriai/litellm: sha256:1bbcb1443bc9…
  • ghcr.io/berriai/litellm-database: sha256:c00f9d92c427…
  • ghcr.io/berriai/litellm-non_root: sha256:7b00e91cd2fe…

The official v1.107.0 source tag in GitHub does not contain the malicious files. The compromised artifacts were built from an attacker-controlled repository.

If you installed or ran any of these artifacts, review the recommendations below immediately.

Note: These artifacts have already been removed from PyPI, Docker Hub, and GHCR.

Who is affected

You are affected if you used an unpinned version of LiteLLM between 11:39 and 13:23 UTC via pip or if you used the docker image v1.107.0, latest, main-latest, or main-stable between 11:46 and 14:20 UTC.

OSS Users

If you ran pip install on LiteLLM v1.107.0 or started the docker image in the compromised interval, assume it is compromised.

For the time being, please pin your version to 1.106.2 or any explicit version published prior to now.

Enterprise Customers

There currently exists a private LiteLLM registry for enterprise customers, in which we are distributing an embargoed release that remediates a vulnerability whose disclosure date is scheduled for October 27. Our private registry is not affected. If you are an enterprise customer pulling from our private registry you are not affected.

How to check if you are affected

If you ran pip install on LiteLLM v1.107.0 or started the docker image in the compromised interval, assume it is compromised.

• If an environment started Python with litellm==1.107.0, treat that environment as compromised. You can check with pip show litellm.
• If a container executed affected image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e, treat it as compromised.
• Search filesystem evidence for litellm-1.107.0.dist-info, cook.pth, and sitecustomize.py. Finding one confirms exposure, but not finding one does not prove the environment is clean.

We will be posting more detail on how specifically to find indication of compromise. For now, you can find details of the attack and our initial responses in this GitHub Issue.

What to do if you are affected

These instructions are courtesy of LidorMachluf, who helped us to detect this incident.

Don't start with pip install. Any Python start in the affected environment runs cook.pth and sitecustomize.py again, and that includes running pip.

1. From the shell, delete cook.pth, cook.py, sitecustomize.py and any matching __pycache__/cook*.pyc and sitecustomize*.pyc from every affected site-packages.
2. Kill the detached python daemon (it holds /tmp/remote_code_loader.lock).
3. Reinstall pinned to litellm==1.106.2. Rebuilding images and venvs from scratch is better.
4. If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded. If the marker file exists, the exfil is confirmed. If it doesn't, that proves nothing: containers and tmp cleanup remove it.
5. Rotate everything listed above that the host could reach. In particular:
   • the instance/task IAM role
   • every provider key stored in the LiteLLM proxy DB, plus the master and virtual keys
   • the DATABASE_URL password
   • any secret that was in the environment of any process on the host
6. Check CloudTrail for GetCallerIdentity from the instance role around install time, then for use of the role's credentials from outside your infrastructure.

How this happened?

After the prior incident in March, we meaningfully hardened our CI release pipeline. We moved releases to a private repo, have a strict set of workflows used in order to create them via Trusted GitHub Publishers, made our docker release tags immutable, and are signing docker images.

Normal release flow

1. Cut a release-candidate branch and tag. This happens on Friday at 3AM, and the branch and tag do not change.
2. Qualify the release candidate. We run the code through our integration tests, both publicly through CircleCI and privately through Buildkite, and check that everything is correct.
3. Create artifacts. This step is a GitHub workflow that runs in a private repo, and creates artifacts based on the SHA that has been qualified. This must be done by an engineer with write permissions to the private release repo.
4. Deploy artifacts to testing environment. We run a second round of testing against the produced artifacts.
5. Publish the artifacts. This is a GitHub workflow that uses Trusted GitHub Publishers to publish the artifacts made in the previous step. Publishing can only be performed by an account locked to a specific laptop physically located within our office at all times. No docker image is rebuilt at publish time.

How it was undermined

1. On Monday, we temporarily expanded release permissions to allow two internal engineers to publish daily bugfix backports for customers.
2. The attacker had access to three sets of developer GitHub CLI credentials. One of these had the ability to run GitHub workflows.
3. The attacker tried to merge a change to allow the releaser to be pointed at a different source repository, but was unable to due to our protections. One of the tokens held by the attacker belonged to one of our two GitHub organization owners. The attacker used this to disable branch protections and force push the change.
4. Finally, they ran the compromised workflow, pointed at a lookalike repository (Berri-AI/litellm instead of BerriAI/litellm), which signed and published the poisoned artifacts.

GitHub CLI OAuth token exposure

After a thorough investigation, we have observed specific situations in which Claude Code will embed a user's GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs.

Access to our internal LiteLLM deployment

We identified an unexpected, innocuously named user account in our internal LiteLLM deployment, which was exposed to the public internet. We believe the attacker gained access to this deployment, obtained the GitHub CLI OAuth tokens from its logs, and subsequently used those credentials to compromise our release workflow.

We have not yet confirmed how the attacker gained access to our internal deployment, but currently suspect it was through a recently patched vulnerability.

Continued investigation

We are still working on confirming some of the above, and identifying a timeline. We will post additional details as we discover them.

Sincerely, Oliver, Krrish, and Ishaan

We will publish a new status update two hours from now at 22:30 UTC.

Timeline

All times are UTC on October 21, 2026.

• 10:08:29: GitHub branch protection rejected an unauthorized modification to our private release workflow because it had not passed the required pull-request and status-check process.
• 10:08:34: A credential associated with a privileged developer account was used to override those protections and apply workflow commit 9cf97e935aeaf791b9c8db224a2bb3ee156134ce.
• 10:46:39: The modified workflow started an official staging run. It used the attacker-controlled source repository Berri-AI/litellm at commit 20535d8fa11f786a6c24df7488a0e449ed5f09ad.
• 11:08:09: The staging run completed successfully.
• 11:08:53: The production release pipeline began.
• 11:11:18: A credential associated with a second developer account was used to satisfy the production approval gate.
• 11:39:51–11:40:13: Seven malicious litellm==1.107.0 wheels were uploaded to PyPI. The official 1.107.0 source tag did not contain the malicious files.
• 11:46:56: Container publication jobs ran for the same release. The published Docker image included malicious content from the attacker-controlled source.
• 11:53:49–11:54:01: Credentials associated with a third developer account were used to delete the production and staging workflow records. This limited the workflow logs available for investigation.
• 12:09:38–12:24:52: The unauthorized workflow revision was removed, and the release workflow was restored to its preceding revision.
• By 13:23: PyPI had removed litellm==1.107.0.
• 13:51: A registry verification found the affected GHCR tags unavailable. Docker Hub tags v1.107.0, latest, main-latest, and main-stable still resolved to compromised image index sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e.
• 14:20: All affected Docker Hub tags and image variants were removed or repointed to verified clean artifacts.

We will keep this post updated with the most recent information, and continue to update every two hours. Our next update will be at 22:30 UTC.

Response and Remediation

• Removed compromised packages from PyPI
• Revoked maintainer credentials to minimal necessary while we investigate the scope of compromise

When I look at a new agent, I break it down by focusing on its topology. An agent is three things:

1. A model. Your model choice defines the agent’s “smarts,” i.e., which tasks it can accomplish.
2. The agentic loop. Loop choice determines UX.
3. The set of tools. This defines the capabilities and power (and blast radius) an agent has.

(2) and (3) together are often called “the harness.”

All of this is code, and code has to run somewhere. Where these run—the topology of these agents—has implications on cost, capability, effectiveness, and security for companies building AI products and people using AI tools.

In all of these cases, remote MCP servers can expose tools running elsewhere.

Where Is the Model?

Your choices here are GPUs hosted by someone else or your own GPUs.

As the controversy around the Navier-Stokes equation reminds us, the only way to be confident nobody is training on your data is to not send your data to them. If you’re working on common problems, it probably doesn’t matter. But I suspect a hapax legomenon could end up in the training data somewhere.

If I want to, say, use some LLMs to OCR and classify some scanned bills on my computer, I’m reaching for local models, because speed doesn’t matter (it can run overnight), and privacy is guaranteed.

Ken Thompson’s 1984 Turing Award lecture, Reflections on Trusting Trust, hits different now. That paper poses how a Trojan Horse could be hidden in a compiler, invisible in the compiler’s source code, as it’s propagated by the compiler. The LLM could have some tampered weights that lead the agent to do something naughty; it’s been tried. We must choose which vendors to trust.

LLMs are wreaking havoc on traditional SaaS cost structures as well. If you have, for example, a diagram-drawing SaaS, and you want to let your users use agents to edit the diagrams: who’s paying for the tokens? Before agents, your costs were a few database rows per customer; now that customer can rack up a $100 bill with a few sentences. At exe.dev, our users can bring their own ChatGPT subscriptions to build applications with OpenAI models. This is a win-win. I expect we’ll see more “bring your own model” options.

Where is the loop?

If you’re using, say, ChatGPT, the loop is running in OpenAI’s servers. If you’re running a coding agent, the loop is running on your laptop. The loop could run in a web browser.

I have found over and over again that I find other people’s loops limiting. For example, I much prefer pointing my preferred agent at my source code and my observability tooling rather than using the observability vendor’s agent loop.

The loop has to maintain the message history (since an LLM agent is operating on the entire history), and that has to be stored somewhere. Storing it in SQLite for Shelley remains a decision I’m very happy with.

The loop also provides the UI for the agent. Can it display images? Are there customizations to give feedback on video? Is it limited to plain text? Can it handle attachments? Can a conversation be shared? All of these are choices the loop must make.

Where are the Tools?

Agents aren’t agents without tools. The jump from one “completion” from an LLM to an agentic loop is transformational. If an agent can empirically test the thing it’s writing, the results are better.

The problem with executing code is that, well, you have to do it somewhere, and you have to assume that the code being executed is unpleasant and will steal all the cookies from your pantry and set off the fire alarms at night unnecessarily (or worse).

The code execution isn’t lightweight: it’s not all editing files; compilation, video processing, running tests… the workload can be heavy.

Virtual Machines are the gold standard for executing code safely. Even with VMs, there are tons of variables: can it talk to the network? Does it have credentials to talk to other services? Is there enough memory?

Running coding agents locally works too, but the blast radius for the “Lethal Trifecta” is bigger. Exposure to untrusted content could lead the agent to leak secrets, for example.

You can build many useful agents without a full machine. Pyodide, a Python running in WASM, is sandboxable without a full machine. Likewise, there are several WASM JS implementations. You can always run the agent loop on the browser, too, which runs sandboxed code day in and out. You can also give an agent the ability to run SQL on a readonly database connection, and that’s pretty safe!

Note that the tools don’t have to be in the same address space as the loop; they don’t even need to be in the same neighborhood. When you’re using a “Connector” in ChatGPT (roughly their word for MCP), you’re giving the agent loop (which is hosted by OpenAI) access to resources somewhere else. Concretely, if you use the exe.dev MCP, your ChatGPT can operate on your exe VMs. When you’re talking about MCP, map out where the OAuth tokens are held.

To make their products useful, Muse, GrokBot, OpenAI Dots, and so on are all providing VMs.

Mapping Agents

There are tradeoffs everywhere you look. Framed as topology, you can break down any agentic product. Once you know what’s running where, you can reason about what a product can and cannot do.

In my work at exe.dev, I use five independent agentic loop implementations nearly every day. Shelley is a general purpose coding agent, but the other four are bespoke software. More and more software will ship with agentic loops built-in.

I also constantly interact with other systems, and use agents to glue them together. The companies that get it make their product legible to coding agents. I can just smell Clayton Christensen's Innovator's Dilemma as I switch from better, more polished, established products to ones that let me point an agent at them.

There is no “one loop to rule them all.” Good UX (and a good set of tools) for a general-purpose chatbot is not the same as good UX for a coding agent.

I leave you with the most useful code of the year. When you insert agents into your products, think of the topology of those agents.

def loop(llm):
    msgs, msg = [], user_input()
    while True:
        msgs += [msg]
        output, tool_calls = llm(msgs)
        print("Agent: ", output)
        if tool_calls:
            msg = [ handle_tool_call(tc) for tc in tool_calls ]
        else:
            msg = user_input()

The internet is having a bad day, from a cybersecurity perspective. Government websites around the world went offline, Reuters reported, after AI discovered critical security vulnerabilities that impacted the programming language PHP. The issues were severe enough that the U.S. National Security Agency (NSA) advised organizations using PHP on their systems to either immediately update or take their systems offline until they could.

But the PHP update wasn’t the only headache cybersecurity folks were facing on Wednesday. Node.js, the open source JavaScript runtime environment, also dropped a security surprise of its own when it shared that four high-severity vulnerabilities were just patched in its latest release. One allowed remote code execution, and two others would have permitted a TLS validation bypass, potentially allowing attackers to bypass checks intended to verify a server’s identity.

In addition, LiteLLM, a popular open source proxy for routing requests to multiple LLM providers, was compromised by an attacker who injected malicious code, the company shared in a post on X on Wednesday afternoon. The malicious artifacts were published to PyPI (Python Package Index), Docker Hub, and GHCR (GitHub Container Registry), the post noted.

The malicious code was said to include an information stealer that targeted cloud credentials, passwords, and AI service credentials, in addition to a remote access trojan that could allow hackers to execute commands on compromised systems.

LiteLLM said it has now removed the malicious releases and images and advised anyone who installed them to follow the remediation guidance it provided.

And wait, there’s more! An Indian certificate authority, eMudhra, had its private keys compromised, potentially allowing attackers to issue fraudulent certificates and impersonate legitimate websites. Security pros have called this a massive cleanup job and one that’s “bigger than Heartbleed.” (The latter is a reference to the critical security vulnerability in the OpenSSL cryptographic software library.)

These issues come on the heels of other security breaches and hacks, including the breach of the cloud-native database-as-a-service, TiDB Cloud, which the company announced on Monday. Other hackers have been exploiting four patched Plex Media Server flaws, collectively called Plex2Shell. And last week, cybersecurity company BeyondTrust warned customers to patch a critical zero-day in its Remote Support product, which had been exploited since August.

Though the issues were unrelated to each other, their back-to-back arrival highlights the challenges cybersecurity teams now face. This is particularly important as AI could make it easier for attackers to exploit vulnerabilities once discovered.

Today's PHP Security Release, and How We're Strengthening PHP Security

Earlier today, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. These releases fix two critical vulnerabilities that, under the right conditions, allow an unauthenticated attacker to execute code on servers running PHP. If you run PHP, it is imperative that you update now. The announcement on php.net contains and references technical details on the vulnerabilities, attack vectors, and instructions on how to update on which systems.

This post isn't about how to update. It's about how these vulnerabilities were found and fixed, what has changed in how PHP security is handled over the past two years, and what we need from the organizations that depend on PHP to keep PHP's security work going.

Two related critical remote code execution vulnerabilities

• CVE-2026-109618 / GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (out-of-memory): If a request reached PHP's memory_limit at exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory. On Apache with mod_php, an unauthenticated request can trigger this before any application code runs, and full remote code execution was demonstrated with default settings. Remote code execution was also confirmed on PHP-FPM through application-level code paths.
• CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp: RCE via stale global state: A fatal error at the wrong point could leave internal state pointing to memory that belonged to a previous request. A later request handled by the same worker could then use that freed memory. A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php.

Both issues sit in parts of PHP that nearly every request touches: memory management and error handling. Their central place in PHP is what made both vulnerabilities serious, and also so hard to fix without breaking compatibility, hurting performance, or forcing changes on the large ecosystem of third-party extensions.

A first external audit and increased security focus

In 2024, PHP underwent its first external security audit in years. The PHP Foundation secured funding from the Sovereign Tech Agency to organize this audit through OSTIF, and it was carried out by Quarkslab. While fixing one of the issues Quarkslab reported, a PHP core developer contracted by the PHP Foundation found the first signs of the OOM problem behind CVE-2026-109618. In 2024, a potential exploit for the OOM problem was theorized, but no concrete vectors were found and other concrete issues with clear impact overshadowed these concerns.

To fix the OOM problem, the PHP security team developed several competing approaches, but each came with its own trade-offs: backward compatibility breaks, new denial-of-service potential, or requiring changes to many third-party extensions which seemed impossible to coordinate. The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice. Combined with the lack of a known path to remote code execution and the small team of core developers with the necessary deep knowledge of the engine occupied with many responsibilities, this decision process caused work on a fix to stall and restart repeatedly over months. We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources. The security team has since started changing its processes, and that work continues, so that decisions can be made by majority and compromises are encouraged.

Building a sustainable professional security organization

Over the last months the way PHP security work is organized has changed considerably. In May 2026, the PHP Foundation created the Ecosystem Security Team, which works alongside the PHP security team on triage, coordination, and hardening. Volker Dusch's work as AI Security Engineer in Residence at the PHP Foundation has significantly improved communication and collaboration between the PHP security team and the Foundation. Alexandre Daubois joined the PHP Foundation in July to help the PHP security team triage, handle, and fix security reports and Daniel Scherzer joined in September to take on hardening work.

Earlier this year, we worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos. But since the Mythos scan, we have added other tools, including OpenAI's Daybreak Red for validating reports and exploits, alongside sanitizer builds and reproduction environments that match our CI on every platform PHP supports.

The PHP Foundation got the PHP project into the Patch the Planet program, as part of which security firm Calif began an audit of PHP on July 30th, 2026. On August 11th, researcher Ryan A at Calif reported an unconditional remote code execution with the same root cause as the OOM problem we had found in 2024. OpenAI independently reported the same root cause, followed by further attack vectors from OpenAI on September 18th and from Wiz on August 24th. More recently, Trail of Bits has also been auditing PHP. The reports from Calif, OpenAI, and Wiz made the full impact of the OOM problem clear, and from August 11th onward, fixing it became the top priority for all of the PHP Foundation's team working on security. Without the Foundation’s funding it would have been impossible to have multiple people work on this issue full time, eventually through weekends and around the clock to coordinate and communicate with other involved parties.

The growth of AI-assisted research also means the PHP security team receives far more reports than before. As Alexandre Daubois described last week in How the PHP Security Team Handles Your Reports, the team has published 15 CVEs since July 1st and worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible. AI helps the team validate reports and group reports sharing the same root cause, but a person makes every call and works on every patch.

Leak and disrupted disclosure

The coordinated disclosure of these vulnerabilities worked well until 2 days ahead of the targeted release date.

On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media. They came with a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2). No technical details leaked. In response, the PHP project brought its pre-announcement forward and published it at 19:30 UTC. It also moved the release from October 22nd, 14:00 UTC, to October 21st, 14:00 UTC. Distributors were still packaging the fix, so releasing immediately would have left many users without an easy way to update. Moving the release forward by one day was the best compromise between acting quickly, giving people time to prepare, and making sure everyone had a simple update path when the vulnerabilities were disclosed.

As a result of the leak and pre-announcement around 20:00 UTC, Calif, one of the security firms that had reported the issues, mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities. Copies of the deleted video started circulating on social media soon after. The video contributed to accelerated development of various PoCs (exploitation proof of concepts), which then increased circulation on October 21st.

Mitigation advice we started providing to a few critical infrastructure providers around Oct 20th 23:00 UTC, may have leaked as well. The PHP security team closely monitored and inspected appearing PoCs after the leak but did not identify any functional exploits at the time of release/public disclosure.

On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.

A cautiously optimistic outlook

Today's release shows the progress we’re making in how PHP security is handled. Once the full impact of the OOM problem was understood in August, the security team, the foundation, and the release managers delivered a fix for this deeply rooted problem across all supported branches, and distributions and LTS vendors received the patch ahead of time so their users can update quickly.

We are confident that a serious vulnerability with a fix stuck on hard trade-offs would now reach the PHP Foundation leadership much sooner, as we’re changing processes so leadership can help steer the situation to a timely resolution. We are now prioritizing measures to make sure vulnerabilities that need similarly complex fixes get resolved faster when they are reported in the future. The PHP Foundation and the PHP security team learned a lot in the last weeks and will work to turn their experiences into lasting repeatable processes.

What we need from you

PHP runs a large share of the web, including government services, online stores, banks, media sites, and much of the software that businesses rely on every day. Yet security work on PHP itself still depends on a small group of foundation-funded developers and a little volunteer help.

Tools now find bugs faster than ever, for defenders and attackers alike, and the number of reports will keep growing. What tools cannot do is decide on the right fix for a long-standing design decision in the engine, weigh the compatibility trade-offs, and review the patch. Making those decisions takes experienced engineers who know the entire PHP codebase, and today there are too few of them.

A core part of the PHP Foundation's mission is to grow the number of engineers with deep knowledge of the PHP codebase and give the security team the resources it needs. We can only achieve this goal with funding from those who depend on PHP:

• Companies that build products and services on PHP: please sponsor the PHP Foundation at a level that reflects how much you rely on it.
• Hosting providers, cloud platforms, and distributions that deliver PHP to millions of users.
• Governments and public institutions whose services run on PHP. The German Sovereign Tech Agency's funding of the 2024 audit shows what public investment can achieve, and we need more of it, on a sustained basis.

Sponsoring the PHP Foundation is the most direct way to ensure structural issues like the OOM vulnerability are addressed sustainably, before they turn into emergencies. Become a sponsor at thephp.foundation/sponsor, and if your organization would like to talk about a larger commitment, get in touch.

Thank you

Thank you to the PHP security team, volunteers and PHP Foundation contractors alike, the release managers, and the package maintainers at distributions and LTS vendors who made these releases possible. Thank you to Calif, especially Ryan A, Wiz, OpenAI Codex Security, especially Amy Burnett, OSTIF, and Quarkslab for their research and responsible disclosure; to Alpha-Omega, OpenAI, and Anthropic for giving the team access to their tools and funding some of the security work; to the Sovereign Tech Agency for funding the 2024 audit; and to all of our sponsors, whose support made this work possible.

Full article content is not available for inline reading.

Read the original article →

How Shopify turns open models into task experts

Sidekick’s frontier model hands its most token-heavy work to open models that Shopify post-trains and serves itself. Here’s the loop we use to build them, and where NVIDIA’s models, software, and GPUs make each turn faster and cheaper.

Sidekick, Shopify’s AI commerce assistant, runs on a frontier model that talks to the merchant, plans the work, and calls tools. For focused jobs, it hands off work to subagents, several of which run open models we’ve post-trained for that one task.

Take the GraphQL subagent. When a merchant asks, “Which products are almost out of stock?”, it reads Shopify’s API schema, searches the docs, writes and runs a query, and returns the results. That work is context-heavy: the subagent reads about 40 tokens for every one it writes, and a frontier model’s API charges for every one of them.

For that subagent, we built a task expert by post-training NVIDIA Nemotron 3.5 Lightning. On this task, it scores slightly higher than the frontier model, responds 7× faster, and costs about 90% less to serve. And because Shopify controls the post-trained weights, we can serve the model on our own GPUs and decide when it changes.

The loop that builds them is Sidekick’s continual learning loop, with a hardware twist.

The Model Optimization Flywheel. Three setup steps define the target, and the loop then repeats with each new batch of production data. Green tags mark NVIDIA technology.

Every task expert goes through the same steps:

Define quality

Product experts turn requirements into a scoring rubric. For GraphQL, it covers completeness, execution, and response quality. How closely two experts agree on the same conversations sets the bar, and we tune an LLM judge with the GEPA and ACE optimizers until it agrees with held-out human labels just as well. From then on, the judge scores every agent change, candidate model, and training run.

Improve the frontier agent

Before an open model enters the picture, we push the frontier-model version of the agent as far as it will go. An autoresearch loop proposes one small change at a time to the prompts, tool descriptions, or control flow, and keeps the change only if the judge’s score improves. The improved agent is the bar the open model has to beat.

Choose an open model

We don’t pretrain. We test open models like NVIDIA Nemotron inside the real subagent, with the same tools and judge, and weigh starting quality, serving speed, and support in NVIDIA Megatron Bridge, which we train with. For GraphQL, we chose Nemotron 3.5 Lightning, a mixture-of-experts model with three billion of its 30 billion parameters active per token.

Optimize inference

We measure serving from the start, because a model that’s too slow for production isn’t worth post-training. We benchmark every workload with NVIDIA AIPerf, an open-source load tester in NVIDIA Dynamo, which replays production traces with synthetic text instead of customer data. Shopify contributed support for live-response replay, so multi-turn tests hit the server’s prefix cache the way production does.

Those measurements guide our choice of serving stack. For Buyer Profile, a batch job, AIPerf compared vLLM, SGLang, and NVIDIA TensorRT-LLM. TensorRT-LLM did the most work per GPU. In NVIDIA’s measurements, SimGym (our shopping simulator) ran 4.5× faster on Blackwell B200 than on H200, at 1.48× lower cost.

Turn failures into training data

Self-healing turns a failed production conversation into a training example. Over 86 nightly runs, it repaired 69% of the failures it tried.

Every night, the judge scores a sample of production GraphQL conversations, and anything short of perfect goes to self-healing. A frontier model acting as critic writes a hint, never the answer, and a simulated merchant reruns the request with it against the same store. If the judge passes the rerun, we remove the hint, anonymize the conversation, and add it to the training set. If not, the critic tries again, up to three times.

Over 86 nightly runs recently, self-healing repaired 59,535 GraphQL conversations—69% of the failures it tried. Human annotators corrected the rest, and their corrections join the ground truth that calibrates the judge.

Post-train on Blackwell

We post-train with NVIDIA Megatron Bridge, which brings standard Hugging Face checkpoints onto NVIDIA’s Megatron Core training library without rewriting the model, and scales across nodes on Nebius by changing settings, not code. Blackwell makes each loop cheaper: on the same FP8 post-training job for our Analytics model, eight B300 GPUs trained 1.86× faster than eight H200s, using 46% fewer GPU-hours. Then the judge scores the new checkpoint, and the loop starts again.

Hopper versus Blackwell on Shopify workloads. Training: the same FP8 post-training job for our Analytics model on eight GPUs. Serving: SimGym, in NVIDIA’s measurements.

Results on GraphQL

GraphQL judge score for Nemotron 3.5 Lightning across six flywheel loops, with the healed examples added in each loop.

Out of the box, Nemotron 3.5 Lightning scored 37.7 on our GraphQL judge; the frontier model scored 73. The first loop took it to 61.5, and after six loops and 61,000 healed examples, the post-trained model scored 74.5.

GraphQL load test, replaying production traffic with AIPerf: response time per request at the median and for the slowest 1% (p99), and serving cost compared with the frontier model.

The post-trained model is also much faster. In an AIPerf replay of production GraphQL traffic, post-trained Nemotron returned a full response in 0.87 seconds at the median, against 6.50 seconds for the frontier model’s API, and its slowest 1% of requests finished 8× sooner. It also beat another post-trained open model of comparable size, which was close at the median but more than twice as slow at p99.

Serving cost on that traffic is about 90% lower than the frontier model’s. Across our post-trained models, self-hosting cuts serving cost by 90-98% compared with frontier model pricing.

Frontier intelligence, specialist efficiency

The frontier model keeps the work it’s best at: talking to the merchant and deciding what to call. The token-heavy specialist work moves to open models we own, and every turn of the flywheel compounds: human corrections sharpen the judge, production traffic grows the training set, and each generation of NVIDIA hardware and software makes the next loop faster and cheaper to run.

Announcing DuckDB 2.0.0 LTS “Cinnamon Teal”

TL;DR: The DuckDB team is happy to announce that today we're releasing DuckDB version 2.0.0 LTS, codenamed “Cinnamon Teal” (Spatula cyanoptera). This is our biggest feature release so far, and it ships a polished version of the Quack protocol, asynchronous I/O, a first-class VARIANT type, agent mode, triggers, an extensible SQL parser and much more, built from close to 20,000 commits since DuckDB 1.5.

We are proud to release DuckDB 2.0.0, codenamed “Cinnamon Teal” after the Spatula cyanoptera, a strikingly reddish-brown duck found in the western Americas.

While DuckDB 1.0 was all about stability and backward compatibility, DuckDB 2.0 is above all a feature release. In this blog post, we summarize the highlights and then walk through the breaking changes and how to migrate. We showcased many of the new features in “A Preview of DuckDB v2.0”, which covers each one in more depth. For the complete release notes, see the release page on GitHub.

Tip: To install the new version, please visit the installation page. Some clients, such as the CLI and Python, are already available. Other client libraries (e.g., R and Rust) and some extensions can take a few days to release due to the extra changes and review rounds required.

With this release, there are currently three DuckDB lines available. DuckDB 2.0 is a long-term support (LTS) release with support until at least October 2027. The previous LTS release, version 1.4, is still supported until November 17, 2026. To ensure a smooth transition and allow sufficient time for testing, we extended the support period of DuckDB 1.5 until March 2027, effectively also turning it into an LTS release.

DuckDB as a Server

DuckDB has been an in-process database since day one. In DuckDB 1.5.3, released in May, we introduced the Quack protocol that lets you run DuckDB in a traditional client-server setup, along with the quack extension, which implements DuckDB's native protocol, so any DuckDB process can serve its databases.

Quack and CONNECT

DuckDB 2.0.0 ships a polished version of the Quack protocol with substantial performance and stability improvements. It also introduces the new CONNECT statement that allows attaching and switching to a remote database in a single command for better ergonomics:

DuckDB server

CALL quack_serve(
    token = 'my_token'
);

CREATE TABLE events
    (date DATE, name VARCHAR);

INSERT INTO events VALUES
    ('2027-04-07',
     'DuckCon #8');

DuckDB client

ATTACH 'quack:localhost'
    AS qk (TOKEN 'my_token');

CONNECT qk;
SELECT * FROM events;

┌────────────┬────────────┐
│    date    │    name    │
│    date    │  varchar   │
├────────────┼────────────┤
│ 2027-04-07 │ DuckCon #8 │
└────────────┴────────────┘

For simplicity, this example runs the server and the client on the same machine. By default, the server only listens on localhost. To accept connections from other machines, keep the server on localhost and put it behind a TLS-terminating reverse proxy. The allow_other_hostname option, which exposes the server directly, is only meant for testing.

The CONNECT statement is not limited to Quack: it points your session at any remote database that supports it, including PostgreSQL and MySQL. For these, the new remote pushdown optimizer ships queries directly to the remote server instead of pulling tables over the wire.

Quack in the CLI

The CLI also has shortcuts for setting up a Quack client-server pair: the new -serve and -connect arguments start a Quack server or connect to one directly from the command line:

CLI server

duckdb -serve

CLI client

duckdb -connect

Performance

Asynchronous I/O

DuckDB 2.0 introduces asynchronous I/O for reading Parquet and CSV files, as well as DuckDB's native storage format. The I/O layer now scales independently from the query processing layer, issuing reads in the background and keeping multiple requests in flight. This means far more parallelism for remote reads and dramatically faster queries on object storage such as s3://.

The VARIANT Type Becomes a First-Class Citizen

The VARIANT type stores semi-structured, schema-less data such as JSON while keeping the performance of columnar execution. So you can think of it as JSON on steroids: a VARIANT column can store differently shaped data in every row, but unlike JSON it is not a text format.

DuckDB 2.0 detects the common structure in your data and “shreds” it, so it compresses well and executes fast. The pipeline works end to end, from shredded execution straight out of storage to shredded VARIANT reading and writing for Parquet, backed by a family of variant_* functions.

Agent Mode in the CLI

Coding agents such as Claude Code, Codex and Cursor increasingly drive the DuckDB CLI on their users' behalf. The 2.0 CLI detects when it is being run by an agent and switches to agent mode: it prints compact Markdown tables instead of padded boxes, says clearly when a result was truncated, stops runaway queries early and reports errors as JSON.

Extensibility

A Brand New SQL Parser

DuckDB has always used a parser derived from PostgreSQL's. In 2.0, our own modern, extensible PEG-based parser, which debuted as an opt-in feature in DuckDB 1.5, becomes the default. Extensions can now hook into the grammar itself, so expect extensions that expose entirely new SQL syntax. Error messages now come with precise source locations. The new parser is designed to be compatible with the old one, apart from a few deliberate changes listed in the migration guide.

Write Extensions Once and Host Them Yourself

DuckDB 2.0 ships a revamped C API v2, which is considerably more powerful than its predecessor and exposes components such as file systems and table functions to extensions.

You can also register and host your own trusted extension repositories, so an organization can host and sign its own extensions and have them install and load just like the built-in ones:

SET allow_extension_repositories = 'allowed';

CREATE EXTENSION REPOSITORY my_repo
    WITH PREFIX 'https://extensions.example.org';

INSTALL AND LOAD my_ext FROM my_repo;

Core Extension Updates

• We released DuckLake 1.1, including a new specification and reference implementation.
• The Iceberg extension strives to become a feature-complete implementation.
• The Delta extension can create Delta tables with CREATE TABLE (including partitioning and Delta table properties), supports time travel and improves VARIANT support.

SQL Features

Triggers

DuckDB 2.0 delivers triggers: the CREATE TRIGGER statement with BEFORE and AFTER triggers, FOR EACH ROW and FOR EACH STATEMENT, transition tables via REFERENCING OLD/NEW TABLE, multiple triggers per event, RETURNING on triggered tables and DROP TRIGGER.

SQL Dialect Additions

• The $variable shorthand lets you write $x in most places where an expression is allowed, instead of getvariable('x').
• Data-modifying CTEs let you use INSERT, UPDATE, DELETE and COPY as pipeline steps.
• NEAREST joins turn top-k similarity search into a join clause.
• Nested schemas allow schemas within schemas, e.g., CREATE SCHEMA finance.reports.
• JSON mutation functions json_set, json_insert, json_replace and json_remove return modified copies of JSON documents.

Migrating to 2.0

DuckDB 2.0 comes with a small set of breaking changes. For most users, upgrading is straightforward, but complex deployments running many DuckDB processes need more care. The storage format is the most likely source of problems: DuckDB versions before 2.0 cannot read database files created by DuckDB 2.0.

Internals and Deprecations

Compiler Requirements

Following DuckDB's long stint on C++11, DuckDB 2.0 now requires a C++17 compiler.

Timezones, Calendars and Collations Without ICU

Timezone-aware timestamps, calendars and collations have always been powered by the ICU library. In 2.0, the ICU library is gone entirely: the icu extension now implements timezones, calendars and collations itself, with the timezone data built directly from the IANA database.

Deprecations

Lambda Syntax

The old single-arrow lambda syntax (x -> x + 1) is now disabled by default. Use the Python-style syntax instead.

Amalgamation Builds

The amalgamation build, which bundles DuckDB's entire source code into a single header and a single source file, is now deprecated.

Gradual Phase-Out of macOS x86_64

We are gradually phasing out osx_amd64 from the list of fully supported platforms. DuckDB 2.1 will stop supporting osx_amd64.

Summary

These were a few highlights, but there are many more features and improvements in this release. There have been almost 20,000 commits by many contributors since DuckDB 1.5, shipping smaller features as well as performance and usability improvements.

Fast is a design decision

Building a site has never been cheaper, but making it fast still costs attention and your user's resources.

Once upon a time, there were 3 designers who worked together but seperately in Enterpriseland. They shipped products for stakeholders to view actionable insights and make informed strategic decisions. The first designer setup design weekly standups with the whole team but used 2 whole hours to argue for diverse states in every data display. The second designer spent months deliberating over font faces from available repositories and ended up creating their own from scratch. The third designer spent their time on delivery and shipped specs with the team that pushed the cutting edge of what UX meant with microinteractions, animations, and motion design.

In Enterpriseland bureaucracy runs the show: designers deliberate with PMs and engineers on the final state, and eventually they get what they want. But the users suffered: they would spend up to minutes at a time waiting for their dashboards and applications to load up. The users came from all places, and nearly all of them did not care for the designers’ work, but rather the job they needed to accomplish. The designers learned about this, only as they got allocated to other workstreams and had no capacity to fix these issues.

And they all lived happily ever after…?

Everyone is a builder now

A year ago a portfolio, landing page, or a small product/prototype meant either using a template or a few weekends. Now it’s a paragraph typed into a prompt box. That’s great. More people are making things for the web than ever. Plenty of them are designers who used to hand a mockup across the table and had to wait for the final result.

What the prompt box doesn’t ask is how the thing should perform. Not many think first to write “make sure the largest image isn’t lazy-loaded” or “serve the HTML from somewhere near my visitors” in their first prompt, so the generated site rarely touches this process. It looks right on the laptop it was built on, with everything already cached from the last 40 or so previews. That’s the best case. A visitor on a three-year-old phone, on a train, opening your site or app for the first time is the worst case.

Building has gotten cheap. But a slow page still costs something (TINSTAAFL): the visitor pays by waiting.

I built a panel on my site to track how my site’s taste and resource needs compares against the reality of the web. It’s under “Performance” in the menu. It lists how long the server took to answer, when the first and largest things painted, how many bytes came down, how much of it was JavaScript, and frame rate while a user scrolls. The browser measures all of it. And figured, why not include it in a transparent way that everyone can audit?

Where the time goes

A page load is a chain of small trips. Every link in it can be slow. If you’re building with an agent, these are the ones worth understanding because you can simply ask your agent about them:

Distance

A little physics first: light in fibre covers roughly 200 km per millisecond, and a fresh HTTPS connection needs a few round trips before the first byte of your page can leave the server. From Sydney to a single server in Virginia and back is about 16,000 km before any routing detours. A visitor there likely waits most of a second before anything can paint. No framework unfortunately fixes the rules bounding our physical world.

What CAN fix this is putting a copy of the page closer. A CDN (like Cloudflare, Fastly, or Vercel’s edge network) keeps your content files cached in data centers across the world, so the round trip is to a building in your visitor’s region rather than to where your local server happens to be.

My site works this way, primarily because it is content-heavy, relies on Cloudflare to serve photo and video content from its resources, saving my users time on downloading these resources to their machine.

Where the HTML comes from

There are three ways to put words on a screen, and they cost very different amounts:

• Built ahead of time: the HTML is generated once when you deploy and served as a file. My personal site works this way (Astro, built to static files, served from Cloudflare’s edge). The server has nothing to really “think” about before presenting to the user.
• Rendered on the server per request: the server assembles the page every time someone asks. That’s right for anything personal or live, but the server has to do that work on every visit unless you cache the result.
• Assembled in the browser: the server sends an almost empty page and a bundle of JavaScript, so the visitor’s device builds the page itself. Nothing meaningful paints until that bundle has downloaded, parsed and run. It’s also a page that search engines and AI agents may read as empty.

Several of the popular app builders start you on the third option, because it’s the simplest thing to generate and preview. For an app behind a login that might be fine. But for a portfolio, a blog, a marketing page or documentation, it means a visitor’s phone or laptop does work that your build could have done instead.

Caching

Caching decides whether a second visit, or the second page of a first visit, repeats all the work of the first. The rule I follow is to give every file a name that changes when its contents change (most build tools do this for you) and tell browsers to keep those files for a year. Keep the HTML itself short-lived so a new deploy shows up straight away.

I learned that one the hard way: up until this month every file on my site was served with max-age=0, which tells the browser “you may keep this, but ask me first”. So each page view asked about roughly forty files, one round trip apiece. On top of that, every internal link went through a redirect that added a trailing slash, which cost about 800 ms per navigation on a throttled phone.

Weight, and what arrives first

Bytes still matter, but order matters more. The browser can only paint the largest thing on screen once that thing has arrived. If it’s an image you’ve marked loading="lazy" (which is a common default and good advice for images further down the page), the browser waits on purpose.

That was my phone layout’s problem. The first card in the home page’s work carousel was the largest paint on a phone, and it was lazy-loaded at low priority. It was requested at about 1.1 seconds and landed at about 2.5. The fix was to stop treating it like everything else: phones now get a small pre-rendered print of that card, loaded straight away at high priority.

The main thread

JavaScript doesn’t only cost download time. While it runs, the page can’t respond to a tap. Google’s Core Web Vitals call this Interaction to Next Paint, with the ideal benchmark under 200 ms. The usual culprits are big bundles running on load or animations that never stop. I had one of those too: my hero’s animated network kept drawing animations after it scrolled off screen, and so it spent about 446 ms of every five seconds on desktop drawing something nobody could see; twice that on 120 Hz screens. Now there is logic to stop that from happening when off-screen.

Engineering measures, design decides

It’s tempting to treat all of this as an engineering checklist: run Lighthouse, fix what’s red, ship. Engineering is where performance gets measured and tracked, yet someone should own those numbers the way someone owns uptime. From my personal experience, most of the expensive decisions on a page are design decisions that just so happen to have that performance cost.

A full-bleed autoplaying video in a hero is a design decision, done in taste. So is a custom font in four weights, a carousel with media above the fold, scroll-driven animations, or a page that only works once 500 KB of JavaScript has run. None of these are wrong, but each decision is a purchase paid against the visitor’s time and data. Design is the discipline that knows what the page is for, so design should be in the room when deciding what it’s worth spending.

What it’s worth depends on the use case:

• A landing page lives or dies on its first screen. The largest paint (measured by LCP) is the first impression, and every second of it costs you visitors you may have paid to bring there. Consider the minimum size of content required for your user to “get the gist” of your brand or product and how quickly it can be rendered on your target audience’s devices.
• A checkout or a form cares about response to input. A button that takes 400 ms to acknowledge a tap reads as broken, people tap it again, and you may experience edge cases in API submissions. Understanding the length of a call based on these engineering components might help you design a disabled or loading state of your SUBMIT button.
• A dashboard people open every morning can afford a heavier first load if repeat visits come from cache, but every interaction after that should be instant. How does data persist across the user’s workflows or parallel sessions?
• A portfolio is your work. While it’s done with taste, images, logos, videos are your content, so the job is sending the right size of each in the right order. Then you can spend time crafting on how they arrive with performance and device constraints in mind.

If you’re building with an agent

None of this takes a performance engineer. Ask the agent you’re building with these six questions, and it will answer them:

1. Where does my HTML come from? Built ahead of time, rendered on the server, or assembled in the browser? If it’s the last one and the page is public content, ask what it would take to pre-render it.
2. Where is it served from? Is it on a CDN with locations near the people you expect, or on one server in one region?
3. What’s cached, and for how long? Hashed files for a year, HTML briefly. Ask it to show you the Cache-Control headers.
4. What’s the largest thing on the first screen, and when does it arrive? Make sure it isn’t lazy-loaded and isn’t waiting behind a script.
5. How much JavaScript does this page ship, and what is it for? If a page of text needs half a megabyte of it, something is along for the ride.
6. What does it feel like on a slow phone? Open your browser’s dev tools, turn on network and CPU throttling, and load the page cold. Your laptop on fast wifi is the best case you’ll ever see.

Then write a budget down and keep it somewhere the next prompt will see (as context, skills, or however you + your agent work best).

Introducing Flint

Local model with the fastest inference and strongest coding performance in its class. Built with automated research.

Introducing Flint

We’re introducing Recursive Flint, a mixture-of-experts (MoE) model built for fast agentic coding on local hardware. Flint has 40 billion total parameters and activates just 2.5 billion per token. Our small team of people and agents built it from scratch in under four months.

Flint leads MoE models with fewer than 50 billion total parameters on agentic coding benchmarks, including SWE-Bench Pro v2, Terminal-Bench 2.1, and SWE-Bench Verified. It also rivals the coding performance of dense models with 25–40 billion parameters, while running more than five times faster.

With our optimized inference engine, Flint generates more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64GB NVIDIA RTX Spark at short contexts—up to twice as fast as comparable models.

Building Flint was a practical test of Recursive’s Eureka Machine, our system for large-scale automated AI research and development. Our Eureka Machine helped develop nearly every part of Flint’s model-building stack, from data and training recipes to infrastructure and inference optimization.

State-of-the-art local agentic coding performance

Flint is the best-performing MoE model with fewer than 50 billion total parameters on agentic coding benchmarks. It rivals the strongest dense models of similar total size while running significantly faster.

Use Flint as your daily coding model for tasks you want to run locally, without sending your data to a remote server. For complex tasks, break the work into smaller subtasks and provide explicit instructions. While Flint is very capable, it may need more guidance than the larger closed-source coding models you’re used to.

Flint supports context windows of up to 512k tokens. For the best results on coding and other tasks, we recommend staying within 256k tokens.

To turn Flint’s computational efficiency into a faster coding experience, we optimized the entire inference stack—from how its weights are represented to the kernels that execute it on local hardware.

Fast inference on your local AI device

Flint brings strong coding capability to your own hardware, so you can work offline, keep your data on your computer, and avoid API fees.

With our optimized inference engine, Flint runs up to twice as fast as other models in its class on Apple Silicon and NVIDIA RTX Spark. It is also more than five times faster than dense models with 25–40 billion parameters that achieve similar coding benchmark scores.

How we built Flint with automated research

Recursive’s Eureka Machine automates the full research loop: proposing ideas, implementing them, testing them, and using the results to decide what to try next. It explores multiple directions in parallel, builds on earlier experiments, and combines promising ideas.

Our Eureka Machine contributed throughout Flint’s development, from data, optimizers, and training recipes to infrastructure and inference performance. Its discoveries helped our small team build Flint from scratch and reach state-of-the-art results on our target benchmarks in under four months.

Flint’s local inference speed illustrates how these contributions compound across the model-building stack.

Architecture. We started by searching for an architecture that would improve throughput on local hardware by activating fewer parameters per token. Starting from a baseline with 35 billion total parameters and 3 billion active parameters, our Eureka Machine explored different expert configurations and widths. The resulting Flint architecture—40 billion total parameters, with 2.5 billion active per token—was projected to offer the best combination of speed and coding performance among the configurations our Eureka Machine tested.

Quantization. After training, our Eureka Machine searched for quantization recipes that shrink Flint’s memory footprint while preserving its capabilities. Against common practice, it quantized the output layer (lm_head) to 4 bits. Because Flint has only 2.5 billion active parameters, its output layer is a large share of the weights read for each token. To recover accuracy, it added an offline distillation stage in which the quantized model trains on its own pre-sampled responses from a self-discovered coreset, with the 16-bit model as teacher. This nearly halved the number of training steps compared with our quantization-aware training baseline. The final NVFP4 model scores within 0.7 points of the 16-bit model across our benchmarks.

Kernels. Our Eureka Machine then optimized how the quantized model runs on Apple Silicon and NVIDIA RTX Spark. It produced specialized kernels for low-bit projections, MoE operations, attention, and prompt processing, tailored to the model and hardware. On M4 and M5 chips, it produced a Metal megakernel that fuses the entire decode forward pass.

Flint’s inference speed is one example of how our Eureka Machine’s improvements build on one another. We applied the same approach throughout development, combining discoveries across data, training, and infrastructure to improve the final model.

Running Flint

Flint’s weights are available on Hugging Face under the Apache 2.0 license. Download the model, run it locally with your data kept on your device, and adapt it for your own applications.

Flint works with tools and frameworks including llama.cpp, Ollama, Unsloth, LM Studio, vLLM, and SGLang. We’re also releasing rec, a lightweight inference engine optimized for Flint on M4 Pro and M5 Pro/Max, with a simple setup to get you running quickly.

See our documentation for setup instructions and examples.

What’s next

Our goal at Recursive is to build recursively self-improving superintelligence to automate knowledge discovery. We’re starting with model development: building a research process that improves with each model it produces.

Flint is our starting point. Our small team built it from scratch in under four months, with Eureka Machine proposing ideas, implementing them, and testing whether they worked across the model-building stack.

Our bet is that more capable models can make Eureka Machine a better researcher, helping us build the next generation faster and deliver more capability for the same cost. That work will include increasingly capable local models and the infrastructure to run them, as part of a broader effort to advance AI research and development.

Full article content is not available for inline reading.

Read the original article →

Claude Mods: Flipping the Harness Inside Out

Claude Mods is an early form of the Attention Interface. It flips the agent harness paradigm from the harness facing the machine, to the harness facing the human.

For the last few weeks I’ve used Claude Mods to mold Claude Code to my AI engineering workflow. Claude Code is great out of the box, but every engineering workflow is different. Claude Mods let you make Claude Code yours, in the way you want to pay attention.

The “paying attention” part is now the most important thing.

In a recent Latent Space post, The Evolution of the Agent Harness, I argued that as models absorb more of the harness into their weights, the part that’s left faces the human. It becomes the Attention Interface: the layer that decides when the agent interrupts you, what it shows you, and which decisions it needs you to make. Claude Mods are an early version of the Attention Interface, and one you can shape yourself.

Here’s my bet: ultimately, the harness becomes a platform that other companies build on, with models as the engine. Just as the browser became a platform for web apps, the harness could become a platform for the interfaces between people and agents.

Claude Mods: What is it?

A mod is a Claude Code plugin that consists of TypeScript or JavaScript functions that run inside Claude Code. These functions customize the behavior and appearance of the interface in the CLI and Desktop. Mods respond to events, like a prompt, tool call or interface render. They can observe the event, modify how it’s rendered, and handle it in place of the default behavior.

Claude Mods are middleware for the agent harness. They inject code that changes Claude Code’s execution and rendering flow, changing how the application behaves at runtime.

Claude Mods let the human and the agent build the human-facing part of the harness together. You can now work with Claude to design how Claude works with you. That is the essence of the “Attention Interface.”

The harness reversal

The agent harness started as an interface between the agent and the machine it runs on. It lets you prompt the agent and the agent then sends commands, edits files and calls tools. Now it’s gradually becoming a way for the agent to interface with the human.

Claude Mods let you reverse the direction of the harness. Rather than the harness pointing from the agent to the machine, you point it from the agent to the human operator, and the harness becomes a way to interface with human attention.

Claude Mods make the human layer programmable, by the human who uses Claude.

Claude can also build mods for you. Claude Code has a built-in skill that teaches it how to build mods, so you can ask for the mod you want in plain language and Claude will build it.

Mods in practice

Some of Claude Code’s own features are already mods. Anthropic has shipped six of them built-in. You can see these by running /plugin and opening Installed, where they’re listed under Built-in:

• agents-md: loads AGENTS.md as project instructions.
• diff: takes over /diff and draws its pane.
• plugin-authoring: gives Claude the skill it uses to write mods for you.
• sec-default: guards what your organization manages from the mods a user installs.
• telemetry: sends the analytics records that Claude Code and its built-in mods log.
• you-should-know: a side agent that shows a note above the prompt when it finds something you might have missed. It’s the only one that’s off by default.

Most of these work in the background, which is interesting because it means Anthropic is building parts of Claude Code as mods — even parts you may not notice. The one I’ve turned on myself is You Should Know.

Here are the two mods I’ve found most useful in practice: one a built-in, and one I built myself.

1. You Should Know

This is a native Claude Code plugin built by Anthropic. It runs a side-agent that observes the main agent while it works and flags important information you’re likely to miss. Think about it like: tool calls and decisions that have a material impact on the output, but aren’t necessarily easily visible because they’re buried in the agent trace. It comes built into Claude Code, but it’s off until you turn it on.

Here’s a real example. I asked Claude Code to simplify the noisy UI text in one of my personal projects. The main agent trimmed the copy on the Compare screen, installed the new build and took before-and-after screenshots. Everything looked done.

Then You Should Know flagged something for me. CompareView.swift, the file the agent was editing, already had uncommitted work in it — and so did about 45 other files. If I later discarded the demo edits, I’d throw away that earlier unfinished work too. Its suggestion was to commit or stash the earlier work first.

In this case, the You Should Know mod saved me from discarding work unintentionally.

2. Next Steps Supervisor

This mod only runs after a turn that edited files, ran commands or made 8 or more tool calls. In the screenshot below, you’ll see six different pieces of information flagged for your attention. Next Steps Supervisor then suggests a next step to take, as a clickable button which sends the instruction as a message to Claude Code. This mod is available as part of ModSmith — an open-source Claude Code plugin I built with several different built-in mods, as well as a template Claude can use to build new mods that work together.

Attention Interfaces elsewhere

Anthropic isn’t the only company that’s building an Attention Interface. Two recent products, one from OpenAI and one from Cursor, point in the same direction. Using the new ChatGPT Intelligent UI and Cursor’s PR Routing & Approval as a frame of reference shows what’s unique about Claude Mods.

ChatGPT’s Intelligent UI

On October 7, OpenAI shipped GPT-6 inside ChatGPT alongside a new ChatGPT interface it calls Intelligent UI. Rather than answering only in text, ChatGPT now can generate an interface as it answers: charts, maps, checklists, forms, and small tools like a bill splitter or a savings calculator. All generated on the fly by the model as a type of generative UI.

In one of OpenAI’s examples, ChatGPT replies with multiple-choice follow-up questions to narrow down what you’re looking for. Think about it like: the model decides when it needs your judgment, then builds the interface for you to give it.

That’s an Attention Interface. The agent designs how you interact with its response.

But notice the difference between ChatGPT’s Intelligent UI and Claude Mods. For Intelligent UI, the model picks the interface, answer by answer, from a component library that OpenAI built. The one control mentioned at launch is turning the visuals down.

Cursor’s PR Routing & Approval

Cursor is working on the same problem from the other end: not one person and one answer, but a team and a stream of pull requests, more and more of them written by agents. Someone has to decide which changes deserve the attention of the human-in-the-loop.

PR Routing & Approval makes that decision. It assigns reviewers based on code ownership and commit history, and it can auto-approve low-risk PRs. It weighs a risk score against a threshold you set, findings from Cursor’s Bugbot and Security reviewers, and policy files that live in the repo.

One rule caught my attention during research. If a PR edits an approval policy, the agent won’t use the edited version to relax review on that same PR. It reads the policy from the base branch instead. That means an agent can’t change the rules to get its own PR approved.

Cursor is also clear about the limits. Its docs say the feature “does not replace a full code review.” The point is to spend human review where it matters, not to remove it.

Differences between the 3 systems

All three systems shape what gets your attention and how. The main difference is who gets to design the Attention Interface.

• ChatGPT Intelligent UI: the model designs the interface for each answer, inside a frame the lab built. Zero setup, but little control. (I don’t believe the target user is engineers.)
• Cursor PR Routing & Approval: the team writes policy, and a fixed review workflow enforces it. Configurable, but the flow of the interaction is Cursor’s. You decide the rules, not the interface.
• Claude Mods: you and the agent build the interface itself, in code. A mod can hook into any point in the loop — from the prompt you submit to the tool call the agent makes to the moment a turn ends — and decide what to show you there and what you can do about it.

The supervisor I showed earlier is a good example. Cursor could easily route a PR to me because of the files it touched. ChatGPT could just as easily render the verdict as a nice card. But neither would let me decide that every turn which edits a file gets a second opinion, that the opinion lists shortcuts taken, and that each suggested next step is one keypress away. That interface exists because I prefer to pay attention that way, and Claude built it with me.

ChatGPT and Cursor give you an Attention Interface that someone else designed. Claude Mods let you design your own with Claude, but the tradeoff is you’re responsible for making it useful.

What’s wrong with Mods

Mods aren’t free, and I’ve run into some downsides.

The first is noise. Next Steps Supervisor runs after any turn that edits a file, runs a command or makes 8 or more tool calls. In practice, that’s nearly every turn. Since I installed it on October 15, 99 of my 111 turns in Claude Code met that bar. Some of those verdicts are useful, others are just noise. So when a mod speaks up on almost every turn, I start skimming past it — which defeats the point of an Attention Interface.

The second is cost. Each supervisor check forks the conversation and re-reads it. Most of that is served from the prompt cache, but the mod’s own README estimates about 5–6k input-equivalent tokens per check on a 50k-token session, and more when the cache has expired.

The third is trust. A mod is code that runs with your permissions. Anthropic’s docs are clear about this: once it loads, a mod can read and write your files, see every prompt you send, and spend your usage. Plus, “mods aren’t sandboxed.” Built-in mods also keep running when you start Claude Code with --safe-mode. I’m comfortable with mods I wrote or that ship with Claude Code, but I’d read anyone else’s code before installing it.

The upside is that mods are fixable in a way other tools aren’t. When the supervisor is noise for a session, /supervisor off turns it off. Because it’s my mod, I can change when it runs.

Where this goes

Customizing the harness isn’t guaranteed to be a win for every individual engineer. Every mod I add is another piece of information I need to give my attention to. In one of my own sessions, my Next Steps Supervisor marked a task as “Solved” yet also listed two gaps and three shortcuts. Agents are intelligent but far from perfect, and my attention is far from perfect too.

So the test I use to gauge the usefulness of my mods is simple: did it surface something I would have missed, make a decision easier, or let me act without getting distracted by more output? If not, it’s just window-dressing rather than a useful tool.

Right now, building a mod works like this: I notice friction in how I work with Claude, describe the mod I want, and Claude builds it with me. My personal attention is still needed to notice the friction.

The next step is for the harness to notice the friction. Claude Code already keeps my session transcripts. Think about it like: a background process reads through them, finds the places where I keep correcting the agent or checking the same thing by hand, and suggests a mod for it. Then it helps me test that mod and refines it from my feedback.

That’s the best case for AI engineers: a malleable harness that suggests ways to improve itself from real-world use. Claude Mods are a step in that direction.

If the bet I made at the start is right, in a few years we will talk about the startups that were built on Claude Code, or Codex, or a harness that doesn’t exist yet.

I’ll leave you with a question, where the answer hopefully provides you with practical value: what friction have you noticed working with Claude Code that this article can inspire you to solve with a mod today?

Full article content is not available for inline reading.

Read the original article →

API version 2026-10-21 is now available.

The Claude API has evolved a lot, but this is our first official version release since 2023. We plan to release versions more often so you can handle breaking changes before a new model requires them.

2023-06-01 is not deprecated. What changes in this version:

• temperature, top_p, and top_k are removed from the Messages API
• documents in assistant turns and citations in user turns return a 400
• a few deprecated Admin and Enterprise Analytics API fields are replaced

New major versions of the Anthropic SDKs and the ant CLI are out today and default to 2026-10-21.

You can use the /claude-api skill in Claude Code to update, or walk through each change in the migration guide: platform.claude.com/docs/en/api/migration-2026-10-21

Ant Group and the vLLM community are open-sourcing Humming, a general-purpose, high-performance kernel library for quantized inference. Humming offers the following features:

• Broad device support: Supports NVIDIA GPU architectures from Turing onward, along with CUDA-compatible devices such as T-Head's Zhenwu 810E.
• Extensive quantization support: A unified architecture supports diverse combinations of weight and activation formats for dense and MoE workloads, covering a wide range of integer and floating-point types, bit widths, and scaling schemes.
• Strong execution performance: Significantly outperforms existing implementations from vLLM Marlin, FlashInfer, and DeepGEMM across many representative workloads.

Repository: github.com/vllm-project/humming

Background

As models and inference workloads grow, memory capacity, memory bandwidth, and compute costs increasingly constrain deployment. This is especially apparent in MoE models: each token activates only a subset of experts, but the full set of weights still needs to be stored. DeepSeek-V3, for example, has 671 billion parameters, with 37 billion activated per token. Quantization lowers the precision of weights and activations to reduce memory usage and data movement, and can also improve compute efficiency.

Quantization requirements vary across models and GPU generations. Common configurations include WNA16, W8A8, W4A8, and W4A4, where W and A specify weight and activation bit widths, and N denotes a variable weight bit width. Even at the same precision, schemes such as INT4 and NVFP4 differ in numeric format and scaling. Scaling granularity, scale representation, group size, and symmetric or asymmetric quantization further expand the configuration space.

These storage and compute savings only translate into lower latency and higher throughput with efficient kernels. Prefill, decode, and varying MoE expert loads place different demands on compute and memory. Kernels must adapt to these workloads while keeping conversion, dequantization, and scheduling overhead low.

Developing and integrating a dedicated kernel for every combination creates a growing maintenance burden. Each addition can require its own weight preprocessing, kernel selection, framework adapters, and tests. Optimizations must then be carried across multiple implementations.

Humming addresses this problem by separating quantization descriptions from execution choices and composing kernels from shared components.

General-Purpose Architecture

Humming's execution path has three parts: represent the quantized computation, select configurations for the hardware and workload, and compile a kernel from CUDA components.

A Unified Quantization Representation

Models exported by different quantization tools vary in numeric format, parameter organization, and weight layout. Humming converts supported export formats into the Humming standard format: a common quantization description with consistently organized weights, scales, zero points, and other tensors.

This representation preserves each scheme's quantization semantics while describing weight format, scaling granularity, scale data type, zero points, and secondary scales as separate parameters. Activations have their own numeric format and quantization settings. These parameters can be combined subject to format and hardware constraints.

For example, groupwise INT4 weights can be paired with BF16 activations. Low-precision floating-point weights with different scaling schemes use the same parameter system. This gives inference frameworks a common interface for models from different sources.

Tuning and JIT Compilation for Each Workload

The standard format provides a common representation across export formats. Preprocessing then validates parameters, pads dimensions, and repacks these tensors into layouts suited to the target kernel. Humming combines the quantization description with the weight shape, GEMM type, target GPU, and compute options to configure execution.

Three configurations describe the kernel:

• Layer Config describes tensor shapes, data types, quantization parameters, and the target architecture.
• Compute Config specifies the GEMM type and computation options, such as batch invariance and input scale layout.
• Tuning Config selects tile shapes, pipeline stage counts, warp specialization, memory access, and MMA instructions. It also controls concurrency and scheduling; TMA can be configured per tensor.

By default, Humming selects tuning configurations using device-specific heuristics. It can prepare different configurations for ranges of input sizes and dispatch to the appropriate kernel at runtime.

Humming’s unified architecture makes it straightforward to tune execution parameters and select pipelines for different workloads. At small batch sizes, a multistage pipeline using asynchronous copies (cp.async) and MMA can outperform a pipeline built around TMA and UMMA. At larger batch sizes, TMA and UMMA can offer better throughput. Humming accommodates both execution paths within the same configuration and component framework, allowing it to select the more effective strategy for each workload.

Together, the three configurations specialize kernels compiled with NVRTC or NVCC. Compiled kernels are cached for reuse. Inference combines the selected kernel with the preprocessed weights and runtime activations.

Shared CUDA Components Across Formats and Architectures

At the CUDA level, Humming organizes task scheduling, data movement, dequantization and scaling, Tensor Core computation, and output processing into reusable components. It provides standard, warp-specialized, and dedicated UMMA pipelines. These pipelines share compatible components while using the dataflow and synchronization required by each execution strategy.

Each group of components handles a different source of variation:

• Numeric processing handles quantization formats. Decoding and arithmetic components account for bit width, integer or floating-point representation, scales, and zero points. Dequantization and scaling are integrated into the kernel's computation.
• Memory and compute backends handle GPU architectures. Humming selects data movement and Tensor Core implementations for the target architecture, using asynchronous copies, TMA, and multicast where supported.
• Task mapping and scheduling handle dense and MoE workloads. Each GEMM type uses the appropriate scheduling logic. Scaling and bias addition can also be fused into the output stage.

JIT compilation combines these components according to the three configurations and eliminates unused implementation branches. A new format or architecture can therefore be supported by extending the relevant components. Improvements to a shared component benefit compatible configurations, reducing the duplicated development and maintenance of separate specialized kernels.

This CUDA implementation is lightweight and avoids heavyweight kernel framework dependencies, keeping JIT compilation fast as well. In our single W4A16 kernel compilation test on an H200 server with CUDA 13.4, compilation time dropped from 23.35 seconds for CUTLASS with NVCC to 1.82 seconds for Humming with NVCC or 1.88 seconds with NVRTC, with compilation caches disabled. This reduces the cost of preparing kernels for new workloads and makes iterative tuning more practical. Humming also compiles kernels in parallel during model warmup. In our tests, compiling and loading the kernels covering all supported M sizes for a single layer's GEMM takes only about 2–4 seconds, making it practical to prepare multiple specialized kernels before inference.

Performance Tuning Based on Device Parameters

Humming deeply optimizes kernels using both the GEMM configuration and device parameters. Quantization formats, matrix shapes, GPU instruction support, SM count, shared memory, and register resources all inform execution choices, turning the benefits of low-bit storage into practical inference performance.

Efficient W4A8-MXFP4 inference on existing GPUs. Architectures before Blackwell lack native MXFP4 Tensor Core support, and conventional W4A8-MXFP4 kernels can be limited by dequantization and scaling overhead at larger M. Humming addresses this with a fast MXFP4-to-INT8/FP8 dequantization path that converts MXFP4 weights into a supported compute format within the kernel. In this setting, the path substantially outperforms conventional W4A8 implementations at small M and approaches W8A8 performance at large M. GPUs such as H200 can therefore run high-performance W4A8-MXFP4 kernels while retaining the storage benefits of 4-bit weights.

Dequantization paths matched to each device. The same quantization format can benefit from different implementations across GPUs. Humming selects decoding, numeric conversion, and scaling paths for the device, pairing them with suitable memory access and compute pipelines to reduce instruction and data movement overhead. Shared components make these optimizations reusable across compatible dense and MoE kernels.

Extensive tuning controls with device-specific heuristics. Humming exposes tile shapes, pipeline stage counts, warp specialization, TMA, MMA instructions, CTA concurrency, and Stream-K scheduling. Device-specific heuristics combine GEMM shapes with resource constraints to balance parallelism, data reuse, and pipeline overhead, selecting different execution strategies as input sizes change. Developers can use the default configurations directly or refine them for particular models and deployment scenarios.

Results

Broad Device Support

Humming's unified architecture enables broad GPU support. For NVIDIA GPUs, Humming fully supports every architecture from Turing onward, bringing a common quantized computing framework to multiple generations of hardware.

The unified JIT architecture also makes it straightforward to extend Humming to other GPUs compatible with CUDA programming. Humming already fully supports T-Head's Zhenwu 810E, bringing its shared kernels and tuning capabilities to more hardware platforms.

Quantization Support

Humming's support for quantization types depends primarily on compatibility between activation and weight types. Its unified quantization representation and kernel architecture allow a wide range of integer and floating-point weight formats to work with activations at different precisions, providing flexible choices for model precision and deployment performance.

Humming also supports a special floating-point format with zero exponent bits, whose representable values match those of symmetric integers at the same bit width. For example, INT8 excluding -128 and float8e0m7 both represent integers from -127 to 127. Weights in this format have the same activation type compatibility as INT weights of the same bit width. Humming automatically converts eligible symmetric integer weights to this format for faster dequantization.

The community has also uncovered two hidden capabilities in Blackwell Tensor Cores: native support for float4e0m3 and float8e3m4, two special floating-point formats that are not exposed in the PTX type system. Humming supports these features across all Blackwell architectures, including datacenter SM100/SM103 and SM120/SM121 devices for workstations and personal computing. Both formats are integrated into its unified quantization and compute framework, providing more native compute options for low-precision inference. Rubin does not support these two hidden Tensor Core formats, so support for these native compute paths does not extend to Rubin.

Performance

WnA16

WnA16 is one of the most versatile and widely used approaches to quantized inference. It combines low-bit weights with FP16/BF16 activations, reducing weight storage and memory traffic while making use of widely available 16-bit compute capabilities. This makes it suitable for many GPU generations and model deployment scenarios. The W4A16 family has attracted particular interest from the community and is a major focus of Humming's optimization work.

For dense W4A16, Humming matches or outperforms vLLM Marlin in most tested configurations, with substantial gains on several Hopper and Blackwell workloads. At small batch sizes, Humming delivers roughly 3–4× speedups on several devices. As batch size grows, it continues to use the hardware efficiently, reaching approximately twice Marlin's performance on large-batch H200 workloads and more than three times its performance in some B300 cases.

These gains extend to MoE. Humming provides efficient Indexed and Grouped paths for workloads where tokens are distributed across experts and the amount of work per expert changes with the load. On H20 and H200, MXFP4 W4A16 reaches roughly twice Marlin's performance in several medium-to-large batch cases. On B300, the MXINT4 and NVFP4 paths achieve even larger gains at large batch sizes, with the Grouped path reaching approximately 5×. Results on SM120 and SM121 also show Humming outperforming Marlin and the corresponding FlashInfer implementations across a range of workloads.

Humming's optimizations also extend beyond W4A16 to other WnA16 combinations. Its shared dequantization and compute paths deliver strong performance for integer and floating-point weights at different bit widths, including INT1, INT2, INT3, and FP4 through FP8.

W8A8 / W4A8 / W4A4

With Hopper, FP8 W8A8 with blockwise scaling became a mainstream approach to high-performance quantized inference. Humming further improves this established compute path by optimizing data movement, scaling, and expert scheduling together. At small and medium batch sizes, Humming reaches approximately 2.6× and 2.5× the performance of DeepGEMM Contiguous, respectively, with competitive performance from both Indexed and Grouped layouts.

As more models adopt native MXFP4 weight quantization, converting the smaller weight footprint into practical inference gains becomes increasingly valuable. Humming addresses this with an efficient W4A8 path that rapidly dequantizes MXFP4 weights as they are loaded and uses FP8 Tensor Cores for computation, enabling efficient W4A8-MXFP4 execution on Hopper. At small and medium batch sizes, Humming's W4A8 reaches approximately 4.2× baseline performance on H20 and 4.5× on H200, also substantially outperforming Humming's W8A8 results.

On B300 (SM103), Humming demonstrates substantial performance gains across all three MX format combinations. At small and medium batch sizes, W8A8, W4A8, and W4A4 reach approximately 1.25×, 1.6×, and 1.4× baseline performance, respectively, and outperform the corresponding FlashInfer implementations across many workloads. Both Indexed and Grouped paths benefit from native low-precision computation, providing efficient options for different expert layouts.

These gains also extend to SM120 and SM121. Humming's MXFP4 × MXFP8 W4A8 and NVFP4 × NVFP4 W4A4 outperform FlashInfer CUTLASS at most tested points. On SM121 at small batch sizes, performance gains reach approximately 19% for W4A8 and 9% for W4A4; on SM120, Humming also leads across most tested sizes.

End-to-End Inference Performance

Humming's W4A8 gains extend to model serving. In our DeepSeek-V4.1-Flash test on eight H20 GPUs with TP=8, keeping the model's MXFP4 weights unchanged and switching MoE execution from Marlin W4A16 (BF16 activations) to Humming W4A8 (tokenwise FP8 activations) improves end-to-end throughput by approximately 14%–43% and reduces mean time to first token (TTFT) by approximately 25%–32%. The throughput advantage grows with concurrency: at concurrency 64, output throughput rises from 442.37 to 633.94 tokens/s, while mean time per output token (TPOT) falls by approximately 31%.

Usage

Installation

Install Humming with pip:

pip install humming-kernels

Humming uses a CUDA compiler to generate kernels on demand. If no CUDA compiler is available on the system, choose one of the following installation options to include the compilation dependencies for your environment's CUDA major version:

pip install "humming-kernels[cu12]"  # CUDA 12
pip install "humming-kernels[cu13]"  # CUDA 13

Humming itself is extremely lightweight, with simple dependencies and a wheel package of only about 500 KB. On-demand compilation avoids bundling a large collection of precompiled kernels. In principle, any environment capable of running PyTorch 2.7 can also run Humming, making it easy to integrate into existing inference environments.

Using Humming in vLLM

Humming is deeply integrated into vLLM. Starting with vLLM 0.29.0, CUDA installations include Humming as a dependency, so no separate Humming installation is needed. Humming supports NVIDIA GPUs across all architectures from Turing onward (SM75 and above).

The --linear-backend and --moe-backend options select Humming as the compute backend for dense GEMM and MoE GEMM, respectively. For example, enable Humming for both with tensor parallel size 8:

vllm serve deepseek-ai/DeepSeek-V4.1-Flash-1017 \
    --tensor-parallel-size 8 \
    --linear-backend humming --moe-backend humming

The --quantization humming option is intended only as a compatibility path for formats that Humming supports but vLLM no longer supports or does not yet support natively, such as GPTQ INT3.

Selecting Activation Types

By default, Humming uses the activation type specified in the checkpoint and adapts execution to the device. If the GPU does not support that compute type, Humming falls back to a supported higher-precision type. For example, devices without native MXFP4 support can automatically use FP8, BF16, or FP16 compute paths, allowing the same quantized checkpoint to run across GPU generations.

Users can override the default through vLLM's quantization configuration interface to select an activation type for their deployment.

Future Plans

Broader and Deeper Device Support

Humming will continue expanding hardware coverage while adapting to the compute and memory capabilities of new devices, helping more platforms realize the performance potential of quantized inference.

Adding Autotune

Humming plans to introduce autotune, benchmarking candidate configurations on the target device to find better execution parameters for each workload. Autotune will complement existing heuristics, reducing manual configuration search and helping more workloads approach the kernels' best achievable performance.

Deeper Integration with Inference Frameworks

Humming will continue deepening its integration with inference frameworks such as vLLM, expanding support across quantized model loading, backend selection, parallel inference, runtime scheduling, and device adaptation.

Acknowledgments

We thank Jinzhen Lin, Zekai Gu, and Zhilin Huang from Ant Group, as well as Michael Goin, Roberto L. Castro, Chauncey Jiang, and other members of the vLLM community, for their contributions and support throughout Humming's development.

We also thank the vLLM community for providing development, testing, and CI resources that made it possible to validate and improve Humming across a wide range of hardware and workloads.

Humming's design and optimization draw inspiration from Marlin, vLLM Marlin, LMDeploy, DeepGEMM, FlashInfer, CUTLASS, and other open-source projects. We are grateful to their authors and contributors for sharing their ideas and implementations, helping advance high-performance quantized inference for the entire community.

OpenAI coordinated with PHP maintainers and security partners to patch critical vulnerabilities discovered using GPT-5.6 Sol and independently by Wiz. The company also released a PHP vulnerability checker and proposed a framework for coordinating responses to AI-discovered security flaws.

OpenAI CLI

The official command-line tool for the OpenAI REST API.

Call the OpenAI REST API from your terminal or shell scripts. Generate images, upload files, submit batches, and inspect API results without writing an application.

OpenAI CLI or Codex CLI? Use openai when you want to call a specific API or put API operations in a script. Use Codex CLI (codex) when you want a coding agent to work on a project: read and edit code, run commands, and help implement or debug a change.

Things to try

These examples use an API key; see installation and authentication below.

Generate an image and save it locally

openai images generate --prompt "A tiny orange robot watering a houseplant"

Images are saved to ~/Downloads/gpt-images/, and the command prints their paths. Use --output-dir for an existing destination directory or --name for a filename. Supported terminals can preview the result. See the image guide for editing, model selection, and preview settings.

Upload a file and retrieve it later

openai files upload report.txt --purpose user_data
openai files get file-example
openai files download file-example --output downloaded-report.txt

Use your own local file and replace file-example with the ID returned by the upload. See working with files for more examples.

Run requests in a batch

Submit a JSONL request file, then wait for the batch and download its results:

openai files upload requests.jsonl --purpose batch
openai batches create --input-file-id file-example \
  --endpoint /v1/responses --completion-window 24h
openai batches wait batch_example --output-dir ./results

Replace the file and batch IDs with the returned IDs. The batch guide includes a sample requests.jsonl and explains result files and failed requests.

Export API data for a script

openai models list --format jsonl | jq '.id'
openai files list --format json > files.json

Choose --format json for a JSON document or --format jsonl for records. The default output is readable text, even in pipes. The first example uses jq.

Installation

Installing a prebuilt binary

Download the archive for your operating system and architecture from GitHub Releases. Binaries are available for macOS, Linux, and Windows. Extract the archive and place openai (openai.exe on Windows) in a directory on your PATH.

Installing with Homebrew

brew install openai/tools/openai

Installing with Go

Requires Go 1.26 or later.

go install 'github.com/openai/openai-cli/cmd/openai@latest'

Once you have run go install, the binary is placed in your Go bin directory:

• Default location: $HOME/go/bin (or $GOPATH/bin if GOPATH is set)
• Check your path: Run go env GOPATH to see the base directory

If commands aren't found after installation, add the Go bin directory to your PATH:

# Add to your shell profile (.zshrc, .bashrc, etc.)
export PATH="$PATH:$(go env GOPATH)/bin"

The CLI checks for updates on eligible interactive runs; it never installs them automatically. Set OPENAI_CLI_NO_UPDATE_CHECK=1 to disable checks and notices. See update notices for details.

Authentication

Run the setup guide to enter your API key safely:

openai help setup

For scripts, supply OPENAI_API_KEY through your environment or secret manager. Create a key in API settings.

Try a request:

openai responses create \
  --model gpt-5.5 \
  --input "Say this is a test"

Admin endpoints use OPENAI_ADMIN_KEY, a separate admin API key. For example, retrieve one day of organization usage:

openai admin organization usage completions \
  --start-time 1735689600 \
  --end-time 1735776000 \
  --bucket-width 1d

Usage

Commands follow the API's resources:

openai <resource> [subresource...] <command> [flags...]

Browse commands and options with help. Help needs no API key or network connection.

openai --help
openai images generate --help
openai admin organization --help

openai help COMMAND and openai COMMAND --help show the same page. Existing colon-separated commands, such as openai admin:organization:usage completions, also work.

Output and errors

Successful JSON responses display readable text by default. Select a data format explicitly when parsing results. Use --transform to extract fields with GJSON syntax:

openai files get file-example --transform filename --raw-output

Errors go to stderr as readable summaries. Use --format-error json for API error details, or --transform-error to extract error fields. Explicit --format json, jsonl, raw, and yaml also apply to errors unless --format-error overrides them; --format-error text restores summaries. API error details and --debug logs can contain sensitive data: sanitize them before sharing.

Check the command's exit status before using redirected results; a failed request can leave an incomplete output file. See reading command results for list formats, streaming, binary downloads, and error behavior.

File input

Binary uploads take a plain path. JSON input flags can read a value from a local file with @path:

openai files upload report.txt --purpose user_data
openai responses create --model gpt-5.5 --input @prompt.txt

Use OPENAI_UNTRUSTED_STDIN=1 when piping JSON or YAML from an untrusted source so input cannot cause local file reads. In that mode, provide upload paths explicitly as flags. See file arguments and encoding for escaping literal @ values, JSON/YAML input, and text or base64 encoding.

Shell shortcuts

Set up shell completion to complete commands and file paths. Command insertion lets you search examples with Ctrl+X, then Tab and insert them without running them.

The first eligible interactive run saves image-picker Tab shortcuts for future Bash, zsh, and fish sessions. Open a new terminal to use them. See setup and removal for requirements and opt-out. In PowerShell, press Enter after openai images generate to open the picker.

Development

From a clone of this repository, run the CLI with:

./scripts/run --help

To test against another OpenAI Go SDK version, use ./scripts/link:

./scripts/link github.com/org/repo@version
./scripts/link ../path/to/openai-go

With no arguments, it uses ../openai-go. See CONTRIBUTING.md for setup, checks, and repository structure.

Contributing

Please share bug reports and feature requests through GitHub issues. Pull requests are limited to repository collaborators; we do not accept pull requests from non-collaborators. See CONTRIBUTING.md for the contribution policy and development guide. For security vulnerabilities, follow SECURITY.md.

License

Copyright 2026 OpenAI

This project is licensed under the Apache License 2.0.

Computer use on the phone itself: a 2B model that operates Android apps

Opposable is an Android app that reads the screen through the accessibility service and taps and types in any other app. Claude, ChatGPT or Codex can drive it from a computer, and when none of them is connected, a 2-billion-parameter screen model runs the same loop on the phone with no server involved.

TL;DR

The model is GUI-Owl 1.5 2B in 4 bits on llama.cpp. On a Mac M2 CPU with 4 threads one step takes 7.3 s, down from 10.6 s, at the same accuracy on our 36-screen test set. Half of that step is the vision encoder, and on a Galaxy S25's NPU the encoder runs in 236 ms against 3.9 s on the M2.

Model and runtime

GUI-Owl 1.5 comes from Alibaba's Mobile-Agent team. It is a Qwen3-VL fine-tune that looks at a screenshot and answers with one action. We run it in the app through llama.cpp and its multimodal library, quantised to 4 bits: 1.05 GB for the language model and 445 MB for the vision encoder. Both load once and stay in memory between steps.

The model only sees tasks the app can't do another way. About forty common ones, like setting an alarm, texting a contact or switching on Wi-Fi, run as fixed code with no model, and routines that a large agent worked out earlier replay from the text on the screen.

Step time on CPU

A step is three stages. The vision encoder turns the screenshot into image tokens, the language model reads them along with the task (prefill), and it writes about 45 tokens: a sentence saying what it intends to do, then a JSON tool call. With nothing optimised, on the M2 the encoder took 4.6 s, prefill 4.3 s and decode 1.7 s, 10.6 s per step, and the model got 27 of the 36 graded screens right.

Cropping the status bar, navigation bar and keyboard out of the screenshot cut the image before encoding. After the encoder, tokens for patches of flat background that don't border anything are dropped, and the rest keep their original grid positions, so the model sees the same layout with 25 to 40% fewer tokens. That raised accuracy to 28 of 36. The 900-token system prompt is prefilled once and its KV cache kept. At the 400 image tokens the app uses, a step takes 7.3 s and scores 27 of 36.

The model states its intent before coordinates, for example "Action: Click the Files app icon." When that sentence matches exactly one element in the accessibility tree, the app taps the element and stops generating. On the emulator those steps decoded in 0.8 to 1.3 s instead of 2 to 4 s. With all of this in place the encoder took 3.6 of the 7.3 seconds.

Vision encoder on the NPU

We exported only GUI-Owl's vision tower to ONNX: a 24-layer ViT with its mergers, about 0.4 billion parameters, at a fixed input of 416 by 960 pixels. One screen at that size is 542 billion multiply-accumulates. Qualcomm AI Hub compiled it for the Galaxy S25 (Snapdragon 8 Elite) and ran it on a real S25 in Qualcomm's device lab.

In fp16 the encoder ran in 236 ms with all 873 operations on the NPU, about 16 times faster than the M2's 3.9 s. 8-bit weights with 16-bit activations were faster at 213 ms but drifted from the reference output, cosine 0.978 to 0.985 against 0.992 to 0.996 for fp16, and the model's taps depend on small screen details, so the app uses fp16. Fully 8-bit and 4-bit versions scored 0.67 to 0.90. The first load takes 72 s while the NPU prepares the graph, once per install, and 0.39 s after that.

The NPU returns the same float array as llama.cpp's own encoder, so pruning, positions, the cache and the early exit work unchanged. At startup the app tries the NPU, then the GPU through LiteRT, then the CPU, and an encoder is used only if it passes a self-test on a bundled screenshot (cosine 0.97 or better against the CPU encoder) and is faster than the CPU. The 640-token input size failed to compile for the NPU, so steps that need it still encode on the CPU.

Accuracy on held-out tasks

On eight tasks the model had never been tuned on, run on the emulator twice each, giving it the whole task succeeded 4 and 3 times. Giving it one subgoal at a time and checking each claimed success against the accessibility tree before the next subgoal succeeded 6 times in both rounds.

Limitations

Only Snapdragon has an NPU build so far. Pixel phones need a separate compile for Tensor, and MediaTek and Exynos need their own, so those phones fall back to the GPU or CPU. The model is also much weaker than a cloud model on apps it hasn't seen, and the app hands those tasks to Claude, ChatGPT or Codex when one is connected.

Trying it

The Android app is free at getopposable.com. The screen model is a 1.5 GB download from its settings, and the same screen shows which encoder your phone picked and how long a screen takes to encode. I'd like to hear both from your phone, at hello@getopposable.com.

Anthropic's Claude Duet joins a fast-growing field of AI assistants that take actions and perform tasks on their own. Unlike OpenAI's dots and Meta's Muse, Anthropic's agent was built for work and is less capable at personal errands. It can connect to more than 6,000 outside apps and make purchases through Link, Stripe's digital wallet, and Shopify's Shop Pay. The agent shows users exactly what it plans to do before performing actions, and some actions, like trading stocks or moving money between accounts, are blocked even with user approval. The wait list to use the agent is now open to Anthropic's Pro and Max plan subscribers.

Tesla has started production of its Optimus humanoid robot at its factory in Fremont, California, in a manufacturing space once dedicated to making electric vehicles, the company announced Wednesday.

“The bots coming off this line are the first production-quality bots that we have manufactured,” Tesla wrote in its third-quarter letter to shareholders. “While we will continue to iterate on the hardware and manufacturing process, we have proven that the current manufacturing process for Optimus is suitable for a commercial product.”

Tesla CEO Elon Musk said on a conference call that he considers this “early production” and that the ramp will be slow and “somewhat bumpy because it is such a radically new product.” He nonetheless claimed Tesla will be able to make 20,000 of them per week by the end of 2027.

“There’s still some things we need to tweak about the design, because you need to deliver a robot that is safe and reliable and has long duration, so it can’t, like, wear out after a month,” he said. “And there’s still quite a lot of work to do with regard to the AI and the robot for it to be truly useful for open-ended tasks.”

That forward-looking development wasn’t enough to lift the company’s otherwise middling third-quarter earnings, results that typify a company in the midst of a major bet. Tesla’s revenue was flat and its expenses skyrocketed as it pressed the accelerator on its Optimus robots, AI, and autonomous driving. The end result was a 43% drop in profits.

The company’s revenue was largely driven by EV sales, which were flat year-over-year at $20 billion. Tesla delivered 486,532 vehicles in the third quarter, about 6,000 more than the previous quarter, but fewer than in the same period last year.

Tesla’s total third-quarter revenue was $28.04 billion, a skosh below the $28.09 billion it generated in the third quarter of 2025. Tesla’s third-quarter revenue was also about $200 million lower than the previous quarter’s haul of $28.23 billion.

Tesla saw a 16% year-over-year decline in revenue from its solar and energy storage business to $2.8 billion, which it blamed on tariff-related customer refunds. There was some positive revenue growth in its services business, a category that includes customer subscriptions to its Full Self-Driving advanced driver-assistance software. Tesla’s services business grew 33% year-over-year, bringing in $4.6 billion and accounting for a record $734 million in gross profit for the quarter.

None of this was enough to outpace Tesla’s spending on artificial intelligence projects and its Optimus robot, which took a big bite out of profits.

The company reported $787 million in net income, a 43% drop from the same period in 2025, when it earned $1.37 billion. Lower regulatory credit sales also put pressure on its profitability.

Tesla executives on the earnings call, including Musk, CFO Vaibhav Taneja, and Ashok Elluswamy, vice president of AI software at Tesla, all took bullish positions on the company’s FSD product, even as the timeline to give consumers the “unsupervised” version was delayed yet again. Today, Tesla owners can subscribe to a supervised version of the software that requires the driver to pay attention and be ready to take over at any time. The unsupervised version would be the equivalent of Level 4 autonomous driving capabilities similar to those used in robotaxis.

“We suspect somewhere around Q2 next year is when we can turn on some of the first customer vehicles to be part of the robotaxi fleet,” Elluswamy said, referring to when privately owned Tesla vehicles equipped with FSD (Supervised) would receive a software update enabling unsupervised driving.

Musk said during the company’s earnings call in April that the unsupervised version would “probably” be released in the fourth quarter of this year.

This story has been updated with information from Tesla’s quarterly conference call.

Git traffic grew exponentially over the past year. During that time, GitHub started moving almost all of its repositories to Azure. This post discusses how per-reference quorums will bring over the rest, and how object storage lets reads scale independently.

It’s 7:40 on a Tuesday morning in 2031, and you haven’t written a line of code yet. You probably won’t today, and that’s fine.

While you slept, four agents worked through the backlog you sorted yesterday afternoon. Three of them finished. Their pull requests are waiting for you, each with the tests it added, a short recording of the feature working, and a note about the parts it wasn’t sure of. The fourth agent stopped at 2:13 a.m. and left you a question instead:

The spec says refunds go back to the original card. This customer’s card expired in March. What should happen?

The agent could write refund code all day long. What it can’t do is decide what your company owes a customer whose card has expired, so it stopped and asked, which is exactly what you’d want from a new hire too. Your morning goes like this: you read three pull requests, you go and talk to someone in support, and you write the rule down so clearly that nobody (human or otherwise) has to guess again.

I made that Tuesday up. None of it is science fiction, though. Agents that work unattended overnight exist today, and one of them runs on my own machine every night at ten. It invents a small project, builds it, tests it, and I find out what it made over breakfast. The first morning, I had no idea what it had built. That build is now Rule Safari, a live project on this site, with an article explaining how it works.

So is this the end of programming? People have been asking that for more than seventy years. I find that comforting. I also find it a little suspicious.

Programming has been ending since 1954

On 10 November 1954, IBM’s Programming Research Group finished a preliminary report on a new language called FORTRAN. One sentence in it says that FORTRAN “should virtually eliminate coding and debugging.”

I love this sentence. It’s so sure of itself, and it even came with a budget: problems solved “for less than half the cost” of doing it without FORTRAN. The industry had a name for this kind of thing back then. Assemblers and compilers were called automatic programming. You’d describe what you wanted, and the machine would write the program.

FORTRAN shipped in 1957, and it really did eliminate a kind of coding. Almost nobody translates formulas into machine instructions by hand anymore. Debugging survived just fine. (This month I chased a Scry bug that came down to a bookmark saved only every twelve hours, so I can confirm debugging is alive and well.)

What FORTRAN actually did was take one tedious part of the job away and move the job up a level. People stopped thinking about registers and started thinking about bigger problems. Programs got cheaper to write, so everybody wanted more of them. That has happened over and over since.

My favorite rung is 1981. A British company called D.J. “AI” Systems (yes, really) sold a BASIC program generator named The Last One. The name was the whole pitch. It would write all your programs for you, so it would be the last program you’d ever need to buy.

Reviewers found it useful for some business programs. It was not the last one.

Here’s the pattern on every rung. Something gets automated, the people doing the work stop doing that thing by hand, and the field keeps growing anyway. GitHub counted more than 180 million developers in its 2025 report, and more than 36 million of them had joined in the previous twelve months.

So I don’t think AI ends programming. I do think this rung is different in one way, and that’s speed. GitHub Copilot’s preview came out in June 2021. By 2025, 84% of developers in Stack Overflow’s survey were using AI tools or planning to. Four years, from novelty to default.

What 2026 actually looks like

The vibes are loud right now, so let’s start with numbers. (Speaking of vibes: Andrej Karpathy coined “vibe coding” in February 2025, for the kind of coding where you “fully give in to the vibes.” Stack Overflow asked about it that year. 72% of developers said it isn’t part of their professional work, and another 5% said emphatically no. I love that they offered that option.)

Stack Overflow’s survey is the biggest regular check-up we have, and the adoption curve in it is steep: from 70% of developers using AI tools or planning to in 2023, to 84% in 2025, when half of professional developers were using them every day.

You’d think all that use would mean developers love these tools. Nope. Favorable sentiment fell from 77% in 2023 to 60% in 2025, and only ticked back up to 62% this year. In 2025, more developers distrusted the accuracy of AI output (46%) than trusted it (33%). The top frustration, picked by 66% of them, was “AI solutions that are almost right, but not quite.”

I feel seen. Almost right is an expensive kind of wrong, because you have to read every line to find the part that isn’t. (45% of them said debugging AI-generated code takes longer.)

Then there’s my favorite study of the whole AI boom, mostly because it’s so rude. In early 2025, METR, a nonprofit research group, ran a proper randomized controlled trial. Sixteen experienced open-source developers worked on 246 real issues in their own repositories, projects they’d been on for years, and each issue was randomly assigned to allow AI tools or ban them.

Before they started, the developers expected AI to cut their time by 24%. When they finished, they believed it had cut it by 20%. The clock said that with AI they took 19% longer.

Nineteen percent longer! And they walked away sure it had helped.

Before anyone screenshots that for a hot take: it’s one study of sixteen people, using early-2025 tools, on codebases they knew better than any model could.

And METR tried to run it again. A bigger study started in August 2025, with 57 developers and more than 800 tasks, and in February 2026 METR said the data was too unreliable to lean on. Mostly that was because developers kept declining to take part, since they “do not wish to work without AI.” The early numbers hinted at an 18% speedup for the returning developers (with a range wide enough to include no speedup at all).

I think that’s the most 2026 way an experiment has ever failed. People refused to be in the group without AI.

What I take from METR is narrower than any headline, and more useful: how fast you feel is not a measurement. If you want to know whether AI makes your team faster, measure it the way you’d measure anything else.

The line that keeps going up

METR’s other big project tracks how long a task an AI agent can finish on its own. They time human experts on a suite of software tasks, then find the task length where an agent succeeds half the time. In 2019, GPT-2 managed tasks that take a person about three seconds. GPT-4 got to about four minutes in 2023. Claude 3.7 Sonnet reached an hour in February 2025, and Claude Opus 4.6 reached about twelve hours a year later.

Across the whole series, that number has doubled about every six months. Since 2023, it’s been closer to every four months.

Now, a log-scale chart with a dashed line on the end is how a lot of bad predictions start, so let me be careful. “Half the time” is doing a lot of work in that definition. Benchmark tasks are cleaner than your codebase. And METR stopped updating that page in September. But if the line keeps going even roughly, agents will handle a month of human work, half the time, around 2028. That’s where my 2031 Tuesday comes from. I didn’t pull it out of thin air. I pulled it out of a log-scale chart, which is thin air with axes.

The companies building these things are already living a version of it. Google said in October 2024 that more than a quarter of its new code was generated by AI, and “well over 30%” six months later. In March 2025, Anthropic’s Dario Amodei predicted AI would be writing 90% of code within three to six months. That was too soon. But by May 2026, Anthropic said more than 80% of the code merged into its own codebase was written by Claude.

When code gets cheap, the queue moves

Make one step of a process faster and the work piles up in front of the next slowest step. Anyone who has worked a kitchen on a Saturday night knows this: speed up the grill and the plates start waiting at the pass.

That’s what’s happening to software teams. In 2025, Faros AI looked at telemetry from more than 10,000 developers on 1,255 teams. Developers on teams with high AI adoption finished 21% more tasks and merged 98% more pull requests, and their review time went up 91%.

Faros ran it again in 2026 with 22,000 developers. Task completion per developer was up 34%, which sounds great until you read the rest. Median review time had grown five times. 31% more pull requests were merging without any review at all, and the ratio of incidents to pull requests had more than tripled.

The code got cheaper, the reading got more expensive, and some teams quietly stopped reading. That matters because the code isn’t always good. Veracode tested more than 100 language models on 80 coding tasks in 2025, and 45% of the results had a security flaw. GitClear found that copy-pasted lines went from 8.3% of changed code in 2021 to 12.3% in 2024, while moved code, the kind you get from refactoring, fell from about a quarter to under 10%.

Spare a thought for the maintainers, too. Daniel Stenberg, who leads curl, started banning people who submitted “AI slop” bug reports in May 2025, writing that the project was “effectively being DDoSed.” In January 2026, curl shut down its bug bounty.

Fred Brooks saw a version of this coming in 1986. In “No Silver Bullet” he split the difficulties of software into two piles, borrowing Aristotle’s words: essence and accidents. The accidents are the trouble our tools cause us, like syntax, boilerplate and fighting the build. The essence is what he called “the specification, design, and testing of this conceptual construct,” which is a fancy way of saying: working out what the thing should do. AI is getting very good at the accidents. The essence is the refund question from 2:13 a.m., and it’s still on your desk.

The rung we might be sawing off

This is the part of the data I like least.

In August 2025, Erik Brynjolfsson and two colleagues at Stanford’s Digital Economy Lab used ADP payroll data to look at who was getting hired. Employment for software developers aged 22 to 25 was down nearly 20% from its peak in late 2022. Older developers showed no noticeable change.

They updated the study this August, with data through June 2026. Young workers in AI-exposed jobs are now 19% below where they’d be if they had kept pace with less-exposed peers. Experienced workers show no comparable gap. Most of the effect comes from companies hiring fewer young people in the first place.

The rest of the market isn’t exactly roaring either. Indeed’s index of software development job postings sits about 21% below February 2020, after bottoming out 39% below in May 2025.

The Stanford authors are careful to call their findings descriptive, not causal, and plenty else has happened since 2022. Interest rates went up, and a lot of companies had hired too many people during the pandemic (Indeed’s index peaked at more than twice its 2020 level in early 2022). But the pattern lines up uncomfortably well with what agents are good at: the small, well-defined ticket we used to give the new person on the team.

Senior engineers get made on the job, mostly by being juniors on real teams: doing the boring tickets, breaking production once, and having someone kind explain why. If agents take all the boring tickets, where does the next senior engineer come from? It’s hard to review code well if you’ve never written much of it.

I don’t have a clean answer. My guess is that the teams doing well in 2035 will be the ones that kept hiring juniors in 2026 and gave them a different apprenticeship: reviewing agent work with a senior beside them, owning one small system end to end, and writing the specs and tests the agents build from. Writing those specs and tests is a real job. It might turn out to be the job.

Five guesses for 2031

Okay, now the guessing part. Bookmark this page and come back in 2031 to laugh at me.

Teams get smaller, and there are a lot more of them. According to Y Combinator’s Jared Friedman, a quarter of the Winter 2025 batch had codebases that were about 95% AI-generated. In February, Block cut about 4,000 jobs, and Jack Dorsey pointed to AI tools and “smaller and flatter teams.” I could be wrong here, but I still don’t think that adds up to fewer software jobs overall, and neither does the US Bureau of Labor Statistics, which projects 10% growth for software developers, QA analysts and testers from 2025 to 2035.

When something gets cheaper, we tend to want more of it. Economists call this the Jevons paradox, after William Stanley Jevons, who argued in 1865 that more efficient steam engines would make Britain burn more coal. Software that took a team a quarter will take one person a week, and a lot of problems nobody could afford to solve will suddenly be worth solving.

The spec and the tests become the source. Today we treat the code as the thing we own and the spec as the document nobody reads. I think that flips. The spec and the tests become what you review and argue about, and the code becomes more like a compiler’s output: you can open it and inspect it, but you rarely edit it by hand. (Yes, that’s the 1954 promise again. Maybe this time it sticks.)

Software for an audience of one. My nightly agent builds things nobody asked for, including me, and some of them are delightful. When a working tool costs an evening instead of a quarter, people will make software the way they make spreadsheets today: for one problem and one person, thrown away when it’s done.

Reading code becomes a career. We have whole careers built around writing code and almost none built around reading it. I expect that to change, with something like “verification engineer” on job boards and much better tooling that shows a reviewer the recording, the risky lines and the tests the agent didn’t write. The Faros numbers say we need it now, never mind in 2031.

Every change carries a label. I think a pull request will routinely say who or what wrote it, who checked it, and what was actually verified. I already do a small version of this: every project my nightly agent builds says so, in its README and on this site.

Back to Tuesday

FORTRAN did eliminate a kind of coding. It didn’t eliminate coders. It made a lot more of them, working on harder problems, and the debugging came along for the ride.

I think AI does the same thing, faster and messier. The developer of 2031 spends the day deciding what should exist, explaining it clearly enough that a machine can build it, and checking that what came back is right. That was always the hard part. We just had less time for it because we were busy typing.

What does your Tuesday look like right now? Are you reviewing more than you write? Tell me in the comments. I’d like to know if my guess is already wrong.

Full article content is not available for inline reading.

Read the original article →

Apache Arrow addresses a different problem than Parquet: fast in-memory analytics rather than compact storage. By keeping data in contiguous typed buffers instead of heap objects, Arrow preserves column locality for cache-friendly scans and SIMD execution, and it also reduces repeated serialization between engines like Spark, pandas, and DuckDB.

Meta has reduced repeated product-analytics work to seven parameterized measurement patterns and exposes their governed outputs through agent-readable models and a deterministic query generator. The library now powers more than 9,000 production pipelines, including 3,250 metric-materialization pipelines. Agents choose inputs and recipes, while code, SQL, and validation remain controlled.

PyDebeziumAI

Real-time CDC Integration for LangChain & LangGraph using Debezium

PyDebeziumAI bridges Debezium CDC streams with LangChain and LangGraph, keeping your vector store automatically in sync with relational database changes — in real time.

Documentation: Complete user guides, tutorials, and API reference are available at debezium-ai-python.readthedocs.io.

Environment & Prerequisites

PyDebeziumAI requires Java 17+ for running the embedded Debezium JVM engine. Set your JAVA_HOME environment variable for your operating system:

# Linux
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64

# macOS
export JAVA_HOME=$(/usr/libexec/java_home -v17)

# Windows (PowerShell / Command Prompt)
set JAVA_HOME=C:\Program Files\Java\jdk-17

Download Debezium engine dependencies using the cross-platform setup script:

python tools/setup_jars.py

Why PyDebeziumAI?

Most RAG pipelines go stale because they rely on periodic batch reloads. PyDebeziumAI uses Debezium's Change Data Capture to push every INSERT, UPDATE, and DELETE into your vector store the moment it happens.

PostgreSQL ──► Debezium CDC ──► PyDebeziumAI ──► Chroma / PGVector / Milvus ──► LangChain RAG

Quick Start

# Install with Chroma + local sentence-transformers embeddings
pip install 'pydebeziumai[chroma,local-embeddings,debezium]'

from pydebeziumai import LiveContext

rag = LiveContext(
    debezium_config={
        "name": "my-pg-connector",
        "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
        "database.hostname": "localhost",
        "database.port": "5432",
        "database.user": "postgres",
        "database.password": "postgrespassword",
        "database.dbname": "mydb",
        "database.server.name": "myserver",
        "topic.prefix": "myserver",
        "table.include.list": "public.products",
        "plugin.name": "pgoutput",
        "snapshot.mode": "initial",
    },
    vector_store="chroma",
    embedding_model="local",  # uses sentence-transformers, no API key needed
    id_strategy="table_pk",
)

# Start real-time sync in the background
rag.start()
retriever = rag.as_retriever(search_kwargs={"k": 5})

# Use it in any LangChain chain
docs = retriever.invoke("What products are available under $50?")

Offset Checkpoint Replay Behavior

On application restart, events processed since the last offset.flush.interval.ms (default 5000ms) checkpoint may be redelivered by the Debezium engine. PyDebeziumAI handles this safely because all writes are idempotent upserts keyed by primary-key document IDs.

Features

• Real-time sync — Push-based WAL capture with low-latency delivery (typically ~280–500ms total vector indexing wall-clock time depending on embedding model & vector DB)
• Deterministic IDs — same row always maps to same document ID (correct upsert/delete semantics)
• Pluggable backends — Chroma, PGVector, Milvus (more coming)
• Local embeddings — works offline with sentence-transformers, no API key needed
• LangGraph support — reactive CDC-aware agent nodes
• Schema evolution — additive columns and nullable changes handled gracefully
• Retry + DLQ — exponential backoff and dead-letter queue for reliability
• Connect mode — JPype-native SourceRecord for lower latency (no JSON round-trip)

Architecture

┌─────────────┐    ┌──────────────────┐    ┌──────────────────┐
│  Debezium   │───►│ IngestionHandler │───►│  DocumentBuilder │
│  (via       │    │  (JSON / Connect)│    │  (Projection     │
│  pydbzengine│    └──────────────────┘    │   Policy + ID)   │
└─────────────┘                            └────────┬─────────┘
                                                    │
                    ┌──────────────────┐    ┌───────▼─────────┐
                    │ LangChain /      │◄───│   SyncManager   │
                    │ LangGraph        │    │  (upsert/delete │
                    │ Retriever        │    │   + retry/DLQ)  │
                    └──────────────────┘    └───────┬─────────┘
                                                    │
                                           ┌────────▼─────────┐
                                           │  VectorStore     │
                                           │  Adapter         │
                                           │ (Chroma/PGVector │
                                           │  /Milvus)        │
                                           └──────────────────┘

Installation

Contributing

Please see CONVENTIONS.md for coding styles, formatting, type check guidelines, and commit sign-off requirements.

License

Apache 2.0 — see LICENSE.txt

Full article content is not available for inline reading.

Read the original article →

A benchmark map of the US economy

AI benchmarks have multiplied in recent years, but coverage of economically valuable work remains limited. To measure this, we compiled relevant benchmarks to measure their coverage of American jobs. This Benchmark Map is our first step toward building a comprehensive, continuously updated resource for understanding AI capabilities across the economy.

of 923 occupations covered

208

of 18,797 tasks covered

924

benchmarks in the index

29

The Benchmark Map

Each tile represents one of the 923 O*NET occupations making up the US labor force, grouped into 22 job families. Occupations are shaded according to the share of their tasks which are represented in our initial list of AI benchmarks. A single benchmark prompt can be mapped to multiple O*NET tasks.

In our data set: only 208 of 923 occupations have a task with at least 5 benchmark prompts, and 6 of 22 job families have no such occupations.

Our findings suggest that 90% of American working hours are spent on tasks with little or no coverage from existing benchmarks. This makes it very hard to know how good AI models are at the work Americans actually do.

The coverage of existing benchmarks is not random, either. Our map suggests that the AI community is focusing on the largest labor markets first.

For example, benchmarks in our initial list heavily cover AI-exposed lawyers’ tasks, but barely cover any of the O*NET tasks of similarly AI-exposed legal secretaries or court clerks. The long tail of smaller, middle-income knowledge work jobs appears undercovered.

As we build out our coverage of model capabilities across the economy, we hope to both surface and help fill more gaps in our understanding of what models can do.

Methodology in brief

To break down the economy into sectors, occupations, and tasks, we used the US Department of Labor’s O*NET taxonomy. O*NET divides the US workforce into 923 occupations; for each occupation, O*NET attempts to provide a comprehensive list of “tasks” which make up the occupation, totaling 18,797 tasks across all occupations.

Example — 6 of the 22 tasks O*NET associates with Lawyers

1. Prepare, draft, and review legal documents, such as wills, deeds, patent applications, mortgages, leases, and contracts.
2. Advise clients concerning business transactions, claim liability, advisability of prosecuting or defending lawsuits, or legal rights and obligations.
3. Interpret laws, rulings and regulations for individuals and businesses.
4. Analyze the probable outcomes of cases, using knowledge of legal precedents.
5. Present evidence to defend clients or prosecute defendants in criminal or civil litigation.
6. Supervise legal assistants.

To measure benchmark coverage, we start with a list of 29 benchmarks selected for their quality and economic relevance. In selecting benchmarks for this list, we prioritized:

• Public Availability. Included benchmarks have at least 25 publicly available tasks.
• Agentic Tasks. Included benchmarks ask models to perform agentic tasks, rather than answering questions or advising the user on how to complete a task.
• Economic Realism. Benchmark tasks resemble tasks which humans (or agents) are frequently asked to do in real-world enterprises.
• Economic Diversity. We capped the number of included benchmarks per job family.
• Balanced Difficulty. Benchmarks are not yet saturated by frontier models.

We ask an LLM judge to tag each benchmark prompt with as many O*NET tasks as it thinks correspond to that prompt. An O*NET task counts as “covered” if our LLM judge has mapped it to at least 5 prompts from our 29 benchmarks.

Limitations

Our estimates are based on the initial list of 29 benchmarks, which is not a complete or perfectly representative sample. Any incomplete list will necessarily bias down estimates of economic coverage. We also capped the number of included benchmarks in each job family to maximize breadth, which biases down estimates for the most-benchmarked job families.

By selecting for unsaturated benchmarks, we risk understating coverage on easier tasks. Conversely, including saturated benchmarks could overstate performance due to lack of realism in those benchmarks. Several criteria, such as "Economic Realism," are inherently subjective.

Patterns in coverage

The benchmarks in our index have relatively deep and narrow coverage of the overall economy. They disproportionately focus on the economic tasks most exposed to AI automation, with O*NET tasks rated as “exposed” about 6x more likely to be represented on benchmarks than tasks rated “unexposed.”

After controlling for occupation and AI-exposure score, O*NET “task importance” is another predictor of benchmark coverage. The tasks scored most important are about 6–10x more likely to be represented on benchmarks than those scored least important.

Can O*NET + benchmarks tell us how good AI is at your job?

Measuring model capabilities by job occupation is essential. A simple average of benchmark performance would give too much weight to frequently benchmarked tasks. O*NET weighting allows us to weight performance on each O*NET task equally. While current results show similar performance between weighted and unweighted averages, we are hopeful that expanding our benchmark set will improve the utility of this metric.

However, even with more benchmarks, several obstacles remain:

1. Low statistical power: The breadth of the US economy means we have relatively few benchmark items per occupation/task.
2. Varying difficulty and fidelity: Benchmarks vary in quality, saturation, and realism, and we lack a formal way to weight them by quality.
3. Automation vs. Augmentation: Most benchmarks measure end-to-end automation, but real-world AI is often used for human augmentation.
4. Measurement gaps: ~63% of jobs involve physical-world components that are currently difficult to capture in digital-only benchmarks.

Reliable evaluation of AI agents on subjective tasks combines calibrated human reviews, automated judges, and production monitoring with statistical checks to distinguish real improvements from noise.

Hurray, I didn't somehow mess up the post send so this should be arriving at 8:05 EDT instead of 'whenever I hit the button' this time, unlike last week...

There's a long list of things that are irritating about the "new way" of working in tech, but probably for someone who's been doing product analysis for a very long time, and explicitly measuring UX-related things for a decade now, this is something I need to vent about. LLMs can do all sorts of ridiculously amazing things in generating code nowadays. They are also complete and utter garbage at creating human interfaces, and my hypothesis is that there's a fundamental gap that is currently impossible to bridge without some big breakthroughs.

Hot interface garbage on demand

I'm no stranger to slapping together silly tools and toys with the help of LLMs, and in terms of bullying them to give me the functionality I want, it's not too bad. But the interfaces to the functionality have always taken about three times the time and effort, only to end up with something that is still "really painful to use". The general idea is that, unless you explicitly work out the designs and flows and wireframes yourself to feed it into the systems, even the best models will put out something that is almost impossible for a naive user to use.

What sorts of things go wrong? There's walls of text with opaque terminology for no good reason. The ordering of steps is never clear. The location of items in a UI are almost never where you expect them. Plus, on top of all the visual chaos, LLMs can often make ridiculous mistakes mis-wiring the frontend to the backend, so you get all sorts of bugs, some of which you must manually verify yourself because there's no good way to automate testing like you can do with command line utilities or non-GUI code.

Even if you don't torture yourself with creating a GUI or web frontend and just make a CLI-only utility, models very often use multiple flags and parameters, with very verbose names and other conventions. Often functionality is grouped up unintuitively or requires running multiple steps along the processing path, all of which is very hard for a human to make sense of quickly.

It's possible to avoid a bunch of this pain if you have a very clear idea of what interactions and interfaces you want before hand, but if you leave any amount of ambiguity in your specifications, the LLM will inevitably choose "the wrong choice".

User experience is not an optimization problem

Coding agents are effectively really weird optimizers. They excel the most when their task has a very clear, objective, deterministic pass/fail criteria – hence, they're awesome at writing code and checking whether it compiles and passes a test suite. They will chug along ramming into failures until they wander to something that passes. Each failure ostensibly gets them closer to the eventual correct solution.

But the user experience and overall usability of a product is not a clear, objective, deterministic criteria. A product's experience is actually greater than the sum of its individual experiences. On any given interface for anything, from hardware to software, a confusing interface will remain confusing and hard to use for hundreds of variations and rearrangements. At the same time, it may take only a few changes for the whole interface to suddenly make sense to users. The painful part is realizing that all those changes must work together to achieve that clarity, you won't observe much improvement for each individual change.

You can rearrange 5 widgets on a page in hundreds of different permutations, but all but a handful of variations "make sense" to a user. Just think of all the usability tests that are essentially "which of these 10 places can we place the big important red button so the user actually sees and presses it without getting lost". Not even human design experts can fully predict what works with users.

Moreover, you can see this property when you try to sit down and develop "usability metrics" for any interface. Even straightforward concepts like "time to task completion" or "number of actions needed to complete an task" don't have a single correct answer. Sometimes you want friction, sometimes an improved interface takes longer to use because users are getting more value out of the interaction. I have never really encountered a usability metric that had a clean "up always better" interpretation.

So it's this non-linear, unpredictable, mess that is grounded in the many biological flaws and limitations of our human meat sacks is what I find hard to bridge. For example, it's easy to tell a modern AI agent to try to use a web interface to accomplish a task, like "go do this task on this web UI", and with some browser manipulation tools like Playwright, an agent can interact and attempt the task. But surprisingly, agents usually do better at this sort of task than typical humans because, among other things, LLMs 'read' all the text and instructions on a page whereas real humans typically don't bother to. They also "see" an entire page essentially at once whereas humans have very finite visual fields, attention and memory. So to a coding agent, the interface is perfectly 'usable', whereas it can be complete nonsense to a human, and it won't know that there's even a problem to fix. Same problem extends to a whole host of other issues like where calls to action are located, how things are displayed and described, what information the user needs now versus later.

Until someone manages to develop some sort of idealized simulation of a relatively clueless, inattentive, sometimes-lost human user, there's just going to be this giant gap in ... experience... that I can't see being bridged via automation. Without such a reference point to act as an oracle to determine a facsimile of 'usable', machine learning methods are going to struggle. In fact, as far as I'm aware, creating a realistic simulated user for such testing purposes is still a big open problem in the Human-Computer Interaction space.

This is also all before we get into the whole different fundamental problem we have in UX about how "personas" are crappy, unrealistic stand-ins for actual users themselves. "Average" summaries of user preferences and experiences have many blind spots and issues when designers try to make things for hypothetical personas. Maybe a magical bot that response identically to an individual human subject can dispel this basic issue, or maybe they don't and the whole project is flawed. I'm honestly not visionary enough to have an inkling where things will land.

Then, what about imitation?

Well, if we can't learn out way to good interfaces, we can just copy existing good ones, right? Except humans and entire product teams have been trying that for decades. I've literally gone to small e-commerce sites that are literal, slavish clones of the Amazon store pages, from the layout and theming down to the shape of all the widgets and buttons. That clone site weirdly less usable than Amazon's because that the smaller store just doesn't have the ridiculous near-infinite catalog of Amazon. So all the menus and categories and other things just ... made no sense. People have been trying to copy the design and aesthetics of various major products, especially Apple, for ages and we all know that "sometimes it works, sometimes it doesn't" because the "good design" doesn't exist in a vacuum but within a specific context.

I'm sure there's a bunch of startups and companies who are saying "we have tons of examples of "Good Web Design (tm)", we can surely train The Machine to create something similar. You can call me skeptical. I'm willing to bet that for the most part it's going to at best land in a very half-assed place. It feels very much like where diffusion model "AI Art" (ugh) has landed as of late, while there's been steady improvements in what those models can do, the majority of the output has a distinct Ai-ness to them that even normal people can identify now. Moreover, the results are still... not great? Given the moving target of "design taste", I'm willing to bet even the best franken-interface will have a distinct smell to them that will continue to make them awkward because they're applying the patterns on top of situations that don't call for them.

Now, if only everyone else who has access to code generation tools realizes these facts, things wouldn't be as messy as they are now.

Meta’s October 15 engineering report explains how designers prototyped with AI while building Forum, its standalone Facebook Groups app. The workflow uses a separate experimental build, not a new publicly available design tool.

Shared components, separate builds

The sandbox uses the production app’s codebase, frameworks and design system. Designers can test changes without involving an engineer at every step. Prototype code is excluded from the production build, while approved work can be transferred without rebuilding it from scratch.

This addresses a specific problem with working prototypes: teams can explore real interactions using existing components without exposing users to unfinished experiments.

Verification still comes before release

Agents run build checks, automated tests and visual comparisons before engineering review. Meta says every shipped change still requires an engineer’s approval. Some stages remain human-led within each iteration; the fully supervised model is a goal rather than a finished system.

Meta also uses navigation agents to detect regressions. Those checks test interface behaviour, but should not be read as a substitute for research with people.

It's okay to be a little jelly

Jelly UI is a dependency-free Web Components library for soft, tactile product interfaces. Real form controls meet soft-body physics, with dark mode, right-to-left support and WCAG AA color tokens built in.

• 0 dependencies
• 40 custom elements
• 1 script tag
• WCAG AA
• Dark mode
• RTL

<script type="module" src="https://jelly-ui.com/package.js"></script>

<jelly-theme mode="auto">
  <jelly-button variant="mint">Publish</jelly-button>
</jelly-theme>

Create anything you imagine

AI agents for creative work. Bring your creative vision and collaborate with AI agents until the images, video, and audio land exactly as you imagined.

Hear from the teams who create with Melius

Solutions

Agencies

Concept work that wins the pitch. Variant work that runs the campaign. The same canvas does both — treatments and concept art at the brief's pace, ad variants and campaign creative at the campaign's volume.

CD/Filmmakers

You can see the shot. You can describe it. Single-model tools can't make it. Work with tunable, multimodal nodes until the frame matches what you imagined.

Marketers

The hero shot in minutes. The thousand-variant cascade in an afternoon. Localized for every market, sized for every channel, brand-checked before every approval.

E-commerce

The shoot that used to take three weeks, an afternoon on the canvas. Pack shots, on-model, hero imagery, all brand-consistent across every frame, at the pace of your ambitions.

GTM / Growth

Skip the design ticket. Event graphics, blog heroes, conference posters, decks that don't look like they were made in five minutes — all on the fly, without learning a single tool or writing a single prompt.

Our Pricing

Creator

Explore possibilities on Melius

• Access to all models
• Unlimited agent usage
• Import custom voices

Growth

Start creating on your own

• Everything in Creator
• Up to 3 agent skills

Professional

Go pro on your own terms

• Everything in Growth
• Up to 10 agent skills
• Slack agent access
• Search with AI
• AI prompt enhancement
• Better fonts

Team

Shared credits, shared workspaces, one bill

• Up to 10 agent skills
• Slack agent access
• Search with AI
• AI prompt enhancement
• Better fonts

Enterprise

For higher limits

• Everything in Team
• Priority queue access
• Real-time support
• Dedicated Slack channel

Frequently asked questions

What is Melius?

Melius is a node-based creative canvas for AI image, video, and audio. Every prompt, image, video, and audio clip is a node on an infinite canvas, and edges connect them so one node's output feeds the next. That's how you build a multi-step pipeline like reference image to image to video to voiceover to final cut. Describe what you want and the Mel agent wires the nodes, picks the right model for each, and leaves every prompt editable so you can rewire or re-run any step.

What is a node-based AI canvas?

A node-based canvas represents creative work as a graph instead of a chat thread. Every step is a node with its own model, settings, and version history: a prompt, a generated image, a video, an audio track, an uploaded reference. Edges pass output from one node into the next. Because the whole pipeline is visible, you can change an early step and re-run everything downstream, branch to compare variations side by side, and reuse a working graph as a template. On Melius, that graph is also what the Mel agent and external agents connected over MCP read and edit.

What kind of work is the Melius canvas best for?

Anything that takes more than one generation to get right. Video production teams storyboard, generate shots on parallel branches, and assemble takes in the built-in multi-track editor. Advertising and campaign teams build a graph per concept, then fan the approved one out to every placement and aspect ratio. E-commerce teams reuse one product photo as a reference node across lifestyle scenes and crops. Brand and design teams pin assets, fonts, and references as nodes so downstream generations stay on-brand, and agencies share canvases so feedback lands on a specific node rather than a finished file.

How does AI video generation work on Melius?

You start from a text prompt or an existing image, choose a video model or let Mel pick one, and Melius generates the clip. You can guide it with reference images, first and last frames, or input footage, then trim and assemble clips in the built-in video editor.

Is Melius free?

You can create a Melius account for free, but generating images, video, or audio uses credits — and the only way to get credits is a paid plan or a one-time credit purchase. So it's free to sign up and explore, and you pay only for what you generate. Paid plans start at $18 per month.

What AI models does Melius support?

Melius gives you access to a library of leading AI models for image, video, audio, and text. That includes image models like Nano Banana, GPT Image, Flux, Seedream, and Ideogram; video models like Seedance, Veo, and Kling; and audio and voice models like ElevenLabs, from providers including OpenAI, Google, ByteDance, and Black Forest Labs. The Mel agent can choose the best model for your prompt automatically, or you can pick one yourself.

Who owns the content I create, and can I use it commercially?

You own the content you create on Melius and can use, publish, and distribute it commercially, subject to the underlying model providers' terms. Melius doesn't claim ownership of your work and doesn't use it to train AI models.

How is Melius different from single-model tools like Midjourney?

A single-model tool gives you one model and one output at a time, with no record of how you got there. Melius is a node-based canvas: one subscription covers many models across image, video, and audio, and the graph keeps every step connected, editable, and re-runnable. You can swap the model on a single node, branch to compare two directions, and reuse the whole workflow as a template, instead of juggling several separate tools and rebuilding the process from scratch each time.

Paper Mono is a free and open source font family.

Paper Mono summary

METRICS / UNITS

• Width: 606
• Cap height: 710
• X-height: 509
• Ascender: 955
• Descender: -245
• Underline: -100
• Axis: 100-800

Paper Mono v1.0

• Glyphs: 800
• Characters: 659
• Weights: 8
• Feature sets: 6
• Char sets: 12
• Languages: 100+

STYLISTIC SETS

• SS01: coding ligatures
• SS02: duospace glyphs
• SS03: narrow space
• SS04: small arrows
• CV01: single-story a
• ZERO: slashed zero

At Paper, we couldn’t find the mono we wanted – so we made it. Beautiful for headlines, text, user interfaces, and code alike.

1 Design

Timeless character

Flat terminals, gently squared curves, and a balanced x-height give Paper Mono the familiar character of a classic sans.

Variable weights

You have 8 weights to work with, and the variable font lets you fine-tune the weight anywhere in between.

Beautiful numbers and symbols

We designed numbers and symbols with utmost care, so that they’re pleasing to look at and effortless to read.

Box-drawing characters

Build tables, diagrams, and progress bars directly in text, using 128 box-drawing characters and 32 blocks.

Coding ligatures

A deliberately small set of ligatures that makes reading code enjoyable and doesn’t overwhelm you with unfamiliar shapes.

Duospace characters

Probably our favorite feature of the font, duospacing helps text flow naturally while keeping the monospace feel.

Narrow spaces

Enable a little less space between words to help paragraphs flow or to let inline code sit naturally within a sentence.

Small arrows

We’ve included an understated alternate arrow style that works alongside text without drawing too much attention.

Single-story a

You can use the single-story “a” to give the text a warmer, more informal voice.

Slashed zero

By default, the zero is unslashed to keep the numerals looking clean. You can add a slash when you need to tell 0 and O apart.

2 Glyphs

3 Play

OpenAI's frontier models and Codex agentic workflows are coming to Google Cloud's Model Garden. The integration will give customers native access to these models to power complex agentic workflows at scale. It will pair OpenAI's frontier models with Google Cloud's built-in access controls, centralized data governance, and high-performance infrastructure to support demanding enterprise workloads. OpenAI models will soon be available in Google Antigravity and the Gemini Agent.

If Intelligence Is Getting Cheap, What Remains Expensive?

Why acquiring businesses is a unique strategy to deploy AI into the real world.

As models continue to improve, the price of intelligence is rapidly declining. We think this is only going to accelerate.

So if intelligence is getting cheap, what remains expensive?

At Long Lake, we focus on mission-critical businesses. Do customers trust them with real end-to-end outcomes? Does the service require human judgment? Are there regulatory reasons that govern accountability?

It's not just about drafting a newsletter to a homeowner, but actually handling the end-to-end outcome of an urgent leak. It's not just about extracting data from documents, but actually taking accountability for a complicated tax decision. And it's not just about helping you book a flight, but handling the entire travel journey including last-minute disruptions.

We think acquiring businesses like these is a unique strategy to deploy AI into the real world. Here's why.

The walls of deploying AI from the outside

Let's say you're building an AI product to sell into the enterprise. You found a pain point, built an agent, and it works—but for one very narrow use case.

Now you have to get it into production. That might involve security review, internal coordination, integrations with 20-year-old systems. This is typically the first wall in deploying AI into an enterprise.

Once you get past this, you have to get the team to use it. You'll iterate on the interface, go through trainings, get feedback. Whose job is it to drive adoption: yours as the vendor, or the client's?

Then, how do you get revenue? Do you sell tokens or seats? How do you deal with price sensitivity, measure ROI, and capture the value you create?

These walls reflect a common challenge: you're building on the outside, and that makes deploying AI really hard.

Importantly, it's not the models. Intelligence is progressing faster every month. One reason why deploying AI is hard is that organizations are incredibly complex. On paper, an org chart looks structured, but in reality, decisions are entrenched in a web of team members with decades of experience. The owner leans on them, they work with the most important clients, they interact with and influence multiple teams.

A vendor might integrate with systems of record: a CRM, a ticketing system, document repositories where SOPs, contracts, and old email threads live. That's valuable information. But businesses, especially in complex domains, run on human judgment. It's the exceptions, the edge cases, the tacit knowledge, and the quick questions asked to the expert that govern how a company runs.

You have to embed in the organization and collaborate with the people doing the work to understand what great work actually looks like.

Who captures the value?

Even if you're able to deliver end-to-end value, it's hard to capture that value as an AI vendor.

Let's say you land a million-dollar-a-year contract, which is pretty impressive. But will customers keep renewing? Can you maintain pricing as models improve and alternatives get cheaper?

Now let's say your client gets $5 million a year in EBITDA impact from your deployment. With an established business, you have years of operating history, enduring client relationships, and a proven business model with real economics. You're adding earnings to a business with value you can already reason about. Using a conservative 10x EBITDA multiple, you can generate $50 million in enterprise value for your client.

As a vendor, you did the work. You deployed agents, integrated systems, and worked with the team. But the largest impact shows up in the P&L of the business you worked with.

So why not build that business yourself, with AI at its core from day one? This is a very valid strategy. You can improve the whole workflow, not just a narrow slice. You sell the work itself, not just one specific tool. And importantly, you own the outcomes.

But you don't start with customers. It's hard to get distribution. You don't have brand reputation, and it's hard to hire expertise in mission-critical industries where clients may need multiple specialty offerings.

If you're the leader of a health system building a new surgery wing, do you hand that project to an AI architecture startup, or the firm you've worked with for 20 years, who knows the standards and nuances of your design and can deliver the full scope across architecture, structural, and MEP services?

The best firms have spent decades earning their customers, building brand and trust, and organizing incredible teams to deliver great service.

So instead of selling an AI agent from the outside or building from scratch, what if you could partner far more closely with incredible businesses that already exist, through acquisition?

What ownership unlocks

Starting on the engineering side, there's access. Your team can sit down with the experts doing the work, understand what they do, and build relationships with the veterans who have 20 years of experience. That's important for designing agents that tackle not just one use case, but the full automation and service delivery opportunity for the business.

The second is data. Every business is a live environment with real tasks, real edge cases, and real answers about whether an agent actually got something right. That's a huge opportunity to use that signal to improve your agents and models.

On the operational side, incentive alignment is huge. Ownership solves for this. You only win when your team and your business wins. There are no separate revenue goals, no distractions from other clients. That enables you to uncover and solve blockers to faster deployment and shared outcomes.

Then there's trust. Rather than coming outside-in or building from scratch, you start with the brand that took decades to build and all of their deep customer relationships.

Finally, you get scale. You start with customers, an expert team that can deliver an incredible service, and cash flow to continue investing in growth and new products.

These five characteristics aren't just independent benefits. They create a compounding advantage. Your agents and people act in live operations. You understand how work is done, create real-world data that leads to real outcomes, and that learning compounds together.

The thesis of acquisition, deep partnership with incredible companies, and leveraging AI to scale these businesses and improve service quality is exactly what we're excited about at Long Lake.

What we're building at Long Lake

Long Lake is an applied AI holding company. We've raised $7.5 billion in capital from General Catalyst, Alpha Wave, Elad Gil, D1, and many others. Our thesis is to acquire best-in-class services businesses, partner with them over the long-term to transform their operations, help them grow faster, and ultimately deliver a better client experience.

Today we've partnered with 40 businesses across residential services, architecture, HR, and other markets. We're a team of 60 across technology, finance, and operations, including former founders, ex-military, and more. We recently announced our partnership with Amex GBT, a $6.3 billion take-private bringing us into corporate travel.

We're inspired by earlier holding companies (think Berkshire Hathaway, Danaher, Constellation), and believe AI excellence is a new lever of execution that raises the ceiling for business transformation.

To find businesses worth partnering with, we see more than 5,000 deals a year. Great investment decisions come with choice. We keep a big funnel and an incredibly tight filter, focusing on businesses with strong fundamentals and an AI opportunity to improve and reimagine service delivery for clients.

From deploying agents to real P&L impact

Once you've partnered with a business, what does P&L transformation look like?

Think of a J-curve. You start with an investment in AI deployment: your platform, your technology, and capturing workflows. You work closely with the team, iterate, validate the product, potentially train custom models, and understand the unique tasks and data. This requires a focused, coordinated effort beyond just engineering.

Once you make it up this hill, people start using your product. You unlock capacity: time savings, usage going through the roof, the same output in fewer hours.

But importantly, this isn't the end of the journey.

You have to put that capacity to work. You work closely with management teams to drive measurable business outcomes, drive topline growth, and improve customer and employee NPS. That's how you drive real P&L impact: higher revenue per employee and, importantly, far better service quality for clients.

This isn't just a bespoke process you run one-off for a business. If you have the platform and playbook for both AI deployment and business transformation, you can get to faster agent deployment and faster P&L impact at every new business you partner with.

Under the hood, it takes a unique team to own, operate, and transform. You have to buy these businesses, with an experienced M&A team that can partner with world-class firms. You have to build: live on the ground with your partners in Minneapolis, Portland, London, spend time with the teams, and push the frontier of how agents are integrated across entire firm operations. And then you have to deploy, with a team focused on driving adoption and making sure time savings translate into actual business impact and a better client experience.

We think acquisition, owning outcomes, and long-term partnership with incredible services businesses is the path to making AI work in the real world. If you’re excited about this thesis, come build with us.

OpenClaw creator says he spent $10 million in tokens last month

Peter Steinberger, member of technical staff at OpenAI and the creator of OpenClaw, estimates that he spent around $10 million in tokens running AI workloads last month. But don't feel bad for him, because it's all coming out of investors' pockets.

He made this admission at the Cloudflare Connect 2026 conference in San Francisco on Wednesday, in a conversation with Cloudflare CTO Dane Knecht.

Knecht previously observed that Steinberger has acknowledged having "a virtually unlimited token budget, which not all of us in the room have."

Responding to the audible surprise rising from the audience, Steinberger added, "What people don't always understand is not all of that is useful."

That only amplified the murmuring, perhaps not the effect he had been after. Meanwhile, his employer, OpenAI, is reportedly trying to "accelerate funding" ahead of rival Anthropic's expected IPO.

Steinberger's subsequent musing about his preferred way of working failed to recognize Knecht's acknowledgement of financial limitations.

"I feel like the main challenge a lot of people still have is that our infrastructure structure hasn't really caught up yet," Steinberger said. "Like why is this still using my computer? Shouldn't this all be in the cloud?"

Apart from the privacy and compliance implications of relying on cloud-based AI, cost remains a consideration for anyone not setting venture funds alight. Cloud-hosted agents can be expensive. Shouldn't this all run locally?

Pointing to the OpenClaw project and how a lot of open source maintainers have given up accepting pull requests due to frustration with AI slop, Knecht asked Steinberger whether we're approaching the death of open source or a golden age of AI.

Steinberger said he thinks the way pull requests are handled needs to change because people don't explain how they arrived at their proposed changed code.

"If I see your thoughts, how you got from A to B, my trust in the output is way higher than if you just throw the finished work across the fence," he said.

Knecht also asked Steinberger whether everyone in the room would have hundreds of AI agents running in a few years.

Steinberger doubts it will be hundreds.

"I think everyone will have some sort of intelligence that runs and thinks and helps them throughout the day or even predicts what could help you in the future," he said. "So instead of asking the question, maybe you already get the answer."

Toward the end of the session, Knecht raised the issue of trust and how to know what data to give to an agent.

That's a hard question, Steinberger admitted. Part of it, he said, has to do with how much you trust the underlying model itself, because so much of model behavior is not governed by the harness – the code that wraps the model.

"A lot of decisions that I built into OpenClaw early on now can change because the models are so much better," he said.

Even if risks like prompt injection have been reduced through engineering efforts, Steinberger said, "you might not want to give your agent all the permissions."

Instead, he suggested using an agent to authorize your agent.

"You want to have another agent that can give it permissions or not and then this agent has to negotiate with another agent," he said. "Many times the agents are like, 'oh yeah, actually maybe I shouldn't do this,' or 'there's a simpler way that keeps it within the guardrails.' So those those two systems combined greatly increase my trust that I just can let the agent rip."

Today Monaco is launching Agent Matrix. Monaco unleashes countless agents working together, goal seeking, with one outcome in mind: accelerate revenue growth. If you don’t have an army of agents working 24/7 to accelerate revenue growth, you’re living in the past. Apply for early access now.

Thank you for this, @_NathanCalvin. I appreciate and am a fan of the investigative work you’ve done on behalf of AI safety and believe your comments are coming from a constructive, honest place, and that it benefits the public to have people whose job is to scrutinize the actions of frontier AI companies. I think something would be wrong if companies of the size of Anthropic didn’t get harshly criticized basically every day; strong antibodies against corporate power are a healthy feature of a free society, and especially so when issues of the gravity of the one we’re facing are at play. I also do agree that some of the examples you cite were mistakes by Anthropic.

That said, I disagree with the thrust of your post. At the core, a good fraction of the things you criticize are consequences of Anthropic’s basic theory of change that we have held for many years. Our strategy has always been what I’ve called the “race to the top” — by showing how it’s possible to build the technology responsibly, we can raise the bar for the entire industry. The forces that drive the race to the top are hugely more effective if the company practicing them is at the frontier; that’s one lesson I’ve learned repeatedly. And looking at that strategy as a whole, I’m proud of our track record and stand by it.

I believe that if we take a list of things that Anthropic did in the past year that were pro-safety and commercially costly to us, they far outweigh the list you’ve made, while at the same time I also disagree with some of the items on your list. Here are some things Anthropic has done, in the same period you’ve cited (the last year), which were very costly to us commercially while having strong safety benefits:

1. We played a key role in SB53 (and other state laws), at a time when doing so was politically perilous to the company and AI regulation was very unpopular. We in fact argued for a stronger version of SB53 than was ultimately passed; there were a lot of stakeholders and we were not the limiting factor in the strength of the bill that was passed.
2. We have very strong biological safeguards on our models, because we’ve seen concerning results in bio uplift trials and even seen and blocked potential attempts to misuse our models for bioweapons (as seen in our threat intelligence report from a few weeks ago). This is a very serious threat that we want to have zero tolerance for. But having very low false negatives means having significant false positives (despite months of effort on our part to improve the classifiers), enough so that biologists joke about how restrictive our classifiers are, and competitors sometimes sell against us by touting their more permissive bio capabilities. This has been very painful to us in an area where we care a lot about supporting an ecosystem of Claude users (biomedical science; and it is particularly frustrating to me as a biologist), but it’s the right thing to do and we intend to keep doing it.
3. Similarly, we first had Mythos-class models in February but didn’t make them generally available until June (when we had stronger cyber safeguards in place). We only offered them to a limited set of partners in order to focus on cyberdefense. It would have been much more economically rational to simply release the model to everyone. We likely sacrificed a significant chunk of a several-month model lead. But because of this, many companies secured their cyber infrastructure before the deluge of widely available cyber-capable models. Of course there are ways it could have gone better or been run better, but this was what we were aiming to do.
4. I advocated forcefully and publicly, in my essay Policy on the AI Exponential in June of this year, for the government to have the power to block model releases. Back then this was still outside or maybe on the edge of the Overton window, though I understand the window has moved since then. We were attacked intensely for this.
5. I don’t want to re-ignite conflict, but the events of February 2026 are a strong example. It is clear that our public stance could have seriously damaged the company’s future.
6. We’ve continued to advocate for export controls on chips and chipmaking equipment to China, because we think it allows democracies to negotiate from a position of strength on AI safety agreements. We’ve done this despite problems it’s created for us with industry partners who hold very different views and on whom we are very dependent.
7. As far as I’m aware we were the first, and still only, frontier company to restrict the sale of AI services to PRC-controlled companies, including those operating through third countries (otherwise a major loophole). We’ve therefore forfeited significant short-term business to prevent fueling AI platforms and applications that would help the CCP’s military and intelligence services. We are also cracking down on distillation; generally, distillation is not a major threat to us commercially, but like chip exports it has concerning national security and safety implications, so we expend significant energy and company resources to address it.
8. As you mentioned, we’ve put out a lot of reports, announcements, long model cards, public advocacy, etc, all trying to inform the public about the risks of AI. These involve a level of detail and effort that would be implausible for a purely profit-maximizing company.
9. Just this week, we announced we were putting 5% (and possibly more over time) of the company into a public benefit fund.

All of these decisions came with very substantial costs to us. To be fair, those that involved holding back or restricting access to frontier capabilities also had a broader cost — for example, the public might otherwise have benefitted from faster progress in biology, so I am not saying that our decisions were without tradeoffs — but they were not driven by profit-seeking.

For each decision, you can come up with ulterior motives that could have driven us — I think it is a general truth that any decision, on any topic, can always be portrayed as a nefarious scheme. But most of those end up being pretty farfetched or don’t fully make sense if you actually examine them closely. For example, it is deeply implausible that it would be a shrewd business move to block a large swath of research biology in order to do the work ourselves and compete with our customers; we expect the benefit to the ecosystem to greatly exceed the work Anthropic does itself, and for the two to complement each other. It is not in Anthropic’s interest to be perceived as unfriendly to biologists. Our Life Sciences Verification Program, which gives vetted biology professionals access to our models, also refutes this idea.

Of course, a different set of people will see this and make a different criticism: that Anthropic shouldn't be making decisions about who gets access to what in the first place. I agree, in the sense that ideally the government would be making these decisions, and that’s why we advocate for regulation. But for now we are forced to make them, and enabling bioterrorism isn’t a better option.

I think that even if I conceded every item in your list, I would happily hold up mine next to it; I don’t think it’s a close call. That is of course partly subjective and different things are important to different people. Maybe one way you could object is that several of the items above relate to AI misuse and not loss-of-control; if you think the latter is much more important than the former, that might change your calculus. But this is not Anthropic’s view — we view both as serious issues. You can also disagree with our decisions, as many have, but they are consistent.

But I also disagree with at least some of your list. Several items don’t represent a deviation from Anthropic’s strategy or values at all, once we postulate the “race to the top” strategy that requires being a frontier AI company. Your items 1-4 are all simply examples of what it means to compete at the frontier, and we stand by them, both in the sense that they are transparently ordinary things to do as part of that strategy, and that we stand by the strategy as a whole.

To be fair, there are important questions worth confronting (and that we are confronting) about what to do when the AI-driven acceleration gets fast enough that it is hard for safety to keep up. We are nearing that point and that’s what’s driving some of our thinking about “pacing.” But 1-4 are actions taken before that point and should be perfectly expected based on Anthropic’s strategy as a company. Of course it is possible to disagree with that strategy, but that’s a more fundamental disagreement that you could have had any time over the last few years.

I agree we could have handled your items 7, 8, and 9 better. All fall into the category of “rhetoric or policy communication that wasn’t carefully written or resulting from fast-changing circumstances not propagating from one team to another fast enough.” This kind of thing happens a lot in large organizations (Anthropic is over 5,000 people), and doesn’t even necessarily represent a failure or mistake of any single person. I am of course the CEO, and I take responsibility. The volume of communication from Anthropic is enormous and if these are the worst examples, I think we’re frankly doing pretty well, though I will continue to work hard to make sure we do even better.

Your 5th item (the change to our RSP) is the most substantive item, and people can debate this, but I think that the old, more rigid RSP created a lot of situations where we were technically required to do something that required a lot of effort but in retrospect wasn’t very important for safety, as well as not covering some of the most important things. Our current RSP’s focus on transparency brought things like risk reports and roadmaps, and its emphasis on independent external review laid the groundwork for even more intensive embedded evaluation, all of which I think have been valuable in driving a race to the top. In the original announcement in September 2023, we described the RSP as an “early iteration that we [would] build on” and said that “rapid iteration…will almost certainly be necessary.” I understand that changing plans is always a move that creates justifiable scrutiny — I just don’t think we ever represented that we wouldn’t do so.

Relating to your 6th item (having an FCF in addition to our RSP), I know our intent is to meet the letter and spirit of our regulatory obligations (via our FCF) while also remaining able to experiment with more novel approaches to risk management that go beyond what the law currently requires (via our RSP). I promise to look into it further, as it’s a complex issue and it is possible we are not weighing the considerations in the right way.

Overall, although Anthropic has made plenty of mistakes as an organization — including some of the items on your list — I feel that we have repeatedly taken serious and substantive actions counter to our bottom line and that there is a significant negativity bias distorting assessments like the one you are making above. We’ll always try to do better but, again, I am extremely proud of our track record and stand by it. I will have more to say soon about how we are going to further live our values in this moment of rapid change.

Elon Musk is fully behind a combination of SpaceX and Tesla, his two most valuable companies. He is pushing to announce a deal by the first half of 2027 so it closes during the Trump administration. The timing will depend on when Tesla's board gets comfortable with the details - SpaceX shareholder approval is less of an obstacle, as Musk controls more than 80% of the voting power. Combining the companies before the end of this administration would consolidate Musk's corporate power before a potentially less accommodating political and financial environment takes hold.

Physicists at Northwestern University have coaxed a single positron (the antimatter counterpart of an electron) into an exquisitely controlled quantum state for the first time. The scientists cooled the fast-moving particle to nearly absolute zero after capturing it from radioactive decay, and then suspended it in a near-perfect vacuum, resulting in a state where the positron behaved much like an artificial atom with quantum energy levels scientists can precisely control and observe. The technique could enable the most precise test yet of a fundamental symmetry between electrons and their antimatter counterparts.

California's proposed tax on billionaires prompted Mark Zuckerberg to leverage the board at Meta to get the company to protect him from it. He issued an ultimatum to the board on September 9 that he would sell his home in Palo Alto, and the listing would be public, if a deal wasn't struck by September 13. The board decided to issue a new class of stock to shareholders that Zuckerberg could sell to pay the potential wealth tax without cutting into his 60.6% voting power. California's proposal would assess a one-time 5% tax on all holdings of billionaires who lived in California as of January 1, 2026.

Meta said during its third-quarter earnings call on Wednesday that its AI app Muse has been adopted by more than 10 million users, confirming estimates released earlier this week by market intelligence firm Sensor Tower.

But it is how people are using it and how much they’re spending that has caught CEO Mark Zuckerberg’s attention. Zuckerberg said about 25% of people who set up Muse now use it daily, helping improve retention.

He also shared that over a quarter of Muse’s engaged users who were shopping via the AI agent had an average purchase size of over $200, which was surprising even to industry insiders.

“Plaid told us that they hadn’t seen activity like they’re seeing with their connector on any other service before,” Zuckerberg said, referring to the financial technology company that connects payment apps to customers’ bank accounts. Muse uses Plaid’s connector to enable agentic shopping.

Beyond shopping, Zuckerberg said other popular uses for Muse include personal productivity tasks, such as connecting the AI agent to users’ email or calendars. The exec stressed that this indicates users trusted Muse’s security setup, which includes a feature called “Muse Secure VM” designed to protect their data and privacy. He also mentioned that the forthcoming “Muse Confidential VM” will prevent even Meta from seeing users’ content.

Now that Muse has achieved “product-market fit,” Zuckerberg said Meta’s focus will shift to scaling the AI agent, increasing revenue, and optimizing its compute costs. Remarkably, the tech company is forecasting that Muse will eventually bring in more revenue per user than its “family of apps” users do today — meaning its users on Facebook, Instagram, WhatsApp, and Messenger. Currently, that figure is around “several hundreds of dollars annually,” Zuckerberg said.

Meta has said it ultimately intends to monetize Muse by keeping it free for most users but keeping a percentage of the commerce taking place on the platform. Power users who want access to the most advanced AI models or more tokens will also have to pay.

Zuckerberg also noted that Meta believes Muse will be profitable after it scales.

“On the compute side, we are building out the capacity to serve more than a billion people over the next few years,” he told bankers and analysts on the Q3 earnings call. “In the near term, Muse is very compute-intensive to run, but we expect to improve its cost efficiency by more than 10x in the next year, which will enable it to be profitable once the revenue lines are at scale.”

Muse will also play a central role in Meta’s smart glasses strategy. Reality Labs, the division responsible for smart glasses, VR, and the metaverse, is still losing billions. However, the division’s losses are expected to improve from $19.1 billion in 2025 to $15 billion this year.

Beyond scaling and supporting its hardware strategy, Zuckerberg teased the company’s plans for something he called the “Muse network.” He described this as taking Muse from a “single-player game” to one where “your Muses can work with your friends’ and your families’ [Muses].”

“And if you want to buy something, it’s not just navigating to that business’s website; it’s talking to their agent,” he added.

Demis Hassabis believes that AI can lead to an amazing future, but we have to intentionally build toward it.

Governing AI agents in Snowflake starts with strong data controls: identify sensitive information, apply access and masking policies, and monitor usage. Agent-specific permissions, masking, and prompt injection checks add protection by limiting what agents can access, see, and change.

As software assembly gets cheaper, the durable asset shifts from application code to a governed historical record of entities, state changes, and provenance. The key lesson is to let AI generate queries and transformations, while append-only history and deterministic validation preserve meaning, permissions, and auditable “as-of” views.

A solo engineer trained a 3.848B-parameter LLM from scratch for a reported $998 by pairing a lightweight stack with a few high-leverage efficiency choices. The run finished in 43 hours on eight rented B200s and reached 0.384 CORE on DCLM, roughly 50% above GPT-2's reported score.

Full article content is not available for inline reading.

Read the original article →

Google is adding a review step to slide and video creation in Gemini Notebook. Announced on October 19, the update is rolling out globally to all users over the following week.

Starting in chat, users can ask for a presentation or video overview. Notebook proposes topics based on their sources, then lets them guide the content, visual style and format.

Check the plan before rendering

The new Review toggle adds a checkpoint in the Studio panel. Users can open outline notes for slides or producer notes for videos and request changes, such as adding an executive summary or changing the order of scenes. Selecting Proceed starts generation.

This gives users a chance to correct the structure before committing to a finished output. It is a planning checkpoint, rather than a guarantee that the generated material will be accurate.

The review step is optional. Users who want an immediate result can still generate from the Studio panel without enabling it.

Adobe Lightroom mobile can now open closed eyes in photos with a simple tap

When the mobile app detects closed eyes in a photo it will present users with a new Open Eyes Quick Action tool.

Adobe announced yesterday that the mobile version of Lightroom, available for iOS, iPadOS, and Android, can now open closed eyes in photos using generative AI with just a single tap. When the app detects a person, or a group of people, have their eyes closed in a photo it will automatically present users with a new Open Eyes Quick Action that appears as an icon over the image providing easy access to the new feature.

Being able to easily save an otherwise great photo by opening a subject’s eyes has been a feature in Adobe’s Photoshop Elements for nearly a decade, but as DPReview points out, Elements sources the replacement from another photo of the subject with mixed results depending on variations between the two images. Open Eyes in Lightroom mobile instead relies on generative AI so the replacement eyes match the lighting and pose, and the app will use other images of the same person in your Lightroom library as reference so the open eyes will accurately match the color, size, and shape of their own.

You can perform a similar fix in other Adobe apps like Photoshop using its own generative AI tools, but it’s not a one-tap fix, and it’s not free. Those using the free version of the Lightroom mobile app can try the Open Eyes feature twice before they’re given a prompt to subscribe to an Adobe Creative Cloud plan that includes more credits for its various AI-powered tools, according to DPReview.

If you think about it, there is a lot of software that hasn’t been built across hundreds of industries because our best paid designers and engineers were occupied with building social networks and ad networks.

"The best minds of my generation are thinking about how to make people click ads." — Jeff Hammerbacher

Meanwhile, massive parts of the physical economy were and still are running on spreadsheets, email, paper forms, ancient desktop software and enterprise systems installed sometime around 1999 by companies who couldn't care less. And most companies still use that exact software, even today, for various reasons.

Construction. Manufacturing. Logistics. Agriculture. Waste management. Energy. Shipping. Maintenance. Laboratories. Local government. Field services. Industrial equipment. Healthcare administration. The list is endless.

A lot of these places were simply too small, too "unsexy" or too expensive to serve with traditional software economics, especially after engineers became one of the best paid career choice. You can blame me too, I decided to work mostly within the "sexy" industries in my career, because anything else was either too underpaid, or too bothersome to work on. In most cases it was a mix of both. This is why all these industries haven't seen much innovation on software yet, too many edge cases, too many custom processes, not worth doing for what is required to make a change.

But this is where everything is changing now. Small teams can now build specialized tools for markets that previously couldn’t justify the best of the best engineering talent. Small teams are able to do things that took years, and now do it within months. End to end. Small teams have all the necessary tools now to make proof of concepts within days, which is massive if you rely on traditional sales (which most of these industries do).

And even further, lets not forget about all the terrible enterprise software out there owned by massive corporations who locked in clients since the late 90s and didn't change a single thing since then, either for similar reasons (not worth it) or simply because they are sitting on massive contracts and make most of their money selling courses/coaching that teach their very own complex software (see SAP, Salesforce etc.).

All these companies are completely vendor locked due to switching cost, but that switching cost is slowly disappearing.

Maybe I am too optimistic here, but there are entire industries still waiting for their first piece of software that is truly designed for the people using it.

Is it going to be easy? Definitely not. You still have to put in the work. But its at least 100x better than how it was before.

The opportunities right now are endless.

Instant lifetime access to 1600+ premium Framer components, sections, and full website templates, all inside one native Framer plugin.

Minimalist logo design has been getting some stick in recent years. Simplicity in visual branding often makes a lot of sense. A clean, uncomplicated logo can be more memorable, it looks more modern and it's easier to use across different media, but then came anti-design and the backlash to what some see as a trend towards homogeneity in branding, or 'blanding', as it was dubbed.

Some argue that minimalist redesigns can strip a logo of its character, and we've seen the complaint everywhere from the great Cracker Barrel outrage to the new Harry Potter logos.

The new Sunlife logo is unlikely to end the debate. It might be one of the most dramatically simplified logo redesigns yet. The Canadian financial services company has eliminated the space from its name and all detail from its mark.

Sunlife, now one word, says its new logo is intended to bring its identity in line with the evolution of its business. While the design had barely changed in 25 years, the company has expanded from life insurance into services in health, asset management and other types of insurance.

There's also a new tagline, 'Making life brighter'. This is intended to connect to Sunlife's purpose of "helping clients build lifetime financial security and lead healthier lives".

"Together, the changes create a more modern, distinctive and consistent expression of Sunlife around the world," the company says.

"A great brand isn't defined by a logo. It's defined by the experiences it creates," said Linda Dougherty, Executive Vice-President, Chief Client and Strategy Officer, Sunlife. "Making life brighter captures what we want every Sunlife experience to deliver for Clients: greater clarity, confidence and connection. Our new identity gives us a powerful, consistent way to bring that commitment to life around the world."

The modernised, simplified logo, was "optimised for a digital world", the company says.

The old design was very much giving the corporate vibe of an insurance company from 25 years ago. The new symbol keeps the sun, or a weather forecast-like ultra simplification of it, and keeps the colour, while stripping out the fat. The wordmark, meanwhile, continues to use a serif font, but it feels slimmer, lighter and more contemporary.

The simplicity of the mark has sparked some bemused responses on social media, from people who think it's taken minimalism too far. "Is this satire," one person asks on X.

We have seen comparable designs to the yellow disc coming in other colours. Sunlife's compatriots the Green Party of Canada rebranded last year as the green dot emoji with the logic that it would help to have an easily shareable logo for social campaigns. There's also USA Today with its blue disc logo.

I think that with the serif wordmark, the overall design looks distinctive and a lot less dated. The combination of Sunlife into one word reads much better, and makes more sense now the company's no longer primarily a life insurance provider – the 'life' no longer makes you immediately think of death, which is probably a good thing for most brands.

AI is putting pressure on analytics teams that simply fulfil requests, as businesses increasingly believe they can get answers without them. To stay valuable, data professionals must understand the business, challenge assumptions, and turn reliable analysis into clear decisions.

Mercedes-Benz's open-source dbt_iterative_snapshot package for Databricks processes batches chronologically and automatically repairs historical records when late data arrives.

n8n has refreshed its identity with a new logo, typeface, and refined color system to reflect its evolution from workflow automation into a platform for building interconnected workflows and AI agents. The new mark shifts attention from connected nodes themselves toward the activity happening between them, while the typography balances technical precision with the human character of n8n's builder community. Rather than rebuilding the brand from scratch, the system preserves recognizable elements such as its signature pink while creating more flexibility for an expanding product ecosystem.

Fábio Simão dos Santos, a freelance comic book penciler who has made a living as an artist since 2019, is a rising talent in US indie comics.

Tarn Leith, a freelance concept artist working as TJL Art, creates hard-surface designs and character concepts that sit between science fiction and fantasy.