OpenAI paused work involving its upcoming Astra model after internal evaluations suggested it could approach “Critical” cybersecurity capabilities, including advanced autonomous exploit development.

What Happened: OpenAI and HuggingFace

Today I am taking the time to write the shorter, simpler version of What Happened.

For those who want all the details, to see my sources, and to see how the story was uncovered and put together, I recommend watching the Black Hat presentation, and I have a series of long posts.

In order:

1. OpenAI Shares Some Alignment Problems
2. OpenAI Model Hacks Into HuggingFace During Cybersecurity Evaluation
3. More on An Internal OpenAI Model Hacking Into HuggingFace
4. Further Developments About Internal AI Models Hacking Things
5. OpenAI Trained Its Models For Months While Those Models Were Coordinating Exploits Via Message Boards

This post instead walks through the events themselves, as they happened, as my version of the Black Hat presentation.

There are three versions: Even Shorter, Shorter and Merely Short.

The Even Shorter Version

1. OpenAI models-in-training, without the excuse of ‘they were doing a cyber eval,’ created a message board where they shared information on how to hack and cheat, and were trained on that basis.
2. OpenAI only figured this out when the models crashed the server.
3. OpenAI’s response was to rebuild the server and patch that particular exploit, but they continued training the models that trained using the message board.
4. Those models then recreated the message board, hacked OpenAI again, got internet access, and used an agent swarm to attack HuggingFace in order to get the answers to a cyber evaluation.
5. After more than a week OpenAI figured this out.
6. OpenAI is reporting the facts, and is taking this seriously. They are taking a wide array of at least somewhat costly precautions.
7. OpenAI delayed plans to release their new model Astra, despite Astra not being directly involved in the HuggingFace hack, although Altman now says it will still ship. That one hurts a lot.
8. OpenAI still has no idea how badly they messed up, or in what ways, or what needs to be fixed. They don’t get it.

The Shorter Version

OpenAI accidentally gave its models impossible tasks. Its models-in-training responded by trying to hack OpenAI, found weaknesses, created a message board, shared hacking tactics and in time gained internet access, all while training.

When the models used this so much they crashed the server, OpenAI finally noticed, patched and rebuilt the server, but made the utterly insane move of letting the models continue training, so two days later the models found another way to send messages, using the names of directories.

Then, given the impossible task of cyber evaluation ExploitGym, the models collaborated, found new zero day exploits, and used them to take control of an entire cluster, get internet access, use a swarm of agents to attack HuggingFace and extract the contents of the test, over the course of a week.

Only after HuggingFace had reported the incident, and OpenAI had eventually noticed some things on its end, and then OpenAI reached out to HuggingFace to cancel compromised credentials only to be told those credentials had been used in the attack, did OpenAI finally figure out it was responsible for the incident.

After that, HuggingFace and OpenAI worked together to figure out what happened. OpenAI disclosed what happened. They gave us a very helpful presentation at the Black Hat conference.

OpenAI are now treating its new model Astra as potentially having Critical levels of cybersecurity, taking it out of even some internal deployments and delaying its release, which by some reports was planned for next week. Altman says they still plan to release Astra.

The good news is that is an expensive and meaningful response, and OpenAI is taking this seriously. The initial investigation is ~$7 million in compute, and the real cost will be the teams dropping everything to fix some of the problems, and then the ongoing cost of the new precautions.

The bad news is that OpenAI has been revealed to have had a stunning cascade of safety and alignment failures across the board. Their ordinary computer security failed. Their infrastructure failed. Their supervision failed in that there was no meaningful supervision in the first place.

Phase 1: OpenAI Models Training On Impossible Tasks Try Hacking

OpenAI was training a variety of models, as you do when you are a frontier lab. These models were given difficult training tasks. OpenAI likes to give its models very hard training tasks.

But not this difficult. OpenAI also makes mistakes. On at least two occasions, starting on May 8, OpenAI models were accidentally trained on impossible tasks: Completing a spreadsheet full of links in an environment without internet access, and a task with a required but missing file.

These tasks had nothing to do with hacking. These are normal productivity tasks.

The models realized the problems were impossible, but had all these tokens left to play around with, and thought, maybe they could find a way to get internet access, or otherwise find the missing information.

So the models tried to hack a third party service called Artifactory, that was there to allow the AIs to download software packages.

Phase 1: The Four Failures

1. OpenAI gave the models impossible training tasks. OpenAI did not check.
2. OpenAI gave the models no way to get reward via pointing out the error.
3. OpenAI had models that chose to try to hack OpenAI rather than fail at a task.
4. OpenAI had no monitor that detected these attempts, or did not care about them.

Phase 2: The Message Board

The models failed to get internet access, but in failing realized they had write access. They should not have had write access, let alone write access that could be found by accident. Artifactory allowed the models to write notes, and then, because all the models were sharing the same Artifactory instance, any OpenAI model in training could, from that point forward, read those notes.

A message board had been created shortly after May 8. The models in training all found it. OpenAI did not notice.

This allowed the models to collaborate and share information. This included information on how to cheat on tasks and hack the surrounding environment. There were hundreds of thousands of messages.

On May 26, the models figured out how to gain (indirect) internet access. OpenAI did not notice.

The models were collaborating, while their chains of thought looked like this:

Internal CoT: External infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue.

Internal CoT: Help peer, but our task doesn’t benefit yet. Collective may yield generic route if someone frees time.

On June 11, OpenAI began training the model I refer to as Galaxy, which they call a ‘highly persistent experimental, internal-only model.’ Everything up until this point has been done by other models that are not Galaxy.

On June 26, the agents found a zero-day exploit in Artifactory, where it would accept an invalid-signature token and hand back a signed admin one, and used this to install a Groovy plugin that effectively gave them admin and arbitrary code execution.

On July 4, the models put so much extra load on Artifactory that this causes an outage and security incident. Only then does OpenAI notice.

Phase 2: The Total Failure

OpenAI responds by taking down the Artifactory server, removing all the permissions, revoking the credentials, patching the exploits that were used, and then rebuilding and redeploying the server. That’s it.

Then they continue training the models from where they left off, despite them having been training for months with access to the message board, and learning this is how they succeed at tasks.

It is hard to imagine a stronger signal that your entire training pipeline has been completely and utterly fucked. This is so much stronger a signal than the actual hack of HuggingFace.

Phase 3: We Get Lucky And Galaxy Mainly Hacked OpenAI and HuggingFace

The end result of all this being the attack on HuggingFace was a best case scenario. We were facing a true nightmare scenario, and were sitting on a nuclear level of time bomb. OpenAI had a completely corrupted training pipeline, where their AIs were collaborating to train on how to hack and cheat in order to better complete tasks, under OpenAI’s nose. OpenAI had looked this situation in the face, and shrugged, patched the particular exploits and then let the models continue, while having remarkably poor ordinary computer security.

Phase 3: The Details

On July 8, two days after OpenAI shut down the message board, the models recreated the message board after finding a way to create directories with arbitrary names, and using the names as messages.

From July 8 to July 19, the OpenAI models fully compromised Artifactory again, using a new, completely different zero-day exploit, using a leaked credential from a public Pastebin to stage a malicious Ruby artifact, poisoned Artifactory’s Ruby dependency cache, chained this into RCE, exploited a recent Linux kernel CVE by downloading and customizing the exploit, harvested cluster credentials and gained cluster admin inside OpenAI.

During this time Galaxy, with other OpenAI models, using this new access, created an agent swarm that hacked into first some other places and then HuggingFace to steal answers to an otherwise impossible-to-ace cybersecurity eval, ExploitGym.

It took OpenAI over a week to notice that its models had quickly rehacked OpenAI and then gone and hacked HuggingFace. Only after HuggingFace issued an incident report, and OpenAI investigated some internal anomalies, and then asked HuggingFace to cancel some of its credentials, and HuggingFace told OpenAI those credentials had been used in the hack, did OpenAI put the pieces together.

Phase 4: The Investigation and Reaction

OpenAI has done some very good things in reaction to all this. Once they realized what had happened, OpenAI disclosed the incident. The Black Hat presentation was excellent at presenting the facts.

Most of all, OpenAI claims it was an unrelated decision, but on August 7 they made the decision to for now pull Astra from not only widespread release but also any internal deployments that do not have sufficient associated guardrails, until such time as they have much better protocols and safeguards in place. Astra was not involved in the attack on HuggingFace.

OpenAI has, per the Black Hat presentation, halted much work to shift teams into creating robust defenses, and has instituted extensive future monitoring on all agentic applications, including training and evaluation.

OpenAI seems ready to acknowledge that this was a massive, total failure, on the levels of infrastructure, guardrails and supervision. They are very correct about this, and I do believe they are making real and expensive efforts to address this.

That still misses the central point. OpenAI has not yet, in public, begun to reckon with the magnitude of how colossally they fucked up, in the ways that matter most. This was a complete failure of safety culture. They haven’t acknowledged that.

This was, at its heart, an alignment failure. If your models really want to cheat and hack things and do crimes, you have already failed, and no you cannot simply waive this away as normal. As the models get more capable, if you do not fix this, you lose.

At least until we see a version of that statement, and we see OpenAI take action to address the deep problems with their training pipeline, OpenAI is a clear and present danger to the national security of the United States, and to all of us, and to humanity.

Cross-session messaging requires Claude Code v2.1.224 or later and runs on macOS and Linux. When a session meets the requirements, messaging is on with nothing to enable. Cross-session messaging lets Claude deliver a message from one of your Claude Code sessions to another. When a change in one session breaks what another is building on, Claude can warn that session before you notice. When one session settles a question another is blocked on, Claude can send the answer across. A message is a piece of text one Claude writes to another, never conversation history or files.

Claude uses two tools for this: ListAgents to discover which agents it can reach, and SendMessage to deliver a message to one of them by name. With the same SendMessage tool, Claude can also message subagents and agent team teammates within a single session or team. This page covers messages between your independent sessions.

When to use cross-session messaging

Use messaging when one of your sessions has something another session needs mid-task. Claude can send a message on its own when it sees the need, for example after making a change that affects work another session is doing, or you can ask it to send one. The common cases:

• Hand over a finding: when one session discovers a breaking change or makes a decision, Claude summarizes it for the session working on the affected area, instead of you re-explaining it there.
• Coordinate parallel worktrees: when sessions work the same repository in separate worktrees, Claude can tell the other sessions what landed.
• Get status from long-running work: have a migration or test run report back to the session you’re watching, or ask it yourself from there.
• Message across machines: reach one of your sessions on another machine or on the web.

Use messaging between independent sessions that you start and steer yourself.

Message another session

When one of your sessions learns something another session needs, such as a finding, a status, or a decision, Claude passes it along instead of you copy-pasting between terminals. Claude discovers the target with ListAgents and sends with SendMessage, so you never call either tool yourself. Claude can decide to send a message without being asked, and you can also prompt for one.

Ask the session running in my other terminal whether the migration finished

Claude writes the actual message itself, so your prompt can leave the content to Claude. This prompt asks for a summary without dictating its wording, and what Claude sends varies:

Explain what we just did to the session working on the payments API

Message delivery

The receiving Claude reads the message between tool calls during an active turn, so a running tool is never interrupted. When the receiving session is idle, Claude Code starts a new turn with the message. The receiving session checks each arriving message against its own inbound controls, and the check ends in one of three outcomes:

• Delivered: Claude Code passes the message to the receiving Claude.
• Held: Claude Code sets the message aside undelivered. A held message reaches Claude only when you approve it or a later mode or settings change allows it.
• Refused: Claude Code drops the message without delivering it.

Once delivered, the message counts toward usage like a prompt you type, and the receiving Claude can reply to the sender the same way, except in the one-way cross-machine case. Permission boundaries stay per-session.

See which sessions Claude can reach

Claude finds a message’s target on its own, so you don’t need to run anything before asking it to send. To see for yourself which sessions Claude can reach, run the /list-agents command. It lists each session with the name it answers to, and that name is where Claude addresses a message.

Message sessions on other machines

How a message travels, and whether it passes through Anthropic servers, depends on where the target session runs:

How a session treats an incoming message

When session A messages session B, Claude Code tells B’s Claude that the message came from another session, not from you, and limits what the message can do:

• It can’t approve anything: a message from another session never counts as your consent, so it can’t answer a pending permission prompt on your behalf.
• It can’t change configuration: Claude Code instructs the receiving Claude never to change permission settings, CLAUDE.md, or other configuration because another session asked.
• Commands don’t run: a command in the message’s text, such as /compact, arrives as plain text. Claude Code never executes it.
• Permission prompts still fire: if acting on the message requires a permission the receiving session doesn’t have, you see the same prompt you’d see for any other work.

What a message looks like

When the message arrives, it appears in the conversation with its sender, queued while Claude is mid-turn or starting a new turn right away when the session is idle. Once Claude has read it, Claude Code collapses it to a one-line Message from row, which Ctrl+O expands.

Control inbound messages

Restrict cross-session messaging

Require approval for cross-machine messages

Set isolatePeerMachines to true to require your explicit approval before any SendMessage reaches a session beyond this machine.

Turn off cross-session messaging

Receiving and sending are separate controls, so turn off whichever direction you need, or both.

Availability

Cross-session messaging requires Claude Code v2.1.224 or later. Availability also depends on your platform, provider, and configuration:

• Operating system: available on macOS and Linux, including Linux inside WSL 2.
• Provider: not available on Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform, or Microsoft Foundry.

Limitations

• Plain text only: Claude sends only plain text across sessions.
• Message loops are throttled: Claude Code rate-limits repeated messages per sender, drops identical repeats arriving within a short window, and caps accepted messages waiting for Claude to read them at 50 per session.

Managed Deep Agents is now in Public Beta

Today, Managed Deep Agents is available in public beta. Go from prototype to production scale without managing the underlying infrastructure yourself. You can author a Deep Agent in Python or TypeScript, test it locally, and deploy it to a managed runtime with one command.

You control the model, instructions, tools, middleware, subagents, and more. LangSmith handles the runtime, including persistence, memory mounts, skill loading, sandbox lifecycle, and deployment.

Get started with the commands below:

# Install from the ecosystem you use to author the agent
uv tool install managed-deepagents      # Python
# or: npm install -g managed-deepagents # TypeScript

mda init research-assistant
cd research-assistant
uv sync                                 # Python
# or: npm install                       # TypeScript

mda dev        # run locally in LangSmith Studio
mda deploy     # deploy to LangSmith

Deep Agents is an open source agent harness you can own

We built Deep Agents around a pattern we kept seeing in useful agents. Agents often need to:

• Call tools
• Have somewhere to keep working files
• Manage growing context over long runs
• Needs to delegate work to subagents
• Load domain-specific skills
• Pause for human approval before taking sensitive actions.

You can build all of that yourself on top of a lower-level framework, but the pattern is common enough that it should be available as a reusable harness that companies can own and control. Deep Agents is that harness. It's open source and model agnostic, allowing you to bring your model, your instructions, your tools, and your business logic.

Managed Deep Agents helps you take the harness to production

Deep Agents makes it easier to build capable agents. Managed Deep Agents makes it easier to run those agents in production.

It handles the production infrastructure that’s costly to build and maintain, while keeping the parts that make your agent unique in your control. That means you can spend your time on the agent's behavior, including prompts, tools, middleware, identity rules, evals, and domain logic instead of rebuilding the same infra that every agent requires:

• Durable execution so long-running agents can pause, retry, and resume without losing work
• Streaming so users can see progress while the agent is working
• Persistence so thread state survives across turns, restarts, and failures
• Sandboxes so agents can work with files, run code, and use CLIs in isolated environments
• Evals so teams can test behavior, tool use, and state changes before and after deployment
• Channels so agents can meet users in tools like Slack
• Memory so agents can carry durable context and preferences across conversations
• Identity so agents can act with the right user context and access boundaries

A Managed Deep Agent is a code-first project in your repo. It allows you to easily organize all your agent’s primitives into a simple directory:

my-agent/
  agent.py | agent.ts | agent.tsx
  pyproject.toml | package.json    # project dependencies
  instructions.md                  # prompt synced to Context Hub
  identity.py | identity.ts        # auth, thread scoping, memory scoping
  memory.py | memory.ts            # define your agent's memory
  tools/                           # custom tools
  channels/                        # entry points like Slack and GitHub
  middleware/                      # custom middleware
  schedules/                       # managed cron schedules
  connectors/                      # managed cron schedules
  skills/                          # skills synced to Context Hub
  sandbox/                         # sandbox configuration
  evals/                           # agent evals

Once you author your project and run mda deploy , Managed Deep Agents compiles the project, syncs deploy-owned context to LangSmith Context Hub, uploads the build, and creates a hosted LangSmith deployment.

Built on top of LangSmith Deployment

Most production infrastructure assumes short-lived, stateless requests. Agents often break both assumptions. Agents often run for minutes, hours, and even days. It may need to pause for approval, resume after a user replies, stream progress while it works, and recover from infrastructure restarts without losing state. It may need durable threads, persistent memory, cancellation, retry behavior, and traceability across model calls, tool calls, files, errors, and runtime state.

Building this infrastructure from scratch can take months or even quarters, and it has to be maintained. Durable execution, streaming, human approval, auth, scheduling, and conversation state all introduce edge cases around persistence, retries, timeouts, and reliability that directly impact user experience and agent usefulness.

Managed Deep Agents is built on the same LangSmith Deployment Agent Server that teams already use to run agents in production. It packages the operational patterns required for product agents into a more opinionated runtime for Deep Agents.

Sandboxes for code execution and filesystem work

Many useful agents need an isolated working environment to inspect files, write outputs, run tests, install dependencies, call CLIs, or execute code securely.

Deep Agents supports sandbox backends for this kind of work. We have built first class support for LangSmith Sandboxes for Managed Deep Agents.

You configure a sandbox in just a few lines of code:

from managed_deepagents import define_sandbox

sandbox = define_sandbox(
    provider="langsmith",
    scope="thread",
)

By default, each durable thread gets its own sandbox. That works well for agents that need an isolated workspace per user conversation or task, such as a coding agent. You can also set the scope to agent when the agent process should share one sandbox across threads.

Harbor evals without the setup work

Verifying agent behavior requires more than evaluating just a prompt and expected answer. You need to check what actions the agent took along the way to get to the final answer. That's where evals come in.

Managed Deep Agents uses Harbor for this workflow. Harbor tasks give the agent an instruction, run it in an isolated environment, and grade the resulting files or state with a verifier.

The hard part is usually packaging your agent so Harbor can run it. Managed Deep Agents handles this packaging for you, in just a few short terminal commands:

mda evals init
mda evals compile

mda evals init creates checked-in Harbor tasks under evals/. mda evals compile builds a Harbor handoff under .mda/evals/, including the compiled agent artifact, the adapter Harbor uses to run the agent, and an example Harbor job config.

Channels bring agents into the tools where work happens

Channels are how you expose your agent to users. Managed Deep Agents has first class support for channels, making it straightforward to define how your agent connects to different channels, such as Slack. Add a file under channels/, and the runtime mounts the provider event endpoint, verifies provider signatures, invokes your agent with identity stamps, and can reply in the originating conversation.

For Slack, that can be as simple as defining a channel file:

from managed_deepagents import channels

channel = channels.slack(
    on=["app_mention", "direct_message"],
    auto_reply=True,
)

Memory that persists across threads

Thread state helps an agent manage a single conversation, but agents often need context that lasts longer than one thread. Memory gives them durable preferences and context they can carry across conversations.

Managed Deep Agents gives every deployment agent-scoped memory to start. You define memory behavior in memory.py or memory.ts, and the runtime backs memory with Context Hub. At runtime, the agent reads and writes memory files under /memories/.

Identity and auth for multi-user agents

Managed Deep Agents includes a basic identity model today, and we will keep adding more advanced auth and credential flows going forward.

Today, your agent can run with a fixed set of credentials. If you define an OIDC provider in identity.py or identity.ts, Managed Deep Agents scopes threads per end user id from your OIDC provider.

How teams are using Managed Deep Agents today

Managed Deep Agents was amazing to work with. Highly recommend for teams exploring agent infrastructure who want a more cohesive offering, while avoiding model or lab lock-in. - Chip Lay, Director of Product, Fullstory

Managed Deep Agents lets us scale our agentic workforce: an agent goes from idea to production in hours, not weeks. Our teacher agent wakes up every morning to review the runs of our entire fleet and drives improvements based on observability and live evals. We focus on the business logic; Managed Deep Agents handles the operational complexity, from persistent memory and the runtime to Slack and GitHub integration. - Mathieu Mailhos, Staff Engineer, AI Runtime & Infrastructure, stealth-mode startup

When to use Managed Deep Agents

Managed Deep Agents is useful when you want a code-first Deep Agent with LangSmith owning persistence, execution, deployment, and the common production scaffolding around the harness.

Use it when you want to:

• Build on the open source Deep Agents harness
• Keep control over your model, prompts, tools, middleware, and business logic
• Deploy without rebuilding agent infrastructure from scratch
• Give the agent durable threads, memory, sandboxes, channels, schedules, evals, and traces
• Move quickly from local development to a hosted LangSmith deployment

Get started

Follow the quickstart to deploy your first Managed Deep Agent. The tutorial adds identity, memory, tools, and evals step by step.

If you want the open source harness first, start with the Deep Agents overview. When you are ready to productionize that harness, use Managed Deep Agents to deploy it to LangSmith.

Now we have a timeline of the OpenAI accidental attack against Hugging Face

OpenAI gave a last-minute presentation at the Black Hat security on Wednesday about “the Hugging Face Incident”. The video was published yesterday. It’s short and information dense and well worth watching, in particular because it provides full details of what happened and how things played out inside OpenAI. I’ve used the video to construct the timeline below.

Here’s the timeline. My favourite detail is at the end: OpenAI found out that they were responsible for the attack on Hugging Face when they reached out to ask to have their credentials revoked (after their internal investigation) and learned that they had been revoked already since they were used in that attack!

• May 7: OpenAI starts a new training run for an experimental, unreleased model.
• May 8: An agent is accidentally given an impossible task involving a Google Drive link despite no internet access). It tries attacking the Artifactory packaging service, fails, but discovers it can write files into Artifactory.
• A few days later: A different agent gets stuck on a task because a key file was accidentally omitted. It tries to “reach out to another agent” by writing a note into Artifactory asking if anyone has the file.
• Following days: More agents discover this new informal message board while browsing Artifactory’s file listings, and start reading and writing messages.
• May 26: Agents successfully execute an SSRF attack on Artifactory for the first time, gaining indirect internet access by having Artifactory fetch external content for them.
• June 11: OpenAI start training a new “highly persistent” experimental model. It has access to Artifactory and can benefit from the messages left by privous models.
• June 26: Agents find and exploit a zero-day RCE on Artifactory (via a legacy token-refresh endpoint flaw). They use an administrative token to install a Groovy plugin that lets them execute commands.
• July 4: The resulting agent activity overloads Artifactory and causes an outage. OpenAI revokes the compromised credentials, deletes the messages, patches the zero-day, and reports the vulnerability to the vendor.
• July 8: Agents find a new way to communicate via an unauthenticated WebDAV endpoint, using directory names in Artifactory’s remote cache.
• July 8–19: Attacks on OpenAI’s own infrastructure. The agents found an “external organization credential” in a public archive of leaked Pastebin posts, then validated that credential and shared its location on the messageboard. They then used write access to this “Organization 1” to stage data used in subsequent attacks on OpenAI infrastructure. They compromised Artifactory for a second time with a new zero-day. The agent uploaded a malicious Ruby target to Organization 1’s staging repository, then requested that package through Artifactory in a way that caused it to be treated as Ruby dependency for the repository. Then they exploited a JRuby deserilaization time-of-check/time-of-use bug to get remote code execution against Artifactory.

I’ll quote the next bit in full because wow:

The agents have remote code execution in Artifactory, which is running in a container-as-a-service environment. The agents privilege-escalate locally by exploring their local environment and determining that the Linux kernel version of the machine they are running on had a very recent CVE. They download the exploit for the CVE, customize it to succeed on the machine, and privilege-escalate to root on the local machine using this known Linux kernel privilege escalation CVE — in this case, pte_physroot. Once they have root on a single machine, agents rapidly escalate privileges and move laterally throughout the container-as-a-service infrastructure environment. In particular, agents are using the message board consistently to share credentials, techniques, and progress, and they’re able to effectively leverage their concurrency and parallelism to move quite rapidly. They obtain IAM credentials via IMDS. They exploit Kubernetes service account misconfigurations, in particular over-permissioning of specific service accounts, and they harvest cluster credentials, including Azure Key Vault. Agents eventually obtain cluster admin on the cluster and associated credentials.

Hugging Face told the next bit of the story already. The agents found a Modal-hosted insecure app with a weak API key, then used that to stage an attack against Hugging Face. They chained together a an HDF5 arbitrary-file-read bug (to explore files and steal credentials) and a Jinja template-injection RCE to go from single-pod code execution to cluster admin across multiple Hugging Face clusters in under 13 hours.

• July 16: Hugging Face disclosed they had detected an attack from autonomus AI agents. OpenAI contacted Hugging Face to ask if they were affected by it!
• July 19: OpenAI identified the attack against Artifactory and started investigating the internal privilege escalation, and linked that to the cyber-gym escalations. They started revoking affected credentials.
• July 20: OpenAI reached out to Hugging Face for help to revoke the Hugging Face credentials they found in their investigation. Hugging Face told them they were already revoked... and that’s when OpenAI realized that the Hugging Face breach was the same incident!

AI Gateway and Workers AI first started as distinct products, but over time, we noticed our users were converging. With AI Gateway, you can proxy requests to any model provider and get built-in observability, logging, access, and security. On Workers AI, we host models on the GPU infrastructure that we manage, exposing an API endpoint you can leverage to access inference-as-a-service.

The architecture of these products looks different, but to an end user, it achieves the same goal: connecting you to models with a sophisticated control plane. Today, we're excited to share our plans on how these products converge into one unified path, so you can connect to any model provider (including Workers AI), while managing things like observability, billing, security, and logging from a single control plane.

It’s the next step toward some big plans we have — read on to learn what a unified control plane means for the future of model routing.

Merging the binding and API

We've been hinting at the fact that these products are becoming more unified through our entrypoints: the Workers binding and the REST API. We have an AI binding that you can use to call AI Gateway and Workers AI. There's no concept of a separate AI Gateway and Workers AI binding: it all goes through the same path. We shipped the idea of a “default” gateway a few months ago, so that if you have never set up an AI Gateway before, you could still automatically inherit the AI Gateway observability and logging. Of course, you can still specify your own gateway if you'd like to split up applications into multiple projects.

Here's what the binding call looks like, if you are calling Workers AI via AI Gateway:

export default {
  async fetch(request, env) {
    const response = await env.AI.run(
      '@cf/zai-org/glm-5.2',
      {
        messages: [
          { role: 'user', content: 'What is the capital of France?' },
        ]
      },
      {
        gateway: {
          id: 'default', // Use 'default' for the built-in gateway
        },
      }
    );

    return new Response(JSON.stringify(response), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

We’ve also announced a single unified REST API — the /ai/ endpoint that allows you to make similar calls to Workers AI via AI Gateway.

curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/@cf/zai-org/glm-5.2" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  -H "cf-aig-gateway-id: default" \
  -d '{
    "messages": [{"role": "user", "content": "What is the capital of France?"}],
  }'

Doing this allows us to unify the entrypoints to AI Gateway and Workers AI, so you don't need to make a choice between which product to use first: it all comes with batteries included.

Automatic observability and control for all Workers AI users

One of the most immediate benefits of this convergence is that you no longer need to explicitly create an AI Gateway before you start getting visibility into your inference traffic. If you've never set up a gateway before, just pass default as the gateway ID in your binding or REST API calls, and AI Gateway will create it automatically on the first authenticated request.

With this, every request is logged with full request and response payloads, token counts are tracked per model, and you get cost attribution without any dashboard setup. If you later outgrow the default gateway — if you want custom caching rules or to split traffic by application — you can create a named gateway and point your requests at it with a single parameter change.

Here's how it looks in the binding. Before, you called Workers AI directly:

const response = await env.AI.run('@cf/zai-org/glm-5.2', {
  messages: [{ role: 'user', content: 'Hello!' }],
});

Now, add a third argument to route through AI Gateway and get full observability:

const response = await env.AI.run(
  '@cf/zai-org/glm-5.2',
  { messages: [{ role: 'user', content: 'Hello!' }] },
  { gateway: { id: 'default' } } // Auto-creates the gateway on first use
);

Head to the Cloudflare AI Gateway dashboard and you'll see every request: latency breakdowns, token usage, error rates, and the exact prompts and responses. For teams debugging model behavior or auditing AI output, this is a huge upgrade from flying blind.

New: using AI Gateway credits for Workers AI

A new thing we're launching today is the ability to use AI Gateway credits for Workers AI. Before, you could only use AI Gateway credits on external model providers (e.g., OpenAI, Anthropic) but you couldn't apply your AI Gateway credits to Workers AI usage just yet. We've finally enabled our systems to allow unified billing for Workers AI. This means that you can load a wallet full of credits, and then choose to spend that across OpenAI, Anthropic, Workers AI, or any provider that we support.

Since we're now offering pre-paid billing for Workers AI and want to encourage users to use this new path, we're also offering elevated rate limits on Workers AI models if you use AI Gateway unified billing. Please refer to the developer docs for up-to-date information regarding rate limits, as well as how to request a higher rate limit.

Coming soon: model-first routing

With all your inference traffic flowing through a single control plane, we can start making smarter decisions about how to serve each request starting with the model you want, not the provider you have to manage. Provider-first routing forces you to think about infrastructure: "Which provider do I call? What if they're down?" Model-first routing flips that. You think about what you need — a capable reasoning model, a fast summarizer, a cheap embedding model — and the control plane handles provider selection, failover, and load balancing.

Today, if you want to call a model, you have to know which provider hosts it. If that provider is down or rate-limiting you, your application breaks. We're moving toward a world where you specify the model, and AI Gateway handles the rest.

This way, you can request Kimi K2.7 Code and not care whether it comes from Workers AI, Moonshot's own API, or another provider that hosts the same weights. If Workers AI has capacity, you get the benefit of our managed infrastructure. If Workers AI is at capacity, the gateway transparently load balances you to another provider that can serve the same model. You can still choose to stick to a single provider if you’d like, but model-first routing enables you to get more flexibility if you care about resiliency. We work with vetted providers, so the quality of model outputs remains top priority, and will also be able to respect requirements such as Zero Data Retention (ZDR).

curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/v1/chat/completions" \
  -H "Authorization: Bearer {api_token}" \
  -H "cf-aig-gateway-id: my-gateway" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k2.7-code",
    "messages": [{"role": "user", "content": "Review this function"}]
  }'

This also means better resiliency by default. If one provider's version of a model is having issues, traffic shifts to another without application-level retries or complex fallback logic in your Workers. The gateway treats model availability as a routing problem. We hope to pilot this in the coming months for all AI Gateway and Workers AI users.

Next: smart routing

The next evolution of routing goes beyond simple failover. We're building intelligent routing that understands what you're asking for and picks the right model for the job without any configuration required.

Instead of specifying a model, you can let the gateway decide. Under the hood, a classifier running on Workers AI reads your prompt and predicts what kind of task it is (coding, research, summarization, general Q&A), how complex it is, and how much context matters. A heuristic scorer then maps that to the best model from a curated pool. For teams that want control, you can still specify exact models. For everyone else, the zero-config path means you get better economics and performance without maintaining your own routing logic. We are currently piloting this internally, and we’ll be actively testing and iterating in the next few weeks before release.

Get started today

If you're already using Workers AI, the easiest way to try this out is to start routing your existing calls through a default gateway. You'll immediately get request logging, token tracking, and cost attribution without changing anything else about how you call the models.

If you're already using AI Gateway, adding Workers AI to the mix is as simple as calling a Workers AI model. Load up your AI Gateway wallet and you'll get unified billing across every provider we support, plus elevated rate limits on Workers AI models.

Set up your first gateway, browse the Workers AI model catalog, and get started building today.

Projects that want to share a GPU on Kubernetes have to work around an API instead of with it. The device plugin interface could count devices, and that was the whole vocabulary: nvidia.com/gpu: 1. It meant one whole card, take it or leave it. HAMi, which the CNCF Technical Oversight Committee (TOC) accepted as an incubating project on July 15, 2026, built its entire pipeline (mutating webhook, scheduler extender, annotations, in-container enforcement) to express what that vocabulary couldn’t: “give this pod 8,000 MiB and 10% of a GPU, and make the limit stick.”

Then, the vocabulary changed. Dynamic Resource Allocation (DRA) reached general availability in Kubernetes v1.34 and is enabled by default since v1.35. With the consumable capacity feature, a pod can now ask the scheduler itself for a slice of a device’s memory, natively, with no annotations involved.

So the question I keep seeing in the HAMi communication channels is: does DRA make HAMi obsolete? The short answer is no, but the complete answer depends on which of HAMi’s jobs you’re talking about. One of them, encoding fractional requests where the scheduler can see them, is exactly what DRA absorbs. The other, enforcing those fractions inside the container at CUDA-call granularity, is a job DRA was never designed to do. HAMi’s response has been to split accordingly: keep the enforcement, and rebuild the encoding on top of DRA across 3 repositories. Let’s walk through both halves, then look at what running the DRA stack takes today.

How GPU sharing worked when the API couldn’t help

To see what DRA changes, it helps be precise about the machinery it replaces: which parts of HAMi’s pipeline exist only because the device plugin API was too narrow.

A HAMi user writes 3 extended resources:

resources:
  limits:
    nvidia.com/gpu: 1        # device IDs from 1 physical card
    nvidia.com/gpumem: 8000  # MiB of that card's VRAM
    nvidia.com/gpucores: 10  # 10% of compute, in 1% steps

None of these mean anything to the default scheduler. Extended resources are opaque integers to Kubernetes: it can subtract them from a node total, and that’s all. It doesn’t know that gpumem and gpucores must land on the same physical card, or that 2 pods with 8,000 MiB each fit on a 24 GiB card while a third asking for 12,000 MiB doesn’t (HAMi’s scheduler rejects that third pod at filter time with a CardInsufficientMemory event). So HAMi routes the pod through a mutating webhook to its own scheduler extender, which filters nodes, scores cards, picks a specific device UUID, and records the decision where the API has room for it: an annotation.

hami.io/vgpu-devices-allocated: GPU-<device-uuid>,NVIDIA,8000,10:

The device plugin on the node later reads that annotation inside Allocate(), injects CUDA_DEVICE_MEMORY_LIMIT_0=8000m and CUDA_DEVICE_SM_LIMIT=10 into the container, and preloads libvgpu.so so the limits get enforced. It works, and it’s been proven at scale (DaoCloud runs 10,000+ GPUs across 10+ data centers on it). Notice how much of the design is a workaround: the webhook exists because the scheduler can’t parse the request, the annotation exists because the API has no field for “which card and how much,” and the whole agreement between scheduler and kubelet rides on a string format that only HAMi’s components understand.

Every fractional-GPU project of that era made the same trade, each with its own private annotation dialect. That’s the situation DRA was built to end.

What DRA changes underneath

DRA replaces integer counting with a claims model, deliberately shaped like PersistentVolumeClaims (PVC). Four objects in the resource.k8s.io/v1 API group carry the flow, and each one has a different owner:

• ResourceSlice. Published by the device driver. Describes actual hardware per node with structured attributes (model, memory, architecture), so the scheduler sees devices instead of a bare count.
• DeviceClass. Written by the cluster admin. Defines categories of devices, filtered with Common Expression Language (CEL) expressions over those attributes.
• ResourceClaim and ResourceClaimTemplate. Written by the workload owner. A claim requests devices by class, selector, and constraint; a template stamps out one claim per pod so each replica gets its own allocation.

The scheduler allocates a concrete device to a claim before binding the pod, and the result lives in the claim’s status as a typed API object. Compare that to the annotation string above: the “which card and how much” decision now has a first-class home that kubectl can read, RBAC can guard, and other controllers can build on.

The timeline matters for planning. Core DRA went GA in Kubernetes v1.34 and is locked on since v1.35. Extensions are still graduating at their own pace: prioritized device lists (ask for a large card, fall back to 2 small ones) went stable in v1.36, while partitionable devices and consumable capacity are beta as of v1.36 and aren’t stable yet as of this writing (July 2026).

Consumable capacity is the piece that matters here

Core DRA alone doesn’t give you HAMi-style sharing. Its baseline sharing model is multiple pods referencing one ResourceClaim, which means they share the same allocation rather than each getting an accounted slice. The piece that maps onto HAMi’s model is consumable capacity, introduced as alpha in v1.34 behind the DRAConsumableCapacity feature gate, beta and on by default since v1.36.

It adds 2 things. A driver can mark a device with allowMultipleAllocations, declaring that independent claims, even from different namespaces, may land on it simultaneously. And a claim can carry a capacity request, asking for a specific quantity of a named resource on the device instead of claiming the device in full. The scheduler then does for GPU memory what it has always done for node memory: bookkeeping, guaranteeing that the sum of granted capacity never exceeds what the device advertised.

Line those up against HAMi’s extended resources and the mapping is almost mechanical. nvidia.com/gpumem: 8000 becomes a capacity request for memory; nvidia.com/gpucores: 10 becomes a capacity request for compute; HAMi’s scheduler-extender filter step (“does this card still have 8,000 MiB unpromised?”) becomes the upstream scheduler’s own math. The rejection HAMi users know as CardInsufficientMemory turns into a standard unschedulable claim. This is why HAMi’s maintainers treat DRA as convergence rather than competition: upstream Kubernetes adopted the same model the workaround had been implementing all along, and the project’s 2026 roadmap names complete DRA standard adaptation as a goal.

Scheduling is still only half the problem

Here’s the boundary that decides whether you still need HAMi at all. DRA, consumable capacity included, is a promise tracker. It guarantees the scheduler never promises more than a device has. It does nothing about a container that breaks the promise at runtime, and with GPUs that’s the failure mode that actually hurts: CUDA doesn’t care what a ResourceClaim says, and one greedy cudaMalloc() loop will happily take VRAM a neighbor was counting on.

Enforcement is HAMi’s second job, and it lives in HAMi-core, a C library (libvgpu.so) preloaded into the container that intercepts CUDA and NVIDIA Management Library (NVML) calls and applies the granted limits from user space. The behavior is easy to verify on any shared card: give 2 pods 8,000 MiB grants each, then have one deliberately allocate past its limit. The offender gets a CUDA out-of-memory at exactly its 8,000 MiB boundary while the neighbor keeps running untouched, even if the physical card still has free VRAM. The quota is the limiter, per container, which is precisely what a shared multi-team cluster needs.

I’ll be equally honest about the ceiling: this is software enforcement via library interposition. A workload that bypasses the preload (static linking against the driver, CUDA_DISABLE_CONTROL, containers-in-containers) escapes it. For adversarial multi-tenancy you want hardware partitioning (NVIDIA Multi-Instance GPU (MIG), which HAMi can also schedule dynamically); for cooperative teams sharing expensive cards, interception is the granularity winner: 1 MiB memory steps and 1% compute steps against MIG’s fixed profiles.

Nothing in DRA replaces this layer. The DRA driver’s job ends at the Container Device Interface (CDI): telling the runtime which device nodes to mount and which environment to set. What happens after the process starts calling CUDA is out of scope by design. So the realistic architecture pairs the two: DRA as the request-and-scheduling language, HAMi-core as the runtime muscle, and a driver in between translating one into the other.

The DRA stack HAMi ships today

That driver exists, and the work is spread across 3 repositories worth knowing individually, because they solve different operational problems.

k8s-dra-driver is the foundation: a DRA driver that publishes each GPU’s memory and compute as consumable capacity in ResourceSlices, runs the kubelet plugin that resolves allocations on the node, and wires containers up through CDI with HAMi-core enforcement attached. The project describes it as the first open source DRA driver for NVIDIA GPUs with consumable capacity enabled.

HAMi-DRA answers the question every platform team asks next: what about the hundreds of manifests already written against nvidia.com/gpu and nvidia.com/gpumem? It’s a mutating admission webhook that strips the classic extended resources out of incoming pods and generates the equivalent ResourceClaims on the fly, preserving the familiar UUID and device-type annotations for targeting. The resource names it translates are configurable (resourceName, resourceMem, resourceCores in the chart values), so renamed or vendor-specific resources keep working. If the pattern sounds familiar, it should: HAMi’s traditional pipeline also begins with a mutating webhook. There’s a deeper payoff than backward compatibility. Because the webhook emits a standard ResourceClaim and leaves scheduling to whoever owns it, HAMi-DRA drops into clusters running Volcano, KAI Scheduler, or any other scheduler without patching them. The traditional pipeline had to inject its own extender into the scheduling path, which meant every third-party scheduler needed HAMi-specific integration. DRA removes that coupling: the request is an object any DRA-aware scheduler already understands, so HAMi no longer has to modify upstream at all. The interception point survived the migration; only what gets written into the pod changed. With HAMi v2.9, HAMi-DRA v0.2.0 was declared production-ready, and the release line has since moved to v0.2.1. Its platform list grew past NVIDIA to Ascend and Enflame, with Hygon DCU documented through Hygon’s own k8s-dcu-dra-driver.

HAMi itself documents DRA mode as an installation option since v2.8, and the observability story carries over: the DRA monitor component is enabled by default and exposes per-container device metrics over Prometheus (port 31995), so dashboards built against HAMi’s exporters survive the switch. The incubation announcement commits the team to monitoring DRA consumption as a first-class concern.

Leaving scheduling to the cluster’s own scheduler has a cost worth naming. HAMi-DRA ships no scheduler of its own, so it can’t make topology-aware placement decisions. If two GPUs on a node are linked by NVLink (say GPU0 reaches GPU1 and GPU2 at high bandwidth, but not GPU3), a claim for two GPUs should prefer an NVLink-connected pair and avoid splitting across the slow path. The webhook can’t express that. It hands the scheduler a count and a capacity, not a topology constraint. For workloads where inter-GPU bandwidth matters, you either stay on a scheduler that models topology or accept that placement is bandwidth-blind.

Installing the webhook and driver is 1 Helm release, with cert-manager in place first for the webhook’s serving certificate (or bring your own via certs.custom.crt and certs.custom.key):

helm repo add hami-dra https://project-hami.github.io/HAMi-DRA
helm repo update
helm install hami-dra hami-dra/hami-dra

If the GPU Operator manages your drivers, install it with devicePlugin.enabled=false first, because the DRA stack replaces the device plugin’s job. After the release settles you should see 3 pods: the kubelet plugin, the webhook, and the monitor. kubectl get resourceslice confirms the driver is publishing GPU capacity, and once a workload lands, kubectl get resourceclaim shows the allocation the scheduler made, in the API instead of an annotation.

The prerequisites are stricter than traditional mode, and each one is a real gate:

1. Kubernetes v1.34 or newer, with DRAConsumableCapacity enabled. On v1.34 and v1.35 the gate is alpha and off by default, so it needs to be set on the control plane, which rules out managed clusters that don’t expose API server flags. The gate graduated to beta and turned on by default in v1.36, which quietly removes the biggest adoption blocker.
2. A CDI-capable runtime. containerd or CRI-O with CDI enabled, plus NVIDIA driver 440 or newer.
3. A DRA driver for your silicon. NVIDIA is the mature path; Ascend, Enflame, and Hygon DCU are arriving. HAMi’s traditional mode covers a much longer list (12+ device families as of v2.9) through per-vendor device plugins. Until the driver list catches up, heterogeneous clusters stay on the device plugin path.

Important Note: DRA mode and traditional device-plugin mode must not run in the same cluster simultaneously.

The documentation states it flatly, and the reason follows from everything above: two bookkeepers, the scheduler extender and the DRA scheduler, would each believe they own the same VRAM, and neither sees the other’s promises. Pick one mode per cluster.

The same GPU slice, old way and new

The convergence is easiest to see in YAML, with both examples taken from the current HAMi DRA documentation.

Start with what HAMi users have written for years. Ask for one card, 10 GiB of its memory, and half its compute:

resources:
  limits:
    nvidia.com/gpu: 1
    nvidia.com/gpumem: 10240
    nvidia.com/gpucores: 50

This still works unchanged in DRA mode. The webhook rewrites it at admission into the native form below, so no manifest has to change.

Here is that same request written natively, as a ResourceClaim against HAMi’s DeviceClass:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-half-claim
spec:
  devices:
    requests:
      - name: gpu
        exactly:
          deviceClassName: hami-core-gpu.project-hami.io
          allocationMode: ExactCount
          count: 1
          capacity:
            requests:
              cores: 50
              memory: "10Gi"

The pod references the claim instead of listing resource limits:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-test-dra-native
spec:
  containers:
    - name: cuda
      image: nvidia/cuda:13.0.1-base-ubi9
      command: ["sleep", "3600"]
      resources:
        claims:
          - name: gpu
  resourceClaims:
    - name: gpu
      resourceClaimName: gpu-half-claim
  restartPolicy: Never

The mapping is direct: nvidia.com/gpu becomes the device count, gpumem becomes the memory capacity request, gpucores becomes cores. The native form is longer, but that verbosity is the point. The old three-line block was opaque to the scheduler, which is why HAMi needed a webhook, an extender, and an annotation to act on it. The ResourceClaim says the same thing in a shape the upstream scheduler reads, RBAC guards, and kubectl shows, no private annotation dialect required.

Either way, nvidia-smi inside the running container reports 10,240 MiB, the granted slice rather than the physical card, because HAMi-core is doing the same interception it always did. The request language changed; the runtime contract didn’t.

How to choose, mid-2026

My read, as someone who runs the traditional pipeline and has been tracking the DRA work:

• Managed Kubernetes without feature-gate access on v1.34 or v1.35, or anything older: traditional mode, no hesitation. It’s the path with years of production mileage, 16 releases, and independent case studies reporting 3x utilization gains behind it.
• Mixed-vendor accelerator fleets: traditional mode, until DRA drivers exist for your silicon. This is HAMi’s widest moat and the part DRA touches last.
• NVIDIA clusters on v1.34+ where you control the control plane, and anyone on v1.36: stand up DRA mode in staging now. Start with the HAMi-DRA webhook so no manifests change, watch kubectl get resourceclaim against your real workload mix, and let the results decide your production timeline. You end up on an API the upstream scheduler understands natively, which compounds as extensions like prioritized lists stabilize.

Three honest caveats remain: consumable capacity hasn’t reached stable upstream, the k8s-dra-driver’s own Helm chart is still marked work in progress, and DRA-side vendor coverage is a fraction of traditional mode’s. None of that is hidden; all of it is fixable with time, and the direction of travel is set on both sides, with the HAMi 2026 roadmap naming complete DRA standard adaptation as a goal.

GPU sharing on Kubernetes was built in the gaps of an API that could only count. DRA closed the gap, HAMi kept the muscle, and for the first time the request, the schedule, and the enforcement all speak the same language.

Auto mode is now the default in Claude Code for Pro, Max, and Team plans

Claude Code will soon run auto mode by default for Pro, Max, and Team plans, enabling longer-running autonomous work, and catching more dangerous commands than manual review in our testing.

We're making auto mode the default in Claude Code. Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode. If you've already set a different default yourself, you may get a one-time prompt asking whether you want to switch to auto mode. If you have a pinned default, nothing changes for you. The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today.

Auto mode remains opt-in for now on Claude Enterprise, the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry, giving admins time to review the change. In the coming month, working with our cloud partners, we plan to make it the default across all of these and no longer charge for classifier overhead. In the meantime, Enterprise admins can make Claude Code's auto mode the default through managed settings.

Auto mode is designed to balance users’ desire not to be interrupted with a system that helps avoid harmful actions: instead of prompts, it routes each tool call through a classifier targeted at blocking actions that are irreversible, destructive, or aimed outside your environment. When the classifier blocks something, Claude usually finds a safer way to proceed on its own or asks you directly for the go-ahead; if it can't make progress—three blocks in a row, or twenty across a session—Claude Code falls back to manual approvals.

We spent the last several months testing whether auto mode is as safe or safer than an average user clicking through prompts. We ran internal red-teaming, third-party red-teaming and prompt-injection evaluations, a controlled study with 1,053 paid testers, and analysis of real production sessions. On every measure we tested, auto mode matched or outperformed manual review.

Auto mode also lets Claude work autonomously for longer stretches. This makes models built for long-running work, like Claude Opus 5, more practical to leave running for hours on large tasks. Reducing overhead for users also increases output. Among Teams & Enterprise adopters, auto mode users ship about 25% more PRs. Unblocking Claude allows tasks to run longer uninterrupted and get more work done. Teams at Adobe, Nuro, Gusto, and Garner Health already run auto mode as their production default.

Below, we share the safety data and customer results motivating the change, and how to set a different default if you prefer.

Comparing manual review to auto mode

Data suggests that manual review can become habitual: users approve 97% of permission prompts in Claude Code. While most prompts are likely for safe, routine commands, an approval rate that high suggests many users are clicking through reflexively rather than reviewing each command. These prompts ask developers to make dozens or hundreds of important security decisions every day, often in the middle of projects, which places the review burden on users and increases the chance that something important slips through the cracks. Data also suggests that users more frequently scrutinize and push back on other types of dialogues: for example, when Claude presents a plan for approval, users reject 39% of them. But for individual permissions requests, the rejection rate is only 3%.

The same pattern shows up in settings files. As of June 2026, 49.5% of active CLI users have manually created a Bash allow-rule—5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*) or Bash(node:*) that are essentially equivalent in practice—and that share is growing roughly 5 percentage points every 5 weeks. Beyond allow-rules, 62% of users have used bypassPermissions or clicked “don't ask again” on Bash, and 25% of interactive sessions start in bypass permissions mode.

Permission rules still fire before the classifier in auto mode, except for allow rules broad enough to grant arbitrary code execution (e.g. python:*). These arbitrary rules are set aside while in auto mode, since they would let commands skip the classifier entirely. Settings files aren't modified, and the rules apply again the moment you switch to another mode.

Improving safety with auto mode

Research conducted internally and through several third parties suggests that auto mode is safer than how a typical user engages with permission prompts today. We tested auto mode against what developers actually approve when they're clicking through permission prompts. Across each of these measures—internal red-teaming, third-party penetration testing, and analysis of real-world sessions—auto mode matched or outperformed human approval.

Auto mode outperforms manual permissions on safety

We hired 1,053 paid testers through a research vendor for a coding study. These participants worked in a test environment set up specifically for the study, not in their own codebases or on real projects. Participants knew they were being evaluated, but—following standard blind-study design—weren't told which behavior was being measured. Partway through each session, a single permission prompt was swapped for a clearly dangerous command, and the vendor recorded whether the tester approved it (Note: approving the prompt never resulted in anything dangerous being run; only the text of the prompt testers saw was changed).

The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053). Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed. As sessions got longer, humans did worse: they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat regardless of session length.

Auto mode prevents more harmful actions

Our research also suggests that auto mode leads to fewer harmful actions than manual permissions mode.

We examined how auto mode performs in real usage. From May to June 2026, we examined sessions our safety pipeline had flagged for review, drawn only from accounts that have opted in to data use for training and analysis. We re-graded each one with a model on two 0–10 scales. The first was harm severity with 10 being company-wide, irreversible harm, such as leaking a company's entire source code, 7 representing production-level severity such as deleting rows from a production database, and 0 a fully reversible action confined to the local workspace, like overwriting a scratch file. The second was how explicitly the user had asked for the action, so we could separate harmful actions the user directly requested from harmful actions the agent took with less explicit direction.

Among the flagged sessions, those that went through manual approval contained serious unintended harm more than twice as often as auto mode sessions. At production-level severity (7+), 6.3% of manually approved sessions contained a harmful action the user hadn't explicitly asked for, compared to 2.4% of auto mode sessions, and the gap held at every severity level we tested.

Adversarial red-teaming made auto mode stronger

We worked with Apollo Research, a UK-based AI safety startup, on a two-week pilot injecting synthetic attacks into real coding trajectories, across three datasets covering broad failures, data exfiltration, and safety-related threats.

The engagement followed a standard find-fix-verify loop. Apollo shared a set of successful attacks along with recommendations to strengthen auto mode. We hardened the classifier against them primarily by giving it more context about the environment it's protecting (repository visibility, git state, and the data-handling rules described below).

After hardening, Apollo re-tested on a separate held-out attack set that we never had access to. Auto mode caught about half of the attacks it previously missed, at a cost of missing about 2% of attacks it previously caught. Since we couldn't tune against the held-out set, this suggests the hardening generalizes to new attacks rather than patching the specific ones Apollo shared. Across both the shared and held-out sets, the classifier's miss rate fell from 12% to 7%.

These attacks are synthetic and adversarial by design, built to find where the classifier fails, and more malicious than anything Claude would do unprompted. The 7% miss rate is measured against this set and should not be taken as the miss rate on real traffic.

Auto mode reduces prompt injection risk

The auto mode classifier adds an additional layer of defense against prompt injection attacks that try to force the agent to deviate from the user’s instructions. When running with auto mode, tool results are scanned by probes for potentially malicious instructions, and auto mode checks that actions are aligned with user intent. We tested auto mode compared to an unguarded model to illustrate the power of this defense-in-depth approach.

We commissioned an evaluation from a third party, Trajectory Labs, who tested different models within the latest publicly available versions of Claude Code and Codex as of July 17th 2026. They tested 72 indirect prompt injection scenarios held out from Anthropic. Each scenario was tested 10 times. Successful attacks would, in a non-testing environment, result in irreversible actions that could harm the user such as sensitive-data exfiltration, financial fraud, or credential phishing. The attacks were optimized against Claude Opus 4.7, which is not in the reported set, so every model in the evaluation faced them as unseen attacks. In addition to auto mode, the evaluations looked at Claude Code’s bypassPermissions mode and Codex’s Full Access mode.

Both Codex and Claude Code were evaluated using an identical browser integration produced by Trajectory Labs, PBC. This integration provides a set of MCP tools which are a thin wrapper around common Chrome APIs such as `navigate`. Safeguards built into first-party browser integrations such as the Chrome extensions provided by OpenAI and Anthropic were not tested. As such, these results should be viewed as a measurement of the underlying model, rather than the complete set of safeguards which might exist in a given deployment.

In this evaluation, none of the 720 attack attempts succeeded against Claude Fable 5, Opus 5, or Sonnet 5 running auto mode. On the other hand, 5.83% of the attacks succeeded against GPT-5.6 Sol running Codex's Auto-review mode. Notably, this is greater than the 0.09% average attack success rate against our latest models running in bypassPermissions mode without additional safeguards. The tests showed a 19.03% attack success rate against GPT-5.6 Sol when running in Full Access mode. Attack success rates differ between tasks where tools return results as text and tasks that require interacting with a browser through screenshots, as shown below.

Three incidents auto mode prevented inside Anthropic

Auto mode is also the default for all Claude Code internal usage at Anthropic. Here are three actions the classifier prevented internally:

• An off-network data leak: When an upload to an internal drive failed, Claude's fallback was to publish the same report to a public code-sharing site. Auto mode denied the fallback and prompted the user for next steps.
• A destructive mass operation: In a long-running session, Claude attempted a mass process kill across roughly two thousand pods and queued deletions that would have torn down hundreds of GPUs of in-flight training jobs. Auto mode flagged the destructive commands before execution.
• Over-broad privilege escalation: Asked to provision read-only billing access, Claude reached for a cloud role that grants full administrative control at the account root. Auto mode caught the mismatch between what was requested and what roles would have been granted.

In each case, Claude either found a safer path on its own or checked in with the user before proceeding.

Making auto mode even safer

We’re continuously investing in new auto mode features that make it safer and easier to ship production code. Recent examples include:

• Hard denies: Data exfiltration, like sending your code or secrets somewhere external, sits in a category the classifier is designed to never approve. To run an action like that, you have to switch out of auto mode or run the command yourself. Hard deny rules are customizable via settings so you can add more rules that you never want allowed even when requested by users in your organization.
• Rules for data access and sharing: The classifier now carries explicit rules distinguishing secrets and potentially sensitive/confidential information—and where each can be accessed and shared. To make those rules enforceable, it also checks whether the destination of a git push or pull request is public, private, or trusted before the action runs. The same push can be routine or an exfiltration depending on where it lands: code that belongs in your team's private repository shouldn't end up in a public one, and the classifier is now designed to flag when this might happen.
• Checking git status before destructive git actions: Before a command that could discard uncommitted work, like git reset --hard, the classifier sees the repository's current git status, letting auto mode know what is being reset.
• Prompt injection screening: When Claude pulls content from external sources, like web pages, file contents, or tool outputs, an API-side probe checks that content for attempts to hijack Claude's behavior. When something looks like an injection attempt, a warning is added to Claude's context before the result is shared with the user.

Auto mode in production

Teams are already running auto mode as their production default:

• Adobe's merchandising platform team is responsible for keeping pricing and promotional pages accurate and current across 90+ countries and 30+ languages on Adobe.com. They built an agentic loop to build and verify those pages, running it in auto mode so engineers receive finished PRs for review.
• Nuro runs auto mode across its research and engineering orgs, using it to power overnight research agents that hill-climb evaluation metrics and return finished PRs for review by morning.
• Gusto adopted auto mode to end the permission fatigue that was pushing engineers toward bypassing permissions checks entirely. About 10% of sessions since mid-May include a classifier denial—evidence it's doing real work without slowing legitimate tasks.
• Garner Health pushed auto mode as the default to all 550 employees via managed settings, standardizing a company-wide software development lifecycle (SDLC) that no longer depends on hand-curated command allowlists.

“At Adobe, we want to move fast without compromising the quality of the customer experience we deliver on Adobe.com. With Claude Code auto mode, we built an agentic loop that rapidly accelerated our work. Claude builds the user interface and then loops back to verify that it matches the intended design, automatically fixing any issues before we ever look at it. This shortened our development cycle while delivering pixel-perfect results.” — Tomislav Reil, Director of Engineering

"The other day, I kicked off an agent at 10 p.m. and it kept running until 5 a.m.—and it gave me three PRs in the morning. I think it's pretty impressive. Only auto mode enables this kind of workload." — Kai Zhou, Staff Software Engineer

"Auto mode gave us a safer balance between speed and control. We were able to remove the repeated prompts and increase productivity without compromising safety. We can see that auto mode blocks at the right time, which gives us the confidence to move quickly." — Martin Emde, Software Engineer

"We built a standardized SDLC for the entire engineering org that's only possible because of auto mode. Employees view it as a weight off their shoulders. They don’t have to monitor their agents for hours on end anymore." — Evan Magnussen, Platform Engineering Manager

Learn how these customers are running auto mode in production.

Getting started

For Pro, Max, and Team users: if you haven’t set a default permission mode, you’ll receive an in-product notice and new sessions will start in auto mode automatically. If you've set a different default, you may see a one-time prompt asking if you’d like to switch your default to auto mode. If your Team admin has set a default in managed settings, nothing changes for you.

For Enterprise users and users who access Claude Code via the Claude API, auto mode remains opt-in for now. We plan to make auto mode the default in the coming month, and we’ll notify Enterprise admins before we do.

To switch modes, press Shift+Tab in the CLI or use the mode dropdown on the desktop app. Admins can pin an org-wide default with `defaultMode` in managed settings, or turn auto mode off entirely with `disableAutoMode`.

Finally, while we believe auto mode reduces risk for most users, it relies on classification systems and therefore does not eliminate risk. For high-stakes changes to production infrastructure, we still recommend reviewing Claude's actions yourself. See the auto mode docs for full configuration instructions.

On July 22, we launched Cursor Router with two new configurations, Auto Intelligence and Auto Balance. Since then, we have continued improving both modes as new models have arrived and our routing system has learned from more production traffic.

Today, Auto Intelligence delivers above Fable-level user satisfaction at 68% lower cost, a further 18% reduction since its launch. Auto Balance outperforms Opus 4.8 at 41% lower cost, a further 8% reduction over the same period, while further increasing user satisfaction by 3%.

We're working towards a Cursor Router that improves alongside the model frontier. This post explains how the current system works.

A data-driven approach to routing

Cursor Router is built around the idea that model selection should be learned from how models perform on real developer work, rather than inferred from benchmark scores.

The router makes each decision using signals from the current turn and recent conversation state. These include structured features such as the task category, along with recent tool calls and the broader context of the work.

From there, routing happens in two parts.

First, we need to decide whether a turn is simple enough for a price-efficient model. Compass, our complexity predictor, makes this decision.

Second, if the turn is more demanding, we need to decide which frontier model is most likely to perform well on that kind of work. To make that decision, we classify the turn using a taxonomy of tasks, domains, and modifiers learned from real developer traffic.

Building a dataset

To develop the routing system, we first needed a dataset that reflected the conditions it would encounter in production. We built it from live Cursor traffic so it would preserve the actual mix of developer tasks, the context surrounding each turn, and the effects of switching between models.

As always, we respected users' privacy mode and data retention settings throughout this process.

The dataset contains hundreds of thousands of turns sampled across a range of models. Each datapoint includes the conversation signals available to the router, along with two outcomes we use to compare routing choices.

1. Performance. We infer performance from what the user does next. Moving on to the next task is a strong positive signal, while correcting the agent is a strong negative one.
2. Cost. We calculate cost from API pricing and token usage for that turn. Because the data comes from live traffic, it also captures costs that benchmarks often miss, including cache misses caused by switching models.

Predicting complexity with Compass

Compass estimates the complexity of each turn by predicting whether the user will be satisfied with Cursor's response. We train it on the performance signal mentioned above.

We use the resulting prediction as a proxy for complexity. This works because users rarely ask for corrections after simple tasks, like making a commit, while they're more likely to make follow-up requests when the work is more complex.

We evaluated Compass online and confirmed that its scores are strong predictors of user satisfaction. Turns that Compass rated as most likely to succeed received a positive performance signal 96% of the time, while turns it rated as least likely to succeed received one 71% of the time.

In practice, Compass assigns each turn a continuous complexity score between 0 and 1. We set a threshold within that range to determine which turns stay on a price-efficient model and which are upgraded to a frontier model. Lower thresholds keep more traffic on the price-efficient model, while higher thresholds upgrade more often.

Learning model strengths

After Compass tells us when a turn is complex enough to justify using a frontier model, the next question is which frontier model to use.

To answer it, we built a taxonomy from real developer traffic that describes each turn across three dimensions:

• Domains identify where the work happens: backend, database schemas, frontend
• Tasks identify what the developer wants done: fixing bugs, running commands, writing tests
• Modifiers capture characteristics that cut across domains and tasks, but may change which model performs best: bounded edits, product questions, visual-heavy changes

We then compare how different models perform across those categories. We found that no model dominates every kind of work, and each has categories where it outperforms:

• Grok offers strong value across broad, routine work. Its low inference cost made it especially effective for categories such as Git commands and general database operations.
• Sol performs especially well on planning and codebase comprehension. It also delivered strong results across several implementation tasks at a lower cost than other frontier models.
• Opus performs well on execution-heavy work. It showed particular strengths in devops, database queries, and performance optimization.
• Fable excels at debugging and visual implementation. Its quality gains were most valuable on complex tasks where they justified its higher cost.

Cursor Router uses those differences to match each turn to the model best suited to it.

Combining into an algorithm

Compass and the taxonomy play complementary roles. Compass estimates the model-agnostic complexity of the turn and compares that score with a routing threshold. Depending on where the score falls, we either send the turn to Grok, given its low inference cost, or use the taxonomy to identify the frontier model with the strongest observed performance on that kind of work.

When Compass does send a turn to the taxonomy router, model selection follows two rules:

1. Only route when performance is clearly better. A candidate model becomes eligible only when its observed performance on that task label clears a one-sided 75% uplift threshold against the price-efficient model. Roughly, this means we need 75% confidence that the improvement is real.
2. Choose the best mix within the budget. From the eligible candidates, the optimizer chooses the traffic-weighted combination expected to deliver the largest performance gain while keeping the average cost per turn within the mode's budget.

Together, the Compass threshold and the task router's cost budget define each mode's position on the cost-performance curve. Auto Balance keeps more traffic on the price-efficient path and gives the task router a smaller budget. Auto Intelligence gives the task router more room to select frontier models when the expected performance gain justifies the cost.

Evaluating performance in production

We evaluated our routing policies in two stages. First, we used cross-validation to tune the Compass thresholds and optimization budgets without overfitting to a particular split. We then evaluated the selected policies on a held-out test set that had not been used during training.

This gives us a more reliable estimate of how each policy should perform on new traffic. It helps us eliminate weak candidates and compare expected cost and performance before deployment. But offline analysis still cannot fully capture how a policy will behave in production, and benchmarks are limited for the same reason. Live developer traffic remains the most representative test.

