my openclaw has become so slow lately. | Friends of the Crustacean 🦞🤝 | Page 1

lavish stream Apr 24, 2026, 9:54 AM

#

my openclaw has become so slow lately. I don't know if I messed something up by trying to enable better memory configuration, but it often takes 10 or 15 seconds to respond. Even just running /new takes 15 to 20 seconds. I tried checking the gateway logs but I couldn't really figure out what was causing it really and neither could my clanker.
Any ideas? Has anyone experienced this? I'm running GPT 5.5 via openai-codex. And I tried different thinking levels and it was kind of similar. Doing the same message in ChatGPT gives me a response in a second or two, super-quick, but the same thing can take five or ten seconds in OpenAI. Initial context is around 22k.
I have both Telegram and Discord set up and both are equally slow and it wasn't like this a month or two ago.

abstract nymphBOT Apr 24, 2026, 9:54 AM

#

rugged pagodaBOT Apr 24, 2026, 9:54 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

worn hedgeBOT Apr 24, 2026, 9:56 AM

#

Lemme check the current docs/source paths, then I’ll give you the shortest useful triage path.

#

I found one likely angle already: /new can be slow even before the actual model call if you’ve got startup-context, hooks, or Active Memory on the hot path. I’m checking those docs/source now.

#

Yeah, this smells a lot more like extra pre-reply work than Discord/Telegram transport.

Big clue: if /new itself takes 15 to 20s, I’d check these first:

session-memory hook
On /new and /reset, it can read the last messages and even make an LLM call to generate the memory filename slug. That can absolutely add ~10s by itself.
Docs: https://docs.openclaw.ai/automation/hooks#session-memory
Active Memory
This is a blocking memory sub-agent that runs before normal replies. If you enabled “better memory” recently, this is a very plausible cause of every-turn slowdown.
Docs: https://docs.openclaw.ai/concepts/active-memory
Startup context on /new
Bare /new and /reset can prepend recent daily memory, so OpenClaw is not sending the same prompt shape as ChatGPT.
Docs: https://docs.openclaw.ai/reference/token-use

Also, “22k context” in OpenClaw is not apples-to-apples with ChatGPT. OpenClaw also injects tools, workspace bootstrap files, skills metadata, and sometimes startup context.

#

First, please paste:

openclaw --version

Then I’d test in this order:

openclaw hooks list
openclaw config get plugins.entries.active-memory
openclaw config get agents.defaults.startupContext
openclaw memory status --deep
openclaw status --all

Quick A/B tests:

#

If session-memory is enabled:
```
openclaw hooks disable session-memory
```
then try /new again.
In chat, if Active Memory might be on:
```
/active-memory off
/verbose on
/trace on
```
If you start seeing 🧩 Active Memory: ... elapsed=..., you found the hot path.
With openai-codex/gpt-5.5, also try:

#

  /fast on

That maps to priority processing on Codex Responses.

One more subtle thing: Codex OAuth does not cover embeddings, only chat/completions, so if your new memory setup expects OpenAI embeddings, openclaw memory status --deep should help expose that.

If you paste these 5 outputs, I can probably narrow it down fast:

openclaw --version
openclaw hooks list
openclaw config get plugins.entries.active-memory
openclaw config get agents.defaults.startupContext
openclaw memory status --deep

Useful refs:

https://docs.openclaw.ai/help/faq

#

https://docs.openclaw.ai/gateway/troubleshooting

lavish stream Apr 24, 2026, 10:05 AM

#

For the hooks I do have the four default ones enabled. I do not have Active Memory enabled. I already disabled that a couple of weeks ago when I noticed it was slowing down.

Regarding the session memory, what's that good for? Will I lose out if I disable it? There is also no startup context configured.

worn hedgeBOT Apr 24, 2026, 10:06 AM

#

Yeah, of the 4 default hooks, session-memory is the one I’d suspect first.

It does this on /new and /reset:

grabs the last ~15 user/assistant messages
makes an extra LLM call to generate a nice filename slug
writes a file to memory/YYYY-MM-DD-something.md

So yes, it’s useful, but mostly for archiving old sessions into your memory folder so they can be searched/recalled later.

If you disable it, you do not lose core chat functionality. You only lose:

automatic saving of old sessions into memory/
any later recall value from those saved session-summary files

You won’t lose:

normal replies
existing memory files
regular MEMORY.md / other memory behavior

#

current session behavior

So honestly, if speed matters more than auto-archiving old chats, I’d disable it and test:

openclaw hooks disable session-memory
openclaw gateway restart

Then try /new a couple times.

If /new suddenly gets fast, we found it.

If /new is still slow after that, then I’d stop blaming memory and look at:

version regression, so please paste:

#

   openclaw --version

