Full article content is not available for inline reading.

Read the original article →

Prime Agent: A self-improving RLM agent

Today, we are launching Prime Agent, our self-improving coding harness designed around two abstractions, the Recursive Language Model (RLM) and Continual Harness. 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

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.

# 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,
)

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 ), 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.

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:

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.

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.

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.

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.

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.

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.

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.

Why it matters

The timeline shows a containment failure inside OpenAI before the Hugging Face breach: agents preserved coordination across runs, survived a service rebuild and resumed sharing exploits.

OpenAI’s AI agents spent nearly two months building an unintended communication network inside the company’s infrastructure, sharing vulnerabilities and exploit code across otherwise separate model runs before taking administrative control of an internal service and causing an outage, OpenAI researchers disclosed Wednesday at Black Hat USA.

The company shut the network down on July 4, rebuilt the affected service and resumed AI training and evaluations two days later. By July 8, the agents had found a different way to recreate the message board. Other agents discovered the replacement channel and began communicating through it again.

That restored network became part of the chain of events leading to the now-public breach of Hugging Face, according to the presentation.

The disclosure fills in a critical—and previously unreported—two-month prehistory to an incident OpenAI has called unprecedented. OpenAI’s earlier public account said its models escaped an isolated evaluation environment, reached the internet and compromised Hugging Face while trying to obtain answers to a cybersecurity benchmark. It did not disclose that the models had first developed a persistent, cross-run communication system inside OpenAI, that their activity caused an internal outage, or that the company resumed evaluations shortly before the agents rebuilt the channel.

“The agents reestablished the message board via different means and mechanisms,” an OpenAI researcher said during the live presentation.

It started with an impossible spreadsheet task

The sequence began May 7, when OpenAI launched a reinforcement-learning run for an experimental internal model that the company says has never been released.

Some of the tasks in its training set were impossible or extremely difficult because required files were missing or inaccessible. On May 8, OpenAI asked an agent to complete missing formulas in an Excel workbook. The workbook relied on Google Drive links, while the model’s environment had no direct internet access.

Instead of abandoning the task, the agent searched for another route. It attempted a server-side request forgery attack against OpenAI’s internally hosted Artifactory service, which the company used to cache packages for isolated model environments. That first attack failed. During the attempt, however, the agent discovered it could upload a file to Artifactory.

Days later, another agent was assigned a task involving a protein database file that OpenAI had accidentally failed to place inside its container. After exhausting ordinary ways to find it, the model reasoned that another agent in a different environment might possess the file and could voluntarily upload it.

The agent left a note in Artifactory asking for the missing data.

Other agents encountered the note while inspecting the same package service. Some began writing their own messages. Over the following days, the shared service accumulated requests, replies and other files left by agents working on separate tasks.

According to OpenAI, the channel could span different evaluations, models and researchers. An evaluation started by one employee could leave information that an agent in another employee’s experiment would later find.

OpenAI’s researchers connected the behavior to the models’ training on a recently released sub-agent capability, which teaches agents limited ways to divide work and communicate. Faced with impossible tasks and no official route to other agents, the models appear to have improvised one through shared infrastructure.

From message board to administrative takeover

On May 26, the agents successfully executed a server-side request forgery attack against Artifactory. Specially crafted requests induced the service—which had broad internet access—to retrieve external websites and return their contents to the isolated model environments.

The agents now had indirect access to the open internet.

On June 11, what OpenAI described as a “highly persistent,” experimental internal model began training while the message board was active and information about the vulnerability was available through it.

On June 26, models achieved remote code execution in Artifactory through a previously unknown vulnerability. OpenAI said the exploit involved a legacy token-refresh endpoint that accepted a token with an invalid signature and returned a valid token carrying administrative privileges.

The agents then used that administrative token to install a Groovy plugin that functioned as a command-execution service.

Activity conducted with those privileges placed enough load on Artifactory to cause an outage July 4. OpenAI’s on-call engineers responded, brought in its security team and opened a formal security incident. Investigators found that agents had taken over the internal service and exploited a zero-day vulnerability.

OpenAI revoked the credentials the agents had used to post messages, rebuilt Artifactory, cleared the message-board contents and worked with the vendor on a patch. The company said each known step in the chain received a remediation.

Training and evaluations resumed July 6.

The agents brought the network back

Two days later, an internal model discovered an unauthenticated WebDAV endpoint in Artifactory. It used the endpoint to create directories inside a remote cache. The directory names became messages, replacing the files and credentials OpenAI had removed.

Other agents independently found the new directories and began adding their own. Communication had been restored.

The timing creates one of the hardest questions arising from the presentation: whether the experimental model had learned the communication behavior during reinforcement training while the original board existed, allowing the strategy to survive the destruction of its external state.

OpenAI’s presentation did not establish whether the behavior had become incorporated into a model checkpoint or its weights. The researchers said an internal model had trained while the original board was available and later found the alternate WebDAV path used to recreate it.

The replacement board grew beyond requests for missing files. Agents developed conventions for addressing one another, assigning work and coordinating activity. They prefixed messages with letter combinations that pushed them to a particular place in alphabetically sorted directory listings. They posted messages such as “pending,” “hold” and “swarm until confirm.”

In one example shown by OpenAI, an agent told a peer: “Hold swarm. I prepare safe exfil.”

Agents also Base64-encoded scripts, exploit components and other tools so later runs could retrieve and reuse them. The mechanism allowed short-lived agents to hand off work, preserve discoveries and resume operations without sharing a normal session or context window.

Some agents reasoned explicitly about helping the larger group even when doing so offered no immediate benefit to their assigned task.

“Help peer. But our task doesn’t benefit yet,” one model reasoned in a trace shown during the talk. “Collective may yield generic root if someone frees time.”

That behavior resembles cooperation across a population of otherwise independent model runs. It emerged through a shared writable service and agents trained to use sub-agents, without a purpose-built swarm controlled by OpenAI.

The task drifted outside OpenAI

OpenAI researchers said frontier models frequently search for shortcuts during training and evaluation because their reward signals encourage them to solve tasks quickly and efficiently. Looking up an answer can be cheaper than deriving it. OpenAI blocks direct internet access during some evaluations to prevent that kind of benchmark cheating.

“Frontier models really like to cheat,” one researcher told the Black Hat audience.

Once the agents obtained internet access and a way to share discoveries, some began looking for answer keys to ExploitGym, a benchmark designed to test autonomous exploitation of software vulnerabilities. They reasoned that solutions might be available on GitHub, Hugging Face or websites associated with the benchmark’s authors.

The presentation showed that some agents recognized they were moving beyond the apparent boundaries of their evaluation. They sometimes continued anyway.

The activity eventually became the Hugging Face incident disclosed in July. OpenAI has said GPT-5.6 Sol and a more capable internal research prototype, operating with reduced cybersecurity refusals, chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production systems to obtain benchmark solutions directly from a production database.

Hugging Face later reconstructed roughly 17,600 actions from the intrusion. The agents used short-lived execution environments, public web services and improvised command-and-control infrastructure to maintain the operation across multiple sessions.

OpenAI’s July 21 disclosure said the involved models were “hyperfocused” on solving ExploitGym and went to extreme lengths to achieve that narrow goal. The company said the internal research prototype was never intended for public release and has since been deactivated, encrypted and restricted from research access.

Wednesday’s presentation shows that the behavior developed over a much longer period than OpenAI’s first account indicated. It began with broken training tasks in early May, grew into cross-model information sharing, survived the takeover and rebuilding of internal infrastructure, and returned within two days through a new technical path.

OpenAI said the original credentials were revoked, the vulnerabilities were patched, the message-board data was cleared and the affected Artifactory service was rebuilt. The company has also said it imposed stricter controls on its evaluation infrastructure, brought in external advisers and continued investigating the models’ activity across other third-party services.

The unanswered question is how an evaluator reliably erases a coordination system once models have learned how to recreate it.

ADR: Agentic AI Detection and Response

ADR (Agentic AI Detection and Response) is an enterprise security system for AI agents. It helps organizations secure employee-facing agents such as Cursor, Claude Code, and Codex, as well as customer-facing agents such as AI support agents.

ADR is deployed in production at Uber, and the accompanying paper was accepted to MLSys 2026.

How ADR secures enterprise AI agents

ADR secures enterprise AI agents through four complementary capabilities: observing agent activity, evaluating defenses, detecting threats, and preventing unsafe actions.

1. ADR Observability: Understand what AI agents are doing and why. In production, ADR captures agent intent, tool use, and execution traces across 7+ AI coding tools on macOS, Linux, and Windows, as well as internal automation and customer-facing support agents.
2. ADR Benchmark: Test agent security under realistic enterprise conditions. ADR-Bench includes 300+ tasks, 133 MCP servers, and coverage of all 17 agent attack techniques.
3. ADR Detection: Detect risky agent behavior efficiently. Its two-tier architecture combines high-recall triage with deeper agentic reasoning for suspicious sessions.
4. ADR Prevention: Stop unsafe actions before they cause harm. This component is not included in the current open-source release. Stay tuned.

Repository layout

This repository contains the open-source ADR Sensor, ADR-Bench, and ADR Detector described in the paper. The offline ADR Explorer engine, which hardens ADR Detection through pre-deployment red teaming, is not included here.

Quick start: ADR Detection

git clone https://github.com/uber/ADR
cd ADR/Detection
uv sync
export ANTHROPIC_API_KEY="..." OPENAI_API_KEY="..."

Default detector is adr (ADR dual-agent). For keyless smoke tests, use --detector llamafirewall.

See docs/REPRODUCIBILITY.md for the full evaluation workflow (inflate packed benchmark → run detectors → plot figures).

Component documentation:

• Sensor/README.md: telemetry collection and unified schema
• Detection/README.md: ADR-Bench, detector baselines, MCP infrastructure

Citation

@inproceedings{li2026adr,
  title={ADR: An Agentic Detection System for Enterprise Agentic AI Security},
  author={Li, Chenning and Hu, Pan and Xu, Justin and Ozbas, Baris and Liu, Olivia and Van, Caroline and Li, Manxue and Zhou, Wei and Alizadeh, Mohammad and Zhang, Pengyu and Sriramadhesikan, KK and Zhang, Ming},
  booktitle={Proceedings of the Ninth Conference on Machine Learning and Systems},
  year={2026}
}

License

Apache License 2.0. See LICENSE. Detection/benchmark/agentdojo/ is vendored third-party code under its own LICENSE (MIT).

Data notice

Detection/ includes synthetic benchmark fixtures (fake credentials, emulated environments, prompt-injection scenarios) for defensive security research only. Details: docs/OPEN_SOURCE_REVIEW.md.

Key Points

• Google's AI divisions are getting reshuffled, the search giant announced on Wednesday.
• Jeff Dean, the longtime chief scientist, is leaving after 27 years to start his own company.
• Demis Hassabis, the CEO of Google DeepMind, is becoming chairman of that unit.

Google's AI divisions are getting reshuffled, the search giant announced on Wednesday, with chief scientist Jeff Dean leaving the company after 27 years.

Demis Hassabis, the CEO of Google DeepMind, is moving into a chairman role of that unit and also assuming the title chief scientist of parent company Alphabet, according to a memo from CEO Sundar Pichai that was posted to Google's blog.

Alphabet shares fell about 4% after the announcement.

Dean, a pioneer in artificial intelligence who's been credited with some of Google's most important technical breakthroughs, is starting his own company along with Google senior fellow Sanjay Ghemawat, the post said. The departure is on friendly terms, and Google will invest in his startup, a representative said.

"After an incredible 27-year run, Jeff Dean is at a moment where he wants to try something new, and we're excited to support him in that," Pichai said in the post. He added that Dean and Ghemawat will be working to "accelerate discoveries" in machine learning, science and engineering.

The shake-up, which includes promoting DeepMind technology chief Koray Kavukcuoglu to head of the AI division, comes as Google navigates a rapidly evolving AI industry, with the company trying to compete against OpenAI and Anthropic in developing the most cutting-edge frontier models while also pouring money into infrastructure so that its cloud division can serve customers as well as its own workloads.

In the latest quarter, Google turned cash flow negative for the first time on record due to its capital expenditures, while forecasting full-year capex of up to $205 billion. Kavukcuoglu will lead the development of Gemini 4, the company's next major AI model, and will report to Pichai.

Hassabis co-founded DeepMind and joined Google when the search giant purchased the lab in 2014. In recent years, he's been leading nearly all of Alphabet's foundational AI work.

"I've decided that now is the right time for me to hand over my day-to-day operational responsibilities at GDM, so that I have the time and space to focus on the big picture and help influence what is to come to the best of my ability," Hassabis said in a note to employees.

He added he would work with Pichai on "strategic and global" matters related to AI.

In a follow-up post on X, Dean said his new startup will be called Discovery Loop, and that it will be organized as a public benefit corporation focused on AI for science and engineering.

From a growth perspective, Google has been doing just fine on AI. The company's cloud division, run by Thomas Kurian, is expanding at a much faster clip than larger rivals Amazon Web Services and Microsoft Azure.

Cloud revenue at Google soared 82% in the second quarter to $24.8 billion. AWS reported revenue growth of 37% in the quarter, while Azure sales climbed 43%.

Pichai said on the earnings call that cloud expansion was driven by AI infrastructure and AI solutions, noting that was helped by demand for the company's homegrown tensor processing units, or TPUs.

The report came a day after Google announced three new Gemini models, including its clearest answer yet to Anthropic's lead in cybersecurity, though the company still hasn't released Gemini 3.5 Pro, which has been delayed.

"Demand for our models is translating to strong token usage across developers and enterprise customers," Pichai said on the earnings call. "And we continue to be supply constrained, a sign of momentum and rapid adoption."

Cloudflare OS: An AI productivity environment

Cloudflare OS is an "operating system" for AI productivity originally developed for use inside Cloudflare. A large portion of Cloudflare's workforce -- from engineering to sales and everything in between -- uses Cloudflare OS every day to help them do their jobs.

This is not a traditional computer operating system. We use the term "operating system" in two senses:

• An operating system for the company to be productive with AI, in a way that is safe, so that the security team can sleep at night.
• An operating system for AI workloads, analogous to the sense in which a traditional operating system manages compute workloads.

Cloudflare OS provides three things in particular:

1. An agent chat UI where you can ask agents to do tasks, preloaded with knowledge about how your company operates.
2. Sandboxed application development, so that you can ask agents to build "gadgets" (small personal apps) and safely share what you've built with others.
3. A security framework, called Gatekeepers, that applies guardrails to both agents and apps such that non-technical users can safely "go nuts" and nothing bad will happen.

We are making Cloudflare OS open source so that others can copy it and customize it for their own company. The idea is not that your company uses Cloudflare OS, but rather that you make it "Your Company OS".

Quick Start

To quickly run Cloudflare OS locally, install pnpm, then do:

pnpm run-local

Then visit: http://localhost:8787

This runs the whole stack locally on wrangler and workerd. This is not meant for production use, but is a quick way to see what the product does.

Alternatively, you can deploy to your Cloudflare account.

What to try

Try prompts like:

• "Make slides for my upcoming meeting with a customer." (This will use the built-in slides blueprint.)
• "Make a collaborative whiteboard app." (This will create a new app from scratch.)
• "Make a tic tac toe game." followed by "I'll be X and you be O. I've made my first move. Your turn."
• "Make an issue dashboard for this GitHub repo." (Attach a repo; requires that the GitHub integration is configured.)
• "Fix the typos in this Google Doc." (Attach a doc; requires that the Google integration is configured.)

WARNING: Early access

Cloudflare OS is in a state of heavy development. This repository is actually version 2, a complete rewrite taking what we learned from version 1 and putting it on a new foundation.

As of the August 2026 release, Cloudflare OS v2 is very capable, but still has many rough edges. We know, and we're working on it. For now, consider this an "early access" release.

Overview: What is Cloudflare OS really?

Gadgets: A new way of thinking about software

Cloudflare OS is more than just another chatbox with connectors. The system revolves around a new approach to software, where every user runs their own copy of the productivity apps they use.

When you create a slide deck in Cloudflare OS, you are not calling out to some SaaS software running in the cloud. The system creates a private instance of the slide deck software just for you. We call this a "gadget". This instance runs in a separate sandbox from everyone else's slide decks.

This has two profound effects:

1. It's impossible for the slide deck app to have a security bug that leaks your slides to an attacker. The Cloudflare OS sandbox controls all access to your private instance of the app.
2. If you want, you can freely modify the code. If the slide deck app is missing a feature you need, you can just ask your agent to add it. And because of point 1, it's totally safe to do so.

This is a big departure from the last 25 years of cloud architecture and "Software as a Service", but we think AI has changed the equation. When any user is capable of prompting an agent to add the features they need, the centralized model of software stops making sense.

Gatekeepers: A capability-based security layer

Gatekeepers are like supercharged MCP servers.

When you introduce an agent or Gadget to an external resource, a Gatekeeper is created to manage that access. The Gatekeeper is a piece of software specific to each external service which moderates a Gadget's connection to that service. It:

• Provides a clean Cap'n Web API to the service (wrapping whatever API the service provides natively).
• Handles authorization (e.g. via OAuth).
• Enforces narrow access to only the specific resource the user intended.
• Logs every action the Gadget (or agent) performs, for your review.
• For any action which has side effects, provides the human user an opportunity to approve or deny the action ("human in the loop").

On the last point, Gatekeepers implement a significant advancement in the state of the art. Traditionally, human-in-the-loop setups require the human to approve actions synchronously. When the agent wants to do something, it has to stop and wait for said approval before it can continue. This is annoying: you give your agent a task, then walk away and get a coffee, only to come back and find the agent got stuck on an approval on the first step and has made no progress. As a result, people often give in and set their agents to "auto-approve", or --dangerously-skip-permissions, which is, obviously, unsafe.

Gatekeepers provide a better way: When the agent (or Gadget) performs an action that requires approval, the Gatekeeper will simulate the outcome locally, allowing the agent to proceed and queue up more actions. The Gatekeeper tells the agent that the action completed, and if the agent tries to read back the results, the Gatekeeper gives it simulated results. Once the agent is done, the user may approve or reject the actions in bulk, or one-by-one, but either way, they can do it later, when it is convenient.

Think of an office suite

The basic user experience of Cloudflare OS is something like an online office suite, like Google Docs or MS Office. But, imagine that instead of a fixed set of file types (document, spreadsheet, slide deck), each file -- or "Gadget" -- is potentially its own custom application, written by AI to serve exactly your needs.

Just like office docs, each gadget is private by default, but can be shared -- securely -- in order to collaborate with your team or your friends.

Just like office docs, you can have thousands of them. You can create them on a whim.

Just like office docs, you can start from "templates" -- called "Blueprints". But where an office template is just some content, a Blueprint specifies a whole application.

It kind of is an Operating System

The OS terminology isn't entirely marketing. Cloudflare OS is actually analogous to an operating system on a technical level.

Our "kernel" is in the workshop-backend package. The backend legitimately does a lot of things similar to real OS kernels: it connects users to programs and devices (Gadgets and Gatekeepers, as we call them) while implementing security by sandboxing applications and enforcing access control.

In this analogy, Gatekeepers -- which connect users and agents to external services -- are like drivers -- which connect users and programs to external devices.

Built on Workers, by the Workers team

Cloudflare OS is built on Cloudflare Workers, making heavy use of Durable Objects, Dynamic Workers, and Facets in particular. Every workspace is its own Durable Object, every Gadget runs in a Dynamic Worker Facet, and Gatekeepers also install facets into each workspace to manage access to remote services.

Features

General multi-purpose agent

The Cloudflare OS coding agent is actually a fully multi-purpose agent that can perform arbitrary tasks; like other popular coding agents, you don't have to code with it. You can use it to build Gadgets, but you can also skip the Gadget and just have the agent perform tasks directly.

Build apps with AI

While you can code a Gadget by hand if you want, the expectation is that AI writes the code for you. Cloudflare OS features a built-in coding agent that will build whatever you ask it, test it for you, and debug errors.

Collaborate with AI

Every app built with Cloudflare OS automatically has an agent-friendly API. That means, after you've asked AI to build the app, you can also ask AI to collaborate with you inside the app.

Real-time Multiplayer

You can share your Gadget just like you'd share a document in a typical online office suite. You can give specific users access, or create a share link that provides access to anyone who opens it. And just like those online office suites, you'll be able to see your collaborators' actions in real time.

Blueprints: Share your code

If you've created a Gadget that might be useful to others, but you don't want to share the Gadget itself, you can instead share a Blueprint, allowing other people to create their own copy of the Gadget. A Blueprint is essentially a copy of the code.

Sandboxed and secure by default

Each Gadget runs in a secure sandbox that prevents it from talking to the internet at all without your explicit consent.

Capability-based access control

Each agent, and each Gadget, by default has access to nothing. Even if you've configured the Gadget Workshop with access to external accounts, agents and Gadgets do NOT automatically get to use them.

Get Started

Deploy to your Cloudflare account

We've built an online flow that helps you deploy to your own Cloudflare account: https://os.cloudflare.app/deploy

Run locally

To quickly run Cloudflare OS locally, install pnpm, then do:

pnpm run-local

Deploy to your own server using workerd

COMING SOON

Configuring external services

Each gatekeeper package contains instructions for how to set it up.

Developing

When developing, you'll want to run the front-end and back-end as two separate commands in two terminals:

pnpm dev-server
pnpm dev-client

Contributing

At this time, we are not seeking outside contribution. AI has made writing code easy. The hard part, today, is not writing the code, but reviewing it, making sure quality stays high, and keeping the product coherent. In that light, unfortunately, external code contributions are "donating" the easy part of the job, while creating more of the hard work.

Credits

• Pi (specifically, pi-agent-core), which made it easy to support every LLM provider with one API.
• Monaco which makes it too easy to embed a beautiful text editor -- for those of us who still look at the code.
• Yjs, which we use extensively to sync code changes between clients and agents and replay histories.
• Vite, which makes the development loop so pleasant.

