Expand description
In-memory file content store — D3 step 1.
Why this exists: read_file’s content used to live in conversation tool_result messages. Each turn the LLM saw it again at full token cost; compaction stripped it; the model then re-read the same file and burned another full-content roundtrip. Across a 120-turn atomgr session that pattern produced 47 reads on 10 unique files plus three compactions destroying file content (datalog 2026-05-06_10-22-35).
FileStore decouples file content from conversation history. The
model’s read_file ToolResult carries a tiny pointer (store_id
- preview); the actual bytes live here.
peek_fileis a separate tool that fetches regions from this store with zero disk hits. Compaction touches only pointers; content survives.
Lifecycle: process-local (no persistence yet — that’s D3b). Path
invalidation fires on edit_file / write_file success so a
stale store_id cannot serve outdated bytes.