Memory
How Gajae-Code automatically extracts durable knowledge from past sessions and recalls a compact summary into each new one.
Memory lets Gajae-Code carry knowledge forward across sessions without manual effort. When enabled, the agent retains durable signal from past sessions and recalls a compact, project-scoped summary into each new session — technical decisions, recurring workflows, and pitfalls that would otherwise be re-discovered every time.
Memory is disabled by default. Enable it from /settings or in config.yml:
memories:
enabled: trueWhere memory fits the loop
Memory bookends a session rather than driving it:
- Recall (session start) — if a memory summary exists for the current project, it is injected into the system prompt as a Memory Guidance block.
- Retain (background) — a pipeline runs at startup (or on demand) to extract knowledge from past sessions and consolidate it to disk for the next run.
Memory is treated as heuristic context, not authoritative state. The agent is instructed to:
- use memory for process and prior decisions, not as the source of truth on current repo state,
- cite the memory artifact path when memory changes the plan, and pair it with current-repo evidence before acting,
- prefer repo state and your instructions when they conflict with memory, treating conflicting memory as stale.
Runtime memory artifacts
Generated local memory artifacts are private runtime state. GJC may keep summaries, long-term memory documents, and generated playbooks on disk so future sessions can recall them, but memory:// should be treated as a compatibility route for internal reads rather than a public user contract.
The /memory slash command
| Subcommand | Effect |
|---|---|
view | Show the current memory injection payload |
clear / reset | Delete all memory data and generated artifacts |
enqueue / rebuild | Force consolidation to run at next startup |
How retain works
The retain pipeline runs in two phases at startup or when triggered via the slash command.
Per-session extraction. For each past session that changed since it was last processed, a model reads the session history and extracts durable signal — technical decisions, constraints, resolved failures, recurring workflows. Sessions that are too recent, too old, or currently active are skipped. Each extraction produces a raw memory block and a short synopsis.
Consolidation. A second model pass reads all per-session extractions and writes three outputs to disk:
MEMORY.md— a curated long-term memory document,memory_summary.md— the compact text injected at session start,skills/— reusable procedural playbooks, each in its own subdirectory.
This phase uses a lease so concurrent processes don't double-run, and stale skill directories from prior runs are pruned automatically.
All output is scanned for secrets before being written to disk.
Which models run memory
Memory piggybacks on the model role system:
| Phase | Role | Purpose |
|---|---|---|
| Extraction (phase 1) | default | Per-session knowledge extraction |
| Consolidation (phase 2) | smol | Cross-session synthesis |
If the requested role is not configured, memory model resolution falls back to default, then the active session model, then the first model in the registry.
Configuration
| Setting | Default | Description |
|---|---|---|
memories.enabled | false | Master switch |
memories.maxRolloutAgeDays | 30 | Sessions older than this are not processed |
memories.minRolloutIdleHours | 12 | Sessions active more recently than this are skipped |
memories.maxRolloutsPerStartup | 64 | Cap on sessions processed in a single startup |
memories.summaryInjectionTokenLimit | 5000 | Max tokens of the summary injected into the system prompt |
Additional tuning knobs (concurrency, lease durations, token budgets) are available in config for advanced use. See Configuration for the full surface.