Skip to main content

Module file_store

Module file_store 

Source
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_file is 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.

Structs§

FileEntry
One captured file snapshot.
FileStore
Process-local file content store.