In “Don’t Automate Your Moat,” I argue that engineering organizations should match AI autonomy to two independent dimensions: business risk and competitive differentiation. I used AI Gateway cost controls as a worked example throughout the piece because a single feature touches all four quadrants depending on which piece you’re building.

A piece making that argument should probably be written that way. Otherwise the framework is just rhetoric. So here is what actually happened: The same quadrants, applied to the writing of the post, then the two practices that cut across all of them.

Full Automation: The citation mechanics

My post has eighteen footnotes, all of them needing consistent structure, working URLs, and clean formatting. This is the work the bottom-left quadrant exists for. If a URL is wrong, I fix it in the next pass and nobody outside the editing loop notices.

AI handled the mechanical assembly. I spot-checked.

Collaborative Co-Creation: The AI Gateway example and the build-versus-buy framing

Two things sit in this quadrant.

The AI Gateway example. Using a single feature as a lens across all four quadrants was a product decision for the post. But the choice of which feature, and how to slice it, was recoverable. A weaker example, or one split across three features, would have cost me a draft. AI accelerated execution once I had settled on cost controls. I drove the design choice and interrogated the trade-off.

The build-versus-buy framing. This one was collaborative. Claude proposed the concept and the analogy: that the token-funded generation loop is functionally a procurement decision, not a build decision, even though the code lives in your repo. I saw what the framing could do for the structure of the argument, that it could link cognitive debt to competitive differentiation, survive a skeptical CTO reading it cold, and give the post a through-line that held the whole piece together. From there we worked it together. My phrase “a buy decision wearing a build costume” came out of that back-and-forth, and the structure of the argument got reshaped around the framing until it actually carried. Neither of us would have produced the final version alone. That is what this quadrant is supposed to look like.

In both cases, AI moved fast on execution. The judgment about whether the contribution fit, and what work it had to do in the surrounding argument, stayed with me. Flip the ratio and the post gets worse. Not catastrophically. Just generic in places where specificity was the whole point.

Supervised Automation: The counterargument section

The research is thin. Most engineering work is maintenance and belongs in the automate quadrant regardless. Engineers can develop ownership of AI-generated code through study and iteration.

These are the objections any thoughtful reader would raise. Not because the post is anti-AI (it is not). The argument is that AI autonomy has to be matched with sufficient human understanding, and that argument has to defend itself against the case for letting AI run further with less. AI could draft the shape of those objections.

My job was verification. The bar was whether a thoughtful reader who disagrees with me would find the steelman fair. That meant tracing each concession back to make sure I was not giving away something I should have held, and each objection back to make sure I was representing the strongest version of the case rather than a convenient strawman.

The risk here is subtle. The section is unlikely to be flat-out wrong. The danger is that an unfair steelman quietly undermines the rest of the argument. A reader who notices a weak counterargument starts wondering what else is rigged. AI drafts, human verifies every path before merge.

Human-Led Craftsmanship: The parts I owned outright

This is where most of the actual time went.

The opening. The engineer who could not explain his own algorithm. The colleague paged about a service connected to a database nobody documented. Those examples were mine. The post only works if those scenes feel true, and a generated approximation of them would have read like exactly that. Not a risk worth delegating.

Defining the dimensions. Naming risk and differentiation as the two axes is one thing. Defining them in a way that holds up under pressure is another. The prose that establishes what business risk actually means (blast radius if this fails, from an afternoon to the business itself), and what competitive differentiation actually means (not the brand or the sales team, but the architecture, the algorithms, the institutional judgment that shaped them), is what every quadrant boundary depends on. If those definitions are vague, the quadrants become Rorschach tests. If they are sharp, the quadrants do real work. I wrote and rewrote those passages until a reader could apply them to their own systems without me there to translate.

The framework and the evidence behind it. The two-dimensional framing came out of my own thinking before Claude entered the loop. Once the dimensions existed, iterating with Claude on how to sharpen them was useful. It pushed me on where the dimensions overlapped and where the quadrant labels were doing too much work. But the seed had to be mine. A framework generated from a prompt would have read like one.

The evidence behind the framework worked the same way. I came in with a starter set of papers I already trusted: the METR productivity study, the MIT cognitive debt work, the Anthropic Fellows skill formation paper, the GitClear data on refactoring decline, and the Tilburg study on senior developer maintenance burden. Those were mine. From there, Claude expanded the research base, surfacing the Lancet endoscopy deskilling study, the OX Security and CodeRabbit and Apiiro analyses, and the survey work on LLM code generation in low-resource domains. That expansion was genuinely useful. It made the post broader and more current than what I would have assembled alone in the same time.

But expanding the source list is not the same as checking it. Every source Claude added had to be read against the specific claim it was being asked to support, because a framework is only as strong as the sources that anchor it. Generating a citation is mechanical. Reading a paper carefully enough to know what it proves, and whether the surrounding sentence reflects that, takes real time.

The Knight Capital loss figure was the clearest example. Different reports cite different numbers. The SEC enforcement order documents one figure. Bloomberg and other secondary sources round or reframe it. Claude pulled from whichever source it surfaced first on a given pass, and the number drifted across drafts. Catching that required going back to the primary source and pinning it.

The pattern repeated across other sources. Claude would attribute a claim to the right general area but the wrong specific paper. A finding about senior developer maintenance burden got mapped to a study that examined something adjacent but narrower. A claim about deskilling got pulled from a Lancet study that supports a more limited version of the argument than the way it had been phrased. Every structural source got reverified against what it actually proved. Several were corrected, replaced, or cut. Earlier drafts leaned on a real-world example whose causation was disputed in its sourcing. That example came out, and the Knight Capital section took its place because the SEC enforcement order documents the chain of causation directly.

This work could not be delegated. I had to own the mental model of what each paper actually proved and what it did not, the same way I had to own the mental model of the framework itself. The framework calls this the test of whether the engineer who built it could explain it in an incident review without looking at the code first. The writing equivalent is whether I could defend each citation in front of a skeptical reviewer without re-reading the abstract. The framework is the claim. The evidence is what makes it more than an opinion. Both had to be mine.

That covers the quadrants. Two practices cut across all of them and deserve their own treatment.

Using Claude as a critic

The most valuable thing Claude did on this post was push back. But you have to ask for it the right way.

Generic prompts produce generic critiques. “What do you think of this draft?” gets you a polite reaction with three suggestions. Useless. The prompt that actually works puts Claude in a specific adversarial seat. Mine looked roughly like this:

You are a pro-AI, token-maxing CTO watching your team and your competitors ship faster every quarter. You have a deeper than average understanding of AI. Provide a thorough critique of this article focusing on logic, completeness, and correctness. Be direct. Be brutal. This is not about the author’s feelings. It is about creating the best argument possible.

