Using the workspace
Scheduled jobs
Turn a request into a recurring task. Dus runs it daily, on weekdays, weekly or every few hours, each time in its own session and worktree, within a budget, and waits for you before anything risky.
A scheduled job is a request Dus runs again and again on its own: "Run the tests and fix anything that fails" every weekday at 09:00, a security review every Friday, a dependency check every 24 hours.
Creating a job
- Type the request in the message box.
- Click + at the bottom left of the message box.
- Choose Create scheduled job.
- Choose how often in Repeat.
- Set the time in At (for Every few hours, the number of hours in Every (hours)).
- Set the Budget per run ($).
- Click Schedule job.
You can pick a skill instead of typing a request, or as well: Create scheduled job needs one or the other. The dialog fills in a Name from your request; change it if you like. For Once a week, also choose the Day. Tick Run in Full Auto to let the job run in Full Auto.
| Repeat | Runs |
|---|---|
| Every day | Daily at the time you pick |
| Weekdays (Mon–Fri) | Monday to Friday at that time. The default, at 09:00. |
| Once a week | On the day and at the time you pick |
| Every few hours | Every 1 to 168 hours, counted from the last run |
The budget per run is $2 by default and at most $50. The job runs in the project you're in. Times are your computer's local time.
How a run works
- Each run is a new session with its own git worktree, so it never touches your checkout or another session's work. The project must be a git repository with a first commit.
- It runs in Auto mode: edits and commands inside its worktree go ahead without asking.
- Full Auto is used only if you ticked Run in Full Auto and the OS sandbox is on. Without the sandbox, the box is disabled and jobs run in Auto.
- The job's budget is that run's task budget. Reaching it stops the run (or asks, as any task does).
- Actions that always ask (pushing, deploying, database migrations, anything outside the worktree) are never approved on their own. The run pauses and the job shows Needs you until you answer in its session.
Duscode must be running for jobs to run. A run missed while it was closed happens once when Duscode next starts, not once per missed slot.
Managing jobs
All jobs are in Settings → Scheduled jobs, in one list. For each job you see:
- the project, schedule and budget
- Next: when it runs next
- Last: the result of the last run (Checks passed, Done, Checks failed, Stopped, Couldn’t run, Running or Needs you), when it ran and what it cost
The buttons are Open session (or Answer when it needs you), Run now, Pause / Resume and Delete. Resuming counts the next run from now. Deleting a job keeps the sessions it already ran.
Jobs are saved in ~/.duscode/jobs.json.
Pull request reviews
Below your jobs, Pull request reviews reviews the open project's pull requests by itself. It's off until you turn it on, and it works with GitHub, GitLab and Bitbucket (the project's origin).
- Open Settings → Scheduled jobs with the project open.
- Turn on Review pull requests automatically.
- Choose what one review may cost (up to $0.25 to up to $2).
Every 5 minutes, while Duscode runs, Dus looks for pull requests that are new or have new commits (drafts wait until they're ready). It reviews each with the same panel as /review: two or three different models, each reading only the changes, and one ranked list of findings. If nothing is wrong, nothing is posted.
Posting is your decision the first time. A review waits under Needs you (and in the bell) with what would be posted. Choose Post review, Post, and always post here (later reviews in this project post by themselves; Ask me first again undoes it) or Don't post. A review is one summary comment with every finding, plus a comment on the line for findings the models were confident about. The comments name no products, only how many models agreed.
It only ever comments. It never approves, requests changes, pushes to the pull request or merges it. Reviews count against your daily budget and each stays within its own limit; when the day's budget runs out, the rest wait for the next day. GitHub and GitLab use your own gh or glab sign-in; Bitbucket uses the email and API token from Apps & connectors.
Jobs that keep a page up to date
A job can update a canvas, for example a research board that gets a New this week section every Monday. The canvas shows when it was last updated and by which job.