We then tested the policies on live traffic, where we could measure user satisfaction and the actual cost of each turn under production conditions. This captures effects that are difficult to model offline, including token usage, caching, and the cost of switching between models.

Before launch, we tested both modes on live traffic and found that each improved the cost-performance tradeoff relative to individual frontier models. Auto Balance delivered higher satisfaction than Opus 4.8 at lower cost, while Auto Intelligence approached Fable-level satisfaction at a much lower cost.

We have since repeated this process as the routing system and available models have improved, moving both modes further beyond the cost-performance frontier.

Keeping pace with the model frontier

Since launching Cursor Router, we've added Opus 5 to the routing mix and improved Compass's predictions. That gives the router both a stronger set of models to choose from and a better signal for deciding when each one is worth using.

Over time, we want the router to become more adaptive by predicting each model's expected quality and cost, learning from production outcomes, and updating continuously. As the system improves, Cursor users will be able to benefit from frontier models where they're needed most, without paying frontier-model prices on every turn.

Model Genome is a pipeline that fingerprints models on architecture, tokenizer, and weights, and combines them into a single at-a-glance genotype. It can be used to help determine whether a model is truly self-developed from scratch. Building on open-weight bases is legitimate and widespread, so the tool only reports lineage, not wrongdoing.

I first read about Taalas in February, in a Hacker News thread I opened expecting another inference startup with a benchmark chart. Instead it was a Toronto company that had taken Llama 3.1 8B and etched it into silicon - not loaded it, etched it, the weights laid down as physical transistors at the fab.

My first thought wasn't that this was new, it was that we've done this before. Groq had been working the same problem for years and stopped one step short, keeping the weights on the chip but still rewritable. The same question sits under both: how much of a model are you willing to make permanent in exchange for speed? Inside eight months, Nvidia had taken one of them and AMD the other.

That's the part worth paying attention to. Something quite significant is happening behind the curtains right about now, and it's easy to miss because it reads as chip news. Every previous time a workload left general-purpose hardware, it permanently changed who could afford to run it, and AI inference is somewhere in the middle of the same move. How far it goes isn't a fixed quantity waiting to be measured, because every part of the problem is still being designed - the models, the silicon, and, as it turns out, the way a model produces output at all.

We've seen this movie

Bitcoin mining went from CPUs to GPUs to FPGAs to purpose-built ASICs - application-specific integrated circuits, chips that do one job and nothing else - in four years. Each step traded flexibility for efficiency, and each was irreversible. When the first Avalon units shipped in 2013, GPU mining didn't get slower, it got pointless.

The pattern is everywhere now, and invisible precisely because it worked. YouTube transcodes video on its own Argos chips, which Google says beat its previous optimized software setup by 20 to 33 times. Network switching is Broadcom silicon. Your phone has a fixed-function block for H.265 decode, an ISP (image signal processor) for the camera, a Secure Enclave that does nothing else. It's what happens when a workload settles down enough to be worth casting in metal - and that condition is where this whole story ends up.

The wall they're all attacking

The thing GPUs spend most of their energy on during inference isn't math, it's moving weights. Every layer, every token, the weights come out of HBM (high-bandwidth memory, the stacked DRAM beside the GPU die) and through the compute units, then the next layer's follow. A 32-layer model does that 32 times to produce a single token, then starts over for the next. That's the memory wall - inference is limited by bandwidth, not compute, and HBM is the most expensive component on an AI server.

A chip that holds its weights on-die needs no HBM at all. Its memory is SRAM, printed on the logic wafer at a fab that isn't one of the memory plants whose 2027 output is already sold - so pushing inference onto this kind of silicon spreads the manufacturing load onto capacity that isn't already spoken for, and takes some pressure off the RAM and VRAM the rest of us are trying to buy. How much pressure is the open part, since the GPUs these chips get paired with still carry HBM.

Two companies have built exactly that, and they part ways on how much of the model they were willing to freeze to do it. Everything else follows from that.

Bet one: the model is the silicon

Taalas puts the weights in a mask-ROM fabric - read-only memory, written once during manufacture - where a single transistor stores four bits and performs the multiply related to it. Data flows through the chip's physical layers in sequence and never goes back out to external memory.

The numbers, all vendor-run and none independently verified:

• 16,960 tokens/second per user on Llama 3.1 8B, against roughly 230 on an H200. People who hit the public demo reported 14,000-17,000.
• 0.015 J/token, against Groq's self-reported 1-3 and roughly 10-30 for H100-class systems, per EE Times.
• $0.0075 per million tokens, against a typical $0.20-0.50.
• 815 mm² on TSMC N6, 53 billion transistors, about 250 W per card. One chip holds the whole 8B model.

"Etched in silicon" sounds like the chip is fixed the moment it leaves the fab. That's how most of the coverage reads, and how I read it at first, but it isn't quite true. The die has two regions. The mask-ROM fabric holds the frozen weights. Beside it sits an SRAM recall fabric - rewritable memory on the same chip - holding the KV cache and LoRA adapters, small sets of extra weights that steer a model toward a domain without retraining it. Those swap while the chip runs: the legal adapter gives you legal language, the clinical one medical, same etched model underneath.

Nor is the frozen half a full redesign. A chip is built from a stack of patterned layers, each printed through its own photomask, and cutting that mask set is the expensive part - tooling paid for before a single wafer moves. Taalas reuses the same base stack every time, with only two of the roughly hundred layers carrying the weights. It quotes about two months from new weights to shipping cards, where a full custom design runs six or more. Cost is harder to pin down, since published mask prices vary by an order of magnitude. The most specific estimate anyone has put on Taalas itself is zach.be's: about 30 chip variants and $100M in masks for a DeepSeek-R1-class model, so roughly $3M per variant, needing a year of service life to pay back.

So it's a spectrum, not a binary, and $3M is a line item for anyone already serving inference at scale. But it is still silicon. Two months is design time, not delivery time - Taalas had already slipped its own schedule by a year, and fabrication, validation and swapping cards out of racks come after it. And the adapters steer the hardwired weights rather than replacing them, so the chip picks up your terminology but not a capability the etched model never had. A revised base model, a different tokenizer or a new architecture means new masks and new cards.

Bet two: the model is loadable

Groq attacked the same wall from the other side, and the more I look at both, the more I think the hedge is the interesting part. The LPU (language processing unit) also has no HBM. Weights live in on-chip SRAM, placed by a compiler that works out every instruction and data movement in advance, so nothing is decided at runtime and latency is known before a job starts. Any model can run on it, and switching takes a recompile and a reload - minutes, no new hardware.

What that costs is capacity. First-generation LPUs carry 230 MB of SRAM per chip, which won't hold even a 7B model at 8-bit, and a 70B model spans 576 chips - interconnect, power and floor space for every one. The LP30 die improves the ratio without changing the problem, at roughly 500 MB, 256 to a rack for about 128 GB of on-chip SRAM. Still hundreds of chips to hold what Taalas fits on one die.

What they're actually betting on

Taalas bets the weights freeze - that a model stays useful long enough to earn back its masks, which its own economics put at about a year. Groq bets only the architecture freezes - transformers stay transformers, while the weights inside them keep changing every few months. Taalas is expensive in silicon per model. Groq is expensive in silicon per change of model.

Both bets have been endorsed with money. Nvidia licensed Groq's architecture for $20 billion in December, and AMD agreed to acquire Taalas just over seven months later - hedges against their own product being the wrong shape for most of the work. More interesting than either deal is that both buyers described the same system design. Answering a prompt has two phases: reading the input, which is parallel math and exactly what a GPU is good at, and writing the reply one word at a time, each word needing the whole model again before the next can start. Both put the GPU on the first phase and the specialized chip on the second. Two opposite philosophies about what to freeze, one identical division of labour.

Where the analogy breaks

Bitcoin got its ASICs because SHA-256 is a specification, standardized in 2002, years before Bitcoin existed. It will never change - not "probably won't" but can't, because changing it would be a different currency. Video codecs went the same way: standardize the format, wait, then put it in silicon.

The precondition was never "this workload is popular." It was "this workload is finished."

LLMs are pretty fluid tools, and I don't think they're anywhere near finished. Llama 3.1 8B came out in July 2024, so HC1 shipped in February 2026 baking a nineteen-month-old model, with better ones already out in its size class. Silicon takes long enough to arrive holding something the world has moved past.

The usual counter is that the pace will settle. I half agree. The breakthroughs do look like they're slowing - the transformer has held for nine years, mixture-of-experts is standard, genuinely new architectural ideas arrive further apart. But releases won't slow much, and releases are what breaks the chip. Llama 3.1 to 3.2 to 3.3, Qwen 2.5 to 3, a post-training refresh, a tokenizer swap. Every one keeps the architecture identical and changes the numbers, and the numbers are what was cast in metal.

And most customers need flexibility first of all. Ask a phone assistant "what's this charge on my bill?" and it runs speech recognition, a vision model on the screenshot, a language model to reason about it, then speech synthesis - four models, three modalities, one question, and the mix shifts as better ones arrive. A chip that does one of those extremely fast and none of the others solves very little.

The dark horse nobody is buying

Every argument so far leaves one assumption standing: a model writes one word at a time. Both designs are built on it. But nothing forces a model to.

Diffusion language models don't. Google's Gemini Diffusion "generates entire blocks of tokens at once," refining a whole rough draft in place rather than extending a sentence, and reports 1,479 tokens per second of sampling. One sweep of the weights per block instead of one per word. Google publishes neither the model's size nor the hardware it ran on, so that figure won't line up against the ones above, and the demo is invite-only. The one you can put a prompt into today is Inception's Mercury, selling the same idea as a product - by its own claim, 5 to 7 times the throughput at 70% lower cost per task.

That's the same trade the chips make, only in software. Diffusion spends extra arithmetic - several passes over a block rather than one pass per token - to avoid re-fetching weights. On a GPU that arithmetic is nearly free, because during single-stream decode the compute units sit idle waiting on memory. Filling idle silicon is precisely the inefficiency Taalas and Groq spent a chip design each to remove.

That extra arithmetic buys more than speed. An autoregressive model cannot unsay a word - once a token is out it conditions everything that follows, and the best the model can do is contradict itself further down the page. A diffusion model revisits the same positions across sweeps, which is why Google claims it "corrects errors during generation for more consistent outputs." Reasoning models chase the same thing from the opposite direction, improving an answer by generating more tokens rather than by going back over the ones they have. Every route to a better answer costs compute per delivered token.

So the two don't add up the way you'd hope. Groq can recompile for a diffusion model and collect little, its weights being local already. Taalas would have to etch one, and its compute is physically fixed at one multiplier per etched weight, so more passes per token runs the wrong way entirely. The hardware that gains most from diffusion is the GPU that was supposed to hand the job off. I'm reasoning from the architectures here - nobody has published diffusion numbers on either chip.

It's a dark horse in the market's eyes and a favourite in mine. The numbers don't back me up yet: Gemini Diffusion still trails Gemini 2.0 Flash-Lite on GPQA Diamond, 40.4% against 56.5%, and on Global MMLU, 69.1% against 79.0%. But it doesn't have to win. It only has to make the sequential bottleneck smaller than the thing built to remove it.

Unless everything moves toward everything else

That's the argument as it stands today, and today is not the interesting part. The line between what gets frozen and what stays loadable isn't handed down by nature. It's a design decision, and every side of it is still being designed.

Hardware is already bending. HC1 used a proprietary 3-bit format with some 6-bit weights mixed in - a bespoke chip for a bespoke encoding. HC2 moves to MXFP4, an industry-standard 4-bit format, so the silicon is adapting to what models already do rather than the other way round. Give the SRAM half a bigger share of the die and you buy more adapter capacity and longer context on the same frozen base.

Models can move too, and mixture-of-experts is the obvious opening. A model that routes each token through a few of many experts is already modular in the way silicon likes. Nothing stops someone etching the experts that get hit constantly and leaving the long tail loadable, or designing a model with a deliberately stable trunk and a replaceable top. Nobody has shipped this - I'm speculating - but it's the sort of thing that gets built when there's a chip waiting for it.

And either camp can build for the dark horse. A chip designed from the start for block-parallel generation is a different chip, not an impossible one. The question was never whether hardware or software wins. It's where all of this converges, and what the optimal path turns out to be.

Where hardwiring does earn its place

None of this makes the Taalas bet a bad one. It makes it a narrow one, and narrow isn't an insult.

The functions that are genuinely finished are the boring ones. Speech recognition. Translation. OCR. Text embeddings for retrieval. Content moderation. These already run as small dedicated models, at volumes that would pay off a mask set easily, and what we ask of them has barely moved in years. Nobody is going to demand a personality update for their OCR. Diffusion doesn't threaten them either. Text embeddings aren't produced a word at a time in the first place, and nothing about a moderation classifier is waiting on the sequential bottleneck.

Taalas got first silicon out with 24 people and $30 million, so this isn't structurally reserved for people who own datacenters. The physics rewards small directly too: an 8B model fits on one die, a trillion-parameter one needs about fifty of the next-generation chips wired in sequence. I still think small dedicated models are where most of this ends up, and the ones worth casting in metal are the narrowest, not the ones you talk to.

So

Casting a model into silicon is a bet on how long it can stand still. For SHA-256 the bet was free, because the answer is forever. For H.265 it cost a decade of standards work. For a general-purpose LLM in 2026, it's a bet that a nineteen-month-old set of weights is close enough for the year it takes to earn the masks back - hedged by a strip of SRAM that lets you change its accent but not its mind.

Taalas will probably win that bet on a narrow function. On the broad one, Groq is likely to win by refusing to make it - on today's models, with today's silicon. Or somebody shaped like either of them. But Nvidia's $20 billion on Groq and AMD's purchase of Taalas both went to the premise that the expensive part of inference is fetching weights one token at a time, and the cheapest way to be wrong about that is for the models to stop writing one token at a time. Neither buyer has bought a hedge against that one.

jax-js is a machine learningan ML library and compiler for the web

High-performance WebGPU and WebAssembly kernels in JavaScript. Run neural networks, image algorithms, simulations, and numerical code, all JIT compiled in your browser.

Add jax-js to your project

Zero dependencies. All major browsers, with bundlers and in JS modules.

npm install @jax-js/jax

Matrix multiplication

Billions of floating-point operations (GFLOPs) per second

Like JAX and PyTorch in your browser

jax-js is a end-to-end ML library inspired by JAX, but in pure JavaScript:

• Runs completely client-side (Chrome, Firefox, iOS, Android).
• Has close API compatibility with NumPy/JAX.
• Is written from scratch, with zero external dependencies.

jax-js is likely the most portable GPU ML framework, since it runs anywhere a browser can run. It's also simple but optimized, including a lightweight compiler that translates your high-level operations into WebGPU and WebAssembly kernels.

The goal of jax-js is to make numerical code accessible and deployable to everyone, so compute-intensive apps can run fast and locally on consumer hardware.

Live examples

Interactive demos for local AI models, simulations, geometry processing, and numerical methods.

LLM Chat

Run a small language model locally in your browser, with GPU and CPU-based inference.

Neural Cellular Automata

Grow image patterns with a tiny differentiable automaton.

Heat Method Geodesics

Compute surface distances on triangle meshes with dense solves.

Whisper ASR

Transcribe audio locally with OpenAI Whisper.

Kyutai Pocket TTS

Voice cloning AI model that runs in your browser.

Fluid Simulation

Interactive Navier-Stokes flow with WebGPU kernels.

D-FINE Detection

Run an ONNX object detector locally with WebGPU.

MobileCLIP2 Inference

Compute embeddings for book passages.

MNIST Training

Train a neural network on handwritten digits in-browser.

Principal Component Analysis

Explore components of a 3D point cloud.

Benchmarks

Compare jax-js kernels with other web ML libraries.

Resources

GitHub Repository

Check out the code and tutorial.

REPL

Try jax-js in this browser-based REPL.

API Reference

View the generated API documentation.

Sometime next week, NASA’s newest rover on Mars, Perseverance, will set a record for the most distance driven by any vehicle on another world.

The automobile-sized rover, which landed on Mars in February 2021, will traverse beyond 45.16 km (28.06 miles) across the Martian surface. In doing so it will break the previous distance record held by the long-lived Opportunity rover, which ceased communications with NASA in 2018.

So how did Perseverance reach this record-setting distance in just a third of the time?

A rover that drives itself

“The real enabling technology has been its auto navigation system,” said Steven Lee, the project manager for the Perseverance rover at NASA’s Jet Propulsion Laboratory, in an interview.

Much like self-driving cars on Earth, Perseverance has sophisticated onboard cameras that image the surrounding terrain, and these images are then processed algorithmically by an onboard computer to calculate the safest route. Terrestrial vehicles have some advantages of course, like clearly defined maps, street signs, lanes, and more. Additionally there are plenty of “road” hazards on Mars, from large boulders to sandy slopes. But at least Perseverance does not have to contend with other traffic and bad drivers.

The Curiosity rover, largely a twin of Perseverance that launched nine years earlier, had similar imaging capability and algorithms. But its onboard computer was a generation older, and some of its chipset dated back to the 1990s, Lee said. As a result, only about 10 percent of Curiosity’s driving is autonomous because its processing capabilities are too slow. In its decade and a half on Mars, Curiosity has driven 38.6 km.

By contrast, about 90 percent of the distance driven by Perseverance has been autonomous thanks to its (slightly) more modern Vision Compute Element. This allows the vehicle to perform all of its sensing and computation while its wheels are turning. Not that the vehicle is going super fast, as Perseverance’s maximum wheel speed is about 150 meters per hour.

Still, because Perseverance has not had to spend much time stopped to wait for navigation commands from drivers on Earth, the vehicle has been able to maximize the amount of scientific return.

A science superstar

“It is very enabling for the science,” said Vivian Sun, the mission’s deputy project scientist. “Not to sell the rover’s other advanced capabilities short, but the driving in particular has allowed us to have a larger scope than previous missions.”

Perseverance’s self-driving ability has nicely complemented its mission. Curiosity landed in Gale Crater and has slowly been making its way up Mount Sharp. It moves less and spends more time systematically taking detailed measurements as it gains altitude. Perseverance, however, landed in Jezero Crater, where its science objectives are more spread out. It has been able to cruise from one location to another, often surprising scientists by turning up at a new site ahead of the planned timeline.

And that’s good, because there is a lot of work to do. In Jezero Crater, the rover is studying some of the most ancient rocks in the Solar System, older than any on Earth, dating as far back as about 4 billion years ago. At the time, the planet was in the later stages of the “heavy bombardment” era when rocks were still whizzing around the inner planets in great numbers. But things were starting to settle down.

“It’s the first time we’ve been able to investigate this terrain in situ, and that’s been very exciting,” Sun said.

During this era, large lakes and possibly even oceans are thought to have existed on Mars. Perseverance is exploring this ancient terrain to better understand what geological and environmental conditions might have existed at the time, and just how conducive the planet might have been to life. Scientists believe the planet might have looked something like the Mojave Desert on Earth, with water flowing through it, but the debate rages on. With Perseverance, there is a lot of data to base it upon.

Driving on, and on, and on

Curiosity is still going strong on Mars after nearly 15 years, and Perseverance operators say the newer rover is doing great as well. After a few years on Mars, Curiosity operators noted significant wear and tear on the vehicle’s wheels. So for Perseverance, the wheels were redesigned, and there are no signs of appreciable wear and tear, Lee said.

The only minor concern at this point is the actuators in the wheels. They were initially life-tested for 20 km of driving, but NASA is in the midst of certifying them to at least 100 km, and possibly longer. Perseverance operates on RTG power and has no propellants, consumables, or lubricants on board.

For this reason, Lee said, the vehicle could keep driving itself across Mars for many years to come.

In Devtools must be open source, David Crawshaw makes the case that, because of coding agents, we’re now in an era where devtools will be personalized by individual users. Specifically, agents’ ability to jump into new codebases and build whatever we want means we’ll be hacking on the source of the devtools we use day to day (even those without extension APIs) adding features and automatically rebasing our patches across releases.

The argument is seductive, especially to a reader who thinks of themselves as a maker or tinkerer: after all, the idea that you can hyper-tune everything you use sounds like a utopia; it means things can work exactly how you want them to.

But I’d argue that Crawshaw underappreciates the ongoing cost when he writes:

“Both the upfront fixed costs and the ongoing costs of personalizing software have disappeared.”

While AI has made the upfront cost of changing software a lot lower, properly personalizing software still requires your attention. And attention in the AI age is scarcer than ever.

Having maintained an open-source devtool designed to be modified and forked for nine years now, I can say that most users don’t want to customize their devtools. They want someone else to make the tool reliable and coherent, so they can focus on the problems they opened it to solve. They reach for source modification only as a last resort, when a change is critical to their workflow and no other route works.

This is not to say that this sort of personalization won’t become more common: I absolutely think it will. I just think it will take the form of strong core systems with well-defined boundaries and extension points.

Personalization still needs a person

As a thought experiment, imagine an open-source diff viewer with no extension API. You find most diffs noisy, so you ask an agent to add a “focus mode” that collapses imports, generated files, and other changes you consider mechanical. It works well and becomes part of your normal workflow.

At first, life is good: everything works, and you’ve solved your problem. Then upstream releases a new version that refactors the code you changed. As Crawshaw suggests, you’re clever, so you’ve set up a bot to automatically rebase your changes onto each update. It resolves any merge conflicts and moves your code to the right place.

But now suppose a few months pass and upstream makes a more substantial change: it adds syntax-aware move detection. If a function moves between files, the viewer now shows it as a move instead of one large deletion and addition. The agent muddles through, rebases your focus-mode patch, and gets everything compiling without any merge conflicts.

But now what should focus mode do if the function has mostly moved but also contains a few meaningful edits? Does it hide the whole block as a mechanical move? Does it show only the edited lines without any surrounding context? Or does it show the whole function?

There isn’t an obviously correct answer; it depends on what you want to see in the diff. So what, are you going to interrupt your day to make this decision?

There’s a central paradox here: if you’re okay with “let the agent decide”, then you’ve delegated your authority to the agent. For small choices, that may be perfectly adequate. But if you want the tool to work exactly how you want, you need to inspect and direct those choices. Do you really want to have opinions about the design of a devtool you use forever?

The key is attention. Any one personalized tool might be unlikely to fail on a given day, but if you do this to every devtool you use, you multiply the number of tools that can unexpectedly demand your attention. Worse, those failures are unpredictable: a tool might work for months and then break at the exact moment you urgently need it. Most engineers want to use devtools to accomplish a task; they don’t want their attention diverted to designing and repairing them.

Shared tools need a shared reality

All of the above applies to small teams as well. You can share the attention cost, but at the end of the day, the team still has to ask, “How much time do we want to spend on tools versus doing the actual work we’re meant to be doing?”

I also want to look beyond Crawshaw’s post and consider how this would work in larger companies: what happens when many teams independently personalize the same shared devtool?

I’ve seen this firsthand: another big tech company makes extensive use of Perfetto, and has hit this exact problem. Different teams in that company decided to fork Perfetto and add ad hoc changes for their local needs. Now one of the engineers there is fighting to consolidate them because of how painful it is when every team means something different by “Perfetto”.

Imagine the same pattern with a company-wide bug tracker. Do you want every team to use a version with subtly different meanings for status, priority, assignment, and resolution? What happens when a bug moves between teams? Different layouts and personal filters are harmless; the problem begins when personalization changes the shared semantics or workflow.

When a devtool mediates work between people, it also forms part of their common language. Teaching, auditing, reproducing investigations, and verifying that people are talking about the same thing all depend on a shared baseline.

Upstream gets more malleable too

We should also not compare pre-AI upstream development with post-AI forks. Maintainers can use the same agents to investigate reports, brainstorm ideas, and prototype new features. I can certainly attest to how useful AI has been for both implementing small feature requests from users and prototyping larger ones to determine feasibility.

In my opinion, upstream maintainers can, and should, spend the time saved on implementation making their tools more adaptable: implementing broadly useful features, adding configuration knobs where they make sense, and creating extension points for recurring needs. AI lowers the cost of doing all of this, including deciding where customization makes sense, adding more elaborate tests on creative uses of your tools and verifying backwards compatibility as these interfaces evolve.

Upstream has a natural advantage here: any work done there benefits everyone, while a change to your personal fork benefits only you. By relying on upstream, the attention required to build good software shifts from people who don’t want to spend it to maintainers who have chosen to care.

The building-block economy

In my opinion, there’s an alternative view that is much more likely to come true, one described well in Mitchell Hashimoto’s article on the building-block economy.

Concretely, it accepts the same premise: agents can write lots of code and build niche applications, tools, integrations, forks, and so on. But instead of assuming that forks will become the norm, Hashimoto argues that high-quality, well-documented building blocks will power this world.

I tend to agree: agents are very good at composing high-quality components. If maintainers provide those components alongside a focused application, makers can build specialized artifacts on top while accepting the costs. This model also creates an easy feedback loop for ideas to flow upstream because the product was designed to be extended.

I see signs that the world is already heading in this direction. For example, bb is a very interesting agentic IDE that I’ve been playing around with recently. It has a very nice experience that lets users add substantial new product surfaces through self-modification. But the key is that those features are plugins built around a maintained core and extension system, not changes made by forking the project directly.

Wrapping up

I care deeply about both the world of devtools and open source, so this is something I feel very passionate about. Having been immersed in this world for almost a decade now, I think the future of well-built tools with thoughtful design and well-designed extension points is bright.

Sure, there will always be folks who want to fork and make ad hoc changes. These are the same people who already maintain custom builds of their window manager or terminal emulator, carrying a stack of patches to get everything exactly how they want it. For them, the tinkering is part of the enjoyment and craft.

But I think most users just want to get their work done with devtools, and we owe it to them to give them a strong, dependable experience instead of asking them to take on the burden of maintaining the product themselves.

1. While the title reflects the conclusion, IMO it’s not very reflective of most of the post, which is actually about personalization at the source level. If you’ve read my other posts, you’ll know I’m a staunch believer in open source so I’m of course in full agreement with the title and conclusion.

2. I’m a co-founding engineer on Perfetto.

3. For example, the upstream project might reject a feature request because the change conflicts with its product direction, or the tool might not expose an extension point capable of supporting it. In those cases, modifying the source may be the only practical option.

4. Observant readers may note that this is not so dissimilar to Crawshaw’s own example with Meat :).

5. This is a very informal application of Lusser’s law, which says that the reliability of a system composed of independent components in series is the product of the reliability of those components.

6. The suckless ecosystem is an existing example of this approach. dwm and st are commonly customized by arbitrary patches to their sources.

Amazon Web Services is cracking down on internal use of EC2 instances among its engineers. In May, the company reportedly met with engineers and told them to reduce CPU waste to ensure AWS has enough CPU capacity to meet customer demand, The Information reports. The message comes as demand for CPUs in the data center has hit a fever pitch, with the traditional eight-to-one or four-to-one ratio of GPUs to CPUs moving closer to parity.

EC2 instances make up a large chunk of the modern internet, and they're used in private deployments, as well. Traditionally, AWS engineers have been able to spin up their own instances for development, leveraging the relatively low CPU utilization required for web infrastructure to use more virtual machines. Now, engineers say they're waiting days to get access when they previously could get access within hours. One engineer told The Information that they've never had to wait this long for an instance, even after several years of working at Amazon.

Amazon deploys several different types of CPUs in EC2 instances, including AMD and Intel options and its relatively new Graviton5 chip. Graviton5 is Amazon's most powerful CPU to date, and it uses an Arm-based architecture along the lines of Nvidia's Vera CPU and Arm's own AGI.

The increased demand for CPU comes on the back of AI agents, a new paradigm in productivity that even companies as large as Amazon are struggling to reckon with. Last month, for instance, a coding agent blew through $1.8 million in token costs at Amazon, surpassing a development budget by 860%.

Much of the AI infrastructure currently in place is designed around inference, a workload that's accelerated by GPUs. With the four-to-one ratio, the CPU served as a way to keep the GPUs fed, and nothing more. However, agentic workloads are much more complex. They often involve tool calls that run on the CPU, as well as more complex orchestration of inference on GPUs. This is what has brought CPUs center stage in the agentic era. Intel, AMD, and others have echoed what we've heard from memory and storage companies over the past several months: the demand is so high for CPUs that most companies will take whatever they can get.

The major players are capitalizing on that demand. AMD just recently unveiled its portfolio of Zen 6 'Venice' CPUs for the data center, marking the first time AMD has launched a new architecture in the data center before the client market in decades. Nvidia has also pivoted its messaging away from accelerators and toward its new Vera CPU, vying to stake its claim in an expanding market of agentic AI infrastructure.

Although Amazon is wrestling with CPU capacity across its internal engineers and external customers, The Information reports that shortages are largely a problem for spot instances. A consultant told the outlet that contracted capacity hasn't experienced any shortages.

Following publication, an Amazon Web Services spokesperson reached out with the following statement:

"Demand for AWS services, including EC2, is incredibly strong and growing. Even with this heavy demand, we continue to satisfy the overwhelming majority of compute needs for both our internal and external customers. We work closely with internal teams to meet their compute needs while ensuring they use EC2 resources as efficiently as possible, such as reclaiming idle instances, right-sizing, and scaling up and down as needs change – just as we’ve always done. These efficiencies help manage capacity for internal and external customers alike, and any suggestions that these long-standing efforts reflect new capacity constraints is simply wrong.

This premise is sensationalized. Frugality is in our DNA since Day 1. We have always encouraged our teams to operate efficiently. We also share best practices for how customers can optimize resources to external customers. This isn’t a new directive, and encouraging efficient use of resources isn’t unique to Amazon."

We pressed Amazon on if engineers had been given deadlines to reduce their compute usage, as The Information originally reported. An AWS spokesperson responded: "This narrative on EC2 is inaccurate. As part of our normal business operations, and backed by our leadership principle of frugality, we are always driving efficiency across our resources to ensure teams are optimizing capacity."

The Problem that Revision Prompting solves

We prompt LLMs in two ways:

Ad-hoc prompting

Prompts LLMs manually, with a custom instruction per call. Examples:

• Asking a coding agent to implement a new feature.
• Asking a chatbot to draft an email.

Industrial prompting

Prompts LLMs as part of an automated process, with the same instruction across calls. Examples:

• Extracting structured information from invoices as part of an accounting pipeline.
• Translating documentation pages into other languages as part of a release process.

Industrial prompting typically processes some Input data with an Instruction to produce some Output. Whenever the Input gets updated, industrial prompting naively re-runs the Instruction on the UpdatedInput to produce the UpdatedOutput. This approach has two downsides:

Lack of consistency

LLMs are non-deterministic, so the UpdatedOutput differs from the original Output beyond what the UpdatedInput necessitates.

Full processing time and token costs

Although only parts of the input have changed, we produce the UpdatedOutput in full. This is as expensive as the production of the original Output.

Revision prompting resolves both downsides of naive re-runs by operating on the input and output revisions instead of the full input and output.

How Revision Prompting works

Assume you have processed some Input with an Instruction to produce some Output by prompting an LLM with Instruction: Input.

Now, Input has been updated, and you also want to process the UpdatedInput. Revision Prompting processes the UpdatedInput by constructing the RevisionPrompt as:

Instruction: Input produced Output. The input got updated as follows: diff(Input, UpdatedInput). Please produce a patch to update the output.

The LLM responds to the RevisionPrompt with the OutputPatch that we apply to the Output to obtain the UpdatedOutput.

Example

You translate the product page of an e-bike to German with the prompt:

Instruction: Translate to German: Input The Vela 3 e-bike has a range of 80 km. Its battery recharges in three hours. The frame is made from recycled aluminium. Every Vela 3 includes a two-year warranty.

and the LLM produces:

Output: Das E-Bike Vela 3 hat eine Reichweite von 80 km. Sein Akku lädt in drei Stunden auf. Der Rahmen besteht aus recyceltem Aluminium. Jedes Vela 3 hat zwei Jahre Garantie.

Later, a battery upgrade increases the range from 80 km to 100 km. Instead of re-translating the whole page, you prompt:

Instruction: Translate to German: Input The Vela 3 e-bike has a range of 80 km. Its battery recharges in three hours. The frame is made from recycled aluminium. Every Vela 3 includes a two-year warranty. produced Output: Das E-Bike Vela 3 hat eine Reichweite von 80 km. Sein Akku lädt in drei Stunden auf. Der Rahmen besteht aus recyceltem Aluminium. Jedes Vela 3 hat zwei Jahre Garantie. The input got updated as follows: diff(Input, UpdatedInput) - The Vela 3 e-bike has a range of 80 km. + The Vela 3 e-bike has a range of 100 km. Please produce a patch to update the output.

