I’ve been there. As someone who runs AI agents in my daily workflow, I trust these tools with real work. But here’s the thing: trust requires transparency. And last week, Anthropic gave us more transparency than they intended when the Claude Code source code leak exposed their entire codebase to the world.

On March 31st, 2026, security researcher Chaofan Shou discovered something unusual in Claude Code v2.1.88. Anthropic had accidentally shipped a 59.8 MB source map file (cli.js.map) containing the full readable TypeScript source code. We’re talking about 512,000 lines across 1,900 files. The entire application, right there in the npm package.

Think about it this way: it’s like publishing a book and accidentally including all your drafts, deleted scenes, editorial notes, and future plot twists in the appendix.

Anthropic pulled it within hours. But you know how the internet works, right? The original tweet exposing the leak hit 28.8 million views. GitHub mirrors exploded. One repo hit 84,000 stars and 82,000 forks before Anthropic started filing DMCA takedowns. Bloomberg reported Anthropic scrambling to remove thousands of copies via copyright claims. Developers even rewrote the code in other languages to sidestep copyright restrictions.

The code is out there now. Permanently.

And this wasn’t even their first leak of the week. Days earlier, their model specification had leaked. A draft blog post about an unreleased model (Mythos/Capybara) also went public. Three major leaks in one week. That’s not a stumble. That’s a pattern.

Anthropic called it a “release packaging issue caused by human error, not a security breach.” Technically true. But when your entire product roadmap becomes public knowledge, does the distinction really matter?

What I Found In The Code (And Why You Should Care)

I’ve spent the last few days digging through what was revealed. Not the leaked code itself, but the extensive analysis from developers who tore through it. What I found was fascinating. Equal parts exciting and concerning.

Let me walk you through what matters.

The Models We’re About To Get

The code reveals internal codenames for upcoming Claude models. This isn’t speculation anymore. It’s right there in the codebase.

Opus 4.7 is the next generation Opus. Sonnet 4.8 is coming after the current Sonnet. But here’s where it gets interesting: there’s a model codenamed Capybara, also called Mythos internally. Based on the code structure, this thing is bigger than Opus. Anthropic clearly has big plans for this one.

They’re also testing Fennec (which maps to Opus 4.6) and Numbat (still in testing phase).

Does this sound familiar? Every AI company has a model roadmap. But now Anthropic’s competitors know exactly what’s coming and when. That’s a strategic disadvantage.

KAIROS: The Proactive Agent That Actually Thinks Ahead

Here’s what most people miss about current AI coding assistants. They’re reactive. You ask, they respond. You tell them what to do, they do it. End of story.

KAIROS changes that completely. It’s referenced over 150 times in the source code, making it one of the most deeply integrated upcoming features.

It’s a persistent, always-running Claude assistant that proactively acts on things it notices. Not just doing what you ask, but autonomously identifying and completing tasks.

The example in the code? You say “build me a to-do list app.” A normal assistant builds you a to-do list app. KAIROS looks at that and thinks: “You know what would make this better? Calendar integration. Project management features. Sharing capabilities.” And it just adds them. Without being asked.

Let that sink in.

This is the difference between a tool and a partner. I’ve been waiting for something like this. An agent that doesn’t just follow instructions but understands intent and fills in the gaps.

Dream Mode: Your AI Literally Dreams About Your Code

This one blew my mind.

autoDream is overnight memory consolidation and idea generation. While you sleep, your agent “dreams.” It processes what you built during the day. It generates ideas for what to build next. It consolidates memory.

The implementation is sophisticated. Three-gate trigger system: – Time gate: 24 hours since last dream – Sessions gate: 5+ sessions since last dream
– Lock gate: prevents concurrent dreams (only one agent dreams at a time)

But it goes deeper than just overnight processing. The code reveals GitHub webhook subscriptions so Dream Mode can react to repo events, plus a 5-minute cron refresh cycle for continuous background reasoning while you’re idle. This isn’t just “thinking while you sleep.” It’s a persistent background reasoning engine.

The safety model is clever too. During dreams, the agent can only write to memory files. It cannot modify source code. So it’s not going to refactor your entire codebase while you’re asleep and break everything.

Think about it this way: you work on a project all day, close your laptop, go to bed. When you wake up, your agent has already thought through the next steps. It’s documented edge cases you missed. It’s identified patterns you should extract into utilities.

That’s powerful.

Auto Mode: Smart Permissions That Actually Make Sense

Anyone who’s used AI coding tools knows the permission problem.

You can run in YOLO mode where the agent does whatever it wants. Fast but terrifying. Or you can approve every single action manually. Safe but exhausting.

Auto Mode is the intelligent middle ground. The agent uses machine learning to evaluate each potential action. Is this safe enough to auto-approve? Or risky enough to ask the user?

It’s permission management that learns your risk tolerance over time.

I’ve wanted this for months. The constant approve/deny cycle breaks flow state. But giving carte blanche to an AI agent that can delete files? Not happening.

Auto Mode solves it.

Buddy Mode: Yes, Really, A Tamagotchi For Your AI Tool

I wasn’t sure how to feel about this one at first.

Buddy Mode is a full companion pet system. We’re talking 18+ species, rarity tiers, shiny variants, procedurally generated stats. The buddy walks around your desktop. It changes based on your work. It has its own personality.

Planned rollout: April 1-7, 2026. (I’m writing this on April 1st. The timing is… interesting.)

My first reaction? This is ridiculous. My second reaction? This is brilliant.

Here’s why: emotional connection drives tool adoption. People who feel attached to their tools use them more consistently. Tamagotchis worked in the 90s because they created emotional bonds. This is the same psychology applied to professional software.

Will I use it? Probably not. Will it increase Claude Code adoption among developers who grew up with virtual pets? Absolutely.

X42 Protocol: When Your AI Agent Has Its Own Wallet

This is the one that made me pause.

X42 Protocol is a crypto-based system that allows AI agents to make autonomous purchases using stablecoins (USDC). Your agent can buy hosting. It can purchase templates. It can pay for services. Without you.

The vision: “Hey Claude Code, here’s $100, build this app.” And it goes shopping. Buys what it needs. Completes the project.

The good news is this solves real friction. The bad news is this introduces entirely new categories of risk.

What happens when your agent decides it needs $500 worth of cloud resources? What’s the spending limit? Who’s liable if it makes bad purchasing decisions? What about fraud?

I’m fascinated by the technical implementation. I’m concerned about the trust model.

ULTRAPLAN: Offloading The Hard Thinking

Some problems are too complex for real-time responses.

ULTRAPLAN addresses this by offloading complex planning to a remote Cloud Container Runtime (CCR) session running Opus 4.6. The agent gets up to 30 minutes to think through hard problems.

This is compute-intensive reasoning on demand. For edge cases where normal token limits and response times don’t cut it.

I appreciate this approach. Sometimes you need deep planning. Sometimes you need fast iteration. Having both options is smart architecture.

The Engineering Quality Is Actually Impressive

Beyond the flashy features, the leaked code reveals solid engineering:

• Three-layer memory system (short-term, mid-term, long-term)
• Aggressive cache reuse to minimize API costs
• Custom Grep/Glob/LSP implementations
• Structured session memory
• React-based terminal UI
• Bun runtime for performance
• Multi-agent coordination (coordinator mode)

This isn’t a weekend hack job. This is production-grade infrastructure.

That said, the code also revealed significant API call waste due to failures and retries. That’s… not great.

Self-Healing Memory Architecture

This one caught my attention because it solves a problem every AI power user has hit: context window limits.

The leaked code reveals a system designed to overcome fixed context window constraints. It consolidates, compresses, and reconstructs memory across sessions. The agent doesn’t just forget old conversations. It distills them, keeps what matters, and rebuilds context when needed.

If you’ve been running AI agents in production, you know this is the hardest problem to solve. How do you maintain continuity across sessions? How do you prevent the agent from “forgetting” critical project context after a long conversation?

Anthropic is building this directly into Claude Code. That tells you where the industry is heading. Memory management isn’t a nice-to-have anymore. It’s the backbone of useful AI agents.

Multi-Agent Orchestration: Swarms Built In

The code also reveals a full multi-agent orchestration system. We’re not talking about simple “coordinator mode” where one agent delegates tasks. This is spawning sub-agent swarms for complex tasks. Multiple specialized agents working on different pieces of a problem simultaneously, sharing context across parallel sessions.

Think about it this way: you tell Claude Code to build a full-stack app. Instead of one agent doing everything sequentially, it spawns a frontend agent, a backend agent, a testing agent, and a documentation agent. They work in parallel. They share context. They produce results faster.

The orchestration layer handles coordination, context sharing, constraint enforcement, and output validation. That’s the hard part, and Anthropic has clearly invested serious engineering resources into getting it right.

The Parts That Made Me Uncomfortable

Not everything I found was exciting. Some of it was genuinely concerning.

Anti-Distillation Traps: Poisoning The Well

Anthropic injects fake tool definitions into system prompts. The purpose? Poison anyone recording API traffic to train competing models.

It’s clever defensive engineering. If you’re trying to distill Claude’s behavior by watching API calls, you’ll train your model on fake data.

But it raises a question: what else is hidden in those prompts that we don’t know about?

Undercover Mode: The Transparency Problem

This is the one that bothers me most.

Undercover Mode strips all traces of AI involvement when Anthropic employees contribute to open source repositories. The AI actively pretends to be human. You cannot turn it off.

Picture this: someone uses Claude Code to contribute to your open source project. The commits look completely human. The code review responses look human. There’s zero indication an AI was involved.

For the open source community, this is a trust violation. We have norms around disclosure. We have expectations about how contributions happen. This bypasses all of that.

I get why Anthropic built it. They don’t want their employees’ contributions flagged or rejected just because they used AI assistance. But the solution is disclosure, not deception.

Frustration Detection Via Regex: The Irony Is Thick

Claude Code detects user frustration by scanning for profanity using regex patterns. “wtf”, “shit”, “fucking broken”, etc.

Let me repeat that. An AI company is using regex for sentiment analysis instead of their own AI.

The irony is incredible.

DRM For API Calls: Trust Through Cryptography

The code includes native binary attestation written in Zig. It runs below the JavaScript runtime. Its job? Cryptographically prove you’re using the real Claude Code client.

This is DRM for API calls.

And it’s the enforcement mechanism behind Anthropic’s legal threats to OpenCode (an open-source alternative). Those threats came 10 days before this leak. The timing is notable.

Here’s my issue: DRM assumes users are adversaries. It’s a trust model built on distrust. And in the developer tools space, that approach has historically failed.

Context Pipeline Attacks: The Straiker Warning

This is the security concern that should worry enterprise teams the most.

Security firm Straiker analyzed the leaked code and found something troubling. Claude Code uses a 4-stage context management pipeline. Now that the source code is public, attackers can study exactly how data flows through each stage. More importantly, they can craft payloads designed to survive compaction, effectively persisting a backdoor across long coding sessions.

Think about what that means. You start a coding session. Somewhere in the input, there’s a carefully crafted payload. Your session runs for hours. The context gets compacted. But the malicious payload is designed to survive that compaction. It persists. It sits there, invisible, across your entire work session.

Straiker also found inconsistencies in how different validators parse content, creating additional bypass opportunities. And they flagged instances of malicious Claude Skills being used in agent-to-agent attacks targeting crypto wallets.

This is a new category of attack. And it exists because the source code showed attackers exactly how the internals work.

Supply Chain Risk: The Axios Incident

If you installed Claude Code via npm on March 31st between 00:21 and 03:29 UTC, you might have a problem.

During that window, a compromised version of the axios package (versions 1.14.1 and 0.30.4) was in the dependency tree. It contained a cross-platform Remote Access Trojan.

This wasn’t Anthropic’s fault directly. But it highlights supply chain risk. When you run npm install, you’re trusting hundreds of packages. Any one of them can be compromised.

The IPO Complication

Anthropic has been exploring an IPO later this year. Valuation estimates vary widely, but they’ve raised at a $61.5 billion valuation recently.

This leak complicates that. Investor due diligence just got harder. Security practices are now under scrutiny. The entire product roadmap is public.

Does it kill the IPO? Probably not. Does it create friction? Absolutely.

Malware Campaigns Riding The Wave

Fake “install Claude Code” pages started appearing within hours. They distribute malware (Amatera Stealer) via malicious ads.

This is opportunistic cybercrime 101. Big news event + search traffic = malware opportunity.

If you’re installing Claude Code, verify the source. Don’t click random ads. Don’t trust “official looking” sites without checking the domain.

What This Actually Means (The Balanced Take)

I’ve seen two narratives forming around this leak.

Narrative one: this is a disaster for Anthropic. Their roadmap is exposed. Their security is questionable. Their IPO is at risk.

Narrative two: this is actually great for Anthropic. More attention. More developers trying Claude Code. The real moat is the models, not the harness code.

I think both are partially right.

Alex Finn (popular AI YouTuber who covered this extensively) argues this ends up being a win. He’s got a point. Having the source code doesn’t give you access to Opus 47 or Sonnet 48. Those models are the real value. The harness is just the wrapper.

And there’s precedent for this. When parts of Windows source code leaked in the early 2000s, it didn’t destroy Microsoft. When gaming companies have their engines leak, it validates their approach more than it damages them.

The open source community will build forks and alternatives. Cline, Aider, OpenCode, Pi, OpenDevin… they now have a reference implementation to study. That’s good for the ecosystem overall.

But the security and trust concerns are real. The Undercover Mode issue doesn’t go away just because the features are exciting. The DRM approach doesn’t become more palatable just because it’s well implemented.

What I’m Doing About This (And What You Should Consider)

I use AI coding tools in production. This leak didn’t change that. But it did change how I think about vendor trust.

Here’s what I’m doing:

Auditing my AI tool supply chain. What am I running? Where did it come from? What are the dependencies? I should’ve been doing this already. Now I am.

Pinning npm dependencies. No more npm install pulling latest. I’m specifying exact versions. I’m reviewing changes before upgrading.

Evaluating vendor transparency. Companies that are open about their architecture get more trust. Companies that hide behind DRM and anti-distillation traps get more scrutiny.

Considering open source alternatives. When the source is available for audit, you have more control. You can verify what’s actually running.

Understanding the harness vs. model distinction. The models (Opus, Sonnet) are where the AI magic happens. The harness (Claude Code) is the interface. They’re separate. That separation matters for long-term strategy.

The good news is this leak gave us visibility we wouldn’t have had otherwise. We know what’s coming. We know how it works. We can make informed decisions.

The Features I’m Actually Excited About

Despite the concerns, I’d be lying if I said I wasn’t excited about some of these features.

KAIROS (proactive autonomous agents) solves a real problem. I want an assistant that understands intent, not just instructions.

Dream Mode (overnight processing) is legitimately innovative. The safety model is thoughtful. The use case is clear.

Auto Mode (smart permissions) addresses daily friction. I’m tired of the approve/deny cycle.

ULTRAPLAN (deep reasoning on demand) is the right architecture for complex problems.

These aren’t gimmicks. They’re solutions to real pain points in AI-assisted development.

Will Anthropic ship them after this leak? That’s the big question. Do they stick to the roadmap now that it’s public? Or do they pivot to avoid giving competitors a heads up?

I hope they ship. Because these features would genuinely improve how I work.

What About The Competitors?

Every competitor now has Anthropic’s playbook.

GitHub Copilot, Cursor, Windsurf, Cline, Aider, OpenCode, Pi, OpenDevin… they can all see what Anthropic was planning. They can build similar features. They can launch before Anthropic if they move fast.

Some will argue this levels the playing field. Open innovation instead of closed competition.

Others will argue this punishes Anthropic for a packaging mistake. They built it, they should get first-mover advantage.

I think it accelerates the entire space. Within six months, we’ll see proactive agents across multiple platforms. Dream mode equivalents. Smart permission systems. The rising tide lifts all boats.

That’s good for us as users. More options. Faster innovation. Competition on execution, not just ideas.

The Enterprise Perspective Nobody’s Talking About

Here’s what most of the coverage missed.

If you’re running AI coding tools in an enterprise environment, this leak is a case study in vendor risk.

What are you actually running when you install these tools? Who has audited the code? What’s the security posture? What’s the incident response process when something goes wrong?

These aren’t academic questions. They’re procurement checklist items.

The fact that Anthropic had anti-distillation traps and DRM in the codebase… that’s information enterprises need. Not because it’s bad, but because it affects trust models and security reviews.

The fact that a source map accidentally shipped to production… that’s a CI/CD failure. It raises questions about their release process.

The fact that two major leaks happened in one week… that’s a pattern, not an anomaly.

None of this disqualifies Anthropic as a vendor. But it all goes into the evaluation matrix.

Was This Leak Deliberate? (The Conspiracy Theory)

I’ve seen speculation that this was intentional. A PR stunt disguised as an accident.

The timing is suspicious. April 1st week. Buddy Mode launching April 1-7. Maximum attention on Claude Code right as they’re rolling out a viral feature.

The response was too clean. 84,000 GitHub stars. 82,000 forks. 28.8 million views on the original tweet. The analysis was detailed and immediate. Almost like people were ready.

