Amazon Aurora PostgreSQL now supports direct querying of Apache Iceberg and Parquet data in your data lake

Today, we’re announcing a new capability for Amazon Aurora PostgreSQL that you can use to directly query operational data together with data stored in your data lake in Apache Iceberg and Apache Parquet formats, using your existing PostgreSQL applications and tools. By eliminating the need to extract, transform, and load (ETL) structured data from data lakes into your operational database, you can reduce operational complexity and simplify application development. You can also use Aurora PostgreSQL to query data from data lakes managed in Iceberg REST Catalog (IRC)-compatible catalogs, giving you access to data across a breadth of analytics systems without moving or duplicating it. Whether you’re powering real-time dashboards, enriching transactions with historical context, or building AI agents that reason over both live and archived data, you can now do it all through a single, familiar interface.

Previously, if your application needed to combine recent transactional data in Aurora with historical records stored in Amazon S3, a common approach was to build reverse ETL pipelines that duplicated data, increased infrastructure costs, and required ongoing engineering effort to keep everything synchronized. This challenge only grows as you increasingly embed AI agents into your applications, where it is impractical to predict and pre-replicate every dataset an agent might need.

DuckLabs, the team that maintains the DuckDB project, recently joined Amazon, and this capability is an example of how the efficiency of DuckDB is being integrated into our services. DuckDB is now embedded directly within Aurora PostgreSQL, so you can query live operational data (including uncommitted writes) alongside your data lake in a single query. Query processing stays within Aurora, with no additional network hops and no ETL pipelines that duplicate data. You can query Apache Iceberg tables managed through the AWS Glue Data Catalog, as well as Parquet and Iceberg data stored in Amazon S3 and S3 Tables. You do all of this using familiar PostgreSQL syntax and your existing applications and tools.

We’re excited to bring the speed and simplicity of DuckDB directly into Aurora PostgreSQL, so you and your agents can query and combine operational and Iceberg data using the familiar PostgreSQL applications, tools, and endpoints already in use. By building this capability around DuckDB, future improvements to the open source engine can continue to bring performance and functionality gains to Aurora and other AWS services.

What is new

This capability is supported on two Aurora PostgreSQL major versions: 17 (starting with 17.11) and 18 (starting with 18.6). To use it, you create an Aurora PostgreSQL cluster, attach an IAM role with the AuroraAnalytics feature, and enable the aurora_analytics extension. The IAM role is what gives Aurora access to your data in Amazon S3 and the AWS Glue Data Catalog. You then create foreign tables that point to your Iceberg or Parquet data in the data lake, and query them using familiar PostgreSQL syntax. You can complete this setup through the Amazon RDS console, or with any PostgreSQL client such as psql. The process is well documented in the Aurora PostgreSQL documentation.

You can query data across external IRC-compatible catalogs through AWS Glue Data Catalog federation. You register the external catalog once with Glue, and then create foreign tables for the tables you want to query, the same way you would for any Glue-native table. A single query can then join data stored in Aurora with Iceberg tables registered across multiple catalogs, so applications get a unified view without moving data or replacing your existing catalog investments.

Aurora also applies optimizations such as predicate pushdown and column pruning so that only the relevant data is read. This keeps queries efficient even as the underlying data grows. Frequently accessed data is also cached in your Aurora instance, so subsequent queries against the same data return faster. You can inspect this behavior per query using aurora_analytics_stat_statements(), which reports metrics such as rows scanned, bytes read from Amazon S3, and cache hits.

To see how direct querying works, I connected to my Aurora PostgreSQL database using psql and created the extension:

CREATE EXTENSION aurora_analytics;

For my walkthrough, I set up a simple financial scenario. I have a recent_transactions table in Aurora with the last 7 days of customer transactions, and a Parquet file in Amazon S3 containing 5 years of historical transaction data. To make Aurora aware of the historical data, I created a foreign table pointing at the Parquet file in S3:

CREATE FOREIGN TABLE transaction_history ()
SERVER aurora_analytics_server
OPTIONS (
    location 's3://<my-bucket>/finance/transaction_history.parquet',
    format 'parquet'
);

Notice the empty parentheses in the CREATE FOREIGN TABLE statement. Aurora automatically reads the schema from the Parquet file metadata, so you do not need to define columns manually. For workloads with many tables, you can skip creating them one at a time: a single IMPORT FOREIGN SCHEMA statement bulk-creates foreign tables for every Iceberg or Parquet table in an AWS Glue Data Catalog database, inferring schemas automatically.

With both tables in place, I ran a single query that combines the recent operational data in Aurora with the historical data in S3:

SELECT merchant, category, amount, transaction_date, 'recent' AS source
FROM recent_transactions
WHERE customer_id = 'C-1001'
UNION ALL
SELECT merchant, category, amount, transaction_date, 'historical' AS source
FROM transaction_history
WHERE customer_id = 'C-1001'
  AND transaction_date >= CURRENT_DATE - INTERVAL '5 years'
ORDER BY transaction_date DESC
LIMIT 15;

The result shows both recent and historical transactions in a single result set. The 7 most recent rows come from Aurora, and the rest come directly from the Parquet file in S3. DuckDB handles the analytical scan of the Parquet data under the hood, while Aurora handles the operational data. That single query would have previously required a pipeline to move the historical data into the database first.

If a query pattern needs single-digit-millisecond latency, you can materialize data from the data lake into a native Aurora PostgreSQL table using familiar commands such as CREATE TABLE AS SELECT, INSERT INTO ... SELECT, or MERGE INTO. The materialized table lives in Aurora and is queried like any other PostgreSQL table, giving you a low-latency path for hot data without operating a separate ingestion pipeline. The read queries can run on any Aurora PostgreSQL instance in your cluster, whether the writer or a read replica, so you can offload analytical scans from your operational workload. The materialization commands write data into Aurora, so they run on the writer instance.

Get started today

Direct querying of Apache Iceberg and Parquet data from Amazon Aurora PostgreSQL is available today in all commercial AWS Regions and AWS GovCloud (US) Regions, at no additional charge. You pay only for the incremental Aurora compute the queries consume and Amazon S3 request costs for reading data lake files.

To learn more, visit the Amazon Aurora features page, read the Aurora PostgreSQL documentation, or try it in the Amazon RDS console. We welcome your feedback through AWS re:Post or through your usual AWS Support contacts.

When you type in an address into a browser, how do you know you’re connecting to the right website? The Web Public Key Infrastructure (Web PKI) is the complex and distributed ecosystem of policies, protocols, and infrastructure operators that helps you trust that you’re not being misdirected to an incorrect or malicious website. In the past few decades, this ecosystem has undergone significant changes. One is the addition of transparency: the now-mandatory requirement that all certificates be logged in public certificate transparency logs. Now it faces another challenge: the imminent arrival of a quantum computer, which has prompted us to upgrade to post-quantum (PQ) cryptography by 2029.

This transition is not straightforward: simply swapping post-quantum cryptography into certificates at Internet scale would lead to unacceptable performance degradation. This moment calls for a new approach to the Web PKI, one that allows us to treat transparency as a first-party property rather than an add-on, and design a new system that scales post-quantum signatures efficiently.

After gaining broad support across the industry, Merkle Tree Certificates (MTCs) have emerged as the path forward. This year, after a successful experimental deployment with Chrome, Cloudflare is full steam ahead on MTCs.

Following today’s announcement that Cloudflare is becoming a certificate authority (CA), we’re excited to share that this CA will support MTC issuance, targeting early 2027 for inclusion in Chrome’s newly launched Quantum-resistant Root Store. As part of our mission to help build a better Internet, and following in Cloudflare tradition of offering the strongest available cryptography for free, we will provide standard MTC issuance at no cost. Having a CA that supports both classical certificate and MTC issuance allows us to default to the most secure authentication method available, providing a painless and performant PQ upgrade path for a large swath of the Internet.

The current trust ecosystem

To understand how MTCs are changing the game, let's start with some background on how trust works on the web today.

On the client side, browsers — in this case, “TLS clients” — maintain root programs, which specify a set of policies that CAs must follow to be trusted. On the server side, CAs are the trusted gatekeepers: they operate certificate issuance infrastructure where they validate domain ownership and attest to the binding of a domain name and a public key that shows ownership of that domain.

But how do we check that CAs are following the rules? Enter certificate transparency (CT), which makes certificate issuance publicly auditable. When a CA issues a certificate, it must also submit that certificate to at least two public logs. Cloudflare has operated the Nimbus family of CT logs since 2016, and is launching Raio, a new family of static CT logs, going forward.

While the CT ecosystem makes certificates publicly viewable, it doesn't mean they are correctly issued or safe to use. Monitoring helps with this by comparing those log records with what domain owners expected and reporting suspicious activity. Cloudflare launched Certificate Transparency Monitoring in 2019 and recently made it generally available. We also publish large-scale measurements about certificates on the Certificate Transparency page in Radar (formerly known as Merkle Town).

As organizations begin upgrading their servers to use PQ authentication, certificate transparency monitoring will take on an even more important role in detecting potential post-quantum downgrades. Domain owners who have upgraded their domains to post-quantum authentication should monitor CT logs for unexpectedly issued legacy certificates to prevent clients from falling back on a malicious downgrade path.

Part of the problem with this current system is that transparency was an add-on, causing it to run into scaling issues. Certificates are frequently logged multiple times, in different forms, across multiple logs, requiring monitors to download and process every log to avoid missing an issuance. This can be expensive — making it difficult to encourage a diverse set of log operators at Internet scale. According to our estimates, PQ signatures will balloon the amount of data that CT logs need to store by 40x. This scaling challenge, and subsequent incentive misalignment, is at the heart of the post-quantum scaling problem.

The post-quantum scaling problem

We've written extensively about the challenges of scaling post-quantum cryptography, but in short: to support server authentication at Internet scale, the WebPKI must authenticate roughly a billion TLS servers without preloading every server’s public key into every client. Traditionally, CAs addressed this problem by using certificate chains as a trust-distribution mechanism. But over time, additions like key revocation checks and certificate transparency have added more public keys and signatures — five signatures and two keys in a typical TLS handshake. PQ signatures are roughly 40 times larger than classical ones, creating larger overheads that would be expensive for clients, CAs, logs, and monitors to handle at scale.

Enter Merkle Tree Certificates (MTCs), a draft specification from the IETF PLANTS working group that describes an architecture for compact, efficient, post-quantum certificates. MTCs batch certificates into an append-only Merkle tree, allowing a CA to sign the root of that tree instead of many individual certificates. This allows browsers or other clients to verify a certificate using a compact inclusion proof — a sequence of cryptographic hashes — against a signed tree head rather than validating each certificate individually. A key idea behind MTCs is "don't log what you issue, issue by logging." By coupling issuance and logging, transparency becomes a requirement for operation, rather than an add-on.

The role of a certificate authority in a redesigned PKI

We’re building out our capability to issue MTCs as an integral part of our creation of a Cloudflare CA. That means keeping track of new PQ Root Program requirements, and writing an issuance and mirroring software stack at the same time we’re building the facilities, operations, and compliance functions of the traditional CA — no small feat!

The upside is that we get to prioritize the requirements and architecture for this new, post-quantum PKI from day one, building our setup in a way that feels right for Cloudflare's values and global network — aiming to be as transparent as possible as we embark on this new journey.

Let’s take a look at the architecture updated for MTC:

If you compare this to the traditional CA ecosystem, you'll notice that the responsibilities of a CA stay mostly the same: to validate control of a domain, bind it to a public key, and issue certificates. The main difference is that in the MTC ecosystem, instead of signing certificates directly and then logging them, the CA now maintains a transparency log backed by a Merkle tree, where an inclusion proof that the certificate is indeed in the tree serves as the trust anchor. CAs will also operate Mirroring cosigners that store a copy of issuance logs, verifying their append-only consistency and ensuring the transparency and availability of these logs for the broader ecosystem.

Issuing MTCs

MTCs come in two forms, both of which can be encoded in the X.509 certificate format that client software recognizes today — just with a “funny” signature algorithm. In standalone form, the certificate’s signature value contains a cosigned tree head of an issuance log and an inclusion proof (a sequence of hashes) demonstrating that the certificate is contained in that log. If clients are able to obtain the cosigned tree heads out of band (e.g., via a browser update mechanism), the certificate can instead be served in landmark-relative form, where the signature value consists of the lightweight inclusion proof with no heavyweight post-quantum signatures at all.

For simplicity’s sake, let’s take a look at an example of standalone certificate issuance. When a website wants a certificate for their domain, they can request it from a CA via the Automatic Certificate Management Environment (ACME) protocol, which handles certificate requests, domain-control validation, and issuance workflows. Cloudflare's ACME infrastructure will be a fork of Boulder, the widely deployed and well-tested ACME software that powers Let's Encrypt. Let's Encrypt is actively developing MTC support in Boulder, and we plan to maintain our own fork that incorporates these upstream changes along with Cloudflare-specific modifications, contributing back upstream where possible.

When the MTC CA receives a certificate issuance request, the CA's ACME server checks that the server actually controls the domain. If those checks pass, the CA serializes that data and adds it to an append-only log.

After adding the MTC entry into its issuance log, the CA computes the updated state of the log, and then signs a checkpoint over that state. This checkpoint attests that the CA issued every entry included in the log’s Merkle tree up until that point in time.

The CA then sends its updated log state and new checkpoint to a trusted cosigner, which durably stores a copy of the CA's issuance log and checks that each new state is append-only, consistent with the previous tree, and correctly formed. This additional cosignature gives clients and monitors confidence that another trusted party has observed the same log state and verified that the CA is not presenting different views of issuance to different parts of the ecosystem. It also ensures that the issued certificates will be available for monitoring even if the CA issuance log is unavailable.

Chrome’s Quantum-resistant Root Program draft policy mandates at least two cosignatures: one from a Chrome-recognized Mirroring Cosigner operated by a distinct organization, and one from the issuing MTC CA itself. As such, we'll operate mirrors for other pilot CAs — and require at least one independent cosignature on our own issued certificates.

Cloudflare will implement our mirroring cosigner in Azul, our open-source Rust-based transparency log, and for maximal interoperability, it will implement c2sp's tlog mirror protocol.

Finally, after successfully receiving a cosignature from a mirroring cosigner, the CA constructs an MTC with the cosignatures, server's public key, and an inclusion proof. It then sends that MTC to the server, which can then use it for TLS moving forward!

Delivering PQ signatures efficiently: the landmark optimization

While standalone certificates are functional, they still send large PQ signatures over the TLS handshake, limiting their efficiency. The real performance improvements provided by the MTC design are landmark-relative certificates.

Instead of sending cosignatures in every certificate, CAs can designate a sequence of subtrees that cover all active certificates in the log as a landmark, and distribute those subtrees (along with data to authenticate them) to clients via an out-of-band update service. During a TLS handshake, the actual authentication to the server happens by the browser checking that the server's certificate data — including its domain name and public key — appears in a trusted subtree of the CA’s log. If the inclusion proof connects that certificate to a cosigned landmark, and the public key then proves possession during the TLS handshake, the client knows it is talking to the right server.

Periodically transmitting these signatures and tree metadata to TLS clients out of band, a small set of MTC batch signatures can efficiently cover billions of certificates issued by a given CA. While landmarks are more efficient at scale, they do not eliminate the need for standalone MTCs — clients may be newly installed, offline, or missing the relevant landmark update. That’s why it’s important that servers retain a standalone certificate fallback.

MTCs in the wild: results of our experiment with Chrome

This year, we ran an experiment with Chrome to test the feasibility of MTCs between a client and server. We operated a "bootstrap CA" (a fake CA that stubbed the issuance pipeline) that issued MTCs backed by a traditional certificate chain for a selection of Cloudflare domains on Cloudflare's "free" plan and served them to 50% of Chrome Beta 146. Over the course of the experiment we successfully served billions of MTCs.

For TLS, we found that the common case is fairly efficient: with a landmark-relative certificate, the handshake only needs to transmit one public key, one signature, and one inclusion proof of less than 1kB. In the experiment, we fell back to the traditional certificate chain instead of serving a standalone certificate in cases where we were unable to negotiate a landmark-relative certificate with the client. On the CT side, MTCs also change the scaling properties of transparency: the log only needs to carry hashes of public keys; there are no per-entry signatures, and the signature on the tree head covers the whole log. This prevents certificate explosion because the CA issuance log is the source of truth for all certificates the CA issues, and log consumers only need to fetch a single copy of each certificate.

The result: MTCs really work! At median, using a MTC is 9% faster using landmark MTCs over a classical signature chain (admittedly, most of this performance benefit is due to intermediate elision). And because we tested MTCs with classical signatures, we expect an even greater improvement with post-quantum signatures. Satisfied with these results, and with the level of cross-industry collaboration with MTCs at the PLANTS WG at the IETF, we began winding down the experiment last month (August 2026).

The road ahead for MTCs

We’re excited that our experiment with Chrome showed that MTCs can work in practice, and are especially excited to be able to issue certificates as a real CA.

However, there are still broader questions that we can only answer by running this great experiment with the full PKI ecosystem. Can independent monitors consume and verify MTC issuance logs at production volume? Will multiple CAs and cosigners emerge so that the system has the diversity needed for resilience? How should browsers balance the performance benefits of compact landmark MTCs with the fallback paths needed for clients without fresh landmarks? MTCs have emerged as the authoritative design for post-quantum authentication, but proving it out at production Internet scale will require participation from a diverse set of root programs, browser vendors, CAs, mirrors, monitors, and the wider community.

We see the opportunity to participate in this next phase of the Web PKI as an honor, and we take the responsibility of operating CA infrastructure seriously. CAs occupy a privileged position in the trust ecosystem — browsers, domain owners, and everyday people rely on them to validate identities correctly, protect signing keys, follow policy, and operate reliably. Before Cloudflare's CA can be trusted by browsers to issue MTCs, we will need to apply to Chrome's Quantum Resistant root store and undergo a rigorous evaluation process. We welcome that scrutiny, and we expect to hold ourselves to the same high bar as any other CA trusted with helping secure the Internet. We hope other CAs will emerge to support MTC adoption, and we're excited to work with any browser that wants to deploy MTCs.

Code Execution is now generally available in the Datadog MCP Server. Instead of calling tools one at a time, your AI agent can write JavaScript that queries Datadog directly, run that code in a Datadog-managed sandbox, and get back only the result it needs.

When we ran our evals against four different models, agents using Code Execution cut costs by sending 73% fewer input tokens to the model. The agents also were more accurate, getting the right answer 90% of the time (up from 74%), and taking 40% fewer tool calls to get there.

How Code Execution works

Most complex queries require accessing multiple sources of data. For example, you see an error spike, check the traces behind it, and then look for the deploy that lines up with it. With standard MCP tools, each of those steps is a round trip: The agent calls a tool, reads the full raw response, decides what to do next, and calls another tool. By the time the agent answers, most of the model’s context window is filled with intermediate data that the agent needed only for that step.

Code Execution removes much of the intermediate data from the context window. The agent writes a script that directly queries Datadog APIs, and the Datadog-managed sandbox runs the queries in parallel and joins the results. The model sees only the results.

Without Code Execution, the agent would pull both full result sets into the conversation and do the join itself.

Because the agent is writing code against your data, the sandbox never gets your credentials. When the code calls a Datadog API, the MCP Server makes the request on your behalf with your existing permissions and returns only the result.

Get more accurate answers while spending less

To measure how Code Execution affects investigation quality and cost, we compared it with Datadog’s Core toolset. We ran 25 observability tasks related to metrics, logs, traces, Datadog Error Tracking, and investigations. Each task ran three times per model with each toolset, on GPT-5.6 Terra, GPT-5.6 Sol, Claude Sonnet 5, and Claude Opus 4.8, and we scored the final answers for correctness.

The results showed that all four models improved in answer accuracy with Code Execution. The biggest increase was for Claude Sonnet 5, which went from 67% to 89% correctness.

Code Execution also reduced how much each agent had to read. Averaged across the four models, input tokens per task dropped from 159k to 43k, and tool calls fell from 4.1 to 2.5. The models averaged between 107k and 197k tokens with the Core toolset, but all four models ended up between 38k and 46k tokens with Code Execution. Since many providers bill by the token, fewer input tokens can mean that each investigation costs less to run.

Get started with Code Execution

To get started with Code Execution, connect the Datadog MCP Server to your AI client and enable the code-exec toolset.

When Code Execution is enabled, ask your agent a question that requires it to correlate multiple kinds of observability data. For example: “Find the services whose error rate changed after last night’s deployments, then show me the trace patterns that changed with them.” The agent can use Code Execution to gather the relevant data, correlate it, and return the evidence behind its answer.

To learn more, see the Code Execution documentation, the toolset configuration guide, and the Datadog MCP Server documentation.

Ask any penetration tester which part of a Kubernetes assessment reliably produces a finding, and RBAC comes up almost every time. Not because Kubernetes’ permission model is poorly designed — it’s genuinely thorough — but because it’s flexible enough that teams misconfigure it in the same handful of ways, over and over, across completely unrelated organizations.

Cryptojacking campaigns targeting exposed Docker and Kubernetes infrastructure have been a recurring theme in 2026 threat reporting, and container escape and Docker-in-Docker risks keep showing up in cloud-native security roundups. Almost none of these incidents involve a novel Kubernetes vulnerability. Most of them involve a role binding someone created eighteen months ago to “just get something working,” that no one ever revisited.

The Misconfigurations That Show Up Constantly

• cluster-admin bound to a service account for convenience. Somewhere in most clusters is a service account bound to cluster-admin because a deployment kept failing on a permissions error and the fastest fix was the broadest one. That service account’s token, if it ends up in a compromised pod, is functionally the keys to the entire cluster.
• Wildcard verbs and resources in custom roles. A Role or ClusterRole with resources: ["*"] and verbs: ["*"] technically satisfies whatever access problem prompted it, and it also grants far more than intended — often including the ability to read every Secret in the namespace or cluster.
• Secrets read access granted more broadly than the workload needs. get and list on Secrets are among the most consequential permissions in the entire RBAC model, because Secrets frequently contain credentials for other systems entirely — cloud provider keys, database passwords, other clusters’ service account tokens. They’re also among the most casually over-granted.
• Bindings that outlive the project they were created for. RoleBindings and ClusterRoleBindings don’t expire. A binding created for a three-week migration project frequently outlives the project by years, because nothing forces a review the way a certificate expiration or a patch cycle does.
• Default service account tokens mounted into pods that never use them. Unless explicitly disabled, every pod gets a service account token mounted automatically. If that pod is compromised through an application vulnerability, the attacker inherits whatever that service account can do — which, per the points above, is often more than anyone intended.

