Sessions and memory

Recommended setup

Start with recent:

json5
{  plugins: {    entries: {      "active-memory": {        enabled: true,        config: {          agents: ["main"],          mode: "escalate",          queryMode: "recent",          promptStyle: "balanced",          timeoutMs: 15000,          maxSummaryChars: 220,          logging: true,        },      },    },  },}

Use /verbose on for the status line and /trace on for the debug summary while tuning — both are sent as a follow-up after the main reply, not before. Use always only when every eligible turn warrants the latency. Keep escalate for the recommended balance, then choose message, recent, or full for the deep-recall query itself.

Cold-start grace

Before v2026.5.2 the plugin silently extended timeoutMs by an extra 30000 ms during cold start, so model warm-up, embedding-index load, and the first recall could share one larger budget. v2026.5.2 moved that grace behind an explicit setupGraceTimeoutMs config: timeoutMs is now the recall-work budget by default unless you opt in. The blocking hook wraps that budget in two fixed phases: up to 1500 ms for session/config preflight before recall starts, then a separate fixed 1500 ms for abort settlement and transcript recovery after recall work stops. Neither allowance extends model or tool execution.

If you upgraded from v2026.4.x and tuned timeoutMs for the old implicit-grace world (the recommended starter timeoutMs: 15000 is one example), set setupGraceTimeoutMs: 30000 to restore the pre-v2026.5.2 effective budget:

json5
{  plugins: {    entries: {      "active-memory": {        config: {          timeoutMs: 15000,          setupGraceTimeoutMs: 30000,        },      },    },  },}

Worst-case blocking time is timeoutMs + setupGraceTimeoutMs + 3000 ms (the configured recall-work budget, plus up to 1500 ms preflight, plus a fixed 1500 ms post-recall completion allowance). The embedded recall runner uses the same effective timeout budget, so setupGraceTimeoutMs covers both the outer prompt-build watchdog and the inner blocking recall run.

For resource-tight gateways where cold-start latency is an accepted trade-off, lower values (5000-15000 ms) work too — the trade-off is a higher chance of the very first recall after a gateway restart returning empty while warm-up finishes.

Was this useful?
On this page

On this page