openclaw - 💡(How to fix) Fix core-plugin-tools per-turn overhead from repeated plugin manifest resolution [1 comments, 2 participants]

openclaw2026-05-04 01:27:19

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#77029•Fetched 2026-05-04 04:59:17

View on GitHub

Comments

Participants

Timeline

Reactions

Author

unicebondoc

Participants

clawsweeper[bot]

unicebondoc

Timeline (top)

closed ×1commented ×1cross-referenced ×1

core-plugin-tools appears to spend significant time per turn repeating plugin manifest/path-loader resolution work that should be cached at gateway boot.

On a production OpenClaw gateway with Discord + Telegram active, per-turn prep is dominated by core-plugin-tools even after pruning unused channel/search plugins.

Root Cause

A real Discord cache-hit test is still pending/inconclusive because no gateway activity was emitted during the capture window, but the plugin-loader cost is independently visible in both CLI and gateway traces.

Code Example

core-plugin-tools  ~9.5-13s
system-prompt      ~7.7-8.8s
stream-setup       ~7.7-8.3s
total              ~29-34s

---

prep stages: totalMs=17653
core-plugin-tools:9509ms
bootstrap-context:8ms
bundle-tools:810ms
system-prompt:3266ms
session-resource-loader:677ms
stream-setup:3378ms

---

Turn 1: totalMs=17359 core-plugin-tools=9286ms
Turn 2: totalMs=17277 core-plugin-tools=9300ms
Turn 3: totalMs=17948 core-plugin-tools=9497ms

---

JS: *resolve node:path:1260:10                                      8.8% total / 35.9% nonlib
JS: *isPathInside dist/boundary-path-BphsbLa5.js:34:22              1.8% total / 7.5% nonlib
JS: *join node:path:1347:7                                          1.2% total / 5.0% nonlib
JS: *collectRuntimePackageWildcardImportTargets dist/loader-*.js    1.0% total / 4.2% nonlib
JS: *normalizePluginLoaderAliasMapForJiti dist/sdk-alias-*.js       0.5% total / 1.9% nonlib
JS: *loadPluginManifest dist/manifest-*.js                          0.0% total / 0.1% nonlib
JS: *loadPluginManifestRegistry dist/manifest-registry-*.js         0.0% total / 0.1% nonlib

---

openclaw version + config digest + enabled plugin IDs + plugin manifest digests

---

30s prep -> 17.6s after plugin pruning
remaining floor: core-plugin-tools ~9.5s
expected with manifest/tool caching: <2s core-plugin-tools, likely <8s cold prep and much faster warm prep

RAW_BUFFERClick to expand / collapse

Summary

core-plugin-tools appears to spend significant time per turn repeating plugin manifest/path-loader resolution work that should be cached at gateway boot.

On a production OpenClaw gateway with Discord + Telegram active, per-turn prep is dominated by core-plugin-tools even after pruning unused channel/search plugins.

Repro / Environment

OpenClaw: 2026.4.29
Node: v22.22.2
Host: Hetzner CPX32, Ubuntu
Channels: Discord + Telegram active
Active gateway plugins after pruning: active-memory, discord, memory-core, openclaw-routing, telegram
Enabled provider/catalog plugins after pruning: codex, minimax, ollama, openai
Primary runtime/model: embedded Pi runtime, minimax/MiniMax-M2.7
Memory embeddings: ollama/qwen3-embedding:0.6b

Observed timings

Before pruning unused plugins, gateway prep was roughly 29-34s per turn:

core-plugin-tools  ~9.5-13s
system-prompt      ~7.7-8.8s
stream-setup       ~7.7-8.3s
total              ~29-34s

After disabling unused slack, openclaw-web-search, and anthropic, prep improved but appears to floor at ~17.6s, with core-plugin-tools still ~9.5s:

prep stages: totalMs=17653
core-plugin-tools:9509ms
bootstrap-context:8ms
bundle-tools:810ms
system-prompt:3266ms
session-resource-loader:677ms
stream-setup:3378ms

Same-session CLI proxy turns still showed the same prep cost:

Turn 1: totalMs=17359 core-plugin-tools=9286ms
Turn 2: totalMs=17277 core-plugin-tools=9300ms
Turn 3: totalMs=17948 core-plugin-tools=9497ms

