Skip to main content
Scheduled tasks let an expert work while you’re away — a morning industry brief, a weekly data roll-up, a reminder at a specific moment.
Every run is a full conversation call and costs credits like any other. The task spends money while you aren’t watching. Estimate before creating: cost per run × runs per day × 30. Insufficient balance makes the run fail.

​
Two ways to create one

Both write to the same table and appear in the same list. Every task is bound to one expert — that expert’s persona and skills are what run at execution time. Creating from a conversation binds the current expert automatically.

​
Only four repeat modes exist

Nothing outside these four is configurable. “Mondays and Fridays”, “weekday mornings”, “every 2 hours”, “every 15 minutes” — the expert may agree in conversation, but what gets stored can only be one of the four above. For multiple times, create multiple tasks.
The time zone is stored per task (conversations default to Asia/Shanghai), so traveling doesn’t drift your schedule.

​
Task types

“Remind me to write the daily log” is a reminder; “write the daily log for me” is execute.

​
Managing tasks: what you can and can’t do

There is no edit operation. The expert’s schedule tool has exactly two actions, add and search, and the page offers only cancel and delete. Moving a task from 9am to 8am means deleting and recreating it. If you say “move the brief to 8am” in a conversation, the expert will most likely create an 8am task and not delete the 9am one — so you get two briefs a day. After any “change”, check the task list.
There are seven statuses: pending, running, completed, failed, cancelled, paused, and waiting_dependency.

​
Task dependencies

A task can name a predecessor, wait for it to finish, and receive its output. If the predecessor still isn’t done after an hour, this task is marked failed. On success, the predecessor’s result session is injected into this task’s prompt as context — which makes two-stage orchestration (“fetch data, then write the report”) workable.

​
What happens at run time

1

Trigger fires

At the scheduled moment the dispatcher hands off the task. If the service was unavailable and the moment was missed, a run within one hour still happens; anything later is skipped outright and never accumulates.
2

A new session is created

Every run creates a brand-new session rather than appending to the previous one.So runs have no memory of each other: day 30 cannot see what day 1 did. If you need continuity, put the context into the prompt or use a task dependency.
3

Sandbox is provisioned

A sandbox is allocated for this run. Failure to allocate does not abort the task — it degrades to no-sandbox mode and continues, meaning no code execution and no file I/O, leaving only capabilities like web search. Output that is suddenly much thinner than usual is typically this.
4

The conversation runs

Your prompt runs on the model currently selected on your account (platform default if unset), with web search enabled.
5

Results are delivered

Output is written to the task’s run record and pushed through your configured channels, with produced files attached.
On failure it retries automatically up to 2 times (3 attempts total) before being marked failed. One failed run doesn’t stop a recurring task’s next cycle.

​
Notification delivery

Available channels: in-app, email, Feishu, WeCom, DingTalk, WeChat. In-app and Feishu are checked by default. Tasks created from an IM conversation push results back to the conversation that created them. Files pushed alongside the result are filtered by extension — finished artifacts only, no intermediate scripts:
Intermediates like .py / .js / .json aren’t pushed — they’re still in the session’s file panel.
The actual delivery outcome per channel (success / failure / reason) is recorded separately and visible in the task detail. That makes “the task succeeded but I got nothing” self-diagnosable: check whether the run is completed, then check whether that channel’s delivery failed.

​
Billing

​
Failure modes and troubleshooting

​
Writing a good prompt

A scheduled prompt has to say everything up front — you aren’t there to answer follow-up questions.
Compare that to “send me AI news daily”: the latter gives you something different every day, the former gives you the same shape thirty days later. The clause most worth writing is the fallback (what to do on an empty day), because otherwise the model will pad to fill your requested count.

End-to-end: daily briefing

Build an automated brief from scratch

Billing formulas

The full token_split algorithm

Channels

Push results to Feishu, DingTalk, WeCom

Sandbox

Execution environment and degradation behavior