PR #73794: perf(capability-provider): reuse active registry on non-memory/non-speech lookups

• Repository: openclaw/openclaw
• Author: poolside-ventures
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73794

Description (problem / solution / changelog)

Summary

• Problem: resolvePluginCapabilityProviders's active-registry early-return is gated on !hasExplicitPluginConfig(params.cfg?.plugins). hasExplicitPluginConfig returns true for any non-empty plugins.entries — i.e., every gateway with at least one installed plugin. The gate fails for effectively every production user, every capability lookup falls through to loadOpenClawPlugins, and the full plugin registry is rebuilt (Jiti loader + manifest validation + per-plugin register()) on each call.
• Why it matters: A single agent turn triggers ~4 capability lookups (imageGenerationProviders, videoGenerationProviders, musicGenerationProviders, mediaUnderstandingProviders, realtimeVoiceProviders, realtimeTranscriptionProviders, etc.). At ~5–6s per re-load, this stacks into ~25–30s of wall-clock latency per turn — even when the LLM call itself completes in <100ms. Repro and instrumented logs in #73793.
• What changed: Dropped the !hasExplicitPluginConfig clause from the early-return. memoryEmbeddingProviders and speechProviders continue to fall through (they reconcile against cfg-level provider preferences). For every other capability key, activeProviders.length > 0 means the active registry is authoritative — the runtime already rebuilds it on config-affecting changes, so reusing it here is safe regardless of cfg.plugins.entries. The unused hasExplicitPluginConfig import was removed from this file.
• What did NOT change (scope boundary): Behavior for memoryEmbeddingProviders and speechProviders. Behavior when the active registry has zero providers for the requested key (still falls through to load). Behavior of hasExplicitPluginConfig itself (still used in bundle-commands.ts, bundled-compat.ts, etc.). Cache-key construction in loader.ts. The capability-provider load path's compat config resolution.

Change Type (select all)

• Bug fix
• Refactor required for the fix

Scope (select all touched areas)

• Gateway / orchestration

Linked Issue/PR

• Closes #73793
• This PR fixes a bug or regression

Root Cause

hasExplicitPluginConfig was added to defensively bypass the active-registry cache when callers passed an explicit cfg, on the assumption that an explicit cfg might request a different plugin set than the active registry was built with. In practice, however, hasExplicitPluginConfig returns true for any non-empty plugins.entries — and every installed plugin populates plugins.entries — so the gate fires universally and the cache is effectively never used in production. The runtime already invalidates the active registry on real config changes (the cache key in resolvePluginLoadCacheContext includes plugins, installs, activationMetadataKey, etc.), so the defensive bypass is redundant. Removing it lets the cache do its job for capability lookups.

Tests

• Added uses active non-speech capability providers even when cfg has explicit plugin entries in src/plugins/capability-provider-runtime.test.ts. Asserts that mediaUnderstandingProviders lookup with cfg.plugins.entries populated returns the active provider directly without invoking loadPluginManifestRegistry or resolveRuntimePluginRegistry({…, activate: false}).
• All 19 existing tests in capability-provider-runtime.test.ts pass unchanged.

Verification

$ pnpm vitest run src/plugins/capability-provider-runtime.test.ts
 Test Files  1 passed (1)
      Tests  19 passed (19)
   Duration  2.87s

Production validation pending — once this lands, scope-openclaw's instrumented timing log will confirm the per-turn register() count drops from 4–5 to 1.

Changed files

• src/plugins/capability-provider-runtime.test.ts (modified, +38/-0)
• src/plugins/capability-provider-runtime.ts (modified, +9/-3)

PR #74097: perf(agents/tools): lazily list capability providers in tool model-config resolution

• Repository: openclaw/openclaw
• Author: poolside-ventures
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74097

Description (problem / solution / changelog)

Summary

• Problem: resolveCapabilityModelConfigForTool (src/agents/tools/media-tool-shared.ts:246) takes providers: CapabilityProvider[] as a required eagerly-evaluated parameter, and short-circuits via hasToolModelConfig(explicit) after the caller has already computed the provider list. The 3 callers (image-generate-tool.ts:202, video-generate-tool.ts:232, music-generate-tool.ts:138) call listRuntime{Image,Video,Music}GenerationProviders({ config: cfg }) eagerly. On hosted gateways with plugins.entries populated, each provider listing triggers a full plugin-registry reload through resolvePluginCapabilityProviders → loadOpenClawPlugins (~5–6s per call).
• Why it matters: For agents with an explicit, complete modelConfig for image / video / music generation, the provider list is pure waste — resolveCapabilityModelConfigForTool returns at the hasToolModelConfig(explicit) check without using it. With 3 generation tools registered on every agent, that's ~15–18s of wasted wall-clock per turn on hosted gateways. Repro and instrumented stack traces in #74096.
• What changed: providers is now () => CapabilityProvider[] (a thunk). It's only invoked when the function falls through to candidate resolution (i.e. when modelConfig is incomplete). The 3 internal callers pass thunks. Two regression tests added in media-tool-shared.test.ts.
• What did NOT change (scope boundary): Behavior when modelConfig is incomplete (still lists providers and resolves candidates). The provider listing logic itself (listRuntime{Image,Video,Music}GenerationProviders). The capability-provider runtime's caching behavior (separate concern, see #73793). All existing image/video/music tool tests pass unchanged.

Change Type (select all)

• Bug fix
• Refactor required for the fix

Scope (select all touched areas)

• Skills / tool execution

Linked Issue/PR

• Closes #74096
• Related #73793 (independent capability-provider cache fix; this PR helps even without that one)
• This PR fixes a bug or regression

Root Cause

resolveCapabilityModelConfigForTool short-circuits via hasToolModelConfig(explicit) before using the provider list, but the provider list is computed by callers before calling the function. The eager evaluation was the natural choice when the helper was first written, but on hosted gateways it has a hidden cost of ~5–6s per call because listRuntime*GenerationProviders triggers a plugin-registry reload (see #73793 for the deeper cache-miss issue on the registry side). Making the parameter lazy lets the helper choose to evaluate it only when needed.

Tests

• Added 2 tests in src/agents/tools/media-tool-shared.test.ts:
  • does not invoke the providers thunk when an explicit modelConfig resolves
  • invokes the providers thunk when modelConfig is incomplete
• All 116 existing tests in image-generate-tool.test.ts / video-generate-tool.test.ts / music-generate-tool.test.ts pass.

Verification

$ pnpm vitest run src/agents/tools/media-tool-shared.test.ts \
                  src/agents/tools/image-generate-tool.test.ts \
                  src/agents/tools/video-generate-tool.test.ts \
                  src/agents/tools/music-generate-tool.test.ts
 Test Files  6 passed (6)
      Tests  116 passed (116)

Changed files

• src/agents/tools/image-generate-tool.ts (modified, +1/-1)
• src/agents/tools/media-tool-shared.test.ts (modified, +37/-1)
• src/agents/tools/media-tool-shared.ts (modified, +16/-3)
• src/agents/tools/music-generate-tool.ts (modified, +1/-1)
• src/agents/tools/video-generate-tool.ts (modified, +1/-1)