Late one afternoon, while fixing the auto-publishing pipeline for one of my sites, I suddenly wondered whether a certain flag defaulted to true or false. Checking would take thirty seconds. But after those thirty seconds, when I returned to the main task, half of the plan I had assembled in my head had quietly fallen apart.
I have always been quietly bad at this — the rebuilding you have to do when you come back. The question itself is tiny, yet the cost of having stepped away from the main thread is strangely large. The /btw slash command, added in Antigravity v2.1.4 (released June 11), made me realize, only after using it, that this cost was never "time." It was context.
A question that stops the main thread takes context, not time
Until now, dealing with a side question that popped up mid-task came down to two options.
The first was to throw the question straight into the conversation I already had open. The answer comes back quickly, but an unrelated exchange gets mixed into the main thread. In a long session, you later read it back and think, "wait, what did I ask this for?" — and the context the agent draws on now carries one extra, irrelevant topic.
The second was to open a new conversation and ask there. The main thread stays clean, but now the new conversation knows nothing about what I was doing. I end up re-explaining the premise of the current task from scratch, and that is exactly where my focus breaks.
Either way, what gets shaved off is not seconds. It is the working map I had built up in my head.
What /btw changed was how I ask
/btw (I assume short for "by the way") lets you throw a side question to a disposable, single-shot agent while keeping the context of your current conversation intact. The main conversation history stays completely clean. The question and answer are self-contained, and the main thread is still sitting right where you left it.
It is very simple to use.
(in the middle of working through the main thread)
/btw I want to check which Gradle task the baseline profile
generation in this project is tied to
→ a one-off agent reads the current project context and answers
→ you read the answer, return to the main thread; nothing is loggedThe key is the asymmetry: the one-off agent can see the current state of the project, but it does not write into the flow of the main conversation. It has permission to read context, but not to muddy it. That asymmetry turned out to be exactly what I wanted.
Why keeping the thread clean actually matters
At first I thought of it as just a convenient command. But after a few days, I understood that what was helping me was not convenience — it was being able to keep the main thread at a steady purity.
When I hand a long task to an agent, the thing I care about most is how undiluted the conversation's context stays. Side questions thrown in midway, rephrasings, things I asked just to test — the more of those fragments pile up, the easier it becomes for the agent to lose sight of the main intent. /btw physically separates the most common source of that dilution from the main thread.
Running several sites in parallel as a personal developer, my head always has two or three tasks faintly running at once. Being able to handle a small question that arises in one of them without dragging it into another task — or into the main context — works in a quieter way than I expected. It is less that the number of interruptions drops, and more that the return after an interruption gets lighter.
How I actually divide it up
After a few days of trying it, this is the rule of thumb I have settled on.
| Situation | What I choose | Why |
|---|---|---|
| A check unrelated to the main thread (a flag, a command name, a spec) | /btw | I want the answer but not in the history |
| Research that feeds a main-thread decision | Ask it in the main thread | It is context I will want to revisit, so it should stay |
| Starting a separate, independent task | A new conversation | Different premise, cleaner to split off |
The single axis I use is: "do I want to read this exchange back later as part of the main context?" If yes, keep it in the main thread. If it can vanish on the spot, send it off to /btw. Since adopting this rule, the conversation history of my long sessions has become far easier to read back.
For the record, v2.1.4 also brought a redesigned quota screen, PDF attachments for Gemini models, and in-conversation search (cmd/ctrl+F). None of these are flashy, but for someone who touches the same tool for long hours every day, updates that refine the texture of the work tend to matter most in the end.
Designing not just what to delegate, but what to ask
When we talk about agent tools, we tend to think about "how much to delegate." But using /btw made me think that there is just as much room to design what to ask, and where. What stays in the main context, and what disappears on the spot. Simply being able to choose that changes the visibility of a long task considerably.
If the feeling of focus being shaved away during long sessions sounds familiar, the next time a side question comes up, try sending it to /btw before throwing it into the main thread. You will probably notice that what you had been losing was never time — it was context.
Thank you for reading to the end. I hope this is useful to anyone else juggling several projects on their own, in how you assemble your work.