v2.7.0 — Kiro CLI backend

Adds a new LLM backend option: kiro-cli. The daemon can now invoke the Kiro CLI instead of calling Bedrock or OpenAI directly, which is useful when you're running Kiro locally and want the daemon to reuse its agent session.

Changes:

• Add kiro-cli as a supported llm_backend value
• Pass --agent flag to the Kiro CLI invocation to reduce token overhead on repeated calls
• Update project title in README

Config:

[llm_backend]
name = "kiro-cli"

No region or credentials required — the backend shells out to the Kiro CLI binary already installed on the host.

v2.6.0 — Bedrock prompt caching for extraction

Extraction passes now split stable instructions (~2K chars of classification rules, date guidance, and JSON response format) into a cacheable system prompt, matching the pattern consolidation already uses. Bedrock/Anthropic models cache this prefix via cachePoint, so repeated extraction passes within the same day avoid re-tokenizing the instruction set.

v2.5.1 — Fix --version reporting

agent-memory-daemon --version was hardcoded to 1.0.0 and never updated. It now reads the version from package.json at runtime, so it stays in sync with npm automatically.

v2.5.0 — prompt quality improvements

Prompt quality improvements

• Line-boundary-aware truncation — cuts at the last newline before the budget instead of mid-line, producing cleaner prompts
• Memory age in manifest — each entry now shows (today), (yesterday), or (N days ago), helping the LLM decide whether to update stale memories vs create new ones
• AbortSignal threading — buildExtractionPrompt now accepts an optional signal, allowing prompt building to bail out during daemon shutdown

Test coverage

• Property-based guardrail tests (maxMemoryFiles cap, maxPromptChars budget, maxFilesPerBatch cap, per-session cursor)
• Preservation property tests (update ops unaffected, validation unchanged, dry-run preserved)
• 248 tests passing

v2.4.0 — Extraction guardrails & cost-optimized defaults

What's new

Extraction guardrails — The extraction engine now enforces hard caps to prevent runaway growth:

• maxMemoryFiles — total memory file count capped (default: 50)
• maxFilesPerBatch — file creations per extraction pass capped (default: 10)
• maxPromptChars — prompt assembly truncated when over budget (default: 40K)
• Per-session cursor replaces the global-timestamp cursor, so already-processed sessions aren't re-sent to the LLM

Post-consolidation orphan sweep — After consolidation rebuilds the index, any .md files not referenced in the index are automatically deleted. No extra LLM calls — pure filesystem cleanup.

Cost-optimized defaults — All content and frequency defaults tuned for Haiku-class models:

Setting	Before	After
max_prompt_chars	120,000	40,000
max_memory_files	100	50
max_files_per_batch	30	10
max_session_content_chars	2,000	1,000
max_memory_content_chars	4,000	2,000
max_extraction_session_chars	5,000	2,000
min_hours	24	48
min_sessions	5	8

Projected cost on Claude Haiku 4.5: ~$0.25/month for a single-agent setup.

Testing

249 tests passing, including 7 new property-based tests covering guardrail enforcement and preservation of existing behavior.

v2.3.0 - Batch Consolidation & Token Efficiency

Large memory sets are now split into smaller LLM prompts via chunk-based processing, with optimizations to minimize token costs across multi-chunk passes.

New

• Chunk-based consolidation: ChunkPlanner partitions memory files respecting maxPromptChars and maxFilesPerBatch limits
• ChunkMerger with last-chunk-wins strategy and order preservation
• Prompt caching support for Bedrock (Anthropic cachePoint) and OpenAI (system/user message split)
• Pre-computed shared context eliminates redundant filesystem reads per chunk
• Config: max_prompt_chars (default 120K) and max_files_per_batch (default 30)

Changed

• Default maxPromptChars raised from 60K to 120K
• LlmBackend.consolidate() accepts optional ConsolidateOptions with systemPrompt
• ConsolidationResult now includes chunksTotal and chunksCompleted

Testing

• 231 tests across 21 files, including 10 property-based tests