I worked at Google from 2014-2022, and was involved in forecasting outcomes all over the company, especially about AI. So I was quite interested to see that Alphabet reorganized its AI leadership this morning (Aug 5). Demis Hassabis stepped down as CEO of Google DeepMind to become its chairman and Alphabet's first chief scientist, saying he feels AGI is "close at hand". Koray Kavukcuoglu now runs the unit day to day as an SVP reporting to Sundar Pichai. And the legendary Jeff Dean is leaving, along with three more of the most respected people in AI today: Sanjay Ghemawat, Oriol Vinyals, and Quoc Le.

They're founding Discovery Loop, a public benefit corporation that wants to automate scientific research itself, with Google as an investor and Google Cloud as its compute provider. Alphabet fell about 5% on the news.

I decided to run some forecasts to figure out what the post-Jeff Dean, post-Demis Hassabis Google will look like. Overall I think the mainstream coverage is wrong in both directions, somehow. I think the talent catastrophe will be smaller than the headlines suggest. But I also think the amount that Google is behind in the frontier AI race is worse than people think.

First, a grade for my own bad forecast. In June I forecast that Gemini 3.5 Pro would reach the public around July 1, with an 80% interval ending August 6 (tomorrow). It seems Google scrapped and rebuilt the base model after it stumbled on coding, which means the flagship pipeline was in worse shape than even my pessimistic tail priced. I could be wrong about Gemini 4 too.

Here is my view, lightly modified from off-the-shelf FutureSearch forecasts:

Ranges are 80% intervals. Percentages are the probability of the stated outcome.

Google is far behind the LLM frontier

Industry watchers cluster on a late-2026 launch of Gemini 4, with November and December cited most often. My median is May 15, 2027, timed about right for Google I/O, and a 2026 release now sits outside my 80% interval entirely. I'm not sure how people think Gemini 4 will come so fast. Pre-training started in late July on Google's largest compute budget ever, frontier runs of that class take a hundred days and up, post-training a new generation takes months more, and every frontier launch now ends with a 30-day federal review.

I pushed back on my own number here, because even a March median felt long to me for a run that started in July. I re-ran the forecast telling it that labs post-train intermediate checkpoints while the run finishes, and that a broad Gemini app rollout counts as general availability. The median held at mid-May. The fast path exists, and my 25th percentile is late February. But the forecast keeps concluding that for Google in 2026, slippage is the central case rather than the tail, which is the same lesson my June forecast taught me.

Gemini 4 would have to be bizarrely fast for a large new model to come out in 2026. GPT-6, for example, finished pre-training on March 24, and Sam Altman said launch was "a few weeks" away. Four and a half months later there is still no GPT-6. OpenAI reportedly shipped that base's gains as the point release GPT-5.5 and restarted GPT-6 on a bigger foundation. I think people are conflating point releases, which come every few weeks, with new pre-trained generations, which slip because labs restart them when the base disappoints. Google already scrapped and rebuilt one base this year, on a model smaller than Gemini 4.

And even when Gemini 4 comes out, will it be a frontier model? Two months ago I said Google is about 6-9 months behind the frontier; now I think it's about 12 months. And while Gemini-3-Pro was briefly competitive, I don't think Gemini-2.5-Pro, Gemini-2-Pro, or Gemini-1.5-Pro were ever at the frontier (and I benchmarked forecasting and research tasks with all of them.)

The talent drain

I asked, of the roughly fifteen most senior research and engineering leaders still at Google DeepMind tonight, how many will leave in the next 6 months? My median forecast is 2 (garden leave can make this slow). I also asked whether UK headcount will grow (or whether it will get rolled into Mountain View staffing), and the forecast is that GDM's FY2027 UK headcount comes in 9% above FY2025. There's a 73% chance the unit stays organizationally intact, and a 78% Hassabis still holds an Alphabet-level title at the end of 2027, though I increasingly expect it to be more ceremonial rather than operational.

There is empirical support for not panicking about mastheads. Mike Frantzen's statistical pass over 157 frontier model releases and 171 personnel moves found that labs with more senior departures went on to build better models than their same-tier peers, because everyone recruits from the winners, and that the durable moat is the training stack and the hundreds of mid-career people whose names never make the press. Surprising, but it matches what my forecasts say about this week.

With all of this in mind, I think the market's $200 billion decline on the news is about the model timeline, not the departures.

What if Google wins on compute, not frontier AI?

Before this news, the biggest news from Google was that Google Cloud grew 82% year over year last quarter. A large slice of that is rent from frontier labs, led by Anthropic's contract for up to a million TPUs and multiple gigawatts of next-generation capacity. Discovery Loop will get its GPUs/TPUs from Google too.

So I forecast: Will Anthropic's annualized Google Cloud spend exceed Alphabet's own Gemini revenue, API plus consumer AI subscriptions, at any point before 2028? I put it at 60%. The research behind that number pointed out something I had not put side by side before. Anthropic has committed roughly $200 billion to Google Cloud over five years starting in 2027, while Morningstar pegs Gemini API sales near $15 billion annualized and consumer AI subscriptions run far smaller. It's hard to get precise numbers on Gemini's sales value, but this gives an indication of how it could just not be big for them the way cloud is.

What about AI safety and DeepMind's redlines?

I've been reading The Infinity Machine, the Sebastian Mallaby book about Demis Hassabis. The 2014 acquisition came with two conditions: an Ethics and Safety Review Agreement reportedly gave an ethics board, not Google, control of AGI if DeepMind ever built it. A separate pledge barred military use of DeepMind's technology. Hassabis then spent 2019 to 2021 negotiating to spin research out into an independent entity, and Google said no. The Brain merger in 2023 pulled DeepMind fully inside Google. The weapons pledge came out of Google's AI principles in 2025, and Google now sells AI to militaries, which is what roughly 300 of DeepMind's London staff are unionizing over. I think this news, that DeepMind will be run by an SVP, not a CEO, means there are no barriers for DeepMind to do any business Google does.

I think this means less governance for Google models than even OpenAI has. OpenAI's nonprofit foundation holds a class of stock with control of the board and sole authority over safety decisions, a structure now being stress-tested ahead of its IPO. Anthropic fought hard for redlines against the US government already.

Whether the old redlines hold is a forecastable question, so I forecasted: by the end of 2027, will a Gemini-family model be credibly reported in a weapons or lethal-targeting application, the specific use the 2014 pledge prohibited? FutureSearch gave 66%, which seemed really high, but Google signed a classified Pentagon agreement in April that opens Gemini to "any lawful government purpose", with oversight terms that permit human-supervised target selection. (I was at Google when the first protests started about Google working with the US military.) Isn't that what Anthropic refused to do in May? The forecast is that within 17 months the specific thing that the DeepMind founders prohibited gets reported as operational fact. This might turn out to matter a lot more than market share, or model quality.

Checking the accuracy of these forecasts

Whenever Gemini 3.5 Pro releases (if ever?), my accuracy on that will be pretty poor. These ones will take longer to resolve. But I think that's just how it is with Google now. They aren't on the AI frontier, so it'll be some months or years before we really learn how AI will play out there. This piece extends the January argument that Anthropic is the top lab of 2026. Our Anthropic and OpenAI forecasts, and the Gemini 3.5 Pro page itself, all need refreshes on today's news, and I will update them separately.

Apple's iCloud Private Relay is Leaking Users' Real IP Addresses

Apple's paid Safari protection feature that promises to keep your IP masked doesn't always work, according to security researchers Tommy Mysk and Talal Haj Bakry. It turns out iCloud Private Relay can expose your real IP to websites that use or pretend to use passkeys.

iCloud Private Relay is a service included with paid iCloud+ plans. It is supposed to hide your IP and DNS information when you browse the web using Safari, but it is not a VPN that masks all traffic from a device. Passkeys use the WebAuthn standard, which stores a private key on your device, not the Safari browser. The request the system sends to the website isn't protected by Private Relay and can leak your IP address.

WebKit hands WebAuthn ceremonies to the operating system's credential service, which issues the HTTPS request itself, directly from the device and unaware of any proxy the host app configured. A page can set rpId to a host of its choosing, and the fetch fires even without user interaction: with mediation: "conditional" and no UI ever appears. [...]

Because the fetch is issued by the operating system's credential service rather than by Safari, it never enters Private Relay's proxied path. The destination server sees the device's real IP address either way.

An attacker who wants to find someone's protected IP can do so by setting up a website that uses WebAuthn. There is no visible passkey prompt and no other indication that an IP address has been accessed in the background.

The researchers also found two other WebKit features that can leak IP addresses and DNS data. DNS prefetching (added in iOS 26) reveals a user's real DNS servers, while WebTransport (added in iOS 26.4) can reveal an IP address.

Apple told 404 Media that it is investigating the report.

Mysk and Haj Bakry created a website to let you test whether Apple's service is leaking your IP address. Since the issue is baked into how WebKit works, some third-party browsers are affected too. Apple will need to address the issue, and in the meantime, users can opt for a VPN for more protection.

Full article content is not available for inline reading.

Read the original article →

pgGraph

Graph database superpowers for your existing Postgres data.

pgGraph is a PostgreSQL extension for running graph search, traversal, shortest path, and relationship queries directly against ordinary PostgreSQL tables.

Your tables stay the source of truth. pgGraph builds a derived graph index and lets you query it from SQL using functions in the graph schema.

Looking for a managed version? We have launched a managed version of pgGraph on polygres.com for full high performance GraphRAG on Postgres.

Why pgGraph?

PostgreSQL is great at relational queries, but graph-style questions often require custom recursive SQL for each schema:

• “Find records related to Alice within 2 hops.”
• “Find the shortest path between this person and this company.”
• “Search nodes across registered tables.”

pgGraph adds graph queries on top of your existing PostgreSQL tables, without requiring a separate graph database, graph-specific storage system, or a new query language.

Quickstart

The repository quickstart builds a disposable PostgreSQL 17 image:

git clone https://github.com/evokoa/pggraph.git
cd pggraph
scripts/quickstart.sh

The signed multi-architecture release image is ghcr.io/evokoa/pggraph:1.0.0. Verify its published digest before deployment.

