phase=stream-ready totalMs=86416
core-plugin-tools:1987ms
bootstrap-context:29ms
bundle-tools:7486ms
system-prompt:36383ms
session-resource-loader:8480ms
stream-setup:32040ms



### Steps to reproduce

1. Configure OpenClaw 2026.4.29 on Windows 11 with the Telegram channel enabled.

2. Set the agent model to an OpenRouter provider-runtime model. Observed with:
   openrouter/moonshotai/kimi-k2.6

3. Start or restart the gateway:
   openclaw gateway restart

4. Send a simple Telegram message to the bot, for example:
   hello

5. Watch the gateway log for the embedded run prep summary:
   [trace:embedded-run] prep stages: ... phase=stream-ready totalMs=...

6. Observe that embedded-run prep takes tens of seconds before stream-ready. In my observed Kimi run:
   totalMs=86416
   bundle-tools=7486ms
   system-prompt=36383ms
   session-resource-loader=8480ms
   stream-setup=32040ms

Instrumentation showed repeated provider-runtime/plugin resolution across multiple prep phases, including tool normalization, system prompt generation, transcript policy, and stream setup.

A local process cache around resolveProviderRuntimePlugin() and resolveProviderHookPlugin(), keyed by provider/config/workspace/plugin-relevant inputs, reduced the same Kimi path to approximately 5 seconds:

prep.total-before-stream-ready 5016ms
stream-setup.bucket-beforeMark 45ms
bucket.stream-setup 46ms

This suggests the upstream fix should cache provider-runtime/plugin resolution rather than adding model-specific fastpaths.

### Expected behavior

Embedded-run prep should reach stream-ready without repeatedly spending tens of seconds resolving the same provider-runtime/plugin hooks.

A grounded reference is the local proof-of-concept provider-runtime cache on the same OpenClaw 2026.4.29 install and same model, openrouter/moonshotai/kimi-k2.6, which reduced prep from ~86.4s to ~5.0s:

Before cache:
phase=stream-ready totalMs=86416
bundle-tools=7486ms
system-prompt=36383ms
session-resource-loader=8480ms
stream-setup=32040ms

After cache:
prep.total-before-stream-ready 5016ms
stream-setup.bucket-beforeMark 45ms
bucket.stream-setup 46ms

Expected behavior: provider-runtime/plugin resolution should be cached or otherwise reused across prep phases when provider/config/plugin state has not changed, so normal Telegram responses are not delayed by 80–120s of repeated embedded-run prep work.

### Actual behavior

Telegram responses became delayed by 1–2+ minutes while the gateway remained running. During these delays, the logs showed embedded-run prep taking tens of seconds before reaching stream-ready.

Observed with openrouter/moonshotai/kimi-k2.6:

phase=stream-ready totalMs=86416
core-plugin-tools=1987ms
bootstrap-context=29ms
bundle-tools=7486ms
system-prompt=36383ms
session-resource-loader=8480ms
stream-setup=32040ms

In later raw log output, the same pattern appeared with 120s+ prep:

phase=stream-ready totalMs=124560
core-plugin-tools=37760ms
bootstrap-context=39ms
bundle-tools=7246ms
system-prompt=38334ms
session-resource-loader=8958ms
stream-setup=32209ms

The logs also showed event-loop liveness warnings and Telegram transport symptoms during the delay window, including polling stalls and send failures:

liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu
[telegram] Polling stall detected
telegram sendMessage failed: Network request for 'sendMessage' failed!

### OpenClaw version

2026.4.29 (a448042)

### Operating system

Windows 11

### Install method

Global npm install on Windows; launched via OpenClaw Gateway Scheduled Task using `openclaw gateway start`.

### Model

openrouter/openai/gpt-4o-mini, openrouter/moonshotai/kimi-k2.6

### Provider / routing chain

Telegram → local OpenClaw Gateway on Windows → OpenRouter → openrouter/moonshotai/kimi-k2.6. Additional comparison used OpenRouter → openrouter/openai/gpt-4o-mini. No intentional external proxy.

