I Don’t Need OpenClaw Anymore

A few weeks ago I wrote about running Claude Code and OpenClaw side by side — two bots, one Telegram, each doing something different. I was genuinely enthusiastic about both. I framed them as complementary tools for different jobs.

I’ve since stopped using OpenClaw almost entirely.

That’s not a knock on OpenClaw. It’s well-built and it’s what got me to where I am. But the thing that made it useful — being a framework for wiring Claude into your life — turned out to be something Claude Code now handles natively. And Claude Code handles it better.

---

What OpenClaw Was For

The appeal of OpenClaw was specific: it gave you a persistent agent with a skill ecosystem. You’d write a YAML config, define your channels (Telegram, iMessage, WhatsApp), install skills, and end up with something that felt like a personal assistant rather than a chatbot you had to open a browser tab to use. Under the hood, it runs a Node.js gateway process — each incoming message triggers a separate Anthropic API call with your conversation history and registered tool definitions.

The value was in the skill library and the persistence. Skills registered tool schemas the model could call — email, calendar, web search, image generation, file access. Persistence meant the agent was always running, always reachable from your phone, not gated behind a terminal session.

That combination worked. I ran it for months. I added skills, broke things, fixed things, pushed into new integrations. By the time I wrote the two-Claudes post, OpenClaw had iMessage via BlueBubbles, email via Himalaya, Apple Reminders, image generation through Gemini, and a growing set of custom skills I’d built or adapted.

And then I looked over at what Claude Code was doing and realized the gap had closed.

---

Claude Code Does the Telegram Thing

The comparison that first made me think was Telegram.

OpenClaw’s Telegram integration was a selling point. You configure the gateway with a bot token, and from then on your phone is a direct line to your agent. That was impressive the first time it worked.

Then Anthropic shipped a native Telegram plugin for Claude Code. It’s an MCP server — Model Context Protocol — that bridges Bot API messages directly into a Claude Code session. The setup took about five minutes:

1. Create a bot via BotFather
2. Install the plugin in a Claude Code session
3. Configure it with your token
4. Pair your Telegram account
5. Done

One Telegram message to a Claude Code session that has full access to my codebase, my file system, my shell, and every tool I’ve configured. I send a message from my couch; it runs commands, edits files, commits code, and reports back.

The OpenClaw Telegram integration was a workaround to get a capable model into a messaging channel. The Claude Code Telegram plugin is the same model, the same context, the same tooling — with a messaging UI in front of it. The workaround became the default.

---

The Skills System Is Just Better

Here’s what I’ve been running Claude Code with:

• Telegram — incoming messages, replies, reactions, file attachments
• Email — read and send via Himalaya CLI over IMAP/SMTP
• Image generation — Gemini 3 Pro Image, auto-uploaded to R2
• Memory — a structured file-based system that persists across sessions, organized by type (user, feedback, project, reference)
• SEO and content tools — full audit pipeline, keyword research, content writing, meta optimization
• Chrome DevTools — accessibility audits, Lighthouse, performance traces
• Figma — read designs, generate code, manage Code Connect
• Scheduled agents — remote triggers that run on a cron schedule
• Code review pipeline — systematic review against a plan before merging
• Custom slash commands — anything I’ve written as a skill lives here

That list is longer than what I had in OpenClaw, and it’s growing faster. The difference is architectural. In OpenClaw, a skill is a YAML file that registers JSON Schema tool definitions with the API — the model can call them, but it can’t see or modify them. In Claude Code, a skill is a markdown file that gets injected directly into the model’s context window. The model reads the instructions, understands the intent, and can write new skills or improve existing ones as part of its own operation.

OpenClaw extends what the model can call. Claude Code extends what the model knows how to do. The latter compounds faster.

---

Memory Across Sessions

The memory problem was the roughest edge of OpenClaw. The agent reconstructed context from files on each new session, which worked but showed the seams. I wrote about this in the quevin-bot post — memory remained the “core problem.”

