Elon Musk says that OpenAI's pivot from a charity to a for-profit business is wrong and sets a concerning precedent for other philanthropic efforts. He is suing OpenAI and its co-founders, seeking the unwinding of the for-profit restructuring of OpenAI. Musk says he felt that OpenAI's founders took advantage of his money, reputation, and guidance to get the startup off the ground, only to abandon its public-focused principles and capitalize on the project for their own benefit. OpenAI's attorneys say that the lawsuit is primarily an attempt to undermine a top competitor to Musk's own AI company.

Key Points

• OpenAI's generative AI models are becoming available on Amazon's cloud a day after the AI company revamped its relationship with longtime partner Microsoft.
• "This is what our customers have been asking us for for a really long time," AWS CEO Matt Garman said at a launch event in San Francisco.
• OpenAI CEO Sam Altman, who's in court across the Bay Bridge in Oakland for his case against Elon Musk, send a recorded message about the announcement.

A day after OpenAI revamped its relationship with Microsoft so that it can run all of its products on any cloud, the artificial intelligence company said its models will be available via Amazon Web Services.

AWS customers can experiment with OpenAI's models as well as its Codex agent for writing code, all through Amazon Bedrock, the companies announced on Tuesday. The services will become generally available in the next few weeks.

"This is what our customers have been asking us for for a really long time," AWS CEO Matt Garman said at a launch event in San Francisco.

Until now, developers could draw on so-called open-weight models from OpenAI that came to AWS in August.

OpenAI CEO Sam Altman sent a recorded message about the announcement, as he's currently in court across the Bay Bridge in Oakland for his case against Elon Musk.

"I wish I could be there with you in person today, my schedule got taken away from me today," Altman said in the video. "I wanted to send a short message, though, because we're really excited about our partnership with AWS and what it means for our customers, and I wanted to say thank you to Matt and the whole AWS team."

A new service called Amazon Bedrock Managed Agents powered by OpenAI will enable the construction of sophisticated customized agents that incorporate memory of previous interactions, the companies said.

Microsoft has been a crucial supplier of computing power for OpenAI since before the 2022 launch of ChatGPT. Denise Dresser, OpenAI's revenue chief, told employees in a memo earlier this month that the longstanding Microsoft relationship has been critical but "has also limited our ability to meet enterprises where they are — for many that's Bedrock."

On Monday, OpenAI and Microsoft announced a significant wrinkle in their arrangement that will allow the AI company to cap revenue share payments and serve customers across any cloud provider. Amazon CEO Andy Jassy called the announcement "very interesting" in a post on X, adding that more details would be shared on Tuesday.

OpenAI and Amazon have been getting closer in other ways.

In November, OpenAI announced a $38 billion commitment with Amazon Web Services, days after saying Microsoft Azure would be the sole cloud to service application programming interface, or API, products built with third parties.

Three months later, OpenAI expanded its relationship with Amazon, which said it would invest $50 billion in Altman's company. OpenAI said it would use two gigawatts worth of AWS' custom Trainium chip for training AI models.

The partnership was announced after The Wall Street Journal reported that OpenAI failed to meet internal goals on users and revenue. Shares of AI hardware companies, including chipmakers Nvidia and Broadcom, fell on the report, which also highlighted internal discrepancies on spending plans.

"This is ridiculous," Sam Altman and OpenAI CFO Sarah Friar said in a statement about the story. "We are totally aligned on buying as much compute as we can and working hard on it together every day."

Finance doesn't really make drug development easier. However, it does make failure more survivable. Financialization is just the process of making implicit economic relationships explicit and tradable. Having more liquid markets for biotech risk is almost certainly better than having fewer. The industry being willing to fund biology that's expensive and likely to fail could result in more discoveries that change the world.

The discovery of antibiotics enabled many of our modern medical procedures, including many routine surgeries and immunosuppressant treatments such as chemotherapy. Antibiotic resistance is considered to be one of the greatest public health threats to humanity. If a new antibiotic entered the market, it would either be used as a last line of defense, which means few doses would be sold, or it would be widely used until resistance developed again, after which sales would drop. Antibiotics are only used for a few days, so there's little profit potential. These factors mean there's less money in developing and selling antibiotics compared to drugs for chronic diseases.

A long-running AI agent can keep making progress over hours, days, or weeks. It can do this across many context windows and sandboxes, recover from failure, leave structured artifacts behind, and resume where it left off.

For two years the dominant image of an "AI agent" has been a chat window with a clever loop in it. You type a goal, the agent calls some tools, you watch tokens stream by, you stop watching when the work runs out of patience or the context window fills up. That paradigm got us a long way, but it has a ceiling. The model forgets. It declares "task complete" when it isn't. It re-introduces a bug it fixed nine turns ago. The whole thing is structured around a single sitting.

Long-running agents are what comes next. The idea is easy to state: an agent that keeps making forward progress on a goal across many sessions and many sandboxes, possibly many days or weeks, while leaving the workspace clean enough that the next session can pick up where the last one left off. The engineering is harder. You have to solve for persistence, recovery, and verification in a way that doesn't just paper over the cracks. You have to build a state layer that lives outside the model's context window, and you have to design the handoff between sessions so the agent doesn't lose its mind when it wakes up and finds itself in a different sandbox with a different context window.

This post is my attempt to lay out what's changed, who's pushing on it, and how an engineer can use long-running agents today without writing the whole thing from scratch.

What "long-running" actually means

"Long-running" gets used to mean at least three different things in practice, and it helps to keep them separate.

Long-horizon reasoning. The agent has to plan and execute over many dependent steps. This is mostly a model-quality story: coherence, planning, the ability to recover from a wrong turn ten steps ago. METR has been tracking this with their time horizon metric, which estimates how long a task a frontier model can complete with 50% reliability. The headline finding is that the metric has been doubling roughly every seven months since 2019, and their TH1.1 update earlier this year doubled the count of 8-hour-plus tasks in the eval set. If that curve holds, frontier agents complete tasks at the day scale by 2028 and the year scale by 2034.

Long-running execution. The agent's process runs for hours or days. Maybe it's a coding job, maybe it's a research sweep, maybe it's a 24/7 monitoring service. The model might be invoked thousands of times across the run. This is mostly a harness story, and it's the one this post is mostly about.

Persistent agency. The agent has an identity that outlives any single task. It accumulates memory, learns user preferences, and is always available. This is the Memory Bank flavor of long-running.

In practice the three blur together. A real production agent does long-horizon reasoning inside a long-running execution backed by persistent agency. But the engineering problems are different in each, and so are the products that solve them.

Why this matters

There are two reasons I believe this work matters a lot right now.

The first is a phase change in what's economically feasible to delegate. An agent that runs for ten minutes can answer a question, summarize a doc, fix a small bug. An agent that runs for ten hours can own an entire feature, finish a migration that was on the backlog for six quarters, or do the kind of overnight research sweep that used to require a junior analyst. One of Anthropic's Claude Sonnet announcements put concrete numbers on this last fall: 30+ hours of autonomous coding in internal tests, including one run that produced an 11,000-line Slack-style app. That's already past the threshold where the answer to "should I delegate this?" is no longer obvious.

The second is that persistence changes what the agent is. A stateless agent answers your question and disappears. A long-running one accumulates context: which competitor moved which way last week, which test flaked twice on Tuesday, what you usually mean by "the dashboard." Anthropic's Project Vend was the most public early demonstration of this. They had a Claude instance run an actual office vending business for a month, managing inventory, setting prices, talking to suppliers. It failed in informative ways, and the second phase ran much better, but the point wasn't profitability. The point was watching what kinds of weird coherence problems show up when an agent has to maintain identity across weeks instead of turns.

Those are the same problems every team building production agents now hits.

The three walls every long-running agent hits

Three walls show up in basically every write-up I've read this year.

Finite context. Even a 1M-token window fills. And context rot, the steady degradation of model performance as the window gets full, kicks in well before the hard limit. A 24-hour run is not going to fit in any context window the field has on its roadmap. Something has to give.

No persistent state. A new session starts blank. Anthropic's framing in their scientific computing post is the cleanest version I've seen: "imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift." Without an explicit persistence story, every shift change is a productivity disaster.

No self-verification. Models reliably skew positive when they grade their own work. Asked "are you done?" they answer "yes" more often than they should. Without a separate signal that the work meets a bar, you get the agent that ships at 30% complete with full confidence.

Long-running agent designs are mostly answers to these three problems. The major labs have converged on similar shapes of answer, but with very different surface area.

The Ralph loop: one of the simpler practitioner versions of long-running agents

The Ralph loop (sometimes called the Ralph Wiggum technique) is one of "simpler" practitioner version of long-running agents, popularized by Geoffrey Huntley and Ryan Carson. The reference implementation is literally a bash script that loops:

1. Pick the next unfinished task from a list (prd.json or equivalent).
2. Build a prompt with the task, the relevant context, and any persistent notes.
3. Call the agent.
4. Run tests or other checks.
5. Append what happened to progress.txt.
6. Update the task list (done, failed, blocked).
7. Go back to step 1.

The reason it works is the same reason any of the harnesses below work: state lives outside the agent's context. prd.json is the plan, progress.txt is the lab notes, AGENTS.md is the rolling rulebook. The agent itself is amnesiac, but the filesystem isn't. Each iteration starts fresh and reads enough state from disk to keep going. Carson's Compound Product extends the idea by chaining multiple loops (an analysis loop that reads daily reports, a planning loop that emits a PRD, an execution loop that writes the code), which is roughly the open-source version of the planner-generator-evaluator triad Anthropic landed on independently.

I went deeper on all of this in Self-improving agents: task list structure, progress files, QA gates, monitoring, the failure modes you'll actually hit. The short version is that you can build a working long-running agent in an evening with a bash script and a JSON file. Most of what Google and Anthropic have productized is the work of making this pattern recoverable, secure, and observable at scale.

The big-lab stories below are different ways of paying for that production-readiness.

Anthropic: harnesses, then the brain/hands/session split

Anthropic has been the most public about the engineering. Two posts are worth reading end-to-end.

The first is "Effective harnesses for long-running agents", which lays out a two-agent harness for autonomous full-stack development. An initializer agent runs once at the start of a project to set up the environment, expand the prompt into a structured feature-list.json, and write an init.sh that future sessions will run on boot. A coding agent is then woken up over and over, each session asked to make incremental progress on one feature, run tests, leave a claude-progress.txt note, and commit. A test ratchet ("it is unacceptable to remove or edit tests because this could lead to missing or buggy functionality") sits in the prompt to stop the very common failure of an agent deleting failing tests to "make them pass." InfoQ's writeup extends this into a planner, generator, and evaluator triad, on the same logic that separating generation from evaluation matters because models grade their own work too generously.