Three things make that prompt work. The persona is hostile to my thesis. The criteria are concrete: logic, completeness, correctness. And the explicit permission to be brutal lets the model drop the hedging it defaults to.

Working that way surfaced things I would have missed. Claude flagged that an early draft conflated cognitive debt as a risk problem with cognitive debt as a differentiation problem, and that collapsing them weakened both. It pointed out that one of the original real-world failure examples did not actually demonstrate the failure mode I was claiming, because the causation was disputed in the source material. It caught a passage where I was asserting a conclusion the evidence supported only in a narrower form.

Some of the pushback I accepted and rewrote around. Some I rejected, because Claude was applying a generic objection that did not fit the specific argument. (During one critique, Claude told me, “This post is sound advice. It did not need sixteen footnotes to establish it.” Fair point, but a bold claim from the model that couldn’t count to 18.) The point was not to follow every note. The point was to have the notes at all. A solo writer with a deadline does not get a skeptical reviewer on demand. Working this way, I did.

The same prompt structure works for structural critique. Swap the hostile CTO for a senior editor, keep the criteria concrete (where does the flow break, what arrives too late, what is Part 2 failing to deliver that Part 1 set up), and Claude will interrogate the architecture of the argument the same way it interrogated the content. Pulling the build-versus-buy framing forward in the final draft, and tightening the bridge between the risk and differentiation sections, came directly out of running that prompt.

This is what the research describes when it talks about AI use that preserves understanding. Interrogative, not delegated. Claude was stress-testing the argument I had already written, not writing it for me, the way a good editor or a skeptical colleague would.

Sounding like me, not like Claude

The hardest part of working with Claude on a post like this is not getting it to write. It’s getting it to stop writing like Claude. (Yes, I know. That’s the construction this section warns against. I, not Claude, wrote it on purpose.)

Models default to a recognizable voice. Em dashes everywhere. Rule-of-three lists at every cadence shift. “Not just X, it’s Y” as a reflexive contrast. Words like delve, leverage, robust, nuanced, comprehensive, pivotal. Transitions like moreover and furthermore. None of this is wrong, exactly. It is generic writing wearing a polished costume. Readers can feel it even when they cannot name it, and the moment they feel it, they stop trusting the argument.

The Redpanda voice is different. Smart, practical, playful, genuine. Short sentences mixed with long ones. Active voice. Plain English. The brand guide is explicit that we are not corporate, not academic, not polite-but-generic. If the post sounds like a polished bot, it has already failed before the argument starts.

The editing pass on voice was its own discipline, separate from the editing pass on argument or evidence. Claude would draft a paragraph that was structurally fine and full of tells. I would rewrite it. Forcing a sentence to sound like me usually meant cutting hedges, killing throat-clearing, and saying the thing directly. The corporate-academic register Claude defaults to is also the register that lets vague claims hide. Several places where the post is now sharper started as a voice fix that turned into a content fix.

A few of the patterns I usually cut survived in the final post. Two em dashes, one rule-of-three list, a “not X, but Y” construction. Each one earned its place. The em dashes carried a beat that commas would have flattened. The list of three was the cleanest way to render a specific argument without chopping it into fragments. The contrast was the only shape that made the claim land. The discipline is not avoiding the patterns absolutely. It is refusing to use them on autopilot.

The tagline was the purest version of this work. Velocity is table stakes. Code is a commodity. Understanding is the edge. That line went through more iterations than any other sentence in the post. Claude produced dozens of variants. None of them were quite right, because taste in a tagline is not a thing the model can verify for itself. The right version had to feel true to me when I read it out loud. The iteration was useful, but the judgment had to be mine.

The takeaway

The parts I delegated most heavily were the parts where being wrong was cheapest. The parts I owned most tightly were the parts where being wrong would have cost the argument or the reader’s trust. The most useful thing Claude did was push back, stress-test the structure, and force me to defend the work I was claiming as mine.

The friction we hit, the drifting Knight Capital figure, the misattributed citations, the model’s instinct to write like a model, did not mean the tool failed. It meant that without an owner holding the mental model, the output would have looked clean and been quietly broken. The framework decided where to spend that ownership. I made that call deliberately, and the post reflects it.

Everyone is adopting AI coding tools. Engineers are writing code faster than ever. But are organizations actually delivering value faster? That’s not obvious.

I wrote Enabling Microservice Success with a big focus on engineering enablement, guardrails, automated testing, active ownership, and light touch governance. I didn’t know AI coding agents were coming, but it turns out that the practices that make microservices work long-term are exactly the foundations you need to make AI coding agents work too. If your organization is adopting these tools—and the evidence suggests we all are—the book covers how to build these foundations in detail.

I’m hearing very different experiences from different organizations, and what seems to make the difference is the level of maturity that the software engineering organization has. As the latest DORA report puts it, “AI’s primary role in software development is to amplify. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.”

A decade ago, I started building microservices at the Financial Times. It didn’t take long to realize that success wasn’t about the technology choices. Success was about getting the cultural and organizational setup right, because that’s what allows teams the autonomy to move fast. There’s no benefit to adopting microservices if your organization can only release code once a week: You’re paying the cost of a more complicated operational architecture but not benefiting from being able to ship changes frequently and with a high degree of confidence they won’t break something in some other part of your system.

The pattern with AI coding agents is strikingly similar. If you don’t have automated tests, or documentation, or CI/CD pipelines that support progressive delivery, you won’t succeed with microservices—and you won’t succeed with AI coding agents either. The organizations reporting the best results are the ones that already invested in the foundations.

Here are some of the specific parallels.

Guardrails matter. When we moved to microservices, we learned quickly that you can’t just tell teams to “do the right thing” and hope for the best. You have to build paved roads and guardrails that help people to do the right thing automatically, so that autonomy doesn’t become chaos. AI coding agents need exactly the same approach. An agent with access to your codebase and no constraints is an autonomous team with no guardrails: it will move fast, but not necessarily in the right direction. If you’ve already built those guardrails for your teams—coding standards enforced in CI, architectural decision records, templates for new services—you have a serious head start because those same artifacts become the constraints that keep agents on track.

Your deployment pipeline is your best safety net. Automated tests, progressive rollouts, zero-downtime deploys—these are the practices that catch mistakes before they reach production, whether the code was written by a human or by an AI. Observability matters here too: You wouldn’t run a microservice without logs, metrics, and traces, so why would you merge code you didn’t write yourself without the ability to understand what changed and why? And independent deployability gives you independent reversibility—when an AI agent makes a bad change to one service, you can roll it back without unwinding six other things. If we’re shipping code three times as fast with the help of AI agents, all of this becomes even more important.

Engineering enablement is how you scale. Your platform team’s templates, libraries, and golden paths don’t just help developers: they become the constraints and context that make AI agents effective across your organization. The organizations that already invested in enablement are the ones finding it easiest to adopt AI coding tools. The ones that didn’t are finding that AI just amplifies the mess.

