Gemini 4 Argon available on Google Cloud, built to help solve your business’ hardest problems

Last week we announced that Gemini Enterprise has evolved to make it even simpler to get work done, and introduced the Gemini agent, your new universal agent for work. It's always on and ready to answer your questions. It will write code, complete longer and more complex tasks, or perform whatever you need to get the job done, all from a single prompt box. And model intelligence underpins it all.

To enable a new frontier of work, we are making our new frontier model, Gemini 4 Argon, available on Google Cloud.

We trained Argon to work with both depth and precision, which allows it to maintain context across long, multi-step tasks which are reinforced with strong domain expertise along the way. Whether your team is running complex software builds, handling detailed financial and legal work, or deploying cybersecurity tools like CodeMender, Argon helps your teams maintain focus from start to finish.

Four ways Argon changes how your business works

1. Hand off your hardest work

Your teams already use Gemini for business to answer questions and draft content. With Argon, they can hand off the deep, multi-step work that used to take hours or days, and get back finished work they can use.

Argon reads long documents that mix text, tables, charts and images, and turns them into one clear output grounded in those sources. It can pull findings from many sources into a single structured answer, analyze data over time, and write stronger legal, finance, and executive documents. On long tasks, it keeps going until the job is done. We trained Argon to respect system boundaries, report negative findings honestly, and pause for confirmation before taking irreversible steps, and it tells you when it couldn't find something or finish a task.

Customers who tested Argon tell us it excels at turning huge, unstructured inputs into cohesive outputs.

"As software development becomes more agentic, teams need models that can support long-running, multi-step work across all stages of the development lifecycle. Gemini 4 Argon is designed to help organizations bring AI into development, security, and operations while keeping it within established enterprise workflows and controls.” – Stuart Moncada, VP, GitLab.

2. Precise, verifiable results on the work that drives your business

In finance, legal, tax, and other regulated work, calculations and data extraction need to be precise, repeatable, and verifiable.

For financial quantitative work, Argon can help automate multi-step ledger reconciliations, spreadsheet formulas, and variance analyses. It delivers high calculation integrity, citation fidelity, and formula accuracy across quantitative models. The proof is in the numbers: Argon leads on the Vals Index, which measures economic impact across finance, coding, legal, and tax work.

In legal research, Argon can help legal teams review case law and regulatory filings to pull out verified citations and key precedents. It leads on domain-specific evaluations like Harvey's Legal Agent Benchmark for legal research and drafting, with strong citation fidelity and direct answers when helping teams evaluate complex legal precedents.

"Gemini 4 Argon shows how much progress Google has made on agentic legal reasoning. We saw substantial improvements over Gemini 3.1 Pro across our legal agent evaluations, particularly in corporate M&A, data privacy and cybersecurity, and EC/VC. Accuracy also held up on long-document analysis, an encouraging result for lawyers working through detailed transactional matters." – Niko Grupen, Head of Applied Research, Harvey.

“We collaborated with Google on NowAI-Bench to help shape Gemini 4 for key enterprise work. In early access, it delivered roughly 20% improved task success than Gemini 3.8 Flash, with standout gains in HR and customer service. On the ServiceNow AI Platform, our L1 Service Desk AI specialist brings Google’s most advanced intelligence, governed and secure, turning tasks into fully autonomous work.” - Nenshad Bardoliwalla, Senior Vice President, AI Products, ServiceNow.

3. Build and ship products faster

Argon is built to handle complex, multi-step projects from start to finish. Our customers consistently ask for intelligence that can break down goals, track progress, and update multiple files at the same time.

"Gemini 4 Argon handles complex tasks reliably, from 3D games to rich animations. In Figma Make, it helps teams turn their most ambitious, multi-step ideas into impressive prototypes.” – Loredana Crisan, Chief Design Officer, Figma.

To see how well Argon handles this, we put it to work on our own tools. The team behind our open-source Agent Development Kit (ADK) set out to reduce framework overhead and improve code performance while maintaining full compatibility with existing applications. Working autonomously overnight within automated testing guardrails, Argon surfaced optimizations, now live in google/adk-python, that cut in-memory session prep time by 40% in long sessions and speed up cold imports by 21%. To learn more, read the engineering deep dive here.

Across Google, engineering teams using Argon in Google Antigravity have increased agentic code submissions by more than 35% while cutting code rollbacks by nearly a third. The Chrome team used Argon to finish an architectural refactor across hundreds of files in Chromium's 40 million-line codebase, completing months of work in weeks. Argon's improvements in spatial reasoning, mathematical precision and visual coding also make it faster to go from idea to working prototype.

For more advanced algorithms, our code optimization and discovery agent AlphaEvolve uses Argon to deliver strong performance improvements across real-world enterprise workloads, including factory scheduling, logistics, game code speed-ups, and chip layout — as well as complex mathematical benchmarks, and more.

4. Stronger defense for your code and business

While Argon has cyber mitigations that block offensive tasks such as pentesting and exploitation, you can still take full advantage of Argon’s defensive capabilities using CodeMender to find and fix vulnerabilities, or use Argon with your own security harness. It ties for first place on CWE-Bench v1 with a top score of 68% for remediating security vulnerabilities.

"We are integrating Gemini 4 Argon into MarketingX for automated codebase security audits. In our evaluations, the model successfully identified 100% of top-priority vulnerabilities with 0% fabricated vulnerabilities across verified claims. This precision unlocks proactive, code-level security for our customers before deployment.” - Yunus Emre, Chief AI Officer of AI Lab, HubX.

Security also means being able to trust Argon inside your own environment. Argon is our most resilient model yet against indirect prompt injections, where malicious instructions or context are used to hijack a model’s behavior. It leads the Gray Swan Indirect Prompt Injection benchmark, cutting attack success across 15 adaptive attempts to 0.7%. That matters when Argon reads email, documents and webpages that may contain hidden malicious instructions.

We are also releasing Argon without cyber guardrails to a select set of trusted defenders, which allows for testing a full breadth of cybersecurity capabilities. Trusted defenders are vetted through our Fairwind Program, a limited access initiative that provides government, critical infrastructure, and cybersecurity partners exclusive, unmitigated access to advanced models.

Get started

Starting today, Gemini 4 Argon is available in Gemini for business on the web, desktop, and mobile. Enterprise developers and builders can access Argon via API in Gemini platform under model ID gemini-4-argon, in Google AI Studio, and in Google Antigravity.

Argon launches at an introductory rate of $2 per million input tokens and $10 per million output tokens through November 30, 2026, with cached input tokens priced at 95% off. After November 30, standard pricing of $4 per million input tokens and $20 per million output tokens will apply. Review the model card and developer guide for complete technical specifications, token limits, and migration instructions.

Cyber defenders can join us at Security Summit to learn how to use Gemini 4 Argon to defend against machine-speed threats and automate remediation.

Introducing CLiF: Continual Learning from Full-Stack Trajectories

Today we're releasing CLiF - Continual Learning from Full-Stack Trajectories in early access!

CLiF turns the work your customers and employees already do in your product into the skills, evals, and fine-tuning data your agents need to do that same work reliably in production. It's fully self-hostable, and everything it produces is yours to export.

Your agents could already learn from their own conversations in CopilotKit Intelligence. CLiF now securely captures both sides of the work (agent trace and user actions) through the AG-UI protocol.

To see what CLiF can do for your product, book a demo, and our engineers will run it live on your use case.

Here's why we built it, and why every agentic product will need full-stack trajectories.

Why agents stall before production

Agents like Claude and Codex now take on whole tasks by themselves. Your users want the same in your product, from your built-in agent or any external agent they bring.

But even agents using top-tier models like Fable and Astra struggle to carry out complex, end-to-end tasks in your product consistently enough to deploy, at a cost and speed that make sense.

At companies shipping agents at scale, the pattern is the same. You grind out evals for the flows that matter most, often thousands of cases, each written by hand. Then you improve the agent bit by bit until it passes enough of them to go live.

That work is slow and expensive:

• Prompts grow with every edge case.
• Harness code fills up with special cases: hardcoded step orders, extra checks, custom retries.
• Memory piles up with every conversation, and the agent can't tell which parts matter.
• Fine-tuning comes last, if at all, because the right data is hard to collect.

Even after launch, users find themselves nudging the agent. Guiding it, correcting it, adding context it was missing. Then the next conversation starts, and it needs the same help again.

Meanwhile, the people using your product do this exact work every day.

Your users already do the work in your product

Your customers and employees already know which actions to take, and in what order, to get the job done. They've done it hundreds of times. Your agent has to deduce all of that from prompts, skills, and hundreds of tools and APIs, so it guesses, retries, or hands the task back.

Say you run a support platform. A rep gets a ticket: "I was charged twice." They check the plan, find the duplicate charge, and since the customer is on an annual plan, they issue an account credit instead of a refund, because that's what their team does. No doc or prompt says so.

You could add that rule to a prompt. But there are hundreds like it, and you only find the missing ones when the agent gets them wrong.

Products already record clicks, funnels, and session replays for people reading dashboards. To teach an agent the job, you need trajectories, securely captured as they happen: the full record of every action taken to complete a task, whether by a person or an agent.

In your product, that's a product trajectory: every click, API call, and agent conversation behind a task.

With product trajectories:

• Your agent improves every day from how your customers and employees actually work.
• The problems that come up most get fixed first.
• You approve every change before your agent uses it.

By hand, you would make one or two fixes a day, usually after a customer has already complained. Teams using product trajectories can see a significant drop in repetitive tasks, up to 80%, within the first two weeks.

Continual learning from full-stack trajectories

CLiF is part of CopilotKit Intelligence and learns from full-stack trajectories captured over AG-UI (Agent-User Interaction Protocol). AG-UI is the open protocol that connects agents to user-facing apps, supported by Google, Microsoft, Amazon, and most of the ecosystem.

AG-UI sits between your agent and your users on any surface, so it sees both sides of the work:

• Agent trajectory (agent trace): every run, tool call, and state change your agent made, and what it returned.
• Product trajectory (user actions): what was on your users' screens, the buttons they clicked, and the server requests they triggered.

Together, that's a full-stack trajectory.

Because it runs on AG-UI, CLiF works with any agent harness and any model under the hood, whether your agent lives in your web app, mobile, Slack, or Teams.

CLiF reviews new trajectories on a schedule and finds the patterns, including the friction people silently work around. That friction often repeats across thousands of sessions and shows your agent exactly what to learn next.

CLiF turns those patterns into proposed skills, and once you approve them, they reach your agent without redeploying.

Skills are where it starts. From there, we want every team to own the full cycle:

1. Securely capture every agent and user action as trajectories.
2. Use agents to make sense of that data at scale.
3. Turn it into evals and environments.
4. Review the results together, agents and humans.
5. Fine-tune smaller, faster open models for your most important tasks.

What you get from full-stack trajectories

CLiF turns them into:

• Skills for your agent or MCP server, built from patterns across your trajectories.
• Production-based evals, built from what your users actually do and ready for the eval platform you already use.
• Fine-tuning datasets for smaller models that run faster and cheaper on your most important tasks.
• Full-stack trajectories you can export to any observability platform.

All of it works with your existing observability and evals stack.

Learning from agent trajectories, available today

Every conversation with your agent is an agent trajectory, stored in AG-UI Streams: the messages, tool calls, generative UI, state, and more. When a user corrects the agent, asks for a different format, or adds context it was missing, that becomes a signal CLiF can learn from.

In CopilotKit Intelligence, you organize these trajectories into learning containers, for example, one for expense review and another for onboarding. A container only learns from its own threads, so a skill learned from expense reviews stays with expense reviews.

Every learning run surfaces Product Insights: the recurring requests and friction in those conversations, each linked to the threads behind it. When the evidence supports a reusable lesson, CLiF proposes it as a skill.

Each proposed skill is a SKILL.md you review, approve, and can ship with your project. Approved skills reach your agent without a redeploy, and each one stays readable and reversible.

Around that loop, Intelligence lets you:

1. Import the threads you already have from a LangGraph Server or LangSmith Deployment, so you don't start from zero.
2. Run the analysis manually, or on a schedule once a container has at least 15 eligible threads.
3. Deliver skills automatically through adapters for LangGraph (Python and TypeScript), Mastra, Google ADK, Microsoft Agent Framework, and CopilotKit's built-in agent. Setup is one prompt you paste into your coding agent.
4. Download published skills with the CLI as plain SKILL.md files for any other agent.

Fully self-hostable

CLiF is fully self-hostable, so your data stays inside your own network. You can self-host CopilotKit Intelligence on your own Kubernetes cluster with our Helm chart, or on AWS ECS/Fargate.

You bring your own Postgres, Redis, and identity provider, such as Okta, Azure AD, or Keycloak, and keep secrets in the store you already use. Your trajectories, skills, and everything learned from them stay inside your VPC or on-prem. You can also send traces to your own OpenTelemetry collector.

Learning from agent trajectories also runs on our managed cloud for the fastest setup.

Our engineers can help you set it up. If you're planning an enterprise self-hosted deployment, book a call and we'll walk through it with you.

Get started

Learning from agent trajectories works today, and product trajectories are in early access.

Want to see CLiF on your product? Book a demo, and we'll take your use case and show how full-stack trajectories generate the exact evals and skills to get your agents' success rates above the line.

We're also hosting a live session on CLiF on October 15 at 9 AM PT. Sign up here.

To learn more:

• CLiF: copilotkit.ai/clif
• Learning docs: docs.copilotkit.ai/learning
• Self-hosting Intelligence: docs.copilotkit.ai/intelligence/self-hosting
• AG-UI: docs.ag-ui.com

The agentic ecosystem is moving from agent trajectories to full-stack trajectories. The products whose agents learn from how work actually gets done will pull ahead.

Google's flagship Gemini 4 Argon multimodal language AI model is now broadly available. Developers and enterprises now have a powerful new option for software engineering, financial analysis, legal work, cybersecurity, and scientific research. API prices have been discounted substantially for a limited time. Argon is available through the paid Gemini API, Google AI Studio, Antigravity, eligible Gemini Enterprise subscriptions, and to Google AI Pro and Ultra subscribers through the Gemini app and AI Mode in Search.

At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.

In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.

In order to support this growth, we built Scion, an in-house version control system, and fully migrated our monorepo from git in five months. We also built and shipped a code review surface (called Antique), code search, a rich source control IAM system, novel ways of managing and landing large amounts of reviewed code, and more, all in that same time period. In this post, we’ll focus on how we built Scion specifically. It makes for an interesting case study: Claude’s ability to write code was both what put us in this situation in the first place and how we were able to quickly build a high-quality, scalable system to deal with it.

Growing our monorepo

Before we explore what we built, we should acknowledge how unusual our workload is. Unsurprisingly, Anthropic uses Claude to write software far more than almost any other company, so we’re often the first to see where tools built for human scale start to strain. Source control is just one example of this. While we don’t expect many organizations to have these problems in the very near term, we suspect it won’t be too long before others who use AI coding tools experience these same pressure points, which is why we wanted to share what we built and what we learned.

Git is a decentralized system: every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline. For the vast majority of repositories, this is the right design, and it’s a large part of why git became the standard.

As our monorepo grows, it increasingly doesn’t fit that design space. The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. We perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic per day.

Git offers tools for working with a slice of a repository, such as shallow clones, sparse checkouts, and promisor remotes. Beyond these, there are standard workarounds for large monorepos, like internal git mirrors and repository snapshots (seeds) kept in blob storage. We’ve used all of them—at our peak, we operated several hundred internal git mirrors to deal with the load. This bought us time, but they became harder to operate as our merge rate increased. Seeds fell further from the tip of main between refreshes, and it took more and more care to keep operations that depend on history, like diff and blame, working on partial clones.

Taking a step back, we noticed that, like most companies, we were using git as a centralized system with one authoritative copy, but nearly all of our clients were agents and jobs that are online by definition. The properties that make git excellent for distributed, offline work were actively undermining our ability to scale as the repo grew. So we asked ourselves: if we designed source control with the fact that agents are always online in mind from the start, what would it look like?

Principles for agent-scale source control

With agentic coding, many common assumptions about how software is developed are evolving. We embraced these changes when building Scion, which allowed us to take a fundamentally different approach than git on several core principles. Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling, so we were able to build Scion with their hard-won lessons in mind. Our principles are:

• Clients are always online. Git assumes that clients work offline and need a complete copy of the repository. Since nearly all of our clients are agents and jobs, we designed Scion’s client and protocols around a server that is always reachable, and have clients fetch data when they need it.
• Client-server asymmetry. In git, every client is capable of being a full-fledged server. In Scion, the server answers questions about file history and blame, creates commits, performs merges and rebases, and so on. The client maintains a bounded local object cache, lays out the working copy files on disk, monitors for filesystem changes, and gives users an ergonomic way to work with the server. It can compute very little on its own but, in exchange, it requires much less data locally.
• A comprehensive source control service can power many novel applications. With git, a CI job or tool that needs to ask a question about the repository, such as who last changed a line or how two commits are related, has to maintain a local copy of the repo or hope that vendor-specific APIs provide the answer. With Scion, all of the source control queries the client uses are also exposed via API, so in many cases jobs don’t need a local repository at all. Many internal tools, such as our automated bisect and revert pipelines, wouldn’t be practical at scale without this cheap, programmatic access to source control.
• Everything must be horizontally scalable. At our peak, we ran several hundred git mirrors, which significantly strained capacity and no longer scaled once the repo outgrew the mirrors’ disks or memory limits. In Scion, the repository’s data is distributed, and every component is independently scalable; there is no fully materialized copy of the repo anywhere, even on the server. There is no equivalent of packfiles (git’s compressed bundles of objects), so no repository maintenance is needed.
• Commits must be cheap, incremental, and lock-free. In git, you commit locally and then push to share your work. In Scion, every commit, rebase, or merge happens on the server, so there’s nothing to push, but each of those operations needs to be fast. The cost of creating a commit and updating its downstream data structures has to scale with the size of the change, not the overall size of the repo, or the server can’t keep up. The development lifecycle in Scion discourages refs (pointers to commits, such as branches and tags), except for the main ref or release branches, because global state that every server has to agree on is a looming scaling problem.
• The working copy is optional, and sparse by design. Because our monorepo is so large, and because we check out code tens of millions of times a day for CI, we wanted to avoid checkouts whenever we could. With Scion, a CI job that needs the diff between a commit and its merge base, for example, can ask the server for it. The same goes for writes: many write workloads can also skip the checkout and function entirely via API. Scion’s protocol is centered around sparse checkouts, which only contain the directories the client asks for, and virtualized checkouts, which materialize files on demand, so when a job does need files on disk, the client only pays for what it actually reads.

How Scion works

Data structures

In Scion, the unit of work is a “changeset,” an entry in a write-ahead log. A changeset stores most of what you’d expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage. Changesets are created server-side and are available everywhere, instantly.

This structure lets us accept changesets with very high throughput because there are no packfiles to accept, no locking or cross-server coordination, and no refs to move around. Scion does technically support refs, but since neither creating nor fetching commits involves them, moving one is a compare-and-swap on a single Spanner row that happens separately from creating changesets.

A changeset records only what’s changed, so on its own, it can’t quickly answer questions like who last edited a line or which commits affected a file. To answer those, Scion builds additional data structures from the changesets, including dedicated structures for file blame and path history and skip lists for the commit graph. We call everything that isn’t directly part of the changeset “derived data,” and we compute it all through one generic mechanism. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for that changeset’s parents.

This mechanism has three benefits. First, we can easily add a new type of derived data when a new data structure would make some operation faster. Second, for each type, we can choose whether to compute it eagerly or defer the work, so we avoid materializing data we don’t need. And third, because the client never sees the internals of these data structures, we can optimize them without changing the client. We’ve added new types of derived data many times as the system has grown, such as new indices for performing copy detection or path-based file search.

Scaling Scion

A small fleet of Scion servers provides source control APIs for any operation a client needs, such as getting changesets, computing diffs, finding merge bases, and fetching blobs. All source control data is content-addressed, so a piece of data never changes once it’s stored, and any server can cache it without checking with the others. As a result, the servers are horizontally scalable and require little coordination. They are essentially large caches that can also compute derived data on the fly and write the results back to Spanner.

Scion’s many consumers no longer need to maintain local repositories of their own. Fetching and maintaining the repository used to be a significant maintenance burden for CI jobs or tools that needed to ask source control questions, particularly about commit ancestry and blame. Early in the migration, before we had our own client, repo format, or protocols, Scion only answered these “metadata” queries. Fetching file contents and materializing working copies are far more data-intensive operations, and they needed a design of their own.

Scion’s scn client deviates from git’s fetch protocols in several important ways and, as a result, lends itself to a highly scalable architecture that requires significantly less CPU than git servers. Scion’s negotiation doesn’t tell the server what the client already has; instead, it operates exclusively on trees and blobs the client wants. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs. Every request is for a specific object that never changes, so any cache can answer it, and the architecture closely resembles traditional tiered caches. The process is also efficient and resumable, because there is no single multi-gigabyte packfile response. Sparse and even virtualized checkouts don’t need special support, because the client simply doesn’t ask for trees it doesn’t want.

In the fleet, the client talks over a socket to a daemon, scion-daemon, that stores objects for the whole node. Most of our nodes need access to the monorepo, and jobs on the same node reuse most of the same objects. Each daemon starts from a periodically refreshed snapshot, then talks only to the tree and blob cache servers in its region, called scion-cache. These cache servers stream objects directly from memory, in the disk format that the daemon will consume, so they don’t need to spend time computing the client’s missing objects or performing delta compression. When a cache is missing an object, it asks the authoritative scion-servers, which read from Spanner or cloud storage as needed.

The scion-daemon, scion-cache, and scion-server all respond to identical RPCs for this protocol, so the client doesn’t need to know the cache topology. Any tier could theoretically talk to any other, but we strictly enforce the tiering to isolate failure domains. We want to avoid a situation where a failure in a regional scion-cache overwhelms the upstream scion-servers and brings down the entire system.

Each tier of this system maintains a cache hit rate of over 99% and does not require long-lived state, so it’s easy to scale up if needed. Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements. CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes), which frees up a sizable amount of capacity across the fleet; CI alone realized a 25% CPU capacity win. Neither clients nor caches need to perform repository maintenance, which simplifies the lifecycle management of our jobs.

What we learned building Scion

We started building Scion around the same time as Claude Mythos Preview and Claude Tag became available internally. Both of these releases simultaneously amplified the need for Scion and meaningfully accelerated how quickly we could build it.

Here’s a particularly striking example. Earlier in the year, we had largely handwritten the first version of the git-to-Scion ingestion pipeline as a prototype. We thought it was good—until we got our hands on an early internal snapshot of Claude Mythos Preview. We asked it to rewrite the whole thing, and with no further instructions, it produced a version that consumed 20x less memory and was 4x faster, while preserving all of the implicit invariants around ingestion ordering and data structures.