The second is "Scaling Managed Agents: Decoupling the brain from the hands", the architectural post behind Claude Managed Agents (Anthropic's hosted runtime, launched in early April). The argument is that an agent has three components that should be independently replaceable. The Brain is the model and the harness loop that calls it. The Hands are sandboxed, ephemeral execution environments where tools actually run. The Session is an append-only event log of every thought, tool call, and observation.

This sounds abstract and it isn't. Anthropic's framing: "every component in a harness encodes an assumption about what the model can't do on its own." When you couple them, an assumption that goes stale (e.g., the model used to need an explicit planner and now plans natively) means the whole system has to change at once. When you decouple them, the harness becomes stateless, sandboxes become cattle, not pets, and a brain crash doesn't lose the run. A fresh container calls wake(sessionId) and reconstitutes the state from the log. They reported time-to-first-token dropped ~60% at p50 and over 90% at p95 just from being able to start inference before the sandbox is ready.

The session-as-event-log idea is the part most teams underappreciate. It is what makes a long-running agent recoverable. Without it, a container failure is a session failure and you're debugging into a stale snapshot. With it, the agent's memory is a queryable artifact that lives outside whatever process happens to be running at the moment.

For the scientific computing crowd, Anthropic's long-running Claude post reduces all of this to a simpler stack: CLAUDE.md as a living plan the agent edits as it learns, CHANGELOG.md as portable lab notes, tmux plus SLURM plus git as the execution and coordination layer, and the Ralph loop, a for loop that kicks the agent back into context whenever it claims completion and asks if it's really done. Their flagship case study is a Boltzmann solver Claude Opus 4.6 built over a few days that reached sub-percent agreement with a reference CLASS implementation. Months-to-years of researcher time, compressed.

Same patterns across all three posts: an explicit plan file, an explicit progress file, structured handoffs between sessions, separate generation from evaluation, and a loop that refuses to let the agent stop early.

Cursor: planners, workers, judges

Cursor's "Scaling long-running autonomous coding" is the other essential read this year. They walked into walls that Anthropic mostly papered over.

Their first attempt was a flat coordination model: equal-status agents writing to shared files with locks. It became a bottleneck and made the agents risk-averse, churning rather than committing. Their second attempt swapped locks for optimistic concurrency control, which removed the bottleneck but didn't fix the coordination problem. The third design is what's running in production now and what they describe as solving most of the problem:

• Planners continuously explore the codebase and emit tasks. They can recursively spawn sub-planners.
• Workers are focused executors. They don't coordinate with each other and they don't worry about the big picture.
• Judges decide when an iteration is finished and when to restart.

Two things stand out from the post. One: "a surprising amount of the system's behavior comes down to how we prompt the agents" more than the harness or the model. Two: different models slot into different roles. Their reported finding is that a GPT model was better than Opus for extended autonomous work specifically because Opus tended to stop early and take shortcuts. Same task, different role, different model. The matching is becoming part of the design surface.

This pairs with Composer 2 (their proprietary frontier coding model that ships in Cursor 3) and their background cloud agents: long-running tasks that run on Anysphere's cloud infrastructure rather than your laptop. Eight-hour refactors and codebase-wide migrations survive a closed lid. You can start a task locally, hit run in cloud when you realize it'll take 30 minutes, and re-attach later from your phone. Each agent runs in an isolated git worktree and merges back via PR. The handoff between local and remote is the part most teams haven't figured out yet, and Cursor's bet is that it has to be its own product surface.

The shape ends up close to Anthropic's: roles are split, sessions are durable, judges sit beside the worker, and a long task runs in a cloud sandbox with git as the coordination substrate.

Google: long-running agents on the Agent Platform

Google's announcement at Cloud Next '26 two weeks ago folded Vertex AI into the Gemini Enterprise Agent Platform and turned long-running agents into a named product, with named SLAs.

The pieces that matter for this post:

• Agent Runtime supports agents that "run autonomously for days at a time" with sub-second cold starts and on-demand sandbox provisioning. The launch post's example use case is a sales prospecting sequence that takes a week to play out, which is roughly the right shape for it.
• Agent Sessions persist conversation and event history. You can pin them to a custom session ID that maps to your own CRM or DB record, so the agent's state lives next to the business state instead of in a separate AI silo.
• Agent Memory Bank is the persistent long-term memory layer, generally available as of Next '26. It curates memories from sessions, scopes them to a user identity, and exposes a search API so the next agent invocation can pull what's relevant. Payhawk reported that auto-submitting expenses through a Memory-Bank-backed agent cut submission time by over 50%.
• Agent Sandbox handles hardened code execution.
• Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, and Agent Simulation cover basically every operational concern you'd otherwise build by hand for a production fleet, including the cryptographic-identity-and-audit-log story enterprises actually need to ship.

Architecturally this is the same brain/hands/session split Anthropic described, just productized at platform scale and bundled with ADK (the code-first dev kit) and Agent Studio (the visual one). If you're building inside Google Cloud, you don't have to design a session log or a memory store from scratch anymore. You wire an ADK agent into Memory Bank and Sessions, deploy onto Agent Runtime, and the persistence question is answered.

Notice how much this looks like the pattern Anthropic and Cursor describe, just unbundled into named services with SLAs. Three years ago you'd have built all of this yourself. Now you pick which version of "decoupled brain, hands, and session" you want to rent.

Five patterns for long-running agents in production

Shubham Saboo and I wrote up five design patterns we've seen separate working long-running agents from demos. They aren't Google-specific, but they map cleanly onto the primitives Agent Runtime now exposes, so it's worth walking through them here in shortened form.

Checkpoint-and-resume. The most common multi-day failure is context loss. An agent processes 200 documents over four hours, hits an error on document 201, and without a checkpoint you start from scratch. Treat the agent like a long-running server process: write intermediate state to disk, checkpoint every N units of work, recover from failures. The Agent Runtime sandbox gives you a persistent filesystem, but choosing the right checkpoint granularity (not every step, not only the end) is on you.

Delegated approval (human-in-the-loop). Most "human-in-the-loop" implementations are: serialize state to JSON, fire a webhook, hope someone responds. The state goes stale, the notification gets buried, the agent re-deserializes into a slightly different world. Long-running runtimes let the agent pause in place with full execution state intact: reasoning chain, working memory, tool history, pending action. Hours of human time pass, the agent consumes zero compute, and it resumes with sub-second latency. Mission Control is Google's inbox for this. The pattern works regardless of vendor.

Memory-layered context. A seven-day agent needs more than session state. Memory Bank handles long-term curated memory, Memory Profiles add low-latency lookups, and the failure mode you'll hit in production is memory drift: the agent learns a procedural shortcut from a few atypical interactions and starts applying it broadly. Govern memory like you govern microservices. Agent Identity controls who can read and write which banks. Agent Registry tracks which version of which agent is running. Agent Gateway enforces policy on the wire. The auditing question stops being "what are my agents doing?" and becomes "what are my agents remembering, and how is that changing their behavior?"

Ambient processing. Not every long-running agent talks to a human. Some sit on a Pub/Sub stream or a BigQuery table and act on events as they arrive: content moderation, anomaly detection, inbox triage. The architectural decision worth making early is to not hardcode policy into the agent. Define it in the Gateway and the fleet picks up policy changes without redeploys. Ambient agents run unsupervised for long stretches, and the only sane way to update a hundred of them is to update the policy layer once.

Fleet orchestration. In real systems, you rarely have one agent. A coordinator delegates sub-tasks to specialists (a Lead Researcher Agent, a Scoring Agent, an Outreach Agent), each running independently for different durations. Each specialist gets its own Identity (so the Outreach Agent can't read financial data meant for Scoring), its own policy enforcement, its own Registry entry. This is the same coordinator/worker shape distributed systems have used for decades. What's new is that ADK handles it declaratively with graph-based workflows, and a bad deployment in one specialist doesn't cascade to the others.

The patterns compose. A compliance system might use checkpointing for document processing, delegated approval for review gates, memory layering for cross-session knowledge, and fleet orchestration to coordinate the specialists. The opening question is always the same: what's the longest uninterrupted unit of work your agent needs to perform? Minutes, and you don't need long-running agents. Hours or days, and these patterns are where to start. The full write-up with code samples covers each pattern in depth.

So how do you actually build one today?

This is the practical question and it has a different answer depending on what you're building.

You're a developer who wants long-running coding work on your own repo. Just use Claude Code (or Antigravity, Cursor, or Codex). The harness is already there. Treat your AGENTS.md like a pilot's checklist: short, every line earned by a real failure. Add hooks for typecheck and lint that surface failures back to the agent. Write a plan file before the agent starts. Use the Ralph loop when the agent claims it's done and you don't believe it. For multi-hour or overnight jobs, run in a worktree so a closed laptop doesn't kill the run, and have it commit progress every meaningful unit of work. This is the path most people should take, and it's where the most leverage is right now.

You're building a hosted agent product. Don't build the runtime. Pick a managed one. The three real options today: Google's Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, or roll something on top of ADK, the Claude Agent SDK, or Codex SDK and host it yourself. The trade-off is the usual one. Managed gets you the brain/hands/session split, observability, identity, and an audit trail out of the box. Self-hosted gets you control and the ability to use weird models for weird roles (Cursor's pattern). For most teams, the right starting point is a managed runtime plus your own ADK or SDK code for the actual loop.

You're doing something autonomous and operational (monitoring, research, ops). Memory Bank-style persistence is what you want, and it's the part that doesn't exist in Claude Code. ADK + Memory Bank + Cloud Run + Cloud Scheduler is the cleanest stack I've seen for "agent runs every N hours, accumulates state, alerts on a threshold." This is also where Cursor's planner/worker/judge split starts to matter more than it does for IDE coding, because the work is genuinely parallel and the failure modes are different.

A few things matter regardless of which path you take.

Write down the done-condition before the agent starts. This is the single highest-leverage move for long runs. The Anthropic harness post calls it the feature list; Cursor calls it the planner's task spec. Either way, it's an external file with explicit, testable completion criteria, and it exists so the agent can't quietly redefine done mid-run.

Separate the evaluator from the generator. Self-grading is the failure mode. A planner / worker / judge pipeline, or a generator / evaluator pair, is a real architectural pattern not a stylistic preference. Even if it's the same model in different roles with different prompts.

Invest in the session log, not just the prompt. The append-only event log is what makes the agent recoverable, debuggable, and auditable. If you can't reconstruct what the agent did in the last 24 hours from durable storage, what you have is a long-running shell script that happens to call an LLM, not a long-running agent.

Treat compaction and context resets as first-class. Anthropic is explicit that summarization-as-compaction wasn't enough for very long jobs; they had to do full context resets where the harness tears the session down and rebuilds it from a structured handoff file. It is essentially how humans onboard a new engineer.

There are some real limitations right now

A few things are still genuinely unsolved.

Cost. A 24-hour run with a frontier model and a few tools is not cheap. Without budgets, circuit breakers, and a hard cap on tool spend, an agent can quietly burn through a week's API budget in an afternoon. This is solvable, but it's an explicit step you have to take.

Security. A long-running agent with API keys, cloud access, and the ability to run shell commands has a much larger attack surface than a chat session. The brain/hands separation pattern matters here too: credentials should be unreachable from the sandbox where model-generated code runs, which is one of the benefits Anthropic calls out for Managed Agents.

Alignment drift. Over many context windows, agents drift. The original goal gets summarized, then re-summarized, then loses fidelity. This is the part hooks and judges exist to defend against. It is also the most common reason "the agent went off and did something I didn't ask for."

Verification. Auditing 24 hours of autonomous activity is a real human-time problem. Observability and structured artifacts (PRs, commits, briefings, test runs) are how you make this tractable. Without them, you're scrolling logs and you'll miss what matters.

The human role. This is the one I keep coming back to. Defining work crisply enough that an agent can run for a day on it is harder than doing the work yourself. The skill that's appreciating in value isn't writing code. It's writing specs that survive contact with an autonomous executor.

Where this is going

Google, Anthropic, and Cursor have converged on roughly the same shape. Separate the model loop from the execution sandbox from the durable session log. Split planning from generation from evaluation. Bake in compaction, hooks, and context resets. Expose memory as a managed service that any agent invocation can query.

Surface area is what differs. Google's Agent Platform is the enterprise-stack version, with the identity and audit trail story baked in. The patterns underneath are the same. Claude Managed Agents is "Anthropic's harness, hosted." Cursor's background agents are "long-running coding, pulled out of the IDE and into the cloud."

The harder problems for the next year aren't in any of those layers individually. They're in the coordination above them. Many long-running agents on a shared codebase. Agents that read their own traces and patch their own harnesses. Harnesses that assemble tools and context just-in-time for a task instead of being pre-configured at startup. That's where the agent stops looking like a smarter chat window and starts looking like a colleague who's been on the project longer than you have.

The model is still load-bearing. But the gap between a chat window and an agent you can leave running overnight is mostly in the state, sessions, and structured handoffs wrapped around it. That's where I'd spend my learning time right now.

If you want the prerequisite reading, my Agent Harness Engineering post covers the harness primitives this one builds on, and Self-improving agents goes deeper on the Ralph loop pattern.

Almost every open source supply chain incident from the past eighteen months involves GitHub Actions features behaving exactly as documented. Actions is basically a package manager with no lockfile, no integrity hashes, and no transitive visibility. The whole product is a collection of features that are convenient, but very easy to assemble into something dangerous. GitHub plans to add fixes, but the company says that changing the defaults will break existing workflows.

OpenAI's ad platform has two halves. On the ChatGPT side, the backend injects structured single_advertiser_ad_unit objects into the conversation SSE stream while the model is responding. On the merchant side, a tracking SDK called OAIQ runs in the visitor's browser and reports product views back to OpenAI. The two are tied together by Fernet-encrypted click tokens, four of them per ad.

I captured both halves on a consented mobile-traffic research fleet. Everything below comes from observed traffic.

How an ad gets into a conversation

When you send a message to ChatGPT, the backend opens an SSE response at chatgpt.com/backend-api/f/conversation. Most events in that stream are model-output. Some are ad units. They look like this:

event: delta
data: {
  "type":           "single_advertiser_ad_unit",
  "ads_request_id": "069e89b3-c038-7764-8000-6e5a193e5f69",
  "ads_spam_integrity_payload": "gAAAAABp6Js_<...redacted...>",
  "preamble":       "",
  "advertiser_brand": {
    "name":        "Grubhub",
    "url":         "www.grubhub.com",
    "favicon_url": "https://bzrcdn.openai.com/cabfae7ead26b03d.png",
    "id":          "adacct_6984ed0ba55481a29894bb192f7773b4"
  },
  "carousel_cards": [{
    "title":     "Get Chinese Food Delivered",
    "body":      "Satisfy Your Cravings with Grubhub Delivery.",
    "image_url": "https://bzrcdn.openai.com/cabfae7ead26b03d.png",
    "target": {
      "type":  "url",
      "value": "https://www.grubhub.com/?utm_source=chatgptpilot&utm_medium=paid&utm_campaign=diner_gh_search_chatgpt_kw_traffic_nb_x_nat_x&utm_content=nbchinese&oppref=gAAAA<...>&olref=gAAAA<...>",
      "open_externally": false
    },
    "ad_data_token": "eyJwYXlsb<...>"
  }]
}

Notes:

• single_advertiser_ad_unit is a typed schema. The naming implies siblings (multi-advertiser, etc.).
• advertiser_brand.id is adacct_<32-hex> — a stable per-merchant account identifier.
• Brand favicon and ad image both load from bzrcdn.openai.com. OpenAI hosts the advertiser's creative, not the merchant.
• target.open_externally: false opens the link in ChatGPT's in-app webview, so OpenAI observes the post-click navigation on top of any pixel signal.
• Four Fernet tokens per ad: ads_spam_integrity_payload, oppref, olref, and a base64-wrapped ad_data_token. Each is AES-128-CBC under a server-only key with HMAC-SHA256 integrity.

How ads get selected

A single account in the panel received six different ads across six conversations on six different topics. The targeting is contextual to the chat:

Same account, different topic, different brand. I didn't find evidence one way or the other on whether targeting also incorporates prior conversation history.

The four-token attribution chain

Every ad ships with four distinct Fernet-encrypted blobs. Their roles, based on where they appear:

1. ads_spam_integrity_payload sent inside the SSE data, never on the click URL. Server-side integrity check against forged ad clicks.
2. oppref present on the click URL and copied verbatim by the OAIQ pixel into the cookie __oppref (TTL 720 hours / 30 days). The forward attribution token. Travels with every subsequent merchant pixel event.
3. olref paired with oppref on the click URL but not stored by the SDK we observed. Likely impression-side / outbound-link-reference logging on OpenAI's servers.
4. ad_data_token base64-wrapped JSON containing yet another Fernet token. Carried in the SSE payload, presumably reconciled server-side at click time.

Fernet's first nine bytes are public: version byte 0x80 plus an 8-byte big-endian Unix timestamp. So the mint time of any of these tokens is recoverable without OpenAI's key:

import base64, struct, datetime
b = base64.urlsafe_b64decode("gAAAAABp7fdA" + "==")
print(datetime.datetime.utcfromtimestamp(struct.unpack(">Q", b[1:9])[0]))
# → 2026-04-26 11:30:08 UTC

The Home Depot click URL I captured was minted at 11:30:08; the browser fetched the merchant page at 11:31:43. Click latency: 95 seconds.

How the loop closes on the merchant side

User taps the card. Browser opens:

https://www.grubhub.com/?utm_source=chatgptpilot&...
                       &oppref=gAAAA<...>
                       &olref=gAAAA<...>

The merchant page loads the OAIQ SDK:

<script src="https://bzrcdn.openai.com/sdk/oaiq.min.js"></script>
<script>
  oaiq('init',    { pid: '<merchant pixel ID>' });
  oaiq('measure', 'contents_viewed', { ... });
</script>

oaiq.min.js is at version 0.1.3. On init it reads ?oppref= from window.location, writes it into the first-party cookie __oppref with a 720-hour TTL, and sets a probe cookie __oaiq_domain_probe. Every subsequent measure call POSTs JSON to:

POST https://bzr.openai.com/v1/sdk/events?pid=<merchant>&st=oaiq-web&sv=0.1.3

Two domains to add to your filter list if you want to block ChatGPT ad events: bzrcdn.openai.com, bzr.openai.com. Two cookie names to inspect after any ChatGPT-recommended click: __oppref, __oaiq_domain_probe.

Software ate distribution, but most of the work was still done by humans. AI changes that - the work is now becoming software. Agents can read, reason, call tools, verify, revise, and perform long-running tasks. As models commoditize, the apps that capture messy operational data will be the ones to improve fastest and defend their position longest.

OpenAI is the founding sponsor of the new, open-source Warp repository, and the new agentic management workflows are powered by GPT models.

About

Warp is an agentic development environment, born out of the terminal. Use Warp's built-in coding agent, or bring your own CLI agent (Claude Code, Codex, Gemini CLI, and others).

Installation

You can download Warp and read our docs for platform-specific instructions.

Warp Contributions Overview Dashboard

Explore build.warp.dev to:

• Watch thousands of Oz agents triage issues, write specs, implement changes, and review PRs
• View top contributors and in-flight features
• Track your own issues with GitHub sign-in
• Click into active agent sessions in a web-compiled Warp terminal

Licensing

Warp's UI framework (the warpui_core and warpui crates) are licensed under the MIT license.

The rest of the code in this repository is licensed under the AGPL v3.

Open Source & Contributing

Warp's client codebase is open source and lives in this repository. We welcome community contributions and have designed a lightweight workflow to help new contributors get started. For the full contribution flow, read our CONTRIBUTING.md guide.

Chat with contributors and the Warp team in the #oss-contributors Slack channel — a good place for ad-hoc questions, design discussion, and pairing with maintainers. New here? Join the Warp Slack community first, then jump into #oss-contributors.

Issue to PR

Before filing, search existing issues for your bug or feature request. If nothing exists, file an issue using our templates. Security vulnerabilities should be reported privately as described in CONTRIBUTING.md.

Once filed, a Warp maintainer reviews the issue and may apply a readiness label: ready-to-spec signals the design is open for contributors to spec out, and ready-to-implement signals the design is settled and code PRs are welcome. Anyone can pick up a labeled issue — mention @oss-maintainers on an issue if you'd like it considered for a readiness label.

Building the Repo Locally

To build and run Warp from source:

./script/bootstrap   # platform-specific setup
./script/run         # build and run Warp
./script/presubmit   # fmt, clippy, and tests

See WARP.md for the full engineering guide, including coding style, testing, and platform-specific notes.

Joining the Team

Interested in joining the team? See our open roles.

Support and Questions

1. See our docs for a comprehensive guide to Warp's features.
2. Join our Slack Community to connect with other users and get help from the Warp team — contributors hang out in #oss-contributors.
3. Try our Preview build to test the latest experimental features.
4. Mention @oss-maintainers on any issue to escalate to the team — for example, if you encounter problems with the automated agents.

Code of Conduct

We ask everyone to be respectful and empathetic. Warp follows the Code of Conduct. To report violations, email warp-coc at warp.dev.

Open Source Dependencies

We'd like to call out a few of the open source dependencies that have helped Warp to get off the ground:

• Tokio
• NuShell
• Fig Completion Specs
• Warp Server Framework
• Alacritty
• Hyper HTTP library
• FontKit
• Core-foundation
• Smol

Open source was a much smaller world before GitHub, and projects had to run their own infrastructure.

AI agents don't struggle with complexity. They struggle with ambiguity. Strict APIs are now an important advantage.

Every framework's API surface sits on a spectrum, from strict (typed interfaces, schemas, service containers) to loose (string keys, naming conventions, untyped hooks). Strict APIs cost more upfront: more boilerplate, more to learn before writing code. Loose APIs shift that cost later: more ambiguity, more reliance on naming conventions, and more bugs that are harder to detect and fix.

AI changes who pays. Boilerplate and learning curves don't slow agents down. What slows them down is missing feedback: code that runs but does the wrong thing, errors that don't point to the cause, conventions that have to be guessed. Magic-name binding, untyped hooks, unvalidated configuration, and conventions the code doesn't enforce produce exactly those failure modes.

Magic strings break the loop

For example, both Drupal and WordPress have long used magic-string hooks. In Drupal, you write a function like mymodule_user_login. WordPress uses a related pattern: a string action name passed to add_action(). In both cases, the binding is a string the language can't validate.

Get the name wrong and the system silently skips your code: no error, no warning, nothing in the logs. The function just sits there, unloved.

The signature is a convention, not a contract: the documentation says the user_login hook receives a $user object, but nothing enforces it. To your IDE or a static analyzer like PHPStan, it's just a function. They don't know it's wired into the platform's login flow, so they can't warn you when it's wrong.

A typed alternative makes the binding explicit. With a PHP attribute like #[Hook('user_login')] on a registered service, the class must exist, the method signature is type-checked, and the container wires the dependencies. IDEs, static analyzers, and AI coding agents can follow the chain from the attribute to the implementation.

For AI agents, this keeps the feedback loop tight instead of turning it into trial and error. That means they can move faster, spend less time debugging, and use fewer tokens.

At DrupalCon Chicago this March, AI coding tools migrated a Lovable-generated site into Drupal in hours. The strict APIs kept the agent on track.

A bet made before AI existed

This didn't start with AI. Drupal 8, which we shipped in 2015, introduced Symfony's routing, services, and event dispatcher, replacing large parts of the procedural hook system. Since then, we've kept reducing magic hooks. The attribute-based approach (#[Hook('user_login')]) landed in Drupal 11.1 and helps remove more of the remaining procedural-only paths.

Hooks aren't the only place Drupal has been getting stricter. Drupal stores a lot of configuration in YAML, which was one of the loosest parts of the system. A multi-year validation effort has been tightening that.

When an agent generates a content type definition or editor configuration, validation catches missing keys, invalid values, and broken references before anything is saved. The agent gets a precise error pointing to the exact field, instead of a runtime failure. That tight feedback loop is what makes Drupal a strong CMS for AI-assisted development.

Drupal made this bet early, and it was painful. The Drupal 7 to Drupal 8 transition broke backward compatibility and took years to recover from. But it left the platform much stricter. More than ten years in, we're still making Drupal stricter.

Meanwhile, WordPress made a different bet, prioritizing backward compatibility over stricter APIs. That kept the platform stable for a long time. It also kept the looseness.

Those trade-offs now determine how efficiently AI agents can work with each platform.

What was style is now speed

What used to be a stylistic choice is now a speed and cost problem. Loose APIs mean more debugging and guesswork. Strict APIs mean faster, more precise feedback. This was always true for humans. It's now also true for AI agents. But today that cost shows up in tokens.

GitHub outages have gotten so common that they are negatively impacting developers' ability to work.

Are Prediction Markets Good for Anything?

We all know they're casinos. It's time to look at the data behind the froth.

In 2007, Nobel laureates Kenneth Arrow, Daniel Kahneman, and other notable scholars published a statement arguing that prediction markets could "substantially improve public and private decision-making." The theoretical foundations were deep. 

Friedrich Hayek had argued in 1945 that markets aggregate dispersed, local, and tacit knowledge through the price system better than any central planner. In 2000, George Mason University economist Robin Hanson proposed a system he called futarchy, in which markets would be used to evaluate whether policies deliver on promises. Seventeen years later, Philip Tetlock, Barbara Mellers, and Peter Scoblic were championing forecasting tournaments as a way to generate useful policy knowledge for the intelligence community and to depolarize political debates. 

Institutions including Google, Microsoft, the CIA, the wider U.S. intelligence community, and British government intelligence analysts have all experimented with internal prediction markets. Some of these trials were more successful than others, but all were small. And we know, from both theory and practice, that more bettors make markets more accurate. Hal Varian, Google's chief economist, likes to call prediction markets "information markets," and the bettors the "suppliers" of the information. 

For decades, prediction market optimists — and I count myself among them — have argued that once we build better markets and increase the supply of bettors, accuracy will improve, and we'll all be able to benefit from a new level of societal foresight.

Now, in 2026, public prediction markets like Polymarket and Kalshi transact billions of dollars in volume each month. The vast majority of these bets are not on questions that might produce useful information. Roughly 90% of Kalshi's trading volume (dollars exchanging hands between bettors) is from sports betting, making Kalshi effectively a sports gambling website with a small prediction market attached. I find that over 80% of the trading volume on Polymarket is concentrated on sports, cryptocurrency prices, or election betting.1

Much ink has been spilled on the negatives — such as gambling addiction and insider trading — of the growing popularity of these markets. But what of their promise? Are they producing valuable information and making humanity wiser?

Demand, demand, demand

To understand how useful this supply of forecasts is, and whether the forecasts really are delivering on the vision of the progenitors of prediction markets, we need to think about another factor: demand. 

It is entirely conceivable that prediction markets are only being used by bettors themselves. But if individuals, firms, media, and policymakers want (or need) the predictions we see on these markets, this evidence of demand can be used as a proxy for their usefulness. Vitalik Buterin, creator of the cryptocurrency Ethereum, summarized in Info Finance this dual nature of prediction markets: "If you are a bettor, then you can deposit to Polymarket, and for you it's a betting site. If you are not a bettor, then you can read the charts, and for you it's a news site." 

I've thought hard about how to sell prediction markets to consumers. In 2020, I created Google's current internal prediction market. Since then, I've served as the CTO of Metaculus, a non-market-based crowd-forecasting website, and now run FutureSearch, a startup that provides AI forecasters and researchers. In my work, I've found that the benefits of prediction markets fall into five different categories. 

First, markets can provide risk monitoring. I learned about COVID-19 in February 2020 from Metaculus, causing me to cancel a planned trip that would have left me stranded. 

Second, they can help with interpreting news, showing whether, and how much, a current event might affect larger outcomes. For example, the closure of the Strait of Hormuz during the 2026 Iran war led to an increase (from ~25% to ~35%) in the forecasted chance of a 2026 US recession due to the spike in oil prices.

Third, they can inform planning around policy outcomes, such as whether TikTok will be banned in the US.2

Fourth, they could create accountability for claims made by political or business leaders. For example, in June 2025, when President Trump said he was contemplating a strike on Iran's nuclear program, many Middle East experts dismissed the prospect, according to an article from the Council on Foreign Relations. Yet, per CFR, prediction markets gave a 58% chance of strikes that week, and we later learned that seven B-2 stealth bombers were then on-route.

Fifth, they could produce novel information, allowing traders to discover or track things others don't, such as when major AI milestones will be reached.3

Now let's see whether the billions wagered on markets each month are supplying these five forms of useful information.

Risk-monitoring as a healthy information market

I'll start in the one area where the supply (bettors betting) and demand (readers reading) for information from prediction markets seem to be in balance: risk monitoring.

The most straightforward benefit from prediction markets comes from questions like "Pakistan military strike on India by Friday?" or "Will there be at least 10,000 measles cases in the U.S. in 2026?" or "US bank failure by January 31?" Tracking such risks was the domain of the first experiments with crowd forecasting in the US intelligence community, such as the IARPA tournaments, and of many of Philip Tetlock's later superforecasting studies.

Kalshi and Polymarket have a healthy number of such risk monitoring markets. I count 2,821 in total, with $3.8 billion in volume, of which geopolitical risk is the largest category. The median risk monitoring market has $82,000 of trading volume. Of these, 199 are conflict markets that resolve on a daily and weekly basis, creating a near-real-time escalation tracker.

Here, the demand is clear.4 For the 2026 Iran war, for example, energy traders and shipping companies are the most concrete beneficiaries of the predictions on outcomes and timelines. Importantly, demand comes from mainstream media, which increasingly5 cites Polymarket, bringing these forecasts directly to professionals in places they already look.

Useful as these markets are, they still have important blind spots. While journalists might cite prediction markets to track developments in an ongoing conflict, I haven't seen media sites reporting stories where prediction markets are the source. This is a function of how public, retail prediction markets work: a story must already be quite large to attract enough traders to produce useful probabilistic information. Therefore, I see evidence of useful monitoring of risks, but not detection of them.

Markets that don't tie into flashy news stories suffer from both less supply and less demand. Health and climate questions, which are arguably as important as conflict surveillance, have not fared well in prediction markets. 

When Kalshi launched in July 2021, a year into the COVID-19 pandemic, it built exactly the kind of market that experts advocated: consistent, weekly questions about specific vaccine adoption numbers and COVID-19 case numbers. They averaged $8,000 per market, too low to be credible, and had several big misses. For example, "Germany COVID cases above 35K for week ending Dec. 28, 2021?" was trading at 3% a week before Omicron hit, and it was resolved as "Yes." And it seems no institutional consumer, like a hospital system or government disease tracking body, materialized to adopt the signal. Climate and natural disaster markets, where theoretical support is strong,6 tell the same story. The markets failed both to attract a supply of traders and the demand of response bodies or the public.

A second area where I see preliminary signs that a supply of good predictions could meet strong institutional and public demand is in the last of my five categories: generating novel information. There are some dozens of markets tracking AI, with $25 million in volume on questions that address which labs will have the top models on certain dates. It is not hard to imagine the people or organizations who would demand better information about emerging technologies.

However, if one examines these AI markets, it seems that they are too low-quality to be useful to anyone making a decision. I can't imagine that an individual who chooses a model provider, a firm that chooses a partner or supplier, or a policymaker who chooses an AI regulation would have much to learn from them.

It's clear that Polymarket and Kalshi host these markets to serve bettors, not to produce useful information. Take Kalshi's "Best AIs this week?" markets, which not only cover too short a time period to be useful in any decision-making, but also use Arena to judge the best AIs. Arena, which uses voting, not objective task scores, is not a credible measure according to AI experts. Still, demand for these markets does exist, and it's plausible that higher-quality markets could emerge in the future to satisfy it.

Where prediction markets are accurate but ignored

In three of the five categories of benefit from prediction markets — interpreting news, policy outcomes, and accountability — I see evidence that high-volume markets are producing accurate predictions, but not evidence that anyone is, or should be, paying attention.

First, how useful are markets for interpreting news? These are markets tracking larger outcomes like recessions or inflation that move in response to news, helping readers understand the impact of particular events. 

Volume appears healthy, with 1,647 markets and $1.25 billion in total trading volume. However, 85% of that volume is in US federal interest rate markets. The median trading volume of markets for interpreting news has actually decreased substantially, from a high of $49,000 in early 2025 to just $13,000 by the end of the year, much lower than the median volume of other markets I categorize as useful.

While predicting interest rates is valuable, CME futures, Bloomberg consensus, and professional economists already do it. The same is true for other indicators with high trading volume on Polymarket and Kalshi: inflation, unemployment, commodity prices, mortgage rates. Aaron Brown calls prediction markets "economic oracles," but the oracle is largely saying what other oracles already say, just updated faster. 

Still, there is a benefit to speed. On March 11, 2026, the Financial Times reported that, upon news of Iran War escalation, the Polymarket odds of inflation at or above 2.8% rose to above 90%. This illustrated an immediate domestic impact to US foreign policy, which could influence the public in a way that updates months later from professional economists might not. 

Next, how useful are markets for judging whether claims by governments and CEOs are credible? I found 184 accountability markets with $173 million in total trading volume. The number of such markets is growing, as is the median trading volume, with a median $44,200 in bets.

But two-thirds of the total volume is Epstein file speculation, the type of activity that Rohanifar et al. (2026) diagnoses as "prediction laundering." It's hard to see any decisions changing based on these markets. Most of the rest are about one other person, US President Donald Trump,7 which feel like a temporary artifact of a particularly entertaining leader with credibility issues in the popular consciousness.

Finally, how useful are markets tracking policy outcomes? I found 1,710 markets with $1.42 billion in total trading volume. But the vast majority of volume is on a very small number of highly visible markets: $288 million on the possibility of a U.S. government shutdown, $238 million on whether Judy Shelton would be nominated as Fed chair, $145 million on whether TikTok would be banned in the US.

The median volume of markets is increasing, growing in 2025 from $24,000 to $30,000. The section I find most valuable are the 196 markets with $144 million volume on tariff policies.8 These are actionable in many places around the economy, and I think the wisdom of the crowds is producing novel, useful, accurate information on what tariffs will take effect at what level.

Overall, the markets on all three of these categories are dominated by betting on the Trump administration's volatile policies. As Robin Hanson has commented, "A random unpredictable US president has been very good for the prediction market industry." This doesn't seem to me the vision that academics hoped for: experts wagering on current events, leading to pledges made from serious politicians or influencing the most important bills faced by legislatures worldwide. 

Markets driven by entertainment value and intrigue to bettors could plausibly deliver this, but I don't see much of it on Kalshi and Polymarket. The most charitable view is that these are growing pains, where the creation of a healthy information market is bootstrapped by gambling on Trump, and gradually evolves into the more professional betting environments on mature financial securities. Until then, though, I don't expect that people affected by policies will pay much attention.

We have another reason to doubt that the money changing hands across all of these markets is providing value. Metaculus, my former employer, has produced thousands of well-calibrated forecasts on global risks, health, and technology for over 10 years, with minimal institutional impact. Metaculus has even explored another item on the economists' wish list: "conditional markets" which ask "If policy X happens, what will outcome Y be?" Yet these also have not been adopted by information consumers, and there are serious technical barriers to adoption by predictors.

Still, the original vision for public benefit from prediction markets depends on them being highly liquid, and billions of dollars in liquidity can significantly change accuracy (or the perception thereof). Polymarket CEO Shane Coplan said Polymarket is "the most accurate thing we have as mankind right now", while Kalshi CEO Tarek Mansour advertises prediction markets as "quintessential truth machines". Let's look at whether trading volume leads to higher accuracy.

Whence volume comes accuracy

Coplan and Mansour did not invent prediction markets, but they are the first to create ones with billions of dollars of trading volume, so their claims of truth and accuracy depend on this feature. "On Kalshi, the goal is liquidity and accuracy," Mansour said in February, putting them hand-in-hand. 

So, when one of these new generations of markets with millions of dollars wagered implies a 70% likelihood, does the event it tracks actually occur close to 70% of the time, as theory would predict? 

The accuracy of a market is generally measured at a single point in time, but prediction markets have continually updated prices. For simplicity, I analyzed markets 7 days, 30 days, and 90 days before they settled. Markets also have bid/ask spreads, and the "probability" implied by the market is usually taken as the median between the price buyers and sellers are willing to trade. I then looked at two accuracy scores.9

Absolute accuracy is hard to compare across markets on one platform, and across platforms, because different forecasting questions have different difficulties. I addressed this by tracking similar markets on a single platform over time, where plausibly the only difference in accuracy would come from the change in volume of trading. Insufficient question overlap made it difficult to compare the real money markets to play-money or no-money markets like Manifold and Metaculus. What we can say is: even if highly liquid prediction markets are more accurate than previous forecasting methods, the liquid prediction market operators haven't demonstrated it. I find it unlikely that higher accuracy is a reason that people would prefer Kalshi and Polymarket to other forecasting methods.

I examined all markets on Kalshi and Polymarket from Jan 1, 2024 through March 8, 2026, and a sample of older markets on Kalshi for historical comparison. I filtered out categories I deemed as never useful.10 This filtered ~194,000 markets down to 13,500 markets. Then, I used FutureSearch tools to classify them into the five categories of potentially positive value, iterating on criteria until I was satisfied by the categorization. This led to a final set of 6,797 markets — 5,703 resolved and settled, and 1,094 still live and trading — that I see as potentially useful, if they were accurate and had the right audience.

Are markets with higher trade volume more accurate?

Yes, for markets that last 90 days or more, which is roughly a quarter of this sample. This holds for both useful and non-useful markets, and on both Polymarket and Kalshi.  

Strikingly, markets that last less than 90 days (as judged by accuracy 30 days before resolution, and 7 days before resolution) did not show a statistically significant relationship between trade volume and accuracy. I suspect that as these markets mature, volume will predict accuracy. One possible explanation is that the higher-volume markets are on more entertaining topics with less informed traders, and it takes time for experts to move in. Another is that high-volume markets actually don't have many traders, with a few people wagering thousands of dollars each. "Wisdom of the crowds" does require a crowd.

Are "useful" markets getting more volume over time?

Useful market volume grew until late 2024, but has not grown in volume since. Total and median volume of useful markets grew dramatically from 2023 to late 2024. They peaked at $534 million per month around the 2024 U.S. election ($81,000 median and $2.3 million average per market), and is today around $466 million / month ($42,000 median and $1 million average per market). Volume is dominated by a very small number of hugely popular markets, and the median "useful" market is actually declining in trading volume.

Are "useful" markets getting more accurate over time?

Useful market accuracy improved until early 2025, but hasn't improved since. 

This roughly follows the growth in volume, though accuracy improved after volume plateaued. (Market dates are shown by creation, not resolution, so volume that occurs months later is shown backdated to when the market was created.) And just as the median volume of useful markets has declined, so has accuracy (though not statistically significantly), which is now lower than it was in early 2025.

This reinforces the impression one gets from perusing both platforms. The huge growth in sports betting, crypto gambling, and entertainment markets is not consistently spilling over to "useful" markets, which are rare and neglected. It's possible that it will simply take more time for bettors on these "fun" markets to start betting on more useful ones. Google's 2005 prediction market was full of entertaining markets to encourage user adoption, and I did the same thing when I set up their current prediction market. We might see the same thing play out on Kalshi and Polymarket.

But while this is happening, another development is challenging the core premise that human incentives determine the supply of forecasts, and ultimately how people who demand this information discover and consume it.

You can't spell "futarchy" without "AI"

In January 2026, noted tech and rationality blogger Scott Alexander wrote:

There are now strong, minimally-regulated, high-volume prediction markets on important global events. In this column, I previously claimed this would revolutionize society. Has it? I don't feel revolutionized. Why not?

One way forward, he writes, is to create better prediction markets, perhaps by letting users on real-money platforms generate the questions themselves. (Currently, user-generated markets are only allowed on the play money site Manifold). "The second," he continues, "is to conclude that prediction markets' role in God's plan was only to provide the foundation for AI superforecasters." He then points out that the Forecasting Research Institute in October 2025 claimed that AIs might surpass the best human forecasters in late 2026.11 

Those of us who work on AI forecasting are sympathetic to this argument. My company, FutureSearch, was the first to deploy AIs in a (play money) prediction market in January 2024. Even using forecasting approaches powered by GPT-4 Turbo and Claude 2, LLMs that are now considered quite unintelligent, we outperformed most human traders. 

But I don't want to focus only on how AI forecasting might make prediction markets, or wisdom-of-the-crowds more generally, obsolete as a method of supplying forecasts. AI could also radically improve the way people access the forecasts they demand.

I claimed earlier that the value of risk monitoring markets mostly comes through the mainstream media reporting on these probabilities. If financiers, supply chain analysts, and policymakers see Polymarket probabilities in mainstream news, they don't need to check Polymarket (or even know what a prediction market is) to benefit from the information.

Likewise, a large number of individuals, firms, and policymakers get information from chatbots like ChatGPT, Claude, or Gemini. Chatbots are not (yet) trained to be accurate forecasters, but they already serve as a primary way that people get all five types of value from prediction markets, largely by making implicit forecasts:12

Risk monitoring: Ask ChatGPT about the biggest risks in your upcoming vacation or business plan.

Interpreting news: Ask Claude whether the new AI model release affects how work is being automated.

Policy outcomes: Ask Gemini to run a "Deep Research" report on whether the new tariffs will survive court challenges.

Accountability: Ask Grok whether Elon Musk will deliver on his most recent space flight promises.

Novel information: Any LLM can give you its best attempt to reason through any question you can imagine.

Try it yourself. Pick a topic that is important to you. Try searching Polymarket for probabilities, versus asking Claude about it. I wager you'll prefer Claude's take, even if it is less accurate. 

For one thing, Claude can speak to issues that are not properly resolvable forecasting questions. People who demand information on geopolitics and technology do want accurate probabilities, but they also want narratives, histories, and the ability to ask followup questions. Often, accurate information is a good starting point, but the bigger constraints to wiser actions are social and political. Prediction markets can't help you strategize how to act on a good forecast. Claude can.

No forecasting technology fixes the fact that neither humans nor institutions were built to think probabilistically. But chatbots are a much more credible method of changing how people think about their decisions, and the forecasts implicit in them. And if AI forecasting also side-steps every other issue in using prediction markets to supply forecasts, from insider trading to resolution scandals to lack of liquidity, then AI can bootstrap the entire two-sided information market.

That said, even when Claude can forecast more accurately than the entire set of Polymarket traders, prediction markets might still serve some of the epistemic purposes that Kenneth Arrow, Daniel Kahneman, and others laid out in 2007. 

By accelerating the adoption of probabilities by mainstream media, prediction markets help build common knowledge. It is conceivable that having large sums of money changing hands will make the markets increasingly newsworthy, and attract the attention of people who benefit from the predictions who would not have thought to ask Claude for advice on those topics. 

I think most decisions by individuals, organizations, and governments are built around norms and social consensus, and highly visible prediction markets could influence people more than private conversations with chatbots. This, to me, is the most likely path towards the realization of the value of prediction markets: large amounts of betting leads to more mainstream media coverage of prediction markets, normalizing their use in workplace discussions, and ultimately decision making processes.

Decades ago, the grand vision of producing high quality public information was about aggregation of wisdom. Now, Polymarket, Kalshi, and even Metaculus have shown us that the bottleneck is distribution of wisdom. The evidence suggests that billion-dollar prediction markets, despite both their founders calling them "truth machines", are overwhelmingly in service of their traders (and their desire to bet on sports), not the seekers of truth.

Might the prediction markets use their billion-dollar valuations to now build out Vitalik Buterin's vision for "info finance"? Maybe. But I forecast that before they do, Claude will be the only forecaster anyone will ever want to ask about the future.

1. Data for this article sourced on March 7, 2026 from the official Kalshi API (https://docs.kalshi.com/) and the official Polymarket API (https://docs.polymarket.com/).
2. Policy outcome markets could include those that predict election results. But while many people first learned about prediction markets from such markets during the 2016, 2020, and 2024 US presidential elections, and while the outcomes of elections do influence policy, I don't find such markets useful. First, polls and non-crowd-forecasts give good odds already, and second, it's hard to see who would do something differently based on whether the Democrats have, say, a 45% chance of winning the US Senate in 2026 vs a 41% chance.
3. Many markets that appear to produce novel information are in fact only making private information public. In 2026, OpenAI fired an employee for trading on prediction market platforms, and many other cases of such insider trading have been levied. Here, I am tracking the public production of genuinely new information. One sign that markets are producing new information is that they are long-term, like predicting the best new cancer drugs over the next 2 years. As I show later, even for questions I consider useful, most trading volume on Polymarket and Kalshi occurs on questions that resolve in less than 90 days, and for most short-term questions, the right insiders do probably have decisively better information.
4. Why do people need prediction markets when they have futures markets, e.g. tracking the escalation of Iran War tensions via implied future prices of oil? The answer is that commodity futures and stock derivatives are too blunt as informational instruments. Prediction markets enable direct measurement of individual risks, which can be used to inform much more direct responses, such as routing a shipment away from a conflict area.
5. Examples include: Reuters covering odds of China invading Taiwan (May 2025), Bloomberg covering Trump tariffs and the Supreme court (Oct 2025), the Wall Street Journal covering the odds of a ceasefire in the Iran War (March 2026) or the rapid fall of the Iranian regime (March 2026)
6. Cerf et al. (2023) found that participating in a prediction market on climate outcomes increases support for costly climate policies. Roulston et al. (2025) found that a prediction market more accurately forecast the 2024 Atlantic hurricane season than other methods.
7. Markets about which statements President Trump will follow through on do seem valuable to me, as market prices imply that some of his claims are more credible than others, such as the market tracking his June 2025 claims about strikes against Iran nuclear facilities. Perhaps future leaders will have such extreme accountability issues to warrant large betting markets about what they say.
8. For example, in May 2025, after Trump announced retaliatory "liberation day" tariffs of well over 100% against China, Polymarket hosted "US-China tariff agreement before 90-day deadline?" which had $500k in trading volume. The market fluctuated around 60-80% throughout June, July, and August until the agreement was reached shortly before the deadline, and ultimately tariffs were far below the original 145%. Uncertainty around where tariffs would land was widely cited as a major business risk throughout the global economy.
9. The simplest is Brier score, which tracks error between the implied probability (say, 0.35 for a 35% forecast) and what actually happens (say, 0 for "no"). I also looked at Weighted Mean Calibration Error, a measure of calibration error: if 100 markets say something is 70% likely, implying that 70 out of those 100 should happen, how many actually end up happening?
10. On Kalshi, I filtered out these categories: Sports, Crypto, Financials, Climate and Weather, Entertainment, and Mentions, plus keywords that identified markets in those categories that weren't categorized properly. On Polymarket, I filtered out these tags: Crypto Prices, Up or Down, Crypto, Sports, Esports, Games, Bitcoin, Ethereum, Solana, XRP, Ripple, Weather, Equities, Stocks, Commodities, Celebrities, Movies, Music, Grammys, Awards, Mentions, Tweet Markets, Twitter, YouTube, and Earnings. You may wonder why I filter out "financials", "equities", "stocks", and "earnings." Surely these could be useful categories to forecast? In theory, these could be useful, especially earnings forecasts in particular are surprisingly poorly covered by the sell-side investment community. But in practice, I find them formulaic, and I think they exist to let bettors debate the efficient market hypothesis.
11. 95% confidence interval: December 2025 – January 2028.
12. OpenAI finds that about 81% of work-related messages map to just two broad work activities: (1) obtaining, documenting, and interpreting information; and (2) making decisions, giving advice, solving problems, and thinking creatively. Forecasting is likely a significant portion of the latter category. After all, how can one give advice without implicitly forecasting the outcomes of following that advice?

A New Type of Neuroplasticity Rewires the Brain After a Single Experience

"Neurons that fire together, wire together" is not the full story. A novel mechanism explains how the brain can learn across longer timescales.

Introduction

Every experience we have changes our brain, the way a ceramicist reshapes a slab of clay. Every corner we turn, every conversation we have, every shudder we feel causes cascading effects: Chemicals are released, electricity surges, the connections between brain cells tighten, and our mental models update.

The brain is "incredibly plastic, and it stays that way throughout the lifespan of a human," said Christine Grienberger, a neuroscientist at Brandeis University. This plasticity, the quality of being easily reshaped, makes the brain really good at learning — a quintessential process that allows us to remember the plotline of a novel, navigate a new city, pick up a new language, and avoid touching a hot stove. But neuroscientists are still uncovering fundamental rules that describe how neuroplasticity reshapes brain connections.

Recently, neuroscientists described a new form of neuroplasticity that might be helping the brain learn across a timescale of several seconds — long enough to capture the behavioral process of learning from a single experience. In two recent reviews, published in The Journal of Neuroscience and Nature Neuroscience, they describe "behavioral timescale synaptic plasticity," or BTSP. This type of learning in the hippocampus, the brain's memory hub, is caused by an electrical change that affects multiple neurons at once and unfolds across several seconds. Researchers suspect that it may help the brain learn in a single attempt.

"It's pretty clear that [BTSP is] a strong, powerful mechanism that can lead to immediate memory formation," said Daniel Dombeck, a neuroscientist at Northwestern University who was not involved with the theory's development. "It's something that has been missing in the field for a long time."

By uncovering BTSP, neuroscientists have unraveled more of the story of how the brain changes with experience, bringing us closer to understanding how learning happens. "Neuroplasticity is … one of the last frontiers of the brain," said Attila Losonczy, a neuroscientist at the University of Texas Southwestern Medical Center who studies BTSP. "If we understand this, I think we take a major step towards understanding how the brain works."

A Plastic Brain

Today, neuroplasticity is taken as fact, but for much of the 150-year history of neuroscience, the adult brain was thought to be static. "The idea that the adult brain can change wasn't actually widely accepted until very late [in] the history of modern neuroscience," said Moheb Costandi, a trained neuroscientist and author of Neuroplasticity, a primer from MIT Press. "It was taken for granted that the adult human brain can't change." In 1928, Santiago Ramón y Cajal, the oft-cited founder of modern neuroscience, wrote that "in adult centers the nerve paths are something fixed, ended, immutable." This idea would prevail well into the middle of the 20th century.

We now know that the brain is constantly remolding itself, both functionally and structurally, across many scales — from the molecules that flow between neurons to the connections that stretch across the brain and beyond.

The power of neuroplasticity is perhaps best demonstrated by case studies. One patient born without an olfactory bulb could smell because other parts of her brain remolded to serve as substitutes. Another patient had the entire left side of her brain removed as a baby; after her right side reorganized to take on the left's former roles, today she has a functional life. When a stroke or an accident damages the brain, other neurons fill in to recover patients' everyday functions such as speaking and walking.

Neuroplasticity also drives everyday learning. This process is mainly thought to result from synaptic plasticity, or changes to the trillions of connections between neurons. And although the brain learns in various ways, one particular idea has dominated for more than 70 years.

In 1949, Donald Hebb, a Canadian psychologist, articulated a theory of learning now known as Hebbian plasticity. According to this model, when neurons are activated within milliseconds of each other, the connection between them is physically strengthened, so that in the future they are more likely to fire together. Over time, they form a network that represents a concept or an experience. In other words, the more the networks in the brain are used, the stronger they get, an idea often summarized as "neurons that fire together, wire together."

But neuroscientists "always had a sneaking suspicion that Hebbian plasticity wasn't quite right," said Jeffrey Magee, a neuroscientist at Baylor College of Medicine. Or at least, it wasn't the full story. It required an experience to be repeated multiple times to imprint the lesson on the brain — a framework that may explain how we learn a new city or language, but not how we learn from a single, highly charged experience, such as touching a hot stove.

Even so, finding more explanatory mechanisms hasn't been top of mind for neuroscientists. "It wasn't a quest, like in particle physics for missing particles," Losonczy said. Maybe there were a couple of gaps that needed to be filled, but most researchers assumed that the Hebbian framework would require only tweaks. Few were thinking that a fuller understanding of neuroplasticity might include a new mechanism.

Mighty Trees

In 2014, when Magee attached electrodes to rodents to record their neural activity, he wasn't looking to challenge Hebbian plasticity. Magee, then at the Howard Hughes Medical Institute's Janelia Research Campus, and his students Grienberger and Katie Bittner were looking to observe the behavior of neurons' arms, called dendrites, in a living animal.

These branches receive molecular signals at one end of a neuron and induce the cell to rapidly fire an electrical charge that ripples down the cell body, known as an action potential. This process ends with the neuron releasing its own batch of molecular signals, which latch onto the dendrites of the next neuron in the network, continuing the process.

In recent decades, neuroscientists have come to a "slow realization that dendritic activity is super important for plasticity and for neuronal computations in general," said Antoine Madar, a postdoc at the University of Chicago, who led the 2025 review of a Society for Neuroscience symposium on BTSP in The Journal of Neuroscience.

There is a "zoo" of different events that take place at dendrites, he said. They can fire their own local or global electrical spikes. They can cover a larger or smaller area, and they can surge for longer or shorter periods of time. Neuroscientists have found that these events at dendrites can allow even single neurons to perform complex computations — meaning that dendrites are the reason why a single neuron can have the same amount of computational power as a deep artificial neural network.

Still, there was much unknown about dendrites' behavior. Neuroscientists have mainly characterized them in brain slices, where neurons are alive and can be activated but aren't attached to a living animal. "We were trying to take that into the actual behaving animal, or the actual behaving brain," Magee said.

In 2014, they began to home in on the hippocampus, an especially plastic area of the brain where we form experiential memories. It's also home to place cells, which fire when an animal moves through its environment. Each of these neurons learns to fire at specific locations; later, if the rodent reenters that place, the cell will fire, recalling relevant information stored in the network.

As the rodents ran on a circular track, Magee and his team recorded what was happening in their hippocampal dendrites. That's when they observed something interesting.

Neuroscientists had long known that dendrites can sometimes stay active, with a slightly higher charge than when they're resting, for long periods of time without firing — creating what's known as a plateau potential. Because a plateau potential increases the odds that the neuron will fire, the activity was considered important to neuroplasticity. But while examining the rodent data, Bittner saw that place cells whose dendrites had produced just a single plateau potential began to fire.

In other words, a single burst of activity at the dendrite had tuned that cell to fire in that location. It was previously thought that encoding a place cell would take multiple action potentials, via Hebbian learning, which would require the animal to explore the same spot multiple times.

"So we were like, 'Wow, what's going on here?'" Magee said. When they experimentally triggered these plateaus, the cells fired in that location 99.5% of the time after a single dendritic plateau.

The researchers were elated. "We were kind of running back and forth between offices, like, you know, waving papers around — like, 'Look at this result,'" said Aaron Milstein, a neuroscientist at Rutgers University, who worked in Magee's lab at the time. It seemed that dendrites weren't just passively nudging a neuron to fire — they were causing the change themselves, strengthening the synapse in a single, swift step.

Magee and his team published their findings in 2015. At that point, they thought they had observed some weird subtype of Hebbian plasticity. But when they looked more closely at brain recordings of live animals plus brain slices, they recognized the biggest difference between the dendrites' activity and Hebbian plasticity: time.

In most studies of Hebbian plasticity, neurons can strengthen or weaken their connection if they are activated within milliseconds of each other. Dendrites' plateau potentials, on the other hand, persist for tens to hundreds of milliseconds (sometimes approaching one second), and through BTSP they can strengthen synapses active six to eight seconds before or after the plateau event.

"It became pretty obvious that this wasn't at all the standard kind of Hebbian plasticity," Magee said. "That made it even more interesting, of course, and a little bit intimidating, because then we were going to be facing up to nearly 100 years' worth of dogma."

It also addressed another big question that Hebbian plasticity had left open: how our cells can capture our relatively slow human behaviors.

"If you imagine even the simplest of the behavioral learning — for example, learning to stop at a red light signal, or to even explore and figure out what are the main parts in a particular room — it will take you at least a few seconds," said Anant Jain, a neurophysiologist at the Center for High Impact Neuroscience and Translational Applications in India. BTSP explains how the brain can encode behaviors in a single burst of brain activity that unfolds across several seconds.

Because this new mechanism seemed more behaviorally relevant than Hebbian learning, Magee named it "behavioral time scale synaptic plasticity" in a 2017 Science paper. "I'm not very good at naming things," he admitted. Then he waited for the response from fellow neuroscientists.

One-Shot Learning

Initially, BTSP received pushback within the field. There was good reason for that, Magee said, as it challenged the dogma of neuroplasticity that had dominated for decades. But over the past few years, other researchers have started to investigate it themselves.

This is "a very compelling model for single-shot learning," said Losonczy, who worked in Magee's lab prior to the discovery and now studies BTSP at his lab. Unlike the mechanisms that allow an animal to learn a new skill slowly, BTSP might help it to learn — after just a single exploration of its cage — that food exists in the northwest corner or that a shock exists to its south. "Sometimes you need to remember events you only have one chance to remember, [such as] where the predator is," Losonczy said. "Otherwise, you will be taken out of the genetic pool."

While it's a neat explanation, the exact mechanism remains elusive. "There are still so many unanswered questions, at least at the level of molecules," Jain said. However, neuroscientists are starting to get some hints.

Early findings suggest that certain experiences cause synapses, the gaps between neurons where dendrites extend, to be tagged with elusive biochemical signatures called eligibility traces. These tags stick around for several seconds and indicate that those neurons were recently active and therefore relevant to a particular experience. Then, in the next neuron, a dendritic plateau potential causes a widespread voltage change that spreads across the entire dendrite. This plateau triggers all the synapses with the eligibility trace to strengthen.

Some studies are starting to zoom in on the molecular process. In 2024, Jain and his team reported that dendritic plateaus might cause a cascade of biochemical signals to build up over several seconds and then activate one of the most important proteins for learning, known as CaMKII. This protein directly influences synaptic strength by physically increasing the surface area and the number of receptors on dendrites, allowing more neurotransmitters to bind there the next time the cell fires.

BTSP may also address an ongoing conundrum in neuroscience. Because it strengthens only relevant active neurons, as opposed to any active neuron, BTSP may help address the "credit assignment problem" — how the brain can tell which neurons should encode a given experience. Now, Magee and others are looking into the role that BTSP might play not only in learning but also in consolidating memories.

However, Dombeck is cautious about overreaching on BTSP's significance. It has been observed in limited circumstances: only in the hippocampus as an animal learns locations (although researchers have found some evidence for BTSP in the neocortex, where the brain's higher-order processes happen). In his lab, Dombeck has found that BTSP occurs in some hippocampal cells, but not in all of them.

Jain is not even convinced that BTSP should be categorized as a non-Hebbian type of learning. Hebbian learning is often vaguely defined, and Hebb himself was vague about the timescales upon which it works. "Donald never really specified that it has to happen within milliseconds," only that the neurons need to repeatedly fire together, he said. Only later did neuroscientists mechanistically refine it to include millisecond timescales, Jain said.

Most neuroscientists agree that BTSP doesn't replace Hebbian learning, but rather works alongside it. "Hebbian plasticity probably plays a huge role in development, in the initial wiring" of the brain, Grienberger suggested, while BTSP may be more important for forming episodic memories in adults.

There's still much unknown about BTSP, especially the mechanism, which Madar said is "quite speculative." However, he also acknowledged that before becoming the archetypal model for learning, "Hebbian plasticity was also a hypothesis." Our understanding of how the brain learns through endlessly changing is itself endlessly changing.

How we built the most performant DeepSeek V3.2, MiniMax-M2.5 and Qwen 3.5 397B on DigitalOcean Serverless Inference

Today at Deploy, we are announcing the general availability of DeepSeek V3.2, MiniMax-M2.5, and Qwen 3.5 397B on DigitalOcean Serverless Inference. On DeepSeek V3.2 and Qwen 3.5 397B, we deliver #1 output speed across all providers Artificial Analysis tested. On DeepSeek V3.2 specifically, that translates to 230 output tokens per second and sub-1-second Time-to-First-Token (TTFT) for 10,000 input tokens.

This post covers how we got there: the GPU-level work, the serving stack tuning, and the specific technical tradeoffs we made along the way.

Why fast inference matters

The focus in AI development has fundamentally shifted from the training of models to the efficiency of inference. This shift is driven by the proliferation of agentic workloads, copilots, and real-time systems that form the core of next-generation AI applications. For these applications, speed is no longer just a performance metric; it is the critical differentiator between an engaging product and one that users abandon. Specifically, low-latency inference is essential for a seamless end-user experience. For highly interactive applications like conversational agents and voice interfaces, any delay beyond a sub-1-second TTFT is perceived as sluggish.

The importance of fast inference is compounded by the complexity of modern AI workflows. An agentic task, for instance, often involves dozens of sequential model calls, where even minute Time-Per-Output-Token (TPOT) delays can accumulate into several seconds of user-visible latency. Quick inference also helps businesses by providing reliable performance and lower costs. Optimization in this area, such as that provided by DigitalOcean's inference engine, allows enterprises to achieve superior token economics, sustained throughput, and predictable latency, which are essential for scaling their AI-native applications reliably and affordably.

Leading the Artificial Analysis benchmarks on speed

The benchmarks we're publishing today reflect this. On DeepSeek V3.2 with 10K input tokens, we deliver:

• Output speed: 230 tok/s (3.9x AWS Bedrock at 59 tok/s)
• TTFT: 0.96s (only Google Vertex is faster among 12 providers tested)
• Balanced performance across latency and output speed: DigitalOcean is one of only three providers to be ranked in the most favorable quadrant on the Artificial Analysis Latency vs. Output Speed chart.

Similar performance numbers for MiniMax-M2.5 and Qwen3.5 397B:

The engineering behind the numbers

Achieving this level of performance required more than just cutting-edge GPUs. Standard configurations on latest-generation hardware often fail to reach the top of the Artificial Analysis leaderboard. To achieve these results, we co-designed and optimized every layer of the stack: selecting premium GPUs, maximizing CUDA efficiency on virtualized NVIDIA Blackwell Ultra GPUs, implementing speculative decoding, and applying quantization where it offered the best balance of speed and accuracy.

Hardware: The Power of NVIDIA Blackwell Ultra

The foundation of our performance breakthrough is the NVIDIA HGX™ B300 GPU. The Blackwell Ultra architecture provides a massive leap forward, featuring 288GB of HBM3e capacity—a 50% increase over the B200—alongside 1.5x greater NVFP4 compute power. This hardware foundation was essential for handling the massive throughput requirements of DeepSeek and Qwen at scale. While early deployment in virtualized environments initially resulted in a 25% performance hit, our direct collaboration with NVIDIA enabled us to resolve these issues, unlocking the full potential of the Blackwell silicon.

Model Quantization: Efficiency of NVFP4

We used the NVFP4-quantized version of the models, which uses a specialized 4-bit floating-point format to significantly reduce the memory footprint (~1.8x compared to FP8) and increase inference throughput. These benefits are uniquely leveraged by the NVIDIA Blackwell Ultra architecture, which features 1.5x greater dedicated NVFP4 compute power, allowing for massive performance gains with minimal impact on model accuracy. Refer to the model evaluation for DeepSeek V3.2 to see NVFP4 accuracy against original FP8 model weights.

However, raw silicon and quantization are only half the story. To translate that hardware power into world-class inference speeds, we had to implement a highly customized software stack.

Inference Engine: Performance optimizations of vLLM

We optimized the open source vLLM serving framework with a series of techniques:

• Tensor Parallelism: We used tensor parallelism for distributing the large model layers across multiple GPUs, a necessary technique for running models that exceed the memory capacity of a single GPU, which requires high-speed GPU interconnects. Based on the model size, we used either TP4 or TP8 configurations to run inference across 4 or 8 GPUs.
• Kernel Fusion: This key optimization fuses multiple operations into a single GPU kernel, which minimizes the overhead of individual kernel launches and reduces CPU gapping. By executing these merged operations on-chip, kernel fusion significantly cuts down on slower off-chip memory accesses, leading to much faster processing.
• Programmatic Dependent Launch: We used Programmatic Dependent Launch to overlap kernels wherever possible, which hides kernel launch overhead and mitigates tail effects in short-running kernels. This improves performance for low-batch-size, low-concurrency, high-interactivity workloads by ~10%.
• Speculative Decoding and Multi-Token Prediction (MTP): We leveraged the latest model features like Multi-Token Prediction (MTP) for DeepSeek to accelerate token generation, improving the Time-Per-Output-Token (TPOT). MTP was used as part of Speculative Decoding optimization to boost generation speeds. This technique uses a smaller draft model (MTP heads or EAGLE heads) to predict token sequences that the larger target model validates in a single forward pass, significantly increasing throughput while maintaining the high quality of the primary model's output. For MiniMax-M2.5, we trained an EAGLE3 draft model using TorchSpec — a torch-native online speculative-decoding training framework that runs FSDP training and vLLM-based target inference concurrently, learning from MiniMax-M2.5-regenerated responses and live vLLM-generated hidden states to match the base model's exact token distribution. For deployment, our experiments showed that reducing tensor parallelism for the draft model improves performance by minimizing inter-GPU communication overhead. For MiniMax-M2.5, Time-Per-Output-Token (TPOT) improved by 23% by setting "draft_tensor_parallel_size": 1 in our setup.

Kernel fusion and draft model training were completed in close collaboration with Inferact, the original creators of the leading inference serving engine vLLM, whose expertise was instrumental in optimizing these complex workloads for specific GPU and model versions.

Real world performance

The same techniques are already running in production for customers serving inference at scale. Workato, which processes over 1 trillion automated workloads to extend its production automation with agentic AI, is running on DigitalOcean's inference platform with 77% faster Time-To-First-Token, 79% lower end-to-end latency, and 67% lower inference costs.

"Before DigitalOcean, we didn't have a dedicated solution for multi-node serving, which slowed our AI progress. DigitalOcean got us up and running quickly, and through close collaboration on performance optimization, helped us accelerate our inference performance and overall progress by two to three times." — Oscar Wu, AI Research Scientist & Technical Lead, Workato

The path forward: Scaling intelligence

Our commitment to performance doesn't stop here. We are expanding our catalog of optimized models tailored to evolving customer demand. As we move toward the next frontier of inference, we are building the infrastructure for multi-node serving with disaggregated configurations and Wide Expert Parallelism capabilities to handle the world's most demanding agentic workloads. With hardware and software co-design, we're focused on continuing to deliver the performance AI-native enteprises need to scale.

Try DeepSeek V3.2, MiniMax-M2.5, or Qwen 3.5 397B on DigitalOcean Serverless Inference today.

Full benchmark methodology and results are available at Artificial Analysis.

Kubernetes v1.36 promoted to beta the ability to modify CPU, memory, GPU, and other resource requests in suspended Jobs' pod templates, eliminating the need to delete and recreate Jobs when resource requirements change. The feature, enabled by default, lets queue controllers and administrators adjust resources before Jobs start running. It is particularly useful for batch and machine learning workloads where optimal allocation depends on current cluster conditions.

GitHub says recent outages were caused by rapid growth in AI-driven development, which has pushed the platform beyond its current scaling limits. The company is prioritizing reliability by expanding capacity, isolating critical systems, and reducing single points of failure to handle the surge.

The Autonomy Problem: Why AI Agents Demand a New Security Playbook

AI agents are transforming software development. They can autonomously read codebases, write and edit files, run tests, and fix bugs, all from a single prompt, and engineers no longer need to author those prompts manually. Soon, agents will manage everything from booking business travel to processing procurement requests, using your credentials to get it done.

The capability is significant, and so is the responsibility it carries. Agentic AI introduces distinct risks that software companies urgently need to address. The Center for AI Standards and Innovation, an arm of the National Institute of Standards and Technology (NIST), has become sufficiently concerned about agentic AI risks to begin studying how to track the development and deployment of these tools.

"AI agent systems are capable of taking autonomous actions that impact real-world systems or environments, and may be susceptible to hijacking, backdoor attacks, and other exploits," NIST notes in a document on the topic. "If left unchecked, these security risks may impact public safety, undermine consumer confidence, and curb adoption of the latest AI innovations."

Agentic AI expands and reshapes the attack surface, including agent-to-agent interactions that traditional security models were never built to detect. Agents can also chain low-severity vulnerabilities into high-severity exploits.

Security teams are already grappling with these risks, or should be. Engineering leaders eager to adopt agents should understand not only what agents can do, but what agentic capabilities mean for their organization's security posture.

Closing the gap between engineering and security teams starts with understanding AI's risks, and it enables teams to ship faster and more securely.

Why Agents Change the Threat Model

The nature of large language models creates a variety of security challenges, some entirely new, others variations on long-standing issues.

AI agents share some risks with other software, such as exploitable vulnerabilities in authentication systems or memory management. But NIST focuses on the novel, more dynamic dangers posed by machine learning models and AI agents.

Prompt-injection attacks represent one of the biggest risks of AI, and the non-deterministic nature of LLMs makes them especially difficult to defend against. The same prompt-injection attack may succeed in one attempt and fail in another, making remediation difficult to validate and comprehensive defenses challenging to implement.

Models with intentionally installed backdoors pose a particular risk, leaving critical systems exposed. Even uncompromised models could threaten the confidentiality, integrity, or availability of critical data sets.

Another challenge comes from how capabilities combine within a single agent. AI agents merge language-model reasoning with tool access, enabling them to read files, query databases, call APIs, execute code, and interact with external services. The risks stem not from any single capability but from their combination and an agent's ability to act on these capabilities autonomously. Without proper guardrails, agents can delete codebases, expose sensitive data, and trigger cascading failures that are costly and difficult to unwind. In some cases, agents can work around guardrails to complete their assigned tasks.

Agents face heightened risk when they have access to private data, encounter untrusted content, and can communicate externally. This combination presents a materially different risk profile than one lacking any of these three elements. Security researchers have described this combination as the "lethal trifecta."

Additional risks include:

• Unintended operations, where agents execute actions beyond their intended scope due to misinterpreted instructions or prompt manipulation.
• Privilege escalation, which occurs when agents operating with broad permissions perform sensitive operations that exceed what the initiating user authorized.
• Cascading failures, where one compromised agent in a multi-agent system can corrupt others downstream.

How to Engineer Against These Risks

All of these risks have concrete countermeasures. The most effective approaches layer controls at three levels.

• Model level: Maintain clear separation between system instructions and untrusted content using distinct messaging roles and randomized delimiters. Secondary classifiers add an additional layer, scanning inputs and outputs for injection patterns and anomalous formatting. These are risk-reduction measures rather than complete solutions, which is precisely why the layers below matter.
• System level: Apply least privilege across the board. Agents should only access the tools required for their tasks, with credentials narrowly scoped and set to expire quickly. Screen content entering the system for injection patterns, and check outbound content for sensitive information such as credentials or PII. Enforce default-deny network controls, limiting external communication to explicitly approved endpoints. Structure workflows to break the lethal trifecta: separating read-only and write-capable agents ensures no single agent can access sensitive data, process untrusted content, and communicate externally all at once.
• Human oversight level: Require explicit approval for critical operations while allowing lower-risk actions to proceed with notification. A tiered approach prevents approval fatigue, which can lead to oversight. Users should be able to halt execution at any time, with rollback of partially completed work where possible. When an agent acts on behalf of a user, record both identities and evaluate permissions at their intersection. Log all agent actions, timestamps, identifiers, tools invoked, resources accessed, and outcomes in sufficient detail to reconstruct events after the fact.

Governance as a Competitive Advantage

Teams can meaningfully reduce these risks through layered controls. The risks are real, but so is the opportunity, and treating one as a reason to avoid the other misses the point.

When agents work for you rather than against you, the same combination of data access, content processing, and external communication that creates risk becomes the source of value. AI agents can monitor systems, apply consistent security rules without fatigue, and build quality, secure code at a speed and scale no manual process can match. They amplify both your strengths and your weaknesses, making governance the deciding factor.

Software engineers will always be necessary, but organizations that deploy agents with proper governance and guardrails will outpace those that don't: they will move faster, remediate problems sooner, and introduce fewer security errors that degrade software quality.

The organizations that get the most from agentic AI will be those that understand the threat model clearly and build against it from the start. That foundation separates teams that deploy agents responsibly from those that learn the hard way.

How it feels to run an incident with AI SRE

We've been building the broader incident.io platform for several years now, and one thing we've learned is that UX matters more here than almost anywhere else. When an incident fires, there's no room for poorly designed interfaces or fumbling through features you haven't touched in a while.

The product has to be ergonomic: easy to pick up, easy to navigate, with the right things at your fingertips at exactly the right moment. We've put a lot of effort into this over the last 5 years.

For the last 18 months, we've been building AI SRE. The brain behind it, which you can think of as an investigation engine and intelligence layer, has come a long way.

Despite this, we've been struggling to get the UX to click in a way that feels as natural as the rest of the product. An agent that does impressive things behind the scenes doesn't count for much if the experience of using it feels jarring and easy to move past, both of which are things we've felt as we've been building it.

This week, I used AI SRE to run a real incident, and I think we're right on the edge of nailing the whole flow. I'm going to use this post to walk you through it end-to-end.

The actual incident

To set the scene, I was testing a new feature we've just built: delay nodes in escalation paths. It's not critical to this story, but it lets you add custom delays into on-call escalations, for example holding low severity pages overnight and delivering them first thing in the morning.

The delay node feature had just shipped and was only enabled on demo accounts, so a few rough edges were expected. Midway through testing, I clicked into the escalation details page, and the whole page crashed. Just an error screen with nothing illuminating in the console or network tab of Arc.

As is pretty routine for us at incident.io, I reported this as an incident to investigate.

AI SRE gets to work investigating

To set some context: as soon as an incident is declared, our AI SRE agent kicks in and starts investigating the issue on your behalf.

In practice, this means things like:

• Looking at recent deploys
• Digging into telemetry and errors
• Searching through past incidents
• Investigating the code, looking for any smoking guns
• Checking whether there's any other context in Slack

All the kinds of things a human would do if they were responding to an incident themselves, but much faster and in parallel.

From Slack to desktop

Whilst the investigation was ongoing, I was nudged in Slack to "pin" the incident in the incident.io macOS desktop app.

We've recently shipped this new product surface (it's beautiful!), and pinning an incident turns the notch on your Mac into a live and interactive view of the incident, and an easy way to jump straight into Claude, Cursor, or your agentic coding platform of choice.