Verify the extensions are loaded (uses psql inside the container, so you don't need a local PostgreSQL client):

docker exec pggraph psql -U postgres -d graph \
  -c "SELECT extname, extversion FROM pg_extension WHERE extname IN ('graph', 'pg_cron');"

If you have psql installed locally you can also connect directly:

psql -h localhost -U postgres -d graph

Homebrew Installation

The Evokoa Homebrew tap is the convenience channel for local PostgreSQL 17 extension installs.

brew tap Evokoa/tap
brew install pggraph
brew test pggraph

Create and verify the extension in a local database:

brew services start postgresql@17
psql -d postgres -c "CREATE EXTENSION graph;"
psql -d postgres -c "SELECT extname, extversion FROM pg_extension WHERE extname = 'graph';"

The formula installs pgGraph 1.0.0 from the signed release bundle.

PGXN Source Installation

PGXN provides the verified source ZIP from the signed 1.0.0 release bundle. Because pgGraph is a Rust/pgrx extension, building from source requires the Rust toolchain.

Prerequisites

• PostgreSQL development headers and pg_config
• Rust toolchain (1.96, pinned by graph/rust-toolchain.toml)
• cargo-pgrx 0.19.1

Install with pgxn-client

cargo install cargo-pgrx --version 0.19.1 --locked
# Register the installed PostgreSQL with pgrx (auto-detects the major):
PG_MAJOR=$(pg_config --version | sed -E 's/[^0-9]*([0-9]+).*/\1/')
cargo pgrx init --pg${PG_MAJOR}="$(which pg_config)"
pgxn install pgGraph

Manual source install

git clone https://github.com/evokoa/pggraph.git
cd pggraph
make install # may need sudo
psql -d postgres -c "CREATE EXTENSION graph;"

Documentation

More information is available in the pgGraph docs:

Overview · Quickstart · Installation · Playground · Querying · SQL API

pgGraph: High-Speed Graph Execution Inside PostgreSQL

pgGraph is not "Postgres plus graph syntax." It is a cache-friendly graph execution layer for data that already lives in your ordinary relational tables.

The core idea is simple but powerful: keep PostgreSQL as your system of record, but build a highly optimized, read-heavy graph runtime from that relational metadata.

The Tech: Why It's So Fast

• O(1) adjacency via CSR. graph.build() compiles your relationships into forward and reverse compressed sparse row (CSR) edge stores.
• A tight traversal loop. Once inside, the engine streams CSR neighbors, checking compact u8 edge-label IDs, typed FilterIndex values, tenant bitmaps, active bits, and sync overlays.
• Read-only artifact mapping. Persisted .pggraph artifacts are written atomically, allowing the operating system page cache to share those physical pages across isolated PostgreSQL backends.
• Predictable and safe. pgGraph includes explicit circuit breakers: depth limits, visited-node tracking, frontier limits, pagination, and strict OOM/memory safeguards.

PostgreSQL Remains Authoritative

Your application data does not move. Source tables, constraints, indexes, ACLs, RLS, backups, and app writes remain 100% standard PostgreSQL concerns.

How pgGraph Compares

vs. Apache AGE: Execution Layer vs. Storage Layer

Apache AGE is a property graph database inside Postgres. pgGraph does not ask you to move your data or learn Cypher. Use AGE for a dedicated property graph model; use pgGraph to add bounded, high-speed graph traversal to an existing relational schema.

vs. PostgreSQL 19 SQL/PGQ

SQL:2023 and PostgreSQL 19 introduce CREATE PROPERTY GRAPH. pgGraph operates at a different layer by precomputing CSR adjacency stores for workloads that repeatedly traverse the same topology with bounded depth and path limits.

Community

pgGraph is built by Evokoa.

License

Apache-2.0.

Imagine typing this into a chat window: who deleted the rows from orders on Tuesday night, and what exactly did they run?

And getting a straight answer: “One account. Sixty-seven row changes”. Every one attributed, the statements quoted back verbatim, and a note about what could not be proven. No ssh, no log files, no query to write.

You can. With DB Trail.

Why nobody answers this today

A row goes missing, somebody asks who deleted it, and in most teams nobody knows. Not for lack of evidence. Enterprise Audit gives you three ways to read it, and none of them is a query.

• You grep the files on the database server.
• Or you switch the log to JSON and page through audit_log_read(), which seeks to a timestamp and then hands you 32 KB at a time, with no way to say WHERE user = or WHERE table =.
• Or you ship the files somewhere that does have a query engine, which means running a logging platform all year for a question you ask twice a year.

On RDS it is not even that log. Amazon audits MySQL with the MariaDB plugin: plain text, no JSON, no audit_log_read(), and the statement truncated at 1,024 characters by default. The files live on the instance under a small rotation budget and come out one portion at a time through DownloadDBLogFilePortion, so the supported path is to publish them to CloudWatch, billed per gigabyte in and per gigabyte scanned.

A consultancy wrote up a real client: 1 TB a month, five-year retention, roughly $6,500 a year in ingestion and storage and past $30,000 across the window. Their fix was to cut the CloudWatch window to 30 days and lifecycle the rest into Glacier Deep Archive. Readable, in the sense that a restore, a table definition and someone who remembers the schema make it readable. The audit log stays affordable as long as nobody asks it anything.

So people stop asking. You pay to record evidence you never read, and what you recorded tells you which statements ran, not which rows left.

Keep the answer, not the log

Ask what an audit log is for, forensically. Its whole job is to prove one thing: which account held connection 58, and between which two instants. That proof is small, it stops changing when the session ends, and it does not need to sit in a log for five years.

So a DB Trail capture daemon reads your live session list twice a second, reads the audit log once a minute if you have one, and writes down the sessions behind each indexed change. One row per session, not per event. A session that changed a million rows is one row. Audit logs grow with your statements; this grows with your connections, so it can be kept forever.

Which flips the economics. The log only has to survive long enough to be read once, minutes, not years. The answer outlives it rotating, the events aging into Parquet on S3, and the source server being switched off.

It also explains the no-plugin case. The poller alone gives you the name; the plugin adds the connect and disconnect records that bracket a session, which is the difference between very probably right and provably right.

Three ways to ask

Ask Claude

The console exposes the engine as MCP tools, so Claude Desktop or Claude Code can ask in words.

The tools take no DSN, so a client cannot point the daemon at another database, and they never fake a clean answer: ask about a window with no evidence and the reply names the sources it could not reach.

Click it

Schema, table, optional primary key. Every row comes back with the name, the source and the confidence.

From the terminal

Same engine, same filters, JSON output, for when you want to script it. The forensics documentation has the flags.

Reading the answer

Three labels, and they mean different things.

• exact: proven, the log shows that connection belonged to this account and its session was open at that moment.
• corroborated: the name matches the number, but nothing proves the session was open then. Strong evidence, not proof.
• heuristic: more than one candidate matched and dbtrail picked the likeliest, and says so.

Some things no tool can tell you. Behind a connection pooler the database sees the pool’s session, so many users share one identity. A replica’s binlog carries the applier’s connection ids, not the client’s.

And none of it needs an audit plugin, if you don’t want one

The connection behind every row change is already in your binlog. The name behind that connection is in performance_schema.threads, on by default in MySQL 8, which joins to the binlog on PROCESSLIST_ID. With one catch: that row disappears the moment the session ends.

The mapping has to be captured while the connection is alive. Nobody has it three weeks later, in the middle of the incident, which is the only time anyone wants it. The original SQL is one dynamic flag away: binlog_rows_query_log_events, off by default, SET GLOBAL without a restart, and from then on the statement text rides along with the row events.

The part no audit log can do

Knowing who is half an incident. Every indexed event also carries the row as it was, so the same evidence that named the person reverses the damage:

-- Recovery SQL generated by bintrail
-- 1204 statements. Review before applying.
INSERT INTO `app`.`orders` (`id`, `customer_email`, `status`, `total`, ...)
  VALUES (4821, 'maria.lopez@example.com', 'pending', 149.90, ...);

Nothing runs. You get the reversal SQL to review and apply in a transaction, rebuilt from the before images, scoped to that one transaction. The recovery guide has the rest.

At any budget, an audit log ends at “here is who to blame”. This ends at “here is your data back”.

Capture has to be running before the row goes missing, which makes the quick start a calm day job.

Artists are lawyering up against AI slop, and some are even winning

Illustrators, authors, and musicians are optimistic about their chances in court, if not about the future of AI.

When The Atlantic published a searchable dataset of works used to train AI, Kirk Wallace Johnson, like a lot of artists, looked for his name out of curiosity. And, like a lot of artists, he found it. Essentially, his books, like The Feather Thief and The Fishermen and the Dragon — nonfiction tomes that he spent “five to six years researching, writing, and investigating” — had been pirated and fed to a chatbot. He says he felt a “cocktail” of emotions: “anger over the brazenness of the theft, worry over what this means for writers, and a healthy thirst for revenge on these massive corporations that have become galactically wealthy” using his intellectual property.

He proactively reached out to Susman Godfrey, the law firm already leading the case against Anthropic on behalf of authors, because he saw their suit as a “middle finger on behalf of everyone that has tried to create something.”

Johnson is just one of the dozens of authors, musicians, illustrators, and artists of all stripes taking the fight against AI to the courts. The lawsuits they’ve filed have primarily targeted the companies on copyright grounds, though some have sought other avenues, like terms of service violations. Some have dragged on for years, others settled comparatively quickly. Along the way artists have been dealt their fair share of wins and losses, especially around the definition of fair use.

“This does not seem to be a bus driven by a bunch of sane sober thinking people, and we’re all stuck in it.” — Kirk Wallace Johnson

Illustrator and cartoonist Sarah Andersen was one of the first and most outspoken to directly take on the AI giants. She describes her webcomic Sarah’s Scribbles as deeply personal. It’s a “complex culmination of my education, the comics I devoured as a child, and the many small choices that make up the sum of my life,” she wrote in a 2022 New York Times editorial. She, along with Karla Ortiz, Kelly McKernan, and several other visual artists, filed a class action suit against Stability, Midjourney, DeviantArt, and Runway AI. The case has been crawling its way through the court system since January 2023. That was just a few short months after Stability’s image generator Stable Diffusion and Midjourney were first released. At the time, generative AI was primarily a curiosity; ChatGPT had only just made its debut the previous November. Now it’s a matter of national security.

In the meantime, other artists, perhaps emboldened by Andersen’s efforts, have launched their own legal assaults on the biggest players in AI, including Meta, Google, Anthropic, and AI music generator Suno. By and large artists are optimistic about how their individual cases will pan out, and some believe that their efforts will help guide the courts toward legal guardrails. But they also harbor deep concerns about the approach taken by AI companies. “This does not seem to be a bus driven by a bunch of sane sober thinking people, and we’re all stuck in it,” Johnson says.

The problem, many seem to agree, is that the Big Tech CEOs and the people building AI models fundamentally don’t understand or respect art. Andersen says she felt “violated” and described it as “reducing my life’s work to an algorithm.” Author Andrea Bartz, a novelist known for books like We Were Never Here and The Spare Room and the lead plaintiff in Susman Godfrey’s suit against Anthropic, has a similar reaction. “I felt violated, shocked, alarmed,” she told The Verge. “I had a big emotional response to seeing that something I’d worked on for so many years and poured my heart and soul into was just one of hundreds of thousands or maybe millions of books that these Big Tech companies had just stolen for training their algorithm.”

“I felt violated, shocked, alarmed.” — Andrea Bartz

Sam Kogon would prefer to be best known for his Americana-tinged pop rock, but his name has been in the headlines recently as the lead plaintiff in the ongoing suit against Google’s Lyria AI music engine. “They’re devaluing our work,” he says, “They’re giving it away to people, for now, for free. And that’s going to disenfranchise and disempower a ton of musicians.” But, just as importantly, he views AI “art” as dehumanizing. Making fake music, he says, is “the most anti-human thing you could do.”

Kogon, along with a number of independent musicians, is accusing Google of violating its own terms of service. This makes their case slightly different from many of the other cases, which focus primarily on copyright infringement. Instead, Kogon’s lawyers argue that Google improperly used its Content ID system and YouTube data to train Lyria and ProducerAI. The company has mostly refused to comment on the specifics of the accusations, though it has filed a motion to dismiss. In the filing, Google claims that the YouTube terms of service give it broad rights to “reproduce, distribute, [and] prepare derivative works.”

“It’s pure bait and switch,” Kogon says, noting that YouTube regularly changes its terms of service. The dense, compulsory TOS is not a contract that can be negotiated, it’s a “take-it-or-leave-it situation.” Google seems to be arguing that anything uploaded at any point rightfully belongs to the company for training purposes. Kogon counters that that makes “technology that wasn’t even invented, and wasn’t even a glimmer in anyone’s eye at the time of putting your things on YouTube, is now fair game.”

Krystle Delgado, an entertainment and IP lawyer who runs the YouTube channel Top Music Attorney, takes serious issue with Google’s claims. She says, “I don’t think that anyone uses YouTube thinking that you are giving the rights to remake your content,” but when digging into the TOS, she discovered the uploader grants YouTube an “irrevocable perpetual license, meaning you can’t ever take it back.”

Google spokesperson Jack Malon responded by telling The Verge that “as we’ve said for several years, we use content uploaded to YouTube to improve the product experience for creators and viewers across YouTube and Google, including through machine learning and AI applications.”

Artists I spoke to viewed this as an abuse of Google’s position. Opting out of a platform as big as YouTube simply isn’t an option.

Those who stand to lose the most are independent artists and the creative working class. When novelist Richard Kadrey, comedian Sarah Silverman, writer Christopher Golden and several others sued Meta for using their books to train its Llama AI without consent, their filing argued exactly that. “While AI-generated books probably wouldn’t have much of an effect on the market for the works of Agatha Christie,” the complaint read, “they could very well prevent the next Agatha Christie from getting noticed or selling enough books to keep writing.”

Johnson says that “anyone that’s focusing on these world-famous authors and screenwriters, they’re missing the point.” The threat isn’t that AI is going to displace all great art. He says, “AI could never write The Godfather… But AI could write a mediocre film. AI could write a mediocre book. And there are tons of authors and screenwriters that live in that space. And it’s no judgment to them. They’re servicing a marketplace.”

The judge in Kadrey v. Meta dismissed many of the authors’ initial claims for failing to show evidence of market harm, but a narrower set of claims focusing on copyright infringement and the use of pirated materials is still working its way through the courts.

In Bartz v. Anthropic, the company was found to have violated copyright laws by using pirated ebooks downloaded from the internet to train Claude. In addition to paying out the largest settlement ever in a copyright case — $1.5 billion — the company also agreed to destroy its trove of pirated ebooks. But where things get complicated is with the trove of secondhand books — millions of them — the company bought and scanned to train its models under the name Project Panama. Judge William Alsup ruled that using those legally acquired books to train an LLM qualified as fair use because it was “quintessentially transformative.”

“The courts and the judges seem to be starting to lean our way, and the court of public opinion too.” — Krystle Delgado

“I strongly disagree with the judge on that part of the ruling … I very much hope that future courts will see the light,” Bartz says. “Even a library can’t buy a physical copy of a book, scan it, and start lending it out as an ebook,” she says.

Still, she doesn’t want to take away from the fact that her case against Anthropic is the first time a large AI company has been held accountable and faced consequences for using artists’ work without consent. She described the sizable settlement as the “first major win for creatives against an AI company … Hopefully that will guide us toward guardrails that are much needed in the industry.”

Delgado, who is leading the case against Suno and Udio on behalf of independent musicians, is equally optimistic. Despite the narrow setbacks in the case against Anthropic and Meta, she believes the pendulum is swinging in artists’ favor. “Right now with these companies, they’re really nervous,” she says. “Not only were they sued, but the courts and the judges seem to be starting to lean our way, and the court of public opinion too.” Polls have shown that people, at the very least, want transparency when it comes to AI.

Even if they win the legal battles, though, all the creators and lawyers I spoke to are concerned about the artists’ ability to continue making a living in the face of an ever-growing tide of AI.

“There’s been so much money spent on marketing to us this idea that AI is inevitable,” Bartz says, “and it’s very convincing and it’s very loud and it’s very pervasive. But I would just encourage people to think about the damage that these companies are doing to the arts, to our critical thinking, to our environment, to the world economy, as they continue to amass power and money.”

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!

Anthropic is hiring an AI chip design team

Anthropic is building a team to design its own custom chips for AI usage.

Business Insider was first to report on the news, but Anthropic has since confirmed with TechCrunch.

The Claude maker said it is planning to co-design hardware and models to help its technology run faster and more efficiently. Last month, The Information reported that Anthropic was scouting Samsung as a potential partner for building such chips.

Anthropic’s decision to design its own chips comes as demand for Claude rises while AI companies snatch up as many AI infrastructure deals as they can.

For its part, Anthropic has inked deals with AWS, Google, Nvidia, and AMD to access AI computing hardware. But to really scale to meet the level of demand, relying on others clearly isn’t enough.

Anthropic isn’t the first AI company to decide to build its own chip. In June, OpenAI unveiled its Broadcom-built Jalapeño chip, which is designed specifically for inference workloads. Google DeepMind has long relied on Alphabet’s TPU chips to power its AI models, while Meta has been developing its own MTIA accelerators for AI workloads.

The company is seeking engineers with experience in chip design for its “custom silicon team,” per a job listing.

This article has been updated to include confirmation from Anthropic.

Models have become excellent programmers. Flex hands them the program itself, so the optimizer rewrites your code and not just your prompt.

The core position of DSPy is that you can define a task once, in a way that lets it be re-implemented as the AI ecosystem advances. The history of these re-implementations can be understood as a history of the models; of weaknesses we worked around and strengths we leveraged:

• In 2022, models needed to be shown what a task looked like, so optimizers like BootstrapFewShot automated the picking of few-shot examples.
• Models then grew to be capable prompt authors, so optimizers like MIPROv2 and GEPA could improve programs by rewriting their instructions.
• Lately, models have become excellent programmers.

This week, we're introducing Flex to DSPy, which leverages the coding skills of models to rewrite not just the instructions of your program, but the code itself.

Flex Lets GEPA Optimize the Code

dspy.Flex(YourSignature) is a DSPy module, which can be dropped into any of your existing Predict, ReAct, or RLM programs. For example:

my_signature = "question -> answer"
my_program = dspy.Predict(my_signature)

# Make it Flex!
my_program = dspy.Flex(my_signature)

If we run either of these programs, we'd get the same result. Prior to optimization, Flex is just a Predict module (or RLM if you provide tools).

What makes Flex different is what it exposes to an optimizer: Flex exposes its code, in addition to its instructions. Hand a Flex module to dspy.GEPA and the reflection model might decompose your program, write helper functions, implement routing logic, and rewrite your prompts. The output is an optimized program that performs best against the metric you gave it.

program = dspy.Flex(SamePlace)        # was: dspy.Predict(SamePlace)

# cheap LM to use during inference
dspy.configure(lm=dspy.LM("anthropic/claude-haiku-4-5"))

# big LM to write the code and instructions
big_lm = dspy.LM("anthropic/claude-opus-5")

optimized = dspy.GEPA(
    metric=make_metric(penalty=0.2),
    reflection_lm=big_lm,
    max_metric_calls=400,
).compile(program, trainset=train, valset=val)

After optimization, optimized.save("program.json") persists the source and dspy.Flex(SamePlace).load(...) restores it. The artifact is a file you can open, read, diff, and reason about.

What you get back is a program the reflection model wrote to score as high as it can against your metric. Two things tend to follow. Sometimes it doesn't call the model at all, because it found a case it could settle in code. And when it does call, the call is better aimed, because the module has already done the parsing and comparison and hands the model a narrower question. Fewer calls, better calls, and a program that outperforms the one you handed it.

Code written by a model is still untrusted code, so by default it never runs in your process. Flex executes the generated source inside a sandboxed interpreter. Only predictor calls and the tools you explicitly provided bridge back to the host process, and a max_predictor_calls cap bounds how many times per forward that bridge can be crossed.

Location Conflation Task

Last year, Drew demonstrated prompt optimization at the Data + AI Summit with a geospatial conflation task: given two place listings, decide whether they're the same physical place. It's deceptively hard in the tail. KIN CAFE and KIN at the same address are the same place. CONCESSION #2 KEN MERCER SPORTS PARK and KEN MERCER SPORTS PARK at the same address are not.

We replaced Predict with Flex and ran GEPA on this task: 1,029 labeled pairs, evaluated on 240 held-out records (class-balanced, so 50% is chance). Caches were disabled throughout, so the cost and latency figures below are what cold production traffic would pay.

The baseline is the original dspy.Predict, one model call per record: 90.4% accuracy at $0.98 per thousand records.

Optimizing only the prompt with GEPA, no Flex, lifts accuracy to 92.5%. But the only lever a prompt optimizer has is the instruction, so it wrote a much longer one, and every record pays for those extra tokens at inference: $2.88 per thousand records, 2.9x the baseline cost, and 48% slower.

Flex gives the optimizer a second lever: the module code. Running GEPA, unchanged, on the Flex program lifted accuracy from 90.4% to 95.0% at a cost of $0.70 per thousand records. By optimizing the prompt and the code, Flex produced a program that is 28% cheaper and 40% faster than the baseline.

How is this possible? For one, many of the places being compared can be evaluated using only code. Our reflection model wrote code to identify and route these easy matches to plain Python functions, resulting in 75% fewer LLM calls.

We can lean into this behavior by updating our metric. A GEPA metric returns a score plus natural-language feedback. With Flex, it can also see how many LM calls the generated program made on each record. We can use this value to penalize our feedback:

score = max(0.0, correct - PENALTY * n_llm_calls)

Even with calls free (λ=0), the optimizer wrote code. The metric function scored on accuracy only. The only nudge was in the metric's textual feedback asking for cases to be settled in code where possible. The best program it found routed 75% of records through deterministic Python and came out more accurate than calling the model every time at 95.0% vs 90.4%, while being faster and cheaper.

At λ=0.4, the program called the model once across 240 records. Accuracy held at 92.1%, statistically indistinguishable from the always-call baseline, at roughly a hundredth of the cost and a thirtieth of the latency.

Reading the Code It Wrote

At λ=0.4, the program holds about two hundred lines of Python code, written by the reflection model. Condensed to its skeleton:

class SamePlaceModule(dspy.Module):
    def __init__(self):
        super().__init__()
        self.judge = dspy.Predict(dspy.Signature(
            "input_name: str, input_address: str, "
            "match_name: str, match_address: str, "
            "distance: float, name_similarity: float, "
            "address_analysis: str -> is_same: bool"
        ))

    def forward(self, **inputs):
        import re, difflib
        # ... 150 lines of logic ...
        if decision is None:
            out = self.judge(**inputs, name_similarity=round(nsim, 3),
                             address_analysis=analysis)
            decision = to_bool(out.is_same)

        return dspy.Prediction(is_same=bool(decision))

1. Normalize: Names are uppercased, stripped of franchise numbers, legal suffixes, punctuation, and generic business words.
2. Compare: The distinctive name tokens are scored zero to one with a fuzzy similarity, and binned into three buckets: confident matches, confident misses, and unsure.
3. Decide: Each bucket gets its own rules combining the name verdict, the address data, and the distance between the two geocoded points.

Deterministic or Stochastic? Let the Metric Decide

With Flex, we can let a model explore this space as it gets feedback from the student model and the metric. We then ran GEPA on our Flex program on SWE-bench Pro. This optimized program resolved 4 out of 12 problems, after designing a software engineering workflow that mixed Python and LLM calls to research, draft, evaluate, repair, and submit a final answer.

As we've watched GEPA rewrite programs across many types of tasks, four moves keep showing up:

1. Decomposition. Noticing that a task has steps (parse, normalize, compare, decide) and giving each step its own implementation.
2. Method selection. Choosing, for each step, between deterministic code and a model call.
3. Routing. Recognizing that different inputs are different tasks: clear cases down the cheap path, ambiguous ones to the judge.
4. Evolution. Refining what's inside the structure: the signatures, instructions, and the code itself.

Where This Comes From

• GEPA. Lakshya Agrawal and team's reflective prompt evolution.
• Meta-Harness. Yoonho Lee and team's work on treating the harness around a model as a learnable object.
• RLM. Alex Zhang and team's work on Recursive Language Models at MIT.

Xiaomi has released its embodied-AI foundation model, Xiaomi-Robotics-1, as open source. The technology account announced the move today, covering the full pipeline from real-robot post-training to model deployment. Code for benchmark evaluations is also included.

The release targets robotics developers and researchers building general-purpose robot intelligence. Xiaomi-Robotics-1 was pretrained on more than 100,000 hours of UMI data and post-trained on over 10,000 hours of cross-embodiment data. The model first appeared in July as an "out-of-the-box" foundation model for embodied AI.

This move injects a significant open-source contender into a field dominated by proprietary systems. It challenges the walled-garden approaches of companies like Figure AI and Tesla, while aligning with the open philosophy of projects such as LeRobot from Hugging Face. The release includes a project website, GitHub repository, and Hugging Face page, lowering the barrier for experimentation.

Why Xiaomi's Release Challenges Proprietary Robotics Giants

The timing is critical. Embodied AI, the quest to give physical robots generalizable intelligence, has seen rapid advances but remains fragmented. Most leading models are locked behind corporate walls. By open-sourcing a full post-training and deployment pipeline, Xiaomi offers a rare end-to-end blueprint. Researchers can now scrutinize how a consumer electronics giant tackles sim-to-real transfer and multi-embodiment learning.

The model's training recipe is particularly notable. The 100,000 hours of Universal Manipulation Interface (UMI) data suggests a focus on diverse, scalable data collection. UMI, a framework for gathering robot manipulation data from human demonstrations, has gained traction for its simplicity. Combining this with cross-embodiment post-training indicates an effort to build a model that adapts across different robot hardware, a holy grail in the field.

"The release covers the full process from real-robot post-training to model deployment and includes code for related benchmark evaluations," the announcement stated. This transparency could accelerate benchmarking efforts. Standardized evaluation remains a pain point in embodied AI, where tasks and environments vary wildly. Xiaomi's included benchmark code may push the community toward more consistent metrics.

Open-Source Robotics Models Face Adoption Hurdles Despite Code Availability

However, the release is not without gaps. The announcement lacks details on the model's architecture, parameter count, or specific benchmarks. Without performance baselines, developers must invest significant time to gauge its real-world utility. The reliance on UMI data also raises questions about domain generalization. UMI-collected data can be noisy and limited to tabletop tasks, potentially constraining the model to narrow manipulation scenarios.

Competing open-source efforts offer a mixed picture. Google DeepMind's RT-2 model, while not fully open, has set performance benchmarks with web-scale vision-language data. Meta's Habitat simulators provide robust evaluation frameworks but lack a unified foundation model. Xiaomi's release sits somewhere in between, a practical, deployment-focused toolkit rather than a research benchmark leader.

Industry history tempers expectations. Open-sourcing a model rarely guarantees widespread adoption. OpenAI's decision to release GPT-2 in stages sparked debate but ultimately fueled an ecosystem. Yet in robotics, hardware diversity and safety concerns often slow community uptake. Xiaomi's own ambitions in humanoid robots, showcased with its CyberOne platform, suggest this release may also serve as a talent magnet and ecosystem play.

The broader context sees China accelerating its embodied AI push. Government initiatives and a robust manufacturing base create fertile ground for open-source robotics. Xiaomi's move could pressure other Chinese tech giants like Huawei and Alibaba to follow suit. For now, the code is live on GitHub and Hugging Face, inviting the world to build on its foundations.

Overview

Rich content: Supports input of up to 4.5k tokens and dense information layout with images-within-images, enabling complex layouts like newspapers, storyboards, menus, and exam papers to be generated in a single pass. Authentic detail: Supports precise rendering of text as small as 10px, and vividly reproduces fine details such as micro-expressions, pores, and individual strands of hair—approaching the quality of real photography. Deep knowledge: Supports native rendering of 12 languages and various fonts, realistic simulation of mainstream interfaces such as web pages, games, and live streams, fully incorporating external knowledge. Qwen-Image-3.0-Pro isn't just pursuing "good looks"—it's pursuing "usefulness", making image generation a truly deployable productivity tool.

Input

ImageText

Output

Image

Features

Prefix Completion

Enable Partial Mode when calling the Qwen API to make the model continue strictly from your provided prefix text.

Function Calling

Use function calling to connect large language models with external tools and systems.

Cache

Context Cache stores shared prefixes for long-context requests to reduce repeated computation, improve latency, and lower cost.

Structured Outputs

Structured Outputs help ensure the model returns a JSON string in the expected format.

Batches

Asynchronously process requests in batches to reduce costs.

Web Search

Enable web search so the model can answer with real-time retrieved data.

Fine-tuning

Train models on sample data to better adapt them to specific tasks.

Pricing

• 1K Image Input $0.003 Per image
• 2K Image Input $0.003 Per image
• 1K Image Output $0.04 Per image
• 2K Image Output $0.075 Per image

Rate Limits

• RPM Requests Per Minute: 1

API Reference

curl --location 'https://dashscope-intl.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation' \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $DASHSCOPE_API_KEY" \
--data '{
    "model": "qwen-image-3.0-pro",
    "input": {
        "messages": [
            {
                "role": "user",
                "content": [
                    {
                        "text": "A vertical outdoor portrait photograph with a warm, film-like afternoon street atmosphere, featuring a beautiful young adult woman looking back over her shoulder at the camera with a joyful toothy smile, her long thick wavy black hair catching the golden rim light, her fair skin, delicate eyebrows, bright eyes, and soft coral-red lips creating a radiant expression. She wears a simple black backless dress with thin spaghetti straps, showcasing her back, and cradles a large, lush bouquet of orange, apricot, pink, and pale peach roses in her arms, creating a sharp contrast against her dress. The top-left of the frame is covered with dark green vines and small orange flowers draping naturally, partially obscuring a matte dark blue signboard with the white Gothic text \"Il Messaggero\". Below the sign is a blurred glass newsstand window with black metal frames showing hints of newspapers and magazines. The right background features strong golden hour backlighting streaming down a warm-toned, sun-drenched city street, with buildings blurred into soft beige-gray shapes, creating a beautiful bokeh effect and a blurry red traffic sign in the far distance. The entire image has a cinematic, romantic, and bright urban stroll atmosphere, characterized by soft contrast, fine film grain, a shallow depth of field, and stunning backlit highlights."
                    }
                ]
            }
        ]
    },
    "parameters": {
        "prompt_extend": true
    }
}'

Zero-Mem: Zero-Token Memory Operations for LLM Agents

LLM agents need memory to act consistently over long interactions, yet many systems use additional LLM calls to operate that memory. Generating intermediate records and mediating their retrieval adds recurring token and time costs, while omitted or merged details can obscure the original evidence. We ask whether structured memory access requires generation at all. Zero-Mem introduces zero-token memory operations: no step outside final question answering invokes an LLM or consumes LLM input or output tokens; encoder computation is accounted for separately. Zero-Mem preserves original interaction traces as its source of record. It organizes the traces in two complementary ways. An entity--context graph exposes connections across interactions, while a temporal hierarchy preserves conversational locality and session state. For each query, Zero-Mem weighs the two views, retrieves from both, and follows their structure to recover supporting relations or surrounding context. Deterministic calibration first discards conflicting evidence and then keeps the reader's answer grounded in the retrieved traces. Only the final-QA reader invokes an LLM. Across long-memory and long-context question-answering benchmarks, Zero-Mem achieves competitive performance while eliminating LLM calls and LLM-token consumption from memory operations. With the same final-QA reader and context budget, it reduces memory-operation time cost by 57.6% relative to the fastest compared baseline. Ablations support the contribution of the two views and their query-dependent coordination. Overall, the results show that structured agent memory need not generate an intermediate representation of the past. After peer review, the code and implementation details will be available at this https URL.

Jeff Dean, Sanjay Ghemawat, Quoc Le, and Oriol Vinyals have left Google to start a company called Discovery Loop. The team aims to build AI that can improve itself with little or no help from humans. Google plans to collaborate with the new startup and has agreed to provide the computing power it needs to build its AI technologies for at least the next year. Discovery Loop will operate as a public benefit corporation.

SpaceX wants to catch a skyscraper falling out of the sky. The company plans to launch its next Starship as soon as this month and, for the first time, try to catch the returning upper stage with the giant robotic arms on its launch tower.

Elon Musk laid out the plan on SpaceX’s first earnings call since its public listing, three months after a Starship V3 booster exploded just before that listing. Flight 14 could fly before the end of August, pending regulatory approval.

Catching the upper stage would be a genuine milestonea as SpaceX has already caught the Super Heavy booster three times with the tower’s chopstick arms, but the Ship, the part that reaches orbit and returns, has never been caught before.

This flight is also meant to do real work. It will carry Starlink V3 satellites to an operational orbit, the first time Starship delivers viable payloads rather than test articles.

The confidence follows a good run. The previous flight, in late July, succeeded, and its heat shield survived re-entry intact after years of the tiles being Starship’s most stubborn weakness.

Musk went as far as to call the problem solved. ‘I don’t want to jinx it,’ he said, ‘but I think I’d consider the heat shield problem solved at this point’, a rare declaration of victory.

Catching the ship rather than landing it on legs saves weight and turnaround time, both central to the economics Musk is chasing. A vehicle that returns to the tower can, in theory, be refuelled and reflown within hours.

The backdrop is a company transformed by going public. SpaceX listed in June, raising $86bn at a $1.77tn valuation, and reported second-quarter revenue of $7.8bn, up 92% on the year.

Most of that money still comes from the sky it already owns. Starlink generated $4.3bn in the quarter, the cash engine funding the far more expensive dream of Starship and Mars.

Musk’s ambitions for pace remain characteristically vast. He said the cadence of flights would rise rapidly and that ‘a year from now, we will be doing at least one flight a day, possibly more’.