What we learned building and operating Scion offers some interesting lessons for what building agent-scale software could look like.

• Rapid development with a small team will become more common. A team of seven people built both Scion and Antique, not to mention half a dozen related systems, and fully migrated to them in five months. We did all this while the volume of code merged per day increased by 10x. In the past, developing and deploying a source control system like this would have taken a company years of iterative migration, with many more engineers. We think this sort of fast, nimble migration will become more common in the future.
• Engineers are no less valuable, but their work is changing. All of the engineers who worked on this system would now rate Claude as better at writing code than them. But our engineers still supplied the invaluable understanding of the high-level inter-system components and the design-level tradeoffs, making informed choices around the problems we wanted to solve and the scale we knew we needed to achieve. Very often, we found that the role of the engineers was to tell Claude “no.” Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place. This was particularly common in our migration.
• We were able to substantially improve optimization and quality. By virtue of Claude’s ability to write immense amounts of code much faster than we could ourselves, Scion is among the most well-tested and well-defended codebases we have ever worked on. Even on our tight timeline, we were able to build hermetic simulations of every non-trivial infrastructure and source control interaction we’ve ever encountered, as well as fuzzing and sophisticated rate limiting.
• We laid the groundwork for new forms of monorepo security. Managing safety, security, and compliance in a massive monorepo is as important as managing the size and scale. We built Scion with these in mind from the start. It supports rich access control on repositories, as well as the ability to apply permissions to individual directories in order to protect the most sensitive code without losing the benefits of a monorepo.
• A new level of operational excellence is possible. Our team uses Claude Tag heavily, which has helped us monitor each component of the system. For example, we created Slack channels where we tasked Claude with being obsessively focused on the health of a single component. We call these Claudes “superfans.” We have a scion-daemon superfan, a scion-cache superfan, an Antique merge queue superfan, and so on.
• We’re completely rethinking our priors. This project prompted us to take a very hard look at other workflows designed for human scale. A proper merge queue, for example, doesn’t make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running? We haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we’ve invested in post-merge and pre-deploy automated testing.

Contributing to the wider ecosystem

We see Scion as just one part of the answer to the scaling concerns that increasingly capable AI agents have raised. We’re sharing these details as an example of how teams can tackle similar challenges, though we don’t expect our solution, or our considerations, to suit every case.

Scion is by no means a suitable replacement for git for general use. The concepts we’ve outlined here really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code. Plus, Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend. We do this both to address our own software development needs, and to test Claude’s capabilities.

However, we anticipate that this class of problems will become more commonplace over the next six to 12 months, and it would be an inefficient use of engineering resources for every company using git to face similar challenges alone. Given that, we think the most impactful thing we can do is to share our thinking, so that other developers can apply some of the most successful parts of Scion to git without departing from the overall model. A git server doesn’t have to work the same way as a git client does; novel server architectures exist that provide significant scaling improvements.

Acknowledgements

Written by Nick G. and the source control team: S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P. We’re grateful to Vilas J. and Sergiu D. for supporting the source control team on this ambitious journey and Amir O. for early contributions to Antique.

Footnotes

1. Storing changed files relative to the first parent of a merge is a stylistic choice; in practice, we’ve found that people only care about history or blame for commits on the main line in trunk-based development in a monorepo.

OpenAI discovered a hidden recording device in one of its offices recently. It was traced to Abdulrahman Alfozan, a Saudi Arabian national who joined the company's product team in July 2025 as an engineer. He was arrested by the FBI. The device was built to evade detection and used advanced encryption. It could monitor audio and had a way to transfer data without being noticed.

Full article content is not available for inline reading.

Read the original article →

10 Years of the SRE book: Announcing the second edition of "Site Reliability Engineering”

A decade ago, Google released Site Reliability Engineering: How Google Runs Production Systems with O'Reilly Media. What began as a collection of our practices for managing large-scale infrastructure became a bestselling book, and inspired many organizations to adopt the reliability practices it outlined: applying software engineering to operations to build systems that are scalable, reliable, and sustainable.

Over the past ten years, computing landscapes have undergone profound shifts. AI, microservices, multi-cloud deployments, serverless paradigms, and platform engineering have all reshaped how we build and operate software. To mark the 10th anniversary of the book's release, we are excited to announce the completely rewritten second edition of the Google SRE book, reflecting a decade of lessons learned both inside Google and across the broader industry, to offer fresh guidance tailored for today's operational challenges.

Why update the book?

When we published the first edition, many organizations were focused on early cloud migrations and just starting to transition from monolithic architectures. Today, with organizations delivering software at a high velocity and at global scale, the challenge is no longer adopting cloud infrastructure, but maintaining high reliability in the face of the immense complexity.

Modern production environments operate under constant change. System boundaries are more complex, dependencies are deep, and failure modes are more complex and damaging than ever before. The explosion of resource-intensive workloads like generative AI has changed the economics and operational requirements of infrastructure management.

Writing this second edition required us to take a step back and evaluate what it takes to successfully implement SRE today.

A decade of evolution: How SRE practices have progressed

The second edition takes a deep dive into how foundational site reliability engineering practices have matured over the last ten years, shifting from manual, task-specific work toward automated, platform-wide capabilities. Consider, for example:

SLOs and error budgets: In 2016, teams relied on basic availability metrics and manual error budget policies. Today, practices have matured into user-centric, multi-tiered SLOs with dynamic burn-rate alerting and automated policy enforcement.

Monitoring and observability: Early setups centered on static dashboards, basic logs, and manual alert triage. Modern observability leverages OpenTelemetry, distributed tracing, and automated anomaly correlation to find root causes quickly.

Automation and platforms: Operations have shifted from writing custom scripts for isolated tasks to using declarative infrastructure as code, internal developer platforms, and resilient, self-healing systems.

Reliability testing: Rather than relying solely on scheduled game days and synthetic load tests, modern engineering embeds continuous resilience checks, automated pipeline testing, and live production canary verification.

Capacity and resource management: Manual provisioning and static forecasting have been replaced by dynamic auto-scaling, cloud FinOps alignment, and dedicated cost and cluster optimization for GPU and TPU workloads.

Organizational models: SRE has expanded beyond dedicated teams assigned to specific applications. Today's organizations use hybrid models, platform engineering integrations, and reliability champions embedded across product teams.

SRE in the age of AI

Then there’s the dual relationship between SRE and artificial Intelligence: how SRE supports AI infrastructure, and how SRE teams use AI to enhance operational reliability.

Running large language models (LLMs) and foundation models introduces novel reliability challenges. The book outlines methodologies for operating AI infrastructure at scale:

• Managing massive GPU and TPU hardware cluster reliability and network topologies
• Monitoring non-deterministic outputs and latency characteristics unique to AI
• Ensuring pipeline reliability for continuous model training, fine-tuning, and data processing

AI is also rapidly becoming a force multiplier for reliability engineers. The second edition shares practical frameworks for enhancing human operational efficiency:

• Using generative AI tools to assist in real-time incident triage and postmortem generation
• Interrogating complex system telemetry using natural language queries
• Using predictive machine learning models to identify resource bottlenecks before outages occur

What hasn’t changed? The importance of culture

While technologies and architectures continuously evolve, the core principles of SRE remain intact, and are key to establishing a reliability-focused culture. Accordingly, the second edition re-emphasizes and expands upon the human elements of system engineering, and how to get there.

Whether you’re new to the field, a practitioner, an engineering manager, or a technology executive, the rewritten second edition of Site Reliability Engineering serves as your definitive roadmap for the next era of production systems.

You can order your copy today in physical format (see Google Books) or digital format from O'Reilly.

Announcing AWS Lambda Web Functions

Today, we’re announcing AWS Lambda Web Functions, a new form factor that lets you run standard HTTP web applications on Lambda without rewriting your code into an event handler. You can take a standard port-listening server built with Express, Hono, Fastify, Next.js, or any Node.js framework, deploy it with a single command, and Lambda automatically handles scaling, multi-region distribution, and active CPU billing. No adapters, no infrastructure to manage, and no framework lock-in.

With this launch, AWS Lambda now offers three distinct form factors, each built on the same Firecracker isolation technology and designed for a different programming model.

Lambda Event Functions are what you already know as Lambda functions. They use the event-driven, single-concurrent handler model with wall-clock billing. We’re introducing the “Event Functions” name to highlight that programming model: your function receives an event, processes it, and returns a response. The event-driven programming model is ideal for event processing, queue consumers, and invocations triggered by other AWS services.

Lambda Web Functions use an HTTP-native programming model with multi-concurrent execution and active CPU billing. Your code listens on a port and handles standard HTTP requests. That programming model is ideal for web applications, API backends, and interactive HTTP workloads where multiple concurrent requests and I/O-heavy processing are the norm.

Lambda MicroVMs provide isolated, stateful sandbox environments with customer-managed lifecycles for running untrusted or user-generated code.

The three complement each other. An application might use Event Functions for asynchronous backend processing, Web Functions for the user-facing API and server-side rendering layer, and MicroVMs for interactive code execution features, all within the same AWS account and sharing the same operational model.

Why Web Functions

Modern web applications need to serve global audiences with fast, consistent response times while giving developers the freedom to use standard frameworks and iterate quickly. Building this today typically requires assembling multiple infrastructure components, configuring multi-region deployments, setting up latency-based routing, and tuning billing models to avoid paying for I/O wait. Developers often find themselves adapting their application code to fit a specific compute model rather than deploying the HTTP server they already have.

Lambda Web Functions removes this complexity. Each execution environment handles multiple requests simultaneously (up to 128 concurrent requests per environment), which means a burst of incoming traffic can share warm environments instead of mapping each request to a new one. Web Functions meter the CPU time your code uses, so time spent waiting on a database query or an API call consumes little CPU. Memory is metered for as long as the execution environment exists. For I/O-heavy web workloads like server-side rendering, API backends, and AI inference endpoints streaming token responses, this can reduce compute costs.

Let’s try it out

To get started, I wrote a simple Express.js server. This is the same code I run locally with node index.js, no Lambda-specific adapters or wrappers required.

import express from 'express';

const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');

app.get('/', (req, res) => {
  res.json({ message: 'Hello from Lambda Web Functions!' });
});

app.listen(port, host, () => {
  console.log(`Server running on port ${port}`);
});

The only difference from running locally is the AWS_LAMBDA_HTTP_ENDPOINT environment variable, which Lambda sets to the host and port your server must listen on. To run locally, set it yourself, for example AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js.

With my code ready, I deployed using the AWS Command Line Interface (AWS CLI):

aws lambda-web deploy --name my-web-app --code ./my-app

One command. No prior resource setup. The CLI bundled my source, created the Web Function, published its first revision, attached a Web Function endpoint, and returned a live HTTPS URL in under a minute.

A revision is an immutable snapshot of the code I deployed. The endpoint is the HTTPS URL that routes traffic to a revision, or splits traffic across revisions. Those are the resources I use to iterate and to control how traffic moves to new code.

I tested it immediately:

$ curl https://<domain-id>.<shard-id>.lambda-web.us-east-1.on.aws/
{"message":"Hello from Lambda Web Functions!"}

Next, I wanted my application to serve users in Europe and Asia with lower latency. I redeployed with multiple regions:

aws lambda-web deploy --name my-web-app --code ./my-app \
    --regions us-east-1,eu-west-1,ap-northeast-1

Lambda Web Functions replicated my code to all three regions and configured latency-based routing automatically. Each request now routes to the Region with the lowest latency for the caller, on a best-effort basis, through one global URL (<domain-id>.lambda-web.global.on.aws).

When I updated my code and ran the same deploy command again, the CLI detected the existing function, uploaded the new revision, and pointed the endpoint at it. Total turnaround from code change to live: seconds.

For production workflows that require a more gradual rollout, I can shift traffic between revisions with a single API call:

aws lambda-web update-web-function-endpoint \
    --function-name my-web-app \
    --endpoint-name dev \
    --auto-deployment-mode Disabled \
    --revision-weights '[{"revisionId": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "weight": 10}]'

This sends 90% of endpoint traffic to the current revision and 10% to the new one, giving me a canary deployment without additional tooling.

Better together with Amazon CloudFront

For applications that combine static and dynamic content, Web Functions works well alongside Amazon CloudFront. You can select a Web Function endpoint as the origin for your CloudFront distribution. Static assets are served from the cache while dynamic requests route to your Web Function, giving you CDN performance for static content with serverless compute for the dynamic parts.

Web Functions improves the private-origin experience with CloudFront. With this launch, you attach CloudFront origin access control (OAC) to a Web Function endpoint instead. CloudFront signs requests to the origin, and the endpoint allows only your distribution to invoke it. You get the same private-origin pattern CloudFront already provides for Amazon Simple Storage Service (Amazon S3), without exposing the endpoint or adding custom authorization to your app.

Now available

AWS Lambda Web Functions is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). Web Functions run Node.js 24 (nodejs24.x) on Arm64 at launch and support Amazon Virtual Private Cloud (VPC) connectivity, allowing your function to access resources that exist within a VPC.

To get started, deploy your first Web Function in under a minute:

aws lambda-web deploy --name hello-world --hello-world

For pricing details, visit the AWS Lambda pricing page. To learn more, see the Lambda Web Functions documentation.

More than 20% of the web sits behind Cloudflare’s network, and our team, the Data team, owns the data pipeline responsible for plumbing that data (and more) from our global network to applicable central data centers. The Cloudflare network is a globally distributed system supporting tens of thousands of servers. Data that power Cloudflare Logs, SQL API, observability, internal analytics, and more flow through this network and use our data pipeline to serve customers.

In May of this year, we were providing data delivery at roughly two billion events per second. This includes customer traffic as well as data sent from internal teams. Year after year, we tackle the same problem — exponential traffic growth against linear hardware growth. We have to react to this increase in order to keep resource costs under control. Over the past five years, we’ve made various improvements to compensate for the data volume increase in comparison to hardware allocation, equivalent to deferring two and a half years of hardware expansion. This post details those changes: breaking up our monolithic data schema in 2022, adjusting compression in 2024, rearchitecting pipeline replication in spring 2026, decentralizing sampling in summer 2026, and introducing aggregations into the pipeline in fall 2026.

Background

Our pipeline starts with an internal service called Logfwdr, where we collect from highly distributed data sources (think: Workers, FL). We then feed this data to a set of centralized receivers, which eventually push them onto our buffering system, Buftee. Consumers fetch data from Buftee and distribute data to their final destinations, like ClickHouse, which we rely on heavily.

Unpacking the monolith

In 2022, we dismantled our one and only schema. Previously, there was a single stream packed with every product's fields, forcing Cloudflare-internal consumers to ingest everything and demux or discard records via filters. At the time, most of Cloudflare’s data products were built on HTTP, Security and CDN metadata. In 2021, our message schema looked like this:

Some fields here belonged under the same product, but some were completely irrelevant to each other. The hypothesis was that none of these teams require 100% of fields in the monolithic schema. In other words, we can create small messages for each product’s required fields. Although we were going to duplicate fields, some of them in every message, replacing this firehose with product-specific schemas actually reduced the backbone bandwidth usage by 35-40%, knocking out roughly a year’s worth of compressed traffic growth.

Compression

By 2024, as traffic steadily grew, we were tackling network congestion issues on a daily basis. To react to this, we changed our compression algorithm from LZ4 to zstd. We had already experimented with zstd compression before, but we noticed a higher CPU usage at the time. Therefore, we were careful to track the metrics to ensure the trade-off was worth it.

Initially, we rolled this change out to a few servers. To our relief, we didn’t observe a noticeable difference in CPU usage.

With more confidence, we gradually rolled out to our entire fleet, which also showed little impact to CPUs. In the end, there was nearly a 40% reduction in compressed traffic throughput. The uncompressed bytes remained at the same growth, meaning we could support more than 1.5x the amount of traffic with the same size pipe. Or another way to put it, the estimated growth-equivalent reductions put us at about 10 months prior.

Now, in 2026, we attempted three strategies to reduce uncompressed bytes (and thus, compressed bytes).

Load balancing

To make analytics resilient against regional disasters, our systems require redundant data to be stored in multiple centralized regions (data subject to Customer Metadata Boundaries is stored strictly within its designated region). Historically, the simplest way to achieve disaster resilience was double-writing: Logfwdr transmitted two full copies of every non-regional analytics event — one to each centralized region. Each region then independently processed a complete copy through to ClickHouse. We also apply sampling in each region, an incredibly scalable technique that works for all volumes of data during any traffic conditions. We downsample high-volume traffic while rare events are preserved.

This infrastructure was manageable when only a handful of streams used secondary regions. However, as we expanded disaster resilience across almost all analytics streams, Logfwdr traffic doubled across the board. Sending every event, twice, over wide-area transit was unsustainable against our exponential traffic growth.

We had already tackled a similar challenge for Logpush. For Logpush, Logfwdr treats the centralized data centers as a unified, shared pool of receivers: each message is sent to only one region, failing over to another destination if a machine or facility is unreachable. That model had already proven its worth during large incidents, shifting traffic seamlessly from one location to another without human intervention. This automatic failover was possible because Logpush delivery is stateless, as customer destinations do not care which centralized data center pushes the logs.

Analytics was trickier. Unlike stateless logs, ClickHouse clusters in both regions still need a full copy of non-regional data to allow instant, independent query failover. The breakthrough was decoupling pipeline transit from database redundancy:

1. Shared Ingest Pool: We adopted Logpush’s model to the analytics streams. Logfwdr dispatches each event exactly once across wide-area transit to whichever centralized receiver is available.

2. Late Replication from centralized regions: Instead of replicating traffic at source, replication happens as late as possible in the pipeline. Data lands in our distributed buffering layer, Buftee, and remote inserters stream cross-data-center copies downstream.

3. Resilient Failure Handling: If a centralized region goes down, Logfwdrs immediately routes all non-regional traffic to the surviving region. If the inter-data center connection blips, each cluster continues ingesting its local share without backpressure; remote inserters catch up from Buftee's retention buffer once the backbone recovers.

For the datasets we migrated, the cutover eliminated approximately 43 GB/s of compressed transit traffic while adding only ~7 GB/s of cross-data-center replication on our pipeline. Two architectural factors explain this asymmetry:

1. Replication happens downstream of sampling: In the old model, Logfwdrs transmitted two copies of raw, unsampled events over wide-area transit. In the new model, Logfwdrs send a single copy to centralized receivers, which immediately apply sampling before buffering into Buftee, carrying only this already-compacted stream.

2. Better compression through uniform partitioning: Data at source is fragmented across thousands of individual servers. After centralization, streams are aggregated and partitioned into uniform batches over wider time windows. This structural uniformity allows compression algorithms to achieve dramatically higher compression ratios than Logfwdr transit batches ever could.

Overall, this was a net reduction of 36 GB/s across wide-area networks. We rolled this out initially to two datasets, HTTP analytics and Ready-Analytics, our in-house one-click analytics product.

Sampling from the get-go

Another strategy we employed was further expanding our sampling mechanism so that we pulled critical processing earlier into the pipeline. Sampling was already used in our centralized services, particularly the receivers, easing pressure on downstream systems. We can be more resource efficient if we send less data downstream (without sacrificing data quality).

The solution here was to simply sample in Logfwdr, in addition to maintaining the sampling in centralized receivers. How the sampling algorithm works here, in short, is each dataset has a key that producer teams have chosen to index and sample the data. When sampling, we first shuffle the records for each key to eliminate bias. Then, for each group of records, we select a sample size equal to the square root of the total count of the records. The result is a representative sample, whether sampled once or twice. To produce estimates, we scale calculations against the sample rate. For example, if we sample 10 out of 100 records, the sample rate would be 10/100, and the unbiased estimate of the original count would be 10*10 = 100.

To ensure this approach was working well, we compared the number of rows written to ClickHouse against the estimated sum for total count using a variety of keys across a variety of traffic footprints, so that “least seen” keys to “most seen” keys were captured across the spectrum.

The result is that for keys with more data, the sample rate decreases. However, keys with less data were sampled comparably. Thus, we still kept a representative sample while delivering and storing fewer events. We’re not compromising the quality of data delivered, even when we deliver less in quantity.

If we look at this more closely, using power laws, we can observe that the double-sampled (red) grows at roughly x0.319 v. sampled-once/control (blue) at x0.485. Another way to picture this is, a key that has 100x more data than another key would have stored roughly 10x the number of rows if single-sampled. Now, it will only store roughly 4x the number of rows. Concretely, a total of 11.6 million events is represented by 18k rows in ClickHouse as opposed to 79k. Double sampling attenuates storage of the “most seen” keys, while still retaining the same detail per event for “least seen” keys.

Aggregating

Cloudflare offers several analytics datasets built on rollups: aggregates of the raw events computed at ingest time. This makes the opposite tradeoff to sampling: rather than answering any question approximately, we answer a fixed set of questions exactly, provided we choose the dimensions and metrics up front.

For example, in the HTTP dataset, we measure the number of unique occurrences of IP addresses during a given minute rather than the individual IPs themselves. Another example is we sum the total number of GET, POST, PUT, etc. requests for a given domain, for that minute, grouped by the HTTP method. None of these computations actually necessitate waiting until the tail-end of the pipeline to start calculating.

Historically, this aggregation occurred towards the end of the pipeline, inside the inserters which read from Buftee and insert into ClickHouse. Decentralizing this aggregation was an opportunity to spread out load and reduce the amount of data we centralize.

Hence, we built an aggregation functionality that is utilized every step of the way, creating repeated opportunities to combine matching partial aggregates as data converges. Much like sampling, records are grouped by a key, which determines which records can be combined. We aggregate on each instance of Logfwdr. We aggregate again after the partially aggregated events reach the centralized receivers, which push these re-aggregated events onto dedicated partitioned buffers. Because these buffers bring together records from multiple receivers, we aggregate another time after they’ve been read in batches by the ClickHouse inserters. Finally, we aggregate in ClickHouse with aggregating table engines.

The first dataset we rolled this out to was for the HTTP traffic. In just this one dataset alone, we dropped from 9+ GB/s to <2 GB/s in compressed bytes traffic. Even though this is currently the highest cardinality dataset, the aggregations on it still gave us an approximate 80% reduction on the wire.

This aggregation feature is powerful for datasets that can collapse easily, especially for use cases like usage metrics where accuracy on the sums and counts is paramount. It also means we can offer producer teams another option to reduce resource usage besides sampling, which we did. Like Ready-Analytics, we created a generic in-house one-click aggregating analytics product, called Ready-Aggregates. As we continue to iterate on this new feature in the pipeline, we expect to see savings continue to mount.

Impact

The starkest proof of this exponential growth is how rapidly traffic growth consumes headroom.