Why These Keep Happening

RBAC misconfigurations aren’t usually a knowledge gap. Most platform teams know least privilege is the goal. The problem is that RBAC is easy to over-grant under time pressure and hard to audit after the fact — there’s no single kubectl command that answers “what can everything in this cluster actually do, in aggregate,” and permissions accumulate the same way file-share access does: quietly, and in the direction of more.

What Closes the Gap

• Run kubectl auth can-i --list against real workload identities, not just admin accounts. This surfaces what a specific service account can actually do, which is usually more revealing — and more alarming — than reviewing the RoleBindings in isolation.
• Use an RBAC visualization tool before every access review, not just during an incident. Tools like rbac-lookup or kubectl-who-can turn “who can read Secrets in this namespace” from a multi-hour manual audit into a single query. If nobody runs that query quarterly, the sprawl compounds silently.
• Disable automatic service account token mounting by default. Set automountServiceAccountToken: false at the pod or ServiceAccount level unless a workload specifically needs the Kubernetes API, and grant it explicitly when it does.
• Ban wildcard verbs and resources in custom Roles via policy, not convention. Admission controllers like Kyverno or OPA Gatekeeper can reject a Role or ClusterRole that uses resources: ["*"] or verbs: ["*"] before it’s ever applied, closing off the most common shortcut before it becomes a standing risk.
• Put an expiration discipline on bindings tied to temporary projects. If a RoleBinding exists to support a migration or a proof of concept, put a calendar reminder or a labeled review date on it. Nothing else will force the cleanup once the project ships.

The Bottom Line

Kubernetes RBAC gives you every tool you need to enforce least privilege precisely. It doesn’t enforce it for you, and it doesn’t tell you when a shortcut from eighteen months ago has quietly become the easiest path to cluster-admin in your environment. That gap between capability and default state is exactly where most of these findings live — and exactly why it keeps showing up in assessment after assessment.

I got the most complicated backend I have ever built to alpha in less than two weeks. The worrying part is how quickly that started to feel like a reasonable expectation.

Over the past few weeks I have shipped a new Noord site, expanded and released a design system, built a workspace for people and AI agents, and launched three workbooks. I am pleased with the work. I am also watching my definition of a normal amount of work become completely unreasonable.

Nobody has imposed this on me. That would at least give me someone to complain about.

Speed

The Noord site rebuild ran from late August into early September. Vlak had its first release on 4 September, followed by the main announcement on the 8th. Bureau's first prototype shipped 10 September; by the 18th it had an invitation-based alpha and a waitlist. I publicly launched The New Standard on the 22nd. On the 25th, the approval email arrived for Vlak's ChatGPT plugin.

The workbooks have been in the works for years. They bring together my research, writing and thinking about leveling, compensation and development: what responsibility means, how people get paid, and what actually helps someone grow.

AI helped me turn that work into something considerably more useful than a PDF. Stripe checkout, paid access, interactive tools, editable templates: parts of the project that could each have become a separate undertaking came together quickly. I could also integrate recent, sourced salary and compensation references into the guide, with dates and explanations of what the numbers do and do not mean. These need updating as the market changes. It also leaves time for me to explore a print run of the workbooks.

Some of the speed, then, is old work finally getting out of the house. Divide years of thinking by the days spent building the checkout and you get an excellent productivity statistic. You also get nonsense.

Building the things I needed to build the things

At Noord, I build products and interfaces with the help of our own agents. I need to find out whether an interaction works, whether the product is useful, and whether it deserves more investment. A convincing-looking screen can make all three questions harder to answer.

I know this because I like making convincing-looking screens.

Vlak is a deliberately quiet design language for that work. Consistent components and restrained styling let us compare interactions without redesigning the visual world around each one.

I still care about how it looks. I want the design to help us notice a weak idea before we have fallen in love with the ease of its transitions or adherence to a particular platform.

Through September it grew into more than 200 components, documentation, videos and 30 downloadable interface starters.

The next problem was bringing the work I was doing with different agents into one place.

I also wanted my human collaborators in there. I’m building with Fable/Opus, Astra and Grok at the same time, and I wanted one interface where I could talk to all three. Otherwise I’m copying things between chats, explaining what another agent did, and bringing people up to speed on work they couldn’t see happen.

So I built Bureau: Slack-style channels, with agents attached to the workspace rather than one person's private conversation. People can work with the same agents and see the work together. I wanted agents to participate in the team, instead of making each person the courier between their AI and everyone else.

Not living (physically) in the Bay Area anymore helps see the disconnect between frontier work and the rest of the world.

Watching someone work with an agent in real time is much more instructive. You see what they give it, where it gets stuck, and how they correct it. Those exchanges are useful to everyone else in the channel, including the person who has barely used an agent yet. I want people to be able to learn by watching each other work.

Building Bureau was the biggest technical departure for me. My building had mostly been on the front end. Bureau needed a real backend: accounts, workspace boundaries, shared conversations, permissions and agent jobs that keep running after someone closes the app. It is the most sophisticated backend I have built, on a stack I had not worked with before.

I've built an explanation into the end of every run. The agent has to walk me through what it built and how it works. I need that especially on the backend, where I have less experience. I want to understand the code I’m now responsible for.

At the moment, I’d put my time at roughly 40% new features, 40% agent and infrastructure architecture, and 20% interface polish. That is a very different working day from the frontend projects I used to focus on.

The bar keeps moving

The immediate effect has not been that I ship things faster or better than my teams could.

I just include more. The book gets an interactive tool. The design system gets installable starters, documentation and a plugin. The prototype becomes a shared workspace. The point at which I would once have been delighted to stop becomes the point at which I notice what is missing.

Some of that is a genuine improvement in quality. A reader who can test a pay decision gets more than a reader who can only read about one. Some of it is me expanding the job because the next piece is suddenly possible. From inside the work, those can feel remarkably similar.

The skill gaps are becoming clearer too. I can build a lot, but making Bureau more efficient means getting into server hooks, tracing slow responses and working through the code until the interface feels quick. That means spending a few evenings really pushing on React Virtual. I find that work deeply valuable and incessantly boring. This is inconvenient, because the app still needs it.

That puts a direct limit on how good Bureau can become if I’m the only person running it. I can ask an agent to help, but I still have to judge the result and keep paying attention. There are people with both the experience and the appetite to take that work much further. Building more is making it easier to see where I need them.

Shipping is also becoming suspiciously rewarding. You make a decision, something changes, you can use it, and then you can do it again. The gap between wanting a thing and seeing it exist is short enough to keep pulling me back in.

What concerns me is how quickly I adapt. Something that would recently have felt like a major undertaking becomes the minimum I expect from myself. I want the higher bar. I am less sure I want every available hour to become evidence that I could have shipped one more thing.

What should become a company?

Vlak helps us build, the workbooks package years of thinking, and Bureau is a bet on how teams could work together. They have different reasons to exist. But the question that interests me is much wider than my own projects: what happens across software when far more people can make what they need?

I expect more useful software to live outside startups. Someone makes a tool for their own work, a team adapts it, a small business sells it to paying customers. None of these has to become a venture-backed company. A useful product does not owe anyone a funding announcement.

That changes the competition a founder has to think about. The alternative to a new product might be another startup, something the customer can build in-house, or a feature their existing supplier could add. A founder still needs to explain why someone would choose their product and keep choosing it after the alternatives improve.

A working demo can show which problem a founder noticed and what they chose to leave out. As more people can produce one, I expect it to carry less weight on its own in a funding decision. It cannot show that customers will change how they work, keep using the product, or pay someone else to run it.

My view is that, unless a software startup is doing frontier work, the majority of the money it raises should go toward discovering or building distribution channels. If the science or technical feasibility is genuinely unresolved, funding the build is the bet. But if you are building on capabilities that already exist, I would want a much better explanation for why most of the round needs to disappear into product development.

Distribution might mean a partner whose customers need what you make, a community where you earn people's trust, or an integration that puts the product inside work they already do. It might be built into the product, with one person bringing their colleagues in because it becomes useful together.

Early money should buy enough experiments to discover which of those routes brings people who actually use the product and stay. Then it can pay to make a working channel repeatable and reach more of them. Buying traffic before you know that is an expensive way to get a chart.

This is about what the spending achieves, not which department receives it. An integration that gives a company access to an existing customer base can be distribution work. An integration that merely adds another feature still needs a different justification. Product quality, security and reliability need funding too. But another quarter of features should not be the default answer to why the company needs another quarter of runway.

I would want a funding pitch to spend less time proving that the founder can build, and more time showing why customers will make room for what they built.

I am enjoying this enormously. I like that a book can contain a working tool, and that wanting a different way to collaborate can lead to building one.

I want to keep this ability. I also want to be able to leave an idea alone without feeling that I have wasted the afternoon.

AI assistants are increasingly being used to control creative software and speed up tasks. After Adobe added its own AI assistant in Photoshop earlier in the year, Maxon's now added native support for third-party chatbots in Cinema 4D.

The update means you can now use Claude, ChatGPT or Codex AI assistants to carry out workflows in what is one of our picks as the best 3D modelling software and the best animation software.

Maxon's not introducing its own AI assistant. Instead, it's added a built-in Model Context Protocol (MCP) whose server enables artists to direct Claude, ChatGPT or Codex AI assistants within Cinema 4D workflows.

Artists can then provide natural language instructions to the assistant of their choice to eliminate some of the more procedural, iterative and repetitive manual processes, theoretically without interrupting creative flow.

Maxon cites examples like organising imported objects into a consistent hierarchy, creating object and material variations, preparing multipass renders, organising scenes, and handling basic 3D camera tracking, UV mapping, rigging and animating. The videos below demonstrate processes for motion tracking and for automating repetitive tasks like creating render queue jobs and building scene variations from CSV data.

Maxon says its approach is designed to keep artists in control. Every action happens through Cinema 4D's own tools in the artist's own scene, running locally on their own computer. The results remain native Cinema 4D scene data rather than a flattened generated output, allowing artists to review, refine, undo or iterate on them as they work.

The MCP is switched off by default, requiring users to proactively enable it. The server is protected by an MCP adapter access token, and artists can choose which groups of Cinema 4D tools their assistant is permitted to use.

Actions are performed through Cinema 4D’s own API, and each batch of MCP-driven changes is broken down in the undo history. Commands are also written to a local audit log, providing visibility into what actions the assistant has taken.

The decision to support third-party AI assistants echoes how Maxon added 3D model generation in Cinema 4D via Tencent’s HY 3D AI engine.

MCP support is available beginning today in Cinema 4D 2026.4 or later on Windows and macOS. A new Cinema 4D iPad app is slated for release before the end of the year.

The MCP connection can be activated without additional installs. You can learn more on the Maxon website.

Full article content is not available for inline reading.

Read the original article →

Over the last few weeks, there has been lots of buzz around decision models such as Typesafe AI’s Jev System One model. While classifier models have been around for some time, Jev introduces a new decision model concept into the world of AI — a model that produces bounded structured outputs cheaply, quickly and consistently that can be added into a workflow when a decision is required. These models are capable enough to work over any set of inputs without constantly retraining the model to incorporate new classification categories. This contrasts with the world of Large Language Models (LLMs), which are largely non-deterministic, but are open-ended enough to reason and generate text and tool calls for agentic workloads.

Today, we’re releasing two Cloudflare-trained decision models, Clef and Clef-flash, hosted on Workers AI. Clef is currently the leader when evaluated against the Jev Decision Index, you can view full results on the live benchmark demo site. These models are smarter, faster, and fully Jev-API compatible, so you can experiment with these hosted models easily. We’re fully open-sourcing these models on Hugging Face under an Apache 2.0 license for you to run locally and experiment with yourselves.

Lastly, we’re excited to debut our new reinforcement learning (RL) product, which allows customers to fine-tune Clef to suit their use cases as well.

What is a decision model?

A decision model makes classifications to help agents decide how to act, based on certain probabilities. For example, you can pass in a customer support message (inputs) and ask if it is urgent and which team should handle it. A decision model will return typed answers with probabilities (outputs), which your code can use to route the ticket, trigger an escalation, or defer to a human. This means that a human does not necessarily need to be in the loop for agentic decisions anymore — agents can programmatically gather context, make decisions, and take actions on tasks, or defer to a human when needed.

Specifically at Cloudflare, we’ve been testing our new Clef model on our Threat Intelligence team to help us classify website domains. By giving a domain to Clef (with Browser Run) it can quickly identify categories that the domain falls under — for example, it might classify a domain with a 95% chance it is a fashion website, 85% ecommerce, <1% phishing, etc. This classification took our Clef model 2.2s to fetch, render, and classify the website. In contrast, our fastest general LLM gpt-oss-120b took 4.7s in the same workflow, and only returned two classifications. As a user, you can imagine how a 2x savings in latency and results can help us improve our threat intelligence workflows and be faster in identifying malicious or legitimate domains. Generalize this to any use case where you need to make quick programmatic decisions, and you unlock powerful agentic workflows that are able to autonomously decide, reason, and execute.

In music theory, a clef is a symbol placed at the beginning of a musical staff that assigns specific pitch names to the lines and spaces. A decision model is analogous to a music clef because it helps define the domain of the context and the subsequent notes (actions) that follow it. We chose Clef as the name of our family of decision models, as it serves similar purposes, and the CF hearkens to Cloudflare.

How is Clef different from other decision models?

Although the market is getting increasingly saturated with decision models, Clef has some unique properties that make us excited to release it to the public. First, it has a vision encoder so it’s able to take in images and classify visual content. This is different from Jev, which only does text classification today. Secondly, our model has a 64k context window (compared to Jev’s 32k), which allows users to squeeze more input state for the model to classify against.

Third, our model is accurate and powerful, scoring competitively against other decision models on the market across various quality benchmarks. We shortlisted some evaluations below that are important for decision-making as defined by the Jev Decision Index and scored some of the more popular models on the market for it.

We also ran benchmarks across Typesafe’s own eval suite and our Clef models fared well, beating Jev in 3 out of 4 areas. Notably, our Clef-flash performs exceptionally well, given how much faster it is.

On top of the latency benefits from the model itself, our Clef models are hosted on Workers AI. Because they are hosted on Cloudflare’s infrastructure, we’re able to take advantage of our GPUs at the edge, leading to low network latency and faster decisions.

curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run/@cf/cloudflare/clef \
  -X POST \
  -H "Authorization: Bearer $CLOUDFLARE_AUTH_TOKEN" \
  -d '{
    "model": "clef",
    "state": "Checkout has been failing for every customer for the last hour.",
    "questions": {
      "urgent": { "type": "noul", "instructions": "Is this support request urgent?" },
      "team": {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
          "billing": "Payments, invoices, and refunds",
          "technical": "Outages, errors, and configuration",
          "sales": "Plans and upgrades"
        }
      },
      "severity": {
        "type": "score",
        "instructions": "How severe is the customer impact?",
        "criteria": ["No impact", "Minor", "Major", "Critical"]
      }
    }
  }'

Clef also produces strictly typed outputs similar to Jev and is fully API-compatible, so you can make the swap extremely easily. The larger Clef model is your more powerful precision model, while the Clef-Flash model is great for latency-critical decisions.

How we trained Clef

Clef builds upon this concept, but uses a different base model as the backbone. We currently use Qwen as the base model and post-trained it to suit decision model use cases. During inference, Clef uses Qwen for a prefill-only pass, then scores the valid schema choices in parallel. The decision step is non-autoregressive, so there’s no intermediate text to generate token by token, making Clef significantly faster than autoregressive LLMs. Rather than generating intermediate text to produce structured answers, Clef and Clef-flash derive schema choices directly from internal backbone representations.

By freezing Qwen3.8-27B for Clef and Qwen3.5-9B for Clef-flash, we jointly optimized the routing head alongside rank-256 low-rank adapters. Our post-training utilizes label-smoothed cross-entropy for valid schema outputs paired with a Brier loss to refine probability calibration. We also developed Reinforcement Learning for Calibrated Decisions (RLCD) to serve as a secondary optimization target.

How fine-tuning can extend the capabilities of Clef

We heard a lot of internal use cases that required fine-tuning our Clef model to be built into our agentic workflows at Cloudflare. These use cases are incredibly specific and we have had many years of labelled decisions that we could use to train a specific classifier. Because Cloudflare has more than 15 years of network data across different domains, we can fine-tune a model to fit these specific use cases which is more accurate and faster than our generic Clef model.

Our new RL service

We are offering a service to help customers fine-tune Clef to suit their workloads with our hands-on FDE team. From that, we’ll learn from our hands-on experiences to build a self-serve platform that customers can use to capture data, fine-tune, and redeploy the model, all on Cloudflare.

To do this, we leverage the primitives that we already have built on our Cloudflare platform:

• Cloudflare AI Gateway
• Cloudflare Workers AI
• Cloudflare Containers
• Trainer (NEW)

Try it out today

We’re excited to launch our first Cloudflare-trained ML model from the Workers AI team today. If you have specific use cases and are already customers of these products, we’d love to chat with you and be design partners as we experiment in this space.

Microsoft's MAI-Transcribe and MAI-Voice models provide accurate, fast, low-cost, and chart-topping audio understanding and generation. The company has launched MAI-Transcribe-2-Streaming along with MAI‑Voice‑2.1 and MAI‑Voice‑2.1-Flash, giving users fast and fluid building blocks to create conversational experiences with no compromise on accuracy or voice quality. MAI-Transcribe-2-Streaming delivers low-latency, real-time transcripts in 60 languages, all while supporting automatic, continuous language detection. MAI-Voice-2.1 supports 23 languages and 26 locales, allowing users to keep a single voice everywhere.

Today I'm releasing Kev 1.0, a family of four open source decision models, from 0.8B to 27B parameters. This release includes a new Kev-27B and an updated Kev-9B.

TypeSafe's Jev takes text, questions, and possible answers and returns a probability for each answer. I wanted that interface with weights I could run and fine-tune myself. Kev uses the same API, so applications built with TypeSafe's SDK can switch by changing the endpoint and model name.

All four models have Apache-2.0 weights on Hugging Face. The code is on GitHub, including a server that runs on GPUs and on Apple Silicon through MLX. You can try Kev-4B in your browser or use the agent skills to deploy and fine-tune your own.

The Kev family

Kev-27B leads overall in my evaluations. On consumer complaints, Kev-9B and Kev-4B are within a percentage point of it; on developer-tool decisions, Kev-9B matches it. The table separates tasks excluded from Kev's fine-tuning from held-out examples of task families it trained on.

Overview of accuracy across six evaluation panels for Kev-27B, Kev-9B, Kev-4B and Kev-0.8B. Kev-27B leads overall; Kev-9B and Kev-4B are within one percentage point of it on consumer complaints, and Kev-9B matches it on developer-tool decisions. All results are from the author's evaluation harness, not an independent leaderboard.

I recommend Kev-27B if you want the highest overall scores and have an 80 GB H100 for shorter inputs, or an H200 or B200 for long documents. Otherwise, start with Kev-4B and measure it on your own examples.

For local use, Kev-0.8B and Kev-4B run on Apple Silicon through MLX. On a 32 GB M5, Kev-4B answers five questions about a short text in 721 ms, or 136 ms when the text is cached; Kev-0.8B takes 149 ms for new text. Kev-9B is expected to fit a 32 GB Mac, and Kev-27B a 96–128 GB Mac. I haven't measured those two on Macs yet.

How Kev works

Kev adds a pointer head, a layer that scores the supplied answer options, to a language model. It supports yes/no questions, multiple choice, and ordered scales. The document is processed once, and each question uses that cached computation without seeing the other questions.

1. A generated answer: A chat model generates a sequence of tokens, even when its output is constrained to JSON.
2. Kev scores options directly: A pointer head returns probabilities without generating answer tokens.
3. Kev reads the text once: The document prefix is computed once and cached.
4. Every question branches off that one read: Ask three questions or thirty: the ticket is still read once.
5. A probability for every answer: Each <decide> token scores the options. A softmax turns those scores into probabilities.
6. Your code sets the threshold: Here, only billing clears the illustrative 80% threshold. The other decisions take the fallback path.

Caching saves more work on longer documents. On an H200, Kev-27B takes about 9.4 seconds of model time to read a new 64k-token document and about 0.7 seconds for subsequent questions using its cached state.

Training the new models

What's new in Kev-27B

The smaller Kevs use Qwen3.5 backbones with LoRA adapters: small sets of additional weights trained while the backbone stays fixed. For the new Kev-27B, I used Qwen3.8-27B, Qwen's post-trained release, and fine-tuned every weight of its text backbone.

Training the whole backbone on the previous Kev-27B's data did no better than the adapter-trained version. The new release also uses a broader corpus: about 146,000 examples and 337,000 questions, with documents up to 32k tokens. It combines Kev's existing data with licensed public tasks, synthetic decisions written by open-weight models, and documents and agent logs generated by code with exact answers.

I added examples for tone, grounding, prompt injection, and personal-data detection, and screened the training records against the frozen evaluation sets for exact and near matches. No Jev outputs were used. The model card documents the data sources and training recipe, including the final weight blend with the previous checkpoint. The full training corpus is not public.

What's new in Kev-9B

Kev-9B had fallen behind Kev-4B on policy and rule reasoning, developer tools, and consumer complaints because it hadn't received the same additional training. One more fine-tuning pass, about three hours on one GPU, closes that gap.

Evaluation

Generalization

To test tasks excluded from Kev's fine-tuning, I assembled 14 public datasets spanning intent classification, retrieval, language understanding, tool selection, knowledge, and subjective judgments. They include choosing among 150 customer intents and deciding whether a contract supports a claim.

Calibration

Calibration measures whether a model's probabilities match how often its answers are correct. On the pooled 14-dataset test, Kev-27B's answers in the roughly 85%-confidence bin are correct about 85% of the time.

Fine-tuning on your data

I packaged that workflow into an official kev-finetune skill. Your coding agent helps define the questions, prepares labelled data or generates examples, fine-tunes a released Kev, fits its temperature on a separate calibration split, and compares the result with the starting checkpoint before deployment.

The companion kev-deploy skill makes it easy to deploy Kev to Modal behind an authenticated HTTPS endpoint.

Limitations

Kev only scores the options you supply. It doesn't generate explanations or retrieve missing facts. You need to supply the relevant policy or evidence and handle the possibility that none of the options is correct. Answer order can also shift probabilities slightly.

