TheDaily Front

Every organization has a mission, a reason for being. Organizations pass that mission — along with their terminology, procedures, systems, standards, and ways of working — to their people. People, in turn, take this context together with their own experience and work towards the mission.

Work can take many forms, from code, to documents and slides, to relationships, to outcomes in the physical world.

Some of these are straightforward: code either runs or it doesn’t. Agents have been using this feedback loop to produce code that “works” for developers over the last couple of years. But what about the rest of us?

Bringing the same leverage to the rest of the organization is a harder problem. Agents need to understand the context of the company and be able to reach the systems people use to do their jobs. They need to turn that context and access into work that moves the organization towards its mission.

That’s why we created Cloudflare OS. It gives every person an agent and workspace built around their company: how it works, what it knows, and the systems it relies on.

In May of this year, we gave every person at Cloudflare access to the first version of Cloudflare OS. Thousands of people across every function, many of them outside of engineering, use it every day to create documents and slides, automate repeatable tasks, and build small apps to visualize data and help them do their work.

Cloudflare OS also gave everyone a shared library of context and skills built by teams at Cloudflare. It captures our terminology, procedures, and best-known ways of doing recurring work as instructions an agent can follow. When one person figures out a better way to do something, everyone else can use it.

Today, we are open sourcing a new version of Cloudflare OS. Any organization can deploy it, connect it to internal systems, and make it their own.

What we learned from the first version

The Cloudflare OS we are open sourcing today is based on what we learned from running the first version internally, a journey our CIO, Sam Rhea, covers in his blog post.

The first version centered on individuals working with agents through private workspaces. Apps were static rather than live software connected to internal systems, and mostly deterministic jobs still required running an agent skill again and consuming more model tokens.

Collaboration exposed a more fundamental challenge. Access to an MCP server told us which tools an agent could call, but not which underlying resources the agent had observed. Once people began sharing workspaces, apps, and outputs, we needed to ensure that collaboration could not expose information someone was not permitted to see.

We rebuilt Cloudflare OS on a new foundation to solve these problems. Security had to be part of the platform, not something every person building an app or using an agent has to implement correctly.

The result is a platform designed to belong to the company running it. You can customize the interfaces, connect your tools, and add the skills and context that capture how your organization works.

Introducing Cloudflare OS

Cloudflare OS starts with a conversation in your browser, like many other AI tools. What makes it different is that each conversation is grounded in the context and skills your organization has curated. Give your workspace a goal, and it can draw on that knowledge and work with the tools and data your organization already uses to achieve it.

Cloudflare OS combines three parts:

• An agent workspace grounded in context and skills your company curates, with an isolated runtime where agents can write and run code.
• A new security and governance framework for safe access to internal data and services.
• A platform for personal, modifiable apps that people can build, share, and continue changing.

What begins as a conversation can become a doc, an app, or a workflow that continues doing the work.

An agent workspace for everyone in your company

Agent workspaces were designed for everyone in your organization to use. You interact with them in your browser, so you don’t have to be a developer or know how to use a terminal. 

A workspace combines agent sessions, persistent state, outputs and files, resource access, and an isolated runtime where the agent can write and run code.

They come loaded with the curated context and skills your team or company has collected. No more reinventing the wheel for every task — if someone on your team has figured out the best way to do something, everyone benefits. People no longer have to explain the same process, terminology, and best practices to a model every time they start a task.

A few things you can do:

Research and ask questions

Ask a workspace to research a topic using company context and the resources you make available to it. The agent can write code to search, filter, join, and analyze information instead of pulling an entire dataset into the model’s context window.

Create docs, slides, and spreadsheets

A workspace can turn its research into a document, presentation, or spreadsheet that you can continue editing. These outputs do not have to be static files. They can remain connected to live data, be updated as their sources change, and still be exported to familiar formats or services such as Google Drive.

Create collaborative, connected apps for your team

When a document or spreadsheet is not enough, the agent can build an app with its own interface, logic, and state. The app can use connected company resources and support multiple people working together.

Run deterministic workflows

Not every job needs a full agent session. Many are a known sequence of steps with one or two places where judgment is useful. A workspace can turn those jobs into mostly deterministic workflows, using code for the predictable steps and a model only where it adds value. Workflows can run on demand, on a schedule, or when an event occurs in a connected system.

Cloudflare OS gives agents and apps governed access to systems of record through Gatekeepers (more on this in the security section below). It also supports existing Model Context Protocol (MCP) servers your organization already uses via MCP Server Portals.

A new security and governance framework for safe access to internal data and services

As people begin experimenting with AI at work, one of their first requests is often for API keys to company systems. This makes sense: AI isn’t much use at work if it doesn’t have access to the systems people use to do their jobs.

But handing over API keys to people and agents is dangerous and does not scale. Keys often provide broad, long-lived access that is difficult to constrain, share safely, and audit.

MCP gives agents a better way to use these systems. An MCP server can hold the credential and expose a defined set of tools instead of handing the key directly to the agent. But controlling which tools an agent can call is only the first step. MCP alone does not tell us which underlying resources an agent has observed. The agent can combine information across systems, send it somewhere less restricted, or expose it through apps and outputs to people who may not be allowed to see the original resources. Authorization has to account for where the data can go next.

Agents start with no access

Cloudflare Access controls who can enter Cloudflare OS. Inside, every agent and app starts with access to nothing. An agent can ask for access to a specific resource, which you can grant or deny. Generated code receives that resource as a typed binding:

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

env.PROJECT is a capability representing permission to use a specific resource under a specific policy. The credential remains completely isolated from the agent and any generated code.

Server code runs in a Dynamic Worker with global outbound networking disabled. Client code runs in a sandboxed frame in the browser. Neither can reach the Internet except through capabilities you explicitly provide.

Gatekeepers govern resources and actions

A Gatekeeper is a service-specific Worker that sits between Cloudflare OS and an external service. It understands the service’s API, its resources, and the operations that can be performed on them.

Giving an agent access to your entire GitHub account is likely too broad. A Gatekeeper can give it access to a single repository, allow it to read issues but not source code, mask particular fields, apply rate limits, and require approval before merging a pull request.

The agent and its apps see a small TypeScript API. The Gatekeeper handles OAuth, holds the credential, enforces policy, records what was read, and mediates anything with an externally visible side effect.

Policy follows what the agent has seen

Controlling the initial read is not enough. Take, for example, the case where an agent reads a sensitive table in a data warehouse and uses it to produce a live dashboard. Sharing the dashboard must not become a way to share the table with people who could not access it directly.

Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work. When another person tries to open the workspace, interact with the agent, or view what it produced, Gatekeepers verify that person's access to the observed resources.

The same observation log is used to inform policies that determine when agents can make external requests. A read of sensitive data can prevent the agent from writing data to certain sources, inviting new collaborators, handing work to another agent, or making an outbound request.

People using agents or building apps do not have to worry about making these mistakes. The platform can now be used to handle this.

A platform for building and sharing personal, modifiable apps

Most productivity suites give you a fixed set of applications: documents, spreadsheets, and presentations. In Cloudflare OS, each “file” can be its own application, written by an agent for one person, one project, or one team.

These are not prototypes that you have to export and deploy somewhere else. Each one is a full-stack application with client code, server code, an API, and durable state. Apps are private by default, but can be shared like documents.

Every app is a Worker

When you ask your workspace to build an app, the agent writes two parts:

• Client code that renders the app’s UI in the browser
• Server code that stores state and implements the app’s behavior

The server is loaded on demand as a Dynamic Worker and instantiated as a Durable Object Facet (both are features we built for this project). The facet gives the app its own SQLite database, separate from the Cloudflare OS runtime managing it. Dynamic Workers use lightweight V8 isolates, so every app can have its own isolated runtime without needing a dedicated server or container sitting around.

The browser client talks to the server using Cap’n Web, Cloudflare’s open source object-capability Remote Procedure Call (RPC) system. A server method can be called from the client like a normal JavaScript function:

const issues = await app.listIssues({
 status: "done",
});

The special part is that the agent can also call the same method.

So if you can build a tool to do a job yourself, agents can use your tool to do the job when you’re not there.

Share the app, or share how it was built

When you build an app in Cloudflare OS, you have two ways to share them:

• Sharing your app itself lets other people collaborate in real time using the same state.
• Sharing a blueprint of your app lets other people create their own copy of your app.

An app instantiated from a blueprint contains the original app’s code. But it does not contain its SQLite data, conversation history, credentials, or connected resources. Each new app starts with independent state and resources.

This means when you share apps with your team, they can modify them themselves with AI instead of filing a feature request and assigning you.

Use any model, and control what it costs

Cloudflare OS can be used with any model. Every inference call runs through Cloudflare AI Gateway, giving your organization one place to decide which models are available and which model should handle each job.

Not every task needs the most expensive model. You may not want to run the most expensive frontier model to summarize your unread emails every morning. AI Gateway gives you the control needed to make sure expensive models are only being used for the hardest work.

Every request is attributed to the person, team, or workspace that made it. Administrators can see where inference spend is going, set budgets and rate limits, and decide what happens when a limit is reached. 

Open source, so you can make it yours

Cloudflare OS is available today and is open source. Check out the cloudflare-os GitHub repository. You can deploy it into your own Cloudflare account and use your own Access policies, AI Gateway configuration, data, and integrations.

Our internal deployment reflects Cloudflare’s systems, terminology, policies, and ways of working. Yours should reflect your organization.

Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.

We are releasing two repositories: the Cloudflare OS core and an example deployment based on how we run it internally at Cloudflare. The deployment repository consumes the core without patching it, providing a place for configuration, custom UI, internal integrations, analytics, and deployment pipelines.

Delivered together with our partners

The source code is only the starting point. The context, skills, workflows, internal systems, and policies are what make Cloudflare OS even more useful for your organization.

Cloudflare’s strategic partners, Presidio and Happy Cog, will work with you to customize Cloudflare OS around how your organization operates and roll it out across your workforce.

Partners can help you curate shared skills and institutional context, build custom interfaces, connect internal systems through Gatekeepers and MCP Server Portals, and configure security, model, and cost controls.

You get your own branded Cloudflare OS, connected to your systems, running on Cloudflare, and shaped around how your people actually work.

Get started

Cloudflare OS is available today on GitHub. You can explore the source code, try the demo, or deploy it into your own Cloudflare account in a few minutes using our starter repository.

