[Feature]: Add Claude Code /btw / Codex /side style ephemeral Side Chat on Orchestrator V2

[sudoax0n]

Problem

T3 Code has Steer and Queue for messages sent while an agent is working, but neither covers a different workflow:

Ask a quick question using the current thread's context without steering the active run and without adding the side exchange to the main thread's future context.

Claude Code now exposes this as /btw; Codex has the same general idea as /side.

This is especially useful in long-running agent sessions. While an agent is working, I may want to ask things like:

• Why did you choose this approach?
• What does this error mean?
• Is that dependency actually necessary?
• What are the tradeoffs of the thing you're currently doing?

Today the choices are all imperfect:

• Steer changes the active turn.
• Queue adds the question to the main conversation later.
• A new thread avoids pollution but loses the exact current conversational context.
• A normal fork is heavier than a disposable side question and becomes another thread to manage.

Desired behavior

Add a lightweight Side Chat / BTW action, available from the composer or command palette, with semantics roughly like:

1. Snapshot/inherit the parent thread's latest stable context.
2. Open a temporary side conversation.
3. Let me ask one or more questions there.
4. Do not add the side-chat messages or answers to the parent thread's subsequent context.
5. Do not interrupt, steer, or queue anything into the active parent run.
6. Closing the side chat simply discards/hides it.
7. Optionally allow Promote to thread or Merge back when I explicitly decide the detour is useful.

If the parent is currently running, using the latest stable forkable boundary is fine. The important property is context-aware isolation, not necessarily access to partially streamed tokens.

A slash command such as /btw / /side would be nice, but a first-class UI action is equally good.

Why this is worth revisiting after Orchestrator V2

This was already explored before V2:

• [Feature]: Side questions without polluting thread context (Codex /side equivalent) #9274 requested a side question using current context without polluting the main thread. It was closed during the feature-proposal cleanup and redirected to Ideas.
• Discussion [Feature]: Add a Codex-style /side command #7311 is the canonical Codex-style /side / SideChat request.
• SideChat: temporary snapshot tabs alongside a running thread #12793 proposed temporary SideChat tabs and was closed as a duplicate of [Feature]: Add a Codex-style /side command #7311.
• PR feat(server): fork threads and side chats #9436 implemented the server/provider side of forks + side chats.
• PR feat: side chat and fork surfaces for web and mobile #9437 implemented the web/mobile SideChat UX.

The maintainer closure on #9436/#9437 explicitly said the orchestration/provider layers were being rewritten for V2 and invited a fresh PR/request once V2 landed.

V2 has now landed via #2829, and current main already has much of the foundation that the old SideChat implementation had to build itself:

• thread.fork
• ThreadForkService
• thread lineage
• context transfer
• provider-aware native/portable forking
• thread.merge_back
• web/mobile fork navigation
• MCP t3_thread_fork

There is even current user-facing fork/merge-back behavior, e.g. #15063.

So this request is intentionally not asking to revive the old orchestration implementation. It is asking whether the new V2 fork/context-transfer primitives can now be surfaced as a lightweight ephemeral SideChat workflow.

Relationship to Steer / Queue

This is intentionally a third semantic:

Steer:  affect the active main turn now
Queue:  run this in the main thread after the active turn
BTW:    answer separately using parent context; never enter main context unless explicitly promoted/merged

That distinction is the feature.

Possible minimal V1

A small first version could be:

• "Open side chat" action on the thread/composer
• fork from the latest stable run using existing V2 machinery
• side chat shown in the right panel on web/desktop
• hidden from the normal thread list while attached to its parent
• close/discard
• promote to normal thread

Merge-back, multiple side tabs, mobile polish, and provider-specific shortcuts could come later.

The old #9437 UX is useful prior art, but the implementation should target the current V2 architecture.

[Danyalkhan14]

+1

[lapinvert]

+1

[antong314]

+1

[yu2001-s]

+1

[Lizzergas]

+1

[tjbnde]

+1

[zedong-peng]

We need this badly

[tocttou]

+1

[TheOneironaut]

+1

[JoelRDev]

+1

[rodrigoGA]

+1

[FrostYz1]

+1

[sankalpmukim]

V2 has now landed, giving this topic some love, even opencode has an internal /btw slash command for a similar purpose. Would be nice to have

[sankalpmukim]

+1, still very much want this. PR #18243 looks like the current attempt, would love to see it land.

[hruzgar]

+1, i was using this all the time in cc would be immensly helpful

[felho]

+1, this is after a few days of very happy T3 Code usage the only really missing feature

[ereid7]

+1 please add

[chisewaguri]

I opened #24476 to bring Claude Code’s existing /btw to T3 Code.

[jballo]

Happy to see there is such a need for this feature. I've built this on top of V2 and want to confirm direction and scope before I open it upstream. Working demo (all providers, web + desktop): jballo#1

What it does: /btw <question> asks a side question while the agent keeps working. It sees the thread as it is right now, including the turn in progress, and nothing from it enters the parent's context. Fork turns the answer into a normal thread, Dismiss hides it, and delete removes it.

How it's built: a side question is an ordinary V2 thread with a sideChat flag (the flag from #18243). It is forced read only on every provider and hidden from thread lists, search, MCP tools and scheduled tasks. It's not a second protocol, which is what #8296 was closed for.

Proposed scope:

• Web and desktop: /btw, a palette entry, a shortcut, and a small island above the composer. This differs from the right panel suggested above: a panel takes width from the diff view, and the island doesn't.
• Mobile hides side questions for now, with the mobile UI as a follow up PR.
• All 9 providers have an explicit read only decision, verified live.

Question for maintainers: is this direction and scope OK to open as a PR? If you'd rather have it smaller, I'm happy to drop parts, e.g. the shortcut, or leave it Claude only first.

[univerz]

+1, i prefer the tab-based solution from codex gui - ideal for complex questions / multiple turns