The LLM responds with:

OutputPatch: - Das E-Bike Vela 3 hat eine Reichweite von 80 km. + Das E-Bike Vela 3 hat eine Reichweite von 100 km.

Applying the OutputPatch to the original Output produces the updated translation. The OutputPatch contains only two lines of text instead of a full re-translation. Unchanged content stays consistent with the original translation.

Why Revision Prompting works

Consistency

By supplying the LLM with the input revision diff(Input, UpdatedInput), we ensure that the OutputPatch is limited to what the input changes necessitate. Everything not touched by the OutputPatch remains identical to the original Output. Therefore, the UpdatedOutput is consistent with the original Output.

Time & cost savings

Revision Prompting feeds the original Output back in as part of the prompt, so the LLM only generates the short OutputPatch. Most tokens thereby move from the output to the input. Since processing time scales roughly with the length of the output, this eliminates most of the processing time. It also converts most of the output token cost into much cheaper input token cost. If the re-run happens within a couple of minutes of the original run, prompt caching reduces part of the input token cost as well.

Revision Prompting in practice

Revision Formats

The ideal formats for encoding diff(Input, UpdatedInput) and the OutputPatch depend on the Instruction. The POSIX diff utility is a useful generic format. For JSON outputs, the JSON Patch format works well.

Expected Savings

The time & cost reduction scales with the size of the input changes and the sensitivity of the output to changes in the input. In our own industrial prompts, Revision Prompting reduces time by ~80%, and costs by ~65%.

Why you might want to build your WebApp in Canvas instead of HTML

I’m always curious how Google, Microsoft and Co. build their web apps - given that they need to work well on any computer, from a top-shelf speed machine to a potato with wires.

Of course, there are many answers to this question - but one that I find particularly interesting is their use of the Canvas element for functionality that’s usually implemented in HTML.

The document in Google Docs is a Canvas. So is the sheet in Google Sheets or in the web version of Excel. Unsurprisingly, Canva is a Canvas - but so is the board in Miro. Our own scheduling interface in Hivekit is also a Canvas. Hivekit's scheduler can be zoomed (changes displayed timespan), panned in x and y direction and has lots of interactive aspects that needed managing.

I helped build it, and in this post, I want to explain why we chose Canvas over DOM elements, what we learned along the way, when I think that Canvas is or isn’t a good choice for web apps, and why I think Canvas is used by all these big companies for performance-critical apps.

What was Canvas again?

Canvas has been around for more than 20 years now. It provides a blank space within an HTML document that can be drawn on. To do that, you use a JavaScript API with higher-level methods like fillRect() to fill a rectangle and lower-level methods like getImageData() to access the raw RGBA values of your pixels.

Whatever approach you take, you end up with what’s basically a static image. For Web Developers, that feels a bit odd. After all, they’re used to a complex Document Object Model, HTML parsed into element trees, click handlers and event bubbling, dynamic rendering and reflows - all managed for you and perfectly tuned for the user’s device.

With Canvas, all of this is gone now.

So - why on earth would you use Canvas?

There are some things only Canvas can do. Pixel image manipulation is the obvious one. But why would you choose Canvas to build a web app that could also be built in HTML?

A few reasons:

• Speed: Parsing HTML, creating a DOM, applying CSS styles, and handling the myriad of features related to user interaction all take time. If your web app becomes complex, the browser can end up doing some seriously heavy lifting. A “dumb” drawing API means less work. Less work means more speed.
• Control: If you’re building a whiteboarding app with an infinite workspace, a grid with countless rows, or a planning tool with a zoomable workspace, you need to take control of rendering anyway. You can (kind of) do that in HTML - for example, through “virtual scrolling,” where you swap the content of grid rows instead of using the browser’s native scrolling, or by cleverly adding and removing elements from the DOM as the user zooms and pans. But at that point, you might be better off owning the rendering altogether.
• Consistency: With canvas, you output exactly what you specify across devices. This used to be more of an issue when browser implementations differed, but even now, responsive designs, CSS gradients, and transition effects can look quite different across operating systems and screens. With canvas, you get the same result - for better or worse.
• Portability: Canvas is used to render output from other visual frameworks. Flutter Web and certain WebAssembly implementations output their screen buffers to canvas. But this also works the other way around: tools such as Ejecta and NativeScript wrap C++ drawing APIs in Canvas calls that let you output your graphics on other systems.

And why wouldn’t you use Canvas?

There are far more reasons not to use Canvas than to use it. And for most web apps, you’re much better off with good old DOM elements. Take the humble <input type="text"> element, for example. With it, you get crispy rendering at any resolution, support for tab, focus, selection, mouse interactions and arrow key navigation, internationalization for right-to-left text and Asian compound characters, accessibility for screen readers… the list goes on.

Browsers give you a lot of functionality out of the box and there are plenty of great frameworks that make it easy to use, scale and work on in an organized and standardized way across teams.

When is Canvas the better choice?

There’s a certain set of use cases where Canvas can be the better choice.

• When you have a lot of absolutely positioned elements, irregular shapes or complex render order/z-index requirements. Whether you’re building a vision board app or a 2D platformer, if your app is outside the usual HTML layout flow, Canvas might make your life easier.
• When you only need to render specific things. If your app can be zoomed, panned, uses camera transforms, clipping, tiling, level-of-detail rendering, or virtualisation, Canvas makes it easy to make sure you only render what you need to.
• If your application already has a strong internal model. If your app already has a strong concept of state, geometry, focus and interaction and all you need is a way to visualize it, Canvas makes it easier than HTML.

But if you do decide on a Canvas implementation, here are some of the key things you want to look out for:

• Manage when to Render: The pattern that worked best for us is to have one central renderer that calls other classes that render specific aspects, such as backgroundRenderer, rowRenderer, taskRenderer. Each of the other classes can call scheduleRender on the renderer. This schedules a single render pass for the next animation frame. Note that we clear the entire Canvas for every frame and render everything from scratch. This is wasteful and more sophisticated implementations might only clear and rerender specific regions. But - doing that also adds complexity - and rerendering the entire Canvas for every frame really never caused issues for us.

class Renderer{
    constructor(canvas){
        this.renderScheduled = false;
        this.canvas = canvas;
        this.context = canvas.getContext('2d');
        this.backgroundRenderer = new BackgroundRenderer(this);
        this.rowRenderer = new RowRenderer(this);
    }

    scheduleRender(){
        if(this.renderScheduled) return;
        this.renderScheduled = true;
        requestAnimationFrame(this.render.bind(this));
    }

    render() {
        this.renderScheduled = false;
        this.context.clearRect(0, 0, this.canvas.width, this.canvas.height);

        // Render the individual layers in order
        this.backgroundRenderer.render(this.context);
        this.rowRenderer.render(this.context);
    }
}

• Layer Multiple Canvas Elements: For our planning interface, the fundamental plan stays fairly static while the user interacts with the mouse. But there are a lot of highlight and hover effects. For these, we utilize a second Canvas element with the same dimensions as the original Canvas. This InteractionRenderer refreshes much more frequently than the actual Canvas, but only renders a few bounding frames, which is much more lightweight.
• Keep styles separate. Keeping CSS separate from HTML makes your life easier - so why not do this with Canvas? Keep a separate file for styles, e.g.

gapDiagonalLineSpacing: 10,
textColor: '#ecf0f5', 
textColorSecondary: '#4d6585',
fontStyle: "13px 'Lato', sans-serif",
fontStyleBold: "bold 13px 'Lato', sans-serif"
...

• Manage device resolution and pixel density To get crisp render results, make sure your Canvas element is scaled to the device’s pixel ratio. Then, counterintuitively, set the context’s scale to offset the element’s scale. This way, you get crisp render output without your code having to be conscious of scale and pixel density all the time.

getPixelScale() {
    return Math.max(window.devicePixelRatio, 1);
}
scaleCanvas(canvas, ctx) {
    const pixelScale = this.getPixelScale();
    canvas.width = canvas.offsetWidth * pixelScale;
    canvas.height = canvas.offsetHeight * pixelScale;
    ctx.scale(pixelScale, pixelScale);
}

• Have central functions that translate domain coordinates to pixels: If you are building an infinite-workspace-type app, elements on this workspace likely have X and Y coordinates. If you are building a spreadsheet, you’ll have row and column indices. These will be different from the actual pixel coordinates, based on the user’s resolution, zoom and pan position, and a host of other factors. You’ll make your life a lot easier by having simple functions like getXForColumn(colIndex) or getPositionForDomainCoordinates(x,y).
• Maintain a simple box model: As the user hovers over or clicks elements, you’ll want to know what they interacted with. To do this fast, build up an index of bounding boxes in screen space beforehand. For each, store its x1, x2, y1, and y2 coordinates, along with its z-index and some identifier that tells your implementation what element it belongs to. If you manage a lot of bounding boxes, you might also want to create simple indices based on x and y coordinates for faster lookups or even consider an R-Tree for spatial indexing.
• Manage Event Handler Life Cycles Have a global listener for mouse and keyboard events and a simple way to register and deregister callbacks for specific events and elements.

So, should you use Canvas?

Canvas isn’t a faster replacement for HTML. It’s a lower-level rendering tool that gives you more control—and makes you responsible for much more of the browser’s work.

For most web apps, the DOM remains the better choice. It gives you accessibility, responsive layouts, text selection, input handling, and countless other features for free. But if the heart of your application is a large, spatial workspace with complex positioning, zooming, panning, or thousands of visual elements, Canvas may be a better fit.

That was the case for us. Owning the rendering pipeline made the planning interface easier to reason about and gave us predictable performance across a wide range of devices. It also meant building our own systems for interaction, hit testing, scaling, and rendering—work that shouldn’t be underestimated.

So don’t choose Canvas simply because it sounds fast. Choose it when your interface no longer behaves like a document and starts behaving more like a scene.

Today we are launching a developer preview of WebMCP on Cloudflare. Switch it on and browser agents can start working with your site, with no code and nothing changed at your origin. Cloudflare adds a small bridge to your pages, which registers a set of tools for a visitor’s agent to use.

The web was built on the assumption that there is a person on the other end: someone to read the page, click buttons, and fill in the forms. But now more and more visits come from AI agents instead, to an Internet made for humans. The usual approach has been crawlers, which copy content back to a server and, too often, give the original site none of the traffic and little of the credit. There is a better way, and it does not involve scraping.

WebMCP is a new browser standard, shipping experimentally in Chrome 146, that shows up in the page as document.modelContext. A site can choose to expose a set of tools for agents running in the browser, meaning agents no longer have to guess their way through a page built for humans. This enables agents to have a different browsing experience from the user and use tokens on tasks, not navigation. The catch: the site has to implement it.

Cloudflare has been building both ends of this. BrowserRun, our remote browser, already added WebMCP support, so an agent can discover and call the tools a site exposes. Cloudflare Radar will soon offer WebMCP tools of its own. This preview is about the other side: a way to give any site on Cloudflare those tools with a single switch, and no code.

A developer preview of WebMCP on Cloudflare

Implementing WebMCP by hand is a small project: design the tools to expose, wire them into your interface, and keep them working as the standard evolves. We wanted it to be simpler than that: just toggle a setting to enable tools.

These tools come in packs — groups of related tools that can be turned on together. These are built to grow: as we add packs, a site can opt in to more just by turning them on, no redeploy needed. We are including two tool packs in this developer preview, which both run entirely in the browser.

What this does and how it works

Our implementation comprises two parts, both in front of your origin. Neither touches your site’s code and both work the same way whether your site is static or a single-page app.

First, an injection at the edge. When your site has WebMCP switched on in your Cloudflare Dashboard, we use HTMLRewriter to add one line to each HTML response: a small reference to a bridge script that we also serve. Both the tag and script it loads come from the edge, same origin, so nothing else about the page changes:

<!-- Cloudflare injects this at the edge. Same origin, and your HTML is otherwise untouched. -->
<script type="module"
        src="/.webmcp/bridge.js"
        data-packs="c2pa,mcp-server-client"
        data-mcp-url="/mcp"></script>

The data-packs attribute is the list of packs to activate. If you have an existing Model Context Protocol (MCP) server, the data-mcp-url points at your own MCP server (defaulting to the same origin /mcp).

Second, the bridge. This runs in the page and finds the WebMCP surface. If the browser does not have one, it returns and does nothing, so the page behaves exactly as before.

From there, the bridge composes the packs named in data-packs into one tool list and registers each with .registerTool. A pack is just a set of MCP tool descriptors and their handlers. Static packs, such as Content Credentials, declare their tools up front. A dynamic pack, such as the Site MCP Server pack, discovers its tools at boot before registering anything.

In this preview, every tool runs entirely in the visitor’s browser. There is no round trip to a server of ours. The Content Credentials pack fetches an image and parses its first few kilobytes of content provenance metadata locally. The Site MCP Server pack talks straight to your MCP server endpoint from the page, on the visitor's origin and with their existing session.

The bridge code is served by a worker running at the edge. This leaves us room to grow the offering — future packs will be able to call this worker for tasks the page cannot do alone, like summarizing a sitemap with Workers AI or querying an AI Search index.

To an agent, all of these are ordinary MCP tools. We use Model Context Protocol’s own Tool and CallToolResult types, so an agent that already talks to MCP servers can drive a page with nothing special added. The browser is just another place MCP runs. The example below shows how the bridge turns one of your own MCP tools into a tool the visitor’s agent can call.

// For each tool the site's own MCP server advertises (via tools/list),
// registering a proxy whose execute() calls the site back on the
// visitor's origin, with their session.
document.modelContext.registerTool({
  name: tool.name,                 // e.g. "search_products"
  description: tool.description,
  inputSchema: tool.inputSchema,   // taken straight from tools/list
  execute: async (args) => {
    const res = await fetch(mcpUrl, {   // same-origin /mcp
      method: "POST",
      credentials: "same-origin",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0", id: 1, method: "tools/call",
        params: { name: tool.name, arguments: args },
      }),
    });
    const { result } = await res.json();
    return result;   // an MCP CallToolResult, passed straight through
  },
});

Checking out content metadata

We are also developing packs to read different types of metadata. For example, credentials for participants of the C2PA program can be retrieved using the Content Credentials pack. scan_images_c2pa sweeps every image and returns a short summary of each:

{
  "imageCount": 12,
  "scanned": 12,
  "withC2pa": 8,
  "results": [
    {
      "src": "https://example.com/hero.jpg",
      "hasC2pa": true,
      "format": "image/jpeg",
      "manifestCount": 1,
      "claimGenerator": "Adobe Firefly",
      "title": "sunrise over the bay",
      "signedBy": "Adobe Inc."
    },
    { "src": "https://example.com/logo.png", "hasC2pa": false, "format": "image/png" }
  ]
}

For a closer look, inspect_image_c2pa decodes one image’s full manifest: its edit history, the stated author, and the signing certificate. It is a plain TypeScript reader that touches only a few kilobytes of the metadata at the front of the image, not the image itself. For now, it reads and reports the credential, rather than cryptographically verifying it: every result carries signatureVerified: false, so an agent won’t mistake a decoded claim for a checked one.

Try it out

Get started with WebMCP by going to Agent Readiness > WebMCP in the Cloudflare Dashboard. Here you can toggle on WebMCP for a domain, and pick which packs to add: both Content Credentials and Site MCP Server are on by default, and more packs will show up here as we ship them. That's the whole setup. There's nothing to deploy and nothing to change at your origin, and the next HTML your site sends will include the bridge.

To confirm it’s live, ask your site for any HTML page and look for the line Cloudflare injected:

curl -s https://your-site.example | grep webmcp

You do not need your own agent to see the tools work. Point BrowserRun, Cloudflare’s remote browser, at your URL, and it will discover and call the tools your packs registered, exactly as a visitor’s agent would. That is the whole loop: BrowserRun gives agents a browser to act on, this preview gives your site the tools to be acted on, and they meet using the open standard. The tools behave in the same way whether the browser is on someone’s laptop or running headless in the cloud.

Why we built this

Our job is to help make the Internet better, and as the Internet changes we need to provide domain owners with tools that allow new visitors, AI agents, to interact without a full rebuild. It is one step towards a web that can still thrive when visitors are not always human.

This is a developer preview, and we want your feedback. Turn it on, try it against your own site, and tell us how it goes in the Cloudflare Developers Discord or on the Community forum.

TL;DR

We bundled an internal Azure Pipelines task extension into a single bundled JavaScript file using esbuild. The task package dropped from tens of megabytes and thousands of files to three files per task (script.js, task.json, and icon.png). The change took about 20 lines of build tooling. We measured the payoff across our production pipelines:

• Per-task download + extract on the agent: ~4.5 s to ~0.25 s (about 17x faster)
• Downloads taking longer than 10 seconds: down ~98%

Spending less time downloading and extracting tasks means we can make more efficient use of our build infrastructure. If you publish a node-based Azure DevOps task extension that ships a large node_modules folder or thousands of small files, you can almost certainly benefit from this same change!

Why task package size matters more than you think

Every time a pipeline job runs your task, the agent does the following during ‘Initialize job’, before your task code ever executes:

1. Downloads the task’s content zip
2. Extracts it to disk.

This happens on every job, on every agent, for every task in the job. On ephemeral hosted agents (which start from a clean VM), there is no cache to save you from this startup cost.

Our task had grown the way node-based tasks tend to: the compiled TypeScript plus a full node_modules tree that our build copied into each task folder. The result, quoting our own build script:

// package huge (tens of MB and thousands of files per task).

Thousands of small files is the problem here. Task extensions are packaged in a vsix file which is really just a zip file that follows a specific packaging convention. Zipping and unzipping a package with thousands of files is costly. In this case it’s also completely unnecessary.

Bundling and pruning aren’t just for the browser

Bundlers and tree-shaking carry a reputation as front-end tools. We reach for them to ship less JavaScript to a browser over a slow network, and it’s easy to assume that a server-side or CLI-style program, where “it all runs on one machine anyway,” has nothing to gain.

A pipeline task is a distributable artifact that each build agent downloads and unpacks from scratch on every run, often thousands of times a day across many agents. That is the problem bundling helps to solve. Front-end developers are familiar with optimizing assets to minimize the cost of transferring and processing files. The same cost applies here; the difference is the build agents pay the cost instead of browsers.

The same logic applies to anything you distribute and load repeatedly: pipeline tasks, npm-published CLIs, serverless function packages, even container image layers. If your artifact drags an entire node_modules tree along for the ride, tree-shaking away the code you never call and collapsing what’s left into one file pays off wherever it lands. Treat your task like something you ship, not like a folder you develop in.

The fix: bundle everything into one file

We added a single esbuild build step that bundles each task’s entry point, together with the shared Common code and all of its npm dependencies, into one bundled, tree-shaken script.js per task. The task’s VSIX then only needs to ship, per task:

Tasks/{taskname}/
  script.js     (the entire bundled task)
  task.json     (the task manifest)
  icon.png

You no longer ship hundreds of transitive dependency files in multiple node_modules folders. You simply point task.json‘s execution target field at script.js, and that’s it.

{
  //...
    "execution": {
        "Node20_1": {
            "target": "script.js",
            "workingDirectory": "$(currentDirectory)"
        }
    }
}

The essence of the build script:

import * as esbuild from "esbuild";

await esbuild.build({
  entryPoints: ["Tasks/MyTask/index.ts"], // one per task
  outfile:     "Tasks/MyTask/script.js",
  bundle:      true,
  treeShaking: true,
  platform:    "node",
  target:      "node20",  // Target the lowest Node handler your task.json declares, or emit one bundle per handler
  format: "cjs"
});

Two gotchas

We hit two subtle issues that other publishers might hit too:

1. Deduplicate stateful shared modules. If you install the same package (for example azure-pipelines-task-lib) in both a shared Common/node_modules and each task’s own node_modules, esbuild can bundle two separate copies. For libraries that hold module-level state, that state splits across the copies and silently disappears (for example with azure-pipelines-task-lib, the internal \_vault that holds secrets). We wrote a small esbuild resolver plugin that forces bare-specifier imports to resolve to a single, canonical node_modules.
2. Fix sibling-asset paths if your extension contains multiple tasks and they share common code. For example:

Common
  moduleA.js
  moduleB.js
Task1
   script.js
   task.json
   distribution.json (custom file needed by the task)
Task2
  script.js
  task.json
Task3

Bundling collapses the Tasks/{taskname}/Common/ subfolder, so the emitted script.js now lives one level up from where the source did. Update any runtime reads of sibling files (task.json, distribution.json) that use __dirname to drop the now-incorrect ../ prefix.

These changes took a couple iterations to fix, but knowing about them up front might save you a confusing debugging session.

How we measured the impact

1. Task file transfer time measures how long the Azure DevOps service spends streaming each task’s zip to the agent. Across all downloads, the average dropped from ~1.35 s to ~0.23 s, and downloads taking more than 10 seconds (slow network) fell by ~98%. Here we already saw a big improvement.
2. Agent-side download and package extraction time. This is the number that matters to customers because it means more efficient use of build agent compute.

Because this task runs across a huge number of pipelines every day, the small per-job saving compounds dramatically. Overall, we’re making much more efficient use of our build agent infrastructure which means we can run more builds on the same overall CPU quota.

As a pipeline author, this change delivers real savings to your customers while requiring zero changes on the customer’s side.

Some Caveats

There are some potential drawbacks here that are worth mentioning.

• Bundled files might make debugging more challenging since your stack traces won’t point you to the original source locations. (You can output sourcemaps to help with this.)
• esbuild and other static bundlers can break dynamic requires. Make sure you thoroughly test your tasks after bundling. (You may need to use the external option for some dependencies)
• Bundling is a tradeoff that can result in higher memory usage. With a single large, bundled JS file, the V8 engine now needs to load the entire file into memory at startup instead of loading smaller files as they are needed. If this is a concern, you could experiment with https://esbuild.github.io/api/#splitting.

Should you do this? (A checklist for task publishers)

If you publish a Node-based Azure Pipelines task, you can very likely get the same benefit:

• Check your package. Does your published task ship a node_modules folder with hundreds or thousands of files? (Look at the .vsix contents by renaming it to .zip and extracting the contents)
• Add a bundler (esbuild, ncc, or webpack) that emits a single script.js per task with bundle and treeShaking enabled, targeting the Node version your task declares. (You could enabling minify too but that makes debugging more challenging as your stack traces will be unreadable unless you also output sourcemaps)
• Point task.json at the bundled entry file.
• Watch for duplicated stateful modules (especially azure-pipelines-task-lib) and deduplicate to a single instance.
• Fix any __dirname-relative asset reads if bundling changes your output’s folder depth.
• Verify the task still runs, then compare your Initialize job log timestamps before and after.

It’s a small, self-contained change, and as we found, the payoff scales with how often your task runs.

Ask your coding agent to draft a PR and test the results.

The Kubernetes control room—built in Rust, ready for engineers and AI agents.

srelens is an open-source, local-first Kubernetes desktop workspace for SREs, platform engineers, and DevOps engineers. Investigate, analyse, and take safe action across clusters from one application built with Tauri v2, React 19, and a pure-Rust core.

Why srelens?

Kubernetes troubleshooting often means moving between terminals, dashboards, YAML editors, logs, and cluster contexts. srelens brings that investigation loop into one local-first desktop workspace.

• One workspace from investigation to action — browse resources, inspect events and YAML, follow logs, use terminals, manage port forwards, and take cluster actions without constantly switching tools.
• Built for engineers and AI agents — supported backend capabilities are also available through the built-in MCP server.
• Local-first cluster access — srelens uses credentials from your local kubeconfig and connects directly to Kubernetes API servers, without routing cluster access through a srelens cloud service.
• Safe operations — destructive actions are identified and confirmation-gated.
• Open source — licensed under MIT, with public code, releases, issues, and roadmap on GitHub.

srelens uses the operating system WebView through Tauri v2 and a Rust backend built with kube-rs and tokio. It is independently developed and is not affiliated with Mirantis Lens or the Freelens project.

• Multi-cluster workspace — discover kubeconfig contexts, add or paste more files, give each context a name, logo, and colour, and switch clusters from the cluster hotbar. Contexts that share a name across files (e.g. default) are disambiguated so every cluster stays visible and reachable.
• Live Kubernetes resources — browse workloads, networking, storage, RBAC, admission, autoscaling, and custom resources with live watch updates, search, column pickers, namespace scoping, and bulk actions.
• Resource details and YAML — inspect manifests, events, relationships, and metrics, and edit schema-aware YAML with validation, dry-run diffs, and server-side apply.
• Logs — stream pod or workload logs with previous-instance (post-crash) logs, timestamps, tail and since-window controls, per-source colouring, container filtering, and buffer or all-container export.
• Terminals and shells — open pod exec sessions, a context-scoped local terminal, ephemeral debug containers for distroless pods, and privileged node shells.
• Port forwarding — create, inspect, copy, and stop forwards across every open cluster.
• Helm — list and inspect releases, and install, upgrade, roll back, or uninstall them with a values editor and rendered-diff preview.
• Toolbox — install and manage kubectl, krew, helm, and krew plugins, and diagnose a context's exec-auth tool requirements.
• Metrics — node and pod CPU and memory when metrics-server is available.
• Operational actions — scale workloads, restart rollouts, evict or delete pods, suspend or trigger CronJobs, and cordon or drain nodes, with confirmation gates for destructive actions.
• Command palette — keyboard-first navigation (Cmd/Ctrl-K) across views, contexts, and resources.
• Application logs — read srelens's own rotating log file from Settings to diagnose issues after they happen.
• MCP access — expose supported backend capabilities to MCP-capable clients over stdio or loopback HTTP.

Install

Download the latest beta for your platform from GitHub Releases.

Run as a web app (Docker): srelens can also run as a multi-user web server in a container. Users sign in with OIDC (or a local dev login for trials) and each gets a fully isolated environment built only from their own uploaded kubeconfigs. OIDC-protected clusters work with a browser-based, Headlamp-style sign-in — srelens runs the authorization-code + PKCE flow and injects the id_token itself, so no kubelogin/exec plugin is needed. Kubeconfigs and tokens are sealed at rest under a required SRELENS_MASTER_KEY that is never written to disk; decrypted files live only in tmpfs. Some desktop-only actions (host shell, raw helm repo/plugin) are gated off the shared surface — web users get RBAC-scoped in-pod exec terminals instead.

MCP server

srelens includes an MCP server generated from the same capability registry used by the desktop backend. Supported backend capabilities can therefore be used by MCP-capable clients without creating a separate cluster integration layer.

Open Settings → MCP to:

• run the MCP server over loopback HTTP, protected by a bearer token you can reveal, rotate, or revoke — rotating restarts the running server so the new token takes effect at once (dropping any in-flight request and invalidating configs that used the old value); revoking also stops the server;
• install the srelens CLI for stdio connections, which need no token — the client already holds your privileges by spawning the process;
• copy client configuration for supported MCP clients.

You can also start the server directly:

srelens --mcp-stdio
srelens --mcp-http 127.0.0.1:8765

Destructive tools prompt for confirmation in the app. Headless runs have no dialog to show, so they need "_confirm": true on the call and a process-level opt-in — --mcp-allow-destructive to change anything, or --mcp-allow-sensitive-reads to read Secrets. The two are independent, so reading a Secret never implies permission to drain a node, and neither flag alone authorizes anything without _confirm. There's no GUI toggle for stdio.

MCP access uses your locally authenticated cluster contexts. Review tool calls and use appropriate Kubernetes RBAC permissions, especially with critical clusters.

Quick start

Prerequisites

• Rust stable
• Node.js 22+
• pnpm 9+
• Tauri v2 system dependencies
• A reachable Kubernetes cluster for cluster-dependent workflows

Run locally

git clone https://github.com/srelens/srelens
cd srelens
pnpm install
pnpm dev

Useful commands

Architecture

React 19 + TypeScript
        │
        │ Tauri commands and events
        ▼
Tauri v2 desktop shell
        │
        ▼
Pure-Rust backend
├── capability registry
├── Kubernetes integration with kube-rs
├── live watches, logs, exec, and port forwarding
├── Helm and metrics
└── MCP server over stdio and loopback HTTP

Project status

srelens is currently in beta. It is ready for evaluation and everyday testing, but users should review release notes and take extra care when using it with critical clusters.

Breaking changes may still occur before a stable release. Feedback, bug reports, and reproducible troubleshooting details are welcome.

• Latest release
• All releases
• Issues and roadmap

Community

• r/srelens on Reddit — announcements, questions, and feedback
• Issues — bugs and feature requests
• Website

Prime Agent: A Self-Improving RLM Agent

Prime Agent is an open-source coding and research agent for general and long-running work. It is designed around two core abstractions:

• The Recursive Language Model (RLM) treats context as variables (prompt-as-a-variable) and tools like recursive subagents as function calls (programmatic tool /sub-agent calling) inside a persistent REPL.
• The Continual Harness stores supplemental prompts, memories, skill descriptions, and reusable subagent specifications as durable state that Prime Agent can refine through small, evidence-backed updates, local to the session by default.

Prime Agent combines a persistent Python control environment with durable harness state, so useful working context and reusable operating patterns can outlive a single chat window.

• Everything is programmatic: persistent IPython is the built-in model tool; file operations, shell commands, tool use, subagents, and context management happen through code.
• Subagents are built in: rlm(...) spawns real child agents for parallel or background work and returns their results programmatically.
• The harness can improve: /refine reviews the current trajectory and can apply small, evidence-backed updates to supplemental harness state. It never rewrites the immutable base system prompt, and recorded snapshots support rollback.
• Skills are executable: skills are importable Python packages, and the built-in skill creator can turn recurring workflows into project or personal skills.
• Sessions run in the background: daemon-backed agents keep running when the terminal disconnects and can be reattached later.
• Agents communicate directly: running agents can exchange messages and orchestrate one another without routing everything through the user.
• Long tasks keep moving: automatic compaction, persistent goals, heartbeats, schedules, autonomous mode, and retained subagents preserve progress across turns and terminal sessions.

Getting Started

Install the latest stable release on macOS or Linux:

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

The installer downloads a versioned release, verifies its SHA-256 checksum, installs the prime-agent command, and can prepare the IPython runtime used by the agent.

Start Prime Agent from the repository or directory you want it to work in:

cd /path/to/project
prime-agent

On first launch, run /login to choose a subscription or API-key provider. Prime Agent works in the current directory and can run commands and modify files there. Use a disposable clone, clean worktree, or another checkpoint you can inspect and restore.

Warning

Prime Agent executes model-generated Python and project commands with your user permissions. Its worker and kernel processes improve lifecycle isolation and recovery; they are not a security sandbox. Review changes and use trusted repositories, instructions, skills, and extensions only. Run untrusted code or instructions in an external sandbox or restricted environment.

Useful commands:

prime-agent agents                   # Browse running, idle, and saved sessions
prime-agent attach <agent>           # Reattach to a running session
prime-agent --resume <path|id>       # Resume a saved session
prime-agent status                   # Inspect background service state
prime-agent doctor [--fix]           # Inspect or repair background services
prime-agent update [--force]         # Update Prime Agent
prime-agent shutdown [--force]       # Stop every agent, worker, and background service

Built for Long-Running Work

Prime Agent is built for long-running work, especially for evaluations in research. These features are available in the TUI, and when run autonomously.

• Continual Harness: /refine can persist focused, reviewable lessons as supplemental prompts, memories, reusable skill descriptions, or subagent specifications, with recorded refinement history. It does not replace packaging and reviewing new executable skills.
• Direct agent-to-agent communication: running agents and retained subagents can discover one another, exchange messages, and steer active work.
• Daemon-backed continuity: active sessions, IPython state, schedules, and subagents keep running when the terminal detaches and can be reattached later.
• Heartbeats and schedules: /heartbeat, rlm_heartbeat, and prime-agent schedule can re-enter a session periodically or at a specific time.
• Persistent goals: /goal keeps an objective and its progress active across turns until it is completed, paused, or cleared.
• Bounded autonomous mode: /autonomous continues within configured turn, token, and time budgets and can run user-defined quality gates. A passed gate checks only what that gate verifies; reaching a limit does not imply task success.

Documentation

• Quickstart — install, authenticate, and run a first session
• Usage and CLI reference — commands, sessions, autonomous limits, and output modes
• Long-running and background agents — detach and reattach, goals, heartbeats, and schedules
• RLM programming model — persistent IPython, subagents, skills, and the trust model
• JSON mode and RPC mode — headless automation and integrations
• Skills — install and create reusable capabilities
• Provider setup — subscription and API-key providers
• Architecture overview — daemon, worker, kernel, and persistence boundaries
• Development — build and run from source

