Long sessions with Claude Code have a rhythm to them. You’re mid-task, Claude is reading files and running commands, and a question pops into your head. Not the main question. A side one. “Wait, what was the flag for that curl option again?” or “Did Claude pick the right port for this earlier?”
Before version 2.1.72, your options were bad. You could type the question and interrupt the main task. You could open a separate terminal. You could just hold the question in your head and hope you remembered it later. None of these are great.
/btw solves this in a way that’s cleaner than I expected.
What it does
You type /btw what was the database port Claude used earlier? and a floating overlay appears with the answer. The main task keeps running. Nothing in the conversation history changes. When you close the overlay, the answer is gone.
That last part is worth sitting with. The answer is ephemeral. It never entered the conversation. From the model’s perspective, you never asked.
The implementation detail that makes this interesting: the /btw agent has full visibility into your current conversation context, but it has no tools. It can’t read files, run commands, or make edits. It’s read-only, context-aware, and disposable.
The inverse-of-a-subagent framing
There’s a useful way to think about where /btw sits relative to the agent model.
A subagent gets full tool access (files, bash, edits) but starts with an empty context. You have to give it everything it needs explicitly. A /btw query is the opposite: it inherits the full conversation context but has no tools at all.
Both are constrained, just in opposite directions. The subagent is blind but capable. /btw is informed but passive.
This design is deliberate. Side questions are almost always about things already in context. “What approach did we take for that earlier?” or “What was the version I mentioned?” Those don’t need tool access. They just need memory. And /btw has that.
How to actually use it
The syntax is /btw followed by your question in the same message. Don’t just type /btw and press enter. The question needs to be there from the start, because that’s what the ephemeral agent receives.
| |
| |
| |
That last one is a bit of a stretch. If Claude hasn’t used jq in the current session, there’s nothing for /btw to pull from. It can answer from training data, but that’s the same as asking any other way. The real value is when the question is about something already in context.
When it’s not the right tool
/btw has no tools, so any question that needs a file read or a command is a dead end. If you type /btw can you check if the config file has the right value, the agent will tell you it can’t do that. Which is correct, but unhelpful. Ask that one normally and interrupt the task.
Similarly: if you think you might reference the answer later, /btw is wrong. The overlay closes and the exchange vanishes. If you need the answer in the record, ask it as a regular question.
There’s also a follow-up problem. /btw isn’t interactive. You get one answer and the overlay closes. If the answer raises another question, you’re back to interrupting the main task anyway.
So the sweet spot is narrow: quick, ephemeral, context-dependent, read-only questions that you need right now and won’t need again.
The flow-state argument
The reason this matters more than it looks: in a three-hour session, context interruptions compound. Every time you break the main task to ask a side question, you pay a recovery cost. Not just in tokens, though those add up too. In attention. You get an answer, then you have to re-orient back to what Claude was doing, re-read the last few messages, get back in the groove.
/btw removes that cost for the questions that fit its constraints. The answer appears, you read it, you close the overlay, the task is still where you left it. Nothing changed.
I’ve been using it mostly for “what did we decide earlier” questions. You’re 90 minutes into a session and you can’t remember if Claude configured something one way or another. Scrolling back through a long context is annoying. /btw what did we set for the worker timeout? is fast.
Token savings are real but secondary
There’s a practical benefit beyond workflow: /btw answers don’t go into conversation history. In a long session, this matters. Every exchange adds to context, and at some point you’re paying for a lot of history that’s no longer relevant. Side questions that you’d normally type and then forget about were silently inflating that cost.
The savings per question are small. But across a multi-hour session with a lot of tangential curiosity, it adds up. I don’t think of it as the main reason to use the command. It’s more of a free benefit that comes with the design.
One thing I’d change
The overlay closing and erasing the answer is clean in theory, but occasionally annoying in practice. Sometimes you want to paste a command or a value from the /btw response. You have to be quick about it before you accidentally close the overlay. A “copy to clipboard” button on the overlay would solve this. Maybe that’s version two.
The /btw command is in Claude Code 2.1.72. If you use custom commands heavily or run long agent sessions, it fits into the same philosophy: get more out of the tool without interrupting what the tool is doing.