The most significant tension in this issue is between two companies making different decisions about how to handle AI with frontier security capabilities. Anthropic restricted Claude Mythos to a small corporate cohort through Project Glasswing. OpenAI released GPT-5.5 to general availability, and some are calling it “Mythos-like hacking, open to all.” The AI Security Institute’s evaluation confirms the capability is real and consequential. How will you manage risk when the time between discovery of a vulnerability and exploitation collapses to zero?

Another important theme is that, in the words of The Sequence, “AI is becoming operational.” It’s no longer about LLMs that can play games with words. It’s about tools that can automate processes across an enterprise: agents, of course, but more specifically agents that can be shared by teams to produce a consistent set of tools that can be used by groups.

AI Models

The open-weight model market is reshaping the economics of AI. This cycle brought at least 10 significant model releases or updates across open and closed providers, with pricing pressure coming from multiple directions. DeepSeek now performs within a fraction of Claude Opus 4.7 on coding benchmarks at a radically lower price; Alibaba, Google, Z.ai, and Moonshot all released capable open models this cycle. The Stanford AI Index documents this at scale. For organizations building on AI, the question is no longer whether open-weight alternatives are viable but which trade-offs they are willing to make on cost, portability, and support.

• Google has published a list of 1,302 real-world use cases for generative AI. It’s very long and probably not worth reading on your own. However, you might want to point your agent at it.
• OpenAI has announced GPT Images 2, its flagship model for generating images. The initial reaction is that it’s slightly better than Google’s Nano Banana. What distinguishes Images 2 is that it “thinks” before generating the image.
• Anthropic used Claude to work on some problems in alignment research. Claude outperformed the humans at lower cost. The problems were, admittedly, cherry-picked to be easily scoreable. But the experiment also demonstrated that a less capable model can supervise a stronger model.
• Moonshot Labs has released Kimi K2.6, the latest in its series of open models. It also open sourced the Kimi Vendor Verifier, a tool that tests the accuracy of vendors selling inference using Kimi.
• Alibaba has released Qwen3.6-35B-A3B, the latest model in its Qwen series. It’s a mixture-of-experts model with 3B active parameters. Simon Willison reports that it draws great flamingos, if you consider that relevant.
• Anthropic has released Claude Opus 4.7. The model is positioned as an intermediate step between Opus 4.6 and Claude Mythos Preview. Anthropic claims that 4.7 is better at multimodal work, including vision, instruction following, and memory use. Its new tokenizer increases the number of tokens that Claude uses. Because billing is based on tokens, that’s effectively a price increase. Simon Willison has built a tool to compare the token usage of different models.
• Google has announced Gemini 3.1 Flash TTS, a text-to-speech model that gives extraordinary control over the speakers: accents, style, expression, and more.
• Stanford’s 2026 AI Index Report is out, with over 400 pages of data and analysis about the state of AI.
• Meta’s refactored AI lab has released its first model, Muse Spark. It’s a multimodal model that has been designed for integration with Meta’s products. There will eventually be a Contemplating Mode for orchestrating agents.
• DeepSeek has released a preview version of DeepSeek-V4, its latest open-weight model. It’s a large model (over 1T parameters) with performance very close to the frontier models, but (as Simon Willison points out) running it is very inexpensive.
• OpenAI released GPT-5.5, which some are calling “Mythos-like hacking, open to all.” In addition to being its “smartest and most intuitive” model yet, OpenAI claims that it reduces token counts, thereby reducing cost. Other sources report that, while it scores highly on benchmarks, GPT-5.5 is markedly more likely to hallucinate and provide incorrect answers.
• Z.ai’s GLM-5.1 is a new version of the open source GLM-5 model that has been optimized to perform well on long-running tasks.
• Google has released Gemma 4, a new version of its family of open source models. The family includes a 31B version and a mixture-of-experts version with 26B parameters, 4B active. These are all reasoning models that are designed for agentic workflows. One model, Gemma 4 E4B, can run on the iPhone and Android.

Software Development

Anthropic has clearly been winning the announcement race. Whether it’s also winning on performance is a different question. Claude Code was a favorite among developers until its performance slipped. Many switched to newly released Cursor 3, which puts an agentic interface front and center while relegating the IDE to the background. Anthropic’s public postmortem on Claude Code’s behavior regression is worth reading both for its specific findings and as a model for how AI providers should communicate quality issues to developers. And Cursor’s transformation from an IDE into an agent is a pattern we expect to see repeated across the industry.

• OpenAI has announced “workspace agents.” Workspace agents can be shared across a team, while the agents we have so far are tied to individual productivity. They enable a team to collaborate on building shared tools to automate workflows.
• Microsoft has announced two new tools, Critique and Council, that use Claude and GPT together to solve research problems. Their benchmark results show that the combination works better than any model used on its own.
• Stash is an open source memory layer that agent builders can use to connect their agents to models. We’re beginning to see an agentic stack that is composed of interchangeable modules.
• Developers have been complaining about a drop in Claude Code’s behavior over the last few months. Anthropic has issued a response explaining what happened and how they’re fixing it.
• Glif is an agent that tries to unify all the LLMs and tools at your disposal. You don’t have to decide which model or tool is best for each task; it makes the decision for you and gets the task done.
• OpenAI has decoupled its agent harness from computing and storage, enabling durable long-running agents. The harness is now open source and can be customized through the Agents SDK.
• Anthropic has announced Claude Code routines. A routine is a package that includes a prompt, a repository, and connectors that will run automatically on Anthropic’s infrastructure, either on a schedule or when triggered.
• Anthropic also announced Claude Managed Agents, a prebuilt harness for developing agents that run on Anthropic’s infrastructure. The harness provides most of the infrastructure that an agent needs (memory management, etc.) but can be configured for the user’s tasks. Anthropic’s goal appears to be becoming the AWS of agentic AI: a service provider for tool builders.
• Interoperability between tools, models, and plug-ins is allowing a new programming stack to develop: an orchestration layer, an execution layer, and a review layer.
• Amazon has launched an agent registry service as part of AWS Bedrock AgentCore. Bedrock AgentCore is a collection of services that make it easy to build and deploy agents on AWS. The registry gives developers a way to discover third-party agents that might be useful to their work.
• Bryan Cantrill’s essay on laziness is a must-read. AI isn’t lazy, and that’s a problem. When work costs nothing, there’s no need to think about future workers. Laziness is a virtue that we need to preserve.
• Anthropic has announced Claude Design, a new tool designed to help designers. It competes directly with Figma and Canva. It’s currently in “research preview.”
• Perplexity has launched Personal Computer, a local AI agent that runs on a dedicated Mac mini (Windows to come) and has persistent access to your files, native apps, inbox, and the web.
• Anthropic has released a Claude plug-in for Microsoft Word, targeting the legal market. Automated edits appear as tracked changes.
• LiteParse is a command-line tool that extracts text from PDF files. If you’ve never needed to do that, you’ve lived a blessed life. Simon Willison has built a web-based version that runs LiteParse in the browser.
• Luke Wroblewski has said that designers should code; they need to understand their medium. But around 2014, heavyweight frameworks like React and Angular got in the way. Coding agents are now making “collapsing the gap between designing and building.”
• Cursor 3, the letest release of Cursor, relegates its IDE to the background. The main screen is designed for orchestrating agents. You can fall back to the IDE for editing code if you need to.
• In the first quarter of 2026, Apple’s app store has seen a huge (84%) increase in the number of new apps, compared to the first quarter of 2025. The cause is probably the ease of using AI to create new apps. Apple also appears to be limiting the use of “vibe coding” to create new apps, and has removed several vibe coding apps from the app store.
• Anthropic accidentally leaked the source code for Claude Code, prompting waves of commentary. Two of the most interesting are Shlok Khemani’s tour of what he found interesting in the source and Gergely Orosz’s discussion of the legal implications.
• “The Hidden Technical Debt of Agentic Engineering” argues that, as with machine learning, agents are relatively small parts of larger software systems, and that technical debt accumulates in all the supporting modules.
• Chat is rarely the best interface for working with AI. Ethan Mollick writes that the current generation of AI models and agents are capable of creating task-specific interfaces on the fly.

