The conversation I want first thing in the morning is almost always yesterday's. Yet opening the sidebar meant scrolling past a column of near-identical names, sometimes two or three passes before landing on the right one.
I work as an indie developer with app projects and site projects running side by side, so Antigravity holds a dozen-plus projects at any given time. Growth is a good sign, but every morning began with the same twenty or thirty seconds of friction before any actual work started. I wanted to be typing before my coffee went cold, and instead I was dragging my eyes up and down a sidebar.
Version 2.8.0, released on August 12, made the sidebar remember its collapsed and expanded state across sessions (2.8.1 followed on August 13). Arranging things finally sticks instead of resetting on the next launch, so I took that as the moment to rethink how I hold projects in the first place.
What I was hunting for wasn't the conversation
Breaking the problem down, that scrolling time wasn't spent looking for a conversation. It was spent remembering which project it lived under.
| Symptom | What was actually happening | What fixed it |
|---|---|---|
| Can't find the conversation | Projects don't match units of work | Redefine granularity |
| Names all look alike | Auto-generated titles from the first message | Fix a three-part naming rule |
| Conversations keep multiplying | Starting fresh threads in the wrong project | Name the target at launch |
Three separate-looking symptoms, one shared root: the unit of work was never defined. So I worked through them in order.
Set granularity by "what you return to," not by repository
My original split was one project per repository. Tidy on paper, but out of step with how I actually come back to work. Making things look orderly had quietly become the goal, and the results were poor: I still read the list from the top, one row at a time.
On the wallpaper app side, classifying image assets and preparing an App Store release live in the same repository, yet they demand completely different mental modes. On the site side, the opposite happens: for weeks at a time I'm making the same category of decision across several repositories at once.
So I reduced the rule to two questions:
- If I don't open it in a given week, it doesn't stay as a permanent project
- If I'd want to read the same conversation history, it belongs in one project even across repositories
Running everything through that filter cut my permanent projects roughly in half. Nothing needs deleting — anything retired can be reopened the moment it matters again. Group by how you come back to the work, not by how it is stored. Of everything here, that was the line that mattered most.
The second question surprised me more than the first. I had assumed repository boundaries were the natural seams, but the history I actually reread is organized around decisions, not directories. When I split asset classification and release preparation into two projects despite the shared repository, the conversations inside each one finally read as a continuous thread rather than an interleaved log of two unrelated concerns.
With state preserved, keep exactly one project expanded
This is where 2.8.0 pays off most. Previously I could tidy the ordering, then reopen the app to find everything expanded again. The tidying never paid for itself, and at some point I quietly stopped bothering.
Now the arrangement after Collapse All survives. That let me commit to a single rule:
Only one project stays expanded at a time.
Whatever I'm focused on stays open; everything else stays folded. Switching means folding one and opening the next. That alone brought the sidebar back inside a single screen.
Worth noting: 2.6.0 (August 7) improved both the speed of opening long-history conversations and the loading of the conversation list. Folding and reopening became cheap enough that this rule stopped feeling like extra work.
Keep conversation names to three parts
Auto-generated names summarize your opening message. Reasonable in principle, but similar requests produce similar titles. Three threads that began with "help me trace this error" are indistinguishable a day later.
So I rename each conversation right after starting it, following one rule: date, subject, verb.
0815-wallpaper-categorizer-triage
0815-labs-sitemap-fix
0814-ios27beta-verifyLeading with the date means alphabetical order roughly matches chronological order. The subject can be whatever you'd call it out loud. The verb goes last so that "triage" and "fix" on the same subject sit next to each other as distinct threads.
Every additional rule is a rule you eventually skip. I keep this one capped at three parts on purpose.
One caveat worth mentioning: renaming has to happen immediately, while you still remember what you were about to do. Renaming at the end of a session sounds tidier, but by then the thread has usually wandered somewhere else, and you end up naming the last thing you discussed rather than the reason you opened it. I'd rather have a slightly inaccurate name written in the first minute than an accurate one that never gets written.
Name the target at launch instead of at the keyboard
Most of my accidental new threads came from typing into whichever project happened to be open. That's fixable at launch rather than through discipline.
Version 2.7.1 (August 11) added --project and --new-project flags, letting you state which project to open or create one outright.
# Alias the places you return to most
alias agy-wall='antigravity --project ~/dev/wallpaper-app'
alias agy-labs='antigravity --project ~/dev/labs-site'
# Isolate throwaway experiments from the start
alias agy-lab='antigravity --new-project ~/tmp/scratch-$(date +%m%d)'Short experiments started inside a real project are what clutter the list later. Putting disposable work somewhere disposable from the beginning means there's nothing to clean up.
Also in 2.8.0: if you have Antigravity IDE installed, a button now opens the current project directly in the IDE. If you move between editor and agent frequently, that removes one round of reopening the same project twice.
What I left unsolved
To be straightforward about the limits: this didn't make everything comfortable.
I haven't found a way to move a conversation between projects after the fact in my setup. Threads I filed wrong simply stay where they are. That constraint is precisely why the naming rule comes first — with consistent names, a slightly misplaced thread is still findable by search.
Cross-project conversation search also doesn't feel strong yet. Rather than force a tooling fix, I now write "what did I decide last week" notes outside the conversation entirely, as short memos. It draws a clearer line between what the agent holds and what I keep at hand.
Neither limitation is severe enough to undo the change. Both are worth knowing before you invest an afternoon in reorganizing, because each one quietly shifts where the effort belongs — into naming and into launch habits, rather than into filing.
If the display settings themselves are the sticking point, it's worth reading alongside Setting Up Antigravity 2.0 with a Japanese UI. And if you want to rework how you review agent output too, The Review Routine I Rebuilt Around 2.8.0's View Limits covers how diff review changes once those limits are in place.
One thing to try tomorrow morning
Trying to reorganize everything at once rarely survives the week. Start by pressing Collapse All and choosing the single project you'll keep expanded tomorrow. Everything else can be reopened one at a time, as it becomes relevant.
Trim these rules to fit your own setup. I may be missing a better way, but the three-part name is the one rule I still keep on busy weeks.