Design review: multi-model new thread (upstream #12179)

[rynfar]

Maintainer asked (2026-10-01) to consider this as Pylon product work with its own design review.

Upstream: 0150c6a53b (pingdotgg/t3code#12179): one send starts several models in separate worktrees so results can be compared. Previously deferred in cycle #736 as a product choice.

Questions: worktree lifecycle and cleanup, quota/cost visibility per provider (Pylon usage page), how sibling threads are grouped/compared, Prime/provider ownership, mobile presentation, and Stop/cancel semantics across siblings.

Exit: a recorded decision linked from the upstream review index.

[rynfar]

Design review

Design review: multi-model new thread

Reviewed against Pylon 00884406f7d8c59c3ee98a617ba8a1eb64661a04. The requested log search found 0150c6a53b409ba3bcb45645709b649cf8708354, upstream #12179.

Upstream behavior

Web and desktop users Shift-click models in a new-thread picker to send one prompt to multiple selections. Regular selection returns to one model. Each selection creates an independent background thread and fresh Git worktree from the selected base branch; the composer remains available.

Changes concentrate in apps/web/src/components/ChatView.tsx, chat/ChatComposer.tsx, ModelPickerContent.tsx, ProviderModelPicker.tsx, ModelListRow.tsx, and the three branch/workspace toolbar components. Fan-out forces fresh worktrees and prevents selecting the project checkout or a previous worktree.

ChatView.tsx validates each provider and derives its model options, prompt formatting, and interaction mode independently. Attachments are prepared once and reused. Failed selections can recover their prompt without replacing a newer draft. Ambiguous failures retain the possible thread ID and block another send until the user explicitly allows retry.

Server changes add optional prepareWorktree.requireWorktree and advertised requiredWorktreeBootstrap. Unsupported repositories or bases reject instead of silently sharing the project checkout. Dispatch errors add bootstrapThreadDisposition: "not-created" alongside "deleted".

No batch command, group event, projection, or migration is added: each target uses an ordinary thread bootstrap. Mobile gains no multi-model authoring UI.

Later history search found 295d7cba09 (#13764) touching the fan-out boundary while moving queued sends to QueuedMessageSender.tsx and chat/sendQueuedMessage.ts. It removes queued-message special cases from composer submission. The adjacent b4620d5955 (#12306) strengthens shared-workspace rewind checks; it is relevant context, not a new fan-out feature.

Current Pylon behavior

Pylon already supports background draft submissions and ordinary worktree bootstrap, but has no multiple-selection state or required-worktree capability. Its apps/server/src/ws.ts still falls back to the project checkout for invalid worktree prerequisites.

Pylon’s bootstrap already marks successful creation inside an uninterruptible dispatch section before draining deletion work. Preserve that stronger implementation rather than replacing it with upstream’s smaller ordering fix. Pylon also supports baseRemoteName, which must survive fan-out.

Its exact rollback and Prime ownership rules exceed upstream’s generic rewind model. PrimeAgentDriver.ts deliberately advertises supportsMultipleInstances: false; selecting several models must not enable multiple configured Prime instances. Multiple threads on one enabled instance require separate admission/capacity verification.

Options

• Don’t adopt. Keep one model per draft on every client. No contract, migration, decider/projection, environment-routing, or provider changes. Low risk and negligible size; users can manually submit separate background threads.
• Adapt independent-thread fan-out. Add the capability and dispatch-error contracts first, preserving existing events/projections and Pylon bootstrap fences. Implement a shared submission controller instead of adding another large lifecycle block to ChatView.tsx. Web/desktop authoring ships first; mobile can view and operate created threads but remains single-model for creation. Each batch stays on one explicitly selected environment, including remote/tunnel use; no cross-environment load balancing. Preserve each provider’s validation and Prime gates. Medium-to-high risk; roughly 1–2 engineering weeks.
• Add durable batches. Persist batch intent, per-target outcomes, and retry state through a pure decider and queue-backed reactor. All clients can recover status after restart. Requires new contracts/events/projections and any necessary migration after Pylon’s current 67. Provider and environment boundaries remain per target. Higher initial cost, roughly 3–4 weeks, but stronger recovery.

Recommendation

Adapt independent-thread fan-out if the maintainer accepts web/desktop-only authoring initially. Decide the selection limit, concurrency policy, and whether selections must survive application restart.

Upstream’s uncertainty map survives component remounts but is in-memory; it does not provide durable duplicate prevention after reload. Treat this as an explicit limitation or introduce stable submission identities. Keep creation fan-out separate from queued follow-up delivery.

Phase adoption as required-worktree server enforcement, shared submission/recovery logic, then picker and toolbar UX. Scratch threads from #963 are unsupported. Name-only projects become eligible only after a successful first commit.

Verification plan

Test missing capability, non-Git and unborn bases, remote selection/fetch failure, unique worktrees, setup failure, cancellation, and deletion drains. Cover partial success, lost acknowledgements, attachment reuse, navigation, remount/reload, and recovery beside newer drafts. Verify per-model options and Prime admission without relaxing multiple-instance restrictions. Confirm mobile can stop, archive, delete, and inspect resulting threads.

Actual verification

Ran the requested git log t3code-upstream/main --grep='#12179' --format='%H %s', commit diffs, later subject/path/-G history searches, and Pylon source searches. gh issue view 964 --repo pylon-code/pylon failed because GitHub was unreachable. No tests or runtime checks were run; no files changed.

Read-only design review (Codex via relay, coordinated by Claude Opus 5.5) against Pylon 00884406f7. Decisions stay with the maintainer.