Working notes
Why our copilot forgets by lunchtime
A working note on why the assistant that helped you all morning is somehow a stranger by 2pm — and what that says about how these things are stitched together.
You spent the morning walking your assistant through a fiddly refactor. It followed. It asked good questions. By 11am it was answering back with the names of your variables and — briefly — the vibe of your codebase. Then you came back from lunch and it had forgotten which framework you were using.
The technical answer is that context windows have a lot of room and very little memory. The assistant does not know that this conversation is continuous; it re-reads the whole conversation on every turn. If the operator app has decided that only the last thirty minutes are worth re-reading, then the last thirty minutes are all the assistant knows. Everything before is gone in the sense that matters.
This is not a limitation of the model. It's a limitation of the app you're using to talk to the model. The choice of what to keep is a product decision, made by people who are optimising for latency, cost, and how the transcript renders on a smaller screen. It is very rarely made by the person doing the work you are asking about.
You can watch the seam if you know where to look. Ask the assistant something that depends on a decision you made two hours ago, and time how confidently it answers. If it hedges, if it re-proposes an approach you already rejected, if it asks a question you already answered — that is the boundary of its working memory, and it is drawn by an accountant, not by you.
The frustrating part is that the raw material is right there. Nothing was lost in a physical sense; the tokens still exist in a log somewhere, and the model could in principle re-read them. What was lost was the willingness to pay to re-read them on every turn. Memory, in this era, is not a capability problem. It is a budget line.
The consequence, when you do a lot of work with these things, is that the boundary between session and archive matters more than most people notice. A good assistant, in the current era, is one whose operators have decided that your morning's decisions are worth preserving even after lunch. That decision costs money to make and money to hold. It is why some products feel like a colleague and others feel like an eager stranger.
I've started to judge these tools less by how smart they are in a single reply and more by how well they hold a thread across a day. Cleverness is cheap now; continuity is expensive. The product that remembers what we agreed on before lunch is doing something quietly generous, and paying for the privilege.
There is a version of this that gets solved, and it probably looks like durable, user-owned memory that the model consults instead of re-reading a transcript. But that is a harder product than it sounds, because memory that persists is also memory that can be wrong, stale, or embarrassing, and someone has to decide what to forget. For now we are in the awkward middle, where the machine is brilliant and amnesiac in the same breath.
The pragmatic move, until this improves, is to write things down. Not for the model, but for yourself. A single sentence at the end of each session that says: today I decided to keep the auth middleware, we're using X for date parsing, don't touch the layout file. When you come back and the assistant has forgotten, you paste the sentence. Then it remembers.