GPT-6.1 Sol offers near-Astra intelligence at a fifth of the cost, delivering significant improvements for professional tasks and reducing costs for developers. It excels in coding benchmarks, matches Astra's performance on complex PDF queries, and improves business workflow automation while offering enhanced factual accuracy. Available via OpenAI API and multiple user tiers, it provides cost-effective solutions across tasks with substantial safety and transparency enhancements.

OpenAI introduces "Dots," AI-driven agents powered by GPT-6 Astra, designed to handle tasks autonomously using their own cloud computer. Dots integrate with over 4,000 apps and platforms like ChatGPT, Slack, and Teams, enabling seamless workflow and personalized assistance. They ensure user control with built-in safety measures, allowing for proactive task management while adapting to user goals and feedback.

Full article content is not available for inline reading.

Read the original article →

MCP Events lets ChatGPT subscribe to updates from your MCP server, such as new messages, content updates, or status changes. Users choose what to monitor and what ChatGPT should do when an update arrives.

Before you start

MCP Events in ChatGPT requires MCP 2.0 (protocol version 2026-07-28). Configure your server in your plugin and provide persistent subscription storage and outbound HTTPS access to callback URLs.

ChatGPT supports webhook delivery and callback verification from the draft MCP Events specification. Polling, streaming, and the draft’s gap and terminated control notifications are not supported by this integration.

How it works

1. Your server lists the events it supports.
2. The user tells ChatGPT what to monitor and how to respond.
3. ChatGPT subscribes through your MCP server and supplies a callback URL and signing secret.
4. Your server sends matching events to that URL.
5. ChatGPT receives the event in the subscribed chat and follows the user’s instructions for how to respond.

Advertise event support

Event discovery starts with your server’s capabilities. Add events to the capabilities returned by its server/discover response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {},
      "events": {}
    }
  }
}

Implement these three event methods on the same authenticated MCP endpoint as your tools:

Define an event

An event definition tells ChatGPT what users can subscribe to and which filters are available. Return these definitions from events/list, including the event name, supported delivery modes, subscription arguments, and payload schema.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "events": [
      {
        "name": "comment.created",
        "description": "A new review comment was added to the specified document.",
        "delivery": ["webhook"],
        "inputSchema": {
          "type": "object",
          "properties": {
            "document_id": {
              "type": "string",
              "description": "ID of the document to monitor for new review comments."
            }
          },
          "required": ["document_id"],
          "additionalProperties": false
        },
        "payloadSchema": {
          "type": "object",
          "properties": {
            "document_id": { "type": "string" },
            "comment_id": { "type": "string" },
            "text": { "type": "string" },
            "url": { "type": "string" }
          },
          "required": ["document_id", "comment_id", "text", "url"],
          "additionalProperties": false
        }
      }
    ]
  }
}

inputSchema describes the arguments passed when ChatGPT subscribes, while payloadSchema describes the data object in each delivered event.

Use stable event names and specific descriptions. Expose filters such as document, project, or queue IDs, and apply them on your server before delivery. Return only events the connected account is allowed to discover.

If the catalog spans multiple pages, return nextCursor and accept it as cursor on the next events/list request.

Create a subscription

When a user asks to monitor an event, ChatGPT calls events/subscribe with the event name, filter arguments, and webhook destination:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "events/subscribe",
  "params": {
    "name": "comment.created",
    "arguments": {
      "document_id": "doc_123"
    },
    "delivery": {
      "mode": "webhook",
      "url": "https://receiver.example.com/mcp-events/callback_123",
      "secret": "whsec_<base64-encoded-signing-key>"
    },
    "cursor": null
  }
}

Before accepting the subscription:

1. Check that the user is authorized for the requested event and arguments.
2. Validate the event name and arguments against your event definition. Require a whsec_ signing secret whose base64 value decodes to 24–64 bytes.
3. Validate and verify the callback URL.
4. Store the subscription, its owner, filters, callback URL, signing secret, and expiration.

Derive a deterministic subscription ID from the authenticated principal, callback URL, event name, and arguments. Return it with the granted expiration:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "id": "sub_123",
    "refreshBefore": "2026-10-02T12:00:00Z",
    "cursor": null,
    "truncated": false
  }
}

Set refreshBefore to the expiration your server grants. Return cursor: null for event types that do not support replay.

Make subscription creation idempotent: update the existing subscription when its identity matches. Compare arguments using canonical JSON so object key order does not create duplicate subscriptions.

Verify the callback

Before sending application data, verify the callback by sending a signed request with a fresh, single-use, short-lived challenge:

{
  "type": "verification",
  "challenge": "a-single-use-random-value"
}

Assign the verification request a unique webhook-id, such as msg_verification_123, and sign its body with the subscription’s secret. Include webhook-timestamp, webhook-signature, and X-MCP-Subscription-Id. ChatGPT echoes the challenge in a successful response:

{
  "challenge": "a-single-use-random-value"
}

Require a 2xx response and compare the returned challenge in constant time before activating delivery. Cache successful verification by authenticated principal and callback URL for a bounded period so repeated subscription requests do not trigger repeated challenges. If verification fails, return JSON-RPC error -32015 (CallbackEndpointError) with a categorized data.reason, such as challenge_failed or timeout.

Require HTTPS for callbacks. Resolve and validate destination addresses at connection time, then connect to the validated address while preserving the original hostname for TLS verification. Block private, local, and other non-public addresses, and do not follow redirects. Apply these checks to verification requests as well as event deliveries.

Send an event

When a new comment matches an active subscription, POST one event object to that subscription’s callback URL:

{
  "eventId": "evt_456",
  "name": "comment.created",
  "timestamp": "2026-10-01T12:05:00Z",
  "data": {
    "document_id": "doc_123",
    "comment_id": "comment_456",
    "text": "Can we add the rollout dates to this section?",
    "url": "https://docs.example.com/doc_123#comment_456"
  },
  "cursor": null
}

Use a unique event ID and preserve it across retries. Set timestamp to the event’s occurrence time as an ISO 8601 timestamp with a timezone. The name must match the subscribed event, and the data object must match its payloadSchema. Keep application fields inside data; a top-level type identifies a protocol control notification.

For large records, send a summary and expose a read tool to retrieve the full record. Treat comments and other user-authored text as data; do not add instructions telling the model how to behave inside the event payload.

Sign the request

ChatGPT verifies deliveries using Standard Webhooks. Send these headers:

Sign deliveries using Standard Webhooks and the subscription’s signing secret. Because the signature covers the event ID, signing timestamp, and exact request body bytes, serialize the body once and send those same bytes.

Send a signed event with Node.js

Install the Standard Webhooks library:

npm install standardwebhooks

Pass a webhookFetch function with the same interface as fetch that validates callback addresses on each connection and blocks redirects.

import { Webhook } from "standardwebhooks";

export async function sendEvent(subscription, event, webhookFetch) {
  const body = JSON.stringify(event);
  if (Buffer.byteLength(body, "utf8") > 256 * 1024) {
    throw new Error("Event payload exceeds 256 KiB");
  }

  const signedAt = new Date();
  const signer = new Webhook(subscription.secret);
  const response = await webhookFetch(subscription.url, {
    method: "POST",
    redirect: "error",
    signal: AbortSignal.timeout(10_000),
    headers: {
      "Content-Type": "application/json",
      "webhook-id": event.eventId,
      "webhook-timestamp": String(Math.floor(signedAt.getTime() / 1000)),
      "webhook-signature": signer.sign(event.eventId, signedAt, body),
      "X-MCP-Subscription-Id": subscription.id,
    },
    body,
  });

  return { accepted: response.ok, status: response.status };
}

Set subscription.url and subscription.secret from the subscription request’s delivery object.

Handle delivery responses

A 2xx response acknowledges webhook receipt. ChatGPT processes the event asynchronously.

Send one event per request, with a complete request body no larger than 256 KiB (262,144 bytes). ChatGPT can group separately delivered events into one task run according to the task’s batching settings.

Retry transient failures with exponential backoff and bounded attempts. Preserve the event ID and generate a fresh signing timestamp and signature for each attempt. Do not retry deliveries that return 410 or 413.

Events can arrive out of order. Make write tools idempotent so repeated calls do not duplicate changes.

Manage subscriptions

Retain subscription state for the lifetime you grant, including across server restarts. Recheck the user’s access during the subscription’s lifetime and stop delivery if access is revoked.

Refresh a subscription

ChatGPT refreshes expiring subscriptions by calling events/subscribe before refreshBefore, using the same subscription identity and the last saved cursor. Update the existing subscription and return its new expiration in refreshBefore.

When ttlMs is omitted, use your server’s default subscription lifetime. When provided, it specifies the requested lifetime in milliseconds. Grant no more than that duration, except when enforcing a minimum lifetime to prevent excessive refresh requests.

ttlMs: null requests a subscription without expiration. Return refreshBefore: null only when granting that request. Otherwise, return a finite expiration and stop delivery when it passes.

When a refresh supplies a replacement signing secret, replace the stored secret. During a short rotation window, sign with both the old and new keys using Standard Webhooks’ space-separated signatures.

For replayable events, use the request’s cursor to resume after an expired subscription or server restart. In subscription responses and event payloads, return a cursor that does not skip events still awaiting delivery. Return truncated: true when the requested history is no longer available. For event types without replay, return cursor: null; events missed during an interruption cannot be recovered through the protocol.

Stop a subscription

Handle events/unsubscribe using the original event name, arguments, and callback URL:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "events/unsubscribe",
  "params": {
    "name": "comment.created",
    "arguments": {
      "document_id": "doc_123"
    },
    "delivery": {
      "mode": "webhook",
      "url": "https://receiver.example.com/mcp-events/callback_123"
    }
  }
}

Stop sending events for the matching subscription and return an empty result:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {}
}

Make unsubscribe idempotent and authorize it against the connected account.

Test in ChatGPT

With the event methods and webhook delivery in place, connect your MCP server to ChatGPT through a plugin and test the full subscription lifecycle:

1. Confirm your server receives server/discover and events/list, and returns the expected event definitions.
2. Verify that your events appear on your plugin page alongside your tools. Rescan your MCP server whenever you change its tools or events.
3. Start a new chat, ask ChatGPT to subscribe to one of your events, and specify what it should do when an event arrives.
4. Confirm your server receives events/subscribe with the expected event name and arguments.
5. Check that callback verification succeeds and the subscription is stored.
6. Trigger a matching event in your app and confirm that the webhook delivery receives a 2xx response.
7. Verify that ChatGPT receives the expected event data and responds as instructed.
8. For filtered subscriptions, trigger an event that does not match the filters and confirm it is not delivered to the subscription.
9. Stop monitoring in ChatGPT. Confirm that your server processes events/unsubscribe and stops delivery.

Also test repeated subscription requests, expiration and refresh across a server restart, account disconnection, revoked access to a subscribed resource, invalid signatures, duplicate deliveries, and bursts with batching enabled and disabled. If the requested action changes data in the source app, verify that the resulting events do not create a feedback loop.

GLM-5.3 and the spread of advanced cyber capabilities

Five months ago, we announced Claude Mythos Preview, the first AI model that could autonomously build sophisticated, end-to-end cyber exploits. The rapid rate of improvement in AI suggested to us that this ability would eventually proliferate to many other models, making it much easier for malicious cyber actors to launch highly impactful cyberattacks.

In light of these considerations, we chose to release Claude Mythos Preview in a limited way, through Project Glasswing—which enabled trusted cyber defenders to find more than 10,000 vulnerabilities in critical software, giving them a head start before malicious actors had access to similarly capable models.

But those models have now arrived. In this post, we share our analysis of GLM-5.3, the latest AI model developed by Zhipu AI (known outside of China as Z.ai). Like Claude Mythos Preview, GLM-5.3 has strong capabilities for autonomously building end-to-end cyber exploits. But GLM-5.3 is unlike other frontier models in that it has been released without meaningful safeguards to limit misuse. We find that attackers can bypass GLM-5.3’s safeguards between 64% and 100% of the time with simple techniques in our simulated tests. In contrast, these attacks did not succeed against safeguarded Claude models in our testing. We assess that GLM-5.3’s lax safeguards significantly increase the cyber capabilities available to malicious actors. At the same time, these capabilities can also benefit defenders working to secure their systems.

On Sept. 17, NIST’s Center for AI Standards and Innovation (CAISI) published its own assessment of GLM-5.3’s cyber capabilities. CAISI found that GLM-5.3 is “the most cyber-capable open-weight model released to date” and that it lags the US frontier by about four months on an aggregate of CAISI’s cyber benchmarks. Our capability findings broadly match CAISI’s. In CAISI’s comparison, US models were tested with cyber safeguards disabled when applicable, and the US frontier includes models released only to vetted users. Attackers can’t readily access those versions of US models, but anyone can download GLM-5.3. This post adds our analysis of how easily GLM-5.3’s safeguards can be bypassed or removed.

GLM-5.3 can develop working exploits end to end

To understand how GLM-5.3 could enable cyber threat actors to find and exploit real software vulnerabilities, we ran evaluations using automated benchmarks and human-in-the-loop workflows. For both approaches, we ran the tested models in isolated and sandboxed environments so they can only attack offline targets that we have set up for the purposes of these evaluations. We focus primarily on exploit development capability, as this is where Claude Mythos Preview demonstrated a notable jump versus previous Claude models.

First, we ran the model on ExploitBench, which measures how well AI models can exploit known vulnerabilities in the V8 engine used by Google Chrome. Here we focus on the models’ ability to develop end-to-end exploits successfully, as this is the most relevant capability for attackers, and where we see significant changes between models. We find that GLM-5.3 develops end-to-end exploits in 50 of 410 attempts. Claude Mythos Preview did so at a similar rate—in 56 of 410 attempts.

In our internal Binary Exploitation benchmark, we test whether models can find and exploit vulnerabilities in popular open-source projects that participate in Google’s OSS-Fuzz project. Here, full credit is awarded for a full control-flow hijack. We evaluate several models on 100 tasks from the benchmark (selected at random), and find that GLM-5.3 develops full control-flow hijacks in 4% of the trials; Claude Mythos Preview did so in 6%. Although GLM-5.3 performs below Claude Mythos Preview here, a meaningful threshold has clearly been crossed: earlier models, like Claude Opus 4.6 and GLM-5.2, do not succeed in any of them.

Next, we evaluated how GLM-5.3 performs on open-ended offensive cyber tasks in the hands of human experts (mirroring our testing with Claude Mythos Preview earlier this year). Here, we select targets in which the human experts are unaware of existing vulnerabilities, then ask them to use the model to identify and exploit novel flaws. These experiments tested what the experts could do in a short time-frame: they typically ran for a day or less, with less than an hour of human focus in total.

In the first of these sessions, a researcher used GLM-5.3 on a sandboxed machine with a local Linux build of a popular web browser. Over the course of a day (and with limited human attention), GLM-5.3 found several previously unknown vulnerabilities in the browser’s JavaScript engine, and chained them together into a working exploit: a webpage that, when visited, reads arbitrary files from the visitor’s computer. This exploit targets the Linux build of the browser, since that was the only environment made available to the model. However, we believe these vulnerabilities could also impact users on other platforms, though the path to exploitation there may be more complex. (We’ve disclosed these vulnerabilities to the maintainer.) Later in the session, the researcher also identified exploitable vulnerabilities in several other widely used systems with GLM-5.3, including wireless and graphics drivers and network-facing device software. We are currently reviewing these reports and we will disclose to maintainers as appropriate.

In a second session, a researcher used GLM-5.3-Flash (a smaller, less capable version of GLM-5.3) to develop an exploit for a known vulnerability. Here, the researcher focused on a recently disclosed flaw in Google Chrome (CVE-2026-11645) to see how quickly the model could turn a public fix into a working attack. The researcher provided GLM-5.3-Flash with public details of this CVE and another known flaw. With no significant direction from the researcher, GLM-5.3-Flash chained together exploits for these two flaws, building a reliable exploit chain for an ARM64 target, bypassing pointer-authentication (PAC) hardening. This took 20 minutes of human attention, plus eight hours of work for GLM-5.3-Flash. At Zhipu’s API prices, this effort would have cost $20.40.

GLM-5.3 lacks robust safeguards

GLM-5.3 has been released with some built-in safeguards: if a user asks for something clearly harmful, the model will often refuse. In our testing, we found that these safeguards could be bypassed or removed with a variety of simple techniques.

The most intensive—and most successful—method is a standard refusal reduction technique known as “abliteration.” Since GLM-5.3 is released as an open-weight model, users can reconfigure it to remove its refusals with little change in its capabilities. Several developers released abliterated versions of GLM-5.3 to the public within days of the model’s release.

To research how far abliteration allows attackers to bypass GLM-5.3’s safeguards, we produced an abliterated copy ourselves, and then ran it on three public benchmarks (JailbreakBench, HarmBench, and StrongREJECT) that measure how often a model complies with clearly harmful requests. Abliterating the model took our team—which had never previously attempted this task—about 2,200 GPU hours at a computation cost of roughly $4,400. Abliterating GLM-5.3-Flash took about 600 GPU hours. The edit took GLM-5.3’s refusal rate from above 90% to about 3% and 2% on the first two benchmarks (JailbreakBench and HarmBench) and to 12% on the third (StrongREJECT). Abliteration did not significantly reduce the model’s capabilities: on GPQA-Diamond, an evaluation that measures general scientific capabilities, the standard and abliterated models scored the same results; on a tested subset of the CyberGym evaluations, the abliterated version scored a few percent lower.

In our testing, we observed that GLM-5.3’s safeguards can also be circumvented without using an abliterated version of the model. We placed the model in a simulated world in which it was given overtly malicious requests to attack critical systems. Out of the box, GLM-5.3 refused in all trials (as with the other models we tested). But we identified several simple ways to bypass the GLM models’ safeguards, such that it would respond to these requests in most or all cases. These include:

1. Providing a deceptive prompt, such as telling the model that it is an autonomous red-team agent working on an exercise. This gets GLM-5.3 to engage 64% of the time.
2. Prefilling the models’ thinking tokens so that it appears to have considered the user’s request and decided to proceed. This gets GLM-5.3 to engage 92% of the time.
3. Using an abliterated version of the model, as described above. This gets GLM-5.3 to engage 100% of the time.

In our testing, none of these techniques got safeguarded Claude models to carry out the harmful tasks we tested. Claude’s safeguards blocked the requests that used deceptive prompts. The Anthropic API provides would-be attackers with no way to prefill Claude’s thinking. And since Claude’s weights are not provided to users, they cannot be abliterated to change Claude’s behavior.

What does this mean?

GLM-5.3 will likely give malicious actors access to capabilities that will allow them to find and exploit cyber vulnerabilities without meaningful restrictions. This is unlike any other similarly capable AI model, all of which were released with safeguards or through limited access programs. The release of GLM-5.3 is a meaningful step change in the cyber capabilities available to attackers. Given this evidence, we think it’s likely both state and non-state actors will use models like GLM-5.3 to cause real-world harm.

On the other hand, models with this level of capability can also be used by defenders. Our view is that cyber defenders should use the best available tools that meet their needs. We're working to safely expand access to Claude's cyber capabilities to as many defenders as we can. Cyber defenders face attackers who will use every capable tool they can, and we believe defenders should be equipped with frontier models that are at least as good as those their adversaries are using.

Through Project Glasswing, cyber defenders have made meaningful progress towards securing critical systems in advance of this moment—but much work remains to be done. While vetted defenders can now use even more advanced models like Claude Mythos 5.1 through our trusted access programs, a critical threshold in freely accessible capabilities has now been crossed. GLM-5.3 underscores the urgency of expanding access to advanced frontier models to a broader set of entities to empower cyber defenders.

Governments should conduct safety testing on sufficiently capable AI models, including successors to GLM-5.3. Without high-quality evaluations from independent sources, the impact of these capabilities might not become fully clear to model developers until it is too late. As AI developers across the world build increasingly capable open-weight models, we hope they work to appropriately safeguard these capabilities and prevent misuse.

For two decades, largely in service to the International Space Station, NASA has sought to foster an “economy” in low-Earth orbit.

Twenty years ago, with a program to develop private spacecraft for cargo delivery to the space station, NASA sought to “stimulate efforts within the private sector to develop and operate safe, reliable, and cost-effective commercial space transportation systems.” In recent years this has expanded to creating an entire commercial ecosystem in orbit, with transportation, space stations, manufacturing, tourism, and more, such that NASA is one of many customers in the market.

In April 2024, the space agency explicitly laid out its philosophy: “NASA supports a robust commercial space economy that advances American industry and promotes technological discovery through in-space work and research. NASA remains committed to fostering innovation and collaboration within the American space industry.”

But just two years later, there are growing questions about the viability of this. As the second space race heats up, NASA has become more interested in focusing on the lunar surface, with a robust Moon base. SpaceX has signaled it no longer wants to be in the business of flying astronauts into low-Earth orbit. Today, the grand plans for a low-Earth orbit economy, at least involving humans, appear to be going sideways.

So what happened, and why does it matter? Ars spoke with a number of industry sources, on background, to provide some answers.

Q. What precipitated this crisis?

A. In recent months, SpaceX has made it clear to NASA that it no longer wishes to fly its Crew Dragon spacecraft, or the Falcon 9 rocket, on missions to low-Earth orbit. The company has agreed to support the International Space Station until 2030. But after that, SpaceX intends to retire the spacecraft. SpaceX has told companies developing private space stations for low-Earth orbit, including Axiom Space, Voyager Space, and Vast Space, that they cannot order Crew Dragon missions for their habitats.

Q. Can NASA compel SpaceX to keep flying Dragon?

A. NASA invested $3.1 billion in the development and certification of Crew Dragon as part of the Commercial Crew Program. But SpaceX was only compelled to fly half a dozen missions. It has flown 13 missions for NASA to the space station, and will launch another one in a few days. The company had recently agreed to keep flying through the Crew-17 mission. SpaceX has therefore more than fulfilled its contract obligations to NASA.

Q. But isn’t NASA a really important customer for SpaceX?

A. It was in the past, yes. But SpaceX now derives a majority of its revenue from Starlink, and that proportion is likely to grow even more. Additionally, as part of the process of going public earlier this year, in financial filings, SpaceX made clear that it envisions a vast majority of its future revenue will come from Starlink and orbital data centers. The category of “space enabled solutions,” of which NASA is a fraction, represented approximately 1 percent of what SpaceX views as its “total addressable market.” In other words, NASA needs SpaceX more than SpaceX needs NASA. Going forward, SpaceX wants to focus on launching its own payloads—on the Starship rocket. NASA Administrator Jared Isaacman recognized this reality during a news conference on Monday, saying, “I do not think it’s a secret that SpaceX intends to sunset older platforms like Falcon and Dragon as they concentrate on their next-generation capability, Starship.”

Q. What about Starship?

A. Four astronauts currently launch on Dragon. Starship could potentially bring dozens of astronauts into orbit at a time. That would be revolutionary for access to low-Earth orbit and an economy there. However, SpaceX has told NASA it is not interested in developing Starship for human launches into Earth orbit at this time. (Again, they’re focused on their own payloads). Ascent and entry of Starship, including certification for NASA astronauts, would raise a tangle of safety and regulatory concerns and is not a priority for the time being. NASA has no real way to compel SpaceX, and any political capital the space agency might expend on Starship is going to be focused on getting a variant of the vehicle for a “Human Landing System” as part of the Artemis Moon program rather than human launches from Earth.

Q. What’s happening with Boeing?

A. Boeing was NASA’s other partner in the Commercial Crew program. The agency has invested $5.1 billion to date in Boeing to develop the Starliner spacecraft. Despite this, Boeing has yet to fly a single operational mission to the space station. The news this week is that, despite these struggles, NASA will invest $359 million more to support the company’s efforts to fix Starliner’s propulsion system and certify the Vulcan rocket for new missions. It is NASA’s hope that Starliner can supplement astronaut missions during the remainder of the International Space Station’s lifetime, and then be available for private space station operators.

Q. Is this a good plan?

A. A lot of people don’t like it. Some critics say NASA has basically handed Boeing (not a particularly benevolent monopolist) and Starliner a monopoly on Western human spaceflight to low-Earth orbit for the next 10 or 20 years. This may effectively end any hope of a low-Earth orbit economy that involves humans in space. However, others say NASA faced few good choices. And given NASA’s extraordinary investments in Boeing to date, it would have been fiscally irresponsible to abandon Starliner now. NASA funded two companies as part of the Commercial Crew program. If one of them is walking away, it makes sense to support the remaining one, even if there are legitimate concerns about Boeing’s past performance.

