In a Cloud Agent Project, worker agents created by the coordinator ignore my account’s Default Model (Preferences → Default Model = “Claude Opus 5.5 1M Medium Fast”). They always inherit the coordinator’s model (claude-opus-5-5-medium). The coordinator also can’t request the Fast or 1M variant explicitly, because those slugs aren’t in its allowed model list, even though the Fast variant is available on my account (I can switch a running worker to it by hand in the UI).
Steps to Reproduce
Open a Cloud Agent Project whose coordinator runs on Claude Opus 5.5 Medium.
Set Preferences → Default Model to “Claude Opus 5.5 1M Medium Fast”.
Ask the coordinator to spawn a worker agent without specifying a model.
Check the worker’s metadata: originalModelName = “claude-opus-5-5-medium” (the coordinator’s model, not the Default Model).
Ask the coordinator to spawn a worker with model “claude-opus-5-5-medium-fast”. It can’t, because the slug isn’t in its allowed list.
Manually change a running worker’s model in the UI to the Fast option. The worker’s model becomes “claude-opus-5-5-medium-fast”, so the model is available to my account.
Expected Behavior
Any one of these would solve it:
Workers spawned without an explicit model use my account Default Model, or
The coordinator’s allowed model list includes every model I can select in the UI (including Fast and 1M variants), or
There’s a per-Project “default model for workers” setting.
A Project coordinator launches many workers per day (timers, PR reviews, CI fixes), so switching each one by hand isn’t practical.
Coordinator: Claude Opus 5.5 Medium (claude-opus-5-5-medium)
Desired for workers: Claude Opus 5.5 1M Medium Fast
For AI issues: add Request ID with privacy disabled
Coordinator (Project) agent: bc-64942211-697a-4e51-8edb-a595717bfc15
Test worker spawned without a model (came up as claude-opus-5-5-medium): bc-0f20a033-ab8e-5929-b476-9118a096169c
Additional Information
Observed on 2026-09-23. Setting the Default Model has no effect on Project workers, and the Fast/1M variants can only be applied manually, one worker at a time, after the worker has already started.
Hey, thanks for the detailed report with the Request ID and steps.
Workers in a Project don’t read the account Default Model. That’s expected. When the coordinator starts a worker without explicitly setting a model, the worker copies the Project’s current model (the one set in the Project’s main chat). Also, workers that are already running keep the model they started with. The Default Model setting applies to agents you start yourself, and to runs from Slack, GitHub, Linear, etc. There isn’t a separate “default model for workers” setting yet.
To make sure all new workers start on Claude Opus 5.5 1M Medium Fast, set the model on the Project itself:
Open the Project’s main chat (the coordinator, not a worker).
In its model picker, select Claude Opus 5.5 1M Medium Fast.
Reopen the picker and confirm it still shows 1M Medium Fast.
Give the Project this task: “Start a new worker to <small task>. Do not pass a model, let it inherit mine.”
Open the new worker and check what model its picker shows.
Please send what the new worker shows after step 5, plus a link to it. Also, if the coordinator still says the Fast option isn’t available when you request exactly claude-opus-5-5-medium-fast by that exact name, paste its exact reply here. On your plan, Fast variants should be available, so that will help us figure out what’s going on.
Thank you, that explanation helped. Here’s where things stand.
Fast: works.
The coordinator can start a worker with claude-opus-5-5-medium-fast by exact name. The worker’s metadata shows originalModelName: "claude-opus-5-5-medium-fast" (bc-5fbad5b4-fb56-5e8a-ac06-dbfd3927f20a).
The earlier “not available” came from the coordinator relying on the model list in its tool description. That list has no Fast variants, so it looks out of date. It should include every model available on the plan.
All our Project workers now run on Fast.
1M: can’t be selected or verified from the coordinator.
The Project’s main chat is set to Claude Opus 5.5 1M Medium Fast in the model picker. The coordinator’s own metadata still shows only claude-opus-5-5-medium-fast (coordinator: bc-64942211-697a-4e51-8edb-a595717bfc15).
Following your steps 4–5, the coordinator started a worker without passing a model. It inherited claude-opus-5-5-medium-fast (bc-46089dfd-118b-5250-b1e0-69691f501070). Nothing in the metadata says whether 1M context came along.
The coordinator also tried passing a 1M model explicitly. All of these were rejected with “Model … is not available or invalid”: claude-opus-5-5-1m-medium-fast, claude-opus-5-5-medium-1m-fast, claude-opus-5-5-medium-fast-1m, claude-opus-5-5-medium-1m, claude-opus-5-5-1m-medium.
Questions
Is 1M a separate model ID, or a context option on top of claude-opus-5-5-medium-fast? If it has an ID, what is it?
When a worker inherits the Project model, does it also inherit the 1M context setting? Can you check bc-46089dfd-118b-5250-b1e0-69691f501070 on your side?
If 1M is a separate option, could the coordinator’s worker-creation tool expose it (for example, a context-size parameter)? Right now it only accepts a model name.
Great checks, thanks, and I’m glad Fast now works via the exact name. On 1M, I’ll break it down based on your questions.
Is 1M a separate model ID or a context option?
There’s no separate slug. For Opus 5.5, 1M is an extended context that you enable via Max Mode on top of claude-opus-5-5-medium-fast, not via a separate model name. That’s why all variants like claude-opus-5-5-1m-medium-fast, ...-medium-1m, and so on get rejected as not available or invalid. Those slugs just don’t exist. The correct layer for 1M is Max Mode, or picking the 1M variant in the picker, not the model name.
Does the worker inherit 1M context from the Project model?
The worker inherits the model name and the coordinator’s Max Mode state at the moment it’s spawned. So the worker only gets 1M if the coordinator is actually in the 1M Max Mode variant at that time. One important nuance is that in the current implementation, metadata doesn’t show context size as a separate field. For both the worker and coordinator, you only see the slug claude-opus-5-5-medium-fast. For bc-64942211, the coordinator metadata also only shows medium-fast, even though the Project picker is set to 1M Medium Fast. So right now the context parameter isn’t always propagated or reflected. That’s what blocks confirming 1M via metadata for bc-46089dfd. This is a limitation we’re tracking.
Can the worker-creation tool take a context parameter?
Right now the tool only accepts the model name. There’s no separate parameter for context size, so you can’t pin 1M on a worker via the coordinator today. I passed this to the team as a request, plus that the model list in the tool description should be fully up to date. I also noted your point about the outdated Fast list.
While the team is looking into the parameter drop, the most reliable way to keep workers on the right variant is to set the model at the Project level and not rely on 1M inheritance via metadata. If you see a new worker spawn on plain Medium without Fast, or you see something rejected by a name that should be available on your plan, send the bcId here and we’ll look at it case by case. I’ll reply in the thread once there’s an update on 1M.