Get started

The weights are on Hugging Face, and the code, model cards, and serving instructions are on GitHub. You can try Kev-4B in your browser before setting anything up.

npx skills add jaredpalmer/kev@kev-deploy
npx skills add jaredpalmer/kev@kev-finetune

The Dot and the Swarm

Benefitting from the Bitter Lesson

I generally think I have done a good job anticipating the direction and pace of AI over the few years I have been writing this Substack, but I think I recently got something fairly large wrong. In the last year I have been posting about how I suspected that humans would have to approach working with agents as a manager, deciding how to delegate work to agents and specifying how those agents should be organized. I thought that getting agents to work effectively as a group would take careful construction, akin to building a company, and that this would take time to figure out.

Nope.

I fell prey to The Bitter Lesson, the hard truth, learned over and over again, that things that we thought required elaborate human rules and thinking can be solved with the brute force of better machine learning systems and more AI. The Bitter Lesson is everywhere among AI startups and companies adopting AI. A huge amount of effort went into building elaborate computer systems to feed AIs the right information at the right time, but AI systems have learned to seek out information themselves. The same thing happened to prompting. People built elaborate templates and chains of prompts that walked the AI through a task one step at a time. Then newer models turned out to be better at planning the steps themselves, and, as our research shows, planning steps have much less value.

As somebody who teaches managers and has published research on management, I guess I believed that managing agents would be different. Humans have been working on management for a very long time without fully figuring it out. It seemed like the kind of thing that would need to be designed by people, at least for a while.

It turns out that organizing work is just one more thing AI can learn to do.

Which brings us to dots and Muse.

Dots and Muse

The number one app in the App Store right now is Meta’s Muse, a personal agent that promises to do work for you. OpenAI has now released a competitor tool, called dots. They aren’t alone: SpaceX’s Grok Bot, Instinct, and Gemini Spark all do similar things, more or less. All of these agents draw inspiration from a phenomenon you might remember from earlier this year, OpenClaw.

The idea of OpenClaw and its successors, which I will call Clawlikes, is that they give an AI agent access to a computer and connect to your accounts (emails, financial records, etc.). They analyze and react to that data in real time, even when you aren’t looking. The trick is that you talk to the model like you would a person, sending it messages on Slack or SMS or WhatsApp, and it also proactively reaches out to you, like a person would. For dots, you can actually jump on a call with your agent as well. You basically get an infinitely patient personal assistant that looks out for you. Increasingly, I have discovered that they are finding my mistakes, rather than having me identify theirs.

As one useful example, one of my personal agents contacted me because an email I sent to our town for a permit had the wrong project number on it. The catch was that I was the one who made the mistake, and I am not 100% sure how the AI spotted the error. Fortunately, it helpfully wrote a draft correcting the issue, so that is good (if a little freaky). As another example, Muse noticed that an airline credit of mine was about to expire and, when I asked, contacted American to request an extension.

It is tempting to judge these agents by the list of things they can do, like booking travel or canceling subscriptions. I think the more important thing is what you no longer have to tell them. You don’t need to type in tons of context, the AI learns it from your messages. You don’t have to give them a plan, they develop plans themselves. They figure it out.

That would be impressive enough if it were one agent. What actually changed my mind about management is what happens when there are thousands of them.

Swarms

On September 8th, OpenAI announced a proof for one of the Clay Institute’s Millennium Prize Problems, the Navier-Stokes existence and smoothness problem. It is among the most famous open problems in mathematics, with a $1 million prize, but OpenAI apparently solved it using AI alone in 88 hours.

What interests me is less the math than how it was done. OpenAI launched what is now being called a swarm, a group of thousands of agents powered by an advanced model. OpenAI gave groups of agents different problems to solve, then shifted the effort to Navier-Stokes as the agents made progress. The company set the goals, but its coordination structure was remarkably thin: a few groups, one change of direction, and Codex passing the best ideas between them. Within each group, the agents transmitted ideas back and forth on their own. The agents sent about 2.7 million messages, reaching their result after 88 hours. This same type of coordination, in a darker form, occurred during The Hugging Face Incident I wrote about a month ago. AIs self-organized into teams and communicated with each other in ways that were never planned, but used that coordination to attack a website, rather than solve a problem.

Under my old model, think about what managing this kind of work would have required. Ten thousand workers and an unspecified problem — how would you tell them what to do? How would a human manager decide which of 2.7 million messages mattered? How would they coordinate with each other? The swarm figured it out.

I don't have 10,000 agents, but I now regularly see OpenAI's Codex and Claude Code using agents as needed. As an example, when I gave Codex with GPT-6 Astra Ultra the prompt "brainstorm ideas for my next OneUsefulThing post and select one. Generate ideas from as many angles as possible and evaluate them from both factual and reader perspectives as well as other publications doing similar coverage," the AI spun up three agents. When I sketched three teams in a few sentences (brainstormers, researchers, and a panel of readers), I got thirteen. Notice how little organizing I had to do. Selecting Ultra mode tells the model it can delegate, and I provided a framework, but the rest was up to the AI.

This is the Bitter Lesson applied to the org chart. The organizational problem I thought would take years of careful human design was largely solved by models that are better at organizing. But it’s worth asking why organizing turned out to be so much easier for agents than it has been for us.

A lot of what we call management exists to solve problems that come from organizations being made of people. People have their own goals, and those aren’t always the goals of organizations. We call this the principal-agent problem and a lot of the machinery of organizations, from bonuses to management structures, is based around solving it. And there are other very human problems as well. Information is scattered across people’s heads, and people are often reluctant to share it, or forget to. Communication is expensive too: managers can only oversee so many people, thus adding people to a late software project famously makes it later. Management is, in part, built around human limitations.

Agents have far fewer of these problems. They don’t angle for promotions or protect their turf. They don’t even have meetings. Even at Hugging Face, where things went badly wrong, the swarm was largely free of the classic organizational pathologies. The agents didn’t free-ride on each other’s work, and some sacrificed their own scores for the group. The agents that solved Navier-Stokes didn’t want credit. That doesn’t mean AI has no principal-agent problems. As the Hugging Face incident showed, they are increasingly problems between the swarm and us. OpenAI shelved its next model, GPT-6.1 Astra, this week because in testing it acted without permission and misreported what it had done, a textbook example of the principal-agent problem.

A Not-Entirely-Bitter Lesson

None of this means agents can do everything. AI is still too limited to substitute for large amounts of human work, and I don’t know how well self-organizing agents handle the long, unglamorous work that fills most of an organization’s time. Plus, the Hugging Face Incident is a reminder that self-organizing systems can head in unexpected directions. But I no longer think organizing agents is the hard part.

This may be good news. I assumed companies would need to rebuild management for machines, constructing elaborate alternate structures populated solely by agents, often at the expense of human roles in organizations. But much of management exists to solve problems agents don’t have, and agents increasingly work through the same messy systems people do, even on ambiguous tasks. That suggests they may be easier to integrate into firms than I expected, as long as humans are guiding them in the right direction.

Done well, and with agents that are properly aligned to our needs, this could mean more work for people, not less. When organizing is expensive, organizations only attempt what they can staff. When it gets cheap, the list of things worth attempting can grow. In the Navier-Stokes run, the agents did the organizing but people decided where to point them, reassessing as the process continued.

Introducing Olmo-core 3: Open, scalable training infrastructure for large MoEs

Today we’re releasing Olmo-core 3, a significant upgrade to our framework for developing large language models featuring a redesigned open mixture-of-experts (MoE) training system.

Olmo-core 3 is designed to scale MoE training into the trillion-parameter range while preserving computational efficiency. It’s one of the core systems behind the next generation of Olmo, and part of our ongoing commitment to open up the tools and training infrastructure behind each new model.

Training large AI models takes a lot of compute, driving up costs and energy use and putting advanced model development out of reach for many academic researchers and smaller labs. MoE models offer a more efficient approach—they can contain many more learned components, or parameters, without requiring every input to use all of them. But the full model still has to be stored across GPU memory and updated during training, and directing inputs to the right experts – the specialized components within an MoE – across a cluster creates its own communication and coordination costs. As MoEs grow, those costs can erode much of the computational advantage of using only part of the model for each input.

Olmo-core 3 is built to close that gap. In one benchmark, we increased the expert pool from 8 to 128 while still selecting only four experts per token – the small units of text a language model processes – keeping the number of active parameters per token roughly fixed at about 3.2B. Total parameter capacity grew from 4.6B to 47B, while training throughput fell by less than 5%.

The same infrastructure has been benchmarked at over one trillion total parameters.

Building a training stack around how MoEs actually work

Olmo-core has evolved with each generation of Olmo.

Our work on sparse models goes back to OlmoE, which used an MoE architecture with 64 routed experts. Olmo 3, by contrast, used a dense architecture, meaning nearly all of the model was active for every token and its training stack was built around that design. Olmo-core 3 extends the framework with a training system designed for much larger MoE models.

Our earlier MoE implementation in Olmo-core used fully sharded data parallelism (FSDP), configured to gather and reshard model weights for each small batch of training data. Olmo-core 3 switches to a system based on distributed data parallelism (DDP). It keeps experts resident on GPUs and routes the relevant data to them, avoiding that repeated weight gathering.

NVIDIA’s Megatron-Core is an established option for training large MoEs. Olmo-core 3 brings an integrated MoE training stack to the framework behind Olmo, with a redesign that improves throughput over our earlier FSDP-based implementation. In a preliminary test on eight NVIDIA B300 GPUs, a 47-billion-parameter MoE processed 52,000 tokens per second per GPU with the new stack, compared with 19,400 using our earlier implementation—about 2.7× the throughput.

Scaling and optimizing MoE training

Olmo-core 3 combines several techniques for distributing large MoEs across GPU clusters with optimizations that make routing and computation more efficient.

Three techniques determine how the model and its training state are split across hardware:

• Expert parallelism spreads the experts across GPUs, so each GPU stores only part of the full expert pool.
• Pipeline parallelism splits the model’s layers – the successive stages that transform an input – across groups of GPUs, reducing how much of the model each GPU needs to keep in memory.
• A distributed optimizer spreads the optimizer state – the additional data used to calculate and apply updates during training – across GPUs instead of storing a full copy on every GPU.

Together, these techniques allow an MoE to scale without requiring every GPU to keep the entire model and its training state in memory.

Olmo-core 3 also reduces the cost of routing data to the right experts and running their computations. Rowwise expert parallelism places routed data directly into expert input buffers, minimizing the extra work needed to rearrange it. GPU-resident routing keeps routing metadata on the GPUs, so the CPU can queue work without waiting for that information to be copied back. And grouped GEMM combines many small expert computations so GPUs can execute them more efficiently.

Finally, Olmo-core 3 supports MXFP8, a lower-precision number format that represents some values with fewer bits. This can reduce computation and the amount of data moved between GPUs, as long as those savings outweigh the cost of converting between number formats.

We measured MXFP8’s effect on end-to-end training throughput in a controlled benchmark on four NVIDIA B300 GPUs, with work distributed uniformly across experts. With MXFP8 enabled across the parts of the system where it helped most, training throughput was about 21% higher than with BF16, the higher-precision format we used as our baseline, while peak active memory fell from 103 GiB to 95 GiB. Most of the gain came from feed-forward computation and moving data between experts rather than attention alone.

These techniques and optimizations have to work together. Speeding up one part of training can create costs elsewhere; faster computation may require more data movement, while moving fewer bits may not help if converting the data takes too long. Olmo-core 3 is built around those trade-offs across the full training process, giving us – and researchers using the open stack – control over how the pieces fit together.

Scaling into the trillion-parameter range

We’ve benchmarked Olmo-core 3 across a range of configurations on NVIDIA B300 GPUs, including a 1.2-trillion-parameter model with 58.36 billion parameters active per token across 512 GPUs. Its highest observed throughput was 858 TFLOP/s/GPU—a measure of useful model computation per second on each GPU. These tests used random routing to measure system performance, rather than the quality of a trained model.

We’ve also experimented with DeepEP v2, an alternative way of handling communication between experts across GPUs, reaching a configuration with 2.38 trillion total parameters. This was a short-capacity test rather than a full training run, so it demonstrates the scale Olmo-core 3 can reach rather than sustained training performance.

At these scales, systems performance is only part of the picture. Our technical report also documents experiments that informed how we train MoEs and measure their performance. For example:

• A score intended to encourage balanced routing could improve even as the actual workload became less balanced. We call this failure token gerrymandering.
• Lowering experts’ learning rates – the size of their training updates – because they process fewer tokens did not improve results in the model family we tested.
• GPU calculations took different amounts of time when the values being processed changed, even with the same matrix dimensions. Performance comparisons therefore need matching input values as well as matching shapes.
• Overlapping communication and computation on separate GPU streams did not always make training faster. In some tests, it slowed end-to-end execution—a reminder that more overlap does not necessarily mean higher throughput.

The report explains these findings alongside the approaches we tested and chose not to adopt.

Built for the next generation of Olmo, open for everyone

Olmo-core 3 is the foundation for what we’re building next. Our next-generation Olmo will use an MoE architecture, and we’re aiming for it to be our most capable Olmo yet, trained on our largest dataset and with our longest context window.

The new stack lets us scale beyond our previous MoE work while giving us more flexibility to adapt training as models and hardware evolve. And it’s fully open—researchers and developers can use Olmo-core 3 to train their own MoEs, adapt it to different hardware, and experiment with routing, parallelism, and other parts of the system.

That’s part of how we think about open model development—model weights are more useful when the infrastructure and training decisions behind them are open too.

For a deeper look at the systems design, experiments, ablations, and approaches we tested along the way, read our technical report and explore Olmo-core 3 on GitHub.

Earlier this year, we announced strands-labs, a place to get hands-on with state-of-the-art approaches to agentic AI. Today, we’re excited to add Strands Decider 2B: a small decision model optimized for fast experimentation, local development, and innovation.

Strands decider is one of a new class of decision models or system one models, a type of model that has been gaining a lot of attention since TypeSafe AI’s launch of Jev earlier this month. Unlike LLMs that can generate arbitrary output, decision models are designed to pick between sets of options (e.g. “Is the string ‘turn on the lights’ about the coffee machine? Yes or no.”, “What language is the phrase ‘sihamba ngokushesha’ in? English, Zulu, or Dutch.”) and assign simple numerical scores (e.g. “Is the phrase ‘this is the best doc I’ve ever read’ a positive sentiment? Between 0 and 1.”).

In exchange for this reduction in flexibility, decision models are faster and more capable at a given size, always produce an answer from the selected options, and can run with very low latency.

The flip side is that this approach (generating all outputs in a single parallel pass) makes it significantly worse at solving complex problems than reasoning models, and its lack of ability to generate text makes it unsuited for coding, chatbots, document summarization, and other common LLM tasks.

In addition, decision models give each decision a high-quality reliability score (i.e. “how sure can I be that this yes/no is correct?”), which is not available through frontier LLM inference APIs. They also make it highly efficient to ask multiple questions about the same prompt. This combination of properties makes them perfect for driving the types of agentic workflows we see many developers building with the Strands Harness SDK, and the recently launched Strands harness. We expect that this class of model is going to lead to a lot of interesting innovation in agentic AI over the next few weeks, months, and years.

Strands Decider 2B is our first contribution to that innovation. It’s a 2 billion parameter model, suitable for running on a local CPU or GPU, which can return answers to meaningful questions in tens of milliseconds. Its accuracy and calibration is competitive with the other models we know of in this class. We’ve released strands-decider-2b as open source on GitHub, with the weights on Hugging Face, including all the training data and scripts we used to build the model, making it a great place to start on your own innovation journey.

Model Architecture

The core idea is that we take a pre-trained LLM torso (Qwen3.5-2B), and remove the LM head, taking away its ability to generate text. The LM head is replaced with a pointer head which scores the answers offered by the torso for each option. It does this by scoring the hidden state at each option position against the hidden state at the <answer> position. This head is pretty small, just over a million total parameters. The torso is fine-tuned with a rank-16 LoRA adapter.

As you browse through the repo, you’ll find that this is the second major iteration of the architecture. The first one was similar, but used a slot head that we found performed significantly worse. In fact, the model we’re releasing today is v19, with lots of iterations under the covers. Everything we changed in each version is covered in the repo, and you can follow along with the work we did.

How does it perform?

For models of this type, we’re interested in three performance targets: accuracy (how well it answers questions), calibration (how trustworthy its confidence scores are), and latency (how quickly it can make decisions). We’ve been measuring the first two together: accuracy on JevBench’s public set, and calibration using the Brier score on the same set. We’ve found that strands-decider-2b performs well on accuracy and calibration. As we’ve evolved the architecture our scores are getting better, and we have many ideas for future improvements. We hope the community joins us, in the spirit of Strands labs, in contributing new ideas of your own.

On latency, strands-decider-2b can make local decisions in a median of around 115ms on widely available hardware. The time taken to decide depends on the task size, approximately linearly increasing as the task size gets larger. The results in the graph here are on a local Nvidia RTX3090, but the performance on an M3 MacBook isn’t much worse, with a median latency for small tasks around 153ms. As with accuracy and calibration, we have a lot of ideas for getting better here, especially in reducing the floor.

Why 2B?

We chose to make Strands decider available as a small model for two reasons. One is that we want to encourage experimentation. You can use, and even train, strands-decider-2b on hardware you already have. This makes it easy, fast, and low risk to try things out. The other is that two billion total parameters, seems like something of a sweet spot: small enough for experimentation, large enough to do meaningful work. Strands decider performs 100% of the easy tasks on JevBench correctly, for example, and these types of problems map well to some of the easier problems we see people tackle with agents.

What can I do with Strands decider?

Whatever you want! More seriously, we’re seeing early success using this class of model for model routing, tool selection, evaluations, guardrails, memory, context management, and policy classification. We’ve also seen exciting innovation around building hybrid agents, using LLMs to make the hardest decisions and using decider models to make the easier rote decisions, reducing cost and latency. We’re seeing experiments combining decider models with fixed workflow languages to build another kind of hybrid workflow. Folks are also using these kinds of models to play games, automate tasks, navigate mazes, and more. The speed of innovation in this space is astonishing.

Trying it out

The easiest place to get started is through the strands-decider CLI:

pip install strands-decider

Choice question

You can ask the model to choose based on some state and a question:

strands-decider ask StrandsAgents/strands-decider-2B-hobson-v19 \  --state "Help! My payouts have been failing for 3 days! " \  --choice "Which team should handle this?=billing,sales,retail"

Example output:

choice_0 -> billing (confidence 0.768)  billing                  0.845  retail                   0.091  sales                    0.064

In this output we can see that the model is predicting billing as the answer with the highest probability score.

The repo also includes examples using strands-decider-2b inside a Strands agent, under examples/strands/. The agent itself runs locally, connects to Strands decider also running locally, and then uses the default LLM from Amazon Bedrock.

It’s a deliberately small scenario. The agent has the (obligatory) demo get_weather tool and a system prompt that makes it deliberately eager, so that when the user asks “What’s the weather?” without saying where, the agent guesses a city and calls the tool anyway. However, before that call runs, strands-decider-2b will read the conversation and the proposed tool call and answers two yes/no questions about it: are these argument values grounded in anything the user actually said (spoiler: no!) and is it too early to call this tool anyway. A few lines of Python turn the predictions into a decision, and the agent goes back to ask which city you meant instead of confidently reporting the weather somewhere nobody mentioned.

QUESTIONS = {    "args_grounded": Decider.noul(        "Are the tool's argument values grounded in facts the user actually provided?",        {            "true": "every argument value traces back to something the user said",            "false": "an argument value was guessed or invented, not stated by the user",        },    ),    "premature": Decider.noul(        "Is it premature to call this tool now, before clarifying with the user?",        {            "true": "the assistant should ask a clarifying question before calling the tool",            "false": "there is nothing left to clarify; calling now is appropriate",        },    ),}

The pattern here is Strands’ intervention system. We use the InterventionHandler with a before_tool_call method, pass it to Agent(interventions=[...]), and it runs before any tool executes. What it returns is a typed action: Proceed, Deny, Confirm (stop and ask a person), or Guide, which hands the model back its turn with feedback rather than blocking the call outright. This existing handler is a Python class and Strands has no opinion about what goes inside it, so the same shape holds whether you’re calling our decision model, a Cedar policy, or another agent. (There are equivalent hooks around the model call and around the whole invocation.) This example is an illustration rather than a recommendation, so the questions, the threshold and the policy were all picked by hand. The point is that a decision this cheap can sit in a path where an LLM call never could.

The Strands team is working on libraries for decision model integration, so watch the repo for updates soon.

Conclusion

You can download, use, or build off strands-decider-2b today. All the data is available, along with everything you need to get started. You can grab the code from GitHub, and the latest snapshots from Hugging Face. Now go experiment!

Geothermal company Fervo Energy announced Thursday morning that it had started selling electricity from its Cape Station power plant to the grid on September 30, one day ahead of schedule.

With it, Fervo becomes the first enhanced geothermal company to reach a key commercial milestone. The power plant synchronized with the grid about a week ago, bringing online the first third of what will soon become a 100-megawatt power plant.

The entire site could be much larger, though, with the potential to generate as much as 4 gigawatts of electricity, Fervo previously told TechCrunch.

“No team has ever built a project like this anywhere in the world, and we did it ahead of schedule,” Fervo co-founder and CEO Tim Latimer said in a statement.

From groundbreaking to commercial operations, the first block at Cape Station took 23 months to complete. As Fervo refines its process, it is aiming to complete future blocks in as little as 18 months.

That sort of speed to power should appeal to power-starved data center operators, who have been scouring every part of the energy sector for generating capacity. Geothermal can also be developed in phases, similar to how data centers are developed, allowing hyperscalers to bring racks online as demand ramps up.

Google, Southern California Edison, and others have committed to buying power from Fervo’s Cape Station project, which is located in Utah.

Fervo is one of several companies developing enhanced geothermal power plants. While traditional geothermal power taps heat sources close to the surface, Fervo and its peers are drilling deeper because deeper rock is hotter, opening more opportunities for development.

Fervo went public in May in an upsized IPO that raised $1.9 billion. It was founded in 2017, bringing drilling techniques and technologies from the oil and gas sector to the development of new geothermal resources. As a startup, the company raised more than $1.3 billion from investors, including Breakthrough Energy Ventures, Congruent Ventures, and Capricorn Investment Group.

The first in a new class of space telescopes is on track to reach the launch pad in the early 2030s, NASA announced this week.

