feat(delegation): add unified subagent model and reasoning controls

[Xipong]

Summary

• add one shared subagent-model resolver using the existing model-switch/auth/normalization pipeline
• add hermes subagent model and classic/TUI /subagent model selection with inheritance reset
• add Desktop Settings model selection backed by the same provider catalog and profile-scoped REST semantics
• add an independent persisted delegation.reasoning_effort control for future children across shell, Classic CLI, TUI, and Desktop
• distinguish explicit reasoning Off (none) from Inherit parent; model and reasoning resets are independent
• fix the TUI subagent picker disclosure/wire: it now says persist: delegation config, cannot toggle global/session scope, and emits no fake session flag

Complete shell setup flow

hermes subagent model reuses the complete interactive hermes model setup flow rather than maintaining a smaller provider/model list. This includes every provider branch, login/setup actions, model discovery, and Custom endpoint creation.

Setup changes useful outside delegation are retained. For example, a custom endpoint created while selecting a subagent becomes a named custom_providers entry and is subsequently available in the primary picker. The active primary model block and auth route are restored, so selecting a worker model does not switch the current primary model.

Confirmed selections are captured at the canonical model-save seam (plus Azure Foundry's direct save path) using a context-local observer. New custom endpoints are persisted with their runtime-addressable custom:<name> provider slug.

The shared picker accepts display-only initial model/provider values. The subagent flow uses its persisted delegation.* selection for provider row, model hint, and nested model cursor; model-only overrides keep the inherited parent provider, while inheritance keeps ordinary primary-model defaults.

The command uses Hermes' dependency-free core picker/fallback stack; it does not add or import InquirerPy.

Subagent reasoning

The child-construction runtime already supports delegation.reasoning_effort with precedence delegation override > parent reasoning. This PR exposes that existing production wire rather than adding a second reasoning system:

• Shell: hermes subagent reasoning [none|minimal|low|medium|high|xhigh|max|ultra|reset]
• Classic CLI/TUI: /subagent reasoning [level|reset]
• Desktop: Settings → Model → Subagent model → Reasoning
• none produces {"enabled": false} for new children
• reset removes only the reasoning override and restores parent inheritance
• running children retain their startup reasoning config; each new child reads the current value without restart

REST model and reasoning mutations are separate fail-closed operations; a mixed request is rejected before the first config write. TUI uses a separate delegation.reasoning RPC. All surfaces call the same validation/persistence functions in hermes_cli/subagent_model.py.

Related work

Closes #67347. The Dashboard surface is covered separately by #67557. This PR supersedes the Desktop scope of #67523.

Surface parity

• Shell: hermes subagent model, direct model selection, reset, --reset, --refresh, and reasoning
• Classic CLI/TUI: /subagent model [model|reset] and /subagent reasoning [level|reset]
• Desktop: model/provider catalog, Inherit parent model, and independent reasoning selector
• Changes are profile-scoped and read for each newly spawned child

Verification

Current head (7ea0b9536), rebased onto main cc4cab2f5:

• post-rebase Python affected graph: 85 passed
• post-rebase TUI full suite: 1444 passed, 1 skipped; typecheck GREEN; affected lint zero warnings
• post-rebase Desktop settings suite: 23 passed; typecheck GREEN; affected lint 0 errors (pre-existing formatting warnings remain outside the new reasoning blocks)
• Ruff, py_compile, and git diff --check: GREEN
• deterministic RED contracts were observed before implementation for reasoning persistence/reset and TUI persistence disclosure
• independent core/runtime audit: 0 High; its REST mixed-mutation finding was fixed with pre-write rejection and regression coverage
• fresh child-construction proof through the real config/runtime seam:
  • high → {"enabled": true, "effort": "high"}
  • none → {"enabled": false}
  • reset → inherited parent {"enabled": true, "effort": "xhigh"}
• live installed shell entrypoint with isolated HERMES_HOME: set/status/reset GREEN

Earlier picker-specific verification remains covered by the branch history: complete custom endpoint flow, primary-model preservation, initial-pointer behavior, cancellation semantics, provider normalization, Desktop/TUI production builds, and the expanded picker/provider matrix.

[teknium1]

Thanks for consolidating the subagent configuration across the shell, TUI, Desktop, and shared persistence path.

Problems

• ui-tui/src/components/appOverlays.tsx:253 passes allowPersistGlobal={!subagentTarget}. For the subagent target this makes ModelPicker display persist: session only (ui-tui/src/components/modelPicker.tsx:624,691) and emit a session flag (:388). But the new /subagent model flow calls delegation.model (ui-tui/src/app/slash/commands/core.ts, PR diff), which persists delegation.model and delegation.provider. The picker disclosure is therefore incorrect for a cross-session configuration change.

Suggested changes

• Give the subagent target an explicit persistence label such as delegation config, and ensure the generated selection is not presented as session-only. Please cover that rendered TUI behavior with a regression test.

Automated hermes-sweeper review.

[teknium1]

For the subagent target this makes ModelPicker show persist: session only and append its session flag, but the resulting /subagent model call persists delegation.model/provider. Please give this target an explicit persistent-delegation label/mode so the picker does not promise session-only behavior.

[Xipong]

Fixed in 7ea0b9536. The subagent picker now labels this as persist: delegation config, disables the global/session toggle, and does not emit --tui-session. Added regression coverage for the label and argument.

[Xipong]

Rebased onto current main and fixed the subagent picker initial cursor so it points to the persisted delegation provider/model, including named custom providers, rather than the active primary model.

Picker verification after the rebase: Python picker/setup/provider matrix 147/147, TUI 80/80 plus typecheck, Desktop 22/22 plus typecheck, Ruff and py_compile passed.

[Xipong]

Added persisted subagent reasoning controls across shell, Classic CLI, TUI, and Desktop in 7ea0b9536. This exposes the existing delegation.reasoning_effort child-construction path; none explicitly disables reasoning, while reset restores parent inheritance. Model and reasoning overrides remain independent.

Current verification:

• Python affected graph: 85/85
• TUI: 1444 passed, 1 skipped plus typecheck
• Desktop: 23/23 plus typecheck
• Ruff, py_compile, affected lint, and diff-check: passed

CI run 30591780426 is still action_required with no jobs created for the fork PR. Could a maintainer approve the workflow run?

[teknium1]

Thanks for the thorough work here — the surfaces are well built (shared resolver module, full model_switch pipeline reuse, locale coverage) and the review confirmed it extends the documented delegation config design cleanly rather than fighting it.

Closing on scope grounds after maintainer review: this adds ~2.2k lines of permanent UI surface (CLI command tree, two slash-command integrations, Desktop settings panel, gateway RPCs) for config keys that already work today via hermes config set delegation.model/provider/reasoning_effort. That trade isn't one we want to take right now — and subagent visibility/control UX is about to be reworked as one coherent surface (a Mission Control overlay built on #70899's plumbing), which is the natural home for per-subagent model display and any future picker, rather than a parallel command tree landing just before it.