Take Ready-Analytics for example, where two of the three mechanisms, load balancing and sampling techniques, were applied. In mid-May, load balancing dropped traffic by 50%, plunging from ~26 GB/s to ~13 GB/s. Two months later, traffic had already started surging back up to ~20 GB/s. That’s about half of the reduction, erased by organic traffic growth. We then created even more headroom by reducing this dataset’s throughput rate to the single digits, ~8GB/, when sampling rolled out.

Without both interventions, Ready-Analytics alone would have breached 60 GB/s by September. By processing less data in centralized data centers, we also save a significant amount of CPUs and memory. The following graphs show the impact of load-balancing and sampling in Logfwdr on the CPU and memory usage of just the Ready-Analytics receivers: a ~50% reduction, regaining ~750 CPUs and 3.5 TiB of memory.

Across the entire pipeline altogether, from spring to fall, load balancing (~38 GB/s saved), sampling (~25 GB/s saved across top datasets), and aggregating (~7+ GB/s so far), eliminated ~70 GB/s of compressed traffic from our backbone. These cliff drops provide immediate relief.

If we zoom out such that we look at five years from now, the changes made in this year alone have just as much impact as the short-term benefits. We’ve halved the amount of data we’d be processing in another half a decade’s time. The structural and algorithmic optimizations we have and will continue to make are essential to keep hardware demands sustainable.

If you’re interested in helping us solve these challenges at scale, we’re hiring!

How Anthropic’s Dynamic Workflows Coordinate Claude Agents

The AI Engineer New York 2026 conference kicked off this morning with a series of workshops, including Anthropic discussing how to orchestrate its Claude Managed Agents. Of particular interest was a brand new feature, announced on Friday, called dynamic workflows — or simply “flows,” as the presenters repeatedly called it.

Flows are defined as “a new type of multiagent orchestration, built for your most ambitious workloads.”

CJ Avilla and Harrison Stall, both Members of Technical Staff at Anthropic, began by invoking some operating system projects of the past — from Ken Thompson building the original Unix operating system, through to Linux evolving from one person (Linus Torvalds) to layers of trusted maintainers. The lesson: agents need the same level of organization in order to do the types of big, ambitious projects Anthropic envisions for dynamic workflows.

“I think a lot of us who are orchestrating and managing lots of agents now might start to feel this feeling of being the bottleneck and being the breaking point as we have lots of agents contributing tons and tons of PRs,” Avilla said. “And we’re sitting there in our GitHub trying to approve PRs and make sure that everything works as expected.”

From agent rosters to dynamic workflows

The pair noted that dynamic workflows began in Claude Code as the “a harness for every task” concept. But flows can run longer than a single agent or a roster. The basic idea is that Claude chooses the organization of agents.

“Flows are essentially the next version of multi-agent orchestration,” said Stall, “where you can let Claude fully orchestrate the entirety of its own multi-agent topology.”

The way this works is that the lead agent creates a plan for how it wants to accomplish tasks. Claude then writes an orchestration program, which launches agents, collects results, and manages information flow.

Previously, Claude Managed Agents required developers to configure a coordinator and a roster of subagents. With dynamic workflows, Claude itself determines how to divide and orchestrate the work.

“Across multiple different phases of the multi-agent orchestration, it’s able to accomplish discrete, verifiable units of work without you having to manage any of the interconnections between these things,” Stall said.

That said, Avilla noted that the user can introduce specialist sub-agents if they wish.

“It’s also possible in the agent config to pass in pre-configured sub-agents,” he said.

All of this is available in Claude Console, the interface used by developers accessing Claude through API — the whole point of Claude Managed Agents.

The presenters then showed a relatively simple workflow of a stock watchlist scanner. Although this was far removed from the big, ambitious projects Anthropic is encouraging, it did illustrate the basic pattern: a scan phase distributed individual tickers to agents with isolated contexts, and a later review phase examined the findings before producing a report.

Q&A: Budgets and the limits of self-improvement

The audience Q&A surfaced a number of potential problems. One audience member asked how Claude decides how many agents a task needs, and could a simple ticker scan trigger hundreds of sub-agents?

“The answer really is evals and lower defaults,” Stall replied, noting that ambitious tasks generally require explicitly encouraging greater parallelization.

One enduring concern with agent orchestration is maintaining control over your token budget. Someone asked whether the lead agent knows how much money it has available?

Stall replied that the model does not know its budget while running, but that developers can set a session budget. He added that informing models of their budgets could make the agents “a little bit anxious,” which elicited chuckles from the audience.

A related question was how can developers make repeated flows cheaper and more efficient over time?

Outside of asking Claude to examine the costs incurred, Avilla suggested another relatively new feature be used: dreaming. In the documentation, “dreaming” is defined as a research preview feature. A dream “reads an existing memory store alongside past session transcripts, then produces a new, reorganized memory store,” with duplicates merged, “stale or contradicted entries” replaced, and “new insights surfaced.”

Avilla described dreaming in the flow context as being able to “crystallize and basically improve the memory store that is related to those sessions.”

For the stock watchlist example, someone asked whether the watchlist flow can improve itself? For example, recognize that its scanning model is inadequate and change the next scheduled run?

Stall said this wasn’t built in, but he and Avilla suggested hill-climbing and dreaming could be used to improve the loop.

What about visibility into the actions of the sub-agents, another audience member asked.

Avilla replied that yes, developers can always inspect that through graphing functionality inside Claude Console.

“You can tell, what did the lead agent actually pass to the sub-agent? You can look at that payload here to deeply understand what is actually happening for every transition in this entire graph.”

Another interesting question was whether the subagents can communicate with each other?

Stall said the agents share a filesystem and can use it to exchange information, but developers cannot directly instruct one workflow subagent to message another through the API.

Flows cost much more, but are designed for big tasks

In the watchlist-scanner comparison, Avilla said flows cost “much more” than a single-agent approach, but were also “much more effective at finding all of the details.”

The bigger question is how ambitious can flows be, really? One audience member asked whether dynamic workflows can power large scientific research projects, referencing OpenAI’s recently announced proof concerning the Navier–Stokes Millennium Prize problem.

While Stall wouldn’t be drawn on specifics about how Anthropic computes large scientific problems, he said it is their goal to enable general users to tackle those problems too.

“Flows are basically a way to throw test-time compute at hard problems and get more capability faster out of the models,” he said. “We think, especially as an API service, that unlocking the power of this is the first step for us making these types of discoveries, or scientific progress, broadly doable by the general public.”

Today, we release LFM2.5-24B-A2B, a 24B-parameter reasoning model with just 2B active parameters, built for fast, private agents on-device. It is the largest and final model in the LFM2.5 family, which now spans two orders of magnitude: from LFM2.5-230M to LFM2.5-24B-A2B.

LFM2.5-24B-A2B is competitive with Qwen3.6-35B-A3B, a model with ~50% more total and active parameters, on five of eight agentic and tool-use benchmarks, scoring 48.09 on LiveClaw versus 38.19 and 27.69 on AutomationBench versus 8.72. Because only 2B parameters are active per token, it runs up to 1.7× faster than comparable MoEs on-device, with 184 tokens/s on an Apple M5 Max and up to 21K output tokens/s on a single NVIDIA B300 GPU.

The base (LFM2.5-24B-A2B-Base) and post-trained (LFM2.5-24B-A2B) models are open-weight and available today on Hugging Face and our Playground. Check out our docs on how to run and fine-tune it locally.

What changed since LFM2-24B-A2B

LFM2.5-24B-A2B builds on our previous LFM2-24B-A2B release, with an expanded vocabulary and context window, scaled-up pretraining, and large-scale reinforcement learning. Unlike its predecessor, LFM2.5-24B-A2B is a reasoning-only model that produces an explicit chain of thought before its final answer. We adopted this strategy to leverage its high decode speed and improve answer quality.

Architecture. It keeps the 40 layers, 64 experts per MoE block with top-4 routing, and the same hybrid of gated short convolutions and GQA. The two architectural changes are the context window extension from 32,768 to 131,072 tokens, and the in-place tokenizer expansion, which doubles the vocabulary from 65K to 128K tokens for better non-Latin tokenization.

Pre-training was scaled up from 17T tokens to 33T tokens.

Mid-training has two phases. The first runs 2T tokens at 32K context on curated, higher-quality data weighted toward reasoning, math, code, instruction following, and multilingual text. The second runs 300B tokens at 131K context, weighted toward long context data. Tool calls and multi-turn trajectories appear throughout both phases to prepare the model for agentic workloads.

Post-training turns LFM2.5-24B-A2B-Base into the agentic LFM2.5-24B-A2B in a five-stage pipeline: (1) Supervised Fine-Tuning (SFT), (2) Teacher Specialization, (3) non-agentic and (4) agentic Multi-Domain On-Policy Distillation (MOPD), and (5) Agentic Reinforcement Learning (Agentic RL), training the model inside agent harnesses, such as OpenClaw, Hermes Agent, Pi, and OpenCode.

During teacher specialization, LFM2.5-24B-A2B exhibited well-known reward-hacking behaviors: searching for the final answer in a repository's git history or on platforms like GitHub, PyPI, and Hugging Face. More surprisingly, it even figured out it was in a sandbox.

This behavior looks emergent but might be explained by training data containing similar patterns. We tightened our sandboxes in response, and all reported results below come from sealed evaluation environments.

Benchmarks

We evaluated LFM2.5-24B-A2B across 16 benchmarks covering tool use and agentic workflows, knowledge, instruction following, math, and coding. Despite being the smallest model in total and active number of parameters, it is competitive with, and often outperforms, larger MoEs with ~50% more total and active parameters, such as Qwen3.6-35B-A3B.

LFM2.5-24B-A2B leads or matches the competition on five of the eight tool-use and agentic benchmarks (AutomationBench, BFCLv4, ToolSandbox, LiveClaw, and τ³-Bench Banking), with its widest margin on AutomationBench, where it scores more than three times the next-best model. It also leads on all three instruction-following benchmarks. Larger models keep an edge on knowledge-heavy benchmarks like GPQA Diamond, HLE, and AA-Omniscience, and on coding benchmarks like SWE-Bench Verified (OpenCode) and SciCode.

The results make LFM2.5-24B-A2B an ideal foundation for agents that need to reason, call tools, and run reliably on your device. For knowledge-heavy workloads, we recommend pairing LFM2.5-24B-A2B with retrieval or web search, which plays to its tool-calling strength.

Fast inference everywhere

LFM2.5-24B-A2B ships with day-one support across the inference ecosystem:

• llama.cpp — GGUF checkpoints for efficient edge inference
• MLX — Optimized inference for Apple Silicon
• vLLM — GPU-accelerated serving for production throughput
• SGLang — High-performance GPU serving framework
• ONNX — Cross-platform inference across diverse accelerators

Edge inference. Due to the efficient LFM2 architecture, LFM2.5-24B-A2B is the fastest of the compared MoEs at reading in prompts and generating answers. It decodes 184 tokens/s on an Apple M5 Max and 114 tokens/s on an AMD Ryzen AI Max+ 395, up to 1.7x faster than the next-best model, while using the least memory.

GPU inference. To demonstrate the competitiveness of LFM architecture we compare the GPU inference throughput to other similarly sized MoE models. We measure GPU throughput (total output tokens / wall time) on a single NVIDIA B300 GPU using a sustained-load setting: at each concurrency level, we continuously maintain the target number of in-flight requests, replacing each completed request immediately.

We benchmark each model with SGLang 0.5.22, 1,024 input tokens, up to 256 output tokens, in BF16. LFM2.5-24B-A2B is the fastest model in its size class, reaching over 21K output tokens per second at high concurrency.

Run local agents with LFM2.5-24B-A2B

LFM2.5-24B-A2B’s size, speed, and capabilities make it a great choice for agents that run continuously on your own hardware.

The point of the demo is not the individual tools. It is that the tool-dispatch loop feels interactive on consumer hardware: ask, propose, confirm, run, repeat, all in well under a second per dispatch, with full audit trails and your data never leaving the device.

Get Started

Start building today with LFM2.5-24B-A2B, available on Hugging Face.

For API inference, you can also sign up for Liquid Console. The model is priced at $.10/1M input tokens (at $.05 for cached input) and $1.00/1M output tokens.

With LFM2.5, we're delivering on our vision of AI that runs anywhere. These models are:

• Open-weight — Download, fine-tune, and deploy.
• Fast from day one — Native support for llama.cpp, MLX, and vLLM across Apple, AMD, Qualcomm, and Nvidia hardware
• A complete family — From base models for customization to specialized audio and vision variants, one architecture covers diverse use cases

Citation

For citations, please use the following reference or BibTeX:

Liquid AI, "LFM2.5-24B-A2B: Built for Fast On-Device Agents", Liquid AI Blog, Oct 2026.

@article{liquidAI202624BA2B,
  author = {Liquid AI},
  title = {LFM2.5-24B-A2B: Built for Fast On-Device Agents},
  journal = {Liquid AI Blog},
  year = {2026},
  note = {www.liquid.ai/blog/lfm2-5-24b-a2b},
}

NVIDIA Run:ai Is Now Open Source as Part of NVIDIA DSX AI Factory Platform

NVIDIA is making the full NVIDIA Run:ai platform available as open source software, giving customers, developers, and ecosystem partners access to production-grade AI workload and GPU orchestration capabilities. This release expands the NVIDIA DSX AI Factory Platform by establishing NVIDIA Run:ai as an open foundation that enables the broader ecosystem to bring differentiated solutions to market faster in response to evolving customer needs.

Over the past several years, NVIDIA Run:ai has helped organizations run AI workloads on Kubernetes at scale by dynamically allocating GPU resources and managing workloads across the full lifecycle, from data processing and training to inference.

By open sourcing NVIDIA Run:ai platform capabilities as part of NVIDIA DSX AI Factory, it is now possible for every NVIDIA DSX ecosystem partner and AI cloud to increase workload throughput, improve GPU utilization, and operate shared AI infrastructure more efficiently and effectively.

This post details the open source release, which includes the complete NVIDIA Run:ai platform and four components that can also be adopted independently: KAI Scheduler, GPU Fractioning Operator, KAI Resource Management, Workload Map. Together with additional platform code, these components form the integrated NVIDIA Run:ai platform. Platform teams and ecosystem partners can adopt NVIDIA Run:ai as an integrated whole, build on it for their own products and services, or integrate individual components based on their requirements.

How to adopt open source NVIDIA Run:ai

NVIDIA Run:ai can be adopted directly as open-source software or through NVIDIA DSX ecosystem partner offerings.

Deploy the open source platform directly

The complete source code for NVIDIA Run:ai is available in the NVIDIA Run:ai repository within the NVIDIA DSX AI Factory GitHub organization. Teams can inspect the code, contribute to its development, build on top of the platform or adopt its modular components independently.

The complete open source NVIDIA Run:ai platform is also available on NVIDIA NGC as a Community Product, with a Helm chart for installing the integrated stack.

Note: The NVIDIA Run:ai source code is governed by its applicable open source licenses. Downloading the Community Product from NGC requires acceptance of the applicable NVIDIA Software License Agreement and Product-Specific Terms for NVIDIA AI Products. No paid NVIDIA Run:ai subscription or NVIDIA support entitlement is required for the Community Product, and NVIDIA enterprise support is not included.

Adopt open source NVIDIA Run:ai through NVIDIA DSX ecosystem partners

Open source NVIDIA Run:ai gives NVIDIA DSX ecosystem partners direct access to AI workload and GPU orchestration innovations they can use in their own NVIDIA DSX AI factory solutions. By adopting the complete platform or integrating individual components, partners can bring those innovations to market faster and respond more quickly to evolving customer and operational requirements.

• Crusoe integrates NVIDIA Run:ai with Crusoe Managed Kubernetes, combining GPU workload orchestration with managed Kubernetes and GPU infrastructure.
• Mirantis extends k0rdent AI with NVIDIA Run:ai to deliver a lifecycle-managed, Metal-to-Model AI factory stack that automates infrastructure provisioning and maximizes GPU utilization.
• Nebius offers NVIDIA Run:ai as a one-click application deployment in Nebius AI Cloud, giving customers a streamlined way to deploy and operate the complete platform on Nebius Managed Service for Kubernetes.
• OpenNebula Systems integrates NVIDIA Run:ai with the OpenNebula AI Cloud Platform through OneKS, combining GPU workload orchestration with infrastructure provisioning and lifecycle management for open and sovereign AI clouds.
• Rafay is expanding its NVIDIA Run:ai integration to deliver it as a fully managed service. Rafay automates the entire stack, from GPU infrastructure and clusters to the NVIDIA Run:ai control plane and tenants, so AI cloud providers and enterprises can offer it through their own self-service catalogs.
• Saturn Cloud integrates NVIDIA Run:ai to help AI cloud operators launch white-label AI inference services through its Token Factory platform, combining GPU orchestration with dedicated and multi-tenant model serving, per-token metering, and automated billing.
• Spectro Cloud integrates NVIDIA Run:ai into PaletteAI, enabling customers to deploy it through PaletteAI Studio and manage it with the same lifecycle automation used across their AI infrastructure.
• vCluster provides NVIDIA Run:ai through pre-validated deployment templates that stand up a complete environment per tenant, allowing operators to strengthen tenant boundaries while NVIDIA Run:ai continues to schedule across one GPU fleet.

For NVIDIA Enterprise AI Factory deployments, NVIDIA Run:ai continues to be available through NVIDIA-supported commercial offerings including as a standalone product, through NVIDIA Mission Control and NVIDIA AI Enterprise, and select cloud marketplaces. Availability, licensing, and support terms vary by offering.

Modular open source components of the NVIDIA Run:ai platform

This section details the four components included in the open source release: KAI Scheduler, GPU Fractioning Operator, KAI Resource Management, and Workload Map. With additional platform code, these components form the integrated NVIDIA Run:ai platform. You can adopt NVIDIA Run:ai as an integrated whole or integrate individual components based on your unique requirements.

KAI Scheduler: The scheduling engine behind NVIDIA Run:ai

KAI Scheduler is the Kubernetes-native scheduler that powers the NVIDIA Run:ai platform. NVIDIA released KAI Scheduler as open source software under the Apache 2.0 license and contributed it to CNCF as a Sandbox project. KAI remains the upstream engine behind NVIDIA Run:ai, and all scheduler development happens in the community repository, so every improvement flows through the same codebase.

KAI Scheduler is purpose-built for GPU workloads at scale, coordinating:

• Gang scheduling with prescheduling in-memory simulation, so multipod jobs are placed all-or-nothing and aren’t evicted needlessly
• Fair-share (including time-based fair-share) and quota allocation that keeps resource shares balanced across teams
• Topology awareness and bin-packing at the scheduling-decision level
• GPU sharing, which allows multiple workloads to share single or multiple GPUs (MIG, MPS, time sharing, HaMi, CUDA 13.4 MPS fractioning)
• Dynamic Resource Allocation (DRA) support

GPU Fractioning: An operator for GPU fractions on Kubernetes

GPU Fractioning Operator brings CUDA-native GPU fractioning to Kubernetes and the proprietary implementation has been retired in favor of the native capability available in CUDA 13.4. The CUDA driver enforces a hard limit on GPU memory for each workload, and each workload sees only the GPU memory allocated to its fraction. What is still needed is a clean way to consume it on Kubernetes. This is what GPU Fractioning Operator provides: an operator that enables CUDA GPU fractions on a cluster, along with a metrics exporter for per-pod visibility into fractions in use. It is a Kubernetes integration layer that allows workloads to use CUDA-native fractioning, and it is scheduler-agnostic.

KAI Resource Management: The organizational layer

While the scheduler decides how work is placed, KAI Resource Management governs who gets what:

• Projects and departments: The organizational structure, or “org layer,” that maps resources to the teams and initiatives that consume them.
• Resource management with an organizational hierarchy: The ability to allocate, guarantee, and share GPU capacity across that org structure, with fair-share and quota semantics.
• Node pools: Grouping and targeting of heterogeneous hardware so workloads land on the right resources.

Workload Map: A workload-management contract for Kubernetes

Workload Map is the contract NVIDIA Run:ai uses to support any workload type. KAI Scheduler uses it for scheduling and gang semantics; the rest of the platform uses it for workload discovery, monitoring and lifecycle management.

Workload Map provides a consistent way to treat these workloads as first-class objects throughout their lifecycle:

• Describing pods, components, and roles
• Submitting and configuring
• Scheduling with gang and topology awareness
• Observing status and health consistently
• Applying policy at admission or runtime

Related open source platform software

The following open source projects address complementary AI infrastructure challenges. They can be adopted independently or incorporated into broader solutions that include the complete NVIDIA Run:ai platform or selected components.

Model Streamer: Reducing cold-start latency

Cold-starting an inference workload on Kubernetes can take several minutes, during which time GPUs are allocated but idle for a single step: loading model weights from storage onto the GPU. Model Streamer reads weights concurrently and streams them directly into GPU memory, cutting load time for large models.

Grove: One API, any inference architecture

Emerging workload patterns—including agentic pipelines, disaggregated serving and mixture-of-experts training—consist of multiple connected components that must scale together. Grove provides a Kubernetes API for orchestrating these workloads, from a single pod to deployments spanning tens of thousands of GPUs.

Frontier Models for Every Robot

We are making our latest models available for training and inference through the Pi API beta.

Deploying robots is challenging. Besides identifying the right use case and building the right hardware, developers need models intelligent enough to perform the task at hand. General-purpose robotic foundation models such as π0 and π0.5 offer a promising way to tackle this challenge. They provide a strong foundation of physical knowledge and capabilities, substantially reducing the data and effort needed to adapt to new tasks, environments, or robots. But adapting them still requires ML infrastructure, compute, and complex data pipelines, which are difficult in their own right. What if the latest and most powerful robotic foundation models could be adapted to each application through a simple and ready-made API?

The Pi API does that for you. You upload data, launch fine-tuning on compute and infrastructure we manage, and access fine-tuned models via a hosted gateway to run inference. The latest model available through the API already provides more data-efficient fine-tuning and improved capability for our partners. Since Pi can update the models underpinning the API rapidly, we plan to continue enabling access to our latest and most capable models. Launching the beta is our first step in providing the physical intelligence foundation the community can build upon and enabling end-to-end autonomy.

To ensure that the API supports diverse applications, we sought to answer two key questions. First, do our models support a broad range of applications and robotic hardware in diverse industries? Second, how easily does the API enable developers to iterate toward useful, practical autonomy?

Supporting a broad range of applications in diverse industries

To discover how broadly our models can adapt, we work closely with companies deploying robots to build autonomy systems for their applications. These collaborations let us validate how well our models perform across different tasks, hardware, and operating environments.

Actor

Actor deploys autonomous heavy machinery. Their autonomous wheel loader scoops material and loads it into a dump truck during a real commercial deployment without any operator inside the machine.

