A session that finishes is not a session that helped. The agent ran, the tokens accrued, a commit landed. None of that tells you whether the work was worth keeping. The most honest outcome measure we have found is quieter: are the lines the agent changed still on the branch a few days later. "It ran" is not "it helped" Most ways of counting an agent's work measure motion. Session count tells you how many times you opened the door. Commit count tells you how many times something got far enough to save. Both go up whether the work lasts or not. A long, expensive session that gets entirely rewritten the next morning counts exactly the same as one that shipped something you still rely on. Line survival is a different kind of measurement. It asks a narrower question: of the lines an agent wrote, how many are still present on the branch some days later. It is not about volume. It is about what stuck. The honest measure of a run is not that it produced lines, but that the lines were still there when you looked again. How it is computed Seorak derives line survival on your machine. When an agent edits a file, we run a longest-common-subsequence diff against the later state of the branch to see which of those changed lines are still present. We keep the counts, not the code. The diff happens locally, and what ships off the machine is a number, never the lines themselves. Identifiers are salted hashes. The same boundary holds here as everywhere else in Seorak: code and prompts stay on your machine. What you see, then, is plainly an example of the shape: an agent touched some lines in a session, and a few days later a subset of those lines are still there. The stat is the proportion that remained, read alongside the rest of the session record. Why it is a better proxy Set the three counts next to each other and the difference is clear. Measure, What it actually tells you Session count, How often you ran an agent Commit count, How often work got saved Line survival, How much of the work was still there later Sessions and commits both reward activity. Line survival is the only one of the three that can go down when the work was not worth keeping. That is what makes it a better stand-in for value. It is closer to the thing you actually care about, which is not how much the agent did but how much of it you kept. Short-lived code is a studied liability This is not only our intuition. Code that is reverted or rewritten soon after it is written has been studied as a quality risk for a long time. Relative code churn, change weighed against the size and history of a component, predicts where defects concentrate. One Windows Server 2003 study separated fault-prone from clean binaries with around 89 percent accuracy on churn measures, where the raw volume of change alone did not. The lines that do not last are the ones worth watching. There is reason to think the problem is growing in the AI era too. Defining churn as code reverted or updated within two weeks of being written, GitClear projected that churn would roughly double in 2024 against its 2021 pre-AI baseline. A later reading across roughly 211 million changed lines found copy-pasted lines rising from 8.3 percent to 12.3 percent between 2021 and 2024, while refactored lines fell from a quarter of changes to under a tenth. We read those as a witness to the shape of the problem, not a measurement of any one session. They say short-lived code is real, it is studied, and it appears to be rising. They say nothing about your sessions. That is what the record is for. The caveat, plainly Line survival is a proxy, not a verdict. The churn research above leans on full version history, reverts and rewrites included. Seorak's reading is lighter than that, and it is worth being exact about what it cannot see. It is revert-blind. It sees that lines are still present. It does not know whether you quietly reverted the work and rebuilt it by hand, or whether the lines that survived are the right ones. It is on-branch only. If the change was moved, rewritten elsewhere, or carried to another branch, that history is outside what this reading covers. So a high survival number does not mean the work was good, and a low one does not always mean it was wasted. Sometimes you keep bad lines for a week and sometimes you throw out good ones the same afternoon. The stat cannot tell those apart, and we would rather say so than dress it up. What it does give you is a check against the easy story that a session helped because it finished. Held next to duration, cost, and whether a run reached a commit, line survival is the part of the record that is least flattering and most useful. It is the line item that remembers what you actually kept. A run ending is a fact about the agent. What is still on the branch a few days later is a fact about the work.