DeepSeek Harness 81 scheduled tasks in one session: fix

"All 81 tasks land in one conversation, editing one means scrolling half a day of history, and execution records are mixed with daily chat" — this is not caused by too many tasks, but by all of them being created in the same session. In the current implementation a scheduled task is hard-bound to the Session that created it, and the task record does not even have a "target session" field (#10911). So you have to use it in reverse: create the dedicated session first, then create tasks inside it. Four routes below, ordered by cost.

DeepSeek Harness: Priority 1: one session per task family (zero changes, do it today)

Create a dedicated session first, then create the matching tasks inside it; delivery, model, and preset all follow the session, and the main conversation stays untouched.

1. Decide the task grouping first: same business line, same model, and same preset go together.
2. Create a new session for every group outside the main conversation, with a prefix in the name, such as cron-market or cron-inspection.
3. Enter that session and create this family of scheduled tasks inside it.
4. Confirm the task's delivery target is that session: on expiry the host restores this cold session and delivers into it.
5. Stop creating any scheduled task in the main conversation; keep it clean.
6. Create as many sessions as you need groups, and do not try to mix tasks for different models into one session.

The value of this route is that it changes no code and needs no plugin, so it works today. The cost is that the session count grows with the number of task families.

DSH plugin: Priority 2: split one more layer by model and preset

A task's model and preset follow the source session, so grouping has to consider both together.

1. List every task and note the model and preset each one expects.
2. Merge tasks with the same model and preset into one dedicated session.
3. Do not mix tasks that need different reasoning levels, or you will have to compromise globally.
4. Keep only one class of task per dedicated session to reduce history noise.
5. Periodically clean up completed one-off tasks so a session does not bloat with history.

DeepSeek Harness: Priority 3: community plugins (verify them yourself)

The reporter listed several candidates in a similar direction, but the community reply reviewed none individually and never verified them at the 81-task scale.

1. The directions the reporter mentioned include "an independent Session per run", "the task itself is an independent session", and "run as a headless independent process".
2. Before choosing, confirm three things: does it actually open a new session per run, is there a usable management panel, and will it still install after a DSH upgrade.
3. Trial three to five tasks for a week before migrating all of them.
4. Check the plugin's own upgrade path; do not entrust 81 scheduled tasks to a package that has stopped receiving updates.
5. Any "upgrade and it breaks" trap should surface during the trial, not on production tasks.

This section has no definite conclusion, only a verification checklist — do not treat someone's list of candidates as a verified solution.

DeepSeek Harness: Priority 4: external scheduler + headless

Move scheduling entirely out of DSH and trigger a headless run from system cron or a workflow tool; each run is an independent process and naturally shares no session.

1. Write one headless invocation per task class, with the concrete prompt in the arguments.
2. Schedule it with system cron or a workflow tool so each trigger runs once and exits rather than staying resident.
3. Watch the credential source: headless checks only the launch environment, the calling directory's .env, and ~/.dsh/.env, so the scheduler's environment variables must be injected explicitly.
4. Write logs per task instead of relying on session history as the execution record.
5. In this setup, "editing one task" means editing one schedule entry and touches no conversation.
6. The cost is maintaining scheduling, credentials, and logs yourself — you have taken over orchestration.

DSH Plugin: Why you cannot "set a delivery target"

A task record contains only the source session that created it, with no target-session field, so "deliver task A into session B" is impossible in the current implementation.

1. Read the README wording: tasks are described as "follow-up messages in their original Session".
2. Read the mechanism: on expiry the host restores that original session.
3. Read the data structure: there is no field where a target session could be entered.
4. So any "create the task in a temporary session then change the delivery target" approach does not work.
5. A true first-class independent run body requires upstream to decouple tasks from sessions.

DeepSeek Harness: Trade-offs of the four routes

Judge by change cost, isolation, and maintenance burden together, not isolation alone.

If all you need is "stop scrolling half a day of history to edit a task", the first route is enough; if you require "every run starts from a clean context", only the fourth fully satisfies it.

Migrating existing tasks

Do not rebuild all 81 at once; migrate a small batch to verify the semantics, then move the rest.

1. Pick three unrelated tasks and rebuild them in dedicated sessions.
2. Wait until each has fired at least once and confirm delivery goes to the new session, not the old conversation.
3. Once confirmed, disable the old tasks in the original conversation instead of deleting them, keeping them as a control.
4. Observe for a week with no issues, then migrate the rest in groups.
5. After everything is moved, clean up the task records and history noise in the original conversation.

Cautions

Choose isolation by cost, not by how clean it sounds.

1. Do not create tasks in the main conversation. Once created there, all later deliveries come back to that session.
2. Do not mix tasks for different models in one group. The model follows the session, so mixing forces a global compromise.
3. Do not ignore the cost of cold session restore. The more tasks and the colder the sessions, the more visible the restore overhead.
4. Do not treat plugins as official capability. The reporter's candidates are unverified by the community; trial them small first.
5. Record task ownership. Write which session a task belongs to into its name.

If all your tasks are already in the main conversation, you do not need to rebuild history — create dedicated sessions, put future tasks there, and migrate old ones as needed.See Fix missing DSH schedule tools: presets and subagents for the related case.