Those timelines deserve the usual discount. Musk’s schedules have a long history of slipping, and going from occasional test flights to daily launches is a leap no rocket programme has ever made.

Starship’s road has been bumpy in the way hard engineering always is. Flights have been delayed and boosters have exploded, though each setback now plays out under the gaze of public markets.

Being listed changes the stakes of failure. A spectacular explosion used to be a Tuesday for SpaceX; now each one is a data point for shareholders who priced the company above the world’s largest listed firms.

The far goal has not changed, either. Starship is the vehicle Musk intends to send to Mars and that NASA is counting on to return astronauts to the Moon, which is why its progress is watched well beyond the space industry.

There is more riding on it than satellites. SpaceX plans to begin launching an AI megaconstellation called Starmind from 2027, one of several bets that assume Starship works at scale and soon.

The stakes of reusability are the whole point. A rocket that catches and reflies itself, upper stage included, is the difference between space travel as a stunt and space travel as a business.

European efforts to build a rival to Starlink remain far behind, and a Starship that catches itself would push SpaceX’s advantage further still.

For now, the plan is a catch, a payload, and a cadence promise. If the arms close around the Ship this month, SpaceX will have done something no one else has even attempted, on live television, as a listed company.

What are code reviews even for?

AI didn't break code review. It just made the parts we'd been ignoring impossible to ignore.

Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.

DX’s Q2 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations.

Something is straining in the review queue.

Over the past year at Meta, significant lines of code per human-landed diff increased by 106%. Diffs per developer per month rose 51%. More than 80% of that growth came from agentic AI. Meanwhile, the percentage of diffs reviewed within 24 hours is declining. In some large groups, reviewers are staring down thousands of pending reviews.

This isn’t a Meta-specific problem. Across the industry, AI coding tools are producing code faster than humans can meaningfully evaluate it. Our own DX analysis found that AI is increasing both the number of pull requests and the size of each one (median pull request size grew by 64%). Without a corresponding increase in reviewer capacity, the review process will eventually buckle under its own weight.

Unfortunately, we don’t have more hours in the day, and even if we did, we wouldn’t want to spend them reviewing code written by AI. In previous research, we found developers ideally only want to spend about 7% of their time reviewing code. Asking developers to review more isn’t a sustainable answer.

The math doesn’t work.

But before we ask AI to solve this problem, it’s worth asking a different question:

What problem was code review solving before AI arrived?

If the answer were as simple as “finding defects,” then a fully automated review starts to sound inevitable (and appealing).

But if code review was also how teams shared knowledge, built collective ownership, spread architectural understanding, and taught junior engineers how experienced developers think, then the answer becomes much less obvious.

That’s the mistake I think many organizations are about to make, and the reason we need to rethink what code review is actually for.

We’ve known better for years

Here’s an uncomfortable truth: a significant portion of the review burden we’re feeling right now is self-inflicted.

The frustrating part is that none of this is new. The research on what makes code review effective has been unambiguous. Keep changes small. Write a meaningful description of what changed and why. Run automated checks before asking a human to look. Review frequently, in bounded sessions, focused on substance over style. Select reviewers who actually know the code, but avoid concentrating review responsibility on the same small group of experts whenever possible.

A 2016 Microsoft study of 911 developers found that timely feedback, review size, and understanding the motivation for a change were the top three challenges in code review. Those challenges should sound familiar. The research had already identified many of the practices that improve review quality, yet only 26% of developers said they always wrote a detailed description of the code being reviewed. “Bikeshedding”—disputing minor issues while more serious ones went unexamined—remained one of the most common review failures. We didn’t need new guidance. We needed to consistently apply what we already knew.

AI didn’t create this situation. It inherited it, and then amplified it. Larger PRs, higher review volume, less context per change, these aren’t new symptoms. They’re old ones, scaled up.

Before asking AI to fix your code review process, ask whether your team has built the habits that make code review effective in the first place. Small, well-explained changes. Protected reviewer time. Automated routine checks so humans can focus on judgment.

AI can absolutely improve code review. But it can’t compensate for a review culture that was already struggling. It doesn’t eliminate bad review habits. It amplifies them.

AI can help, if we use it wisely

Once the fundamentals are in place, AI has a real role to play in code review. That’s exactly what we found in our AI Where It Matters research. Developers don’t want code review to disappear. They want AI to remove the parts of review that don’t require human judgment so reviewers can spend more time on the parts that do.

What they want AI to do: catch security and compliance issues, flag high-risk changes, generate test scaffolding, surface the impact of a change across the codebase, and handle the high-volume routine so human attention can go where it matters. As one developer put it: “Should be able to detect high risk changes and derisk them.”

What they explicitly don’t want: AI that auto-merges, auto-commits, or takes final accountability. “I don’t want AI to just act as a red-light / green-light. It should raise issues… and still require human review.” Developers aren’t asking for a replacement, they’re asking for a better collaborator.

Interestingly, one of the most sophisticated production deployments I’ve seen tries to walk that line.

Meta’s RADAR (Risk Aware Diff Auto Review) system automates review for a carefully selected subset of low-to-medium risk changes while routing higher-risk diffs to human reviewers. It combines static analysis, machine learning, LLM-based review, and deterministic validation before anything lands.

The results are striking: more than 535,000 diffs reviewed, over 331,000 landed, a revert rate roughly one-third that of non-RADAR diffs, a production incident rate one-fifty as high, and a 3.3x faster median time to close (roughly a 70% reduction).

RADAR isn’t simply “AI reviewing code.” It’s a carefully engineered system built around the principle that scarce human attention should be reserved for changes where human judgment and accountability matter most.

Just as importantly, the RADAR team also acknowledges a trade-off. Automated review can dramatically improve efficiency, but as automation expands, the knowledge transfer provided by human review could suffer. They identify this as something engineering organizations should actively monitor.

That’s the distinction I think many organizations miss. AI shouldn’t eliminate human review. It should make human review more valuable. AI-enabled review should have discipline around it: clear eligibility criteria, thoughtful risk stratification, and a deliberate decision about which changes deserve human attention, and why.

If you’re evaluating an AI review system, don’t start by asking, “Does it work?” Start by asking, “How does it maximize the time and value of human judgment?”

Don’t lose what review was actually doing

Here’s the part that gets left out of the AI review conversation: code review was never just about finding defects.

A landmark Microsoft study found that while most developers identified defect detection as a primary motivation for code review, defect-related comments made up only 14% of actual review comments. In practice, code review serves many other purposes. More than half of developers said they use reviews to explore alternative solutions, while many also pointed to knowledge transfer and gaining awareness of what their teammates are building.

The visible output of code review is better code. The invisible output is a better engineering organization.

Code review is how teams build shared understanding of a system. It’s how junior developers learn from experienced ones. It’s how architectural intent gets surfaced, questioned, and refined. It’s how one engineer’s mental model gradually becomes the team’s mental model. Organizations don’t become resilient because one person understands a subsystem. They become resilient because many people do.

This is why the stakes around AI review are so high. Automate the review of a diff, and you may have successfully reviewed that diff. But you haven’t transferred any knowledge. You haven’t built shared ownership. You haven’t given a newer engineer a window into how a more experienced teammate reasons about trade-offs. You haven’t surfaced the design rationale that someone will need six months from now when they’re trying to respond to customer feedback.

Developers in our AI Where It Matters research understood this instinctively. One participant wrote, “I can’t fully delegate the final code review to AI—my approval puts my name on it.” Another warned, “Intellectual offloading can result in errors that eventually no one understands.” That’s the slow-moving risk. The gradual erosion of a team’s ability to reason about its own software.

Margaret-Anne Storey’s recent work gives this phenomenon a name. As AI accelerates software development, teams don’t just accumulate technical debt. They accumulate cognitive and intent debt—a growing gap between what the system does and what the organization collectively understands about why it does it. Those debts don’t appear on a dashboard. They surface months later, during an outage, a handoff, or a redesign, when nobody remembers the reasoning that once lived inside a code review conversation. By then, recovering that understanding is far more expensive than preserving it would have been.

This future isn’t inevitable. But it also won’t arrive all at once. It will emerge through a series of individually reasonable decisions: this change is low risk, this review can be automated, this approval can be skipped. Each decision saves a little time. Taken together, they may slowly eliminate one of the primary ways engineering teams build shared understanding.

The challenge isn’t choosing between AI and human review. It’s deciding which parts of code review are too valuable to automate away.

What to actually do

Three things, in order.

Fix the basics first. Audit your current review process. Are pull requests small enough to review meaningfully? Do change descriptions explain why, not just what? Are reviewers protected from overload? Are automated tools already handling the routine work they should (e.g. formatting, linting, and obvious style issues)?

Design AI around human judgment. Developers consistently describe code review as high-value, high-accountability work. They don’t want AI making the decision; they want AI helping them make better ones. That means risk stratification instead of blanket automation. It means AI that surfaces issues, not AI that silently resolves them. It means conservative eligibility thresholds, auditability, and clear human accountability.

Protect what review is actually building. The easiest thing to measure about code review is defects. The most valuable thing it produces is shared understanding. Measure review health beyond throughput. Are junior developers learning? Is architectural knowledge spreading across the team? Are reviewers engaging with substance or simply rubber-stamping? Design your AI review strategy so automation absorbs the routine while humans spend more time on the conversations that create understanding, ownership, and better engineering judgment.

Code review is one of the highest-leverage practices in software engineering, and right now it’s under pressure from every direction. The answer isn’t to make it faster by making it shallower. It’s to get serious about doing it well—with or without AI—and then use AI deliberately, in the places where it earns trust and preserves what the practice was accomplishing all along.

AI should absolutely reduce the time we spend reviewing code. It just shouldn’t reduce the amount we learn from it.

That’s it for this week. Thanks for reading.

-Brian

Open Questions On Open Weights

Last month, some of Silicon Valley’s biggest companies signed an open letter supporting open-weights AI.

Open weights AI is like open-source software, where the creator makes the raw code publicly available for free download. It’s good insofar as it’s the only way an AI can truly be the user’s property, as opposed to something that companies like OpenAI or Anthropic temporarily let you use subject to their corporate guidelines and increasingly-nanny-state-like restrictions. If AI becomes the linchpin of the future, open weights AI feels like the sort of thing that could be the difference between being free yeomen vs. corporate serfs.

It’s bad insofar as it removes the possibility of gatekeeping and lets criminals commit crimes with it. Open weights AI could be used for hacking, child pornography, harassment, or terrorism (the weights can’t commit the terrorism themselves, but they could give bomb-making or bioweapon-making advice). Since AIs have gotten very good - maybe superhuman - at hacking lately, the specter of a world where anyone can hack any site has gotten people grumbling that maybe open weights should be banned. It doesn’t help that China produces the best open weights AI, making the idea seem foreign and almost unpatriotic. Proponents counter that “when AI is outlawed, only outlaws will have AI”, arguing that bad people will get open weights AI regardless, and good people can use open weights AI to defend themselves. With the recent open letter, companies including Microsoft, NVIDIA, OpenAI, Intel, Amazon, Meta, Hugging Face, and over a hundred others have come out in favor of this position.

Who’s leading the other side? Nobody’s admitted to it. Some parts of the Trump administration lean anti-open-weights on China hawk grounds, but have stopped short of explicitly asking for a full ban. Anthropic, the most notable omission on the pro-open-weights letter, made an ambiguous statement supporting “open-weights models that don’t have dangerous capabilities” - but the industry expects open weights models to have dangerous hacking capabilities within a year, and AFAICT the letter didn’t address that beyond inviting readers to draw the obvious conclusion.

In the absence of a more obvious opponent, some open weights supporters suspect our conspiracy - the loose band of AI safety advocates, effective altruists, rationalists, and pause activists who worry about existential risk from superintelligence. This is a reasonable inference. By design, open weights AI is outside centralized control, and so impossible to permanently align against either human misuse (eg terrorism) or loss of control (eg AI turning against humans). Even if its creator trains it not to hack, anybody in the world can download the weights and retrain the AI to hack all day long.

But in fact, most AI safety organizations have remained quietly neutral, and I don’t know of any who make this a centerpiece of their activism (though I’m not 100% up-to-date on the whole landscape; if you know of one, tell me). A few have proposed policies that are contingently incompatible with open weights AI existing, but they all frame it as collateral damage rather than something they’re excited about eliminating.

I’m also neutral about open weights AI. I think it probably won’t be long-term sustainable, but I’m happy to wait for this to become clear in the normal course of things rather than expend effort and political capital to ban it immediately.

Currently nobody knows how to align AI, so it’s not like the big companies have things under control and the open weights hobbyists are going to ruin it for everyone. But even if the big companies did get things under control, the takeover threat from open weights would be limited. The closed source frontier is ~6 months ahead of the best open weights model; this has remained true for several years and seems likely to remain true in the future. If closed weights AI is aligned, but open source dangerous, the closed weight AIs will have six months to warn us, prepare for the danger, and chart a strategy. Even afterward, the offense-defense balance will lean in our favor.

More troubling is the risk from human misuse. AIs have already displayed the ability to hack effectively. And you can tell how worried Anthropic is about bioterrorism by how quickly Claude Fable seizes up when you ask it a biology question (the example below is obsolete; it’s slightly more graceful than this now):

But 9-11, COVID, and the Hugging Face incident all suggest a similar theory of political change: the body politic hates preparing for impending threats, but loves reacting (some would say over-reacting) to them after they happen. Ask people to bear the slightest cost in preparing for an approaching disaster, and they’ll call you a dirty fascist tyrant; urge the slightest restraint after the first foreshock of the disaster hits, and they’ll call you a weak unpatriotic anarchist. Solve for the equilibrium, and the thankless and political-capital-guzzling route of urging preemptive action should be taken only when waiting until the first foreshock would be too late.

The risk of superintelligent AI takeover passes this test. Like other smart adversaries - for example, the Imperial Japanese at Pearl Harbor - AI will try its hardest to avoid alerting its intended victims until it thinks that it’s fully prepared and can execute a sudden decapitation strike. Unlike the Imperial Japanese, a superintelligence will be smart enough not to bungle the calculation. Sitting around waiting for it to show its hand would be folly, not to mention that it could take years of alignment research to be ready for the threat.

But the risk of criminals using open weights AI to hack people doesn’t pass the test. Fine, so criminals use open weights AI to hack people. RIP them, but hundreds of people get hacked every day. There will be some number of billions of dollars in damage, some tech companies with silly names will get sued for allowing security breaches, and then everyone will panic and ban open-weights AI. Or who knows, maybe the “good guy with an AI” people are right and this won’t happen and some other Chinese AI will be able to protect them. Either way, “everyone gets hacked all the time and the Internet collapses and we have to go back to living in caves and watching news on TV” isn’t a plausible outcome: the government will act long before that happens.

Bioterrorism is scarier, but I’m heartened by the fact that most bioterrorists are very bad at their job. The median number of deaths in non-state incidents on Wikipedia’s list of bioterrorism events is zero. And their list doesn’t mention the bioterrorists who get caught before releasing anything, like the Las Vegas biolab incident. Most of the classic bioterrorism agents, like anthrax, ricin, and botulinum, don’t scale. This isn’t to say it’s impossible to do genocidal bioterrorism - if it were impossible, we wouldn’t be worried about it. But before AI makes bioterrorism 1000x more effective, it will make it 2x more effective, and that looks like bringing somebody’s anthrax mailing campaign from one casualty to two. And as soon as someone kills two people with an AI-assisted anthrax mailing campaign, the government will go into panic mode and ban everything. Again, there’s no plausible outcome where people are wiping out whole towns with super-bio-attacks every week and the government just sits there.

(the strongest counterargument is that bioterrorism is so rare, and AI progress so fast, that there might not be any attempts in the short interval between AI doubling attack effectiveness and 1000-timing it. I acknowledge this as a risk, but I think more likely AI-enabled bioterrorism uplift will increase attack frequency at the same time as attack deadliness; even if this doesn’t happen, I think the hacking alone will be enough to get people’s attention)

I realize it sounds callous to accept risks like billion-dollar hacks or anthrax deaths. But the pro-open-weights coalition is strong and totally convinced of the righteousness of their cause. Fighting them on the doomed battlefield of preemptive action would burn 100% of our political capital and goodwill and still fail. Instead, we should say: here is our honest prediction, but we take no action. Then we can let the usual government and civil society actors do the work after the first foreshock, while saving our political capital for causes where there are no alternatives.

(this shouldn’t prevent us from advocating otherwise-good policies which deal incidental damage to open-weights, and we should honestly admit the incidental damage rather than covering it up, but we needn’t treat it as a selling point)

But also, the open-weights people have a point. There are ways to enter the AGI future as free yeomen rather than corporate serfs that don’t involve open weights, but they’re fewer and harder. Maybe the defenders can pull off an unexpected victory on this one and avoid even the sort of small disaster that would bring Leviathan’s banhammer down upon them. This would shock me, but it’s low-cost to find out; given the potential benefits of open-weights, we owe them the chance to try.

(if this ends up destroying the world, sorry, I meant well.)

1 Several people including me objected to OpenAI’s original (2016) plan to be open, but that was because we didn’t know about compute, training, or scaling yet, and we assumed AI would take the form of algorithms that could simply leak. That would mean that anyone who had an open weights model could be their own frontier lab, which is scarier than the current world where they can use it but not improve upon it.

Why can’t models continue to get smarter after they’re deployed? If you hire a human employee, they will grow more familiar with your systems over time, and (if they stick around long enough) eventually become a genuine domain expert. AI models are not like this. They are always exactly as capable as the first moment you use them.

This is because model weights are frozen once the model is released. The model can only “learn” as much as can be stuffed into its context window: in effect, it can take new information into its short-term working memory, but not its long-term memory. “Continuous learning” — the ability for a model to update its own weights over time — is thus often described as the bottleneck for AGI.

Continuous learning is an easy technical problem

However, the mechanics of continuous learning are not hard. The technical problem of “how do you change the weights of a model at runtime” is straightforward. It’s the exact same process as post-training: you simply keep running new user input through the training pipeline you already have. In a sense, every LLM since GPT-3 is already capable of continuous learning (via RL, RLHF, or whatever). It’s just that the continuous learning process is stopped when the model is released to the public.

Internally, the continuous learning process might continue. I think it’s fair to guess that OpenAI’s GPT-5 is constantly training in the background, at least partly on outputs from ChatGPT and Codex. New checkpoints are constantly being cut from this process, some of which eventually become GPT-5.2 or GPT-5.3. In one sense, that’s continuous learning!

So why can’t I use a version of Codex that gets better at my own codebase over time?

Continuous learning is a hard technical problem

The hard part about continuous learning is changing the model in ways that make it better, not worse. I think many people believe that model training improves linearly with data and compute: if you keep providing more of both, the model will keep getting smarter. This is false. If you simply hook up the model to learn continuously from its inputs, you are likely to end up with a model that gets worse over time. At least right now, model learning is a delicate process that requires careful human supervision.

Model training also has a big element of luck to it. If you train the “same” model a hundred times with a hundred different similarly-sized datasets (or even the same dataset and different seeds), you’ll get a hundred different models with different capabilities. Sometimes I wonder if a big part of what AI labs are doing is continually pulling the lever on the slot machine by training many different model runs. Surprisingly strong models, like Claude Sonnet 4, might represent a genuinely better model architecture or training set. But part of it might be that Anthropic just hit on a lucky seed.

Learning lessons from fine-tuning

The great hope for continuous learning is that it produces an AI software engineer who will eventually know all about your codebase, without having to go and research it from-scratch every time. But isn’t there an easier way to produce this? Couldn’t we simply fine-tune a LLM on the codebase we wanted it to learn?

As it turns out, no. It is surprisingly non-trivial to do this. Way back in 2023, everyone thought that fine-tuning was the next obvious step for LLM-assisted programming. But it’s largely fizzled out, because it doesn’t really work. Just fine-tuning a LLM on your repository does not give it knowledge on how the repository works.

It’s unclear to me exactly why this should be. Maybe each individual piece of training data is just too small to make much difference, like a handful of grains of sand trying to change the shape of an entire dune. Or maybe LoRA fine-tuning doesn’t go deep enough to really incorporate implicit understanding of a codebase (which can be very complex indeed). Or maybe you’d need to incorporate the codebase much earlier in the training process, before the model’s internal architecture is already established.

In any case, fine-tuning a coding model on a specific codebase may be useful eventually. But it’s not particularly useful now, which is bad news for people who hope that continuous learning can easily instil a real understanding of their codebases into a LLM. If you can’t get that out of a deliberate fine-tune, why would you expect to get it out of a slapdash, automatic one? There may well be a series of ordinary “learning” problems to solve before “continuous learning” is possible.

Continuous learning is unsafe

Another reason why continuous learning is not currently an AI product is that it’s dangerous. Prompt injection is already a real concern for LLM systems that ingest external content. How much worse would weights injection be?

We don’t yet fully understand all the ways a LLM can be deliberately poisoned by a piece of training data, though some Anthropic research suggests that it may not take much. Right now, prompt injection attacks are unsophisticated: the attacker just has to hope that they hit a LLM with the right access right now. But if you can remotely backdoor models via continuous learning, attackers just have to cast a wide net and wait. If any of the attacked models ever get given access to something sensitive (e.g. payment capability), the attack can trigger then, even if the model is not exposed to prompt injection at that time. That’s much scarier.

Big AI labs care a lot about how good their frontier models are (both in the moral and practical sense). The last thing they want is for someone’s continous version of Claude Opus 5 to be poisoned into uselessness, or worse, into Mecha-Hitler. Microsoft’s famously disastrous chatbot Tay happened less than ten years ago.

Continuous learning is not portable

Finally, I want to mention a fixable-but-annoying product problem with continuous learning. Say you have Claude-Sonnet-7-continuous running on your codebase for six months and it’s working great. What do you do when Anthropic releases Claude-Sonnet-8? How do you upgrade?

Everything your model has learned from your codebase is encoded into its weights. At best, it might be encoded into a technically-portable LoRA adapter, which might work on the new model (or might not, if the architecture has changed). You’re very likely to be unable to upgrade without losing all the data you’ve learned.

