Serves language-model responses from a frozen fixture file.

Evaluation needs a workflow LLM whose answers do not move between a baseline run and a candidate run, otherwise a behavioural difference cannot be attributed to the candidate. This is an installed host source rather than an Elixir test callback so an evaluation recipe stays ordinary configuration: the same manifest grammar selects a replay provider or a live one, and nothing about the application changes between them.

A fixture file is JSON Lines. Every entry requires "schema_version": 1, a request_hash matching sha256: followed by 64 lowercase hexadecimal characters, and exactly one of response or responses. response is one JSON object. responses is an ordered, non-empty sequence of at most 1,024 JSON objects. No other entry keys are accepted.

For example, one line is:

{"schema_version":1,"request_hash":"sha256:0000000000000000000000000000000000000000000000000000000000000000","response":{"content":"frozen"}}

The sequence form exists for a request that repeats identically — a retry, or a loop that rebuilds the same prompt — where the first call gets the first element and the next call the next. An ordinary multi-turn agent loop does not need it: each turn carries the accumulated transcript, so each request hashes differently and gets its own entry.

The hash is over the deterministic encoding of the provider-neutral request the workflow actually built, before any provider adapter sees it, so a fixture is not tied to the vendor that recorded it. That also makes the match exact by construction: a run whose prompt, messages, or tools differ at all produces a different hash and fails rather than silently replaying a response recorded for a different question. A normal-data miss reports the computed hash as no replay fixture matches this request (request_hash: sha256:...) in command output and private capability inspection. A private-data run keeps the hash out of its public command diagnostic because the unsalted request hash could reveal equality or permit guesses of low-entropy prompts; author those fixtures from the owner-only inspection record instead. Copy the hash into the entry, provide the response the workflow expects, and rerun.

The provider is owned. Its response cursor lives in a process that monitors the run that acquired it, so a run failing between acquisition and cleanup cannot leave a replay owner behind.

Every failure is closed. An unknown hash, an exhausted sequence, a malformed or oversized response, a duplicate entry, or a fixture past its ceilings all fail the call rather than inventing or reusing a response. Nothing here performs network activity, and the safe snapshot carries the format version, fixture-set hash, entry counts, and ceilings — never a payload or a path.

Load failures name the rule that refused the file. A rejected line reports {reason, line}, and the line number is the number in the file, blank lines counted, so a fixture author can open the file at the offending line. The reason and the number are the only per-line detail that crosses the boundary; the line's bytes never do.