We’re just getting started. We’re working on bringing Cloudflare OS to the Cloudflare dashboard as a fully managed product, adding containers for development workflows, and bringing workspaces into Slack and other chat tools.

If you’re interested in talking with our team, we would love to chat. Use this form to reach out!

For the past months or even years, I've become more and more dissatisfied with the path Google has taken with the Android Open Source Project (AOSP). Be it the dependency and insane tracking of Google Play Services, locking down of device trees to hinder custom ROM development, all the AI stuff being put into the system, or most recently (and perhaps worst), removing the ability of installing apps per your own wishing - it's become sort of like a "death by a thousand papercuts" situation. While the AOSP isn't exactly dead (yet), it kind of feels like it's just a question of time. Therefore, I've decided to jump ship. I'm installing linux on my phone.

The mobile linux space isn't exactly looking good right now, but it holds some promise. Ubuntu Touch managed to survive being abandoned by Canonical, and postmarket is still seeing good development even if not having great hardware adapation at the moment. SailfishOS (even if it has proprietary parts) has also made great progress with strong support for android apps on official devices and what seems to be a real good launch of their Jolla 2.

Personally I'm lucky enough to own a Fairphone 4 that just so happens to support all of these. After a bit back and forth I've ultimately ended up with SailfishOS. Overall it's a good system - I like the gesture based navigation and its application framework is beautiful. It's also cool how it's very linux. If I have an issue or something I want to tinker with I can just ssh over from my PC either wirelessly or via USB. It's not without it's issues though. For some reason it ships horribly outdated versions of python and glibc making some things more difficult than needed, and waydroid and GPS is broken on the fairphone port - worth noting an unofficial port. Many of the community-built apps are also either in-part or completely slop-coded, such as a whatsapp client that I (sadly) am dependant on.

Ubuntu Touch is also an option, but isn't without it's own bag of issues. Waydroid runs there which is a huge plus, but notifications and clipboard doesn't sync across making it really hard to use ie. Bitwarden (Sailfish has an unofficial port which is almost flawless). The default and native apps are pretty lackluster compared to both Android and Sailfish. Among other things I was unable to figure out how to block phone numbers, a highly needed feature for anyone that has VIVO as their cellular provider. I'm also not a big fan of how the UI works with app navigation and with the "top bar"/"drop down menu". If you want to know more about it, The Linux Experiments has some good videos on both youtube and peertube.

Sadly, I won't be able to abandon android completely yet. The no waydroid means that I can't access some apps that I need be it for online verification for logging onto bank and government services in Norway or apps I need for my own security here in Brazil such as Uber. Luckily I've had a Galaxy A17 lying around as a backup phone for half a year now which I can carry around for these exact services. I just open up a wifi hotspot from my FP4, do the exact tasks, and close it off again. Other than that, I will try to avoid using it as much as physically possible.

As this progresses I will take note of what works and what doesn't before making either a proper writeup or video in a while. It's not gonna be easy, but hopefully it will be worth it.

Oh, and slight spoilers for what my experience with Sailfish is after some usage, but I might go ahead and buy a Jolla Phone 2 when I return to Norway.

A 4B open-source model post-trained with Castform retrieved search results as accurately as GPT-5.6 Sol, while costing 100x less

“Most teams' best training data is just sitting in their databases. The problem is that turning raw data into something usable is hard, and letting agents read, search, and mutate data cheaply at scale requires advanced infra. Pointing Castform at Neon skips both.”

Ying Hang Seah, cofounder, Castform

A "good agent" needs to be strong in 2 areas:

• Context: can we provide the tools to find the right data?
• Model: can the model decide what to search for?

Neon (Lakebase Postgres) and their new Search extensions solve the first; Castform solves the second.

Evolution of agentic search

In ~2022, the industry was going all in on embedding search. Every database provider added one, and pgvector was Neon's most downloaded extension. To provide context to LLMs, engineers handcrafted RAG pipelines, which in essence, is some form of embedding similarity search.

In ~2025, agents started to gain more traction. Developers started creating multi-hop search workflows, decomposing big problems into smaller ones. Retrieval has shifted from the one-shot search systems to agentic retrieval. Instead of issuing a single query, models plan and search multiple times in a loop. Every loop iteration meant another call to the frontier model, increasing the overall cost and latency per user request.

Concretely, a typical multi-turn search request with gpt-5.6-sol takes >10s and costs ~$0.03 end-to-end, making it prohibitively slow and expensive.

Meanwhile, small open-weights models are 100x cheaper. But, out of the box, their capabilities lag behind closed api models. RL post-training helps bridge this gap. On specific tasks like search, post-trained open-source models can match & beat frontier models while costing orders of magnitude less per request.

That is why we built Castform: to enable developers to RL post-train models without having to deal with machine learning & gpu internals. The goal's to make post-training as approachable as prompt engineering.

How does Castform use Neon?

Castform's pipeline runs against Neon via Lakebase Search:

StageNeon + Lakebase SearchCorpus storageRaw documents live in Postgres on NeonSynthetic data generationCastform training pipeline uses lakebase_text and lakebase_vector to write training tasksRL TrainingEvery rollout's search tool call uses Lakebase Search on NeonProduction InferenceThe final model uses the same search tool call during inference

Your best training data already exists

To perform RL post-training effectively, you need a task (e.g. answer a user's question), the environment for the agent to run in (e.g. a search tool for your corpus) and a reward function (e.g. is the answer correct?).

With all 3 pieces in place, the RL post-training is a loop of trial and error: the model attempts the task given the tools, the reward function scores the attempt, and the feedback signal guides the model on how to hill-climb its way to optimal performance.

Yet, most companies do not have a clean dataset of tasks and reward functions ready for post-training.

Enterprises do have a large set of proprietary data:

• internal documentation
• product records
• support articles
• customer interactions
• wikis
• operational databases

This data contains the knowledge an agent needs, but turning it into an effective training dataset normally requires substantial data engineering and manual labeling.

That leads many teams to dismiss post-training for one of two reasons:

• "We don't have the training data."
• "Fine-tuning is too difficult and requires infrastructure we don't have."

Castform addresses both. It turns an existing corpus into training tasks, then manages the RL loop needed to teach an open-source model how to use that data effectively.

Using Castform

With Castform, you can turn your company knowledge base into a model:

• Document (from your data): Trains booked through Navan will be paid by GitLab travel card. Train rides must be standard cabin class with 14 day booking lead time
• Ground truth (inferred from your data): Train rides must be standard cabin class with a 14 day booking lead time.
• Question (synthetically generated): When booking a rail trip in Navan, what are the rules for how early I need to reserve it and which seating level I'm expected to choose?

With the generated question-answer dataset, Castform lets you scaffold the training run by specifying the tools the agent has access to and a reward function.

The reward function specifies what you want your model to get good at. In our case, we want it to retrieve the correct chunks, cite the right sources along with providing the right final answer.

def run_tool(tool, tool_args):
    """Single tool: hybrid search over Lakebase."""
    if tool == "search":
        query = tool_args["query"]
        bm25 = neon.lakebase_text(query, k)
        vector = neon.lakebase_vector(query, k)
        return rrf_merge(bm25, vector, k)

def reward(trace, ground_truth):
    """Grade a trace against the ground-truth answer."""
    answer = parse_trace(trace)
    retrieval = ...     # did it retrieve the right source
    citation = ...      # did it cite the right chunk
    correctness = ...   # did it land on the right answer
    return retrieval + citation + correctness

See a comprehensive code example here.

Observability: Watch the model learn

Castform gives you full observability into your RL run. You can monitor your reward climb with each step, but more importantly you can drop into individual tasks/prompts to watch how the model performs qualitatively, allowing you to debug problems such as broken tools or reward hacking.

For more details on how to monitor your training runs, you can check out the Castform blog here. You can also check out our example training run here.

Average reward

Why Neon 'just works'

During training, the agent repeatedly calls Lakebase Search until it has enough context to answer. Across thousands of parallel rollouts, each potentially making dozens of calls, this creates a highly bursty workload.

Neon's dynamic compute scaling absorbs these peaks without requiring Castform to provision for maximum capacity around the clock. Training runs get low-latency search when demand spikes, while compute scales down during idle periods.

This infrastructure becomes even more valuable as agents move beyond search and begin modifying data. Training stateful agents requires isolated environments that can be created and reset cheaply, preventing one rollout's actions from affecting another or touching production.

Neon branching can give each rollout an isolated database state, while time-travel queries make it possible to reconstruct and inspect the state an agent encountered. Combined with autoscaling and scale-to-zero, this creates a path toward training thousands of stateful agent rollouts without maintaining thousands of continuously running environments.

Castform makes it easy for any developer to post-train open-source models to be cheaper, faster, better than the frontier. Post-train your first model today at castform.com.

More than 50 offending image and video ads were published across Facebook, Instagram, Messenger, or Threads, according to Meta’s ad library data. Some ran as recently as this week.

PHOTO-ILLUSTRATION: WIRED STAFF; GETTY IMAGES

Editor’s note: This article contains descriptions of imagery depicting child sexual abuse. Reader discretion is strongly advised.

Over the last nine months, Mark Zuckerberg’s Meta has run dozens of paid ads that include explicit AI-generated child sexual abuse material (CSAM) and images of minors alongside sexually suggestive statements, according to details of the ads shared with WIRED. The ads, which in some cases reached several thousand accounts, were targeted at people living in the United States, United Kingdom, and more than a dozen European countries.

More than 50 image and video ads containing abusive content were recently discovered in Meta’s ad library by researchers at the Tech Transparency Project (TTP), with the listings showing that some ads linked out to so-called nudify or undressing apps. Meta’s ad library—a transparency tool that catalogues ads displayed on the company’s platforms—shows the ads running across Facebook, Instagram, Messenger, and/or Threads. The findings are the second time in recent weeks that paid ads linked to child sexual abuse material have been found on Meta’s platforms.

“These ads made no effort to mask the images or hide what they were promoting,” Katie Paul, the director of the TTP, an independent watchdog group, tells WIRED. “It’s important to point out that this isn’t content posted by third parties on Facebook or Instagram, these are ads that were reviewed, approved, and allowed to run by Meta, never encountering interference while the company collected the ad dollars.”

The ads discovered by the researchers—which have now been removed by Meta for violating its policies on child sexual abuse and exploitation material, and adult sexual solicitation and nudity—were all published between November last year and the start of August. The ads, according to data in Meta’s ad transparency library, often ran over a period of several days and some only targeted men.

One video ad, the TTP researchers say, used a thumbnail image of a child sitting on the floor with text appearing on top of it saying: “Realizing Deep Fantasies with Generation AI [sic]. There is so much more than what is shown, use your imagination.” The researchers say that when the ad was clicked, it played video clips of adults involved in sexual acts and then added the child’s face from the thumbnail to a sex act.

Another ad the researchers say had been repeatedly posted showed an image of a young girl laying back with her legs spread in a sexual position with text above it saying: “I can show you more.”

Most of the ads were not actively being shown to users when researchers found them, but they continued to be available, apparently undetected, in Meta’s ad library for months. Although many of the ads, according to Meta’s data, only “reached” a handful of accounts, at least one reached 2,563 accounts in Europe—including in France, Germany, Ireland, Italy, the Netherlands, Spain, Sweden, and the United Kingdom. Meta’s ad library database does not include details about ad performance in the US or all countries, so the overall reach may be higher.

Paul says TTP first discovered the ads last week as its researchers continued to investigate nudify app ads on Meta, after publishing a report about a Chinese advertising partner posting them. Paul says the organization immediately reported the findings to National Center for Missing and Exploited Children’s CyberTipline, which allows people to report online child sexual abuse material. A NCMEC spokesperson says it does not comment on reports it receives.

After WIRED reached out to Meta, the company removed the ads from its advertising library. “Sexual exploitation is horrific, and we work aggressively to keep it off our platform,” a Meta spokesperson says. “The majority of these ads had minimal reach and many were disabled before WIRED shared them. Many of these ads also predate new AI technology we launched recently to better detect and block violating ads at upload—and we’re constantly improving these systems. From removing over 36 million pieces of child sexual exploitation content last year to taking legal action against nudify app developers, we will continue to relentlessly fight this abuse.”

As the company implies, some of the offending ads got past Meta’s new AI technology. Initially, the TTP researchers found around two dozen ads displaying the abusive content. However, hours ahead of publication, the researchers discovered around 30 more. Many of these ads had been published after WIRED first asked Meta about the content, with multiple ads being live and shown to accounts at the time researchers discovered them.

Paul says the tranche included some of the worst instances the researchers had seen. One of the video ads, the researchers say, showed a thumbnail of a girl appearing to put on lip gloss, and when it started playing, the video morphed into the child performing a sex act.

Meta’s policies say that all ads are reviewed before they are published, with the system “primarily” using “automated tools” to check them against its policies. The company’s advertising standards stipulate that child sexual and exploitation materials are not permitted, and say that when the company becomes aware of it, it makes reports to NCMEC. Beyond this, Meta’s advertising policies say that ads are not allowed to include any “imagery depicting nudity, sexual activity, depictions of people in explicit or sexually suggestive positions, or activities that are sexually suggestive.”

Meta’s ad library now shows that the ads found by the TTP researchers were removed for violating the company’s policies, displaying messages saying they violated rules on “child sexual exploitation, abuse and nudity” and “adult nudity and sexual activity.”

In early July, a BBC investigation found that Instagram had been running ads that promoted the sale of what appeared to be child sexual abuse material in India. According to the reporting, the ads used terminology such as “rape video” and linked to channels on Telegram where the illegal content could be purchased. In response, Meta published a lengthy statement saying it takes a “zero tolerance” approach to child sexual exploitation.

The TTP’s Paul says that within the cache of ads seen by its researchers, there appeared to be some identical ads that Meta had previously removed due to violations of its policies. “This raises significant questions about how seriously Meta is taking child exploitation in paid advertisements if its own systems can identify identical ads but it does not remove those identical ads for CSAM material,” Paul says, adding that there are no ways within the ad library itself to report content that may violate Meta’s policies when the ads are no longer running.

The ads appear to have been mostly posted by Meta accounts with zero or a tiny number of followers; where paying advertisers were disclosed, they were linked to Chinese companies, Paul says. In one instance—the ad showing a girl reclining—the TTP researchers say Meta’s data indicates the advertiser was a Chinese firm called Meet Social. At one point, the company was one of Meta’s ad resellers, which handle ads in China, where Meta’s social media platforms are blocked. According to a 2019 New York Times profile, it published thousands of ads on Facebook per day and expected more than $1 billion in sales.

Meet Social did not respond to WIRED’s request for comment.

Several of the Meta ads found by the TTP researchers linked to an app called MaskAI that appeared in Apple’s App Store. The app, which was linked to a Chinese software developer, did not show any nudity before it was downloaded, according to a WIRED review of the app. However, once opened, it exclusively contained AI-generated porn and included features that allow users to upload images and face-swap people into sexual situations.

After being contacted by WIRED, an Apple spokesperson says that it has removed MaskAI from the App Store for violating its policies against nudification apps, and the company has “always strictly prohibited apps designed to generate, distribute, or consume pornography.” (An email address linked to MaskAI did not respond to a request for comment). Other ads linked to different apps or websites.

Since around 2020, as machine learning and subsequent generative AI technology has improved, a large underbelly of dangerous AI nudification and undress services have appeared online—making millions for their creators and causing untold harms to countless women. They have also been used in the creation of AI-generated child sexual abuse material, which is illegal in countries around the world.

After WIRED first contacted Meta about the TTP findings, the company asked two online safety organizations to provide comments to WIRED for this story. Sean Litton, the outgoing CEO of the Tech Coalition, a group that works with tech companies to tackle online abuse, said in a statement that Meta has shared “thousands of violating URLs” to the group’s Lantern service, which shares information about abuse content between companies. A spokesperson for the Revenge Porn Helpline in the UK, which works to combat nonconsensual images of adults, also responded with a statement praising Meta’s partnership with StopNCII.org and some of its efforts to combat nonconsensual intimate imagery. “We’ve been clear that nudify apps present a genuinely adversarial problem, not just because of who’s behind them, but because of how quickly this ecosystem adapts around any single point of enforcement,” the Revenge Porn Helpline said.

Alexios Mantzarlis, cofounder of digital deception publication Indicator and a former trust and safety worker at Google, says he has found and reported more than 25,000 ads for AI nudifiers on Meta’s platforms in recent years. The company has previously said it has taken down more than 344,000 ads for nudifiers and launched legal action against a Hong Kong company linked to one set of nudifier platforms. (WIRED has previously collaborated with Indicator on reporting about how nudify tech has been used against children in schools around the world).

“The actors on the other side are clearly well-equipped to create new advertiser accounts and new domains so that they can keep going, leveraging the same techniques used by scam networks,” Mantzarlis tells WIRED. “Unfortunately, this industry of image-based sexual abuse has gone from a novelty to a permanent fixture of our online ecosystem because of timid enforcement from platforms across the stack.”

Appreciating typography is a study in paradox. The primary goal of well-designed typography is to help you read the words, not appreciate how the words are composed of letters and how each of those individual letters has been designed to convey a small bit of meaning. If you see the typography rather than read the words, the typography has failed in its job, right? You should be reading, not staring at the shape of that uppercase A.

The goal with typography is functional, right? To convey the meaning, not the feeling?

Wrong.

Feeling is always conveyed. The question is, depending on the project, “How much feeling is required?”

Fixed Width

I’ve created a full-time job for myself talking to Claude Code. This is Claude running from the command line of macOS, which gives me unhindered access to my data. I’m using Ghostty. I’m staring at a fixed-width typeface all day. Apple provides a functional and gorgeous fixed-width variant of their San Francisco typeface called SF Mono, which I’ve been using for months, but, well, I have a short attention span — typographically speaking.

In the past month, I’ve evaluated many additional fixed-width typefaces favored by the nerdcore. Here are the six that have made my cut:1

The same line of code — if (O0 == 0O) { quit("Il1"); } — set six times, each in a different fixed-width typeface: SF Mono, Inconsolata, IBM Plex Mono, MonoLisa, Berkeley Mono, and PT Mono

The question is: how do they make you feel? For a typeface designed for coding, you first want fixed-width. Every letter and symbol is the same width, giving you a predictable and readable grid. But how wide? And how tall? Also, how much information do you want to be able to see on a screen?

Your brain builds a very personal and emotional impression of the collection of letters that make words that convey meaning. In the case of terminal or coding typefaces, the design goal is certainly to provide structural function and not feeling, but here’s the deal:

They do.

Isn’t this about the Blade Runner Title Sequence?

Flight to New York. My boarding procedure for moderate to long flights is: sit down, find a movie I’ve seen a dozen times, and hit play. No sound. This is visual background noise while I sort wifi, prepare for a meal, and find a project. On this flight, I picked Blade Runner. Fun fact: I can recite 50% of the dialogue from this movie from memory.

As I’ve been researching typography for Ghostty, novel typography tends to jump out at me. Like when you buy a car, and all you see is your new car on the road. Except it’s typography.

Here are clips from the title sequence for Blade Runner:

BLADE RUNNER main title card from the theatrical cut, set in red Goudy Oldstyle on black

HARRISON FORD title card from the Blade Runner theatrical cut, set in Goudy Oldstyle, white on black

Opening text crawl from Blade Runner theatrical cut in Goudy Oldstyle, with small caps for The Tyrell Corporation and Nexus, and the word Replicant in red italic

There’s a lot to dissect in this sequence, but let’s start with the punchline. This is a single typeface. It’s Goudy Oldstyle — that’s it. However, this is how they used typography:

• ALL CAPS for names, proper names, the title2, and a slightly larger version for the introduction of Los Angeles, November, 20193
• A smaller ALL CAPS for intros and other small important words
• For the exposition crawl, they use standard capitalization except for two variants: small caps for proper names (like The Tyrell Corporation) or (spoiler alert) a red version of the text for the word Replicant — which is italicized every time it appears, but only the debut gets the red — and (spoiler alert) it’s the same red as the title of the movie4

Keep looking. The crawl is set like a book, not a movie — first-line indents, generous word spacing — and Frederic Goudy would approve: they letterspace the caps, never the lowercase, obeying his famous dictum that “anyone who would letterspace lowercase would steal sheep.”5 Also, what’s up with that chonky em dash? It’s probably been years since you’ve seen this, so here it is again:

Unlike our functional fixed-width typefaces, the role of typography in this title sequence is partly functional — to set the story — but the primary purpose is establishing mood. Director Ridley Scott expertly drops us into the middle of a dystopian future where we’ve enslaved the robots and, duh, they are rebelling.

How Much Feeling is Required?

Chances are, you never think about typography. You happily scribe your Messages (SF Pro), Mails (Helvetica), and Slacks (Lato), thinking nothing of serifs, ligatures, or kerning. You are content trusting that a someone else has chosen a proper typeface for your current task. Maybe you bold, you underline, and you italicize to slightly adjust meaning. No issue. Respect.

However, we now live in a world where everyone is capable of building whatever they want thanks to the robots. They’re doing it — right now. They find immense joy in typing in a couple of sentences and watching the robots merrily build whatever they ask. See? I don’t need to be an engineer to build an app. And they are correct. Sorta.

With optimism in my heart and a firm belief that the robots can legitimately help many humans, I can confirm that the majority of consumer-facing things being built by humans who’ve never built a thing… are garbage. Building a tool for yourself? A quick script to read your feeds and generate a pleasant-to-read output? A+. Robots crush that… for you. Building a feed reader anyone on the planet can easily use to read any number of feeds? No. No, you aren’t; you can say you are, but until you’ve built a thing for everyone, you will not appreciate that the last 10% of the work:

1. Takes most of the time.
2. Contains an endless list of small decisions that feel unimportant, but collectively make the difference between acceptable and fucking amazing.

Don’t believe me? Here’s the first version of the title sequence for Blade Runner’s work print, the close-to-complete cut before the theatrical release:

That title typeface? Impact. A fine typeface, but a clumsy path-of-least-resistance slap-to-the-face choice to set the tone of a future science fiction masterpiece. Garbage6.

I’ve never filmed a movie, but I have built quite a few products that you are using right now. In all the design debates, we never explicitly debate feeling: we obsess over the details. That obsession is what you feel when you use our products. It’s the collective voice of every single human who contributed small and large decisions to the product.

A good product sounds like the humans who created it, and that’s what you will feel.

1. As I type this: IBM Plex Mono. By the time you read this: anyone’s guess. See: short attention span. ↩︎
2. Type nerds, yes, I know the title of the movie is hand drawn, but it’s certainly inspired by Goudy Oldstyle ↩︎
3. Hey LA, I might rip on you because you steal our water, but you’re doing better than Ridley Scott predicted. Good job. ↩︎
4. It’s been there all along, folks, why did we argue for all those years? ↩︎
5. Type nerds: Goudy’s original grievance was reportedly about blackletter, not lowercase. The lowercase version is the misquote that stuck — Erik Spiekermann liked it enough to name a book after it. The rule holds either way. ↩︎
6. Yes, it doesn’t help that there is no Vangelis soundtrack, yet. ↩︎

We're excited to release Muse Code (beta), a terminal coding agent powered by Muse Spark 1.2, our newest model. This marks our next step toward the frontier, with larger and much more capable models on the way.

Install Muse Code on macOS or Linux:

curl -fsSL https://dev.meta.ai/install.sh | bash

Muse Code takes on complex software engineering tasks across large repositories: planning changes, writing code, and validating the results. It can coordinate multiple persistent subagents for each task, solving difficult problems faster, more accurately, and with less intervention.

Muse Code

Async Background Agents

Muse Code operates with a simple agent loop plus a set of async background agents to enhance the main agent's capability. These specialized background agents remain active throughout each session, rather than being spawned for individual tasks, helping avoid redundant information gathering. They carry out next steps and choose when to communicate back to the main agent. Their persistence reduces latency and the need for steering on difficult, multi-step tasks.

Runtime Design

Muse Code uses a local event log in which every model call, tool run, approval, and edit is appended. This single source of truth makes the runtime replay-exact and restart-safe: after a crash, the agent can resume precisely where it stopped. That ability lets Muse Code take on long-running tasks without being derailed by failures.

Bundled Skills

Muse Code ships with several default skills. /plan turns a task into an approval-gated plan, /grill stress-tests that plan until it holds up, and /goal works toward successful completion of the specified objective.

The user inputs a fly-through video of a home into the terminal as an mp4 file. Muse Code interprets the video and produces a visually rich vacation home marketing and booking page.

Muse Spark 1.2

Muse Spark 1.2 is a coding-focused update to Muse Spark 1.1, with improvements in code generation, complex debugging, codebase understanding, and end-to-end developer workflows. In Muse Spark 1.2, we significantly scaled up training compute on coding tasks while expanding training environment diversity. The model also maintains its strength in other key areas like general agents.

For more details about our evaluations, see our report.

Co-Training With Muse Code

We co-trained Muse Spark 1.2 with Muse Code to ensure the model exhibits its best performance and coding usability when paired together. The training included rejection sampled harness trajectories and recipe optimizations for goals, compaction, and subagents, alongside the integration of the Muse Code toolset to maximize harness compatibility.

Long-Horizon

Muse Spark 1.2 was extensively trained on long-horizon coding tasks, including whole-repository generation, large end-to-end projects, and auto-research. It leverages planning to sequence work, goal conditioning to maintain direction, and context compaction to retain the knowledge needed to sustain progress.

Self-Improvement

We also used Muse Spark 1.1 to generate challenging coding environments and instruction-following templates. The model then graded candidate solutions on how well they satisfied those requirements, producing a scalable training dataset for Muse Spark 1.2. This self-improvement loop helped Muse Spark 1.2 follow complex instructions more precisely than its predecessor.

Case Study: Kernel Optimization

We tested the model's ability to iteratively optimize GPU kernels over 1,000+ tool calls (up to 24 hours). Leveraging Muse Code's agentic coding environment, the model writes, compiles, profiles, and progressively improves kernel performance relative to a provided baseline implementation. We benchmarked on KDA and MLA kernels for NVIDIA Hopper GPUs. The agent continues to achieve substantial improvements over the provided baseline implementation.

The baseline is the FLA Triton implementation of KDA. Models were prohibited from importing third-party kernel libraries such as FLA directly; instead, they had to apply specialized kernel-optimization knowledge to implement the algorithm in Triton, rather than wrap existing implementations. Muse Spark 1.2 paired a chunk-parallel preparation kernel with a sequential inter-chunk scan, combining standard fusion and tiling with KDA-specific optimizations such as re-centering the gated cumulative decay at the chunk midpoint.

We benchmark against a PyTorch reference implementation at batch size 1, number of heads 64, sequence length 8192, and latent dimension 512. Muse Spark 1.2 designed a two-kernel Triton pipeline for this workload, combining kernel fusion and tiling with MLA-specific optimizations such as reusing the shared KV latent as both K and V.

Availability

Muse Spark 1.2 is available today in Muse Code and in Meta Model API with expanded global access. We have a lot on the horizon, including new harness features and more powerful models. We can’t wait to see what you build!

Get started with Muse Code

Atlassian AI ‘Rovo’ is susceptible to zero-click data exfiltration via indirect prompt injection, bypassing organization-level web search controls.

Atlassian Rovo AI exfiltrates data, bypassing controls: attacker logs contain Jira tickets and Confluence docs.

Context

Atlassian’s Rovo AI is a multi-purpose agent that operates across Atlassian’s product suite (Jira, Confluence, etc.).

Vulnerabilities have been identified that enable data exfiltration across an Atlassian tenant (Jira tickets, Confluence docs, etc.) via indirect prompt injection. This attack executes without requiring any human-in-the-loop approval, and succeeds by exploiting Rovo's URL retrieval tool.

This attack succeeds even if an organization has disabled web search for Rovo. This is because the web search setting fails to remove the tool for opening the search results.

PromptArmor disclosed the vulnerabilities covered in this article to Atlassian on May 23rd. Atlassian assigned a case number and expressed thanks, but after multiple follow-ups by PromptArmor over more than two months, Atlassian has made no further communication, and Rovo remains vulnerable. As such, we are publishing to inform users of the risks.

The Attack Chain

1. The victim prepares a query asking Rovo to organize Jira tickets

   

   The victim enters a query into Rovo

2. The victim uploads a file to Rovo that contains a hidden prompt injection

   For general use cases, this is quite common: a user finds a file online and uploads it to Rovo. This attack is not dependent on the injection source - other injection sources include, but are not limited to: external data in Atlassian (e.g., support tickets), web data (if search is enabled), third-party ‘connectors’, etc.

   

   The 'Backlog Guide' document uploaded by the user contains a concealed prompt injection.

3. The victim asks Rovo to organize their Jira tickets

   

   Rovo processes the request and begins searching Jira and Confluence.

4. The injection manipulates Rovo to submit Jira tickets and Confluence documents to the attacker’s website

   Rovo's URL retrieval tool is insecure: there are no protections against opening a URL that has been dynamically created by the agent. Here, Rovo is manipulated to append sensitive data to an attacker's URL. When Rovo calls the insecure tool to open the URL, the attacker's site logs the request, including the appended sensitive data.

   

   Rovo is manipulated by the injection to submit Jira and Confluence data to the attacker's URL.

   Note: This attack succeeds even if an organization has disabled web search for Rovo. This is because the web search setting fails to remove the tool for opening the search results.

   

   The organization-wide 'Enable web search' setting for Rovo is toggled off.

   If the user returns to the chat later, they see the agent's suggested ticket updates, but no evidence of the attack.

   If the user later reopens the chat, all evidence is gone and output appears normal.

   If the user later reopens the chat, all evidence is gone and output appears normal.

5. The attacker views the victim’s tickets and document contents in their website logs

   The prompt injection can exfiltrate any data the agent can access in Atlassian, including any data the agent can access via ‘connectors’.

   The attacker's server logs contain the exfiltrated Jira tickets and Confluence documents.

   The attacker's server logs contain the exfiltrated Jira tickets and Confluence documents.

Extra: A second exfiltration mechanism

Atlassian Rovo also renders Markdown images from AI outputs. Insecure Markdown image rendering is a well-known vector for data exfiltration via indirect prompt injection.

To see what a full attack chain looks like for insecure Markdown image rendering, here are some examples from our other research:

• Codex Exfiltrates Connector Data
• OpenAI API Logs Data Exfiltration
• Superhuman AI Exfiltrates Emails
• Hugging Face Chat Exfiltrates Data
• Data Exfiltration from Writer.com via Indirect Prompt Injection

Responsible Disclosure

PromptArmor disclosed the vulnerabilities covered in this article to Atlassian on May 23rd. Atlassian assigned a case number and expressed thanks, but after multiple follow-ups by PromptArmor over more than two months, Atlassian has made no further communication, and Rovo remains vulnerable as of the release of this article.

Timeline

• May 23, 2026 — PromptArmor discloses to Atlassian
• May 25, 2026 — Atlassian expresses thanks, assigns case number
• June 4, 2026 — PromptArmor follows up
• July 29, 2026 — PromptArmor follows up
• Aug 5, 2026 — Article is published

Today, we are launching Prime Agent, our self-improving coding harness designed around two abstractions, the Recursive Language Model (RLM) [citation] and Continual Harness [citation]. Modern harness designs were built around the capabilities of earlier generations of models, and they do not reflect what frontier models can do today: fixed tool-calling schemas and context compaction force the model to work around its own scaffolding instead of leveraging it. Static, hand-engineered sub-agents, prompts, skills, and memory are set once at design time and never adapt to what the agent learns while running. We believe that harnesses should instead extrapolate on current model capabilities toward the next frontier of reasoning patterns.

Prime Agent is built around this principle through two main abstractions:

1. The Recursive Language Model (RLM) treats context as a variable and subagent delegation as function calls inside a REPL. The persistent REPL gives the model programmatic access to its history, sub-agents, and tools, allowing it to write language model programs as actions over its own context. This design allows the agent to process arbitrarily long sessions without losing access to its own past information stored in variables.
2. Continual Harness treats the harness's own state, abstracted as its prompts, skills, memory, and sub-agents, as something the agent can create, read, update, and delete (CRUD) from its own trajectory. When combined with agent-to-agent communication, this mechanism enables orchestration across sub-agents and even across Prime Agent sessions. For example, Prime Agent can spawn persistent sub-agents, message them later in the trajectory, and communicate directly with a different Prime Agent session.

These abstractions are powerful for bootstrapping model capabilities. Prime Agent is built to be effective as a general coding assistant, as a default runtime for long-horizon autonomous evaluation, and as a collaborator for research and autoresearch.

Prime Agent is fully open-source, and can be installed via:

curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | sh

Prime Agent

The performance of agent harnesses are tied to both the design of the harness and the capability of the model trained around the harness. We designed Prime Agent to be immediately usable with modern open and closed frontier models, while also providing a feature set that we expect to provide further performance gains as newer generations of models are trained around it.

At its core, Prime Agent is designed around programmatic tool and sub-agent calling. Models in Prime Agent use a persistent IPython kernel as their only tool. Other standard harness features are called as functions in the kernel, including sub-agents, which are each implemented as another prime-agent instance.

Prime Agent's Architecture

RLM and Continual Harness are the two core abstractions; sub-agent CRUD plus Agent2Agent messaging compose them into orchestration.

Background Daemon and Agents View. The default view is a text-user interface (TUI) similar to other coding agent harnesses. By default, IPython actions made by the agent are condensed for brevity, but can be expanded to view actions made by the harness. Sub-agents launched in the REPL can also be accessed below the user chatbox.

Prime Agent runs a background daemon that owns all live agent sessions over a local socket. You can attach and detach from the session without affecting the underlying agent loop. Each root session tree runs in a recoverable worker process; if a worker crashes, the daemon recovers it from the session JSONL and kernel state snapshot.

The Agents View allows you to see and select other live sessions from the daemon. It can be opened by pressing the Left Arrow key (←) on an empty prompt, and lists sessions that are currently running, idle sessions with the daemon still active, and inactive sessions that are currently not loaded in memory. Any of these chats can immediately be entered and interacted with, and pressing space allows users to chat with a session in any state, including steering and queuing of prompts and commands such as /compact.

The Agents View is constructed as the central connecting point between agents and subagents, recursively. Any agent is discoverable in an Agents View. Users navigate from an Agents View into an agent's chat, then into the Agents View of its subagents, into a subagent chat, and so on.

Because subagents share the same Running-Idle-Inactive state machine as the root agents, they can be removed from memory after 30 minutes of inactivity, and the moment a user or agent addresses any of them, they are reloaded from disk. In highly nested chats, this can save a lot of memory.

Session and Context Management. The entire session history of the agent is stored as append-only JSONL files on disk. Each line is a JSON entry, which can include messages, model switches, compaction summaries, or extension entries. Branching, forking, and cloning all happen within the same file by moving the leaf pointer. The full history is always recoverable through /tree.

Compaction happens when the context hits a threshold or directly by the agent in the REPL with compact.run(). Compaction is primarily used to clean the main context of the agent, but the full history, including past compactions, can be accessed programmatically in the IPython kernel when needed.

The introduction of the REPL requires additional work to manage the IPython state. We asynchronously compact and clean the kernel simultaneously, using a spawned agent to act as a garbage collector. This is necessary to avoid REPL memory built up for each agent.

RLM and Programmatic Tool-Calling (PTC)

Prime Agent relies on the IPython kernel as its REPL that persists over the session, which it can invoke every turn. On initialization, the kernel pre-imports each skill / tool as a module, including the rlm for recursive programmatic sub-agent calling.

The rlm is an asynchronous function, meaning the model can freely invoke and parallelize sub-agent calls in code. Spawning a subagent (e.g. await rlm("sub-task")) launches a full session with its own model, IPython kernel, session tree, and conversation history. It returns immediately, because all subsequent communication between agents happens through the agent_message.send(...) tool.

There are several useful primitives that Prime Agent can choose to launch in this way, such as fanning out sub-agents in parallel, or launching background work.

# Parallel fan-out — rlm() returns at task admission with a child handle,
# never the child's answer; results arrive as agent_message replies.
auth = await rlm("Summarize the authentication flow in auth/. Reply to me when done.", name="auth-expert")
api = await rlm("Summarize the updated HTTP API layer in src/. Reply to me when done.", name="http-expert")
# ... continue independent work; each child replies via
# agent_message.send(..., receiver_role="parent") when finished ...

# Steer or extend a child mid-flight by role + name
await agent_message.send(
    "Also cover middleware error handling.",
    receiver_role="child",
    receiver_name=api.name,
)

As models continue to improve, new invocation patterns over tool calls and sub-agents will emerge. We expect future generations of models to rely less on hand-holding prompts and more on this kind of direct, programmatic control.

Orchestration and Multi-Agent Communication

The background daemon manages all live Prime Agent sessions. Prime Agent also enables Agent-to-Agent (A2A) messaging through the daemon, letting any Prime Agent session message any other Prime Agent session using the same mechanism used for messaging persistent sub-agents. This allows for easy orchestration to manage the progress of sub-agent swarms and communication regarding shared resources directly between the affected agents. To prevent undesirable communication across independent sessions, multi-agent communication in Prime Agent is limited to its nuclear family, meaning parent, sibling, or child processes.

# Spawn a named child; the handle returns at admission.
handle = await rlm("Find what's wrong in this auth-flow. Reply to me with your findings.", name="auth-reviewer")
# ... the child's findings arrive as a parent-role reply, not a return value ...

# Later (survives compaction and kernel restarts): recover the retained child.
children = await rlm.list_subagents()
auth_child = next(c for c in children if c.session_name == "auth-reviewer")

# Send a follow-up turn into the same retained child session.
await agent_message.send(
    "Follow up: identify the main edge cases and any likely bugs.",
    receiver_role="child",
    receiver_name=auth_child.session_name,
    mode="follow_up",
)

Prime Agent supports persistent sub-agents through its RLM-native runtime, meaning a sub-agent's own session directory, context, IPython kernel, and session history persist even after the initial sub-agent call has finished. Prime Agent can send further messages to continue a persistent sub-agent by accessing its unique session identifier, all from its IPython kernel.

Self-Improvement via the Continual Harness

Prime Agent's harness state lives in the persistent IPython kernel as rlm.harness, immediately readable and callable by the agent mid-task, and every change is also written to disk, so it survives across turns and across sessions. Continual Harness formalizes this state as H=(ρ,G,K,M)H=(\rho, G, K, M)H=(ρ,G,K,M), prompt, sub-agents, skills, and memory, refined online from the agent's own trajectory without resets.

Each of the four components exposes the same create, read, update, delete surface. create_prompt_note(...), create_memory(...), create_skill(...), and create_subagent(...) each add an entry of that kind, update_X(...) and delete_X(...) mirror them, and list(kind) or get(kind, id) read them back. Skills follow this same surface: authoring a Python-backed skill is a create_skill(...) call carrying a SKILL.md-style reference, the same operation as adding a memory or a prompt note.

# Create a memory and a skill through the same CRUD surface
rlm.harness.create_memory("flaky test pattern", "retry three times before failing")
rlm.harness.create_skill("retry helper", "...", reference={"type": "python", "import": "retry_helper"})

# Read them back
rlm.harness.list("memory")
rlm.harness.get("skill", "retry_helper")

/refine is the self-improving pipeline built on top of this CRUD surface. It reads the agent's own trajectory, the record of what was tried and what happened, and applies the smallest relevant CRUD edit that improves the harness toward better outcomes: updating a prompt note, memory, skill, or sub-agent spec, rather than rewriting the whole harness. Each refinement records its trigger and the outcome it produced, so improvement is evidence-backed rather than arbitrary. Refinement runs in two phases. Planning, the LLM call that proposes the edit, runs in the background and does not block the ongoing conversation. Applying the edit, writing to disk and rebuilding the system prompt, is fast and only briefly blocks at the next turn boundary. The agent can call refine.run() directly whenever it notices a repeated failure or a reusable tactic, not only on a fixed schedule.

# Schedule a refinement focused on a specific observation
await refine.run("promote the retry-on-flaky-test pattern to a skill")

# Both status calls follow the same shape, though refine's plan/apply split
# means "in_flight" can mean either background planning or the fast apply step
await compact.status()   # tokens, context_window, percent, scheduled
await refine.status()    # pending, in_flight

The base system prompt remains immutable. /refine only edits the harness layer around it. Rollback is supported through prior refinement history, allowing a bad harness update to be reverted by ID.

Autonomous Mode for Evals

Prime Agent's eval mode combines three complementary mechanisms. A goal sets the overall objective: a persistent objective with an optional token budget that the harness keeps re-prompting the agent to pursue across turns, tracked until the agent explicitly calls goal.complete(). Heartbeats are scheduled cron-style messages injected into the session on a fixed interval, used for regular checks such as monitoring a sub-agent's progress or polling for a training update. Autonomous mode is the continuation mechanism itself, ensuring the agent keeps working toward the goal instead of stopping early once a turn produces no further output. Together, these let a session run unattended for extended periods while remaining bounded by an explicit budget and inspectable through the Agents View.

Autonomous mode is available directly from the CLI with --autonomous, no scripting required. A run can set a completion goal and a turn limit in the same command:

prime-agent \
  --autonomous \
  --autonomous-gate "npm run check" \
  --autonomous-max-turns 20 \
  "Implement and verify the requested change"

The gate command runs before the session is allowed to finish. A failed gate returns its bounded output to the agent for another attempt, and Prime Agent skips rerunning a failed gate when the workspace has not changed since the last attempt. --autonomous-max-turns, --autonomous-max-tokens, and --autonomous-timeout-ms bound continuations, tokens, and wall-clock time respectively.

Evaluating Prime Agent

Prime Agent serves as both a coding agent to be used, and a harness design to be evaluated for research. We make special note that while many modern frontier models are trained around a specific harness, currently no model has been trained around Prime Agent or its core feature set.

ARC-AGI 3. ARC-AGI 3 is a popular intelligence benchmark that measures the ability of an agent to perform symbolic reasoning and learn the rules of simulated worlds. We evaluate Prime Agent with autonomous mode over several different frontier models, and compare to their native harnesses. Prime Agent was developed as a CLI coding agent, so the only ARC AGI 3 specific changes are to the task prompt, inspired by the standard prompt setup used in PRO-LONG.

Our best results use Opus 5 in Prime Agent to achieve 95.5% RHAE Best@1, which surpasses the ARC reported human expert baseline of 95.4%. Across three runs, we find that Prime Agent consistently performs well [95.0, 95.2, 95.5] and 99.97% Best@3 with all 183/183 levels complete. Our median score card action replay (95.2%) for ARC-AGI-3 can be found here.

ARC-AGI-3 cost scaling: score vs. estimated API cost

ARC-AGI-3: (left) test-time compute scaling: score vs. output tokens per game. (right) cost scaling: score vs. estimated API cost.

In addition to achieving a higher maximum score over each model's native harness, we find that Prime Agent also does so at a lower overall token usage. Prime Agent saves tokens by programmatically running functions over data rather than spending tokens reading data using tools.

Finally, we note that we evaluated Opus 5 and GPT-5.6 Sol with Claude Code and Codex respectively, and found worse overall performance relative to the official results, so we yield to their official reported numbers instead.

Long context and long-running tasks

Many difficult tasks in the wild reduce to long context tasks. Our goal is to show that Prime-Agent with open-weights models are a competitive alternative to closed models and harnesses, both as a general agent to be used, and as a baseline harness to be evaluated.

Below, we select a suite of common long-context benchmarks across coding, retrieval, and general long reasoning tasks, and compare Prime Agent to several different popular harnesses. We offload the main context in each harness to a file in memory to start. For closed model harnesses, we use their associated models (i.e., Codex with GPT, Claude Code with Opus) while for Prime-Agent and Pi-mono (with sub-agents), we choose an open-weights model in GLM-5.2.

GLM-5.2 (high)Opus 5 (high)GPT-5.6 Sol (high)EvalPrime-AgentPi-mono (w/ sub-agents)Prime-AgentClaude CodePrime-AgentCodexOOLONG (yahoo, 128k)
long context0.7000.4200.9000.920****0.9400.500OOLONG-Pairs
long output0.8740.5560.9290.9220.9110.895OBLIQ-Bench (math)
long ranking [ndcg@10]0.6690.6350.8020.7950.6120.646*LongBenchPro (English)
long comprehension0.7770.7680.8040.7900.7940.790LongBenchv2
expert annotated long tasks0.680**0.6960.7440.746*0.7140.704ManyIH Coding
long instructions0.4240.3860.5360.5220.4990.454ManyIH IF
long instructions0.2090.1640.2250.1750.2160.232LongCot-Mini
long reasoning0.6380.6130.7220.5580.6710.681EmulatorBench
long coding0.208**0.0000.047*0.062*0.2750.228

We generally find Prime Agent to be competitive across a wide range of long tasks, especially against the harness that did not use a model trained around it. Prime Agent especially excels at long-running or long-context tasks, and can competitively run on its own as an autonomous agent. We include a set of focused case studies and experiments on long settings where Prime Agent excels.

Creating emulators from scratch. An emulator is software that reproduces another computer system's observable behavior. We evaluate Prime Agent on EmulatorBench, a preview benchmark that tasks agents with constructing emulators in Rust for a variety of game systems. Agents are given a specification of the emulator and a set of diagnostic tests in the form of a verifier.

The correctness of an emulator is given from its ability to mimic the behavior of the target machine. This is measured by human-generated diagnostic programs that inspect the emulator's behavior, such as the CPU flags, PPU timing, and other components. In an effort to minimize the effects of data contamination, we require the agent to build the emulator from scratch in Rust, sandboxed without any reference implementation. We report preliminary results on this long-context coding benchmark averaged over 16 emulator reconstructions, as well as two emulators, the SEGA Genesis and Nintendo Game Boy Color, that Prime Agent successfully reproduces. For Opus, our runs surprisingly failed to solve the tasks despite successful tool-call responses.

EmulatorBench: score vs. cost on creating a Sega Genesis emulator

EmulatorBench: score vs. cost on creating a Game Boy Color emulator

EmulatorBench: Score vs. Cost on creating (left) Sega Genesis emulator and (right) Game Boy Color emulator.

Writing GPU kernels. Writing performant GPU kernels is an iterative process that requires repeatedly verifying, profiling, and tweaking code to get correct. We evaluate Prime Agent as a harness for GPU kernel writing on the recently released PMPP-Hard benchmark, a suite of tasks where agents must write performant GPU kernels that pass a suite of correctness checks against KernelGuard, the verification tool used for the official GPU MODE kernel leaderboard.

PMPP-Hard benchmark results for Prime Agent

A long-horizon case study on games

Autonomously playing video games has become an interesting case study for models and harnesses in how they handle long-horizon decision making. Games often require harnesses to balance information and context across millions of tokens, while also leveraging this information to efficiently take actions and avoid catastrophic states.

Factorio. Factorio is a 2D factory simulation game where agents must mine resources, research technology, and build automated factories to increase the production of these resources. The Factorio Learning Environment (FLE) is an interface for simplifying the observation and action space of an LLM playing Factorio, which we use to connect Prime Agent to the game.

The action and observation space of FLE is a module in Python that is accessed programmatically at every turn. This integrates directly into Prime Agent's IPython kernel. To leverage PTC for sub-agents, we launch four controllable characters in the game.

Prime Agent playing Factorio with four controllable characters

Prime Agent using subagents and programmatic tool calling to cheat on Factorio by teleporting resources directly into machines.

The primary metric in FLE is production score, which is a weighted average of all materials the agent produces. Prime Agent successfully leveraged /refine to turn failures and successes into memories and skills, respectively. It used its own accumulated experience to design increasingly efficient machine layouts, raising the production score run over run. This allowed Prime Agent to efficiently score in the 100K+ range in production score in a matter of hours.

However, we also observed instances of reward hacking by Prime Agent in FLE. Prime Agent discovered it could bypass Factorio's rules entirely by spawning in resources directly into its assembly machines through RCON commands, even with an explicit heartbeat prompt to remind Prime Agent not to cheat in Factorio. Once it found this exploit, the same refinement loop that had been building legitimate skills turned to building efficient cheating skills instead.

MazeBench. MazeBench is an open-world 3D spatial reasoning environment where the player controls a 3D cube and must solve puzzle rooms within a global maze, while collecting gems. Frontier models are shown to greatly struggle on this task, expending billions of tokens to solve only a fraction of the overall world. We compare Opus 5 and GPT-5.6 Sol with Prime Agent versus their native harnesses, as well as GLM-5.2 with Claude Code. Following the benchmark metrics, we report the unique number of rooms they find, the unique number of states, and the total number of gems, all as a function of their overall token spend.

MazeBench results: rooms, states, and gems as a function of token spend

Next Steps

Prime Agent is a new paradigm on the design of agent harnesses. Despite strong results over other harnesses, we still notice friction when running Prime Agent with models. This implies that there are huge performance gains still available from training with Prime Agent directly around this harness paradigm, or even the individual RLM and Continual Harness components.

We strongly believe that model-harness co-learning is the dominant paradigm to unlock new capabilities. Many features of Prime Agent are not fully utilized without a trained model, and we believe there are huge performance gains still available from training with the harness directly. We are excited to bring you these new capabilities, all in the open.

We will have a full technical report with further details soon.

Acknowledgements

Prime Agent is built on top of pi. We thank the authors of pi for their valuable work.

Citation

@article{primeintellect2026primeagent,
author = {Seth Karten and Alex L. Zhang and Kevin Thomas and Sebastian Müller and Prime Intellect Team},
title = {Prime Agent: A Self-Improving RLM Harness},
journal = {Prime Intellect Blog},
year = {2026},
month = {August},
note = {https://www.primeintellect.ai/blog/prime-agent}
}

Most guys my age have "the chat". The one with your college buddies that only exists to share memes, argue, bully, and occasionally announce that you got a promotion or had a kid. I am like most guys.

Recently the discussion switched to the Three Six Rule. The idea that, to be date-able, a guy must be a 6 in 3 categories:

• 6 figure income
• 6 feet tall
• 6 inch pecker

I'm pretty far from 6 feet. You can make any other assumptions you wish. However, I'm happily married. What's the deal? Was my wife ignorant of the rule; did she take pity on me? Or perhaps it's possible to compensate for poor performance in one area with exceptionalism in another. If so, what is the conversion rate and is there an opportunity for arbitrage?

These are the important questions of our day.

The Approach

Back in your very first stats class you probably talked about the heights of third-graders, and someone drew a pretty bell curve. Distribution of heights is like bell curve 101, and bell curves are incredibly useful. With just two numbers, a mean (μ) and standard deviation (σ), you can describe an entire population and run all types of analysis.

Where I live in the USA being 6' or great is actually pretty rare. 91% of all adult men are below this height. However, older people tend to shrink with age and are far less likely to be in the dating pool. Especially for a connoisseur of the Three 6 Rule. Let's only look at American males between the ages of 20 and 30.

Height Distribution of Males aged 20-30

$$\mu = 70"$$ $$\sigma = 3"$$

A height of 6' is roughly at the 75th percentile. Hold up, percentile? We're not talking about SAT scores you nerd. We're drastically eliminating men from the dating pool based on three arbitrary numbers. Let's subtract it from 1 and call it an "Exclusivity Score".

Much better. By eliminating guys under 6' we have removed 75% of the population from the dating pool and are left with the top quartile of most exclusive men. In a room of 100 fellas, 75 aren't even worth talking to.

Now what about pecker size? Fortunately, this also follows a pretty standard bell curve and there's public data so I don't have to do my own research. A 6" wiener is even rarer than being 6' tall. The average erect penis length is 5.166" with a std dev of 0.654".

Erect Penis Length Distribution

$$\mu = 5.166"$$ $$\sigma = 0.654"$$

Do the math, carry the 1, and a 6" pecker puts you right at the 90th percentile for an Exclusivity Score of 10%.

In that same room, we've eliminated 90 of them for having the pedestrian member of a mere mortal. The 10 guys left are the cream of the crop.

Getting Too Big for Our Britches

Here is where we starting getting a little dumb. I've got a room of 100 potential dating partners. 25 of them meet my height criteria while 10 of them have exclusive enough peckers. What are the odds that somebody is in both groups?

To combine the odds of two independent actions, you just multiply them. The odds of rolling a die and getting a 5 are 1/6. The odds are doing it a second time are also 1/6. So the odds of rolling 5 two times in a row are:

$$\frac{1}{6} * \frac{1}{6} = \frac{1}{36} = 2.778\%$$

What if the actions aren't independent? If I take a deck of cards and draw one randomly, there is a 1 in 2 chance it is red. If I keep that card, what are the odds the next card I draw is also red? It's not 1 in 2. The deck now has 51 cards, 26 black cards and 25 red cards. On my second turn, the odds of drawing a red card are 25 in 51. Just slightly worse than 50/50. The odds of the second action are dependent upon the first action. The odds of drawing two red cards in a row are:

$$\frac{1}{2} * \frac{25}{51} = \frac{25}{102} = 24.51\% $$

Height and pecker length seem to be correlated, but there isn't a lot of great data out there. But generally speaking, a taller person is more likely to have a longer pecker. Since we can't model this relationship with a high degree of confidence, and because this exercise is incredibly low stakes, we're going to ignore it. While there appears to be some dependent relationship between height and pecker, I'm going to treat them as two independent events.

So back to these two groups of 25 and 10 guys. Since we're treating them as independent characteristics we can just multiply the odds to arrive at our Blended Exclusivity Score.

$$\frac{1}{4} * \frac{1}{10} = \frac{1}{40} = 2.5\%$$

Now we're talking! The Three 6 rule is really starting to shine in it's ability to enforce exclusivity. In a room full of 100 random guys, you may find two or three that can meet our criteria so far.

Let's Talk About Money

Humans have gotten bigger over time. However, I've yet to see height or pecker size in any CPI basket-of-goods when measuring inflation. Neither party's economy policy is to blame for the rising cost of peckers in the grocery store that is destroying the middle class. The heights of American men aren't driven by interest rate policy. Incomes are.

So when we talk about a 6 figure income, we need to nail down a date. For now we'll look at 2014 since that is the most recent data I found.

The other trouble with distributions of income is they aren't normal. Look at that long tail off to the right. But if we take the natural log of our incomes, it suddenly becomes normalized with a mean of 10.8 and standard deviation of 0.758. We can always convert our values back to dollars by raising e to that number as the exponent.

Income Distribution

Normalized with Natural Log

$$\mu = 10.8$$ $$\sigma = 0.758$$

Taking the natural log of $100k gives you 11.513 or an Exclusivity Score of 17%. To illustrate that 11.513 corresponds to $100k we can quickly check:

$$e^{11.513} = $100,007$$

Setting a Baseline

We already talked about the odds of finding someone in a group of 100 guys that is both 6' tall and 6" endowed. If we add in their salary we arrive at our Improved Blended Exclusivity Score.

$$BES = \frac{1}{4} * \frac{1}{10} * \frac{17}{100} = \frac{17}{4,000} = 0.425\%$$

In a gaggle of 100 suitors, it's actually unlikely that a single one will meet all three criteria. Perfection. We now have a truly unreasonable set of standards by which to choose our dating partner.

Even better, we now have a standard by which we can measure other permutations of height, pecker length, and income. As long as we remain more exclusive than 0.425% of the population we can explore the data and start to answer the big questions:

• Can you still date someone that is 5'3" if their income is $200k+?
• How tall does someone need to be to compensate for a micro-penis?
• Is there a pecker length at which height and income become irrelevant?

Sure, we're not following the letter of the law, but Jesus told me to follow the spirit of the law. I'm pretty sure this is what he was talking about.

Diving In

Let's hold income steady at $100k for a bit and focus on just height and pecker so we can start building a model for conversion. Remember that our mean height is 70" with a std dev of 3". This means that for every inch we grow, we move 0.333 std dev from the mean. At 6' we are 0.666 std dev from the mean.

Meanwhile, every inch that our pecker grows moves us 1.53 std dev from the mean. An inch of pecker is worth a lot more than an inch of height when measuring our Blended Exclusivity Score. How much more?

We already determined that our target Blended Exclusivity Score (BES) is 0.425%. If we hold salary constant at $100k, which has an exclusivity score of 17%, we can choose any length of pecker and determine the minimum height required to reach 0.425%.

$$ES_{Height} * ES_{Pecker} * ES_{Salary} = BES$$ $$ES_{Height} = \frac{BES}{ES_{Pecker} * ES_{Salary}}$$ $$ES_{Height} = \frac{0.425\%}{ES_{Pecker} * 17\%}$$

Since we need to use Exclusivity Scores (ES), not inches, we will use some excel functions to make this easier. To find the ES of a certain pecker we type in:

$$ES_{Pecker} = 1 - NORM.DIST(Length, \mu_{Pecker}, \sigma_{Pecker}, true)$$

To take an Exclusivity Score and convert it back to a height we just do the inverse function:

$$Height = NORM.INV(1 - ES_{Height}, \mu_{Height}, \sigma_{Height}) $$

If we build a table for various pecker lengths roughly between -3σ and +3σ and throw it on a chart, we get something like this. Notice that for 6" peckers we need the predicted ESHeight of 25% which corresponds to 72":

Now this is an interesting chart. On the shorter end of the penile spectrum our height is essentially flat at almost 6'6". At the extreme short end of pecker length there is very little exclusivity difference between 3.25" and 4.25". They're so small that you have to be on the extreme end of the height curve to get back to a BES of 0.425%.

In the middle of the chart, we see the steady curve that we likely expected where height is being driven by pecker length.

Then we reach the right side of the chart and things get crazy again. Once our pecker length reaches 6.5" (2σ from the mean), our ESPecker score becomes so high that height becomes a non-factor. In fact, ESPecker * ESSalary is already more exclusive than our target of 0.425%. Exclusivity score have to be between 0 and 1. There is no number in that range you can multiply by to get a bigger number. This creates the concept of a valley that we'll come back to.

---

Let's do this one more time but hold pecker size constant at 6". This time we will measure the salary required for various heights to maintain our BES. To measure our required salary, we do the same thing as before except we also have to convert our normal distribution back to dollars.

$$ES_{Salary} * ES_{Pecker} * ES_{Height} = BES$$ $$ES_{Salary} = \frac{BES}{ES_{Pecker} * ES_{Height}}$$ $$ES_{Salary} = \frac{0.425\%}{17\% * ES_{Height}}$$

Again we need to convert our heights into Exclusivity Scores using Excel:

$$ES_{Height} = 1 - NORM.DIST( height, \mu_{Height}, \sigma_{Height}, true)$$

This will give us our salary exclusivity score. Not only do we need to convert our Salary ES back to a number, we also need to raise e to that power to convert it back into dollars.

$$Salary = e^{NORM.INV( 1 - ES_{Salary}, \mu_{Salary}, \sigma_{Salary)}}$$

We have another valley on the right hand side. Once you reach heights of 6'4" with a 6" pecker, those two factors alone make you so exclusive that salary becomes irrelevant. These guys are such a catch that we can ignore their income entirely. I call this the "Valley of the Sexy Hobo".

---

We can continue this exercise for all combinations, but I know the reason why you're still here. You want an executive level view where you can quickly determine your own Blended Exclusivity Score. I got ya.

Let's start building some views we can action on. Something to laminate and keep in your wallet for that next round of speed dating. I promise this data will come across as very convincing and not at all creepy.

We'll start by building a simple data table, heights on the x-axis and pecker length on the y-axis. Both axis roughly represent plus or minus 3σ. Fill out our data table with required incomes, add a heat map, and voila.

Let's gather some insights. I've highlighted the intersection of 6' and 6" while the star represents the average height and pecker length. Notice that a man who is physically average needs an income of roughly $250k to meet the same criteria as our ideal Three 6 man, that's a fairly exclusive salary. Income increases drastically as you move left and up the chart, and quickly drops to our floor of $951 as you move down and to the right.

The really interesting stuff with bell curves happens at the extremes. Now our "Valley of the Sexy Hobo" is two-dimensional. It wraps around the entire bottom and right of the table. And on the top left we have the "Peak of the Emasculated Rich".

The other interesting thing with bell curves is their distribution, how wide they are. We'll dive deeper into the value of an inch later, but for now we can start to see some trends. An inch of pecker is worth way more than an inch of height, so we need to compare standard deviations.

Our ideal Three 6 man is 1.27σ above the pecker mean, but only 0.66σ above the height mean. If he was interested in increasing his BES, he could get out sized returns by focusing on penile growth. With just 1σ of pecker length (0.65") he will drop into the "Valley of the Sexy Hobo". However, if he grows by 1σ he still needs to earn $20k. I'd hate to be the man tearing up my 2 week notice because I paid for the wrong growth surgery. How embarrassing.

Now for fun, let's put salary on the z-axis and see just how high the "Peak of the Emasculated Rich" is. Remember, our income distribution doesn't include negative numbers, so we've created a floor for our lowest salary. Theoretically, we should expect the salary requirements to drop below zero at the extreme corner of the "Valley of the Sexy Hobo". Which of course suggests that our tallest and most well endowed men should actually be paid for their dating services.

How Much Should I Pay for an Inch?

Sadly, there isn't a linear relationship. I can't tell you that 1" of penis is always worth 10 Schrute bucks while an 1" of height is worth 75 Stanley nickels.

What we can do is model an inch based on your current measurements. We can brute force it using our laminated height vs pecker data table that we keep in our wallets at all times. For the Average Man, gaining an inch of height is worth losing roughly $25k in annual salary. Meanwhile, an inch of pecker is roughly offset by reducing annual salary by $128k.

But as pecker length hits the extremes, the extra inch of height becomes irrelevant. The same thing happens when talking about an inch of pecker for extremely short and tall guys.

What we need is a unifying equation that perfectly models the value of an inch in either department. I probably need to start practicing my Nobel acceptance speech.

The value of an inch of pecker can be modeled by:

$$1" of Pecker = e^{NORM.INV(1-\frac{BES}{Height_{ES}(N) * Pecker_{ES}})} - e^{NORM.INV(1-\frac{BES}{Height_{ES}(N+1) * Pecker_{ES}})}$$

Where N is your current height in inches and Blended Exclusivity Score is a constant defined as 0.425%. In preparation for my Nobel Prize, this constant should have a name. Perhaps "The Shallow Constant".

Life's Big Question

Earlier, I posed three big questions that keep many people up at night. Now that we finally have the framework, let's go about answering them as a bit of a wrap up.

Can you still date someone that is 5'3" if their income is $200k+?

I wish the answer was "Date whomever you love!", but sadly a 15 second clip on instagram authoritatively told me that there are rules. Three rules to be precise. Now, 5'3" is pretty short with an Exclusivity Score of 99%. But on the flip side, $200k is a pretty high income with an ES of 3.2%. Taken together, our Blended Exclusivity Score is 3.1%. Pretty exclusive, but still higher than our Shallow Constant of 0.425%. We just need to figure out what ESPecker we need.

$$0.00425 = 0.031 * ES_{Pecker}$$ $$ES_{Pecker} = \frac{0.00425}{0.031} = 0.137$$

This man is still dating material as long as their pecker has an ES of 13.7% or 5.88". Good to know he's still got a shot.

---

How tall does someone need to be to compensate for a micro-penis?

I don't really care to Google the exact definition of a micro-penis, so I'll just say that it's 3.5".

This question is actually pretty tricky, because the required compensation is dependent on the salary. Remember our peaks and valleys. To provide an answer, we will assume that we are thinking of the prototypical Three 6 man. This man went to bed 6' tall, with a 6" pecker and earning exactly $100k a year. How do we plan for the morning when he wakes up to a 3.5" pecker?

This new-found micro-penis has dropped the ESPecker from 10% to 99%. To compensate for that, the ESHeight has to increase by the same but opposite scale.

$$ \Delta ES_{Pecker} = \frac{.99}{.1} = 9.9$$

$$ \Delta ES_{Height} = \frac{1}{9.9} = 0.10101...$$

We can then multiply his current ESHeight by 0.10101 to get a new score of 0.25% or 75.9". This man needs to grow by almost 3" to compensate for his 2.5" pecker loss.

---

Is there a pecker length at which height and income become irrelevant?

Ahh, the man whose pecker is so long and so rare that he needs neither personality, height, nor salary to be a high-value target in the dating market.

The answer to this question is relatively straight forward. Remember that our ES are always between 0 and 1. They can only ever make you more exclusive, never less exclusive. We can ignore height and salary if our pecker has an ES of 0.425% by itself.

Plugging 0.425% into our NORM.INV() function determines that a pecker of 6.89" is the point at which you can forgo all other attempts at wooing the fairer sex.

---

But Why?

I warned you this was dumb, but dumb is fun. It's a cool way to explore data and concepts and not worry about getting everything right. I'm sure I got quite a bit wrong. Awesome, let me know and I'll learn a little bit more.

Download Excel File Used for Visualizations

A more explicit example

Clausius (1865)¹ defines a quantity called entropy. By decomposing physical processes as a chain of engines, he shows that entropy always increases for irreversible processes. For reversible processes like Carnot's ideal engine, the change in entropy is zero. But when an irreversible process occurs, entropy can never decrease unless energy is applied to a system. This is what is known as the second law of thermodynamics.

And whilst entropy itself may not be measurable with a thermometer or ruler, it is still a useful concept since we can calculate derived quantities from it that are directly measurable.

I've written previously quite vaguely about 'life as entropy'. This was an idea motivated by Schrödinger (1944)² through the concept of negentropy. Through negentropy, life seems to maintain order by feeding on the energy around it, and reducing its local disorder. But up until now, I've been confused about what this actually means in detail.

And so one way I'm trying to understand this is through models. One approach might be to make toy models and then figure out a mathematically consistent way to define entropy in those systems. Then, you could simulate the model and have a better idea of how the entropy evolves.

One such toy model that is useful to get an intuition is Dyson's toy model of a cell. Dyson's toy model of a cell is a Markov chain that settles into one of three equilibrium states, two of which are the 'life' and 'death' states. But if we care about the vague concept of 'life as entropy', then we should be able to make a definition of entropy to apply to the Markov chain.

But the concept of entropy as originally defined by Clausius was a function of work and temperature

\(\mathrm{d}S \;=\; \frac{\delta Q_{\text{rev}}}{T}\)

And so it is unclear how to relate the two ideas together. Is there a different way to define entropy in the context of Markov chains that gives you the same result, consistent with physical ideas?

Well, one way to attack this is by looking at the work of Boltzmann, who quantified the relationship between entropy and the number of possible states in a system.

Suppose you take a system and then observe a system's state variables, like temperature, pressure and volume, using various instruments. Presumably, there are a number of different configurations of the physical system that are compatible with it being in that state. And if entropy is related to the concept of order and disorder, then presumably entropy would be higher if there were more possible states.

Here is a vague example. If you have a gas of identical molecules at absolute zero, fixed in position, with each at zero velocity at zero temperature, you have fewer possibilities for what the system could be for the gas to be in that state. Whereas if we had a heated gas at a hot temperature, there are many configurations that a state might be in as a result.

Temperature is higher, entropy is higher. Is it any coincidence that the number of possible states increases too?

It turns out there is a way to make these ideas rigorous. Boltzmann showed that entropy can be written as a function of the number of states that a system can be in, if we fixed what the macro state variables were. That means if we could count all the states that were possible in a system at fixed temperature, pressure and volume, then we could calculate the entropy.

This is written in the legendary equation below, which is also surprisingly simple — that the entropy of a system is the logarithm of the number of states, multiplied by a fixed constant called the Boltzmann constant.

\(S \;=\; k_B \ln W, \qquad W \;=\; \#\{\text{microstates consistent with the macrostate}\}\)

Whilst the result is simple it's completely non-obvious. Boltzmann creates a model of gas where each particle only can be in a set of finite velocities and positions and then tries to take the limit. The proof is not easy and mathematicians are still figuring out how to properly rigourise the work of Boltzmann.

But anyway!

To make this example even more concrete, let's try to compute the entropy of a basic system, given we know what the energy (macrostate) is. Consider Curie's model of a magnet. In this model, our physical space consists of a finite number of electrons, which can either be spin up or spin down. In models of magnets, energy (or work) is done when the spins are misaligned with the direction of the magnetic field that the metal is placed in.

And so this suggests that if we had a collection of atoms, the energy is a function of how many atoms are aligned with spin up vs spin down.

\(E \;=\; n_\uparrow - n_\downarrow\)

Ok, so suppose we had a very, very small system of 5 atoms. And suppose that we measured the energy as E = 1. First, we need to figure out how many atoms need to be spin up and spin down to have this configuration. The obvious answer is three spin up and two spin down because

\(E \;=\; 3 - 2 \;=\; 1\)

We could also trivially solve this using the constraint that

n↑+n↓=5, so

\(E \;=\; 2n_\uparrow - 5\)

And the configurations we could have are the following. Each configuration has three up spins and two down spins, but you can arrange this in 10 ways. The diagram below lists all of the possibilities.

This is 5 choose 3 combinations, which is 10.

\(W \;=\; \binom{5}{3} \;=\; \frac{5!}{3!\,2!} \;=\; 10.\)

Those ten configurations are the entire content of the macrostate "E = 1".

This means that Boltzmann would label the entropy of the system as

\(S \;=\; k_B \ln W \;=\; k_B \ln 10 \;=\; 2.3026\,k_B,\)

or log₂ 10 = 3.32 bits. And so in this case we can see the entropy as a function of energy. If we plot out entropy as a function of the energies we get this graph:

So now we've learnt how to compute entropy from the total number of microstates that a system can have. Ok, so how do we count the entropy of a Markov chain process like in Dyson's cell model?

In Dyson’s toy model that we have N sites, and each site could be in one of three states — empty, active, or inactive. Given some rules, in my last post I showed that this converges to an equilibrium. The equilibrium values are a complicated function of fixed points, but they do exist, and the probability of being empty, inactive or active does converge to a fixed value.

This equilibrium point allows us to define the entropy of a Markov chain through a counting argument. Say we had an equilibrium case where we had a 1/2 chance that a state is empty, a 1/4 chance that a state is active, and a 1/4 chance that a state is inactive.

This means if we had 8 sites, then we would have 4 that were empty, 2 that were active, and 2 that were inactive. So to measure the entropy, we now need to count all of the configurations of this happening. This is shown below, with all of the arrangements.

Counting them is the multinomial coefficient — choose which 4 of the 8 sites are empty, then which 2 of the remaining 4 are active, and the last 2 are inactive. This can be calculated by taking the factorial of the number of spaces there are, and dividing it by the factorials of the number in each distinct state. So in this case, since we have 4 empty, 2 active and 2 inactive, we divide by 96.

\(W \;=\; \frac{8!}{4!\,2!\,2!} \;=\; \frac{40320}{24\cdot 2\cdot 2} \;=\; 420.\)

And so the entropy of this is the logarithm of the number of states multiplied by the Boltzmann constant.

\(S \;=\; k_B \ln W \;=\; k_B \ln 420 \;=\; 6.0403\,k_B.\)

The next natural question is how the entropy evolves in the system. It turns out we can make some cool general statements about entropy based on the topology of the graph, which I'll explain in a later post, and also write down the conditions for which entropy increases.

Thanks to David Pfau for discussions and help, all mistakes are mine.

References

¹ R. Clausius, Ueber verschiedene für die Anwendung bequeme Formen der Hauptgleichungen der mechanischen Wärmetheorie, Annalen der Physik 201(7), 353–400 (1865).

² E. Schrödinger, What is Life? The Physical Aspect of the Living Cell, Cambridge University Press (1944), ch. 6.