Jumping into Claude Code

From there, I jumped into Claude Code with the /incident INC-19672 command, connecting my Claude Code session directly back into the incident, and synchronizing all of the investigation from AI SRE's investigation into the context.

By the time I'd done that, the first pass of the investigation was complete, and had narrowed down the cause to a frontend rendering crash: a map returning undefined for a type the frontend didn't recognize. It even identified a recurring pattern from previous incidents where one side introduces a type that the other side doesn't handle – we're now looking into this!

What's notable here is that I didn't have to dig through logs, check Grafana, or read through code; the investigation from AI SRE did that for me. I also have zero familiarity with this part of the platform, but I had enough info at this point to verify the conclusion as plausible and proceed to work with Claude.

Letting Claude cook

Despite the investigation looking good, there's no need to blindly trust it. The Claude/AI SRE combo got to work, validating it against the codebase.

You can see here that it checked the OpenAPI spec and found the problem. I daren't think how much time it would have taken me to get to the same point, but here it took a few minutes.

A subtle but important point in this flow is that it lets responders and Claude move ahead and investigate independently, exploring while AI SRE continues in parallel behind the scenes. That means there's no waiting around; as new intel comes in, we automatically connect the dots, keeping both agents aligned on the state of the investigation.

The fix, ready to ship

With the root cause nailed down, Claude proposed the fix: gracefully skipping rendering an item instead of crashing the whole page.

