The comparison people ask for is a feature table. The one that actually decided how I build is narrower than that, and it is not really about features at all.
Where does the agent live between invocations, and what survives the gap?
Answer that and most of the rest follows.
Two different bets
OpenClaw is MIT licensed, written in TypeScript on Node, and self-hosted. Its own repository describes the Gateway as “the local control plane for sessions, tools, events, and channel connections.” That is the shape: a resident process you run, which owns sessions and holds connections to messaging channels, and which you talk to from a UI, a CLI, or a phone.
Claude Code is a terminal tool. It starts, it works in a directory, it ends. Anthropic’s documentation frames it around the codebase you point it at rather than around a resident service.
Neither is a subset of the other. They are answers to different questions.
A resident agent is right when the conversation is the durable thing. You want to message it from a phone, have it remember Tuesday’s discussion on Thursday, and have it react to something arriving rather than to you starting a session.
A session-scoped tool is right when the repository is the durable thing. State lives in git, not in the agent. The agent is a process that shows up, changes files, and leaves.
What I actually run
On this machine, right now: 65 loaded launchd jobs and 35 trigger definitions. They publish articles, pull Search Console data, watch for security drift, regenerate a state digest, monitor upstream pull requests.
Not one of them is a long-lived agent process. Each is launchd starting something on a
schedule, letting it finish, and reaping it.
That was not a compromise. It is the part I would defend hardest.
The scheduler is the boring, forty-year-old, extremely well-tested part of the system, and that is exactly why it holds the crown.
A resident process that has been up for three weeks accumulates state you did not design and cannot inspect. When it misbehaves at 3am, you are debugging an execution history nobody recorded. A job that starts fresh, does one thing, writes its output somewhere durable and exits has a failure mode you can reproduce: run it again.
There is a real cost. Anything genuinely conversational, anything that has to respond to an inbound message rather than a clock, does not fit this shape at all. That is why a gateway process runs here too, alongside the cron jobs. I did not pick one architecture. I split the work by which kind of durability it needed.
The rule I actually use
If it can be expressed as “at 8am, do this, and leave evidence” it goes to a scheduled session. Everything about that is inspectable. The trigger is a file. The schedule is a plist. The output is a commit or a report. Nothing is remembered that is not written down.
If it has to be reachable, it needs a resident process. Inbound messages, a phone, anything where a human starts the interaction on their own schedule rather than yours.
What the comparison usually gets wrong
Most versions of this question turn into channel counts and marketplace sizes. Those are real differences and they are easy to tabulate, which is precisely why they dominate.
They are also the parts most likely to be irrelevant to you. I do not need twenty-four messaging integrations. I needed two: a scheduler I trust and one inbound channel.
The question worth asking of any agent tool is not what it connects to. It is: when this goes wrong at 3am, what will I have to look at? If the honest answer is “the process memory of something that has been running for a fortnight,” that is a real cost, and it should be paid deliberately for work that genuinely needs it.
What actually generalises
Persistence is a design decision, not a feature. Every agent tool has an implicit answer to what survives between invocations, and it is usually not on the comparison page. It determines your debugging story more than any capability does.
Prefer state you can read. Git, a plist, a report on disk. An agent’s internal memory is the least inspectable place state can live, so put as little there as the job allows.
You are probably going to run both. The framing of picking a winner assumes one axis. Scheduled autonomous work and reachable conversational work are different problems, and the interesting engineering is in deciding which is which, not in choosing a side.
Sources
- OpenClawOpenClaw Foundation
- Claude Code overviewAnthropic
- launchdlaunchd.info