Optional, node-local read cache for resolved (decoded) large step results.

When Baton.ResultStore reads a spilled artifact, it gunzips and JSON-decodes the payload. Fan-in and multi-model synthesis steps frequently read the same large upstream result more than once; this cache lets them skip the backend round-trip and the decode on subsequent reads.

The cache is a pure performance layer — the backend remains the source of truth — so a miss, an eviction, or a dropped table only costs a cold read, never correctness. It is off by default; enable it with config :baton, :result_cache_enabled, true.

Keyed by content hash

Entries are keyed by the artifact's sha256, not its storage key. A retried step overwrites the same storage key with potentially different bytes (the Postgres backend upserts on key), so a key-addressed entry could go stale. The sha is content-addressed: different bytes produce a different key and miss the old entry automatically.

Eviction

A single byte budget (Baton.Config.max_cache_bytes/0) bounds the table. When an insert would exceed it, the whole table is flushed and rebuilt cold — deliberately the simplest correct policy. Because the cache is safe to drop, this trades a periodic cold spell for zero eviction bookkeeping; a smarter policy (e.g. sampled LRU) can replace clear/0-on-overflow later without touching callers.

Storage

An owner-less, named, public ETS table created lazily on first write (Baton has no supervision tree of its own; the optional Baton.Plugin merely warms it at startup). Data rows are {sha256, term, byte_size}; a reserved {:__bytes__, n} row tracks the approximate total.