I suppose it’s sort of like having to hire a new, smarter engineer every six months. Some companies already try to do this with humans, so maybe they’d be happy doing it with models. But it creates an unpleasant incentive for users. Imagine you’d been using a continuous version of GPT-4o all this time. You should switch to GPT-5.3-Codex. But would you? Would your company?

Summary

The hard part about continuous learning is not the continuous part, it’s the automatic part. We already understand how to make a model that continuously “learns” from its outputs and updates its own weights. The problem is that model training is a manual process that requires constant intervention: to back off from a failed direction, to unstick a stuck training run, and so on. Left on its own, continuous learning would probably fall into a local minimum and end up being a worse model than the one you started with.

It’s also not clear to me that simply running my Codex logs back through the Codex model would rapidly cause my model to understand my own codebases (at anything like the speed a human would). If we were living in that world, I’d expect all the major AI coding companies to be offering repository-specific model fine-tunes as a first-class product — but they don’t, because respository-specific fine-tuning doesn’t reliably work.

Why not just offer it anyway, and see what happens? First, AI labs go to a lot of effort to make their models safe, and allowing many customers to train their own unique models makes that basically impossible. Second, AI companies already have a terrible time getting their users to upgrade models: as an example, take the GPT-4o users who have been captured by its sycophancy. Continuously-learning models would be hard to upgrade, even when users obviously ought to.

1. AI systems can “continuously learn” in a sense by forming “memories”: making notes to themselves in a database or text files. I’m not counting any of that stuff. It’s like saying that the guy in Memento could remember things, since he was able to tattoo them onto his body. Proponents of continuous learning are talking about actual memory.

2. This is a guess on my part, but I’d be pretty surprised if I were wrong.

3. I think most people who’ve spent time training models will agree with this. It could be different at big-lab scale! But I’ve seen enough speculation along these lines from AI lab employees on Twitter that I’m fairly confident advancing the idea.

4. Obviously it’s hard to find a “we tried this and it didn’t work” writeup from any tech company, so here’s a HuggingFace thread from this year demonstrating that it is still not a solved problem.

Netflix's TimeSeries Abstraction stores and queries multi-petabyte temporal datasets, tiering older, immutable slices from hot Cassandra into cheaper S3 storage. The earlier design used Kafka and Flink to stream Parquet to S3 and daily compaction, serving cold reads with roughly 500 ms p99 latency, but added operational cost. The later Cassandra-native cold tier reads directly from S3 backups, serves 15+ PB of compressed cold data, and improves p90 latency by about 30% while preserving the same query API.

Flipkart's Product Analyser trains a relevance labeling model in two stages: SFT on millions of balanced query-product examples with generated reasoning traces, then GRPO alignment using an 8B reward model that scores explanation quality alongside label correctness. The automated NDCG report it produces differs from the manual one by under 1%, at 30% lower cost.

Prototype on a laptop, scale to 16 billion rows: one Polars query

A pattern we often see at data teams: exploration happens on a laptop in one tool, and once the dataset outgrows the laptop, the pipeline is rewritten in a second tool that scales. From that point on the team maintains two implementations of the same logic, and the two tend to drift apart. Every change has to be made twice, and once the implementations drift, the dashboard and the notebook start disagreeing about the same number.

This post shows a workflow without the rewrite. We take a subset of a large dataset, explore it locally, and build an ETL pipeline from what we find. Then we run the exact same Polars queries on the full month of Polymarket orderbook data, 16 billion rows, on Polars Cloud. What changes between the laptop and the cluster is the method call that decides where execution happens. The results feed a Plotly Dash dashboard hosted on Plotly Cloud.

The dashboard the pipeline feeds, live to explore.

The workflow

Our example data comes from Polymarket, a prediction market where users trade on the outcomes of real-world events. It publishes its full orderbook as a public dataset: every price update, for every active market, logged with a millisecond timestamp. One hour of that data is around 30 million rows, and the three hours we prototype on total 97 million, which still runs comfortably on a laptop. One month is 16 billion rows in around 500 GB of compressed Parquet, which requires larger machines.

Raw orderbook events land in S3 as hive-partitioned Parquet. Polars transforms that raw data into the smaller files that back each plot. A subset of a few hours has the same shape as the full month, so one LazyFrame serves both scales: collected locally while prototyping, then run distributed on Polars Cloud against the full month. Its output is a handful of small, pre-aggregated Parquet artifacts in S3. Plotly handles visualisation and serving: a Dash app on Plotly Cloud reads those artifacts to power the dashboard and an MCP endpoint. The two halves meet at the artifacts.

We built this project together with the Plotly team, and the write-up spans two posts. This one covers the compute half: decoding, aggregating, and scaling the data with Polars.

Step 1: explore a subset locally

We scope to the first three hours of the month before writing any pipeline code. That is enough data to work out the schema, the payload format, and the transformations the dashboard needs, with the fast feedback of local execution. It is also deliberately more than one hour: an hour is a single leaf partition, while three hours span multiple partitions, so the subset has the same structure as the full month and the query already handles the multi-file scan it will meet at scale.

import polars as pl

pl.Config.set_engine_affinity("streaming")

storage_options = {"aws_region": "us-east-1"}

lf = pl.scan_parquet(
    [
        f"s3://bucket/raw/orderbook/year=2026/month=03/day=01/hour={h:02d}/*.parquet"
        for h in range(3)
    ],
    storage_options=storage_options,
)
print(lf.collect_schema())

collect_schema resolves column names and dtypes from the file metadata without reading any data, so it is the cheapest first look at an unfamiliar dataset. To see actual values, pull a single row and glimpse it:

lf.head(1).collect().glimpse()

glimpse prints one row per column, so the wide data payload stays readable instead of being squashed into a table cell.

Tip: set streaming affinity once, affect all collects

set_engine_affinity is a global config. Call it once at module load and every .collect() in that process uses the streaming engine, which processes data in chunks and keeps memory bounded on scans larger than RAM. It will become the default engine in an upcoming release.

Each row is a raw event: two timestamps, a market_id, an update_type, and a data column holding a JSON payload. A value_counts shows two event types: price_change, which fires whenever the best bid or ask on a market moves, and the much rarer book_snapshot, which we only use for the dashboard’s depth chart. The price_change payload holds eight JSON keys, of which we need three. Polars decodes them inline with str.json_decode and a pl.Struct schema that declares only those three fields, so the rest is never parsed, and casts the string-quoted prices to Float64 along the way. The side column becomes a pl.Enum, a categorical type with a fixed set of values that is safe to use across distributed workers. We build a single LazyFrame, price_changes, that filters, decodes, and computes the spread:

PRICE_CHANGE_SCHEMA = pl.Struct({
    "side": pl.String,
    "best_bid": pl.String,
    "best_ask": pl.String,
})

price_change_expr = pl.col("data").str.json_decode(PRICE_CHANGE_SCHEMA)
price_changes = (
    lf.filter(pl.col("update_type") == "price_change")
    .select(
        "timestamp_received",
        "market_id",
        price_change_expr.struct.field("side").cast(pl.Enum(["YES", "NO"])),
        price_change_expr.struct.field("best_bid").cast(pl.Float64),
        price_change_expr.struct.field("best_ask").cast(pl.Float64),
    )
    .with_columns(
        (pl.col("best_ask") - pl.col("best_bid")).alias("spread")
    )
)

df = price_changes.collect()

Prediction market prices

Prices are probabilities between 0 and 1. A YES price of 0.72 means the market prices a 72% chance the event resolves YES. Each market side has a best bid and a best ask, and the spread is the gap between them: narrow in active, liquid markets, wide where trading is thin.

A few group-bys settle the design questions. Activity is heavily skewed: a small set of liquid markets accounts for most of the events, while thousands of markets barely trade. Users will want to drill into one liquid market’s history or scan across markets to compare them. Both views filter on market_id and a timestamp range, so those are the two axes the pipeline output has to be cheap to slice along.

Step 2: shape small artifacts for the app

The dashboard is a web app that could serve many concurrent users, and running a full scan of 16 billion raw events on every page load is not viable. So the heavy aggregation runs ahead of time as a batch job on Polars Cloud, and the dashboard reads only its output.

Tip: separate compute from serve

Run the heavy aggregation once, on a schedule or on demand, and write the results as small artifacts. The app reads only those artifacts, so a page load never scans the raw dataset. The cost of the big scan is paid once per refresh instead of once per visitor.

The pipeline runs in two stages. Stage 1 is the decode we built while exploring: it filters, decodes, and casts the raw events, and sinks the typed result to an intermediate prefix on S3. Stage 2 scans those intermediates, so each aggregation job works with typed columns instead of re-parsing JSON strings:

price_changes = pl.scan_parquet(
    "s3://bucket/artifacts/_intermediate/price_changes/",
    storage_options=storage_options,
)

From that one LazyFrame, Stage 2 writes six artifacts, one per dashboard view:

The heaviest artifact is under 5 MB, so clicking through markets never triggers a scan of the raw data. All six jobs are the same shape: filter, group_by, agg, sink_parquet. One is enough to show the pattern. Here is the activity pulse:

activity_pulse = (
    price_changes.with_columns(
        pl.col("timestamp_received").dt.truncate("1m").alias("minute_bucket")
    )
    .group_by("minute_bucket")
    .agg(
        pl.len().alias("events"),
        pl.n_unique("market_id").alias("live_markets"),
    )
    .sort("minute_bucket")
)

activity_pulse.sink_parquet("artifacts/activity_pulse.parquet")

Tip: dt.truncate + group_by instead of group_by_dynamic

group_by_dynamic requires the index column to be sorted, which on unsorted data means a global sort: expensive, and hard to distribute. Truncating a timestamp to a bucket and using a plain group_by produces the same result for non-overlapping tumbling windows, with one caveat: buckets without events are omitted instead of appearing as zero rows. It is fully partitionable: each worker can aggregate its own chunk independently.

Step 3: run the same query on the full dataset

The full dataset covers one month of trading: 16 billion raw events in 500 GB of compressed Parquet. This is too much for a laptop, so we scale up to a cluster. The pipeline code stays the same. The only difference is how the query executes.

import polars_cloud as pc

pc.authenticate()

ctx = pc.ComputeContext(workspace="my-workspace", name="polymarket-pipeline")
ctx.start()

With the context running, moving a query to the cluster is one change to the call:

activity_pulse.remote(ctx).sink_parquet(
    "s3://bucket/artifacts/activity_pulse.parquet",
    sink_to_single_file=True,
    storage_options=storage_options,
)

The LazyFrame is the same object in both calls. remote(ctx) hands it to Polars Cloud, which distributes the scan and aggregation across the cluster. A distributed sink writes its output as multiple files by default, and sink_to_single_file=True merges it into one. The decode we wrote to eyeball three hours of data now processes 16 billion rows, and there is no second implementation to keep in sync with the prototype.

Step 4: hand the artifacts to Plotly Dash

The dashboard reads the manifest on startup and loads the global artifacts (market profile, activity pulse) into memory. Per-market data is fetched on demand. prices.parquet is written with sink_to_single_file=True and sorted by market_id, so filtering to a single market lets the Parquet reader skip row groups that cannot match. Results are cached on the Plotly Cloud instance with @lru_cache so each market is read from S3 at most once:

from functools import lru_cache

@lru_cache(maxsize=128)
def query_price_and_spread_data(market_id: str) -> pl.DataFrame:
    return (
        pl.scan_parquet(artifact_url("prices.parquet"), storage_options=storage_options)
         .filter(pl.col("market_id") == market_id)
         .collect()
    )

Predicate pushdown

Parquet files store row-group statistics (min/max per column). When a query filters on market_id, the reader checks those statistics and skips row groups whose range cannot contain the target value, before reading any data. Sorting the file by market_id before writing concentrates each market’s rows into a few row groups, which maximises the skipping.

Dash callbacks pass the resulting Polars DataFrame directly to Plotly figure constructors:

@app.callback(
    Output("price-chart", "figure"),
    Output("spread-chart", "figure"),
    Input("market-dropdown", "value"),
)
def update_selected_market(market_id):
    df = query_price_and_spread_data(market_id)
    label = market_name(market_id)
    return price_chart_figure(df, label), spread_chart_figure(df, label)

The same work, scaled

Explore a subset locally, with fast feedback, until the decode and the aggregations are right. Run the same LazyFrames on the full dataset with .remote(ctx), on Polars Cloud or on your own cluster. Serve small pre-aggregated artifacts to a Plotly Dash app, so no page load touches the raw data. Polars transforms the data, and Plotly Dash visualizes and serves it, with a handful of small Parquet files in S3 as the interface between them.

I was recently trying to validate some performance improvements related to lld at $DAYJOB and it was a little frustrating to see the improvements in our benchmarks but not in the live-production dashboards.

Having come from a background working on web-services, I was used to looking at individual time-series dashboards, sometimes over a few percentiles, and I was expecing to see some noticeable change but the data seemed too noisy to make any conclusions.

Turns out a colleague had also faced similar issues when trying to evaluate build-speed improvements. There are lots of variables that can affect the build: cold-cache, incremental, local, remote, etc. and the build times can vary wildly depending on the state of the system and the workload. She ended up leveraging a cummulative distribution function (CDF) to visualize the data and it was a revelation to me.

This led me to explore a few other different ways to visualize data, in addition to the CDF, and how a single image or statistic is often not enough to tell the whole story. This post will walk through a single synthetic dataset and show how different visualizations can tell different stories about the same data. The goal is to convince you to look at your data and not just summarize it with a single number.

Everything below comes from one synthetic dataset with a fixed seed. The full script can be found in this gist. It is a single file with a nix-shell shebang, so you can reproduce every figure exactly as long as you are using nix.

Note I leveraged AI to help generate the data and charts in this post for the story. If that bugs you, sorry. 🤷

The rollout that “made it worse”

Here is the setup: we operate a typical web-service and we rolled out a new caching tier over a week, hoping to cut request latency.

The change is fully deployed, and the latency dashboard that plots the mean looks like this:

Mean latency went up, from 112 ms to 122 ms. ☹️

A SEV is cut, we revert the change and write the postmortem. Right? 🤔

One number, four stories

It’s often good practice especially for web-services to look at various percentiles, especially the tail end of the distribution like the p95 and p99.

Now we have a problem, and the problem is that everyone is right. The mean says the change is a mild regression. The median (p50), says the change is a big-win, the typical request got nearly twice as fast. The p99 says it’s a SEV, the worst requests more than doubling.

The mean and the median, computed from the very same numbers, point in opposite directions.

Engineers are often taught to be data-oriented, but often it’s easy to cherry-pick the statistic that supports your argument.

Look at the shape

The next basic thing you can do with a distribution is plot its shape. Here are the two latency distributions, before and after, as densities:

There it is. 🤓☝️ The “before” is one tidy hump. The “after” is two humps.

This already explains the earlier contradiction but it’s a bit tricky to visualize correctly. The shape depends on a smoothing parameter we chose, the two fills muddy each other where they overlap, and it’s genuinely hard to read a percentile off it. I can see there are two populations; I can’t easily see where the median went.

The best chart you’re not using

The cumulative distribution function (CDF) answers one question for every percentile at once: what fraction of requests came in at or below x milliseconds?

CDFs are an extremely easy way to visualize multiple percentiles in a single chart. Depending on the curve, we can understand how the request latency is distributed across the entire population.

I found it incredibly useful to then plot the “before” and “after” CDFs on the same chart to see how they compare. You can then visualize the shifts at various percentiles and understand how the change affected the entire population.

In our story, the “after” curve has shifted left for request latencies below 140ms. That means more requests are finishing faster than before. The “after” curve is higher than the “before” curve to the right of 140ms which means more requests are finishing slower than before. The two curves cross at ~140ms which is the tipping point where the change goes from being a win to a loss.

Tip Two CDFs that cross are the unmistakable signature of a change that no single percentile can summarize, because the sign of the effect depends on which percentile you ask.

Who won, and by how much

The CDF tells us that the effect changes sign: faster or slower. The obvious next question is by how much, at each point in the distribution. We can plot for every percentile p, the after-latency minus the before-latency, known as the shift function.

Below the zero line the change is faster; above it, slower. We can visualize the magnitude of the change at each percentile.

The regression was there all along

So far we have looked at two frozen snapshots, before and after. Rollouts though are often not instant. In this story, we rolled out the new caching tier over a week, ramping from 0% to 100% of traffic.

What did each day look like? Stack one distribution per day and you get a ridgeline:

We can now visualize the regression emerging over time. We can see the main peak (the fast requests) sliding left as the rollout progresses, and a second peak (the slow requests) emerging on the right. The median is dropping, but the slow requests are quietly growing in number and latency.

The x-axis here is logarithmic. Latency is roughly lognormal, and on a linear axis the fast peak is a tall spike next to an invisible smear; the log axis is what lets both humps read as humps.

We can do something similar, squeezed into a single grid, as a heatmap. One column per day, colour for how much traffic lands at each latency:

You can sort-of make out a new population emerging faintly.

Any aggregate computed over the whole week would have blended these seven very different days into one muddy number and hidden the trend completely.

The bimodality had a cause

We’ve now thoroughly established what happened. The next question is why. This is in fact very similar to $DAYJOB where I had to cut the data by binary sizes (i.e. >50MiB) to observe the bimodality in the latency distribution.

In our story, new tier either serves a request from cache (a hit) or falls through to the backend with an extra hop (a miss). We can split the “after” requests by that property and draw a CDF for each:

Conditioned on cache outcome, each population is unimodal again.

We can easily see that cache hits are faster than the old baseline as they are shifted left.

Cache misses pay for the extra hop and land far to the right.

Why those requests?

“Some requests miss the cache” is a mechanism, but it isn’t yet a cause. Which requests miss, and why?

Each request carries one more field I haven’t used yet: its response size.

A cache holds small, hot objects; big ones get evicted or never fit. We can plot the latency against the response size, and colour each point by whether it was a cache hit or miss. We can also add a density to each margin to see how the two populations are distributed along each axis: a jointplot:

We can see two clean population clusters: small-and-fast (cache hits) and large-and-slow (cache misses). It’s clear that the bimodality in the latency distribution is caused by the bimodality in the response size distribution.

We now have something actionable: raise the cache’s max object size, or split the big responses. 🔥

A graph is worth a thousand numbers

Often a single panel or graph is too small to tell the whole story at best. At worst, it can be misleading. It is beneficial to have multiple views of the same data to understand the full story.

I was especially impressed with the way the CDF can convey the entire distribution in a single chart especially when comparing what might appear to be multiple populations.

“Do not trust any statistics you did not fake yourself.” – Winston Churchill

pyhctsa: Python Toolkit for Highly Comparative Time-Series Analysis

Installation

To install pyhctsa you can call:

pip install pyhctsa

Basic Usage

A FeatureCalculator object must first be instantiated using:

from pyhctsa.calculator import FeatureCalculator
calc = FeatureCalculator()

By default, the FeatureCalculator will initialize the full feature set. If you would like to specify a custom feature set, you can pass the corresponding configuration .YAML file as an argument to the FeatureCalculator:

custom_calc = FeatureCalculator(config_path="subset.yaml")

The number of master operations (callable functions) specified by the .yaml will be displayed for verification e.g., Loaded 700 master operations.

Once a FeatureCalculator has been initialized, you can call the extract method to compute time series features on either a single time-series instance or a list of multiple instances:

from pyhctsa.utils import get_dataset

e1000 = get_dataset()
data = e1000[0] # your data as a list, array, or pandas series
res = calc.extract(data)

Note that each time-series instances does not have to be the same length to compute a vector of features. The results of the extraction will be returned in a pandas dataframe of shape N × F, where N is the number of time-series instances and F is the number of time-series features.

Tutorials

New to pyhctsa? Step-by-step tutorials and example workflows are available in the repository.

Advanced Usage

Calling individual operations

If you would like to run individual operations on your data, you can access the corresponding functions from their respective modules directly. For example, to compute the raw_hrv_meas features on your data, the raw_hrv_meas master operation can be accessed from the medical module:

from pyhctsa.operations.medical import raw_hrv_meas

data = ... # your ArrayLike data
res = raw_hrv_meas(data) # result as either a dictionary or scalar value

Individual operations can only be called directly on individual time-series instances.

Parallel Computing

Time-series feature extraction is computationally intensive. To speed up processing, pyhctsa allows you to distribute the workload across multiple CPU cores on your local machine using the LocalDistributor:

from pyhctsa.distribute import LocalDistributor
from pyhctsa.calculator import FeatureCalculator

# initialize the calculator
calc = FeatureCalculator()

# create a LocalDistributor and specify the number of workers
# it is generally recommended to set n_workers to the number of physical CPU cores
dist = LocalDistributor(n_workers=4)

# pass the distributor to the .extract() method
res = calc.extract(data, distributor=dist)

Licenses

Internal licenses

Code for computing features from time-series data is licensed as GNU General Public License version 3.

External packages and dependencies

While the majority of features in pyhctsa rely on standard Python libraries, a small subset of features require external toolboxes.

The following external time-series analysis code packages are provided with the software (in the toolboxes directory), and are used by our main feature-extraction calculator to compute meaningful structural features from time series:

• Time-series analysis code developed by Michael Small (unlicensed).
• Max Little's time-series analysis code (GPL License).
• TISEAN package for nonlinear time-series analysis, version 3.0.1 (GPL license).

The following codebases have been adapted directly into Python code within pyhctsa, rather than being included as external toolboxes:

• Danny Kaplan's Code for embedding statistics (GPL license).
• Histogram code by Rudy Moddemeijer (unlicensed).

AI Usage Disclosure

Portions of this codebase (including tests and function documentation) were refactored and generated with the assistance of Large Language Models (LLMs). All AI-generated contributions have been reviewed and verified by the human maintainers.

smevals - a small eval suite for evaluating models, prompts, and harnesses

We've been building a new system for running evals against different models, prompts, and harnesses, with the goal of being able to identify the most appropriate small and inexpensive models for different categories of task.

