On March 10, 2026, a developer set Claude Code loose on a refactor, noticed something in a different file, and typed "btw" at the start of a message. Claude answered the question. The refactor kept running. The main conversation thread did not change. When the response came back, the task resumed from exactly where it had been.
This was new. Not new as in "recently possible," new as in "the cost structure of asking questions during active work just changed."
The feature is called /btw. Invoke it with the command, or start a message with the word, and Claude Code opens a side channel. The exchange is read-only (Claude calls no tools), ephemeral (it does not persist in the main conversation history), and scoped only to answering what you asked. You get an answer. The task you interrupted does not know it was interrupted.
The announcement came from Thariq, a member of the Claude Code team, on March 10 and 11 via posts that moved fast through developer communities. The practical use case is obvious once you have lived the alternative long enough: you are three minutes into a refactor, you have a question about a pattern in a separate module, and previously your options were to interrupt and lose the thread, or wait and lose the thought. /btw is a third option.
But March 10 is not where this story starts.
The Hint That Did Nothing
In December 2025, a developer ran strings on the Claude Code binary and found a line: "Start with 'btw' to ask a quick side question without interrupting Claude's current work." The string was not dead code sitting in a dormant module. It was an active hint surfacing in the CLI's tips rotation. Users were seeing it in their sessions.
The feature did not work.
GitHub Issue #14804 documented the problem. Messages starting with "btw" behaved identically to any other message. No side channel opened. The main task's context took the query in like any turn in the conversation. The hint was advertising something that had not shipped.
This is a specific failure mode with its own name in the research brief that circulated after the story broke: the leaky experimental. Not vaporware, which is a product that does not exist. Not a dark launch, which is a feature that exists and is deliberately hidden. The leaky experimental is code that escapes into user-visible surfaces before the functionality catches up. The hint system did not gate on feature readiness. The string got out.
Claude Code has three documented instances of this pattern. Issue #12396 found /extra-usage surfacing before the command did anything useful. Issue #3315 found MCP roots appearing in the interface before the implementation behind them was ready. Anthropic's triage bot recognized all three as structural duplicates when routing the /btw report. The pattern repeats because the root cause is architectural: tip strings and hint strings are maintained separately from feature flags. One ships when it is written. The other ships when it is built.
A dev.to piece cataloging undocumented Claude Code commands captured what the community made of this: "the dev team will casually drop 'oh yeah, that exists' or ship things without mentioning them in release notes." That characterization is more accurate than critical. It means the team is building faster than the documentation layer can track, and the seams are visible to anyone who looks closely enough at the binary.
Six Words and a Comma
On January 6, 2026, Boris Cherny, who leads Claude Code at Anthropic, responded to Issue #14804. His full substantive response was six words and a comma: "A thing that we're experimenting with, more to come." He added that he would remove the hint from the tips rotation to stop generating noise.
The hint was not removed.
By the time Thariq announced the working feature in March, 83 days had elapsed since Boris posted that response. The hint kept appearing in sessions throughout. Developers who saw it and tried it found a feature that behaved like any other message. A few filed reports. A few more ran strings on the binary to understand what they were seeing. Most moved on, noting the promise without expecting a timeline.
The 83-day gap is not a criticism of the pace. It is a data point about what the inside of a moving project looks like when the task queue runs ahead of the cleanup list. The hint stayed in rotation because removing a string from the tips system was a lower priority than building the thing the string described. The feature caught up to the hint rather than the other way around.
What Read-Only and Ephemeral Actually Mean
The architectural detail that matters most came from @oikon48, a Japanese developer who analyzed the behavior shortly after launch: /btw is read-only, meaning Claude calls no tools, and ephemeral, meaning the exchange does not persist in the main conversation history.
These are not limitations that the team will eventually remove. They are the design. And the reasoning behind them is worth unpacking.
If /btw called tools, a mid-task question about a function in a different file could modify that file. The main task's context would shift underneath it. Conflicts become possible between the side channel's writes and the primary thread's assumptions. The guarantee that the running task continues unaffected requires that the side channel cannot write.
If the exchange persisted in conversation history, every "btw" question would add tokens to the context window of the main task. Long sessions would degrade faster. The noise floor of the primary thread would rise with each side query. Ephemerality keeps the channel from taxing what it was designed to avoid disturbing.
The competitive picture clarifies what makes this distinctive:
| Tool | Mid-task query | Ephemeral and read-only |
|---|---|---|
Claude Code /btw | Yes | Yes |
| Cursor | Yes (queue or interrupt) | No; joins main context |
| Windsurf | Yes (queue) | No; joins main context |
| GitHub Copilot | No (async PR model) | N/A |
Cursor has the most mature mid-task system among the alternatives. Option+Enter queues a message; Command+Enter interrupts. Either way, the message enters the main conversation. It modifies the thread it routes into. Windsurf supports message queuing but no parallel channel. Every tool in the comparison treats a mid-task query as an addition to the primary conversation. Only /btw opens a separate channel and discards it when the question is answered.
That row in the last column is the architectural claim. The Claude Code team built a feature that preserves the main task's state as inviolable. The side channel exists, gets used, and disappears. The session it opened next to does not know it happened.
What Turn-Based Costs
AI coding assistants inherited their interaction model from chat interfaces, which inherited it from help desk systems, which inherited it from letters. You send a message. The model processes it. You wait. You respond. The turn-based structure made sense when inference was slow and the bottleneck was the model. Inference got faster. The interaction paradigm did not change with it.
Turn-based interaction with an AI during active coding has a cost that does not appear in benchmarks: developers learn to batch their questions. If asking something means stopping the work, you defer. You make a mental note. You try to hold the question until the task completes and you can start a new turn. Some questions survive long enough to be asked. Many do not.
The ones that do not survive are often worth asking. The mid-task sanity check, the "is this the right pattern for this case," the quick question about a function in a different part of the codebase: these get filtered out by the cost of asking them. Not because the developer decided they were unimportant. Because the tool structure made asking expensive and deferral looked cheaper.
Over enough sessions, developers working with turn-based AI tools adapt their thinking to match the tool's constraints. Questions become larger and more pre-planned. Exploration shrinks. The spontaneous check gets replaced by longer upfront thinking about what to ask. That adaptation is invisible until something changes the cost structure.
/btw changes the cost structure for one specific class of question: the question you already suspect the answer to and want to verify without derailing what the AI is doing for you. That class of question is common. It is common enough that Boris Cherny's team spent 83 days building the feature after a string advertising it leaked into the tips rotation.
The Direction the Step Points
/btw is narrow by design. It does not give Claude persistent awareness of parallel concerns. It does not redesign the session architecture or add memory of the side conversation. It opens a read-only, ephemeral channel, answers your question, and closes. The scope is small and intentional.
What the feature signals is larger than its scope. The Claude Code team built something that assumes developers will have questions during active tasks and made those questions cheap to ask, rather than assuming that the right UX is to wait for the task to complete before starting a new turn. That assumption is different from the one every other tool in the comparison table is operating under.
The 83-day paper trail from Issue #14804 to Thariq's launch announcement documents the team taking that assumption seriously enough to build it twice: once as a hint string in December, and once as a working feature in March. The hint appeared first because someone wrote the description of the thing before the thing existed. The feature appeared because the description was accurate about something worth building.
It was.