I often hear people around me say that OpenClaw has gotten slow. They send it a message and get a response much later, or sometimes it feels like their messages are being ignored altogether. Is it a bug, a server problem, or has Claude just gotten lazy? I found two main causes behind these complaints, so I wanted to share a few small tips.
The first culprit is Cron. Cron is a recurring scheduled task you set for an agent, like “Check my email every morning at 9” or “Check the server status every 30 minutes.” It is like a recurring alarm on your phone. The problem was where that alarm was ringing.
It helps to think of an OpenClaw agent as a single assistant. This assistant can only have one KakaoTalk window open. When I send a message, the assistant reads it and writes a reply. Cron is a recurring alarm I set in advance for the assistant. “Check the news every 30 minutes.” “Check the server status every hour.” “Organize my email and calendar every morning.” When an alarm rings, the assistant stops what it is doing and handles that task first. Even if I send a KakaoTalk message, the assistant cannot see it until the alarm has been handled. The assistant has not gotten slower. One assistant simply cannot handle 24 alarms and look at my KakaoTalk messages at the same time.
Once you start using OpenClaw, you naturally start creating Crons all over the place. One or two at first. Server status checks, news collection, email checks, calendar organization. In the beginning, there is no real problem. Even after ten or twenty, it still seems fine. Then one day, you send a message to the agent and get no response. Ten seconds. Thirty seconds. A minute. You open the logs, wondering if something has broken. Nothing is broken. The agent is busy in the background. It is handling all the alarms I set up.
Technically, it works like this. In OpenClaw, the main session is the agent’s consciousness. One KakaoTalk window. When I message it on Telegram, this main session responds. The problem is that Cron also runs in this main session by default. Conversations and alarms are standing in the same line. If an alarm is being handled at the front, my message waits in the queue. There is one chef, and dine-in orders and delivery orders are coming through the same line. If the delivery orders pile up, the diners cannot get their food no matter how much they wave.
Cron has a setting called sessionTarget. There are two options: “main” and “isolated.” With main, that one assistant handles the task directly. With isolated, you hire a temporary worker to handle it. When the task is done, the temporary worker goes home. The problem is that the default is main. If you do not change anything, every alarm gets sent to one assistant. Black Swan monitoring, price alerts, news summaries, email checks, calendar reminders, GitHub PR checks, learning routines. If you keep adding them one by one, before you know it, all 24 are on that assistant’s to-do list. That is exactly what happened to me. And most of the people around me who said “OpenClaw has gotten slow” were in the same situation.
Let’s look at a timeline. At 00:00, the main session starts handling an alarm. At 00:01, I send a message. The message enters the queue. At 00:03, the alarm finishes, and only then is my message handled. A two-minute delay. That is what happens with a light alarm. But if there is a heavy monitoring alarm that runs every 30 minutes, you may have to wait several minutes every time you try to talk to it. The agent has not gotten stupid. It is busy. This is what “Why is OpenClaw like this lately?” really means.
So why does the main target exist? Because some alarms only make sense when the assistant handles them directly. A morning report is only useful if the assistant remembers last night’s conversation and can make a meaningful summary. A daily review is the same. These tasks should run in the main session. The problem is running everything in main, including tasks like price checks, PR monitoring, news collection, and email checks that do not need any context from yesterday’s conversation. It is like giving one assistant every task that could have gone to a temporary worker.
The solution comes down to one question. “Does this alarm actually need the context of my conversations with it?” If it does, leave it in main. If it does not, move it to isolated. Most monitoring alarms can go to isolated. In my case, I moved 13 of the 24 to isolated, and cleaned up the rest that did not need context. I left only report alarms that run four or five times a day in the main session.
There is one technical detail to keep in mind. To run Cron in an isolated session, you need to change the payload type to agentTurn. The systemEvent used in main works by slipping a note into the assistant’s notepad, but isolated has no notepad. agentTurn is like handing a temporary worker a work order that says, “Do this.” In the Cron settings, change sessionTarget to isolated and the payload kind to agentTurn.
Once you change the settings, you feel the difference immediately. You message the agent you thought had gotten lazy, and it responds right away. Even when alarms are running in the background at the same time. The 24 alarm clocks have been moved into the next room. Only four or five reporting alarms remain in my room, and even those ring only when I want them to. The agent’s consciousness can finally focus on me. When people around me complained that OpenClaw was slow, I told them to check their alarms first. Seven out of ten had the same cause.
Another major reason OpenClaw becomes frustrating is making the main agent do work directly. When the main agent starts writing complex code, analyzing a long document, or searching the web, my conversation responses become noticeably slow or stop altogether for that entire period.
So I use the main agent only as a manager. When a task comes in, I give it instructions to call a sub-agent and hand the task off instead of handling it directly. I write these instructions in AGENTS.md in the workspace. OpenClaw’s agent reads this document every time a session starts, so I can write, “For complex tasks, spawn a sub-agent to handle them. Your only role is to pass along the result.” It is like telling an assistant, “Don’t do the work yourself. Call someone and have them do it. You just report back to me.” The main session of the main agent should always be empty. That is the only way it can respond immediately when I message it.
For the same reason, I split the main agent itself into three. Zeon handles coding and system operations, Sion handles writing, and Mion handles investment and data analysis. Each has a separate main session, so even if Sion is writing a long piece, Zeon can answer me right away when I message him. Separating Crons into isolated sessions is a distribution by unit of work. Splitting agents into multiple agents is a distribution by role. The principle is the same. Do not put everything into one consciousness.
Working with agents has made me realize that this is much closer to designing and running an actual organization than to writing traditional code. Who should handle which task? How should the reporting lines work? Where do bottlenecks emerge? It feels quite different from the development environments I have known until now. It feels different from dividing up functions and separating modules.
Agents are more human than you might expect, and that is why the problems they cause often resemble the problems you encounter in human organizations. When agents periodically become slow or communication starts breaking down, I go back to rethinking the division of work first. As if I were drawing an organization chart for a company.