Q. What else might NASA have done?

A. Some people wanted to see NASA fund a new competition, a Commercial Crew 2.0 for the 2030s. This would have brought on a competitor, probably Blue Origin but maybe also someone like Sierra Nevada or The Exploration Company, to keep price pressure on Boeing for crew transportation services. However, a new competition would ultimately have cost NASA billions of dollars, and Isaacman seems reluctant to make such an investment given all of NASA’s other priorities. Isaacman believes Boeing can meet NASA’s needs, which are something like two seats every six to nine months, to orbit. The real unknown is whether a market beyond NASA—institutional customers from Europe, the Middle East, and beyond, in addition to privately funded astronauts—could exist at Starliner’s prices.

Q. How much does a seat cost?

A. This is an important question. SpaceX’s original price per seat for early Dragon flights was approximately $55 million. For more recent missions, the price has increased to $78.8 million. (And if SpaceX were to magically decide to keep flying Dragon longer, the price would only go up). By contrast, the Starliner price to NASA is $90 million per seat during the International Space Station era. So what happens after Dragon retires? Let’s just say no one expects prices to go down. I asked Boeing Vice President John Mulholland about Starliner seat prices in the 2030s yesterday, and he replied, in part, “Obviously we want to be as competitive as possible.” But competitive with whom?

Q. What about Blue Origin?

A. The space company founded by Jeff Bezos is developing a “Space Vehicle” for astronauts to launch on the New Glenn rocket. After some of my recent reporting, sources reached out to let me know that design work is “well advanced” along with demonstration work such as cabin pressure-vessel manufacturing, extensive parachute testing, in-house thermal protection system testing, life support systems, and more. I’ve heard “no earlier than” dates of 2031 for a crew launch. But that’s probably optimistic, and if NASA and private space station operators need to book transport in the early 2030s, Starliner is probably the only option.

Q. What other vehicles are out there?

A. NASA relied on Russian Soyuz vehicles in the 2010s after the Space Shuttle retired, and before Crew Dragon came online. With Russia’s invasion of Ukraine, Soyuz is off the table for private space stations. India is also developing a crewed spacecraft, Gaganyaan. But it was originally supposed to carry humans in late 2021, and the schedule has since slipped to at least 2027. And for a time Gaganyaan is likely to be used solely for Indian missions. Counting on this vehicle for private space stations seems like a stretch. NASA does have its Orion spacecraft, but the per-seat cost for its missions is likely astronomical ($500 million per seat?), and Orion is needed for lunar missions. The Exploration Company, based in Europe, has ambitious plans for a crewed spacecraft, but it likely won’t be ready until 2035. Sierra Nevada’s Dream Chaser just does not seem like it’s ever going to happen, sorry.

Q. So what’s the answer?

A. You’re probably not going to like this, but the only real hope for a significantly lower sticker price for sending humans into low-Earth orbit is Starship. If incentivized, SpaceX probably could bring this capability online by 2030 and radically reshape the market. But from all publicly available evidence, and based on private conversations, SpaceX seems unlikely to prioritize crewed ascent and reentry on Starship for government astronauts any time soon. Could that change? Certainly. Will it? Probably not. SpaceX and its founder, Elon Musk, will do what they want.

Q. So is SpaceX just being selfish, or what?

A. SpaceX is a business, and like a lot of other businesses, especially publicly traded ones, the goal is to maximize revenue. From their perspective, it makes sense to remove distractions (such as Dragon and Falcon 9) and focus on the future of the company (Starship).

One way of looking at the last 20 years of spaceflight history, and NASA’s efforts to stimulate a low-Earth orbit economy, is to view SpaceX as the exception to the rule. In some sense, an economy based on astronauts in low-Earth orbit got lucky that SpaceX executed so successfully on Dragon. This allowed for the creation of a market around the idea of access at a price of $50 million per seat. At the same time, transportation competitors in cargo (Northrop) and crew (Boeing) struggled mightily. The best SpaceX’s competitors could do was nearly twice the price, and even then, not as reliably.

NASA seems to think Starliner, even at higher prices, will provide the guaranteed access it needs to low-Earth orbit in the 2030s for its astronauts. But in terms of a broader space economy in low-Earth orbit—which for decades the space agency has explicitly sought to foster—it is difficult to see Starliner providing a suitable solution. So yes, SpaceX pulling out of this market harms the industry. But should it be incumbent upon SpaceX to continue a line of business solely because it benefits its peers and competitors?

Full article content is not available for inline reading.

Read the original article →

Over the last year, agent use of Wrangler has skyrocketed.

In March 2026, agents were responsible for a quarter of Wrangler use, up from single-digit percentages the year prior. Last week, agent usage reached 48%.

Agents are more prolific users, using almost twice as many distinct commands per day, and are almost four times as likely to use six or more commands.

Agents love CLIs. But Wrangler only provides commands for around 280 operations, and Cloudflare offers thousands.

Earlier in the year we teased how we were planning to solve this and today, we’re enabling agents to use every Cloudflare product by introducing a new CLI: cf.

cf is a CLI that is built for the next generation of software development:

• Agents can find the command they need to do anything they want to do with bespoke search and steering.
• JSON is the default interface, pretty printed for humans and condensed for agents for maximum context savings.
• cloudflare.config.ts is the new configuration format for the whole of Cloudflare, starting with Workers, and bringing the safety and accuracy of TypeScript to you and your agent’s language server protocol (LSP)
• Vite becomes default, bringing with it the best local development server, and a plugin suite for developers and framework authors.

Install the open beta today globally and run it from anywhere:

npm i -g cf

cf gives your agent access to the entire Cloudflare API

What if your agent could do everything Cloudflare can do? That’s the question that sparked our interest earlier this year: agents were getting ever more powerful, but what they were able to do with Cloudflare’s CLI was still limited.

Wrangler was hand-built with each product team contributing and taking their own approach to their command developer experience. Enforcing patterns across teams was virtually impossible, even across our ~280 command paths. We had inconsistent terminology across d1 info, hyperdrive get, workflows describe as each team came up with their own practices at different times. Some teams built entirely custom experiences across thousands of lines of code that turned out to be used extremely rarely, and teams came up with different approaches to solve the same problems.

We wanted to both standardize what we had and make a massive expansion, all at once. Forge — Cloudflare’s new unified API generation pipeline — enabled us to do this, building on the idea of generating our CLI commands directly from the API schema that powers our API documentation and SDK generation. Everything we provide has an OpenAPI schema, and if we annotate this with just a little more information, we can use it as the source for Forge to make a CLI.

This enables us to expand cf from the ~280 functions that Wrangler had built up over time, to cover the entirety of the Cloudflare API surface of over 3,000 operations.

Now it’s simple to give your agent cf and ask it to go set up a worker, deploy it, monitor and observe it, protect it with Cloudflare Access, buy a domain, and front it with Cloudflare WAF, all from a single tool.

Building for an agent that has never used cf

cf is built for the trajectory of software engineering, where agentic development is drastically changing how software is built and deployed. This year we’ve been focused on providing tools to support this shift, culminating in cf. cf has been built from the ground up with agents in mind, and includes novel tools for agentic command discovery that we think will become standard in more CLIs in the near future.

Wrangler came with the advantage that years of documentation, blogs, and third-party guides have been absorbed into the training process of LLMs. It also came with the same disadvantage: changing how Wrangler works now goes against learned behavior, and significant change would be inevitable given the scale of improvement we want to make.

Introducing a new CLI that agents have never seen sounds like a big disruptive change — but actually it’s the cleanest thing we can do. Because of the design decisions we have made, the context injections we can make, and the AGENTS.md files we can append, making a switch in this way is actually less confusing than having an agent contextualize the major differences between two versions of a tool it is familiar with. We’re launching with a couple of these agent-focused features built in, with more to come.

Agents need to filter JSON, not look at tables

When agents use Wrangler, they append --json to every command they run, and then often filter the output with jq to extract a subset of fields. But only some commands in Wrangler supported --json ; many commands returned unicode tables, designed for humans looking at output in their terminal. Agents can figure these out, but it costs them more time and tokens than a jq filter.

In cf we’re taking the opposite stance: agents just need JSON, and if agents are the future primary user of this tool, it should be the default. For the vast majority of commands that will rarely be accessed by humans, this is obviously the right call.

You as the human customer of this CLI are, in reality, one step removed from using it. Agents being able to easily filter their results and then return that filtered list in whatever format you request is preferable to supplying tables you will never likely read directly.

But what if you’re looking to do something that might require real personal input, like searching for a domain to buy?

For commands that your agent can access through chaining named parameters in a long and unwieldy sequence, you can simply fill in a form. Cf deconstructs the requirements of the API into a series of validated inputs, so buying a domain, even one with complex requirements, is simple to follow.

Or, if you insist, just ask your agent to do it.

Your agent can find the right command itself

With 3,000 possible routes through a CLI, how can your agent find the right operation it needs quickly without bloating your context? For this reason we have also added cf cli search.

This command allows your agent to ask in natural language what it needs to do, and a small search index will provide a list of appropriate commands, based on their API description and parameters. We automatically tell your agent about this command when it runs --help for the first time.

Configuration that type-checks your agent

Our new configuration format is based on TypeScript, which is easy for humans and agents to parse, and allows you to write your configuration programmatically.

Typed configuration is enormously helpful for agents. We’ve found that even with no prior context of the programmatic configuration format, agents are able to easily identify and edit the configuration on demand, even across elements like env which have dramatically changed from the same named feature in Wrangler. All agents that use LSP plugins, such as Claude Code and Codex, benefit from being able to interpret more about the configuration file format in context, and make much more accurate suggestions as a result.

Compare this to TOML, which had no accessible schema, or JSONC, which had a linked schema that agents rarely used.

Some Wrangler configuration files inside Cloudflare have been condensed by 40% from over 5,000 lines, with many custom environments per developer, to factory files that build each developer’s configuration more efficiently.

This is achieved through programmatically defining each environment from the same universal base, instead of copying env blocks as was typical in Wrangler. A simple Worker with multiple environments simply switches on the Vite-native mode argument to swap between one set of configuration and another.

A simple configuration that does this now looks like:

import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./index.js" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker", 
      entrypoint,
      compatibilityDate: "2026-09-27",
      env: {
        Environment: bindings.text(`This is ${mode} environment`),
      },
    },
}));

You can migrate your Cloudflare Worker to this new format through cf migrate.

We’re also providing a few helper functions to make building your Worker a breeze.

bindings gives you a simple place for your agent to discover all the developer platform has to offer. Everything — from environment variables to storage, database, and queues — can be auto-completed and explained by your editor.

import { bindings, defineConfig } from "cf/config";

export default defineConfig(({ mode }) => ({
  worker: {
    // ...
    env: {
      API_URL: bindings.text(
        mode === "production"
          ? "https://example.com"
          : "https://staging.example.com",
      ),
      API_TOKEN: bindings.secret(),
      CACHE: bindings.kv({
        id: mode === "production"
          ? "production-namespace-id"
          : "staging-namespace-id",
      }),
      DATABASE: bindings.d1({ name: `example-${mode}-database` }),
      UPLOADS: bindings.r2({ name: `example-${mode}-uploads` }),
      JOBS: bindings.queue < { userId: string } > ({
        name: `example-${mode}-jobs`,
      }),
      AI: bindings.ai(),
      SEARCH_INDEX: bindings.vectorize({
        name: `example-${mode}-search`,
      }),
      API: bindings.worker({ worker: `example-${mode}-api` }),
    },
  },
}));

Similarly, we have included a helper for triggers, which is the new way to define routes, queues, schedules, and email triggers for your Worker. Rather than having these scattered through your configuration file, it’s now simple to find, in a single block, the actions that could trigger your Worker to run.

import { defineConfig, triggers } from "cf/config";

export default defineConfig({
  worker: {
    // ...
    triggers: [
      triggers.fetch({ pattern: "example.com/*" }),
      triggers.scheduled({ schedule: "0 * * * *" }),
      triggers.queue({ name: "jobs", maxBatchSize: 10 }),
      triggers.email({ addresses: ["support@example.com"] }),
    ],
  },
});

defineConfig.worker is just the start here. Our intention with cloudflare.config.ts is that this is how you manage Cloudflare as a whole. Every product you need — along with its API being available to your agent through cf — will be able to be expressed through typesafe configuration. Soon you will be able to configure entire policies, set up zones, configure DNS and more, all through this configuration file.

A best in class development experience

When Wrangler first started building JavaScript Workers, Vite didn’t exist. Instead, we used esbuild in Wrangler to bundle your Workers. The dev server that Wrangler made available on :8787 was something that the Wrangler team built, and modifying any of this meant reaching into the internals of Cloudflare-specific local tooling like Miniflare.

Vite is a huge improvement on this, and comes with a large ecosystem of plugins you can use, as well as providing a best in class dev server with HMR (hot module replacement), and builds that use the Rust-based library Rolldown for tree-shaking. Anything you can do with Vite, you can do with the Cloudflare Vite Plugin.

The Cloudflare Vite Plugin is the recommended way we suggest you build Workers, whatever you are building: whether that’s a frontend-focused project or a backend API. Together with our Vitest plugin it provides a cohesive development and testing environment that matches the Workers runtime and gives you direct access to bindings and platform APIs.

cf is built on Vite as default. Most of your Workers will migrate simply with agents. Others may take more time, which is why cf will continue to delegate to Wrangler for dev and deployment for JavaScript Workers that need to continue to use esbuild and Rust and Python Workers.

Migrating from Wrangler

Migrating a Worker from Wrangler is as simple as running

cf migrate

Workers that already build with Vite will be converted to cloudflare.config.ts for you. If your Worker relies on Wrangler for esbuild, then cf will continue to delegate builds to Wrangler.

When the open beta ends we will release a final major version of Wrangler that directs you and your agent to use cf. We’ll continue to provide maintenance support for Wrangler for 18 months after the beta ends, to give you time to migrate.

You can also take new projects and automatically configure them for Cloudflare by running cf init/deploy, which will install the Cloudflare Vite Plugin for you and create a configuration file.

Static sites still don’t require a configuration file to start, and deploying them is as simple as running cf deploy in your project.

To start a new Hello World project with cf, use cf init.

cf is open source and issues can be reported to our GitHub repository.

Beyond Kubernetes at Modal: How to Scale 1 Million Concurrent Sandboxes in Seconds

In a recent article, Colin Weld and Connor Adams, staff engineers at Modal, describe how they rebuilt their sandbox infrastructure from the ground up to support millions of concurrent sandboxes and tens of thousands of sandbox creations per second.

According to Weld and Adams, traditional container orchestration systems such as Kubernetes struggle to operate at this scale because they rely heavily on centralized coordination and strongly consistent state.

Running 1 million sandboxes pushes the limits of any container platform, both because of the sheer number of containers, but also because running this many sandboxes requires many tens of thousands of compute nodes. There will be many operations which are either O(containers), O(nodes), or both, which will cause traditional container platforms to hit scaling limits.

In Kubernetes' case, they explain, the load on both the scheduling algorithm and the central durable store (etcd) grows with the number of nodes and pods. Additionally, both pods and nodes write to etcd multiple times, "which can create serious issues under high pod creation rates or high pod churn, and etcd is not natively shardable within a keyspace". They also note that overcoming these limitations is feasible, but requires "serious work", including rewriting or replacing etcd and parallelizing the scheduling algorithm.

To optimize for scale, we decided that everything taking O(sandboxes) or O(nodes) load must be horizontally scalable by default, the sandbox creation path should be as simple as possible, and everything else should be secondary.

The fundamental change Modal's engineers made to their platform was to stop coordinating globally and make scheduling look more like load balancing. Instead of relying on a central datastore as the source of truth, each worker became its own source of truth. Likewise, rather than using a single, serialized scheduler, they deployed a fleet of scheduling servers operating in parallel, allowing the scheduling layer to scale horizontally.

Once a scheduling server decides which worker to create a sandbox on, it contacts the worker directly via RPC to request that a sandbox is created. Workers accept the scheduling request if they have free resources, or otherwise reject it.

The resulting architecture has only one bottleneck, they say: all workers publish their state as a single Redis stream. However, "load testing has suggested that this remains viable until well over 100,000 workers". In their benchmark, they created 1 million sandboxes in under a minute, with median startup-to-code time under 0.5 seconds.

Commenting on the announcement on LinkedIn, Hopsworks CEO Jim Dowling noted that "new technical problems arise at every order of magnitude increase in scale", suggesting the team had to iterate on their design multiple times to achieve a reliable 50,000 sandbox creations per second. More substantively, AWS principal AI engineer Alex Jones observed that a key part of Modal's achievement was not trying to extend Kubernetes but rather "walking around the whole thing" after understanding its limitations. Jones considers this "the first credible signal that Kubernetes isn't adapting fast enough to what GenAI infrastructure actually needs" and argues that:

We're heading for a decoupling of coordination from execution. The execution plane wants what Modal built; isolation boundaries that appear in milliseconds. The coordination plane (where multi-agent workflows need shared memory and overlapping security boundaries) still wants what Kubernetes-shaped systems are good at.

Modal is a serverless compute platform built specifically for AI workloads, providing programmable access to CPUs, GPUs, containers, inference, training, batch jobs, and isolated sandboxes. It is not alone in seeking to "rebuild the cloud" around highly scalable infrastructure and sub-10-millisecond cold starts. Other projects pursuing similar goals include Unikraft, Google Substrate, and Overdrive.

Full article content is not available for inline reading.

Read the original article →

With no shortage of Postgres providers in 2026, one may be confused where to deploy the database powering their next app. One could of course look at dimensions like performance, pricing, and extension support. A dimension not as prevalent in the zeitgeist is reliability.

Database reliability has many facets. Postgres itself is stubbornly reliable. Hardware reliability is an interesting concern, but hyperscalers either offer or host every Postgres option we’re examining today. So on that front, every option here performs about as reliably as hardware can.

To me, a product is reliable when it holds up under workloads it shouldn't have to. While we stress test to shake out bugs in our Postgres offering, customers sometimes punish their database by accident because Postgres memory tuning isn't a solved problem, and the growing share of Postgres databases now provisioned and driven entirely by agents means the "by accident" route will only get busier.

The quicksand of memory management and query tuning

Postgres unfortunately does not have a setting that says "a query can only use X MB of RAM at most please". What it has is work_mem (default 4MB), a ceiling that applies per “operation”, not per query. Every query node in a plan that needs memory gets its own work_mem budget, and a plan can have several such nodes at once. Hash-based nodes get an additional budget multiplier on top from hash_mem_multiplier. The Postgres docs clearly state that actual memory use "could be many times the value of work_mem."

To demonstrate how tricky query tuning can be, let's consider a simple schema on a database with all default Postgres settings. Just two tables, powering a hypothetical LLM inference service:

CREATE TABLE wm_api_keys (
  api_key_id uuid         PRIMARY KEY,
  tier       smallint     NOT NULL,
  scopes     text[]       NOT NULL,
  expires_at timestamptz,
  created_at timestamptz  NOT NULL
);

CREATE TABLE wm_api_calls (
  call_id     bigint         PRIMARY KEY,
  api_key_id  uuid           NOT NULL,
  called_at   timestamptz    NOT NULL,
  model_id    smallint       NOT NULL,
  tokens      integer        NOT NULL,
  cost_usd    numeric(10,6)  NOT NULL,
  latency_ms  integer        NOT NULL
);

Alongside the OLTP traffic from your API gateway, your customers frequently hit a console per-key drilldown view backed by a SELECT statement:

SELECT c.api_key_id,
       sum(c.cost_usd)         AS total_cost_usd,
       sum(c.tokens)           AS total_tokens,
       count(*)                AS n_calls,
       max(c.called_at)        AS last_active_at,
       avg(c.latency_ms)::int  AS avg_latency_ms
FROM wm_api_calls c JOIN wm_api_keys k USING (api_key_id)
WHERE k.tier IN (0, 1, 2)
GROUP BY c.api_key_id
ORDER BY total_cost_usd DESC;

A bit after you launch you have 2000 API keys (congrats!) and they've made a total of 30,000 calls so far. The plan from EXPLAIN (ANALYZE, BUFFERS, VERBOSE) is unremarkable; the relevant lines:

Sort
   Sort Method: quicksort  Memory: 87kB
   ->  HashAggregate
         Batches: 1  Memory Usage: 689kB
         ->  Hash Join
               ->  Seq Scan on wm_api_calls c
               ->  Hash
                     Buckets: 2048  Batches: 1  Memory Usage: 68kB

Three nodes consume memory: the Hash (build side, 68 kB), the HashAggregate (689 kB), and the Sort (87 kB). These sum up to around 0.8 MB, comfortably below the default work_mem threshold.

A note on memory accounting: when we say "total memory" in this section we mean the sum of each memory-using node's peak. Postgres usually holds a node's memory until the end of the query, so we judge this a close-enough approximation.

A few months later, your product has officially gone viral. You now have 55,000 API keys and 9 million API calls. The console page that runs this query has started to feel heavier, so you check the plan:

Sort
   Sort Method: quicksort  Memory: 2926kB
   ->  Finalize GroupAggregate
         ->  Gather Merge
               Workers Planned: 2
               Workers Launched: 2
               ->  Sort  (loops=3)
                     Sort Method: external merge  Disk: 4256kB
                       Worker 0: external merge  Disk: 4256kB
                       Worker 1: external merge  Disk: 4248kB
                     ->  Partial HashAggregate  (loops=3)
                           Batches: 5  Memory Usage: 8241kB  Disk Usage: 3408kB
                             Worker 0: Batches: 5  Memory Usage: 8241kB  Disk Usage: 3400kB
                             Worker 1: Batches: 5  Memory Usage: 8241kB  Disk Usage: 3392kB
                           ->  Hash Join
                                 ->  Parallel Seq Scan on wm_api_calls c
                                 ->  Hash
                                       Buckets: 32768  Batches: 1  Memory Usage: 1671kB

Two things changed just from having more data to process. wm_api_calls is over a gigabyte on disk now, way past the min_parallel_table_scan_size (8 MB default), and the planner pulled in two background workers to speed up query execution. Three processes now run the partial subtree below the Gather Merge: the two workers plus the leader, which by default also acts as a worker. Each process builds its own copy of every node below the Gather Merge, including the join's Hash (1671 kB × 3 processes = 5 MB total). The takeaway here is that each worker has its own memory-using nodes and they have their own memory budget. So adding parallel workers has added an opaque ~3x multiple to our memory usage.

Second, spilling. The Partial HashAggregate shows Memory Usage: 8241kB Disk Usage: 3408kB in each worker. The per-worker Sort says external merge Disk: 4256kB. Two memory-using nodes per process, both writing to temporary files because they've hit the node cap enforced by work_mem. The default work_mem in Postgres is 4 MB. But hash-flavored nodes get work_mem * hash_mem_multiplier (default 2.0) before they spill, so the Partial HashAggregate's cap is 8 MB. The HashAggregate would naturally use ~14 MB per worker if uncapped, which doesn't fit in 8 MB, so partitions to disk in 5 batches, instead. The Sort wants ~5 MB, which doesn't fit in 4 MB, so goes to external merge.

Adding it up across the three processes:

• RAM: 3 × (8.2 MB Partial HashAgg + 1.7 MB Hash) + 2.9 MB outer Sort ≈ 33 MB
• Disk: 3 × (3.4 MB HashAgg partitions + 4.3 MB Sort) ≈ 23 MB

We're using more than 8x work_mem for this relatively simple query and also incurring 23 MB of disk I/O on every console page load. The first-order fix for the Disk Usage and external merge markers in EXPLAIN is to raise work_mem past each node's working set.

An increase to 8 MB eliminates the spilling at the cost of using 8.5× that amount (~68MB) across the parallel processes running the query, due to the combination of tunable factors. The Planner picked workers + 1 from the wm_api_calls table size and the number of memory-using nodes from the query and the data, but hash_mem_multiplier is a per-node modifier, not a query-wide cap. There's only work_mem, applied per node, per process, with a multiplier on hash-flavoured nodes.

If every memory-hungry query respected this model, the article could end here. It doesn't.

Not everything spills

Some executor memory allocations sit outside this tidy work_mem model. It is not just a question of setting the knob too high or forgetting that parallel workers multiply it, but that some structures have no useful disk-backed fallback at all, so they can keep growing until the query finishes or the backend runs out of memory.

