​

Context Engine

​

Quick start

fluffbuzz doctor
# or inspect config directly:
cat ~/.fluffbuzz/fluffbuzz.json | jq '.plugins.slots.contextEngine'

​

Installing a context engine plugin

# Install from npm
fluffbuzz plugins install @martian-engineering/lossless-claw

# Or install from a local path (for development)
fluffbuzz plugins install -l ./my-context-engine

// fluffbuzz.json
{
  plugins: {
    slots: {
      contextEngine: "lossless-claw", // must match the plugin's registered engine id
    },
    entries: {
      "lossless-claw": {
        enabled: true,
        // Plugin-specific config goes here (see the plugin's docs)
      },
    },
  },
}

​

How it works

1. Ingest — called when a new message is added to the session. The engine can store or index the message in its own data store.
2. Assemble — called before each model run. The engine returns an ordered set of messages (and an optional systemPromptAddition) that fit within the token budget.
3. Compact — called when the context window is full, or when the user runs /compact. The engine summarizes older history to free space.
4. After turn — called after a run completes. The engine can persist state, trigger background compaction, or update indexes.

​

Subagent lifecycle (optional)

• onSubagentEnded — clean up when a subagent session completes or is swept.

​

System prompt addition

​

The legacy engine

• Ingest: no-op (the session manager handles message persistence directly).
• Assemble: pass-through (the existing sanitize → validate → limit pipeline in the runtime handles context assembly).
• Compact: delegates to the built-in summarization compaction, which creates a single summary of older messages and keeps recent messages intact.
• After turn: no-op.

​

Plugin engines

export default function register(api) {
  api.registerContextEngine("my-engine", () => ({
    info: {
      id: "my-engine",
      name: "My Context Engine",
      ownsCompaction: true,
    },

    async ingest({ sessionId, message, isHeartbeat }) {
      // Store the message in your data store
      return { ingested: true };
    },

    async assemble({ sessionId, messages, tokenBudget }) {
      // Return messages that fit the budget
      return {
        messages: buildContext(messages, tokenBudget),
        estimatedTokens: countTokens(messages),
        systemPromptAddition: "Use lcm_grep to search history...",
      };
    },

    async compact({ sessionId, force }) {
      // Summarize older context
      return { ok: true, compacted: true };
    },
  }));
}

{
  plugins: {
    slots: {
      contextEngine: "my-engine",
    },
    entries: {
      "my-engine": {
        enabled: true,
      },
    },
  },
}

​

The ContextEngine interface

• messages — the ordered messages to send to the model.
• estimatedTokens (required, number) — the engine’s estimate of total tokens in the assembled context. FluffBuzz uses this for compaction threshold decisions and diagnostic reporting.
• systemPromptAddition (optional, string) — prepended to the system prompt.

​

ownsCompaction

• true — the engine owns compaction behavior. FluffBuzz disables Pi’s built-in auto-compaction for that run, and the engine’s compact() implementation is responsible for /compact, overflow recovery compaction, and any proactive compaction it wants to do in afterTurn().
• false or unset — Pi’s built-in auto-compaction may still run during prompt execution, but the active engine’s compact() method is still called for /compact and overflow recovery.

• Owning mode — implement your own compaction algorithm and set ownsCompaction: true.
• Delegating mode — set ownsCompaction: false and have compact() call delegateCompactionToRuntime(...) from fluffbuzz/plugin-sdk/core to use FluffBuzz’s built-in compaction behavior.

​

Configuration reference

{
  plugins: {
    slots: {
      // Select the active context engine. Default: "legacy".
      // Set to a plugin id to use a plugin engine.
      contextEngine: "legacy",
    },
  },
}

​

Relationship to compaction and memory

• Compaction is one responsibility of the context engine. The legacy engine delegates to FluffBuzz’s built-in summarization. Plugin engines can implement any compaction strategy (DAG summaries, vector retrieval, etc.).
• Memory plugins (plugins.slots.memory) are separate from context engines. Memory plugins provide search/retrieval; context engines control what the model sees. They can work together — a context engine might use memory plugin data during assembly.
• Session pruning (trimming old tool results in-memory) still runs regardless of which context engine is active.

​

Tips

• Use fluffbuzz doctor to verify your engine is loading correctly.
• If switching engines, existing sessions continue with their current history. The new engine takes over for future runs.
• Engine errors are logged and surfaced in diagnostics. If a plugin engine fails to register or the selected engine id cannot be resolved, FluffBuzz does not fall back automatically; runs fail until you fix the plugin or switch plugins.slots.contextEngine back to "legacy".
• For development, use fluffbuzz plugins install -l ./my-engine to link a local plugin directory without copying.