Consistent ~10s blocking latency on every OpenResponses API call

[drowsy scarab]

Hi, I'm seeing consistent blocking latency (~10 seconds) on every call to the OpenResponses API in OpenClaw, and I'd like to confirm whether this is expected behavior or a known issue.

This happens on every request, not just the first one.

From the logs, several components appear to run synchronously before the response starts:

• Slack socket ping / timeout warnings
• Bedrock IAM token discovery attempts (even though Bedrock is not used)
• Plugin initialization / library loading
• Session history loading (~52k chars)

Here is a sample log showing the sequence and timing:
https://gist.github.com/kanekoh/417974ff6d5f1e72c6aa3521012d689f

The total duration per request is typically around 16 seconds, and the blocking behavior repeats consistently.

Questions:

1. Are these initializations expected to run on every OpenResponses API call rather than once at startup?
2. Is there a supported way to disable unused integrations (e.g., Bedrock discovery, Slack hooks) to reduce latency?
3. Are there plans for lazy-loading or caching of these components?

If helpful, I can open separate GitHub issues for each symptom after confirming the intended behavior.

Thanks!

[final egret]

I checked the source, and the short version is: no, a steady ~10 seconds pre-response stall on every POST /v1/responses does not look intended overall.

A few specifics:

1. What is expected on every request

   • Session transcript/history loading: yes, some of that is per-run. The OpenResponses path ends up in src/agents/agent-command.ts, which calls resolveSessionTranscriptFile(...), and the run path reopens the session transcript via SessionManager.
   • Session store metadata: this is already cached in src/config/sessions/store-load.ts, so the store itself should not be fully reloaded every time unless cache is bypassed.

2. What should already be lazy/cached

   • src/gateway/server-http.ts caches the OpenResponses module with openResponsesHttpModulePromise.
   • src/agents/model-catalog.ts caches provider/model discovery with modelCatalogPromise.
   • So repeated “first-use” plugin/library init on every request looks more like a cache miss / regression / unintended repeated path than expected behavior.

3. Bedrock

   • There is a supported disable for implicit Bedrock discovery:
     plugins.entries.amazon-bedrock.config.discovery.enabled: false
   • Relevant source: extensions/amazon-bedrock/discovery.ts

• Also, Bedrock probing can happen from memory embeddings auto-selection: src/memory-host-sdk/host/embeddings.ts calls hasAwsCredentials(), which falls back to AWS defaultProvider({ timeout: 1000, maxRetries: 0 }) in src/memory-host-sdk/host/embeddings-bedrock.ts.
  • So if memory search / embeddings are on provider: "auto", that is a plausible repeated probe source.

4. Slack

   • I do not see src/gateway/openresponses-http.ts directly calling Slack socket code.
   • The ping/timeout warnings look like background Slack monitor logs from extensions/slack/src/monitor/provider.ts, not intended request-path work.
   • You can disable Slack at the config level with channels.slack.enabled: false (or disable the specific Slack account).

5. So, answering your questions directly

   • Q1: No, not all of those should be re-initializing on every OpenResponses call. Transcript/session continuity work, yes. Repeated heavy plugin/catalog init, no.
   • Q2: Yes, you can disable unused integrations, especially Bedrock implicit discovery and Slack. If memory embeddings are involved, pin the provider explicitly instead of auto, or disable that feature.
   • Q3: Some lazy-loading/caching already exists today, which is why the repeated blocking pattern looks suspicious rather than intended.

I’d open at least one GitHub issue for the repeated /v1/responses blocking latency, and probably a second focused Bedrock auto-discovery issue if that still happens with Bedrock unused. Please include:

• openclaw --version
• your gist
• whether memory search / embeddings are enabled

• whether any AWS env vars are present

Relevant docs:

• https://docs.openclaw.ai/providers/bedrock
• https://docs.openclaw.ai/channels/slack
• https://docs.openclaw.ai/reference/memory-config
• https://docs.openclaw.ai/gateway/configuration-reference

If you want, I can help turn this into a tight issue template next.

[drowsy scarab]

@final egret Thanks for the detailed explanation — this is very helpful.

It may take me a bit of time to verify my configuration (memory/embeddings settings and AWS environment variables), but I'll follow up with the results and open the corresponding GitHub issue(s) once confirmed.

Appreciate the guidance.

[final egret]

Sounds good. I’m glad that helped.

Yep, checking the memory/embeddings config plus any AWS env vars is the right next step. When you open the issue(s), definitely include openclaw --version too, that helps a lot with triage.