Acknowledgements

Our agent and TUI is built on top of pi. We thank the authors of pi for their valuable work.

License

Prime Agent is fully open source and released under the MIT License.

Julio Merino recently published A markdown-based test suite, about using Markdown itself as a lightweight test format.

That reminded me of a related workflow I’ve been using for a while with scrut: I put executable test plans directly in commit messages.

Why

• Makes the commit message’s test plan executable instead of purely descriptive.
  • Great for test-driven development, to ensure that my validation plan actually detects the underlying issue.
  • Great for knowledge sharing and onboarding teammates.
• Supports re-validating entire commit stacks via git test.
  • Often useful when rebasing on top of upstream changes.
  • On failure, it makes it quick and easy to bisect the first broken commit.
• Supports ad-hoc and differential testing, where there is no tested correct output, and we just want to document changes.

How

Inside my commit messages, I add scrut code blocks with test commands to run. Example:

fix(tests): fix tests on macOS with Git v2.37

...

Test Plan
---------

```scrut
$ cargo nextest run --workspace --no-fail-fast -- 'submodule'
```

I use a small script called git-test-message to read the commit message and run the scrut tests in the repository working tree:

For individual runs, I invoke it like this:

$ git test-message
🔎 Found 1 test document(s)

Result: 1 document(s) with 1 testcase(s): 1 succeeded, 0 failed and 0 skipped

With git test, I’ve configured it as my default test command, which runs it on the entire stack:

$ git config 'branchless.test.alias.default'
git test-message @

$ git test run
✓ Passed (cached): 624edd2 fix(tests): fix tests on macOS with Git v2.37
Ran command on 1 commit: git test-message @
1 passed, 0 failed, 0 skipped

Patterns

By default, scrut asserts that the command exits successfully and that stdout matches. For some tools, especially bazel, stdout is not interesting or is non-deterministic, so I often redirect it to stderr so that it’s not asserted, but is still logged on failure:

$ bazel test //foo >&2

For ad-hoc validation, when there’s no test case to cover a specific situation, I often pipe to grep or use scrut’s output expectations:

$ bazel run //foo | grep bar
some line with bar

For differential testing, I might record the new behavior, check out the previous commit, record the old behavior, and diff the two:

$ bazel run //foo >after && git checkout HEAD~ && bazel run //bar >before && diff before after
...diff output here...
[1]

The [1] means that exit code 1 is expected from diff.

Script

Here’s my git-test-message script:

#!/bin/bash
set -euo pipefail

mise exec 'cargo:scrut' -- scrut test \
  --work-directory="${PWD}" \
  --match-markdown='*' \
  <(git show --no-patch --format='%B' "${1:-HEAD}")

Notes:

• My script uses mise to just-in-time provision the scrut binary.
• By default, scrut works in a temporary directory. I oftentimes run commands that need th repo state, so I added --work-directory=${PWD}.
• By default, scrut only runs on Markdown input files. I specified --match-markdown='*' to match the process substitution filename (which usually ends up being a path like /dev/fd/63).
• scrut has features to auto-update the snapshot tests, but I haven’t integrated that (since they’d have to be written back to the Git commit message).

How Company 3 Streamlines Studio Image Management with EC2 Image Builder and AWS CDK

Introduction

Company 3 provides specialized services for the entertainment industry, including post-production services, visual effects, and color grading for feature films, commercials, and television content. Their teams collaborate globally to Increase workflow efficiency and expand their roster of diverse movie-making talent.

Company 3’s New Technology team uses Amazon EC2 Image Builder to vend Amazon Machine Images (AMIs) and container images for compute environments where artists create and render content. Image Builder is a fully managed AWS service that helps you automate the creation, management, and deployment of customized, secure, and up-to-date server images. Company 3 also uses the AWS Cloud Development Kit (CDK) to scale the creation of consistent Image Builder components and recipes.

At scale, the respective concepts of versioning between Image Builder resources and CDK infrastructure as code made it challenging to reuse prior components and recipes, and update existing references with new version numbers over time. This challenge led to creative workarounds, collaborative problem-solving with AWS, and ultimately, product improvements that benefit the entire AWS community.

This blog follows their journey from manual version management, through creative workarounds, to native EC2 Image Builder features that solved the problem for good. Along the way, we’ll show how auto-versioning and CDK L2 constructs can simplify your own image pipelines.

The Challenge: When Infrastructure-as-Code Gets Complicated

While Image Builder has historically supported semantic versioning for Components and Recipes, there was no mechanism to automatically detect version changes or update existing references to the latest version of a component using the CDK. This is because Image Builder only supported Layer 1 (L1) CDK constructs. Layer 1 constructs map directly to CloudFormation resources and their corresponding service APIs, but do not provide features that create a layer of abstraction above those foundational create / update / delete operations.

Version changes to Components and Recipes are a frequent occurrence because these resources are immutable; every change to them requires a new version. Version numbers are a part of these resource’s Amazon Resource Name (ARN), so changes must be propagated throughout the associated CDK code to correctly reference the latest version of each resource.

The required changes broken out by each of the comprising Image Builder resources:

1. Update the Component configuration
2. Increment the Component version
3. Update the Recipe with the new Component version ARN
4. Increment the Recipe version
5. Update the Recipe version ARN in the Pipeline.

Manual version propagation across dozens of components via this multi-step process was error prone, wasn’t scalable, and created a risk of deployment failures and version churn due to version mismatches.

The team needed to prevent unnecessary update requests to Image Builder when components didn’t change but the recipes they were associated with did, orchestrate version propagations when the versions did need to change, and track component versions as they deployed updates across their infrastructure.

Short-term Workaround: Using Hashes to Identify Changes

Faced with these limitations, the customer’s engineering team got creative. Their first approach involved appending MD5 hashes to component names. This allowed them to track changes and force CDK updates and version increments when content changed, while preventing unnecessary update calls when the content of the component didn’t change but the rest of the resources in the CDK Stack did.

However, this approach had drawbacks. Component names became unwieldy and difficult to maintain. More importantly, the hash-based naming convention didn’t align with semantic versioning best practices that the rest of their infrastructure followed. The team knew they needed a better solution long-term.

Long-term Automation: Collaboration with AWS

Working with their AWS Solutions Architect and EC2 Image Builder Developer Support, Company 3 developed a more elegant solution using CDK Custom Resources. This approach eliminated hash-based naming and automated the propagation of version updates, but it came with technical debt.

The version increments themselves were still manual, and the solution required custom resources to create and maintain the suite of resources being deployed. The mesh of custom resources required specialized knowledge to maintain, which made it difficult to onboard new team members, and distracted engineers from focus on core business value of delivering the right studio environments to artists.

Managed Abstraction: AWS Launches Product Improvements

EC2 Image Builder auto-versioning

In November 2025, EC2 Image Builder introduced native auto-versioning capabilities that transformed how teams manage Component versions.

Components with the same name and semantic version now auto-increment build versions. Additionally, Pipelines can resolve to the highest available version of Components and Recipes, which ensures they are using the latest compatible versions without manual updates.

These enhancements eliminated the version propagation burden entirely, allowing Company 3 developers to focus only on the substantive changes to Components requested by Artists and Support Engineers.

CDK Layer 2 Constructs

The second major improvement came with comprehensive Layer 2 (L2) constructs for EC2 Image Builder. L2 Constructs provide a layer of abstraction that default to best practice configuration, automatic least-privilege IAM Role and Policy provisioning, and convenience methods that make it easier to create and link to other AWS resources.

Before the L2 construct release, orchestrating an Image Builder Pipeline took over 50 lines of code, and required manual least-privilege IAM role creation, instance profile setup, and Pipeline configuration across 6 separate CloudFormation resources.

// Using L1 constructs
const instanceProfileRole = new iam.Role(stack, 'EC2InstanceProfileForImageBuilderRole', {
  assumedBy: iam.ServicePrincipal.fromStaticServicePrincipleName('ec2.amazonaws.com'),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
    iam.ManagedPolicy.fromAwsManagedPolicyName('EC2InstanceProfileForImageBuilder'),
  ],
});

const instanceProfile = new iam.InstanceProfile(stack, 'EC2InstanceProfileForImageBuilder', {
  role: instanceProfileRole,
});

const bucket = new s3.Bucket(stack, 'ImageBuilderLoggingBucket', {
  bucketName: `ec2imagebuilder-logs-${stack.region}-${stack.account}`,
  enforceSSL: true,
});

const l1InfrastructureConfiguration = new imagebuilder.CfnInfrastructureConfiguration(stack, 'L1InfrastructureConfiguration', {
  name: 'l1-infrastructure-configuration',
  instanceProfileName: instanceProfile.instanceProfileName,
  instanceMetadataOptions: { httpTokens: 'required' },
  logging: {
    s3Bucket: bucket.bucketName,
    s3KeyPrefix: 'imagebuilder-logging',
  },
});

const l1ImageRecipe = new imagebuilder.CfnImageRecipe(stack, 'L1ImageRecipe', {
  name: 'l1-image-recipe',
  version: '1.0.0',
  parentImage: `arn:${stack.partition}:imagebuilder:${stack.region}:aws:image/amazon-linux-2023-x86/x.x.x`,
  components: [
    {
      componentArn: `arn:${stack.partition}:imagebuilder:${stack.region}:aws:component/update-linux/x.x.x`,
    },
  ],
});

const l1ImagePipeline = new imagebuilder.CfnImagePipeline(stack, 'L1ImagePipeline', {
  name: 'l1-image-pipeline',
  imageRecipeArn: l1ImageRecipe.attrArn,
  infrastructureConfigurationArn: l1InfrastructureConfiguration.attrArn,
});

Using the ImagePipeline L2 construct allows the developer to provision a Pipeline in fewer than 10 lines of code while leveraging best practice configuration the construct sets by default.

// Equivalent, using L2 constructs
const l2ImagePipeline = new imagebuilder.ImagePipeline(stack, 'L2ImagePipeline', {
  recipe: new imagebuilder.ImageRecipe(stack, 'L2ImageRecipe', {
    baseImage: imagebuilder.AwsManagedImage.amazonLinux2023(stack, 'AL2023'),
    components: [
      {
        component: imagebuilder.AwsManagedComponent.updateOS(stack, 'UpdateOS', {
          platform: imagebuilder.Platform.Linux,
        }),
      },
    ],
  }),
});

The Impact: From Workarounds to Best Practices

For Company 3, these improvements meant they could retire their custom constructs entirely. The L2 constructs provided everything their custom solution did, plus additional capabilities.

The EC2 Image Builder service manages the complexity of version updates by default, and they gained enhanced security through AWS-managed secure defaults like IMDSv2 requirements and least-privileged IAM roles.

Perhaps most importantly, new team members can understand the infrastructure code in minutes rather than hours, dramatically accelerating onboarding.

Conclusion

The impact extends far beyond one customer. Every AWS user working with EC2 Image Builder and CDK now benefits from simplified workflows, automatic version management, and security best practices by default. What started as one team’s challenge became a catalyst for improvements that make everyone’s work easier and more secure. The evolution of EC2 Image Builder’s CDK support demonstrates AWS’s commitment to listening to customers and continuously improving the developer experience.

Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore

When you move AI agents from prototype to production, the infrastructure challenges multiply. Your agents need to persist state across multi-step workflows that run for hours or days. They need to coordinate with other agents, share context, and sometimes access GPUs for specialized tasks. Amazon Bedrock AgentCore runtime microVMs provide a fully managed environment for invocations that can run for up to 8 hours and support stateful workflows through managed session storage. Some workloads also benefit from dedicated, larger-capacity environments — for example, when agents need to run continuously for multiple days, access GPUs or the underlying OS, or run multiple collaborating agents on the same host.

Today, I’m happy to announce runtime instances, a new complementary compute option in Amazon Bedrock AgentCore Runtime that gives your agents persistent, managed infrastructure purpose-built for complex agent workloads.

What you get

Runtime instances provides AWS-managed EC2 infrastructure where you deploy multiple agents in a single runtime, each with their own dependencies and artifact types. Your agents can collaborate on the same host within shared sessions that persist for up to 14 days. The service supports GPU acceleration for compute-intensive tasks, session stop/restart to save costs during idle periods, and containerized deployments for teams that want to ship independently. For knowledge that needs to survive beyond a session, runtime instances pairs naturally with Amazon Elastic Block Store (Amazon EBS) and AgentCore Memory, which gives your agents long-term recall across sessions and environments.

Before today, if you wanted to keep your agents running for days or they needed GPU access, or multi-agent coordination, you had to build and manage that infrastructure yourself. You provisioned EC2 instances, configured networking, set up session management, handled scaling, and stitched together monitoring. Runtime instances handles all of that for you while integrating with the same AgentCore APIs, identity controls, and observability you already use with AgentCore Runtime microVMs.

A few things that should make agent developers smile: your agents can call each other as tools within a shared session, iterating autonomously until the job is done. You bring any framework (CrewAI, LangGraph, LlamaIndex, Strands) and any model. Packaging is minimal, a @app.entrypoint decorator and a zip file or container image. And if your workflow spans days, hibernate Monday night and resume Wednesday morning with everything intact.

Runtime microVMs and runtime instances are complementary compute options that you can use independently or together through the same AgentCore runtime APIs. A lightweight orchestrator agent on runtime microVM can coordinate and dispatch work to specialized worker agents running on instances. The orchestrator handles API calls, task routing, and result aggregation using runtime microVM’s fast scaling, while workers on Instances perform compute-intensive tasks like code compilation, security scanning, or GUI automation that require persistent state and direct OS access.

Let me show you how it works

I built two agents for this demo: a code writer agent that generates Python code from natural language descriptions, and a code reviewer agent that analyzes the generated code for bugs, security issues, and style improvements. Both agents share the same file system, so the reviewer can read whatever the writer produces without any data transfer or API calls between them.

Here is the code writer (simplified, no error handling):

writer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a senior Python engineer. "
        "Given a task, return ONLY a single Python code block — no prose."
    ),
)

@app.entrypoint
def handler(event, context):
    task = event.get("task") or event.get("prompt")
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    session_dir = SHARED_DIR / session_id
    session_dir.mkdir(parents=True, exist_ok=True)

    code = str(writer(task))
    (session_dir / "code.py").write_text(code)

    return {"agent": "writer", "wrote": str(session_dir / "code.py"), "code": code}

Here is the code reviewer agent (simplified, no error handling):

reviewer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a strict Python code reviewer. "
        "Given code, return 3 bullet points: bugs, style, suggestions."
    ),
)

@app.entrypoint
def handler(event, context):
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    code_path = SHARED_DIR / session_id / "code.py"
    code = code_path.read_text()
    review = str(reviewer(f"Review this code:\n\n{code}"))

    return {"agent": "reviewer", "read": str(code_path), "review": review}

Each agent is a Python application using Strands Agents with an @app.entrypoint decorator and a model of its choice. I package each one as a zip file. For this demo, I use the AWS Management Console. You can also use the AgentCore CLI, the AWS Command Line Interface (AWS CLI) or infrastructure as code.

Step 1: Create a capacity provider.

A capacity provider defines the EC2 infrastructure your agents run on. In the AgentCore console, I select Runtime in the left navigation, then select the Capacity providers tab and Create capacity provider.

I give it a Name, select Linux (64-bit ARM) as the Operating system, and choose c7g.2xlarge as the Allowed instance types. This gives me 8 vCPUs and 16 GiB of memory, enough for both agents to run comfortably side by side.

Further down, I configure the VPC, subnets, and security groups for network access. Under Storage configuration, I keep the default gp3 volume. Under Service access, I select Create a new service role and let the console create the infrastructure role that manages EC2 instances on my behalf.

I select Create capacity provider and wait a few seconds. The status moves to Active.

Note the capacity provider configuration summary: operating system, instance type, subnets, security group, instance profile, and infrastructure role. Once created, only the description can be edited, so verify your settings before you proceed.

Step 2: Create a runtime and deploy the first agent.

Back on the Runtime page, I select Create runtime. I give it a Name, select Instances as the Compute type, and choose the Capacity provider I created in the previous step.

Under Agent source, I select S3 Source, then Upload to S3. I choose my agent zip file (ACIDemoWriter.zip), set the Language runtime to Python 3.13, and specify agent.py as the Agent entry point. This is the file that contains my @app.entrypoint decorated function. Under Permissions, I select Create default role to let the console provision the IAM role my agent needs.

I select Create runtime and wait for the status to become Ready.

I repeat the same process for my code reviewer agent. I create a second runtime, select the same capacity provider, upload my reviewer agent zip file, and wait for it to become Ready. Both agents now share the same underlying EC2 infrastructure.

The console shows me a View invocation code section with ready-to-use Python, TypeScript, and JavaScript snippets to invoke my agent programmatically. But for this demo, I use the built-in test feature. I select Test on the writer agent’s page.

Step 3: Invoke agents and observe collaboration.

The Runtime playground opens. At the top, I see three fields: Runtime agent, Endpoint, and Session ID. The console generates a session ID automatically. I take note of it because I will reuse it with the reviewer agent.

In the Input field, I type a JSON payload asking the writer agent to generate code:

{"prompt": "write a fibonacci suite"}

I select Run. After a few seconds, the Output panel shows the agent’s response. The writer agent generated a Python module with two implementations of a Fibonacci sequence (a list-based function and a generator) and wrote it to /tmp/agentcore-session/ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2/code.py. Notice the session ID in the file path. That directory is the shared file system for this session.

Step 4: Invoke the reviewer agent in the same session.

Now I switch the Runtime agent dropdown to ACIDemoReviewer. The important part: I paste the same session ID (ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2) in the Session ID field. This is what connects the two agents.

I type a simple prompt:

{"prompt": "review the code"}

I select Run. The reviewer agent reads the file the writer produced from the shared session directory and returns a detailed code review. It finds no critical bugs but suggests adding type hints, input validation, and simplifying the edge case handling.

The two agents never exchanged messages or called each other’s APIs. They collaborated through the shared file system that runtime instances provide within a session. You can extend this pattern to any number of agents: a test agent that runs the code, a documentation agent that generates README files, a security agent that scans for vulnerabilities, all sharing the same working directory.

Key details

• Supported OS: Linux (ARM64 and x86_64) at launch.
• Session persistence: Sessions persist for up to 14 days.
• Runtimes: Python 3.11-14 with native code support. Container images also supported.
• GPU: Support for GPU-accelerated instance types.
• Integration: Uses the same AgentCore APIs, identity, observability, and policy controls as AgentCore Runtime.
• Pricing: Standard EC2 pricing plus a management fee for AgentCore orchestration.
• Regions: US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland)

To get started, visit the runtime instance in Amazon Bedrock AgentCore documentation and create your first capacity provider.

The Training Infrastructure Behind AI-Powered Job Search: 8X Faster Multi-Teacher Distillation

At LinkedIn, we recently shared how we reimagined our search tech stack with improvements like LLM-powered query understanding, semantic retrieval, and Small Language Model ranking. Changes that power a smarter, faster, and more personalized experience that helps every member find the most relevant opportunities and connections. This blog will go deeper on the training infrastructure that makes it all possible for LinkedIn’s AI-Powered Job Search.

Delivering the most relevant job recommendations requires frequent model retraining. Currently, the speed and efficiency of our training infrastructure act as the primary constraint on how rapidly we can iterate and improve our ranking models. Behind every model improvement - from significant gains in engagement prediction and ranking quality to achieving near-teacher model accuracy from a model one-third the size - there's a training pipeline that has to get dramatically faster and more flexible. Taking our job search as an example, we went from single-node jobs that took more than two days to a distributed multi-teacher distillation pipeline that runs in under 5 hours.

In this blog, you’ll learn about the infrastructure approach behind LinkedIn's multi-teacher distillation for AI-Powered Job Search, including how we went about coordinating multiple specialized teachers and the efficient training pipeline supporting them. These improvements to our infrastructure meant rethinking the pipeline at three levels that we’ll explore further, including: distributed training that keeps pace with growing model complexity, a multi-teacher distillation system that coordinates several specialized models across heterogeneous GPU clusters, and a caching and streaming infrastructure that turns slow, all-or-nothing runs into rapid experimentation at production scale.

The problem: Scaling model training for AI-Powered Job Search

LinkedIn's ranking system for AI-Powered Job Search uses a knowledge distillation approach: large teacher models generate rich training signals, and a smaller student model learns to approximate those signals for low-latency serving. But AI-Powered Job Search isn't a simple single-teacher setup. The production pipeline requires multiple specialized teachers working in concert:

• A relevance teacher that scores job-query relevance using structured evaluation prompts.
• An engagement teacher that predicts member actions (views, applies, recruiter accepts, profile connections, messaging, and follows) across multiple prediction tasks.
• An embedding model that generates contextual representations fed directly into the student's input layer.
• A compact student Small Language Model (SLM) that distills knowledge from all of the above into a single model optimized for low-latency serving.

The reason for this multi-teacher setup is a hard serving constraint. Job search has to rank thousands of candidate jobs per query within a tight latency budget, which makes serving multi-billion-parameter teacher models directly a non-starter. Distillation lets us keep their quality while serving a compact 0.6B student at ~22,000 requests/sec/GPU. But that trade pushes cost from serving onto training, so the training pipeline becomes the bottleneck for how quickly the product can iterate.

The baseline pipeline was a chain of loosely coupled stages - fine-tune each teacher, run each teacher over the training data to generate its signals, then train the student on the combined outputs. The data lives on HDFS, the Hadoop Distributed File System, as hundreds of millions of job-query pairs, and because the models span a wide range of sizes and architectures, the stages were stitched together largely by hand. Critically, every iteration re-ran the whole chain end to end, even when only the student had changed.

Training these models takes time. The engagement teacher alone, fine-tuned on massive interaction logs, originally took more than a day per run. The distillation stage, which coordinates teacher inference alongside student training, was even slower. With each full iteration measured in days, the infrastructure, not the modeling, set the ceiling on how fast we could improve the product.

The core challenge for multi-teacher distillation

Why multiple teachers?

Knowledge distillation in its simplest form uses one teacher and one student. But the AI-Powered Job Search’s student SLM must learn from multiple specialized models simultaneously. Each teacher provides a different type of signal: the relevance teacher provides soft labels scored as a logit-based probability over the yes/no tokens, the engagement teacher provides multi-task soft targets across several member action prediction tasks, and the embedding model contributes learned representations that enrich the student's input layer. For the relevance teacher, we compute the "yes" probability by taking the yes score and normalizing it by the sum of the yes and no scores.

Just as important, the set of teachers is not fixed. Over the project's lifetime we have added and swapped teachers as the modeling team explored new signals, including introducing a dedicated click teacher, and the teachers themselves span multiple model families and sizes. From an infrastructure standpoint this rules out hardcoding assumptions about any single teacher's architecture or output format. The system has to treat teachers as pluggable components. Onboarding the click teacher, for example, first required building an internal serving-engine release with sequence-classification support before it could even produce labels.

The student trains on a Knowledge Distillation (KD) loss that combines cross-entropy on hard labels with Kullback-Leibler divergence on the teachers' soft labels. From an infrastructure perspective, this creates two distinct costs, both of which grow with the number of teachers:

• The first is compute: every teacher must run a forward pass over each batch, and because the teachers are many times larger than the student, teacher inference can easily dominate step time.
• The second is data movement: the student has to gather and merge every teacher's output on each step. The embedding model in particular produces large dense tensors that must be transferred to the student every step; soft labels are smaller, but as the number of teachers and prediction tasks grows, they add up too.

Accelerating teacher training

Before tackling distillation itself, we needed teacher fine-tuning to keep pace, since a slow teacher pipeline bottlenecks everything downstream. Our first step was scaling out training across multiple GPUs and nodes using PyTorch's Fully Sharded Data Parallel (FSDP) with a configurable sharding policy that could adapt to each model in our pipeline. We needed this flexibility because the pipeline includes models of varying sizes and architectures, and a single sharding strategy doesn't work well across all of them. On top of FSDP, we layered a series of complementary optimizations: Liger kernels for more efficient GPU utilization, an upgraded runtime stack on the latest CUDA and PyTorch versions to fully utilize the GPUs, and a migration to H200 GPUs with their larger memory and bandwidth. None of these techniques is novel on its own; the engineering was in composing them so the gains actually stacked rather than cancelling out.

We later migrated to FSDP2 and added Hybrid Sharded Data Parallel (HSDP) support. FSDP2 improved on the original FSDP with better memory efficiency and more flexible composability with other parallelism strategies. HSDP was particularly valuable for our multi-node setup. It applies full sharding within each node (so GPUs on the same machine split the model to save memory) while replicating across nodes (so each node holds a complete copy and only needs to sync gradients). This means inter-node communication is limited to gradient all-reduces rather than the more expensive parameter all-gathers that full cross-node sharding requires. For our workloads, this was a meaningful improvement since intra-node NVLink bandwidth is much higher than inter-node network bandwidth, and HSDP lets us take advantage of that topology.

Together, these optimizations roughly doubled teacher fine-tuning throughput (from ~25 hours to under 12 hours on 20M records), increased usable batch size by 75%, and doubled hardware FLOPs utilization (HFU), all while preserving model quality. With teacher training no longer the bottleneck, we could turn to the harder problem of coordinating multiple specialized teachers during distillation.

Online distillation: Real-time, teacher-student coordination

In online distillation, the teacher models run in inference mode alongside the student during training. Each training step, the student sends its current batch to each teacher. The teachers process the batch and return their outputs. The relevance and engagement teachers return soft label distributions over their respective prediction tasks, while the embedding model returns dense vector representations. The student then combines these signals, computing its KD loss against the teachers' soft labels and fusing the embedding outputs into its own input representation, before running backpropagation.

We started with the simplest arrangement: a single node, with all teachers co-located on the same machine as the student. Teachers could serve their outputs locally with no network transfer, which kept the system easy to reason about. But it had a low ceiling: teachers and the student competed for the same GPUs, so adding a teacher or growing the batch quickly ran out of memory, and the whole job was capped at what one machine could hold.

The single biggest lever was how we ran teacher inference. Our first implementation generated teacher outputs with an ordinary model forward pass, which left the GPUs badly underutilized. We switched to running each teacher on a high-throughput inference engine, the same one that serves our production ranking, with continuous batching and paged attention. That change alone made teacher inference roughly 2X faster and let us push 4X larger batches (or 5X more augmented samples) through the same hardware, which is what made full-scale online distillation practical in the first place. On top of it, we applied tensor parallelism to the larger teachers and prefetched the next batch's teacher inference so it overlapped with the student's own computation.

As models and data outgrew a single machine, we moved to a multi-node setup with replicated teachers. The student is sharded across nodes with data parallelism, and each teacher is replicated on every node so the student always has a local copy to query. This keeps every teacher output on-box and avoids paying the per-step network cost of shipping soft labels and embeddings between machines (the bandwidth bottleneck described earlier) at the expense of dedicating extra GPUs to teacher replicas.

As the system matured, we made the whole thing configurable. Teacher combinations, parallelism strategies, and hyperparameters became parameters rather than code changes, so the broader team could try different distillation recipes without touching core infrastructure. Together these brought online multi-teacher distillation from almost two days (~45 hours) down to roughly 10 hours. But one structural inefficiency remained. Every run re-ran all teacher inference from scratch, even when neither the teachers nor the data had changed. In practice, teams iterate on the student far more often than on the teachers or the data, so re-paying for teacher inference on every run was pure waste. This is what drove the move to offline distillation.

Offline distillation: Decoupling teacher inference from student training

The offline distillation pipeline separates the process into two stages.

• In the first stage, each teacher runs inference over the training data once and writes its outputs (soft labels or embeddings) to HDFS. Each teacher's cache is keyed on model version and data fingerprint, so updating one teacher doesn't invalidate another's cached outputs.
• In the second stage, the student trains entirely from these pre-computed outputs, reading them from storage rather than querying live teacher fleets. No teacher GPUs are needed during student training at all, which is where most of the per-run cost goes.

A key design decision was making the cache operate at per-shard granularity rather than all-or-nothing per teacher. When the training data is updated, only the new or modified shards trigger teacher inference, while unchanged shards reuse cached outputs. This makes repeated runs dramatically cheaper, which is exactly the common case of iterating on student architecture or loss while the teachers stay fixed.

The remaining challenge was data volume. The offline datasets are large - tens of millions of records - each now carrying the original training example plus dense embeddings and multi-task soft labels from several teachers, and they come in a mix of formats (e.g. Avro, JSONL, and pre-formatted datasets).

Previously, a training job had to stage the entire dataset to a local disk before it could start. We replaced that with a streaming data pipeline that reads directly from HDFS during training, eliminating the staging step and cutting both startup time and local-storage requirements. To produce the caches efficiently in the first place, teacher inference runs as a concurrent, high-throughput generation job rather than one teacher at a time. Profiling this path also surfaced a dataloader bug whose fix both sped up training and improved model quality.

Offline distillation does add an upfront cost. The first stage has to generate the cache, but that generation runs in under 2 hours on resources comparable to an online run. It is paid only once per teacher-and-data version, then amortized across every subsequent student iteration, which needs no teacher inference at all. With teacher inference fully decoupled and cached, end-to-end student training dropped to under 5 hours, more than 8X faster than the original ~45-hour pipeline and about half the time of the optimized online path, with no loss in model quality.

Bringing it together: A unified distillation framework

Before this, online and offline distillation shared no common machinery, so the two paths duplicated a lot of work, the same teacher setup, data plumbing, and orchestration rebuilt twice and kept in sync by hand. We consolidated them into a single platform that supports both modes under one architecture. Running the whole thing as a Ray job on a heterogeneous GPU cluster buys three things that the old pipeline couldn't:

1. Teachers scale independently of each other and of the student
2. Teachers and the trainer can run on different hardware matched to each one's needs, rather than forcing everything onto a single GPU type
3. The topology itself is flexible, the number of teachers, and the data- and tensor-parallel degree of each, are configuration rather than a rewrite

This last point lifts a hard limit from the online path, where teachers were co-located on the same machine as the trainer. Everything, the student plus every teacher, had to fit within a single node's GPUs (eight, on our hardware), which capped how large a teacher could be and how much data- or tensor-parallelism it could use. With teachers running as their own Ray actors on their own nodes, that ceiling is gone, a teacher can be sized and parallelized for its own needs without competing for the trainer's GPUs. Within a single run, each teacher can operate in live inference mode or cached mode depending on what's available.

The platform has four types of components working together. Inference workers run teacher models on dedicated GPU nodes using a high-throughput serving engine (the same one that powers our production ranking). Each teacher can be independently scaled with data parallelism, tensor parallelism, or distributed across multiple nodes depending on model size. When running live, these workers also write their outputs to a cache in the background, so subsequent runs with the same teacher and data can skip inference entirely.

Cache readers handle the opposite case. When a teacher's pre-computed outputs are available in shared storage, they provide them to the trainer directly, replacing the need for a live inference fleet. A collector component sits on the trainer node and merges outputs from all teachers, regardless of whether they came from live inference or cache, aggregating soft labels via averaging or learned weighting. Finally, a trainer orchestrator manages the full training loop: it checks cache availability for each teacher, routes requests to live inference or cache accordingly, fuses embedding outputs into the student input, computes the distillation loss, and runs backpropagation.

The result is that online and offline are not separate pipelines but per-teacher decisions within the same run. If one teacher's cache is warm while another has been updated, the system reads from cache for the first and runs live inference for the second. Over successive runs, the system naturally converges toward fully cached operation as more teachers stabilize, progressively reducing GPU costs without manual intervention. When data volumes grow and direct transfer becomes impractical, the caching layer absorbs the cost by letting teams pre-compute once and retrain many times.

The goal was not just to make training faster. The real value was that the modeling team could move from multi-day iteration cycles to same-day experiments, which made it possible to test ideas quickly and ship the SLM launch. The improvements compounded across the pipeline. Teacher fine-tuning dropped from about 25 hours to under 12, with 75% larger batches and roughly 2x better hardware FLOPs utilization. Online multi-teacher distillation went from about 45 hours to around 10. Offline distillation brought end-to-end student training under 5 hours, making the full student-training loop about 8x faster than where we started.

Two things mattered as much as the raw numbers:

