Configuration

All keys live in config/conduit.toml and are read by RewindConfig.fromConfig().

Key	Default	Meaning
rewind_enabled	true	Whether a recording can be armed at all.
rewind_hot_window_seconds	120	How much history is kept in RAM.
rewind_keyframe_seconds	10	Keyframe and state-snapshot interval.
rewind_memory_cap_mb	256	Hot-tier ceiling. Oldest history is evicted past it, with a log line.
rewind_entity_sample_stride	2	Transform sampling stride for mobs and items.
rewind_save_prompt_seconds	60	Match-end save prompt timeout, after which it discards.
rewind_tape_max_count	0	Keep at most this many saved tapes; the oldest are deleted after a save. 0 never prunes.
rewind_tape_max_mb	0	Keep saved tapes under this total; the oldest are deleted after a save. 0 never prunes.

How the knobs trade off

rewind_hot_window_seconds is how far back a host can scrub. Two minutes covers the “that clutch was ruined, take it again” case that rewind exists for. Raising it is the most direct way to spend memory.

rewind_keyframe_seconds controls restore accuracy for the things captured at keyframes rather than per tick, chiefly inventories and slice state. A shorter interval means a scrub lands closer to the true state at that moment, at the cost of more snapshots. Ten seconds is a deliberate middle: player pose is per-tick regardless, so bodies are always exact, and it is inventories that quantise.

rewind_entity_sample_stride is the sampling stride for non-player entity transforms. 2 means every other tick. Raising it saves real memory in mob-heavy games and shows up as slightly coarser interpolation on scrubbed mob positions, which almost nobody notices.

rewind_memory_cap_mb is the backstop. When the hot tier hits the ceiling the oldest per-tick history is evicted and the rewindable floor advances, so the effective window becomes shorter than rewind_hot_window_seconds asked for. This is logged rather than silent, and the log line is the thing to look for when a host reports that they could not scrub back as far as they expected.

Tuning by game shape

A small arena game with few entities can afford a longer window; the per-tick block journal is near-empty when nothing is building.

A build-heavy or chaos-event game generates a large block diff and a lot of entity churn, so it hits rewind_memory_cap_mb far sooner. If hosts there report a short effective window, raise the cap before raising the window, since raising the window alone just evicts faster.

Per-game overrides

RewindConfig.fromConfig() reads the server defaults, but a RewindConfig can be constructed directly and passed to RewindRecorder.start, which is the right move when one game on a shared server has materially different needs from the rest.