Security

Security has spent a lot of time in the news. Two core tools for secure private networking, Tor and Signal, have been attacked. In both cases, the attack didn’t involve the software or protocols themselves. These attacks teach us that secure systems are often jeopardized by the software that surrounds them. We’ve also seen that ransomware gangs are using postquantum encryption, and that quantum computers are likely to break traditional encryption sooner than expected. If you’re not investing in security, it’s time to start.

• The Tor network is the gold standard for secure private networking. Researchers recently discovered a vulnerability in Firefox browsers that lets attackers de-anonymize identities. The vulnerability has been fixed in Firefox 150, but it’s a reminder that anything can be attacked.
• We all know that ransomware gangs use encryption. The Kyber group is making the transition to postquantum encryption.
• A supply chain attack against npm allows bad actors to steal developers’ credentials. Once it has infected a victim, it inserts itself into other packages that the victim publishes.
• Law enforcement agencies were briefly able to exploit a vulnerability in iOS notifications that allowed them to access unencrypted messages sent with the Signal secure messaging system. The vulnerability has been patched. It’s important to understand that the vulnerability wasn’t in Signal itself but in the environment in which it operated.
• With AI, time from discovery of a vulnerability to exploitation has dropped to zero. To help defense catch up, Google has added three agents to its Google Security Operations platform: Threat Hunting, Detection Engineering, and Third Party Context.
• Microsoft reports that criminals are increasingly using Teams to impersonate help desk personnel, who ask users for their credentials and then steal data.
• NIST has stopped assigning severity scores to lower-priority vulnerabilities. All vulnerabilities will still be added to the National Vulnerability Database (NVD).
• The NSA is using Claude Mythos Preview, despite Anthropic being blacklisted by the Pentagon. Anyone want to guess what they’re using it for?
• Anthropic will ask for identity verification in some cases.
• Small open-weight models can do as well as Anthropic’s Mythos at finding vulnerabilities. The key isn’t the model; it’s the system within which the model works.
• A new malware campaign embeds credit-card stealing software into a single pixel SVG image. ecommerce sites using Magento Open Source or Adobe Commerce are vulnerable.
• Anthropic has pulled its newest model, Claude Mythos, from broader release because it’s too good at finding vulnerabilities in other software. They’ve made it available to a few corporations via Project Glasswing, an attempt to secure critical software before it can be exploited. The AI Security Institute’s analysis of Claude Mythos Preview says that it “represents a step up over previous frontier models in a landscape where cyber performance was already rapidly improving.”
• Many open source security maintainers agree with Greg Kroah-Hartmann‘s report that the quality of AI-generated security bug reports has gone up tremendously.
• Versions of Claude Code that include the Vidar malware have been published on GitHub. They are based on the code that Anthropic inadvertently leaked. These versions entice victims to download them by claiming to have unlocked enterprise features.
• Claude has been used to discover zero-day remote code execution vulnerabilities in both Vim and Emacs. The vulnerabilities are triggered when a user opens a file. An update is available for Vim; Emacs developers argue that it’s really a bug in Git, which may be correct but misses the point.
• Breakthroughs in quantum computing mean that computers capable of cracking current encryption algorithms may be on the horizon.

Infrastructure and Operations

Multiple providers released overlapping pieces of an agent stack this cycle, covering orchestration, persistence, memory, and registry services. A three-layer model (orchestration, execution, review) is becoming the standard architecture, but each vendor’s implementation makes different bets about portability and durability. It’s important to evaluate each vendor’s products carefully before settling on an agent stack.

• Microsoft now allows admins to uninstall Copilot, though there are conditions.
• Google has announced two new eighth-generation TPUs. One is designed for training (8t), the other specializes in inference (8i). This is the first time Google has produced specialized TPUs for training and inference.
• Google has open-sourced Scion, its testbed for agent orchestration.
• Anthropic has agreed to buy 3.5 gigawatts of computing power from Google and Broadcom, maker of Google’s GPUs. The deal specifies power consumption rather than the number of chips, implying that the limiting factor isn’t computation but the availability of power. Chips come and go; watts are a constant.
• Ollama now uses Apple’s MLX framework to improve performance on Apple silicon. Support is currently limited to the Qwen3.5-35B-A3B; support will be added for other models. As part of this update, it also uses NVIDIA’s NVFP4 floating point format for model quantization.

Web

Don’t overlook the web layer when planning for AI-driven disruption. The web’s infrastructure is older than most of the people who maintain it, and several items this cycle are reminders of the gap between what that infrastructure was designed for and how it is used today. Two deal with protocols that have outlasted their original assumptions; another reimagines the dominant CMS from scratch using current tooling.

• Is PHP the new COBOL? What about open source itself? “Who Will Maintain the Web When PHP’s Veterans Retire?” points to a reality that we don’t like to think about. Not only are companies reluctant to hire junior developers; the ones they do hire aren’t learning older technologies.
• Laravel is apparently injecting ads for its commercial cloud service into agents. What happens when an open source framework receives venture funding and starts injecting ads into agents? We’re about to find out.
• Doesn’t every musician need tools to typeset Gregorian chant?
• Is IPv8 the future of the Internet? IPv6 has been “two years away” since early in the 1990s. IPv8 is fully backward compatible with IPv4, and resolves its security and address depletion issues.
• Cloudflare has released EmDash, an alternative to WordPress based on how the web is used today. Drew Breunig calls this a reimagining: a new phase of software development in which we can use agentic programming to rethink and reimplement tools based on current needs.
• Is BGP Safe Yet? is a web app that tests whether your ISP has implemented BGP (the protocol that’s responsible for routing packets at internet scale) correctly. Many haven’t.

