feature: Allow model and harness selection before submitting implementation in a new thread

[thehorse2000]

What Changed

onImplementPlanInNewThread in ChatView.tsx now navigates to a new draft thread with the implementation prompt pre-filled in the composer, instead of immediately creating a server thread and auto-submitting.

A single new store hook extraction (applyStickyState) was added alongside the existing composer draft hooks.

Why

Previously, "Implement in a new thread" locked the user into whatever model and harness were active on the plan thread — there was no opportunity to change them before the implementation run started.

Plan generation and implementation often benefit from different models or access modes (e.g. plan with a reasoning model under Supervised, implement with a faster model under Full access).

Using the existing draft-thread flow solves this cleanly: the draft composer already exposes the model picker and harness selector, so no new UI is needed. The implementation prompt is pre-filled so the user can review it, adjust settings, and submit when ready.

UI Changes

Before: Clicking "Implement in a new thread" immediately starts the implementation run in a new thread — the user arrives mid-execution with no chance to change the model or harness.

After: Clicking "Implement in a new thread" opens a new draft thread with the implementation prompt pre-filled in the composer. The user can change the model, harness
(Supervised / Auto-accept / Full access), or edit the prompt before manually submitting.

Monosnap.screencast.2026-04-10.11-25-14.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included a video for animation/interaction changes

---

Note

Medium Risk
Changes the "Implement in a new thread" flow from immediate server-side thread creation/turn start to client-side draft creation and navigation, which could affect user expectations and any logic relying on automatic orchestration dispatch.

Overview
"Implement in a new thread" now opens a draft instead of auto-submitting. onImplementPlanInNewThread in ChatView.tsx no longer calls orchestration APIs to thread.create and thread.turn.start.

Instead it creates a new draft/thread mapping via setLogicalProjectDraftThreadId, applies sticky composer state (applyStickyState), pre-fills the implementation prompt, and navigates to /draft/$draftId so users can adjust model/runtime/harness before sending.

^{Reviewed by Cursor Bugbot for commit 7315dc5. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Navigate to a draft thread on 'implement plan in new thread' to allow model and harness selection

• Previously, onImplementPlanInNewThread in ChatView.tsx immediately created a server thread and started a turn via orchestration APIs.
• Now it creates a local draft thread, applies composer sticky state, sets the implementation prompt, and navigates to the draft route — letting the user choose a model and harness before submitting.
• Behavioral Change: The action no longer triggers server-side thread creation or turn execution; instead it redirects to a draft view with the prompt pre-filled.

^{Macroscope summarized 7315dc5.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 9f03d48d-bbaa-4c6d-ad34-5859a8f34709

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ef214d1. Configure here.}

[cursor]

Implementation thread loses plan source linkage

High Severity

The old onImplementPlanInNewThread explicitly sent sourceProposedPlan: { threadId, planId } in the thread.turn.start command, linking the implementation thread to its originating plan. The new flow navigates to a draft thread, where upon submission the regular onSend path runs — but that path's thread.turn.start (around the bootstrap flow) never includes sourceProposedPlan. The onSubmitPlanFollowUp path does include it, but only fires on same-thread plan follow-ups where activeProposedPlan is non-null. On the draft thread, activeProposedPlan is always null since the draft has no proposed plans. This breaks server-side plan-to-implementation tracking and client-side features like the plan sidebar step display.

Additional Locations (1)

• apps/web/src/components/ChatView.tsx#L2662-L2678

 

^{Reviewed by Cursor Bugbot for commit ef214d1. Configure here.}

[thehorse2000]

This is a good point but will increase PR scope, let me know if must be done in this scope.

[cursor]

Existing project draft silently discarded on implement

Medium Severity

onImplementPlanInNewThread always creates a fresh nextDraftId and calls setLogicalProjectDraftThreadId without first checking whether a draft already exists for the logical project. setLogicalProjectDraftThreadId replaces the logical-project-to-draft mapping and deletes the previous draft's thread state and composer content if it's no longer referenced. If the user had an in-progress draft with unsaved content for the same project, that content is silently destroyed. The existing openOrReuseProjectDraftThread and useHandleNewThread both check for and reuse existing drafts to avoid this.

 

^{Reviewed by Cursor Bugbot for commit ef214d1. Configure here.}

[juliusmarminge]

ehhh it's fine i tihnk

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces a feature change to implementation thread creation workflow with significant runtime behavior modifications. Two unresolved review comments identify substantive bugs: loss of plan source linkage (high severity) and silent draft data loss (medium severity). These issues need to be addressed before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[juliusmarminge]

Tested and it works well. Will think a bit before making a call whether we want this or not.

a) it blows out the current draft thread if you have any
b) people used to this action auto-starting the agent might be mad if we change it
c) Adding another button "Copy plan to new thread" might be acceptable as a middleground

[thehorse2000]

Good thinking, Also might add
d) New draft thread is not linked to the original plan thread.

Not sure if its important but can be fixed i think.

The middleground option sounds good.
I believe the idea of switching models / harnesses between plan and implementation is actually really needed especially when we have more harnesses added in the future.
As you know some models are exceptional at planning while others are great implementers.

[juliusmarminge]

I don't think that matters. In fact i think its kinda good if it doesn't, means you can have a single plan then implement in 5 diffferent new threads if you want