V8 profile evidence

A one-turn V8 profile (node --prof) showed JavaScript hot paths concentrated in plugin loader / path-boundary / manifest resolution code, not model inference:

JS: *resolve node:path:1260:10                                      8.8% total / 35.9% nonlib
JS: *isPathInside dist/boundary-path-BphsbLa5.js:34:22              1.8% total / 7.5% nonlib
JS: *join node:path:1347:7                                          1.2% total / 5.0% nonlib
JS: *collectRuntimePackageWildcardImportTargets dist/loader-*.js    1.0% total / 4.2% nonlib
JS: *normalizePluginLoaderAliasMapForJiti dist/sdk-alias-*.js       0.5% total / 1.9% nonlib
JS: *loadPluginManifest dist/manifest-*.js                          0.0% total / 0.1% nonlib
JS: *loadPluginManifestRegistry dist/manifest-registry-*.js         0.0% total / 0.1% nonlib

Additional matched patterns included realpathSync, readFileSync, zod parsing, and ajv validation, but the dominant samples are path resolution and boundary checks.

Expected behavior

Plugin manifest resolution, runtime dependency wildcard target collection, and Jiti alias map normalization should happen once at gateway boot or plugin reload time, then be reused for subsequent turns.

Actual behavior

core-plugin-tools appears to redo enough plugin/manifest/path resolution work per turn that it costs ~9-13 seconds before the model stream begins.

Proposed fix

Memoize plugin manifest + loader alias map data at gateway boot. Invalidate only when one of these happens:

openclaw plugins enable <id>
openclaw plugins disable <id>
explicit gateway/plugin reload
plugin directory mtime or manifest digest changes

A narrower variant would cache the resolved tool schemas for the active plugin set and invalidate by:

openclaw version + config digest + enabled plugin IDs + plugin manifest digests

Impact

On the measured production gateway:

30s prep -> 17.6s after plugin pruning
remaining floor: core-plugin-tools ~9.5s
expected with manifest/tool caching: <2s core-plugin-tools, likely <8s cold prep and much faster warm prep

This materially affects Discord/Telegram latency because users perceive every turn as stalled before token streaming begins.

extent analysis

TL;DR

Implementing a caching mechanism for plugin manifest and loader alias map data at gateway boot is likely to significantly reduce the core-plugin-tools processing time.

Guidance

Memoize plugin manifest data: Cache plugin manifest data at gateway boot to avoid redundant resolution work per turn.
Invalidate cache on plugin changes: Invalidate the cache when plugins are enabled, disabled, or reloaded, or when plugin directory modifications are detected.
Consider caching resolved tool schemas: Cache resolved tool schemas for the active plugin set to further optimize performance.
Monitor performance after caching implementation: Verify that the caching mechanism effectively reduces core-plugin-tools processing time and improves overall gateway performance.

Example

No explicit code example is provided due to the complexity of the issue, but the proposed fix suggests implementing a caching layer for plugin manifest and loader alias map data, similar to the following conceptual approach:

const cache = {};

function getPluginManifest(pluginId) {
  if (cache[pluginId]) {
    return cache[pluginId];
  }
  const manifest = loadPluginManifest(pluginId);
  cache[pluginId] = manifest;
  return manifest;
}

function invalidateCache(pluginId) {
  delete cache[pluginId];
}

Notes

The effectiveness of the caching mechanism may depend on the specific plugin configuration and usage patterns. It is essential to monitor performance after implementing the caching solution to ensure it achieves the expected results.

Recommendation

Apply the proposed caching workaround to reduce core-plugin-tools processing time and improve gateway performance, as it is likely to have a significant impact on reducing latency for Discord and Telegram users.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

#indexing error #inference speed #output truncation #response parsing #generation error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix core-plugin-tools per-turn overhead from repeated plugin manifest resolution [1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Code Example

Summary

Repro / Environment

Observed timings

V8 profile evidence

Expected behavior

Actual behavior

Proposed fix

Impact

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix core-plugin-tools per-turn overhead from repeated plugin manifest resolution [1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Code Example

Summary

Repro / Environment

Observed timings

V8 profile evidence

Expected behavior

Actual behavior

Proposed fix

Impact

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING