The schedule command manages scheduled agent execution.
Usage
Commands
Adding Jobs
Options
Examples
Add a daily reminder bound to a specific agent
Add a weekly digest
weekly runs every 7 days (604800 seconds).
Fire-and-forget alert
A reply in #C012345 lands as a brand-new turn instead of resuming the maintenance job’s conversation. Without --no-continuable, a delivered result is continuable by default — a reply resumes the job’s conversation with the brief in context.
Deliver via home channel
Run /sethome in the target chat first.
Deliver into a thread
Append a third :thread_id segment to thread the outbound message — a Slack thread ts, a Telegram forum topic id, or a Discord thread id:
The router preserves the thread segment end-to-end, so the message lands in the Slack thread rooted at message ts 1728987654.001234. Adapters without thread support silently ignore the segment. See Scheduler Delivery → Thread semantics.
Fire-and-forget notice
--no-continuable opts out of session seeding, so a reply starts a fresh session instead of resuming the job. See Continuable Delivery.
Fan-out to all home channels
Deliver back to origin chat
origin requires --channel and --channel-id so the executor can resolve the creating chat.
Blueprints & Suggestions
Create jobs from reusable templates, or accept consent-first suggestions — the same engine that powers the /automations and /blueprint chat commands. See Automation Suggestions for the concepts.
blueprint
Create a schedule from a blueprint template.
blueprint-list
List available blueprints (built-in + user YAML).
suggestions
List pending automation suggestions.
suggestion-accept
Accept a suggestion and create the schedule job.
suggestion-dismiss
Dismiss a suggestion without creating a job.
suggestion-propose
Propose a blueprint as a suggestion (manual/CLI trigger).
Examples
Add with delivery target [Legacy]
Start scheduler
List scheduled jobs
list merges store-backed jobs (created with schedule add) and daemon schedulers in one view. Store jobs are tagged [store].
Store jobs print as [store] <name> (id: <id>) [enabled|paused] — <cadence> — last run: <ts>:
list --json returns a single document splitting the two sources:
View logs
Stop a job
Delete a job
delete finds store jobs first (by id, then by name) and removes them; it falls back to the daemon PID handler for legacy jobs.
Skip the model turn when there are no new emails
--pre-run runs scripts/new_mail.sh before each tick. Exit 0 + stdout → agent runs with that stdout appended to the message. Non-zero exit → tick is skipped, no tokens spent, no Telegram ping.
--pre-run is a trusted, human-configured surface — it is not accepted by the agent-callable schedule_add tool, which prevents a prompt-injected agent from persisting arbitrary shell commands on the host. Configure --pre-run only via the CLI, YAML, or Python.
No-LLM command action
--command runs the shell command on schedule and delivers its stdout verbatim — model-free, so there is no agent turn, no tokens, and no --message needed. --command and --script are aliases for the same flag. See Scheduler Command Action for the full feature page.
--command is a trusted, human-only surface (like --pre-run) — it is NOT part of the LLM-callable schedule_add tool, so a prompt-injected agent cannot persist arbitrary shell commands. Configure --command only via the CLI, YAML, or Python.
Backend action
--backend runs the message as one headless turn through a registered CLI backend (see praisonai backends) — no native agent, no in-process model turn. It is mutually exclusive with --command. See Scheduler Backend Action for the full feature page.
--backend is a trusted, human-only surface (like --command and --pre-run) — it is NOT part of the LLM-callable schedule_add tool, so a prompt-injected agent cannot persist arbitrary backend jobs. Configure --backend only via the CLI, YAML, or Python.
--command and --backend together → --command and --backend are mutually exclusive: a job runs exactly one model-free action. Configure one or the other.- Invalid timeout →
--backend-timeout must be a finite, non-negative number of seconds.
- Missing
praisonai-code → CLI backend '<id>' unavailable: <e>. Backend jobs require the praisonai-code package (pip install praisonai-code).
- A duplicate schedule name now exits non-zero (previously it substring-matched
Error and could misclassify).
Pin a scheduled job to a specific model
--model snapshots the model onto the job so unattended runs stay on it — and fail closed if the default drifts. --no-pin follows whatever the default becomes:
See Scheduler Model Pin for the full feature page.
Managing store-backed schedules
A store-backed schedule is a job authored by schedule add, persisted in ~/.praisonai/config.yaml, and managed from the CLI without hand-editing YAML. list, delete, and describe are now unified across store and daemon jobs, and five subcommands manage the store surface end to end. The agent-callable equivalents live in Schedule Tools.
Which command should I use?
Store subcommands and daemon subcommands overlap, so pick by how the job was created.
Add a one-shot reminder
Pause and resume
Update cadence or message
update clears last_run_at when the cadence changes so the new schedule runs fresh — this avoids the “updated one-shot never fires” trap.
Show past runs
Remove a store-backed schedule
remove retains run history — query it any time with praisonai schedule runs <name|id>.
See Also