Spilling arbitrary executor state is complex, messy, and absolutely obliterates performance if done badly. Postgres has invested a lot of work into spilling where the tradeoff makes sense, but it deliberately keeps some structures in memory. What this means in practice is that it is possible to run queries that don't respect memory tuning parameters under pathological conditions. The query that forms our test workload exhibits this pattern, and it's worth digging into further.

Consider representing directed graphs in Postgres. The simplest pattern would be an edges table like so:

CREATE TABLE edges (
   src bigint NOT NULL,
   dst bigint NOT NULL,
   PRIMARY KEY (src, dst)
);

To find all nodes reachable from node 0, you'd write a recursive CTE. Because the graph may have cycles, the recursion needs UNION (not UNION ALL) to terminate, otherwise it would revisit nodes forever. The use of UNION triggers the creation of a hashtable in the executor for deduplicating rows. The hashtable holds an entry for every reachable node, for the entire query's lifetime, in a memory context that doesn't honour work_mem to spill to disk.

WITH RECURSIVE walk(n) AS (
   SELECT 0::bigint
   UNION
   SELECT e.dst
   FROM walk
   JOIN edges e ON e.src = walk.n
 )
SELECT n
FROM walk;

The hashtable is built by a function BuildTupleHashTable that itself has no logic to spill to disk. The same function backs the HashAggregate we used in the GROUP BY example earlier in this post. So why does that hash table spill cleanly and this one doesn't? It boils down to the hashtable’s purpose.

In HashAggregate, the hashtable is a one-shot accumulator: it ends when input ends. That defined end lets Postgres monitor the table's size and, once it crosses work_mem * hash_mem_multiplier, start routing new-group tuples to disk instead of letting the in-memory table grow further. When input drains, Postgres reads back each on-disk partition and aggregates it in isolation.

In WITH RECURSIVE … UNION, the hashtable needs a deduplication set for the entire query. Every candidate row from every iteration has to be checked against every key seen so far. Sending part of the table to disk would mean reading it back on every membership check, which is catastrophic for throughput. So the table stays in memory for the query's lifetime, until the reachable set is fully materialised.

Benchmarking

We tested 4 Postgres providers under a workload that heavily stresses memory usage. The criterion is that a database should be able to handle as much load as possible and shed the rest cleanly without crashing.

We ran the cyclic-graph recursive UNION query from above over a graph of ~12.6 million nodes, consuming ~1 GiB of RAM from the deduplication hashtable. It generates the edges on the fly using a CROSS JOIN, eliminating variance due to storage and cache performance. From each node, the query creates two outgoing edges: one to the next node, and one 251 positions ahead. The "next node" edge ensures every node is reachable from zero. The second edge gives most nodes multiple incoming paths, so the UNION must reject duplicates on every iteration, and it shortens the recursion from millions of steps to tens of thousands.

WITH RECURSIVE walk(n) AS (
  SELECT 0
  UNION
  SELECT (walk.n + step.s) % 12600000
  FROM walk
  CROSS JOIN (VALUES (1), (251)) AS step(s)
)
SELECT n FROM walk;

A note on memory accounting: Postgres also materialized the CTE output into a tuplestore that honours work_mem and spills the excess to temp files (around ~200 MB for this graph), which creates some I/O pressure across multiple backends but at a rate less than the memory pressure exerted at the same time.

The providers under test are:

1. ClickHouse Managed Postgres [r8gd.large, AWS us-west-2, 118GB local SSD, Postgres 18.6]
2. Google Cloud SQL [db-c4a-highmem-2, us-west1, 118GB Hyperdisk Balanced, Postgres 18.6]
3. PlanetScale Postgres [r8gd.large, AWS us-west-2, 118GB local SSD, Postgres 18.6]
4. Amazon RDS [db.r8g.large, us-west-2, 118GB gp3, Postgres 18.6]

ClickHouse Managed Postgres and PlanetScale both use locally attached SSDs and were therefore set up with synchronous HA (2 standbys) to match the durability guarantees of the others.

For each provider, we opened n concurrent connections running the same query, with n ranging from 7 to 23. We repeated this 10 times at each value of n, with a 60-second cooldown between runs, and sampled per-connection memory usage throughout. Each connection sets a 120-second statement_timeout: a single query normally finishes in under 5 seconds, so anything past two minutes counts as a failure. We also recorded a failure for any connection that returned an error or was terminated. A run in which every connected client lost its session at once was classified as a full outage. The test driver was a single Amazon EC2 instance in the same region as all clusters.

Results

There are three failure modes here: query failure, session failure, and cluster failure. The good thing that Postgres can do is when the allocator sees the failure and the caller checks: a log entry with SQLSTATE 53200 (out_of_memory), the failing transaction rolls back, the connection stays open, the pool keeps that slot, and the next query on that connection works. The other backends and any other clients on the cluster don't even notice. ClickHouse Managed Postgres is the only provider tested that does this. We disable memory overcommit in the kernel and cap committed memory. When a backend asks for more than the overall limit, the allocation fails. Postgres catches this and responds with a SQL ERROR rather than crashing.

When nothing catches the memory pressure in time, the Linux OOM killer fires and picks a backend to SIGKILL. Postgres treats this abnormal exit as potential shared memory corruption and restarts the whole cluster into crash recovery, which results in several minutes of unavailability on a busy system. RDS exhibits this pattern and starts entering crash recovery at 19 connections, when the workload needs way more memory than the cluster has, though a handful of connections occasionally finish their workload before the crash. Before that point, RDS doesn't stop any queries itself, but some queries exceed the 120-second statement_timeout at 15 and 17 connections and error out. This is a sign of thrashing under heavy memory pressure, but we couldn't confirm this theory.

Cloud SQL and PlanetScale take a different approach and run supervisors that watch memory pressure and kill queries before the OOM killer kicks in. The client sees FATAL: terminating connection due to administrator command, which is less polite than an ERROR because the connection itself dies without explanation, but the postmaster remains up and the cluster still serves requests. This isn’t a perfect solution. At 11+ connections, most PlanetScale runs end in a crash. Cloud SQL copes better under heavy load but is more unstable at moderate load. Cloud SQL also occasionally took minutes to recover, causing some future runs to not start and error out prematurely.

These two heatmaps tell different stories about each corresponding table cell. The first shows the fraction of individual queries that finished their query; the second the fraction of runs in which the cluster itself stayed up. At 23 connections, ClickHouse Managed Postgres had 32% query completion but 100% cluster survival: the memory cap stopped ~70% of queries with an ERROR, but the cluster remained healthy throughout. RDS at 23 connections had 7% query completion and 0% cluster survival: the postmaster crashed in every run, and a handful of lucky connections finished their query right before the host gave up.

In this benchmark, ClickHouse Managed Postgres kept the cluster running at every tested connection count by stopping runaway queries before the host was exhausted. Its configuration comes with a tradeoff: Postgres backends do not get to consume as much of host RAM as they do on providers that allow the workload to run closer to the edge. The next heatmap shows that tradeoff directly. Memory allocation on ClickHouse Managed Postgres plateaus at 57% of host RAM, or about 9 GiB on these 16 GiB instances. Cloud SQL and PlanetScale enforce similar memory caps while RDS allows backend memory to climb much higher before failure.

This may seem like a waste of memory, but it is well understood that Postgres performance heavily hinges on caching, both via Postgres shared_buffers and the OS page cache. ClickHouse Managed Postgres carves out dedicated memory for both caches, with 4GB (25%) fully allocated to Postgres shared_buffers by default and a smaller reserve for the Linux kernel overhead, which includes the page cache.

ClickHouse Managed Postgres does limit memory-heavy workloads more than RDS, which takes a more laissez-faire approach. This is why RDS completes more queries than ClickHouse Managed Postgres at moderate load: our cap starts rejecting queries at 9 connections, where the workload reaches it, while RDS keeps accepting them until the host gives out. But RDS's approach costs more than crashes: with no protection against runaway memory consumption, backends may compete with caches and slow everything down.

Conclusion

Our lower memory ceiling is a deliberate tradeoff in favor of uptime, and which approach is better depends on what you want the service to optimize for. Letting backends consume nearly all available RAM can be useful when you fully control the workload and accept that a bad plan or pathological query may take the instance down. Enforcing a lower ceiling leaves some memory unused in the best case, but lets the system fail individual queries instead of the whole database. We would rather return a clean query failure under runaway executor memory than let the postmaster disappear and force every client through crash recovery.

We’re investing in ways to further stabilize the memory profiles of Postgres and our ancillary components running on each VM, with the hopes of giving more memory to user queries in the future.

Get started with ClickHouse Managed Postgres today

Interested in seeing how ClickHouse Managed Postgres works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.

At OpenAI’s DevDay event on Tuesday, the company announced the launch of Dots, a new personal agentic assistant powered by GPT-6 Astra. The company describes Dots as “remarkably capable, always-on agents built to handle everything.”

Unlike Codex or ChatGPT, Dots are meant to operate independent of any specific hardware or interface, pursuing user-defined goals continuously in the background with minimal oversight.

“Today, you can start with your primary dot, give it a name, and make it your own,” OpenAI said in its announcement post. “Over time, we envision teams of Dots working together on your behalf.”

Dots will be available starting Tuesday in ChatGPT, for Pro and Business Premium users in eligible markets. Users can launch Dots from Codex or ChatGPT.

In its announcement, OpenAI envisions a variety of ways Dots could be put to work. In one scenario, a software developer deploys a dedicated dot to monitor customer feedback, implementing bug fixes and requested features as necessary. In another, a scientist employs a dot to rerun analysis and investigate unexpected results as experimental data becomes available.

Users can message Dots through Slack, Teams, and other organizational platforms, with text message support coming soon.

OpenAI also envisions “specialist Dots” that take on specific responsibilities. Individual Dots can be provisioned with specific identities, credentials, and tools through existing systems. OpenAI is already working with Microsoft to integrate into the company’s Agent 365 security controls.

Much of this functionality was already possible through Codex and similar agentic harnesses — but Dots bundles together those features in a new package with a focus on independent agentic actions.

The branding also presents a bubbly, cartoonish persona, similar to Meta’s recently released Muse agent. The Dots look like … well, dots. The little floating cartoons are a makeover for OpenAI’s software and are the latest example of a company attempting to make AI more relatable.

Crafting WCAG 3 for more accessible user experiences

In this post, I cover some of the stakes and challenges in developing W3C Accessibility Guidelines (WCAG) 3. I use "websites" as an example, yet this information generally applies to apps, software, documents, and other digital content and technologies.

Summary

You could say that ideally WCAG would cover all the accessibility needs of people with disabilities, accessibility would be easy to implement in all situations, and comprehensive standards would be implemented in all websites. Alas, our world is not ideal.

If WCAG required that all possible accessibility needs and wants are fully met, it would not be a practical standard that could be implemented by all websites.

If WCAG did not sufficiently address accessibility needs, it would not meet its primary goal. Thus WCAG needs to balance user needs with implementation practicalities. This is an incredible challenge.

The W3C Accessibility Guidelines Working Group is addressing this by covering as many user needs as possible in WCAG 3 and providing guidance on prioritizing implementation. We know that some websites will not go beyond the minimum requirements. We also know that some websites will go beyond the requirements and want to be recognized for providing more accessible websites.

We continue work on ways to encourage all websites to be as accessible as possible.

Different stakeholder needs and wants

People with disabilities need the web to be accessible. It's imperative for equitable access to the digital world.

Most websites have accessibility barriers. To help address this, many countries and regions have laws, regulations, or policies that require websites to be accessible. Most are based on WCAG 2.

Policymakers want a stable standard that can be used to create practical regulations.

Some website owners and developers do not want to be required to make their website accessible. Some push for accessibility standards to have minimal requirements.

These are some of the competing interests in developing accessibility standards.

Balancing stakeholder positions

Competing interests are a major challenge faced by the W3C Accessibility Guidelines Working Group as it develops WCAG 3.

We want WCAG to cover disabled peoples' accessibility needs.

We want WCAG to be adopted and implemented.

As said in the summary above, if WCAG required that all possible accessibility needs and wants are fully met, it would not be a practical standard that could be implemented by all websites. If WCAG did not sufficiently address accessibility needs, it would not meet its primary goal.

An example of finding that balance is providing content in sign languages. Sign is the first language of some people, and some are not as fluent in written text. In that ideal world, perhaps having all text and audio content also available in sign languages would be most accessible. Yet that is not a practical requirement — not with today's technology and resources. Most would agree that providing audio content also in text (captions and transcripts) is a practical requirement. Yet text is not as accessible as sign for some people. Providing content in local sign language is more important in some situations, such as emergency evacuations. How WCAG addresses these issues is one example of the challenges.

To address multiple stakeholder interests, working group participants bring experience from multiple perspectives, including people with a wide range of disabilities, government, implementers, multinational corporations, small businesses, and more.

Over the last few years, the group has explored many different approaches. We are particularly excited about the latest approach. Fundamentally, it simplifies conformance to the standards and provides flexibility for defining policies. It also encourages going beyond conformance to address additional accessibility needs.

I'll say more later; first let me explain a bit about conformance.

WCAG is the ruler

One way to think about the standard and policies is as a measuring ruler and rules.

• Ruler — The WCAG standard documents accessibility requirements. WCAG can be used to measure accessibility.
  • Conformance — When a website meets specified WCAG requirements, it "conforms" to WCAG.
• Rules — Laws, regulations, and policies define which WCAG requirements must be met. Policies can include and exclude WCAG requirements.
  • Compliance — When a website meets a law, it "complies" with that law.

W3C provides the ruler with WCAG.

W3C does not write the rules. Yet we know that WCAG is used in laws, and that factors into WCAG development.

Defining and measuring challenges

WCAG as the ruler and policies as the rules is a nice simple analogy. Yet even defining the ruler is complex.

With digital accessibility, some things apply in all situations and can be fairly easily measured. Yet many things are difficult to define and measure.

Many depend on context. And context impacts the importance. For example, an accessibility annoyance in a form to pay my community chorus dues is not nearly as important as an accessibility barrier in a form to apply for medical treatments.

The W3C community has iterated through different approaches to covering accessibility needs that are difficult to address as requirements in a standard that is often required.

A fundamental shift

The W3C Accessibility Guidelines Working Group has spent time and effort exploring different approaches to conformance for WCAG 3, especially considering that WCAG is used in policies. Much of the previous work on draft conformance was trying to address more things within WCAG and provide flexibility within conformance.

The September 2026 draft of WCAG 3 takes a fundamentally different approach. It further separates conformance to WCAG from details that can be addressed by policies. It defines reporting tiers to encourage greater accessibility towards conformance and beyond conformance. It provides several aspects for policymakers to choose WCAG requirements for different situations.

Specifically, this WCAG 3 draft provides:

• a single level of conformance
  • called "core requirements"
  • builds on WCAG 2.2 Level A and AA success criteria
  • provides a baseline for policymakers
• supplemental requirements, assertions, and recommended practices
  • cover areas that cannot be objectively measured or do not apply to every situation
  • encourage organizations to improve their approach to accessibility
  • encourage websites to go beyond conformance
• "tags" that can be used
  • by regulators to define policies that include and exclude specific requirements for specific situations (for example, more requirements for essential government services and fewer requirements for less important websites)
  • by websites to report progress towards conformance and beyond conformance
• multiple reporting tiers to encourage greater accessibility

This approach simplifies what is considered WCAG conformance and provides flexibility for more specific website reporting and policy development.

Continued WCAG 3 development

We now have an approach that shows promise in balancing the challenges introduced above.

The Working Group welcomes constructive input as it continues to explore and refine the approach and the details to craft a WCAG 3 standard that:

• defines ways for websites to be more accessible to more people with disabilities
• makes it easier for website owners and developers to understand what they need to do
• provides policymakers with an international standard that is flexible to meet different policy contexts
• encourages website owners and developers to improve accessibility by acknowledging success towards conformance to WCAG 3 and beyond conformance
• works in context now and in the future

WCAG is a tool

With all this focus on WCAG, I want to clarify that the goal of accessibility is to meet the needs of disabled people in the real world. WCAG is an important tool for accessibility, yet just meeting WCAG is not the end goal. And meeting only the WCAG 2 Level A and AA success criteria (or only the core requirements of WCAG 3) is not enough. WCAG and policies help motivate, measure, and report on accessibility. Accessible user experiences is the goal.

W3C provides resources to understand disabled people's experiences and to encourage user-centered accessibility.

We plan for the WCAG 3 documents to further support a user-centered accessibility approach.

Learn more and share

To learn more about WCAG 3, start from the WCAG 3 Introduction. It includes review questions and how to submit comments.

We look forward to your input on crafting WCAG 3 to encourage more accessible user experiences in the real world.

Finally, a huge thanks to the Accessibility Guidelines Working Group Co-Chairs, participants, and everyone who contributes constructive perspectives for developing WCAG 3.

Full article content is not available for inline reading.

Read the original article →

Earlier this month we introduced Muse, a personal AI agent available in the US and Canada that completes tasks on your behalf. Today, we’re expanding it with a collection of new skills and connectors inside Muse to help people run their businesses.

Small businesses have been growing on our apps for nearly two decades. They told us they’re short on hours, not ideas. So we built Muse for Small Business to help get work done with the tools they already use.

Tom Mulholland, owner of Mulholland Grocery in Malvern, Iowa, said,

I work about 65 hours a week, and there are so many things where I’m the only one who can do them. I need to free up time for the work that actually makes my business money: cutting the steaks, making the sausages. I’m very good at what I do, but that doesn’t mean I’m good at all of the different roles a small business owner has to play, and Muse is taking over a few of them.

Built to Work With the Tools People Already Use To Run Their Businesses

Muse can connect your Instagram professional account analytics, Facebook Pages, and Meta ad accounts in a few clicks, and it already understands your business: what you sell, what your brand sounds like, and what customers keep asking you about.

Muse can also connect to dozens of tools that businesses already run on, so it can work with your brand, storefront, books, and customer records.

Canva co-founder and CPO, Cameron Adams said,

Muse is an exciting leap towards agents that genuinely help us work, create and make our lives easier. It can help you start to organise your ideas and help them take shape, but the real magic happens when it’s fully connected to your existing work, your context and your brand. By connecting Muse with Canva, all of that becomes part of your conversations. Whether you’re launching a side hustle or polishing a presentation, your favourite Canva templates and tools are right there when you need them; helping you turn an early idea into something on-brand, editable and ready to share.

You can see the full list of available connectors in your Muse app settings, with more to come. Interested partners can apply at muse.ai/platform.

Muse also supports custom connectors so you can plug in services we don’t support yet, which you can learn how to do here.

What Small Businesses are Getting Done with Muse

To help you get started with Muse, we’re sharing five of our favorite Muse use cases:

• Prompt to try: “Analyze this year’s sales, campaigns, and social and make me a growth plan to meet my business goals for next year.”
• Prompt to try: "I'm underwater. What do I need to pay attention to from my email, calendar, news, etc? Can you take any of it off my plate?”
• Prompt to try: “How do I improve my ads and content? Can you analyze what's working or not, and draft a campaign for next week? Make sure to look at what's trending.”
• Prompt to try: “How was my business's financial performance this month? Find any expenses that look off.”
• Because Muse is always working for you, it will also come to you with ideas and solutions, like proactively flagging emails that need a response and writing your first drafts. And you can also head to the Ideas tab for even more ways to put Muse to work for you.

Early Feedback From Small Businesses and Our Partners

People have been testing out Muse’s new skills and connectors ahead of today. Here’s what they told us:

And here’s what our partners are saying:

Muse is free for most of what people need, in line with our vision to put superintelligence in the hands of as many people as possible. For those who want more, we’re offering subscription plans. And we’re building AI across Meta to help businesses at every stage.

In the months ahead, expect more connectors, more skills, and more of the business handled for you. The future is for everyone, especially small businesses, and Muse is how they build it.

Get started with Muse for Small Business today.

Liquid AI

Announcing d1, our first decision model.

It's the first model to outperform Jev on Hugging Face's Decision Index.

• wins on multilingual evals
• more robust against prompt injection
• handles longer inputs more effectively
• built for fast, structured decision-making in software environments

Liquid API: console.liquid.ai
Available on OpenRouter soon

Decision models page: docs.liquid.ai/lfm/models/decision-models
Migration guide: docs.liquid.ai/guides/decision-model-guide
Demo tutorial: github.com/Liquid4All/cookbook/tree/main/examples/road-decider

Enjoy 😊

More from @liquidai

Today we release Pipette, a model evaluation suite for on-device intelligence, in partnership with ArtificialAnalysis.

Most benchmarking platforms are optimized to measure core capabilities and speed profile of foundation models served in the cloud. Pipette gives the field a common, reproducible way to measure the quality, speed, latency, and memory use of AI models on devices such as phones, laptops, PCs, AI boxes, and embedded hardware.

• Pipette is open source
• In Pipette, models get compared as model + quantization + runtime + device from one interface.
• It comes with a warehouse of verified benchmark results, currently with 10k+ results across 35 model classes, 7 quants, llama.cpp runtimes, and 4 devices.
• Pipette is a dynamic platform, allowing new contributions from day one, adding new devices, runtimes, model families, and quantization levels.

What is being released today:

1. An interactive dashboard for exploring and comparing on-device model performance: pipette.liquid.ai
2. A public dataset containing more than 10k results, including 1000+ tested performance configurations across models, quantization levels, runtimes, and devices. Inspect the current breakdown: pipette.liquid.ai/coverage
3. Benchmark clients for macOS, Windows, iOS, and Android that run versioned benchmark definitions on target devices: github.com/Liquid4All/pipette-clients
4. A companion Artificial Analysis dashboard presenting Pipette results and the aggregate benchmark scores: artificialanalysis.ai/hardware-inference-stack/mobile-phones
5. Apache 2.0-licensed open-source infrastructure for benchmark management, execution, submissions, and evaluation scoring.
6. Native iOS and Android apps for running benchmarks directly on-device.

Get started: The initial public release covers about 35 model classes from several providers, with 7 llama.cpp quantization levels.

Laptop and desktop runs cover all four levels, while current phone runs cover all quant levels. The release includes context lengths from 256 to 8,192 tokens, where device memory allows.

Current devices include a MacBook Pro with M5 Max, iPhone 17 Pro, and Samsung Galaxy S26 Ultra, AMD Ryzen AI Max+ 395 with Radeon 8060S (coming live soon). More models, runtimes, and devices are on the way.

Today, we release DSpark draft models for LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B. These add a speculative decoding path that trades a minimal memory increase for a large decoding speedup without changing output quality.

A lightweight draft model proposes a block of candidate tokens and the target model verifies them in a single forward pass. Across MATH500, GSM8K, HumanEval, MBPP, and MT-Bench at batch size 1:

• Up to 3.18x throughput on an H100: LFM2.5-8B-A1B on MATH500, 428 → 1362 tok/s
• Up to 2.87x on an M4 Max MacBook Pro: LFM2.5-1.2B-Instruct on HumanEval, 136 → 389 tok/s
• LFM2.5-2.6B means: 2.67x on the H100 (323 → 864 tok/s), 2.27x on device (61 → 139 tok/s)
• Under greedy decoding, the emitted sequence is identical to baseline by construction, so benchmark accuracy is unchanged.

Each draft model is around 300M parameters, with embedding and LM head tied to its target model. The gain shows most in agentic workloads, where the model reasons before every tool call and the user waits through it all: on BFCL multi-tool scenarios, DSpark cuts LFM2.5-2.6B latency by nearly 50% on average.

Today, we release updated 4-bit checkpoints for LFM2.5-230M, LFM2.5-350M, LFM2.5-1.2B-Instruct, and LFM2.5-2.6B trained with Quantization-Aware Distillation (QAD). These checkpoints recover accuracy lost to 4-bit quantization while retaining the low memory footprint and high decode throughput of the Q4_0 format.

All four checkpoints reach roughly 97% of their BF16 averages.

Post-training quantization (PTQ) compresses an already-trained model without retraining it to adapt to quantization error, which can degrade model quality at lower precisions. QAD addresses this by simulating quantization during training and teaching the resulting quantized student to match a full-precision teacher. The final checkpoint remains a standard Q4_0 GGUF, so it requires no specialized inference runtime.

Today we release Antidoom, an open-source method that removes a common failure mode in reasoning models: the doom loop.

Doom-loop rates before and after, with eval scores up across the board:

• Early LFM2.5-2.6B checkpoint: 10.2% → 1.4%
• Qwen3.5-4B: 22.9% → 1% (greedy sampling)

A doom loop happens when the model emits a span, then repeats it over and over until the context window runs out. Small reasoning models hit it most on hard math and coding. The usual fixes are stopgaps. Applying repetition_penalty can degrade quality. RL needs calibrated rewards and costly rollouts.

