The session that hurts most is not the one that runs up a bill. It is the one that sits there, retrying the same fix, while the clock keeps moving and nothing lands. A big cost shows up on its own. You feel it. A stall is quieter. The agent looks busy. The terminal is scrolling. But the work has stopped going anywhere, and the only thing accumulating is time. That it goes unnoticed is not carelessness. Missing an automated run's quiet failure while your attention is on other work is a documented attention problem, the kind that shows up in experienced people as well as in new ones and does not wash out with practice. What a stall looks like in the record Seorak does not read what the agent is doing. It reads a handful of stats coming off the session and watches how they move together. A stall has a shape in those readings: The state sits in stuck and stays there. Not a blip, a plateau. A retry loop: the same fix attempted again, then again, with no new ground covered. Duration climbing while the run has not reached a commit. Time passing, no commit movement underneath it. None of those alone is proof. A long run is sometimes just a long run. A retry is sometimes the second attempt that works. The stall is the pattern of them together: state flat, retries stacking, the clock advancing past where progress should have shown up. The worst session is not the expensive one. It is the one that stopped moving an hour ago and is still typing. Why the moment beats the postmortem You can find a stall after the fact. The replay keyframes will show it: the first error, then the same fix circling, then a long flat stretch with no commit at the end. That is a useful read. It is also too late to change anything. The hour is already spent. And catching it live by watching is the wrong job to hand a person. Staring at a long, low-event run for the one minute it stops converging is exactly the monitoring task attention is weakest at, which is the old case for letting an automatic alarm watch for the rare event instead of leaning on vigilance. Catching it while it is happening is a different thing entirely. It is the difference between learning you idled and being able to step in. Read the diff yourself. Reword the prompt. Stop the run and take over. The decision is yours, but you only get to make it if you know in time. So when the readings line up, Seorak says so plainly, in the moment, on whichever surface you are near. Terminal, web, or phone. Something like: Your agent has been retrying the same fix for 25 minutes. No softening, no guessing at your feelings. A direct statement of what the readings show, while you can still act on it. What this is, and what it is not The honest part: this is heuristic. Seorak builds the stall from stats, not from understanding the code. It does not know whether the fix is wrong. It knows the run is in stuck, the same attempt keeps coming back, and the clock has outpaced any commit. That is a strong tell, but it is a tell, not a verdict. Which means it can be wrong in both directions: Case, What Seorak sees, What is actually true False stall, Long flat run, no commit, A hard problem genuinely in progress Missed stall, Activity that looks like motion, Churn that never converges The retry loop is the strongest tell, because real progress rarely repeats itself the same way. A run that keeps returning to the same fix is usually circling, not closing in. Seorak leans on that, and on time without commit movement, and tells you. You decide whether it is right. All of this stays on your machine. Seorak derives the counts and the state locally and ships only the stats. The code the agent is retrying, and the prompt that set it loose, never leave. The identifiers are salted hashes. What crosses the wire is "this run is stuck, retrying, twenty-five minutes in," and nothing about what the fix says. A stall costs the same tokens whether you notice at minute three or minute thirty. The only variable is how long it runs before someone looks up. That is the part Seorak is trying to shorten.