A session leaves the same trace no matter where you look at it. Seorak keeps one record per session and shows it in the place that fits what you're doing, instead of asking you to open a dashboard. The record is small and the same everywhere: session state, duration, token count and the cost derived from it, stalls and retry loops, whether the run reached a commit, whether the lines it changed were still on the branch later, and a few replay keyframes worth revisiting. That record is built on your machine. Counts and state are derived locally and only those stats ship. Code and prompts stay put. The interesting decision was never what to capture. It was where to put it. The terminal is where you already are When a session is running, you are usually in the terminal. So that is where live state belongs: is the run active, idle, stuck, or waiting on you, how long has it gone, what has it cost so far. No new window, no context switch. You glance, you keep going. The terminal read ships. seorak speaks the window in prose and opens the door to the dashboard. It was the last of the reading surfaces to arrive, which is worth remembering when the rest of this reads as though the shape had been obvious from the start. The web is for the slow look Some questions do not belong mid-session. Where did this run actually stall? What were the keyframes, the first error, the biggest commit, the peak throughput, the cost spike? Did the lines from last week's session survive on the branch, or did they get rewritten? That is the deep read, and it wants a screen with room. The web surface is the history: outcomes over time, replay keyframes, the longer pattern of when your sessions tend to last versus churn. This is distributions, not a verdict. Seorak reads stats, not your code and not you. It can show you that runs past a certain length tend to produce lines that get rewritten. It cannot tell you that you are good or bad at anything, and it does not try. The menu bar watches one number There is a fourth surface with the narrowest job of all: a menu bar item that watches usage headroom, so the question of how much room is left this window does not require opening anything. It is built and it is not released, so treat it as a stated part of the shape rather than something you can go and install. Mobile is ambient, on purpose The phone has the smallest job and the most specific one. It carries live state when you have stepped away, and it surfaces a needs-you nudge when a session has stalled, looped, or run unusually long and hot. That is it. The record is one thing. The surfaces are windows onto it, each sized to the moment you are in. Be clear about what mobile is not. It is not a pocket dashboard. You will not scroll history or pull replay on it. It is live state plus the notice that says: this run wants your attention, or this run is fine and you can stay away. The value is the timing, not the screen. One record, read four ways Surface, Its job Terminal, Live state and the window in prose, while you work Web, History, keyframes, outcomes Mobile, Ambient state plus a needs-you nudge Menu bar, Usage headroom, built and not yet released None of these screens is the product. A live state readout exists elsewhere. History views exist elsewhere. A phone notification is not novel. What is hard to copy is the combination: capture that happens locally, the same record delivered to wherever you actually are, readings that update while a session is still moving, and a nudge that lands at the moment it helps instead of in a writeup the next morning. Any one surface on its own is a feature. What is hard to copy is the set of properties underneath them: local capture, one record delivered wherever you are, readings that move while a session is still running, and a nudge timed to the moment it helps. The record is singular. Where you read it should match what you are doing.