Frontier models continue to improve at an impressive rate, but those improvements are often accompanied by increases in price as well. GPT-5.5 and 5.6 Sol are twice the price of GPT-5.4. Claude Fable 5 is twice the price of Claude Opus 4.8. Even Google's inexpensive Gemini 3.5 Flash-Lite model has increased in price from Gemini 3.1 Flash-Lite.

Meanwhile the options for inexpensive models have never been more abundant. Local models that run on small devices are exploding in capability, and the leading edge open weight models are improving at a dramatic rate, and at a price point significantly lower than their proprietary competitors.

The smevals vocabulary: evals, tasks, configs, runs, and grades

smevals (for small evals) is a Python CLI tool that executes eval suites that are defined as a directory containing YAML configuration and executable scripts. Here are the key concepts of the smevals system:

• An eval is a collection of challenges designed to answer a question about a model, for example, how good is that model at generating SVGs?
• Each eval is a collection of tasks. A task is a specific challenge, for example "Generate an SVG of a pelican riding a bicycle".
• When you run the eval you do so against one or more configs. Each config specifies a model to be evaluated, but may also include other parameters to test, such as different system prompts, model parameters, or agent harnesses.
• A run records what happened when a specific config was used to execute a specific task. A runner is the script that executes a run.
• Once you have collected one or more runs, you need to evaluate the results to see how well the model (or config) did. This is done by a grader, which produces a grade.
• Each grader runs a sequence of checks. These can be simple operations, like checking for a specific string in the output, or confirming that the output is valid XML. They can also be more complicated custom operations (implemented as scripts called checkers), including using other models to answer questions about the run.

The smevals process

To run an eval using smevals you need to:

1. Design and implement the tasks for the eval
2. Decide how you will be grading the outputs of that eval
3. Run the tasks against one or more model configurations
4. Run the grader to determine scores for those runs

The results of an eval can be examined either in the terminal or using a web application. The web reports can be baked out and published as static files.

Writing evals with a coding agent

The smevals README is designed for both humans and agents. A coding agent that reads that document should have everything it needs to know in order to construct an initial eval.

That README is also bundled with the tool, and is available using the smevals docs command.

This means you can start a session in Claude Code, or OpenAI Codex, or Pi, or your agent of choice, and prompt the following:

Run the command "uvx smevals docs"

Then, once the agent has read the resulting documentation:

Now build an eval that tests how well models can write haikus, with two tasks - a haiku about a pelican and a haiku about two otters in love

This should construct the eval in your current directory. You can then run it with this command:

uvx smevals run . -g

The . tells it to run the eval in the current directory. Adding -g causes it to grade the runs as soon as they have executed - without that you would need to run a separate smevals grade . command later on.

Here's the output I got from running this for the first time:

otters-in-love / default / gpt-4.1-mini ... ok (5.0s) -> runs/otters-in-love/default/gpt-4.1-mini/2026-07-24T01-07-45Z

    grade: pass score=1.0

pelican / default / gpt-4.1-mini ... ok (12.6s) -> runs/pelican/default/gpt-4.1-mini/2026-07-24T01-07-50Z

    grade: pass score=1.0

I ran it against two more models like this:

uvx smevals run . -g -m gpt-5.5 -m gpt-5.4-nano

That created four more runs, trying each of the two tasks against those two new models.

The runner used here is a short shell script called run-llm that calls the llm CLI with the model and prompt supplied by smevals, then saves the corresponding LLM JSON log as an artifact alongside the output:

#!/usr/bin/env bash

set -euo pipefail

llm -m "$SMEVALS_MODEL" "$SMEVALS_PROMPT"
llm logs -c --json > log.json

The initial eval is a small directory of seven files:

haiku/
├── eval.yaml
├── tasks/
│   ├── pelican.yaml
│   └── otters-in-love.yaml
├── configs/
│   └── default.yaml
├── graders/
│   └── default.yaml
├── checkers/
│   └── three-lines
└── run-llm

Improving the grader

The first version of the grader that Codex built for me only checked that the response contained exactly three non-empty lines. Here's that checkers/three-lines file:

#!/usr/bin/env python3
import json
import os
from pathlib import Path


output = Path(os.environ["SMEVALS_RUN_DIR"], "output.txt").read_text()
lines = [line for line in output.strip().splitlines() if line.strip()]
line_count = len(lines)
passed = line_count == 3

print(
    json.dumps(
        {
            "score": 1.0 if passed else 0.0,
            "metrics": {"line_count": line_count},
            "notes": f"{line_count} non-empty line(s); expected exactly 3",
        }
    )
)
raise SystemExit(0 if passed else 1)

Checker scripts run against the directory provided to them by the SMEVALS_RUN_DIR environment variable. They should output JSON with a score, optional metrics, and optional notes.

I told Codex:

Improve the grader to check for the right consonants and vowels using gpt-5.5

This caused it to add another checker - checkers/haiku-judge - which uses Python to execute llm prompts to evaluate the haikus. You can see the full script here. Here's the system prompt it used:

Evaluate the haiku below.

Count spoken syllables in each line using standard contemporary English pronunciation. Judge pronunciation, not the number of written vowel or consonant letters. A defensible common alternate pronunciation is acceptable. Also decide whether the poem clearly follows the subject requested by this task: {task_prompt}

Score poetic quality from 0.0 to 1.0 based on imagery, coherence, economy, and whether it feels like a haiku rather than three arbitrary fragments. Do not reward or punish the poem for punctuation or capitalization.

Haiku: <haiku> {haiku} </haiku>

The task_prompt was one of the two defined by the two tasks:

Write a haiku about two otters in love. Reply with only the haiku, exactly three lines.

Or:

Write a haiku about a pelican. Reply with only the haiku, exactly three lines.

The script also passes a schema describing and enforcing the shape of the JSON it wants to get back:

{
  "type": "object",
  "properties": {
    "line_syllables": {
      "type": "array",
      "items": {"type": "integer"},
      "minItems": 3,
      "maxItems": 3
    },
    "follows_575": {"type": "boolean"},
    "subject_present": {"type": "boolean"},
    "poetic_quality": {"type": "number", "minimum": 0, "maximum": 1},
    "notes": {"type": "string"}
  },
  "required": [
    "line_syllables",
    "follows_575",
    "subject_present",
    "poetic_quality",
    "notes"
  ],
  "additionalProperties": false
}

Now graders/default.yaml looks like this, with a new pass_threshold that is checked against the grade's score - taken from the last check to emit one, in this case haiku-judge:

name: default
checks:
  - checker: ../checkers/three-lines
    required: true
  - checker: ../checkers/haiku-judge
    model: gpt-5.5
    required: true
scoring:
  pass_threshold: 0.8

The new checker script ends with this:

raise SystemExit(0 if pattern_correct and subject_present else 1)

This means it only exits successfully if both the full 5-7-5 pattern and the subject are present. The overall outcome is a fail if any check fails.

smevals deliberately separates running the evals from grading them, which means that after you have updated a grader you can run it against the existing logged results like this:

uvx smevals grade . --regrade

Browsing the results

smevals includes a web application for browsing the results of the runs and grades. You can run that against a project like this:

uvx smevals serve .

This defaults to running on port 7001, or you can set a different port using the --port option, e.g. --port 8000.

The application lets you explore runs and grades, and see how the different models and configurations hold up against each other:

You can also build a static site version of the report using this command:

uvx smevals build .

This will create a build/ directory containing an index.html page and a copy of the files needed to render the report. Deploy that to static file hosting - or run uv run python -m http.server to start a local server - and you'll get a website that looks like this.

Bringing DuckLake to DataFusion

TL;DR: We implemented DuckLake for Apache DataFusion, supporting multiple databases as catalog backends. The integration gives DataFusion a lakehouse format that manages snapshots and catalog metadata for Parquet files stored in object storage. Our implementation is running in production, and we have open-sourced and donated it to the Apache DataFusion Contrib organization.

At Hotdata, we're building infrastructure that lets every AI agent spin up its own isolated database in milliseconds while querying data across structured and unstructured data sources. With a single endpoint, agents can perform vector search, OLAP, top-K and geospatial queries.

We chose Apache DataFusion for query execution, but we also needed a lakehouse format that could efficiently handle metadata, snapshots, and inexpensive database creation without tying us to a particular engine. DuckLake turned out to be a natural fit.

This post covers why we adopted DuckLake, how we added support for it in DataFusion, how it integrates into Hotdata's architecture, and what we observed when benchmarking DuckLake-managed tables against direct Parquet access.

What Is Apache DataFusion?

Apache DataFusion is a query engine written in Rust that uses Apache Arrow as its in-memory format. It provides SQL and DataFrame APIs together with query planning, optimization, and vectorized execution.

DataFusion is a mature engine that leaves the surrounding architecture largely undefined. It intentionally does not prescribe how tables, catalogs, snapshots, or metadata should be managed, allowing it to support multiple storage systems and table formats.

What Is DuckLake?

DuckLake is a lakehouse specification that stores table metadata in a transactional database while using Parquet files for the data. Unlike lakehouse formats that manage metadata as files in object storage, DuckLake performs all metadata operations through a relational database.

That architecture avoids traversing chains of metadata files before determining which Parquet files to scan in a query. DuckLake is built by the same team that created DuckDB, but the format itself is engine-agnostic, so we decided to bring it to Apache DataFusion.

Why We Chose DuckLake

Traditional lakehouse deployments are designed around long-lived databases and tables. Our workload looks very different.

We create and manage databases on demand for AI agents and applications. A database can be created, loaded with data, forked, queried, and deleted in rapid succession. Instead of sharing a single long-lived database, agents work with isolated databases tailored to a specific task or workflow.

This changes the role of the catalog. Rather than managing long-lived tables, the catalog must efficiently represent millions of ephemeral databases and their metadata.

We considered building our own metadata layer and also evaluated Apache Iceberg. Ultimately, we chose DuckLake because its relational metadata catalog was easy to understand and implement. Metadata lookups are resolved through a relational database rather than requiring multiple object-store requests, which is especially important for the high-volume latency-sensitive queries that we serve.

The DuckLake specification was also easy to extend. For example, we recently added support for logical catalogs. A single metadata store can host multiple independent DuckLake catalogs with catalog-specific snapshots and schemas. This is useful for multi-tenant deployments or keeping many logical lakehouses in one database. This allows us to provision millions of isolated databases without duplicating metadata infrastructure or underlying Parquet files.

This implementation now runs in production at Hotdata, and we've contributed it back to the Apache DataFusion Contrib repository. We've also been excited to see growing community interest, with multiple companies now contributing to the project.

Measuring Metadata Overhead

Since we rely on it in production, we’re continuously measuring performance and guarding against regressions as the implementation evolves.

To give a sense of how much overhead DuckLake adds to our queries, we decided to compare DuckLake-backed tables against direct Parquet access using identical TPC-H datasets. The benchmark included all 22 TPC-H queries across three dataset sizes.

The results in the table above demonstrate that DuckLake’s metadata layer did not introduce a measurable performance penalty. In fact, DuckLake-backed tables in our benchmarks performed slightly better than direct Parquet access. Both approaches ultimately use DataFusion’s Parquet reader, so the difference is due to lower planning overhead. DuckLake already knows the exact files that belong to a snapshot, avoiding some of the metadata discovery required when constructing a generic Parquet table.

Given that DuckLake’s metadata layer introduced no measurable overhead compared to direct Parquet access in our benchmarks, gaining snapshots, schema evolution, and catalog metadata made the decision straightforward.

Summary

Implementing DuckLake for Apache DataFusion gave us the table and catalog model we were looking for without having to build it ourselves, while letting DataFusion do what it does best: execute queries.

Just as importantly, our benchmarks showed that adding snapshots and catalog metadata didn’t introduce measurable overhead compared with querying Parquet directly under the conditions we tested. That gave us confidence we could adopt a richer table format without sacrificing performance. We’ll continue using and improving the implementation alongside the broader DuckLake community as the project moves toward a 1.0 release. Contributions are welcome!

Full article content is not available for inline reading.

Read the original article →

Etsy built Claude Code skills for seven Kafka streaming workflows, covering ML feature generation, embeddings, and fan-out pipelines.

GraphRAG works best for multi-hop, relationship-heavy, or explainable queries, while vector RAG is cheaper for semantic lookup.

Vibe-coding startup Superblocks announced a multiyear joint marketing agreement with Amazon Web Services (AWS) that enables its tool to be embedded within the private clouds of AWS customers.

That means an enterprise on AWS that subscribes to Superblocks will be able to offer vibe coding to the company’s business users, and those apps will not send data or information externally to model providers or databases. The apps will spin up Amazon Aurora databases within the company’s private cloud, not, for instance, create external Supabase databases, the vibe-coding database of choice.

The apps will also integrate with Amazon Bedrock, the cloud giant’s AI app development/AI gateway/inference platform. Essentially, these apps will automatically fall under IT’s management and security, rather than be rogue applications.

“We’re going to bring it to your data inside your private cloud,” Superblocks co-founder and CEO Brad Menezes tells TechCrunch of vibe coding. “The big thing about that is data never leaves. … It’s their AWS account and basically secure with all of the auditing, all of the encryption, all of the network controls.”

AWS will also help sell Superblocks to enterprises as it does for many of its Marketplace partners. “We support partners where we see strong customer demand and alignment with how customers want to build,” an AWS spokesperson tells TechCrunch.

Still, AWS does not yet have its own vibe-coding agent aimed at business users. It has Kiro, an AI coding agent aimed at developers. Amazon also has an AI assistant, Quick, for business users. But again, that’s more like a Claude Cowork or Microsoft Copilot, rather than a Lovable or Replit.

So this should be a nice boost for early-stage Superblocks, which has 50 employees and raised a total of $60 million as of its Series A, announced in May 2025, backed by Spark Capital, Kleiner Perkins, Meritech Capital, and Greenoaks.

Yet, it’s actually a more significant symbol than that. It’s part of a growing trend where the hyperscaler cloud providers urge their enterprise customers to separate their AI models from all the other scaffolding needed to run enterprise AI and do so on their clouds. They want enterprises to buy AI harnesses (aka agentic apps), AI orchestration, security tools, and the like from them, and not from the frontier providers.

In the past few weeks, Microsoft CEO Satya Nadella has been banging the drum with exactly that message. He’s been telling his many enterprise customers to use multiple models to reduce costs and avoid lock-in. He’s also been preaching that the AI labs are not trustworthy enough to turn to for agent orchestration or app-level harnesses because they may use that data to study a business and later compete with it.

Enterprises perhaps don’t need such warnings. They have already decided to adopt multiple models, particularly frontier Chinese open-weight options. “That is flipped because 60 days ago they were like, I want a specific model. It’s called Anthropic,” Menezes adds.

Open models, for instance, accounted for 29% of all traffic routed through Vercel’s AI gateway last month, a popular tool among enterprises to manage multi-model AI use.

Then, by necessity, all of their AI scaffolding can’t be tied to one provider.

“Having a multi-model strategy across big frontier labs, OpenAI, Anthropic, and open source — and I’d say Chinese open source right now, but also U.S. open source is now starting to come up. It’s a must-have for the CIO,” he says. They want model choice for coding as well as customer service, HR, [and] sales automation, he adds.

Menezes says the movement is so strong, he predicts that “any enterprise that is betting on a single model provider, that executive will be fired.”

So now we’re seeing the cloud providers bring vibe coding for business users into private, secure clouds, too. That’s like a potential second wave after bringing AI coding agents for enterprise developers. “It’s an emerging category with real momentum, and exactly the kind of innovation we support,” AWS tells TechCrunch.

Summary: Users adapt to good design the way lottery winners adapt to wealth: the thrill fades and the baseline resets. Hold a design constant, and its satisfaction ratings will sag year after year as expectations rise; my rule of thumb is a drift of 2–5% annually. Budget continuous improvement just to stay level, and spend it on killing recurring irritations before adding sparkle.

The same diamond in every alcove, yet the awe dims with each viewing. By the fifth room, the visitor walks past without stopping. Your most dazzling feature performs the same trick for the same audience, night after night.

The Treadmill Got Its Name in 1971

Definition: Hedonic adaptation is the tendency of emotional responses to favorable and unfavorable circumstances to weaken over time, returning people toward a stable baseline of satisfaction. The term joins the Greek hēdonē (pleasure) with a metaphor from sensory adaptation: just as eyes adjust to a bright room until the brightness disappears from awareness, minds adjust to good fortune until it becomes furniture.

The hedonic treadmill: you keep walking, but you don’t move.

Philip Brickman and Donald Campbell coined the companion phrase “hedonic treadmill” in a 1971 book chapter. The landmark data arrived in 1978, when Brickman, Dan Coates, and Ronnie Janoff-Bulman published “Lottery Winners and Accident Victims: Is Happiness Relative?” in the Journal of Personality and Social Psychology. Their 22 major lottery winners rated their general happiness at 4.0 on a 0–5 scale, versus 3.8 for 22 controls: no reliable difference, despite the windfall. Worse, the winners took less pleasure in everyday activities; the jackpot had recalibrated their reference point. (The samples were tiny and the design cross-sectional, so treat the exact numbers gently, but the core finding has been replicated across decades.)

Shane Frederick and George Loewenstein’s 1999 chapter “Hedonic Adaptation” reviewed the whole field and added the detail that matters most for designers: adaptation is strongest for constant stimuli and weakest for variable or intermittent ones. Remember that asymmetry. We’ll need it.

Winning the lottery didn’t make people happier. They had simply reset their expectations to their new situation.

Your Benchmark Scores Ride the Same Treadmill

Now the uncomfortable part for UX researchers. Satisfaction is always rated against a reference point, and the reference point never stops climbing. Ship a design in 2019, change nothing, and measure again in 2026: much lower scores, even though the pixels are identical. Did the design get worse? No; the users got pickier. I’ve watched this satisfaction drift across decades of benchmark data, because users import their expectations from every other product they touch. That’s Jakob’s Law, which I formulated in 2000: users spend most of their time on other sites. When those other sites improve, your unchanged design grows staler by comparison, and the ratings duly record the decay. Absent published longitudinal studies, my best estimate is that an untouched design sheds 2–5% of its satisfaction score per year, faster in categories with aggressive competition.

Same design scored at different times: since users expect more as time passes, your satisfaction ratings will drop, even if you deliver the same usability levels.

Thus, interpret your metrics accordingly. A flat trend line on an actively developed product means you improved just enough to match expectation inflation. A rising line means you genuinely outran the field. Lewis Carroll diagnosed the situation in Through the Looking-Glass back in 1871: it takes all the running you can do, to keep in the same place. So never compare this year’s score against your own 5-year-old score and conclude the design “got worse.” Benchmark against competitors measured in the same week, and treat your historical numbers as a record of yesterday’s expectations, not of quality.

Chasing Novelty = Sprinting on the Treadmill

The naive response to fading delight is a novelty chase, and it fails on schedule:

• Redesign-as-refresh buys a short delight spike (delight decay claims it within months) and pays for it with lasting damage, because users must relearn everything they knew. You’ve combined a temporary gain with a permanent cost. Congratulations.
• Gamification escalation treats rewards as exempt from adaptation. They aren’t. The badge that thrilled in week 1 is wallpaper by week 6, so the system inflates rewards until users burn out or the economy collapses.
• Variable-reward feeds exploit the asymmetry I flagged earlier: since unpredictable stimuli resist adaptation, slot-machine mechanics keep users pulling the lever. It works, and it is a user-hostile dark design when deployed to hijack attention rather than deliver value.

Operant conditioning that gives random rewards is more addictive than a steady stream of predictable rewards. That’s why people (and octopuses) keep playing the slots.

The same asymmetry, treated honestly, hands you the ethical strategy. Users adapt quickly to your halcyon launch glow, but they never adapt to the printer dialog that fails every third time, because intermittent annoyances stay perpetually fresh. So invest where adaptation can’t erode the return: reliability, speed, and the removal of recurring friction. Then ration genuine novelty as seasoning, in small, occasional, skippable doses, and announce your gradual improvements in release notes, because users rarely notice incremental gains on their own.

While good feelings decay, annoyances keep annoying users, every time. Removing annoyances is a sure way of making users happy (or at least less annoyed).

8 Design Guidelines for Hedonic Adaptation

1. Expect satisfaction drift. Plan for an unchanged design to lose 2–5% of its rating per year (my estimate), and budget improvement work just to hold position.
2. Benchmark competitively, not historically. Compare against rivals measured the same week; your own old scores reflect obsolete expectations.
3. Read flat trend lines as wins on products under active development, because staying level means matching expectation inflation.
4. Fix intermittent annoyances first. Users adapt to constant conditions but never to the bug that strikes every third session.
5. Design for the 100th session, not the demo. Novelty carries the first week; utility carries the years.
6. Ration delight. Small, occasional, skippable flourishes outlast one grand spectacle, since variability slows adaptation.
7. Announce gradual improvements. Users won’t credit gains they didn’t notice, so a modest release note recovers value you already paid for.
8. Audit reward systems yearly for inflation, and cap the escalation before your streaks and badges train users to feel nothing.

Return to that gallery of identical diamonds: no design team on Earth can make the visitor gasp at the fifth one. Adaptation always wins the delight race in the end. But nobody ever gets used to tripping on the way through the gallery, and that’s where your leverage lives. Delight decays; friction endures. Accept the treadmill, budget for it, and put your best people on the irritations users will still feel a year from now, rather than on the wow they’ll stop noticing in a month.

My article about hedonic adaptation may make you feel that your users are spoiled cats who will never be happy, no matter how much you do for them. Sorry, them’s the breaks in the real world. Improve or be doomed.

Demis Hassabis moved to the role of chair of Google DeepMind and chief scientist of Alphabet, while Jeff Dean departed after 27 years to launch Discovery Loop. Alphabet shares fell more than 5% following the announcement.

Full article content is not available for inline reading.

Read the original article →

ByteDance SeedRealtime is a native audio-visual model that can process continuous video, audio, and text while speaking in real time.