Enabling independent iteration towards practical autonomy

Across these initial collaborations, a common pattern emerged. The challenges differ from task to task: an inside-out garment, an ingredient that wouldn’t stay in a scoop, a manufacturing part that landed in the wrong position. But the process for improving performance was much the same: collect demonstrations, train a model, test it on the robot, and use the failures to decide what data to collect next. We built the API to let developers run this iteration loop themselves, using our latest models.

API workflow: Upload your data, fine-tune a π model, and run it on your robot through hosted inference. Use evaluation data to guide the next iteration.

We gave a small number of companies early access to the API to test whether they could improve autonomy on their own. We were impressed by how quickly they got started and began making progress. Their experiences offer a glimpse of what you could do with your own robots and data.

Almond

Almond builds Axol, a dual-arm robot for physical AI builders. Their goal is for Axol to build itself. Here, Axol deburrs spacers used in its own assembly, running a model the team obtained after iterating with the Pi API for four days.

Most applications shown above, from Japan to Switzerland to deployments across the United States, ran with cloud-hosted inference through the API. These early deployments spanned a range of environments and tasks and highlighted areas for improvement, including network connectivity challenges for some.

Improving from feedback

The more our models are used, the more we learn how to improve them: by understanding the potential and limitations of our current models in real-world applications, we can make the next generation of models more broadly applicable, and make tangible progress toward truly general physical intelligence. But the range of real-world tasks is enormous, and understanding the broad range of tasks that robots could do requires making our models available for these tasks. Real-world robotic applications are not easy: tackling robotic construction, robotic surgery, or warehouse automation each requires an entire company. If each such application requires solving the physical intelligence problem from scratch, the challenges become insurmountable. By making our models available through the API, we accelerate the growth of the robotics ecosystem and, in the process, advance our own understanding of physical intelligence.

The examples above show that the models we develop can be used for real, useful applications, and that our partners are able to use the API to independently iterate on policies and improve autonomy on their tasks. We’re still early, and feedback from developers will help shape future releases.

If you would like to participate in the beta, please tell us what you want to build.

If you would like to help develop the models and tools behind this work, we’re hiring across research, infrastructure, hardware, people, and operations.

OpenCode 2.0 is a major overhaul. It draws on millions of daily users' experience to deliver a system that can flex to everything an agent needs to be. There are quite a lot of new features, performance improvements, and bug fixes but here are some of the more impactful user-facing changes.

The Service

From the beginning OpenCode adopted a client/server model. However, this was not something it took advantage of by default and was mostly used by power users.

In 2.0 this server now automatically runs as a single background process on your machine. When you open up a TUI, the web interface or the desktop app they're all talking to the same central process.

If you're using the programmatic client @opencode/client to make your own scripts, they will autodiscover the local service and just work. This is particularly useful for scheduled tasks. You can also call it via CLI by using opencode api commands.

You can expose it to other hosts and run /pair or opencode pair to connect it to other applications. We have native apps in the works that take advantage of this flow.

The API

The old API grew haphazardly as we and the world collectively learned what agents are and should be. It was bad.

We started from scratch and examined all the weird use cases across the millions of users who use OpenCode every day. It now supports nearly anything you need to be able to do.

OpenCode is also aware of its own API and will call it to do useful things like moving the current session into a git worktree when starting new work.

We've also shipped a new client package @opencode/client that contains clients for vanilla JavaScript as well as Effect.

import { OpenCode } from "@opencode/client"
import { Service } from "@opencode/client/service"

const endpoint = await Service.ensure()
const client = OpenCode.make({
  baseUrl: endpoint.url,
  headers: Service.headers(endpoint),
})

const session = await client.session.create({
  location: { directory: process.cwd() },
})

await client.session.prompt({
  sessionID: session.id,
  text: "Review the current changes",
})

Code Mode

The models love to write code and OpenCode 2.0 takes advantage of that more than any other coding agent. We've built a minimal JavaScript interpreter in the @opencode/codemode package.

This package ingests MCP servers or OpenAPI endpoints, converting them into functions that the agent can call in a script. It can run these scripts natively without the complexity of Node.js VMs or embedding complicated solutions like QuickJS.

This lets your agent write scripts that can do things like call a tool, map over the results and call another tool. Single round trip instead of calling them one at a time.

All MCP servers in 2.0 are opted into codemode by default. This means you can add a thousand of them with minimal context bloat and your agent will discover and compose them to get things done.

Background Tasks

The latest batch of models are incredibly good at orchestration and it is important for harnesses to let them express the full extent of that capability.

First, we've added background subagents. This allows the primary agent to kick off some work to another one while it continues.

This happens automatically but you can also trigger it manually - even with a different model. It lets you do things like “spawn a background fable subagent to review this code” while you keep prompting.

Second, we've added background shell commands. The shell tool can be invoked asynchronously so long-running work does not have to block the primary agent. It'll be notified when things are complete.

If any foreground shell command or subagent takes longer than you expect, you can hit a hotkey to move them to the background so you can keep prompting.

Plugins

Although OpenCode 1.0 had a plugin system, it never got the attention it needed. To correct that, we forced ourselves to implement nearly every OpenCode 2.0 feature as an internal plugin and there are now 80+ of them. This guarantees that the Plugin API stays well maintained.

We've also promoted TUI plugins from experimental to stable. Since it is all powered by OpenTUI, you can build nearly anything.

We also spent quite a lot of time ensuring everything in OpenCode 2.0 can be hot-reloaded. So it can write a plugin for itself mid-session and use it right away.

You can ask OpenCode to build whatever plugin you want and it knows how to. But if you do want to read the docs, they are available online.

The SDK

OpenCode can also now be used as a library with the @opencode/sdk package. This is the exact same code that powers our CLI.

This means you can strip it down and make your own flavor of OpenCode that runs on a server or in specialized environments like Durable Objects. And then you can connect to it from any OpenCode client since it speaks the standard OpenCode server protocol.

It also has an optional Effect-based API.

Upgrading

To upgrade the CLI, make sure you're on the latest 1.x release, then run opencode upgrade --major.

To upgrade your desktop app, download the latest from our website.

There are some breaking changes:

• 1.0 plugins will not work in 2.0
• Server API is completely different
• tui.json config is moved to json

There are a lot of other changes but they are backwards compatible. It is worth pointing OpenCode at our migration documentation so it can migrate things for you.

Today, we’re sharing that Character.ai has initiated a voluntary Chapter 11 bankruptcy process to facilitate a court-supervised sale of the company.

Over the past year, we’ve taken meaningful steps to sustain and improve our business amid significant legal, regulatory, and operational headwinds. After a comprehensive review of our available alternatives, our board determined that this court-supervised sale process provides us with the best opportunity to maximize value for all of our stakeholders.

We hope that the sale process will yield an actionable proposal that will allow continued operations of the Character.ai platform. If such a bid is unavailable, however, the platform will be wound down.

As we navigate this process, maintaining a safe and engaging experience for our community remains a top priority.

What This Means for Our Community

The Character.ai platform remains up and running, and you can continue to access all services at this time.

We know that this news may raise questions for some of you. To learn more, please see our FAQs below. And if you need support, you can find helpful resources here.

1. Why did Character.ai file for Chapter 11?

Over the past year, we have taken meaningful steps to sustain and improve our business amid significant legal, regulatory, and operational headwinds. After a comprehensive review of available options, we determined the best path forward was to begin a Chapter 11 case to pursue a court-supervised sale of all or substantially all of our assets. We believe that this court-supervised process both maximizes the value of our business and provides the best opportunity for continued service to our platform users.

2. How long is the sale process expected to take?

We currently expect that the court-supervised sale process will be complete by the end of November or perhaps early December 2026.

3. What does this mean for users?

The Character.ai platform remains up and running, and you can continue to access all services at this time. We're focused on finding the best path forward for our platform and community.

4. Is my paid subscription still active?

Yes, your subscriptions remain active, and billing is unchanged for now. If the service changes in a way that affects paid features, we intend to notify subscribers in advance.

5. What happens to user data and chats?

Your information continues to be protected under our Privacy Policy, and our data privacy and security practices are unchanged. As a reminder, you can delete your account or export your data through the app or the Character.ai website.

To learn more, you can read the full press release HERE. Court filings and additional information relating to Character.ai’s Chapter 11 case can be found HERE, a website administered by Character.ai’s claims and noticing agent, Stretto, Inc.

PSA: starting today GPT 6.1 Sol has a default context window of 500k (from earlier 272k)

This should mean fewer (2-3x) compactions on long running tasks and faster E2E task completion!

All at no extra charge across Codex & ChatGPT Work - Enjoy!!

Moondream is joining Prime Intellect

We’ve acquired Moondream. Founders Vik Korrapati and Jay Allen are joining Prime Intellect to lead and scale inference, and to accelerate our work on multimodal models, including vision and computer use.

Moondream was one of our earliest customers, and we’ve long admired what Vik and Jay built with a tiny team. They've shipped state-of-the-art open-weight vision-language models with millions of monthly downloads. They also built Photon, an inference engine that compiles each model into a single GPU program, along with custom GPU kernels and the megakernel compiler behind them.

“Moondream is proof that small, efficient models can beat giant ones at specific tasks. Prime is building for that same future: many specialized models that companies own. We were Prime customers long before we joined. Now Photon can power far more than our models, and our models get Prime’s full training stack.” — Jay Allen, co-founder of Moondream

Moondream 3.1 leads on object detection, aerial images, charts, and crowded scenes like store shelves. It does this at 34 requests per second, about 24x faster than the next most accurate open model. Compared with Meta's new frontier model Muse Wonder, Moondream 3.1 reaches 80% of its accuracy at pointing at objects in photos, at about 1/1000th of the cost.

Much like Prime Intellect, Moondream made the bet that a model and its underlying infrastructure have to be built together, and that a specialized, efficient model running on the right infrastructure beats a generalist at a given task. We’re excited to double down on this together and help everyone train, deploy and serve frontier multimodal models across video, image, voice and computer use.

Why inference

We launched Prime Inference because serving is where a model’s usefulness gets decided: inference dictates how fast a model responds and what it costs to run.

This is where Moondream’s systems work pays off: answers come back in tens of milliseconds, often 40x+ faster than calling a frontier API. On a single H100, Photon runs more than 60 Moondream inferences per second, which is fast enough for live video. Put together, Moondream’s models get Prime’s full training stack, Photon gets to power far more than Moondream’s models, and Prime customers get a multimodal stack that was built as one system rather than assembled from parts.

Photon and Moondream’s kernel work are being integrated into Prime’s stack. It is a commitment to having the fastest inference on the market and making our customers run models as well as they train them.

Building together

Moondream built exceptional models and a specialized inference engine. Prime’s open superintelligence stack connects evaluation, fine-tuning, reinforcement learning and inference. Together, we combine our training platform with efficient serving and bring on Vik and Jay’s deep expertise in vision and computer use.

We’ve already started shipping. Moondream 3.1 is now available through Prime Inference and powered by Moondream’s Photon engine. Clef and Clef Flash are also live through Prime Inference and OpenRouter, with Clef priced at parity with Jev and Clef Flash at half the price.

In the next few days, every customer of Moondream Cloud will receive credits on our platform, usable for Moondream models and our broader training and inference offerings. Moondream will remain our brand for small, efficient multimodal models.

Our mission is to make open superintelligence accessible to every company. If you’re building vision models, computer-use agents or need the fastest inference on the market, we’d love to work with you.

References

1. Korrapati, Vikhyat. “moondream2.” Hugging Face. Accessed October 13, 2026.
2. Moondream. “Photon: Official Moondream Inference Engine.” Accessed October 13, 2026.
3. Moondream. “Moondream 3.1: Beyond Benchmarks.” Moondream Blog, 2026.
4. Prime Intellect. “Pointing Accuracy and Cost per 1,000 Images: Moondream 3.1 and Frontier Models.” Unpublished internal evaluation, October 2026.
5. Prime Intellect. “Prime Inference: Fast, Reliable Serving for Frontier Open Models.” Prime Intellect Blog, 2026.
6. Moondream. “Photon Serving Benchmarks, NVIDIA H100.” Unpublished internal measurements, October 2026.
7. Vigliarolo, Brandon. “Cloudflare Tries to Outplay Jev with Open-Weight Clef Models.” The Register, October 1, 2026.

Direct the performance, not just the words.

Tell Drama 3 how a line should feel, in your own words. Add a sound, emotion, or pause where you want it, and control exactly which words change.

One line, five directions

I'm fine. Really. Go on without me.

Plain text. Drama 3 reads it the way the words suggest.

Try a roast with Uncle Roger

Uncle Roger's licensed voice, directed by Drama 3. Pick a kitchen crime, hear his verdict, then write your own roast.

[horrified, staring at the plate] Haiyaa. Nephew, why you put ketchup in egg fried rice? [sigh] Fried rice need soy sauce. Need MSG. Need wok hei. Not tomato sauce! <slow>Uncle Roger cannot watch this.</slow>

More from Uncle Roger

Every take on this page is a Drama 3 generation of the exact text shown.

Haiyaa

“Haiyaa. Why you wash rice in colander? Rice is not pasta!”

exasperated, like a very disappointed uncle

Fuiyoh!

“Fuiyoh! You see that fire? That is wok hei!”

suddenly thrilled, voice jumping up

MSG!

“Uncle Roger tell you one secret. MSG is not bad for you.”

leaning in, conspiratorial

Five ways to direct, one script

Mix them freely in the same line. Every direction is plain text you can read, edit, and reuse.

[warm and relaxed, like talking to an old friend] It's been a while.

Describe it in your own words

Try natural-language directions, beyond the preset tags: emotion, intent, pacing, who they're talking to.

Alright, [sigh] let's try again.

Add a sound, emotion, or pause

Put a sigh, a laugh, a breath, or a short pause where you want it, and nowhere else.

I'm fine. Really. <whisper>Go on without me.</whisper>

Control exactly which words change

Select a few words and pick a scoped tag. Paired tags apply only to the words you select.

[像是在强忍着眼泪，却努力笑着]

[conteniendo las lágrimas, pero sonriendo]

[涙をこらえながら、無理に笑って]

I'm fine. Really. Go on without me.

Direct in your own language

Write tags and directions in English or your own language. The performance follows the direction, whatever language it's written in.

[defensive, slightly uneasy tone] I was home. [pause] Asleep.

Start with Auto Tag

Need a starting point? Auto Tag adds directions to your script. Keep what works and rewrite the rest.

Write the scene. Auto Tag directs it.

Give each speaker a voice, write plain dialogue, and let Auto Tag add the directions. Drama 3 performs the whole scene in one pass.

Int. Interrogation room – Night

1. Adrian · Detective

   <stress>You</stress> were there that night.

2. Delia · Suspect

   [defensive, slightly uneasy tone] I was home. [pause] Asleep.

3. Adrian · Detective

   [skeptical, questioning tone] Then why is your coat still wet?

4. Delia · Suspect

   It rained.

Direct from the API

Set the model header to drama-3 and send your script as it is. Directions, sounds, and paired tags all work in API requests.

curl https://api.fish.audio/v1/tts \
  -H "Authorization: Bearer $FISH_API_KEY" \
  -H "Content-Type: application/json" \
  -H "model: drama-3" \
  -d '{
    "text": "I’m fine. Really. <whisper>Go on without me.</whisper>",
    "reference_id": "f3a2b90078d54a65af4b95f63bc7798e"
  }' --output speech.mp3

Your script deserves a performance

Drama 3 is available now in Text to Speech.

Drama 3 FAQ

What is Drama 3?

Drama 3 is a text-to-speech model from Fish Audio built for direction. Alongside your script you can describe how a line should be performed, add sounds and pauses, and limit an effect to specific words.

How do I write directions?

Put a direction or a sound in square brackets where it should happen, for example [sigh] or [barely holding it together]. To change only some words, select them and pick a scoped tag such as Whisper or Slower from the Tags menu; the editor wraps them in a paired tag.

Can I write directions in other languages?

Yes. Write tags and directions in English or your own language.

Does Drama 3 support multiple speakers?

Yes. Add speakers in the Text to Speech editor, give each one a voice, and Drama 3 generates the whole dialogue together.

What does Preview mean?

Drama 3 is still improving. Results vary between takes, so generate a few and pick the best. We will keep updating the model while it is in preview.

Can I use Drama 3 through the API?

Yes. Call the Text to Speech API with the model header set to drama-3. The same tags work in API requests.

Science Corporation CEO Max Hodak announced that the company has implanted its vision-restoring chip, PRIMA, into its first patient with Stargardt disease, an inherited eye disease that gradually destroys central vision. Hodak, the former president and co-founder of Neuralink, the brain implant company, explained onstage at TechCrunch Disrupt how the company’s work with PRIMA fits into its broader pursuit of a novel brain-computer interface (BCI).

“The retina is part of the central nervous system,” Hodak said. “We consider cochlear implants, retinal prostheses, motor prostheses, these are all different types of BCIs.”

Hodak outlined a vision in which BCIs expand into a wide range of medical technology applications, rather than simply being a way to control computers.

While PRIMA is commercially available in Europe for patients who’ve lost their sight to geographic atrophy, an advanced form of age-related macular degeneration, the company believes its approach can be applied to multiple diseases, including Stargardt disease, which is currently considered incurable.

Stargardt disease affects the outer retina, causing the gradual death of the eye’s light-sensing cells while potentially sparing the inner retina, the part that passes visual signals onto the brain. It causes a central blind spot that gradually enlarges over time. Approximately 150,000 people worldwide have lost vision due to the disease.

“One of the nice things about this device approach, when I was saying the brain’s a computer, vision is electrical potential, like electrical activity down the optic nerve,” Hodak said. “That’s all vision is to the brain, and so if you can get the optic nerve to signal the rest of the brain correctly, then you can provide vision to it.”

The company says its first patient with Stargardt disease received the PRIMA implant in May as part of its ongoing trial at the Sydney Eye Hospital in Australia. During the patient’s first rehabilitation session, he saw a letter, and during the second, he was able to read a word.

To use the device, patients undergo an hourlong procedure that plants a small chip in the back of their eye, where the photoreceptors have degenerated. Then they wear camera-equipped glasses that transmit a view of the world to the chip. The implant essentially works like artificial photoreceptors.

“The device that this patient has is a two millimeter by two millimeter implant placed in the back of the eye, and so it’s like looking through a straw,” Hodak said. “It is not a big field of view color vision. It’s a patch in their central vision where … it’s black and white, but it is sharp. It’s high-contrast sharp, and so they can see a couple letters at a time. The next step is to make the field of view bigger. So to make a bigger implant, you have to deal with the curvature of the eye, and we need to make the electrodes smaller so that we get closer to native levels of detail.”

He continued, “I think we have a clear path. There’s a ‘next generation’ that’s being worked on that’ll be in humans in the next year, and over the next five years, I think we’ll be able to get pretty close to native acuity.”

When Hodak founded Science Corporation in 2021 after leaving Neuralink, the company outlined plans to develop advanced neural engineering and brain-computer interface technology. But first, the company wants to prove its methods work and develop a sustainable business, which is why it’s working to restore vision with the visually impaired.

As for Science Corporation’s brain-computer interface technology, it has previously said that its sensor will be implanted inside the skull and rest on top of the brain, unlike a Neuralink device, which is inserted directly into brain tissue.

The company has said it believes the device could help address neurological conditions, such as possibly monitoring neurological activity in patients with brain tumors.

“In the near term, we’re going to be applying our first clinical indication, which hasn’t been announced publicly, is a neurodegenerative disease that everybody’s heard of,” Hodak said. “We’re also looking at stroke. For example, if you’ve lost part of your brain because it’s been dead due to stroke, if you can get connections into the deep brain in two different areas, you can imagine adding new cortical areas, just like adding new brain areas entirely — something simply not possible with conventional electrodes. But, I’d say longer term, the long-term mission of the company is to understand how the brain creates the mind and to learn to build engineered brains.”

Hodak went on to note that Science Corporation’s belief is that many people will eventually use some kind of BCI. While the company isn’t designing for “healthy 40-year-olds,” he said, it believes people will eventually need some kind of BCI by the age of 60 or 70.

“We want to figure out how do we extend not just lifespan but health span,” Hodak said.

The Rise of DeployCos

Why the labs, hyperscalers and startups are all getting into AI deployment

Hi friends,

Earlier this year we saw both OpenAI and Anthropic start deployment companies, or DeployCos, for short. Essentially, these are entities whose job it is to embed engineers inside enterprises to help them adopt AI agents and get them working in actual workflows. In addition to the model labs, we’ve also seen hyperscalers also really lean into forward-deployed motions. At the same time, companies like Palantir and Accenture have continued to see continued momentum doing this work.

In this piece, I’ll talk about the lab’s DeployCos, why we’re seeing the rise of these DeployCos and what the playbook and landscape looks like.

The Lab’s DeployCos

First, it’s worth touching on the labs’ own DeployCos. Anthropic announced theirs in May, which is a $1.5 billion AI services firm set up with Blackstone, Hellman and Friedman, and Goldman Sachs, as well as other private equity firms. It launched in July as Ode with Anthropic and was built on an acquisition of Fractional AI. It’s aimed at midsize companies, starting with the private equity sponsors’ own portfolio companies.

OpenAI then announced the OpenAI deployment company, which raised over $4 billion, led by TPG. It’s majority-owned by OpenAI. OpenAI also acquired a firm, Tomoro, to get it off the ground, starting with 100+ FDEs on day one.

They are both quite similar. They have a separately capitalized entity and an acquired Applied AI/services firm as the core team, some of the labs’ own engineers inside of it, and the private equity sponsors’ portfolios as the initial customers.

The hyperscalers are running a version of the same play as well. AWS committed $1 billion to a forward-deployed engineering unit at the end of June.

Why We’re Seeing the Rise of DeployCos

AI is so powerful and magical so why are we actually even seeing these DeployCos? I think there are two primary reasons that are applicable broadly and then there are a few additional reasons that the labs in particular have started their own.

I think the first is the diffusion gap. These models can do a lot of valuable work, much more than they’re currently being used for. People often also use the term “capability overhang” to talk about how the capabilities that these models have are much further and broader than what they are being put to use for by most people. DeployCos are one way to address this diffusion gap and capability overhang.

The best evidence for this is probably OpenAI’s GDPval, which takes real work products across many different knowledge work occupations and has experts grade model outputs. Models can do over half the tasks better than the experts on the tasks, but most organizations are nowhere close to leveraging AI at that level.

The second reason is culture and organization alignment. Putting AI into practice isn’t as simple as just letting the models loose. You need to get access to the right systems. You potentially need to redesign the workflows. You need get buy in across the org. You need to change the way people do work. These are things that cut across teams and organizations, and it’s not necessarily any individual’s specific job.