Biology

• OpenAI has announced GPT-Rosalind, a model that has been tuned for 50 common workflows in biology. Unlike most models, Rosalind has been tuned to be skeptical rather than enthusiastic or sycophantic. Access to Rosalind is limited because of the potential for harm.

Robotics

• Spot, the Boston Robotics robotic dog, can now read gauges and thermometers. It uses the Gemini Robotics-ER 1.6 model, which can reason about visual information.
• Major League Baseball is using a robotic system to rule on challenges to a human umpire’s ball/strike calls.

Every day, millions of pieces of fake content are produced. Videos, audio clips, posts, articles, generated by artificial intelligence, distributed at industrial scale, aimed at shifting public opinion across entire countries. The people producing them are often outside the country being targeted. The people receiving them almost never know they’re fake. And they have no idea how they’re made.

A few years ago, troll farms worked like this: entire buildings full of people, shifts, desks and workers paid to write posts, create fake profiles, comment and pick fights in online discussions. It was expensive, slow, and in the end, the real impact was marginal. Those buildings still exist today, mostly in India, split between teams specializing in scams and teams dedicated to disinformation. They work on commission and they’re mostly AI experts now. They no longer write the articles themselves and no longer do graphic design or photo editing. They have AI agents do everything: agents they create, configure, instruct, and supervise. Hundreds of thousands of autonomous agents that do in one hour what used to take weeks of human labor. Troll farms have become AI farms, producing synthetic content at industrial scale.

The report “From Trolls to Generative AI: Russia’s Disinformation Evolution,” published in February of 2026 by the Centre for International Governance Innovation (CIGI), tells one of these stories, specifically about disinformation campaigns originating from Russia. Networks like CopyCop, a disinformation operation linked to the GRU (Russian military intelligence), use uncensored open-source language models like modified versions of Llama 3, installed on their own servers, to transform press articles into political propaganda and distribute it across hundreds of fake websites without leaving a trace. Because the models run locally, there’s no watermark and no log. The model runs on their hardware, inside their borders, outside any Western jurisdiction.

The paper “How malicious AI swarms can threaten democracy,” published in Science in January 2026 describes well what is coming: coordinated swarms of AI agents with persistent identities, memory, and the ability to adapt in real time to people’s reactions. The authors call them “malicious AI swarms.” Fully autonomous agents, each producing original content, each one different, each one adapted to context.

They can simulate real communities that appear credible, and they build what we can call synthetic consensus: the illusion that an opinion is widely shared, that a position is held by the majority, when in reality it’s a single operator speaking through thousands of masks.

It works because we humans have bugs too, and the swarms exploit them at a scale that was never possible before or that would have required enormous human resources.

One bug is called the bandwagon effect. Combined with another bug, illusory truth: repetition plus apparent source independence equals perceived truth. So if we see the same position expressed by different sources, in different contexts, with different words, on different platforms, we register it as widespread. And if we perceive it as widespread, we consider it more credible. And if we consider it credible, we tend to align with it.

Swarms of autonomous agents exploit both mechanisms at the same time, at industrial scale.

What most people still haven’t grasped is the scale. We were used to automation: A system that sent a hundred thousand identical emails, at most changing the name and little else, or made just as many posts and similar comments with minor variations. It automated the publishing, but at its core it was recognizable spam. Our mental model is still that one: If it’s automated, it’s generic. If it’s generic, you can spot it. But that’s a perception error built on years of experience when AI agents didn’t exist. That model is over. These agents no longer fit the concept of automation, because they make decisions, they radically change the text based on the recipient. They aggregate data from heterogeneous sources in real time: social profiles, public records, leaked databases that you can now buy for a few dollars on any dark web marketplace. Billions of personal records are already out there, scattered across hundreds of breaches accumulated over the years, and AI can cross-reference them, reconcile them, and build a coherent profile of a single person in seconds. The computational cost is negligible: a few cents in tokens to generate a perfectly personalized message. Consider that a single agent with access to a language model and a couple of leak databases can produce thousands of unique pieces of content per day, each calibrated for a different person. Multiply that by a hundred thousand agents working in parallel, twenty-four hours a day, and you have the scale of what’s happening.

Another legacy from the past: “I’m just an ordinary person, why would anyone bother creating content specifically to convince me?” That may have been once true. Today, nobody is losing time because these agents don’t get tired, don’t sleep, and do nothing else: find connections, aggregate data, produce false content calibrated for each of us. The old demographic profiling is over. This is surgical media targeting at industrial scale.

But the capacity to respond and deny is not at industrial scale. If hundreds of thousands of coordinated agents spread a video of a politician saying something they never said, that politician can deny it all they want. The video is there. Millions of people have seen it. The denial arrives later, arrives slower, and will never reach the same scale. It arrives in a world where nobody knows what’s true anymore.

If the same swarms spread the news that a head of state has died, and the news is false, that head of state can make all the videos they want to prove they’re alive. Those videos will probably be dismissed as deepfakes. Because the swarm’s narrative got there first, took root, and at that point any evidence to the contrary looks fabricated.

Whoever controls the swarms today controls the version of the facts. Whoever tries to push back is already at a disadvantage because they have to prove that a real video is real in a world where everyone has learned that videos can be fake.

The attackers are often outside the country being hit. Groups aligned with governments that want to shift public opinion in another country, or that target specific demographics. Young people, for example, using platforms that are often owned by those very countries.

All of this is a massive threat to democracy because democracy operates on some premises, including that people form opinions based on real information, discuss with each other, and then decide. If the information is fabricated, if the debate is populated by entities that don’t exist, if the consensus we perceive is synthetic, that premise collapses. And with it, the entire mechanism. Elections become the result of who has the best swarms, not who has the best ideas. Public debate becomes a performance where most of the voices are generated, and public opinion stops being public and becomes the product of whoever has the resources to manufacture it.

We grew up thinking that threats to democracy came from coups, censorship, or regime propaganda broadcast on television or in national newspapers. Those were real threats, but they were at least visible. They were things you could identify and fight. Now the threat is bigger and, above all, invisible, personalized, and it operates inside the very channels we use to inform ourselves, to discuss, to participate. It contaminates information from within, to the point where nobody knows which voices are real and which are machines.

