# Reasonix Studio 2.45: Scheduled Tasks and Agent Dispatch Controls

Reasonix Studio 2.45 adds confirmed, read-only scheduled tasks and changes consent for agent dispatch, with specific runtime requirements and permission boundaries.

By Paras Madan | 2026-10-19


Reasonix Studio 2.45 arrived on October 19 with scheduled, read-only tasks and a clearer consent model for dispatching work between sessions. The practical change is that recurring checks can run without a fresh prompt, while enabling Dispatch now authorizes subsequent tasks and replies between linked sessions.

The [stable release](https://github.com/esengine/DeepSeek-Reasonix/releases/tag/studio-v2.45.0) belongs to the third-party DeepSeek-Reasonix project. It is MIT-licensed software, rather than an official DeepSeek model release. Model access and usage costs still depend on the providers configured in the application.

## Scheduled tasks need confirmation and a running scheduler

The command-line interface adds `reasonix schedule add`, `list` and `tick`, alongside related schedule-management commands. A person confirms the task in the terminal before it can run. The scheduled session is read-only, making this a fit for recurring inspections and reports rather than unattended code changes.

Studio runs confirmed schedules while it remains open with a visible window or tray icon. The [released ticker implementation](https://github.com/esengine/DeepSeek-Reasonix/blob/studio-v2.45.0/cmd/reasonix-studio-host/schedule_ticker.go) requires a supervised kernel and a visible interface, with a lock allowing only one kernel to tick at a time.

The CLI takes a different route: an operating-system scheduler must call `reasonix schedule tick`. Defining a task alone does not create an always-running service. Someone planning a morning repository check should verify that the chosen scheduler will actually be running at that time.

The [scheduler's timing rules](https://github.com/esengine/DeepSeek-Reasonix/blob/studio-v2.45.0/internal/runtime/scheduler/doc.go) also avoid replaying every missed slot. It considers the latest slot and checks its grace period. Opening a laptop after several days therefore does not launch several days of overdue runs; an expired slot is recorded as skipped.

## Read-only execution still needs resource limits

The [scheduled-run implementation](https://github.com/esengine/DeepSeek-Reasonix/blob/studio-v2.45.0/internal/frontend/schedulerun/exec.go) checks that the saved task still matches what a person confirmed. It then applies token, wall-clock and step limits using the tighter of the schedule's budget and the user's policy.

Those controls address different failure modes. A read-only task can still spend money, take too long or repeatedly encounter a blocked operation. The runner distinguishes budget stops, blocked runs and failures instead of treating any finished process as a successful report.

A sensible first schedule is a narrow check with a clear output and a small budget. Confirm where its report appears, whether it runs after a missed time and what happens when its model provider is unavailable before expanding the schedule to more projects.

## Dispatch consent moves to the setting

Version 2.45 changes what the Dispatch switch means. Enabling it gives consent for tasks and replies between a session and the sessions it opens, so those exchanges no longer each produce an approval card. Newly opened sessions retain the originating session's model, preset, approval mode and planning posture without widening them.

The [dispatch consent tests](https://github.com/esengine/DeepSeek-Reasonix/blob/studio-v2.45.0/internal/assembly/boot/effect_dispatch_consent_test.go) distinguish a verified linked session from an unrelated sender. The implication for users is worth making explicit: review the setting as an ongoing delegation choice, rather than expecting to approve every message individually.

A model can ask the user to enable a switch it needs, but the change requires confirmation. Security-boundary settings remain outside the model's ability to change. These are useful limits, although they still need to be understood alongside the actual permissions granted to the session.

## Notifications help when a run needs a person

Phone reminders can notify phones signed into the same account when an action awaits approval, a model asks a question or a turn fails. They contain the category and count, and must be enabled separately on the desktop and phone because both sides default to off.

That is a useful companion to longer-running work: the agent can continue within its configured scope, then tell someone when progress depends on a decision. It should not be confused with permission to approve an action automatically or a guarantee that a closed desktop keeps running schedules.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI founders and developer-tool teams explain agent permissions, workflow changes and technical launches in stories that reach the right users.

[Book a 30-minute call](https://cal.com/paras-madan/30min).