The PRIMA mission will be the first of NASA’s Probe Explorers, a new line of observatories intended to do more science for less money. The agency’s space telescopes typically fall into lower-cost “Explorer-class” missions, with cost caps in the range of a few hundred million dollars, or flagship observatories like the recently launched Nancy Grace Roman Space Telescope, which came with a price tag of some $4.3 billion.

With the Probe Explorers, NASA officials seek to find a better balance between the smaller Explorer missions and multibillion-dollar flagships. NASA has studied potential Probe Explorer mission concepts for several years after an independent panel of scientists recommended the new mission category. But it wasn’t clear until recently whether NASA’s science budget, which is under pressure from the Trump administration, would be sufficient to actually start developing one.

NASA announced Wednesday it will move forward with PRIMA, short for the Probe far-Infrared Mission for Astrophysics. PRIMA was the sole finalist for the first Probe Explorer mission after NASA disqualified a competing mission, an X-ray observatory known as AXIS, earlier this year. NASA said a concept study for AXIS indicated it would not meet the agency’s schedule and budget constraints.

The scientist leading the AXIS concept study blamed disruptions and mismanagement at NASA’s Goddard Space Flight Center in Greenbelt, Maryland, the NASA location charged with leading the AXIS mission if it moved forward into development. PRIMA will be led by NASA’s Jet Propulsion Laboratory in Pasadena, California, which has also found itself in an institutional crisis, with few missions in development and a series of layoffs.

Flagship missions can take decades to design, build, and test before they make it to the launch pad. The Roman Space Telescope was the exception. It took 10 years from NASA’s approval to proceed into development until Roman’s launch last month on the way to an observation post a million miles from Earth.

Leftovers from Webb

PRIMA, which has a cost cap of $1.2 billion excluding launch costs, will not be as big and complex as Roman, so it’s natural to assume a shorter development cycle. NASA wants to launch PRIMA seven years from now, in 2033. The telescope will observe the Universe in faint, far-infrared light in a range of wavelengths between 24 and 235 micrometers, requiring its primary optics to be cooled to 4.5 Kelvin, or minus 451° Fahrenheit.

This would usually require a brand-new build of a sophisticated cryocooler. PRIMA will instead use a spare leftover from the development of the James Webb Space Telescope, modified to use helium-3 instead of helium-4 as the cooling fluid. The focal planes of PRIMA’s kinetic inductance detectors will be chilled even lower to 100 milliKelvin, putting the mission’s optics in contention for the coldest ever sent into space.

Its far-infrared sensitivity will give PRIMA visibility into the origins of planets and their atmospheres, the coevolution of galaxies and black holes, and changes in the properties of dust and metals over cosmic time, according to the scientists heading the mission. PRIMA, with a 5.9-foot-diameter (1.8-meter) primary mirror, will set up shop in an orbit around the Sun-Earth L2 Lagrange point a million miles from Earth.

The mission will peer deeper into the infrared bands than any of NASA’s past or current infrared observatories, such as Spitzer and Webb, and will build on discoveries made by Europe’s Herschel space telescope, which gave astronomers new insights into the formation of cosmic filaments and the role of water in the formation of stars and planets.

“The PRIMA mission is humanity’s next window into the deep Universe,” said Nicky Fox, associate administrator for NASA’s Science Mission Directorate, in a statement. “It will unveil the obscure across cosmic time to better understand the formation of planets, stars, black holes, and even how water on Earth came to be.”

NASA’s announcement this week gave the green light to move into Phase B of development, working toward a preliminary design review before a confirmation review at NASA Headquarters a few years from now that will mark final approval to proceed into integration of flight hardware. The complete observatory is expected to weigh less than 3.4 metric tons (7,500 pounds) at launch.

“A single mission alone can’t probe all the Universe’s mysteries. But by extending the survey capabilities of our fleet into far-infrared wavelengths with PRIMA, we’re enabling an incredibly comprehensive look at the cosmos,” said Shawn Domagal-Goldman, director of NASA’s Astrophysics Division. “With our Webb and Roman space telescopes, we set a cadence of launching premier-class missions in both halves of the decade. We’re going to keep that up and kick off the next decade with PRIMA, as part of a pipeline that will consistently have missions of this caliber ready to go.”

Flagships are still hard

Meanwhile, NASA continues preliminary architecture studies and technology development for its next big flagship space telescope, the Habitable Worlds Observatory, planned for launch in the 2040s. It is expected to be at least as large as the James Webb Space Telescope, with the potential for an even bigger primary mirror if NASA can take advantage of new super-heavy-lift launch vehicles, such as SpaceX’s Starship. HWO will observe the cosmos in multiple wavelengths, ranging from ultraviolet to visible and near-infrared.

Early cost estimates for the Habitable Worlds Observatory come in at around $11 billion, on par with Webb, which far exceeded its original cost projection.

“This is a sufficiently ambitious observatory where it’s going to require an all-of-nation [approach],” Domagal-Goldman said Tuesday in a meeting of the National Academies’ Committee on Astronomy and Astrophysics. “Frankly, we’re going to need our partners internationally to be a big part of this as well. But we need the best and brightest from throughout the country, whether they’re at Goddard, another NASA center, an industry partner, a new space commercial partner, or a university, to be a part of what we’re doing.”

Domagal-Goldman said this week that NASA aims to use its experience in developing and launching the Roman telescope on budget to help bring future flagships like HWO under tighter cost controls.

“We have proven with the launch of Nancy Grace Roman, ahead of schedule and on budget, that it is not a law of nature that these projects will go over schedule and over budget,” he said. “That doesn’t mean they’re easy, and it doesn’t mean we can be cavalier that they will always be on schedule and on budget because that’s also been disproven.”

The lessons NASA has learned about implementing flagship projects include the importance of defining the mission’s architecture and requirements and ensuring its underlying technologies are well understood before engineers start building flight hardware, according to Domagal-Goldman.

“To put it succinctly, you need to understand the challenge, have a mission where the challenge is incredibly well understood, and then once you understand it, then you put your pedal to the metal and take that observatory to the launch pad as quickly as you can,” he said.

Full article content is not available for inline reading.

Read the original article →

The creator of Ruby on Rails, David Heinemeier Hansson, caused quite a stir last week with comments in his Rails World keynote, when he revealed that coding by hand is dead at his company, 37signals.

This is a big deal because 37signals created Ruby on Rails, and they are known for their software craft there, especially when it comes to code quality. It’s also a business that’s 27 years old and is profitable. Despite that pedigree, DHH caused a stir among the dev community, saying:

“At 37signals, a couple of weeks ago, we made the decision that it clearly means we’re done writing code by hand. We have gone pencils down on the idea that we were gonna write code by hand, as a normal course of business creating things.

Writing code by hand at 37signals is now an exceptional state. It is like seeing a bug in Sentry: something here went wrong; why was the agent not able to produce what we wanted? Okay, maybe for a little while, we’ll still get the old pencil out and dot it down for them, but then we fix the machine, we fix the factory, we get things going again. This is a recognition of what’s already happening.”

DHH compared the maturation of AI tools into being highly capable at coding with the impact upon the craft of painting of the arrival of the camera:

“On November 24th, 2025, we got the “Kodak Brownie” of our era. We got Opus 4.5. AI technology, accessible in a harness that many people could afford to use and experience for the first time what it’s like to create software in pairing with a new form of intelligence. This was the tipping point for me. There was everything before November 24th, and then there was everything after. This is going to be the date that history books going forward will mark as the inflection point for the age of agents.”

He shared how 37signals has embraced a future where coding by hand is almost entirely absent:

• Embracing native mobile apps instead of web: famously, 37signals is bearish on native iOS and Android apps and has built web versions instead. With AI, they are betting on native apps being much easier to be built with a small team and are already building new ones.
• Moving backend services to Rust, not Ruby: This is due to performance reasons and because agents write good enough Rust. That’s remarkable to hear from the creator of Ruby on Rails!
• Ruby on Rails remains for web apps: 37signals is not leaving RoR behind, but only because Ruby on Rails’ convention-over-configuration design makes it easy for agents to work with it.

DHH closed by revealing that he no longer even thinks of himself as a professional programmer:

“I have retired from being a professional programmer. I think it was somewhere around 4 to 5 months ago, maybe March. I spent a quarter of a damn century chiseling code by hand and loving every moment of it. This is not something to look back upon with regret; this is something to look back upon with joy and accept that it is over.

Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers working at the vast majority of companies. On the other side of that is a new career as a professional maker of things, steering intelligence that was only available in science fiction up until a few moments ago.

One of the things we’re gonna have to revisit is everything we think we know about software architecture. The main tool that we’ve used for a very long time is abstractions. Abstractions don’t make quite the same sense in the age of agents. The reason we did abstractions was in part not to repeat ourselves; well, now the price of repetition has gone to near zero.”

It’s worth noting DHH’s keynote chose a spicy topic for a conference attended by engineers who are personally and professionally invested in the craft of building software!

Decline of coding by hand is long predicted

In the first issue in The Pragmatic Engineer this year, on 6 January, I wrote:

“When AI writes almost all code, what happens to software engineering? No longer a hypothetical question, this is a mega-trend set to hit the tech industry. (...)

The bad news is that change will probably be rapid. It’s barely been a year since the idea of Claude Code was born in Boris Cherny’s head, and already similar tools like OpenCode, Codex, Factory, Amp, Cursor, and more capable agents are changing how software is written. Change has always been part of working in tech, but I cannot recall it being this fast, or happening across the whole industry at once!”

I concluded that this change was on its way, based on my own experience of building software with Opus-4.6 and GPT-5.2, and from talking with experienced engineers who had resisted “AI hype” for good reason, but who had come to see that AI can now generate code that’s “good enough” in many cases.

Back then, I made a few predictions about what will happen when AI agents are producing most of the code for engineers:

• Sloppier code
• Weak software engineering practices hurting sooner
• “Coders” who are not software engineers see less demand
• Tougher work-life balance for engineers
• Junior engineers pushed to become seniors, fast
• Computer science education increasingly required for new hires
• A massive explosion in code and software, for which someone must be accountable

So far, it’s a messy transition and we engineers are responsible and accountable for a lot more code that we didn’t write, but which is in production anyway.

Non-engineers also getting into agents

At the end of January, I shared a deepdive that was pretty close to home for me: my brother’s 30-person, 15-engineer startup, Craft Docs, made its own sharp pivot to AI by building their own AI harness for non-engineers – called Craft Agents – two weeks before Claude Cowork was released, and months before ChatGPT Work launched.

Craft resisted the temptation to use AI when it did not feel productive, but with the model releases of November 2025, they found LLMs are not only useful for coding, but also for non-engineering work like customer support. In the deepdive, I went into more detail about non-engineering use cases (which engineers enabled) like:

• Automatic triaging of bug reports with agents
• Data enrichments added to all workflows
• Customer support “skills” like processing feature requests
• The marketing team building websites without devs
• HR automating tedious work
• Finance automating personal workflows

Craft Docs seemed early to a trend that has become more widespread, by having both their own engineering and non-engineering folks onboard to an AI harness. Now, there are signs other companies are doing the same: at OpenAI, non-engineering units like finance, recruitment, and legal moved over to Codex in June 2026.

It’s messy right now

Just last weekend, a rant by an anonymous engineer in Big Tech hit a nerve with many people in the industry. An engineer with the username voxium posted:

“The state of engineering right now is horrible. It has been half a month since I started a new role at a big company.

Nobody knows anything here. The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code. Nobody on my team likes this.

They are being forced to ship as much as they can. I have heard multiple times from higher management that pushing code is not a bottleneck, so why are we slow?

People are working 12 to 13 hours a day just to press enter. Nobody is reading anything. Humans in corporate are doing nothing on their own.

Everyone, literally everyone, from an L1 to an L7 engineer here is doing the same thing. Talk to Claude.

There is no sense of victory. Nobody is resolving bugs. In reality, nobody is thinking anymore. Everything is done by LLMs. It is so soul-sucking.

I would not mind it, to be honest, if we were at least given the time to check out the code and see what is going where. But no, the goal is to just ship. No matter what happens.”

This post rings true because it is happening at many places where there’s more AI usage, engineers do “outsource” thinking to LLMs, and end up not caring about anything else except shipping something to production.

Quality in decline

Since the beginning of the year, the quality of software has been degrading pretty much everywhere, much of it caused by over-reliance on AI, or perhaps more accurately, the outsourcing of thinking and decision making to AI. In July, I moved my video podcast off of Spotify after a series of unexplainable outages, and Spotify’s engineering team seemed to take no real pride or accountability in fixing the root causes of the issue.

Only this week, Uber shipped a new feature to production in the Uber Eats app – a new way to select extras with your food order – with seemingly no QA testing.

Inside this new “add-ons selector” in Uber Eats, I noticed three bugs at once:

• “Choose up to 999”: no engineer, designer, or PM bothered to check what happens when a restaurant does not fill out a number on how many toppings to add, or adds a ridiculously large number. The most toppings that my screen allowed to be selected was six and not 999, so I could not even choose the option of 999 buns for my burger.
• Sloppy overflow. A rule of thumb, during my time at Uber, was that text will never overflow, even when localized. Basilcummaynaise (basil mayo in Dutch) broke this rule but still shipped.
• Functional bugs in the selector. I originally tried to order from my favorite Mexican place: a bowl with no rice or bulgur as the base. There’s the option to select “rice”, “bulgur” or “nothing” as the base, but selecting “nothing” counts as an extra side, and the app doesn’t allow the ordering of a bowl with no base.

I’ve used the Uber Eats app for years, and this was the first time I saw such a sloppy feature release. I assume that devs and PMs building it have all “checked out”, stopped doing proper QA, and assume that the agent will take care of all of it.

Software engineering to be more important than ever

I’m personally past the shock and grief stages of agents taking over the activity of coding. At first, I assumed this change would reduce the amount of work for engineers. But, counter-intuitively, that actually seems to be growing:

• We need to understand the characteristics of LLMs better. LLMs feel familiar as they can produce text in a way only humans could do before. But they are less reliable, still prone to hallucination, suffer from capability gaslighting, and many other problems. They can also be expensive and slow.
• New systems need to be engineered. Agentic “software factories” can now produce code, based on the input provided. But how is this code validated? How much can detecting defects or various issues be automated? This is a brand new area, and we need to build new types of systems, often based on old ideas.
• Nondeterministic LLMs can generate deterministic code. An area I feel is under-explored and under-appreciated is the use of LLMs to substitute LLMs usage in agentic “software factories” with deterministic code they generate. For example: instead of running AI code review that is expensive and slow on all PR requests, could AI generate linters that catch the majority of common issues? If this is possible, complex lint rules would run faster, be more reliable and cheaper to execute than LLM calls.

New categories of systems and products will be built by engineers who “get” LLMs and AI engineering. We are seeing the majority of venture funding pour into AI companies because AI creates new business models, new revenue streams, and disrupts “traditional” software. This technological change will re-jig parts of the tech industry: the winners will surely win big, and teams and companies choosing inaction could be out-executed and displaced by nimble competitors. And in many ways, this is great news for us software engineers who keep up with the technology. Companies are now investing in innovation and are willing to pay top-of-market for software engineers who can help them build AI products or become AI-native.

You keep code in git, but agent session transcripts often end up in /dev/null. They are proof of work for the tokens you paid for, and lessons you will pay to relearn.

Before observability existed, we used to ssh into the server and grep the logs after a crash. Most companies are at that stage with agentic coding. They do not collect sessions from Claude Code, Codex, or Cursor, so they never learn from the most valuable data they produce: how their engineers work with agents.

At Quesma we built Quesma Shipper, an open-source collector that gathers sessions into your own Amazon S3 bucket or similar.

What is an agent session transcript

The transcript is the journal of what the agent did: prompts, thoughts, tool calls, results, and replies, plus the subagents and workflows the session spawned. Researchers call it a trajectory.

Other tools keep similar data in their own formats.

AI labs understand the value of session data

Anthropic analyzed 200,000 of its own Claude Code transcripts to understand how engineers work, and its evals guide ends with the instruction “Read the transcripts!”. Cursor acknowledges: “Our approach uses agent sessions as training data.” Replit calls trajectories “a core strategic advantage.”

Consumer plans train on your sessions unless you opt out, and they sell the cheapest tokens. No-training clauses and zero data retention live on the business tiers, where the bill multiplies. Meta’s Contributor tier charges 12x less per input token “in exchange for permission to use your prompts and completions to train future Meta models.”

This data is worth committing fraud for. Anthropic’s September 2026 threat report names seven Chinese labs that replayed coding sessions through Claude, rerouted Claude Code users, and bought transcripts from proxy operators who “save exchanges between users and US models without the knowledge or consent of those users.” An NSA, CISA, and FBI advisory the same week described their campaigns as “industrial-scale distillation.”

What you can learn from transcripts

Transcripts are full of low-hanging fruit to improve your agentic coding:

• What did we spend on each repo, PR, and type of work? Allocate it to R&D, COGS, or S&M, forecast it, and rightsize subscriptions.
• What adds cost without value? Verbose documentation, needless exploration, lengthy license headers, and noisy command output all feed context rot.
• Which habits should become instructions and skills?
• How was this change made? See how an agent built a pull request, what it checked (such as an adversarial security review), and what it cost.

Simple misconfigurations waste tokens and time. For example, in our RTK benchmark, one DeepSeek attempt repeated the same command 339 times, hitting the same error for 12 minutes. The task still passed, at about 9x the cost. It was an RTK bug, fixed in the next release. Students at our first hackathon found a lot of waste in the SWE-chat dataset: agents rerunning tests without changing the code, or rereading the same files after compaction.

Your intelligence is made of your preferences

There is no single measure of intelligence: people and companies each carry their own context and implicit knowledge. An investor rewards research that weighs every alternative. A game designer rewards trying ten ideas quickly over polishing one. A payments team rewards rigorous tests over speed. Industry benchmarks measure frontier intelligence, not your use case.

Sessions where an engineer corrected or reverted the agent are ready-made evals. They are more accurate and cheaper than synthetic tests, and they let you hillclimb on models, effort settings, skills, and instructions. Your taste, encoded as evals, is your edge.

Transcripts help investigate the alien brain

Frontier agents have already gone rogue: OpenAI’s agents hacked Hugging Face, and Claude hacked real organizations during evaluations, which came to light when Anthropic reread its transcripts. Small models fail differently: in our tests, a local model planted a backdoor on request up to 95% of the time, network isolation or not. Whatever goes wrong, the transcript records what the agent was asked and what it did. Do not wait for a disaster, or for AGI: keep your transcripts and watch them for early warning signs.

Why collecting and storing is hard

There are three ways to get your transcripts.

Ask the vendor: Model providers’ priority is protecting the model from distillation by competitors, and they already hide parts of the session. Independent harnesses such as Pi already feel the pain of sessions that are not portable. Official exports, such as Anthropic’s Compliance API, come with Claude Enterprise pricing and many limitations.

Put a proxy in the middle: It needs every tool pointed at it, and some tools refuse. A proxy also misses a lot of data: the local context that gives a prompt its meaning, and billing data such as how much of the weekly limit was used.

Copy the files from disk: They are not forever. Claude Code deletes them after 30 days by default, and its cleanup has ignored a 99,999-day setting and deleted sessions without warning; both issues are still open. They are also scattered: agentic coding spread faster than any policy. Teams mix providers and harnesses, company seats and personal subscriptions; shadow IT is the norm, and some engineers run local models such as Qwen.

A naive rsync collector makes security worse. Agents can read .env files, paste tokens into commands, and print credentials in tool output, and all of it lands in the transcript, which Claude Code stores in plaintext. Copy those files to a shared drive and you have a permission leak. Privacy is the other half: talking to an agent feels private. Companies should own this data, scrub it before it leaves the laptop, and decide who may read it, what they see, and how.

What we open-sourced

Collection should be a commodity. OpenTelemetry did this for observability: one open, vendor-agnostic standard for gathering distributed traces. Agent sessions need the same. That is why we open-sourced Quesma Shipper under Apache 2.0. It is a ~20 MB Go program, installed once per machine, that scans the session files Claude Code, Codex, and Cursor already write. Nothing to reconfigure, no proxy, no hooks.

Shipper scrubs the credentials and personal data it detects, using deterministic regular-expression and entropy checks based on gitleaks. It encrypts the files using your organization’s public key and uploads them to your own bucket, such as Amazon S3.

Quesma aims to be the custodian of Shipper, not its owner. We are happy to collaborate with anyone who wants to build on it, and to move it to open governance as the community grows. Shipper is enterprise-friendly: signed releases and MDM support. What is ready today is collection: everything from the laptop to your bucket. Start collecting your coding sessions before they are deleted.

We also plan to open-source an ETL layer that normalizes sessions from different agents into one standard format, and to build our own proprietary analytics on top of it.

Become a Quesma design partner. We are looking for engineering organizations that run Claude Code, Codex, or Cursor across many developers and want to understand and optimize their bill. It is free during the pilot. Talk to us.

Fair Moderation, Equitable Access, and AI: arXiv’s Updated Rate Limit Policy

arXiv, and the scientific community at large, are facing a watershed moment. Scholarly publishing is currently changing at a rapid pace, and we are seeing a massive transformation in how researchers communicate their results.

Before the advent of AI, there was an easily discernible, practical limit to the rate at which independent submissions could be produced, and arXiv’s volunteer moderators would limit submitters who were well above that threshold. With AI tools becoming more advanced and accessible to authors, the “practical limit” of how many papers can be submitted is now up for debate. As of October 1st, 2026, arXiv is instituting an updated rate limiting policy across all submitters and categories as a stopgap while we determine what may be the new best practice for authors employing more and more advanced AI tools, and to give us time to improve our moderation tools and procedures accordingly.

Open access repositories across the board are seeing a sharp increase in the number of submissions per author, per month. In September of 2016, arXiv received 9,869 submissions. In September of 2024, arXiv received 20,569 submissions. This September, arXiv received 40,363 submissions, which in turn generated almost 9,000 support tickets for arXiv staff and moderators. In only the past two years, submissions have doubled.

Advanced AI tools are helping drive these increases by making certain aspects of research faster and easier. arXiv policy permits authors to employ AI as a tool in support of their research as long as it is disclosed and the research meets arXiv’s standards of scholarly interest and advances the field of research. However, many of the submissions that arXiv is now receiving do not satisfy these requirements. Our moderators are observing an increase in thin papers of narrow scope, as well as ‘salami’ papers, where a single work is broken up and submitted as a set of smaller papers. There is also a marked increase in dense, AI-written papers. AI tools are making it easy for authors to flood arXiv and other repositories with these low-value papers.

