feat(mcp): agents can pick a scheduled task's model, effort and Fast tier#30808

Problem

An agent can't choose a scheduled task's model through MCP. schedule_task has no model input. Create copies the calling thread's modelSelection (or the project default), and update always keeps the stored one. So when a user says "run this nightly on Haiku" or "switch that task to Sol with Fast on", the agent can't do it. The same user can do it in the web and mobile scheduled-task forms.

Change

schedule_task takes an optional target, the same shape delegate_task and create_threads already use, minus environmentId and projectId. A task runs in its own project's environment, and schedule_task already names both at the top level.

• The target resolves through resolveTargetRechecking, the same code delegate_task uses. It checks the same things: provider instance, model, option ids and values. It also refuses a provider instance the project has disabled, since launch would reject it on every run. Partial targets merge the same way. {options: {serviceTier: "priority"}} keeps the stored model and its other options, and a new model starts from that model's defaults.
• A target can pick a provider that lacks the task's runtime mode (Pi has no auto). Runs would then fall back to approval-required and wait. The saved mode now steps down to the broadest mode that provider offers, with delegate_task's rule for an inherited mode. Without a target the mode is unchanged.
• A caller outside a thread can pass a complete target (providerInstanceId and model) on a project with no default model. Before, it was refused because there was nothing to inherit from.
• Thread-bound tasks refuse a target. Bound runs follow the thread's current model on purpose (#18467), so a stored target would never run. The schema says so, and the error tells the agent to pass bindToCurrentThread: false. An update can unbind and set a target in the same call.
• The task summary returned by schedule_task and list_scheduled_tasks now includes target for unbound tasks, so the agent can see what it set. Bound tasks leave it out, since the stored selection doesn't decide their model.
• The MCP tool-list byte budget goes up by 605 bytes (47818 to 48423). That's the new target field, mostly the option schema and descriptions it shares with delegate_task. I shortened its own description to "As in delegate_task. Unbound tasks only."; the bound-task refusal's error carries the rest. The evals below cover it. The Agent context budget check stays red until a maintainer adds the agent-context-increase label.

Scope and approval

There is no issue or discussion. I'm filing this as focused configuration of an established capability:

• What exists. Scheduled tasks already store a modelSelection with options and launch runs with it. The web and mobile forms let users set it. schedule_task is the agent's way in, and delegate_task and create_threads already accept this same target and validate it the same way.
• What it controls. Only the stored modelSelection of an unbound task. Nothing about how or when tasks run changes. Omitting target keeps today's behaviour on both create and update.
• Why it stays inside that capability. No new workflow and no changed default. It's parity between the agent and the user for a field both can already see. Bound-task behaviour from #18467 is unchanged; this PR refuses the input there instead of storing something that would mislead.

The web picker's handling of these options is a separate PR, #30729. This PR touches only the MCP path.

Verification

Server tests in apps/server/src/mcp/OrchestratorMcpService.test.ts, new block "the model of a scheduled task":

• create with a target that has options saves that model and options
• update with a target merges into the stored selection
• update without a target keeps the stored selection
• the summary reports the saved target
• a bound task refuses a target and its summary omits target
• one update can unbind a task and set a target
• an unknown model (model_unavailable) and an unknown option value (invalid_request) are refused on create and update, and nothing is saved
• a provider instance the project disables is refused (provider_unavailable)
• a target steps the runtime mode down to one its provider offers, on create and update; an update without a target keeps the stored mode
• a complete target works on a project with no default model

vp test run src/mcp/OrchestratorMcpService.test.ts -t "the model of a scheduled task" with upstream/main's contracts, service and handler: 7 failed, 1 passed. The disabled-provider, runtime-mode and no-default-model tests were added after CodeRabbit's reviews; each fails without its fix. The one that passes is "update without a target keeps the stored selection", which is today's behaviour. With this branch all 68 tests in the file pass. vp run check:changed passes (format, lint, knip, typecheck, tests).

Runtime transcript. I started a dev server from this worktree with its own .t3 (empty DB, not seeded). A throwaway project pointed at a scratch git repo, Codex default model. I called the tools over /mcp with an MCP client session issued the way t3 thread does it:

Evals. Three new cases in evals/mcp-tool-use/cases/orchestration.ndjson: pick a model for a new task (bad), switch an existing task to Sol with Fast on (bad), and move a task's time without touching its model (control). 3 samples each:

The targeted runs cost $4.07.

On Codex (GPT-6.1 Sol and GPT-6 Astra, through CLIProxyAPI), the results are partial. The eval's Haiku shell simulator hit the same Anthropic spend limit, so every sample where the agent ran a shell command errored. Graded samples on this branch: Sol 3/3 picks-model, 1/1 changes-model, 3/3 keeps-model; Astra 2/2 picks-model, 2/2 keeps-model. On main's text every bad-case sample errored, so there's no Codex before/after. I then started one full-suite run per Claude model on this branch. The Anthropic workspace hit its spend limit partway through both, so they're partial. Sonnet graded 223 of 299 samples and Opus graded 134 of 300 ($23.32). Every existing schedule case Sonnet reached passed (schedule-one-off-tomorrow, schedule-one-time-date, schedule-runs-job-first, scheduled-run-lists-tasks, the CI-schedule control). The graded misses were control-link-means-url (Sonnet 0/2), DEL-02 (Sonnet 2/3), DISC-01 (Opus 0/2) and delegates-then-new-thread-with-model (Opus 2/3). None of those samples loaded or called schedule_task. I didn't run a main baseline for those cases, so I can't say whether they also miss on main.

Not checked:

• A Codex before/after in the eval. The runs above are partial and main's text has no graded bad-case samples.
• A bound-task refusal over a real MCP call. My client session isn't attached to a thread, so it can't create a bound task. The unit tests cover this path.
• The evals after the shortened target description. No eval API key was available for that run.
• The runtime-mode step-down over a real MCP call. The unit test covers it.

Reviewed with review-loop: 3 rounds with GPT-6.1 Sol. Verdict: approved. Round 1 found that bound tasks ignore a stored target. The fix is the bound-task refusal above, not a change to #18467. Round 3 covered the disabled-provider check. A further round on the runtime-mode and no-default-model fixes: 1 round with GPT-6.1 Sol, verdict approved.

Created with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code