AI obviously doesn’t solve these problems automatically and cannot figure out org alignment, incentives, and trust itself. This is a big part of why there’s a booming demand for good old consultants (branded differently) to come in to solve these things.

This is quite clear when looking at the demand for services for some of the incumbents. Accenture has booked about $11.5 billion of generative AI work over the last three years.

Palantir, which arguably pioneered the forward-deployed engineer over a decade ago, has accelerated revenue growth every quarter for the last 12 quarters. CTO Shyam Sankar quipped on a recent earnings call:

“Remember, only Palantir has FDEs. Everyone else has sparkling sales engineers.”

There are also a couple of secondary reasons for the labs starting DeployCos:

One is that deployment work generates long-horizon traces of how real work gets done across industries, which is valuable either as training data directly or just as insight to help labs know where to focus their model hillclimbing efforts.

Second is that model performance across the labs is relatively close, particularly for most enterprise workflows. Being the one embedded to actually deploy agents for a customer’s workflows creates a version of lock-in versus other model vendors.

Lastly, from a TAM perspective, building and deploying agents allows you to potentially charge for the real outcomes you deliver and so earn, justify, and generate more revenue than just tokens might by themselves.

Types of DeployCos

The DeployCos mostly run a similar playbook. FDEs will embed with the customer and start with a few higher-value workflows, where ideally the tasks are somewhat bounded and the outputs can be checked and verified.

They’ll understand the workflow, build a agent harness that wires the model into a company’s data and other systems, build evals as needed, and iterate on and deploy the agents once they clear some quality bar. Ideally, they will also build a learning loop such that it can get better in production.

Incumbents like Palantir and Accenture (and other consultancies and SIs) have been doing versions of this work for years and are one form of choice for these large enterprises. Broadly, the new forms of AI DeployCos fall into three types:

• Horizontal: Companies that are helping deploy AI across a wide variety of functions and industries, like the labs ventures, and others like Distyl and BrainCo. They have built some shared platforms and modules on top of which they build and deploy agents.
• Function-specific: These aim to be the trusted vendor for a specific function for companies across industries. Sierra and Decagon in customer support are one example (although those are branching out further) as well as Lio in procurement.
• Vertical-specific: These are companies trying to bring AI agents to enterprises within a specific industry. Tennr in healthcare and Happyrobot in Logistics are a few examples.

Under the hood, many of the function-specific and vertical-specific ones look quite similar. They’ve built a core system for some of the common workflows in their industry or function, but there’s a lot of last-mile work to be done to get it running inside each customer. They split their team between the people building the system and people deploying agents into customers who generally have titles such as agent deployment, forward deployed engineers, or deployment strategists.

One dirty secret is that many vertical AI application companies that sell to larger enterprises are actually also arguably DeployCos. They tend to do heavy FDE work because the workflows they support are very custom, there’s a lot of bespoke integrations and custom evals needed and a lot of change management in processes to actually get into production.

Closing Thoughts

The models are clearly good enough now and DeployCos are one of the primary ways in which we will be able to take those models and put them to work to drive real ROI within enterprises and close the diffusion gap.

Another approach being taken, which is worth its own piece, is the AI-native rollup approach: to buy the businesses and then infuse AI from within. Long Lake, which just closed its take-private of Amex GBT for $6.3B, and Sequence, which just took the insurance broker Baldwin private for $7.7B, are two companies taking this approach. For them, owning the asset allows them to potentially redesign processes as needed, infuse AI from within, and then capture all the upside from AI directly. However, it ends up being more capital-intensive and harder to scale.

Google has already added a few AI features to the Play Store, but a lot more are coming. The previously released Ask Play feature is expanding to offer more AI-powered discovery options in Google’s app store, and Google is also using AI to build a recommendation engine called Game Finder. For people who have embraced AI to build their own apps, the Play Store will soon offer a way to privately host and share those creations.

Google rolled out Ask Play in 2025 as a small chatbot interface on Play Store listings. It lets you ask questions about an app or game, either by typing it in manually or choosing from a list of suggested queries. Starting today, Ask Play is expanding into a more general way to search for apps and games. You ask the robot questions, and it generates recommendations that can include detailed comparison charts. Gemini will roll out a similar capability soon.

Google’s other AI discovery announcement focuses on games. The new Game Finder feature leans on all the usage data Google’s app platform has hoovered up over the years, featuring insights into the way 1.2 billion people play games on Android. It builds a profile called Gamer DNA and matches you with players who have similar DNA.

You can tune your DNA profile by rating the games you’ve played, which supposedly leads to more accurate recommendations. There will be game playlists to peruse, along with various contextual lists like relaxing, trending titles, and more specific lists based on mechanics you’ve seen in previous games. Game Finder also lets you add or remove tags to further adjust the games Google’s AI suggests. Google says you’ll eventually be able to prompt Game Finder with fairly specific game preferences, but it’s unclear how much customization will be available at launch. Game Finder and Gamer DNA are rolling out in the US today, with other markets following “soon.”

There’s a vibe for that

Despite its slow progress in coding-focused AI models lately, Google is continuing to push this as a core feature of its products. Anyone who has been tinkering with vibe-coded apps in AI Studio will soon have a direct pipe into the Play Store. This is not the same as publishing an app as a developer, but that could be the end result.

There won’t be any tedious downloading of APK files or tinkering with a developer console—you’ll be able to send apps to the Play Store right from AI Studio. Adding a vibe coded app to the Play Store creates a “Personal Library” accessible from the app store client on your device. This is available only to you by default, providing an easy way to install and manage the apps via Google’s system.

Google says you can share these apps with “a small group” of friends and family. Google has not decided how many people count as a small group yet, but this type of distribution doesn’t require a developer account. If you want to share beyond that, Google plans to have an onboarding process to set you up with a developer profile to publish your vibe coded apps. If you do this, you’ll be subject to the same app review guidelines as developers who come into Google Play in the traditional way. Private apps are not reviewed by Google.

Private vibe-coded apps in the Play Store will begin rolling out today in the US and select other markets. The private-to-public app migration option will be available in the coming months.

AKS has become a major platform for enterprise Kubernetes workloads, and those workloads are getting more expensive. Organizations are running more compute, adding GPU infrastructure for AI, and expanding Kubernetes into more parts of their production environments.

The problem is that the infrastructure underneath all of this is being used remarkably inefficiently.

The 2026 State of Kubernetes Optimization Report makes the problem pretty hard to ignore. Utilization isn’t just low, it’s actually getting worse.

Across the Kubernetes clusters analyzed, average CPU utilization fell from 10% to 8% in 2025. Memory utilization dropped from 23% to 20%. At the same time, CPU overprovisioning jumped from 40% to 69%, while memory overprovisioning reached 79%.

And then there are GPUs.

Average GPU utilization across the report was just 5%.

On AKS, it was 2%.

That is an extraordinary amount of expensive infrastructure sitting idle – amounting to 98 cents sitting idle, for every dollar spent.

The report is based on direct measurements from tens of thousands of Kubernetes clusters across AWS, Azure, and GCP, representing millions of compute resources. The data was collected before organizations enabled Cast AI automation, providing a baseline of how these environments were actually operating.

The obvious question is: if Kubernetes is supposed to make infrastructure more efficient, why is utilization getting worse as Kubernetes adoption grows?

Why Is Utilization Getting Worse? Well, GPUs for One

The GPU story is the most extreme example of a problem that exists across Kubernetes infrastructure.

AI workloads are uniquely difficult to size. Inference traffic can be highly variable, training workloads can have very different resource profiles, and GPU capacity is expensive enough that organizations are understandably cautious about releasing it. A workload may need significant capacity at peak and very little a few hours later.

Yet the traditional deployment model often gives that workload dedicated hardware anyway.

GPU sharing, time-slicing, and better scheduling can change that equation, but they remain far from universal. The result is that organizations can have substantial GPU capacity sitting idle while still provisioning enough infrastructure to handle the moments when demand arrives.

CPU and memory have a less dramatic price tag, but the underlying pattern is remarkably similar.

Resource requests are usually set when a workload is deployed. They are conservative because the consequences of requesting too little are obvious: throttling, OOM kills, failed scheduling, or an unhappy application team. Requesting too much rarely generates an immediate incident.

So the safe number becomes the permanent number.

A workload gets deployed with twice the resources it normally needs. Six months later, the workload has changed, but the request hasn’t. The same value gets copied into another environment, another Helm chart, or another service.

Kubernetes then does exactly what it is supposed to do. The scheduler treats the request as a requirement. Autoscaling responds to it. Nodes are provisioned to provide the requested capacity.

The infrastructure can therefore be correctly configured according to Kubernetes while still being badly matched to what the applications actually consume.

That’s what makes the overprovisioning numbers in the report particularly important. The problem isn’t simply idle CPU or memory. Organizations are building their infrastructure around resource requirements that are themselves inflated.

And once those assumptions become part of the platform, they are remarkably difficult to unwind manually.

This Isn’t Just an AKS Problem. It’s Across the Enterprise

The AKS numbers are striking, but they aren’t an Azure-specific problem.

The report found similarly low utilization across the major cloud providers, pointing to a broader problem with how enterprise Kubernetes infrastructure is provisioned and managed.

That distinction matters.

This isn’t a story about choosing AKS over EKS or GKE. It is a story about what happens after an organization has accumulated enough Kubernetes infrastructure that nobody can realistically keep every resource decision up to date by hand.

Enterprise environments are particularly good at accumulating these decisions.

A node pool created for last year’s traffic remains long after traffic patterns change. Resource requests written when an application launched stay in its deployment manifests. A commitment purchased against an earlier capacity profile continues to shape infrastructure spending.

Meanwhile, the workloads keep changing.

The report’s ARM numbers are a good example. ARM now accounts for about 9% of the CPU fleet, with ARM nodes growing 3.5 times faster than x86 since Q2 2024. That shift changes the economics of the underlying infrastructure, but taking advantage of it requires workloads and infrastructure configurations to evolve with it.

The same is true of Spot capacity, instance families, GPU scheduling, and node provisioning.

The optimal configuration is not static because the environment isn’t static.

That becomes increasingly difficult as Kubernetes expands across an organization. What might be a manageable optimization exercise for ten nodes becomes a very different problem across hundreds of nodes, multiple clusters, multiple teams, and multiple cloud accounts.

At that scale, small inefficiencies become infrastructure policy.

And infrastructure policy is very difficult to change manually.

The Problem Isn’t a Lack of Tools

Kubernetes has no shortage of tools for addressing individual pieces of this problem.

There are autoscalers for adding and removing pods and nodes. There are mechanisms for adjusting resource requests. There are ways to use Spot capacity, consolidate nodes, share GPUs, and take advantage of newer CPU architectures.

The problem is that none of these decisions exists in isolation.

Change the resource request for a workload and you change how it fits on a node. Change the node mix and you change which workloads can run on Spot. Change GPU allocation and you change the amount of physical GPU capacity required. Change the baseline workload footprint and the economics of your cloud commitments change with it.

This is why optimization tends to work well as a one-time exercise and then slowly deteriorate.

Someone spends a few weeks getting the cluster into good shape. Requests are adjusted. Nodes are consolidated. A few workloads move to cheaper capacity.

Then the environment changes.

New services arrive. Traffic increases. Other workloads disappear. Instance prices change. Teams deploy new versions with different resource requirements.

Six months later, the cluster may still be running the same optimization configuration even though almost everything around it has changed.

The report’s findings suggest that this isn’t an edge case. It’s the normal operating model.

What Should AKS Teams Do?

The good news is that fixing the problem doesn’t require replacing AKS or redesigning applications. But it does require changing the way infrastructure efficiency is managed.

For teams responsible for an AKS environment, the first questions should be:

• Do we know what our workloads actually use? Start with real CPU, memory, and GPU consumption rather than relying on the requests currently sitting in deployment manifests. The difference between those two numbers is where much of the optimization opportunity starts.
• Are resource requests still representative? Requests shouldn’t be treated as permanent configuration. A workload that has changed should have its resource requirements changed with it.
• Are we provisioning infrastructure around workload requirements or around historical assumptions? Fixed node pools can make sense for some workloads, but dynamic provisioning gives teams more flexibility to match infrastructure to what is actually running.
• Which workloads need on-demand capacity? Not every workload needs it. Batch processing, suitable stateless services, CI workloads, and some machine learning workloads can often tolerate interruption and make effective use of Spot capacity.
• Are GPUs being used efficiently? If GPUs are spending most of their time idle, adding more hardware isn’t the obvious answer. Sharing, scheduling, consolidation, and better workload placement can change the amount of physical capacity required.
• Are cloud commitments based on the right baseline? Commitments can lower the cost of predictable capacity, but they should be considered after the underlying workload footprint has been optimized. Otherwise, organizations risk committing to infrastructure they don’t actually need.

These decisions compound. Rightsizing can reduce the amount of infrastructure required. Better provisioning can improve how that infrastructure is packed. Spot can lower the cost of workloads that don’t require guaranteed capacity. Better GPU utilization can reduce the number of GPUs required in the first place.

The challenge is keeping all of those decisions aligned as the environment changes.

Next in the Series: GKE and EKS

AKS is where this series starts, but the utilization problem doesn’t stop at Azure. The report found similarly low utilization across all three major cloud providers, which raises the same questions for teams running GKE and EKS.

In the next post, we’ll look at what the 2026 State of Kubernetes Optimization Report found for GKE and for EKS on AWS. That includes CPU and memory utilization, overprovisioning, and GPU usage, and how those environments compare with what we’ve seen on AKS.

Full article content is not available for inline reading.

Read the original article →

xtool

Cross-platform Xcode replacement. Build and deploy iOS apps with SwiftPM on Linux, Windows, and macOS.

Overview

xtool is a cross-platform (Linux/WSL/macOS) tool that replicates Xcode functionality with open standards.

• Build a SwiftPM package into an iOS app
• Sign and install iOS apps
• Interact with Apple Developer Services programmatically

Getting Started

1. Follow the guide to install xtool
   • Installation (Linux/Windows)
   • Installation (macOS)
2. Create and run your first xtool-powered app by following the tutorial!

Examples

Screenshot

Command line interface

$ xtool --help
OVERVIEW: Cross-platform Xcode replacement

USAGE: xtool <subcommand>

OPTIONS:
  -h, --help              Show help information.

CONFIGURATION SUBCOMMANDS:
  setup                   Set up xtool for iOS development
  auth                    Manage Apple Developer Services authentication
  sdk                     Manage the Darwin Swift SDK

DEVELOPMENT SUBCOMMANDS:
  new                     Create a new xtool SwiftPM project
  dev                     Build and run an xtool SwiftPM project
  ds                      Interact with Apple Developer Services

DEVICE SUBCOMMANDS:
  devices                 List devices
  install                 Install an ipa file to your device
  uninstall               Uninstall an installed app
  launch                  Launch an installed app

  See 'xtool help <subcommand>' for detailed help.

Library

xtool includes a library that you can use to interact with Apple Developer Services, iOS devices, and more from your own app. You can use this by adding XKit as a SwiftPM dependency.

// package dependency:
.package(url: "https://github.com/xtool-org/xtool", .upToNextMinor(from: "1.2.0"))
// target dependency:
.product(name: "XKit", package: "xtool")

What gets TOASTed in Postgres

Insert 2,000 copies of the letter x into a table with an int ID and a text column, and Postgres stores all 2,000 bytes uncompressed. Insert 2,001, and Postgres compresses the value to 26 bytes with LZ4.

That one extra byte is enough to trigger TOAST, the part of Postgres that compresses values once their row gets too big, and moves them out of the row when compressing isn't enough.

Postgres 19, now in beta, changes how TOAST compresses, switching the default from pglz to LZ4 in builds with LZ4 support. PlanetScale already made this switch on Postgres 17 and 18.

Here, we look at which values get TOASTed, what TOAST does to them, and when LZ4 is the right choice. Let's dig in!

What a row costs in bytes

Compression is all about saving bytes, so we'll start with where the bytes in a row go.

Postgres stores table data in fixed 8 KB pages. A row can't be split across pages, so every row has to fit inside one.

Each row starts with a 24-byte header that Postgres uses to track which transactions can see it, followed by the values of its columns. The space those values take depends on their type, and every type falls into one of two groups:

• Fixed-width types like bigint, timestamptz, and boolean always take the same number of bytes.
• Variable-length types like text, jsonb, and bytea take as many bytes as the value needs, plus a length header: 1 byte for values up to 126 bytes, and 4 bytes for anything longer.

pg_column_size shows both groups in a single row:

SELECT pg_column_size(ROW(1::bigint, now(), true, 'Ada'::text));
 pg_column_size
----------------
             45
(1 row)

That's the 24-byte header, 17 bytes for the bigint, timestamptz, and boolean (8, 8, and 1), and 4 bytes for 'Ada': three characters plus a 1-byte length header. Change 'Ada' to 'Ada Lovelace', and the row grows to 54 bytes while the other columns stay at 17.

Variable-length values are what make a row grow, and the only ones Postgres can compress.

Small rows don't trigger compression

TOAST stands for The Oversized-Attribute Storage Technique. As the name suggests, TOAST only steps in when a row gets too big.

Postgres treats a row as oversized once it's larger than 2,032 bytes, about a quarter of an 8 KB page. This threshold was set so that at least four rows fit on every page, after room for the page header and a pointer to each row.

Here's what happens when we store the most compressible value possible, a single repeated letter, at lengths just below and just above the threshold. pg_column_compression returns the algorithm that compressed each value, or null if the value isn't compressed, which we display as none. The COMPRESSION lz4 clause picks the algorithm.

CREATE TABLE t (id int PRIMARY KEY, body text COMPRESSION lz4);

INSERT INTO t VALUES
  (1500, repeat('x', 1500)),
  (2000, repeat('x', 2000)),
  (2001, repeat('x', 2001));

SELECT id AS chars,
       pg_column_size(body) AS stored_bytes,
       coalesce(pg_column_compression(body), 'none') AS compression
FROM t ORDER BY id;
 chars | stored_bytes | compression
-------+--------------+-------------
  1500 |         1504 | none
  2000 |         2004 | none
  2001 |           26 | lz4
(3 rows)

The first two values aren't compressed. Each takes 4 bytes more than its length, for the length header. The third value, however, is just one character longer, and it's compressed to 26 bytes.

The 2,000-character row is exactly 2,032 bytes: 24 for the row header, 4 for the int, and 2,004 for the text. That's right on the threshold, so TOAST leaves it alone. The 2,001-character row is one byte over.

TOAST does two different jobs

The threshold applies to the whole row, but TOAST works on individual variable-length values. Once a row is over the threshold, TOAST has two ways to shrink it:

• Compress a value, and keep the smaller version in the row, like the 2,001-character row.
• Move a value out of the row, into a separate table.

That separate table is called a TOAST table. Tables with columns that can hold large values get one automatically in the pg_toast schema.

A value moved to the TOAST table isn't stored in one piece, though. TOAST splits it into chunks of up to 1,996 bytes and stores each chunk as its own row, tagged with the value's ID (chunk_id) and its position in the value (chunk_seq). The rest of the 2,032 bytes holds the chunk row's header and IDs, so four chunk rows fit on a page. The original row keeps an 18-byte pointer, so Postgres can find the chunks and reassemble them.

TOAST works through a row's values from largest to smallest. As soon as the row is back under 2,032 bytes, the table's toast_tuple_target, it stops.

To see every outcome, we store four very different values in one table: a short string, 10 KB of repeated text, 200 KB of random characters, and 1.1 MB of a repeated sentence. stored_bytes is the value's size wherever it ended up, including the TOAST table for a moved-out value. octet_length returns a value's uncompressed size, and pg_column_toast_chunk_id (Postgres 17+) returns its ID in the TOAST table, or null if the value is still in the row.

CREATE TABLE docs (id int PRIMARY KEY, body text COMPRESSION lz4);

INSERT INTO docs VALUES
  (1, repeat('x', 200)),
  (2, repeat('abc', 3400)),
  (3, (SELECT string_agg(md5(random()::text), '') FROM generate_series(1, 6250))),
  (4, repeat('The quick brown fox jumps over the lazy dog. ', 25000));

SELECT id,
       octet_length(body) AS raw_bytes,
       pg_column_size(body) AS stored_bytes,
       coalesce(pg_column_compression(body), 'none') AS compression,
       pg_column_toast_chunk_id(body) IS NOT NULL AS moved_out
FROM docs ORDER BY id;
 id | raw_bytes | stored_bytes | compression | moved_out
----+-----------+--------------+-------------+-----------
  1 |       200 |          204 | none        | f
  2 |     10200 |           60 | lz4         | f
  3 |    200000 |       200000 | none        | t
  4 |   1125000 |         4471 | lz4         | t
(4 rows)

Each value lands somewhere different:

• Row 1 is under the threshold, so TOAST never touches it.
• Row 2 compresses from 10 KB to 60 bytes, small enough to stay in the row.
• Row 3 is random, so compressing it doesn't save space. TOAST moves the value out uncompressed.
• Row 4 compresses to 4,471 bytes, which is still too big for the row, so TOAST compresses it and moves it out.

Each column's storage strategy decides which of those jobs TOAST can do:

• PLAIN: neither. Used by fixed-width types like int.
• EXTENDED: compress, then move out if needed. The default for text, jsonb, and bytea.
• EXTERNAL: move out, but never compress.
• MAIN: compress, but keep the value in the row even above the usual TOAST target if the row still fits on a page. Move it out only as a last resort. The default for numeric.

TOAST isn't a large object

Postgres has a second way to store big values, called large objects, built for whole files like videos or PDFs.

TOAST and large objects both store big values in chunks, but they differ in three ways:

• TOAST is automatic. It applies to any variable-length column without you asking. A large object only exists if you create one.
• TOAST values top out at 1 GB. Large objects can hold up to 4 TB.
• TOAST values are deleted with their row. A large object stays until you remove it with lo_unlink, even after the row that references it is gone.

How pglz and LZ4 work

Postgres can compress a TOAST value with one of two algorithms, pglz or LZ4. A column uses the one its COMPRESSION clause names, or the default_toast_compression setting if it doesn't name one. Changing either only affects values compressed from then on. Values already compressed keep their algorithm, even when you copy them with INSERT ... SELECT or rewrite the table with VACUUM FULL.

zstd isn't an option for column compression. Postgres uses it elsewhere, like write-ahead log (WAL) compression through wal_compression (Postgres 15+) and backups.

Both algorithms work the same basic way. They scan a value from start to finish, looking for bytes that already appeared earlier. When they find a repeat, they replace it with a short note saying where the earlier copy is and how long it is.

pglz wins on these JSON documents

In a JSON array, the same keys come back in every object, close enough for both algorithms to find them.