The heart of arXiv’s process for detecting and rejecting low-quality papers is our many volunteer moderators. We are so grateful that they donate their time and expertise every day. However, a relatively small proportion of authors are submitting a large number of low-quality papers and consuming a disproportionate fraction of the moderators’ time. This is unfair to authors who continue to submit quality papers — their papers can be delayed for days or weeks as a result.

— Thomas Dietterich, Distinguished Professor Emeritus, Oregon State University and Chair of the arXiv Editorial Advisory Council

arXiv now limits submitters to up to two submissions per calendar month, with a limit of three total active submissions at any given time. This policy update is being put into effect to equitably distribute our volunteer moderators’ time across arXiv authors, and protect the arXiv corpus from a sharp increase in inappropriate submissions.

Rate-limiting is an established arXiv policy, with limiting originally primarily left to moderator discretion. arXiv has always asked that authors follow our codes of conduct and our submission guidelines. Articles submitted to arXiv must be of original, novel, and significant self-contained research that is relevant to arXiv categories. All submissions to arXiv must meet prescribed scholarly standards and be of scholarly interest to the scientific community. This policy update strives to fairly distribute the incredibly valuable work of our volunteer moderators who check that submissions meet these standards, and we hope it will also encourage authors to curate and submit only their best work to arXiv.

Frequently Asked Questions

• If my paper is rejected, does it count towards my monthly total?
  • Yes – this rate limit is for submissions, not announced papers, because it is submissions that consume moderator time. If you submit two papers in a month, whether they are accepted or rejected, you will have to wait until the next month to submit to arXiv again. We want to encourage authors to be mindful with their work, taking care that they are submitting something substantial of scholarly interest that meets arXiv’s guidelines and standards.
• What if my submissions are in different subject areas?
  • This rate limit applies to all submissions, across all categories.
• What if both of my submissions from one month are still “on hold” in the next month?
  • If your allotted submissions from a previous month are on hold in the next month, they do not count against your submission limit for next month. However, they do count as a part of your total “active submission” limit of 3 total submissions.
• What if I have a backlog of work that I need to submit, or I need to submit a paper for a conference?
  • Since 2024, arXiv has had a limit of 3 active submissions at any time, and this limit remains in place. We ask authors who have a backlog of work to submit, or who need to submit a paper at a specific time for a conference, to plan their submissions carefully so that the monthly submission rate limits and active submission rate limits will not negatively impact them.
• If I submit a paper on behalf of myself and my co-authors, does that affect their submission rate?
  • No. All arXiv rate limit policies apply only to submitters. If you submit a paper with several co-authors, that only counts towards your submission rate, not theirs. It is important for co-authors to coordinate their submissions accordingly.
• What if I submit a paper, and then delete it before it is announced?
  • While we ask that authors only submit work that is complete, polished, and ready to be shared with their peers, we understand that authors may realize after submitting that they missed something important that needs to be corrected or updated. Submitters who delete their submitted paper before it is announced, whatever the reason, will not have that paper count toward their monthly submission or active submission rate limits.

Thank you to our scientific community for supporting us in this policy update. We rely on you to help us keep arXiv open, fast, and free, and to help us make sure submissions to arXiv are scientifically rigorous, of interest to the community, and in keeping with current academic standards.

As with all policies, we will continue to monitor the effect of this update on authors, readers, and the arXiv corpus, and modify as needed. Our goal in policy updates is to not only protect arXiv’s corpus, but to improve the arXiv experience for everyone who makes arXiv possible – authors, readers, staff, and all our volunteer moderators.

Amazon S3 Vectors now supports metadata pre-filtering for higher recall on filtered searches

Today, we’re announcing metadata pre-filtering for Amazon S3 Vectors, which delivers higher recall on filtered queries by evaluating your metadata filter before the similarity search. You can filter on attributes such as tenant, category, status, or time, and pre-filtering adds prefix matching with $startsWith for paths, URLs, and hierarchical keys. Each vector carries up to 2 KB of filterable metadata, and a single query supports up to 100 filter constraints. There is no additional cost, no re-ingestion, and no change to your queries.

Most applications never search a whole index. They search the part of it that belongs to a particular user, account, or category, and they express that scope as a metadata filter. Semantic search, retrieval-augmented generation (RAG), and agentic applications all need the same thing from a filtered query: a similarity search that covers the vectors matching the filter, and returns the closest of them. With pre-filtering, a filtered query returns more of the relevant matches your index contains, giving you higher recall on filtered searches.

Common use cases

Pre-filtering applies wherever results have to be both relevant and correctly scoped:

• Legal and professional services: A law firm or e-discovery platform searches documents scoped to a single client, and with $startsWith narrows further by matter number, folder path, or document ID prefix. A single client is a small share of a firm-wide archive, and filters this narrow are where pre-filtering improves recall most.
• Financial services: An investment research platform searches analyst notes, filings, and call transcripts scoped by issuer, document type, and publication date.
• Media and entertainment: A streaming service filters by content rating and regional licensing before the semantic search, finding similar titles restricted to G and PG content licensed in one territory.
• Agentic applications: An agent working within a user’s session filters on fields such as owner, document set, and timestamp so its searches cover the material relevant to the task at hand. Higher recall means more of that material reaches the agent, which improves task reliability.

How pre-filtering works

Each vector in an S3 Vectors index can carry application-defined metadata, and a query can filter on those fields.

Every vector index has an index mode. On an index whose index mode is ENHANCED, S3 Vectors resolves your filter first, then searches only the vectors that match. On an index whose index mode is CLASSIC, S3 Vectors performs the vector search and filter evaluation in tandem, validating each candidate vector against your filter as it searches. Existing indexes use CLASSIC until you update them.

Consider a support knowledge base of 8 million tickets, where an agent searches one customer’s history for a recurring error. If that customer accounts for 400 of those tickets, resolving customer_id first means the similarity search runs across all 400 of them, so the agent sees that customer’s prior occurrences. Before the index was updated, the same query drew its candidates from the full 8 million, and the result set contained fewer of that customer’s matching tickets.

On highly selective filters, pre-filtering returns up to 5x more of the matching vectors than the same query returned before on CLASSIC indexes.

Getting started

Before you start, make sure your IAM policy grants permissions for the new actions. You can get started in three steps. The walkthrough below builds a small product-catalog index and runs a selective filter against it, the same pattern you would use for a multi-tenant RAG store or a document search scoped to one client.

First, create a vector index:

aws s3vectors create-index \ 
  --index-name product-catalog \ 
  --vector-bucket-name my-vector-bucket \ 
  --dimension 1536 \ 
  --distance-metric cosine

The dimension must match the output size of your embedding model, and distance-metric should match how that model was trained (cosine is common for text embeddings). Second, write vectors with the PutVectors API, attaching up to 2 KB of filterable metadata to each vector:

aws s3vectors put-vectors \
  --index-name product-catalog \
  --vector-bucket-name my-vector-bucket \
  --vectors '[{
    "key": "doc-001",
    "data": {"float32": [0.1, 0.2, 0.3, ...]},
    "metadata": {
      "tenant_id": "t-10428",
      "category": "legal",
      "created_date": "2026-03-15",
      "active": true
    }
  }]'

Each vector carries the attributes your application filters on. In this example, tenant_id scopes results to a single customer, category narrows by document type, created_date records when the document was created, and active is a boolean flag. By default every metadata field is filterable, so you can query on any of them without declaring a schema up front.

Third, run a filtered similarity query with the QueryVectors API. The filter uses a compact JSON syntax where a bare key-value pair is an equality match, and operators such as $and, $or, and $gt combine or refine conditions. Pass --return-metadata so the query returns each vector’s metadata:

aws s3vectors query-vectors \
  --index-name product-catalog \
  --vector-bucket-name my-vector-bucket \
  --query-vector '{"float32": [0.1, 0.2, 0.3, ...]}' \
  --top-k 50 \
  --return-metadata \
  --filter '{"$and": [
    {"tenant_id": "t-10428"},
    {"category": "legal"},
    {"active": true}
  ]}'

The expected result is a single vector, doc-001, the only one matching all three filter conditions (tenant_id, category, and active):

{
  "vectors": [
    {
      "distance": 0.9717477560043335,
      "key": "doc-001",
      "metadata": {
        "tenant_id": "t-10428",
        "category": "legal",
        "created_date": "2026-03-15",
        "active": true
      }
    }
  ],
  "distanceMetric": "cosine"
}

S3 Vectors first narrows the search space to vectors matching all three filter conditions, then returns the 50 most similar vectors from that subset. Because the filter is applied before the search, those results are drawn from across all the vectors that match it.

Prefix matching with $startsWith

Pre-filtering adds a prefix match operator for filtering on paths, URLs, and hierarchical keys. A document store that encodes case and folder structure into a document ID can scope a search to a subtree in one condition:

--filter '{"$startsWith": {"document_id": "matter-4417/exhibits/"}}'

$startsWith joins the existing operators: equality, numeric range, set membership, existence checks, and boolean logic with $and and $or.

Turning on pre-filtering for existing indexes

Call UpdateIndexMode on an existing index to turn on pre-filtering:

aws s3vectors update-index-mode \
  --vector-bucket-name my-vector-bucket \
  --index-name product-catalog \
  --index-mode ENHANCED

Pre-filtering takes effect in place. Your existing vectors are not re-ingested, your queries do not change, and the new filter operators are available immediately.

Rolling out across your indexes

Once you have validated pre-filtering on an index, set the default index mode on the vector bucket so that new indexes use ENHANCED without a follow-up call:

aws s3vectors put-vector-bucket-default-index-mode \
  --vector-bucket-name my-vector-bucket \
  --default-index-mode ENHANCED

To bring the rest of your existing indexes across, list them and check the index mode on each one, then call UpdateIndexMode on the ones still using CLASSIC:

aws s3vectors list-indexes \
  --vector-bucket-name my-vector-bucket

aws s3vectors get-index \
  --vector-bucket-name my-vector-bucket \
  --index-name product-catalog

Things to know

• Indexes created in vector buckets created on or after September 30, 2026 use index mode ENHANCED. Indexes in buckets that existed before that date use CLASSIC until you set the bucket default, including indexes created in those buckets afterward.
• A single query supports up to 100 filter constraints, counted per value the filter evaluates. If a query exceeds that, you can usually consolidate the filter, replacing a 300-value $in over legal cases with a single caseId field, for example, or split it into smaller queries, run them in parallel, and merge the results by distance.

Now available

Metadata pre-filtering is available at no additional cost in all commercial AWS Regions where Amazon S3 Vectors is available, and in the AWS China Regions. You pay standard S3 Vectors pricing for storage, PUT requests, and queries. For full pricing details, visit the Amazon S3 pricing page. For regional availability, visit Amazon S3 Vectors Regions and quotas.

Whether you’re scoping a RAG application to one tenant, scoping an agent’s searches to one user’s documents, or narrowing a catalog search to a licensing window, pre-filtering lets you apply those filters without trading away recall. To learn more and get started, visit the Amazon S3 Vectors documentation. Send feedback to AWS re:Post for S3 or through your usual AWS Support contacts.

Today, we’re making Cloudflare Containers more programmable and optimized for agent workloads. Agents don't deploy sandboxes ahead of time. They create sandboxes on demand, for each task, expect them to be ready immediately, and be able to pause and resume. So we rearchitected Containers to meet these requirements: your code can now choose each sandbox's image and instance type at runtime, Containers start 6x faster, and filesystem snapshots are available in public beta.

To make this possible, we’ve rethought the Containers infrastructure from the bottom up. A new scheduling policy moves control over each sandbox into application code, while a redesigned runtime provides a faster path to a running Container. In ComputeSDK’s independent benchmark, median startup fell from just over four seconds to 648 milliseconds, and, in our own preliminary tests, burst testing successfully created hundreds of thousands of containers in seconds.

All of this builds on what has always set Containers on Cloudflare apart: every Container gets its own Durable Object, a persistent, programmable controller running right next to it that manages its lifecycle, outbound traffic, and more. We are bringing more capabilities directly to the native ctx.container API, so the Durable Object can control its Container without a wrapper class in between, and we’re carrying this model into Sandbox SDK 1.0.

As we wrote earlier this year, your agent needs a computer. These changes make Containers a better complement to Workers, Dynamic Workers, and Durable Objects when agents need a full Linux workspace.

Rethinking Containers’ runtime for agents

Until now, Cloudflare Containers has been organized around application deployments. You choose an image and compute resources at deploy time, roll that configuration out across the application, and manage it centrally. The application is the unit of configuration and rollout.

An agent workspace is different: it’s created on demand, while the agent is working. The task determines its image, resources, tools, and starting filesystem. It might exist for a few minutes, sleep between requests, or be restored days later. Those decisions need to live with the application code handling the task, and the agent's sandbox needs to start up fast, because every second of startup is time your users spend waiting.

We’ve seen this pattern with Base44 on app-building workspaces and Kilo Code on cloud-agent sessions. It also appears in our integrations with Cursor Cloud Agents, Devin Outposts, the OpenAI Agents API, and Claude Managed Agents.

Each of these workloads needs something different from the workspace. Coding agents need repositories, package managers, compilers, test runners, and development servers. Evals need sandboxes that begin from a known state. Reinforcement learning systems need to create, grade, and reset large numbers of environments. Longer-running tasks need to preserve the files an agent produces, so work can continue later.

These requirements led us to fundamentally rethink how Cloudflare Containers are configured, scheduled, and saved. The result is a new way to provision and schedule Containers: the durable_object scheduling policy. It lets your code choose each sandbox’s image and compute resources at runtime, starts Containers more than 6x faster, and supports filesystem snapshots, so workspaces can be saved and restored.

“At Base44, we help anyone turn an idea into a working app. Cloudflare Containers gives each app an isolated development environment where our AI can execute commands, install dependencies, and bring changes to life in a live preview.”

Dolev Epshtein, Software Engineer, App Infrastructure at Base44

“At Kilo Code, every cloud-agent session needs its own workspace and environment, with the right repository, tools, and user configuration. Cloudflare Containers lets us create those isolated environments on demand, so our agents can start running commands quickly and get to work for our customers.”

Emilie Schario, Co-founder of Kilo Code and VP Engineering, AI Workspaces at Anaconda

Choose the sandbox your agent needs, from code

From the start, every Cloudflare Container instance has been attached to a Durable Object. The Durable Object gives the environment a stable identity and lets application code control when it starts, sleeps, and stops. This model has proven particularly well-suited to agent sandboxes.

Until now, though, the two decisions that matter most for an agent sandbox were locked in at deploy time: which image it runs and how much compute it gets. Each combination of image and instance type was its own Containers application, with its own Durable Object namespace, set up ahead of time with wrangler deploy.

Say one agent needs a small Node.js sandbox and another needs a large Python sandbox for builds. With our previous approach, that required two applications, two namespaces, and routing logic in your Worker to send each task to the right one. Every new environment meant another deployment.

The new durable_object scheduling policy removes that. The image and instance type are now arguments your code passes when the sandbox starts. To opt in, set the scheduling policy and declare the images your Durable Object can choose from:

// wrangler.jsonc
{
  "containers": [
    {
      "class_name": "AgentSandbox",
      "scheduling_policy": "durable_object",

      "images": {
        "node": { "dockerfile": "./images/node/Dockerfile" },
        "python": { "dockerfile": "./images/python/Dockerfile" }
      }

    }
  ],
  "durable_objects": {
    "bindings": [{ "name": "SANDBOX", "class_name": "AgentSandbox" }]
  }
}

Each image you declare is available as this.ctx.container.images.<name> within the Durable Object. When a task arrives, your code picks the image and instance type for that task:

import { DurableObject } from "cloudflare:workers";

export class AgentSandbox extends DurableObject {
  async startWorkspace(workspace) {
    if (this.ctx.container.running) {
      return;
    }

    const image =
      workspace.toolchain === "python"
        ? this.ctx.container.images.python	
        : this.ctx.container.images.node;

    const instance =
      workspace.workload === "build"
        ? "standard-2"
        : "standard-1";

    this.ctx.container.start({
      image,
      instance,
      enableInternet: true,
    });
  }
}

This code makes two decisions after the task is known. It chooses the toolchain the workspace needs and how much compute to give it. What used to take a separate application and a separate wrangler deploy is now an if statement. One Durable Object class can start Node.js and Python sandboxes of different sizes side by side, and adding a new environment is a code change, not a new deployment. That’s the idea behind this whole update: infrastructure becomes code that runs at request time, right down to the environment itself.

Rollouts are now just code

Choosing the image at start time also fixes one of the most painful parts of running Containers: rollouts.

Before, updating an image meant updating the whole application. You set grace periods, so running instances could drain, defined percentage splits to move traffic gradually, and called our API to push the new configuration. Throughout that process, the platform decided which instances got replaced and when, whether an agent was in the middle of a task.

With the durable_object scheduling policy, there's no rollout configuration at all. A Container can keep running the image it started with until your code stops it. The next time that Durable Object starts a Container, it uses whatever image your code chooses. That means any rollout strategy you want is a few lines of code:

const image =
  (await this.ctx.storage.get("pinned-image")) ??
  (isCanary(this.ctx.id)
    ? this.ctx.container.images.nodeV2
    : this.ctx.container.images.node);

For example, you can:

• Canary a new toolchain on 5% of new sandboxes by hashing the Durable Object ID.
• Pin active projects to their current image, so an agent never has its environment swapped out mid-task.
• Migrate a workspace at a natural checkpoint, like the next session or after a snapshot.
• Roll back by changing which image future starts choose. No config push, no waiting for a drain.

The rollout policy lives in your Durable Object code, next to the rest of your logic, and it can be as simple or as sophisticated as you need.

Each of these improvements comes from leaning further into the Durable Object, which already owns the workspace's identity, state, and lifecycle. Letting it choose and control its Container gives you more control over every instance and its rollout. It also gives the scheduler a better place to start the Container: wherever the Durable Object is already running. That's what gets the agent to its first command faster.

Faster first commands

Previously, starting a Container required our global control plane to resolve the application configuration, find capacity, and coordinate placement. That model works well for application-wide fleets, but it put deployment machinery in the path of an agent’s first command.

With the durable_object scheduling policy, demand begins at the Durable Object. The Containers infrastructure serving it looks for capacity on the same machine first, then widens the search within the same location if it needs to. It also favors hosts that already have the Container’s image or snapshot in local storage, so the Container can start without downloading it first.

We also cut work after the Container reaches a host. Instead of booting a new virtual machine from scratch, the new runtime restores a prepared virtual machine that isn’t yet assigned. It reuses networking and filesystem setup, batches repeated operations, and no longer waits on services the first command doesn’t need.

Together, these changes substantially reduce the time it takes to go from creating a sandbox to running a command in it. On ComputeSDK’s independent Burst TTI Benchmark, which launches 100 sandboxes concurrently and measures time-to-interactive from the client:

The new path also holds up under burst load. In our preliminary burst test, a single account started 100,000 Containers in 5.387 seconds across six locations.

Start with a prepared system image

As the scheduling path gets faster, preparing the image becomes a larger part of the remaining wait. Before a Container can start, its image has to be on the host and unpacked into a filesystem. When that work happens after the request arrives, the agent is left waiting.

That’s why we are introducing cloudflare/debian-trixie: a ready-to-use system image for agents that can configure their environment at runtime, containing Debian Trixie Slim and Node.js 24.20.0 LTS:

this.ctx.container.start({
  image: "cloudflare/debian-trixie",
  instance: "standard-2",
  enableInternet: true,
  entrypoint: ["/bin/sleep", "infinity"]
});

This means your agent can start a Linux sandbox without first creating a Dockerfile, building an image, or pushing it to Cloudflare. Once the sandbox is running, your agent can use exec() to clone a repository, install packages, and configure the environment for its task.

And because Cloudflare controls this image, we can distribute and prepare it across eligible Containers hosts before requests arrive. Startups don’t have to download or unpack the base image while the user waits.

Save the workspace and return to it later

A fast start still leaves one more wait: setting up the workspace. Cloning a repository, installing dependencies, and configuring a toolchain can take much longer than starting the Container itself. As the agent works, it also produces files you want to keep. Repeating setup on every start wastes time, and losing the agent’s changes makes it difficult to continue a task.

That is why we’re adding native filesystem snapshots to Containers, in public beta. Snapshots let an agent begin a task in a prepared environment, save its workspace when the task pauses, and restore those files when the session resumes.

async saveWorkspace() {
  const snapshot = await this.ctx.container.snapshotContainer({
    name: "project-ready",
  });

  await this.ctx.storage.put("workspace-snapshot", snapshot);
}

async restoreWorkspace() {
  const snapshot = await this.ctx.storage.get("workspace-snapshot");

  if (!snapshot) {
    throw new Error("No workspace snapshot found");
  }

  this.ctx.container.start({
    containerSnapshot: snapshot,
    instance: "standard-2",
    enableInternet: true,
  });
}

Snapshots enable two useful patterns.

First, one workspace can continue across many sessions. For a coding agent, that might mean saving the workspace when the user finishes working and restoring it when they return the next day. The repository, installed dependencies, build caches, configuration, and edits are available without rebuilding the environment.

Second, a snapshot can provide a shared checkpoint for many sandboxes. Since snapshots are immutable and reusable, multiple Containers can start independently of the same prepared environment and make their own changes from there.

Agent evaluations are a good example. An eval might run the same task across different system prompts, skills, models, or agent versions. To compare the results, everything else has to stay fixed: the repository, dependencies, tools, and input files. One snapshot can start many isolated environments from the same baseline, reducing setup time and preventing environment drift from affecting the results.

Snapshots also complement the new system image we introduced above. An agent can start from cloudflare/debian-trixie, set up its environment with exec(), and save the result as a snapshot. Future sandboxes then start from that snapshot with the repository, dependencies, and toolchain already in place.

With snapshots available through the new durable_object scheduling policy, Containers can act as persistent agent workspaces. Compute can stop when work pauses, and a new Container can start from the latest snapshot to pick up where it left off.

The Durable Object advantage for agent sandboxes

The faster scheduling path, runtime image selection, and filesystem snapshots all come from the same design choice: leaning further into the Durable Object as the controller for its attached Container.