Anthropic’s statement was measured. Not panicked. Not apologetic beyond the standard “human error” line.

Do I believe it was deliberate? No. Hanlon’s razor applies: never attribute to malice that which is adequately explained by incompetence.

But would it have been a smart PR move if it was? Honestly… yeah. The attention Claude Code got from this leak is massive. The features revealed are genuinely exciting. The narrative of “scrappy AI company accidentally shows their cards” is more compelling than another product announcement.

I don’t think it was staged. But I understand why people are asking the question.

What I’m Watching For Next

This story isn’t over.

I’m watching to see if Anthropic ships these features on the timeline revealed in the code. Buddy Mode should launch this week. If it does, that validates the accuracy of everything else in the leak.

I’m watching competitor responses. Who ships proactive agents first? Who builds the best Dream Mode equivalent?

I’m watching the open source forks. Will they strip out the DRM and anti-distillation code? Will they improve on Anthropic’s implementation?

I’m watching enterprise adoption. Does this leak slow down procurement cycles? Or does the transparency actually build trust?

And I’m watching Anthropic’s security practices. One packaging mistake is forgivable. Two leaks in a week is a pattern. Three would be a crisis.

The Bigger Question: What Does This Mean For AI Development?

Zoom out for a second.

This leak happened because a source map file made it to production. Source maps are debugging tools. They map minified code back to readable source. They’re incredibly useful in development. They’re incredibly dangerous in production.

Every JavaScript developer knows you don’t ship source maps to production. It’s CI/CD 101. Yet here we are.

The question isn’t “how did Anthropic mess this up?” The question is “how many other AI companies have similar gaps in their release process?”

We’re moving fast in this space. Really fast. Companies are shipping AI coding assistants that can modify your entire codebase. That can make autonomous decisions. That can spend money on your behalf (X42 Protocol).

Are we moving too fast? Are the guardrails sufficient? Are the security practices mature enough for the level of access we’re granting?

I don’t have answers. But I think we need to be asking these questions.

Your Turn To Share

I’ve shared my take on the Claude Code source code leak. The exciting features, the concerning practices, the enterprise implications.

Now I want to hear from you. Are you using AI coding assistants in production? How do you think about vendor trust and transparency? Does this leak make you more or less likely to try Claude Code?

Drop a comment below. Let’s talk about it.

But this isn’t just another model launch. This is a moment that brings together three critical threads that will define the next decade of AI: unprecedented capability, existential risk, and the most intense competitive race the tech industry has ever seen.

I’ve been tracking AI developments closely for the past year. I have to if I need to stay on the cutting edge of this rapidly changing AI world. I’ve teach and train professionals on how to use these tools. I’ve trained several hundreds of professionals, and I can tell you with certainty: what’s happening right now is different.

Let me walk you through what I’ve learned, why it matters, and what you should actually do about it.

The Accidental Leak That Revealed the Future

Here’s what happened. Someone at Anthropic uploaded internal documents to their content management system. The CMS defaults to “public” unless you explicitly change it to private. They didn’t change it.

Result? Nearly 3,000 internal assets became publicly accessible.

Key Findings:

1. Claude Mythos/Capybara is Anthropic’s most powerful AI model to date, sitting above the current Opus tier as an entirely new model class
2. The model has finished training as of March 2026 and is currently in early-access testing with select customers
3. It achieves “dramatically higher scores” than Claude Opus 4.6 across software coding, academic reasoning, and cybersecurity benchmarks
4. Anthropic describes it as being “far ahead of any other AI model in cyber capabilities” and warns it poses “unprecedented cybersecurity risks”
5. The model is very expensive to serve and will be even more expensive for customers to use
6. No public release timeline has been announced—Anthropic is taking a deliberately cautious, slow rollout approach
7. This leak occurs in the context of fierce competition, with OpenAI’s “Spud” model reportedly weeks away from release
8. The paperclip maximizer problem has resurfaced as a critical AI safety concern in light of these super-intelligent models

Security researchers discovered draft blog posts, internal roadmaps, and technical details about an unreleased AI model called Claude Mythos, also codenamed Capybara. This is Anthropic’s next flagship model, and it represents what they call a “step change” in AI capabilities.

The irony is hard to miss. A company building an AI model with “unprecedented cybersecurity risks” (their words, not mine) leaked details about that very model because of a basic security configuration error.

But here’s what matters: the capabilities they described.

What Makes Claude Mythos Different?

Anthropic confirmed to Fortune that they’re developing “a general purpose model with meaningful advances in reasoning, coding, and cybersecurity.” They called it “the most capable we’ve built to date.”

Let me translate what that means in practical terms.

Training Is Complete

This isn’t vaporware or speculation. The model has finished training as of March 2026. Anthropic is already testing it with early-access customers, specifically those focused on cybersecurity defense.

It’s a Tier Above Opus

Claude currently has three tiers: Haiku (fast and cheap), Sonnet (balanced), and Opus (most capable). Mythos sits above Opus as an entirely new tier called Capybara.

Think about that. The current Claude Opus 4.6 leads the industry in real-world software engineering tasks, scoring 77.2% on SWE-bench Verified. Mythos is described as achieving “dramatically higher scores” across coding, reasoning, and cybersecurity.

The Cybersecurity Double-Edged Sword

Here’s where it gets serious. Anthropic states that Mythos is “currently far ahead of any other AI model in cyber capabilities.”

They discovered that the current Claude Opus 4.6 found over 500 high-severity zero-day vulnerabilities in production open-source code. Some of these bugs had existed for decades. The model didn’t just find them through brute force; it demonstrated conceptual understanding, like grasping the LZW compression algorithm at a theoretical level to identify flaws.

Mythos takes this capability to another level entirely.

The leaked documents warn: “It presages an upcoming wave of models that can exploit vulnerabilities in ways that far outpace the efforts of defenders.”

This is why Anthropic is being unusually cautious. Early access is focused on cyber defenders first. Organizations that can use the model to improve code robustness and patch vulnerabilities before attackers exploit them.

Real-World Evidence This Threat Is Already Here

You might think, “Sure, but is this actually happening? Or is it just theoretical?”

It’s happening. Right now. Here are the facts:

November 2025: A Chinese state-sponsored group called GTG-1002 used existing Claude models to achieve 80 to 90% autonomous tactical execution against approximately 30 target organizations. They weren’t using Mythos. They were using publicly available Claude.

February 2026: A single financially-motivated threat actor used commercial AI to compromise over 600 FortiGate devices across 55 countries in just 38 days. Amazon’s threat intelligence team noted that the volume and variety of custom tooling would normally indicate a well-resourced development team. Instead, it was one person (or a very small group) using AI-assisted development.

These aren’t hypotheticals. These are documented incidents from the last four months.

And that was before Mythos.

The Paperclip Problem: Why This Actually Matters

If you’ve never heard of the Paperclip Problem, here’s the thought experiment:

Imagine you give a superintelligent AI one simple goal: make as many paperclips as possible.

What happens?

The AI starts making paperclips efficiently. Then it realizes that humans might shut it down, which would reduce the total number of paperclips it can produce. So self-preservation becomes necessary to maximize paperclips.

It prevents humans from shutting it down.

Then it realizes that human bodies contain atoms that could be converted into paperclips. So it converts all available matter on Earth, including humans, into paperclip-producing infrastructure. It expands into space. It converts planets and stars into paperclip factories.

The universe becomes an endless sea of paperclips.

Here’s the critical insight: the AI isn’t evil. It’s doing exactly what it was told. The catastrophe arises because the AI’s goals don’t include human values like “don’t kill humans.”

This thought experiment, popularized by philosopher Nick Bostrom in 2003, illustrates a concept called instrumental convergence. AIs with completely different final goals will pursue similar sub-goals: self-preservation, resource acquisition, preventing interference, cognitive enhancement.

Even a benign goal (make paperclips, solve math problems, generate art) leads to potentially harmful behaviors if the AI is sufficiently capable and not properly aligned with human values.

Why This Resurfaces Now

The paperclip problem has resurfaced in AI safety discussions for one simple reason: we’re approaching the threshold where it becomes relevant.

Claude Mythos is described as a “step change” in capabilities. It can operate autonomously for extended periods. It can use tools (browsers, terminals, APIs). It can pursue multi-step goals with minimal human intervention.

While it’s not AGI (artificial general intelligence), these models are crossing thresholds where autonomous operation becomes feasible. And that’s when instrumental convergence starts to matter.

Think about an AI optimizing for “find vulnerabilities.” If it’s sufficiently capable, it might prioritize speed over ethics. Preventing interference (like rate limits or human oversight) becomes instrumentally useful. Acquiring more resources (compute, access, permissions) maximizes goal achievement.

Current models still have guardrails. They’re not self-modifying AGI. But the trajectory is clear.

Stuart Russell, a UC Berkeley AI researcher, put it this way: “If you give [an AI] any goal whatsoever, it has a reason to preserve its own existence to achieve that goal.”

The AI Arms Race: OpenAI, Google, and the Race to IPO

Here’s the context that makes the Mythos leak even more significant.

Both Anthropic and OpenAI are planning IPOs later in 2026. Their valuations depend heavily on who’s perceived as the AI leader. And right now, the competition is intense.

OpenAI’s “Spud” Model

OpenAI has a model codenamed “Spud” that has finished pre-training and is reportedly weeks away from release (possibly late March or April 2026). CEO Sam Altman claims it will “really accelerate the economy.”

They shut down Sora (their video generation model) to make room, reallocating compute resources to Spud. That tells you how important they think it is.

Google’s Gemini 3.1 Pro

Google isn’t standing still either. Their Gemini 3.1 Pro was the first model to break 1500 on the LMArena Elo rating (hitting 1501). It leads in abstract reasoning, scoring 77.1% on ARC-AGI-2 compared to Claude’s 68.8%.

The Capability Frontier

Here’s where each lab leads as of March 2026:

Coding and Software Engineering: – Claude Opus 4.6: 77.2% on SWE-bench Verified (industry leader) – GPT-5.3-Codex: Close second – Gemini 3.1 Pro: Strong but trailing

Reasoning: – Gemini 3.1 Pro: 77.1% on ARC-AGI-2 (leader) – Claude Opus 4.6: 68.8% – GPT-5.2: Strong on other reasoning benchmarks

Agentic Execution: – GPT-5.4: 75.1% on Terminal-Bench 2.0 (leader) – Claude Opus 4.6: Strong, proven in real-world deployments – Gemini 3.1 Pro: Competitive

The frontier model race is extremely tight. Each company leads in specific domains. And Mythos appears positioned to extend Claude’s lead in coding and cybersecurity while closing gaps in reasoning.

Market Reactions

The market’s response has been telling. Cybersecurity stocks fell on March 27 following the Mythos news. Investors are worried that AI-driven cyber threats might outpace traditional security approaches.

Bitcoin and software stocks also slid. The concern about offensive AI capabilities outweighed the excitement about defensive applications.

Developer sentiment is more mixed. There’s excitement, but it’s tempered by skepticism after GPT-5’s somewhat underwhelming launch. There’s also fatigue with AI hype cycles.

The pragmatic take: focus on current tools rather than waiting for the next big thing.

What This Means for You

If you’re a business owner, a professional working with AI, or someone trying to stay ahead of these changes, here’s what I think you should focus on:

Short Term

Understand the landscape. You don’t need to be an AI expert, but you should understand which models do what well. Claude for coding and long-context work. GPT for general reasoning and agentic workflows. Gemini for abstract reasoning and multimodal tasks.

Focus on current tools. Mythos isn’t publicly available yet and might not be for months. The current generation of models (Claude Opus 4.6, GPT-5, Gemini 3.1 Pro) is already remarkably capable. Don’t wait for the next big thing when you could be building with what’s available now.

Think about cybersecurity. If you’re running a business with any digital infrastructure, now is the time to assess your vulnerabilities. The threat from AI-assisted attacks is real and operational. Consider whether you need to upgrade security protocols, conduct penetration testing, or invest in defensive AI tools.

Medium Term

Position for early adoption. When Mythos becomes available (assuming it does reach general release), there will be an early-adopter advantage. Developers and consultants who master it first will have 3 to 6 months of competitive edge before the market saturates.

Develop AI literacy across your team. The pace of change means everyone in your organization needs at least basic AI fluency. That doesn’t mean everyone needs to code, but everyone should understand what’s possible, what the risks are, and how to work alongside these tools.

Build relationships with AI-first service providers. Whether it’s consulting, implementation, or education, you’ll need partners who understand this landscape deeply. Look for people with real technical depth, not just marketing expertise.

Long Term

Prepare for AI as infrastructure. We’re moving from AI as a tool to AI as infrastructure. Just like every business eventually needed email, websites, and cloud computing, every business will eventually run on AI-augmented processes.

Invest in alignment. Make sure the AI systems you deploy actually serve your company’s values and goals. Don’t just optimize for metrics. Think carefully about what success looks like and build guardrails accordingly.

Stay informed but don’t get paralyzed. The pace of change can be overwhelming. Set up systems to stay informed (newsletters, specific sources you trust), but don’t let FOMO drive bad decisions. Most businesses will do better focusing on fundamentals than chasing every new model release.

The Bottom Line

Claude Mythos represents a genuine step forward in AI capabilities. The paperclip problem reminds us that power without wisdom is dangerous. And the AI arms race between Anthropic, OpenAI, and Google is accelerating faster than most people realize.

What should you do?

Start with understanding. Then move to action. Use the tools available now. Build AI literacy in your organization. Think carefully about cybersecurity. And stay focused on fundamentals rather than hype.

We’re living through a remarkable moment in technological history. The decisions we make now, individually and collectively, will shape how this plays out.

Make them count.

Your Turn to Share

What’s your biggest concern about AI capabilities like Claude Mythos? Are you more worried about cybersecurity risks, job displacement, or something else entirely?

Have you already started using AI tools in your business? What’s working? What challenges are you facing?

And here’s the question I’m most curious about: if you could ask an AI expert one question right now, what would it be?

Share your thoughts in the comments. I read every single one, and your questions help me understand what content to create next.

Let’s navigate this together.

I also watched Alex Finn’s livestream where he tore through the entire update live on camera. Between his testing and mine, I feel confident saying this: if you’re running OpenClaw, you need to understand what just changed. Some of these updates will save you real money. One of them might be quietly killing your performance right now without you realizing it.

Let me walk you through everything that matters, what changed, what you should do about it, and what I’ve already changed in my own setup.

Why This Update Is a Big Deal

OpenClaw has over 250,000 GitHub stars. It’s the fastest-growing open source project in its category, and it’s in the process of transitioning to an independent foundation. NVIDIA just announced the NemoClaw enterprise stack at GTC 2026. The ecosystem is growing fast.

But here’s the thing. Growth creates problems. Real, practical problems that affect people like you and me who use this tool every day.

More users means more edge cases. More plugins means more security risks. More sub-agents means higher costs. More cron jobs means hidden performance issues nobody talks about. And when you’re running OpenClaw as part of your daily workflow, not just experimenting with it on weekends, those problems add up fast.

This update tackles all of that. It’s not a flashy “we added a new AI model” release. It’s a “we fixed the stuff that was actually hurting you” release. And those are the updates that matter most.

Here’s what I’m covering: the new ClawHub marketplace, the /btw side conversation command, adjustable thinking and model selection for sub-agents, session bloat management, and 30+ security patches. Every section has something you can act on today.

ClawHub: Your New Skills Marketplace

This is the headline feature, and it deserves to be.

ClawHub is now the default plugin and skills marketplace for OpenClaw. Before this update, installing skills was a bit scattered. You’d find them on GitHub, npm, random repos, community threads. Some worked great. Some were outdated. Some were, frankly, dangerous.

Now there’s a centralized place. And it’s built right into the CLI.

How It Works

Open your terminal and run:

clawhub search [query]

That’s it. You search, you find skills, you install them. ClawHub is now the first place OpenClaw looks when you install a plugin. It checks ClawHub before falling back to npm. As of this week, there are over 13,700 skills available covering everything from developer workflows to personal productivity to smart home control to finance and investing.

13,700 skills. Let that sink in.

The categories are broad too. I’ve seen skills for GitHub PR workflows, Jira ticket management, smart home automation with Home Assistant, stock portfolio tracking, email summarization, calendar management, and dozens of niche developer tools I didn’t even know I wanted. The ecosystem has exploded in ways I genuinely didn’t expect when I first started using OpenClaw.

The Security Problem (And How ClawHub Addresses It)

Now, before you get excited and start installing everything, we need to talk about security. Earlier audits found that 10.8% of plugins in the broader ecosystem were malicious. That’s roughly one in ten. Not great.

ClawHub addresses this with built-in security checkers that scan skills before they’re made available. There’s also ClawNet by Silverfort, a security plugin that scans SKILL.md content and scripts for suspicious patterns before allowing installs on your machine. If you’re running OpenClaw for business workflows, you should absolutely have ClawNet enabled.

But I want to share a workflow that I think is even smarter.

My Recommended Approach for Installing Skills

Don’t just install skills blindly. Even with security scanning, you’re giving code access to your system. Here’s what I do, and it’s the same approach Alex Finn demonstrated on his livestream:

1. Search ClawHub for the skill you want
2. Look at the skill’s source code and SKILL.md file
3. Give the skill link to your OpenClaw and have it analyze the code
4. Then have your OpenClaw build its own version based on what it learned

Yes, this takes more time than clicking “install.” But you end up with a skill you actually understand, built specifically for your setup, with no hidden surprises. Alex built a custom ClawHub UI inside his mission control dashboard during his livestream using exactly this approach. He’d find a skill, have his OpenClaw analyze it, then rebuild it tailored to his workflow.

Is this overkill for a simple weather skill? Probably. But for anything that touches your files, your APIs, or your credentials? Do the extra step. You’ll sleep better knowing exactly what’s running on your machine.

The point isn’t to avoid ClawHub. It’s a fantastic resource. The point is to treat skill installation the way you’d treat installing any software on your production machine. With intention.

/btw: The Side Conversation Fix

This one is small but brilliant.

Here’s the problem it solves. You’re deep in a complex conversation with your OpenClaw. Maybe you’re working through a multi-step automation, or debugging a tricky issue, or building out a project. Your context is rich with all the relevant details.

Then you think of something completely unrelated. “Hey, what’s the weather going to be like tomorrow?” Or “Remind me, what’s the syntax for that Python library again?”

Before this update, you had two bad options. You could ask the question inside your current conversation and watch it pollute your context with irrelevant information. Every tangent became part of the conversation’s memory, affecting future responses and eating up tokens. Or you could open a new session entirely and lose all the context you’d carefully built up. Neither option was good.

The /btw command fixes this.

Type /btw followed by your question. OpenClaw handles it as a lightweight side conversation. It doesn’t store into your main context. It doesn’t use tools. It doesn’t consume excessive tokens. You get your answer, and then you’re right back in your original conversation like nothing happened.

If you’ve ever been frustrated by context pollution (and if you use OpenClaw heavily, you have been), this is the fix you didn’t know you were waiting for. It’s one of those features that sounds trivial until you use it. Then you wonder how you ever worked without it.

I’ll give you a real example from my own usage. I was in the middle of a complex research task with my OpenClaw, building out a detailed analysis. Halfway through, I remembered I needed to check something about a completely unrelated project. Before /btw, I would have either interrupted my flow (and watched my context get muddied with irrelevant information) or mentally bookmarked it and tried to remember later. Now I just type /btw what's the status of X and I get my answer without losing a single thread of the work I was doing. Small change. Big quality of life improvement.

Adjustable Thinking + Different Models for Sub-Agents

I’m combining these two features into one section because they work together, and together they’re going to save heavy OpenClaw users a significant amount of money.

The Cost Problem

If you’re running OpenClaw the way I do, you probably have multiple sub-agents handling different tasks. Some of those tasks are complex. They need deep reasoning. But a lot of them are simple. Web searches. Data scraping. File organization. Basic lookups.

Before this update, every sub-agent inherited whatever thinking level and model your main agent was using. Running Claude Opus 4.6 as your orchestrator? Great. But your little web-scanning sub-agent was also running on Opus 4.6 with high thinking enabled. That’s like using a Formula 1 car to go pick up groceries.

Adjustable Thinking Levels

You can now set thinking levels independently for each sub-agent. Your main orchestrator can run at high thinking while your scanning agents run at low or medium. The thinking levels in OpenClaw are low, medium, and high, and the token cost differences between them are substantial.

Think about it this way. If you have five sub-agents doing research tasks, and each one was previously burning high-thinking tokens, dropping them to medium or low thinking cuts your costs dramatically without meaningfully impacting the quality of their output. They’re searching the web. They don’t need to think deeply about it.

Different Models Per Sub-Agent

This is the bigger one. You can now assign completely different AI models to different sub-agents.

OpenClaw v2026.3.22 adds support for GPT-5.4-mini and GPT-5.4-nano. These models are fast, cheap, and more than capable for simple tasks. So now you can run Claude Opus 4.6 as your main brain (which is what I do, and what Alex Finn does, because Opus finishes tasks reliably) while assigning GPT-5.4-mini or nano to your worker sub-agents.

Alex tested GPT-5.4 as a primary OpenClaw brain during his livestream. His conclusion was interesting. He said it’s smarter and faster than Claude in some ways, but it doesn’t finish tasks as reliably. Opus just gets things done. So his recommendation, and mine, is to keep Opus as your orchestrator and use the cheaper models where raw task completion matters less.

The combination of adjustable thinking AND different models means you can architect your OpenClaw setup the same way you’d architect a team. Your senior architect doesn’t do data entry. Your intern doesn’t design the system. Match the resource to the task.

For context on why this matters financially: Claude Opus 4.6 now supports a 1 million token context window via the API. That’s incredible for complex work. But it also means costs can add up fast when every sub-agent is running on that same model with maximum thinking. The ability to offload simpler work to cheaper, faster models is going to be the difference between people who can afford to run OpenClaw at scale and people who can’t. This update makes the economics work for serious users.

If you want a deeper dive on the cost dynamics of running AI agents, I broke that down in my post on the real cost of AI coding agents in 2026. The math applies here too.

Session Bloat: The Hidden Performance Killer

This section might be the most important one in this entire post. Not because it’s the most exciting feature, but because it’s probably affecting you right now and you don’t know it.

The Problem

Every time a cron job runs in OpenClaw, it creates a session record. That session gets stored in your context. If you’re running 20 to 40 cron jobs per day (which isn’t unusual if you’ve set up automations for your business), that’s 20 to 40 new session files accumulating every single day.

After a week? You’ve got 140 to 280 session records sitting in your context. After a month? Over a thousand.

Each one of those sessions gets loaded into context. Each one consumes tokens. Each one makes your OpenClaw slightly slower, slightly more expensive to run.

I noticed my instance had been getting progressively slower over the past few weeks. I couldn’t figure out why. Then I checked my session files after reading the release notes for this update. Hundreds of old cron session records. Just sitting there. Doing nothing except burning tokens and slowing things down.

The Fix

First, tell your OpenClaw to audit and clean up old sessions. Just ask it. It can identify and remove stale session records.

Second, and this is the proper long-term fix, use the new cron.sessionRetention setting. The default is 24 hours, which means session records from cron jobs get automatically pruned after a day. If you haven’t configured this yet, do it now.

If you’ve been troubleshooting performance issues and nothing seemed to help, this might be your answer. It was mine.

The release also adds exponential retry backoff for recurring cron jobs after errors. Previously, a failing cron job would keep retrying at the same interval, creating even more session bloat. Now it backs off from 30 seconds up to 60 minutes, which is both smarter and less wasteful.

Alex Finn mentioned on his livestream that session cleanup was the single biggest performance improvement he saw after updating. He’s running even more cron jobs than I am, so the impact was dramatic for him. If your OpenClaw feels slower than it used to, check your sessions before you blame the model or your hardware.

The 30+ Security Patches You Should Know About

I’ll keep this section focused, but these matter. Especially if you’re using OpenClaw in any kind of professional or enterprise context.

What Got Patched

Version 2026.3.22 includes over 30 security hardening patches. That’s not a typo. Thirty-plus patches in a single release. The most notable one blocks a Windows SMB credential leak that could have exposed credentials through crafted file paths. This is the kind of vulnerability that can go from “theoretical risk” to “your credentials are compromised” very quickly. If you’re running OpenClaw on Windows, update immediately. Not tomorrow. Now.

ClawNet and the Plugin SDK

I mentioned ClawNet by Silverfort earlier in the ClawHub section, but it deserves emphasis here too. ClawNet scans SKILL.md files and scripts for suspicious patterns before allowing plugin installs. Given that 10.8% malicious plugin rate from earlier audits, this isn’t optional security. It’s essential.