Claude Code’s memory system is purpose-built for exactly this. There’s a /memory directory where each memory is its own markdown file with typed frontmatter — name, description, and a category like user, feedback, project, or reference. A MEMORY.md index gets loaded into every session’s context window. A startup hook surfaces relevant history. The model writes to it deliberately, reads from it reliably, and updates or removes entries when they go stale.

The pattern I use now:

• User memories — preferences, expertise level, working style
• Feedback memories — what I’ve corrected or confirmed across sessions
• Project memories — ongoing work, decisions, what’s blocked and why
• Reference memories — where things live, what tools exist, what credentials connect where

Nothing gets lost between sessions. Context I’ve built up over weeks is available the next morning when I open a new Claude Code window. That’s the persistence OpenClaw was trying to provide — it’s just handled natively here.

---

The Thing About Always-On

The one thing OpenClaw genuinely had that Claude Code doesn’t: proactive availability. The OpenClaw gateway runs continuously. It can initiate actions — heartbeats, scheduled checks, autonomous outreach. Claude Code requires you to start a session.

This difference matters less than I thought it would.

In practice, I’m not reaching for my agent because it pinged me. I’m reaching for it because I have something to do. The “always-on” feature saw less use than the “I have a task for you right now” feature, by a wide margin. The friction of opening Claude Code is low enough that it stopped registering as friction.

The one case where always-on would still matter: true automation — things that run while I’m not there, that don’t need me to initiate. For that, Claude Code now has scheduled remote agents and cron-based triggers. I’m using these to run recurring tasks on a schedule. Not the same as a persistent gateway, but it handles the actual use cases I had.

---

What Changed My Mind Concretely

It wasn’t a single moment. It was a series of small realizations:

I looked at my API spend and realized OpenClaw was costing me 3–4x what a $20/month Claude.ai Pro subscription runs. Every message through the gateway is a separate API call, billed per input and output token, with the conversation history growing the context window on each turn. Claude Code comes bundled with Pro and Max subscriptions at a flat monthly rate. The metered-vs-flat math stopped being close.

I went to install a new OpenClaw skill and spent twenty minutes fighting configuration that Claude Code would have handled with a markdown file and a slash command.

I needed to fix the BlueBubbles tunnel URL — again, because the ephemeral Cloudflare tunnel changed on restart, again — and thought: I’m spending maintenance time on infrastructure that exists to get me to the same model I already have direct access to.

I used the Claude Code Telegram plugin to fix a bug in my quevin.com repo from my phone, in a way that would have required OpenClaw to invoke Claude Code anyway. The intermediary layer had become purely overhead.

None of these individually would have changed my workflow. All of them together made the answer obvious.

---

Where OpenClaw Still Lives

I haven’t uninstalled it. If you need:

• iMessage integration without writing your own BlueBubbles bridge
• WhatsApp as an input channel
• A persistent agent that truly runs 24/7 without requiring a terminal session to stay open
• A multi-channel setup where the same agent lives in five places at once

…then OpenClaw is still the right tool. The architecture it provides is genuinely powerful for those cases.

But for a single developer running an agentic workflow primarily through one channel and one development environment? The overhead of a separate framework stopped making sense when Claude Code became the better answer to the same question.

---

The Pattern

OpenClaw attracted me because it extended what Claude could do. Claude Code has since absorbed that extension, improved it, and added everything else. The framework that enabled the workflow became less necessary as the core tool got better.

This is probably going to keep happening. The interesting surface area isn’t “what third-party tool can I bolt onto this model.” It’s “how much of what I need has the model learned to do natively.” That surface area is expanding faster than any framework can track it.

The question “what can’t Claude Code do” keeps getting harder to answer.

I’ll let you know when I find something.

---

Related Reading

• Two Claudes, One Telegram — Where this started: running both side by side
• Quevin Bot Is Actually Running Now — The OpenClaw setup before the shift
• It’s Not What You Can Do — It’s What You Can Get Done — The broader frame for why this kind of tool evolution matters