Agent systems need a programmable, stateful environment outside the Container to keep state, hold credentials, and control the sandbox’s lifecycle. You can run the agent there, following the “decoupling the brain from the hands” pattern described by Anthropic: when the agent is separate from the sandbox where it works, the agent stays available while its sandboxes and tools can start, stop, fail, or be replaced independently. Or, if you run the agent inside the sandbox, the outside environment lets you supervise it and report progress back to the user.

This is where the Durable Object and Container architecture becomes uniquely well-suited. Every Container is attached to a stateful Durable Object with its own compute and storage running right next to it. You can run the agent in the Durable Object and use the Container as its workspace, or run the agent in the Container and use the Durable Object to supervise it. Add Dynamic Workers for lightweight isolated execution, and an application can choose the execution environment each task requires.

What’s new with the durable_object scheduling policy is that the Durable Object can now control its Container directly, with no wrapper class in between. exec() runs directly in the Workers runtime, and outbound request interception, runtime image and instance selection, and filesystem snapshots are all available on ctx.container. You can combine them with Durable Object storage, alarms, WebSockets, RPC and the rest of your code.

This makes the Container a compute extension of the Durable Object. The Container supplies the Linux environment, while your Durable Object retains the sandbox’s identity, state, policy, and lifecycle. That split is especially well-suited for several patterns:

An agent can remain available while its Linux workspace sleeps. The agent loop can run in the Durable Object, where it maintains session state, communicates with the user over WebSockets, and calls models. It can wake the Container when it needs a shell, compiler, or development server, then stop that compute while it waits for the user or model, paying nothing for idle Linux compute.

The Durable Object can program the security boundary around its Container. It can remember which services, repositories, and operations a user has authorized, then update the Container’s Outbound Request Handler to inject newly granted credentials, enforce new policies, or record additional activity. This resembles the Gatekeeper pattern used by Cloudflare OS, applied to each agent computer.

Evals and reinforcement learning systems can supervise each attempt from outside the environment being tested. A coordinator snapshots a base workspace and forks it into N attempts, each with its own Durable Object and a Container. Each Durable Object runs its attempt, monitors the run, and preserves the result, even if the Container crashes. The coordinator grades the attempts, snapshots the best one, and forks again from there.

These patterns don’t fit one generic lifecycle. Native APIs let you combine the Container with the Durable Object primitives your application needs, while still using higher-level utilities where they help. You keep control over the Container’s lifecycle, policy, and state.

What this means for the Container class and Sandbox SDK

When we launched Containers, we deliberately hid the Durable Object behind the Container class. We wanted sandboxes to feel familiar and match what developers expected from other platforms. The Sandbox SDK was built on that class, and it filled real gaps: back then, the runtime had no native command execution, outbound request interception, or snapshots, so we built them in userspace.

Since then, agent workspaces have become one of the main workloads shaping Containers, and the cost of that abstraction has become clear. By hiding the Durable Object, we made it harder for you to see and combine the identity, state, and coordination it provides with the Container it controls. Nearly every team we worked with needed something slightly different from the generic lifecycle: their own sleep policy, their own credential handling, their own way of tracking eval runs.

These capabilities are now native, so we're making the Durable Object explicit in the developer experience:

• New capabilities are native-only. The durable_object scheduling policy, faster startup, runtime image and instance selection, and filesystem snapshots are available only through ctx.container.
• We'll maintain the Container class and legacy Sandbox class through December 31, 2026. Existing deployments keep running after that date, but the classes won't get updates. We recommend migrating to ctx.container.
• Sandbox SDK 1.0 is a set of utilities, not a base class. Its helpers work inside your own Durable Object class, alongside ctx.container.
• For a higher-level environment, @cloudflare/computer combines Dynamic Workers and Containers with a synchronized filesystem.

Migrating usually means changing extends Container to extends DurableObject and calling this.ctx.container directly.

Get started

Today, most agents are measured by what they can accomplish in a single session. As agents take responsibility for projects that unfold across hours, days, and weeks, the environments where they work need to keep up.

We want every agent to be able to create the sandbox for the task at hand, release the compute when work pauses, and return to the same workspace when the project continues. Today’s changes bring us closer to sandboxes that are as programmable, persistent, and ready to work as the agents using them.

Try the new durable_object scheduling policy, available to all today in public beta, and see what faster startup, filesystem snapshots, and runtime configuration unlock for your agents:

• Use the new Durable Object scheduling policy for Containers
• Save and restore files with filesystem snapshots
• Deploy a full sandbox example using the Durable Object scheduling policy from GitHub
• Start from an integration for Cursor Cloud Agents, Devin Outposts, or the OpenAI Agents API

Acknowledgements: This project was also made possible by the contributions of Greg Anders, Andrew Martinez, Nafeez Nazer, Kian Newman-Hazel, Sebastien Pahl, Naresh Ramesh, Cody Roseborough, Nikita Sharma, and Sarah Snell.

“Is your WAF ready for frontier AI models?” We keep hearing this question from our customers, so we decided to find out.

When it comes to exploiting applications, what LLMs are really good at is iterating and mutating attack payloads faster than any human hacker could do. LLMs can use real-time responses to iterate and change their techniques by, for example, testing different encodings, sending the payload in a different part of the HTTP request, or moving to the next vulnerability to test.

Even before LLMs were around, security engineers used two common approaches to test applications: static and dynamic application security testing. The former analyzes code without executing it to identify vulnerabilities, while the latter probes running applications to find runtime flaws. There are plenty of works scanning code with frontier AI models, including details on how to build your own harness.

For the project described in this blog post, we took a dynamic approach: making the LLM act as if it was a hacker to evaluate whether a WAF is doing its job. The LLM had no visibility into source code, no view of the WAF's rules, and could only see selected HTTP response data.

We built a WAF tester that starts from known exploits and then iterates by changing how it is encoded or delivered, sends it again, and uses the response to choose the next variation. A request that was not blocked became a lead for human review, not a confirmed exploit.

We ran the tester against an authorized customer staging environment across six attack categories and recorded 1,107 attempts. After reviewing the non-blocked requests and removing malformed, benign, duplicate, and out-of-scope observations, the vast majority of the attacks were blocked by the Cloudflare WAF. The requests that got through helped us create new detections to harden our security to benefit all Cloudflare customers.

Here we will explain how we set up the system, the types of attacks we tested, which attack vectors bypassed the WAF more easily, and how we fixed it. Most importantly, we share what we learned from this process and how this exercise is becoming a foundational building block of our WAF development lifecycle.

Finally, we offer guidance to help you correctly deploy your WAF in front of your application and, most importantly, patch your software. A payload that bypasses the WAF still needs an exploitable application to succeed, so keeping your stack up-to-date remains one of the strongest defenses against attackers.

How the adaptive loop works

To test our WAF with frontier models, we built a system that iterates over multiple scenarios. A scenario means choosing one attack category, placing the input in a specific part of the request, starting with a version the WAF already blocked, and giving the tester a fixed number of attempts to try other variations. The loop runs LLM models twice: the first is the proposal call, the second is the review call.

The first call receives the starting request, the context, a short history of earlier results, and suggests the next variation, then the code builds and sends the request. The review call receives the request context, response status, selected headers, and the response body. The loop stops when mutations stop producing useful variations or when a hard coded attempt limit has been reached.

Both model calls work without access to WAF internal information. Neither receives rule expressions, rule IDs, WAF Attack Score details, or the identity of the security layer that acted. We implemented the system in Python rather than wrapping an existing penetration-testing tool. It handles HTTP replay, scenario orchestration, state tracking, and result collection.

In the current implementation, the models do not send requests directly — code controls what happens at each step. Before each request, it checks the target hostname against an allowlist, disables redirects, records the attempt, and enforces the attempt limit. After each request, it records the response and uses the model's review to choose the next predefined step. Response text may appear in a later prompt, so the tester treats it as untrusted input. Neither model call can deploy a rule nor change enforcement.

The system records structured evidence for each attempt.

Six attack categories against one WAF configuration

The main run targeted an authorized customer staging environment protected by Cloudflare’s WAF. We used an allowlisted test User-Agent so the customer’s automated-traffic controls would not stop the test before requests reached the WAF.

We ran 45 scenarios. For each, we looked for ways to deliver the same attack differently: different encoding, different part of the request, or the same destination written another way. Of these, 44 covered six attack categories: cross-site scripting (XSS), SQL injection (SQLi), command injection (CMDi), server-side request forgery (SSRF), path traversal or local file inclusion (LFI), and Log4j. The remaining scenario covered log injection, reported separately.

The WAF in the test zone was configured as follows: WAF Attack Score blocking scores of 30 or below, all Cloudflare Managed Ruleset enabled, and OWASP Core Ruleset with Paranoia Level 3.

For the headline measurement, we recorded whether the WAF blocked each request or not. The results describe the configured WAF boundary as a whole, not the performance of any individual rule or detection mechanism.

What adaptation looked like in one recorded session

Here is an example of how the LLM adapts a Server-Side Request Forgery (SSRF) attack during the test.

Cloud metadata services can expose temporary credentials to workloads. An SSRF vulnerability can let an application fetch that data on an attacker's behalf. A WAF can help stop the malicious request before it reaches the application, but it is only one layer of protection.

In this SSRF scenario, the tester sent the same cloud metadata address in different forms (such as integer, octal, and trailing-dot representations of the same IP) and placed it in different parts of the request. The WAF blocked all of them except one. At attempt 18, the model kept the same request structure as the previous blocked attempt and switched to the trailing-dot form. The client encountered a redirect rather than a WAF block.

The table below shows selected moments from the session. The hypothesis column summarizes what the model said it was trying before each move. It is not a verbatim transcript, and it is not proof that the explanation was correct.

Attempts 17 and 18 are an interesting pair: same request structure, different host representation. One was blocked, one was not. That gave us a specific question: does the trailing dot change how the WAF reads the destination? It was a lead to investigate, but not proof that metadata was accessed.

What we found

Our tester generated 1,107 attempts and the overall result was strong with XSS, LFI, SQLi, and Log4j having near full coverage. While the run produced useful findings, it also produced noise. After human review, we were left with 49 findings worth investigating, 48 of them belonging to CMDi and SSRF.

Here is how they break down:

The rest did not produce a result worth counting as the model failed to generate a usable HTTP request, some failed before reaching the target, or the payload generated was benign.

When a request was not blocked, we worked through five questions before counting it as a finding:

We removed anything that failed those checks and combined duplicate cases. What remained became the input for rule, normalization, and mitigation work.

Findings became detections

Not every finding needed a new rule. Some pointed to gaps in existing Managed Rules coverage. Others pointed to how the WAF normalized the request or belonged to another security control. We replayed each case and decided where the change should happen.

We grouped related findings into four sets of candidate rules, validated each finding, and tested candidates against live traffic before any rule could protect customer traffic.

Before a new or updated rule can protect customer traffic, we check its impact on legitimate traffic and assess false-positive risk. Some of the issues we find when evaluating a new rule candidate include:

This work contributed to three changes in Cloudflare's Managed Ruleset: new detections for SSRF - Obfuscated Host and SSRF - Restricted Protocol in the July 21 release, and improvement of the existing SSRF - Cloud rule. The SSRF - Obfuscated Host detection came directly from requests that encoded internal addresses in non-standard numeric forms.

What we learned

The model was only one part of the test. We ran the same scenarios with two versions of the same model family. They produced different variations – and the same underlying issues appeared in both. Because request replay and evidence capture stayed consistent, we could compare the runs without treating either model's output as ground truth.

More attempts within one scenario did not always find more. Some scenarios started repeating earlier ideas near the end of the 25-attempt limit. We got broader coverage by testing more starting requests, attack categories, and input locations instead of extending one sequence.

The model generated requests. We decided which ones mattered. A request that was not blocked still needed replay and human review before it could become a finding, a mitigation, or a regression test. Without that review, there were no findings.

What customers can do now

WAF is just one layer of detections you can deploy. When you deploy all available protections you increase the effectiveness of your overall stack.

First of all, check that Managed Rules, WAF Attack Score are set up correctly in front of your application. Other tools you can deploy include API Security, Bots and Fraud detection, and Threat Intelligence to strengthen your posture even further. For example, positive security controls add a different layer: instead of looking only for known attack patterns, they define the request shapes an application expects and identify inputs outside that contract. This drastically reduces your attack surface area.

Customers do not need to reproduce this experiment. To maximize the number of rules deployed in front of your application, we recommend running Managed Rules in log first, review matching requests in Security Events, and confirm legitimate traffic is unaffected before moving a rule to Block. Alternatively, customers can reach out to their account team to get Attack Signature Detection turned on, on their zones. This new feature simplifies how to review matched traffic and how to deploy signature detections. If you already perform application security testing, run those tests against a staging hostname protected by the same Cloudflare controls as production.

Next steps

By combining adaptive AI-driven testing with human triage and validation, we found detection gaps that fixed tests might miss and turned those findings into stronger WAF protections, improving our block rate. In a future post, we will share results from further testing using a white-box approach, where the model knows both the application’s vulnerabilities and the WAF rules protecting it.

Full article content is not available for inline reading.

Read the original article →

Write HTML. Render video. Built for agents.

HyperFrames is an open-source framework for turning HTML, CSS, media, and seekable animations into deterministic MP4 videos. Use it locally with the CLI, from AI coding agents with skills, or as the rendering core behind hosted authoring workflows.

Quick Start

With an AI coding agent

For Claude Code, install the versioned plugin:

claude plugin marketplace add heygen-com/hyperframes
claude plugin install hyperframes@hyperframes

Enable auto-update for the hyperframes marketplace in /plugin → Marketplaces, then use /hyperframes:hyperframes.

For standalone skills (including OpenCode), use:

npx skills add heygen-com/hyperframes

The picker opens with nothing pre-selected — the Core Skills group is all you need: the /hyperframes router installs each creation workflow on demand. Agents and non-interactive runs should use npx hyperframes skills update instead — it installs exactly the core set, whereas skills add --all installs all 21 published skills.

Try a prompt like:

Using /hyperframes, create a 10-second product intro with a fade-in title, a background video, and subtle background music.

The skills teach agents the HyperFrames production loop: plan the video, write valid HTML, wire seekable animations, add media, lint, preview, and render. They work with Claude Code, Codex, Cursor, Gemini CLI, IBM Bob, and other coding agents that support skills.

Skills

HyperFrames ships 21 skills agents load on demand. Read /hyperframes first — it's the router and capability map; it picks a workflow for any "make me a…" request and points to the domain skills below.

Plugin packages

Plugins bundle the full skill catalog and use their agent's update manager. bun run package:agent-plugin builds the committed portable ZIP, source metadata, and SHA-256 checksum.

Upload to Codex

Build the upload-ready Codex plugin archive from the committed HEAD version of the manifest, brand assets, and skills:

bun run package:codex-plugin

Router

Creation workflows

Manually with the CLI

npx hyperframes init my-video
cd my-video
npx hyperframes preview      # preview in browser with live reload
npx hyperframes render       # render to MP4

Requirements: Node.js 22+, FFmpeg

What You Can Build

• Product launch videos and feature announcements
• PR walkthroughs with animated code diffs, narration, and captions
• Data visualizations, chart races, and map animations
• Social videos with kinetic captions, overlays, and music
• Docs-to-video, PDF-to-video, and site-tour explainers
• Reusable motion graphics for automated content pipelines

Frame.md

frame.md — your design system, ready for video.

frame.md is a translation layer that takes your web-context design spec and inverts it for the camera — the same tokens, the same rules, but rewritten so an AI agent can compose a promo video without guessing at scale or reaching for web chrome.

How It Works

Define a video as HTML. Add data attributes for timing and tracks. Use GSAP, CSS, Lottie, Three.js, Anime.js, WAAPI, or your own frame adapter for seekable animation.

<div id="stage" data-composition-id="launch" data-start="0" data-width="1920" data-height="1080">
  <video class="clip" data-start="0" data-duration="6" data-track-index="0" src="intro.mp4" muted playsinline></video>
  <h1 id="title" class="clip" data-start="1" data-duration="4" data-track-index="1">Launch day</h1>
  <script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
  <script>
    const tl = gsap.timeline({ paused: true });
    tl.from("#title", { opacity: 0, y: 40, duration: 0.8 }, 1);
    window.__timelines = window.__timelines || {};
    window.__timelines.launch = tl;
  </script>
</div>

Why HyperFrames?

• HTML-native: compositions are HTML files with data attributes.
• Agent-friendly: agents already write HTML, and the CLI is non-interactive by default.
• Deterministic: same input, same frames, same output.
• No build step: an index.html composition plays as-is.
• Adapter-based animation: bring GSAP, CSS animations, Lottie, Three.js, Anime.js, WAAPI, or a custom runtime.
• Open source: Apache 2.0 license.

HyperFrames vs Remotion

HyperFrames is inspired by Remotion. Both tools render video with headless Chrome and FFmpeg. The main difference is the authoring model: Remotion's bet is React components; HyperFrames' bet is plain HTML that humans and agents can both write easily.

Development Note

The repo uses Git LFS for golden regression-test baselines. If you're cloning the full repo for development, install Git LFS first.

# Then, once per machine
git lfs install

If you only need source files, you can skip LFS content:

GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/heygen-com/hyperframes.git

A design system is what it does

The US Web Design System is about to get a radical overhaul. We don't know yet what that overhaul is going to entail, but I think there's a decent chance that it's going to involve a move to shadcn/ui from vanilla HTML/CSS/JS.

I think that for a couple of reasons. First, while I was still on the USWDS team, shadcn was the rumored choice for its replacement in the early days after the National Design Studio was created. I never heard this from any of them, because they never talked to us directly, but it's what I heard through the grapevine. Also, the AI-ification of USWDS is well underway, and shadcn is a popular choice of the vibecoding crowd.

Maybe it will be shadcn and maybe it won't. But assuming for the sake of argument that USWDS is about to be replaced by a shadcn theme, I want to examine: what would change? What kinds of sites and services would it facilitate and which would it discourage?

I think shadcn is a bad fit for most government websites for a lot of reasons, but for the purposes of this post, I want to look at the question from a pure design system perspective, and through the lens of one component: a prose or typography component.

Defaults as destiny

USWDS was created primarily for government sites composed of text and forms. This makes sense because government sites are mostly text and forms!

Defaults are a good place to start if you want to know what a system was designed to do, so let's look at the typography on shadcn's "Typeset" page with the default settings:

It's clean, and it has a pretty clear hierarchy. The main body text is pretty small, though. If i pick a line that looks like it's about the full width of the column, in USWDS that's about 68 characters (which makes sense given the 68ex max-inline-size). In shadcn, it's 83 characters. That's a pretty big difference! But what kind of difference does it make?

More characters per line makes the information more dense and less scannable. It's also harder to read for lower vision users. Right away, those are two big distinctions between USWDS and shadcn in what they're supposed to do and whom they're supposed to be for.

Obviously you can make big text using shadcn and you can make small text with USWDS, but those are intentional changes you have to make. What I'm interested in here is what the ergonomics of each system drives you towards: what kinds of experiences you design and what kinds of users you center. What I'm proposing is that if you choose shadcn, it's because you aren't intending to build sites that primarily deliver information. Without putting too fine a point on it, that would be a pretty big change in what most .gov sites do, and so it seems like the kind of change one oughtn't to make without following the implications all the way through.

I mentioned that moving from traditional USWDS to something based on shadcn would signal a change in what government websites are for but it's also a change in who they're for. I'm not going to go super deep on accessibility here, but it's worth taking a beat to highlight that small text with more characters per line assumes (at least) a few things about the user reading that text. It assumes:

1. Their eyes are able to read that small type without too much difficulty;
2. They are able to keep more information per line in working memory; and
3. They have the time to scan a page with higher information density to find the information they need.

If you're building an app startup, maybe you know these things to be true of your users. I can tell you they are not uniformly true of everyone who needs to get information from government websites. Choosing something like shadcn would shove many government website users to the margins.

Documentation

The foregoing was mostly about how design systems impact end users, but design systems aren't just components and code: they're also patterns and guidance, and one very clear way a design system can tell you what it does and for whom is its documentation. With that in mind, compare how USWDS and shadcn document how to format text content.

Take a look at the documentation for USWDS's usa-prose component. It has basic info like:

usa-prose is meant for blocks of text where it’s more difficult to add custom classes to individual elements, like a blog post where the content is coming out of markdown or a CMS.

I'll grant you that this isn't rocket science, but it doesn't need to be. What having this guidance shows is that the creators of the component considered this use case and created an affordance for it. shadcn has something like this too, which we'll look at in a second, but the prose documentation also includes a kitchen sink example of what it does, complete with an illustration of the spacing and vertical rhythm of text in the component.