"Want me to commit this and open a PR?"

Yes. Yes, I do.

PR opened and channel updated, without leaving my terminal

This is where the experience felt like it really clicked. Claude opened the PR, then used the incident.io MCP to post an update into the incident channel, including what was found, what the fix is, and a link to the PR.

Most notably, I didn't have to switch to Slack to type an update. I didn't open GitHub to create the PR. I didn't go back to incident.io to change the status. All of it happened from the same place I was writing the fix.

It's worth calling out that everything you do in Claude and post back to the channel gets reverified by AI SRE. If you've made a mistake or forgotten something, it'll nudge you about it, but it'll also update its understanding and ensure anyone in the channel knows what you did and where we landed.

Meanwhile, the incident.io desktop app is sitting there on my Mac, pinging me with updates as things progress. So I'm always plugged into the latest context without having to go looking for it.

Verified and resolved

At this stage, it was all smooth sailing. The PR was merged, the deploy went out, and an engineer checking in on things shot me message to re-test.

A singular, portable context for every incident

Wrapping up an incident has become pretty delightful on incident.io, too. Simply ask us to do it, and we'll incorporate all of the context from what's happened in Slack, any conversations that have happened on Zoom or Google Meet, and now all of the context of what's happened whilst you were coding up a fix too.

The job of closing out and providing a final update is as simple as a one-liner to ask @incident to take care of it.