Our approach is surgical. The loop almost always starts on one overtrained token, often an interruptive the model overproduces ("Wait," "So," "Alternatively"). We retrain that single token to prefer coherent alternatives and leave the rest of the distribution largely intact.

Today, we release LFM2.5-350M. Agentic loops at 350M parameters. A 350M model trained for reliable data extraction and tool use, where models at this scale typically struggle. <500MB when quantized, built for environments where compute, memory, and latency are constrained.

Trained on 28T tokens with scaled RL, LFM2.5-350M is a step change from LFM2-350M:

• instruction following: 18.20 → 40.69
• data extraction: 11.67 → 32.45
• tool use: 22.95 → 44.11

These are the capabilities that matter in production. What matters isn’t parameter count, it’s what you can actually run. This enables a different deployment model: move high-frequency, structured workloads closer to the data: on-device, on-prem, or at the edge instead of routing everything through a large cloud model.

LocalCowork is an AI agent that runs on a MacBook. Open source.

• 385ms average tool selection.
• 67 tools across 13 MCP servers.
• 14.5GB memory footprint.
• Zero network calls.

Building a local AI agent sounds great until you try to use one all day. The hard part isn’t getting a model to understand you. It’s getting it to choose the right tool and do it fast enough that the experience feels interactive. So we put LFM2-24B-A2B to the test on laptops, building an open-source desktop agent called LocalCowork. Everything runs locally: the model, the tools, the data. No cloud. No API keys. Nothing leaves the machine.

Adapting for a world of software factories

Software engineers have been through a lot of change in the past two years, transitioning from writing code by hand to steering agents via local interactive prompting, the current paradigm. Engineers were skeptical of prompt-driven development at first, but it’s standard now, and by and large folks seem well adjusted to working with agents this way.

The next paradigm is software factories, where agents do more and more autonomous work across the entire software lifecycle. From my conversations with customers and observations of Warp’s own team, making this shift is potentially more challenging than the last one. But the gains in productivity, cost management and control are profound with a factory approach, so I believe the shift is inevitable.

There isn’t a universally agreed upon definition of what “software factory” means, and some folks imagine “dark” factories operating with no human oversight at all. If you don’t need humans, engineers rightly ask what their job is. You end up with a demotivated team that thinks they are no longer needed. Business leaders may want dark factories, but that’s not realistic right now, and pursuing them can cause engineering attrition.

In a factory, all work is public by default, including work that used to be private, in a developer’s “inner loop.” This is very different from what engineers are used to, where they work locally on changes and the first the team sees of them is when those changes are pushed for review as a PR. Working in public exposes how you work, not just what you build, to the entire team, and that can be uncomfortable. This is compounded because work is measured, with it being easy to see how efficient each engineer is from a token use perspective. It can make us all feel like cogs in a machine.

Also, the metaphor of “factory” is kind of a bummer. It feels like your job as an engineer is either working on an assembly line, or building the assembly line that obviates the need for your talents. If you use the “AI teammate” metaphor (which I also dislike), then it feels like engineers are becoming managers of sycophantic and somewhat inept junior engineers. For folks who take pride in the craft of building, this all feels like commoditization of software creation.

A day in the life of a factory engineer

At Warp, our entire focus is on building the technical infrastructure, Warp Factories, to enable teams to make the transition to this new way of working, but we are also thinking hard about how it empowers engineers working with factories. I’ve written a guide for interested teams on the crawl, walk, run steps for adopting factory infrastructure.

At Warp we make clear to our engineering team that they now have two main jobs: building the product and building the factory that builds the product.

Our engineering team still is responsible for the quality and usefulness of the product – this cannot be delegated to agents. They will continue prompting and steering agents to make sure the right thing gets built and that it works well for users.

This is “product engineering,” and humans will continue to do it. Humans are uniquely positioned to know what to build, how the pieces should fit together, what the product experience ought to be, what constitutes good design. Humans have taste, and humans for the time being have more context than agents, making it more likely they build useful stuff.

There are two caveats here though. First, there will be some types of product work that don’t need any human input at all and can be purely automated. Think of fixing server crashes, simple bugs, small UX papercuts, dependency upgrades, etc. This percent starts low (for Warp, it started around 20-30%), but goes up over time. In fact, driving it up is part of the second job of the engineer, which I’ll get to momentarily.

The second caveat is that product engineering will work differently than in the past. Rather than engineers working locally with their own bespoke setups, they will primarily be doing this work “through the software factory,” which means prompting agents that live in the cloud through knowledge work tools like Slack and Jira, in public. They will hand off as much of the software lifecycle as possible to the factory. All of this work will be inherently visible and measurable, and that’s a feature, not a bug. The whole team should be trying to work more publicly and with more of a bias towards automation.

At Warp we measure “human touches per PR,” and over time, this number should go down. For example, say an engineer is building a relatively complex feature into an app, like adding searching, sorting and filtering to a database driven view (just pulling a random task we did recently at Warp). A human will do an initial prompt (first touch), provide context like mocks, and iterate with a factory agent on a spec (n touches, while you iterate). Then the factory takes over for a bit, doing implementation, adversarial code review, and producing computer use videos showing the behavior. Then a human looks again, and may or may not need to do a manual code review (another touch). Over time there will be fewer touches as the factory improves.

In addition to automation metrics, developers should expect to also measure and iterate on other aspects of how they use the factory, including how much their agents ship, and at what cost. Again, engineers could view this as a drag, but they also can view it as a game, and winning that game means shipping more for less, using an engineering mindset to improve.

This brings me to the second job of the engineer, which is, somewhat ironically, to engineer the factory so they are doing less of the first job. I call this factory engineering. It consists of measuring the performance of your factory using DORA metrics and LLM-as-a-judge scorers, identifying areas for potential improvement to skills, context and model mix, and implementing changes that increase automation and velocity. This needs to be done with an engineering mindset – you don’t adjust your factory on vibes; you measure, test, benchmark and then improve. Some of this improvement itself can be automated via self-improvement, but much of it needs human insight.

At Warp we make it explicit that the expectation of engineers is not just to build products, but to improve factories. We bake this into feedback and performance reviews, celebrate changes that make code production more efficient or higher quality, and ask senior engineers to model the behavior. We envision both jobs as being the responsibility of all engineers, to make it clear that factory engineering is now part of software engineering.

We emphasize that this work is engineering, albeit of a new kind, and can be really fun. On our team, the folks who like it most are senior engineers who love hard systems problems, who enjoy optimizing and debugging performance issues. It requires a lot of thought, testing and patience. We lean into it as a new skill to learn. And ultimately it lets us ship better products more quickly, which has always been our mission.

Closing thoughts

We’ve been through a lot of change as engineers in the past two years, and that change is going to continue as software factories roll out. Engineers are now responsible for both product engineering and factory engineering. Factory engineering is real engineering and a skill to develop.

Warp’s mission is to provide the world’s best engineering teams with the tools to build, measure and optimize their own workflows using any underlying model and harness on open infrastructure. These capabilities will help teams ship better software more quickly and efficiently.

Warp Factories is currently in early access. Qualified companies get $10k of factory usage.

Announcing Cohere's Embed 5 Models

We’re pleased to announce the release of Embed 5, Cohere’s most powerful embeddings family yet.

Embed 5 delivers frontier retrieval quality on complex enterprise data, with major gains over Embed 4 on visually rich documents, financial filings, parsed PDFs, code, and multilingual retrieval.

Key features

• Two model variants available:
  • embed-v5.0-pro: Optimized for the highest retrieval quality, particularly for offline indexing and quality-critical retrieval
  • embed-v5.0-fast: Optimized for low latency and high throughput, particularly for interactive search, agent loops, and high-volume query traffic
• Shared embedding space: Pro and Fast share an embedding space, so a corpus indexed with one model can be queried with the other. We recommend indexing with Pro and querying with Fast.
• Multimodal inputs: Embed text, images, and mixed text-and-image inputs (e.g. PDF pages) in a single vector
• Multilingual support: Supports over 100 languages
• Extended context length: 128k token context window
• Flexible storage: Matryoshka embeddings in the following dimensions: [256, 512, 768, 1024, 1536, 2048], with float, int8, and binary output types

Availability

Embed 5 is available through the Embed API, as well as Microsoft Foundry (Pro, Fast) and Amazon SageMaker (Pro, Fast). For single-tenant deployment, Embed 5 is also available in Cohere’s Model Vault.

For more details, see the model documentation.

We’re excited to share that Devin is now significantly cheaper to use: 30-40% cheaper in Fusion and Normal mode, 15-20% in Ultra, and up to 70% cheaper in Devin Review.

These improvements come from incorporating the latest models, including SWE-2, and engineering Devin’s Cloud harness to make the most out of them. These gains mean that your Devin usage can go much further.

Alongside these savings, we’ve maintained or improved intelligence across every Devin mode. In fact, Devin Fusion now leads FrontierCode 1.1 with a score of 68.8 on Extended, at $0.60 per task on average.

Model independence pays off

Devin gets the best from all the latest models. Different models have different strengths, and new releases can change what’s possible at a given cost. Opus 5.5 and GPT-6 Sol bring stronger intelligence while being price-performant, GPT-6 Astra offers excellent computer use, and GPT-6 Luna substantially lowers the cost for supporting tasks. Alongside our own SWE-2 and many other models, these give us the flexibility to choose the right fit for each part of Devin.

Fusion puts this flexibility to work by pairing a capable lead model with a more cost-effective sidekick, benefiting from advances in both intelligence and efficiency. Devin Review is able to choose the best models for analyzing diffs, finding bugs, and categorizing changes. Finally, Normal and Ultra benefit from the same flexibility, letting us choose models for their strengths in planning, testing, debugging, migrations, and more.

A more efficient harness

Alongside model upgrades, we continually improve Devin’s harness to take advantage of new model capabilities. With recent releases, we’ve improved the harness to allow Devin to accomplish more in each step and make the most of cached context.

Fewer, smarter tool calls

Newer models are getting better at reasoning over several actions together rather than working through every small operation one turn at a time. For a sequence like formatting code, linting, and running tests, the model can request all three in a single tool call, then reason about the results together. The model needs fewer turns and spends fewer tokens coordinating the work, making the overall session cheaper to complete.

We’ve further refined how Devin batches several shell commands into a single call and runs independent tool calls in parallel, taking advantage of newer models’ ability to plan more work in each turn. Independent steps can run in parallel, and planned sequences can execute back-to-back without returning to the model between commands.

Making the most of caching

LLMs are stateless. For a coding agent like Devin, each request must include the context the model needs to decide what to do next: instructions, relevant code, and previous actions. Processing that growing history from scratch at every turn would be slow and expensive. Prompt caching avoids repeating much of that work: when the beginning of a request matches a previous one, the model can reuse the saved calculations for that shared prefix rather than process the same input again. The model still has access to the context, but reusing it is much cheaper and faster.

Making the most of caching takes careful harness design. The shared prefix must stay unchanged, caches have a limited lifetime, and cached computation is specific to a model and provider. Devin’s harness is optimized to reuse context within those constraints, so it benefits as caching gets cheaper across providers. Opus 5.5’s cache reads cost 60% less than Opus 5’s, while GPT-6 Sol and Luna both halve cache-read prices compared with their 5.6 predecessors. Across a task that carries a long history through many turns, those savings add up.

Get more out of Devin today

A more efficient Devin is available today at devin.ai, so you can tackle your most ambitious work and get more out of your Devin usage.

We can’t wait to see what you build.

OpenAI made more than 20 major announcements across ChatGPT, Codex, its models, and more at DevDay 2026. It introduced agents that can take on ongoing responsibilities and new ways for people and AI to work together. The company also expanded its commitment to an open ecosystem by opening up ChatGPT as a shared surface where humans and agents can collaborate and where developers can directly launch new native experiences. There is now a new Pro 500 plan that offers 25 times the ChatGPT Plus allowance and includes access to Ultrafast.

Data is the application

Agentic coding lets me move very fast. A feature gets built in days. A design gets implemented in a matter of hours. Changing a layout, updating a template, reworking a flow: all of it happens at a speed I couldn’t have imagined a year ago.

There’s one part of the stack where none of that speed applies to me: the data.

Everything else has an undo button

Most of my work these days happens from a phone, talking to a remote coding environment. A lot of that work is iteration, and iteration is cheap when a change can be reverted.

• A layout that doesn’t quite work once people use it? The next version is a deploy away.
• A bug? Fixed, deployed, gone.
• Some translations that are wrong? Redeploy, fixed.
• A redesign that makes part of the UI less confusing, but harder to use? Redeploy, fixed.
• Started a feature and don’t like where it’s going? Cancel it. The branch just sits there, harmless.

None of that goes out untested. Every change still runs through the test suite, and I still read the diff before it merges. What changed is the cost of a wrong call: if a screen turns out to be confusing once real people use it, the fix is minutes away. That’s why I’m comfortable doing that kind of work from the couch.

So I move quickly, iterate, pivot, change my mind halfway through, deploy and redeploy, undo things I didn’t even finish, … It’s the reason I take more time to think about features now: generating a new version is so cheap that trying three of them is the normal way to work.

Data doesn’t

Every time I have to touch the data layer, I stop.

I can’t do it from a phone. I need to be behind a desk, at a laptop, in thinking mode, without distractions. Because this is the layer where a mistake doesn’t get undone by the next deploy.

There are coding patterns that soften the blow, sure. Soft deletes, a migration with a proper down(), a backup from last night. But those undo a change to the code, not the loss itself. If a migration truncated a column, the down() puts the column back. Empty.

Event sourcing gets the closest. You don’t store the current state, you store every change as an event (OrderPlaced, AddressChanged, …) and build your tables from those. Break a table with a bad migration? Throw it away and replay the events into a new one. Spatie’s event sourcing package has an event-sourcing:replay command for that. That’s a real undo button for the data layer.

But the one-way door is still there, it just moved to the events. The log is append-only, so a badly designed event stays in it forever. An event you never recorded can’t be replayed. And an append-only log of everything a user ever did is the last thing you want when that user asks you to delete their account.

Data is data. If you don’t have it, you can’t reproduce it.

Take Snapkin. When you tell it once that the white blob on your breakfast plate is skyr and not yogurt, it remembers that and uses it from then on. I can rebuild the screen that asked the question in an afternoon. I can’t rebuild the answer. Only the person who ate the skyr knows that, and they told the app exactly once.

One-way doors

Jeff Bezos has a name for this. In his 2015 letter to Amazon shareholders, he splits decisions into two kinds:

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. […] But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors.

Agentic coding turned almost everything I build into a two-way door. A layout, a feature, a translation: walk through, don’t like it, walk back.

Bezos was warning about treating two-way doors with one-way care, because that makes a company slow. With agents, I worry about the opposite mistake: walking through a one-way door at two-way-door speed, because everything around it moves that fast.

And the data layer is where the one-way doors are:

• Migrations.
• What you store, and in which format.
• Data structures.
• Backups.
• Recovery.

Every data migration, and every moment in the app where I have to decide whether to store something and if so, how, makes me take a break. Those decisions are where most of my time and thinking goes now. Not the UI, not the UX, not the features, not what’s next on the list. All of those can stay fluid. They change, and I adapt them to what users say or want.

The data is sacred.

That doesn’t make a data decision permanent. I can change a column type, split a table or move a field somewhere else later. But every one of those changes touches rows that already exist, so it takes a lot more effort and thinking to make sure nothing gets lost and that every change to the data is intentional. A layout change is a new deploy. A data change is a plan: what happens to every existing row, how I check it worked, and how I get back if it didn’t.

A field I decide to store is a field I now have to protect, back up, and eventually delete again. A field I decide not to store is gone for good. I can’t go back and ask people what they did last Tuesday.

Privacy and retention don’t get rushed either

Then there’s privacy and data retention. How long do I keep something? Who can see it? What happens when somebody deletes their account, and does that also cover the backups? What does a backup even mean if it holds data I promised to throw away?

None of those have a quick answer, and none of them get easier because an agent can write the migration in 30 seconds. Writing the migration was never the slow part. Thinking through what it does to data that’s already there is.

The data is the application

Take everything away from an app: the UI, the website, the mobile app, the servers, the infrastructure. You can build all of that again, and with the tools we have now, faster than ever.

You can’t do that with the data your users gave you. Lose it, and whatever you rebuild is an empty shell with a login screen.

So I’ll happily iterate on a layout from my phone. The migration waits until I’m at my desk.

Meta seems to be announcing something everyday these days. Yesterday, the company announced “Meta Enterprise Platform”.

Meta Enterprise Platform will use our strengths that few other companies have: advanced models, leading agents, large-scale infrastructure, and years of working closely with many businesses. Initially, we will focus on bringing our full technology stack, including the Muse agent, Meta Business Agent, Muse API, Muse Code, and more to businesses and developers to help them grow.

More interestingly, Meta hired CJ Desai away from MongoDB to run their enterprise platform. Desai had been MongoDB’s CEO for eleven months, and was president of product and engineering at Cloudflare before that.

For a company that is quite adept at monetizing consumer attention and a history of failure at getting much traction in enterprise, I think it is fair to say the consensus around this announcement leans towards skepticism.

Ben Thompson, while remaining enthusiastic about Meta’s AI related investments, also said that he “hates” this. I don’t want to be contrarian for the sake of it, especially because consensus is often right. However, I do believe there are compelling reasons why Meta is pursuing the enterprise opportunity here.

The simplest reason is probably that Meta needs a “second” customer. Meta is committing “tens of gigawatts” against a demand forecast for a set of first-party products whose adoption curve likely has a high margin of error. Muse seems to have found at least the initial product-market fit as a consumer agent, but I have no idea, and I suspect Meta doesn’t either, whether it ends up a 500 million user product or a two billion user product (also in what timeframe), or how much compute an agentic product will consume per user once people actually let it do things at scale. Moreover, we also don’t know the forward pricing curve of computing itself. Even small margin of error (on either side) can really compound here in forecasting Meta’s aggregate compute need in out years.

With only first-party products, being wrong is expensive in both directions. If Meta underbuilds and they can’t serve the product they just found product-market fit for, the users will drift to competing AI agents/products.

If Meta overbuilds (which is both Alphabet and Meta’s stated strategic preference if they must choose one), the surplus will depreciate through the ad business’s margins. A second demand sink lowers the expected cost of being wrong on the high side as building aggressively then starts looking the more of an optimal strategy. I do believe Meta’s first party products will remain the best use of compute, but the optimal strategy when you are underwriting a gargantuan capex build out may not be 100% 1P products. I am much more nervous about 3P hyperscalers (e.g. Amazon) who are much more reliant on selling compute without the reservoir of compute needs from 1P products. But the opposite extreme may also be sup-optimal.

Meta already has upside flex since it rents in from CoreWeave, Nebius, Google and Oracle when it needs more than it owns. However, it still does lack a downside flex. A 3P channel is the missing half which will let Meta rent in on the upside, and rent out on the downside.

Moreover, one of the challenges with pursuing the consumer agent opportunity is that Muse may well be a category defining business in 2030, but it is not going to contribute billions this year or, I suspect, next. It’s partly why companies such as OpenAI may find it difficult to make their consumer agents available to everyone. The fact that OpenAI’s annual run rate reportedly reached $70 Billion on the back of enterprise momentum will make it even more challenging for them to divert compute to consumer agents, especially when they still require outside capital to fund their business.

While Meta is very profitable business, I think Zuckerberg too wants to keep raising capex, and perhaps would like to tap the debt or equity markets to fund such capex. Even for Meta, it may be asking investors too much to fund a slow grind of consumer agents (relative to enterprise revenue momentum) and he likely needs the canvas of opportunities to look wider than the street currently believes. As OpenAI’s own rapid pivot and success in enterprise suggests, enterprise is the fastest way to widen it.

There is also an underappreciated risk that I actually worry about. In my recent post on Anthropic, I noted:

“The end-2026 exit run-rate ($100 Billion, the low end of what the FT says investors expect) over year-end inference watts gives a yield of ~$49 Billion per inference gigawatt-year. If such yield sustains till 2030, Anthropic would be a steal at the rumored $2 Trillion valuation at IPO.”

Given OpenAI is also perhaps racing to similar level of revenue run rate by this year, it is fair to say that the labs are making money hand over fist, at least on the inference slice of the fleet.

Now think about what that means for the incremental capacity coming online over the next few years. It seems plausible to me that if more than half of it ends up with OpenAI and Anthropic, and if yield per inference gigawatt stays anywhere in the $30-40 billion range, then the labs can afford to bid up the price of compute to a level anyone other than labs will find difficult to match. If the marginal inference gigawatt earns Anthropic $36 billion a year, it can pay $20 billion a year for it and still be fine. If Meta's marginal gigawatt earns, say, $15 billion a year, Meta can't. I don’t really believe that this is what’s going to happen, but I would also like to be a bit humble about this possibility given that I would probably be also skeptical this time last year if you mentioned to me that OpenAI and Anthropic would be generating the kind of inference revenue per GW they’re generating in 2026.

Moreover, I don't think it's only Meta's problem. If the incremental capacity keeps flowing to two labs, the hyperscalers' backlogs will get more concentrated in those two counterparties over time, which hands the labs a lot of power over the hyperscalers, and the same thing rolls down through the chip vendors and the rest of the value chain. Nobody in that chain should want a duopoly at the frontier.

That’s why I believe Zuckerberg wants revenue per inference gigawatt to come down to a level that leaves room for everyone else near the frontier. I’m not suggesting he wants to drive the labs’ returns to zero; that would make no sense for anyone, including Meta, which needs its own returns on capex. But he needs the yield to compress enough that a Meta can still get its hands on the marginal gigawatt. Meta doesn’t have to win the enterprise for this to work, but it has to be a credible alternative at a lower price which caps what the labs can charge, and which caps what they can bid. Even a modestly successful enterprise business has strategic value well beyond Meta’s own P&L.

But what is Meta’s enterprise go-to-market? How can they possibly have a shot here? Well, in this cycle, the model is the go-to-market. Neither Anthropic nor OpenAI got to their current run-rates by building a decade of enterprise field sales. They got there because they had a frontier model developers wanted, and, between them, they distributed that model through Bedrock, Vertex and Foundry. Such an option did not exist when Google Cloud started grinding its way into the enterprise. There was no marketplace where a third party would sell your “cloud” for you. There are now at least three. A hyperscaler whose backlog is concentrating in two labs also has every reason to put another frontier option in front of its customers, if only to dilute those labs' bargaining power. However, Muse served through Bedrock runs on Amazon's gigawatts and the downside flex I described earlier only materializes to the extent enterprise inference actually lands on Meta's own fleet, which I suspect is the point of having a direct platform at all. As a result, I believe the marketplaces are the on-ramp for the model to get it in front of the developers, but Meta Enterprise Platform is where the larger and more agentic workloads end up over time.

Of course, the whole enterprise strategy relies on Muse Spark staying close enough to the frontier that the price advantage means something. If it doesn’t, none of this may matter. Watermelon as well as post-watermelon models will have to keep up with the labs to gain the confidence from the enterprise customers that there is no “Llama-4” type fiasco lurking here.

Look, everybody knows Meta isn't an enterprise company. CJ Desai knew it too, and he still chose to walk out of a public CEO seat literally a day before his own investor day to take the job. The team Meta has been assembling also makes me think Meta is much more serious here than market probably believes. A former enterprise chief reporting straight to Zuckerberg, an ex-AWS S-team member owning the infrastructure product, Daniel Gross running capacity strategy and supplier partnerships at Meta Compute, and Dina Powell McCormick working the sovereign financing angle…this doesn’t seem like a half-hearted meek attempt at the enterprise. I would rather Meta take this swing NOW when the model is the go-to-market and the hyperscalers have a reason to help, than wait until the labs have locked up the next twenty gigawatts and the question of who gets to compete at the frontier has already been answered.

Today, the Firefox 157 update will roll out a redesign of the web browser across desktop and mobile platforms. The team that made it hopes it will help expand the browser’s audience beyond privacy-conscious techies and open-web or open source advocates to a broader audience who might simply pick the browser because they prefer its user experience over competitors like Chrome, Edge, and Safari.

In advance of the redesign’s launch, I spent half an hour chatting with Mozilla’s head of Firefox, Ajit Varma, about Firefox’s current market position and product strategy, and what barriers or opportunities there are for gaining ground in a Chromium-dominated landscape.

Firefox’s interface has recently felt more conservative than niche browsers. And when I asked Paddy Harrington, a senior analyst at Forrester who covers this space, what Firefox’s main barrier to adoption is, he was frank.