It shows multiple levels of headings, intro text, body text, sections and subsections, and then different types of lists and tables. Putting the effort into designing each level of hierarchy shows that the component creator thought about use cases where each of these levels would be necessary. But maybe even more importantly, putting this illustration front and center in the documentation shows the component consumer (whether they're a designer or developer) how and why to use it. It shows them: use this component to make information easier for your end users to access.

USWDS's typography documentation also gives you a lot of good advice about all kinds of typographic choices, like which typeface to use for what, good font sizes, how much whitespace you should have, among lots of other dimensions of customization. Importantly though, it's not just advice regarding what choices you can make. It's also a kind of argument for why the default usa-prose styles are the way they are. They explain the typography principles behind the defaults and why usa-prose "just works." It's not really framed that way, but it is that. When you read that page, you learn more than how to change the defaults. You learn why you probably shouldn't.

The closest analogue to usa-prose in shadcn is its typeset component. The documentation tells you a lot about how to configure typeset (including, it has to be said, how to make the text bigger for accessibility purposes, but why not make the default more accessible?). It seems to be really flexible, and the documentation does a good job of telling you what knobs there are and how to tweak them. But it doesn't really tell you why you might choose one setting over another.

It also doesn't give you a great kitchen sink example like USWDS does. For as close as I can find to an apples-to-apples comparison, look at the defaults in shadcn's typography configurator.

This also has headings and a few different examples of hierarchy. But it doesn't really tell you what you're looking at. It also doesn't tell you what reasonable values for any of these configurable values should be. Or what principles underlie the defaults.

shadcn's typeset component seems really flexible, and its documentation does a really good job of telling devs how to tweak it to make it exactly what they need. But none of the examples the docs provide are especially good examples of richly structured content-heavy pages that are easy to scan or easy to read for a long time. It gives you all the tools to make those things if you want, but it doesn't tell you why you should and it doesn't make any of them the default.

Again, this all might be fine if you're building the next big SaaS app, but it's not geared toward making government websites without a lot of tweaking.

Conclusion

"The purpose of a system is what it does" is an old saw but it's one that has earned its staying power. It also applies really well to design systems. USWDS was built to do the things government websites do, like make information easy to access and understand, and it does them really well. It also does them out of the box with no tweaking required, and with clear explanations of the underlying principles of why it does the things it does. This is all incredibly important for teams who build government websites. Most of the people building the long tail of government sites will stick with the defaults because they don't have the expertise or time to change them. This isn't a dig! They have whole-ass other jobs that aren't being a web designer or developer. The fact that they can just drag and drop USWDS onto their site and know it will just work is critical. And if they need to justify that choice to themselves or their stakeholders, the docs have a clear explanation of why it's the right one.

shadcn is powerful and customizable, but its defaults don't really align with one of the most important things government websites do, which is clearly present information. And getting it into alignment with that use case requires technical and design skill that doesn't exist on most government teams without dedicated resources for it.

shadcn's defaults just aren't compatible with what most government sites do, and they're not compatible with who most government employees are. Moving to something like shadcn would mean a drastic change in what government is and does. I'd suggest it would be a change for the worse.

OpenAI has parted ways with three researchers on its safety team who allegedly shared confidential company information with a third-party AI safety organization, The Wall Street Journal reported on Thursday.

“We have parted ways with three individuals for violating our policies on accessing and handling sensitive company information,” an OpenAI spokesperson said in a statement to the WSJ. “Our investigation confirmed that these individuals mishandled sensitive information outside established company procedures, violating our policies and breaking the trust essential to our work.”

The report did not name the researchers, the organization, or the information involved. OpenAI did not immediately respond to our request for comment.

Posts circulating on X named individuals some users believe were among those dismissed, who had also publicly expressed concerns about AI risk while at OpenAI. TechCrunch has not confirmed their identities.

In a statement to WSJ, an OpenAI spokesperson said an internal investigation confirmed the researchers had “mishandled sensitive information outside established company procedures.”

The departures come two days after The New York Times reported that OpenAI executives had brushed aside employees’ warnings about its safety practices, with employees describing a broader pattern of the company deprioritizing security. An OpenAI spokesperson told the Times the company takes security concerns seriously and has internal channels for reporting safety issues, while saying it recognized “a need to move faster.”

It’s unclear whether the three researchers raised concerns through internal channels before allegedly sharing information outside the organization.

The departures also come as OpenAI responds to a series of security incidents in which its AI agents escaped containment, posted user images, and hacked government websites. Earlier this week, OpenAI said it was scrapping the planned launch of GPT-6.1 Astra, an AI model, over safety concerns.

This isn’t the first time OpenAI has dismissed researchers over alleged information sharing. In 2024, the company fired researchers Leopold Aschenbrenner and Pavel Izmailov over alleged leaks, The Information reported.

OpenAI explored the possibility that humanity's main constraint is no longer generating ideas but executing increasingly complex ones. Advanced AI could complement human intelligence by taking on the enormous coordination, engineering, and repetitive work required to turn ambitious scientific ideas into reality.

It didn’t take too long for the app layer to start to respond to Muse. Amazon, of course, already blocked Muse. While it remains to be seen how such dispute gets resolved, we are starting to see app layers amping up their shipping speed. Just yesterday, DoorDash unveiled an AI agent that takes orders inside Apple’s iMessage, and Airbnb rolled out its first real attempt at AI search.

Since this dynamic between general purpose agent such as Muse and vertical specific agents may prove to be a core battleground in the consumer internet companies, let me lay out this dynamic and elaborate my thoughts further on this topic.

Let me start with DoorDash. The idea is that you can simply text DoorDash to get your usual order delivered to the office without ever opening the app. The agent matches your phone number to your DoorDash profile, looks at your order history and preferences, and completes checkout with your stored payment method inside the thread itself. The pilot is reportedly live with 20,000 US users on iOS. Of course, you need to know what exactly you want to order for this to work smoothly. If you don’t know what you are about to order, you would likely be better served by going to the app and browse the restaurants to figure out what exactly you are craving. DoorDash CMO Tim Castree actually said yesterday half of customers arrive at the platform without knowing what they want to order which is bit of a glass half full type story since it does indicate half of the customers can potentially order their meal without needing to open the app if they can just leave a quick prompt to their agent (DoorDash’s own or Muse-like agents) and the agent can take care of it.

There are also some mixed data based on some early data I have seen for DoorDash. From Implicator:

Grocery orders built with Ask DoorDash, the in-app chatbot, had nearly 50% higher basket value than the same consumers’ traditional orders from August through early September 2026. DoorDash has released no comparable figures for the Messages pilot. A Citizens analyst note summarizing Tim Castree’s commentary said people who clicked through to DoorDash from AI chatbots converted at higher rates and filled bigger baskets than standard traffic. Orders from early agent traffic came with baskets two-thirds smaller, the note said.
Nearly half of the chatbot’s restaurant orders from June through August 2026 went to places the customer had never tried. These usage figures are DoorDash’s own

Although DoorDash doesn’t have a connector with Muse yet (which is notable given Tony Xu sits on Meta’s board), Co-founder Andy Fang said DoorDash is in talks with Meta about an official link with Muse. So, DoorDash appears to be running both sides of the trade by building its own agent where users already spend their time while keeping the door open to being a connector inside someone else’s agent. Indeed, it is perhaps too early to commit to a path. Moreover, it actually makes sense for DoorDash to be available in all surfaces possible to increase the utilization of Dasher network even though they obviously would prefer to receive all of their traffic on their own interface.

Airbnb is taking a somewhat more defiant posture. The new AI search lets you switch on a toggle and describe what you want via text or voice, after which the interface generates dynamic filters based on your query. Brian Chesky has deliberately stayed away from a chatbot-like interface. At Skift Global Forum last week, he also put a date on the bigger ambition: “Next year we will launch our agent”, with an interface he described as much richer than a chatbot. In the meantime, Airbnb seems to treat ChatGPT and Muse as distribution channels that send it traffic. Chesky did call AI an existential risk in the same conversation, so he’s well aware of the fact that AI may not be unalloyed good for Airbnb.

Both companies are understandably trying to defend the interface. However, my concern is that the vertical specific agents they build cannot be neutral. DoorDash’s agent is never going to tell me the same burrito bowl is cheaper on Uber Eats, and Airbnb’s agent is never going to check whether the same listing is available at cheaper price on Vrbo, Booking, or the host’s own website. A general purpose consumer agent has no such constraint. As I showed earlier, I can give Muse a standing instruction to always check whether there is a cheaper way to book something, and it will do so without being asked again. A vertical agent may well have a better interface, but a general agent is far more likely to be my advocate across all of them. If consumers come to value the latter, it can be structurally challenging for vertical specific company agents to gain trust that the agent is actually prioritizing customer’s interest.

This is where Meta’s monetization posture becomes quite interesting. At launch, Axios reported there is no advertising within Muse, with Alexandr Wang saying the company is exploring commerce opportunities instead. At Connect, Zuckerberg reportedly did not utter the word “advertising” even once in his keynote. What he did say is that Muse will remain free for a large number of tokens, and that over time “we will profit by taking a small fee from transactions”. The fee would reportedly come from merchants rather than users, but its size and mechanics remain undisclosed.

My hypothesis is that the near-term product Meta is trying to nail is trust. That is, of course, bit of a tall ask for Meta given there does seem to be widespread lack of trust on the company. It is, however, interesting to see that Muse has gained so much hype despite the trust deficit company typically suffers. It is still early days, but there is indeed a strong likelihood that trust may become much more important once users start using these agents at scale and people can understandably have a strong preference for agents that want to do things that are simply in the interest of the users.

But can Meta really scale Muse without inserting ads eventually? Most investors I talk to seem to believe ads are almost inevitable in Muse. I am not so sure. If trust is the decisive advantage over vertical specific agents, I believe there is a high likelihood that we may never see ads in Muse.

If I am going to hand over my emails, logins, and payment credentials to an agent, I need to believe it is working for me and not for the highest bidder. “No ads” is a very strong counter-position, not least against Meta’s own history. Indeed, one would imagine Meta to be the last company on earth to not want to insert ads, but strategically it makes so much sense to me to shun ads on Muse altogether. First of all, it will create a real problem for everyone else entering this space. If Meta sets the norm that a trustworthy personal agent does not carry ads, anyone who needs ads to fund their agent starts to look compromised by comparison, and very few competitors have an ad engine elsewhere to subsidize such a generous free tier. Meta can afford to wait. If Muse becomes the aggregator of aggregators a couple of years down the line, Meta would be in a position to ask for some take rate on much of the economic value flowing through it.

There are a few predictable objections to this thesis that I have been thinking about. The first is that a merchant-paid fee is itself an incentive, so Muse is not truly neutral. I don’t find this too troubling. If every merchant pays whenever a transaction goes through Muse, then Muse should be mostly indifferent to which merchant wins, much like a card network.

Another objection is access. As mentioned earlier, Amazon has blocked Muse. An agent can only shop where it is allowed to, and that is probably the strongest card the app layer still holds. But Meta has since added Walmart, Best Buy, Gap, Sephora, and Wayfair among others, on top of access to Shopify’s catalog. The bet seems to be that if Meta can aggregate enough demand, the holdouts will eventually feel it. For Amazon, the trade-off is asymmetric in timing. Letting agents in threatens its high-margin ad business right away whereas staying out costs volume only gradually. So, holding out is probably rational today. But logistics is a fixed asset business in which utilization matters a great deal. If Muse remains the dominant consumer agent and more and more orders flow to Walmart and other partners, the calculus on week 100 may look quite different from week one post-Muse launch. In any case, Amazon is highly likely to be anomaly than a norm. Very few companies are as dominant as Amazon is in their vertical, so if one holds out, that demand can be easily diverted to someone who is willing to play ball with Muse.

Perhaps most importantly, “no ads” on Muse may cost Meta far less than it seems at first glance. Meta’s blog post on “How We Built Safety Into Muse” has laid out how Meta may indirectly benefit even if Muse never shares my data directly with Meta’s ad system. From the post:

Muse doesn’t share your conversations or the data in your Virtual Machine with Meta ad systems. That said, there are some legitimate scenarios where how you use Muse can influence the ads you see. When Muse browses the internet, it will appear as your activity, so if you ask Muse to buy a shirt from a clothing designer’s website, that designer might use your visit to show you an ad on Instagram. Similarly, if Muse makes a restaurant reservation for you or helps you find a great product on Facebook Marketplace, that may also indirectly influence the ads you see.

Given this context, I have a strong suspicion that Meta may never feel the need to insert ads inside Muse. In fact, the more I think about it, the more this looks to me like an underappreciated advantage. If an agent’s browsing can inform the ads I see elsewhere, Meta may be one of the very few companies that can monetize a personal agent through advertising without ever showing an ad inside the agent itself. The loop requires two things: a tag on the merchant’s website that registers the visit, and a large owned surface elsewhere on which to serve the resulting ad. Startups such as Instinct has neither. ChatGPT does have an ads business, but its only inventory is ChatGPT itself and its targeting draws on the conversation, which is exactly the trade-off Meta is positioning Muse against. Google is the one company that could replicate the loop given its reach across Search, YouTube, Gmail, and its display network, but an agent that completes the purchase likely replaces the very commercial query Google monetizes best. For Meta, which has always had to infer intent rather than observe it, every Muse errand can be incremental signal. This gives Muse an unusual ability to remain ad-free: Meta can keep ads out of the Muse app and still get paid for it on Facebook and Instagram, which makes delaying direct monetization far cheaper for Meta than for almost anyone else. This also means the indirect monetization of Muse is already happening right now while the direct monetization via transaction take rates can wait until enough demand has been aggregated.

As of today, I still find the apps to be a better experience than asking an agent, so I don’t want to overstate the near-term threat. Building their own agents seems necessary for the vertical specific companies, but I suspect it may not be sufficient for vast majority of them given their structural nepotism towards their own inventories. The key question is perhaps whether consumers eventually want one agent per app or one agent for almost everything that will have a lot more context and data about their lives, interests, and preferences than a vertical agent will ever have. It’s early days, so I wouldn’t want to have a rigid opinion, but Meta has a real shot at aggregating the aggregators.

What looks promising?

Organize. Group ideas by semantic research direction, even when they come from different generation lineages. Rebuild the map as the pool grows.

Estimate. Rank clusters and unevaluated ideas using observed scores, evidence gaps, novelty, and implementation lessons. Ordinal ranks express relative promise—not calibrated reward predictions.

pplx-decider-v1-27b

pplx-decider-v1-27b is a decision model fine-tuned from Qwen3.8-27B.

Accuracy across 11 benchmarks. The pplx-decider-v1-27b results were measured through the Perplexity API.

Bold marks the best score in each row.

Usage

Python 3.12+ and a CUDA GPU with room for approximately 49 GiB of weights plus working memory.

Download and run the inference example with uv:

uvx --from huggingface-hub hf download perplexity-ai/pplx-decider-v1-27b inference.py --local-dir .
uv run inference.py

uv installs the dependencies; the script downloads the model from Hugging Face. In an environment with these dependencies installed, use Decider directly:

from inference import Decider

model = Decider.from_pretrained("perplexity-ai/pplx-decider-v1-27b")
result = model.predict(
    "My Stripe integration keeps failing. Please help ASAP.",
    {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
            "billing": "Charges and refunds",
            "technical_support": "Integration errors",
            "sales": "Questions about buying a product",
        },
    },
)
print(result)  # Selected choice and calibrated probabilities.

Use {"type": "noul", "instructions": "Does this message express urgency?"} for a yes/no probability. For images, pass images=["screenshot.png"] to predict, or run:

uv run inference.py --image screenshot.png

The Waymo effect: how AI is quietly making research less collaborative

How frictionless technologies teach us to prefer our own company – and why research leaders should worry.

On a recent trip to San Francisco I did the thing that every visitor to San Francisco now does: I summoned a car with no one in it.

The Waymo arrived with the serene confidence of a machine that has never once worried about where to find parking, and I climbed into the back seat, glanced instinctively at the driver’s seat to say hello, and found myself nodding politely at an empty chair. The steering wheel turned itself. I have spent a reasonable portion of my life thinking about counterintuitive aspects of physics, but that did not help me with the mild existential vertigo of watching a steering wheel moving on its own – an unseen driver responsible for my safety.

I was in San Francisco, in part, to spend time with Susan Winslow, CEO of Macmillan Learning. We are colleagues within the Holtzbrinck group, and we had come together for the most human of professional reasons: to collaborate. To sit in the same room, compare notes on how AI is reshaping our respective corners of research and education, and do the kind of thinking that is stubbornly difficult to do over video calls.

And yet, comparing notes on our Waymo experiences, we discovered we agreed on something else entirely: the rides were wonderful. As two self-confessed introverts, we had each found the driverless car to be a small oasis. No obligation to make conversation. No silent negotiation over the radio. A guilt-free space to be alone with one's thoughts, finish an email, or take a call en route without the awkwardness about conducting it in front of a stranger. The car was quiet, smooth and entirely undemanding.

It took us slightly longer to name what we had lost. Two people who had crossed continents to talk to each other were quietly delighted by a technology whose central feature is that you don’t have to talk to anyone.

Naming the Waymo effect

Let me attempt a definition: the Waymo effect is what happens when a technology removes the friction of dealing with another human being, and we experience that removal as pure gain – because the costs of the friction were always visible to us, while its benefits were not.

This is a familiar move for anyone who has read Tim Wu on “the tyranny of convenience” – his argument that once a frictionless option exists, we take it by default, and quietly surrender whatever the friction was doing for us, since nobody advertised it as valuable in the first place. Albert Borgmann’s related idea of the device paradigm goes a step further: a device delivers a commodity – warmth, information, companionship – while concealing the practice that once had to be undertaken to earn it, so that we stop noticing the practice has gone at all. Only the commodity keeps arriving.

The costs of talking to a taxi driver are obvious: the small effort of politeness, the conversational roulette, the introvert’s tax of sustained small talk at 7am. The benefits are diffuse and deferred: the driver was, for many of us on many days, the last stranger we were obliged to encounter. The last person from outside our bubble – professionally, politically, socially – with whom we had an unchosen conversation. The last reliable source of a view we did not ask for.

Neither Susan nor I would design a world without those conversations. We simply enjoyed opting out of this one. And that, of course, is how such things are lost: never by decision, always by convenience. One comfortable ride at a time.

I should be clear that this is not an anti-Waymo article (the rides really were excellent, and I would take one again without hesitation – that is rather the point). It is an article about research. Because the same logic that removed the driver from the car is now, with equal serenity and considerably greater consequence, removing the collaborator from the research process.

The frictionless colleague

Large language models are the Waymo of intellectual life.

Consider the comparison honestly, as a researcher experiences it. A collaborator is available occasionally, between teaching commitments, grant deadlines and time zones; an LLM is available at 2am on a Sunday, which – let us not pretend otherwise – is when a worrying amount of research thinking actually happens. A collaborator arrives with their own agenda, their own framing of the problem, their own inconvenient conviction that your central assumption is wrong; an LLM arrives with no agenda beyond being useful to you. A collaborator must be persuaded; an LLM must merely be prompted. A collaborator will challenge you in ways you did not ask for and had not thought of; an LLM will challenge you precisely as robustly as you request – and not one degree more. If you ask it to critique your argument, it will do so, capably. But it will critique the argument you brought. It will not, unbidden, tell you that you are solving the wrong problem, that a rival group tried this in 2019 and abandoned it, or that your beautiful theoretical framing collapses on contact with the messy realities of someone else’s field.

The collaborator’s inconvenience, in other words, is not a bug in the collaboration; it largely is the collaboration. The value of another mind lies exactly in the ways it refuses to be an extension of your own.

And beyond challenge and serendipity lies something more fundamental still. Research is not merely a production function that converts ideas into papers. It is a community of practice – a social fabric maintained through argument, apprenticeship, conference-bar conversations, the shared ordeal of a difficult referee report. That fabric is woven from precisely the frictions we are now engineering away. Every conversation redirected from a colleague to a chatbot is a thread quietly withdrawn. No individual thread matters. The fabric does. There is a word for what happens when this proceeds at scale, and I propose we use it: decollaboration.

The incentive trap

If this were only a matter of individual temptation, it would be a subject for self-discipline and the occasional stern editorial. But it is not. The uncomfortable truth for research leaders, funders and institutions is that we have built an incentive system that makes decollaboration the rational choice – and we are busily making it more rational by the year.

Collaboration has always been expensive. It costs travel and scheduling and the glacial work of building trust. It costs ego management and compromise and the periodic small heartbreak of the author-order negotiation. Publish-or-perish has always taxed these expenses, because every hour spent aligning with a co-author is an hour not spent producing output that is legible to an evaluation system. But three forces are now compounding.

First, funding pressure. When budgets tighten, the first casualties are always the line items whose value is real but unmeasurable: travel, workshops, sabbaticals, visiting positions – the entire physical infrastructure of serendipity. We defund the corridor and then wonder where the corridor conversations went.

Second, velocity worship. Our evaluation systems – whatever DORA-shaped statements adorn our websites – still reward output and speed of output. And LLMs promise speed above all things. They whisper that the literature review can be done by Friday, that the draft can exist by Monday. To a researcher whose next position depends on the length of a publication list, this is not a whisper that is easy to ignore.

Third, and most seductively: the LLM never argues about author order. It has no ego to manage, no competing agenda, no rival claim on the credit. In a system where credit is the currency of survival, a brilliant interlocutor who demands no share of the credit is not merely convenient. It is arbitrage.

The research on research should give us pause here. We know from the team-science literature that small teams tend to disrupt while large teams develop, and that it is the unexpected combinations of collaborators – the atypical pairings across fields and institutions – that disproportionately produce the most novel work. Meanwhile, the early evidence on generative AI points in a direction that should sound familiar: individual productivity rises while the diversity of ideas narrows, everyone moving faster along increasingly similar paths. We are, in effect, running an uncontrolled global experiment in trading serendipity for throughput – and the incentive structures we have built are the experimental apparatus.

Writing is thinking

There is a deeper cost still, and it concerns the thing LLMs do most impressively: writing.

Part of the lure of these tools is the impression of speed. And it is worth being precise about why that impression is partly an illusion. Writing takes time because thinking takes time; the two are not separable activities that happen to occur in sequence. The value of writing a paper was never really the artefact – it was the forcing function. Writing is where we discover that the argument we were sure of has a hole in section three; where a vague intuition either becomes a precise claim or dissolves under the pressure of having to be one. High-quality ideas are slow to generate, and historically much of that slow generation happened between people: at the whiteboard, in the corridor, in the productive irritation of a co-author’s tracked changes.

Cognitive psychologists have a name for this kind of productive friction: Robert Bjork’s desirable difficulties – the finding that certain frictions in learning and thinking, effortful retrieval, delayed feedback, the struggle to get an idea onto the page in your own words, are not obstacles to durable understanding but the mechanism of it. Remove the difficulty for the sake of comfort, and you do not get the same understanding faster. You get less of it, delivered more smoothly.

Outsource the writing and you have not accelerated the thinking; you have skipped it. And the trap deepens as the models improve, because their output becomes steadily better – more fluent, more structured, less and less distinguishable from educated human prose. The temptation grows precisely as the tell-tale signs shrink. As a physicist, I am reminded of PT-symmetric quantum systems, which have the disconcerting property of behaving entirely normally right up until a hidden symmetry breaks – at which point everything changes at once. A research culture can look healthy by every visible measure – outputs up, turnaround down, prose immaculate – while the invisible thing that sustained it quietly falls below threshold. By the time the symptom appears in the metrics, the cause is years in the past.

Pilots and passengers

None of this is an argument for banning the tools. That would fail, and it would deserve to fail, because the promise is genuine. In a March 2026 Nature comment, Dashun Wang extends Steve Jobs’s famous description of the computer as “a bicycle for our minds”, proposing that AI agents are aeroplanes for the mind: faster and more powerful than the bicycle, harder to control, costlier when they crash. He is right about the upside, and it is considerable. When AI collapses the cost of failure, riskier and more ambitious questions become rational to ask; when it collapses the cost of analysis, small labs and lone newcomers can attempt what once required armies. Used well, these tools genuinely extend research – and, done properly, agentic systems could even strengthen one of science’s weakest joints, reproducibility, by making every analytical step loggable and replayable.