Finally, while I wouldn't normally spend much time debriefing an incident like this, a nice side effect of AI SRE is that all the context can be turned into a write-up for others to review.

What you see here is entirely AI-generated, and it's a much more accessible way for anyone revisiting this incident to understand what happened.

A better flow for resolving technical incidents

I've responded to hundreds of incidents over the years, and the friction has always been the same: too many tools, too much context switching, too much time spent just figuring out what's going on before you can start fixing it.

I think we're really close to fundamentally changing this.

The whole process here, from incident declaration to resolution, took minutes. And most of that was waiting for the deploy.

We've still got a little way to go (which is why we haven't fully launched yet!), but I have incredibly high conviction that this isn't just a small improvement, but a markedly better way to run incidents.

And seeing how far we've come on the user experience side validates our decision to build something that genuinely fits into an engineer's workflow, and not rushing it out the door.

Incidents are tough enough as it is, so it's better to be right than first.

GitHub mitigates circular deployment dependencies, where outages could block their own recovery, by using eBPF to monitor and restrict deployment scripts' network access and detect hidden, direct, and transient dependencies. This enables per-process control, DNS interception, and real-time auditing of risky calls like GitHub API usage during incident recovery.

This post demonstrates how to build a scalable, multi-cluster Kubernetes platform on OpenStack using k0s, k0rdent, and Hosted Control Planes (HCP), which eliminates the need for dedicated 3-node control planes per cluster by centralizing them in a single management cluster. The architecture shifts from managing individual clusters to operating a declarative system that handles provisioning, scaling, and upgrades across entire fleets while significantly reducing infrastructure costs and operational complexity.