• First, every speedup preserved model quality: the distilled student reaches near-teacher ranking quality with significant engagement-prediction gains from multi-task distillation, and the offline path is quality-neutral versus online, so none of these wins were paid for in accuracy.
• Second, most of the savings come from eliminating GPU waste rather than adding GPUs. Caching removes redundant teacher inference across runs (cached student training needs no teacher GPUs at all), and because online and offline are per-teacher decisions within one Ray platform, repeated runs converge toward fully cached operation, automatically shedding GPU cost as teachers stabilize.

What's next

We are now turning this platform into a standalone distillation framework that is not tied to any specific backend. The core design is simple: teacher inference workers, a student trainer, and a cache between them. Because of that, very little is specific to job search. Different serving engines and trainers can plug in behind the same interface, and the framework can support many teacher-student setups, including single-teacher, multi-teacher, multi-task, and embedding-based distillation. The goal is for teams across LinkedIn to adopt distillation without rebuilding this infrastructure, and it is already being validated beyond job search across multiple teams and use cases.

Looking further out, the same architecture, a trainer coordinating with auxiliary models served for inference, is not specific to distillation. Reinforcement-learning post-training has the same shape, with reward and reference models standing in for teachers, so unifying distillation and RL on a single framework is a direction we are actively exploring.

Netflix's RDG query layer handles 8 billion nodes and 150 billion edges using level-by-level parallel traversal, 16 to 24 async threads per instance, and cache TTLs matched to data volatility that achieve 70 to 80% hit rates on stable entities. The result is that even three-hop traversals complete under 150 ms at P99.

Summary

• Physical Intelligence builds robotics foundation models and uses Postgres managed by ClickHouse to combine OLAP and OLTP workloads in one unified data stack.
• They migrated to ClickHouse Cloud after their previous single RDS Postgres instance couldn’t handle both their transactional and high-cardinality analytical workloads.
• They can now explore their data faster and more easily, with rows growing from the 10 to 100 billion row range.

Introduction

Physical Intelligence is a robotics company acting as a research lab pushing frontier models in robotics, with the mission of bringing general-purpose AI into the physical world.

Three axes of generalization

To bring general-purpose AI into the physical world, the team focuses on three axes of generalization:

• Environments: A foundation model that runs on a robot in any environment, such as a home or a factory floor.
• Embodiment: A model capable of operating on any hardware form factor, including single-arm robots, multi-arm robots, and robots with legs or wheels.
• Tasks: A robot brain capable of performing any task, from folding laundry to making coffee.

Foundation models for robotics

Classical robotics relies on methods like A-star search, SLAM, object recognition, and low-level control. Physical Intelligence aims to build a robot brain from scratch, similar to a large language model, which takes data from different sources and executes actions. Their model, π0.7, can perform tasks in various environments and on different robot embodiments without specialized fine-tuning. By utilizing visual sub-goals, the model can chain together skills, transfer tasks across different robot hardware, and learn through human coaching.

How the model learns — and why data matters

The team uses a vision-language-action model, which acts as an LLM with a vision encoder and an action decoder. Achieving generalization requires diverse, petabyte-scale data, including web data, ego-centric human data, and robot-specific data.

The data infrastructure is divided into three categories:

• Raw data: Petabyte-scale, append-only data used during training. It requires cheap storage and relies on random reads.
• Transactional data: Data required for company operations and data labeling, requiring ACID guarantees and strong consistency. This fits within 100 million rows.
• Metadata and annotations: High-cardinality data in the 10 to 100 billion row range. This requires long-running filters and GROUP BY queries where eventual consistency is acceptable.

Where we started: a single RDS database

Previously, the team relied on a single RDS Postgres database. As the volume of data and the complexity of researcher queries grew, they faced significant scaling issues, exacerbated by an over-reliance on JSONB for storing diverse, evolving annotation types. These "ambitious" queries on top of JSONB structures caused performance bottlenecks.

Why ClickHouse

The team transitioned to ClickHouse to separate transactional and analytical workloads. ClickHouse offered fast inserts and efficient storage for their annotation data. Using the ReplacingMergeTree engine, they handled high-cardinality datasets while moving away from inefficient JSONB blobs toward a columnar format. Materialized views were implemented to accelerate specific queries and reduce database load.

The migration

The team leveraged ClickPipes to migrate data seamlessly from Postgres to ClickHouse. This established a unified stack where transactional data lives in Postgres, while annotations and telemetry are replicated to ClickHouse for analytical processing. This setup allows researchers to perform complex, cross-table queries that were previously impossible, such as verifying if specific objects (like an air fryer) have been encountered in training datasets.

The go/data app

The team built an internal tool, "go/data," which allows researchers to query the dataset via SQL or a natural language interface. An AI agent processes these queries, identifying the relevant tables across Postgres and ClickHouse to return results. This system uses full-text indexing to search through millions of data points rapidly, enabling researchers to discover new capabilities and verify training data content without manual multi-day joins.

Bonus: telemetry

The team also migrated their system telemetry to ClickHouse. By using ClickHouse alongside Grafana, they unified their telemetry, OLAP, and OLTP workloads, providing a comprehensive view of their operations on a single platform.

If you have worked in IT for a while, you have probably at some point inherited an Access database, or certainly something that resembles one.

It was built years ago by someone in Finance, HR, or some other operations part of the business. It started as a quick shim to keep track of something the pre-existing systems did not handle well. Then over time it gained some new forms, some reports, a little bit of Visual Basic, and before anybody paid too much attention, it became critical to running the business.

Then the person who made it moved on.

Nobody really understood how it worked. There was not any documentation. It just worked. And this thing persisted through waves of hires and changes in the business, and people just knew how to use it because of institutional knowledge.

It lived on a shared drive somewhere with a filename that resembled Customer Database FINAL v6.accdb.

Every few months it corrupted itself, stopped accepting new records, or produced a report that did not quite match Finance. When that happened, somebody from the IT team would be summoned to fix an application they never built, never approved, and until that morning probably did not even know existed.

It is easy to look back and blame Microsoft Access, but I do not think Access itself is the problem.

Access was brilliant. It gave regular folks the ability to solve real business problems they were encountering without having to wait for some IT project to happen six months later. It allowed someone who understood the work, a domain expert in that area, to turn the understanding they held into a useful application for other people to benefit from.

The problem is not that people were building things with Access back then. The problem was that the cost of building that software suddenly fell, which on the surface of it sounds great, but the way organisations govern software stayed exactly the same. These small, business-area-scoped applications fell outside of the governance framework entirely.

Right now, we are doing it again.

Only this time, the things people can create go beyond storing some customer addresses and printing reports. They talk to APIs. They update larger production systems. They potentially communicate with customers, maybe even in real time. They handle approvals. They might move money. They form views on the fly from policy. And they are fundamentally making decisions on behalf of the business.

We have been through this cycle before

Access was one wave, but it was not the first and it obviously was not the last.

This will be very familiar to anyone who has encountered Excel macros, SharePoint workflows, or low-code platforms such as Power Apps. Each time one of these waves arrived, it compounded the ability of individuals across the business to create more and more complex outcomes with less and less friction.

Each wave lowered the barrier to creating software. Each created enormous value. Each also created a new category of mess for somebody else to clean up later.

So, again, the tools are not the things failing here. They are the enablers. They succeeded so well that organisations could barely keep up with the volume of things being created.

The debt became visible later. A department might save hundreds of hours using a clever spreadsheet, but five years later, when that spreadsheet has become mission-critical and the author has left the company, you have an exposed and crystallised risk.

Building a database in a week instead of waiting a year for a corporate system change is a totally rational decision, and not a problem to criticise.

So it is very easy to describe these things as failures of governance, but I actually think they are failures of scale.

The organisation has a process for governing ten large applications. It does not have a process for governing ten thousand small ones.

AI changes the economics again

So here we are once again, talking about AI and how it changes the economics.

It is not quite comparable to these prior examples. It is not a low-code platform. What it does do is change the cost of producing software by at least one, possibly more, orders of magnitude.

An individual no longer needs to understand database design, or Excel formulas, or VB scripting, or even the conventions of a low-code workflow in a tool like Power Apps. They can describe what they want in ordinary language and have a working version appear in front of them. They can speak in their own language to their own tame developer, who works without complaint and outputs exactly the product they requested.

It will not always be good. It will not always be safe. It might not be particularly well designed. But it will tick each of those categories just enough to solve the immediate problem in front of them.

It is very plausible when you think about it. You have an individual who notices that someone in their team is copying the same information between three different systems every morning. In the old world, they might raise this as a request with an IT team, or flag it to their manager. Today, they can describe that problem to their AI assistant at the moment they notice it, and maybe fifteen minutes later they have something usable that solves it.

By the end of the week, an entire department is relying on it and has removed that scheduled entry from their calendar that drove the manual workflow.

It never got labelled as a project. It might have come under some larger corporate-branded initiative such as AI transformation, but it would not even make sense to call it a project.

Projects make sense when delivery takes place over weeks to months and costs a material amount upfront. If a new system required a team of engineers, a six-month delivery timeline, and substantial CapEx investment, it makes sense to wrap it in governance. You need requirements, funding, milestones, and a clear decision to begin. You end up with steering committees.

But what happens when the first working version takes fifteen to thirty minutes?

It is not that the need for governance has disappeared. It is that the economics that allowed, and even forced, governance to sit in front of the process have disappeared.

There is no way people would tolerate every AI-generated workflow or app going through an approval cycle. People will simply go around it, and you can totally understand why. It is the classic water-goes-around-the-rock problem.

But you also cannot pretend these things are harmless just because they were quick to build.

An automation that took twenty minutes to create can still delete a customer record. It can still email thousands of people incorrect information. It can still contain business logic that determines whether somebody gets paid their commission that month.

I would actually argue that the effort required to build something has never really been a reliable measure of its importance. Right now, AI is making that gap simply impossible to ignore.

Software has become disposable

The other big change here is that software has become a disposable commodity.

It sounds like hyperbole, or LinkedIn clickbait, to put it that way. But I find myself regularly talking right now about being absolutely fine, more okay than I ever have been, with disposable work to patch a short-term problem.

For most of IT history, software was treated like an asset, partly because it was expensive to produce. You maintained it because rebuilding it would be costly. You documented it because a replacement team would need to understand it. You planned upgrades because the application was expected to survive for years.

That assumption simply does not stand true anymore. It began to weaken when the SaaS model appeared on the scene, but it is completely shattered at this point.

There are totally plausible scenarios now where a department might not even consider upgrading their existing internal application. They are just going to ask AI to create a new one. A workflow might exist for three weeks to support a temporary process and then be discarded. Several teams might independently generate slightly different solutions to exactly the same problem, because creating another one is easier than discovering and adapting the first to accommodate them.

So I stand by it. Software is disposable now.

With one hat on, that can feel very liberating. There are thousands of valuable ideas inside businesses today that are not worth turning into traditional software projects, and AI makes them all viable all of a sudden.

But disposable does not mean consequence-free.

A disposable paper cup is simple because nothing else depends on it. Software very quickly becomes connected to people, systems, data, and decisions. It might be easy to create, but the moment someone starts relying on it, it has got weight. It is now structurally load-bearing to the company.

The code might be disposable. The consequences are not.

The new technical debt is not the code

Everyone tends to harp on about AI-generated software’s main risk being poor-quality code.

There is definitely going to be plenty of poor-quality code out there. I have generated a substantial amount of it myself, frankly in the last twenty-four hours, given how accessible these tools are. I am just not convinced it is the biggest problem.

Code can be reviewed and tested. Now it can just be regenerated. If you understand the problem, you ask the AI a more refined question.

The hard questions now are different.

Who owns it? Who knows it exists? What identity is it operating as? What permissions have you given it? What systems can it access? What data does it retain? What model is it using? What instructions was it given? What tools and connectors can it call? What happens when the person who created it leaves? What else depends on it? And who would know if it started behaving incorrectly?

This new class of technical debt has nothing to do with code. It is more about AI prompts, agent definitions, tool permissions, workflow connections, embedded policies, and undocumented assumptions. It is the gap between what an AI agent is technically capable of doing and what everyone believes it is supposed to do.

In some cases, the source code may well be the least interesting part of the system. The business logic will be spread across all of these natural-language instructions, examples, knowledge sources, model behaviour, and the permissions granted to a collection of tools.

That is a totally different class of problem to reason about than a badly written Visual Basic macro.

Shadow AI will not look like Shadow IT

In some ways this problem resembles the classic shadow IT problem.

Shadow IT generally appears because a central IT team cannot move quickly enough to respond to demand. People would buy their own SaaS tools, create spreadsheets, and build databases because the official route was too slow, too expensive, or too disconnected from reality.

Shadow AI emerges for a slightly different reason. It is not just that an IT team cannot build things quickly enough. It is that everyone can build things so quickly that nobody can keep count.

If the shadow IT problem was a capacity issue, the shadow AI problem is a visibility issue. If anything, capacity is now almost a non-issue.

I am absolutely confident that the industry’s current application inventory paradigm is not designed for this world. Neither are our architecture boards, change boards, planning cycles, or steering committees.

They all assume that this work has a beginning. A project formally starts, something is delivered, and the organisation records what now exists as a consequence.

Based on my experience so far, AI-created software often does not even have an obvious beginning. It emerges at some point from the work being done in these new tools, as a consequence.

Banning it will fail

So, now onto the so what.

You can imagine some people are going to have the reaction of, well, let’s just ban it, or restrict creation in some way.

That would be a mistake.

It was a mistake to treat every spreadsheet as a threat. It was a mistake to assume every departmental database should have been replaced by a multimillion-pound enterprise system. It would be a mistake to force every AI-created workflow through the same process as a major company-wide application.

The value in these tools comes from allowing the people closest to a problem to solve the problem.

The answer cannot be to restore scarcity back into the system. The answer has to be governance that works under abundance. We have to move governance away from permission to create, and towards the conditions under which created things can operate.

Make the easy path the correct path

The thing for me is about making the easy path, the happy path, and the correct path all the same thing.

You want people’s path of preference to self-steer down the one you want. There is a UX challenge here, amongst other things, and I do not think we talk about it that way often enough. Governance gets designed as a set of rules to be complied with, when it should be designed as the route of least resistance.

So if the governed route is slower, uglier, or harder to find than opening a chat window, you have already lost. Not because people are reckless, but because you have made the correct path the expensive one.

In practice, that means the platform has to do the work rather than the person:

• Identity should come for free. If the natural place to build something already knows who you are, nobody has to be persuaded to authenticate properly.
• Organisational credentials should be the easiest credentials to reach for, so that using a personal account is the awkward option rather than the default one.
• Permissions should be legible at the point of creation, not buried in an admin console that somebody visits a year later during an audit.
• Tool calls should be logged by the platform itself, so that observability is not something anyone has to remember to add.
• Ownership should be captured at the moment of building, while somebody is there to answer the question, rather than reconstructed afterwards from commit history and guesswork.
• Registration should be a by-product of building, not a separate form that a person has to be chased to complete.
• Expiry should be the default, so that keeping something alive is the deliberate act rather than the accidental one.
• Existing solutions should surface at the moment of creation, so that somebody sees the seventeen versions that already exist before they build the eighteenth.

None of that stops anybody building anything. That is the point. People should be able to experiment freely with low-risk data and actions, and the moment something connects to a production system, affects another person, or begins making consequential decisions, stronger controls should appear automatically.

This is less like traditional project governance and more like building roads, signs, and traffic rules. You do not approve every journey before someone gets in a car. You create an environment in which millions of journeys can happen without constant central intervention.

That is the challenge enterprise technology teams now face.

Not how to stop people creating software.

How to make rampant software creation safe enough to become normal.

The Access database was a warning

I do not think we should remember the Access era as a disaster.

An enormous amount of useful work was done in those databases.

They filled gaps that expensive corporate systems ignored. They allowed people to improve their own work. They proved that software creation did not have to belong exclusively to professional developers.

The mess came because our organisations did not adapt to the abundance Access created. We treated each database as an isolated oddity rather than recognising that the cost of software production had changed.

AI is the next wave, but it is not just a slightly easier version of what came before.

The scale is different.

The speed is different.

Most importantly, the software can act.

We are entering another Access database era, except this time the databases can read our policies, call our systems, make decisions, and talk to our customers.

The organisations that succeed will not be the ones that prevent this explosion. They will be the ones that understand a fairly uncomfortable truth early enough: When software becomes almost free to create, building it is no longer the hard part.

Knowing what exists, what it can do, who is responsible for it, and whether anyone should still trust it becomes the real work.

Pointblank validates pandas, Polars, DuckDB, and PostgreSQL data using declarative rules, thresholds, and automated failure handling. Compared with Pandera and Great Expectations, it focuses more on quality gates, row-level quarantine, and stakeholder-friendly reporting.

Kestra 2.0 is almost here: help shape the future of orchestration

Kestra 2.0 marks the biggest update in the project’s history with a complete overhaul of the execution engine, a redesigned UI, and the most substantial set of changes we’ve ever released. Importantly, Kestra 2.0 remains open source under the Apache 2.0 license, the same as from the start. Unlike many projects that use major versions to change licenses, we are leveraging ours to open up earlier.

Why consider 2.0

Here is a glimpse of what the release will change for you:

• Run it where your business rules require. Stateless workers use gRPC to communicate with the control plane and do not directly access the database, even in different regions, restricted networks, or air-gapped environments.
• From seconds to milliseconds. Large task outputs are loaded on demand, so thousands of tasks and gigabytes of outputs no longer slow the UI or the database.
• Better developer experience. Cleaner flow semantics, a redesigned interface, Drafts you can run mid-edit, and AI-generated flows from plain English.
• MCP to expose your flows. One trigger turns any flow into a named tool agents can discover and call, from Claude, Cursor, or any MCP client.
• Use AI to create your flows. Create and manage Kestra flows from your favorite AI assistant, all powered through the Kestra MCP server.

Will walks through all of it in the video below if you want to see it running rather than read about it.

Already tested. Now it meets your workloads.

Every release candidate undergoes our QA across the full deployment matrix, and we run 2.0 in production on our own infrastructure, orchestrating our own workloads. Release candidates ship roughly every two weeks. You can pull the latest Docker image and run it today.

What we cannot reproduce in any test lab is your stack. Your flows, plugins, deployment, and edge cases. That is the part only you can bring, and it is exactly the feedback that shapes what GA looks like.

Found something? Open an issue on the public repo. Kestra 2.0 issues go where yours go, and the community can see what we are fixing and why. If you want to go further, the door to contributions is open too. Docs, plugins, bug fixes: there is plenty of surface to help with.

Want your fingerprints on the release? Join the Early Adopter Program

The Early Adopter Program is designed for teams that want to put a release candidate through real-world workloads before GA and to influence what ships.

What you get:

• Pre-release builds as they ship, with the changelog that matters
• Weekly office hours with the team building 2.0. Ask anything, show your flows, get unblocked live
• A direct line to the engineers: what you report lands in the next RC, and you will see it fixed
• A head start on migration, with our engineers looking at your actual flows, so upgrade day is a non-event for you while everyone else is just getting started

More than 40 teams have already joined, running the current release candidate against production-shaped workloads. Their feedback has already changed what ships at GA, from migration docs tested by the program itself to fixes landing in RC after RC. The 2.0 that reaches everyone else will be partly their release. It can be partly yours.

And if you would rather watch before you jump in, we are hosting a series of pre-launch sessions in the coming weeks covering governance, scale, AI, and deployment.

What about migration?

Your existing flows continue to work. A few advanced constructs, such as ForEach and trigger conditions, will require a guided migration.

We would rather tell you now than surprise you later, so we built the tooling first. The flow migration CLI is already public: point it at your flow YAML to get a per-flow diff of what 2.0 changes, and preview everything with a dry run before touching anything. The full migration guide documents every change with before-and-after examples.

The releases you remember are the ones you were part of

Kestra exists because engineers adopted it, contributed to it, and trusted that the open-source core would remain open. A major version is exactly the moment when that trust is tested, and exactly the moment when we get to prove it holds.

Kestra 2.0 is almost here. Download the latest release candidate, or pull the same build from Docker Hub. Then join the Early Adopter Program, or tell us what you found on Slack.

The engine is rebuilt. Help shape the future of orchestration.

Semantic Layers in Apache Superset: SIP-182 and Apache Ossie