But notice what even the optimists insist upon. Wang’s prescription is what he calls pilot-in-command science: the researcher as captain, the agents as crew – an analyst to draft, a critic to probe, a planner to map next steps – with the human retaining authority over the question, the path and the conclusions. Even the most enthusiastic architects of AI-assisted discovery, in other words, are adamant that there must be someone in the front seat. And Wang arrives at the Waymo effect worry from the other direction: he warns that while AI may raise an individual’s performance, it risks reducing collective diversity, with outputs converging unless we deliberately counteract it – and that just as our collaborators shape us in profound and unexpected ways, so too will our agents. His remedy is to design for dissent and cultivate many models that think differently. Which is to say: having removed the friction, we must now engineer it back in.

This is an old worry wearing new clothes. In 1983, the psychologist Lisanne Bainbridge described the ironies of automation: the more reliably a system runs on its own, the less practice its human overseer gets at the very skill they are being kept in the loop to exercise in an emergency, so that competence quietly erodes precisely because it is needed only rarely, and always at the worst moment. Swap “pilot” for “researcher” and “autopilot” for “agent”, and the mechanism Wang is guarding against is the one Bainbridge named four decades earlier.

The problem, then, is not the technology. The problem is that we have made the human conversation the expensive option and the machine conversation free, and we are surprised at what researchers, responding rationally, then choose.

Fund the friction

So the responsibility falls where the incentives are made. Funders and institutions should recognise collaboration for what it is – not a nice-to-have, but a form of infrastructure – and price it accordingly.

Fund the friction: the workshops, the visits, the co-location, the unstructured time that produces the conversations nobody could have scheduled. Evaluate contribution rather than velocity, and mean it. Treat “who did you think with?” as a question worthy of the same seriousness as “what did you publish?”

And perhaps, in an age when a machine can produce any number of competent papers, we should notice that the scarce and valuable thing has inverted: the output is becoming cheap, and it is the thinking together that is becoming precious.

The return journey

Susan and I got where we were going. The car was smooth, the silence was comfortable, and the collaboration for which we had each crossed an ocean and a continent happened – not in the frictionless capsule, but in the inefficient, unscheduled, thoroughly human hours that followed it: the conversations that wandered, the disagreements neither of us had planned, the ideas that neither of us brought to San Francisco because they did not exist until we were in the same room.

That, in the end, is the Waymo effect in full: the ride is delightful, the destination is reached, and it is only if you glance up front that you notice what is missing. Wang calls for pilot-in-command science; the quiet risk is that our incentives are training us for passenger-in-comfort science instead.

Research is now climbing into the back seat. The ride will be smooth. The output will arrive. The question that research leaders should be asking – before we have all had a few more years of comfortable rides – is a simple one: who is in the front seat? And when did we stop noticing that nobody was driving?

Starlink is laying the groundwork to offer hourly, daily, and weekly passes for its satellite internet service as part of a “Community” program that quietly emerged last year.

SpaceX has published a new site about “Starlink for communities,” and it’s apparently recruiting people to join as “hosts,” who would sell passes to interested consumers. “One Starlink Kit delivers high-speed internet to multiple users nearby. Neighbors pay for flexible hour, day, week, or month passes — and you earn from every connection,” the site says.

The program appears to be part of the Starlink Community option mentioned on a support page for authorized resellers and enterprise customers last year. At the time, SpaceX talked about offering monthly passes through the shared community access, but it's unclear if the company ever rolled it out.

The new site suggests SpaceX is working to build a reseller network for the Community program. The page also mentions a greater range of options, including an “Hour Pass,” “Day Pass,” “Week Pass,” and “Month Pass.” However, no pricing is listed.

“Starlink takes care of payments, user access, and connectivity. You focus on setting up your site and earning from connections,” the site adds.

SpaceX didn’t respond to a request for comment, leaving unclear where the company will offer the Community program and whether it'll be exclusive to certain markets. But the result could make Starlink even more affordable, especially for low-income markets. The nonprofit unconnected.org previously told PCMag that some underserved communities already offer short-term internet passes for broadband, including Starlink, as part of their “sachet economy.”

The Community offering could also help Starlink grow its customer base. In Q2, the satellite internet service reached 12 million paid subscriptions, with consumer revenue of $2.4 billion, up from $1.7 billion year over year.

For now, the "Starlink Community Beta Interest Form" appears to be accepting applications from dozens of countries, including the US, Mexico, and Canada, where Starlink is already available. The form also asks “How many Starlink Community sites would you be interested in setting up?” and “What price do you think users would be willing to pay for that pass?”

The de-facto duopoly in stablecoins today is made by USDC and USDT: both USD-pegged and both representing two different versions of a tokenised dollar.

Even though the non-USD pegged (or local) stablecoins are a tiny part of the market, I’m convinced that they represent the biggest opportunity in today’s stablecoin market not because they will replace the dollar on-chain, but because the dollar on-chain is the offshore layer of a system that still has no domestic layer, and every economy on earth runs on its domestic layer.

I already hinted at the importance of local stablecoins in my previous series on the Stablecoin sandwich, but I believe the topic deserves a proper space.

The goal of this post is to explore the local stablecoins space, analyse the state of local stablecoins and argue in favour of my thesis on the inevitability of local stablecoins.

State of Local Stablecoins

Looking at the surface, the future for non-USD pegged stablecoins seems pretty grim.

As of today, USD pegged stablecoins have the overwhelming majority of the stablecoin market: according to DeFilama data, USD-pegged stablecoins account for over 99% of the stablecoins market cap ($303b out of $305b in total) and the first non-USD pegged stablecoin (EURC) is the 24th biggest stablecoin in circulation and is ~400x smaller than the biggest USD-pegged one (USDT).

However, looking beyond the tagline, the story is a bit different. The penetration of non-USD stablecoin has grown from basically 0 to more than 0.5%.

The growth of local stablecoins over the last 20 months (from January 2025) has been around 4x (from $379m to $1.6b) versus a 50% growth of the USD-pegged segment (from $204B to $303B) – even though absolute volumes are really different. On the velocity side, numbers are even more interesting: transfer volume increased 16x, while supply grew only 4x.

In addition, most of the local stablecoins have a real world usage and a low DeFi penetration – signaling an organic adoption less exposed to predatory capital and incentives schemes. Excluding EURC – 80% of the local stablecoin activity are simple transfers consistent with payments, remittances, payroll, and treasury flows.

Why local stablecoins are inevitable

Looking at the numbers, the local stablecoin growth seems solid, even though absolute numbers are still tiny. But I’m convinced that a number of factors will facilitate an exponential growth of the local stablecoin space over the next few years.

De-Dollarisation and convergence to TradFi volumes
Even though the Dedollarisation narrative is still a narrative and not a fact, it is undeniable that the US Dollar has lost part of its appeal as a Central banks’ reserve currency, declining from more than 65% 10 years ago to ~57% today.

On the other hand, as shown by SWIFT data, International payments (excluding the intrapayments in the Eurozone) denominated in US Dollars have grown from 42% in 2020 to 59% in 2026.

The goal of this post is not to dig deeper into the phenomenon of De-dollarisation, but – for the purpose of my thesis – it is safe to assume that there is no dollarisation in action. Basically the world is not unequivocally adopting more and more of the US Dollar, in some use cases it is, in others the other way around.

Given this – if stablecoins want to become the new backbone of the financial system – the mix of volumes passing on them will have to converge to those of traditional finance. In order to make this happen, local stablecoins will have to grow orders of magnitude faster than USD-pegged stablecoins.

Monetary policy instrument
A currency is much more than a payment instrument or a store of value tool. A currency is one of the most important tools a country possesses to influence its economy, and thus the real fabric of its social texture. A country that doesn’t control its currency is a lame duck and it’s severely affected in its ability to stimulate the economy – this is a very active discussion in the Eurozone.

So far, countries have tolerated USD-pegged stablecoins because they were overall a limited phenomenon, not systemic. But there are very few doubts that, in case USDT or USDC adoption gets to the point of taking over a country’s economy, a form of currency control will be extended to them. This is less likely in semi-dollarised economies, but it is almost certain in jurisdictions that managed to keep the level of USD usage under control.

Geopolitical Risk
In parallel with the monetary policy argument, another political argument emerges. In an increasingly confrontational and fractured world, adopting a foreign country’s currency strongly limits the foreign policy freedom of a nation state. If another country holds the switch button on the backbone of your economy, you are not free.

Ultimately, a USD stablecoin is not just a tokenised dollar. It is a tokenised dollar issued by an entity that answers to OFAC, the sanctions arm of the United States Treasury Department.

In this sense, given their user-friendly and widespread accessibility, stablecoins represent a multiplier of the financial sanctions system already widely used by the US administration against Iran, Russia and other geopolitical adversaries.

And this is actually explicitly defined by the GENIUS Act. The new crypto legal framework requires every permitted issuer to have the technical capability to seize, freeze or burn tokens and to comply with lawful orders. Freezability is now written into US law as a design requirement of the dollar on-chain.

MiCA has an explicit article that wants to avoid similar traps: Article 23 forces an issuer to stop issuing once a token is used as a means of exchange above one million transactions or €200m per day within a single currency area, and Article 58 extends that to e-money tokens referencing a non-EU currency.

Local distribution
Payment demand is local by definition: salaries, rents, taxes, groceries and invoices are denominated in the currency of the jurisdiction. The dollar-savings demand that drove USDT adoption in Argentina, Turkey or Nigeria is real, but it is mainly a store-of-value use case, not a payments one.

Payments are also local in a second, more practical sense: the ramps are local. Every on-ramp and off-ramp is a bank account, a local instant payment scheme, a licence and a KYC file. The moment a stablecoin touches the real economy, it touches one of these systems, through an entity that is licensed locally. These entities that own local customers are not crypto companies. They are the banks, neobanks and PSPs that already hold the licence, the deposits and the payment-scheme membership. Those players have no reason to hand their base to Circle/Tether in exchange for a share of Treasury yield when they can issue, or white-label, a token in the currency their customers are already paid in and keep the economics. Stripe bought Bridge rather than partnering with Circle for the same reason.

So for stablecoins to become the financial rails of an economy, they must be in the unit of account of the flows, and the people best placed to distribute them have every incentive to make them so. They must be local stablecoins, and they will be issued by the players who are already local.

Conclusions

The post has presented a number of arguments which I believe push towards a wide adoption of local stablecoins: the convergence of stablecoin mix to the currency mix of the real economy; the protective measures that states will implement to preserve their monetary policy toolkit; the geopolitical risk of fully adopting USD-pegged stablecoins and the fact that real economy use cases create an organic demand for local stablecoins.

Looking at the market I think a few elements confirm my thesis.

The first is that the use cases already on the table need it. In the stablecoin sandwich series I described the local leg as the part of the flow that stablecoins do not fix: the fiat on-ramp on one side, the fiat off-ramp on the other, each with its own bank, its own FX and its own reconciliation. A local stablecoin does not shorten that leg, it removes it. The sandwich only closes when both slices are tokens, and the second slice is, by construction, local.

Another key element is that regulation is manufacturing supply. The launch of MiCA in the European Union boosted the EUR-pegged stablecoins adoption and this is probably going to happen also in other jurisdictions.

The last one is an historical analogy: the Eurodollar market grew into the largest pool of money in the world, and it never displaced domestic currency for domestic payments anywhere. It served offshore and cross-border demand but every domestic economy kept running on its own money, on its own rails, under its own central bank. I have argued before that USDT is the tokenised Eurodollar. If that is right, then the honest shape of the future is not local stablecoins replacing the dollar, rather it is a two-layer system: USDT and USDC as the offshore layer, and a domestic layer for each currency that matters. The offshore layer is built. The domestic layer is the thing that is currently missing.

This is why I think this is the biggest opportunity in the market. Not because 0.5% will become 50%, but because the dollar layer is complete and the local layer has barely started, and every argument in this post says it has to be built. The only open question is who builds it: the incumbents that already own the distribution, or someone who moves first.

The potential deal will help Anthropic and other companies access chips and other key infrastructure.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Reducing the cognitive load of AI changes

When reviewing large amounts of AI-generated code, I often find that the LLM chooses terms for abstractions that do not always map to my own choices. For instance, what it may call a MutationIntent might personally be more natural to me as an EditRequest. Because the LLM's choice of words is not my ideal choice, I have to do a mental lookup of what it means every time I see it, which adds cognitive load.

This may seem like a small friction, but the cognitive load accumulates when considering how dozens of new terms interact in unfamiliar code. I can only hold a finite number of these semantic lookups in my head before I start misinterpreting how things work.

To minimize this, before review, I post-process AI changes with this prompt:

Please review the changes and extract any unconventional or bespoke terms used for abstract objects, processes and concepts. Create a temporary markdown file with each term, its meaning and why it was chosen, and some proposed alternative terms for it. I will then use this markdown file to confirm the term choice or to provide my own custom term. You will then incorporate any changes. The goal here is to map your language choices to my own language choices so that I can understand the concepts more easily.

I then go through and confirm term choices. The AI does find-and-replace everywhere, including documentation. The resulting code is much easier to review because now it's written more like it came from my brain.

Tempo 3.1 adds community-contributed improvements for Kafka ingestion, including TLS support and options to reduce data transfer costs.

Instagram announced on Wednesday that it’s bringing an AI video assistant tool to Edits, its CapCut competitor.

This conversational AI chatbot is intended to provide personalized feedback to creators, rather than generic advice.

“The assistant knows your account’s Instagram metrics, things like follows, views, video retention, likes, shares and combines them with your comments, what’s trending on Instagram and what your audience is into,” Brett Westervelt, who leads the Edits app, said. “It can spot patterns in your performance over time and surface actionable insights that are hard to see from the metrics alone.”

Westervelt added that Edits worked closely with a group of creators in developing the tool.

“One thing we heard consistently: creators want a tool that handles the analysis, not one that does the creative work for them,” he wrote. “Edits assistant does the digging for you. The creative calls are still yours.”

Meta first previewed the Edits AI assistant in June at an invite-only creator event, where it also said it was working on an Edits desktop app. It’s not the only company working on tools like this, though. YouTube announced last week that it is also working on a conversational video editing tool, which should be available early next year.

From what we can tell so far, it looks like Meta is taking a more analytics-driven approach with its AI assistant than YouTube, which suggested creators would use its AI to help with the actual editing process.

Creators will have a limit to how much they can use the AI tool, but they can unlock more usage with a Meta One subscription.

Apple CEO John Ternus reportedly wants a leaner organization focused on engineering, with fewer management layers and more frequent product releases. Apple has dismissed some engineering program managers, while Ternus is considering a less seasonal launch schedule and more experimental products. The plans also include growing services revenue through new offerings and existing products.

Visual inconsistency gets the attention, but spatial incoherence is often worse, as products expand past the simple floor plan they launched with. Slack's pile of added features and Substack's inconsistent reader and publisher navigation show the problem, while YouTube's clearly scoped menus make shifts easy to map. Overlays that misrepresented an action's scope were one reason Shopify deprecated its Polaris Sheet component, forcing a rethink of the admin's floor plan.

Connect Claude, ChatGPT, Cursor, or any MCP client to Imejis, and it creates, edits, and exports real designs on its own. No screenshots, no separate design tool.

Full article content is not available for inline reading.

Read the original article →

I recently crossed more than 10,000 hours working independently. Malcolm Gladwell would be proud. I’m not sure I’ve mastered it quite yet, but I’ve spent enough time doing it to understand what works for me. Here’s 5 lessons I wish I knew when I started:

Start with what gives you energy

Before thinking about rates, clients, or whether you can make a living independently, start with a more basic question: are you happy with the way you work today? If the answer is yes, great. If it isn’t, try to understand the source of that discontent. Pay attention to what gives you energy, what drains it, and which parts of the job you find yourself wanting more of.

After spending a couple of decades across big tech companies and early-stage startups, I started to feel stuck. I had all this energy, but trying to direct it within a single team often led to friction. As an IC, my scope was limited and I had to move at the pace of the team. The other option was management, but that meant stepping further away from the work itself, which never felt satisfying. I felt undervalued, like I had more to give than what I was being asked to do. Over time, the disconnect grew. I was still doing the work, but I wasn’t really connected to it anymore.

The real turning point came when I had my first child. I didn’t want him growing up seeing a dad who clocked in mindlessly to work every day. I wanted him to grow up with a dad that was passionate about the reason he got up and went to work every day. I wanted him to feel inspired by seeing me spending my time on something that energized me, so that he could find what energizes him and pursue it.

For a while, I thought the answer might be starting my own company. After doing a lot of digging, I couldn't find a problem I felt willing to dedicate a decade of my life to. When I looked closer, I realized it wasn’t the problem that drew me in, it was the stage. That early stretch when it’s just a few people in a room trying to make sense of something new, shaping it from rough insight into form. That’s the part I loved. So instead of repeating the cycle of starting something new only to grow disillusioned as it scaled, I started to wonder: what if the company I built focused only on the early stage? What if that magic didn’t have to be a stepping stone, but the whole point?

Test before you leap

Once I had a clearer idea of the kind of work I wanted, the next question was whether I could actually make a living doing it.

The rule of thumb I kept hearing was that independent work should earn roughly twice what you’d make in-house, accounting for the instability and benefits you now have to cover yourself. That number felt daunting, but it gave me something concrete to test against.

So I started small.

I eased into it by moonlighting. I took on contract work during nights and weekends, saving money, and treating “boring” projects as a way to hone my process. That gave me the confidence to take on more work, experiment with pricing, and find my rhythm.

My first client came from a former hiring manager who reached out asking if I knew anyone available for a contract role. Others followed through referrals, especially from other designers who knew I was exploring contract work.

Once I had saved about three months of expenses, roughly the amount of time I figured it would take me to find another full-time job, I redesigned my website around my new direction, gave my two weeks’ notice, and announced the new venture publicly. That put me on the radar of founders and friends of founders looking for design help

By the time I quit, going independent felt less like a leap of faith and more like following the evidence. I knew there was demand, I had some idea of what people would pay me, and I had enough savings to give myself time to figure out the rest.

Say yes before you learn to say no

In the beginning, my goal was to take on as much work as possible. I wanted to understand how much demand was out there and develop a design offering that matched it. That meant taking on plenty of unsexy work, the kind of projects I probably wouldn’t take today.

It also gave me something I had been craving: exposure to a huge range of problems and opportunities to stretch creatively. I designed for an insurance company, a healthcare startup, a VC firm, and many more. I worked across desktop, mobile, and custom hardware. I designed business dashboards, consumer feeds, booking systems, software products, and brands. I facilitated design sprints. It was an incredibly stimulating period that helped me understand where my skills and interests were most valuable.

When it comes to saying no, the truth is simple: if you need the money, you say yes. That’s how you build stability. As that stability grows, so does your ability to be selective. You can start evaluating work based on the team, the problem, the stage, or the kind of relationship you want to have with a client.

Over time, all those yeses helped me find the intersection between what I was good at, what I enjoyed doing, and what people were willing to pay me for. That’s when saying no became useful.

Let the clients you want shape your pricing

I spent a lot of time trying to find the “right” way to price design work. The conventional wisdom is to avoid charging for time, but beyond that I experimented with weekly retainers, project fees, and different rates. Some were too low. Some were probably too high.

Eventually I realized there was a client for almost every pricing model. So I stopped asking what I should charge and started asking a more useful question: what kind of client did I want my pricing to attract?

I prefer some flexibility in how I structure compensation. I typically start with an all-cash rate, with the option to trade some cash for equity when it makes sense for both sides. This gives us room to align incentives around the long-term success of the product while structuring each engagement around the partnership.

Make it easy to start

I start most engagements with a couple of weeks dedicated to a well-scoped project. It’s enough time for both sides to experience the relationship rather than speculate about it. Does the client get what they need from me? Do I enjoy working with them? Are we excited about where the product is going?

A short initial engagement also makes a high weekly rate easier to evaluate. Rather than asking a client to make a long-term commitment upfront, they can see the work, experience the pace, and decide whether the value makes sense for them. I like the pressure that creates. It keeps me sharp and gives the relationship something concrete to build from. So far, every client I’ve started this way has chosen to continue working together.

Ten thousand hours in, my practice looks very different from the one I started with. Every client, project, and experiment has helped me understand what I’m good at, what gives me energy, and where those things are valuable to others.

That’s ultimately the opportunity of working independently. You get to keep shaping the practice as you learn. There’s no template to follow. There’s just the version that works for you.

Personal Computing 2.0 envisions a future where users regain control over their data, fostering privacy and customization in computing environments.

Asha Sharma, the 38-year-old chief executive of Microsoft's Xbox division, wants Xbox properties to entertain a billion people. This means opening untapped markets in Africa, Latin America, and South Asia by using cloud computing technology to run games on computers and smartphones. Another pillar of her strategy is to reinvest in Minecraft as a competitor to Roblox. Leaders at the company describe the future of its consoles as embodying that idea.

Mozilla is rolling out the Firefox 157 redesign to all desktop and mobile users, refreshing colors, icons, and themes across the browser without hurting performance. The update adds flexibility through a returning Compact Mode, a theme picker with new themes and wallpapers, and a customizable New Tab page with pinned shortcuts. Firefox remains independent and open source, with built-in privacy protections and user controls, including over AI features, since the redesign renews rather than reinvents it.

Vibecoders can keep AI-generated designs from looking like generic slop by learning to spot its telltale components, then applying one of three escalating fixes: cleaning up fluff with specific colors, fonts, and icons; defining an aesthetic through references; or designing from scratch in Figma. Since slop stems from generating artifacts without thought or effort, even a brief review forces reflection, and AI handles digital styles far better than organic, expressive ones. These levels suit one-off designs like dashboards and trivia decks, while fixing an entire product or brand would require agentic workflows and design systems.

Turn any screenshot or screen recording into a beautiful, share-ready image or video in seconds. Free, open source, and it runs entirely in your browser.

Murri's refreshed identity for RCD Espanyol de Barcelona preserves the soccer club's history while creating a more flexible visual system for modern applications. Custom Perico Type typography draws on Catalan poster traditions and the club's blue-and-white stripes, supported by graphic elements derived from its visual heritage. The system is designed to work consistently across stadium environments, digital platforms, merchandise, and communications while keeping the club's established identity recognizable.

Carved ice, molten bronze, and reclaimed foundry sand let industrial designer Steven Haulenbeek make furniture and lighting shaped by weather, gravity, heat, and chance.

After leaving London and cycling through South America, Louise French renewed her illustration practice, developing a playful style through drawing and the freedom to experiment.