Summary

Add support for choosing which model a cron job uses when it is created, and make the selected or effective model clearly visible in the Web UI for existing cron jobs.

Problem to solve

Cron jobs can vary a lot in complexity. Some scheduled tasks are simple and should use a faster or cheaper model, while others need a stronger model for reliability or reasoning quality.

Right now, users do not have a clear Web UI flow to choose the model for a cron job, and it is not easy to see which model an existing cron job is running with. This makes recurring task cost, quality, and behavior harder to understand or audit.

Proposed solution

Add model selection and display support to cron jobs in the Web UI.

Requested behavior:
When creating a cron job in the Web UI, provide a model selector.
Store the selected model as part of the cron job configuration.
In the cron job list and detail views, clearly display the configured model.
If the job uses the default model, show that explicitly, such as:
Model: default
or Model: default (gpt-5-mini)
Ideally allow users to edit the model for an existing cron job.

Example display:
Daily briefing · Every day 09:00 · Model: gpt-5
Inbox triage · Every 30 min · Model: gpt-5-mini
Heartbeat check · Every 30 min · Model: default

Alternatives considered

Use only the global/default model for all cron jobs. This is simpler, but it makes it difficult to optimize different scheduled tasks for cost, speed, and quality.

Allow model configuration only through a config file or CLI. This would help advanced users, but Web UI visibility is still needed so users can easily inspect what recurring jobs are using.

Impact

This would make cron jobs more transparent and configurable.

Benefits:
Users can choose cheaper/faster models for simple recurring tasks.
Users can choose stronger models for important scheduled workflows.
Cron job behavior becomes easier to understand.
Recurring model usage becomes easier to audit from the Web UI.
Cost and performance management improves.

Evidence/examples

Examples of cron jobs that may need different models:
A simple heartbeat or reminder can use a lightweight/default model.
A daily planning summary may need a stronger model.
Inbox or calendar triage may need a model with better reasoning.
Long-running or high-frequency cron jobs need visible model settings because they can affect cost over time.

Additional information

The main requirement is Web UI clarity: users should be able to look at cron jobs and immediately understand which model each one uses. The model should be visible both when creating a cron job and when reviewing existing cron jobs.