feat(openclaw-plugin): add captureMinLength config to reduce unnecessary VLM token consumption

[yingriyanlong]

Problem

The auto-capture feature triggers VLM extraction (deepseek-chat) for almost every user message, including trivially short ones (as low as 4 CJK chars / 10 EN chars). In multi-agent setups with high interaction volume, this leads to excessive API calls and token consumption.

Observed impact: 100K+ deepseek-chat API calls in 2 days from a 10-agent setup due to aggressive capture thresholds.

Solution

Add a configurable captureMinLength option (default: 50 chars) that sets a minimum sanitized text length for triggering auto-capture. Messages shorter than this threshold are skipped (reason: length_out_of_range), avoiding unnecessary VLM calls.

The new threshold works as a floor:

const minLength = Math.max(resolveCaptureMinLength(compactText), captureMinLength);

This preserves the existing CJK/EN-aware minimum while allowing users to set a higher bar.

Changes

File	Change
config.ts	Add captureMinLength type, default (50), allowed key, resolve (clamped 1..1000), UI hint
text-utils.ts	Update getCaptureDecision signature, use Math.max to combine with built-in minimum
index.ts	Pass cfg.captureMinLength to getCaptureDecision call

Usage

Default (50 chars) — no config needed. To customize:

{ "captureMinLength": 100 }

Backward Compatible

• Default behavior preserves existing 4/10-char minimums via Math.max
• Existing configs without captureMinLength use the 50-char default
• No breaking changes

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Mac seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[qin-ctx]

[Bug] setAgentId() mutates shared OpenVikingClient state (agentId, resolvedSpaceByScope, runtimeIdentity). In concurrent multi-agent scenarios, async handlers interleave at await points (e.g., client.find() → normalizeTargetUri → resolveScopeSpace). For example:

1. Agent A's handler calls setAgentId("A"), then await client.find() (HTTP in-flight)
2. Agent B's handler fires, calls setAgentId("B"), clearing cached resolvedSpaceByScope
3. Agent A's find() resumes — resolveScopeSpace now uses this.agentId = "B", deriving the wrong agent_space

This causes memories to be stored in / retrieved from the wrong agent's space. The same issue exists in the agent_end handler below (line 491).

Consider either:

• Creating a per-agent client instance (e.g., clone with agent-specific ID) instead of mutating shared state
• Passing agentId as a parameter through find()/request() so each call is self-contained

[qin-ctx]

[Bug] lastProcessedMsgCount (line 484) is a closure variable shared across all agents. In multi-agent setups each agent has its own message history, but this counter tracks a single global position. After Agent A's agent_end processes 10 messages (lastProcessedMsgCount = 10), Agent B's agent_end calls extractNewTurnTexts(messages, 10) — if B's message array has fewer than 10 elements, no new texts are extracted and B's memories are never captured.

Consider using a Map<string, number> keyed by agentId to track per-agent message positions:

const lastProcessedMsgCountByAgent = new Map<string, number>();
// in handler:
const agentKey = hookAgentId ?? cfg.agentId;
const lastCount = lastProcessedMsgCountByAgent.get(agentKey) ?? 0;
// ... after processing:
lastProcessedMsgCountByAgent.set(agentKey, messages.length);