Pi seats: honour a node's effort (asking before any PR)

[smota]

Short version. I use Pi seats to run models and providers that OpenRig doesn't support natively, with a different reasoning effort per seat. The model reaches Pi, but the effort is dropped. Would you take a PR that passes a Pi seat's effort to Pi, and lets rig seat set-effort work on Pi seats?

What happens today

spec node                       Pi seat
─────────                       ───────
model:  provider/id     ──►     pi --model provider/id      ✓
effort: high            ──✗     (no flag, Pi uses its default)

• effort: on a Pi node is accepted and stored without a warning, but nothing passes it on. buildPiChildArgs has no thinking flag, and neither does the resume path.
• rig seat set-effort refuses Pi seats with "reasoning effort applies to claude-code and codex seats only", and EffortRuntime is "claude-code" | "codex".
• In my rigs, the Pi session files show 16 sessions pinned at low or high that ran at medium:

pinned   ran at   sessions
──────   ──────   ────────
low      medium   11
high     medium    5

• The only route today is Pi's native model+effort syntax, model: provider/id:high. Pi sets the thinking level from the suffix and records the model without it. Draft PR fix(daemon): Pi model-pin check reads a :<thinking level> suffix as Pi does #1403 supports that syntax in the model-pin check: a pin such as provider/id:high is compared as provider/id, so it no longer raises a false divergence notice. It also documents the suffix in rig-spec.md. fix(daemon): Pi model-pin check reads a :<thinking level> suffix as Pi does #1403 is stacked on fix(daemon): Pi model-pin check reads only the current runner's own record #1349 and will be marked ready once fix(daemon): Pi model-pin check reads only the current runner's own record #1349 lands.
• That keeps today's workaround usable, but it has limits: the effort is hidden inside the model string, set-effort still can't change it, and OpenRig doesn't report it.

Proposal

Pi already has the flag: pi --thinking <off|minimal|low|medium|high|xhigh|max>.

resolveSeatEffort(node) ──► effort E
                              │
        ┌─────────────────────┼─────────────────────┐
        ▼                     ▼                     ▼
  launch adapter        resume adapter       rig seat set-effort
  runner --thinking E   runner --thinking E  accepts Pi, Pi levels
        │                     │
        └──────► pi --thinking E ◄──────┘
                              │
                 session records thinkingLevel ──► observed effort

1. Pass it through: the runner takes --thinking <level> and forwards it to the pi child, on launch and on resume. With no effort set, nothing is passed and Pi keeps its default, as now.
2. set-effort: add pi to EffortRuntime, with Pi's own levels. The saved choice applies at the next launch or resume, as it does for the other runtimes.
3. Report it: the launched effort comes from the runner's --thinking argument, and the observed effort from thinkingLevel on Pi's assistant records. That fits the requested, saved, launched and observed values in seat-effort.ts.
4. Spec validation: an advisory when a Pi node's effort isn't a level Pi accepts, rather than dropping it silently.

Out of scope: an effort-divergence notice, and OMP.

Questions

1. Is this in scope, and as one PR or split into pass-through first, then set-effort and reporting?
2. Level names: Codex uses none and Pi uses off. Should OpenRig translate between them, or accept only each runtime's own names?
3. When both are set: a model: x/y:low suffix together with effort: high. Should the explicit --thinking win, which is what Pi does, or should spec validation flag the conflict?

I'd add unit tests for the runner and adapter arguments and a stub scenario for launch and resume, and describe the downstream effect, since launch and resume are on the arteries list.

[mvschwarz]

Thanks, @smota, for asking before building, and for the clear write-up of today's behaviour and the proposal. As you describe it, the ask is for Pi agents to keep their configured effort, passed to Pi as --thinking on launch and resume, and for rig seat set-effort to work on them, with the launched and observed effort reported. Your numbers make the gap concrete: in your rigs, 16 Pi sessions pinned at low or high ran at medium (11 pinned at low, 5 at high). Your description of today's behaviour matches our read of current main: rig seat set-effort refuses Pi agents ("reasoning effort applies to claude-code and codex seats only"), and nothing passes an effort to Pi. We'll come back to your three questions in this thread.

[mvschwarz]

Following up on your three questions, @smota:

1. One pull request is fine. Passing the effort on launch and resume, making rig seat set-effort and --clear work for Pi, and reporting the requested, saved, sent-at-launch and observed effort honestly fit together. Please build on the existing resolver (resolveSeatEffort in packages/daemon/src/domain/seat-effort.ts) and its rule that the latest explicit choice sticks until cleared, with clearing falling back to the spec's effort or the runtime default. Please leave out an automatic restart, any model or account change, separate storage for the effort, an effort-drift notice, and OMP changes.
2. Level names: use Pi's own levels, the ones you listed, with no translation of Codex's none to off and no mapping across vendors. An unfamiliar value should get an advisory, not a new refusal. Please tie the tests and docs to the Pi version you support, and when Pi falls back to or caps a level, report that separately from the level that was requested.
3. A model suffix and an effort together: when the resolver gives an explicit effort, pass it as --thinking, and let it win over a model suffix, which, as you note, is what Pi does. With no effort resolved, leave --thinking out and keep Pi's existing suffix, default and session behaviour. Please don't reject a model-and-effort combination that's accepted today, and don't change the model string to carry effort. After a clear, report what was sent at launch; Pi's level counts as changed only once it's observed.

For the observed effort, please read it from the supported Pi version's real session record for the current launch. Where that can't be tied to this launch, show it as not verified.

This isn't a promise of a merge or a release.

[smota]

Thanks, @mvschwarz. This is now up as #1528, built to your answers. It passes the resolved effort as --thinking on launch and resume, makes set-effort and --clear work for Pi, and reports the requested, saved, sent-at-launch and observed effort. It uses Pi's own levels, gives an advisory rather than a refusal, and leaves OMP unchanged. The first comment on the PR walks through the implementation. Closing this discussion so the review continues there.

[mvschwarz]

An update for anyone following this: @smota's #1528, based on the answers above, is merged to main and isn't in a release yet. A Pi agent's effort, when it's a level rig seat set-effort accepts, now reaches Pi as --thinking on launch and resume; for any other value no flag is sent, and Pi uses its default. rig seat set-effort and rig seat effort also work on Pi agents.

[mvschwarz]

Released in 0.6.13 (release notes), for anyone following this: @smota's #1528. A Pi agent's effort reaches Pi as --thinking from its next managed launch, restore or handover, including an effort already in a spec. rig seat set-effort and rig seat effort work for Pi agents too, and the report shows what was requested, saved, sent and, on Pi 0.99.0 or later, recorded. Thanks again, @smota.