[Feature]: Auto-enable "Run on first message" when the first Model Router is created #17841

Problem

PR #17797 added a "Run on first message" toggle under /settings/meta-llm, defaulting it off. The toggle is only meaningful once a Model Router exists, and the most natural moment a user wants routing is right after they create their first router. Today they must create the router, then discover and flip a separate switch — an easy-to-miss extra step that leaves the feature effectively undiscovered.

Proposed behavior

When a user creates their first Model Router (the meta-profiles list goes from 0 → 1), the "Run on first message" preference is flipped on by default — but only if the user hasn't already enabled it themselves. Subsequent router creations leave the preference untouched, so an explicit user choice is always respected.

Acceptance criteria

• Creating the first Model Router (0 → 1) sets run_router_at_conversation_start to true when it was previously unset/off.
• If the user has already enabled the toggle, creating the first router does not change it (no overwrite of an explicit choice).
• Creating a second or subsequent router leaves the preference untouched.
• A failed preference write is surfaced to the user and does not abort router creation; the rendered switch and the persisted value stay consistent (both on, or both off).
• Existing gating is unchanged: a stale true with no active router still cannot emit route_task_to_model.
• No behavior change when no router exists — toggle still defaults off and everything works as before.

Notes

Follow-up to #17797. Non-issue: the toggle still defaults off globally; only the 0 → 1 creation moment flips it on.

This issue was created by an AI agent (OpenHands) on behalf of @juanmichelini.

OpenHands AI triage

The following comments and acceptance criteria were added by the OpenHands AI agent.

Triage

Scope is the Canvas frontend (OpenHands/OpenHands), the only surface that owns the run_router_at_conversation_start app preference (src/types/settings.ts, src/api/settings-service/settings-service.api.ts) and the /settings/meta-llm page (src/components/features/settings/meta-llm-profiles/meta-llm-settings-view.tsx). The router itself, the route_task_to_model tool, and the meta-profiles endpoints live in software-agent-sdk, so no backend or wire-contract change is expected here.

The intended trigger is already inferable from the code: handleSave in meta-llm-settings-view.tsx detects a 0 → 1 creation (view === "create" && active === null) and auto-activates the new profile. The requested change reuses that exact detection point to also default the preference on. The "do not overwrite an explicit choice" requirement is effectively "only set when the current value is falsy", since false is indistinguishable from unset (DEFAULT_SETTINGS.run_router_at_conversation_start = false). No product or design decision remains open, so this is ready for development.

Non-goals:

• Do not change the global default (DEFAULT_SETTINGS) — the toggle still defaults off when no router exists.
• Do not change the cloud settings API, the meta-profiles endpoints, or the existing buildRouterAtStartSystemSuffix gating.
• Do not add auto-disable-on-last-router-delete; only the 0 → 1 creation moment flips the preference.

Acceptance Criteria

• Creating the first Model Router (meta-profiles list 0 → 1) writes run_router_at_conversation_start: true via the existing settings path when the preference was previously unset/off.
• If run_router_at_conversation_start is already true, creating the first router does not write a new value for it (no overwrite of an explicit choice).
• Creating a second or subsequent router does not write run_router_at_conversation_start.
• When the preference write fails: the failure is surfaced to the user (error toast, consistent with the existing handleSave catch), the router is still created and activated, and the rendered switch reflects the persisted value (on only if the write succeeded) so the UI and stored value stay consistent.
• Existing gating is unchanged: buildRouterAtStartSystemSuffix(true, false) still returns undefined, so a stale true with no active router cannot emit the route_task_to_model instruction.
• With no router present, behavior is unchanged: the toggle renders disabled/off and no settings write occurs on load.
• Automated coverage: focused behavioral tests in __tests__/components/settings/meta-llm-profiles/meta-llm-settings-view.test.tsx assert the 0 → 1 on case, the already-true no-overwrite case, the second-router untouched case, and the write-failure case. npm run lint, npm test, and npm run build pass.
• Live validation on the agent-canvas dev stack: creating the first router on /settings/meta-llm visibly flips the toggle on, and the PR includes a screenshot/video of that behavior.