feat(cron): add per-job reasoning effort across all surfaces

[dschnurbusch]

Summary

Adds a first-class, optional reasoning_effort override to individual cron jobs.

Runtime precedence is:

1. valid explicit job override
2. profile/global agent.reasoning_effort
3. provider/model default

Omitted, null, or empty values inherit the profile/global setting. Explicit none disables reasoning for the job. New writes are validated and canonicalized at the core cron storage boundary, while malformed hand-edited/legacy values remain read-safe: the scheduler warns and falls back to the global value.

This is a current-main consolidation of the work discussed in #23524 and the overlapping implementations in #7382, #26214, and #30929. It addresses the gaps identified there rather than copying an outdated parser path: current CLI ownership, gateway/dashboard APIs, both web and desktop cron editors, all supported effort levels including max/ultra, null/empty clear semantics, and malformed-record fallback.

Why this belongs on the job

Cron jobs already support per-job provider/model selection. Reasoning effort is the remaining inference axis that materially changes quality, latency, and cost. Keeping it global prevents a scheduler from running bounded classification work cheaply while preserving stronger reasoning for high-consequence jobs.

The field is deliberately not added to provider/model drift snapshots. An omitted override continues to mean “follow this profile’s global policy”; an explicit override pins the job’s reasoning policy. Existing jobs remain unchanged.

no_agent jobs preserve the value but do not use it, because no agent/model is instantiated. The UIs mark it inactive rather than deleting it, allowing a job to switch back to agent mode without losing its intended setting.

Surfaces covered

• Core cron create/update storage and validation
• Scheduler runtime precedence and safe malformed-record fallback
• cronjob tool schema, create/update/clear/list formatting
• Standalone hermes cron create/edit/list commands
• Interactive /cron create/edit/list commands
• Authenticated gateway /api/jobs
• Multi-profile dashboard backend
• Web cron editor and job metadata
• Desktop cron editor, detail view, types, and translations
• Suggestion/automation job-spec preservation
• User, CLI, tool, and internals documentation

Supported values

none, minimal, low, medium, high, xhigh, max, ultra

Python validation derives the active effort names from hermes_constants.VALID_REASONING_EFFORTS so cron does not develop a separate stale dialect.

Testing

• 693 passed — complete tests/cron suite
• 551 passed — focused cron tool, scheduler, storage, gateway API, dashboard backend, and CLI suites
• Web Vitest: 9 passed
• Desktop Vitest: 8 passed
• Web TypeScript typecheck: passed
• Desktop renderer + Electron TypeScript typechecks: passed
• ESLint on every touched frontend file: passed
• Ruff on touched Python files: passed
• git diff --check: passed
• Windows footgun scan: passed

The repository-wide Python suite was also started, but this local environment produced broad unrelated baseline fixture/environment failures outside the touched areas; the complete cron and focused cross-surface suites above pass cleanly.

Closes #23524.

Related: #7382, #26214, #30929.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #7382 — same feature (per-cron-job reasoning_effort override with job > global precedence) and same core mechanism (cron storage/validation + scheduler precedence + cronjob tool schema + CLI). #7382 is the earliest-open canonical; #26214, #30929 and #62623 already point there, and #23524 is the tracking issue. The extra effort levels, null-clear semantics and broader UI surface here don't change that it's the same feature. Related: #23524 (spec), #62623/#14617/#26214/#30929 (prior implementations).

[teknium1]

Thanks for the broad cross-surface implementation. The underlying job-level gap is still present on current main, but the scheduler resolution needs updating before this can be salvaged.

Problems

• The changed scheduler block replaces current main's resolve_reasoning_config(_cfg, str(model)) call at cron/scheduler.py:2991-2997 with direct parsing of only agent.reasoning_effort. That regresses the per-model agent.reasoning_overrides precedence introduced by e81d18dfb and documented in hermes_constants.py:951-1009.
• The new scheduler tests do not cover the current required chain: explicit job override → effective-model override → global value. Add coverage for both a matching model override and malformed job data falling through to that model override.

Suggested changes

• Keep the shared resolver for the fallback path: use the parsed job override only when valid; otherwise call resolve_reasoning_config(_cfg, str(model)).

Automated hermes-sweeper review.