Replaying a coding session token by token is mostly noise. You sat through it once. Watching the whole thing again, slower, does not teach you much. What teaches you is the handful of moments where something turned. So Seorak does not keep a recording. It keeps keyframes: the few points in a past session worth going back to, and nothing in between. Why a full transcript fails you A transcript is honest in the dullest way. It contains everything, which means it contains almost nothing useful per minute. If a session ran for two hours, re-reading two hours of tool calls and retries to find the moment the cost jumped is worse than not looking at all. You will not do it twice, so you will not do it. The thing you actually want is small. When did the first error show up. Where did the real commit land. Where did the run burn fastest. Where did a verification first fail. Those are questions with specific answers, and the answers are almost never spread evenly across the timeline. They sit at a few timestamps. Learning from a past session is about a few moments that turned, not a recording you sit through again. The keyframes Seorak marks Seorak picks out a small set of moments per session and lets you jump straight to them: First error. The point the run first went sideways, which is usually where the interesting decision was. Biggest commit. The largest piece of work that actually reached the branch, not the largest piece of activity. Peak burn. The highest-cost window across the run's ordered tool calls, so you can see what the agent was doing when it got expensive. Verification failed. The first verification run that came back failing, which is the moment the work stopped agreeing with its own checks. These come from stats Seorak already derives on your machine: session state, duration, token count and the cost from it, stalls and retry loops, whether the run reached a commit. The keyframe is just a pointer at the moment a stat changed. Code and prompts stay on your machine. Identifiers are salted hashes. Seorak is pointing at when something happened, not reading what your code said. An example of what the set looks like for one session, with plain example values, not a measured benchmark: Keyframe, Roughly when First error, early, a few minutes in Peak burn, mid-session Biggest commit, mid-session Verification failed, late, near the end of a long run Four points. You can read all of them faster than you can scrub one minute of a transcript. The honest limitation This is the part to be clear about. Keyframes are not a full recording, and you cannot reconstruct the whole session from them. If the moment you care about was not one of the marked ones, replay will not surface it. That is a real tradeoff, and we made it on purpose. The bet is that for going back and understanding a past session quickly, the few moments that turned are worth more than the complete tape you will never finish watching. A recording optimizes for completeness. Review optimizes for the points where something changed. Those are different goals, and only one of them respects your time a week later. There is also a limit on the moments themselves. A peak burn tells you cost concentrated there, and roughly what the run was doing. It does not tell you whether the burn was the agent thrashing or the agent doing genuinely hard work. That read is still yours. Seorak gets you to the moment fast. It does not decide for you what the moment meant. So replay here is short by design. You open a session, see four or five marks on a timeline, and go to the one that matters. The rest of the run stays where it was, unwatched, and that is fine.