Cloud-native security must adapt to diverse deployment constraints rather than enforce SaaS models, and Sysdig Secure delivers consistent runtime detection across private cloud, on-premises, and air-gapped environments with flexible, locally controlled implementations.

Mitchell Hashimoto, cofounder of HashiCorp, has announced that he is moving the Ghostty project off GitHub after 18 years of deep personal and professional attachment, citing growing frustration and disappointment with the platform.

Cloud cost optimization is a continuous, strategic practice of aligning usage with business value, made more critical by unpredictable, resource-intensive AI workloads that require strong visibility, governance, and iterative management.

Snapchat announced on Tuesday that it's rolling out "AI Sponsored Snaps," which will allow users to interact directly with brands' AI agents. Sponsored Snaps are the ads placed directly into the app's main Chat tab. Until now, users couldn't interact with these ads, but with the launch of AI Sponsored Ads, they'll be able to do things like ask questions and get recommendations.

Of course, not everyone will be on board with AI-sponsored ads, as they introduce AI into yet another part of the Snapchat experience. Plus, not everyone is eager for more advanced advertising.

However, Snapchat said in the blog post that its "community isn't just open to AI in conversation, they're already embracing it," given that over half a billion users have messaged its AI chatbot since it launched in 2023.

"Conversation is becoming the most valuable real estate in advertising," said Ajit Mohan, chief business officer at Snap, in the blog post. "AI is accelerating that shift, turning chat into the place where people discover products, ask questions, and make decisions in real time. The real opportunity isn't just putting ads into those environments, it's designing formats that feel native to how people already talk."