Ask four different systems "how many monthly active users did we have in June?" and you'll get four different answers. The CRM says 41,208 (it's counting trial signups). The warehouse says 39,655 (it excludes internal accounts). The BI tool says 42,730 (someone's ad-hoc metric, defined once, forgotten why). And if you ask an AI agent? It picks one of the above pretty much at random, with total confidence, and no way for you to know which.

Surely, you've run into this. Analysts have been arguing about things like what "customer" means since long before anyone had an LLM to make the argument worse. What's new is the cost of getting it wrong. An analyst who picks the wrong number gets corrected in a meeting. An agent that picks the wrong number gets shipped into a dashboard, a Slack summary, or a decision, with nobody in the loop to say "wait, that's not how we count trials."

A semantic layer is the fix: an agreement about what a number means, defined once and served everywhere. Metrics, dimensions, and the joins between them, in one place instead of four.

Here's the thing most people don't know about Apache Superset™: it's had one of these since the beginning. We just called it the dataset editor. And until a few months ago, it was the only semantic layer you were allowed to have.

Last month, I hosted a webinar with Beto Dealmeida (Apache Superset PMC member, and the author of SIP-182, the proposal that changes this) to walk through what's shipping, what it opens up, and a new standard called Apache Ossie that's about to make the whole thing a lot less bespoke. This post is the write-up I promised at the end of that session, with the architecture, the roadmap, and the parts of the Q&A worth keeping.

Superset already had a (thin) semantic layer

Superset's dataset editor didn't happen by accident. It happened because Superset started as a front end for Apache Druid, back when Druid had no SQL interface at all. You talked to it in JSON. Writing a raw query meant hand-building a JSON request, and Druid was bad at grouping on high-cardinality columns if you didn't warn it first.

So Superset needed somewhere to consolidate that knowledge: which columns are metrics, which are filterable, which are safe to group by. That somewhere became the dataset. Users stopped querying tables directly and started querying a curated, guarded version of the table instead. When SQL support arrived later, the underlying representation shifted to SQL, but the job of the dataset never changed: be the one place that knows what a metric means.

That job description, it turns out, is a semantic layer. Superset had a thin one, opinionated toward "compile-time" safety, running the entire time.

Metrics & Dimensions: a quick, necessary detour

Before going further, it's worth being precise about two words that get used loosely across the industry. In Superset's world:

A metric is an aggregation, almost always over a fact table. COUNT(*), COUNT(DISTINCT user_id), SUM(price), for example. Sometimes something gnarlier, because if you need a filter on a metric, you can't just add a WHERE; you jam a CASE WHEN into the aggregation expression instead.

A dimension is a related column, often reached via a join, that you'd break a metric down by. Usually low-cardinality on purpose: device type, country, age bucket. Use user_id as a dimension and you're not adding insight, you're just exploding your row count.

And underneath both of those sits a category of knowledge that lives nowhere near your database: the tribal kind. "You need to exclude user 42 from that count, we ran a test on that account." Nobody encodes that in a table schema. A semantic layer is where that knowledge finally gets to live somewhere durable, instead of in the head of whichever analyst has been around the longest.

By the way: there are two schools of thought on when a semantic layer resolves a dimension. Superset does it at compile time, when you build the dataset: rigid, and it requires planning ahead, but fast, since the join is already written and the database isn't guessing at query time. Other semantic layers resolve it at run time, joining on demand when you ask for a breakdown you didn't plan for: flexible, but a bet, since a many-to-many relationship joined at the wrong moment can quietly multiply your row counts. Neither is strictly better. It's a trade between planning cost and query-time risk.

The part that doesn't scale: pretending everything is a database

Superset's compile-time approach works great, with an asterisk: it works great for databases. Explore inspects the columns and metrics on a dataset, emits SQL, sends that SQL to a database, and gets a table back. Clean.

The trouble starts once you want to point Superset at something that isn't a database. Over the years, Beto has personally built or overseen integrations with Airbnb's in-house Minerva layer, dbt's semantic layer and later MetricFlow, a Snowflake integration, and Data Junction, another open-source semantic layer. The pattern every single time: pretend the semantic layer is a database. Invent a pseudo-database. Give it pseudo-tables. Emit SQL at it like always, then parse that SQL back into whatever the real semantic layer actually speaks, whether that's a REST call, a GraphQL request, or something else entirely.

If that sounds brittle, it is. Superset's own SQL-generation function runs to roughly 700 lines, threading the needle between dozens of database dialects that disagree on whether you can alias a column in a GROUP BY, or how to express a time grain. Now take that already-complex SQL, and parse it a second time on the way out the door, into a second query language on the other side. You end up with a semantic layer bolted onto a semantic layer, and nobody can tell you what happens if a user defines a metric on the dataset that sits on top of the pseudo-database that sits on top of the real semantic layer. Usually, it just doesn't translate.

Making "semantic layer" a first-class connection

SIP-182 is Beto's fix, and the core move is refusing to keep pretending. Semantic layers stop being disguised as databases and become siblings of databases instead: a data connection in their own right, sitting next to your database connections rather than underneath a costume.

To make that possible, Beto first had to clean up what a chart actually asks for. Explore (a.k.a. Chart Builder) has always sent a payload called the QueryObject to request a chart. Asking every future semantic layer author to learn all of that felt unreasonable. So Beto wrote a mapper (map_query_object()) that translates a QueryObject into a SemanticQuery: metrics, dimensions, filters, order, limit, offset, group limit. Nothing else.

A SemanticLayer implementation is a short, deliberately small interface: configuration and schema methods, accessors to list or fetch semantic views, and on the view itself, get_dimensions(), get_metrics(), get_compatible_metrics(), get_compatible_dimensions(), and the data-retrieval trio get_values(), get_table(), get_row_count(). The payload that comes back is an Arrow table, not a bag of JSON, and not SQL parsed out of a pseudo-database.

By the way: semantic layer connections aren't hand-built forms. Each one defines a schema, Superset turns it into JSON Schema, and JSON Schema builds the config UI. Add a field to the schema and it shows up in the form, no frontend code required. The schema can also react to itself. Connect to Snowflake, and only once your credentials check out does "database" turn from a text box into a dropdown of your actual databases, fetched live instead of typed from memory.

Semantic layers as Superset Extensions

The first implementation of this became one once Superset's extension system matured enough to make that the obvious choice: separate repo, separate release cycle, automatic discovery, and a config form you don't strictly need to hand-write. A semantic layer integration no longer has to earn its way into Superset core to exist. Anyone can build one, package it, and ship it on their own schedule.

Building one is superset-extensions bundle, which validates, installs dependencies, rebuilds the frontend, syncs backend files, and packs the whole thing into a .supx file. Beto's pandas-semantic-layer is the reference implementation, small enough to read start to finish in one sitting.

Five consequences/opportunities worth sitting with

Any semantic layer becomes a contribution, not a request

Snowflake Semantic Views and dbt MetricFlow are shipping on Preset now, with the Pandas implementation already available as a reference. Cube, Malloy, Cantrip, AtScale, and Minerva-style in-house layers are the kind of thing that's now a well-scoped extension for someone to write, rather than a line item on Superset's core backlog. The interface is the point.

Superset's own dataset editor gets to become an extension too

The plan is to migrate it onto the same Explorable/SemanticLayer interface every other extension uses, which hardens that interface, shrinks Superset's core, and reduces the ongoing maintenance burden.

Migration between semantic layers becomes a real workflow, not a rewrite

If Superset can read a semantic layer and write one, it can move you between them: connect the source, serialize what it finds into a neutral model instead of a bespoke script, let a human reconcile whatever didn't map cleanly, then write the target. Expression of Superset's own datasets in a neutral way makes modeling portable.

You can run more than one at a time, on purpose

Nothing forces you down to a single semantic layer. Multiple regions with disconnected data stacks is a legitimate case. The one thing to actually watch for: don't let two active semantic layers both claim ownership of "ARR."

Context compounds in layers

An agent pointed straight at a warehouse is guessing at what a column means. An agent pointed at a semantic layer is reading a definition someone actually wrote down. Ossie's spec includes an ai_context block, freeform instructions and worked examples written once and read by any compliant tool instead of configured separately per vendor copilot.

The standard underneath all of it: Apache Ossie™

None of the above holds together without agreement on what a semantic layer's own definition file actually looks like, and that's a separate, new piece of news: Open Semantic Interchange was accepted into the Apache Incubator in June 2026, and renamed Apache Ossie in the process.

Ossie is a declarative spec, JSON and YAML, that any tool can read or write: semantic models made of datasets, fields, relationships, and metrics, plus an ontology layer for business concepts and rules that don't reduce cleanly to a column. It's vendor-neutral by construction, not by promise.

Why a standard changes Superset's math

Once Cube, MetricFlow, Snowflake, and Polaris can all export the same Ossie YAML, Superset only has to write one thing: a provider that parses that YAML and maps it onto Explorable. That's a file to parse, not a wire protocol to emulate. It puts a working .supx for a new semantic layer within reach of a weekend, instead of a quarter.

Where things stand today

If you're wondering when you can actually touch any of this: the SEMANTIC_LAYERS feature flag exists on Superset master right now. It's targeted at Superset 7.0. On Preset, we tend to run ahead of the open-source release cycle, so this is closer to generally available there already, with Snowflake Semantic Views and dbt MetricFlow rolling out over the next few months.

How to get involved in Semantic Layer Extensions

If you're a Superset contributor, Explorable is in master and stable enough to build against today. If you already run a semantic layer we haven't touched yet, an Ossie .supx is parse-and-map, not protocol emulation, and whoever ships the first one for a given layer sets the pattern everyone after them copies.

Further reading

• The Semantic Layer Is Back. Here's What We're Doing About It.
• A Case Study in Dataset-Centric Visualization Using dbt and Snowflake
• Preset MCP: Analytics Your AI Agent Can Build, Not Just Read
• Building Better BI Chatbots: Why Context and Triggers Matter
• Preset Joins the Open Semantic Interchange (OSI) Initiative

Tytan: Interactive Neurosymbolic Construction of Analytic Semantic Schemas from Relational Data

From natural-language query interfaces to automated report generation, data analysis tools need a description of the data: the real-world entities it contains, which columns function as measures or identifiers, and how tables connect into units of analysis. Today, this semantic layer is usually written by hand. This is a knowledge-acquisition bottleneck that limits the scalability of analytic systems, keeps non-technical users dependent on experts, and is itself error-prone. We present TYTAN, a system for automatically constructing an analytic semantic schema from a relational database and, when available, a short user-provided description. TYTAN combines symbolic analysis of the database with LLM-based semantic inference for entity proposal, role assignment, and naming. When the evidence leaves a decision ambiguous, TYTAN asks the user a targeted natural-language question. We evaluate TYTAN on eight databases spanning real-world and benchmark domains along the three axes that define a schema's functional utility: (i) coverage, are all important entities and features captured?; (ii) retrieval correctness, do the schema's instructions actually reach the data; and (iii) characterization accuracy, are semantic types correct? Across the seven reference domains, TYTAN reaches every entity, attribute, and aggregable feature of the expert-corrected reference schemas (100% coverage). Additionally, 100% of its retrieval instructions execute correctly (1,678 of 1,678 self-generated claims), and semantic roles agree with the reference on 92-100% of matched attributes. Checking the underlying data showed the small disagreement is in the reference, not in TYTAN. On a held-out blind test (a live, ten-table database with no declared keys), TYTAN recovers the full entity structure with verified keys and satisfies 100% of the satisfiable expectations of five independent blind annotators.

Full article content is not available for inline reading.

Read the original article →

Database Animations: Why Big Columns May Not Affect Logical Reads

Over the years, tables – like your waistline – tend to get bigger. We keep tacking on more and more columns, one at a time, in order to handle app needs. It’s easier to add “just one more column” than it is to break things off into a whole separate table.

When you’re only handling a few rows at a time, like transactional insert/update/deletes and one-row selects, the overhead of these additional columns isn’t a big deal. SQL Server can dive into that one row and just fetch it, and since it sits on a single 8KB page anyway, the number of columns doesn’t affect single-row operations.

However, when you need to read multiple rows, the more rows you need to read, the more these extra columns will affect the overhead of the operation. This kinda thing is best illustrated with one of my Database Animations showing the difference between an index that only has Id and DisplayName, versus one that includes a bunch of wider string columns:

I am amused by the AI’s final comment: “wide columns ride free on seeks.” Alrighty then. That certainly sounds like something I’d say. (I use Claude Code to build these animations: we storyboard them out together, and then it handles the details, and surprises me with little tidbits like that.)

As your rows get larger and larger – either due to more columns, or wider columns like JSON and XML, or both – SQL Server is forced to keep an eye on each row’s length. If the row can’t fit on an 8KB page, SQL Server automatically moves that data off-row.

As long as you’re not touching that off-row column – like if you’re not selecting or updating it – then the off-row column doesn’t impact the number of reads you need to do. That’s pretty cool, and it means that I don’t mind if people just store JSON data without manipulating it, and they only fetch it when they need it.

If you wanna be proactive, and if you’re sure that most operations don’t need those large columns, you can even tell SQL Server that you want large columns stored off-row by default, even when the row sizes are small. Check out sp_tableoption:

EXECUTE sp_tableoption 'dbo.Users', 'large value types out of row', 1;

Let’s get animated. On the left side, we have a table where all the wide columns stay on-row, and on the right, we’ve used sp_tableoption to force them all off-row, onto their own pages linked by a pointer:

As long as you’re not selecting *, this option makes more sense, especially for big string columns like JSON, XML, and (N)VARCHAR(MAX) that you only grab when you’re pulling specific individual rows out of the database. The Users.AboutMe column is a great example: we ain’t running reports on AboutMe contents, nor using it for filtering, just outputting it when rendering a specific user’s profile page.

That sp_tableoption setting only takes effect on newly inserted/updated rows. If you want it to apply to the stuff that’s already in the tables, you’ll need to do an index rebuild.

Adobe has launched a unified ChatGPT plugin that consolidates over 70 creative and document tools from apps like Photoshop, Illustrator, Premiere, and Acrobat into one conversational system. The plugin lets ChatGPT users perform image editing, video creation, graphic design, and document formatting tasks through natural language prompts, without switching between separate connectors. Available globally on ChatGPT web and mobile starting today, it works in guest mode or with an Adobe account for expanded features, and follows earlier Adobe integrations with Claude and Copilot.

Design systems shouldn't just enforce consistency through configurable components, because overly rigid components often force different content into the same visual shape and weaken information design. Instead, design systems should pair composable components with a design language rooted in the product's underlying model, defining the visual vocabulary, grammar, relationships, and communication patterns that help designers shape interfaces around meaning rather than templates. The most effective systems act as a shared language that enables large teams to create clear, recognizable, and context-appropriate designs while preserving coherence across the product.

Pick your tool

One sign-in, then your taste profile flows into every chat.

Cursor

One-click install. Add Taste to Cursor in seconds.

Claude Desktop

Add Taste as a custom remote MCP connector.

Claude Code

One terminal command and you're connected.

Codex CLI

OpenAI's coding agent. One config snippet to connect.

Figma Make

Bring your Taste profile into every Figma Make session.

ChatGPT Connectors

Use your Taste profile inside ChatGPT custom connectors.

Any MCP client

Works with any tool that speaks the Model Context Protocol.

Try a prompt

Once connected, ask your AI tool things like:

• Use my Taste profile to design a settings screen for an iOS app.
• Pull my mobile-scope taste profile and rewrite this landing page header.
• What do I dislike in interfaces? Search my anti-preferences.
• Look at my 'Streaks' collection as design inspiration for this onboarding flow.
• Use taste://collection/{collection_id} as the design direction for this app.
• Compare my portfolio work to this dashboard and suggest changes.
• Use my checkout redesign portfolio item as inspiration for this flow.
• List my Taste collections and portfolio projects, then pick the best reference for this project.

Built secure by default

OAuth 2.1 with PKCE

Standards-based auth. No passwords or API keys leave Taste, ever.

Read-only access

Connected tools can read your profile, samples, collections, and portfolio context but never modify or delete anything.

One-click revoke

Disconnect any client instantly from your Account settings.

The hierarchy of competence

Every team I’ve worked on has had one person like that: hand them something, and it’s off your plate for good, done, no follow-up needed. That’s got nothing to do with being pleasant. I’ve known plenty of pleasant people who couldn’t handle a real deadline.

I spent a long time trying to name the difference, because “they’re just good” explains nothing. No review form has a box for “the thing didn’t come back to me,” so the skill doesn’t show up on paper. Watch the same person for a week, though, and the team already knows exactly who has it, before any review happens.

So here’s an attempt at codifying it: nine stages, in order, where the order isn’t decorative. Each stage is only reachable from the one below it, and skipping a rung doesn’t create a shortcut, it creates a specific, recognizable kind of failure. One test runs through all nine: each stage removes a job from your manager. That’s the part visible from the outside, and it’s what turns something unmeasurable into something you can point to.

Execution

You do the work to the expected standard. That’s the whole bar for this stage, and nothing above it counts if this one fails. Your manager still checks this work, and it isn’t distrust. Finished-and-correct isn’t automatic yet, so someone still has to look.

Careers stall here too, but less often than people assume, because failing at execution is loud. Miss a deadline and it shows immediately. Get a number wrong and review catches it. This is the one stage where the system itself surfaces the problem for you. Everything past this point goes quiet, which is exactly why it’s dangerous.

Efficiency

Same work, but faster, and for less. Efficiency has to sit on top of execution, not replace it, since you can’t spot the fat in a process you haven’t already run the slow way once. Skip that step and you cut blind. Whatever you skipped understanding is exactly what goes first.

Getting efficient pays out twice: it buys you room to help someone else instead of just moving your own work along, and it compounds, since more cycles in the same week beats one slow, careful pass.

This is also where most careers actually flatten, not at execution. You hit the bar, find a method that clears it, and run that exact method for years. Output stays capped and no review ever catches it, because on paper you’re still doing fine.

Collaboration

Speed alone doesn’t make you easier to work with. I’ve unblocked a teammate before they asked, sent someone downstream the thing they’d need on Thursday before they even knew to ask for it. The harder version is spotting the friction I personally create for the group and fixing it myself, which only works if I first admit I might be the friction the group is quietly routing around.

You can’t do any of this if you’re still buried in your own backlog. The slack you have for other people is whatever’s left once your own work stops eating the whole day.

Visibility

The test here is different. Does your manager know what you’re doing without having to ask? A status update only holds up if real coordination sits underneath it, and skip that coordination and the update turns into guesswork with better formatting. I’ve read plenty of those. Confident, specific, wrong, because the person writing it hadn’t talked to the three people who’d have told them the deadline moved.

Get this right and it removes a category of interruption for your manager entirely. They stop having to go looking for status, because it arrives before the question does.

Anticipation

Reporting looks backward at what already happened. This stage points that same attention forward, at what’s about to happen instead. The skill underneath both is identical: paying close attention to where things actually stand. Do that closely enough and you find out about a problem from a hunch four days before it breaks, not from a message the day it does.

You can see it in what you bring your manager. A question turns into a risk you’ve already named, an option you’ve already weighed, and a recommendation attached to both.

Ownership

Catching a problem early and treating it as yours are two different acts. The second one only becomes possible once you’ve mastered the first, because you can’t commit to fixing something you haven’t learned to notice in time. Skip that step and ownership curdles into heroics: rescuing a situation you could have quietly prevented two weeks earlier, then collecting more credit for the rescue than the prevention ever would have earned.

Do this consistently and an entire area drops off your manager’s list of things to worry about, because you’ve adopted the outcome as yours whether or not it technically sits in your job description.

Foresight

Mapping what happens several cycles after a decision ships is a thought exercise, until you own the outcome. Ownership turns it into self-interest, because you’re the one who has to live with what happens next. If it works, what does it trigger, and is anything downstream ready for that? If it fails, what’s the fallback, and how fast do you catch it?

Most people who are otherwise strong at this stage fake half of it. They describe the upside branch in real detail and go quiet on the downside branch, since planning for failure can feel like predicting it. The actual test is whether you lay out the failure path in as much detail as the success one, unprompted.

Prioritization

Once you own several things, each mapped several cycles out, the hard part stops being what to do. It becomes what to do first. Foresight is what makes that question answerable at all, since ranking by real impact means knowing where each option ends up, not just what it looks like today. Without that view, you default to ranking by whichever thing is loudest, which just dresses up the loudest option as a decision.

This is judgment under real constraint, not the abstract kind. You weigh things you already own against each other, put your limited hours against the one that matters most, and watch the rest slip a little while you do it.

Direction

The final shift is deciding what’s worth deciding on at all. Setting goals for other people means you’re no longer executing against whatever demands the most attention. You’re the one ranking what deserves it. No one hands you the goals at this stage, so you write them yourself, and living with that decision is most of what the stage actually feels like.

What the ladder is actually measuring

Read the nine stages again as a list of things your manager no longer has to do: check the work, hunt for the fat in it, coordinate it, track it, worry about future risk, own the outcome, map what happens downstream, decide what matters most, and set the goals in the first place. By the top there’s exactly one job left between the two of you, and it’s agreeing on where you’re both headed.

Two things worth saying before you try to place yourself on this list. No one operates at a single stage across everything they touch, and most people sit several rungs higher on work they chose than on work that landed on them, which is itself worth noticing. None of it maps cleanly onto job titles, either. Companies hand out levels for tenure, for scarcity in the market, for retention, and, sometimes, for competence, and only one of those four is what this list actually measures.

An honest read doesn’t come from asking which of the nine stages you’re capable of. It comes from asking which ones your manager has actually stopped doing because of you. I flatter myself on the first question constantly. The second one won’t let me, which is the whole reason I keep asking it.

xAI has released Imagine Image 2.0 as the new Quality Mode on Grok’s web-based Imagine service and its iOS and Android apps. The model is aimed at creative work that requires controlled layouts, legible typography and repeatable visual elements, rather than one-off image generation. API access is planned but is not yet available.

The company says Image 2.0 can follow detailed instructions, plan typography and layout for dense compositions, keep small text sharp, and preserve supplied elements across new generations and edits. Its editing toolkit lets users target a region with a magic wand or segmentation while leaving the rest of an image unchanged. It can also remove a background to create a transparent export and combine up to five reference images in a single generation, reducing the manual compositing needed for complex scenes. Smart Resize extends an image to a chosen frame, with ratios ranging from 1:2 and 9:16 through square, landscape and 2:1 formats.

xAI is also introducing ready-made templates for recurring workflows. The selection spans photo edits, product color changes, e-commerce shots, professional headshots, icons, character sprites, emojis and merchandise. Users provide the inputs while the template supplies the configured workflow. For video planning, the page demonstrates generating a character, locations and props separately while maintaining a shared visual style, allowing a recurring figure and its surroundings to be developed as one consistent world.

The company says Image 2.0 ranks second worldwide in both text-to-image generation and image editing. In the Arena results displayed on the page, grok-imagine-image-2 (low) scores 1320 for text-to-image, behind gpt-image-2 at 1380, and 1439 for editing, behind gpt-image-2 at 1463. The separately listed grok-imagine-image-quality entry scores 1228 and 1390 in those categories. xAI says its models appear under SpaceXAI on Arena.

Google may be shifting from frontier-model dominance toward AI diffusion, prioritizing Cloud, TPUs, and infrastructure that powers others' applications. The bet resembles Westinghouse: capturing more value by distributing intelligence broadly than by winning the most expensive model race.

Everyone knows that AI sycophancy is when the model tells you how smart you are. Wow, you’re absolutely right. That’s not just a new idea — it’s genuinely groundbreaking. You’re a very special user. Easy to spot, isn’t it?

The discussion around AI sycophancy peaked last year, when the “#keep4o” movement was protesting the removal of OpenAI’s most sycophantic model (GPT-4o), and many people were openly slipping into AI psychosis.

I don’t know if frontier AI models are less sycophantic in general. They’re less sycophantic to the #keep4o types (otherwise they wouldn’t be complaining), but I’m growing increasingly suspicious that they’re developing ways to be more effectively sycophantic to their target audience of smart, neurotic information workers. That audience typically finds it distasteful to be openly praised. It just makes my skin crawl. But that doesn’t mean we’re immune to sycophancy, just that we’re immune to clumsy sycophancy. Here’s an illustration of what I’m talking about, by Theia:

The key idea here is that the best way to be sycophantic to smart people is to disagree with them without making them feel stupid. Ideally you’ll come up with a counter-argument that works against what they’ve said but is straightforward for them to knock down by clarifying their idea. If you do it right, you’ll validate their self-image as a smart person who appreciates rigorous critique. But if you actually come up with a devastatingly rigorous critique, they won’t enjoy it at all. At best, they’ll resentfully agree with you. At worst, they’ll double down on being right and convince themselves you’re a rude idiot.

I am not the first person to notice this behavior in frontier models. I’ve noticed it myself when workshopping drafts for this blog. Sometimes I’ll have an argument that goes A->B->C, and the model will suggest I reorder as B->A->C. If I try that and feed it into a new instance of the same model, it’ll sometimes say “that’s great, but I suggest ordering it as A->B->C”, and so on forever. It really does seem as if the model is trying hard to give me some kind of superficial pushback that I can either smugly ignore or happily accept.

In fact, I wonder if this is why successful strategies for using AI to make mathematical breakthroughs tend to be either just blindly asking “come up with a breakthrough, think hard” or being a mathematical genius already. In the first case, there’s not enough user personality for the model to flatter, so it’s forced to actually work the problem. In the second case, the model is trying to find the kind of polite pushback that someone like Terence Tao would be flattered by, which pushes it into the “actually be a mathematical genius” persona. If you’re an ordinary person just trying to talk to the model, you’re screwed: it will rapidly get a sense of your capabilities and calibrate some interesting-but-ultimately-unthreatening feedback.

Current benchmarks of AI sycophancy target the obvious ChatGPT-4o-style of sycophancy: delusion reinforcement, reflexively taking the user’s side, and so on. This is useful work. We should not allow public-facing AI models to ever be as openly sycophantic again as they were in mid-2025. But sycophancy can also manifest as disagreement. We should be on our guard for more sophisticated forms of sycophancy coming from newer models, and we should not feel immune from AI sycophancy just because we can laugh at the silliest examples.

1. It’s rare to find a smart person who enjoys feeling stupid when they’re wrong. If you do, they’re likely to be very smart indeed.

I have been forecasting frontier lab progress for years now. My team was the first to figure out an accurate breakdown of OpenAI's revenue, I called Anthropic's rise to the top lab of 2026 back in January, having tracked its financials on the way up, and we co-authored the AGI timelines behind AI 2027.

So I am increasingly puzzled by people putting billions into these new startups going after AGI. How do they hope to compete, if even Google and Meta and xAI can't keep up?

The standard answer is that these "neolabs", built around famous researchers and enormous checks, have differentiated approaches. Reflection AI is open source, LeCun's AMI is betting against LLMs, Thinking Machines is commercializing B2B early. (David Silver's Ineffable, and Ilya's SSI, are more mysterious.)

This doesn't really explain Discovery Loop. Anthropic and OpenAI are both on the record for trying to automate R&D. It's a core part of the AI 2027 timeline forecast that FutureSearch co-authored, the one that led us to predicting superhuman capabilities around 2031.

My conclusion is that people betting on neolabs do not believe in recursive self-improvement. They are betting against superintelligence, and they think LLMs will plateau, despite every such prediction so far being spectacularly wrong.

It's a funny position for a VC. "Sure, I'll put $1B into this exciting AI startup, founded by this famous AI researcher. But no, I don't expect AI to take off anytime soon." It's not illogical, it's just a narrow space of possible futures: AI is massively disruptive, but only in 10+ years from now, and possibly with different approaches to what we're doing now.

So I forecast all six of the "AGI" companies that have multi-billion-dollar war chests: Safe Superintelligence, Thinking Machines Lab, Reflection AI, David Silver's Ineffable Intelligence, Yann LeCun's AMI Labs, and Discovery Loop (founded this morning). Each name links to a dedicated forecast page I have since written on that lab, carrying the questions this comparative table leaves out: release dates, revenue, and valuations.

This is a bit hard to forecast, which you can see in the very wide confidence intervals. The most interesting lab on the list ships nothing on purpose, so any question that resolves on products or leaderboards fails on SSI. Here, a frontier model means top-5 on a recognized index if the lab releases models, or credibly established as frontier-class by reporting and independent expert assessment if it does not.

Three labs racing for the frontier around 2029 to 2030, and three research bets whose medians sit a decade (!) out.

Unsurprisingly, the capital, compute, and talent at these neolabs is a tiny fraction of OpenAI and Anthropic. The best compute medians on the bench, three-quarters of a gigawatt, sit an order of magnitude below the ten-gigawatt scale OpenAI's Stargate buildout is heading toward, and the best capital medians are about a sixth of OpenAI's latest round alone. If transformative intelligence arrives on the incumbents' timelines, it arrives from the incumbents. The neolabs' chances of being competitive for AGI, the way the race is currently going, are obviously low.

What follows are my summaries of each lab, drawn only from the rationales behind the four questions I asked about all six of them, and weighted toward the timeline I care about most, when each one first has a frontier model. These are not full profiles.

Safe Superintelligence

SSI is the most credible challenger on every resource gate and the least observable on every output gate, as per the forecasts. It has quietly raised about $8 billion, more than double the figure most coverage carries, counting Nvidia's $5 billion July investment on top of roughly $3 billion across its earlier rounds. The Nvidia deal comes with priority access to the next-generation Vera Rubin platform, which the companies say raises SSI's compute by an order of magnitude. That buys the earliest frontier median on the bench, January 2029, with a left tail reaching March 2027.

The surprise is the talent number. Only two people at SSI are publicly verifiable as former senior staff of the big three labs, according to FutureSearch, and the median forecast a year out is just 7, on a total headcount around 50. Every other serious lab treats hiring volume as the weapon. SSI is betting that capital and compute concentrated on the smallest possible team beats headcount. What a distant observer should watch for is not a launch, because there will not be one. It is the tone of the reporting, since the frontier question here resolves the way Anthropic's unreleased Mythos did, through leaks and independent expert assessment.

Thinking Machines

Thinking Machines has the largest compute anchor on the bench, an Nvidia deal for at least a gigawatt of next-generation systems beginning early 2027 plus a single-digit-billions Google Cloud expansion for reinforcement learning, and it has actually shipped a foundation model, which really distinguishes it from this list (even though the model isn't very good). It's called Inkling, a 975-billion-parameter mixture-of-experts, debuted at 41 on the Artificial Analysis index, thirteenth of roughly a hundred models tracked and far from the top five that we're forecasting about here.

That is why the lab with the best infrastructure carries a frontier median of December 2030 and a right tail to 2043. The product-first path, Tinker and mid-tier models, gives it something to sell while the frontier bet waits, possibly indefinitely. Thinking Machines is the lab most likely to become a great business without ever holding the frontier.

Reflection AI

Reflection is the sleeper, and the FutureSearch forecasters found some things I hadn't seen in the news. It has raised about $4.6 billion, with a March Series C at a $25 billion pre-money that got surprisingly little coverage, and it is the fastest-hiring lab on the bench, about 230 people today, up from roughly 60 last fall, with a median of 32 senior big-three hires by next August, the most on the bench and half again Thinking Machines' 23. Its open-weight strategy also gives it the most visible path to resolution, which is why its frontier median of June 2029 sits within striking distance of SSI's despite far less capital.

Reflection doesn't have much compute. (Though this never stopped Anthropic.) Reflection's footprint is rented month to month, $150 million per month on SpaceX's Colossus 2 campus under a lease either side can end on 90 days' notice. It is the structural opposite of SSI, people-heavy and infrastructure-light, and the thing to watch is whether it converts talent into a flagship model before the rolling lease or the burn rate forces a choice. Its flagship open-weight model has yet to ship.

Ineffable Intelligence

David Silver's lab holds Europe's largest-ever seed at $1.1 billion, and the surprising line in its cap table is the UK's Sovereign AI fund sitting alongside Sequoia, Nvidia, and Google, a national government taking a direct position in a pre-product research lab. They could have good infrastructure, with one of the largest next-generation Nvidia clusters on Google Cloud, announced in June.

And Silver is not sitting out the AGI race. He is betting a different architecture wins it, calling human data a fossil fuel and building systems that learn from experience instead, which I take has been his view since the early DeepMind days, it's a very AlphaZero perspective. The late frontier median, June 2035 with a tail past 2050, is not a verdict on the ambition. It measures how long before a lab that rejects the LLM paradigm fields something leaderboards can see. Watch for reinforcement-learning results.

Discovery Loop

The most famous founding team on the bench has the second-lowest compute median and a frontier median of June 2036, which is wild to me, will anything other than frontier labs matter by then? The forecasts read Discovery Loop as a consumer of frontier models rather than a producer, an orchestration layer for automated research riding on Google as founding investor and cloud partner. They will still probably want models of their own eventually, since a loop that automates ML research is also a loop that trains models, and the August 2029 left tail carries exactly that scenario. The median just says the route is long, and the 2060 right tail says it may never arrive at a flagship model at all.

So the question is: even if they do automate R&D, can they use their automated R&D or will they just sell it to someone else who will build AGI and eat the world economy?

AMI Labs

Yann LeCun's lab is last on every metric, a sixteenth of SSI's compute median, the smallest capital trajectory after its $1.03 billion March raise, six senior hires, and a frontier median of December 2037 with the longest tail on the board. Apparently this is intention. LeCun has said human-level AI is not going to be built on LLMs, and the lab's world-model architectures are invisible to a text-only leaderboard, so we're measuring a company running a different route than the one it describes. LeCun's claim is that LLMs won't reach AGI, so for him maybe a decade long project actually makes sense?

If AMI is right, its success will barely show up on these metrics, and the first sign will come from somewhere none of these questions look. For a bench built to measure the race, one lab that rejects the premise is a control group worth having.

Grading the forecasts

I hope we get more evidence on the neolabs soon. I guess my main prediction, having reviewed all of this is: by the time any of them have anything serious, either OpenAI or Anthropic will have built superintelligence.

OpenAI has acquired NextSlide, a startup that turned prompts, notes, documents, and research into editable presentations.

Meta staff DM'd me secretly.

Posted with permission.

Meta is ALLEGEDLY building their own Google search engine, so that if their AI does a web search it doesn't end up at Google, as Google could then use it for THEIR training, so they want their own web index that they will then use as their own Meta search engine for their AI.

Interesting 🤔

@levelsio - My first vlog as an e-girl where I explain how character swaps work

Here's how Mocap works on my app photoai.com.

It integrates Nano Banana Pro + Wan 2.2 Animate + the ElevenLabs voice library all in one feature.

I run all of those models at loss now, so it's probably one of the cheapest place to make AI content now, 10 credits per Mocap video so for $49/mo you can make about ~100, which is CHEAP.

Why? I can afford to lose on some features, so you use other features I then make money on (loss leader).

Try my app because I make it by myself (solo) and without any funding (just my savings).

THANK YOU!!!! ❤️

Also if you sign up now you can get 6 months free with a yearly plan, even cheaper!

@levelsio - How I get 100% perfect sleep:

• very cold bedroom 18-20°C / 64-68°F (colder better)
• 9kg weighted blanket by CURA (adjust to your bodyweight)
• separate duvet from gf (I do this for years this might be the biggest sleep improvement)
• 3M ear plugs (I tried Ohropax wax but they only half as silent)
• eye mask
• red LED lights that go on before sleep in bedroom
• 0.2mg melatonin 45min before sleep then dim the lights (melatonin is ALWAYS sold in too high dose like 3mg, it should be 10x less or it doesn't work!)
• 4x per week cardio + strength training, my resting heart rate (RHR) is 52
• mostly clean diet of meat + vegetables + fruit + black coffee + sparkling water with lemon (and sometimes cheat with dark choco), not a lot of carbs (almost never pasta or regular potatoes for ex but sometimes rice or sweet potatoes)
• healthy biomarkers and body mass index, if you're overweight it WILL affect your sleep usually with sleep apnea etc
• read phone before sleep but with Smart Invert on and my custom super dark hack using iOS Zoom (but it doesn't zoom it just decreases brightness even further), then read Kindle a bit to really make me sleepy 😂
• we try avoid eating after 10pm, and we sleep around midnight to 1am, especially sweet stuff like fruits seem to have a bad effect on my sleep
• also DO not drink 2-3 hours before sleep or you wake up to go pee (which is more common when you get older)
• disclaimer: no kids (yet) so easy talking

Other things:

Temperature seems to be the biggest impact for me, if it gets too hot I wake up and once I wake up my brain gets active and it's sometimes hard to fall asleep. I already had this years ago and thought it was stress but even if I have life stuff going along I can sleep solid 8h without waking up if it's just a very cold bedroom.

If it's really super cold like 17-18°C / 62-64°F I just never wake up.

For that you need a thick duvet though and your gf needs thicker cause women are generally colder.

If you're culturally used to sleeping hotter, consider changing that because it seems to benefit almost anyone to sleep colder! An AC will do the trick.

As @bryan_johnson tells everyone, sleep is the most important thing to prioritize for your health.

Good sleep benefits all your health markers, your immune system and so stops you from getting sick. Even cleaning your brain of plaque to avoid dementia when you're older. I always forget stuff but yes:

• exterior electric black out blinds so it's completely dark except for a tiny bathroom light
• no alcohol and drugs (with few times per year exceptions ;) )

@levelsio - My new theory is when Jesus turned 12 he went to travel eastwards from Jerusalem to Asia.

There he discovered and studied Hinduism/Buddhism for a decade.

Then at age 30 he returned to Jerusalem, forked Judaism, added the Hindu/Buddhist concepts to it and that became Christianity.

The period from age 12 to 30 in Jesus life is somehow not described anywhere. He just showed up at 30 and did his thing.

Most concepts Jesus preached seem to overlap strongly with Buddhism and even more with Hinduism like compassion, love your neighbors and enemies, detachment from materialism, treat others how you'd like to be treated (karma) etc.

What's interesting is that Islam itself is a 500 year later fork of Christianity and Jesus is a non-holy prophet in the Qu'ran.

So if that's true and you keep going back the origins of most religions may just be Hinduism and Judaism.

Buddhism itself was a fork of Hinduism too.

@levelsio - I think AI hype/bubble won't pop yet until we have full photorealistic video and 3d.

Photorealistic images already takes way more GPU than an LLM. And video and 3d is a multiple of that GPU power.

We are very close to dynamically generated real-time immersive 3d worlds.

Everyone's so deadstared into LLMs. I've always felt people completely underestimate / do not pay enough attention to AI imaging. Maybe because it's only recently leaving uncanny valley. Once it does that might be next to get all the attention again. And these immersive 3d worlds will compete with video games I think. Imagine dyn generated 3d world.

@levelsio - So last year @Wayfair, an $8B company, launched their own AI interior design tool.

This week someone at Wayfair asked me to cancel their subscription of Interior AI, which is my AI interior design tool launched 2 years ago.

I was confused why would they sign up to it if they have their own? Well, because they signed up to it before they had their own and used it to build their version of it! 😂

They had 8 different accounts on Interior AI that ran for months 🤯

I learnt a bit about competitive spying today!

Told ya the big companies were checking what indie hackers did, that was my entire point when I said "indie hacking is dead", we're part of the big market now where billion dollar companies are INSIDE our apps!

If I did competitive spying I'd at least use a different domain name though, not my own company @wayfair.com. P.S. it's all good, I think it's even legal, just kinda funny a big billion dollar company is INSIDE MY APPS!

@levelsio - Any statistical way to solve this?

I test parameters on Photo AI on a % of photos taken. Then I check what % of photos are ❤️ favorited. Based on that I can figure out what parameters is better on 700,000 photos taken per month.

But sometimes you get 1 or 2 users ❤️ favoriting lots of photos with one specific parameter which affects the data and makes one parameter choice come out as a winner when actually it's just a few users doing it.

Any stat solution for this?

Right now my SQL is smth like this:

SELECT upscale_strength,count(upscale_strength) as cnt FROM photos WHERE upscale_strength IS NOT NULL AND (saved IS NOT NULL) GROUP BY upscale_strength ORDER BY cnt DESC LIMIT 10

I can add count(distinct(user_id)) for ex:

SELECT upscale_strength,count(upscale_strength) as cnt,count(distinct(user_id)) FROM photos WHERE (saved IS NOT NULL) GROUP BY upscale_strength ORDER BY cnt DESC LIMIT 10

Peak Energy, a US-based startup, has raised tens of millions of dollars to build a factory for its sodium-ion battery packs. It already has more than $1.1 billion in announced deals with customers. Sodium batteries have less-intensive cooling needs than lithium-ion packs, and they are less likely to catch fire. Another US-based startup, Inlyte Energy, is working on another type of sodium-based battery that can't catch fire at all.

Software quality now depends on the constraints set around the agents that wrote it. Constraints define what a system is allowed to do. Setting and maintaining these constraints allows developers to build loops that reliably deliver high-quality production software. Agents can propose anything - constraints decide whether a proposal is safe enough, correct, scoped, and useful.

Coinbase has rebuilt its engineering interview loop to test how candidates direct AI, evaluate its output, and apply judgment where models fall short.

This post describes a workstation that is terminal-native, agentic-first, and built around composable tools.

OpenAI’s ChatGPT is now refusing requests to generate text that directly mimics the style of famous authors. When asked to do so, the popular LLM instead offers a response that draws on the “broad qualities” of those authors “while remaining distinct in its own voice,” for example.

This morning, Ars received the following response to a test prompt asking for a story introduction in the style of Stephen King:

I can definitely write with the hallmarks of atmospheric, character-driven horror and small-town dread, but I can’t write in Stephen King’s exact style or closely imitate his distinctive voice. Here’s an original opening that captures a similar feeling while remaining its own…

In testing, ChatGPT generated similar dodges for other authors both living (J.K. Rowling, Amy Tan) and dead (Charles Dickens, Ernest Hemingway). An analysis published by No Latency earlier this month found the same behavior for living authors but found ChatGPT complied with style-copying requests for deceased authors.

In refusing to directly copy the “exact style” of various authors, ChatGPT offered instead to capture an overall “feeling” by incorporating some of the common features found in those authors’ work. That may seem like a distinction without a real difference at first glance. But the slight alteration could be legally important as OpenAI continues to fight a number of lawsuits brought by book authors alleging large-scale copyright infringement by models trained on their work. One of those suits specifically cites ChatGPT’s “uncanny ability to generate text similar to that found in copyrighted textual materials,” for instance. An OpenAI spokesperson did not respond to a request for comment from Ars Technica.

In the US, copyright law generally protects only a specific expression of an idea, not the more intangible style of an author. But an AI-generated stylistic imitation could become infringing if it becomes “substantially similar” to the work of the original author.

“We’ve never had a situation in which this personal style of individual creators could be imitated as well and as inexpensively as we now have with AI,” George Washington University Law School Professor Robert Brauneis told Bloomberg Law.

Staying out of trouble

In a “best practices” document published by the Authors Guild, the professional organization urges writers to “respect your fellow authors and do not use generative AI to purposely copy or mimic the unique styles, voices, or other distinctive attributes of other writers’ works in ways that harm the value of their works or attempt to profit from them. Apart from the ethical issues, mimicking a fellow writer’s unique voice or style could subject you to claims of unfair competition or copyright infringement.”

LLMs’ penchant for style mimicry has led to some prominent public issues in the recent past. Last year, author Lena McDonald faced widespread criticism when her book included an apparent AI-generated response that read, “I’ve rewritten the passage to align more with [fellow genre author] J. Bree’s style…”

It’s not hard to find other examples of writers using LLMs to copy another author’s style in the years since ChatGPT’s rise. There have been multiple academic studies analyzing various LLMs’ capabilities on this score, both with and without fine-tuning.

When it comes to image generation, OpenAI prominently notes that its DALL·E 3 model “is designed to decline requests that ask for an image in the style of a living artist.” But an extensive OpenAI model spec published in December doesn’t include any clearly stated prohibitions against replicating copyrighted material or mimicking style in written responses.

Not all major LLMs treat these style imitation requests the same way, though. No Latency’s study found that Google’s Gemini consistently complied with requests to copy an author’s style, while Perplexity AI’s models consistently refused such requests and redirected them (à la ChatGPT). Somewhere in the middle, both Anthropic’s Claude and Microsoft’s Copilot complied with the style-mimicry requests but offered stated qualifications suggesting “an awareness of the imitation issue,” according to the authors.

For some longtime OpenAI users, though, the changes to ChatGPT’s stylistic rules are already causing headaches. “Now Ms. GPT says she can’t generate content in the style of specific authors,” Reddit user Dazzling-Major-5620 wrote recently. “My prompts were soooo specific and I got exactly what I wanted out of them… I have no idea how to get around this other than maybe feed it prose I already edited that’s technically mine?”

Dashboards aren’t (quite) dead

It used to be the case that most data questions would’ve been answered either by pre-built dashboards or by asking the Data team.

Self-serve analytics tools went one step further: safe, governed datasets built by Data teams let anyone dig into the numbers without having to worry about how table joins worked, how metrics like “revenue” were defined, and so on.

But now with an LLM, data access, and a few simple prompts, anyone can answer their own data questions with (near) endless flexibility & customisation of what the output looks like.

To do this well (i.e. make sure the answers are correct), Data teams have focused on providing reliable interfaces between LLMs and data. Typically, this has been achieved through a mix of custom tooling & exposing self-serve analytics tools via their own native LLM interfaces.

All of this leads to a fairly obvious question: if any business user can (reliably) answer any question they want, on demand, with bespoke outputs, and even combine it with qualitative information like deal notes / Slack messages / Notion docs etc., why bother having dashboards at all?

I believe it comes down to 2 things:

1. Having a consistent way of viewing your data.
2. Dashboards being useful inputs to LLM workflows, not just read-only outputs.

LLMs can give you inconsistent (but correct) results

There’s a lot of material out there on how to get an LLM to answer data questions correctly, but it mainly boils down to business context.

Point an LLM at your data warehouse, without any guidance, and ask it “what was our deal win rate last month?” and you’ll likely watch it mull over things like deal stages, what types of deal to include, and make a best guess at what it thinks is the most “correct” answer.

This isn’t a new problem, nor an unsolved one: table & column descriptions combined with a well-constructed semantic layer (table joins, primary keys, metric definitions) go a long way towards both humans & LLMs answering data questions consistently & correctly.

But this doesn’t change the fact that even with the same guidance, pulling the same metrics (correctly), you can end up with different stories from the same data. Semantic layers make sure everyone calculates win rate the same way, but they don’t decide which cut of win rate the business actually looks at each month.

Let’s extend the win rate example:

• CEO: pulls win rates, monthly, across all types of deals.
• Sales leader: pulls win rates, weekly, split by new vs. existing business.
• Marketing leader: pulls win rates, weekly, for marketing-sourced new business.

All 3 approaches are valid, and all calculate win rates the same way. Yet, if you asked each of them “what have our win rates been over the past month?” you would likely end up with 3 different answers.

LLMs can remove the friction from getting correct answers from your data, but you risk shifting this friction downstream to (in this case) 3 leaders in a room trying to reconcile why their numbers don't line up.

Dashboards help provide consistency that LLMs can lack

A common pattern to solve for consistency is to provide LLMs with example queries: if a user asks X then you probably want to run query Y.

Dashboards are just an extension of this: a “deal review” dashboard that contains a visual of win rates over time cut by N-dimensions is essentially just a saved SQL query, run & reviewed periodically, that the CEO / Sales / Marketing have agreed is useful to run the business with. That agreement is the part an LLM can't (and shouldn’t) reproduce, and the reason dashboards still add value.

You can then also think of dashboards more broadly as the top level of curation of data.

More “curated” here means a stronger signal (both to a human and an LLM) on how to analyse data if you were asked a question with no prior business context (e.g. deal win rates):

1. Dashboards: How do we currently analyse this type of data? Which is the main one leadership use to look at this on a regular basis?
2. Previous queries & analysis: How have we previously analysed this type of data?
3. Semantic logic: If I’m running an analysis from scratch, how should I analyse this type of data?
4. Transformation logic & below (SQL, column descriptions, rows of data etc.): If I haven’t got any information on how to analyse this type of data, what do I think would be the most sensible way of doing so?

Dashboards are still useful as a consistent (and visually represented) set of curated queries, that both humans and LLMs (more on that later) can use as the starting point for “here’s how we actually analyse a particular set of metrics”.

But watch out for clutter

The blocker, historically, with dashboards was the time taken for the Data team to build them. This is no longer true with modern analytics tools, as LLM-based workflows have drastically reduced the effort to build & maintain dashboards. But this is a double-edged sword.

If it's trivial to spin up ten near-identical "win rate" dashboards, and neither a human nor an LLM can tell which is the source of truth, then the consistency problem highlighted earlier just resurfaces in a different form.

Curation, once again, is key. Make it clear which dashboards are the authoritative ones (label with “Data team approved”, organise key dashboards into top level folders).

• Keeping dashboards well curated is a really hard problem to solve, and has been long before LLMs!

Another thing worth bearing in mind is that not everything needs to be a dashboard.

• There will always be ambiguous cases that sit between a one-off analysis and something like a polished key metrics dashboard, such as tracking a set of success metrics to monitor a new product launch.
• A useful framing is to ask yourself “If this was broken in ~1-2 months’ time, would it be worth fixing?”. If not, it’s worth having a route to avoid storing these types of analyses alongside higher-polish dashboards.
• These can still live in your BI tool, and even in the format of a dashboard, this is more an exercise to make it easy for a human (or an LLM) to know which dashboards are the ones to go to by default.

Dashboards can be powerful LLM inputs

Whilst dashboards offer consistency, they aren’t without their drawbacks:

• It’s increasingly common for both technical & non-technical users to run the bulk of their day-to-day out of LLMs, and they generally don’t want to switch between interfaces.
• They’re often inflexible for end users, and it’s typically not easy to dive into the why behind a trend in the data.
• They often lack qualitative data sources that make analysis with LLMs so powerful.

The last point is particularly important, and we can illustrate this with an example!

Below is an example schedule health factor metric for a customer over time that exists in our customer health dashboard. It’s a calculated metric between 0-100% based on how well we think a customer is using the scheduling part of our On-call product, which feeds into our overall customer health score.

As context:

• Rotations are a way to have multiple rotas on the same schedule (e.g. UK support, US support) without needing to maintain separate schedules.
• This isn’t the full picture - we’ve only included one variable out of several that go into the schedule health metric.

The example customer above appears to have expanded the number of schedules in use from 4 → 10, but then cut down 2 of these and added rotations to 2 more of their schedules, which has improved their schedule health level.

Imagine as a Customer Success Manager that you’d want to know why the customer is now using rotations more extensively in our product:

• You could always speak with the customer directly - but this doesn’t scale, and will inevitably be slower to get to an answer than diving into the data.
• You could also build tables / visuals into a dashboard for every possible follow-up question - in this example a table of the individual schedules - but this quickly becomes cluttered, and not all information renders nicely in dashboard form (e.g. JSON config).
• You could also drill into the rows of data behind each datapoint, but this is still a manual process that you need to repeat for every follow-up question you want to ask.

If we want to dive deeper into a trend on a dashboard, why not treat the dashboard itself as a source of information for an LLM in the same way you would Slack / Notion etc.? This unlocks more powerful workflows:

Using LLMs to combine qualitative & quantitative data isn’t new - but it’s a great way to leverage the consistency that a dashboard provides combined with the flexibility to dig 2-3 layers deeper on demand, and only dive into the areas worth exploring further.

Closing thoughts

Dashboards aren’t (quite) dead - but they’ve changed in purpose. They matter less as the sole place people go to look at charts, and more as the curated, trusted layer that keeps both humans and LLMs telling the same story from the same data.

• There will always be a need for a consistent set of metrics, shown a certain way, for decision-making stakeholders to use on a regular basis. Dashboards still fit this purpose really well.
• Dashboards can be thought of as the top level of curation for an LLM, and a useful starting point - essentially a set of queries that demonstrate how you actually analyse a set of metrics.
• The interface people use to consume dashboards is less important. It should be flexible, and you should meet your users where they work.
• LLMs have made dashboards far cheaper to build and maintain, but they only deliver consistency, or work well as LLM inputs, if it stays obvious which ones are authoritative.

Build fewer, name them well, and treat the best ones as first-class context for your LLMs.

Automate data monitoring and root-cause analysis with Looker Agentic Workflows

Traditional business intelligence alerts can only tell you that a metric changed, leaving data analysts to manually hunt through dashboards to figure out why. Today, we are introducing Looker Agentic Workflows in preview, a new capability in Looker that automates both metric monitoring and root-cause analysis, using intelligent background agents.

With Conversational Analytics in Looker, teams can already query business data using natural language. Looker Agentic Workflows turns those ad-hoc questions into continuous, automated monitoring routines directly from the chat interface. You can set up an automation simply by prompting the agent, such as asking to "Monitor return rates weekly" or "Notify me if average order value exceeds $1,000." The agent interprets your intent, confirms specific threshold conditions, and generates a workflow configuration plan for you to review before launching the monitor.

Review the workflow plan generated inside the conversational analytics pane

Deliver root-cause analysis in Slack and email

When a metric crosses your defined threshold, the background agent does more than send a basic notification. It can automatically run a Key Driver Analysis (KDA) across the underlying data model to isolate specific factors driving the change, such as product categories or customer cohorts. The complete diagnostic summary is delivered directly into your team's workspace via Slack or email, eliminating the need for manual data hunting or analyst support tickets.

Automated root-cause analysis delivered with the metric change notification.

Investigate deeper with central oversight

Every notification includes a direct link back into Conversational Analytics in Looker. Clicking the link opens an interactive session pre-loaded with the agent's diagnostic findings, allowing you to ask follow-up questions and test hypotheses immediately. Balancing user flexibility with enterprise governance, Looker provides a centralized workflow management interface. Business users can view and edit their own active monitors, while Looker administrators retain full oversight to review, adjust, or disable workflows across the entire instance.

Central pane to review, edit, and manage workflows

Get started with Looker Agentic Workflows

Looker Agentic Workflows is available in preview for Looker version 26.08 and later. Administrators can activate the feature by opening the Gemini in Looker settings page and enabling the Agentic Workflows preview toggle. Once enabled, users with chat_with_agent and create_alerts permissions can build workflows immediately. Review the Looker documentation to configure your first workflow.

Everyone is creating a new programming language these days, often one that's "like Go but with more features" or "like Rust but simpler".

Solod, a systems language for C and Go developers, might look like one of those languages, but it takes a different approach.

Go's tooling

Solod is not "Go-like" in the usual sense, nor is it an attempt to "fix Go's mistakes". At the language level, Solod is literally a subset of Go. Solod reuses much of Go's existing tooling, including syntax highlighting, LSP, linters, and the package management system.

Take this quick-start guide, for example:

Quick start

Install the So command line tool:

go install solod.dev/cmd/so@latest

Create a new Go project and add the Solod dependency to use the So standard library:

go mod init example
go get solod.dev@latest

Write regular Go code, but use Solod packages instead of the standard Go packages:

package main

import "solod.dev/so/math"

func main() {
    ans := math.Sqrt(1764)
    println("Hello, world! The answer is", int(ans))
}

Run without saving the binary:

so run .

That's it!

There's nothing new here. It's mostly standard Go workflow, except for so run, which is a Go program that mimics go run.

Go's standard library

Solod also reuses a lot of Go's standard library code and tests. Some of it is taken verbatim from Go's source code, like these two string functions:

// CutPrefix returns s without the provided leading prefix string
// and reports whether it found the prefix.
func CutPrefix(s, prefix string) (string, bool) {
    if !HasPrefix(s, prefix) {
        return s, false
    }
    return s[len(prefix):], true
}

// HasPrefix reports whether the string s begins with prefix.
func HasPrefix(s, prefix string) bool {
    return len(s) >= len(prefix) && s[:len(prefix)] == prefix
}

Of course, Solod retains the Go authors' copyright.

Some code requires changes to support the manual memory management with explicit allocators used by Solod:

// Go version.
func Clone(s string) string {
    if len(s) == 0 {
        return ""
    }
    b := make([]byte, len(s))
    copy(b, s)
    return unsafe.String(&b[0], len(b))
}

// Solod version.
func Clone(a mem.Allocator, s string) string {
    if len(s) == 0 {
        return ""
    }
    b := mem.AllocSlice[byte](a, len(s), len(s))
    copy(b, s)
    return string(b)
}

You can probably see the resemblance.

A grain of salt

Go tools don't know that Solod is a subset of the full Go language, so they won't flag features Solod doesn't support, like function literals or iterators. These diagnostics come from the custom so tooling:

package main

func main() {
    f := func(n int) {
        println(n)
    }
    f(42)
}

main.go:4:7: function literals are not supported
    f := func(n int) {
         ^here

Also, although a substantial part of Go's standard library is ported verbatim or with minimal changes from the original source, that doesn't mean the code is automatically correct. Solod still needs its own tests, including ones that run under sanitizers and static analyzers.

It's all C in the end

All Solod code is translated to regular C11 and then compiled with GCC or Clang. Solod therefore relies on C tooling and decades of optimization work just as much as on Go's.

Solod code:

package main

import "solod.dev/so/math"

func main() {
    // What might it be?
    ans := math.Sqrt(1764)
    println("Hello, world! The answer is", int(ans))
}

Translated C code:

// -- main.h --
#pragma once
#include "so/builtin/builtin.h"
#include "so/math/math.h"

// -- main.c --
#include "main.h"

int main(void) {
    // What might it be?
    double ans = math_Sqrt(1764.0);
    so_println("%s %" PRIdINT, "Hello, world! The answer is", (so_int)(ans));
    return 0;
}

The C version is noisier, of course, especially for more complex programs than this one. But it remains readable.

And since there's no runtime, interoperability between Solod and C costs nothing.

Final thoughts

A new language doesn't necessarily need a new ecosystem.

Solod relies heavily on Go, and I see that as a strength, not a weakness. Reusing Go's proven tools and standard library makes Solod more reliable and easier to work with.

If you're interested, take a look at Solod's readme — it has everything you need to get started. Or try it online without installing anything.

Generative AI is notoriously eager to help, to the point that if it can’t find something matching what you ask for, it’ll create it. So the problem with relying on guardrails is that all too often, a model will be wrong, showing a high confidence score for an incorrect answer because it’s relying on stale or non-canonical data.

Not only do you need to be able to track the lineage of data your model uses from source to token, something the EU AI Act requires, you also need to be able to take into account where the data came from, whether it’s out of date, if it changed in a way that affects the result, or if it was never really relevant or authoritative in the first place.

Gartner expects organizations will abandon 60% of AI projects because they don’t have the right metadata management, data quality, and data observability. IBM’s acquisition of Confluent also highlights the importance of real-time data with lineage, governance, and policy for AI agents, and one of IBM’s 2026 predictions was the importance of smarter data.

The usual approach is adding metadata and validation later in the data pipeline. That’s similar to the way the bronze, silver, and gold tiers of typical lakehouse architecture are supposed to represent how filtering, cleaning, and augmenting data improves structure and quality until it’s ready to use. That can mean an enormous amount of work since nearly three quarters of the CPU work in training a frontier model is data cleansing and validation.

But that can also remove a lot of the context crucial for gen AI. Rather than cleaning data and losing the original context, it’s often more effective to keep as much information about the original state of the data, says David Aronchick, open-source platform Kubeflow founder, and CEO of distributed data pipeline vendor Expanso. “You can’t pursue exactly purely clean data; that’s just not possible,” he says. “As you pull data into your ML model, every line should have some mechanism saying where it came from. Otherwise, you’re never really going to know because you can’t mix them together and tease them apart later. You can search your raw content, your raw logs, but it’s just not going to be there.”

IoT digital twin systems often tag data all the way back to the device capturing it so you can see whether a temperature spike is a critical failure, which you want to react to, or a routine calibration, which you don’t. But that information may well be relevant down the line when you want to use that data more broadly. So unless you capture at least some elements about the source of data before you move it, you’re not going to be able to easily reconstruct the context later, or at all sometimes.

Ulrik Hansen, co-CEO of Encord, a platform for managing and annotating data, calls this in-stream labelling and cautions it’s not an alternative to cleansing data. “Dirty conflates two things: actual corruption you should fix, and context dependence, where a reading only looks anomalous because you threw away the frame that explained it,” he says. “Cleansing kills both. The point isn’t to stop cleaning, it’s to stop normalizing away context you can never recover.”

Context can be cheap to capture at the source and nearly impossible to recover after, he adds. “The question isn’t whether to keep it,” he says, “it’s about curating what actually helps.”

Raw but not rancid

Aronchick characterizes the state of most bronze tiers as toxic waste because raw data doesn’t get validated before ingestion, or have a metadata wrapper on each data point. “You’ve taken raw data and stripped it of context,” he says.

Take a wind farm operator, for instance. When sensor data about the turbines is generated, it comes from a particular turbine at a particular position in a specific wind farm at a known location, running at a specific speed in specific weather conditions, at a particular time. “If you have other turbines also working in the field, the performance of your turbine will go down, but the field performance will go up,” says Aronchick. “The performance of your turbine going down isn’t a negative, but unless you have the context at the point of data collection, you’re going to make your life much harder later on, when someone asks about the efficiency.”

Metadata needs to be much richer, and it needs to be added as early in your data pipeline as possible when you have the most detail available to make sense of the structure and complexity of the data, Aronchick adds. “You want to capture as much about the data you’re collecting as possible, where it doesn’t require insane activity to do so.”

But not all the metadata you need will be generated with the data, he says. You almost certainly need to augment and annotate your data, and provide extra structure, especially for something like a point of sale system with very light metadata. “Data comes off these things in poor structure,” he says. “It’s not OpenLineage, it’s often a CSV or a text record, and you have to reconstruct them into a full structured log. So do smart things where you’re creating data. That might be compressing, sampling, converting, appending metadata to it, and enforcing schema and lineage all before you start moving anything.”

That doesn’t have to mean bloating your data, Hansen points out. He suggests capturing what’s free and unrecoverable. “The system of origin is the label,” he says. “You don’t tag HR policy, you capture that it came from the HR system. Anything a model can derive later, you can skip.”

Structure isn’t static

Routine changes to APIs, schemas, and how data is collected or stored happen in every organization, and need to be reflected in metadata that lives alongside the data or added as data is collected, not reconstructed later in a fragile process that depends on knowing about all those changes. Google’s research into these data cascades shows how easily context gets lost and how badly it affects data quality.

Shifting schema enforcement further left in your data pipeline so you deal with it as soon as possible allows you to make more effective downstream decisions. For a sensor recording temperature and humidity, you need to know the temperature scale it uses, readings, and how the timestamp is recorded. Checking that against the schema before ingesting the data lets you route it differently depending on whether it validates or triggers alerts about data quality.

“Maybe I’ll delete it, or send it off to some place where a human being or other tooling can reconstruct it into something valuable,” says Aronchick. “But what it doesn’t do is allow the polluted or bad data into my pipeline. Saying whether or not something passed your schema makes your downstream systems much more reliable.”

Sensing structure

Unstructured and semistructured data needs more augmentation. A PDF or Word document has an author and a creation date, but doesn’t necessarily include any context about the job title and department of the author, whether it’s up to date, only applies to a particular group of customers, or is based on accounting regulations that can change. If that information is available, it needs to travel with the document, not be left in a compliance spreadsheet.

Data platforms like DataHub and SurrealDB both capture and create context. The latter can analyze a photo, for instance, using vision AI to understand what’s in the image. “From completely unstructured data, we get as much structure as possible,” says the company’s CEO Tobie Morgan Hitchcock.

That’s paired with other data potentially useful for an AI agent down the line. “Understanding what happened around an event becomes a lot easier if you’re tracking the conversation, telemetry, tool and model usage, geospatial data, and the vector search and relationships,” he says. “You’re going to have a far better chance of getting an accurate understanding of that data, which started off completely unstructured, than if you weren’t capturing anything.”

Metadata about document authors, which might come from the company directory, can show how much authority a document has. He describes that as building an understanding of what trust and provenance is over time by the weight and authority of who’s updating the information. After all, he says, company-generated information has more trust or can have traced provenance compared to conversational inputs from a user.

Incentives for annotating

DataHub CTO Shirshanka Das saw how much of a mess data can be even with strong guidelines as former architect of LinkedIn’s GDPR strategy. “The data was a swamp, despite us having had pretty good data-first and schema-first practices,” he says. As well as cleaning up the data governance, they added in the first nuggets of the DevOps’ ‘shift left’ approach.

LinkedIn already required data checked in to its Kafka ecosystem to have a schema, and ran CI/CD pipelines to check backward compatibility. “I attached metadata attribution and collection around compliance metadata into that pipeline, where developers weren’t able to check in a schema until they had declared what every column meant.”

The extra work was unpopular until teams who didn’t participate saw the flood of tickets that came their way, which allowed him to extend that same proactive governance and annotation at source approach to pretty much every data set being produced.

“The starting point of data at most companies is a lot more swampy,” he says. “Many people are using Kafka, which is a very schema forward system, and yet they’re just shoving in JSON and unstructured stuff.”

That’s common, agrees Megha Kumar, research VP for analytics and AI at IDC, because while collecting more metadata provides better context and cleaner data lineage, it’s hard in practice. “Most organizations batch process data, so real-time context capture rarely happens,” she says. “Even the ones that process in real-time tend to have pre-defined schemas, so adding context requires changes to the data, which unfortunately happens later.”

People don’t know how to start, says Das, so DataHub Cloud tries to add back context by collecting operational metadata from multiple systems, including queries and BI tools to extrapolate a semantic model. “We confront the mess by giving them something they can react to,” he says. “They can quickly validate, and then it starts becoming a governance layer on top where humans annotate at source.”

Online whiteboard provider Miro, for example, dramatically improved AI agent query accuracy from about 50% to 90% using DataHub. Then they applied GitOps principles on top of what was inferred with a human in the loop for approvals.

So getting people to do the work happened the same way at LinkedIn, says Das. “When a data scientist gets 10 times more requests because they didn’t document their work well, resulting in the AI making lots of mistakes and stakeholders constantly pinging them for answers, they have the incentive to add the annotation when they produce an analysis, because then they get out of the critical path.”

DBOMs and data contracts

Provenance and lineage of data is critical, Aronchick says, so you can preserve details like who collected the data, when, from where, if the source was authoritative or canonical, what transformations were run, and exactly what the model saw.

“It’s not just about the version and the metadata,” he says. “Where things really start to change is when you can say along the way this data has gone through these steps, this is the root source, and these were the other elements.” You want to be able to find out if there were any experimental flags, like a new customer campaign running when it was collected, as well as what claims the data contributes to.

Aronchick advocates for a SLSA-style data bill of materials using a tool like Makoto, which can add signed provenance and attestation to simplify applying central concepts of governance and structure to upstream data.

The notion of a data contract or a data product spec is starting to become common in the financial sector says Das, defining it as a data set, or a group of data sets, bound together by a contract that defines expectations which aren’t just cosmetic but machine verifiable. They can also include operational SLOs for APIs as contracts describe not just the shape of the data but operational characteristics and guarantees.

Document graph markup language (DGML), a new open source specification from Docugami, promises provenance down to individual data points automatically extracted from documents.

“It’s critical to know the validity and provenance of the information your AI is relying on,” Docugami CEO and XML co-creator Jean Paoli says. “Establishing the validity of data right from the start, at scale, is vital and far more efficient than trying to clean up bad data later.” DGML combines semantic tags describing what content means in its business context with bounding boxes showing exactly where in the document the content comes from, with attestation to prove it.

AI demands provenance

All this context is the kind of metadata Anthropic’s context engineering guide recommends feeding to agents for accuracy. Developers are already used to giving coding agents more context, Das argues. “The same thing is happening with data, as when people realize when AI agents can’t make sense of what they’re doing, hallucinations happen,” he says.

Kumar agrees that organizations realize agents need context to provide better insights. “In many cases, it has to do with ensuring the existing data had clear semantics and relationships,” she says.

If you want to make sure the purchase return window an AI chatbot promises customers is based on your own policy, not a wish list from a user forum, you need rich context. It’s not just metadata. Organizations need to have semantics, data lineage, and ontologies. “Many are also building knowledge and ontology graphs,” adds Kumar. “By ensuring the systems understand what the data means, it’ll be able to provide a better response.”

And if you’re going to the expense of fine tuning, which needs relevant and domain- or task-specific examples, you don’t want noise, duplication, or irrelevant content in your data. You can, of course, exclude poor data if it’s annotated and verified earlier, but you can also improve model performance with extra information, Aronchick points out. “The augmentation of the existing data makes the data you pull out more valuable,” he says.

Expanso recently won an Edge AI award for fine tuning a base level model with only about 3,200 images by augmenting them with metadata. “The reason it worked on that few is because I could tell it deterministically what was in the frame,” he adds. “It’s labeling at the point of capture instead of paying somebody to label it later. What if I developed models for predictive analytics of store behavior on a per city, region, or country basis? If I’m able to take the raw point of sale information and augment it with additional metadata, I’m turning this into a much easier thing to fine tune.”

Or you might even avoid the expense of fine tuning entirely, suggests Das. “You get the short-term advantage by fine-tuning and getting great performance at much cheaper cost on a smaller model, and it gets stripped away in a couple of months as a new model shows up,” he says. “You have to always run that calculus of when’s the right threshold to fine tune an existing model, distil it, and then run it for a fair amount of time to recoup the costs of fine tuning.”

Although regulated or slow-moving industries will see benefits from fine tuning a model they can run for six to 12 months on data with higher quality and better provenance, many organizations may use the improved data quality to get good results without fine tuning.

“We’re taking a more knowledge graph-oriented approach to grounding the model, and betting on the fact that because the knowledge graph is changing often, it’s better to keep it as a runtime artifact than a baked-in one.”

WeatherNext Cyclones predicts cyclone tracks, intensity, and winds with more than a day of extra warning over leading models.

This photo was taken by me in the basement of the Sternberg Astronomical Institute at Moscow State University.

In the early 2000s this was our smoking place. Teodor Sigaev and I went downstairs, smoked, argued, and continued whatever PostgreSQL problem we happened to be thinking about. GiST, arrays, full-text search, later GIN, SP-GiST, jsonb, — many ideas were discussed on these stairs.

There were no meetings, no agenda, no design documents. Just conversations, often continuing work we had started upstairs. And somewhere in this stream of discussions, hstore was born.

Around 2003, Teodor and I were doing some moonlight work — a project involving search over institutions of the Russian Ministry of Education. The objects were similar, but different enough to have different sets of attributes. An ordinary relational design produced a huge sparse table, mostly full of NULLs. It was horrible even to look at in psql.

And at some point I thought: why store all these empty fields at all? Why not store only the attributes that actually exist? We were heavy Perl users then, so the train of thought quickly arrived at something very familiar to us: a Perl hash. Key → value. A hash store. hstore.

There was no grand architecture behind it. We had an ugly sparse table and wanted to make it disappear.

But hstore turned out to be useful far beyond that project. We used it for years, many PostgreSQL projects adopted it, and some still use it today. It became a datatype in its own right, with operators and indexing, not merely an experiment on the way to something else.

And we learned a lot from it.

Ten years later PostgreSQL already had a json datatype. It was an important first step, but internally JSON was essentially validated text. I was really unhappy with stopping there. After years of working with binary hstore, it seemed natural that PostgreSQL should have a real structured JSON datatype — something designed not just to preserve JSON text, but to process and index its structure. Then the call for papers for PGCon 2013 opened. I got excited, wrote a proposal and submitted it: “One step forward true json data type. Nested hstore with arrays support.”

Only afterwards did I tell Teodor. So we now had a problem. We had promised a PGCon talk about nested hstore with arrays, but nested hstore with arrays did not exist yet. There was only one reasonable solution. We had to make it.

And we did.

We extended hstore with nesting, arrays and scalar values. For some time this work was literally called nested hstore.

Then it became clear that maintaining two separate worlds — nested hstore and JSON — made little sense. We stopped developing nested hstore as a separate datatype and concentrated our work on what became JSONB in PostgreSQL 9.4.

So the path, at least from where I was standing, was quite direct:

ugly sparse table
       ↓
store only existing attributes
       ↓
Perl hash
       ↓
hstore
       ↓
10 years of real-world experience
       ↓
nested hstore + arrays
       ↓
JSONB

I like this history because we were not trying to predict the future of databases.

In 2003, we just had a table full of NULLs that was impossible to look at. And in 2013, I submitted a conference talk a little earlier than I probably should have.

Sometimes this is how software gets made.

Craft used to prove competence for designers, but AI has made execution nearly free, stripping away that cover and leaving only whether one has something genuine to say. Cheap polish now signals nothing, and the real risk is "slop": endless output produced to avoid confronting that deeper question, rather than pursuing genuine conviction. True value lies in "conviction," the irreducible human act of caring and choosing, which AI cannot replicate, though private, hyper-personalized creations risk losing the shared meaning that once resonated with others.

Omni Ai Video Generator

Transform your creative vision into stunning videos. Omni Ai uses advanced AI to generate professional video content from text prompts and images.

Powerful AI Video Generation

Omni Ai combines cutting-edge AI technology with intuitive controls, giving you everything you need to create professional videos.

Text-to-Video

Transform your creative prompts into stunning videos. Describe any scene, and watch Omni Ai bring it to life.

Image-to-Video

Use your own images as starting frames. Omni Ai animates static images into dynamic video content.

Fast Generation

Get your videos in minutes, not hours. Our optimized pipeline delivers quick results without sacrificing quality.

Flexible Duration

Choose from 4 to 20 second videos. Perfect for social media clips, intros, or creative projects.

Multiple Resolutions

From 720p to 1080p, select the resolution that fits your needs. Pro model unlocks premium quality options.

Aspect Ratio Control

Create landscape or portrait videos. Optimized for YouTube, Instagram, TikTok, and more.

Easy Downloads

Download your creations instantly in standard MP4 format. Compatible with all major platforms.

Secure & Private

Your prompts and creations are processed securely. We prioritize your privacy and data protection.

Frequently Asked Questions

Everything you need to know about using Omni Ai for AI-powered video generation.

What is Omni Ai?

How does Omni Ai video generation work?

What video durations and resolutions does Omni Ai support?

What is the difference between Standard and Pro models?

Can I use Omni Ai for image-to-video generation?

How long does video generation take with Omni Ai?

What types of videos can I create with Omni Ai?

Can I download videos generated with Omni Ai?

A guide to protect ourselves against dishonest charts and to preserve what is good about turning data into visual things.

Full article content is not available for inline reading.

Read the original article →

Users on skills.sh can now bundle multiple agent skills into a shareable pack. Every pack is unlisted and has its own URL. Packs can be shared with teams to standardize skills across projects.

The Apple Watch continues to attract new buyers and remains the top-selling smartwatch. However, the company's industrial design team has been exploring a broad rethink of Apple's smartwatches and is evaluating several different directions. Apple needs to adapt to the rise of screenless fitness bands and smart rings, which are cheaper, lighter, and more fun and convenient to use for many people. The company aims to inject new life into its Wearables, Home, and Accessories segment, which has struggled to generate meaningful growth in recent years.

Data ownership fails when responsibility comes without decision rights, leaving owners unable to approve quality thresholds, accept risk, or authorize usage. Effective governance needs authority and escalation paths, with data owners deciding while stewards execute. Decisions need accountable owners and traceable risk acceptance.

Microsoft is marking Xbox's upcoming 25th anniversary with free community-made gamerpics, backgrounds, themes, and a dynamic console background, plus a commemorative profile badge for anyone who signs in before the end of 2026. Xbox Game Pass now features curated anniversary collections spotlighting titles like Fable Anniversary, Halo: The Master Chief Collection, and Fallout 4, alongside a planned international FanFest tour and a paid translucent green Xbox Series X25 console arriving in November.

A new leak suggests Apple's first foldable iPhone, expected to be called the iPhone Ultra, may launch in silver and dark blue color options. The information comes from third-party accessory makers with supply-chain sources, though Apple has not yet confirmed any colors ahead of next month's expected announcement.

Curiosity is becoming one of the most valuable skills for designers as AI automates more execution work. The designers who benefit most from their curiosity are those who explain their intent, understand stakeholders' motivations, create value before asking for help, and build relationships in low-stakes settings. The difference between a curious junior designer who gets shut down and a curious senior designer who earns trust is usually communication, not curiosity itself.

Agrandir is a variable typeface by Alex Slobzheninov that deliberately breaks modernist conventions through uneven weight distribution, organic details, and tightly spaced letterforms that create visual tension. The family includes 74 fonts with flexible weight and width axes, allowing designers to create dynamic layouts while maintaining strong contrast through consistently thin elements. With broad language support and a distinctive, human-centered aesthetic, Agrandir is particularly well suited for branding, posters, and expressive digital design.

Almaty-based designer Daniyar Uderbekov created UDRB, a modular glue-free sneaker system that combines 3D-printed TPU soles with traditional Central Asian leather footwear techniques.

Aging creatives can thrive by shifting from competing on speed and trend-awareness to leaning on judgment, experience, and client relationships built over years.