What can we do? Watermarking? Pattern detection? Unfortunately, they don’t work. The major AI platforms can embed markers in content generated by their models, true. But the people building autonomous swarms don’t use commercial platforms. They use open-source models with fine-tuning and capabilities that can’t be controlled from outside. And they often have no legal obligation to do anything because there are no global laws that can impose watermarking on every computer in the world. The result is paradoxical: The content produced by those who follow the rules stays marked, and the content produced by those who want to cause harm stays free.

Pattern detection systems have the same limits. They work for a while, then once the detection patterns are identified, the swarms adapt. They’re designed to do exactly that.

And the platforms where all of this circulates have a financial incentive to turn a blind eye. Internal Meta documents made public by Reuters in November 2025 estimated that roughly 10% of Meta’s global 2024 revenue, about $16 billion, came from advertising for scams and prohibited products. Fifteen billion high-risk ads served on average every day to users. The maximum revenue Meta was willing to sacrifice to act against suspicious advertisers was 0.15% of total revenue: $135 million out of $90 billion. When a platform’s business model depends on ad volume, removing the fraudulent ones has a cost that nobody wants to pay. I suspect Meta is not alone in this.

Regulation doesn’t solve this problem either. I’ve worked on the European AI framework, the GPAI task force, the Italian AI law, and I’ve brought my perspective to the UK Parliament. I’ve been in those rooms. Europe has the AI Act, the GPAI Code of Practice is currently being drafted, and has a regulatory apparatus that is more advanced than any other bloc in the world. The United States has no federal regulation, and twenty-eight states have tried to legislate with transparency requirements that amount to fine print. But even the most ambitious European framework has a structural limit: The attacks come from countries that answer to none of these rules. You can regulate your platforms, your developers, your companies. You can’t regulate a building in Saint Petersburg, Shenzhen, or New Delhi, where someone is instructing swarms of agents on open-source models running on local servers, outside any jurisdiction.

One way out is to return to the reputation of sources. Editors, news organizations, journalists with a name and a face. People and organizations that have a professional track record to defend and that risk something when they get it wrong. Sure, they can have political leanings and they can make mistakes. But they have a constraint that no AI agent will ever have: public accountability. A system that generates millions of pieces of false content answers to no one. An editor answers to their audience, to the law, to their reputation. That constraint is the only filter that still holds, and protecting it is the only thing we can do right now, while the laws try to catch up with a technology that moves faster than any legislative process in the world.

Are we completely at the mercy of AI swarms or can we fight back?

Machines should not get to overpower humans, especially when what’s at stake is how we govern ourselves. The antibodies exist. We need to activate them.

The more people understand how swarms work, the less effective they become. A swarm that manufactures fake consensus only works if the people receiving it don’t know synthetic consensus exists. A bit like deepfakes. We know about them now and we often spot them. Once you see how it works, it’s harder to fall for it.

Then we need investment in culture. In spreading digital literacy, which is not learning how to use a computer, but learning to understand the social and cultural effects of the digital world. It means teaching in schools how to verify a source and what the signs of manipulated content are. It means stopping the practice of treating media literacy as a school project and starting to treat it as democratic infrastructure, on the same level as bridges and hospitals. It means funding independent journalism instead of letting it die, strangled by the same mechanisms that reward false content because it generates more engagement. It means demanding that platforms give different visibility to those who have a verifiable reputation versus those who have none.

Because awareness is the only antibody that scales at the same speed as the threat. And unlike regulation or detection systems, awareness doesn’t need to be imposed. It can be built, taught, shared, and spread from person to person.

Before sharing a piece of content, check where it comes from. Before reacting to a video or a statement, stop. Ask yourself whether the source has a name, a history, something to lose. Treat every piece of content as potentially synthetic until a credible, accountable source confirms it. These are habits, not technologies. They cost nothing and they work immediately.

Finally, we need the help and collaboration of the tech community. Those who design platforms, write code, and make decisions about how feeds and ranking algorithms work are making choices that directly shape the information ecosystem. These are choices with democratic consequences. The people making them know it. Many have known it for years. This is the moment to stop treating it as someone else’s problem and to decide which side you’re on. Because the swarms are not waiting.

We can do this. The tools exist, the knowledge is there, and the threat is clear enough that pretending not to see it is already a choice. The question is whether we act now, while the window is still open, or later, when the damage will be harder to reverse.

The release of Gemma 4 has added energy to the discussion of local models and their importance. Models that you can download and run on hardware you own are becoming competitive with the “frontier models” hosted by large AI providers. These models have gotten good enough for production use, good enough for tasks that until recently required an API call to a frontier model. They are typically open weight (though not open source) and much smaller than the frontier models like Anthropic’s Claude.

The reasons for going local vary. For a financial services company, regulation may require that no sensitive data can leave the premises. For a developer in Europe, data sovereignty laws make cloud APIs awkward. For a developer in China, hardware constraints and geopolitics have made local, efficient models a practical necessity. For developers outside the US, the costs of using frontier models can be prohibitive. None of these reasons are new, but all of them are more urgent than they were a year ago, because the models are catching up.

Why local?

Reasons for running AI locally fall into a few categories: cost, privacy, performance, and control. Let me take them in order.

Cost is the easiest to quantify, though the numbers can be misleading. Developers using agentic tools for programming can spend $500 to $1,000 per month or more on API calls. NVIDIA CEO Jensen Huang has suggested that his engineers should spend an amount roughly equal to half their salary on AI tokens, given the productivity return. Whether or not you take that as prescriptive advice, it signals that token spending at scale is significant, which is exactly what makes the local alternative worth examining.

The hardware cost depends on where you’re starting. If you have a capable desktop already, dropping in an RTX 4070 ($500–$800 retail) gets you a 12GB-VRAM GPU adequate for most local models. Building a dedicated system from scratch (CPU, motherboard, 32GB of RAM, storage, case, power supply, and GPU) runs closer to $1,500. Teams spending $500 a month on API calls break even in a few months. After that, local costs approach zero; electricity for a consumer GPU setup runs $20 to $40 a month. High-volume batch work makes the economics even clearer. Processing thousands of documents through a cloud API gets expensive fast; locally, it costs nothing but time.

For individual developers and small teams, the management overhead is minimal. A tool like Ollama reduces running a local model to a background service; updating to a newer model is a single command, done on your own schedule. At enterprise scale the picture changes: Organizations that need production uptime guarantees, multiple developers sharing access, compliance logging, and dedicated engineering support face real overhead. A dedicated ML engineer runs $200,000 a year, and that’s noise compared to the cost of building or leasing AI infrastructure. For a solo developer or a two-person shop, that concern doesn’t apply.