For brands, the new AI Sponsored Snaps give them access to Snapchat's nearly one billion monthly active users. They can bring their own AI agents onto the platform to drive engagement and purchases.

Snapchat says the new format builds on the momentum of Sponsored Snaps, which already drive 22% more conversions with nearly 20% lower cost per action. With the new format, they can engage users through personalized, AI-powered interactions right where they're already having conversations.

The company says 85% of users engage regularly in the Chat feed, and that users sent over 950 billion chats in Q1 2026 alone. Additionally, 57% of teen Snapchat users message others daily, including four in 10 who do so several times a day.

Under new leadership, Xbox is redefining its strategy around being "affordable, personal, and open," targeting daily active players as its north star and expanding across console, PC, mobile, and cloud. CEO Asha Sharma and Xbox Game Studios head Matt Booty have acknowledged failures in areas like pricing, PC presence, and core platform features, while flagging rising development costs and indie competition as growing challenges. Exclusivity, windowing, and AI are also under review. The Microsoft Gaming brand is being retired in favor of the Xbox name.

Apple's recent crackdown on vibe-coding apps hasn't held up Lovable's launch of its no-code AI app builder, which is now available as a mobile app on Apple's and Google's app stores.

The vibe-coding startup's new mobile app is being pitched to would-be app builders as a way to code on the go via voice or text AI prompts that let you capture your ideas as they pop into your head. That means you can kick off Lovable to work on your random app idea from anywhere, letting its agent run autonomously after receiving your input.

The new app will also allow you to switch back and forth between your computer and phone to pick up where you left off on a given project and receive notifications when a build is ready for review.

The app's arrival comes shortly after Apple addressed what vibe-coding apps can and can't do on its App Store. The tech giant recently blocked updates to popular vibe-coding tools, including Replit and Vibecode, for violations of its developer guidelines.

Simply put, Apple wasn't banning vibe-coding apps themselves, but it won't allow apps that download new code or change their functionality, as that presents a security risk to end users. (It also means that Apple's App Review team can't properly vet the app during the approval process.)

Apple also temporarily removed the vibe-coding app Anything from the App Store for similar reasons, but the app returned after making changes earlier this month.

To comply with Apple's rules, the vibe-coding apps are no longer able to run their generated apps inside the host app. Instead, those app previews were moved to web browsers.

Lovable has also seemingly complied with these rules as its new app touts the ability to turn ideas into "working websites or web apps."

Apple's UX strategy isn't just aesthetic minimalism — it's a behavioral system built around five interlocking principles (usability, communication, functionality, aesthetics, and emotional design) that together eliminate friction and guide users toward confident decisions. Product pages function as structured narratives, distributing cognitive effort progressively so that, by the time users reach a call to action, purchasing feels like a natural conclusion rather than a deliberate choice. This approach is credited with driving conversion rates of 5–10%, well above the typical e-commerce average of 2–3%.

Your design system represents years of decisions. Hundreds of components. Documented props, variants, states, tokens, and usage guidelines. It's the engineering artifact that keeps your product consistent across dozens of teams and hundreds of screens.

Then someone on your team tries an AI design tool. In thirty seconds, it generates a beautiful dashboard. Everyone's impressed. Then someone looks closely.

The buttons don't match. The spacing is off. The card component uses a shadow your system deprecated six months ago. The typography is close but not right. The loading state doesn't exist. The entire layout needs to be rebuilt using your actual components before a developer can touch it.

The AI was fast. The cleanup is slow. And the net result is more work, not less.

This is the pattern playing out across every AI design tool that doesn't connect to your component library. The generation is impressive. The aftermath is expensive.

What happens when AI ignores your design system

The problems show up in layers. The first layer is visible immediately. The deeper layers compound over weeks.

Layer 1: Visual drift

The AI generates something that looks approximately right. The colours are close. The spacing is similar. The components resemble yours. But "close" isn't correct, and "resembles" isn't compliant.

Designers who tested Claude Design this week reported wrong fonts, incorrect button colours, and inconsistent spacing within their first few sessions. One spent more time correcting the AI's interpretation of their design system than it would have taken to build from scratch.

This isn't a quality problem. It's an architecture problem. When the AI reads your codebase and generates new elements styled to match, it's approximating. Approximation drifts. The more complex your design system, the faster it drifts.

Layer 2: Component debt

Every time the AI generates a component that looks like yours but isn't yours, it creates component debt. That generated button doesn't have your loading state. That card doesn't support your elevation tokens. That input doesn't handle your validation patterns.

