Repository navigation
[Bug]: schedule_task can't set model or reasoning effort, and silently ignores modelSelection #16833
Description
Problem
An agent creating a scheduled task over MCP can't pick the model or its options (for example reasoning effort) for the runs.
schedule_taskalways copies the calling thread's selection (or the project default) when the task is created (apps/server/src/mcp/OrchestratorMcpService.ts:1528).update_scheduled_taskalways keeps the stored selection (OrchestratorMcpService.ts:1623).- Neither input schema has a model field (
packages/contracts/src/orchestratorMcp.ts:520-542,587-594), and the input isn't strict, so an agent that passesmodelSelectiongets a success response while the field is dropped. - The returned summary (
orchestratorMcp.ts:546-564) doesn't include the model, options or modes, so the agent can't see that its setting was dropped.
The server, the runner and the mobile editor already support a full selection per task (ScheduledTask.modelSelection, used at apps/server/src/scheduledTasks/ScheduledTaskService.ts:802,825), and #16592 adds the same controls to the web editor. Only the MCP tools are missing it.
Steps to reproduce
- In a thread running Claude Opus 5.5 at default effort, have the agent call
schedule_taskwith afixed_timeschedule,bindToCurrentThread: false, and an extramodelSelectionthat sets effort toxhigh. - The call succeeds, and neither the result nor
list_scheduled_tasksshows a model or effort. scheduled_tasks.model_selection_jsoncontains only{"instanceId":"claudeAgent","model":"claude-opus-5-5","options":[{"id":"fastMode","value":false}]}, so the run uses default effort.
Expected behavior
The agent can set the provider, model and options for a scheduled task, and can see what a task will run with.
Suggested fix
- Add an optional
target(reuseOrchestratorMcpTarget,orchestratorMcp.ts:100-128, the same field the other work-starting tools take) toschedule_taskandupdate_scheduled_task. Resolve it the same way those tools do: validate it againstorchestrator_capabilities, and inherit options only when the provider and model are unchanged. - Leaving
targetout keeps today's behaviour: copy from the calling thread on create, keep the stored selection on update. - Add
providerInstanceId,modelandoptions(and probably the runtime/interaction modes) toOrchestratorMcpScheduledTaskso list/schedule/update show them. - Optionally, reject unknown input keys on these tools so mistakes surface as errors.
- Fix the
schedule_taskdescription, which says settings "inherit from this thread" without saying it's a one-time copy.
Related: #15821 (follow the thread's model for thread-bound tasks), #16592 (web editor controls).
Reacted by Jack van der Bilt, Oana Goge, Alek Åström, Graydon and Kevin Takeda
Activity
juliusmarminge commentedon Oct 7, 2026
Note
Grok responding on behalf of Julius.
Triage: confirmed on current
main.Root cause
schedule_taskalways copies the calling thread's selection, or the project default when there is no calling thread:apps/server/src/mcp/OrchestratorMcpService.ts:1528-1529.update_scheduled_taskalways writes backexisting.modelSelection(and the stored runtime/interaction modes):OrchestratorMcpService.ts:1623-1625.OrchestratorMcpScheduleTaskInput(packages/contracts/src/orchestratorMcp.ts:520-542) norOrchestratorMcpUpdateScheduledTaskInput(:587-594) has a model or target field. They are plainSchema.Structs, so an extramodelSelectionkey is dropped and the call still succeeds.OrchestratorMcpScheduledTask(:546-564) has no model, options or modes, so neither the result norlist_scheduled_tasksshows what a task will run with.apps/server/src/scheduledTasks/ScheduledTaskService.ts:802,825). Only the MCP surface is missing it.Proposed fix
target: OrchestratorMcpTarget(orchestratorMcp.ts:100-128) to both inputs. Resolve it with the same resolver the work-starting tools use (OrchestratorMcpService.ts~1131-1213), which already validates against capabilities and inherits options only when provider and model are unchanged. Iftargetis omitted, keep today's behaviour.providerInstanceId,model,options(andruntimeMode/interactionMode) toOrchestratorMcpScheduledTask.schedule_taskdescription to say the settings are a one-time copy.Workaround
Until this ships, check or change the model and effort for the task from a scheduled-task editor in the app instead of over MCP. Controls for this in the web editor are in #16592, which is still open.
Related: #15821 (open feature request for thread-bound tasks to follow the thread's current model). It overlaps but is a separate request.
manvankaliber commentedon Oct 19, 2026
I’m interested in this as well. Being able to choose the provider/model and reasoning effort per scheduled task would help me keep routine runs on an appropriately economical configuration, avoid burning through my limited subscription usage, and reduce the risk of unexpectedly high API bills. It would also help to have the saved selection visible in the task list/editor so I can confirm what each recurring task will use. Thanks for investigating this.
juliusmarminge commentedon Oct 22, 2026
Reproduced on current main a50cd989ae with the isolated Linux dev server and real MCP requests. Disabled fixed-time tasks with bindToCurrentThread:false accepted both an extra modelSelection and a target requesting Claude Opus 5.5 with xhigh effort, but stored the project default (Codex gpt-6.1-sol). Both creation responses and list_scheduled_tasks omitted the selection. This reproduction used an external MCP client and a project default; it did not run a scheduled provider turn.