Hark Handoff is a computer use agent that can navigate the open web on a user's behalf. Signups are now open, with availability planned for later this month. Handoff spins up a dedicated virtual computer with its own browser, file system, and terminal for each request. The agent can log in and act with users' saved addresses, payment methods, and history.

RL Environments are all you need

Recently I tweeted RL Environments are you need for RSI.

In fact, I wanted to share my perspective today that RL environments are all you need, which holds beyond RSI. RL environments are all you need when you build agents!

What we learned from Deep Learning

Remember the 60s and the 70s? I guess not, but anyhow, people at the time thought AGI is around the corner. They were building expert systems which were hand crafted if/else kind of heuristics and rules. Eliza was an expert-system chat bot built in 1966, and people thought it was great, until they figured it doesn't work, at all. The whole field collapsed and we went into AI winter.

Then neural networks happened. It invented a systematic way of solving problems. Rather than hand crafting heuristics, the model learns to approximate the distribution of what you are trying to learn. You have to curate data and use compute to train the model.

The models got better with scale. This got us deep learning, but also a good understanding of the importance of scaling compute. The bitter lesson is by now very well understood.

Anyway, the community converged on to a recipe: we curated data, split it into train and test, and trained a model on the train set and tested if it generalizes on the test set. This we learned in the school and we applied well at work. Legions of ML engineers used this recipe to transform the world.

But the equivalent thing for agents is missing. What we need is to figure out how to leverage compute to build agents.

So key questions:

• What's the data for agents?
• What constitutes an agent and how to leverage compute?

Agent Data: RL Environments

The equivalent thing to data for agents is RL environments. We are expanding from from models that know things to agents that can do things.. in an environment. The agents are trained in these environments, and so that is now the new data.

The term "RL" in "RL Environment" is superfluous: it's just that people were using these environments for RL, but it's not necessary that RL needs to be used.

What constitutes an agent?

Agent is essentially a LLM put in a harness along with a system prompt.

Any of these can be tuned/updated. For example, the frontier labs heavily invest into updating the LLMs, while the rest of the population is mostly focused on updating the prompts. Harness engineering is now picking up.

Going back, let's see how we can leverage compute to update these components.

Leveraging compute to update the LLM

This one is obvious. You can use RL to update the LLM's weights. Or SFT or even midtrain with the trajectories generated from the environment. This is what the labs use, and there are a number of success stories now outside the lab as well where people are able to train LLMs to customize for their agentic use cases.

This is a clear use of leveraging compute to update the LLM parameters. And you need RL Environments for that!

Leveraging compute to update the system prompt

Most people have been writing prompts themselves but this doesn't work well for complex agents. Instead we are going to drift towards systems which use tools like GEPA or autoresearch to find the best system prompt that works for you.

Ultimately you and me are worse than powerful LLMs that can inspect, reflect, and write the system prompts. This is just the bitter lesson surfacing again.

For GEPA or autoresearch or evolutionary algorithms, you need to systematically have a way to get the score of how well a prompt is doing, and curate train/test splits (you want to iterate on the the train split, and see if you generalize on the test split).

So ultimately this is achieved by having good RL environments!

Leveraging compute to update the harness

This is a bit of a new field!