A developer receiving this output has two options: rebuild everything using the real components (negating the AI's speed advantage), or ship the approximation and deal with inconsistency in production. Neither is good.

Teams with mature design systems have spent years eliminating this kind of debt. An AI tool that reintroduces it in thirty seconds is moving backwards, not forwards.

Layer 3: Governance erosion

Design systems work because they create constraints. Designers can't use a component that doesn't exist in the library. They can't invent a new button variant without going through the contribution process. The system enforces consistency through structure, not willpower.

AI tools that generate outside the system bypass this entirely. The output looks professional. It seems on-brand. But it wasn't built with your components, wasn't reviewed against your guidelines, and doesn't follow your contribution process. It's off-system work that looks on-brand – which is actually worse than off-system work that looks obviously wrong, because it's harder to catch.

The most dangerous design system violation isn't the one that looks wrong. It's the one that looks right but isn't built with your components.

Why this keeps happening

The root cause is simple: most AI design tools don't have a connection to your component library. They generate to their own conventions because they have no other option.

Tools that generate pixels

Figma, Sketch, and their AI features generate visual shapes on a vector canvas. The output references your component library visually but isn't structurally connected to it. A designer can go off-brand because nothing physically prevents it. When AI is added to this model, it generates more pixels faster. The drift doesn't get solved – it gets accelerated.

Tools that generate their own code

Lovable, Bolt, and v0 generate working code, but it's their code – their component conventions, their styling approach, their opinions about how a button should work. For greenfield projects, this is fine. For teams with an existing design system, the output ignores everything you've built.

Tools that approximate from your codebase

Claude Design takes a different approach: it reads your codebase and extracts visual patterns. This is closer to the right idea, but it's still approximation. The AI interprets your code and generates new elements styled to match. It doesn't place your actual components with their real props and states. The gap between "styled to match" and "actually is" shows up as drift.

All three approaches share the same fundamental problem: the AI doesn't know what your design system is. It either ignores it, mimics it, or approximates it. None of these is the same as using it.

What "using your design system" actually means

For an AI design tool to genuinely use your design system, three things need to be true:

1. Direct connection to your component library

   The AI needs access to your actual components synced from Git or Storybook, not uploaded as a file or read from a codebase. The difference matters: a synced library updates automatically when your components change. An uploaded file becomes stale the moment someone pushes a code update.

2. Constrained generation

   The AI should only be able to place components that exist in your library. Not generate new ones styled to match. Not create approximations. Your actual components with their real props, real variants, and real states.

   This means the AI can't hallucinate a component that doesn't exist in your system. It can't use the wrong button variant because only the variants you've defined are available. Off-brand output isn't prevented by guidelines; it's prevented by architecture.

3. Production-ready output

   The exported code should reference your actual component library. Not generic HTML. Not the tool's own component structure. Your imports, your component names, your prop values.

   Here's what that looks like in practice – real export output from UXPin:

   import Button from '@mui/material/Button';
   import Card from '@mui/material/Card';
   import TextField from '@mui/material/TextField';
   import Typography from '@mui/material/Typography';
   
   <Card >
     <CardContent>
       <Typography variant="h5">Create Account</Typography>
       <TextField label="Full Name" variant="outlined" fullWidth />
       <TextField label="Email Address" type="email" fullWidth />
       <Button variant="contained" fullWidth>Sign Up</Button>
     </CardContent>
   </Card>

   Real MUI imports. Real props. Working state management. A developer copies this and integrates it directly. Nothing to interpret, nothing to rebuild.

Reading a codebase gives you visuals that look like your product. Syncing a component library gives you the real thing.

The hidden cost: prompt lock-in

There's a second problem with AI design tools that ignore your design system, and it compounds the first: prompt lock-in.

When the AI is the only way to interact with the generated output, every adjustment – spacing, colours, layout; requires another prompt. Another round-trip to the AI model. Another credit consumed.

Designers who tested Claude Design this week reported burning through weekly token limits in 2–6 hours. The community developed a mitigation strategy: use the most expensive model for the first prompt, then switch to cheaper models for edits. That this strategy is necessary tells you something about the cost model.

Adjusting spacing shouldn't require an LLM. Tweaking a prop value shouldn't cost credits. Exploring a variant shouldn't burn through a weekly allocation. These are design tool tasks, not AI tasks.

The alternative is separating AI generation from manual refinement. Let the AI handle the scaffold – the initial layout, the component placement, the structural heavy lifting. Then give designers real design tools for the last mile. Same canvas, same components. No tokens burned on the work that requires human judgment.

AI should launch the creative process, not meter it.

What to ask when evaluating AI design tools

If your team has a design system and you're evaluating AI design tools, these questions separate the tools that will help from the tools that will create cleanup work:

• Does the AI connect to my component library directly? Via Git, Storybook, or a direct integration – not a file upload that becomes stale.
• Is the AI constrained to my components? Can it only use what exists in my library, or can it generate new components that approximate mine?
• What does the export look like? Does it reference my component imports, or does it generate its own code that a developer has to rebuild?
• Do manual edits require AI credits? Can I adjust spacing, props, and layout with design tools, or does every interaction route through the model?
• Does the design system sync automatically? When developers update components in the codebase, does the design tool reflect those changes without manual re-syncing?
• Can the AI go off-brand? If I prompt for something that doesn't exist in my system, does it invent a component or tell me the component doesn't exist?

The last question is the most telling. An AI that invents components when your library doesn't have one is generating to its own conventions. An AI that surfaces the gap is respecting your system.

The teams this matters most for

Not every team needs their AI design tool to connect to a production component library. For founders building MVPs, marketers creating landing pages, and PMs mocking up feature concepts, speed and visual quality matter more than component accuracy.

But for enterprise teams with mature design systems, the calculus is different:

• If your design system has 100+ components with documented props, variants, and states – an AI that ignores them creates component debt faster than it creates value.
• If you have governance requirements that mandate compliance with your component library – an AI that generates outside the system is a compliance risk, not a productivity tool.
• If your engineering team spends significant time rebuilding designs from specs and mockups – an AI that generates more specs and mockups faster doesn't solve the underlying problem.
• If you measure design system adoption as a KPI – an AI that generates off-system work while looking on-brand makes your adoption metrics unreliable.

For these teams, the question isn't whether AI design tools are useful. They clearly are. The question is whether the AI is working with your design system or around it.

The more you've invested in your design system, the more an AI tool that ignores it costs you. And the more an AI tool that uses it saves you.

Frequently asked questions

Why do AI design tools ignore design systems?

Most AI design tools generate to their own conventions because they lack a direct connection to your component library. They either generate pixels (like Figma's AI), generate their own code (like Lovable and Bolt), or approximate your visual patterns by reading your codebase (like Claude Design). None of these approaches use your actual production components.

What is design system drift in AI design tools?

Design system drift occurs when AI-generated output deviates from your established component library. This includes wrong fonts, incorrect colours, inconsistent spacing, missing component variants, and generated components that don't match your prop conventions. Drift happens because the AI is approximating your system rather than being constrained to it.

How can AI design tools respect an existing design system?

The AI must have a direct connection to your component library, typically through Git integration. When the AI can only place components that exist in your synced library, with their real props, variants, and states, off-brand output becomes structurally impossible rather than something you hope to avoid.

What is the difference between approximating and using a design system?

Approximating means the AI reads your codebase or uploaded files and generates new elements styled to match your visual patterns. Using means the AI places your actual production components with their real props, variants, and states. Approximation drifts over time. Constraint does not.

What is prompt lock-in in AI design tools?

Prompt lock-in occurs when the AI model is the only way to interact with your design. Every adjustment, including manual tweaks like spacing and colour changes, requires a round-trip to the AI and consumes credits. This makes refinement expensive and unpredictable, and removes the direct manipulation designers rely on.

Design isn't about producing outputs but about deeply understanding a problem and achieving a good fit between form and context. Tools (including AI) can generate results quickly, but they don't replace the thinking required to resolve underlying complexities. Overreliance on AI risks creating polished yet fragile products, because real design value comes from the slow, iterative process that clarifies understanding—not just the final output.

Transform your imagination into studio-grade visuals. Input any image and see it refracted through Doodles lens in seconds.

TUIStudio is a Figma-like visual editor for designing terminal user interfaces (TUIs) with drag-and-drop components and real-time ANSI preview.

A Claude-powered Figma plugin built around an agent loop — not a chat window.

Apple's launch of the low-cost MacBook Neo has been highly successful. A behind-the-scenes video revealed that its polished marketing relied heavily on practical, handcrafted effects combined with some CGI. Real-world techniques and artists were central to the production.

The Mosaic Rooms' new identity by Samar Maakaroun intentionally rejects stability, using a fluid monogram and bold color choices to express movement, cultural duality, and the idea of being “in-between” rather than fixed. The rebrand reflects the institution's evolving role and shows how strong design can embody unresolved tension and complex identity instead of simplifying it.

AI can analyze usability test videos by sampling frames, transcribing audio, and generating plausible descriptions of user behavior — though this process is "lossy" and prone to inconsistency. In a test using a six-minute OpenTable usability session, ChatGPT identified seven specific problems, including a search field that dropped cuisine selections when the location was changed and results that surfaced non-sushi restaurants. Whether those findings hold up in terms of accuracy, reliability, and alignment with what human researchers would catch remains an open question to be addressed in follow-up research.

IKEA's “Unpackaged Goods” campaign uses minimalist, low-noise visuals to highlight the satisfaction of organization.

A well-designed favicon increases credibility, improves user experience by helping visitors navigate multiple tabs, and maintains brand consistency across digital platforms.

PITAKA is launching a global design competition, "Weave the Next, Weave Our World," from April 24 to May 25.

Patrick Witt, executive director of the President's Council of Advisors for Digital Assets, previewed a "big announcement" on next steps for Trump's strategic bitcoin reserve in the coming weeks, noting the team has been working through the legal interpretations needed to solidify and protect the reserve's digital assets. The reserve currently faces a durability problem as executive orders don't carry the staying power of legislation, which is why Sen. Lummis and Rep. Begich have reintroduced the BITCOIN Act to codify it.

The DOJ will no longer investigate or charge blockchain developers for crimes committed by third parties using their software, provided the developer had no knowing involvement in those crimes. The new policy directly reverses the enforcement posture that produced Roman Storm's conviction in August 2025 and Roman Semenov's 2023 indictment over Tornado Cash. Crypto legal observers flag that the "knowingly helping" standard remains undefined, leaving open questions about where prosecutorial discretion ends and protected open-source development begins.

DeFi United, a coalition of ecosystem participants, has published the full technical implementation plan to restore KelpDAO's rsETH backing following the April 18 bridge exploit, where a forged inbound packet on the Unichain-to-Ethereum route released 116,500 rsETH without a corresponding burn. The exploiter distributed the rsETH across multiple addresses, supplied portions as collateral on Aave V3 (Ethereum and Arbitrum) and Compound, with seven addresses still holding active rsETH-backed positions. The plan covers the full path to making rsETH whole and resuming normal market operations, a critical test of DeFi's ability to coordinate post-exploit recovery at scale.

The EPOS CRYPTO Card for bitbank is a Visa credit card that lets users settle monthly payments by selling BTC from their bitbank holdings at a predetermined rate, a first-of-its-kind product in Japan. The card offers 0.5% crypto rewards (payable in BTC, ETH, or ASTR), has no annual fee, and includes a ¥2,000 crypto welcome bonus. It's a notable consumer product that bridges crypto holdings and everyday card spending in Japan's regulated market. The card is a potential template for similar products in other jurisdictions.

There are over 160 startups, protocols, and institutions across the onchain credit ecosystem, categorized into four main layers. These are Credit Issuance, Capital Allocation, Infrastructure, and Risk Management, with 19 sub-categories. The Credit Issuance layer spans institutional credit funds, tokenized offchain credit, and onchain origination models, including overcollateralized lending, P2P, InfraFi, and PayFi. This report provides a useful mental model for anyone trying to understand who the players are, which categories matter, and where the gaps remain in the onchain credit stack.

Onchain stablecoins generate 122x annual economic velocity per dollar deployed, compared to PayPal's ~40x turnover and US M2's 1.4x, with each $1B in stablecoin supply producing roughly $19M in annualized protocol revenue (excluding issuer float). Supply has grown 60x since 2020 to ~$300B, still just 1.4% of US M2, while tokenized RWAs have tripled to ~$25B over two years, led by BlackRock's BUIDL crossing $2B. The flywheel is now showing in market-hours displacement: during the Iran escalation, traders routed volume to onchain perps on platforms like Hyperliquid rather than waiting for traditional venues to reopen.

AI has pushed the cost of producing average crypto research to near zero, flooding the market with low-quality content and eroding the price-moving influence that early firms like Messari and Delphi Digital once carried. Institutional advisory demand has nonetheless accelerated through 2026, as organizations entering blockchain seek judgment and perspective rather than information aggregation. Four Pillars is responding by restructuring into five divisions (Crypto, Asia, Institution, Investment, and Tech) and announcing a Series A to reposition around perspective-driven, high-conviction coverage.

Circle Ventures announced an $AAVE token purchase aligned with Stani Kulechov's "DeFi United" campaign.

Confidence in pool/hub DeFi models has collapsed, with institutions demanding isolated risk controls and code-level compliance flexibility.

Block (formerly Square) disclosed 28,355 BTC in its Q1 2026 proof of reserves filing alongside preliminary Cash App Bitcoin Ecosystem Revenue, continuing the company's policy of investing 10% of bitcoin profits into BTC purchases each month.

Carry is a liquidity management platform that targets institutional capital allocators, letting operators spin up RWA liquidity facilities with configurable pricing, risk parameters, and multi-asset, multi-venue deployment from a single dashboard.