Privacy arguments are often more compelling than cost. The concern isn’t primarily about bad actors at cloud providers; it’s about contracts, compliance, and control. GDPR and similar regulations create real constraints on where data can go. Healthcare and financial services companies have legal obligations that may effectively prohibit sending sensitive data to external APIs regardless of the provider’s security guarantees. Running a model locally means data stays on your hardware, under your control, with no possibility of inadvertent leakage to a third party. DockYard, writing about the business case for local AI, puts it simply: Local models “keep sensitive data on-device, reducing exposure to breaches and unauthorized access” and simplify compliance with regulations that require strict data residency.

The world beyond the US

The strongest momentum behind local AI adoption comes from developers and organizations outside the United States. The reasons vary by region, but they’re structural everywhere.

European regulators have been skeptical of US-based cloud services since before the first Schrems ruling invalidated the Safe Harbor framework in 2015. The concern that US intelligence services can access data held by US companies, regardless of where that data is stored, has never been fully resolved, and recent US policy directions have amplified European anxieties. More countries, including China and many other Asian nations, are also developing their own data sovereignty laws. Locally run models sidestep the problem.

China has become a leading provider of open AI models. DeepSeek’s appearance as a major open-weight model family wasn’t an accident; it reflects a systematic investment in AI that emphasizes efficiency and openness over raw scale. As I’ve written elsewhere, the Chinese approach to AI has been shaped in part by hardware constraints: When you can’t easily acquire NVIDIA’s fastest chips, you optimize your software instead. You use quantization. You build mixture-of-experts architectures that activate only a fraction of parameters per token. You design models that run well on the hardware you can actually get. The result is a generation of models that run efficiently on local hardware, and a developer community with expertise in building those models. While those techniques have been taken up by AI companies in the US, China clearly leads in efficient AI.

For application developers in India, Southeast Asia, Latin America, and Africa, cost is the most immediate barrier. Cloud API pricing denominated in dollars is expensive relative to local income levels in ways that matter for product economics, not just personal preference. Language is a deeper issue. Of the world’s 7,000-plus languages, only a few have enough textual data to train capable models, and both frontier and smaller open-weight models reflect that reality. A survey of African languages found pronounced performance gaps across models of all sizes. What open-weight models offer is the ability to fine-tune on local language data that the original training missed. A developer in Uganda building a health information tool, or a team in Malaysia building a customer service product, can take an open-weight base model and adapt it to the languages their users actually speak. That’s not possible with closed models.

The response has been a wave of regional model development. Sarvam in India has open-sourced models trained on data emphasizing all 22 official Indian languages, released under Apache 2.0. Sunbird AI in Uganda built Sunflower, a family of models covering 31 Ugandan languages, that was developed in partnership with Makerere University and trained on digitized radio broadcasts and community texts. Singapore’s AI research group built SEA-LION, tuned specifically for Southeast Asian languages and cultural contexts. Malaysia launched a domestically developed LLM, ILMU, in August 2025.

Chinese open source models help to fill this gap. According to Hugging Face’s data, Chinese models now account for a larger share of downloads on the platform than US models. Sunflower is built on Qwen; Malaysia’s NurAI, which targets 340 million speakers of Bahasa Melayu and related languages across the region, uses DeepSeek as its foundation. This isn’t ideology; it’s that Chinese open source models are efficient enough to run locally, permissively licensed, and increasingly well-suited to the multilingual fine-tuning these applications require.

OpenRouter’s model usage rankings, which track billions of API calls across many models, reflect the same reality. DeepSeek models and Qwen variants from Alibaba appear at the top of usage charts alongside offerings from OpenAI and Anthropic. (OpenRouter notes that raw token counts can be skewed by a few high-volume users; request counts give a more representative picture. Also note that rankings vary sharply day-to-day and week-to-week.) The frontier of capable AI is no longer exclusively American, and the application developers driving much of that usage are building for audiences that American tech companies have largely ignored.

Performance

When performance is an issue, the metric to watch depends on what you’re building. Time to first token matters most for interactive applications: how long before the model starts producing output. For a cloud API, that includes the network round trip (typically under 30 milliseconds to a major provider) plus server-side work: queuing, scheduling, and processing your prompt through the model before generation begins. For typical requests this can run to several hundred milliseconds in total, and longer when the server is under load. A local model starts processing immediately, with no queuing and no network hop, so time to first token is very low. For anything that feels like a conversation (a code assistant, a document tool, an interactive agent), that difference is perceptible.

Once generation starts, tokens per second is the metric to watch. Here, cloud providers have the advantage: Their infrastructure prioritizes inference, generating responses to prompts and API calls. A local model may feel faster to start and slower to finish than a well-provisioned cloud API.

For agentic workflows that chain together many model calls, both factors matter. Network round trips accumulate: At 30 milliseconds each, a hundred sequential calls adds three seconds of pure overhead before accounting for server-side processing, and the time-to-first-token overhead multiplies with every step. This is one reason local models have appeal for agentic applications, where the number of individual inference calls can be large.

High concurrency is a separate problem, and one where local deployment struggles. Consumer hardware handles one request at a time, or a few; a cloud provider scales horizontally. If your application serves many simultaneous users, local deployment requires either significant hardware investment or a different architecture.

Fine-tuning for specific applications

Applications where specialized domain knowledge matters are more common than people realize, and for all of them fine-tuning is a substantial advantage. A customer support model that knows your product deeply, a coding assistant tuned on your company’s codebase, a document processor fine-tuned on your industry’s vocabulary: These are things you can build and own with open models in ways you can’t with closed ones.

Developers are frequently prototyping an application on a frontier model, then moving to a smaller or local model that has been fine-tuned for production. An early description of this practice appears in “What We Learned from a Year of Building with LLMs”: “Prototype with the most highly capable models before trying to squeeze performance out of weaker models.” The practice is also recommended by both Anthropic and OpenAI, though they assume you will use their own smaller models, and they might get prickly around what they see as “distillation.”

Fine-tuning models is frequently associated with expensive AI experts, but it is gradually becoming more accessible. Techniques like QLoRA allow fine-tuning a 7B or 8B parameter model on a consumer GPU with 12GB of VRAM. Tools like Unsloth reduce VRAM requirements further while increasing throughput. The Hugging Face ecosystem (Transformers, Datasets, PEFT, TRL) provides additional tools for working with models. An individual developer or small team can adapt a base model to a specialized domain.

Cloud providers can’t easily offer this flexibility. You can fine-tune some closed models, but you’re working within the provider’s constraints at significant per-run cost, and the resulting model still lives on their hardware. Fine-tuning an open model produces something you own, that runs on your hardware, with no ongoing licensing fees and no dependency on a third party’s infrastructure decisions.

Security

The biggest advantage of a local model is that data stays local. There are no API endpoints to compromise, no cloud credentials to steal, no third-party infrastructure to go down during an outage. For regulated industries, this is often a decisive factor.