### Additional provider/model setup details

The repro was run against the agent’s configured default model in C:\Users\[WINDOWS_USER]\.openclaw\openclaw.json.

During the Kimi repro, gateway startup logged:

agent model: openrouter/moonshotai/kimi-k2.6

During the comparison run, gateway startup logged:

agent model: openrouter/openai/gpt-4o-mini

OpenRouter authentication was already configured and working. API keys/tokens are omitted.

Several plugins had config entries present but were disabled, and OpenClaw logged warnings for them at startup:

- active-memory disabled but config present
- browser disabled but config present
- codex disabled but config present
- device-pair disabled but config present
- lossless-claw disabled but config present

The Telegram channel was the only active channel in the observed gateway startup:

http server listening (1 plugin: telegram)

No intentional external proxy was configured. The issue appears tied to repeated provider-runtime/plugin resolution during embedded-run prep, not to a specific downstream model response.

### Logs, screenshots, and evidence

```shell
I have a sanitized evidence bundle with:

- timing extracts before and after the provider-runtime cache proof-of-concept
- patch marker scans
- redacted config excerpts
- curated log snippets only, not raw auth/session files

I can attach the sanitized zip if useful, but I am initially avoiding public attachment of raw logs/config/session files because they may contain local paths, bot identifiers, tokens, or other sensitive data.

Key observed timing evidence:

Before provider-runtime cache, with openrouter/moonshotai/kimi-k2.6:

phase=stream-ready totalMs=86416
core-plugin-tools=1987ms
bootstrap-context=29ms
bundle-tools=7486ms
system-prompt=36383ms
session-resource-loader=8480ms
stream-setup=32040ms

Another later raw log showed the same pattern at 120s+:

phase=stream-ready totalMs=124560
core-plugin-tools=37760ms
bootstrap-context=39ms
bundle-tools=7246ms
system-prompt=38334ms
session-resource-loader=8958ms
stream-setup=32209ms

After adding a local provider-runtime cache around resolveProviderRuntimePlugin() / resolveProviderHookPlugin(), same Kimi route:

[local-debug:provider-runtime-cache] hit runtime provider=openrouter owner=openai-completions plugin=openrouter
[local-debug:stream-setup-actual] after.providerTextTransforms.beforeWrapTextTransforms 1ms
[local-debug:stream-setup-actual] after.preparedRuntimeExtraParams.beforeApplyExtraParams 1ms
[local-debug:stream-setup-actual] after.applyExtraParams.beforeResolveCacheRetention 1ms
[local-debug:prep] stream-setup.bucket-beforeMark 45ms
[local-debug:prep] prep.total-before-stream-ready 5016ms
[local-debug:prep] bucket.stream-setup 46ms

Supporting investigation:

Instrumentation showed repeated provider-runtime/plugin resolution across multiple prep phases:

- normalizeAgentRuntimeTools
- logAgentRuntimeToolDiagnostics
- provider system prompt contribution / transform
- transcript policy
- provider stream registration
- provider text transforms
- prepared runtime extra params
- cache-retention / transport extra params

The suspected central call path is:

function resolveProviderPluginsForHooks(params) {
  return resolvePluginProviders({
    ...
    activate: false,
    cache: false,
    ...
  });
}

function resolveProviderRuntimePlugin(params) {
  const apiOwnerHint = resolveProviderConfigApiOwnerHint(...);
  return resolveProviderPluginsForHooks(...).find(...);
}

function resolveProviderHookPlugin(params) {
  return resolveProviderRuntimePlugin(params) ?? resolveProviderPluginsForHooks(...).find(...);
}

Because resolveProviderPluginsForHooks() passes cache: false, multiple prep consumers appear to repeatedly pay the provider/plugin discovery and matching cost.

Observed secondary log symptoms during the same delay windows:

liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu
[telegram] Polling stall detected
telegram sendMessage failed: Network request for 'sendMessage' failed!

I believe those Telegram transport errors are secondary symptoms/noise from the long event-loop-blocking prep window, not the root cause of the embedded-run prep latency.