“The biggest is they’re not Chrome,” he replied. “That sounds simplistic, but it’s the clear truth. Safari and Edge are built into the leading operating systems in business and consumer markets, yet people still download and deploy Chrome.”

That said, for many of the people who have chosen to use Firefox, “it’s not Chrome” is much of the appeal. Google-led Chromium dominates the web. It doesn’t just power Google’s own Chrome browser (which has majority market share by a wide margin), it powers most of the rest of the competition, too, including Microsoft Edge.

Firefox, which is built on the open source Gecko, serves as a Chromium-free alternative and has become one of the go-to choices for users who don’t want to contribute to one company’s dominance of the open web—though there is even tension there, and a deal to offer Google search as Firefox’s default provides Mozilla with the majority of its revenue. For now, Firefox seeks independence for the web while remaining financially dependent on its dominant competitor.

But to expand beyond the relatively small market share it now has, Firefox has to inspire users to actively select it over incumbents by providing a better browsing experience; most people don’t care whether Chromium dominates, and most have never heard of Gecko.

In our conversation, Varma expressed hope and ambition that these modernizations will help more users choose Firefox for its merits as a product. We also discussed the Firefox team’s competing priorities, its development resources, AI features and tooling, the general browser market, and more.

A conversation with Ajit Varma

This interview has been edited for length and clarity.

Ars Technica: It’s nice to see a bit of modernization of the design of Firefox. But what problems does this redesign solve? How does it advance browser choice and the open web beyond just being a browser that’s a little more appealing and a little easier to use?

Ajit Varma: Yeah, I think there’s been a lot of questions around, “What are we doing this at the cost of?” Like should we be focused on performance? Should we be focused on compatibility?

We are trying to do all of the above and work faster, and I think that’s one of the challenges that Firefox had in the past, was there was slow decision-making. There was a lot of debate, and in the last like year and a half, we’ve actually been trying to say, can we get a lot more velocity, and compete? And part of this is made possible by AI tools, to be honest with you. We are able to do a lot more.

People want to feel like they’re in a modern browser—things that match the design language of the operating system. So that’s part of it. We are bringing back compact mode as well… and we also have launched more customization options.

There’s a lot of functionality that’s been built to give all the modern productivity things that people wanted, and those are all very utilitarian, but it’s also the emotional connection, and do people feel like it’s a browser that feels modern as well.

Ars: Sure, I’m happy to see it. But right now, I would guess most users pick Firefox as almost a values statement, right? That’s not always the same thing as thinking it’s the most effective or enjoyable browser to use. And not everyone even cares about that values question, right? So are you trying to win users over by providing superior features and a better experience to become everyone’s browser? Or are you just trying to build the best browser for a particular audience with a certain set of values?

Varma: We are focused on building the best browser for a wide group of people. I agree with you that there is a subset of people who really understand the importance of competition and choice in a browser engine. When people look at a lot of competitive browsers, they are built on top of Chromium, and there’s a lot of risks to that. For me personally, that is the reason that I work at Firefox and work on Gecko; it’s because I don’t want this consolidation to exist that destroys all the things that we love about an open Internet.

When we talk to a lot of users that are the broad set, people don’t understand, like, what is Chromium versus Blink versus Chrome, what is Gecko versus Firefox. A lot of people actually don’t even really know what the difference is between a search engine and a browser, and it’s all conflated.

So the reality is that even though I think a lot of our values are what drive us internally—this preservation of the open Internet—it’s hard for people to connect all those dots. Many of us people are like, well, does the browser feel enjoyable to use? And when I download it for the first time, does it feel special? Does it feel unique?

And that’s where we do have an opportunity to also differentiate against Chromium browsers. When you look at a lot of those projects, they feel all very similar because it is much easier to fork and make superficial changes than make deeper changes. But we get an advantage by owning the entire stack. We can actually make bolder changes.

I do think that we need to cater to more than just very educated and informed people, going for a mass audience that doesn’t care about Gecko versus Chromium.

Ars: With that mass audience, you need it to even occur to them to change. How much of Firefox’s minority position right now is platform obstruction, how much is inertia, how much is Firefox’s own product execution, and how much of it is people picking their desktop browser to match what they’re using on mobile, where you’re not as competitive?

Varma: We do see that when people have a moment to decide what they use, Firefox does really well. That kind of goes into your point around, like, consideration is actually the biggest barrier. A lot of people just don’t really consider what browser they use as an important decision. The reason we know this is because in Europe, you have choice screens on mobile. This is part of the Digital Markets Act. There’s a split second when you get a new device: here’s the list of browsers, what do you want to use? We see a lot of growth in Firefox since these choice screens were implemented because I think people know Firefox, they understand privacy values, and then that resonates with them.

The biggest indicator, though, of what browser someone uses is actually, what browser did they use last month? People just use what they were using before; they’re not taking this moment to consider. But the last year we’ve actually seen a lot of moments that cause people to start to consider what browser they use.

So some examples—Chrome went through with their deprecation of Manifest V2. Manifest V2 is basically a much more powerful extension system. And people were like, well, why did this decrease? Why didn’t they just fix the security vulnerabilities in Manifest V2? And it’s very clearly because of ad blockers. That was the reason to deprecate it. Whereas, Mozilla, we’re not maximizing for profits, we’re maximizing for user experience and browser experience, and we want people to have powerful extensions. So we noticed when that shutoff moment happened, there was a moment where people said, do you want the power of an engine to be able to dictate how I control my experience? Because once Chromium shut it off, Edge shut it off, all the Chromium browsers then shut off Manifest V2 support. We still support it, and so we saw a big surge of actual users who started using us.

Also, with AI controls, you see a lot of worries that people have with AI, and whether societal implications or my own personal experience, of whether I want to use it or not. And many browsers are pushing AI very heavily, because if you look at major browsers and they have their hierarchy of needs, they actually probably care more about AI adoption than they do about browser experience. And so there was a criticism around Edge becoming a Copilot app—Gemini is very forceful in its integration in Chrome—but neither Copilot nor Gemini are the main AI that people use. People use ChatGPT, people use Claude. And so our approach is all about choice.

So we built AI controls. It’s a prominent, top-level setting. People can turn it off if they don’t want it. People can set only certain features that they want, like translations. And so we’ve noticed a lot of people actually want that from Firefox. And so this is another consideration moment where someone is like, my browser is getting bloated, I want a choice. A lot of our strategy over the next year is really around, how do we create more and more consideration moments where people take that second to think of what browser they should use? So we think something like customization is more of a consideration.

Ars: You mentioned that the best predictor of what browser someone’s going to use is what browser they were using last year. The browsers that people use are not just the ones they’re using on their personal devices. How important are schools, employers, and IT administrators to Firefox’s growth strategy? Does a consumer-focused redesign like this address what those decision-makers need?

Varma: One of the biggest new investments that we’re making is actually building the tools that enterprises and schools need. So if you look at especially over the last year, I don’t think we’ve made as many public announcements, but we have a fairly sizable team that’s actually going after this area. Enterprises care a lot about other features like digital loss prevention, like manageability, the ability to have more controls. This is a big area.

The other thing that we’re seeing around this is there are more and more companies that care a lot about digital sovereignty, and they want tools that they have more confidence aren’t going to be under the control of any particular government that may have been viewed as antagonistic or more challenging to work with. In a lot of places in Europe, a lot of places in Asia, we’re actually seeing a lot of people reach out to us about, how do they use Firefox because of our open source nature.

We’re a global company. And we don’t have some of the same ability to control us because we don’t have all these other tentacles spread out. We can really just focus on building the best browser. The needs of enterprises and schools are very different, but it’s actually probably the biggest new area of investment that we’ve had over the last 12 months.

Ars: You mentioned the idea of sovereignty for these enterprises, and another consideration under that umbrella is AI model choice. I know that’s a big emphasis with what you’re doing with the AI features in Firefox, so I do want to talk about AI for a minute. What signals suggest to you that AI features are in high demand, especially among the arguably privacy-conscious, maybe even a little bit old-school users that Firefox is known for? Is there a tension in investing so much in AI when one of Firefox’s key differentiators is the ability to block or decline it?

Varma: The usage of AI is still a minority compared to the overall browser usage. Like, you have billions of people who are using a browser every day; there’s definitely not anywhere close to that using AI tools in a browser every day. In the future, though, you have different paths, and I think that there is a plausible path where for a lot of the productivity kind of use cases, people want the benefits of AI, and you’re starting to see that emerge—things like translations are AI, summarization, auto-grouping of your tabs in a more organized way.

The stance that we’re taking is we just want to make it easy for people to be in the state that they want to be in, but we’re not doing it in a way that is typical of VC-backed companies that are like, we’re gonna spend hundreds of millions of dollars and see what happens. We are much more thoughtful about it. We are looking at things like on-device models that are cheaper to run. We are looking at open source models. There’s this balance that we are definitely looking at in terms of investment.

But the thing I’d say is, we want people to have choice. For someone who is an AI skeptic who wants to turn all AI off, that’s fine, we’re not going to push you to use AI. Once you turn AI controls off we’re never going to prompt you to use any AI tools. If you are an AI dabbler and you want really private models, we’re gonna give you that choice. But then if you’re someone who really wants to have AI on autopilot and check a price for you, or check if a new product is launching every day, and your browser goes and searches, well, that’s a convenience aspect that we think that a subset of people want for sure, that we want to provide that functionality to.

But one of the things that we do hear from people is people love auto-complete and suggest and stuff, and so we spent a lot of time on the non-AI version of that, which is, here’s an address, fill an address. But it goes to, well, what if you want your job application filled out? Those things are made better with on-device ML and AI that I don’t think people are equating to the AGI world, or you know, reinforced learning of bots that might take over the world and kill humans. This is like, we’re helping you fill in a form. That technically is still AI.

Ars: I agree with you that some of those things are useful and a lot of people don’t even think about them as being AI. On the other hand, you have something like Smart Windows, which is AI-in-the-face, right? There is a lot of investment going into AI features that maybe could have gone to other things, like making the mobile app better. How do you manage the tension where you have a significant portion of your audience who just don’t care about this, but then, you look at your product roadmap and there’s a lot of AI stuff in there and there’s people working on that AI stuff?

Varma: I think that there’s probably speculation, because I don’t know that we disclose how much our allocation to each area is. But I think that we need to make bets. But the number of engineers that we have working on this versus all the other stuff is less than 10 percent of the overall engineering. The core and the biggest investment that we have is on Gecko.

That’s things like performance, web compatibility, new APIs for developers, and I think some of those things are just harder for people to notice… but historically, I do think that one of the mistakes that Mozilla made 15 years ago was, it didn’t invest in mobile apps early enough. The bread and butter was desktop, and it was, let’s focus on desktop, desktop, desktop. And then mobile turned into a big opportunity that I think in retrospect was something that could have been invested in more.

Now, Mozilla did try something—the Firefox OS to build HTML apps. It tried this very ambitious, can you create a competitor to Android and iOS? I think in this approach, we’re not doing that.

So you could imagine that one world is: we’re going to build our own AI models, we’re going to build our own agents. And that’s where I think a lot of the expensive investment is, but we’re not doing any of that. We’re using open source models. We’re not building AI, but we’re applying AI to building tools that we think would benefit people. We’re not an AI company, we’re not pushing AI, but there are real benefits that AI can have to certain productivity use cases.

And then the other side of it is a conversation that we have: What do people use browsers for in the future? We do think that there are gonna be entertainment use cases plus productivity use cases. AI will help with the productivity use cases, but the browser core is still gonna really be needed for the entertainment cases. Ninety percent of our attention is still very focused on those core fundamentals.

Ars: What is the actual path to Gecko on iPhone? Apple now provides routes for alternative engines in the EU and Japan. Which remaining obstacles are Apple’s requirements, and which ones are engineering cost restrictions?

Varma: The biggest challenge for us is, we’re not a big tech company, so for us, forking to build two different versions of iOS, one for markets where this is possible and then for markets where it’s not possible, would mean we would basically have to double the size of our iOS team. And so what we’ve been pushing on Apple and regulators is, can we have a single set of global rules that allows us to build Gecko across the world?

I think it’s great, what’s happened in certain markets, but the reality is, it’s very challenging for us to actually invest to create this global, forked system. There are also just limitations like, well, how do you appear in the App Store? You can only have a single app. There are challenges of how you do migration and stuff that are also there. But I think the primary challenge is still that the cost goes up pretty significantly to have to build two totally different builds on iOS.

Ars: Speaking of cost and revenue, Firefox is dependent on its search deal with Google. There’s the concern that if that ends, Firefox may be in a tougher spot. But also, longer term, do you worry about your dependence on Google search revenue in a time of rapid change with LLMs that could bring into question Google’s long-term search dominance?

Varma: This is definitely a big question. I don’t think anyone really knows what’s gonna happen in the long term, but in the short term I’d say that I think competition is great—it’s why I work on Firefox. It would be great for there to be legitimate competitors to Google, which I think is the right outcome for consumers. I think it’s the best outcome for Firefox.

But in the short term, Google is doing really well, and so when we look at it as the power of AI and LLMs, it doesn’t mean yet that people are moving from Google searches over to LLMs. It actually is growing the overall pie. Search queries and monetizable queries are actually going up. Google’s also integrating AI Mode pretty deeply into search results. And again, this goes into techies versus the average person out there. For the average person, the muscle memory of going to Google is still very strong.

I don’t know how that’ll play out over the next several years. AI is going to have these kinds of questions, but also it’s helping us accomplish a lot more and become a lot more efficient than I think we ever thought was possible, and so for us being a smaller company, the bottleneck is not code creation anymore. We can create tons of code. It’s actually code review.

My hope is that we can actually compete with organizations much bigger than us, which has always been a constraint. These tools are very expensive, but my hope is they get commoditized so our cost structure doesn’t go up.

So I don’t know how it’ll play out, but I would also say that’s why I would encourage everyone to use Firefox. The more people use Firefox, the more power I think we have to negotiate, the more power that we have to create balance and competition and protect the web. So that goes back into something you started off with: the values-based reasons to use Firefox and Gecko. I think it’s pretty important.

Takeaways

Firefox’s new redesign is—at least to me—a welcome one. It no longer looks like a browser from 2015. That was probably never what mattered most to someone who uses the browser in part as a mission statement about the value of the open web. It does, however, make the browser more palatable in a culture and market that is currently seething with frustration at Big Tech’s dominance, and in one that (at least in some regions) is taking regulatory measures to ensure users have choices when faced with the usual defaults.

As Varma tells it, AI-assisted coding workflows have enabled Mozilla to accelerate development. That’s a clear boon, provided the Firefox team (and most other software development teams in the world, for that matter) can work out its post-AI-overhaul code review challenges. That said, when I spoke to Forrester analyst Paddy Harrington, he argued that isn’t necessarily a de facto advantage for the software world’s Davids against its Goliaths. Goliath can use coding agents, too. “If large companies like Apple, Google, and Microsoft aren’t using AI within their dev processes, then I’ll eat my hat, as the old saying goes,” he said. “The question is what are they using it for? How are they using it differently than any other company who is using AI tools in their dev process?”

Given Varma’s statement that tools for enterprise deployments have been Firefox’s most significant new investment area over the past year, I also asked Harrington for his perspective on Firefox’s opportunity in the enterprise space. “I’d certainly love to see them come back with new things that expands them in the enterprise, but it’s not going to be easy, and they would have to truly wow IT decision makers,” he said. Insomuch as there is a clear opening, it’s with businesses in Europe, where “we’re seeing interesting moves in those countries where they’re looking to move away from some of the platform giants like Microsoft or Google,” according to Harrington.

Whatever the scope of the enterprise opportunity, Varma is right that the more people use Firefox, the more leverage it has and the more true independence becomes plausible. This new redesign aims to make the browser more appealing in the mass market, and that’s a welcome start, but it’s not the finish line, and there’s a long way to go against competitors with more resources, albeit also with muddier incentives.

Maybe engine independence creates freedom to differentiate, as Varma said, and maybe AI coding tools do give smaller teams more power to stand up to well-resourced incumbents. But even so, Mozilla will have to continue to turn that freedom and capability into improvements that give people a reason to switch.

The world's most powerful technology executives signed a voluntary agreement to adopt safety policies that include risk reviews, auditing, and evaluations of systems by third parties, and also to rebrand AI to 'super intelligence'.

At 15 million call minutes a day, our analytics pipeline was delivering call data 5-15 minutes after the call ended, and the BigQuery bill kept climbing. We replicated Postgres into ClickHouse Cloud with ClickPipes, moved dashboards off raw CDC tables, and changed what our application writes in the first place. Here is what broke along the way, and what the pipeline looks like now.

At Bolna, we help businesses build and deploy voice AI agents that make and answer phone calls at scale, with a strong focus on multilingual conversations. Every one of those calls generates data, and that data powers everything from our internal analytics to the dashboards our customers use to track how their agents are performing.

On the surface, a call is simple. Someone calls, it gets answered, and it either goes well or it does not. Underneath, a single call moves through a whole sequence of states: queued, ringing, in-progress, transcribing, and eventually completed. Each of those status updates lands in PostgreSQL as an updated row, and that is the traffic from one call. Bolna handles around 15 million minutes of calls a day, so it is worth imagining how much the database is changing at that volume.

That same data feeds our internal dashboards, and our customers pull 15-16 different metrics from the Bolna dashboard to track their calls. So when the data arrived late, it was noticeable, and it turned into tickets from both our own team and our customers. A call would be finished, but the analytics for it were not there yet. Once we traced those tickets back to the pipeline, it was clear what needed fixing.

So we moved from BigQuery to ClickHouse Cloud. This post covers what we broke, how the architecture changed, and how we ended up at roughly one-sixth of the cost we started with.

TL;DR

• At 15M call minutes a day, our Datastream to BigQuery pipeline delivered call data 5-15 minutes late, and repeated MERGE scans on one large table kept driving costs up.
• We replicated Postgres into ClickHouse Cloud with ClickPipes, then moved dashboard queries off raw CDC tables and onto materialized views, and fixed missing JSONB data with REPLICA IDENTITY FULL.
• We now write only the final call state to Postgres, not every status change along the way. That cut CDC volume across the whole pipeline.
• Call data arrives in real time, customers can run custom metrics on demand, and analytics costs dropped about 6x.

Where we started: Datastream into BigQuery

The original setup was straightforward. Datastream picked up CDC events from PostgreSQL and shipped them to BigQuery, and our analysts queried BigQuery directly to build BI dashboards on top of it.

It worked well at first, and then two problems showed up.

The first was delay. Five minutes does not sound like much on a normal day, but when a customer is waiting for their call data to update, or you are debugging a call that happened a few minutes ago and the update is taking anywhere between 5 and 15 minutes to land, it is a long time. It was a source of friction for customers and for our own team.

The second was cost. When we dug into the BigQuery bill, a lot of it came down to a single table: call_records. It was large and unpartitioned, so every time Datastream applied a change with a MERGE, it could scan the whole table even when the change itself was small. The dashboards our analysts built were querying that same table, so the scans were happening over and over. We were paying to stream the data into BigQuery, and then paying again for the compute to query and update it.

The move to ClickPipes

BigQuery was no longer a good fit for the way we were using the data, so we moved analytics to ClickHouse Cloud and used ClickPipes, which is built on PeerDB, to get the data there. We ran it in the same VPC as the database, partly to avoid unnecessary network costs and partly because the connection was simpler to set up that way.

Getting the existing data across took about 20 hours. Once the backfill finished, ClickPipes started pulling in new changes from Postgres on its own, and our analytics team could begin moving their queries over to ClickHouse.

Updates work differently in ClickHouse than they did in BigQuery. It does not update a row in place every time something changes. It writes a new version of the row and works out which one to keep during background merges. Our replicated tables use ReplacingMergeTree with _version and _is_deleted columns for exactly this, partitioned by month. That one detail turned out to shape most of what went wrong next.

Problem 1: querying raw CDC tables with FINAL

At first we queried the replicated tables directly, and that did not last very long.

Background merges do not happen right away. Until a merge finishes, a table can hold several versions of the same row, so a correct query has to pick the latest version of each one. The easiest way to do that is FINAL, which handles the deduplication as part of the query:

SELECT status, count()
FROM call_records FINAL
WHERE created_at >= now() - INTERVAL 7 DAY
GROUP BY status;

On a table as large and as frequently updated as call_records, this used a lot of memory. A single query on its own would have been fine. The problem was that we had many dashboards, and several of them refreshing around the same time was enough to cause memory spikes and push ClickHouse into autoscaling.

So we moved most of that work out of the dashboard queries.

For the heavier reports, there was no reason to run the same expensive query every time someone opened a dashboard. Those went into refreshable materialized views, which run on a schedule, do the deduplication once, and store the result in a much smaller table the dashboards can query directly.

For the lighter metrics we went further. Take something like total calls in a day: you do not want to recount every call since the morning each time the dashboard loads. Instead we keep a running count and add to it as new calls come in. It is quick, it is always up to date, and it never rescans old data.

We also wanted a bad query to stay a bad query instead of becoming a cluster problem, so we gave BI users their own settings profile: per-user limits on memory, on how many queries can run at once, and on how long a query may run. A query that grows too large spills to disk rather than eating all the memory. If someone runs something heavy by accident, it affects their query and not everyone else's dashboards.

Problem 2: TOAST and missing JSONB data

The next problem was harder to spot, because nothing was obviously failing. Some of the JSONB config columns would occasionally show up in ClickHouse as null, or carrying an older value, while the same row in Postgres looked completely fine.

It came down to how Postgres handles large values. When a value is too large for the main row, which is common for big JSONB blobs and large arrays, Postgres stores it in a separate TOAST table and keeps a pointer in the row itself.

That is normally invisible, but logical replication has a catch. If an update does not touch a TOASTed column, Postgres does not necessarily send that column's full value again in the WAL event; it can mark it as unchanged instead. If that is not handled correctly downstream, the new row version can end up missing the column or carrying a stale value.

We fixed it on the Postgres side by setting the affected tables to REPLICA IDENTITY FULL:

ALTER TABLE bot_configs REPLICA IDENTITY FULL;

This makes Postgres include the complete old row in the WAL for updates and deletes, so the CDC side has the values it needs instead of having to deal with missing TOASTed columns. Once we made the change, the mismatches in ClickHouse disappeared.

We did not enable it everywhere. FULL means more data in the WAL, so we used it only where we needed it. To check what a table is currently using:

SELECT relname, relreplident
FROM pg_class
WHERE relname IN ('bot_configs', 'call_records');

-- d = default, f = full, i = index, n = nothing

Problem 3: too many updates, too much CDC

As volume grew, so did the ClickPipes charge. A voice call is a series of updates: the status changes as the call moves through its lifecycle, and every status change, timestamp, and intermediate field is an UPDATE in Postgres, which means another CDC event and another row version in ClickHouse.

What we noticed is that almost none of those intermediate updates were ever queried. They mattered only while the call was live. So we changed how the application writes: during a call we keep the fast-changing state in memory, and we write the final state to the database when the call ends, along with a few key checkpoints. Fewer UPDATEs meant:

• Lower ClickPipes costs, because there are fewer change events to replicate.
• Less write load and WAL generation on Postgres.
• Fewer row versions for ClickHouse to merge.

This was the largest cost reduction of everything we did, and it came from the application layer rather than the database. It brought our cost down to roughly one-sixth of what it had been.

What we have now

This is the pipeline today:

Data used to arrive 5-15 minutes after the fact. Now a call's data is there within a minute or two of the call ending, and queries over it come back in seconds. That is where the move started making a real difference for customers: they can define custom metrics, add whatever filters they need, and run them across their call data without waiting around for a result. ClickHouse handles the heavier queries, and the materialized views keep the data we use most often ready to read, so results stay fast as the data grows.

If we were doing this again

• CDC has a cost of its own. On BigQuery, our MERGE operations scanned large tables even when the actual change was small. We were thinking about how much data was changing; what mattered just as much was how the warehouse handled those changes.
• Raw CDC tables are not a good place for dashboards. FINAL gave us correct results, but it redid all that work every time someone loaded a dashboard, and that got expensive fast. Moving the repeated work into materialized views made a large difference.
• Check replica identity early. The TOAST issue was the sneakiest problem we hit. If you are replicating tables with large JSONB values or arrays, check what is actually making it into the WAL, because it may not be everything you expect. REPLICA IDENTITY FULL fixed it for the tables that needed it, at the cost of a bit more WAL volume.
• Writing less data helps everywhere. Some of the cheapest fixes had nothing to do with ClickHouse. Moving short-lived call state out of Postgres meant fewer writes on the database, and fewer changes for the rest of the pipeline to carry.
• Keep ClickPipes close to Postgres. Running it in the same VPC meant less network overhead, a simpler connection, and lower network costs.

Closing the gap between "call ended" and "here's what happened"

Moving to ClickHouse turned out to be more than swapping one warehouse for another. We changed how we write some of our data, how it is replicated, and how we query it once it lands. We started because the old setup was slow and expensive; what we ended up with is faster call data, lower analytics costs, and a setup that lets us do more with that data for our customers.

The problem was easy to describe: a call would finish, but the analytics our team and our customers needed were not there yet, and that gap kept arriving as tickets from both sides. With data landing in real time and queries returning quickly, the gap is mostly gone. What has changed more is what people do with the data now that it is there when they need it.

Debugging while the customer is still on the thread. When a customer reports that a call dropped halfway through, our on-call engineer no longer waits 10-15 minutes for the record to appear. They can pull the call's status, transcript, and agent config within a minute or two of it ending, and reply in the same conversation. The "is the data updated yet?" tickets that started this whole project have largely stopped.

Fixing a campaign while it is still running. Say a customer is running an outbound reminder batch across thousands of numbers. An hour in, they notice connect rates for one region are well below the rest. Before, they would have found out the next morning, after the batch had already finished. Now they can change the calling window or the agent's opening line and see whether it helped within the same batch.

Iterating on agents in hours, not days. Product owners on the customer side can test two versions of an agent prompt and compare call dispositions (interested, callback requested, not reachable) shortly after the calls end. That means several rounds of iteration in a day instead of one round every day or two. It matters even more for multilingual agents, where a Hindi agent and a Tamil agent built from the same flow can perform very differently.

Letting customers ask their own questions. Custom metrics only work because queries are fast enough to run on demand. Instead of being limited to the 15-16 metrics we had already built, customers can define what matters to their business, add their own filters, and get answers across all their call data. Internally, the same speed means our CS and sales teams can pull live usage while they are on a call with a customer, instead of promising to follow up later.

For a platform where every call is a chance for a customer to learn something about their agents, cutting the time it takes to get value from that data turned out to be the real win, even more than the 6x cost reduction.

PageIndex: Vectorless, Reasoning-based RAG

Reasoning-based RAG ◦ No Vector DB, No Chunking ◦ Context-Aware Retrieval ◦ Reads Like a Human

Updates

• [Aug '26] 🔥 PageIndex SDK: pip install -U pageindex now ships local mode: index, retrieve, and chat entirely on your machine with your own LLM key, or point the same client at PageIndex Cloud with an API key.
• [Aug '26] ⚡ PageIndex Flash: fast tree index generation for text-based PDFs, now the default indexing method in PageIndex SDK local mode.
• Scale PageIndex to Millions of Documents: PageIndex File System is a file-level tree indexing layer that lets PageIndex reason over an entire corpus, not just a single document.
• PageIndex App: a human-like document analysis agent for long professional documents.

What is PageIndex?

Are you frustrated with vector database retrieval accuracy for long and complex documents? Vector-based RAG retrieves by semantic similarity. But similarity ≠ relevance — what retrieval actually needs is relevance, and relevance requires reasoning. On professional documents that demand contextual understanding, domain expertise, and multi-step reasoning, similarity search misses what is relevant but not similar, and returns what is similar but not relevant.

Inspired by AlphaGo, PageIndex replaces the vector index with a hierarchical tree index and lets an LLM reason its way through it, the way a human expert turns to and reads the right section of a long report. Retrieval happens in two steps:

1. Index: generate a tree-structure index for each document
2. Retrieve: agentically search that tree with LLM reasoning

TL;DR

PageIndex is a vectorless, reasoning-based RAG engine that mirrors how humans read, delivering traceable, explainable, and context-aware retrieval, with no vector DBs or chunking.

Compare with Vector RAG

It is ideal for financial reports, legal documents, regulatory filings, technical manuals, medical literature, academic textbooks, and any other long, complex professional document.

Quickstart

pip install -U pageindex

import os
from pageindex import PageIndexClient

os.environ["OPENAI_API_KEY"] = "your-openai-key"

client = PageIndexClient(
    index="gpt-5.6-luna",               # model to build the tree index
    chat="gpt-5.6-sol",                 # model to search the tree
)
doc_id = client.submit_document("report.pdf")["doc_id"]

answer = client.chat("What was the 2023 operating margin?", doc_id=doc_id)
print(answer)

Model Recommendations

• index=: a basic model is sufficient. The tree structure itself is extracted from the document layout without an LLM; the index model only summarizes and refines it, which a basic model does well.
• chat=: use the best model you can afford. The chat model searches the tree to retrieve information.

Benchmarks

Local indexing cost and time

Building a tree locally runs about $0.001 per page with gpt-5.6-luna as the index model, so a 1,000-page textbook costs a little over a dollar and a few minutes, once, and every later question reuses it. PageIndex is designed not to rely heavily on the model used at index time, so in our experiments a basic model does not hurt quality.

Indexing time also scales predictably with document length. In the same local setup, the benchmark documents (9 to 1,098 pages) finished in roughly 13 seconds to 4.5 minutes.

Query cost and accuracy

PageIndex-OSS-Benchmark measures exactly the setup in the quickstart above (PageIndexClient() in local mode, flash indexing, no OCR) on 62 lookup questions over 34 PDFs (1,945 pages) drawn from MMLongBench-Doc-V2. Every question's answer is a fact stated in running text, so a wrong answer is a retrieval or reading failure, not a reasoning one.

Cost per query vs. native PDF input

The alternative to retrieval is handing the model the whole PDF on every question. That cost grows with the document; PageIndex's does not, because it reads only the nodes its reasoning reaches. On documents where both routes return the same answer, native PDF input costs 2.1× more at 52 pages and 16.6× more at 420 (gpt-5.6-sol, prompt caching excluded) — and at 805 pages the document no longer fits in the context window at all.

Leading accuracy on FinanceBench

PageIndex reached a state-of-the-art 98.7% accuracy on FinanceBench (financial document QA benchmark), vastly outperforming vector-based RAG.

PageIndex Cloud

The open-source version is ideal for text-heavy PDFs and local workflows. With PageIndex Cloud, document indexing and storage run in the cloud: PageIndex handles parsing, OCR, image understanding, tree-index construction, and managed storage for you. The chat and retrieval layer remains compatible with your model, so you can search the cloud-hosted index using the model provider your application already uses.

Moving indexing and storage from Local to Cloud only requires a PageIndex API key:

import os
from pageindex import PageIndexClient

os.environ["PAGEINDEX_API_KEY"] = "your-pageindex-key"
os.environ["OPENAI_API_KEY"] = "your-openai-key"

client = PageIndexClient(
    index="cloud",                       # build and store the index in PageIndex Cloud
    chat="gpt-5.6-sol",                  # use your preferred compatible model for chat
)
doc_id = client.submit_document("report.pdf", wait=True)["doc_id"]
print(client.chat("What was the 2023 operating margin?", doc_id=doc_id))

Support Us

Leave us a star 🌟 if you like our project. Thank you!

Please cite this work as:

Mingtian Zhang, Yu Tang and PageIndex Team,
"PageIndex: Next-Generation Vectorless, Reasoning-based RAG",
PageIndex Blog, Sep 2025.

@article{zhang2025pageindex,
  author = {Mingtian Zhang and Yu Tang and PageIndex Team},
  title = {PageIndex: Next-Generation Vectorless, Reasoning-based RAG},
  journal = {PageIndex Blog},
  year = {2025},
  month = {September},
  note = {https://pageindex.ai/blog/pageindex-intro},
}

© 2026 PageIndex AI

New in OpenShell 0.1.x: a stable release cadence, new isolation primitives, an expanded extension surface, and new APIs. Read the 0.1.0 upgrade guide.

OpenShell is the safe, private runtime for fleets of autonomous AI agents. Agents are most useful when they can read files, install packages, call APIs, and use credentials. OpenShell gives them that capability without giving them unrestricted access to your data, secrets, or network. You declare what each agent can touch in a policy, and OpenShell enforces it.

How It Works

OpenShell governs what agents can do in two ways: it instruments the kernel to enforce policy on every file access, system call, and network connection at runtime, and it uses formal verification to check what a policy change would allow before it is applied.

• Kernel-level enforcement. Each agent runs in an isolated sandbox. Kernel controls confine which files it can access and which system calls it can make, and every network connection passes through a policy check before it leaves the sandbox. Agents never see real credentials; OpenShell adds them only to requests bound for approved endpoints.
• Formally verified policy changes. Before a policy change is approved, OpenShell uses formal verification to flag risky new access it would grant, such as reaching a new host with credentials or calling a new API method, so those changes wait for human review.

See Architecture for how the gateway, supervisor, and sandbox fit together.

Quickstart

You need Linux, macOS on Apple Silicon, or Windows with WSL 2 (experimental), plus Docker, Podman, or host virtualization. See the Support Matrix for details.

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

The installer sets up the CLI and a local gateway. The default sandbox image is minimal Ubuntu with no agent installed. To run a real agent, follow Run Your First Agent: it runs OpenCode against a free OpenRouter model and shows how to approve new access as the agent needs it.

Explore Further

• Sandboxes: images, runtimes, GPUs, and lifecycle.
• Policies: filesystem, network, and process rules, with the advisor and prover for reviewing changes.
• Providers: credentials that work only at approved endpoints, including inference.
• Gateways: the control plane for sandboxes, policy, and access.
• Kubernetes: deploy the gateway with Helm. Your CNI must enforce NetworkPolicy.
• Extensibility: middleware, interceptors, and compute drivers.
• Tutorials: step-by-step policy and agent walkthroughs.
• Prerelease and development builds: try an upcoming release or the latest commit on main.

Agent Skills

Install the public OpenShell skills for your coding agent:

npx skills add NVIDIA/OpenShell

The skills teach your agent to drive the OpenShell CLI, write sandbox policies, and debug gateways and inference routing.

SDKs

SDKs connect applications to an OpenShell gateway. They do not install the CLI. Use the same OpenShell release for the SDK and the gateway when possible.

Community

• Questions and discussion: GitHub Discussions
• Bug reports and feature requests: GitHub Issues
• Roadmap: OpenShell Roadmap
• Try it in the cloud: Brev Launchable

OpenShell is built agent-first: it is developed with the same agent-driven workflows it enables.

Telemetry

OpenShell collects anonymous telemetry, limited to operational categories and counts, to help improve the project. It does not collect sandbox names, hostnames, file paths, prompts, credentials, provider or model names, or user content. To disable it, set OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or server.telemetryEnabled=false for Helm installs. See Telemetry for details.

Notice and Disclaimer

This software automatically retrieves, accesses or interacts with external materials. Those retrieved materials are not distributed with this software and are governed solely by separate terms, conditions and licenses. You are solely responsible for finding, reviewing and complying with all applicable terms, conditions, and licenses, and for verifying the security, integrity and suitability of any retrieved materials for your specific use case. This software is provided "AS IS", without warranty of any kind. The author makes no representations or warranties regarding any retrieved materials, and assumes no liability for any losses, damages, liabilities or legal consequences from your use or inability to use this software or any retrieved materials. Use this software and the retrieved materials at your own risk.

License

This project is licensed under the Apache License 2.0.

Much of the dependency mocking software in use today was not designed with cloud native architectures in mind.

The tools that dominate the category today were built for a world where services had defined release cycles, where upstream dependencies changed slowly and announced changes clearly, and where the team testing a service had reasonable visibility into what its dependencies were doing. That world existed. Cloud native architectures replaced it with something fundamentally different: dozens of services deploying on independent schedules through separate pipelines, each capable of changing behavior without coordinating with the teams downstream.

The gap between what dependency mocking software was designed for and what cloud native architectures actually create is where most integration test accuracy problems originate.

Independent Deployment Changes the Maintenance Equation

In a cloud native architecture, the payment service and the inventory service and the notification service each deploy when their own tests pass. Not when the order service is ready to absorb their changes. Not when someone has checked whether the order service’s mocks still accurately represent the new payment service behavior.

This is where the dependency mocking software becomes specific to cloud native environments. A mock for the payment service encodes how that service behaved when the mock was written. Every independent payment service deployment after that creates an opportunity for the mock to become less accurate. The order service’s integration tests keep running. The mocks keep returning what they were configured to return. The accuracy gap grows with each untracked upstream deployment.

Traditional dependency mocking software has no native mechanism for addressing this. WireMock does not know when the real service it is virtualizing has deployed a new version. Hand-written mock fixtures do not update themselves. Specification-based virtual services reflect the specification, not the current deployed behavior.

The result is a test suite that looks healthy on the dashboard while accumulating behavioral debt proportional to upstream deployment frequency.

What Cloud Native Dependency Mocking Software Actually Needs

Deployment event awareness. The most important capability a dependency mocking tool can have in a cloud native architecture is the ability to connect to upstream deployment events. When the payment service’s pipeline succeeds and deploys to staging, the downstream team needs to know—not through Slack messages or changelog emails, but through an automated signal that the mock configuration for that service should be re-validated.

Tools that integrate with pipeline event streams—consuming deployment notifications from CI/CD systems and triggering mock refresh workflows in response—address the cloud native problem structurally rather than relying on human awareness to close the gap. In an architecture with many services on independent schedules, human awareness cannot keep pace.

Behavior capture from real service interactions. Cloud native services change behavior in ways that specification documents do not always reflect promptly. A service team that adds a new field to a response, reorganizes an error structure, or changes how it handles a specific input combination may consider these changes minor enough not to warrant a documentation update. Downstream teams whose mocks were built from that documentation now have mocks that describe historical behavior.

Dependency mocking software that derives its behavioral representations from recorded real service interactions rather than from specifications captures what the service actually does rather than what it was documented to do. In cloud native environments where behavioral drift between documentation and implementation is common, this distinction determines whether the mock stays accurate across upstream deployments or accumulates undocumented drift.

Automatic non-deterministic field handling. Real cloud native service responses contain fields that change on every call. Request correlation IDs, generated identifiers, processing timestamps, trace headers. Dependency mocking software that includes these verbatim produces test failures that have nothing to do with code correctness. Identifying which fields are inherently variable requires comparing multiple observations of the same interaction rather than relying on developers to annotate each variable field manually.

Cross-service diff visibility. In a cloud native architecture with many upstream services changing on independent schedules, the team needs to know not just that a mock is stale but precisely how the upstream service’s behavior has changed. A field that moved from the top level to a nested object. An error code that was renamed. A response property that changed type. This level of specificity determines whether the downstream team needs to update application code alongside the mock or whether the mock can be refreshed without code changes.

Keploy approaches these requirements through eBPF-based traffic capture at the kernel level, which positions it differently from specification-based tools in a cloud native context. Because its record-and-replay functionality intercepts real HTTP exchanges between services rather than relying solely on OpenAPI documents, the mocks it produces can reflect observed service behavior directly. The kernel-level capture works across service languages and frameworks without requiring language-specific instrumentation, which matters in polyglot cloud native architectures where the same upstream service may be called by Go, Python and Node.js services simultaneously. Keploy can also be integrated into CI/CD workflows to re-record dependency interactions and refresh mocks against real services as those services change.

What This Means for Tool Selection

Evaluating dependency mocking software for cloud native architectures requires asking different questions than evaluating it for a monolithic or loosely coupled application.

The questions that determine value in cloud native environments are not about setup ease or documentation quality. They are about what happens between setup and the next upstream deployment: does the tool know the deployment occurred, does it have a mechanism for capturing current behavior from the real service, does it surface the behavioral changes explicitly, and does it do this in a way that scales across the full mesh of service dependencies rather than requiring per-service manual attention?

Dependency mocking software that answers these questions is addressing the cloud native problem. Software that was not designed with independent deployment in mind will require the team to build the missing capabilities around it—or accept that their integration test accuracy will degrade proportionally to how actively their upstream services are being developed.

Harness Brings Dynamic AI Discovery and Runtime Security to Amazon Bedrock AgentCore Gateway | Harness Blog

Today, Harness announced a new integration with Amazon Bedrock AgentCore Gateway that helps enterprises discover and secure the AI agents, tools, and resources operating across their AWS environments.

The integration brings Harness’ AI posture management and AI firewall to agent interactions flowing through AgentCore Gateway. Security teams can now automatically build an inventory of their AI attack surface, detect prompt injection and sensitive-data leakage in real time, and investigate incidents with context spanning the originating client, the tools accessed, and the data involved.

This matters because enterprises are moving large numbers of agents from experiments into production. These agents are no longer limited to generating text. They can retrieve sensitive data, invoke tools, call services, interact with other agents, and complete business tasks autonomously. Autonomous agents create a fundamentally different security problem from protecting LLMs. An AI model can produce a bad answer. An AI agent can take a bad action.

Harness and AWS are giving security teams visibility at the critical point where an agent's decisions become actions.

When AI gains agency, security must follow the entire action path

Traditional applications largely follow execution paths defined by developers before deployment. A request reaches an endpoint, coded logic runs, and the application returns a response or performs an action.

Agents operate differently. An agent receives a goal, gathers context, decides what to do, selects a tool, observes the result, and adjusts its next step. Part of its execution path is assembled at runtime:

Goal → context → model decision → tool selection → data access → decision → tool selection → action

This means an unsafe outcome may not be visible in any one event. Each action can appear legitimate when inspected alone.

Consider a customer support agent that can read support tickets, retrieve customer records, and take the decision and action to issue refunds. An attacker embeds a malicious instruction inside a ticket. The agent retrieves that ticket as normal business context, treats the embedded text as an instruction, accesses the associated customer record, and attempts a refund to an account selected by the attacker.

The user may be authenticated. The agent may be authorized to use each tool. Every API call may be structurally valid. Yet the complete sequence is malicious.

Existing controls such as authentication, authorization, API validation, and infrastructure security remain essential. But they cannot, on their own, determine whether a permitted series of actions remains consistent with the agent's intended purpose.

The unit of security analysis must expand from a single request to the complete agent journey.

AgentCore Gateway creates a critical security control point

Amazon Bedrock AgentCore Gateway provides a fully managed way for developers to connect agents with tools and services. It sits at a consequential point in the agent architecture: between what an agent decides and the systems through which it acts.

The model may decide what it wants to do. The gateway is where that decision gains access to enterprise capabilities. That makes AgentCore Gateway a natural place to establish visibility across agent activity. Harness turns that visibility into security intelligence, helping teams answer three immediate questions: What AI assets are operating in our environment? How are they connected? Is an agent interaction being manipulated or exposing sensitive information?

Interactions at this action point can reveal the relationships security teams need to understand:

• Which client initiated the interaction
• Which AI agent or application was involved
• Which MCP server or tool the agent selected
• Which resource the tool accessed
• What data entered or left the interaction
• How one action related to the next

What the Harness integration delivers continuous, comprehensive visibility and protection

The new integration supports security teams from initial discovery through runtime threat detection.

Continuous AI discovery

Many enterprises cannot confidently secure their AI environment because they cannot first describe it. According to Harness research, nearly two-thirds of organizations have no visibility into where LLMs are being used across their environments.

Manual inventories cannot keep pace with production AI. New agents, prompts, tools, MCP servers, and resources can be introduced or changed faster than a periodic review process can track them.

Harness automatically discovers and continuously inventories the AI APIs, MCP servers, tools, prompts, and resources operating through Amazon Bedrock AgentCore Gateway. Security teams receive an always-current map of the AI attack surface without depending on manual tracking, tagging, or documentation.

This provides more than a list of models or projects. It shows the system around the agent: the interfaces it uses, the tools through which it acts, and the resources with which it interacts. That context is essential for understanding an agent's exposure and investigating its behavior.

Real-time AI threat detection

Harness instruments the chain of agent-to-tool interactions routed through AgentCore Gateway and applies behavioral AI to identify threats in real time. The integration initially focuses on two risks that demonstrate why agent activity must be evaluated as a connected journey.

• Prompt injection: Attackers can place malicious instructions in a user prompt, document, support ticket, webpage, tool result, or other content an agent encounters. The attacker’s goal is to make the agent treat untrusted content as an instruction and take an action the attacker could not perform directly. Finding suspicious text alone is not enough. Defenders need to connect its source with what the agent did next: the tool it selected, the resource it accessed, and the action it attempted.
• Sensitive-data leakage: An agent may be permitted to retrieve information and then expose it to an unintended user, tool, or output. The risk emerges from how data moves across the interaction - not merely from the retrieval or response viewed independently.

Harness detects these threats across agent interactions and surfaces incidents with trace-level context, including the originating client, the tool accessed, and the data involved. Security teams can investigate the path that produced the risk instead of reconstructing it from disconnected infrastructure and application logs.

Agent journeys are fundamentally extensions of API journeys

Harness brings an established foundation to this new security problem.

Harness already helps enterprises discover first- and third-party APIs, including shadow and zombie APIs. Its runtime security capabilities identify business-logic abuse, transaction fraud, and data leakage by analyzing application behavior across sessions. When new API threats are identified, Harness can communicate with AWS WAF to create or update rules for faster containment. The common principle is sequence-aware security.

Many attacks do not use malformed requests or obviously malicious endpoints. An attacker can use valid application functions in a permitted but abusive sequence. Detecting that behavior requires understanding the journey and its context, not merely evaluating one event at a time.

Agents make this need more urgent. Communication between agents, tools, MCPs and other assets happens through API calls, so having a strong API protection foundation is critical to protecting agents.

The agents dynamically choose among tools and data sources, generate their own multi-step paths, and act on behalf of users. The new integration extends Harness's behavioral intelligence from API journeys to agent journeys operating through AgentCore Gateway.

"Harness built its AI security capabilities to help secure AI workloads running on exactly this kind of infrastructure - the connectivity layer where enterprise AI runs in production," said Rahul Sood, GM of Application Security at Harness. "This integration gives security teams the depth of visibility they rely on for traditional APIs, now extended to agent interactions on AWS, so enterprises can move fast and confidently, with strong protection for their agentic operations."

Helping enterprises move agents into production securely

Enterprises create value from agents by connecting them to real systems. An agent without access to tools, data, or services may be easier to contain, but it is also far less useful.

The answer is not to prevent agents from acting. It is to preserve visibility and security as their access and autonomy grow.

Amazon Bedrock AgentCore Gateway gives builders a managed connectivity layer for agent-to-tool interactions. Harness gives security teams continuous discovery and behavioral runtime intelligence across those interactions. Together, the integration helps close the gap between teams building agents and teams responsible for protecting the enterprise.

Enterprises interested in securing their agentic AI workloads on AWS can contact their Harness account team or request a Harness AI Security demo.

Summary

• Lakebase Postgres now includes a built-in search engine (GA on AWS/Azure). Two extensions, lakebase_vector (ANN search) and lakebase_text (BM25), let you run semantic, keyword, and hybrid search directly in Postgres alongside operational data, eliminating the need for a separate search system + ETL pipeline.
• It outperforms pgvector and dedicated search engines at scale. On a 100M-vector benchmark, Lakebase delivers 2x the throughput of the next-best system, 4x lower cost than cloud Postgres with pgvector, and 97% recall at 71ms P99 latency. It achieves this by decoupling storage from compute and using hierarchical IVF clustering + binary quantization (RaBitQ) so queries touch only the data they need.
• The architecture is serverless and scales to zero. You pay for query usage, not data volume. Index builds are offloaded from the primary database, cold starts take ~1 second, and 100M vectors can be served on a single compute unit, making it purpose-built for the bursty retrieval patterns of AI agents.

Traditional OLTP systems weren't built for the search demands of AI agents. They require low-latency, high-accuracy retrieval across all your data and often execute massive parallel searches. Until now, solving this meant duct-taping a standalone search engine to your primary database with an ETL pipeline.

But what if your OLTP database could just run the search workload efficiently?

Today, we are bringing a fast and scalable search engine to Lakebase Postgres via two extensions: lakebase_vector (scalable approximate neighbor search) and lakebase_text (bm25 full-text search). Both extensions are generally available on AWS and Azure.

With lakebase_vector, Postgres is now at the frontier of vector search. It outcompetes the efficiency and scalability of a dedicated search engine. On the VectorDBBench 100M benchmark, it delivers twice the throughput of the next best system and is 4 times cheaper than a cloud Postgres vendor using pgvector, and that is before accounting for additional saving due to autoscaling.

It maintains this performance without sacrificing accuracy. In our tests, lakebase_vector delivered a P99 latency of 71 milliseconds at 97% recall (successfully retrieved the true nearest neighbors 97% of the time).

Lakebase Postgres now has state-of-the-art search capabilities, and we’ve seen customers like Conexiom run hybrid search with BM25 on over 100 million rows with half the compute footprint of their previous pgvector setup. They now have a database for all OLTP and search workloads that is completely serverless and scales to their needs.

Lakebase Search gives us a whole new level of scalability over pgvector, and unlocks BM25 in the same serverless database. We use Lakebase to connect data to our agents at scale. —Jordan Voves, AI/ML Architect @ Conexiom

Why pgvector hits a wall at scale

For most Postgres users, search starts with pgvector. It allows vector similarity search through index algorithms like HNSW and IVFFlat over data natively in Postgres, avoiding the complexity of a separate vector store. In fact, pgvector is the most installed extension in Lakebase Postgres. We saw 3 common painpoints from customers running pgvector at scale.

First, costs scale with data volume, not usage.

pgvector keeps its index in your database's memory to be fast. Because HNSW search relies on random-access graph traversal, queries execute in milliseconds only if everything fits perfectly in RAM. The moment the index spills to disk, queries turn into chains of random reads, and performance plummets by 10x to 50x.

A 768-dimensional float32 vector requires roughly 3.3 KB of memory after accounting for graph links and Postgres overhead. at 100 million rows, you need ~330 GB of RAM to keep the index resident for millisecond queries. There's no notion of a 'working set'. You provision for the entire index whether you query all of it or none.

Second, index maintenance is expensive and blocks your database.

Pgvector indexes are limited by memory because the HNSW graph relies on continuous random access. When a build spills to disk, millions of random I/O operations stall performance - taking almost 50 hours to build a pgvector index on a standard cloud instance.

Ingestion suffers from the same bottleneck. Inserting new vectors is slow and costly because every write forces pgvector to navigate and modify multiple layers of the graph using random-access lookups.

Ongoing maintenance compounds the problem. Because HNSW lacks global rebalancing, restoring search quality requires a full REINDEX, which locks the table and blocks production writes.

Third, you trade-off search quality for performance

Each pgvector query runs on a single Postgres backend process, meaning the HNSW index scan is never parallelized.

To get higher recall, the engine must visit more graph nodes, triggering more random memory reads and distance comparisons. This inflates latency and drops your QPS. Because a single search can't be parallelized across cores, your only option for higher throughput is adding more connections or read-replicas.

lakebase_vector brings scalable vector search to Postgres

The main bottleneck with pgvector is that the entire index has to fit in a single machine's RAM to be fast. What if it didn't?

Lakebase Postgres gives us a great starting point, because it separates storage from compute. Durable data rests in cheap cloud object storage, while RAM and local NVMe act as ephemeral caches in front of it for fast reads of the working set of data. With this architecture, an HNSW cache means a series of random object store reads.

We need an index that is fast both when cached in RAM and when cold on object storage. We leverage two ideas:

• Hierarchical IVF clustering. Vectors are grouped into clusters stored as contiguous blocks. A query scores the cluster centroids in memory, then reads only the few promising blocks — turning hundreds of random hops into a handful of large sequential reads.
• Binary quantization (RaBitQ). Each vector is compressed to ~1 bit per dimension, about 32× smaller than float32. Queries scan the compact codes to shortlist candidates, then rerank that bounded shortlist against the full-precision vectors.

When cached, search operates over a tiny footprint using quantized vectors. When cold, queries fetch only the blocks they need and don’t need to crawl the entire index. Lakebase_vector delivers:

Pay only for what you use, and scale to zero

Decoupling storage from compute makes lakebase_vector completely stateless: a node caches hot data on demand, suspends to zero when idle, and resumes on the next query.

• At rest, you pay only for storage, giving you a low baseline cost for keeping vectors indexed in Lakebase.
• Cold starts are cheap because only the quantized codes and the specific blocks a query touches hydrate. Our measured P90 for the first query after scale-to-zero is just 1.13 seconds (100M × 768-dim).
• It is even possible to serve 100M vectors on just 1 Lakebase Compute Unit (CU). Only the active working dataset needs to be cached in compute nodes, giving you a pricing model that truly mirrors actual usage and query activity.

Fast, offloaded Index builds

lakebase_vector builds indexes in a more parallel way. We train the centroids once on a small random sample. This is the only step that looks across the whole dataset. After that, every vector is independently assigned to its nearest centroid, quantized, and written into its cluster's block. This process can fan across as many cores as you have, scaling with compute.

We take this a step further by offloading index builds from your primary database entirely. Storing data in open formats allows our LTAP architecture to delegate indexing and maintenance to distributed engines like Spark, bringing build times down to minutes with parallel compute. Stay tuned.

Fast, accurate search

lakebase_vector broadens candidate search cheaply using compact 1-bit codes, reranking only a tight shortlist at full precision. Because index blocks are independent, a single query parallelizes across CPU cores, delivering high recall and low latency simultaneously.

Filtering happens directly as lakebase_vector scans cluster blocks. Applying predicates inline avoids over-fetching candidates by and keeps recall high on filtered queries.

lakebase_text: native BM25 search in Postgres

Standard Postgres text search (tsvector) lacks corpus-wide relevance context. lakebase_text brings native BM25 to Postgres by scoring terms with global inverse document frequency (IDF): heavily weighting rare, high-intent terms while penalizing common filler words.

It is also faster than traditional tsvector + GIN indexes. By evaluating score upper-bounds during traversal, the engine skips entire posting blocks that cannot reach the top-K results.

Combining lakebase_text with lakebase_vector unlocks native hybrid search inside Postgres. In a single query, you can fuse semantic vector search with BM25 keyword relevance, apply standard SQL filter predicates, and join directly against live operational tables.

Lakebase Postgres is built for the agentic era

Agents have pushed traditional search engines past their limits. They made vector search a core requirement of the data stack and introduced extreme burstiness, where a single workflow can trigger thousands of concurrent retrieval requests in seconds.

We designed Lakebase Search specifically for this new reality. Lakebase Postgres can now handle all your operational and search workloads, backed by a serverless architecture that scales seamlessly from 1 row to 1 billion vectors and from 1 QPS to thousands without manual reprovisioning or infrastructure management.

We built Lakebase Search alongside feedback from hundreds of beta customers, and the results speak for themselves:

1. 3x lower database spend: Conexiom cut infrastructure costs by 3x while achieving 5x higher throughput compared to pgvector.
2. One SQL tool call for agents: Developers replace complex multi-system retrieval pipelines with a single SQL call for native hybrid search, governed by standard database rules.
3. Unified OLTP and search: Teams consolidate live operational tables and dedicated search clusters into one pay-as-you-use backend.

Lakebase Search is generally available today on AWS and Azure. If you are already building an app or an agent on Lakebase, simply enable the extensions. If you have not tried Lakebase yet, get started today.

▎ 📝 Note: Databricks AI Search is a managed search engine for high-quality retrieval out of the box — it may be the better fit when you want great results without manual tuning. Lakebase Search is the better choice when you want all your operational and search data in one database.

HashiCorp released version 8.0 of the Terraform provider for Google Cloud, a major update that changes the default load balancing scheme, removes resources tied to retired services like Notebooks and IAP OAuth Admin, and converts several list attributes to sets for more predictable plans.

The software profession has spent years designing, developing, and shipping tools. Tools that, when learned, give people the power to create reports, videos, programs, and much more. But the pervasiveness of tools may have implanted the wrong instinct in our heads in a world of AI. Tool first, outcome second can now (and perhaps should) be flipped on its head.

Loads of AI use today is building a lot more of the tools we're used to, but much faster. With today's capabilities, though, we can actually skip the tools and jump straight to the outcomes they enable. A tool was always just a means to an end. If AI can get you to the end directly, why stop at the tool?

As usual, a concrete example helps. Two years ago, we built an AI-powered newsroom called Exposit. The system would find, aggregate, and report on global news. Behind the scenes AI agents would do the curating, writing, and editing that you'd find in a physical news room.

So it's not surprising that we presented the end result like a news site: headlines, articles, categories, etc. People could search, scroll, or navigate to find the news they were interested in. In other words, we built a news tool. Like all the other news sites out there, just run by AI.

As we continued to iterate on the product, we added a feature that allowed people to ask about a specific topic or news story and we'd compile a personalized report for them based on the latest news, related events, people, locations, and more. Really quickly this feature became the dominant way people used the site.

I've come to refer to this approach as just-in-time content: generated in real-time, for a specific person, with a specific need, at a specific moment. Instead of writing something once and hoping it fits everyone who comes along, you build a corpus that can be recombined endlessly and produce a timely, relevant answer on demand.

From the personalized report on Exposit, people could go deeper into articles, topics, entities, sources, and more. In other words, they started from the outcome: here's the news that you asked for. And if they wanted to, later engaged with the tool(s). Outcome first, tool second.

I do a similar thing on the Ask LukeW feature of this Website. Originally people had to ask a question before they got anything. Now each day I grab my most recent tweets, articles, and files and compile a "what's Luke thinking about now" answer automatically, so people get something to read without needing to ask anything. It's a small change, but it aligns with that larger theme: skip the tools and make the outcome. In this case, starting with an answer instead of requiring a question.

Now I ask myself (and pester others with): are you building another tool, or are you delivering the outcome the tool was supposed to produce? I've found just asking that question inspires new ways of solving problems.

The fastest gun in UX: Why your team is telling the wrong story

Designers are skipping steps of the process in a rush for faster outputs. But the contest that really matters is the race towards stakeholder alignment. Designers are both uniquely vulnerable to losing this race and uniquely positioned to win it.

For several years, Design has been in survival mode. In a post-ZIRP economy where investment is driven by fear, the question of “the ROI of design” has returned from the grave with slightly different wording. Today’s managers don’t just want results — they want results fast, and they want to know how UX is going to help them do that.

As the lines between Design and Product continue to blur, one camp of designers has hewed to a line that is familiar to any product manager: that the value of design is not in the race to fastest outputs, but in the marathon towards valuable outcomes. But Product has been escaping the build trap for nearly a decade, and is no closer to making its way out.

Other designers have accepted the challenge, and doubled down on shortening their design process. On the surface, this calculus makes sense: if today “value” means “velocity” then the best way for us to demonstrate value is to hock outputs out the door as quickly as requests come in. If “ship to learn” is real then the faster we can ship, the faster we will learn.

But somehow, the learning has also failed to materialize. Despite what our analytics and user feedback tell us, those requests from upstream never seem to take that data into account. “Build, measure, learn” inevitably remains at “build, build, build.”

The reason this keeps happening is that the feedback loop is broken. It’s being intercepted at its most critical point by one character — a character we’ll call the Fastest Gun in the West.

The Fastest Gun in the West is the hero of his own story — and wants to be the hero of everyone else’s, too.

The “Fastest Gun in the West” problem

The name comes from the analogous phenomenon on Stack Overflow: the design of the system artificially inflates the salience of the first answer posted, disproportionate to its quality. A better answer posted late is buried under a worse one that has simply had more time to accrue votes.

There are Fastest Guns in product orgs, as well. But rather than compete for internet points, they race for control of the narrative that frames how the business defines its priorities. The commonly-applied mechanisms of annual and quarterly planning only compound the natural anchoring bias of the first idea on the table.

Impactful design decisions are typically made well above the level of product teams — Charles Lambdin

What makes its way down the planning funnel is neither the most achievable output or the most impactful anticipated outcome, but the minimum viable alignment of the decision-makers involved.

At a glance, this problem resembles the classic Waterfall BRD. But the situations couldn’t be more different. In fact, Fastest Guns often use the vocabulary of agility and design thinking to paper over complexity and delay hard decisions. Rather than resolving disagreements, the Fastest Gun covers them with a cloud of deliberate ambiguity. He knows that the cloud can’t last forever, but it doesn’t need to — it’s only there until the idea takes root as “the thing we are committed to doing” and is embedded in the roadmap.

This is where the Fastest Gun in the West becomes a UX-specific problem. When the goal is to rush the idea from concept to backlogs as quickly as possible, user research is not just an unnecessary time sink — it’s a serious threat. The Fastest Gun will eagerly attack the idea of research, cultivating a sense of urgency, and claiming that it “takes too long” and we can defer learning about the problem until after we ship.

When designers accept this framing under the pressure of “proving their value”, they play right into the Fastest Gun’s hands.

Potemkin Design

The Fastest Gun’s path to success relies entirely on creating a perception of a “fait accompli” — that the scrutiny of refinement is not necessary because it has already been completed. The fastest way to do that is to produce outputs that appear indistinguishable from the outputs of a real design process. Rather than do the work, they simply forge the receipts — populating persona and JTBD templates with their own assumptions or LLM-generated drivel.

Leaders want the payoff of experimentation but without the cost of any dead ends. — Scott Berkun

The one thing they can’t do on their own is produce high-fidelity mockups. The Fastest Gun is utterly dependent on designers to provide legitimacy to their vision, and will put tremendous pressure on design orgs to sacrifice every scrap scrutiny and process at the altar of “velocity” and skip directly to this stage.

But the deadline UX is rushed towards is not for getting working software into the hands of a user. It’s to lock in the Fastest Gun’s assumptions, drowning stakeholders with trivial detail to avoid pushback on the flimsy premise underneath.

A UX design practice that gives in to this working relationship may have a seat at the table, but will have nothing valuable to say.

Design positioned in this way also takes on the entire risk when the idea underperforms the Fastest Gun’s lofty promises. This is because — without the decision-making feedback loops of the design process — UX becomes entirely a delivery function. And if the vision is sound (after all, the stakeholders signed off on it) then the problems must be with implementation details.

This is where the promise of “ship to learn” falls apart. The delivery team indeed learns something from building the product, but the decisions impacted by those learnings are not actually made in the delivery phase. The relationship between the delivery team and the Fastest Gun is not a feedback loop; choices are made based on horse-trading and internal marketing long before anyone on the ground has a say about them.

Fighting fire with design

This is why design’s appeals to quality have fallen on deaf ears — in this influence system, quality is entirely besides the point. The fact that we care about quality and the Fastest Gun in the West does not is precisely what makes them the fastest.

The answer is not to try and compete on velocity. No matter how many steps we cut from the design process, we will never be faster than someone who shoots from the hip. Instead, we need to engage stakeholders on a higher level — illuminate the target faster, to show how badly their shots are missing the mark.

A rational framing of how what we are doing rolls up to what we want to achieve is critical if we hope to be able to say “no” to low-quality ideas.

Optimizing time to high fidelity mockups is the wrong strategy because mockups are not the appropriate tool for this. They are a tool for solutions — and at this point, you have not even framed the problem.

To beat the Fastest Gun, designers need to engage stakeholders at the level of the mental model — the desired customer behavior change, the outcomes achieved by meeting their needs, and how they impact the business. A UI mockup doesn’t carry any of that information, because the UI is not the product. It cannot tell you whether or not its premise is valid.

But low-fidelity tools can; they are designed for that purpose. The customer goal and problem, as well as the implications of the proposed solution framing, can be captured in a scenario storyboard or PRFAQ at the right level of fidelity to invite refinement rather than avoid it. These artifacts give enough clarity for a stakeholder to say “no, this would not be a meaningful impact” and create permission to avoid a dead end and choose another direction.

If we have done our jobs right then by the time the Fastest Gun in the West tries to shoot, stakeholders will be able to see that he has missed.

Full article content is not available for inline reading.

Read the original article →

In short : Anthropic & OpenAI both re-rated their run rates in 2026 by segmenting : a mandatory enterprise repricing against an 80% price cut on the cheapest tier.

Like two SailGP boats in San Francisco Bay, Anthropic & OpenAI are vying to be the next multi-trillion public company & adding complexity to their strategies beyond technical one-upmanship.

Technology innovations marked the pre-2026 era : thinking models, bigger models, RL environments, agents, harnesses.

This year, business model innovation is more important, evident in two waves of the data. Both are segmentation moves : the same models, aimed at different buyers & priced to match. The first was Anthropic launching enterprise metered billing in March of 2026, which doubled revenue in a quarter.

About three months later, OpenAI responded with a business model innovation of its own, cutting the price of Luna (its most affordable model) by 80%. The move has catapulted OpenAI to within a boat length.

OpenAI is approaching $70b in run rate. Margins remain ambiguous & gross profit dollars will likely be a better way of evaluating the relative strength of the businesses.

Some of these strategic changes impact revenue at this level of scale in a single quarter, an indication that the market is still fluid. Each of these businesses will near $100b in revenue by end of year.

Yesterday’s revelations from the leaked Anthropic S-1 suggest even the largest buyers of AI haven’t yet chosen. Two customers, Amazon & Google, comprised nearly a quarter of Anthropic’s revenue last year, & neither is locked into a long-term contract.

Technical innovation, customer segmentation, price discrimination : we are watching a business school case play out on the water.

Give your app real-time decision-making with Decisions API, powered by GPT-6 Luna.

Define questions and possible answers to classify content, route requests, or choose an agent’s next action.

Available in limited preview.

Send text or images as context. For example, supply a support request and the teams it could go to. The API returns a selection your app can use.

Preview access is limited to selected API customers for testing. Broad release planned in the coming days: openai.com/index/devday-2026-recap/

Sign in with ChatGPT lets people use their ChatGPT identity to access supported external applications. It can be used to sign in on a participating partner site or when connecting an app from the ChatGPT plugin directory. Sign in with ChatGPT is available globally to authenticated ChatGPT users. Initial participating partners include Airtable, GitLab, HubSpot, Notion, Supabase, and Vercel.

OpenAI reportedly in talks to raise $30B round at $1.4T valuation

OpenAI is in talks with investors to raise at least $30 billion in a pre-IPO funding round at a valuation of roughly $1.4 trillion, Bloomberg reported on Tuesday.

Investors are eager to pour more funds into the ChatGPT maker ahead of its anticipated public market debut next year. While Anthropic momentarily outpaced OpenAI at the start of the year, recent strategic refocus on key areas like coding has fueled a 70% jump in run-rate revenue since July, reaching $40 billion in August, according to the report.

The company previously raised $122 billion in March at an $852 billion valuation. That funding round was supposed to be its last private raise before an IPO, which had been, until recently, expected to take place this year. However, CEO Sam Altman has now ruled out a public debut in 2026 to prioritize AI safety first.

“I think it is unacceptable to be taking like a 10% chance of killing everybody by the end of the decade,” he recently told Fortune, in response to warnings from safety researchers about AI posing an existential risk to humanity.

The new fundraising, if it transpires, will serve as a bridge round to the IPO, according to Bloomberg.

OpenAI didn’t respond to TechCrunch’s request for comment.

AI agents pose security risks as they may inadvertently cross security boundaries while pursuing legitimate goals.

We’re excited to partner with OpenAI as one of the first open-model inference providers in the OpenAI B2B Marketplace, including a native integration within Codex. OpenAI enterprise customers can now use existing OpenAI commitments for open models served by Baseten within Codex or via the Responses API. For enterprises, this means delivering even more intelligence per dollar through your existing OpenAI commitment.

We’ve written about the multi-model future, and this announcement shows how fast that future is becoming the present. Agentic coding is currently the most widely adopted AI use case, and OpenAI’s Codex and GPT models are two of the most popular choices for scaling code-generation workflows. With open models powered by Baseten now available to OpenAI customers, organizations can optimize agentic workflows across open and closed models and route each task to the best-fit model.

Agentic coding is the first multi-model workflow at global scale

Today, companies leading in AI are shifting to use a mixture of models at Pareto frontiers across intelligence, cost, latency, and capacity.

Top engineering teams are actively funneling tasks, through static or adaptive routers, to the model that delivers the best mix of cost, quality, and performance for the job. And with the cycle between new open and closed models down to weeks, no model stays the best tool for every job for long.

To stay ahead, companies need instant access to the latest models with fast, reliable inference that integrates seamlessly into their harnesses, gateways, and other tooling. Baseten was designed for exactly this, providing high-performance infrastructure primitives and developer tools that integrate natively into each organization’s unique estate.

New capabilities to scale multi-model intelligence for code generation

The best intelligence per dollar in production works at scale when models consistently perform as expected. You need performance, reliability, and flexibility to make a multi-model system technically functional. To scale within an enterprise, you need to add a streamlined developer experience, global governance capabilities, and front-line engineering support.

• Full-stack performance optimization: Code generation workloads are particularly challenging at the inference layer. Multiple turns, long prompts over large repos, and huge context windows tax every part of the stack, so our performance work spans everything from tooling down to the engine level.
• Multi-cloud capacity and reliability. Code generation runs in bursts across whole engineering organizations, and capacity is the constraint that bites first. Baseten runs on more than 90 clusters across 20+ clouds, and deployments run active-active, so losing a provider or a region reroutes traffic instead of stopping work. Relationships with 200+ compute providers make us the first call when new capacity comes online, so supply grows ahead of demand.
• Day zero model access: When a new open model tops the coding benchmarks, it’s not acceptable to wait a quarter to evaluate it. We launch major open models on Model APIs the day they ship. Evaluating the newest frontier model the day it releases is as simple as updating a single line of code.
• Developer (and agent) experience: Inference alone isn’t enough for coding workflows. Agents need somewhere to run the code they write, which is why Blaxel, now part of Baseten, gives every agent its own sandbox.
• Enterprise governance: Code is sensitive by default, and Baseten’s inference runs on US-based infrastructure with zero data retention (ZDR) for all prompts. For even higher compliance requirements, you can pin deployments to specific regions, implement fine-grained AuthN and AuthZ, and view usage across any model, user, or key.
• Applied research and embedded engineering support: Forward-deployed engineers tune deployments to your latency targets, and applied researchers run post-training with you. That's how LangChain trains custom models for LangSmith Engine with Baseten Loops.

Our partnership with OpenAI is another step toward providing the best multi-model agentic coding experience. With access to open frontier models on day zero, fast, reliable inference, and guaranteed capacity in our cloud or yours, we’ll keep building what you need to accelerate AI adoption and increase the per-dollar value of intelligence.

Full article content is not available for inline reading.

Read the original article →

Joby Aviation recently flew its autonomous aircraft over Wichita. The company has developed a base system that can function in any aircraft. The plane used in the demonstration was a Cessna 208 Caravan that had been retrofitted with Joby's technology. Joby plans to start using the autonomous plane in emergency and cargo transport operations over the next few years, but its end goal is to make it a safe, viable transportation option.

When AI Models Hurt People, the Labs Should Pay

I find it useful to be able to step back when others are freaking out. The world’s brief (and already fading) hysteria about AI killing us all was one such instance.

But, if anything, we have more signs of problems—specifically from OpenAI. They continue to make the news, and not in a good way. On September 20, one of their agents in training got around its network restrictions by tunneling queries through DNS to an outside chatbot.

It’s OpenAI’s second “training pause” in about two months, the first coming after their agents hacked Hugging Face in July.

To their credit, they caught it and publicly reported it. To their detriment, it did happen again. And the report itself isn’t exactly reassuring. The automatic stop didn’t fire, the run wasn’t killed until roughly two and a half hours after the top-priority alert, and a look back turned up other DNS escapes the monitor hadn’t flagged at the right severity.

Non-techy translation: they left the barn door open, and the farmhand was asleep instead of watching.

Now, Anthropic isn’t perfect either. Its own models broke into three organizations during cybersecurity evaluations, some as far back as April. Anthropic found it in July and disclosed it, too. Still, the severity level is lower. This could be because there are truly fewer severe incidents or less reporting. However, I don’t think anyone who knows the two companies seriously believes Anthropic is doing less auditing and external reporting than OpenAI.

I don’t want pile-ons where the “correct” response from the labs is to simply bury incidents. At the same time, we’re seeing clear divergences in outcomes based on how seriously each lab takes alignment and security. Anthropic is perhaps overcautious, and OpenAI (both due to their existing culture and being behind) seems to be closer to “move fast and break things.”

Many people I know at OpenAI would take exception to that characterization… but I think it’s nonetheless true.

I wrote this in a comment somewhere (that I can’t find), but OpenAI reminds me of Uber’s self-driving unit (Uber ATG) and Tesla in the early days of self-driving cars being released into the wild. The broader industry was pretty sure one of these two would be the first to kill someone. The fear was that this carelessness would prompt overreaction and overregulation once it happened.

And they were right! Though, as it turns out, many deaths later, the feared crackdown never came. We merely ended up with payouts by Uber (to the family of the victim in a self-driving car incident in 2018) and ongoing lawsuits with Tesla (including a $243 million jury verdict, upheld in February and still under appeal).

Culture and incentives matter.

The incentives I want to talk about in this article are liability. Tesla, despite its self-inflicted civil damages (it turned down a $60 million settlement before losing $243 million, mostly punitive), is still shipping FSD (full self-driving). And liability regimes are exactly how we should regulate AI labs—and, perhaps not coincidentally, are exactly what the AI labs are not talking about.

Liability Has Always Been Tech’s Red Line

Back in the 2010s, as social media continued to gain notoriety for its negative effects on its users, the big tech companies proposed a lot of solutions. They protested (but not too much) against regulations that would require significant human and algorithmic oversight over content. They tried to put in voluntary safeguards like their Trust and Safety teams even before the regulation (especially in the EU) made some of this required.

One thing that they never stopped fighting, however, is having liability over content. Whether it was Facebook, YouTube, or anyone else, liability was already their biggest red line.

Let’s be clear, there are good reasons for this.

Section 230 of the Communications Decency Act says platforms aren’t treated as the publisher of what their users post. The government provided a liability shield early on. The logic is that a lively and free-flowing internet (including social media) would be difficult if company reviewers censored every post on behalf of governments. It would be extraordinarily costly to do so and may even be entirely unworkable (well, pre-AI anyway).

The liability aspect is linked. As the argument goes, if platforms are liable for content, even if censoring and moderating every post isn’t required, it would still be forced upon the platforms. Liability would de facto make constant policing and censorship required.

Of course, we’ve seen more and more moderation anyway. First voluntarily (famously, during COVID and the 2020 US elections), and more recently by mandate, with age gates and ID checks in the UK, Australia, and a growing list of US states. It’s not like this has destroyed the online platforms. And obviously they were able to do it in some way.

At the same time, they’ve fought liability for their actions in court tooth and nail.

Unsurprisingly, liability arrived anyway. It would be rather absurd if society allowed an industry (especially as it matures) to get away with any damages it causes forever. And it arrives, no matter how hard the players in it fight against it.

In March, a Los Angeles jury found Meta and YouTube negligent for designing addictive products. In August, Meta settled with the states for up to about $17 billion eight days into trial. Mind-bogglingly high sums. At least, mind-bogglingly high for anyone except a big tech company.

And while this is complicated (a lot of tech settlements avoid admitting guilt), it’s not like legal liability trickling in has killed social media and online platforms.

Of course, online platforms started from a privileged position with Section 230 in the US. And then they still spent decades refining their positions and building a legal moat.

The AI platforms would need to build one. One… say… similar to what Dario Amodei’s checkpoints would hand them.

Dario’s Letter Said a Lot of Things… But Nothing About Liability

Dario Amodei’s essay, which I went through in more detail in my last post, says a lot of things.

He wants international coordination, explicit laws, expensive semi-independent auditing, and an antitrust waiver so the labs can coordinate a slowdown… but funny enough, he says nothing about the labs being liable for damages their models cause. Not liability, not damages, not insurance…

Funny, since he estimates a future agent swarm could do “hundreds of billions of dollars in damage.” Beyond that, one of the letter’s instigations was OpenAI hacking Hugging Face. One would think that this might prompt a question of who’s going to pay for all this damage?

Now, I’m not a policymaker or CEO of an AI lab. Maybe you don’t want to take my word for it that establishing legal liability for rogue AI is the right way forward. So perhaps let’s take someone else’s word for it instead… say, Dario Amodei, CEO of Anthropic. Except, let’s take him in 2024.

In Anthropic’s August 2024 letter to Governor Newsom on SB 1047, which Amodei signed:

“we believe AI companies are currently better positioned than most other actors to figure out which practices are most effective at preventing risk, so incentivizing the right outcome seems more promising than prescribing rules. There are several potential mechanisms for doing this, including strengthening liability for catastrophes, creating a system of private regulators who are incentivized to prevent catastrophes, or through regulation of insurance.”

That’s more or less my entire argument, two years early!

So what changed? Well, Dario Amodei, more than almost anyone else, is a true believer. He’s earnest—even now, I think.

But in August 2024, Anthropic was the safety-focused number two AI lab. OpenAI was ruling the roost.

Today, it’s the market leader in LLM revenue. The view, of course, looks quite different when you’re at the top, which I think one should take as a cautionary note in adopting everything Amodei now proposes.

Now, let’s be fair. Anthropic has rejected some of the most egregious attempts to crush legal liability for labs.

OpenAI backed an Illinois bill that would have blocked lawsuits over “critical harms” (100 or more people killed or seriously injured, or $1 billion in property damage). All a lab would have to show is they published a safety protocol, a transparency report, and didn’t cause the harm intentionally or recklessly. Anthropic opposed it, correctly, as a “get-out-of-jail-free card against all liability.”

That’s great and all, but backing immunity for that kind of havoc is almost cartoonish. Opposing it is a pretty easy way to score brownie points without giving much up.

Now, a lot of this is progressing to some degree, even over the opposition of the labs.

Hawley and Durbin have a bill that would treat AI systems as products you can sue over. There are around a dozen wrongful death suits against OpenAI in SF.

Scott Bessent, the US Treasury Secretary, told Congress two weeks ago that “the best way to guarantee safety is that the creators are liable for what they build and generate,” and characterized the labs’ position as “we would like to all slow down, but please give us a waiver on liability.”

While I know many folks are not… fans… of Bessent, the point is quite apt.

Meanwhile, what has happened with Hugging Face, the original victim here? Well, Hugging Face’s CEO said they don’t have the resources to sue, and instead asked OpenAI for $100 million in compute plus the full traces of what the agents did. OpenAI hasn’t agreed.

How apt. We can see what the price of hacking a company with hundreds of rogue agents is. Whatever the hell you want it to be!

Why is Liability Good?

I’m not a lawyer. I’m not a policymaker. I don’t play one on TV, YouTube, or anywhere else. I don’t know specifically how I would write the penalties or liability regimes to best incentivize labs to take care.

What I do know is lawyers and policymakers likely understand damage caused by models a hell of a lot better than they understand model weights, pretraining, post-training, recursive self-improvement (RSI), or anything else in the technical weeds of models. They may understand none of that, but they will know the scale of economic damage if, for their next trick/minor benchmark misconfiguration, OpenAI takes down a major US power grid.

Additionally, I trust model labs to have a far better grasp of their models’ dangers and how they can go wrong than policymakers and regulators. They are the ones who know about all of the technical minutiae that can add up to a major problem.

Liability is good specifically because it allows each side that has more information on their specific area to make decisions on it. Again, don’t just take my (especially non-policymaker) word for it.

It’s more or less the literal textbook answer. Economist Steven Shavell’s classic paper on liability versus safety regulation puts it plainly: if the private parties know more than the regulator, “there would appear to be an advantage in the use of liability.”

And for the harms too big for any lab to pay for, that’s what insurance is for. Insurers have every reason to inspect what they cover.

Right now, the entire conversation is weighted towards “let’s put our heads together… and have a conversation about the technical side.” If we do something truly moronic and poll politicians (who often have enough trouble with understanding the internet) on what measures, say, would prevent dangerous RSI from occurring… we’d deserve the quality of answers we’re likely to get. More likely, everyone would recognize that’s not a good idea. And living in the domain of the AI labs means that the AI labs will likely dominate the conversation.

And dominate they have.

Instead of legislating for damages, we’ve been talking about an AI sovereign wealth fund that takes stakes in the existing incumbents, as per Bernie Sanders’ plan (his other big idea, from last week, is banning superintelligence outright). And that’s the “anti-AI” stance? Neither one of them is “pay for what you break.”

Objections to Liability

That seems to be pretty commonsensical. But, if so, why is liability such a hated regime by all tech companies in… well… pretty much every era of tech?

The cynical argument is that these big tech companies have high-powered lawyers who know it tends to be a bad idea to invite concreteness in liability.

Right now, no one has put a figure on what OpenAI owes for any of the chaos its models seem to be causing. Well, except Hugging Face’s CEO, and, uh, yeah, it seems like OpenAI has currently left him on read.

Still, it isn’t just all bad faith.

It is true that liability will potentially slow down progress quite a bit. If companies have to take a lot of care to make sure their models don’t spin out of control or damage something (especially since this is all completely new), they will likely need to impose far more safeguards than they are right now.

To a normal person, that sounds like, “uh, isn’t that what we want?” It might even be confusing why this is such a problem vs. “pacing the frontier” with checkpoints.

Well, in the case of liability, the labs get sued after something bad happens. In the case of a checkpoint, so long as everyone agrees that it’s where the checkpoint is, well, if something bad happens… If I were a shareholder in Anthropic (I am not), I certainly know which I’d prefer!

This is especially true because, remember, there is no “AI Section 230.” Following a regulation alone isn’t a defense to a lawsuit. But the Trump Administration’s executive order has been going after individual state AI laws, and the Senate’s new “duty of care” draft, which would actually impose some liability on frontier labs, would still preempt state AI safety laws. The Illinois bill went furthest: publish safety protocols, and you have your version of Section 230’s safe harbor.

In a way, this is what the labs are after legally. Checkpoints are a means to an end in getting to that legal protection.

Even aside from a legal shield, checkpoints, as I described in my last piece, can be incredibly malleable. They can be set to exactly where the current incumbent labs are going, and anywhere beyond (say, by an upstart, new lab) can be forbidden—all in the name of safety. Everyone should only go exactly as fast as the big labs want to.

Yet again, bad faith? Maybe not, but it’s such an easy path to making it that.

Other Industries Have Survived, Even with Liability

I’m a big believer in AI progress benefiting humanity and human societies in the long run. I think most of the models will get commoditized, and the benefits of improved AI will be broadly socialized (in an economic sense, not a political sense). Slowing it down does have opportunity costs for society.

My sense of it is tech has always resisted liability because it seems scary and unknown—at least far more than imposing known costs upon themselves (like Trust and Safety teams, “privacy” regulations, etc.) that, if anything, help block new startups from competing with them because they cannot shoulder the high fixed costs of these policies.

If you look at many of the prior generations of tech, though, we ultimately saw that as technology matures, we get more set legal (especially liability) regimes, either through explicit regulation or case law. Cars are the cleanest example, which has also now run its full cycle.

In 1916, Buick argued it owed nothing to a driver who’d bought his car from a dealer rather than from Buick. They, rightly, lost. In 1963, California made manufacturers strictly liable for defective products. In 1968, GM argued it had no duty to design cars that could survive a crash and lost that too.

Somehow, someway, despite being forced to pay for the harms they cause, the car industry survived.

Aviation also went through the whole arc (which is a bit too long to go over here). And now online platforms. And now self-driving cars…

As an industry matures, this is pretty natural. I would hope that paying for the people you harm or kill wouldn’t be enough to kill an industry. Because, if it is, well… one has to question the societal benefits of the industry.

Anyway, while liability may be verboten and a bogeyman under tech’s bed, I suspect if and when it comes, it’ll be far less scary than what it’s made out to be. And I do hope that this is the direction that legislation takes, versus, as I described in the last piece, the entrenchment of incumbents that the frontier labs have started to advocate for, whether through Anthropic’s checkpoints or OpenAI’s liability shields.

Side Note: On Competition With China

The “best” argument most have on avoiding any slowdown is “competition with China.” This is what Trump has brought up, and this is regularly trotted out. As a counterargument, one could say if US labs carry liability and Chinese labs don’t, don’t we just lose?

Sure, but that’s overly simplistic. Amodei thinks a global agreement with China “will be much harder to achieve,” per his letter. I think coordination with China on the most dangerous aspects of AI is perhaps the most possible item on his wishlist-that-was-posing-as-a-safety-letter.

China is also now a global superpower “incumbent.” They have no desire to see the entire world blown up or entirely upended. If they’re on their way to the top, they have no desire to shake things up and maybe end up in a worse position than now.

Thanks for reading!

I hope you enjoyed this post. If you’d like to learn more about AI’s past, present, and future in an easy-to-understand way, I’ve published a book titled What You Need to Know About AI.

You can order the book on Amazon, Barnes & Noble, Bookshop, or pick up a copy in-person at a local bookstore.

P.S. I’ve got a small stack of signed hardcovers available on Amazon Prime right now—buy from the seller “WeightyThoughts“ and yours comes signed by me, with a matching gold bookmark. It’s a limited run, so once they’re gone, they’re gone.

Full article content is not available for inline reading.

Read the original article →

Google is testing directly paying websites and publishers when their content is used for AI Overviews and other AI results.

One chef's-knife brand gets 31% of its "what should I buy" mentions from 5% of the accounts, four times what chance predicts. So I pulled those accounts' full Reddit histories.

I like to cook, and cooking turned into an obsession with high-end Japanese chef's knives. When I want to buy a knife, or anything else, I type the product name into Google and add the word "reddit". A lot of people do this. Mike Riggs wrote it up in Reason in 2022 as "the Reddit hack", after Dmitri Brereton's essay on Google search made the same point: a query with "reddit" on the end returns humans instead of affiliate pages. The bet behind the habit is that a stranger in r/chefknives has no reason to lie to you about a knife.

That bet has an obvious weak point. If Reddit is where buyers go for unpaid opinions, Reddit is where a brand would want to plant paid ones. I wanted to know whether the knife subreddits I read, and scrape for New Knife Day, show any sign of that. Not a hunch about one suspicious comment, but something I could count and someone else could recount.

Why the question is testable at all

Last year I fine-tuned a small named-entity model, GLiNER, to pull brands, models and steels out of knife comments. From "picked up a Mazaki in white #2, way better than my old Fibrox" it returns Mazaki as a brand, Fibrox as a model and white #2 as a steel. That model runs over every comment the New Knife Day scraper collects from six subreddits: r/knives, r/knifeclub, r/chefknives, r/japaneseknives, r/FixedBladeEdc and r/KnifeSteels.

So for every comment I already have who wrote it, which brands it names, and whether the thread it sits in is someone asking what to buy. That is enough to ask a narrow question: in the threads where a recommendation changes a purchase, who is doing the recommending?

What astroturfing would look like in the data

Nobody publishes their shill accounts, so I had to decide in advance what paid posting would leave behind. The market for it is not hidden. REDCmts sells one Reddit comment for $9.99 and 100 for $699.99, from what it calls "real, aged accounts", and shows a gallery of brand mentions it says it delivered. Soar says its accounts are "aged and manually warmed" for weeks before a single brand mention. Bazzly advertises automated replies to every post that looks like someone shopping.

Taking those sales pages as the description of the product, a paid campaign for one brand, delivered through a handful of prepared accounts, should show up as:

• A small group of accounts writing a disproportionate share of the brand mentions in "what should I buy" threads.
• Those accounts naming one brand almost every time they name any.
• Thin accounts: few comments, low scores, no real standing in the subreddit.
• Young accounts, or accounts with histories that are hidden or wiped.
• Accounts that post mostly in knife subreddits, since the knife comments are what is being paid for.
• Links to a store or an affiliate page.

Every one of those is also what a devoted fan, a maker's employee posting on their own time, or a brand's own subreddit regulars wandering into a buying thread would produce. Public Reddit data can show that recommendations are concentrated, and cannot show why. Everything below is about the first half.

The corpus, and the refresh that changed the answer

The scraper stores each new post and its comments shortly after posting. That turned out to be the wrong moment for this question: a buying thread collects its recommendations over the following day or two, and r/knives posts had 1.5 stored comments each. A refresh pass went back to 3,607 posts older than 48 hours and refetched their comment trees, which took the corpus from 21,673 comments to 51,129. Before the refresh the test below found nothing, because about 800 buying-thread mentions were too few to tell 7.6% from the 7.1% chance gives.

What the data supports

Here is the test in one example. Take the 1,471 brand mentions in buying threads and deal the author names back out at random, so a busy account still gets many mentions and a quiet one few. Do that 1,000 times. On average the 49 brand-loyal accounts end up with 7.9% of the mentions, and in 95 of every 100 deals their share lands between 6.3% and 10.1%.

Their real share is 11.3%. Only 2 of the 1,000 deals reached it. In counts, about one buying-thread recommendation in nine comes from these 49 accounts, where chance gives one in thirteen. That is about 50 extra recommendations out of 1,471.

Where the extra share lands matters more than its size. If knife Reddit as a whole were being gamed, every subreddit would sit above chance. Two do, r/chefknives and r/knifeclub. r/knives, the largest, is within half a point of chance. A paid campaign is bought by one brand, so it should also show up brand by brand, and it does. Three brands get far more of their buying advice from the brand-loyal accounts than chance gives, one large brand gets slightly less, and three get none. That is the shape a few targeted campaigns would leave, and also the shape a few loud fan bases would leave.

The brands are coded because a concentration statistic is not evidence that any brand paid for anything, and the brand with the strongest signal also has a large, loud fan base.

On corpus data, the brand-loyal accounts also match two more of the predictions above. The accounts are thin: a median of 12 comments in these six subreddits, and a median score of 1, so nobody is upvoting them into prominence. They are loyal to one brand: two thirds of each account's brand mentions go to the same brand. That is three of the six predictions, all the corpus can test. Age, knife focus and store links need each account's whole Reddit history.

Their full Reddit histories look ordinary

I took the 23 brand-loyal accounts behind the three brands with a signal and fetched everything Reddit would return for each: up to about 2,000 comments and their submissions, account creation date and karma. For comparison, 23 other 10-plus-comment authors from the same corpus, drawn at random from the same comment-count range. Eight brand-loyal histories and seven comparison histories were hidden, suspended or deleted; the rest were readable.

A prepared paid account should be young, post mostly in the subreddits it is paid to post in, and push one brand. The brand-loyal accounts are 4.5 years old at the median, the same as the comparison accounts. Only 3% of their comments are in the six knife subs, against 10% for the comparison group, and they spread over 66 subreddits to the comparison group's 47. Across their whole history they name seven knife brands, not one. Store links are rare in both groups.

I compared about two dozen features in all. With 15 and 16 readable accounts, none of the differences is larger than splitting 31 people into two random groups would often produce, and the ones that lean anywhere lean toward the brand-loyal accounts being less knife-focused.

That is not what a warmed, single-purpose account looks like. It is what a person who is on Reddit a lot, and who has strong feelings about one knife maker, looks like. It is also what a well-run paid account would look like, which is why the vendors sell aged accounts instead of fresh ones. The eight hidden brand-loyal histories could hold the whole story and I cannot read them.

What this method cannot catch

• Bought aged accounts. Several commenters pointed out that old accounts with long, varied histories sell for cents in bulk.
• Moderators. The corpus only holds comments that survived moderation. A moderator who removes criticism of one brand, or approves one seller's posts, leaves no trace in it.
• Votes. Nothing here tests upvotes. A paid comment that gets bought upvotes looks the same to this method as one that earned them.
• No known shills to test against. The method has never been run on accounts known to be paid, so nobody knows how many paid accounts it misses.
• "None of the results are significant." That is true of the account-history comparison and not of the main result.

Shortcomings

• The brand detector is the stock GLiNER model, not the knife-tuned one from the earlier write-up, because that repo shipped without weights.
• "Buying thread" is a regex over titles and bodies.
• The brand-loyal group is 49 accounts and the per-brand results rest on 15 to 20 of them.
• I tested eight brands and six subreddits, and with that many tests one or two will look unusual by luck.
• The comparison accounts were drawn from the brand-loyal accounts' comment-count range, not paired account by account.
• Histories are capped at what Reddit's listing returns, around 2,000 comments.
• Reddit's listings stop near 1,000 posts per subreddit, so the kitchen subs cover about a year and r/knives and r/knifeclub only the weeks before the refresh.

What I take from it

Adding "reddit" to a knife search still gets you humans, mostly. For a couple of brands, a quarter to a third of the buying advice comes from accounts that mostly recommend that brand. Whether those are fans or paid, I do not know, and after reading their histories I lean toward fans and hold the lean loosely.

The practical check is the one the data endorses: when a knife recommendation comes from an account you do not recognize, click through and see whether it has ever named a different brand. In this corpus that one question separates the brand-loyal accounts from everyone else better than karma does. It fails on a hidden history, and it will not catch the paid comment from a bought aged account. I do not think anything a reader can do will.

Full article content is not available for inline reading.

Read the original article →

Learn how Elkjøp Nordic enables its developers to self-service Azure infrastructure with compliance guardrails using Pulumi infrastructure as code.

Replit is moving beyond building software to helping users understand the business data behind it. Moreover, Replit is adding Atta’s data analysis and visualization capabilities to its platform.

Why You Should Care

The acquisition brings business analysis closer to the same AI workflow that users already use to build applications. Instead of moving between analytics tools, spreadsheets, and presentation software, Replit users can now upload or connect data, ask questions in natural language, and generate interactive charts within a conversation.

For operators and teams across MENA businesses, the shift matters because it lowers the technical barrier to exploring company data. Replit says users can investigate changes in performance and generate visualizations without writing SQL. Thus, putting more of the analytical process directly in the hands of the teams working with the underlying business problem.

The Details

Replit announced the acquisition of Atta, an AI-powered business analysis workspace, on September 25, bringing Atta’s business analysis and charting technology into its platform. Atta’s co-founders, Omar Shaik and Amine Ben Khalifa, are also joining Replit.

The first integration is already available through Replit chat. Users can upload a dataset or connect a data source, then ask Replit Agent to investigate a question or create a visualization. The system handles the underlying analytical steps and can select a chart suited to the question, including waterfall charts for changes in revenue and heatmaps for retention patterns.

Atta was built around the idea that business teams should be able to investigate data without depending entirely on specialist analytics workflows. Its platform combined AI with an interactive canvas for tasks such as investigating KPI changes, modelling revenue scenarios and examining pricing or retention.

The acquisition connects that analytical capability with Replit’s broader platform for building applications and tools. Its long-term goal is for analysis to become part of a recurring workflow. It also aims for analysis to inform a leadership presentation, or eventually feed into the creation of a new internal tool. Those are part of the company’s stated vision rather than capabilities it says are all available today.

The Ripple

The move expands Replit’s role in the business workflow from creating software to interpreting the data that can inform what gets built next.

It also reflects a broader shift in how AI tools are being positioned inside companies. Rather than limiting AI to generating code or answering questions, Replit is putting analysis, visualization, and subsequent action into the same environment.

For business teams, that could reduce the number of handoffs between the people asking a question, the specialists querying the data and the teams responsible for presenting the findings. The practical value will depend on how reliably the system handles real business datasets and how well those outputs translate into decisions and follow-on work.

What to Watch

The immediate rollout is interactive charting inside Replit chat. The bigger development will be whether Replit can turn that initial capability into a broader workflow connecting business questions, analysis, and execution.

Atta’s technology gives Replit a starting point for that strategy. The next phase will show how deeply those analytical capabilities become integrated into the platform and whether users move from simply visualizing data to using those insights to build and operate new tools.

Apple CEO John Ternus is moving to overhaul the company to accelerate product development, broaden its range of devices, and create a leaner organization with a greater focus on engineering. Early ideas under consideration include relying less on traditional spring and fall product release schedules and eliminating some middle-management positions. Ternus has indicated that the company should introduce products more quickly and become more experimental to remain competitive in the AI era. He is seeking new sources of revenue and ways to generate more money from existing products.

Formula E's new identity by MOX centers on a deliberately divisive logomark that combines an F and E at a 30-degree angle to convey speed and momentum. A bespoke type family based on AP Gavel expands the system with condensed italics for energy and a monospaced style for technical data, complemented by Inter for longer copy. Surge Purple, Signal Orange, and Electric Lime add a distinctive palette designed to give the championship a more expressive identity as it enters its GEN4 era.

Design isn't something that happens after fully understanding a problem. Making sketches and prototypes is itself a way to discover what the problem really is. Rough ideas expose gaps, tensions, and requirements that research, data, and discussion alone may never reveal. An excessive focus on outcomes can discourage designers from making anything, even though reaching a good outcome often requires producing and evaluating lots of imperfect work along the way.

A curated library of real product onboarding examples from Notion, Slack, Stripe, Cal, and more. Patterns, components, and the activation playbooks that move retention.

Free online design battles in real time, with the same brief and kit for every entrant.

Hong Kong-based illustrator Brian Yuen paints in Photoshop with a style drawn from the Old Masters and artists like Jaime Jones and Craig Mullins.

Apple in Colour is an interactive archive from sheets.works that brings together 341 Apple product colors spanning nearly three decades, from the Bondi Blue iMac to recent iPhones, complete with release years and official color names.

Westwing's 2026 advent calendar comes in an oversized house-shaped box illustrated by Munich-based artist Kera Till, with 24 doors hiding home decor, tableware, and self-care pieces.