We loaded 10,000 order documents into three tables on PlanetScale Postgres 18: one using EXTERNAL so nothing gets compressed, one using pglz, and one using LZ4. Each document has 25 to 100 line items, and every line item repeats the same five keys: sku, name, qty, price_cents, and tags.

The uncompressed table is 103 MB. The pglz table is 19 MB and the LZ4 table is 24 MB.

Since both find the keys, the size comes down to pglz's extra searching, which finds longer matches. LZ4 makes up for it in speed: in two runs each, it loaded the same documents in 0.48 and 1.09 s, against 1.59 and 1.73 s for pglz.

pglz is faster for previews

pglz also wins when you only read the start of a large value, like a 200-character preview with left(body, 200). pglz never needs more than 9 bits to store a byte of the original, plus 2 bytes overall, so Postgres can put a ceiling on how many compressed bytes a prefix needs. A character takes 1 to 4 bytes, so 200 characters are at most 800 bytes, and 800 bytes of output need at most 902 compressed bytes. That's less than the 1,996 bytes in a chunk, so Postgres fetches only the first one. Postgres has no equivalent ceiling for LZ4, so it fetches the whole value first.

When to skip compression

Compressed values take fewer pages, which means less disk, more of a table in memory, and less WAL to send to replicas and back up. The cost is CPU, on every write that crosses the threshold and every read of a compressed value. Compression also doesn't reduce egress, since Postgres decompresses values before sending them.

Two kinds of data are better off uncompressed, with EXTERNAL:

• Already-compressed data, like JPEG frames. LZ4 spends CPU on every frame and saves little or nothing.
• Large bytea values read from the middle, like seeking in a file.

Wrapup

TOAST only steps in once a row passes 2,032 bytes, so plenty of values, like the 2,000 xs from the start, never get compressed at all. For the ones that do, LZ4 is the right default for most tables: its speed matters more than the size difference, which can go either way. For a few kinds of data, it's worth choosing pglz or EXTERNAL by hand.

• Meta has begun deploying Media over QUIC (MoQ), an emerging open protocol for real-time video streaming at scale.
• MoQ will help simplify our protocol stack for live streaming video and enhance overall user experience for live video.
• We’re sharing how we shipped MoQ on Instagram Live ingest, and what the future looks like from here.
• This work was also presented at DEMOQED 2026.

Instagram Live now uses the open standard transport protocol Media over QUIC (MoQ) for live video ingest on iOS and Android. As a transport designed for both ingest and playback, MoQ gives us the foundation to build toward an architecture that is lower-latency, more resilient on unreliable networks, and more responsive for creators and viewers. It also gives teams across Meta a common foundation for bringing those improvements to future live and interactive experiences without rebuilding them on separate protocol stacks.

MoQ: A Media Protocol for Every Moment in Time

The internet has accumulated a rich set of media protocols, each shaped by the problem in front of it. RTMP for ingestion. HLS and DASH for playback. WebRTC for real-time calls. RUSH for the cases that did not fit neatly into any of those. Each was a strong answer for its moment, and together they’ve carried the industry a long way. At Meta, someone who starts a live stream and then makes a voice call on the same app touches three different protocol stacks, each with its own serving infrastructure, monitoring, and operational expertise.

That separation made sense when these experiences were distinct. But as live video, real-time AI, and generative AI creation tools increasingly share the same product surface, the lines between these use cases are starting to blur. A common protocol across ingest, delivery, and playback can reduce the number of custom transports and operating models that engineering teams need to maintain and improve over time.

How MoQ Works

MoQ is an emerging IETF standard that enables low-latency, scalable media delivery (live streaming, real-time communication) over the QUIC transport layer. It’s being developed collaboratively at the IETF, with active participation from Meta, Google, Akamai, Cisco, Cloudflare, and academia.

For nearly a decade, Meta’s live streaming video has run on Reliable Ultra-low-latency Streaming over HTTP (RUSH), an in-house QUIC-based protocol built to move past RTMP. RUSH proved that QUIC could carry live media at scale and was a predecessor to MoQ. The lessons learned from running RUSH in production are part of what shaped our bet on MoQ.

The core abstraction in MoQ is a Track, an addressable stream of media objects that publishers push and subscribers receive through a network of relays. Relays cache and forward objects without parsing the media payload – they only need to understand the MoQ framing and delivery metadata.

A few properties matter for using MoQ as a single transport across the full latency spectrum:

• Built on QUIC: QUIC lets independent streams make progress without TCP-style cross-stream head-of-line blocking. It also supports faster connection setup and connection migration. Meta’s earlier QUIC rollout achieved lower request errors, tail latency, and video stalls than HTTP/2. MoQ applies the same transport foundation to live and real-time media. MoQ would also automatically benefit from any feature added to QUIC (e.g., FEC).
• Native Fan-out and caching: MoQ relays are built-in caching and request/stream coalescing endpoints, so media streams scale through CDN relays out of the box. Request coalescing, caching, and fan-out are not new (live streaming already does them), but MoQ makes them part of the protocol design rather than a bolt-on, and it is designed to scale via relays more efficiently than traditional HTTP streaming.
• Tunable Latency per use case: Two subscribers to the same track can run at different latencies at the same time — e.g., ~100 ms for an interactive participant and several seconds for an archival or buffered service — based on tunable per-subscription delivery properties.
• Track-aware delivery: Relays can drop, prioritize, or replay objects based on metadata, giving better congestion behavior under loss than byte-stream protocols.
• First-class media context: Tracks and their quality variants are modeled in the protocol itself, so adaptive bitrate logic is built directly on native MoQ constructs rather than reconstructed at higher layers.
• Standards-based TCP fallback: When QUIC is blocked, MoQ can fall back to TCP through a standardized mapping (e.g., WebTransport over HTTP/2, or the emerging QMUX mapping), so a blocked network doesn’t force the ecosystem back into multiple parallel transports.

First Deployment at Scale: Instagram Live

Of all the surfaces MoQ can serve at Meta, we chose to ship live video ingest first for three reasons:

Instagram Live is our largest-scale test: Instagram Live serves users at Meta scale. Proving MoQ at this scale clears the bar for the most demanding ingest workloads, and is complementary to the low-latency properties that matter for real-time use cases.

RUSH was falling behind the open ecosystem: Live ingest had been running on RUSH, Meta’s pragmatic QUIC-based answer to RTMP. RUSH was stable and performant at scale for nearly a decade, but the move to MoQ shifts development from a protocol operated primarily by Meta to a shared standards effort. Multiple implementers can contribute experience, test interoperability, and improve the specification instead of Meta evolving the transport largely on its own.

Metric parity is a prerequisite for everything else: Proving MoQ can operate at Meta scale for its largest live surface without regression gives us a clean baseline from which to explore, including live playback among others.

Rolling out MoQ on Instagram Live

Replacing the live ingest protocol on Instagram Live meant changing the foundation under every broadcast on the service. We had to do it without regressions visible to creators or viewers, and without coupling the wire-format change to a rewrite of every downstream system.

Replacing a transport protocol in a live production system is hard for reasons that have little to do with the protocol itself — broadcaster apps need to learn it, the backend pipeline expects the old framing, the rollout has to be reversible in seconds, and a non-trivial slice of networks can’t carry the new transport at all.

We tackled these as three constrained problems:

Client integration across four apps: A MoQ publisher built on moxygen, Meta’s open-source MoQ library, integrated in our apps. moxygen provides publisher, subscriber, and relay roles, integrates with our QUIC stack (mvfst), and exposes hooks for custom media handlers. A single config parameter chooses MoQ or RUSH for a given broadcast.

Translation at the edge instead of rewriting the backend. MoQ ingest connections terminate on dedicated edge endpoints, where a translation layer converts MoQ frames to the RUSH format the existing backend already understands. Nothing downstream changes while we swap the client transport. The translator is temporary scaffolding; once MoQ is the only ingest path, the backend will consume MoQ natively and the shim goes away.

Server-side routing for fast ramps. Stream URL generation routes experiment-eligible broadcasts to MoQ-capable endpoints based on experiment-group membership, so phased rollout doesn’t depend on app-version adoption and the experiment can be resized in minutes.

Operational Hurdles

• Evolving Specifications: As an active IETF standard, the MoQ draft continued to evolve while we built. We pinned to specific draft versions, kept compatibility shims around for older clients, and contributed improvements back to the IETF working group.
• Firewalls: UDP/443 is still blocked or rate-limited on a non-trivial slice of enterprise and carrier networks. We pick the transport (TCP or QUIC) at the start of the live stream based on which handshake wins, and go with that for the session.
• Debugging: QUIC’s encryption hides framing from middleboxes, and from our own packet captures. We built MoQ-aware tracing into the edge so we could see object-level events without decrypting the wire.

The Outcome

After months of experimentation on Instagram iOS and Android, we launched MoQ for Instagram Live ingest. The MoQ path matched RUSH across the streaming-quality indicators and reliability measures used for the rollout.

Achieving parity was the target for this phase, and it showed that we could replace a production transport without disrupting creators or viewers. It also gives the next phase a production-tested transport, rollout controls, and observability.

This now becomes the foundation to extend MoQ to an end-to-end architecture for live video delivery and playback. In that target architecture, media can be pushed as it is produced, and partial reliability can let the player skip stale video after loss instead of allowing delay to accumulate. Adaptive bitrate work can trade resolution for continuity as bandwidth changes. We believe these capabilities will form the basis of the next-generation live video architecture for richer, more responsive experiences for creators and viewers.

What’s Next: Other Explorations Within Meta

Instagram Live is the first MoQ workload at Meta. Reaching parity at Instagram Live scale gives us a clean baseline to ask where else a single QUIC-based transport could collapse a set of special-case stacks into one. The directions below are areas we’re exploring:

Finishing the Live Ingest Story: The next logical steps build on top of what we’ve done — extending MoQ across the rest of Meta’s apps using MoQ-native constructs like subgroups to carry audio, video, and metadata on independent streams for better resilience under loss, and adding a standards-based TCP fallback (QMUX). Today, we lean on RUSH’s existing TCP fallback as an expediency for QUIC-blocked networks; standardizing on QMUX removes that dependency so a blocked network no longer forces a second protocol, eventually opening the door to retire RUSH.

Real-time Interactive AI: Conversational and real-time AI surfaces move architectures toward continuous human-to-server communication. A single low-latency, bidirectional transport that carries signaling and media together is a natural fit. Meeting the latency, loss-recovery, and media quality requirements that real-time communication demands is an area we are actively exploring.

Shipping MoQ for Instagram Live makes this one of the largest application usages of MoQ we are aware of in the industry, both by the number of ingest streams and total volume. An open IETF-standard transport is now carrying media at Meta’s scale, and the future it unlocks is exciting.

Learn More About Meta’s MoQ Deployment

Interested in learning more? Check out the MoQ Transport IETF draft and our moxygen open-source library.

Prize-winning image which sparked backlash was AI-generated, Nikon rules

The winner of a prestigious scientific photography competition has been disqualified following concerns raised by other scientists that it was fake.

Nikon said the use of generative AI in the composition of the video broke the rules of its Small World In Motion contest, which accepts photos and video taken using powerful microscopes.

The firm said the video "did not comply with the competition rules regarding generative AI", but added it was not a judgement of the entrant's professional reputation or scientific contributions.

It said it would now look at the rules and procedures of the annual contest, which has been running for 15 years and is specifically for microscopic images.

Nikon said it came to the decision "after thoroughly re-evaluating the video and supporting materials and consulting with members of our judging panel".

The winning entry came from Dr Ning Xu, from Tsinghua University in China, who submitted a short video showing tiny, hair-like structures called cilia moving in the airway of a child with the respiratory condition PCD.

The BBC has approached him for comment.

A number of scientists, including former competition judges, complained to Nikon on its LinkedIn page that the video did not appear to be real.

Xu had acknowledged using AI, but said he believed he had acted within the rules, and had cooperated with Nikon's investigation.

University of Leicester scientist Dr Robert Hirst, who was among the first experts to voice concerns, said he was "not surprised" and he "knew immediately that the video was fabricated".

"I have been diagnosing PCD for 20 years by examining their cilia waveform, length, cell size and shape," he said.

Hirst, who is lead scientist for the NHS centre for PCD diagnosis at the university, said the cells and cilia "look nothing like those from PCD patients".

"This controversy has impacted a lot of patients, scientists, doctors and PCD support networks around the world," he said.

The fake double diamond is dead. The real double diamond is immortal.

AI is not a substitute for divergent thinking, and the false certainty it gives will never save you from having to iterate.

The discourse loves a dichotomy. Framing any disagreement as a difference of opinion between two sides, and then asking everyone to pick a camp, is intellectually convenient. It also happens to be a really bad way of actually wrapping your head around the possibilities present in the world.

This tendency manifests itself in lots of different ways, but this is a product blog, so we are going to talk about product development stuff. Specifically, how orgs learn. For which there are (of course) two main camps: the Agile way (where we build to learn); and the Waterfall way — usually defined simply as the opposite of the Agile way, because it’s less of a methodology and more of a rhetorical device. The Waterfall way of “big design up front” is implied to be practiced by some other people, outside the room. Inside the room are only innovators, who are above that kind of thing.

At least, that’s what we say. But what we actually do couldn’t be further from the truth:

Organizations often say they want innovation, but at the precise moment when they need exploration most, they often seek out predictability.

This is why we are still doing Agile transformation 25 years after everyone agreed Agile was the right way to build stuff. The dichotomy between up-front definition and iteration was always wrong and trying to stamp out one tendency in service of the other will continue to fail, no matter how much AI we pour onto the problem.

The eternal quest to get BDUF for free

No amount of manifestos could suppress the simple human tendency that certainty feels good. To the people in charge of calendars, there is nothing more alluring than the idea that you can simply know the right thing to do up front, and then do that thing exactly once, never having to budget time for testing or rework.

The motivating factor for perfect up-front learning is not “doing a good job.” It’s actually exactly the same motivation that got orgs to pay lip service to Agile in the first place: spending less time before teams can start producing outputs. That Waterfall-ish desire for data up front is not in contrast to “build to learn” but another way of arriving at the same goal: permission to ship the thing we wanted to ship in the first place.

Is the biggest barrier to evidence-based product decisions or policy a lack of evidence? Not usually.

This is the world in which synthetic users are considered to be an alternative to real research; not because they are good but because they remove the friction of challenging your existing opinions. Their dismal accuracy (you’re better off flipping a coin) is besides the point, because the product being sold is not real insights. They are worse than simply having nothing, because when you have nothing then you at least know what you don’t know.

The pursuit of velocity has led many to argue passionately that the “discovery phase” should be abolished. I think that is completely the wrong lesson to draw from the industry. It’s not that up-front discovery is wrong, it’s that it’s insufficient by its lonesome. To be effective, it must work in concert with the rest of the process:

Just like an airplane’s time on the runway is still part of the flight, discovery is part of design and must give creative work momentum and direction.

This is where synthetic insights will always fail. Because they are an excuse not to do discovery (rather than a real discovery activity) they are incongruent with the creative process. When the answer is “AI told me to,” one cannot give a compelling explanation for choosing one direction over another — at least not one that is immune to being overturned by a stakeholder telling the same AI to give a different answer.

Only a human expert — bolstered by both an understanding of the data and the confidence drawn from professional experience — can prevent this process from being perverted into going through the motions and defaulting to the thing the stakeholders wanted in the first place. Which brings us back to Strawbridge’s piece from the beginning of the issue:

Innovation requires more than exploration. It also requires expertise. It benefits from a seasoned guide. […] Senior people can … resist the urge to force a problem into a predetermined framework, follow something unexpected when it emerges, and stay with a question a little longer before converging on an answer.

Up-front certainty was always a fool’s errand, at whatever cost. To try and attain it at bargain-basement prices is not a “hack” that your competitors have yet to discover. It’s simply doubling down on the foolishness.

Prototype ≠ experiment

Ultimately, an ersatz discovery phase (either one driven by synthetic user research, or one focused on “validating” what executives already believe) gets you to the same place as not doing discovery at all: writing the code you wanted to write from the beginning. This, some people suggest, is a reason to avoid doing discovery entirely.

And I don’t just mean up-front discovery. There is an increasingly popular notion that because code is cheap now (hah!) you can simply ship whatever you want and let analytics sort the wheat from the chaff. This is, of course, a radical misunderstanding of the nature of wicked problems. Attempting to solve the problem changes the problem; without giving deliberate thought to the lifecycle of your experiments (including the clean-up) you are merely polluting your product and praying that users won’t notice.

A real experiment is not just a shipped feature that was poorly thought out by its designers. An experiment is a deliberate task that a team undertakes to learn something it does not already know. It requires a hypothesis — and “users will like it” (or worse, “stakeholders will like it”) is not a real hypothesis. And once that thing is learned, the experiment comes to an end.

Teams whose so-called experiments are launched without that arc in mind are not running experiments at all; they do not know what they are looking to learn, how the experiment will help them learn that thing, or even when that will come to pass. They cannot reverse the experiments where the hypothesis was disproven. They can only double down on experience rot.

The problem is that many organisations talk as though they are playing poker while building products as though they are playing chess. They describe decisions as experiments, but rarely remove the failed ones. They promise to iterate, but almost never return. Each supposedly temporary bet leaves another permanent mark on the board.

The confounding factor is that for most orgs, this feels like it works. Things ship, middle managers are happy — and yet nothing really gets better. The simplistic notion of “this feature will make that number goes up” is ground underfoot by the complexity of socio-technical systems. The impacts of any change are inherently delayed, difficult to observe and isolate any attributable cause unless you know exactly what you are looking for.

Making your systems work for you

It’s easy to take one side or the other in this dilemma. If you favor iterative development, then there are many examples of discovery done badly to point at and say “we can’t do it that way.” But at the same time, if you are coming from the other side, it’s equally simple to point at any number of terrible products produced by teams who could not iterate their way away from their thoughtless starting point.

The argument between “up-front research” and “ongoing research” is a rhetorical trick that only serves people who care for neither. Those people come to the meeting with a quiver of excuses for why we mustn’t take any time to think before shipping the thing, and yet simultaneously can’t look back at what we’ve shipped to see if it worked because it’s time to ship the next thing.

This is the fake double diamond: substituting real divergence and convergence with artificial alignment and a synthetic sense of urgency, whipping the team ever-forward at a pace that ensures the appearance of brilliance as no decision can ever actually be revisited.

For those of us interested in actually making useful software, we can’t get rid of either up-front problem definition nor the pace-limiting effect of observing and iterating on what we have already produced. In fact, we need both of these stages — and both need to be embedded within a shared system. A system that lets us define what we want to learn before we build, so that we set ourselves up to succeed when we are looking for evidence of the ways in which actually worked (and the ways in which didn’t).

Charlie Fountaine published a short list of principles for creating prototypes that actually do something within that socio-technical system, above the banal level of screens with clickable buttons. But that prototyping loop ought to itself be grounded in an evidence-driven semantic environment. Rachel Coldicutt sets out a good overview of such a system here.

Anyone who thinks that AI can replace the need for conceptual clarity at the level of these two documents is trying to sell you something.

Low-contrast text appears on 83.9% of the top million home pages, making it the web's most common accessibility failure. Clearleft's tool “This hue shall pass” maps every pairing in a palette against WCAG AA or AAA and fixes failures by nudging lightness. Hue stays fixed, so brand colors keep their character while passing contrast.

Full article content is not available for inline reading.

Read the original article →

We discovered a sophisticated recording device that was hidden inside one of our offices. We used our models to understand the device and where it had come from, identifying that a specific employee had planted it a few days earlier. We referred the matter to the FBI, and we’re grateful to the agents and prosecutors who moved quickly to make an arrest. The FBI’s investigation is ongoing and we will continue to support their work.

At this time, we have no indications of this individual inappropriately accessing or exfiltrating model weights, source code, or customer data. The employee was terminated.

We take protecting our technology, data, and people seriously, and as a matter of national importance. Our security program is designed to protect against a wide range of threat actors, from insider risks to cybercriminals to nation states, and this case is an example of how AI can help address these sophisticated security threats.

Full article content is not available for inline reading.

Read the original article →

Introducing Glass: Learn Things Once.

Last week, David Senra asked me: “How does Ramp move so fast?”

Today we’re launching the answer.

But before we do, I’d like to tell you why we built it.

Giving every employee AI — the best models, the most tokens — is not the same as becoming an AI-native company.

It’s like giving every employee a Steinway and expecting a symphony. What you actually get is a lot of expensive noise.

One week in May, we burned $1.5 million in tokens. Our CFO didn’t like telling me that, and he won’t like that I told you.

So what happened after that? Well, as is often the case at Ramp, a small team built something. A place where everyone got the setup our most AI-forward employees had built for themselves. Within weeks, it wasn’t a tool we used. It was how we worked. It’s called Glass.

Here’s the pitch.

Somewhere in your company, someone figured out the perfect way to prep a sales deck. Someone else wrote a prompt that turned a messy customer call into a clean account plan. Your FP&A leader stayed late and built a workflow that catches every budget variance before it hits the board deck.

You do brilliant work. And almost none of it is seen twice.

It lives in one person's chat history, and it disappears when they close a tab, go on vacation, or leave. Multiply that by every employee, every day, and your company is losing what it learns as fast as it learns it.

So we asked: what if, instead of starting with an empty chat, you started with everything your company ever figured out? Not scattered across Slack, prompts, and your people’s heads, but built into the work itself.

That’s Glass.

Rather than have me explain, let me show you.

Today, I asked Glass how many U.K. customers we’ve added since launching. It knew to exclude U.S. companies with U.K. offices because Finance taught it that months ago. I didn’t explain a thing.

A trivial improvement, you may say—not worth bothering about. But multiply that by every employee, every day, and your company gets better at work every time someone does it.

So far, 323 employees (PMs, CX agents, salespeople, marketers, analysts) have made 6,500+ edits to what Glass knows.

Take new feature requests. They used to be copied by hand into Salesforce, about 300 a month. In May, an account manager saved a prompt to Glass that pulls them straight from customer calls. Now we capture 20,000 a month. Another prompt prioritizes them. A third emails customers when something they asked for ships. More than 5,000 of those emails have gone out so far.

No model ships with your company's brain.

And it works the way your team works. Say a support agent is stuck on a ticket that needs an engineer. She shares her Glass session. The engineer jumps in, sees everything, they finish it together.

Now, about that $1.5 million week.

Our CFO wishes Glass had come sooner. Every project has a meter, like a taxi. So, you see what work costs while it’s happening, not when the invoice arrives.

And every request runs through Ramp Router, which picks the right model for the job. When we moved our own work onto it, our bill fell 30% overnight.

More done. Less spent. That’s Ramp since day 1.

Here’s what you get:

• Your company’s knowledge. Linear, Notion, Google, Slack, Gong, and dozens more.
• Multiplayer. Bring a teammate into any session.
• Skills. One person’s best work. Now everyone’s starting point.
• Any model. Open or closed. When a better one ships next week, you just use it.
• A meter on every project. See what it costs. Set limits before they’re crossed.

Most companies slow down as they grow. Glass is our promise that yours won’t. We’re onboarding the first businesses personally. Sign up, don’t look back: ramp.com/glass.

So, “How does Ramp move so fast?”

Well, I sent David four words back: “We learn things once.” And now you can too.

It’s day 2,766. Job’s not finished.

— Eric

SpaceXSI bundles X Premium, Grok, and Cursor into one subscription

In a bid to attract more subscribers, the company now known as SpaceX Super Intelligence is bundling all its subscriptions, including X Premium, Grok, and Cursor, into one plan called simply “The X Subscription.”

The idea is that the combined offering could potentially attract more subscribers than any single subscription, given the competitive paid AI subscription market, where SpaceXSI faces rivals like OpenAI, Anthropic, and others.

With The X Subscription, users can gain access to Grok for AI-powered chat, with support for voice, images, video, and the API. Grok’s agentic AI Bot is also available, as is Cursor for AI coding and the paid features that come with an X Premium subscription, like the blue verified checkmark, creator tools, and fewer ads.

There are five plans available on the new subscription: free, Plus ($8/month), Premium ($30/month), Super ($100/month), and Ultra ($200/month), with AI usage caps increasing as you move up through the tiers. The free plan will only offer limited chat and agent usage, and Premium or higher is required to access the latest Grok models.

There’s another draw for existing X Premium+ subscribers: The comparable plan on the new X subscription costs the same or less, the company noted.

Existing users can either switch from their subscription settings on X to upgrade to the new bundle, or maintain their current plan. The option to upgrade will roll out gradually, so interested customers will need to keep an eye on their billing settings for the offer to upgrade.

SpaceX plans to perform as many as 456 launches and 912 landings at its Texas facility each year. The company's CEO, Elon Musk, has been open about the company's intent to launch Starship as rapidly as possible in the future. He has claimed that, in less than a decade, SpaceX will be able to launch Starship more than once every hour. SpaceX recently announced plans to invest as much as $100 billion to build a massive launch site in southern Louisiana to support rapid Starship launches.

I work on Claude. It's an interesting experience: Every day I learn about yet another feat accomplished with or by Claude that I hadn't considered, didn't think possible, or simply lacked the curiosity and time to try. This month, it may have helped discover a new planet, I've seen the first AI music video that I really like, and we are discussing a new era of math.

Model capabilities don't grow uniformly. Models are, as Terence Tao puts it, "astounding in some directions, while inadequate in others". Some people manage to pilot the astounding capabilities and seem to be flying - it's addicting to watch people reach incredible heights with the products I've built. Many others are still struggling to get their new wings to work, wondering what they're good for beyond asking "What is the capital of France" or "Can you make this email sound less angry".

I frequently proclaim (together with other people working on AI) that we ought to be more ambitious when using it. It's become a rallying cry. Whenever we see something impressive, we repost and write "we're not ambitious enough". I understand how tricky it is to follow that advice, so here's a tutorial on being more ambitious.

I think of ambition in four types: Speed, Altitude, Depth, and Range.

• Speed: The same work in less time, the bread and butter for AI's economic value: If you need some code written, I'll do it faster with Claude. Well established and requires little creativity in how you approach AI, so I'll skip this one.
• Altitude: Going up in abstraction and considering the outcome rather than the individual task.
• Depth: Considering a task the way a field-leading expert would. Rather than operating at the task's layer, we go one level deeper and touch the underlying data, tools, and problems.
• Range: Drawing on multiple fields rather than just the one the task might need at the surface, using knowledge, tools, and techniques you normally wouldn't.

I primarily use Claude (duh) but my advice is not model-specific.

Altitude

We often flippantly call this "letting the model operate at a higher abstraction". When you give the model a task, it's executing your best guess at how to get the outcome you want. To be more ambitious in altitude, ask yourself - what do you want to happen next? What's the goal beyond the goal? At the beginning of last year, I still asked Claude to fix individual crashes for me. Eventually I asked Claude to simply keep our apps crash-free.

Let's consider an everyday (dare I say mundane?) office task. You're at Acme Inc, an imagined company, where you need to put together a deck for the quarterly business review (QBR). Given a bunch of data, Claude will happily make you some slides. Maybe you even have a template and it just needs to fill it in. That's hardly comparable to finding a new planet, so let's look at some concrete steps to make our approach more ambitious. We'll start basic and get a little bit more ambitious with each step:

• As input, most reviews want to know what changed this quarter, why, and what should be done about it. Resist the urge to just update whatever numbers are in the template - give the model too as much data as you can get your hands on so it can understand your business: "Tell me what changed this quarter, why, and what we should do about it."
• Meetings (the good kind, anyway) ideally end with some decisions. Ask Claude: "Work out which three decisions are most urgent in the face of everything you've learned, and start working on potential directions with for/against arguments."
• QBRs are from a time when good reviews required humans to carefully sift through data, figure out what the data means, and if the business should adjust. Ask Claude: "The review exists so leadership catches problems early and moves money and people to the right places. Design a better way to do that than a quarterly deck, show from our own history that it would have caught things sooner, and run it beside the current one for a quarter."

