feature · August 8, 2026
Your next chat starts where you stopped
Palim now hands your most recent thread to a new chat as a finished handoff, with no summary to write and no session ID to paste.
Why we built it
Palim could already store a handoff with palim_save_context. Getting it back was the harder half: you needed a search topic or a session ID, so every new chat began with you reconstructing what the last one had figured out.
We measured how bad the gap actually was across 14 days of our own daily work. Of 116 substantial coding sessions, only 20 contained a single save call. And at the start of a new session, the most recent stored state was a median 6.3 hours old.
The cause is not unwillingness, it is fading. A client reads its instructions once, at the beginning. By turn 400 those instructions are far behind, and saving simply stops happening.
What’s new
One call, no arguments
palim_resume takes no arguments. It returns the thread you most recently worked on, already written as a handoff a new chat can act on:
- where the thread stands right now
- the decisions that were already settled
- the open items still waiting
- the files and documents that matter
- up to three other active threads, so your assistant can switch if the newest one is not the one you meant
Short threads are deliberately never skipped. A two line decision such as “Postgres over Mongo” is often the most useful thing in your memory. Only records that carry no content at all are walked past.
A wrong guess costs you nothing
The handoff ends with an explicit instruction: if your first message has nothing to do with the thread, the assistant ignores it silently and answers normally. You never see a wrong continuation, and you are never asked to confirm one.
The record stays current between checkpoints
A chat is one record in Palim, written by two parties that never touch the same field:
| Writer | What it writes | When |
|---|---|---|
| Your assistant | The handoff: state, decisions, open items, references | At every meaningful checkpoint |
| The session hook | The last turn of the chat, stored encrypted | After each turn, debounced |
The separation is the point. A hook cannot summarize, it can only copy. If both wrote the same field, a flat fragment would overwrite your assistant’s carefully written handoff after every turn. Because the fields are separate, the record is never empty and never degraded.
Both writers share the same session ID, so a chat stays a single entry instead of splitting into dozens of rows.
Chats stay linked, not merged
When a new chat continues an earlier one, it records continues_from with the previous session ID. The two remain separate, searchable entries, and the connection between them stays visible.
Also available over plain HTTP
GET /api/resume returns the same handoff as JSON, or as plain text with ?format=text. It accepts the same filters as the tool: tool_source, project, and within_hours.
How to use it
For most people there is nothing to set up. Assistants connected to Palim call palim_resume at the start of a chat and continue from there. If yours does not, ask it directly: “continue where we left off.”
To narrow what comes back, the tool accepts four optional filters:
| Filter | Effect |
|---|---|
tool_source | Only threads from one client, for example cursor or claude |
project | Only threads belonging to one project |
within_hours | Ignore threads older than the given number of hours |
include_messages | Append the tail of the transcript when the thread has stored messages |
Resume reads, it never writes
Calling palim_resume changes nothing in your memory. The handoff you get back is only as good as the last checkpoint your assistant wrote, so keep saving context at the moments that matter.
Availability
palim_resume is available to all Palim users, in every connected client that supports MCP tools.