A Seven-Hour Session With 390 Prompts and No Record

At 10:20 one morning, we opened a work session with a two-sentence request containing three typos, because the idea had arrived faster than we could type it. By then we had 35 open work sessions and no reliable way to tell which ones still mattered. That meant we could not tell which answer was current, which work had already been done, or what needed attention next.

How the counter filled up

It began the way a kitchen counter fills up. We opened one work session, then another. Some were investigating a problem. Some were carrying out a task. Some were there because we wanted to check one small thing before we forgot. We treated them like browser tabs. If a window was still open, we assumed it might still be useful.

That worked for a while. It stopped working somewhere around five or six open sessions. At 35, it was a pile.

One session lasted seven hours and took 390 prompts, or back and forth messages, while it worked on a way to keep session information and written notes in sync. Another had been opened late at night to recover work after an earlier conversation lost its place. Three were unnamed one-prompt tests that produced nothing more than a quick confirmation. They were open windows that we kept counting as part of the job because we had no better record.

Memory was the first fix, and it failed

We looked at the windows, remembered what we thought they were for, and assumed the ones we could see were the ones that mattered. A session from the morning could hold one answer about a setting, while a session from the afternoon had gone another direction. Without a clear handoff, we could not tell which answer should win.

That cost time. During one stretch that morning, four separate sessions worked on the same setup problem. The last one took 98 prompts, longer than the first three put together, and it had no record of what the earlier work had already settled. Nothing malfunctioned. We were paying for the same thinking more than once, and losing the patience that comes from knowing where things stand.

What the 10:20 request asked for

The request was for three things. We needed a dashboard. We needed the written notes to match reality. We needed to know what was open and what each open session was actually doing.

That first attempt did not solve the problem either. It took 41 prompts and 26 minutes just to put the questions into words. But it gave us the list we had been missing. For every open session: Is it active? What job did it claim? Where is it working? When did it last do anything real?

A record for every session

The answer was a SessionStart hook, a small command that runs whenever a new work session opens. Its only job was to create a short record for each session with a start time, the device it came from, the folder it was working in, and the particular version of the project it had claimed. It did not make decisions or try to understand the work. As work continued, that record could be updated with a plain label, a status such as active or idle, and the time of its last real activity.

Those records feed a simple dashboard. Instead of treating open windows as the truth, we could see current sessions grouped by project, their status, and when they had last been active. A session opened from a phone could be told apart from one opened at a desk. A three-minute test could be seen for what it was, and the dashboard made the test sessions visible enough to close.

There is now a regular check on the records as well. It points out sessions that still say active after hours of no activity, work that claims one project while the written record says another, and gaps that do not fit the job a session said it was doing. The check saves attention for the moments when a person actually needs to decide something.

What can’t be repaired

Some of that day cannot be fixed. The seven-hour session that helped build this system was itself one of the sessions we were trying to understand. Its earlier hours were not recorded in the new way. We can only piece them together from old conversation exports and change history. There is no going back and adding a record at the moment work began.

A tool can help keep the list, but it cannot decide what deserves our time. We still have to choose whether an old session is worth reopening, whether a task has changed, and whether it is time to stop.

The hook does not know which of the 35 sessions deserved to stay open. It only knows when each one started, where, and under what claimed project, which is exactly the gap that let one setup problem burn 98 prompts on its fourth pass instead of its first. That is still worth having. A record that says a session has been idle since 9am is a smaller thing to check than a screen of 35 windows, and small things get checked.

If you run AI work yourself, or a vendor runs it for you, ask whether each open task has a name, a start time, a claimed project and a last-activity time. A simple record per session makes idle and duplicate work visible enough to close. Deciding which work deserves attention still takes a person.

dxdev LESSON · paste into your AI coding agent
LESSON: Open work needs a record written by the tooling at the moment it starts, because memory of what each window was for does not scale past a handful
SOURCE: dxdev.com/everyday-ai/thirty-five-open-sessions
WHAT HAPPENED: Over one day, 35 AI work sessions were left open and treated like browser tabs, with no reliable way to tell which still mattered. One session ran seven hours and 390 prompts, and three were unnamed one-prompt tests. Four separate sessions worked on the same setup problem in one morning, and the last took 98 prompts, longer than the first three combined, with no record of what the earlier ones had settled. The fix was a SessionStart hook that writes a short record for each session (start time, device, folder, claimed project), later updated with a label, a status, and the time of last real activity, feeding a dashboard grouped by project. A regular check flags sessions still marked active after hours of no activity and sessions whose claimed project disagrees with the written record.
THE RULE: Every open unit of work needs a name, a start record, a status, and a last real activity time written by the tooling when it starts, so which work is current is read from a record and not remembered.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any workflow that opens long lived AI or work sessions with no automatic record of start time, folder, project, and claimed job.
  2. Any status such as active or idle that is set by hand, or that never changes when no activity has been recorded.
  3. Any two open sessions working on the same problem with no shared handoff note of what the first one already settled.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.