PromptWake vs Doing It Manually

Every honest comparison in this section ends with some version of 'and you could also just back it up yourself'. So it is worth writing the page where that is the option being compared, because for a large share of readers it is the correct choice and pretending otherwise would discredit everything else here.

The manual version, in full

This is not a strawman. It is what we would tell a friend to do if they were not going to install anything:

# 1. stop the two tools that delete on a timer
#    ~/.claude/settings.json  → { "cleanupPeriodDays": 3650 }
#    ~/.gemini/settings.json  → { "general": { "sessionRetention": { "enabled": false } } }

# 2. copy everything, nightly
DEST="$HOME/Backups/ai-history-$(date +%F)"
mkdir -p "$DEST"
rsync -a ~/.claude/projects "$DEST/" 2>/dev/null
rsync -a ~/.codex/sessions "$DEST/" 2>/dev/null
rsync -a ~/.gemini/tmp     "$DEST/" 2>/dev/null
rsync -a ~/.codeium/cascade "$DEST/" 2>/dev/null
sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \
  ".backup '$DEST/state.vscdb'" 2>/dev/null
sqlite3 ~/.local/share/opencode/opencode.db ".backup '$DEST/opencode.db'" 2>/dev/null

# 3. cron it, and point DEST at storage that is itself backed up

That is the whole product for one person. If you are a solo developer or a two-person team, run it, put it in cron, and spend the money on something else. We would rather be the company that told you that than the one that sold you a subscription for it.

Where it stops working, in order of when it bites

The script does not degrade gracefully. It works completely until one of five things happens, and then it has usually been broken for months before anyone notices.

• A tool changes its format. Codex moved its thread index into SQLite; VS Code moved chat sessions from .json to .jsonl. Your rsync keeps exiting zero and copying a directory that no longer holds what you think it holds.
• Nobody checks it. A backup script that fails silently is indistinguishable from one that works, until the day you look. The failure is discovered by the person who needed the data.
• It only covers the machine it runs on. Every new laptop and every new hire starts uncovered, and there is no list of who is covered.
• The output is unreadable to anyone else. A directory of JSONL and SQLite in a colleague's home folder is not something a tech lead opens. There is no shared view, so the record is private by construction.
• It is not evidence. When a customer's security questionnaire asks how AI-generated code is retained and reviewed, 'each developer has a cron job' is not an answer that survives the follow-up question.

The script is not wrong. It is a personal habit standing in for an organisational control, which works exactly as long as the organisation is one person.

What we actually add

Four things, and it is a short list on purpose. Format tracking, so a tool changing its layout is our problem rather than the reason your archive quietly stopped containing anything. Correlation, so the prompt, the response and the file diff arrive as one record instead of three directories you would have to join by timestamp. A shared timeline, so the record can be read by someone other than its author. And visibility, so 'is this working' is a screen rather than a hope.

Notice what is not on that list: we do not capture anything the script could not, in principle, copy. The data is the same data, written by the same tools, to the same disks. Anyone claiming a fundamental capability difference here would be overselling.

The test

Ask one question: if the developer who wrote the script leaves next month, what happens to the record? If the answer is 'nothing, it is on their laptop and nobody else knows the cron entry exists', you have discovered the actual difference between a personal habit and a system of record.

If that answer is fine for your situation — and for a lot of situations it genuinely is — run the script. It is above, it is free, and it works.