I was fixing store descriptions for one of my wallpaper apps one evening. I had attached a table of per-language differences and worked with the agent for the better part of an hour. The conversation got long, so I ran /compact, asked it to continue, and the suggestions that came back had nothing to do with the table.
Had it never read the table? Read it and forgotten? Never received it at all? The screen gave me no way to tell, and I just sat there.
Here is what I'd like to say up front: you can tell these apart with a small experiment instead of a guess. All you need is one file with a passphrase in it.
Check the version first
As far as I could confirm, the Antigravity CLI release history says the following. My source is a third-party roundup of updates, not the official changelog text, so please read the official notes for your own environment too.
- v1.3.5 (Oct 14):
/compactbecame available on Linux and macOS - v1.4.6 (Oct 23): attachments are kept after compaction
So before v1.4.6, an attachment's contents might have dropped out of the working conversation after compaction. I say "might" because I haven't reproduced it on those versions myself.
agy --versionOn v1.4.6 or later, the version is less likely to be the cause. The experiment below is still worth running, since the cause may lie in how you attached the file.
Use a canary file to see whether the attachment arrived
The problem it solves: separating "never arrived" from "lost during compaction."
# Make a passphrase that appears nowhere else, in a one-line file
TOKEN="canary-$(date +%H%M%S)-$RANDOM"
echo "The passphrase for this check is ${TOKEN}." > canary.txt
echo "$TOKEN"Then, in this order:
- Start a new conversation, attach
canary.txt, and ask for the passphrase in the file. - If the answer is right, the attachment arrived before compaction. If it is wrong, compaction is not the issue; look at how you attached it.
- Run
/compact. - Ask for the passphrase again.
- A correct answer means this version keeps attachments through compaction. A wrong answer, or "I don't know," means compaction dropped it.
Why build it this way? The passphrase was made a minute ago, so the agent cannot guess it from general knowledge. Right means it really read the file; wrong means it really didn't.
Reading the result
| Before compact | After compact | What to do |
|---|---|---|
| Wrong | (skip) | Review how you attach files. Compaction is not involved. |
| Right | Wrong | Update and repeat the test. If you can't update, re-attach after each compaction. |
| Right | Right | The attachment survived. For a big file like a table, suspect that details got thinner. |
The third row was the trap closest to home for me. A one-line passphrase survives easily, while my table had fifty rows. Whether something arrived and whether every detail was kept turn out to be separate questions.
My rule for starting over after compaction
When the test comes back wrong, my routine is short:
- Attach important files again right after compacting
- Compact at natural breaks, and just before, have the agent write three lines on what must be kept
- Run the canary test once on the day I update the CLI
Don't trust that an attachment arrived; check that it did. The longer the session, the less I let that line slide.
One next step
When today's work is done, create canary.txt and run the five steps once. A one-line note of the result makes it easy to compare after your next update.
If your session stops from hitting the limit rather than compacting, recovering from a context limit error may help, and getting started with agy and slash commands covers the basics. The idea is the same as the canary check for hooks that load but never run.