feat(cli): choose model options when starting a thread with t3 thread start#23932

Problem

t3 thread start can pick --provider and --model, but not the model's options, so a thread started from a script always runs at the provider's default effort (Claude Opus medium, GPT-6.1 Sol low here). t3_thread_launch already accepts modelSelection.options; the CLI never sends them.

Reproduced on v0.1.2: t3 thread start . "Reply cli ok" --provider claudeAgent_x --model claude-haiku-5-5 --wait --json replies fine, the thread has no options, and there is no flag to set them.

Change

A repeatable --option id=value that fills modelSelection.options:

• It needs --provider and --model. Option ids depend on the model, so applying them to whatever the project default happens to be would be a guess.
• true and false become booleans (--option fastMode=false); other values stay strings.
• A malformed entry or a repeated id fails with one line on stderr before connecting, like the other usage errors.
• Ids and values pass through as given, the same as --model today. t3_thread_launch does not check options against the catalog (delegate_task does), so effort=bogus on Claude falls back to the default. I left server-side validation out because it also changes the MCP tool for outside agents. Happy to add it here or in a follow-up if you want it.
• One paragraph in docs/user/outside-agents.md.

Scope and approval

No prior issue or discussion. I think this fits the focused configuration route: t3 thread start (#22732) already chooses the provider and model it passes to t3_thread_launch, and that tool already takes options. The flag fills a field the tool accepts and adds no server behavior.

Some context, since this is not ad hoc. I have tracked T3 releases weekly since about v0.0.42 with a release radar and a registry of local workarounds, each with a removal condition. Scripts outside T3 (launchd schedules, mail and recording pollers) need to start threads. That went through V1 HTTP dispatch helpers (retired with V2), then a webhook relay host thread that #20447 rightly broke by treating webhook data as untrusted, and since Oct 21 an OAuth MCP client that approves itself with a local pairing code (works, but needs token storage and re-approval every 30 days). #22732 is the right official answer. The one piece scheduled jobs still miss is choosing the effort; the registry entry reads "Remove when t3 thread start takes options".

Verification

• 3 new tests in apps/server/src/cli/thread.test.ts: options map to typed {id, value} entries (including false and a value that contains =); a repeated --option is rejected through the real Command.runWith parse; --option without --model is rejected. vp run check:changed: format, lint, knip, typecheck and tests pass.
• Dev server from this branch (vp run dev:server --home-dir <clone>/.t3 --no-seed), source CLI with --base-dir pointing at it, real turns with --wait --json:
  • Claude Sonnet 5.5, --option effort=high: completed. Thread and run projections store options: [{"id":"effort","value":"high"}]; the Claude SDK query started with "effort":"high".
  • GPT-6.1 Sol on Codex, --option reasoningEffort=low: completed; the turn was sent with "effort":"low".
  • Claude Opus 5.5, --option effort=low --option fastMode=false: completed; fastMode stored as boolean false and passed to the provider as fastMode:false.
  • Usage errors exit 1 with one line: --option needs --provider and --model., --option 'effort' is not id=value., --option effort is given more than once.
• Not checked: other providers (Cursor, Grok, OpenCode, Antigravity) beyond the pass-through. No UI change.

Planned independently with Claude Opus 5.5 and GPT-6 Astra (the plans converged), implemented with Claude Opus 5.5 in Claude Code (T3 Code). Reviewed with GPT-6.1 Sol on high: approved, no findings.

🤖 Generated with Claude Code