However, when you run a model on your own infrastructure, you take responsibility for the model’s security. Model creators make their own choices about safety and alignment before releasing a model. Base models (the foundation before instruction tuning and alignment) will comply with requests that a safety-tuned model would refuse; that’s a property of the model, not something you configure at runtime. When you choose a model to run locally you’re also choosing how much alignment work its creators did. Organizations need to evaluate this deliberately rather than assuming it’s handled.

The opacity of training data is a subtler concern. Because almost all open-weight models withhold their training datasets, you can’t audit the data on which the model was trained, making it hard to assess bias, verify that proprietary or regulated data wasn’t included, or detect benchmark contamination. For applications in regulated industries, this is a real gap.

Prompt injection is a threat that applies to any model. In a prompt injection attack, adversarial content in the model’s input overrides the system prompt and hijacks the model’s behavior. The malicious content can be in almost any form: text on a web page, invisible pixels in an image, and much more. The attack surface grows in agentic workflows, where models take actions based on content they retrieve from the web and other external sources. Frontier labs have made progress here: Anthropic has published research on RL-based injection hardening for agentic contexts, and OpenAI published the Instruction Hierarchy, a training methodology that teaches models to assign differential trust to instruction sources. Neither technique has a known open-weight equivalent. That said, both labs have stated publicly that the problem is unlikely to be fully solved. The root cause is architectural: LLMs process instructions and data in the same token stream, and that’s not a bug that can be patched out.

Supply chain security is yet another concern. Hugging Face hosts hundreds of thousands of models, and most have not been audited for safety. Some are actively hostile. Downloading a model from an unknown source and running it on your hardware is analogous to running an arbitrary executable. Sticking with well-known models such as Gemma from Google, GLM from Zhipu, and DeepSeek from DeepSeek AI reduces this risk substantially. The well-known models aren’t risk-free, but they’re in a different category from the long tail of unvetted uploads.

The current open model landscape

Before getting into specific models, it’s important to distinguish between “open source” and “open weight.” They are not the same, and most of what gets called open source AI is actually only open weight. The Open Source Initiative published a formal definition of open source AI in October 2024, requiring not just open model weights but training code, training data provenance, and evaluation code—enough for a skilled person to reproduce the system.

By that standard, almost none of the headline models qualify. Most models only release the weights: the trained numerical parameters that make up the model itself, without the data or code that produced them. Without training data, you can fine-tune a model, but you can’t audit the model for bias or benchmark contamination. Without training code, you can’t reproduce or systematically improve it. The term “openwashing” has started circulating for models that claim openness while releasing only weights, and it’s warranted. For most developers, the practical question is what the license actually permits. Apache 2.0 and MIT licenses, which several of the major open-weight models now carry, are permissive enough for most commercial use.

As of early April 2026, Gemma 4 from Google is the strongest open-weight model available. Like all the models here it releases weights only; training data and code are not disclosed. It comes in several sizes: compact 2B and 4B variants aimed at edge deployment, a 26B mixture-of-experts model that activates 4B parameters per token, and a 31B dense model suited for reasoning and fine-tuning. All variants handle images and video natively. For most developers looking for a locally runnable model right now, Gemma 4 is where to start.

The GLM series from Zhipu is underrated. The current release is GLM-5.1, with GLM-5 still widely used; both have large context windows and strong performance on reasoning tasks. The series has a particular focus on deep tool-assisted research workflows. This goes beyond what raw benchmark scores capture. For applications that involve sustained, complex work, such as legal document analysis, research synthesis, and multistage coding tasks, the GLM family is worth serious consideration.

DeepSeek’s V4 models are large, but they use a mixture-of-experts architecture to deliver high quality with a small active parameter count. DeepSeek’s R1 family ranges from 1.5B parameters to 671B. It has been specialized for reasoning and mathematical tasks. Training data and code have not been released for either V4 or R1. The community has launched an Open-R1 project that attempts a full reproduction of DeepSeek-R1’s training from scratch.

The Qwen series from Alibaba is capable across a range of tasks, multilingual, and licensed under Apache 2.0. Organizational changes have put its trajectory in question, though the open-weight releases of Qwen3.6-27B and other models in the Qwen 3.6 family are encouraging.

Kimi K2.6 from Moonshot AI is worth knowing about, although running it is beyond the capabilities of most consumer hardware. It’s a one-trillion-parameter mixture-of-experts model with 32B active parameters per token, trained specifically for coding and agentic tasks. Aggressive quantization can bring Kimi’s VRAM requirements down to 24GB, but that’s the practical floor.

Meta’s Muse Spark isn’t open but deserves a mention. Announced in early April 2026 and built by the newly formed Meta Superintelligence Labs under Alexandr Wang, Muse Spark is proprietary. Meta has a history of releasing open-weight models, so it’s possible something similar will follow for Muse Spark, but there’s no announcement, no timeline, and no guarantee. There has also been talk of smaller versions of Spark for edge devices.

If you want models that are genuinely open source by the OSI definition—training data, code, and weights all released—the options are more limited and less capable: Olmo from the Allen Institute for AI is the most serious effort; the full Dolma training dataset, training code, and hundreds of intermediate checkpoints have been released. It’s a valuable resource for researchers, but it isn’t competitive with Gemma 4 or DeepSeek on capability.

Regardless of which model you’re considering, how do you know whether it’s good enough for your application? Published benchmarks are often misleading; they measure what the benchmark designers thought to measure, not necessarily what you need. A more reliable approach is building a “golden dataset”: a few hundred real prompts drawn from your actual use case, with known-good answers, against which you can evaluate any candidate model. It’s worth doing before committing to any model for production use.

Choice and control

The gap between frontier and open models is narrowing and, more to the point, seems less and less relevant as open models improve. Is it worth getting locked in to a cloud provider, giving up control of your data provenance, and losing the ability to fine-tune a model for an application in exchange for a few points on a benchmark that doesn’t reflect the real world? An increasing number of AI developers and users are concluding that it doesn’t. The regulatory environment in Europe, and the hardware constraints in China, are producing a global developer community with expertise in making local AI work.

None of this means that cloud AI is going away. The frontier closed models will remain ahead on raw capability, and there are applications where that matters. But the days when a US-based cloud API was the only serious option for capable AI are over. Local AI is increasingly capable, and for a growing fraction of what developers want to build, especially outside the United States, it’s a viable choice.

If you want an introduction to using LLMs with open weights, join Christian Winkler on O’Reilly for the Open Weight Large Language Models Bootcamp on May 20 and 21. You’ll learn how to use models to retrieve information, combine the results of different models and refine the results with dense passage retrieval, discover how these models can excel on less powerful hardware by using new approaches to quantization, explore different frontends these models can be plugged into, and more in an interactive hands-on environment. O’Reilly members can register here.

Not a member? Sign up for a free 10-day trial before the course to attend.