If we take a subagent model picker after that redesign lands, this PR is the reference for the resolver + selection-observer approach, and we'll credit it. Your delegation fixes (#74858, #66401, #68087) all merged with your authorship preserved — thanks again for those, they were excellent.

[Xipong]

Thanks — and to be clear, I am not asking to reopen #74375 or to land its TUI picker immediately before the redesign. The Mission Control direction described on #70899 sounds genuinely excellent; a unified live feed, timelines, budgets, steering, spawn tree, and replay view could be a major Hermes feature.

What I am missing is the product direction across Hermes' other first-class surfaces.

The closure here treats Mission Control as the natural home for any future subagent picker. But the scope announced on #70899 is currently a TUI overlay, and it does not include selecting the persistent model/provider/reasoning defaults used by future subagents. Model display inside a running-agent detail pane is useful, but it is not the same capability as configuring what the next subagent will run on.

More importantly, Hermes is not only a TUI product:

• Desktop already has much of the observational half of Mission Control in a separate implementation: an Agents view across sessions, nested parent/child trees, live activity streams, models, duration, tool/token/file metadata, aggregate cost, and child-session watch windows.
• Dashboard already has its own configuration and model surfaces, but no announced native equivalent of the new Mission Control controls.
• Plain CLI cannot reasonably use a TUI overlay as its only configuration path. hermes config set is a low-level escape hatch, but it is not equivalent to a provider/model picker with catalog discovery, authentication/setup, custom endpoints, coherent provider:model selection, and explicit reasoning inheritance/off semantics.

If Mission Control remains TUI-only, the result seems to be that the TUI becomes substantially more capable than Desktop and Dashboard for subagent orchestration, while Desktop's existing Agents view and Dashboard's existing configuration UI remain separate partial products. I cannot tell whether that divergence is intentional, temporary, or simply not planned yet.

That is the part I think needs clarification. Is Mission Control intended to be:

1. a TUI-specific feature, with Desktop and Dashboard expected to remain different and less complete;
2. a shared subagent control product backed by surface-independent state/RPCs, with native TUI, Desktop, and Dashboard presentations; or
3. the first implementation of a broader cross-surface design whose parity work just has not been announced yet?

And within that direction:

• is model/provider/reasoning selection for future subagents intended to become part of Mission Control, or is it a separate settings capability;
• are the existing Desktop Agents view and Dashboard expected to receive equivalent steering, timeline, budget, replay, and spawn controls;
• what is the intended lightweight path for plain-CLI users who do not run the TUI?

Even a rough direction would help. Right now the closure points to a future TUI feature as coverage for a cross-surface capability, while neither the published Mission Control scope nor a Desktop/Dashboard parity plan actually covers it. Mission Control sounds like a killer feature; I would just like to understand whether it is being designed as one coherent Hermes product or as a much more capable TUI surface alongside two separate, increasingly divergent applications.