Skip to main content

Enumeration: EWorkingMemoryStrategy

Defined in: internal/working-memory/types.ts:164

The ways a thread's history reaches the model.

IWorkingMemoryConfig.strategy names the gateway's default, IAIProfile.workingMemory overrides it per profile; WorkingMemory resolves the two for every call.

Enumeration Members​

SLIDING_WINDOW​

SLIDING_WINDOW: "SLIDING_WINDOW"

Defined in: internal/working-memory/types.ts:194

The latest turns verbatim, no summary, no helper model call.

What ChatGPT and Claude do: the model reads the conversation itself, not a digest of it.

Pros:

  • Precise: the model sees the exact words, numbers and code of the last turns, nothing is paraphrased away.
  • No helper call: no cheap-model cost, no background job, no summary that can be wrong.
  • Lowest latency to a correct memory: a fact stated one turn ago is there, not waiting for an update.
  • Nothing stored: no thread state to maintain, reset or leak.

Cons:

  • The input tokens grow with the thread until the window is full; every call pays for the whole tail.
  • Hard forgetting: a turn that falls off the window is gone for the model, with nothing standing in for it.
  • Long threads crowd the knowledge base: chatHistoryRatio is the only brake.
  • getThreadMemory has nothing to show the user; the query rewriter gets no thread context.

Use it when:

  • the exact wording matters: coding help, contract or document review, quoting the user back;
  • threads are short-lived: a widget that answers a few questions, a form assistant;
  • the model has a large window and the per-call cost is not the concern;
  • no "what do you remember" UI is wanted.

Do not use it when:

  • threads run for days or hundreds of turns: every call pays for the tail, and what falls off is lost for good;
  • the knowledge base must dominate the prompt (RAG assistants): the history competes with the chunks;
  • a small-window or expensive model is used;
  • the product shows or resets the thread memory.

SUMMARY_BUFFER​

SUMMARY_BUFFER: "SUMMARY_BUFFER"

Defined in: internal/working-memory/types.ts:224

A rolling summary + facts written by the cheap model, followed by the last recentTurns turns verbatim.

Long threads stay cheap: everything older than the tail is one short digest.

Pros:

  • Bounded input: the summary is capped, the tail is fixed, so a 500-turn thread costs like a 20-turn one.
  • Soft forgetting: what left the tail lives on in the summary and the facts.
  • Visible memory: getThreadMemory shows the user what the gateway remembers; resetThreadMemory clears it.
  • The facts feed the knowledge-base rewriter (QueryRewriter) with the thread's context.

Cons:

  • A helper call after every updateEveryTurns turns: cheap-model cost and a background job per answer.
  • Lossy: the digest drops wording and detail, and a wrong summary misleads every later call.
  • Stale by one update: the summary runs in the background, so the digest lags the newest turns.
  • Short threads pay for a summary they never needed.

Use it when:

  • threads are long-lived: support cases, personal assistants, agents that run for many steps;
  • the cost per call must stay flat whatever the thread length;
  • the product shows the thread memory to the user or lets him reset it;
  • the knowledge-base rewriter should know the thread's context (the facts feed it).

Do not use it when:

  • the model must see the exact words of earlier turns: a paraphrase is a bug there;
  • threads are a handful of turns: the helper call is pure overhead;
  • a fact stated one turn ago must be available at once: the summary lags one background update;
  • no cheap model is configured or budgeted for the helper calls.