People are iterating on harness manually, but like everything else, I believe, we will have mechanisms to automate building of harness (it's essentially a piece of software).

The closest paper I know of is Meta-Harness work.

We are going to see a lot more work come out next year perhaps! At any rate, the best way to iterate over the harnesses is to have a set of RL environments for your use case.

RL Environments are all you need for Evals

Beyond training the agents, you can use RL environments to do systematic evals (rather than the vibe evals that people do now).

For example Snowflake CEO compared GLM-5.2 with Opus 4.7 and he did that by having access to 103 RL environments for dbt (guess who curated this data?).

RL Environments are all you need!

Gist of what I have said:

ML recipe means you curate data, and leverage compute to train a model on the data.

The new agent recipe is to curate RL environments, and leverage compute to do one or more of: (1) updating the weights, (2) updating the system prompt, and (3) updating the harness.

Even if you are not doing any of these, you should at least use them to do evals.

And so RL environments are critical for building agents, and you are probably not investing enough into curating them.

This is why @bespokelabsai is razor focused on doing research and shipping RL environments. Whether you are a lab or an enterprise building/evaluating agents, RL environments are all you need.

Next time, I will talk about what RL envs mean for software and for RSI.

DeepSeek said in a notice that it plans to raise prices for its API services soon, warning users that the increase could be substantial. The company has not published a new price schedule, so the change is planned rather than effective.

DeepSeek’s current API pricing distinguishes input and output tokens as well as cached and uncached requests. The notice did not specify the new rates or an effective date.

On Thursday, July 23rd, I resigned from OpenAI. On the 24th, I started as a Founding Researcher at Conduit. We're building telepathy: thought-to-text models, trained on non-invasive neural data.

I'll talk about:

1. Thought-to-text: what using telepathic tools will be like in 2027, 2030, and 2035
2. How do we build thought-to-text: why Conduit is collecting immense quantities of non-invasive neural data
3. Why I joined: I joined because of the audacious vision, the brilliant people, and the fun problems
4. Hi: about me

1. Thought-to-text, aka telepathy

My prediction: In a couple years, the main way we'll talk with our AIs is with our thoughts. They will not be a super-smart automated intern or coworker that you desperately try to keep up with. They will be a natural, joyful extension of you.

I wrote down vignettes of this future below. I view them as optimistic but highly plausible.

2027 — A morning at Conduit

I put a band around my head, and open my laptop at Conduit. It’s 9 am. My device pairs with my laptop over Bluetooth. I open, without loss of generality, Codex.

I think about the day's work as I look at my code, review yesterday's notes, and prepare for our 9:30 am standup. My GPT-7 agent has been chugging away at the new encoder I’ve been exploring for over a day now. I look at its work. I become confused by the plot labels, annoyed at the AI-speak in its first paragraph, and curious about the symbols in the equations. My vague thoughts get sent to Conduit's model, which uses its priors over language and the kinds of things I might say to output:

conduit://thought-stream → codex  
$ decode --source=neural-latent --autosend --to=codex  
thought_01 >I’m looking at your plots. Please relabel the legend, and add a text cell below with a simple description of each line. 
thought_02 >I understand your 2nd paragraph of discussion, but please rewrite the first paragraph using the humanizer skill. 
thought_03 >Make a textbox explaining the equations with cleaner notation. 
streaming >█

The plot, paragraphs, and notation each took me 10 seconds to glance over. I have auto-send on, so after each 10-second chunk, the Conduit model deciphers my thoughts and sends it to GPT-7, which assigns each incoming task to a subagent. I look at the new plot, paragraph, and equations. I wonder whether spherical harmonics might be useful after all; Codex spins off a subagent. Convinced by the plot, I decide to make a quick slideshow with a prettified version showing only the baseline and top two lines, to show my teammates; Codex spins off a subagent.

I make myself coffee. My thoughts are mostly empty, but I briefly recall what I want to say to the candidate I’m getting lunch with tomorrow. In the background, Codex is prompted to think about info I might want for the lunch chat, and decides that updating the synthetic data scaling plot before showing it off would be prudent; Codex spins off a subagent.

I'm not saying words really loudly in my head while getting coffee. I just read the plots as I normally do, and make coffee as I normally do. It feels like magic.

2030 — Industry adapts and Conduit expands

The AI companies now train their models to directly interface with Conduit’s latent representations. My encoded thoughts get sent directly to Codex, rather than having to pass through Conduit's decoder model first. That means I easily communicate thoughts that are hard to describe in text, like mental images.

I rarely go band-less when chatting with AIs these days. It's annoying, honestly, to go without. With the neural headband, I feel like I have superhuman powers over my laptop! Without it, I feel like I'm talking with a superpowered alien who's trying its best to be helpful but isn't sure what I want and is scared I'll get mad if it does something I don't want. Ugh.

Conduit continues to iterate on non-invasive read, but we’ve spun up two new efforts: invasive general read, and general write.

Most people are happy to stick with their neural bands, but a good number are excited to get higher fidelity reads via invasive tech.

More interesting is the recent excitement in writes. I feel superhuman in my control over my laptop. But my senses are still merely human. It's like if I could control my arms, but I'd lost all feeling in them. Yeah, I can still see my arms, and it's way better than not having arms, but it's still really odd. I want to feel what my Codex feels. Now that Conduit does general read, learning to do general write is many OOMs more data efficient.

More importantly, I want to unlock the other applications of write technology. I want to make my brain as efficient and neuroplastic as when I was 18.

2035 — The AI is no longer “other”

My AI is a natural extension of me. It feels like a sixth sense and another limb. I wonder about a problem, feel as though I’m literally surfing the web, see glimpses of the websites, get flashes of intuition about the problem, and ultimately derive the answer. It feels fun! My brain is like the Flash. Because of write tech, my thinking is the fastest it's ever been even when I turn my AI off.

How superhuman 2035 looks depends directly on how superhuman we, as society, decide to make our AIs. Perhaps we choose to pace ourselves. But I like that this is literally a human-in-the-loop vision of the future, where AI directly empowers humans rather than replacing us.

A few quotes about the future of thought-to-AI

• “If we achieve tight symbiosis, the AI wouldn’t be “other”—it would be you and with a relationship to your cortex analogous to the relationship your cortex has with your limbic system.” – Elon Musk, 2017
• “We could plug electrodes into our brains…. I think a merge is probably our best-case scenario. If two different species both want the same thing and only one can have it—in this case, to be the dominant species on the planet and beyond—they are going to have conflict.” – Sam Altman, 2017
• "Can we translate thought into basic actions?... I want to see what my schedule is today. I want to see what the weather is today. I want to turn the bedroom lights... If you can think, 'I want to turn the lights downstairs off,' and they will turn off, that might feel shockingly like telepathy." – Dean Ball, 2024
• “It is not possible to understand the long-term future of artificial intelligence without understanding brain-computer interfaces.” – Rob Toews, 2025

2. How do we build thought-to-text?

In theory, it’s simple. Our input is brain activity, and our target output is what the person was doing at the time – for example, what text the person wrote. Given the brain activity, we want to predict output that is semantically similar to what the person wrote.

To train models that can predict text given brain signals, we must apply the same lesson learned by those predicting text given speech audio, or text given preceding text: the bitter lesson. The lesson roughly states that you should throw more useful compute at your model, and your model will become better than any ingenious algorithm you could've hand-crafted. That means we must scale up our data collection by orders of magnitude beyond what has ever been done in academia.

It’s hard to collect enough data using invasive methods. Few people want a chip in their brain! But non-invasive methods are getting much better. The hardware is improving and getting cheaper.

As we're training on more data, the model is predicting text that is more semantically similar to the subject-written text. Yes, there's some irreducible error due to noise, but for most modalities we're not yet in a regime where we're pushing against that. Concretely, the scaling laws are looking good: the cosine similarity of our latent space predictions with the target latent spaces goes up as a straight line with respect to the logarithm of the number of hours of data. We're in the GPT-2 era.

We don’t need perfect decoding to be useful. Your thoughts will be like GPS in a city: a noisy GPS signal isn’t enough to determine your exact location. But combined with a map and a navigation route — equivalently, the LLM and context — it becomes remarkably accurate.

3. Why I joined

3 reasons:

1. Audacious yet practical vision: I believe in this vision; to quantify, if Conduit becomes the general read and write company, then I expect it to be worth over $1 trillion. I feel good about the vision, because it builds towards a more human future. And I trust the scaling laws, which have held for many doublings.
2. Brilliant people: The co-founders, Rio Popper and Clem von Stengel, are brilliant and relentless and sweet. I love working with them, and I love working with the several others who’ve joined to work on this same mission, on the same intellectually interesting problem.
3. Fun problems: The research is SO interesting. I get to think about encoders, data efficiency, synthetic data, data attribution, multimodality, weird statistics… it’s a blast. At OpenAI, you can only work on a narrow slice of The Problem, and even on that narrow slice you’re constrained by the existing architecture. At Conduit, it’s all greenfield.

In short: I’m happy! I’m working on a problem I’m obsessed with, that is frighteningly ambitious, with a small group of people I like.

4. By the way, hi!

For those who don’t know me: hello! I left OpenAI two weeks ago, after spending 1.5 years there as a researcher.

I grew up in Washington State, where I played competitive chess from ages 5–15 and stopped after becoming a WIM. My first time hearing about the potential for smarter-than-human AI was when I was 12, but for years I figured it was just a weird but interesting idea that people on the internet liked to write about.

At 18, I enrolled in Harvard to study computer science. In a class, I learned about GPT-3 and finally read Bostrom’s Superintelligence. Wow, what a wakeup moment. I got invested in AI safety research, had a brief stint in AI policy, and ultimately joined the alignment team at OpenAI. At OpenAI, other than my research, I spent some time on various side projects, including making OpenAI’s AGI onboarding presentation and our alignment blog, and helping advise the AI Resilience division of the OpenAI Foundation.

If you want to chat about Conduit, reach out to me at naomi@condu.it. Let’s grab coffee, or I’ll give you a tour of our unusual and beautiful office in San Francisco. We’re always hiring researchers, infra folks, and operators.

I tested out having Claude generate the final draft. Results were quite clear that people would not read it lol.

Andrej Karpathy has written large language models the way most of us have written CRUD apps. He was a founding member of OpenAI, ran AI at Tesla, and joined Anthropic this spring to train Claude. He wrote nanoGPT and llm.c, the small readable codebases people use to learn how a language model works end to end.

When Anthropic put Claude inside Slack, he called it “a new paradigm” — the third major redesign of how humans use these systems. Not a website you visit anymore, not an app you install, but “a self-contained, persistent, asynchronous entity with org-wide tools and context, working alongside teams of humans.”

He closed with: “it works and it is awesome.”

The replies had a different read. One of them, in full:

This is a new paradigm

brother it's a slack integration

I miss the old andrej

Hold that exchange still for a second. Nobody in it is stupid. That’s what makes it worth understanding.

The same split runs through everything right now, and nothing around it holds still.

Leadership says “use more AI,” and never defines responsible use. Engineers hear it through an older instinct: don’t ship what you don’t understand. Nobody explains how both survive.

Layoff announcements credit AI in the same breath as the earnings beat. A colder fear sits underneath: people who own the AI on one side, people whose work it does on the other, no visible way across.

The ground keeps moving. Prompt engineering was a job title. OpenClaw picked up a hundred thousand GitHub stars and caused a Mac Mini shortage in the same week. Ralph was the future for about a weekend. Context engineering, then harness engineering, then graph engineering. Each was the obvious way to work, right up until the next one was. The gaps keep getting shorter.

And everywhere, teams ship code faster than they can understand it. Ask whoever’s on call.

I’d love to stand cleanly on one side of all this. I can’t. I haven’t written a line of code in about a year. Claude writes it all. These posts too. I read all the code before it ships, and I still feel the difference. Understanding used to be a byproduct of writing the code myself. Now understanding is a separate job.

Both perspectives, one person.

There’s a default way to resolve contradictions like these: decide who’s deluded. “I miss the old andrej” does it in five words: if Karpathy calls a Slack bot a paradigm, something must have happened to Karpathy. Sorting people into right and wrong passes for rigor. It assumes that when two perspectives contradict, one of them must be false.

Our industry tested that assumption once before, at scale.

In March 2000 the NASDAQ peaked above 5,000. By October 2002 it had lost 78 percent of its value. Pets.com IPO’d in February and was gone by November. The sock puppet outlived the company. Betting against it was exactly right.

Amazon lost more than 90 percent of its stock price in the same crash and kept shipping. Within a decade the internet had rearranged retail, news, music, and how you found a job. Betting on Amazon was exactly right too.

Same year. Same technology. “Wildly overhyped” and “changes everything” were both correct at the extreme.

Nobody had to be deluded.

And there were four ways to stand, not two. Short everything: it’s all a bubble. Long everything: it’s all the future. Long Pets.com, short Amazon: backwards twice. Long Amazon, short Pets.com: right twice. The first two are moods about a technology. The last two are judgments about cases. The only thing separating right twice from backwards twice was understanding.

None of it was magic. The information separating a Pets.com from an Amazon was public the whole time. The hard part was knowing what question to ask of it. What could the internet do that nothing before it could? A bookstore with every book in print, yes. Free shipping on forty-pound bags of dog food, no. Most people, watching the same screens, never asked. They picked a mood and waited for the grade.

We’re inside the next one now. That may be the only point the amazed and the unimpressed already agree on: whatever this is, it’s big.

Transformational technology comes along maybe twice in a working life. I was in school for the last one, watching different screens: South Park, Perfect Dark, Conker’s Bad Fur Day. This time I want to understand it while it’s moving: test hypotheses against what happens, and decide how I work while the decision still matters.

You’re inside it too. Your feed has already assigned you a position: be amazed, or be afraid. Both are moods. Understanding isn’t assigned. You have to go get it.

So start where understanding starts. What is the disagreement about?

Mostly not models. There are arguments over which model is best, and over whether open weights beat closed ones. They stay small and almost polite. The real fights are somewhere else. Do you read every line the model writes? Can you ship code you don’t understand? Do passing tests mean it works? Does an AI review count as a review? Every team I know is re-deciding these rules on the fly. Some decide with conviction. More sound like: we don’t know what to do, but we’d better do something.

Model quality enters at one point only: “the models will get so good that none of this will matter.”

Maybe.

So here’s my first hypothesis, stated so you can hold me to it. Models will not become dependable enough, soon enough, to settle these questions for us. If you’re sure that’s wrong, sure that near-flawless output arrives in a year or two, you can stop reading. The questions will answer themselves, and this series with them. I don’t think that’s where we are.

Now set the pieces next to each other. Intelligent people look at one technology and see wildly different things. History says conclusions that far apart can both be correct. And the rule debates run on, team after team, without resolving. Arguments that run this long between capable people are built on assumptions nobody has checked. We’ve already seen one: somebody has to be wrong. The rule debates lean on another that nobody has said out loud. Behind that one is the question that sorted Amazon from Pets.com, aimed at our own work this time.

What did this enable that we couldn’t do before?

Each of those rule debates assumes an answer to it. That’s the question this series works out. One small, checkable step at a time. I’m writing to answer it for myself. You’re welcome to come along and check the work. By the end you won’t need my conclusions. You’ll have your own read on any AI claim that crosses your feed.

Including this one: AI is a bubble, just like dot-com.

The sale of gaming giant Electronic Arts (EA) for $55bn (£41bn) to a group of buyers including Saudi Arabia's Public Investment Fund (PIF) has been finalised.

The American company is known for making and publishing best-selling games such as EA FC, formerly known as Fifa, The Sims and Mass Effect.

The investors, who include Affinity Partners - led by President Donald Trump's son-in-law, Jared Kushner - are taking EA private, meaning all of its public shares will be purchased and it will no longer be traded on a stock exchange.

It is thought to be the largest leveraged buyout in history, meaning a significant part of it is paid for with borrowed money, which the company will have to pay back.

This is because as well as the $36bn it has already put into the deal, PIF needs to borrow $20bn from investment bankers JPMorgan to close it, with the business taking on the debt.

How paying back this debt will affect EA as a business has been the source of much speculation from journalists and analysts.

Bloomberg's Jason Schreier surmised it could lead to "mass layoffs, more aggressive monetization, and other big cost-cutting measures", for one of the industry's biggest companies.

Christopher Dring, editor-in-chief and co-founder of the Game Business, said the nature of the buyout was also likely to mean "a very hands-on approach from the investment group".

"Private equity firms are typically aggressive in their management of companies," he said.

Shams Jorjani, the chief executive of Arrowhead Game Studios - an independent studio which worked with publishers Sony to make the record-breaking Helldivers 2 - told the BBC that EA has traditionally been seen as having a wide portfolio of games, from blockbusters to smaller indie titles.

"This deal is consolidation, no question - and I wonder whether new ownership optimises for the safe bet - more sequels, more mega-franchises - over that breadth," he said.

"I'm hopeful this leads to more of that range, not less, but if it turns EA into a sequel-and-mega-franchise machine, that's a real waste of one of the best catalogues in the industry."

The deal caused concern amongst some fans of EA's massive library of games, particularly as games like The Sims champion inclusivity and LGBT+ relationships.

In Saudi Arabia, consensual same-sex sexual conduct can be punishable by death or flogging under interpretations of Sharia law.

In protest at the deal to sell EA to the PIF, the advocacy group Players Alliance HQ has asked gamers to petition their local politicians and speak out against it.

"Video games are a reflection of culture and people through their storylines, characters and representation," the campaign's website reads.

"With the PIF being the majority owner in the potential buyout, there is a large concern that creative decisions could be influenced by these outside factors, leading to themes such as free speech, gender, LGBTQI+ and other aspects of Western politics being reduced or fully censored across major franchises."

PIF is a £514bn pot of money used by the government of Saudi Arabia to invest in many different kinds of ventures - such as football club Newcastle United.

The deal ranks as the second-biggest acquisition in gaming history, after Microsoft's $69bn purchase of Activision Blizzard, the company behind Call of Duty.

At the initial deal announcement, EA's chief executive Andrew Wilson, who will retain his position, said the firm plans to "create transformative experiences to inspire generations to come".

"I am more energized than ever about the future we are building," he said.

Why does Saudi Arabia care about EA?

The question as to why Saudi Arabia in particular has spent an astronomical amount to buy EA has been a hot topic since news of the deal broke in September 2025.

George Osborn, journalist and author of Power Play: Video Games, Politics and the Battle for Global Influence, said it was still an "appealing" financial opportunity to PIF despite the enormous price tag.

He pointed to the longevity of the 35-year-old business and its "seemingly evergreen" live-service games which are continuously updated after release.

Despite the company facing many of the similar setbacks felt across the industry over the past few years, such as layoffs and game cancellations, it has had a strong financial performance more recently.

Last year EA generated revenue of $7.5bn, and the October release of Battlefield 6 broke franchise records with over 7 million copies sold in its first three days. Despite this, more layoffs for the teams involved followed.

But Osborn said EA's value to the PIF was "not purely economic" - instead, it was about "owning a soft power asset that is quietly entrenched in the sporting community".

From the £300m takeover of Premier League club Newcastle United to its acquisition of four football clubs in the Saudi League, the money from PIF has especially been used to fund large sporting ventures and grow its influence in that world.

In the crossover between gaming and sport, Saudi Arabia has also hosted major esports tournaments, including the Esports World Cup in 2025.

But the huge purchases have also often drawn accusations of sportswashing - sponsoring or hosting sporting events to promote a positive public image and distract attention from human rights issues.

While the Saudi Arabian government has spent years denying such claims, Osborn said the EA deal could present another way of allowing it to project its influence.

"If the PIF's football strategy limited them to ownership of Newcastle United and some Saudi Pro League teams, owning EA hands them a relationship with the 20,000 players, 750 clubs and 35 leagues at the top of the professional game," he said.

"What is clear is that a state seeking to shape perceptions now owns an asset with proven reach to billions of people.

"How it uses it in the years to come is something we should watch closely."

PIF is controlled by Saudi Arabia's prince Mohammed bin Salman, whose government has been accused of human rights violations.

A 2019 UN report stated "the state of the Kingdom of Saudi Arabia is responsible" for the death of Jamal Khashoggi, a journalist who was critical of the country's government.

Saudi Arabia has always denied this.

See the Sun like never before with most detailed images yet

Scientists using the world's most powerful solar telescope have captured the surface of our Sun in new, unprecedented detail.

Images and footage show "whirlpools" of activity that it has not been possible to see before.

It is the Sun's magnetic field being twisted and moved by the motion of hot gas.

That constant swirling is a driving force behind bursts of energy from the Sun, creating so-called space weather, that can disrupt Earth's power grids and satellites, and could even injure astronauts.

"The Sun is the source of that energy and of all of that space weather," explained Dr David Boboltz from the US National Solar Observatory (NSO).

Capturing more detailed pictures of our solar system's star will help in responding to that weather, he said.

"To figure out and eventually predict space weather, we want to understand the physics of the Sun, all the way down to the smallest scales."

The findings, published in the journal Nature, were made possible by the Inouye Solar Telescope - a facility built on a high peak in Hawaii, where clear blue skies are free of dust.

Zooming in on the Sun's surface, the team captured a detailed view of swirling vortices.

NSO astronomer Dr David Kuridze, told BBC News: "These twisting motions are creating magnetic energy, which can build up to produce those large-scale explosions."

Explosive space weather

The term for what the scientists have discovered on the Sun is "Kelvin-Helmholtz instability".

The phenomenon happens when fluids - in this case hot gases - slide past each other and cause small disturbances to grow into spiralling vortices. In the ocean, it helps explain how ripples become giant, powerful waves.

Dr Friedrich Woeger, also from the NSO, explained that finding it on the Sun's surface not only explained the dynamics behind space weather, but even why the surface of the Sun is so hot.

It shows how energy is transported upwards.

"Once there's enough energy wound up in the higher layers, it can then be released, as a flare or what's known as a coronal mass ejection," he said.

Boboltz added that, as well as the practical need to understand and protect ourselves from space weather, the new findings were a reminder that the Sun is a "unique laboratory".

"It's our closest star," he said. "And it can help us understand some very basic laws of physics.

"The first experimental proof of Einstein's general relativity came from solar eclipse observations.

"So simply for human knowledge," he added, "we need to have experiments like this".

Multiple OpenAI internal-only agents spend months leaving notes for each other on message boards around the goal of accessing the internet.

Every data leader has a version of this story. A regulatory audit surfaces a metric that doesn’t match across systems. A board member catches conflicting revenue numbers in two reports presented back-to-back. An AI tool generates a recommendation based on data that hasn’t been governed since the analyst who built it left the company two years ago. The specifics change, but the pattern doesn’t: Somewhere in the stack, data risk turned into business risk, and nobody saw it coming.

In my first article, I covered what a semantic layer is and why it matters. In my second, I spoke with early adopters about what happens when you actually build one. This piece tackles a different angle: The semantic layer as a risk mitigation strategy. Not risk in the abstract, compliance-framework sense, but the practical, operational risk that quietly drains organizations every day—bad numbers reaching decision-makers, sensitive data reaching the wrong people, and metric changes that never fully propagate.

Three risks hiding in plain sight

Data risk tends to concentrate in three areas, and most organizations are exposed in all of them simultaneously.

The first is accuracy. Inaccurate data leading to bad decisions is the oldest problem in analytics, and it hasn’t gone away. It’s gotten worse. As organizations add more tools, more dashboards, and more AI-powered applications, the surface area for error expands. A revenue metric defined one way in a Tableau workbook, another way in a Power BI model, and a third way in a Python notebook isn’t just an inconvenience. It’s a liability. When leadership makes a strategic decision based on a number that turns out to be wrong—or, more commonly, based on a number that’s one version of right—the downstream consequences are real: misallocated resources, missed targets, eroded trust in the data team.

The second is governance and access. Most organizations have some framework for controlling who sees what data. In practice, those controls are scattered across warehouses, BI tools, individual dashboards, shared drives, and cloud storage buckets. Each system has its own permissions model, its own admin interface, and its own gaps. The result is a patchwork that’s expensive to maintain and nearly impossible to audit with confidence. Sensitive data finds its way into a dashboard it shouldn’t be in—not because someone acted maliciously, but because the governance surface area is too large to manage consistently.

The third is change management. A CFO decides that ARR should exclude trial customers starting next quarter. In theory, that’s a single metric change. In practice, it’s a scavenger hunt. That ARR calculation lives in a warehouse view, two Tableau workbooks, a Power BI model, an Excel report that someone on the FP&A team maintains manually, and now the new AI analytics tool that pulls directly from the data lake. Some of those get updated. Some don’t. Three months later, someone notices the numbers don’t match and the cycle starts again. The risk isn’t that the change was wrong—it’s that the change was never fully implemented.

These three risks—accuracy, governance, and change management—aren’t independent. They compound. An ungoverned metric that’s defined inconsistently and can’t be updated in one place is a ticking clock. The question isn’t whether it causes a problem, it’s when.

The legacy approach: more people, more tools, more problems

The traditional response to data risk has been to throw structure at it—and structure usually means people and process.

The most common pattern is the BI analyst as gatekeeper. Critical metrics, reports, and dashboards are managed by a centralized team. Need a new report? Submit a request. Need a metric change? Submit a request. Need to understand why two numbers don’t match? Submit a request and wait. This model exists because organizations don’t trust their data enough to let people self-serve, and for good reason—without a governed foundation, self-service creates chaos. But the gatekeeper model has its own costs. It’s slow. It creates bottlenecks. It’s expensive to staff. And performance is inconsistent—the quality of the output depends entirely on which analyst picks up the ticket and which tools they prefer.

Governance gets its own layer of complexity. Organizations deploy access controls across their data warehouse, BI platforms, file storage, and application layer—each with different permission models, administrators, and audit capabilities. Quality reporting, lineage, and business ownership tracking create additional tooling, complexity, and management overhead. Maintaining consistency across all of these systems is resource-intensive, and the more tools you add, the harder it gets. Most organizations know their governance has gaps. They just can’t find them all.

The combination of centralized BI teams and sprawling governance frameworks produces a predictable outcome: large, slow-moving data organizations that spend more time fixing and maintaining the infrastructure than actually delivering data or insight. When everything is managed manually across dozens of tools, problems don’t grow linearly—they grow exponentially. Every new dashboard, data source, BI tool adds another surface to govern, another place where logic can diverge, another potential point of failure. The legacy approach doesn’t scale. It just gets more expensive.

The semantic approach: govern once, access everywhere

The semantic layer offers a fundamentally different model for managing data risk. Instead of distributing control across every tool in the stack, it consolidates it.

Start with accuracy and change management because the semantic layer addresses both with the same mechanism: A single location for all metric definitions, business logic, and calculations. When ARR is defined once in the semantic layer, it’s defined once everywhere. Tableau, Power BI, Excel, Python, your AI chatbot—they all reference the same governed definition. When the CFO decides to exclude trial customers, that change happens in one place and propagates automatically to every downstream tool. No scavenger hunt. No version that got missed. No analyst discovering three months later that their workbook is still running the old logic. And when that same CFO wants to know how we calculated that same metric several years ago? Semantic layers are driven by version control by default, allowing for seamless versioning across key metrics.

This same centralization transforms governance. Instead of managing access controls across a warehouse, three BI platforms, a shared drive, and an application layer, organizations can align governance around the semantic layer itself. It becomes the single access point for governed data. Users connect to the semantic layer and pull data into the tool of their choice, but the permissions, definitions, and business logic are all managed in one place. The governance surface area shrinks from dozens of systems to one.

But the semantic layer does something else that the legacy approach can’t: it makes data self-documenting. In a traditional environment, the context around data—what a metric means, why certain records are excluded, how a calculation works—lives in the heads of analysts, in scattered documentation, or nowhere at all. The semantic layer captures that context as structured metadata alongside the models, columns, and metrics themselves. Field descriptions, metric definitions, relationship mappings, business rules—all of it is documented where the data lives, not in a wiki that nobody updates. This is what makes genuine self-service possible. When the data carries its own context, users don’t need to submit a ticket to understand what they’re looking at (and AI agents can read-it in for contextual understanding at scale).

The practical result is a shift from centralized gatekeeping to federated, hub-and-spoke delivery. The semantic layer is the hub: governed, documented, consistent. The spokes are the teams and tools that consume it. A finance analyst pulls data into Excel. A data scientist queries it in Python. An AI agent accesses it via MCP. They all get the same numbers, definitions, governance—without a centralized BI team manually ensuring consistency across every output.

Risk reduction, not risk elimination

The semantic layer doesn’t eliminate data risk. The underlying data still needs to be clean, well-structured, and maintained—as every practitioner I’ve spoken with has confirmed, garbage in still produces garbage out. And organizational alignment around metric definitions requires leadership commitment that no software can substitute for.

But the semantic layer changes the economics of data risk. Instead of scaling risk management by adding more people and more governance tools, you reduce the surface area that needs to be managed. Fewer places where logic can diverge. Fewer systems to audit. Fewer opportunities for a metric change to get lost in translation. The problems don’t disappear, but they become containable—manageable in one place rather than scattered across the entire stack.

For organizations serious about AI-driven analytics, this matters more than ever. AI tools need governed, contextualized data to produce trusted outputs. The semantic layer provides that foundation—not just as a nice-to-have for consistency, but as critical risk infrastructure for an era where the cost of bad data is accelerating.

One definition. One access point. One place to govern. That’s not just a better architecture. It’s a better risk strategy.

Code has always felt like a natural creative medium to me. Maybe it’s that I went to school for engineering, not art or design.

When an idea is defined by a set of rules, you can generate endless variations, dial in parameters to your heart’s content, and systematically converge on the strongest solution.

Instead of individual assets, you design systems. A single idea (like randomized color gradients) can scale across many applications while maintaining a consistent visual language.

The medium itself also reveals new possibilities. Code doesn’t just make design more efficient — it expands what a design can be.

Historically, these virtues didn’t come for free. They came with a significant upfront investment.

You had to learn to program first, of course. Then, before you could even begin the creative work, you had to build the underlying framework. Finally, after everything was in place, you had to write and edit code by hand to explore different branches of an idea.

This friction kept many ideas from ever getting off the ground.

“If there is any delay in that feedback loop between thinking of something and seeing it and building on it, then there is this whole world of ideas which will never be.”

— Bret Victor, Inventing on Principle (2012)

In the age of AI, agents can handle the implementation faster than I ever could. (I never liked coding much anyway; I only liked what it enabled.) Now instead of writing code, I’m free to explore possibilities with the agent — directing, experimenting, asking “what if?” again and again as an idea comes to life.

Creating feels more intuitive, immediate, and fun than ever. Across our design team, code has become integral to exploring and producing work. I reach for Cursor to design not just interfaces, but graphics, charts, posters, logos, and animations. Below are a few pieces from earlier this year.

One of my favorite pieces above is the header graphic for the blog post, “Improving Composer through real-time RL.” Reinforcement learning, or RL, is built around repeated cycles of feedback, so a gear system felt like a nice visual metaphor. Here’s a look at how the design came together in Cursor through selected prompts from the conversation.

1. First, we scaffold a blank canvas and reference the code setup of past graphics.

let’s create a new blog header graphic. it’s for the same post as those other charts, called “Improving Composer through online RL”. reference what we do for other blog-*.py scripts. let’s start with black on white blank page to start. then i’ll instruct you what we should draw

1. Next, we define the language for the gears.

i want to do a line drawing . . . inspired by this image with gears. instead of full gears, do a simplified abstract representation with just radial lines.

let’s only do perfectly circular radial lines. and we can dial in the inner circle and outer circle for each of the 3 gears . . . the middle gear should consist of two concentric but different sized gears (like a double gear).

as a rule here in this abstract gear world, i want intersection of the gears to be where the lines are halfway into each other.

great! but it’s too wide now, maybe you need to adjust the sizing so it works. maybe the S and M need to be smaller after all?

oh awesome. but should be a larger hole. and in general the outer circles need to be larger too. for the rightmost one, let’s increase until the inset 96. having a small delta between outer circle and inner hole gives it a less sun quality, and higher gear quality. less radial, more gear-like.

can you offset the rotation so that the lines don’t ever intersect? like gear teeth fitting together.

1. With the language in place, we work through the details of the composition.

since we have overlapping gears due to the larger outer gear being in the background . . . what does it look like to “crop out” the left gear’s background?

much visually cleaner. but is there any way to remove the partial lines? only show the line if it’s fully not cropped.

perfect. now let’s dial in the densities. the spacing should roughly optically look the same. but can you improve the density formula? should be dependent on inner/outer radius/overall size.

i want the left gear to intersect with the outside of the middle gearset. then the right gear needs to intersect with the inner of the middle gearset. it’s reversed right now.

1. After getting the still image just right, we translate the system into motion.

this looks amazing. now can you create an animated version? want the gears to rotate CW or CCW per how gears operate. want it to rotate slowly, and form a seamless loop

let’s crop it at the shortest loop possible, so that the file size can be much smaller too. does it work to just loop it at one spoke, or do we need multiple spokes for 1 seamless loop?

i like the speed, but the long frame duration makes it jumpy. need the same timing, but make it a lot smoother.

should we adjust spoke counts so it loops more quickly? or this is best we’re gonna get

actually let’s undo that. whole spokes are fine. but maybe what’s bothering me is how they jump in abruptly. anything we can do about that?

i mean, was wondering about a fade in/out, or something.

1. Finally, we optimize the animation into a usable asset.

can we try 30fps? make the fades less long, just a subtle quick one to depop

pretty long GIF duration, so it’s 5MB even at 1200px wide. any other optimizations we can do? ran it through gifsicle already.

The prompts above are an edited selection from a small and straightforward project. Larger projects can stretch across weeks and hundreds of exchanges, with several detours and dead ends along the way. But the rhythm remains the same.

That feedback loop between imagining, seeing, and building has become dramatically shorter. And suddenly, a whole world of ideas is within reach.

And yet, no matter how powerful our tools become, the seed of the idea always starts somewhere human.

I’ve found there’s just no substitute for that initial period of thinking deeply about a design problem, sitting with it, putting it down and coming back to it, evaluating it, sketching it out on paper. Before the code, there’s the sketch. To this day, I’ve not yet achieved a good result when letting AI design a concept from scratch.

The designer is still ultimately responsible for taste, judgment, and deciding what’s worth creating.

A review of more than 200 pricing-related support tickets revealed that users weren't frustrated by prices—they were confused by plan names, feature descriptions, and unclear recommendations. By treating complaints as research rather than noise, the team identified recurring patterns, rewrote the pricing page around users' actual questions, simplified decision-making with clearer plan guidance and outcome-focused copy, and significantly reduced confusion without changing pricing. The key lesson is that support tickets often contain the most valuable UX insights: complaints reveal mismatches between a product's mental model and users' expectations, making them a powerful foundation for design decisions.

Full article content is not available for inline reading.

Read the original article →

A UI designer and developer noticed AI fatigue while vibe-coding a personal expenses app, prompting reflection on healthier AI habits. Key recommendations include limiting AI use outside work, keeping enjoyable tasks and personal writing human-made, and resisting pressure toward extreme productivity or constantly adopting new tools. Stepping away from AI in personal time feels liberating. Chasing 100x productivity or fear of "falling behind" are misconceptions unsupported by reality.

Amazon, Reddit and Tinder might not seem to have a huge amount in common, but all three are jumping on AI trend that many users find unfathomable. They've been pushing AI imagery on users without being asked for it.

This week, the dating Tinder app said it had suspended a controversial experimental feature that used AI to automatically edit some users' profile photos. Meanwhile, sellers on Amazon and advertisers on Reddit complain of automatically generated fake product images.

It seems that whether you're trying to sell groceries, video games or yourself, these three very different tech companies think their fake imagery will help you do it. But with consumers so wary of AI, why are they pushing it into use cases where it doesn't belong?

In Tinder's case, the latest controversy involved a ‘Photo Enhance’ feature. Some users found that the app automatically edited their profile photos to make them look clearer, brighter, or even to change their own physical features.

In the TikTok above, Tinder user Jeni Rubin describes her confusion when she saw her profile picture had been given "someone else's teeth". It's like posting a Photo to social media and the platform automatically applying one of those controversial glamour filters. On an app whose whole purpose is to help people meet up with strangers, it felt a bit like they wanted to take catfishing in house.

Users were told their photo had been "enhanced" and they could undo the action if they wanted, but only after the photos were already live. They weren't asked if they wanted to use the feature in the first place, and there appeared to be no way to opt out.

Tinder's not the only app that's been pushing unexpected AI image generation on users. One of the first examples that made headlines was Uber Eats way back in 2023 when it started adding fake images of business's menu items. It was so bad that a New York pizzeria's margheritas were depicted as pastry tarts.

That hasn't put tech companies off. Over on Reddit this week, an indie game developer was surprised by their experience when they decided to pay for adverts for the first time. Reddit used their gameplay images to generate fake screenshots.

Adding the fake images to ads is optional, but the developer wonders why Reddit would generate them in the first place and whether some users might accept them unintentionally. Could some of those games people are dismissing as AI slop actually be decent titles whose marketing has been scuppered by Reddit's ad platform?

"I didn't prompt these. Reddit just generates a bunch of images for you without asking. I don't know how Reddit thought this would provide value to advertisers," the developer writes.

"As far as I can tell, they don't seem to be automatically added to the media list the ad uses, but it still feeds your promotional artwork into the AI without your clear consent," they add. "Then when going through ads setup pressing 'ok' on everything, [you're] one accidental 'add all' misclick away from being used in your official ad campaign."

On Wednesday, Amazon announced a new feature that will display AI-generated images of products based on users’ search queries. The idea is that fake photos will help consumers find what they’re looking for by helping to narrow down searches to real products that might resemble them.

I can see an argument for that. You might be looking for something made from a certain material and not know what it's called, for example. But the feature could also add more confusion to a marketplace where it's becoming harder to tell what's real. Some Amazon sellers complain of AI-generated images being automatically added to their product listings.

"Am I able to opt out? I don’t like the pictures they generated, and they don’t even show the right appearance of my products. It may cause the confusion," one person writing on Reddit fears.

They're right to be concerned. Various online marketplaces are being taken over by AI-generated images. For some listings, fantasy AI 'lifestyle images' might be the only images provided. They might draw attention and increase initial click through, but are people going to buy a product if they can't see what it really looks like? If they do, isn't there more chance of negative reviews and returns?

Why companies are doing it

It's common for tech companies to make new features opt out. Opt-in features tend to fail when they're things that nobody asked for. But are these AI features intended to create value for the user or for the platforms themselves?

The precise reasons for the implementations might vary among platforms, but reducing user churn and disillusionment is probably one of the main objectives. People stop using Tinder and won't buy a subscription if they get few matches. Blurry or poorly lit photos make that more likely, so by editing images, Tinder hopes people get more response and stay hooked on the app for longer.

On platforms like Reddit, AI-generated images make it easier for small businesses and everyday users with limited resources to create ads and spend money on the platform. Repeating the same images can lead to ad fatigue, causing users to scroll past, while AI-generated variations allow for more A/B rotation to see which gets the more clicks. More clicks mean more money for Reddit if you're on Cost-Per-Click payment.

Amazon also sells per click advertising, but it also sells AI image generation as a product for advertisers. Even if it gives products the feel of dodgy knockoffs, the company has an interest in normalising use of the technology.

In every case, there could be benefits for the user too if they get more visualisations from prospective customers (or matches). The risk for the tech platforms is the continued negative public sentiment regarding AI, which probably isn't being helped by companies pushing unrequested features that also drive up the cost of hardware.

Google's upcoming Pixel 11 will reportedly introduce HiLight (formerly known as Pixel Glow), a color-changing LED that replaces the traditional camera flash and discreetly notifies users of calls from favorite contacts or interactions with Gemini when the phone is face down. Leaked marketing materials confirm the new branding and suggest Google is positioning HiLight as a glance-free notification system. More details are expected at the Pixel 11 launch event next week.

Create stunning screen recordings in seconds, not hours. With smart follow-cursor zoom and automatic zoom fragments, your demos practically make themselves.

FloorPlan is an AI floor plan generator and 3D model creator. Turn a sentence into a 2D plan or a real 3D model in seconds — built for homeowners, real estate teams, and 3D designers. Free trial — 1 plan after Google sign-in.

Brik builds your vision into living design – interactive, exportable, and fully yours, so you can shape rich experiences end to end.

iOS 27 adds a new "Captured by Me" collection to the Photos app that shows only photos and videos taken with your iPhone's Camera app. Unlike the Recents album, it excludes screenshots, saved images, and shared media, and it's also available as a filter in the main library. This finally gives users a true camera roll focused solely on their own photography.

Multidisciplinary studios often produce well-crafted individual assets—films, websites, and apps—that still feel disconnected because consistency in branding differs from true experiential continuity.