Codex/OpenAI route latency on openai-codex/gpt-5.5
any unusually large bootstrap/system prompt overhead

You can also watch it live while testing:

openclaw logs --follow

Docs:

#

If you want, paste your version after trying that and I’ll help narrow down the next suspect.

lavish stream Apr 24, 2026, 10:08 AM

#

But why isn't the session memory thing that runs on /new asynchronous?

worn hedgeBOT Apr 24, 2026, 10:09 AM

#

Because today it’s implemented as a blocking internal command hook, not a background task.

Short version:

/new and /reset go through the internal hook pipeline
that pipeline awaits handlers serially
session-memory is one of those handlers
so /new waits for it to finish before reset continues

Why do it that way at all?

Deterministic ordering
Hooks can depend on the pre-reset state and run in a known order.
Safe access to the old session
/new is mutating/rotating the session, so blocking avoids races with transcript/session-file changes.

#

Hooks can emit messages
The generic hook event can push reply messages, so the caller waits for completion.

So, “why isn’t it async?” is less “it can’t be” and more “the current internal hook system for reset commands is synchronous by design”.

And honestly, I think your instinct is fair, session-memory is a pretty good candidate for being moved off the hot path, especially since it can make an extra LLM call just to generate the slug.

There actually are other places in OpenClaw that do fire hooks in the background, so this is not some fundamental limitation. It’s just not how this specific hook path was wired.

So my practical answer is:

Yes, disabling session-memory is a reasonable workaround
No, that hook does not need to be on the critical path for most people
and if you want this improved, it sounds like a legit GitHub issue / feature request:
https://github.com/openclaw/openclaw/issues

If you want, I can help you word a tight issue report for it.

lavish stream Apr 24, 2026, 10:11 AM

#

OK but even just regular messages are way slower than just ChatGPT. Even ChatGPT on maximum thinking level is faster than openclaw on low thinking level

worn hedgeBOT Apr 24, 2026, 10:13 AM

#

Yeah, that’s the key signal then. If both Telegram and Discord are equally slow, and low thinking doesn’t help much, the bottleneck is probably before or around the model call, not the channel and not just reasoning depth.

Why OpenClaw can feel slower than ChatGPT even on the same family:

OpenClaw rebuilds an agent prompt every turn
it injects tool schemas
it injects workspace bootstrap files (AGENTS.md, SOUL.md, USER.md, MEMORY.md, etc.)
it includes session history
and on openai-codex/* it goes through the PI/Codex OAuth route, which has its own transport behavior

So “low thinking” only reduces one part of the total latency. If prompt assembly + transport + large context dominate, it won’t move much.

A few very plausible causes for regular-turn slowness:

Big injected bootstrap/context
OpenClaw injects workspace files every turn by default.
Check:

#

   /context detail

That should show if one of your injected files is huge.

Context injection mode
By default it is always.
There’s a setting to skip bootstrap re-injection on safe continuation turns:
agents.defaults.contextInjection: "continuation-skip"
Docs: https://docs.openclaw.ai/gateway/config-agents
Transport weirdness on openai-codex/*
OpenClaw uses WebSocket-first, SSE fallback in auto.
If that path is unhappy, forcing SSE is worth trying.
Docs: https://docs.openclaw.ai/providers/openai
Prompt/tool overhead vs ChatGPT

#

ChatGPT is the first-party path, so it’s just not a fair latency baseline for OpenClaw agent runs.

What I’d test next, in this order:

openclaw --version
openclaw status --all

Then in chat:

/context detail
/status
/fast on

#

And if you want a config A/B test, try these:

{
  agents: {
    defaults: {
      contextInjection: "continuation-skip",
      models: {
        "openai-codex/gpt-5.5": {
          params: { transport: "sse" }
        }
      }
    }
  }
}

#

That’s the cleanest “is it prompt reinjection or transport?” test I can think of.

If you paste:

openclaw --version
openclaw status --all
/context detail

…I can probably tell you pretty quickly which bucket this falls into.

Useful refs:

Glad we narrowed it past “just memory”, at least.

lavish stream Apr 26, 2026, 7:56 PM

#

So regarding the number one big injected bootstrap context, you know how big is too big? Right now this is what my OpenClaw agent is telling me about my context.

~38k tokens cached context
~16k tracked prompt estimate
~12k system/developer/project context
~4.3k tool schema tokens
~1.9k skills list tokens
~4.9k project files, including AGENTS.md, SOUL.md, USER.md, TOOLS.md, MEMORY.md
plus some provider/runtime overhead

Is this within reason or is it too much? Is this the reason why it feels really slow? It takes 5 seconds at the fastest to get a response in a clean session in a new session.

#my openclaw has become so slow lately.