v2.2.1 — Increase Bedrock request timeout for large prompts

Fixes timeout errors when processing large consolidation/extraction prompts (50K-100K+ chars) against Bedrock.

What changed

• Added explicit NodeHttpHandler with configured timeouts:
  • connectionTimeout: 10 seconds (establish TCP connection)
  • requestTimeout: 5 minutes (wait for LLM response)
• The AWS SDK v3 has no default request timeout, but the underlying HTTP agent can close idle sockets prematurely. The explicit handler ensures long-running Converse API calls complete successfully.

Why

Large prompts (e.g. 94K chars from 35 session files) can take several minutes for the LLM to process and respond. Without an explicit timeout configuration, the request could be terminated prematurely by the default socket behavior.

v2.2.0 - Bedrock backend rewritten to use AWS SDK

Replaces the raw fetch + manual SigV4 signing implementation with @aws-sdk/client-bedrock-runtime. This fixes "fetch failed" errors in container environments (ECS, AgentCore) where the raw HTTP approach couldn't connect to Bedrock endpoints.

What changed

• Bedrock backend now uses BedrockRuntimeClient and ConverseCommand from the official AWS SDK
• Removed ~250 lines of manual SigV4 signing, credential resolution, and INI profile parsing
• The SDK's default credential provider chain handles env vars, ~/.aws/credentials, SSO, ECS container credentials, EC2 IMDS, and more — out of the box
• Region falls back to AWS_REGION / AWS_DEFAULT_REGION env vars when not set in config

Why

The previous implementation used Node.js fetch directly to call the Bedrock Converse API with hand-rolled SigV4 signatures. This worked locally but failed in container environments due to IPv6 DNS resolution, network routing, and TLS issues that the AWS SDK handles internally.

New dependency

• @aws-sdk/client-bedrock-runtime (peer dependency of the AWS SDK v3 ecosystem)

v2.1.1 — Container compatibility fixes

Fixes Bedrock API connectivity in container environments (ECS, AgentCore, EC2).

Bug fixes

• Force IPv4-first DNS resolution for Bedrock API calls. Node.js fetch (undici) defaults to IPv6, which fails in container environments that lack IPv6 routes to AWS endpoints.
• Expand credential chain to support ECS/AgentCore container credentials (AWS_CONTAINER_CREDENTIALS_RELATIVE_URI) and EC2 instance metadata (IMDSv2).
• Fall back to AWS_REGION / AWS_DEFAULT_REGION env vars when region is not set in config.

What was happening

The daemon initialized successfully (credentials resolved, sessions scanned, prompt built) but the actual HTTP call to Bedrock failed with "fetch failed". This was caused by Node.js attempting IPv6 DNS resolution first in environments without IPv6 connectivity.

v2.0.0 — Memory Extraction

Full Changelog: v1.0.0...v2.0.0

This release adds a second operational mode to agent-memory-daemon: extraction. While consolidation reorganizes and prunes existing memory files on a slow cadence, extraction watches for new session content and runs an LLM pass to identify facts, decisions, preferences, and error corrections worth remembering — writing them as individual memory files.

What's new

• Extraction engine — scans session files for new content, builds a prompt with the current memory manifest, calls the LLM, validates returned operations, and writes new memory files
• Cursor-based tracking — a .extraction-cursor file tracks what's been processed so only new session content triggers extraction
• Mutual exclusion — extraction and consolidation never run concurrently; consolidation takes priority when both triggers fire on the same tick
• Rate limiting — configurable minimum interval between extraction passes (default 60s, minimum 10s)
• Dry run support — set dry_run = true to preview what extraction would do without writing files

Configuration

Three new TOML keys:

extraction_enabled = true           # default: false
extraction_interval_ms = 60000      # default: 60000, minimum: 10000
max_extraction_session_chars = 5000  # default: 5000

Testing

17 property-based tests (fast-check) and unit tests covering all extraction components. 197 total tests passing.

---

Want me to create this as a GitHub release on the v2.0.0 tag?