Repository navigation
orchestration worker-start: accept --model (and --effort) for the pi and devin agents #26971
Description
Summary
orca orchestration worker-start --agent pi --model <id> and --agent devin --model <id> are refused, although both CLIs accept a model at launch. Please add pi and devin entries to the agent session-option catalog, as #24796 did for OMP and #24624 / #24768 did for OpenCode.
Observed (Orca 1.4.221, Linux; pi 1.1.0; devin 3000.11.3)
$ orca orchestration worker-start --agent pi --model openai-codex/gpt-6-luna --effort low --task <task> --worktree new-child ...
Agent pi does not support launch-time model selection. Omit --model to run the model from its own config.
$ orca orchestration worker-start --agent devin --model swe-2-medium --effort low --task <task> --worktree new-child ...
Agent devin does not support launch-time model selection. Omit --model to run the model from its own config.
Without --model, every worker runs the machine-wide default (pi: defaultModel / defaultThinkingLevel in ~/.pi/agent/settings.json; devin: agent.model in ~/.config/devin/config.json), and the receipt reports launch.effective.model = null. Rewriting those global files before each dispatch races with other coordinators on the same machine (the same concern as #19980 and #22896).
Launch flags the agents already accept
- pi:
--model <provider/id>(optional:<thinking>suffix) and--thinking <off|minimal|low|medium|high|xhigh|max>. Model discovery:pi --list-models. - devin:
--model <id>. Effort is part of the model id (swe-2-medium/swe-2-high/swe-2-max,claude-fable-5-1-low|medium|high, …). Model discovery:devin models list. A model-only entry, like OMP's, would cover it.
Evidence that the agents honour the flags under Orca supervision
On 1.4.221 we started each agent with the flag in an Orca terminal (orca terminal create --command "pi --model openai-codex/gpt-6-luna --thinking medium", and devin --model swe-2-medium), then bound a supervised worker to it with worker-start --terminal. pi ran gpt-6-luna • medium (its default is gpt-6.1-sol • low), and devin ran SWE-2 Medium (its default is Max). Both received the task and sent worker_done.
We would rather not rely on that path: it skips Orca's managed agent-first launch (for example, devin's first-run workspace trust prompt, #15860) and leaves launch.effective null.
Prior art
- orchestration worker-start: accept --model (and --effort as --thinking) for the omp agent #23388 (OMP): comments by @hieuphung97 and @fabkho ask for pi too, and @fabkho offered a small PR.
- feat(orchestration): support Pi worker launch models #17704 "feat(orchestration): support Pi worker launch models": closed on 2026-09-15 without merge. A later comment asks whether it has a blocker.
- fix(orchestration): allow model selection for OMP workers #24796 (OMP model selection, merged 2026-10-03); Validate OpenCode worker model preferences on the execution host #24624 and Keep OpenCode worker model selection separate from the default #24768 (OpenCode worker models, v1.4.222).
Expected
worker-start --agent pi --model X --effort Ylaunchespi --model X --thinking Y.worker-start --agent devin --model Xlaunchesdevin --model X.- The receipt's
launch.effectivereports the applied model and effort.
Activity
AmethystLiang commentedon Oct 12, 2026
Thanks for reporting. Looking into it
yoyofreeman commentedon Oct 13, 2026
Independent corroboration on a separate host (Orca 1.4.224, pi 1.1.0, Linux).
orca-ide orchestration worker-start --agent pi --model <provider/id> ...is still refused in 1.4.224:Our coordinator dispatches each worker on a per-task model (a free gateway group), and the global-config race you describe is real for us too: several pi sessions share one machine, so rewriting
~/.pi/agent/settings.jsonbefore each dispatch is not viable.Workaround we run today (same shape as the issue): create the terminal with the flag, then bind the supervised worker to it:
It works, but as you note it leaves
launch.effective.modelnull and skips the managed agent-first launch. A model-only catalog entry forpi(like OMP's) would let us drop the workaround.TomSpoct commentedon Oct 23, 2026
Same refusal on the worktree/agent-launch path, Windows host:
Use case: using Orca as the coordinator for implementation handoffs. Two constraints collide right now:
piagent carries the operator's failover machinery (subscription rotation across accounts), butworktree create --agent piresolves the model from pi's own config, so the coordinator can't pin the model the task needs.--agent codex --model <id> --effort <level>works and guarantees the model, but drops pi's failover entirely — the worker dies on one account's exhaustion instead of rotating.So the practical workaround today forces a choice between "wrong model" and "no failover".
Since pi's
--modelalready accepts a full reference with an optional thinking suffix (provider/id:medium), the mapping for this agent could be:--model→--model provider/id,--effort→ the:levelsuffix (or pi's--thinkingflag, if that's cleaner than suffix parsing in the launcher).floriandotorg commentedon Oct 30, 2026
Would be so nice to fix this, it blocks using cheap subagents.
fix(pi): start workers on a chosen model and thinking level
fix(pi): start workers on a chosen model and thinking level
fix(pi): start workers on a chosen model and thinking level
fix(pi): start workers on a chosen model and thinking level
fix(pi): start workers on a chosen model and thinking level
fix(pi): start workers on a chosen model and thinking level