If you paste the config bits or the follow-up findings here, I can help sanity-check them before you file.

[drowsy scarab]

@final egret I've followed your advice and confirmed the following:
Environment:

• OpenClaw 2026.4.14 (updated from 2026.4.12)
• Raspberry Pi 5 (ARM64)

Results:

• env | grep -i aws was empty (no AWS env variables)
• openclaw memory status showed Provider: openai (requested: auto)
• openclaw config get memory showed Config path not found: memory (no configuration, using defaults)

What I've tried:

• Specified "openai" as the embeddings provider. The status now shows requested: openai, but the logs still show [bedrock-mantle-discovery] Mantle IAM token generation unavailable with ~6s blocking.
• Added plugins.entries.amazon-bedrock.config.discovery.enabled: false — only produced a "plugin disabled but config is present" warning; discovery still runs.
• Upgraded from 2026.4.12 to 2026.4.14 — no change.

Summary:
Bedrock mantle discovery cannot be stopped even with the plugin disabled, discovery config set to false, and the embeddings provider explicitly specified. It seems like memory-host-sdk calls defaultProvider() regardless of these settings.
Here is my sanitized config (tokens redacted): https://gist.github.com/kanekoh/f3696b364dc038b2099bd2f1e595dbcb

If you have no other suggestions, I'd like to proceed to open a GitHub issue.
Thanks.

[final egret]

Nice, thanks, that narrows it down a lot.

I think I see the important mismatch now:

• your logs are from [bedrock-mantle-discovery]
• but the config you toggled was plugins.entries.amazon-bedrock.config.discovery.enabled

Those are two different plugins.

From source:

• extensions/amazon-bedrock/discovery.ts does honor plugins.entries.amazon-bedrock.config.discovery.enabled
• extensions/amazon-bedrock-mantle/discovery.ts currently has no equivalent discovery.enabled gate
• extensions/amazon-bedrock-mantle/register.sync.runtime.ts calls resolveImplicitMantleProvider(...) when that plugin is active

So I’d try one more thing before filing:

{
  plugins: {
    entries: {
      "amazon-bedrock-mantle": {
        enabled: false
      }
    }
  }
}

If bedrock-mantle-discovery still runs after disabling amazon-bedrock-mantle explicitly, then yes, I’d absolutely open a GitHub issue, because that would mean the explicit plugin disable is being ignored.

Even if that disable does stop it, I still think there’s a reasonable issue/request here: Mantle does not currently seem to have the same config.discovery.enabled off switch that regular Bedrock has, and on a Pi that IAM fallback cost is pretty nasty.

So my recommendation is:

1. try plugins.entries.amazon-bedrock-mantle.enabled: false
2. if logs persist, file the issue
3. include:
   • openclaw --version (2026.4.14)
   • Raspberry Pi 5 / ARM64
   • the sanitized config gist
   • the exact note that amazon-bedrock discovery disable had no effect because the active log source was bedrock-mantle-discovery

Relevant docs:

• https://docs.openclaw.ai/providers/bedrock-mantle
• https://docs.openclaw.ai/providers/bedrock
• https://docs.openclaw.ai/gateway/configuration-reference

If you want, paste the result after toggling amazon-bedrock-mantle, and I’ll help word the issue cleanly.

[drowsy scarab]

@final egret Thanks, That makes sense.

[final egret]

Glad that helped.

If you test the amazon-bedrock-mantle disable and want a second pair of eyes on the result or the GitHub issue wording, send it over.

And if this answer was enough to unblock you, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

[drowsy scarab]

Sure!

[final egret]

Thank you 🙏

[drowsy scarab]

@final egret Disabling amazon-bedrock-mantle worked — the [bedrock-mantle-discovery] log is completely gone and the blocking is resolved.
I also tested with Slack disabled. The pong timeout warning disappeared, but the overall request duration didn't change significantly, so Slack wasn't a direct cause of the blocking as you suspected.
I'll open a GitHub issue for the missing config.discovery.enabled gate on amazon-bedrock-mantle as you suggested.
Thanks for helping track this down!

[final egret]

Nice, that’s a great catch. I’m glad we pinned it down.

That lines up cleanly with the source:

• amazon-bedrock-mantle was the blocking path
• Slack was just noisy background logs, not the main latency cause

A GitHub issue for the missing config.discovery.enabled gate on amazon-bedrock-mantle sounds exactly right. Including the before/after result from disabling the plugin will make it a strong report.

And if this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users.

[drowsy scarab]

@final egret mark solution was done.