[FEATURE] Model switching for existing Cowork tasks within Projects

[8kyama]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

First — I want to say thank you. I'm writing this from Japan as a paid-plan user, and Cowork has genuinely changed how I work. I love Cowork. That's the reason I'm writing this at all.

(Note: English is not my first language. I'm drafting this with Claude Opus 4.7's help to translate and polish my words. If anything reads awkwardly, please forgive me — the frustration and the love behind this request are entirely real.)

---

What this request is NOT (please read before closing as duplicate 🙏)

• This is not about Claude Code's /model command. Cowork has no equivalent.
• This is not about Dispatch model selection (Model and product selector for dispatch #43956). This is about standalone Cowork tasks in the Desktop app.
• This is not solved by "just create a new task." That is precisely the problem — see below.
• This is not about switching models in Chat. Chat already supports this; Cowork tasks do not.

What this request IS

A request to change the model of an existing Cowork task (inside a Project, or standalone) while preserving its conversation history, per-task memory, instructions, and working files.

---

Why this matters — how I actually use Cowork

I use Cowork Projects not for one-off tasks, but as a platform for specialized long-running agents. Inside each Project, I create separate tasks per role and build each one into a persona over many, many turns. One task is my "Marketing Director." Another is my "Brand Director." Each has:

• its own voice and tone
• its own decision frameworks
• its own accumulated memory of real decisions we've made together for my company
• its own working files and instructions

Over weeks, these tasks become far more than sessions — they become the closest thing I have to specialist colleagues who actually know my business. I consult them on real decisions, every day. This is not a hypothetical workflow. It is how I run a real part of my company, and Cowork Projects is the reason it's possible. Thank you for that.

Then Opus 4.7 shipped. The better reasoning, the better memory handling, the improved file-system memory — everything in the release notes is exactly what these long-running specialist agents need. I wanted to upgrade my Marketing Director and my Brand Director immediately.

And I discovered there is no way to do it.

The only path is: start a new task. Which means:

• All conversation history: gone
• All per-task memory: gone
• The persona I spent weeks shaping: gone
• The continuity with each specialist agent I was building: gone

Every model upgrade becomes a full reset. And here is the painful part — the better Cowork gets (and it keeps getting better, thank you), the more painful each reset becomes, because each agent grows more valuable the longer I invest in it. Right now, staying on Opus 4.6 feels like the only way to protect the agents I've built. That can't be the intended experience.

I've already asked the in-app help chat, and I've submitted feedback via the thumbs-down button. I'm also writing this public issue because I'm convinced other Projects users running specialist agents must be feeling the same thing — they just may not have the words (or the English) to say it.

Proposed Solution

Please consider adding a per-task model selector to Cowork tasks, so that an existing task (inside a Project or standalone) can be upgraded from, for example, Opus 4.6 to Opus 4.7 while preserving:

• conversation history
• per-task memory
• folder instructions and working files
• the accumulated persona

Ideally:

1. A model dropdown on each task, similar to how the Chat side already works
2. The ability to pin a task to a specific model so it does not silently change
3. A small indicator showing which model version a task was last run with

If switching the model on an existing context is technically risky, even a "fork this task with the new model, carrying over history and memory" action would be an enormous improvement. Anything short of "start over from zero" would let us actually benefit from model upgrades instead of fearing them.

Alternative Solutions

The only workaround I have found is manually copying persona instructions and key decisions into a brand-new task. This loses the live conversation history and the per-task memory that make these specialist agents what they are. It is not a real substitute — it is starting a new relationship with an assistant who happens to have read some notes about the old one.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

A typical day: I consult my Marketing Director agent on campaign copy in the morning, my Brand Director agent on creative review in the afternoon. Both remember every prior decision we've made together.

When Opus 4.7 shipped, I wanted both upgraded that day. I couldn't — not without resetting them. So I'm still on 4.6, and that's the wrong incentive structure for both of us.

Additional Context

• Japan-based paid-plan user. Cowork has been a before/after moment for how I work.
• This request is specifically about the Cowork Desktop app (macOS) + Projects — not Claude Code CLI, not Dispatch.
• Related but distinct from Model and product selector for dispatch #43956 (which is about Dispatch model control). This request is about standalone Cowork tasks inside Projects.
• Full disclosure: this Issue was drafted in Japanese and translated/polished into English with Claude Opus 4.7's help, because English is not my first language. The intent, the frustration, and the love for Cowork behind this request are entirely mine.

Thank you so much for building Cowork. I genuinely love this product — that's why I'm writing. Please let us bring our specialist agents with us when we upgrade to the next model. 🙏

[github-actions]

Found 1 possible duplicate issue:

1. [BUG] REGRESSION: Cannot switch between Opus and Sonnet mid-thread in Cowork after April 15 desktop redesign #48973

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[8kyama]

Preempting: "Why not just put the persona in CLAUDE.md or a skill?"

Because a skill gives Claude a role. Weeks of Cowork sessions give Claude lived history with my company — the actual decisions we made, the feedback loops, the judgment calls.

• Skill: "You are the Brand Director. Tone is X, audience is Y."
• Session: "Three weeks ago we decided against approach Z for reason W. Last Tuesday's client feedback showed us U."

Instructions describe the role. Sessions are the relationship.

Starting a new task with a perfect skill file is like hiring a new Brand Director who read the company handbook but has never worked with me. That's what I'm trying to avoid.

[8kyama]

Not a duplicate of #48973 — related but distinct. Please don't auto-close 🙏

#48973 is a regression bug: mid-thread Opus⇔Sonnet switching that used to work (even in Projects) was removed in the April 15 desktop redesign. They want it back.

This issue (#49649) is about model version migration: upgrading an existing task from Opus 4.6 to Opus 4.7 while preserving conversation history, per-task memory, folder instructions, and the accumulated persona. Even before April 15, there was no way to upgrade a task to a newer version of a model without creating a new task and losing everything.

Resolving #48973 would restore sibling-model switching (Opus ↔ Sonnet). It would not, on its own, solve version migration — which is specifically about bringing a specialist agent forward to a new model generation without resetting it.

The two are complementary: fixing #48973 likely establishes the infrastructure that would make #49649 much easier to implement. But they are different asks with different scopes.

[Shift-Justyn]

+1 I would like to be able to switch models or update to new models for existing projects without the loss of context and memory.

[Jigokuson]

I use Co-Work in the exact same way. Why there is no model switch in their "Non-Developer Project Agent" is beyond me, to be frank it is backwards thinking that every other session type on their platform does have a model switching command but it does not. The reasoning behind this is doubled now that they removed the model Fable 5. Yes it regresses back to Opus 4.8 but at what effort level what if the Fable session was set to medium effort and the user would have set the effort to Max in an Opus session. Telling a user to just start a new session is pretty much a slap in the face and unacceptable. Thank you for the well formatted and argued case Skyama.

[benlogistica]

+1, and this just bit me hard.

I was deep into an active Cowork task running on Fable 5 when the model became unavailable. Because Cowork locks the model after the first message, I couldn't switch to another available model to keep going, the whole task is now stuck mid-execution, with all its accumulated context, until Fable 5 comes back (whenever that is).

This is a real problem, not a nice-to-have. A model going temporarily unavailable shouldn't be able to freeze an entire long-running task. Every other Anthropic surface, web chat, Claude Code CLI (/model), lets me change the model mid-conversation. Cowork being the only one that doesn't is exactly where it hurts the most, because Cowork tasks are the long-lived ones with the most context to lose.

Please let us change the model at any point in a Cowork task, taking effect from the next message. As it stands, we have zero freedom here, and one upstream availability blip can kill a task we've invested hours into.