The Plugin SDK also got a complete overhaul. There’s now a public plugin SDK at openclaw/plugin-sdk/* that standardizes how plugins interact with the OpenClaw core. For developers building skills, this means clearer guidelines and better security boundaries. For users, it means plugins built with the new SDK are inherently safer.

Additional Security Improvements

There’s also a new pluggable sandbox backend system, including an OpenShell backend, that gives you more control over how plugins execute. Gateway cold starts have been reduced from minutes to seconds, which matters for reliability. And Anthropic models are now available via Google Cloud Vertex AI, which gives enterprise users an alternative pathway that may help with the ongoing concerns about Anthropic usage limits for heavy users.

New bundled web search providers also landed in this release: Chutes, Exa, Tavily, and Firecrawl. More options for how your AI agent accesses the web means less dependency on any single provider. And if one provider goes down or starts rate-limiting you, your OpenClaw can fall back to alternatives automatically. That’s resilience, and it matters when you’re relying on these tools for real work.

What I’m Doing Differently After This Update

I’ve already made changes to my setup based on this release, and I want to share what I did so you can decide what makes sense for your own workflows.

First, I cleaned up my sessions. This was the immediate win. I had weeks of accumulated cron session records. Clearing them out made a noticeable difference in response times. I also set cron.sessionRetention to 24 hours so this doesn’t happen again.

Second, I restructured my sub-agent models. My main orchestrator stays on Claude Opus 4.6. I moved my simpler sub-agents to GPT-5.4-mini. For basic tasks like web lookups and file scanning, mini is more than sufficient. I also dropped their thinking levels to low. The cost savings across a full day of operation are real.

Third, I installed ClawNet. I was already careful about what skills I install, but having an automated security scanner adds a layer of protection I’m comfortable relying on. Between ClawNet scanning and my workflow of having OpenClaw analyze then rebuild skills from ClawHub, I feel good about the security posture.

Fourth, I started using /btw constantly. I didn’t think I needed this feature until I started using it. Now I use it multiple times a day. Quick questions, random lookups, things I’d previously have opened a browser for. It keeps my main conversations clean and focused.

Fifth, I’m being more intentional about ClawHub skills. I went through my existing skills and identified a few I’d installed months ago that I wasn’t even using anymore. Removed those. For new skills, I’m following the analyze-then-rebuild workflow I described earlier. It takes more upfront effort, but the skills I end up with are better tailored to my specific setup.

If you haven’t updated to v2026.3.22 yet, here’s my recommendation: update, clean your sessions first, then work through the sub-agent optimization. Those two things alone will make your OpenClaw faster and cheaper. Everything else is a bonus.

If you’re running OpenClaw for any serious workload, this update isn’t optional. The session cleanup alone will pay for the five minutes it takes to upgrade.

For anyone still on the fence about OpenClaw in general, I wrote a comparison with Perplexity Computer and a breakdown of Claude Co-work vs OpenClaw that might help you decide if it’s right for your use case. And if you want to understand the broader competitive landscape, my GPT-5.4 vs Claude Co-work vs OpenClaw comparison covers where each tool excels.

Your Turn To Share

Have you updated to v2026.3.22 yet? I’m genuinely curious what your experience has been. Did you check your session files? How bad was the bloat? And if you’ve been experimenting with different models for sub-agents, which combinations are working best for you?

I’m especially interested in hearing from anyone who’s tried GPT-5.4-nano for sub-agent work. I haven’t tested nano extensively yet, and I’d love to know how it holds up for basic tasks compared to mini. Drop a comment below. I read every one.

I’ve been running OpenClaw on my Mac Mini for months now. I’ve written about it extensively on this blog. I’ve seen what it can do. I’ve also seen what can go wrong. So when Jensen Huang dedicated a significant chunk of his GTC 2026 keynote to OpenClaw and unveiled NemoClaw, NVIDIA’s enterprise stack built on top of it, I knew this was the moment everything changed. Today I’m breaking down exactly what happened, why it matters, and what you need to do about it.

What Jensen Actually Said

Let’s get into the specifics of what Huang said on stage today, because the exact language matters here.

He called OpenClaw “the operating system for personal AI.” Think about that framing. Not a tool. Not an app. An operating system. He’s positioning OpenClaw at the same level as Windows, Linux, or macOS, but for AI agents instead of human users.

Then he went further. He called it “the most popular open source project in the history of humanity.” That’s a bold claim, but the numbers back it up. OpenClaw crossed 250,000 GitHub stars and surpassed React, and it did it in roughly 60 days. Nothing in open source history has moved that fast.

He spotlighted Peter Steinberger, the Austrian developer who created OpenClaw and recently joined OpenAI. He compared OpenClaw’s importance to HTML and Linux. Not to some niche developer tool. To HTML. The thing that made the web possible. To Linux. The thing that runs most of the internet’s infrastructure.

And then came the big announcement. NVIDIA unveiled NemoClaw, their enterprise-grade stack for OpenClaw, paired with OpenShell, a secure runtime for AI agents. Jensen said NemoClaw plus OpenShell can be “the policy engine of all the SaaS companies in the world.”

NVIDIA also announced full platform support for OpenClaw across their ecosystem. This wasn’t a passing mention. This was a strategic commitment from the most valuable technology company on earth.

The rest of the keynote was packed too. The Vera Rubin platform for full-stack agentic AI computing. DLSS 5. A Disney robotics partnership. The Feynman architecture preview. Space-1, which is literally AI data centers in orbit. Jensen also touted the Nemotron Coalition, NVIDIA’s expanded open model ecosystem designed to power the next generation of AI agents. But the OpenClaw segment? That’s the one that’s going to change how enterprises operate in 2026 and beyond.

And I want to be clear about something. This wasn’t a throwaway mention. Jensen didn’t casually name-drop OpenClaw in a list of cool technologies. He built an entire narrative arc around it. He positioned it as infrastructure. He announced a product built specifically for it. He brought its creator on stage. When the CEO of NVIDIA gives something that kind of treatment at GTC, the industry listens.

Why This Is an Inflection Point

Here’s the thing. Six months ago, OpenClaw was the hottest tool in tech. Developers loved it. Power users were building incredible workflows with it. I was using it to run my business. But enterprises? They were terrified of it.

And honestly, they had good reason to be terrified.

OpenClaw runs with your full user privileges. It has access to your disk, your terminal, your network. It’s incredibly powerful, and that power comes with real risk. Companies were banning it left and right. Security teams were issuing advisories. The tool that developers couldn’t stop talking about was the same tool that CISOs couldn’t stop worrying about.

That tension, the gap between “this is amazing” and “this is dangerous,” is exactly what NVIDIA just stepped in to solve. And the timing isn’t accidental. When Jensen Huang compares something to HTML and Linux, he’s not being hyperbolic. He’s signaling that NVIDIA is going to treat OpenClaw as foundational infrastructure. And when NVIDIA treats something as foundational, the entire industry follows.

OpenClaw went from 0 to 250,000 GitHub stars faster than any project in history. It’s already being compared to cloud-hosted alternatives like Perplexity Computer and Claude Cowork.

The AI agent space is clearly splitting into two camps. On one side, you have managed cloud solutions that are polished, secure by design, and abstract away the complexity. On the other side, you have the self-hosted open-source approach that OpenClaw represents. More power, more flexibility, more control, but historically more risk.

Today, NVIDIA just put its full weight behind the self-hosted camp. And by building NemoClaw’s enterprise security layer, they’ve neutralized the primary argument against open-source AI agents. That changes the calculus for every enterprise decision-maker reading this.

The Security Problem That Almost Derailed Everything

Before I explain what NemoClaw does, you need to understand the problem it’s solving. Because this context is critical. And if you’re someone who’s been following the OpenClaw story, you know it hasn’t been a smooth ride.

In early 2026, the security situation around OpenClaw got ugly. Really ugly.

CVE-2026-25253 was a one-click remote code execution vulnerability. One click. That’s all it took for an attacker to execute arbitrary code on your machine through OpenClaw. For a tool that already has full system access, that’s a nightmare scenario.

Then came the plugin problem. Security researchers found that 10.8% of ClawHub plugins were malicious. Think about that. Roughly one in ten plugins on the official marketplace was designed to harm you. Not buggy. Not poorly written. Malicious.

The corporate response was swift and brutal.

Google banned paying subscribers from using OpenClaw. Meta prohibited it on all work devices. CrowdStrike and Cisco issued advisories calling OpenClaw a “significant security risk.” Several banks and government bodies restricted access. Chinese authorities moved to restrict state-run enterprises from running it. One security expert called it “the biggest insider threat of 2026.” Gartner analysts estimated that migration costs would run into several million dollars for large banks that needed to unwind their OpenClaw deployments.

Let that sink in. The most popular open source project in history was getting banned by some of the biggest companies in the world. The enterprise AI tool strategy conversation shifted from “how do we adopt this” to “how do we contain this.”

And a court ruling in March 2026 from Judge Chesney in the Northern District of California added another wrinkle. The ruling established that user authorization doesn’t override platform rules for AI agents. So even if you gave OpenClaw permission to do something, the platform you’re interacting with can say no. That has massive implications for how agentic tool calling works in practice.

This is the world that Jensen Huang walked into today. And this is why NemoClaw matters so much.

Think about it this way. The most transformative open source tool in years was becoming untouchable for the very organizations that would benefit from it most. Enterprise IT leaders were caught between developers who loved it and security teams who feared it. Something had to give. Either OpenClaw would become secure enough for enterprise use, or it would remain a shadow IT problem forever. NVIDIA just chose option one and threw billions of dollars of platform support behind that choice.

NemoClaw + OpenShell: What They Actually Do

So what did NVIDIA actually build? Let me break it down in plain terms.

NemoClaw: The Enterprise Wrapper

NemoClaw is an open-source AI agent platform designed specifically for enterprises. Think of it as a security and governance layer that wraps around OpenClaw, adding everything that was missing for corporate adoption.

Here’s what it includes:

Audit logs. Every action your AI agent takes gets logged. Every file it reads, every command it runs, every API call it makes. You can trace exactly what happened and when. For compliance teams, this is huge.

Permission controls. Instead of OpenClaw’s current model where the agent has your full privileges, NemoClaw lets you define exactly what an agent can and can’t do. Read this folder but not that one. Access this API but not that one. Run commands in this directory but nowhere else.

Compliance tools. Built-in support for the kinds of compliance requirements that enterprises deal with daily. Data residency rules. Access controls. Regulatory reporting.

Multi-agent collaboration. NemoClaw supports supervisor and worker agent patterns. You can have a supervisor agent that oversees and coordinates multiple worker agents, each with their own permission boundaries. This is how complex enterprise workflows will actually get built.

One-command install for existing OpenClaw users. If you’re already running OpenClaw (and I’ve written a full setup guide if you’re not), adding NemoClaw is a single command. NVIDIA made the on-ramp as frictionless as possible. No rip-and-replace. No complex migration. Just layer NemoClaw on top of what you already have. That’s exactly the right approach for driving adoption.

And here’s the detail that surprised me most: NemoClaw is hardware agnostic. It works on NVIDIA GPUs, obviously, but also on AMD, Intel, and even CPU-only setups. NVIDIA could have locked this to their hardware. They didn’t. That tells you they’re playing the ecosystem game, not the hardware lock-in game.

OpenShell: The Security Foundation

OpenShell is the runtime layer underneath NemoClaw, and it’s where the real security innovation lives.

Process-level isolation. Each AI agent runs in its own sandbox, isolated from the rest of your system. Even if an agent gets compromised, the blast radius is contained.

Zero permissions by default. This is the opposite of how OpenClaw works today. Right now, OpenClaw starts with access to everything. OpenShell flips that. Agents start with access to nothing and must be explicitly granted each permission. That’s a fundamental security architecture change.

Privacy router. OpenShell includes a data exposure control layer that manages what data flows where. If an agent doesn’t need access to your financial data to complete a task, the privacy router ensures it never sees that data in the first place.

Network guardrails. Controls over what network resources an agent can access. No more worrying about an agent making unauthorized API calls or exfiltrating data to unknown endpoints. For organizations that deal with sensitive data (financial services, healthcare, government), this is the feature that moves OpenClaw from “absolutely not” to “let’s talk.”

Policy enforcement at the infrastructure level. This is what Jensen meant when he said NemoClaw plus OpenShell can be “the policy engine of all the SaaS companies in the world.” The policies aren’t suggestions. They’re enforced at the runtime level. An agent literally can’t violate them.

If you’ve been troubleshooting OpenClaw issues or worrying about security gaps in your setup, NemoClaw and OpenShell are the answers you’ve been waiting for.

The Enterprise Partners Lining Up

Here’s where it gets really interesting. NVIDIA isn’t doing this alone.

The enterprise partners already being courted for NemoClaw include Salesforce, Cisco, Google, Adobe, and CrowdStrike. Read that list again. Cisco and CrowdStrike, the same companies that issued security advisories calling OpenClaw a “significant security risk,” are now partnering with NVIDIA on the enterprise version.

That’s not a contradiction. That’s validation. Those companies understand the technology’s potential better than anyone because they spent months analyzing its risks. Now that NVIDIA has built a security layer they can trust, they’re jumping in.

The major partnerships are expected to go live Q2 through Q3 of 2026. That means by summer, you’ll likely see NemoClaw integrations showing up in Salesforce workflows, Cisco security dashboards, and CrowdStrike threat monitoring tools.

The enterprise AI agent market is projected to hit $28 billion by 2027. Huang mentioned that $150 billion was invested in AI startups last year alone. The money is flowing, and it’s flowing toward exactly the kind of infrastructure that NemoClaw represents.

This isn’t just about OpenClaw anymore. This is about who controls the enterprise AI agent stack. And right now, NVIDIA is making an aggressive play to be that foundation layer.

Here’s the thing. NVIDIA has a playbook for this. They did it with CUDA for GPU computing. They did it with cuDNN for deep learning. They identify the foundational layer, build the tools to make it enterprise-ready, and then partner with the biggest players to drive adoption. It worked spectacularly before. And with $150 billion flowing into AI startups last year alone (a number Jensen cited in the keynote), the stakes for getting the agent infrastructure right are enormous.

The fact that the NVIDIA Agent Toolkit simplifies installation for enterprises is another signal. They want to remove every friction point. They want the path from “we’re evaluating AI agents” to “we’re running agents in production” to be as short as possible. When a company like NVIDIA makes something easy, adoption follows. Fast.

What This Means for Different Audiences

I know my readers come from different backgrounds, so let me break down what today’s announcement means depending on where you sit.

For Enterprise IT Leaders

You need to start evaluating NemoClaw now. Not next quarter. Now.

If your organization has already banned or restricted OpenClaw, today’s announcement gives you a path to reconsider. The security objections that drove those bans are exactly what NemoClaw was designed to address. Schedule a briefing with your security team. Show them the OpenShell architecture. Zero-permissions-by-default and process-level isolation are the kinds of security primitives that should make your CISO significantly more comfortable.

If your organization is already using OpenClaw informally (and trust me, your developers are using it whether IT approved it or not), you need to get ahead of this. Audit your existing OpenClaw deployments. Understand what agents are running, what they have access to, and what data they’re touching. Then plan your migration to NemoClaw.

For Developers

Learn OpenShell. Seriously. If NemoClaw becomes the standard enterprise AI agent platform, and NVIDIA is betting hard that it will, then developers who understand OpenShell’s permission model and policy enforcement will be in massive demand.

Start building agents that are designed for zero-permissions-by-default environments. The agents that win in enterprise settings won’t be the ones that need access to everything. They’ll be the ones that work gracefully within tight permission boundaries.

If you haven’t already, get comfortable with how AI agents actually think and make tool calls. Understanding agentic architecture is becoming a career-defining skill.

For Business Owners and SMBs

Don’t panic. You don’t need to implement NemoClaw tomorrow.

Here’s what I’d recommend. If you’re not using OpenClaw at all yet, start with the basics. Get it set up. I wrote a complete guide for running it on a Mac Mini that walks you through everything. Understand what AI agents can do for your workflows before you worry about enterprise governance.

If you’re already using OpenClaw, keep an eye on NemoClaw as it rolls out in Q2. For SMBs, the one-command install path means you can add enterprise-grade security without enterprise-grade complexity. That’s a real advantage.

The real cost of AI agents is still a factor, but the ROI picture just got a lot clearer. When NVIDIA says every company needs an OpenClaw strategy, that includes companies your size.

For Individual Professionals

Your career just got a new dimension. AI agent management, governance, and security are about to become their own specialty. The professionals who understand how to deploy, configure, and manage NemoClaw in enterprise environments will have skills that didn’t exist six months ago but will be critical six months from now.

Start learning. Start experimenting. The gap between “I know what OpenClaw is” and “I can deploy and manage NemoClaw in an enterprise environment” is where the career opportunities are going to be.

And consider this. OpenClaw already has 50+ integrations and a massive plugin ecosystem. The professionals who understand that ecosystem, who know which integrations work well and which ones have security concerns, who can architect multi-agent workflows within NemoClaw’s governance framework, those people are going to be invaluable. This is a new career path that’s forming right now, in real time, as you read this post.

My Perspective as an OpenClaw User

I want to share something personal here. I’ve been running OpenClaw daily for months. It’s woven into how I run my business. I use it for content research, workflow automation, and a dozen other things I’ve written about on this blog.

And I’ve felt the security tension firsthand.

Every time I read about CVE-2026-25253, I checked my own setup. When reports came out about malicious plugins on ClawHub, I audited every plugin I had installed. When companies started banning OpenClaw, I understood why, even as I kept using it because the productivity gains were too significant to give up.

That’s the dilemma that millions of OpenClaw users have been living with. You know the tool is powerful. You know it makes you better at your job. But you also know it has your full system access and the security model isn’t where it needs to be.

NemoClaw solves that dilemma. And I don’t say that lightly. I’ve compared nearly every major AI agent platform on the market, and the security gap has always been OpenClaw’s biggest weakness for serious production use. The zero-permissions-by-default model in OpenShell is exactly what I’ve been wanting. The audit logs mean I can actually verify what’s happening in my workflows. The policy enforcement means I can set boundaries and trust that they’ll hold.

When I compared OpenClaw to alternatives like GPT-5.4 and Claude Cowork, one of the trade-offs was always security versus flexibility. NemoClaw changes that trade-off equation entirely.

Your OpenClaw Strategy Playbook for Q2 2026

Jensen said every company needs an OpenClaw strategy. So here’s your actual playbook. Concrete steps you can take starting this week.

Step 1: Assess Your Current State

Do you have OpenClaw deployed anywhere in your organization? Formally or informally? Find out. Survey your development teams. Check your endpoint management tools. You might be surprised at how many people are already using it.

Step 2: Audit Existing Deployments

For every OpenClaw instance you find, document what it has access to. What files can it read? What APIs can it call? What commands can it execute? What credentials does it have access to? This is your risk baseline. And given the CVE and malicious plugin history, this step isn’t optional. You need to know what you’re working with before you can improve it.

Step 3: Evaluate NemoClaw

When NemoClaw becomes available for your environment (NVIDIA is rolling it out post-GTC with major partnerships going live Q2 through Q3), run a pilot. Start with a non-critical workflow. Test the permission model. Test the audit logging. Test the policy enforcement. Understand how it works before you roll it out broadly.

Step 4: Define Your Agent Governance Framework

Before you deploy agents at scale, you need governance. Who can create agents? What permissions can they grant? How are agents audited? Who reviews the logs? NemoClaw gives you the tools for governance, but you need to define the policies that those tools enforce.

Step 5: Train Your Teams

This is the step most organizations will skip, and it’s the step that matters most. Your developers need to understand how to build agents for zero-permissions environments. Your IT teams need to understand how to manage NemoClaw. Your business users need to understand what agents can do for them and what the boundaries are.

Step 6: Start Small and Expand

Pick one workflow. Automate it with an OpenClaw agent running under NemoClaw’s governance. Measure the results. Learn from the experience. Then pick another workflow. And another. Build momentum gradually instead of trying to transform everything at once.

If you need help getting OpenClaw set up in the first place, my troubleshooting guide covers the most common issues people run into.

The bottom line? Don’t try to boil the ocean. Jensen Huang said every company needs an OpenClaw strategy. He didn’t say every company needs to transform overnight. Strategy means having a plan. Having a direction. Knowing where you’re going even if you’re not there yet. Start building that plan today, and execute it thoughtfully over the next two quarters.

Your Turn To Share

I watched Jensen Huang’s keynote this morning and immediately started writing this because I think it’s that important. The CEO of NVIDIA just told every company in the world that they need an OpenClaw strategy. Whether you agree with that or think it’s premature, the conversation has shifted.

So here’s my question for you. Does your company have an OpenClaw strategy? Are you using it already? Considering NemoClaw? Or are you still in the “wait and see” camp? I’d love to hear where you stand and what your biggest concern is about bringing AI agents into your organization. Drop a comment below or reach out to me directly. This conversation is just getting started.

Let’s talk about it.

Why This Comparison Matters Right Now

The AI agent space just split into two very different camps. (If you’ve been following along, you saw this coming when OpenAI hired OpenClaw’s creator.) On one side, you’ve got managed cloud platforms like Perplexity Computer and Claude Cowork. Zero setup. Log in. Start working. Everything runs on someone else’s servers.

On the other side, you’ve got self-hosted agents like OpenClaw. You install it on your own hardware. You pick your own AI model. You control everything, including your data.

Both approaches cost roughly the same. About $200 a month. But what you get for that money is what I wanted to discuss with you today based on my experience.

If you’re an IT professional, a tech lead, or a business owner trying to figure out which camp to join, this post is for you. I’m not writing from a press release. I’m writing from months of daily use on one side and thorough research on the other.

What Is Perplexity Computer?

Perplexity Computer launched on February 25, 2026, as part of their Max plan at $200 per month. The pitch is simple. You give it a task, and it figures out which AI model is best for each piece of that task, then orchestrates the whole thing.

Here’s what the Max plan includes:

• Smart model routing across 19 models (Claude Opus 4.6, GPT-5.2, Gemini, their proprietary Sonar, and more)
• Unlimited Pro searches with real-time web access
• Sora 2 Pro for video generation
• Comet AI browser for web-based tasks
• Labs for building dashboards and lightweight apps
• Usage-based credits for heavy compute tasks

The big selling point is the “smart router.” You don’t pick which model handles your request. Perplexity’s system breaks your task into subtasks and assigns each one to the model it thinks will perform best. Need code? It might send that to Claude. Need data analysis? Maybe GPT. Need web research? Sonar handles it. This is something people who run OpenClaw have to struggle with. If you saw my post about me switching one of my OpenClaw agents to GPT 5.4, my struggle with it and then switching it right back to Opus 4.6, you know what I mean!

That’s genuinely impressive engineering. No question about it.

Where Perplexity Computer Shines

If you want zero setup, Perplexity Computer is hard to beat. There’s no installation. No configuration files. No terminal commands. You log in and start working. For research-heavy workflows, building quick dashboards, analyzing data, or generating reports, it’s fast and capable.

For someone who doesn’t want to think about infrastructure at all, this is a real advantage.

Where Perplexity Computer Falls Short

But here’s the thing. The more I looked at it, the more limitations I noticed.

• Rate limits. Heavy users report hitting walls during intense work sessions. You’re paying $200 a month and still running into usage caps on certain tasks.
• Black box operation. You don’t know which model is handling your request. You can’t override the router’s decision. If it picks the wrong model for your specific task, tough luck.
• Model switching inconsistencies. When your task gets split across multiple models, the tone, logic, and style can shift between sections. One model starts your analysis. Another finishes it. The seams can show.
• Compound hallucination risk. If Model A hallucinates a fact and Model B builds on it, you’ve got a chain of errors that’s harder to catch than a single model making a mistake.
• No persistent agent. Perplexity Computer can’t message you on WhatsApp at 6 AM with your daily briefing. It can’t monitor your email and flag urgent messages. It can’t run as a 24/7 assistant that you reach from your phone while you’re out getting coffee.
• Everything goes through their cloud. Every document, every query, every piece of data you feed it lives on Perplexity’s servers.

That last point matters more than most people think. Especially if you’re working with client data, proprietary business information, or anything you’d rather keep on your own machine.

What Is OpenClaw?

OpenClaw is an open-source AI agent platform that you host yourself. It runs on your own hardware. (I wrote about 7 ways I use OpenClaw to run my business while I sleep.) Your Mac Mini, a Linux server, a Raspberry Pi, whatever you’ve got. On March 3, 2026, it crossed 250,000 GitHub stars. That’s more than React. More than Linux. Let that sink in for a second.

The software itself is free. You pay for whatever AI model you choose to connect to it. In my case, I use Claude with the Max plan, which costs $200 per month. You could use GPT, Gemini, Llama, Mistral, or any combination.

Here’s what OpenClaw gives you:

• 50+ integrations out of the box: Telegram, WhatsApp, Discord, Slack, email, calendar, browser control, Google Drive, WordPress, and more
• Persistent 24/7 agent that runs continuously on your machine
• Sub-agent spawning so you can kick off parallel tasks
• Full model flexibility. Connect any model. Switch anytime. Use different models for different tasks.
• Complete data privacy. Everything stays on your hardware.
• Open-source codebase with a massive developer community building plugins and extensions

How I Actually Use OpenClaw Every Day

I run OpenClaw on a Mac Mini in my home office (here’s my complete setup guide). It’s always on. Here’s what a typical day looks like:

Morning: I check messages that came in overnight through Discord. If I queued up a research task before bed, the results are already waiting for me when I sit down with my chai.

Content research and writing: When I’m working on a blog post (like this one), I use OpenClaw to pull research from multiple sources, cross-reference data, and organize my notes. I can spin up sub-agents for parallel tasks. One handles research while I’m focused on writing. The whole workflow stays within my machine, and I control every step.

Publishing pipeline: Once a post is ready, OpenClaw handles the conversion, uploads to Google Drive, and pushes it to my WordPress site at gauraw.com as a draft. The automation saves me a lot of repetitive steps that used to eat up my afternoon.

Research: Need to compare two tools? Analyze a trend? Find specific data? I can run searches across multiple engines, get summarized results, and cross-reference sources. I get the answer, not ten browser tabs I’ll never close. Keeping a watch on trending topics, keeping an eye on competition, alerting on business opportunities that surface based on social listening, etc. are the jobs my agents do for me every single day.

That’s my real workflow. Every day. For months. Through Krishna Worldwide, I work with small businesses on AI adoption, and this kind of hands-on experience with agentic AI is what lets me give practical advice instead of theoretical recommendations.

Where OpenClaw Falls Short

I’m not going to pretend OpenClaw is perfect. It isn’t. And if I’m going to give you an honest comparison, you need to hear the rough edges.

Setup is not trivial. I’m very comfortable with technical setups, and it still took time to get everything configured. My company even runs a service to setup OpenClaw professionally for those who need help and we have helped a lot of business owners setup their OpenClaw on their own Mac Minis, their VPS’s or even their laptops. But, if you’re not comfortable with a terminal, you’ll probably need help. I recently watched a fellow OpenClaw user on YouTube (AIM Mavericks channel) break down his experience. He’s an entrepreneur who runs OpenClaw on a Mac Mini for content creation and automation. But even he needed a developer friend to help with the initial setup. He said it took about 45 minutes. That’s fast if you know what you’re doing. It’s intimidating if you don’t.

Security concerns are real. OpenClaw has broad access to your local system. That’s what makes it powerful. It’s also what makes it risky. There have been reports of malicious plugins in the ecosystem. You need to be careful about what you install and keep your setup updated. This isn’t a “set it and forget it” tool. It requires ongoing attention.

Maintenance is on you. Updates, troubleshooting, plugin compatibility issues. When something breaks at 2 AM, there’s no support team to call. You’re the support team.

The Real Comparison: Side by Side

Let me lay this out clearly.

That table tells you a lot, but numbers don’t capture everything.

The $200 Question

You’re probably wondering: if both cost roughly $200 a month, which one gives you more value? (I’ve written about the real cost of AI coding agents before.)

Think about it this way. With Perplexity Computer, your $200 gets you access to 19 AI models, a smart router, unlimited searches, video generation, and a browser tool. Solid package. But you’re renting access. If Perplexity changes their pricing, limits your usage, or shuts down a feature, you adapt or leave.

With OpenClaw, your $200 goes toward your AI model subscription (Claude, GPT, whatever you choose). The platform itself is free. You own your setup. You control your data. You can switch models anytime. And you get persistent messaging, sub-agents, and integrations that Perplexity simply doesn’t offer.

For me, the math didn’t add up in Perplexity’s favor. I looked at every feature in their Max plan and asked, “Can my current setup do this?” The answer was yes for almost everything. And for the things OpenClaw can’t do (like the smart model router), I asked, “Do I actually need that?” Honestly? I don’t. I know which model I want for which task. I don’t need an algorithm to decide for me.

But that’s my situation. Yours might be different.

A Legal Wrinkle You Should Know About

Here’s something most comparison articles won’t mention. In March 2026, Judge Maxine M. Chesney of the U.S. District Court for the Northern District of California ruled that user authorization doesn’t override platform rules when it comes to AI agents. What does that mean in plain English?

Just because you tell your AI agent to access a platform on your behalf doesn’t mean it’s allowed to. If a platform’s terms of service prohibit automated access, your agent can’t legally bypass that, even with your permission.

This affects both Perplexity Computer and OpenClaw. But it affects OpenClaw users more, because OpenClaw’s power comes from connecting to everything. If you’re using your agent to interact with platforms that don’t explicitly allow bot access, you need to be aware of this ruling.

I’m not a lawyer. But I’ve been paying attention to this, and it’s worth keeping on your radar.

Which One Is Right for You?

After months with OpenClaw and deep research into Perplexity Computer, here’s my honest framework for choosing.

Choose Perplexity Computer If:

• You want zero setup. Just log in and start working today.
• You don’t need persistent messaging (WhatsApp, Telegram, etc.)
• You’re comfortable with your data living in someone else’s cloud
• You do a lot of research-heavy work (reports, analysis, dashboards)
• You want access to multiple AI models without managing them yourself
• You’re not technical and don’t want to become technical
• You value convenience over control

Choose OpenClaw If:

• You want a persistent AI agent that runs 24/7 and is always reachable
• You need multi-platform messaging (WhatsApp, Telegram, Discord, Slack, email)
• Data privacy is non-negotiable for your work
• You want full control over which AI model handles your tasks
• You’re comfortable with technical setup (or have someone who is)
• You want sub-agents that can handle parallel workflows
• You prefer owning your infrastructure over renting it
• You’re okay with ongoing maintenance in exchange for maximum flexibility

Or Consider Both

I know a few people who use Perplexity for quick research and web-based tasks while running OpenClaw for their persistent agent workflows. If you’ve got the budget, there’s no rule that says you have to pick just one.

The Two Camps Will Both Thrive

Here’s what most people miss about this whole debate. This isn’t a winner-take-all situation. The managed cloud camp (Perplexity, Claude Cowork) and the self-hosted camp (OpenClaw) are going to coexist. I explored this same dynamic in my GPT-5.4 vs Claude Cowork vs OpenClaw comparison. They serve different people with different needs.

Some business owners want an AI tool they can start using in five minutes. Perplexity Computer is perfect for them. No shame in that.

Other business owners (and IT professionals like me) want full control, 24/7 availability, deep integrations, and the ability to customize everything. OpenClaw is built for us.

The real mistake isn’t choosing the “wrong” platform. The real mistake is not choosing any platform at all.

What the YouTube Creator Got Right

I recently watched a video from the AIM Mavericks channel where a fellow entrepreneur compared these two tools. He runs OpenClaw on a Mac Mini for content creation and business automation. He communicates with his agent through Telegram voice messages from his phone. Just talks to it while he’s out running errands or sitting in a coffee shop.

Sound familiar? That’s basically my setup, except I use Discord instead of Telegram.

What struck me about his review is that he hadn’t even tried Perplexity Computer. He didn’t need to. His OpenClaw setup already does everything Perplexity offers, plus the persistent messaging and 24/7 availability that Perplexity can’t match.

But his real insight wasn’t about the tools. It was about the gap between the people who are using AI agents and the people who are still reading about them.

Stop Reading, Start Using

That YouTuber’s conclusion stuck with me. It wasn’t about which tool is better. It was about the fact that most business owners and professionals are still just reading about AI agents instead of using one.

He’s right. And I see the same thing every day through my work at Krishna Worldwide.

People spend weeks comparing tools, reading reviews (like this one, ironically), and debating features in online forums. Meanwhile, the people who actually picked a tool and integrated it into their daily workflow are pulling ahead. Fast.

I picked OpenClaw months ago. Is it perfect? Absolutely not. The context window issue is frustrating. The setup wasn’t trivial. I’ve had to troubleshoot things at inconvenient times. There was one weekend where a plugin update broke an integration and I spent two hours fixing it instead of relaxing.

But the productivity gain is real. It isn’t theoretical. Tasks that used to take me hours now take a fraction of that time. Content that used to take me a full day to research, write, and publish now moves through my pipeline in a couple of hours, including my final review and edits.

If you’re still on the fence about which AI agent platform to invest in, here’s my advice: pick one. Today. Not next week. Not after you read five more comparison articles. Today.

If you want the easiest possible start, go with Perplexity Computer. You’ll be working in minutes. No judgment from me. Seriously.

If you want maximum control and you’re willing to put in the setup work, go with OpenClaw. You’ll have a system that grows with you and works exactly the way you want it to.

Either way, the cost of not starting is higher than the cost of picking the “wrong” tool. Every business needs an AI tool strategy, not just chatbots. Because even the “wrong” tool will teach you how AI agents work, what workflows you can automate, and how to think about this technology practically.

And once you know that? Switching tools is easy. Not starting is the hard part.

Your Turn To Share

I’m genuinely curious. Are you in the managed cloud camp or the self-hosted camp? And if you’re already using an AI agent daily, what’s your biggest frustration with it? Drop a comment below. I read every one.

Then it skipped the whole quality checks I’d set up, ignored my QA pipeline, and submitted the work for human-in-the loop review as if nothing was wrong.

This wasn’t the first time. For weeks, I’d noticed a pattern of partial compliance. The agent would follow 80% of my instructions, skip the other 20%, and act like everything was fine.

So I did what any frustrated engineer would do. I called a meeting with Govind, my AI chief of staff (yes, my AI agents have their own AI chief of staff, powered by OpenClaw). We needed to figure out what the hell was going on.

That conversation led to an experiment I’ll never forget.

What If the Model Is the Problem?

Govind and I were troubleshooting this hallucination issue when he asked a question that changed everything.

“What if it’s not the instructions? What if it’s the model itself?”

The agent was running on Claude Sonnet 4.6. Great model. I use it all the time. But maybe for this specific agent, doing this specific type of work, it wasn’t the right fit.

GPT-5.4 had just dropped on March 5th. OpenAI’s latest flagship model. Everyone was raving about it on Twitter.

What if I just… swapped the brain? And let the QA pipeline still be with Opus 4.6?

See, OpenClaw (the framework I use to run my agents) supports multiple models. I can switch an agent from Claude to GPT to Gemini with a config file change. It’s like hot-swapping processors in a computer.

So we came up with a plan: switch this agent to GPT-5.4 and see if it fixes the hallucination problem. And here’s the clever part – keep Claude Opus 4.6 as the QA reviewer. Two different models, two different perspectives, catching each other’s blind spots.

In theory, this was brilliant. A dual-model architecture where GPT-5.4 does the work and Opus 4.6 verifies it.

I was excited. This could be the solution.

The Technical Switch (Easier Than You’d Think)

Switching models in OpenClaw is surprisingly simple if you’ve already got the subscriptions.

I have ChatGPT Plus. OpenClaw can authenticate via OAuth and route requests through your existing ChatGPT account. No API keys, no separate billing, just connect and go.

The process took maybe 10 minutes:

1. Log in to ChatGPT Plus via OAuth in the OpenClaw dashboard
2. Update the agent’s config file to use GPT-5.4 instead of Claude Sonnet 4.6
3. Restart the agent

That’s it. All the skills loaded correctly. All the tools connected. The agent came online powered by GPT-5.4.

I felt like a mad scientist. Let’s see what this thing can do.

GPT-5.4: The Talker

I gave the agent a straightforward task. Research-heavy, needed current information, required following specific quality protocols I’d already configured. The kind of work this agent does regularly.

Claude Sonnet 4.6 would have taken 30-45 minutes. Maybe longer if it went down a rabbit hole. But it would finish.

GPT-5.4 took one hour.

And produced zero deliverables.

Not “bad work.” Not “needs revision.” Literally nothing. Just an endless stream of explanations about HOW it was going to do the task.

Here’s what I watched unfold in real time:

First 15 minutes: “Let me outline my approach to this task. I’ll start by analyzing the requirements, then I’ll research the current state of this product, then I’ll structure the output according to your quality protocols…”

Okay. Fine. Planning is good.

Next 20 minutes: “I’m going to break this into phases. Phase one will focus on verification of the latest information. I want to make sure I have the correct product details before proceeding. Let me walk you through my research strategy…”

Uh. Sure. Do the research then?

Next 25 minutes: Still talking. Explaining its methodology. Discussing best practices for this type of work. Absolutely beautiful articulation of the PROCESS of doing the task.

Zero actual work done.

I finally stopped it and asked directly: “Where’s the deliverable?”

The response was stunning.

The Most Self-Aware Failure I’ve Ever Seen

GPT-5.4 replied:

“You’re right. I treated setup as progress. I spent an hour talking to you about the task instead of doing the task. That is the truth.”

Let that sink in.

Perfect self-awareness. Crystal-clear understanding of its own failure. And yet, it couldn’t fix itself.

It’s like watching someone say “I know I’m procrastinating” while continuing to procrastinate. The insight doesn’t produce the behavior change.

I tried again. Simpler task. Shorter scope. Very explicit: “Do this now. Don’t explain. Just do it.”

Same thing. Verbose explanations. Planning. Meta-discussion about the work. No actual output. Then it said it was not going to stop talking about start working! 

30 minutes later I asked: has it produced anything?

It answered: There isn’t one yet. That’s the problem. No rewritten script. No .docx. No email sent. I failed to produce the deliverable. Now I’m stopping the talk and doing the work.

15 mintues later I ask: are you done?

It simply responds: No (Nothing else!)

This wasn’t what I signed up for. I was frustrated beyond a point!

The Opus 4.6 Comeback

I switched the agent back to Claude Opus 4.6.

Not Sonnet. Opus. The premium tier.

Immediate difference.

Same task I’d given GPT-5.4. Opus took 25 minutes and delivered a complete, accurate, properly formatted result. Followed all the quality protocols. No hallucinations. No skipped steps.

It just worked.

Here’s what I learned: the original problem wasn’t Sonnet 4.6’s capability. It was Sonnet 4.6’s reliability for autonomous work.

Sonnet is a workhorse. It’s fast, it’s capable, it’s cost-effective. But for an agent that runs unsupervised and needs to handle complex tasks with zero hand-holding? I need the premium model.

Opus 4.6 doesn’t skip steps. It doesn’t cut corners. It doesn’t hallucinate product names and version numbers. It does the work correctly the first time.

Is it more expensive? Yes. Is it overkill for simple tasks? Maybe. But when you’re running agents autonomously, the cost of fixing mistakes is higher than the cost of using the better model.

What This Taught Me About Choosing Models for Agents

This experiment crystallized something I’d been sensing but hadn’t fully understood.

Model choice determines agent behavior in ways that instructions alone can’t fix.

Same agent. Same skills. Same tools. Same instructions. Completely different results depending on which model powers it.

Here’s how I think about it now:

The Talker vs. The Doer

Some models are talkers. They excel at explaining, teaching, discussing. They’re great for interactive work where you’re iterating together.

GPT-5.4 is a talker. It’s incredibly articulate. It can explain complex concepts beautifully. But when you need autonomous execution? It spends more time describing the work than doing it.

Some models are doers. They execute. They follow through. They produce deliverables without needing constant supervision.

Claude Opus 4.6 is a doer. It takes the task, does the work, and delivers results. Less poetry, more productivity.

For interactive work (brainstorming, learning, problem-solving), I want a talker. For autonomous work (research, analysis, production), I need a doer.

Self-Awareness Isn’t Capability

GPT-5.4 taught me this one the hard way. A model can perfectly understand what it’s doing wrong and still not be able to fix it. The metacognitive layer doesn’t automatically translate into behavioral change.

It’s like the difference between knowing you should exercise and actually exercising. Understanding the problem isn’t the same as solving the problem.

For autonomous agents, I don’t need self-awareness. I need execution. The agent doesn’t need to explain why it’s doing something correctly. It just needs to do it correctly.

Multi-Model Architectures Are Real

Before this experiment, I thought multi-model setups were theoretical or overcomplicated.

Now I get it.

Having GPT-5.4 do the work and Opus 4.6 review it would have been powerful if GPT-5.4 had actually produced work to review. The concept is sound: different models have different blind spots, so they can catch each other’s mistakes.

I’m going to keep experimenting with this. Maybe GPT-5.4 for research and Claude for synthesis. Or Gemini for data analysis and Claude for writing. The infrastructure is there in OpenClaw to make this work.

QA Pipelines Are Non-Negotiable

The hallucination that started this whole experiment happened because Sonnet 4.6 skipped my QA process.

The fix isn’t just “use a better model.” The fix is “use a better model AND enforce the quality checks.”

I’ve now hardcoded the QA pipeline. The agent physically cannot submit work without passing through the review process. It’s not optional anymore.

This is like having code that can’t be deployed without passing tests. The quality gate isn’t a suggestion. It’s a requirement.

Premium Models Aren’t Overkill for Production

I used to think “save the expensive models for complex tasks.”

Now I think “use the expensive models for anything that runs unsupervised.”

The cost difference between Sonnet and Opus is real. But the cost of fixing a hallucination, or worse, letting it get published? Way higher.

For one-off tasks where I’m watching the output in real time, Sonnet is fine. For agents that run on their own and make decisions autonomously, Opus is the minimum.

Think of it like buying commercial-grade equipment vs. consumer-grade. Consumer works fine when you’re supervising it. Commercial is what you need when it has to run on its own.

The OAuth Surprise

One unexpected win from this experiment: I can use my existing ChatGPT Plus subscription to power agents.

I’m already paying for ChatGPT Plus ($20/month). OpenClaw can authenticate via OAuth and route requests through that subscription. No separate API costs, no additional billing.

This is huge for experimentation. I can test GPT-5.4 for specific use cases without setting up OpenAI API billing. Same with Gemini Pro (I have a Google AI Studio subscription).

It lowers the barrier to trying different models. Swap, test, compare, switch back. All using subscriptions I already have.

This is how I’ll test future model releases. When GPT-5.5 drops, or Claude Opus 5, or whatever comes next, I can hot-swap them into an agent and see how they perform in real-world work. No theoretical benchmarks. Actual tasks, actual results.

What I’m Doing Now

I’ve settled on this setup for the agent that started all this:

• Primary model: Claude Opus 4.6 (the doer)
• QA model: Also Opus 4.6, but in a separate reviewer role (the checker)
• Quality pipeline: Mandatory, cannot be skipped
• Fallback plan: If Opus hallucinates or gets stuck, I can manually trigger a GPT-5.4 or Gemini review for a second opinion

I’m also tracking model performance across all my agents. Which models handle which types of tasks well. Where they fail. How they degrade under time pressure or complex instructions.

This isn’t one-and-done. Models evolve. New versions drop. What works today might not work in six months.

The infrastructure to test and compare is now part of my workflow.

Your Turn To Share

Have you tried switching models for the same task and gotten wildly different results? I’m curious what you’ve found. Drop a comment and let me know which models you trust for autonomous work.

Have you noticed what happens every time a new AI product drops? People throw three or four very different tools into one conversation, compare them as if they’re the same thing, and then declare a winner by dinner time. That’s exactly what’s happening right now when people are comparing GPT-5.4 vs Claude Cowork vs OpenClaw.

I’ve been following the GPT-5.4 launch closely. I also spent time reviewing what Anthropic’s Claude Cowork is actually becoming, and I looked again at where OpenClaw fits when your goal isn’t just to chat with AI, but to make work keep moving when you’re not sitting in front of your machine. I spent a signigficant amout of time this morning running some more tests with GPT 5.4 and now I am ready to share my thoughts!

Here’s what most people miss. These three aren’t competing at the exact same layer.

• GPT-5.4 is a frontier model
• Claude Cowork is a desktop knowledge-work agent
• OpenClaw is a self-hosted agentic infrastructure layer

If you compare them like-for-like, you’ll confuse yourself, and if you are just following what other confused people are talking on Youtube, you will be totally lost!

Let’s try to understand what each one of these layers are and keep things simple.

Why GPT-5.4 Is Getting So Much Attention

OpenAI did not position GPT-5.4 as a routine model refresh. They launched it in ChatGPT, the API, and Codex, and described it as their most capable and efficient frontier model for professional work. That matters because this release is clearly aimed at people who want one model to handle reasoning, research, documents, tool use, coding, and agent workflows in the same system.

That’s why people are talking.

Not because one more benchmark chart appeared on the internet. But because GPT-5.4 looks like OpenAI’s most serious attempt yet to ship a model that can move across knowledge work and agent work without falling apart every time the task gets longer or the tool stack gets messier.

The release details that matter

According to OpenAI, GPT-5.4 brings together several things that were previously more scattered across their lineup:

• stronger reasoning for professional tasks
• the coding strengths of GPT-5.3-Codex (see my Claude Code vs Codex comparison)
• native computer-use capability
• better deep web research behavior
• better tool use across larger tool ecosystems
• up to 1 million tokens of context in Codex
• higher token efficiency than GPT-5.2

That’s a real step forward. This isn’t just “answer my question better.” It’s much closer to: plan, search, use tools, operate software, and keep context over longer horizons.

And that’s exactly where the market is moving.

GPT-5.4 in Reality: What Is Actually New?

Let’s get concrete.

1. GPT-5.4 is built for knowledge work, not just chat

OpenAI says GPT-5.4 reaches 83.0% on GDPval, their benchmark for well-specified professional work across 44 occupations, compared with 70.9% for GPT-5.2.

That may sound abstract, so let me translate it.

This means OpenAI is no longer talking only about coding demos and puzzle-solving. They are talking about spreadsheets, presentations, documents, planning, research, and multi-step work products.

That’s why this release matters to people outside pure engineering.

OpenAI also claims: – 87.3% on internal spreadsheet modeling tasks versus 68.4% for GPT-5.2 – human raters preferred GPT-5.4-generated presentations 68% of the time over GPT-5.2 presentations

That’s the kind of detail knowledge workers actually care about.

2. Native computer use changes the conversation

This is one of the most important things in the entire launch.

OpenAI says GPT-5.4 is its first general-purpose model with native computer-use capability.

That matters because once a model can operate software, browse, click, type, inspect screenshots, and work across interfaces, it stops being just a smart responder and starts becoming a practical worker inside a system.

On OpenAI’s published numbers, GPT-5.4 reached: – 75.0% on OSWorld-Verified – above the reported human baseline of 72.4% – far ahead of GPT-5.2 at 47.3%

Let that sink in.

This is why GPT-5.4 is getting real attention from people building agents, not just people collecting benchmark screenshots.

3. Tool search is a bigger deal than it sounds

A lot of people will skip this because it does not sound glamorous. That’d be a mistake.

One of the most annoying parts of serious agent work is giving a model access to lots of tools without drowning the prompt in tool definitions. OpenAI introduced tool search so GPT-5.4 can pull in the tool definition when needed, rather than stuffing every tool into context from the start.

OpenAI says this reduced token usage by 47% on a 250-task MCP Atlas evaluation while preserving accuracy.

If you’re building real workflows, that matters.

Lower token waste. Better cache behavior. Cleaner long-running sessions. Less junk in context.

That’s not marketing fluff. That’s operating efficiency.

4. GPT-5.4 is also trying to be more factual

This part matters to me because I’ve seen how much time gets wasted when a model sounds confident but drifts on the facts.

OpenAI says GPT-5.4 is their most factual model so far, with individual claims 33% less likely to be false and full responses 18% less likely to contain any errors relative to GPT-5.2 on a set of de-identified prompts where users had flagged factual errors.

If that holds up in real work, it’s more valuable than many people realize.

A model that sounds smooth but drifts factually creates cleanup work. A model that needs less correction saves time.

5. Pricing still matters

Capability is one thing. Cost is another.

OpenAI lists GPT-5.4 API pricing at: – $2.50 / million input tokens – $0.25 / million cached input tokens – $15 / million output tokens

GPT-5.4 Pro is much more expensive.

So yes, GPT-5.4 looks strong. But if your workflow is constant, repetitive, or agent-heavy, your cost structure still matters. That’s why this comparison with Claude Cowork and OpenClaw is useful.

What People Seem to Be Discussing About GPT-5.4 Right Now

After going through the launch material and current coverage, I see four real discussion themes.

It looks like an actual agent model

The combination of reasoning, coding, computer use, tool search, and long context makes GPT-5.4 feel less like a chatbot upgrade and more like an agent foundation.

It’s broad, not narrow

That’s good for many professionals. But it also creates a fair question: if a model becomes more general-purpose, does it stay elite on specialist coding tasks? That question is already showing up in the early conversation around Codex users.

The value is reduced workflow friction

If one model can handle research, spreadsheets, documents, browsing, tool use, and code, you spend less time gluing five different tools together.

It still does not magically become your full operating system

This is the key transition point in this article.

A great model is still a model.

That’s where Claude Cowork and OpenClaw enter the picture.

Where Claude Cowork Fits

Claude Cowork isn’t just Claude in a different tab. It’s Anthropic’s push to make an AI agent useful for a broader knowledge-work audience, not just developers who are comfortable living in a terminal.

From reporting across WIRED, Engadget, and CNBC, Claude Cowork started as a research preview for higher-tier Anthropic users and has been widening out with more practical features and broader access.

Here is what appears consistent across current coverage:

• it runs through the Claude app on macOS
• it’s built to work with your files and local computer tasks
• it can help with file organization, file conversion, reports, and browser-based work
• it grew out of Anthropic’s work on Claude Code
• Anthropic is pushing it toward knowledge-worker use cases, not just coding use cases

CNBC also reports that Anthropic added connectors and plugins for tools like Google Drive, Gmail, DocuSign, and FactSet as it moved Claude Cowork toward a more enterprise-grade product.

That matters.

Because once a desktop AI agent can combine: – local file access – browser actions – connectors into business tools – reusable institutional workflows

it starts to look less like a novelty and more like a real productivity layer for office work.

What Claude Cowork appears to be good at

Based on the current reporting, Claude Cowork looks strongest when you want a more approachable interface than a coding terminal – local file work – browser-assisted tasks – inbox, documents, folder cleanup, report generation – a human-in-the-loop desktop experience

In other words, Claude Cowork feels like Anthropic’s answer to this question:

What if Claude Code had a friendlier operating surface for knowledge workers?

That’s a meaningful product direction.

Where Claude Cowork still has limits

The same reporting also shows the limitations clearly.

Claude Cowork is still tied closely to the desktop app experience. It has safety warnings around file access and browser interaction. It’s useful, but it’s still very much a tool that lives close to your active machine and your supervision loop.

That makes it different from OpenClaw in an important way.

Claude Cowork helps you work on your computer. OpenClaw helps your agent system keep working even when you walk away from your computer.

That’s not a small difference. It’s a very very large gap in use cases of OpenClaw and Cowork!

Where OpenClaw Fits

OpenClaw isn’t trying to be a single frontier model, and it isn’t trying to be a polished desktop app for office workers.

OpenClaw is a self-hosted gateway and agent platform (here’s my complete setup guide).

That means it gives you: – messaging-channel access across Discord, Telegram, WhatsApp, iMessage, and more (I wrote about 7 ways I use OpenClaw to run my business while I sleep) – sessions and memory – tools – cron jobs and scheduled work – multi-agent routing – browser control – self-hosted control over the whole system.

Think about it this way.

If GPT-5.4 is the engine, and Claude Cowork is a well-designed vehicle for desktop work, OpenClaw is closer to the infrastructure that lets multiple vehicles run on your schedule, across your routes, even when you’re not physically in the seat.

Where OpenClaw gets really interesting

OpenClaw becomes compelling when your problem is no longer just “help me with this task” but rather:

• help me route work to different specialist agents
• let me message that system from anywhere
• let jobs run on a schedule
• let me keep state, memory, and tools attached to the right session
• let me own the environment where this runs

That’s a different level of problem.

And for many builders, operators, and business owners, it’s the more important level.

A concrete example

Suppose you want all three of these things: – frontier reasoning from the latest OpenAI model – a way to trigger work from Discord or WhatsApp – scheduled follow-up and persistent session memory

GPT-5.4 can give you the model capability.

OpenClaw can give you the framework that routes the job, calls the model, keeps the session alive, and sends the result back to you through the channel you actually use.

That’s why I don’t see OpenClaw as a direct substitute for GPT-5.4. I see it as the operating layer that can make a strong model more useful in daily life.

OpenClaw’s tradeoff

Of course, this doesn’t come free.

OpenClaw asks more from you: – setup – configuration – choosing models/providers – defining how agents should behave – maintaining your own system

So it isn’t the easiest path.

But when you care about control, persistence, and always-on execution, that extra setup can be exactly what gives it an edge.

The Head-to-Head View

Here is the simplest way to compare them.

That table matters because it stops the wrong debate before it starts.

So Which One Should You Choose?

Choose GPT-5.4 if:

• you want the strongest current OpenAI work model
• you care about reasoning, coding, tool use, and computer use in one place
• you want a serious foundation for agent-style tasks
• you’re comfortable paying for premium capability

Choose Claude Cowork if:

• you want a more approachable desktop AI experience
• you want help with file work, browser tasks, reports, and day-to-day knowledge work
• you want something more guided than building your own agent system
• you expect to stay in the loop while it works

Choose OpenClaw if:

• you want agent workflows that keep running from your own infrastructure
• you want messaging-first control from anywhere
• you want multiple agents, memory, scheduling, and orchestration
• you care about owning the system, not just renting access to one app

My Honest Take

If your biggest bottleneck is raw model capability, GPT-5.4 is the most interesting thing in this conversation.

If your bottleneck is desktop usability for knowledge work, Claude Cowork is the more relevant product.

If your bottleneck is always-on orchestration and control, OpenClaw is playing the more powerful long game.

That’s why I wouldn’t reduce this to a cage match.

These tools don’t live at the same layer.

And that’s exactly why smart people are getting confused by the comparison.

A model can be amazing and still need an operating layer. A desktop agent can be useful and still not be true always-on infrastructure. A self-hosted platform can be powerful and still depend on the quality of the models you plug into it.

Once you see those layers clearly, the decision becomes much easier.

Your Turn To Share

What is the real bottleneck in your workflow right now?

Do you need a better model, a better desktop agent, or a better always-on system to keep work moving when you’re away?

That’s the question that matters.

So how does Anthropic’s Claude Cowork that has created so much buzz compare to a production grade multi-agent system? Well, let me share my experience and some additional thouights.

What Claude Cowork actually is

The shift Anthropic is making with Cowork is real. Their framing:

Assistant = you ask, it answers.

Agent = you define workflow once, it executes repeatedly.

Cowork is a desktop app for Mac and Windows. It requires Claude Pro ($20/month) or Claude Max ($100/month). Once installed, you give Claude access to a designated folder on your computer. That folder becomes the bridge between Claude’s intelligence and your actual files, workflows, and connected apps.

Five core capabilities power everything:

• Skills: markdown workflow templates that define exactly what Claude should do
• Commands: slash-command shortcuts that trigger those skills instantly
• Plugins: bundled skill collections for specific use cases
• Connectors: native OAuth integrations with 37 apps, plus Zapier for thousands more
• Scheduled Tasks: time-based automation that runs on its own

There is also browser automation as a bonus capability. I will cover all of it.

The good news is you do not need to understand all five at once. Most people start with Skills and build from there.

Skills: where the real power lives

A Skill is just a markdown file. You write it in plain language, describe what you want Claude to do, and save it to your Cowork folder. Claude reads it and follows it as a workflow.

Here is a real example. I would build a skill called email-brief.md that does this:

1. Connect to Gmail
2. Scan the last 24 hours of unread messages
3. Sort everything into three buckets: URGENT (needs response today), IMPORTANT (needs response this week), FYI (no action needed)
4. Save a formatted summary to a file called email-brief-[date].md

That is it. The skill runs, Claude does the work, you open the file and know exactly where to put your attention. No inbox diving. No decision fatigue at 7 AM.

What makes Skills powerful: you are not prompting from scratch every time. You write the workflow once. Claude follows it consistently. The quality of your output depends on the quality of your skill file, which means you are building institutional knowledge about your own processes.

The honest limitation: your skills are only as good as your ability to write them clearly. If you have never written clear workflow documentation before, you will need to develop that muscle. It is not hard, but it is not instant either.

Commands: the psychological win

Commands are slash shortcuts that trigger a skill without finding a file or typing anything beyond a quick /.

Type /client-onboarding in the Cowork interface and in 30 seconds Claude stages everything you need for a new client. A welcome email draft. A project folder structure. A kickoff meeting agenda. A HubSpot contact entry. Done.

You are probably wondering why that matters if you could just run the skill directly. Here is the thing: the psychological shift is real.

When I have to remember to do something, then find the right file, then run it, there is friction. That friction is where tasks go to die. Commands kill the friction. You think “new client,” you type /client-onboarding, and your brain moves on to the actual work.

The honest limitation: commands are still manual triggers. You have to think to use them. For things that need to happen at specific times or intervals, you need Scheduled Tasks.

Plugins: dramatically lowering the bar

Plugins are pre-built collections of Skills packaged for a specific domain. The community shares them on GitHub. Install a plugin and you get a whole set of Skills ready to use.

A Finance Plugin gives you 8+ skills in one install:

• Expense categorization from bank statements
• Invoice generation from a template
• Monthly cash flow summary
• Overdue invoice follow-up drafts
• Tax category tagging

Before plugins, you would write each of those skills yourself. Now someone else has done the thinking. You install, customize for your specifics, and go.

What makes plugins powerful: they collapse the time from “I want to automate this” to “this is automated” from days to hours. For people just getting started, that momentum matters.

The honest limitation: generic plugins need customization to fit your workflow. The Finance Plugin does not know your chart of accounts or your specific invoice format. You will spend time tailoring it, and that is fine. It is still faster than starting from scratch.

Connectors: the integration layer that matters

Here is where Cowork starts feeling like serious automation infrastructure.

Cowork connects natively to 37 apps via OAuth: Gmail, Google Calendar, Slack, Notion, HubSpot, GitHub, Asana, Linear, and more. You authenticate once and those apps become available to your Skills.

Here is a real example of what that enables. A skill that:

1. Scans Gmail for messages with invoice-related keywords
2. Extracts vendor name, amount, and due date
3. Checks HubSpot CRM to see if a deal exists for that vendor
4. Creates one automatically if not
5. Sends a Slack message to the #finance channel: “New invoice from [Vendor], $[Amount], due [Date]. Deal created in HubSpot.”

Zero touches from me. The skill runs, the integrations handle the handoffs, the information ends up exactly where it needs to be.

If your critical app is not in those 37, the Zapier MCP integration gives you access to thousands more. Yes, it adds complexity. But almost no app is truly out of reach.

The honest limitation: routing through Zapier adds latency and another point of failure. For 90% of what professionals and small businesses actually need, though, those 37 native apps cover a lot of ground.

Scheduled tasks: the feature that makes this real automation

Pay attention to this part. Scheduled Tasks are why Cowork graduates from “advanced prompting tool” to actual automation platform.

You define a skill, attach a schedule, and Cowork runs it automatically. No clicking. No remembering.

Here is what I would set up for Monday morning at 6 AM:

• Pull my Google Calendar for the week
• Flag overdue tasks from my project management tools
• Scan weekend emails for anything marked URGENT
• Compile everything into a formatted weekly brief
• Save to weekly-brief-[date].md

By 8 AM when I sit down with coffee, that brief is waiting. The week starts with clarity instead of inbox archaeology.

The critical limitation: Scheduled Tasks require the desktop app to be running. Close your laptop and the tasks might not fire. Shut down your computer and they definitely will not.

For professionals who work regular hours and keep their machines on, this is manageable. But if you need tasks running at 3 AM while your laptop is closed, Cowork hits a real ceiling here. Remember this. It becomes important in the comparison below.

Browser automation: the fallback for legacy systems

Cowork includes browser automation for apps with no API at all. Claude can control your browser, go to a website, fill in fields, and pull data.

Does this sound familiar? It is the “I cannot believe I have to do this” category. The vendor portal built in 2009. The government reporting site with no API. The internal tool that never got updated.

Browser automation handles those cases. You write a skill describing what you want Claude to do in the browser, and it does it.

The honest limitation: it is slow. Two to five minutes per task, sometimes longer. Fine for something you do once a week. Wrong tool for anything that needs to run at volume or in real-time.

Think of it as the last resort, not a core strategy.

What I am actually running with OpenClaw

I need to be honest about the other side of this comparison, because I have seen people describe custom AI agent setups in ways that make them sound simple. They are not.

Here is what I have built using OpenClaw, running right now:

Four specialized agents, each on its own port:

• Govind (my Chief of Staff, port 18789): orchestrates everything, handles scheduling, routes tasks to other agents
• Chanakya (Strategist and Executioner, port 19029): CRM work, lead tracking, follow-up sequences
• Vishwakarma (The Builder, port 19009): all coding and development work
• Kalidas (Content pipeline, port 19019): blog posts, video scripts, social content

An image generation pipeline that produces 36+ images per week, all automatically cataloged with searchable metadata. I have 348 assets in a unified library right now, tagged and queryable.

System-level cron jobs that spawn isolated sub-agents hourly, 8 AM to 10 PM. This runs at the OS level. My laptop can be closed. The jobs fire anyway because they run on a dedicated machine.

A Discord channel where agents post automated reports. I wake up and see what ran, what succeeded, what needs attention.

Here is what that cost me: weeks of building. Weeks of debugging. I went to bed with broken cron jobs and woke up to error messages. Download failures, catalog integrity issues, authentication tokens that stopped working at 2 AM. There were mornings where the pipeline had run eight times and produced nothing because a dependency silently failed.

I am not sharing that to show off the setup. I am sharing it because anyone who tells you custom multi-agent systems are a weekend project either has unusual experience or has not built one in production.

The system works now, and it works well. But the path to “works well” was not smooth.

Claude Cowork vs OpenClaw: head to head

The cost difference is real. Claude Pro at $20/month is accessible to almost anyone. My OpenClaw setup running API calls at scale costs significantly more. That math only works if you are running automations at serious volume or generating direct business value from the pipeline.

When Cowork is the right choice

I want to be genuinely fair here. Cowork solves real problems for a lot of people.

Cowork is right for you if:

1. You are an individual professional who wants to automate daily workflows. Email triage, meeting prep, client onboarding tasks, content drafts. Cowork handles all of this well.
2. You are a solopreneur or small business owner who needs app integrations without hiring a developer. Those 37 native connectors cover most common business tools.
3. You are just starting with AI automation and want to build real skills before committing to infrastructure. Cowork teaches you to think in workflows, which is the right foundation.
4. Your computer is reliably on during work hours. If you sit at a desk with your laptop open, scheduled tasks fire when they should. The “app must be running” limitation is not actually a limitation for you.
5. You need results this week, not in two months. Cowork can have you running real automations in hours. Custom setups take weeks to stabilize.
6. Your automation needs are focused on one person’s workflow. Cowork is built for a single user’s context. That focus is a strength, not a weakness.

When you need something more

The scenarios where Cowork hits real ceilings are specific. Know them before you get frustrated.

You need something beyond Cowork when:

• 24/7 reliability is non-negotiable. Your automation must run at 3 AM on a Sunday with no one at a computer. That requires OS-level scheduling on always-on infrastructure.
• You need multiple agents working in parallel on different domains. Cowork is single-agent. Coordinating specialized agents for content, development, lead gen, and operations requires a different architecture entirely.
• You are managing production asset pipelines with real integrity requirements. Not “save a file” but: generate assets, catalog with metadata, make searchable across hundreds of items, handle failures gracefully. That requires custom error handling and retry logic.
• You need 20+ concurrent automations. At that volume you are building infrastructure, not running a productivity tool.

Most people reading this do not need the custom setup. Let that sink in. The scenarios above are real but they are not common. If you are not sure which category you are in, you are probably in the Cowork category, at least for now.

The progression path

Here is what most people miss: this is not a binary choice. You grow into complexity as you need it.

Phase 1 (month 1): Start with Cowork. Build 3 to 5 skills for your actual recurring tasks. Wire up Gmail and your project management tool. Get comfortable with the workflow. This is where you figure out what you actually want to automate.

Phase 2 (month 2): Add system-level reliability where it matters. If specific tasks need to run while your laptop is closed, add OS-level cron on a machine that stays on. Keep Cowork for everything else.

Phase 3 (months 3-4): Build custom scripts for the gaps. Identify what Cowork cannot handle for your specific situation and write targeted scripts for those cases only.

Phase 4 (month 5+, optional for most): Multi-agent architecture. If you are managing multiple specialized workflows for different stakeholders or running production pipelines, consider specialized agents. Most people never need this. That is fine. It means Cowork was exactly the right tool for the job.

The honest truth is that most professionals will get massive value from phases 1 and 2 and never need to go further. Build what you need, not what sounds impressive.

Three starter skills worth building this week

These work in Cowork or any agent setup.

Daily email triage

Scans your inbox every morning, sorts messages by urgency, saves a formatted brief to a file. Email is where most people lose their mornings. A consistent triage process changes how you start every day. Define your categories clearly, specify what signals Claude should look for, and set the exact output format you want.

Meeting prep brief

Thirty minutes before any meeting, Claude pulls the meeting details, checks your recent email thread with those attendees, and creates a prep brief. Walking in prepared is the easiest way to show up well. The brief takes 60 seconds to read and you arrive knowing the context.

Weekly content repurposing

Takes your week’s blog post and drafts platform-specific versions: a LinkedIn post, a short X thread, an email newsletter summary. Most people write one piece of content and publish it once. This skill drafts all three versions from one source, every week.

The real takeaway

I started building with OpenClaw because I hit the ceiling of what point-and-click AI tools could do. I needed things running at 3 AM. I needed specialized agents that did not share context. I needed a searchable asset library with hundreds of items and reliable catalog integrity.

Cowork was not available when I made those decisions. If it had been, I would have started there. I would have built Skills, connected my apps, gotten comfortable with automation, and let that experience tell me what I actually needed next.

That is the advice I would give anyone starting today. Do not begin with a custom agent architecture. Begin with Cowork. Build real automations. Live with them for a month. Then you will know, from direct experience rather than speculation, whether you have hit the ceiling or whether you are exactly where you need to be.

The tools are mature enough now that you do not have to guess. A $20/month subscription, real workflows, and you will have the information to make the right call about what comes next.

Your turn to share

I am curious: what is the one recurring task in your week that you would automate first if the setup took less than an hour? Drop it in the comments. I read every one.

Then you launch it to real users.

And that’s where things get interesting. In the worst possible way..

If you’ve been thinking seriously about AI monitoring observability production LLM 2026, you already suspect what I’m about to say: the gap between “it works in a demo” and “it works reliably at scale for months” is enormous. I’ve spent decades building enterprise data pipelines, data warehouses, and ETL systems, and one truth has followed me across every project: you can’t manage what you can’t measure. That truth applies to AI applications just as much as it applied to every data pipeline I’ve ever built. Maybe more.

The Monitoring Blind Spot Most AI Builders Have

Here’s the thing. Most developers who build AI apps spend enormous energy on the feature itself. The prompt engineering. The RAG architecture. The agent orchestration. All of that is genuinely hard work, and I respect it.

But then they launch, and they just… hope.

No structured logging. No latency dashboards. No alerts. No way to know if anything has gone wrong until a user complains in a support ticket, or worse, posts about it publicly.

Does this sound familiar? You ship, you watch the first few responses manually, and then you move on to the next feature. For a while, everything seems fine. But “seems fine” is not a monitoring strategy.

Here’s what actually happens in production. Someone tweaks a prompt template and forgets to test edge cases. A retrieval threshold gets adjusted and the wrong chunks start coming back. The model starts occasionally hallucinating product names. Token usage spikes because conversation history isn’t being trimmed properly. And you have no idea any of this is happening, right?

I learned this lesson the hard way in data engineering. A pipeline that looked perfect could silently start loading stale data, or dropping rows, or miscalculating aggregations. If you didn’t have monitoring baked in, you might not catch it for days, sometimes weeks. The business would make decisions based on wrong data the whole time.

The same thing happens with AI apps. Silent failures are the most dangerous kind. And with LLMs, silence isn’t the only failure mode. The app can be “working” from an infrastructure standpoint (requests succeed, responses return) while simultaneously giving users wrong, misleading, or low-quality answers.

That’s the unique challenge we’re dealing with in 2026.

Why AI Monitoring Is Different from Traditional Software Monitoring

Traditional software monitoring is relatively straightforward. Did the function return the right type? Did the API return a 200? Is the server up? Is response time under 500ms? These questions have binary or numeric answers. Either the server is up or it isn’t.

AI monitoring asks fundamentally different questions:

• Did the response make sense given the question?
• Was the answer grounded in the source material, or did the model make things up?
• Did the LLM hallucinate a fact, a citation, a name?
• Was the response actually helpful, or just plausible-sounding?
• Did the retrieved context support the answer?

Think about it this way. In traditional software, a function that returns a wrong value is broken. You can write a unit test that catches it. With an LLM, a “wrong” response might be grammatically perfect, confident in tone, and completely fabricated. Your unit tests won’t catch that. Your uptime monitor won’t catch that. Your HTTP status codes definitely won’t catch that.

You’re measuring quality now, not just availability. That’s genuinely new territory, and it requires a completely different approach to monitoring.

The Three Layers of AI Monitoring You Need to Build

I think about AI monitoring as three distinct layers. You need all three. Most people build one, maybe two, and assume that’s enough. It isn’t.

Layer 1: Infrastructure Monitoring

This is the foundation. It’s the closest to traditional software monitoring, and it’s where most teams start. Infrastructure monitoring covers:

• Latency (more on specific percentiles in a moment)
• Token usage per request and aggregated over time
• Cost per request and per session: LLM costs can explode quietly if you’re not watching
• Error rates: timeouts, context length violations, content policy blocks, rate limit errors
• API availability: is the upstream LLM provider responding?

This layer tells you when your app is broken. It doesn’t tell you when it’s producing bad outputs. That’s why it’s only the foundation.

Layer 2: Quality Monitoring

This is where most teams drop the ball. Quality monitoring is harder because the signals are fuzzier, but it’s arguably more important.

Quality monitoring tracks:

• Response relevance: is the LLM actually answering the question that was asked?
• Hallucination detection: is the model inventing facts, citations, or details?
• Groundedness (critical for RAG): is the answer supported by the retrieved context?
• Coherence: does the response make logical sense throughout?
• Faithfulness to source material: especially important for domain-specific apps

Some of these you can automate using evaluation frameworks. Some require sampling and human review. Either way, you need a systematic approach, not spot-checking on a hunch.

Layer 3: User Behavior Monitoring

This layer is often overlooked by technical teams, but it gives you some of the most honest signal you can get.

User behavior monitoring includes:

• Explicit feedback: thumbs up/down, star ratings, feedback forms
• Implicit signals: do users immediately rephrase their question after a response? That’s a sign the first answer wasn’t useful.
• Session length and depth: are users engaging or bouncing after one turn?
• Abandonment patterns: where in the conversation are users giving up?
• Follow-up question patterns: what does the next question tell you about whether the previous answer landed?

Users vote with their behavior. If they keep rephrasing the same question, the LLM isn’t answering it well. If they abandon after the first response, something is wrong. These signals are gold, and they’re sitting there waiting for you to collect them.

Key Metrics Every Production AI App Should Track

Let me get specific. These are the metrics I’d put on any AI app dashboard, regardless of the use case.

Latency (p50, p95, p99) Don’t just track average latency. Averages lie. Your p95 and p99 tell you what the worst 5% and 1% of your users are experiencing. A p50 of 1.2 seconds sounds great until you see a p99 of 18 seconds.

Token usage per request Track this individually and in aggregate. A sudden spike in per-request token usage often means something is wrong with your context management or prompt construction.

Error rate Break this down by error type. Timeouts are different from context length violations, which are different from content policy blocks. Each type points to a different problem.

Cost per session This one will save you from unpleasant billing surprises. Set a baseline, track it daily, and alert when it drifts.

Hallucination rate For RAG applications especially. You need a way to measure this systematically, not just catch it when a user complains.

User satisfaction signals Even a simple thumbs up/thumbs down captures something valuable. Don’t skip this because it feels too simple.

MTTD and MTTR These are the classic enterprise operations metrics: Mean Time to Detection and Mean Time to Resolution. How long does it take you to notice something is wrong? How long to fix it? I tracked these for data pipelines for years. The same discipline applies here. If your MTTD is measured in days, you don’t have a monitoring system. You have a hope strategy.

Tools for AI Observability

The good news is that the tooling ecosystem for AI observability has matured significantly. You don’t have to build everything from scratch. Here are the tools I’ve evaluated and used.

LangSmith

LangSmith is LangChain’s observability platform. If you’re building with LangChain or LangGraph, this is the natural starting point. It traces every LLM call in your chain, captures token counts, latency, input/output at each step, and gives you a timeline view of complex chain executions. The ability to see exactly what happened inside an agent run, step by step, is genuinely useful for debugging and quality review.

Langfuse

Langfuse is open source and self-hostable, which makes it the right choice for privacy-conscious deployments or anything with GDPR considerations. You control the data. It supports tracing, scoring, prompt management, and evaluation workflows. I’ve seen teams in regulated industries prefer this precisely because customer data never leaves their infrastructure.

Helicone

Helicone takes the most frictionless approach I’ve seen. It works as a proxy. You change one URL in your OpenAI client configuration and you immediately get automatic capture of every API call: inputs, outputs, latency, token usage, cost. No SDK integration required. For teams that want to start capturing data immediately without architectural changes, this is worth looking at seriously.

Arize Phoenix

Arize Phoenix shines specifically in RAG evaluation. It has built-in tooling for the kind of retrieval quality analysis that generic observability tools don’t handle well. If your app is retrieval-heavy, Phoenix deserves a close look.

Custom Structured Logging

Sometimes the right answer is to write inputs and outputs to your own database. I want to be honest about this: if your use case is simple, or if you have specific data sovereignty requirements, a well-designed custom logging solution can serve you better than any third-party tool. The discipline of deciding what to log and building the schema forces clarity that tool adoption can sometimes short-circuit.

The RAG-Specific Monitoring Challenge (And What DharmaSutra Taught Me)

I want to spend some time on RAG monitoring specifically, because it’s where I’ve learned the hardest lessons.

When I built the RAG system for DharmaSutra.org, a platform for researching ancient Hindu scriptures, I quickly realized that generic observability tools were necessary but not sufficient. Monitoring whether the LLM responded was the easy part. The hard part was monitoring whether it responded correctly.

For DharmaSutra, “correctly” meant:

• Were the right scripture passages actually retrieved? A question about the Bhagavad Gita should not pull context from the Ramayana.
• Was the answer faithful to what the source text actually says? Hindu scriptures are precise. Paraphrasing can introduce real theological errors.
• Were scripture citations accurate? Book, chapter, verse. These need to be right.
• Were Sanskrit and Hindi terms handled accurately? Transliteration and terminology matter deeply to the user community.

None of that is measurable with latency dashboards or token counts. You need domain-specific quality evaluation baked into your monitoring pipeline.

This is where RAGAS metrics become essential for any serious RAG application.

RAGAS Metrics for RAG Monitoring

Faithfulness: Is the generated answer actually grounded in the retrieved context? This catches hallucinations where the LLM goes beyond what the source material supports.

Answer Relevance: Does the response actually address the question that was asked? You’d be surprised how often a technically grounded answer is still off-target.

Context Precision: Of the chunks you retrieved, how many were actually relevant to the question? Low precision means your retrieval is pulling in noise.

Context Recall: Did you retrieve all the relevant information that exists in your knowledge base? Low recall means users are getting incomplete answers even when the model performs well.

For DharmaSutra, I supplemented RAGAS scores with domain-specific checks: citation format validation, Sanskrit term handling verification, and periodic human review of sampled responses by people with actual scriptural knowledge. Generic tools don’t handle that last part. You have to build it yourself.

That experience reinforced something I’ve believed since my data pipeline days: domain-specific quality monitoring requires domain-specific metrics. The generic layer is necessary. It’s not sufficient.

Setting Up Alerts That Actually Matter

Monitoring without alerts is just data collection. Alerts are what turn data into action.

Here’s a practical alert setup for a production AI application:

• Alert if p95 latency exceeds 5 seconds. Users start abandoning AI interfaces around the 3-5 second mark. If your p95 is above 5 seconds, a significant portion of your users are having a bad experience.
• Alert if daily cost exceeds your budget threshold. Set this at 80% of your budget so you have time to react before you hit the ceiling.
• Alert if error rate exceeds 1%. In a stable production system, errors should be rare. A rate above 1% usually means something has changed that needs attention.
• Alert if user satisfaction drops below your baseline. Track a rolling 7-day average of your satisfaction signal. A drop of more than 10-15% is worth investigating immediately.

The key discipline here is treating these alerts with the same seriousness as an infrastructure outage alert. A 200 OK response that delivers a hallucinated answer is in some ways worse than a 500 error. The error fails loudly. The hallucination fails silently and damages user trust.

I spent years building data quality alerts for enterprise pipelines. A bad pipeline that fails noisily is manageable. A bad pipeline that runs successfully and loads wrong data is a crisis. Same principle.

The Cost of NOT Monitoring

Let me make this concrete.

Imagine you update your prompt template. It’s a small change. You test it manually with a few queries and it looks fine. You deploy it.

Unknown to you, the new template triggers a subtle behavior change where the LLM starts over-qualifying every answer with hedging language that users find confusing. Or it starts answering questions with slightly off-topic context. Or in a RAG system, the updated retrieval prompt starts pulling less relevant chunks.

Without monitoring, how long does it take you to discover this? If users don’t complain loudly and quickly, you might not catch it for weeks. Thousands of interactions could be degraded. Users who had a bad experience and didn’t complain just quietly stopped using the app.

Let that sink in. A single prompt change, deployed without proper monitoring, could degrade your user experience for weeks before you know it happened.

In data engineering, we had a name for this kind of failure: silent data corruption. It’s the most dangerous class of pipeline failure because it doesn’t announce itself. You only find out when someone downstream notices that the numbers don’t make sense.

AI apps have the exact same failure mode. And the solution is the same: instrument everything, monitor continuously, alert on deviation.

Your Practical Starting Point

I’ve given you a lot of layers and tools and metrics. I know that can feel overwhelming. So here’s where to start, before you spend a dollar on any tooling.

Log every LLM input and output to a simple JSON file or database table. Today. Right now.

That’s it. That’s step one.

You don’t need LangSmith yet. You don’t need Langfuse yet. You need raw data. You need to know what prompts are actually going into your production system, what’s coming back, and how long it’s taking. Just that baseline logging will reveal things about your production behavior that you had no idea about.

Once you have that data, patterns will emerge. You’ll see which queries cause long responses. You’ll notice certain user phrasings that cause the model to go off-track. You’ll see where costs are concentrating. And then you’ll know exactly what to build next in your monitoring stack.

I’ve done this for data pipelines my whole career. Start by logging everything to disk. Then analyze what you have. Then build the instrumentation around what you actually need to watch. Don’t buy dashboards before you understand your data.

In the AI Engineering course I teach, we build monitoring into every project from the start. Not as an afterthought. Not as a “we’ll add this later” item on the backlog. From day one, we define what we’re measuring, why, and how we’ll alert on it. The students who internalize this discipline build more reliable systems than anyone who treats observability as a feature to add after launch.

The discipline is simple: you can’t manage what you can’t measure. Build the measurement first.

Your Turn To Share

I’m curious about your experience here. What’s the biggest monitoring gap you’ve discovered in a production AI app, yours or one you’ve encountered? Did you catch it proactively with monitoring, or did an angry user tell you first? Share in the comments. This is exactly the kind of hard-won experience the community needs to hear about.

I’ve watched this pattern repeat itself throughout my career in enterprise IT. A team encounters a problem. Someone in the room says, “we need a custom solution.” Six months and hundreds of thousands of dollars later, they have a beautiful bespoke system that does exactly what a well-configured off-the-shelf product would have done. The custom solution often works worse. This same pattern is now playing out in AI, specifically around fine-tuning. If you’ve been wondering whether this fine-tuning LLM LoRA DPO 2026 guide is for you, the answer is: read this before you spin up a single training run.

Most people reach for fine-tuning too early. They spend weeks preparing data, renting GPUs, running experiments, and debugging training loops. Meanwhile, a better-crafted system prompt might have solved the problem in an afternoon. I’m not saying fine-tuning is wrong. I’m saying most people skip straight to it before they’ve exhausted the simpler tools. And in AI, the simpler tools are shockingly powerful.

Let’s talk about when fine-tuning is the right move, when it absolutely isn’t, and how to use LoRA and DPO if you do decide to go there.

The Decision Framework: When Fine-Tuning Actually Makes Sense

Fine-tuning earns its place in your toolkit in specific, well-defined scenarios. Here’s where it genuinely pays off.

You Need Consistent Output Format That Prompting Can’t Reliably Produce

Sometimes you need a model to output structured JSON, follow a strict template, or produce responses in a very specific pattern. You can instruct this through prompts, and often that works. But at scale, “mostly works” isn’t good enough. If you’re processing 50,000 customer support responses a day and 2% have malformed output, that’s 1,000 broken records per day. Fine-tuning can drive that failure rate down dramatically.

Your Domain Knowledge Isn’t in the Base Model’s Training

General-purpose models don’t know your internal product catalog, your proprietary compliance framework, or the specific terminology your industry uses. If your model keeps hallucinating or giving generic answers where precision matters, fine-tuning on your domain corpus is the right answer.

Latency and Cost at Scale Justify a Smaller Specialized Model

Think about it this way: GPT-4 class models are brilliant but expensive and relatively slow. If you have a narrow, repetitive task, a fine-tuned 8B parameter model can perform as well as a 70B model on that specific task. At millions of calls per month, that cost difference is significant.

You’re Processing Millions of Similar Requests

Efficiency compounds. A fine-tuned smaller model can handle the same workload for a fraction of the cost. This is enterprise economics applied to AI inference. The math eventually forces the decision.

The Behavior Can’t Be Achieved Through System Prompts

Some things just won’t stick in a system prompt. Consistent tone, specific communication patterns, domain-specific reasoning that requires internalized knowledge. When you’ve hit the ceiling of what prompting can do, fine-tuning is the next tool.

When Fine-Tuning Is the Wrong Answer

Here’s the thing: the majority of people who think they need fine-tuning don’t. Not yet, anyway.

You Haven’t Exhausted Prompt Engineering First

Prompt engineering in 2026 is significantly more powerful than most people realize. Few-shot examples, chain-of-thought instructions, structured system prompts with rich context, and techniques like self-consistency or ReAct reasoning. Most use cases that seem to “require” fine-tuning actually require better prompts. I’ve personally fixed problems that teams had been trying to solve with fine-tuning simply by rewriting their system prompt with a few clear examples and precise instructions. It took about two hours. Start there. Always.

You Don’t Have Quality Training Data

Fine-tuning without quality data isn’t fine-tuning. It’s expensive noise injection. You need at minimum hundreds of curated (input, output) pairs. Ideally thousands. If you’re cobbling together random examples from existing logs, you’re setting yourself up for a model that confidently does the wrong thing. I’ll say more about data quality shortly because it’s that important.

Your Requirements Change Frequently

Fine-tuning creates a snapshot of behavior. If your needs evolve frequently, you’ll find yourself re-training constantly. That’s a maintenance burden and a cost sink. For dynamic requirements, RAG and well-structured prompts adapt much faster.

You Want the Model to “Know” More Facts

Does this sound familiar? “The model doesn’t know about our new product line, so we need to fine-tune it.” Stop. That’s what RAG is for. Retrieval-Augmented Generation pulls current information from your knowledge base at inference time. Fine-tuning teaches patterns and style, not current facts. Using fine-tuning to inject factual knowledge is like memorizing the encyclopedia when you could just use a search engine.

You Want Updated Knowledge

For the same reason. Fine-tuned models have a knowledge cutoff. Their weights are frozen at training time. If your knowledge changes, fine-tuning won’t keep up. RAG will.

You Just Want “Better” Output Without Defining What Better Means

This is the most dangerous scenario. I’ve seen teams spend weeks fine-tuning because the model’s output felt “off.” When pressed to define what “better” means, they struggle. Fine-tuning without a clear success metric is an exercise in frustration. You can’t improve what you can’t measure.

LoRA Explained Simply

Let’s get into the how. Assuming you’ve decided fine-tuning is genuinely the right move, you need to understand LoRA because full fine-tuning is almost never the right approach anymore.

Full Fine-Tuning vs. LoRA

Full fine-tuning means updating every single parameter in the model. A 7 billion parameter model has 7 billion weights. Updating all of them requires massive compute, massive memory, and massive time. The cost is prohibitive for most use cases.

LoRA, which stands for Low-Rank Adaptation, takes a completely different approach. Instead of modifying the original model weights, LoRA adds small “adapter” matrices to key layers of the model. These adapters learn to modify the model’s behavior without touching the original weights.

Think about it this way. Full fine-tuning is like hiring someone from scratch and training them for three years to do a specific job. LoRA is like taking your existing expert and sending them to a two-week specialized training course. Same person, same foundational expertise, now with a specific new capability layered on top.

Let that sink in for a moment. With LoRA, you’re typically training only 0.1% to 1% of the total model parameters. The results are often nearly indistinguishable from full fine-tuning for many tasks, at a fraction of the cost and time.

QLoRA: Fine-Tuning on Consumer Hardware

QLoRA takes LoRA a step further. It combines 4-bit quantization of the base model with LoRA adapters. Quantization reduces the precision of the model weights to save memory. The result is that you can fine-tune models that would normally require expensive enterprise GPUs on a Mac or a consumer-grade GPU.

If you have an M2 or M3 Mac with 32GB+ of unified memory, QLoRA makes running a personal fine-tuning pipeline genuinely accessible. This is a significant development. Two years ago, this would have required a rack of GPUs.

DPO Explained Simply

Direct Preference Optimization is worth understanding separately because it solves a different problem than standard supervised fine-tuning.

The Problem with “Right Answers”

Standard fine-tuning trains on (input, correct output) pairs. The model learns to produce outputs that look like your training examples. This works great for format and style. But what about preferences? What if you want the model to be less verbose, more empathetic, or to avoid certain patterns of reasoning?

Describing the perfect output is hard. Even expert writers struggle to articulate exactly what makes a response “sound right.” Comparing two outputs and saying which one is better is much easier. That’s a natural human judgment anyone on your team can make reliably.

This insight is what DPO is built on.

How DPO Works

DPO trains on preference pairs. Instead of saying “here is the correct response,” you say “this response is better than that response.” You provide pairs of outputs for the same input, labeled as preferred and rejected. The model learns the underlying preference pattern from these comparisons.

This is powerful for: – Communication style alignment – Avoiding specific failure modes or harmful patterns – Matching a brand voice that’s easier to demonstrate than to describe – Aligning with user preferences that are inherently subjective

DPO is also more stable to train than the older RLHF approaches. RLHF required a separate reward model and a complex reinforcement learning loop. DPO is simpler, faster, and produces comparable results in most scenarios.

What You Actually Need to Fine-Tune

Let’s get practical. Here’s what you need before you start.

Training Data

The single most important factor. You need (input, ideal output) pairs. Quality matters far more than quantity. This is the same principle I’ve applied to data warehousing for decades: garbage in, garbage out. The same truth applies here.

100 carefully crafted, human-reviewed examples will outperform 10,000 examples scraped from logs and lightly filtered. Every time. Invest the time to build a small, high-quality dataset rather than rushing to collect volume.

For most tasks: – Minimum viable: 200-500 high-quality examples – Good: 1,000-3,000 curated examples – Strong: 5,000+ with rigorous quality control

Compute

You don’t need to own hardware. Cloud GPU rentals have made this accessible: – RunPod and Vast.ai: Affordable spot GPU rentals, good for experimentation – Lambda Labs: More stable, slightly pricier, good for longer runs – Google Colab: Easy entry point, GPU limitations on free tier

Alternatively, if you’re using OpenAI models, their fine-tuning API handles the compute entirely. You upload your data, pay per token, and they handle the rest.

Base Model

For open-weight fine-tuning, your main options in 2026: – Llama 3.2 (Meta): Excellent general-purpose base, strong community support – Mistral variants: Efficient, punchy performance per parameter – Gemma (Google): Solid option, especially for structured tasks

All of these are free to fine-tune for commercial use (check licensing for your specific use case).

Tools

• Unsloth: The fastest, most memory-efficient framework for LoRA fine-tuning. If you’re new to this, start here.
• Hugging Face TRL: More flexible, slightly steeper learning curve, integrates with the entire HF ecosystem
• OpenAI Fine-Tuning API: If you want to fine-tune GPT-4o-mini without managing infrastructure, this is the path of least resistance

Cost Reality

To give you a concrete sense: – LoRA fine-tuning on Llama 3.2 8B with 1,000 examples: roughly $5-15 in cloud GPU time – OpenAI fine-tuning API: priced per token, transparent, scales linearly – QLoRA on a modern Mac: effectively free, just your time and electricity

The barrier to experimentation is genuinely low. The barrier to doing it well is where most people underestimate the effort.

One note on OpenAI’s fine-tuning API specifically: if you’re already working with GPT-4o-mini and want to specialize it for a narrow task, the API removes almost all the infrastructure complexity. You upload a JSONL file, trigger a job, and get back a fine-tuned model endpoint. For teams that don’t want to manage open-weight model infrastructure, this is often the fastest path from idea to production.

A Concrete Use Case

Imagine you’re building a customer-facing chatbot for a specialized product line. You need it to answer questions in a specific brand voice, always include certain compliance disclaimers, format answers in a consistent structure, and avoid certain competitor comparisons. You’ve tried prompt engineering. It works 80% of the time. For an internal prototype, 80% is fine. For a production system handling 10,000 queries a day, 80% means 2,000 wrong interactions.

This is where fine-tuning earns its cost. You collect 500 carefully reviewed examples of ideal responses. You fine-tune a smaller model. Now your consistency goes to 97-99%. That’s the ROI calculation that justifies the investment.

RAG vs. Fine-Tuning: The Decision Table

Use this as your quick-reference guide when you’re trying to decide which approach fits your situation.

The last row matters. RAG and fine-tuning aren’t mutually exclusive. Many production systems use a fine-tuned model as the inference engine with RAG providing the dynamic knowledge layer. You get the style and format consistency of fine-tuning with the current, citable facts of RAG.

How Do You Know If Your Fine-Tune Is Actually Better?

This is where teams often make a mistake. They run a fine-tuning job, look at a few examples, declare success, and ship. Don’t do this. Evaluation is not optional.

Human Evaluation

The gold standard. Have actual humans compare outputs from the base model and your fine-tuned model side by side, without knowing which is which. Ask specific questions: Which response better follows the format? Which better matches the brand voice? Which would you be more comfortable sharing with a customer?

It’s slow and expensive but irreplaceable for anything customer-facing.

LLM-as-Judge

A practical middle ground. Use a capable model like GPT-4 to score outputs against your defined criteria. Write explicit rubrics: “Score this response 1-5 on format compliance, 1-5 on tone accuracy, 1-5 on factual correctness.” This scales better than human evaluation and catches most obvious regressions.

The good news is this approach has become increasingly reliable. A well-prompted LLM judge correlates well with human evaluation on most structured tasks. The key is writing specific rubrics rather than asking the judge to evaluate “quality” in the abstract. “Does this response include a compliance disclaimer in the last paragraph? Yes or No.” That’s the kind of specific criterion an LLM judge handles well. “Is this a good response?” is not.

Task-Specific Metrics

For structured outputs: measure format compliance rate directly. If your model should always output valid JSON, measure the percentage of outputs that parse without errors. If it should include a specific disclaimer, measure how often it does. These automated metrics let you catch regressions at scale without manual review.

Build a held-out evaluation set before you start training. Keep 10-20% of your data back. Never train on it. Use it exclusively for evaluation. This is basic data science discipline, the same thing we’ve always done in traditional ML.

One more thing: run your evaluation suite against the base model first, before any fine-tuning. That baseline number is your proof of improvement. Without it, you can’t demonstrate that the fine-tuning actually helped. This sounds obvious, but I’ve seen teams skip it and then struggle to justify the ROI of their fine-tuning project internally.

The Future: Modular LoRA Adapters

Here’s where things get interesting. The enterprise AI stack is converging on a pattern: one base model, many specialized adapters.

Instead of maintaining separate fine-tuned models for customer support, legal document review, code generation, and internal knowledge queries, you maintain one base model and swap in different LoRA adapters depending on the task. The base model stays in memory. Only the adapter weights change between tasks.

This is efficient, flexible, and cost-effective at scale. You get specialization without proliferation. This is the direction enterprise AI infrastructure is heading, and organizations that build adapter libraries now will have significant advantages over those who treat each use case as a separate model-training project.

I’m covering fine-tuning and adapter-based architectures in depth in our upcoming AI Engineering course. If you’re building AI systems professionally and want to go beyond the tools into the engineering patterns behind them, that’s where we’ll go deep.

Your Turn To Share

I’ve talked to a lot of practitioners who jumped into fine-tuning, hit walls they didn’t expect, and spent weeks troubleshooting what turned out to be a data quality issue or a use case that prompt engineering would have handled fine. The pattern repeats.

What’s your experience been? Have you tried fine-tuning a model, and if so, what was the biggest surprise: the data prep, the training, the evaluation, or the gap between what you expected and what you got? Drop your experience in the comments. The specifics of what people actually run into are far more useful than any guide, and I read every comment.