Flow
Where the paging tools need work
1Copy once
Today every reply copies the full cache back to the GPU while the flag is on.
2Record the adapter
A specialist can answer on a cache the main adapter built, with no error.
3Limit and persist
Snapshots pile up in RAM with no cap and vanish on restart.
4Teach restraint
The training examples only show when to page, never when to skip it.
5Test recall
Plant a fact, save, clear, restore, and check the fact comes back.
The save button I gave my coding agent takes one photo of its working memory and then shows the model that same photo on every turn until something tells it to stop.
The model behind the agent can only hold so much conversation. What it has read sits on the GPU as a cache, so it doesn't have to reread the whole prompt for each new word. When I switch from a long database session to frontend work, I either drag the old talk along or lose it.
So I added three tools the model can call itself. Save turns the conversation into a cache, moves it to system RAM under a name, and frees the GPU. Clear wipes the history. Restore brings a saved cache back.
Restore only flips a switch
Restore doesn't move anything. It sets a flag. The real copy back to the GPU happens on every reply while the flag is on, and only clear turns it off. So a restored snapshot is frozen, since nothing new gets added to it, and it costs a full copy on every turn. Without a snapshot, the normal path rebuilds the prompt and reads it all again every turn, so the choice is a full reread or a full copy, every turn. If I kept it, I'd copy once at restore and hold it on the GPU until clear.
The specialist reads the manager's photo
The agent can also hand a question to a specialist adapter, a small add-on that changes how the model thinks. That goes through the same reply code. If a snapshot is on at that moment, the specialist answers on top of a cache the main adapter built. Nothing throws an error, because the sizes match. I suspect you'd get a confident wrong answer. I haven't seen it, but nothing stops it. If you build something like this, record which adapter made each snapshot and refuse to restore under a different one.
I taught the model when to page with a small set of hand-written examples: done with a topic, save and clear; asked about it again, restore. None show when to leave the tools alone, so I'd guess it pages too often.
The recall test I don't have
The test script just feeds prompts and prints answers. It never checks that a restore brings anything back. The test I'd write is plain: tell it a fact, save, clear, check the fact is gone, restore, and ask for it. Until something like that passes, I can't say the feature works.
A second memory that writes things down
I also added a plain memory store that keeps notes as text, finds them by meaning, and saves them to a file. The paging tools keep a cache in RAM only, with no limit, and lose it all on restart. I trust the text store more.
Saving has a catch too. It reads the whole conversation on the GPU first, so it needs the very memory it's trying to free.