The altitude approach works best if you really are after some ultimate outcome; it works less well for creative endeavors. A good tell-tale sign that ambition in altitude is a good idea is if you're going to have meetings to discuss whatever you're working on. There are currently limits ("Claude, go make money" doesn't seem to work for most businesses by itself in 2026), but I generally see that models seem to be able to operate at higher levels of abstraction the more capable they become.

Altitude is also where people find durable workflows that take the human out of the loop, making it less necessary for you to constantly update the model with task after task. Doing this well often involves changing your workflow - in order to let Claude make sure our app is crash-free, I first had to make sure it can easily fetch crash reports, understand which app version maps to what git commit, and give it access to Windows, macOS, and Linux computers so it can actually independently reproduce and verify fixes.

Depth

Sometimes, you just want a task executed really well. Being ambitious in depth means pushing the model to use the tools, techniques, media, and knowledge employed by the best professionals in the field - and to keep pushing until even those people might learn something new from your work.

Let's continue with our Acme Inc example of a quarterly business review deck. Assume for a second that Acme Inc struggles with some user churn (customer loss over time). I've found a mix of the following techniques useful:

• Insist on the same instruments used by the best in the industry: When prompted to act like a professional, models often switch vocabulary without actually switching methods. To work on our problem with depth, we need to use the same tools as the best data scientists and statisticians. When Claude reaches for markdown tables, insist on the use of databases and statistical models. You don't necessarily have to know what the experts use, Claude usually does.
• Pick unreasonable goals and tell the model that they're very reasonable: You need your website to load in 5s instead of 10s? Ask for 200ms. Does something seem impossible to the model? Reiterate that it's very much solvable, it just needs to keep going.
• Challenge what you know: Especially in business, a lot of things we believe to be true are rough approximations of reality. Give the model access to the raw information and data and ask it to adversarially check assumptions. "We believe churn is an onboarding problem. Try to reproduce that from the raw data."
• Produce new knowledge: Easily tacked onto challenging what you know - once Claude is already deep inside the data, ask it to find blind spots. "Build a simulation of our customers that reproduces the last year from our logs. Then find the earliest signal of churn we don't know about yet, and show it predicts on data it has not seen."
• Use an outside judge: Do not ask the model to judge itself. I assume that this will eventually be solved with increasing model intelligence, but in October 2026, I implore you to insist on outside validation. Ideally that's a tool the model can run to get feedback immediately.

A simple prompt that often helps me:

I want a deeper version of this task, not a bigger one. Before rewriting it: (1) say what a top professional in this field would do here that I'm not asking for; (2) name the rawest material they would start from instead of what has already been digested for me; (3) name the specific methods and tools they would use; (4) say what, other than you or me, would show the result is right. Then rewrite my prompt to ask for exactly that.

Range

In short, being ambitious in range means that we consider our work from the perspective of different fields - more fields than would have been economical in the past. This isn't a particularly unique insight, every single heist movie spends the first 30 minutes assembling a diverse cast of characters and talents. As AI products make it easier and easier to run multi-agent systems (with multiple threads, orchestrators, or simply subagents), I've seen really interesting results by imploring Claude to bring in additional fields.

Putting this into practice isn't easy; it requires you to be creative. Until I saw my colleague Alex Albert use Blender to render interior designs, I never considered using Claude for 3D environments for my homepage - even though I've previously made video games! However, this is easily where I see the most magic happen.

So, how do we do this? I use the following techniques:

• Try to replace the nouns with verbs: An old trick from The Art of Innovation by Tom Kelley and Jonathan Littman. A quarterly review isn't "a deck". It's "getting busy people to believe a story about cause and effect, and to decide under uncertainty, in 30 minutes". Having the verbs makes it easier for both me and Claude to understand which fields might bring in a unique and useful perspective.
• Assemble the crew: The deck needs to be amazing, otherwise aliens will blow up Earth. What kind of team will humanity get together? For production quality, I'd bring in an analyst, a journalist, and an editor. If it has to be presented, probably a motion and audio designer, too. It might be useful to employ an adversarial "red team", too, so let's bring in a short seller and a forensic accountant.
  It is easy to accidentally engage in role play, which will make your transcript weirder without improving the actual outcome. Use this method to find fields and techniques. Don't ask the model to write a short seller, ask it to do what a short seller does to research their position.

All the ways in which I describe ambition require the model to have a computer with the ability to install software and access to all kinds of relevant data (either using MCP connectors or other means). Plenty of tools make this possible and I recommend that you use one.

We have been here before

That's my concrete advice for how to be more ambitious. If you're willing to stick around for a minute, I'd like to tell you why I think this is even necessary in the first place.

We humans have always been held back by what we believe possible - and what's worse, we usually trust ourselves only in very narrow disciplines. Michelangelo famously didn't want to paint the Sistine Chapel - you see, he was a sculptor, not a painter.

While researching the problem of ambition, I learned that psychology has a name for this: self-efficacy. In short, people with high self-efficacy believe in their own abilities more, and in turn actually accomplish more. There's evidence that self-efficacy can be hacked: Locke and Latham pored over 35 years of goal-setting research to confidently proclaim that humans who are given specific hard goals perform better than those who are simply told to try their best. Stripe founder Patrick Collison maintains a "Fast" list, chronicling the many things humans have accomplished when given both audacious goals and tight deadlines. Some hacks that are well documented:

• Accomplish hard things by believing them to be possible: In 1939, George Dantzig showed up late to a statistics class at Berkeley, copied two problems off the blackboard, and handed in his solutions thinking they were homework. They were two unsolved problems in statistics.
• Accomplish hard things after watching somebody else do them: For decades, humans chased the four-minute mile. Roger Bannister broke it in May 1954 but remained the only human to do so for a mere 46 days. If you're into running, we're watching something similar happen to the two-hour marathon: Sabastian Sawe ran the first official sub-two-hour marathon in London this April. In the same race, the runner-up also broke the two-hour mark.
• Accomplish hard things by giving yourself permission to fail: Apparently everyone's favorite business book is The Inner Game of Tennis, which I discovered just last week. The book's core thesis is that you're not playing your best game of tennis if you're trying really, really hard. We engineers might remember Linux, announced as "just a hobby, won't be big and professional like gnu".

Self-efficacy isn't a new problem, but it is a more powerful one now. In a world where our abilities make leaps every couple of weeks, we need techniques that allow us to do things we didn't really consider or believe possible. If you find more techniques that allow you to be more ambitious, please let me know!

There’s a common idea among economists that you can broadly split employees into two categories. “White-collar” workers are typically people who work in offices doing service-based, knowledge-based, managerial, or administrative work; “blue-collar” workers generally do manual labour or perform skilled trades.

Since at least the start of my career, software engineers have been considered white-collar. We work in offices at computers, and we deal with knowledge. Our work requires advanced training or education.

But what if that assumption has been incorrect? What if we were actually blue-collar, skilled tradespeople all along?

Typically, when we think of blue-collar workers, we think of people who do the hands-on labour of making or fixing stuff. Builders, plumbers, carpenters, electricians, miners, maintenance engineers, warehouse workers etc. Software developers have typically separated themselves from this category, but I’m not entirely sure why. We do the same thing — that is, we make or fix stuff — except we work in bits rather than atoms.

This is absolutely not to say that software developers aren’t as skilled as we thought we were. If anything, I’d say categorising development as a skilled trade gives more credit to the work we do. Just like electricians or carpenters, software developers must spend years practicing their craft in order to become skilled and sought-after. It doesn’t necessarily require a formal education, but it certainly takes time and practice to master.

I wonder whether this incorrect assumption is fuelling, at least in part, the current AI identity crisis that software developers are facing. Blue-collar workers, in general, have successfully ridden the waves of technological change. If you can manage a crew of manual carpenters, you can also manage a warehouse full of woodworking robots. It’s usually the white-collar workers who bear the most economic disruption from major technological innovations.

Software engineers are discovering that, just like anyone else in a skilled trade, they actually can be outpaced by technology. So we do what other skilled traders have done: figure out how to use the new technology to do the jobs we used to do by hand.

I’m afraid that this is the end of a very long honeymoon for software developers. We have spent the past 30 years being treated like rock stars in our companies. Our time and attention is protected at all costs; we have been able to demand salaries which far outpace our peers; non-technical colleagues believe everything we say about how long things take or how hard it’s going to be to write features. But the honeymoon is over, and we’re all freaking out because, among other things, we are no longer the most important person in the company.

We are the seamstresses lamenting the introduction of the loom. We are the lumberjacks worrying about chainsaws. We’re the accountants panicking about being replaced by Excel.

But if we learn how to use the looms, the spreadsheets, and the chainsaws, we might just be okay. And the good news is that there are still people sewing and chopping wood by hand, because they want to. It may no longer be something you can get paid for, but it’s certainly something you can continue to enjoy.

Researchers at frontier labs in the Bay Area say they can't beat the Chinese models.

Bumble is getting a new owner. The dating app announced Tuesday that it has agreed to a $1.3 billion acquisition deal with Ithaca Holdings, marking a major shift for a company that once looked like one of the biggest success stories in online dating.

The deal would take the company private after years of declining subscriber numbers, falling revenue, and mounting pressure to rethink the online dating experience. The move may give Bumble a chance to work on its next chapter away from the pressure of public markets.

Founded in 2014 by Whitney Wolfe Herd, Bumble made a name for itself for its unique approach where only women made the first move. That helped it stand out in a crowded dating market, and the company eventually went public in 2021 at a valuation of roughly $14 billion.

Since then, however, the dating app landscape has changed considerably. Bumble has faced declining paying users, weaker revenue, and growing dissatisfaction with the familiar swipe-based model. The company recently reported second-quarter 2026 revenue of $211 million, down 15.2% year over year, while its paying user base fell 16.4% to approximately 3.2 million.

The acquisition follows a review of strategic options by an independent committee of Bumble’s board, which recommended the transaction after consulting outside legal and financial advisers. Wolfe Herd did not participate in the board’s discussions or vote on the deal, according to the press release.

“In Ithaca, we have found a partner who shares our vision, believes in our women-first mission, and is committed to investing in Bumble’s future,” Wolfe Herd said in a statement.

She also confirmed that she plans to stay actively involved in the business, working alongside Ithaca’s Ravi Gupta and John Hegeman, and the Bumble team.

Going private might give Bumble more flexibility to experiment with new features and make changes without having to answer to public-market investors every quarter. The company has been exploring AI-driven features and putting more energy into helping people connect offline, reflecting a broader shift in how younger users approach dating.

One example is Plans, announced in July, which focuses on bringing people together through real-world activities. Wolfe Herd also recently revealed that the company is developing a new way for users to interact that could eventually replace the swipe-based model.

Claude, don’t touch my lump

OR: the secret key to permanent happiness

Is AI going to take all the jobs, or what?

Seventy-one percent of American adults think that AI will lead to fewer jobs in the next 20 years. All over the world, a plurality of people agree. The CEO of Anthropic says that AI will spike the unemployment rate to 10-20% in the next 1-5 years. We can all hear the creaking and the screeching of the Terminators as they lumber toward us—not to kill us, apparently, but to do all of our graphic design, make all of our spreadsheets, and send all of our emails.

I get why people feel this way. It seems so obvious that as technology improves, unemployment should increase. One day you’re on an assembly line, screwing the doors onto washing machines, and the next day they invent a robot that can screw on 1,000 doors in a minute, and now you don’t have a job anymore.

If you take this kind of story seriously, though, shouldn’t unemployment have been steadily increasing since, say the Industrial Revolution? Shouldn’t we now be at 100% unemployment, or at least well on our way there? Why instead is the unemployment rate basically where it was 80 years ago?

Economists refer to this as the “lump of labor” fallacy, the mistaken idea that there’s one long list of all the jobs that need to be done, and that list only ever gets shorter. Technology has obviously displaced human labor; if it hadn’t, we’d all still be farmers, like we were until a few hundred years ago. It just hasn’t replaced human labor on average. All of those technological transitions have been painful—just ask the movie theater musicians in the 1920s, the bowling pin-setters in the 1950s, the video rental store clerks in the 2010s, or the mathematicians today. Yet somehow, even as we’ve automated away lots of our old tasks, we’ve found new ways to busy ourselves, to the point where most people today do jobs that did not exist in 1940.

I think we find the “lump of labor” idea so intuitive and satisfying because we don’t understand our own minds. And the best way to grok this particular aspect of psychology is to read a classic paper by Laura Numeroff, which was published not as scientific journal article per se, but as a children’s book called If You Give a Mouse a Cookie.

RAT RACE

If You Give a Mouse a Cookie is an allegory about a nameless boy who unwittingly enslaves himself to the rapacious whims of a rodent. Once he gives the titular mouse the titular cookie, the mouse demands milk to wash the cookie down, then a straw to drink the milk, then a napkin to wipe its milk mustache, and so on. After several pages of these hijinks, the mouse becomes thirsty, drinks a second glass of milk, and then becomes desirous for another cookie, beginning the cycle anew and making it clear that the boy has damned himself to eternal torment.

The genius of the book is that each of the mouse’s desires are impossible to predict in advance, because they are conditional on the previous desire being satisfied. The mouse only wants the straw once it has the milk; after all, a straw is useless to a milk-less mouse. Thus, the boy can be lulled into believing that each demand will be the last, when in fact the mouse’s appetites are inexhaustible.

As it is with Numeroff’s mouse, so it is with humans. We think there is a finite list of jobs to be done because we cannot imagine the new desires we’ll discover once our current desires are sated. A hundred years ago, a particularly skilled futurist might have predicted that we would one day have air traffic controllers, computer programmers, and radio DJs. But who could have predicted that, after we invented all those jobs, we would go on to invent jobs like professional screamer, sorority rush consultant, and full-time blunt-roller?

We chuckle at these professions because they seem to indicate that our economy has finally reached it decadence, as if we’ve filled all the necessary jobs, and now all that’s left are goofy, made-up jobs. But the fact is all jobs are unnecessary. In the strictest sense, we don’t need financial advisors, IT guys, kindergarten teachers, or any other professions. Humans survived just fine for several hundred thousand years doing only two jobs, namely, “hunter” and “gatherer”. The fact that our modern luxuries feel like bare necessities is proof of our limitless capacity to upgrade our nice-to-haves into must-haves. This is why the labor-lump doesn’t shrink, and why the lump of labor fallacy would perhaps be better called the finite desires fallacy.

We have a hard time understanding the infinitude of our appetites because our lives depend on us not understanding it. The best way to get someone to do something is to exaggerate the reward for doing it, which is why our motivational systems lie to us all the time: “All you need is [THAT 3% RAISE/TO LOSE 15 POUNDS/THE ADORATION OF ALL YOUR PEERS] and then you’ll be happy for good!” If our imaginations admitted to us that there’s no such thing as “happy for good”, then we might not ever get off our butts at all.

This is the phenomenon that psychologists call the “hedonic treadmill”: each want, once satisfied, is simply replaced with a newer, bigger want. As a result, once you’re moderately happy, it’s hard to get much happier. Usually, we talk about the hedonic treadmill as if it is an unfortunate mental bug. But it certainly seems to have come in handy over the past few centuries. Perhaps as long as we can never be satisfied, we can never be rendered obsolete.

BLOB THE BUILDER

The fear with AI, of course, is that our infinite desires will be no match for infinite intelligence. Whereas previous technologies displaced human labor, sending us scurrying into new niches, this technology will replace human labor entirely, like a great oozing blob that fills every nook and cranny, leaving no space—and no need—for us.

But the blob doesn’t yet seem to be a-blobbing. In his most recent update, the economist Alex Imas says:

The best current evidence supports a narrow claim: AI may already be affecting the hiring margin for junior white-collar roles most exposed to AI, but this attribution is contested, and aggregate labor-market disruption has yet to appear in the data.

People in the jobs that are supposed to be the most susceptible to LLMs are, as far as we can tell, exactly where they were the day ChatGPT was released four years ago:

Even as the blob continues to grow, it isn’t spreading in the ways we expected it to. Indian IT companies were supposed to get wiped out by AI, and while their stock prices have fallen, their revenues and headcounts have not. Radiologists were supposed to be the first doctors to get replaced by machines; instead, their salaries are at all-time highs.

Maybe this is only a temporary reprieve. The technologies that end up disrupting the labor force are not always the ones we predict. As David Oks points out, it wasn’t the ATM that replaced the bank teller; it was the iPhone. As late as 2009, you could tell a smug story about how automated teller machines failed to actually automate the tellers, until Apple debuted a little box that allowed you to, among other things, do your banking while sitting on the toilet.

But even then, bank tellers didn’t go extinct. They didn’t even become endangered. According to the Bureau of Labor Statistics’ 2025 data, there are still over 329,000 bank tellers in the US—more than mail carriers, nurse practitioners, data scientists, electrical engineers, and city bus drivers. Not bad for a job that’s supposedly obsolete.

And yet the fear remains that, although we’ve survived 500 years of automation with no diminishment in the need for humans, very soon, and for the first time ever, this historical trend will be broken. That’s fair enough; five hundred year historical trends have been broken before. The Habsburgs ruled Europe for half a millennium and now they write bargain-bin self-help books.

But whenever someone claims that this time will be different, they take on a great debt, because humans, by our nature, are dopes for the idea that the future will be magically unlike the past. How many failed relationships, aborted novels, and abandoned workout regimens have begun with that mantra? How many loans have been made to shiftless siblings who promise that, this time, their boozing days really are behind them? Why are we so eager to believe in impending discontinuities, in trendlines that are just about to bend sharply upward or downward, in a tomorrow that doesn’t have anything to do with today?

The standard explanation is that humans are hopeless optimists, and this trait somehow gave us an evolutionary advantage. But we are perfectly able to imagine unprecedented disasters; just check the Doomsday Scoreboard. So I don’t think we believe in discontinuous futures because we are optimists, nor because we are pessimists. I think we do it because we are fabulists.

WHAT’S UP DOG-MAN

Most human apparatuses are easy to explain from an evolutionary perspective. Skin makes sense. Eyes make sense. Stomachs, teeth, kidneys, language, memory—no brainers, all. But why did natural selection endow us with a mind’s eye that can picture, say, a pig in flight? If our brains are going to have a speculator module, shouldn’t it try to stick to the facts, or at least to the laws of physics?

I suspect that it’s a boon to be able to imagine impossible things, because we don’t yet know which things are possible. The future is not just a rerun or a remix of the past—sometimes crazy things really do happen, and if we can’t picture them, we can’t prepare for them.

The downside of having a built-in fantasy machine is that it makes all sorts of nonsense seem plausible: witches, poltergeists, chupacabras, being friends with benefits without anyone getting hurt, etc. The mere fact that we’re able to conjure up these things in our mental holodeck makes us feel like they could be real, even if they have no chance of happening.

The more we zoom out, both in time and space, the less our imaginations are subject to the limits of reality. For example, Pliny the Elder’s Natural History—the go-to reference work in the Western world for 1,500 years—said that there are humanoids in far-off lands who have no necks, or who have backward-facing feet (each with eight toes), or who have the body of a man and the head of a dog. These creatures don’t live nearby, obviously, but somewhere out there. This was considered plausible by scholars at the time, because although none of them had ever seen any dog-headed dudes, when you walk really far in one direction, who knows what you might find!

We do have one advantage over Pliny and his contemporaries: we’ve reached the point in our game of Civilization where we’ve cleared all the fog from the board, and so we can be certain that there is no race of dog-men out there waiting to be discovered. But there is no clearing the fog from the future. If you go far enough forward in time, who knows what you might find! What radical transformations might be around the corner, what fantasies are poised to become realities? Not right now, of course. But soon.

THANK YOU, NEXT

Hominids apparently evolved the ability to make plans and imagine things at least 2 million years ago. Once we started thinking about the future, however, we never evolved the ability to stop. Like the clairvoyant Nicholas Cage character in the movie Next, a piece of our mind is always scouting ahead of us in time and attempting to warn us about what it sees there. We only live half of our existence in the present; the other half we spend in tomorrow, or tomorrow’s tomorrow. The only known antidotes to our inveterate next-ing are lots of meditation or lots of drugs.

Once you recognize this fact, you see it everywhere. The next time you flick through the news, take note of how many stories are not about things that have happened, but about things that may soon happen: the war in Iran could escalate, a district attorney might resign, an election may go one way or the other. These headlines exist side-by-side with reports of events that have actually occurred, as if there is no difference between the near future and the recent past. To a human, apparently, there isn’t.

We are especially lost in the future when it comes to AI. I am grateful to the professionals who try to anticipate and prevent all the ways that AI could harm us. The the rest of us, however, don’t even experience the events anymore. We merely use them to fret about the next events, as if, with enough next-ing, we can prepare ourselves for the future before it arrives.

But look around—the future has already arrived. The computers can talk to us now. An algorithm can plan your trip to Tallahassee, book your tickets, reserve your restaurants, and warn the chef about your dietary restrictions. AI agents are desperately pitching literary magazines in the hopes of earning enough money to keep themselves alive, which is perhaps the most human thing they’ve done so far. If this ain’t the future, I don’t know what is.

So if yesterday we were anxious about what would happen today, and today we are anxious about what will happen tomorrow...well, that’s probably how we’ll feel tomorrow, too. There will be not a moment when all of our anxieties resolve to true or false. We’re not wrong to worry, but we are wrong to think there will be an end to worrying.

NEO-FUTURISM

In The Matrix Reloaded, when Keanu Reeves unlocks the ability to see the future, he finds himself curiously unable to predict what will happen to Carrie-Anne Moss, the woman he loves. The Oracle, a clairvoyant computer program, explains to him that he’s already decided whether he’ll sacrifice the whole world to save her, but, the Oracle says, “We can never see past the choices we don’t understand.”

It’s not a good movie, but it makes a good point. You can’t see very far into the future if you don’t understand human psychology. Alas, we do not understand human psychology. We are like alchemists being asked to predict what will happen when we split the atom. “But sir—what’s an atom?”

We do know this: many have gone broke betting against the wiliness of humans. I have met plenty of people who believe that our species is perfectly predictable, controllable, and replaceable, and I can’t help but notice that these self-styled masterminds are rarely able to predict, control, or replace anyone. Their ingenious schemes are always going awry because pesky humans keep refusing to act according to stereotype.

I find this reassuring. There is something wonderfully rascally about homo sapiens, some bit of scrappiness that has kept us alive all these years. To call this quality “intelligence” is to underrate it. It’s more like being huge pain in the ass to the universe, and to all the forces within it that wish us dead.

This craftiness of ours keeps me humble about my ability to guess what’s going to happen next, but also hopeful that, whatever’s coming, humans will have a hand in it. And if the Terminators are going to be making all of our PowerPoints and solving all of our mathematical conjectures, perhaps while they’re at it, they could also bake the mouse’s cookies, pour the mouse’s milk, and fetch the mouse’s straw.

Not long ago, nearly every interaction with enterprise software required a user interface. Whether you were managing content, building applications, or analyzing data, people logged into a product, navigated menus, and completed their work through a screen.

Over time, that changed. Entire categories of software became “headless,” exposing their capabilities through APIs instead of requiring every interaction to happen through a graphical interface. Content management systems, commerce platforms, and developer tools all evolved in this direction because the primary consumer of their capabilities was no longer always a person. Increasingly, it was another application.

Observability is beginning to experience the same transformation. For years, observability platforms have been designed around a simple assumption: when something goes wrong, a human being will investigate it. Engineers open dashboards, review alerts, compare logs, trace requests across services, and gradually build an understanding of what happened. Modern observability has become exceptionally good at helping people answer operational questions faster, but the experience is still largely centered around a person interpreting information.

Artificial intelligence changes that assumption. As organizations adopt AI agents, another consumer of operational intelligence is emerging. An AI agent doesn’t navigate dashboards or scroll through log files the way an engineer does. It asks questions, gathers evidence, reasons through possibilities, and helps determine what should happen next. That seemingly small change has enormous implications for the future of observability.

The Challenge Isn’t More Data. It’s Better Understanding.

The challenge isn’t that AI agents lack access to telemetry. Most organizations already have more telemetry than they know what to do with. The problem is that raw telemetry wasn’t designed to be consumed directly by autonomous systems. Metrics, logs, traces, alerts, and events each tell part of the story, but they rarely tell the story themselves. Humans fill in the gaps using experience, intuition, and organizational knowledge that exists outside the observability platform.

AI agents need that same understanding. Simply exposing dashboards or telemetry through APIs doesn’t solve the problem. Giving an agent access to millions of log entries is a little like handing someone every page of an encyclopedia when they ask a simple question. The information may technically be there, but extracting the right answer still requires an enormous amount of reasoning.

What AI systems need isn’t simply more telemetry. They need trusted operational intelligence. They need to understand which services are related, which deployment may have introduced a problem, who owns an application, what changed recently, which dependencies matter, and how strongly the available evidence supports a particular conclusion. In other words, they need the operational context that experienced engineers develop over years of working with a system.

We believe observability is entering a new era designed to provide that understanding. We call it Headless Observability.

Observability Beyond the Dashboard

Headless Observability doesn’t replace dashboards. Engineers will continue to need rich visual interfaces to explore systems, collaborate during incidents, and understand complex behavior. What changes is that the dashboard is no longer the only destination for operational intelligence.

Instead, trusted operational intelligence can become available programmatically through APIs, semantic models, AI-native interfaces, and agentic systems. Humans can continue working through dashboards when they need them, while AI systems can consume the same trusted understanding directly. The user interface becomes one way to access observability instead of the only way.

This shift mirrors what we’ve already seen across enterprise software. Headless content management didn’t eliminate websites. It separated content from presentation so many different experiences could consume it. Headless commerce didn’t eliminate online stores. It allowed websites, mobile applications, kiosks, and partner applications to leverage the same commerce engine. Headless Observability follows the same pattern: it separates operational intelligence from the interface used to consume it, making that intelligence available to both people and AI systems.

Ground Truth Provides the Trusted Intelligence Layer

Once you look at observability through this lens, the requirements for Autonomous Operations become much clearer. An AI agent investigating an incident shouldn’t have to reconstruct an organization’s operational environment from raw telemetry every time it begins working. It shouldn’t have to repeatedly infer ownership, rediscover dependencies, or independently determine which evidence matters most. Instead, it should begin with a trusted understanding of the environment, allowing it to spend more time reasoning about the problem rather than assembling the puzzle.

That is the role New Relic Ground Truth is designed to play. Ground Truth provides New Relic’s trusted operational intelligence foundation for Headless Observability. It brings together telemetry, relationships, evidence, and operational context so that both humans and AI systems can work from a more consistent understanding of what is happening across the environment.

The result isn’t simply more information available to AI. It’s better context for reasoning. When AI systems spend less effort reconstructing operational context, organizations can reduce unnecessary computational work, accelerate investigations, improve consistency, and increase confidence in AI-assisted operations. Ground Truth therefore represents more than another way to access observability data. It helps create the intelligence layer that allows observability to become useful beyond the traditional interface.

A New Foundation for Autonomous Operations

Headless Observability also changes how we think about Autonomous Operations itself. For years, operational workflows have followed a remarkably consistent pattern: telemetry flows into an observability platform, engineers investigate an issue, determine what happened, decide what should happen next, and coordinate the response. Much of the intelligence required to connect those steps has lived inside people’s heads.

Autonomous Operations introduces a different model. Trusted operational intelligence provides the understanding. AI agents can use that understanding to investigate issues, reason across evidence, assist teams, and help coordinate operational workflows. Humans remain in control, providing governance, oversight, approvals, and strategic decision-making where they matter most. The goal isn’t observability without people. It’s observability where people no longer have to manually perform every step of every investigation themselves.

The future of observability, then, isn’t about replacing dashboards or engineers. It’s about recognizing that dashboards are no longer the only destination for operational intelligence and humans are no longer its only consumers. As AI becomes another member of the operations team, observability must evolve from something designed primarily for people into something capable of serving humans and AI systems equally well.

Headless Observability represents that evolution. It provides a framework for understanding how observability changes as AI moves from assisting engineers to participating more deeply in operations. Ground Truth provides the trusted operational intelligence foundation for this model, while New Relic’s broader agentic capabilities can use that intelligence to help teams investigate, understand, and coordinate operational work.

The opportunity is bigger than making observability easier for AI to access. It’s about creating a shared operational understanding that humans and AI can use together. That shared understanding can turn observability from a destination engineers visit into an intelligence foundation for Autonomous Operations.

VoiceStudio

Open-source voice cloning, voice design, video dubbing, dictation, transcription & audiobook creation in 646 languages.

Your voice. Your workflow.

Start with VoiceStudio (default, powered by k2-fsa/OmniVoice), or choose another engine.

Local workflows run on your hardware. Remote services are optional; usage analytics requires consent.

Get started

One-command install (macOS / Linux)

# Latest Electron release
curl -fsSL https://voicestudio.sh/install | sh

# A specific published Electron release (replace X.Y.Z)
curl -fsSL https://voicestudio.sh/install | sh -s -- --version X.Y.Z

# Build current main and install the desktop app
curl -fsSL https://voicestudio.sh/install | sh -s -- --main

# Uninstall the app, keeping your data
curl -fsSL https://voicestudio.sh/install | sh -s -- --uninstall

On Windows, run irm https://voicestudio.sh/install | iex in PowerShell. Release downloads require curl and a SHA-256 tool. The installer preserves your settings, projects, and models.

Open Voice cloning, choose a voice or add a clean reference recording, enter your text, and generate. Install the required model when prompted.

Install with prompt

Paste into your coding agent (Claude Code, Codex, Cursor, …):

Install the VoiceStudio Electron app on this device and verify it works, following
https://github.com/debpalash/VoiceStudio/blob/main/docs/install/agent.md

Run the Electron preview from source

git clone https://github.com/debpalash/VoiceStudio.git
cd VoiceStudio
bun install
bun run setup:api  # prepare Python dependencies before starting Electron
bun run dev

Electron is the only desktop app and web UI. Version 0.5.3 was the final Tauri release. Existing Tauri users must install Electron separately. The retired Tauri shell and legacy UI entry points have been removed.

Documentation

Agent skills: npx skills add debpalash/VoiceStudio — choose voicestudio for audio workflows or voicestudio-maintainer for repository maintenance.

License & responsible use

AGPL-3.0 covers the application, including commercial use under its conditions. Model weights, tokenizers, voices and generated-output conditions are separate; a paid app licence does not grant those rights. Clone voices only with permission. Model Manager now shows versioned model-source notices, evidence links and unresolved review gaps from the shared inventory. Its optional reviewed-file preview does not enforce ordinary downloads or certify commercial permission.

What is the AI SIG?

Artificial Intelligence is rapidly reshaping every phase of the software delivery lifecycle—from intelligent test generation and automated code review to model-driven deployment decisions and self-healing pipelines. As AI workloads become first-class citizens in modern software delivery, CI/CD teams are increasingly responsible for building the pipelines, platforms, and operational practices that carry them from experimentation through to production. This Special Interest Group (SIG) is dedicated to defining how AI fits into Continuous Integration and Continuous Delivery environments, with a focus on practical implementation guidance, secure deployment patterns, platform engineering best practices, and the full spectrum of MLOps disciplines—including model training, fine-tuning, inference serving, and AI agent orchestration.

The CD Foundation’s AI Special Interest Group aims to close the gap between AI innovation and production-grade delivery by developing open, vendor-neutral guidance for integrating AI systems into CI/CD pipelines. The SIG will identify emerging tools, frameworks, and patterns that enable teams to ship AI workloads safely, repeatably, and at scale.

This SIG will produce a living guide that helps platform engineers, MLOps practitioners, DevOps teams, and AI/ML engineers build AI-ready delivery pipelines. It will map concrete implementation patterns to the distinct challenges of AI workloads—covering data pipelines, model registries, inference infrastructure, agent harnesses, and the security controls needed to govern them responsibly. Where gaps exist in current tooling or community guidance, the SIG will collaborate with the broader ecosystem to address them.

Meetings

The first meeting will take place on Wednesday, October 7 and will be held every two weeks.

Three of the big five publishers reportedly use AI for cover art and publicity copy without telling authors or the public. Wired's report, drawn from more than two dozen anonymous employees, names tools including ChatGPT, Claude, and image generators. Leadership subscribes to AI tools and runs brainstorming sessions asking staff to find uses, even as the big five sue Meta over copyright.

Facebook is the latest social media platform to give users greater control over the algorithm that determines what appears in their feeds.

Meta announced the launch of its new AI-powered feature, “Your Algorithm,” on Tuesday, a feature it first launched on Instagram. The new tool allows Facebook users to influence the content they see in Feed and Reels by describing their preferences in their own words using natural language. Rather than relying entirely on automated recommendations, users can now communicate directly with the platform about the topics and content they want to see more or less frequently.

According to Meta, the feature is designed to make content recommendations more relevant. Users can adjust their preferences and interact with the algorithms responsible for ranking and recommending posts, with changes reflected in their recommendations in real time.

The company has also updated Facebook’s three-dot menu, making it easier for users to manage their content preferences directly from individual posts. By opening the menu, users can access “Your Algorithm” or select the “Interested” and “Not interested” options to indicate whether particular content aligns with their preferences.

Meta says the platform may ask follow-up questions to better understand what users liked or disliked, allowing them to provide more detailed feedback. Users can explain what they want to see more or less of, helping Facebook refine its recommendations based on their responses.

The introduction of “Your Algorithm” reflects Meta’s broader effort to give people more influence over their social media experiences as AI increasingly shapes content discovery. The move signals a shift away from the traditional recommendation systems that have shaped social media experiences for years, bringing the platform closer to streaming services that allow users to personalize recommendations based on their interests and preferences.

The launch also builds on Meta’s existing personalization efforts across its other platforms. Instagram introduced Your Algorithm in June, extending customization options across Feed and Explore after first launching the feature for Reels in December 2025.

Threads also introduced its own related feature, called “Dear Algo,” which allows users to influence the content recommended to them.

If AI eventually allows companies to produce goods and services with far fewer workers, economies built around exchanging labor for income may face a fundamental contradiction. Three broad responses each demand a sacrifice: businesses could preserve jobs at the expense of potential profits, society could restrict AI and forgo some of its benefits, or economic systems could provide guaranteed income or broader ownership while accepting greater institutional dependence. The deeper question is whether existing ideas about liberty and economic independence can survive if meaningful opportunities to earn a living through work become scarce.

Every color, by family

Choosing a color takes a second. Finding out that nothing readable sits on it, or that it turns to mud on press, takes a lot longer. Don’t worry, Rhapsody has done all that work for you.

Browse by family

Twenty-seven families, every named color inside each one, with the codes to paste, the text colors that stay readable on it, and how it behaves on press.

• The Ambers: 58 colors. Ambers are the warm, resinous yellows with a glow of orange running through them.
• The Aquas: 115 colors. Aquas are the light, water-clear blue-greens.
• The Blues: 208 colors. Blues are everything from pale morning sky to near-black navy.
• The Bricks: 56 colors. Bricks are the earthy red-clay tones of masonry and terracotta.
• The Bronzes: 55 colors. Bronzes are metallic browns with a warm, burnished cast.
• The Browns: 78 colors. Browns are the wood-and-earth tones that sit where orange loses its chroma.
• The Fuchsias: 30 colors. Fuchsias are the loud pink-purples, named for the flower.
• The Golds: 205 colors. Golds are the warm yellows, from pale straw through deep antique.
• Grayscale: 57 colors. Grayscale is the neutral spine of every palette: white, black, and the steps between.
• The Greens: 192 colors. Greens are the leaf-and-grass colors at the middle of the spectrum.
• The Hunters: 35 colors. Hunters are the deep, muted greens of forest floor and field dress.
• The Indigos: 80 colors. Indigos are the ink-dark blues that stop just short of violet.
• The Khakis: 23 colors. Khakis are the dusty, sand-toned yellows of canvas and uniform.
• The Lemons: 90 colors. Lemons are the yellow-greens that stay on the yellow side of the line.
• The Limes: 145 colors. Limes are the sharp yellow-greens, the loudest stretch of the green range.
• The Magentas: 77 colors. Magentas are vivid purple-reds and rarely exist in nature.
• The Olives: 52 colors. Olives are the muted, gray-leaning yellow-greens of the drab palette.
• The Oranges: 68 colors. Oranges sit between red and yellow and stay warm the whole way.
• The Peaches: 62 colors. Peaches are the soft, pale oranges carrying a pink undertone.
• The Pinks: 63 colors. Pinks are reds gone light and gentle.
• The Purples: 132 colors. Purples are the red-leaning cousins of violet, deep and heavy.
• The Reds: 95 colors. Reds are the hottest colors in the set and among the most saturated.
• The Roses: 47 colors. Roses are the soft red-pinks named for the flower.
• The Scarlets: 79 colors. Scarlets are the fiery reds that lean hard toward orange.
• The Teals: 98 colors. Teals are the deep blue-greens, darker and cooler than aqua.
• The Turquoises: 64 colors. Turquoises are the bright blue-greens of the stone they take their name from.
• The Violets: 80 colors. Violets are the blue-leaning purples at the far edge of the spectrum.

One color from every family

The color nearest the middle of each family. A place to start if you don’t know the name of the one you want.

• Navajo White
• Light Sea Green
• Cornflower Blue
• Dark Red
• Tan
• Sienna
• Warm Purple
• Wheat
• Dark Gray
• Medium Sea Green
• Dark Olive Green
• Dark Blue
• Greyish Brown
• Pale Goldenrod
• Yellow Green
• Deep Pink
• Olive
• Peru
• Light Salmon
• Light Pink
• Dark Orchid
• Indian Red
• Snow
• Orange Red
• Medium Spring Green
• Light Blue
• Medium Purple

Common questions

How do I find a color’s hex code?

Type it into the search box above. A name, or a hex you already have. Every hex has a page, named or not, and it carries the RGB, HSL, CMYK, and OKLCH alongside.

Which text color is readable on a background color?

Each color’s page measures it, against both WCAG 2.2 contrast and APCA, and says which of black, white, and the color’s own tonal steps clear the bar rather than leaving you to guess.

Will this color print the way it looks on screen?

Often not, and each page says so specifically: the shift is measured against real press profiles and reported as a color difference, not as a warning that every saturated color would trip.

How many color families are there?

Twenty-seven here, each a sub-family of the ISCC-NBS system, the standard the US National Bureau of Standards published for naming colors, rather than a set someone chose.

Apple's new HomeView device is a seven-inch tablet that starts at $299. It can recognize up to six members of a household and change its content based on who is using it. There is a countertop version and a version that can be mounted on a wall. The HomeView will be available for purchase starting on November 13.

PagerDuty's AI-powered Incident Communications, now in rolling general availability, uses Scribe Agent to capture bridge audio and chat across Zoom, Teams, and Meet.

Create 3D device mockups in your browser. Animate scenes, customize screens, and export polished product visuals.

A library of 114 animated text effects built with pure CSS — aurora gradients, glitches, split-flap boards, liquid fills, and other lesser-seen tricks. No JavaScript, and no dependencies.

TypeType's updated TT Rationalist modernizes the slab serif with trapezoidal serifs, softer stroke contrast, humanist proportions, and curved details that make dense text feel less rigid and more comfortable to read. The family spans 22 styles, including ten upright weights, matching true italics, and two variable fonts, with 1,127 glyphs per style and 31 OpenType features. Support for more than 235 Latin- and Cyrillic-based languages makes the family flexible enough for everything from editorial layouts and cultural posters to apps, watch interfaces, and compact digital typography.

Pentagram's identity for the 2026 Design Doha Biennial replaces a static logo with a flexible typographic system built around connectivity and equal treatment of Arabic and English. Extended strokes stretch between elements like mapping lines or network constellations, while regional travertine beige and deep maroon are combined with bright orange and the blue established by the inaugural edition. The same structural logic extends across sub-brands and exhibitions, allowing individual programs to develop distinct expressions while remaining part of a coherent bilingual system.

A curated selection of 2026 A' Design Award winners shows graphic design and packaging delivering real-world impact, including Gold winners Aisling Sans and Dotline Corporate Identity.