Scheduled Runs

Ask the assistant to run something later — once, or on a recurring schedule — and it fires as its own fresh conversation at the time you asked for, with your prompt as the first message. There is no dedicated scheduling screen: you create, inspect, and manage scheduled runs the same way you do everything else, by asking in chat.

This feature may not be available in all setups. If the assistant declines to schedule something, it may not be enabled by your administrator.

Creating a scheduled run

Describe what you want done and when, in plain language:

"Every weekday at 9am, check open PRs in this repo and summarize anything waiting on me."

"One week from today, remind me to follow up on the migration ticket — start a new conversation about it."

Under the hood, every schedule is exactly one of:

• One-off — fires once at a specific time.
• Recurring — fires on a cron schedule (e.g. 0 9 1-5 for weekdays at 9am), interpreted in a timezone you can name; UTC is the default.
• Event-fired — fires when something happens inside the instance (another task finishing, a background job completing) instead of on a clock. This is a narrower, more technical option meant for chaining runs together; ask the assistant about it if you want one run to kick off right after another.

Once created, the assistant gives you back an ID for the schedule, and you can keep referring to it by name or description in later messages ("pause the PR summary task", "cancel that reminder").

What happens when a scheduled run fires

• A brand-new conversation is created, seeded with your stored prompt as its first message. It has no memory of the conversation you created the schedule from, so word the prompt so it stands on its own.
• The new conversation appears in your thread list like any other, marked as an automatic run.
• A Scheduled run card appears in it, showing the trigger (the cron expression or one-off time), when the run started, and — once it finishes — how long it took and how many tokens it used (see Limiting how much a run can spend below).
• Because nobody is watching it live, the run auto-approves its own tool calls rather than pausing to ask you, the way an interactive conversation would. See Permissions.

Unattended runs auto-approve their tools. You can point a scheduled run at a specific access profile to bound what it's allowed to reach; a named profile can only take repositories or tools away from what your own account already has, never grant anything beyond it.

Managing a scheduled run

Ask the assistant, in chat:

• "What scheduled runs do I have?" — lists your tasks with status and next fire time.
• "Pause the PR summary task." / "Resume it."
• "Snooze the nightly digest until next Wednesday."
• "Change that task to run at 8am instead." / "Change its prompt to also include closed PRs."
• "Cancel it."

You can only see and manage your own scheduled runs.

Limiting how much a run can spend

A scheduled run has nobody watching it, so a run that goes in circles could use a lot of tokens before its time limit stops it. You can give a task a token budget — the most tokens one run may use — and a time limit, when you create it or later:

"Every night at 2am, review yesterday's commits — cap each run at 200,000 tokens and 30 minutes."

"Raise the token budget of the nightly digest to 500k." / "Remove its token budget."

• What counts. Every token the run's assistant sends to or receives from the model, including its subagents and any external coding agents it calls. Prompt tokens the provider served from its cache count in full — the budget is a guard against runaway runs, not a bill. Background helper calls (the conversation title, summaries, memory recall, safety checks, context compaction) are not counted.
• The smallest budget is 1,000 tokens. Without one, your administrator's default applies, which is often no limit. Your administrator can also set a maximum that caps any budget you ask for.
• How a run stops. The budget is checked between steps, so a run can go over by up to one step (one model reply and the tools it started). At 80 % the assistant is told to save its work and wrap up. When the budget is spent the run stops with a note in its conversation, and is recorded as failed (stopped at token budget). Like a timeout, repeated failures count toward the task being turned off automatically.
• Runs waiting for an approval keep their budget: when the approval is answered, the run continues and its tokens keep counting toward the same budget. If the server restarts while it waits, the run ends as failed and is not continued.

When a run finishes, its card shows the tokens it used — for example Tokens: 84.2k (in 80.1k, cached 61k, out 4.1k) — and, if it had a budget, Budget: 100k (84 %). The Cost row says unknown when the model has no known price; it never shows a made-up $0.

Reviewing past runs

Ask "show me the last few runs of the PR summary task" or "what did the nightly digest say last time?" The assistant can list a task's run history — status, timings, token usage (including cached tokens) and the budget each run had — and pull back a specific run's original prompt and final answer without you needing to go find its conversation yourself.

How this differs from webhook-triggered runs

An unattended run kicked off by something happening outside the instance — a push to a repository, an incoming webhook — is not something you set up from chat. Those are declared by your administrator in the server configuration. They run through the same underlying engine and show up as the same kind of Scheduled run card, but you cannot create, see, or manage them as a scheduled run of your own.

Limits you should know about

• If a recurring run is still going when its next fire time comes around, the new fire is skipped rather than queued or run alongside it — a slow run does not pile up.
• Recurring schedules use plain wall-clock time in the timezone you named: on the day that zone's clock skips forward, a fire lands an hour late that day; on the day it repeats, it can fire twice.
• A run that makes no progress for about an hour is treated as stuck and marked failed.
• A run stops at its time limit (one hour by default, at most six hours) and at its token budget, if it has one. Both can be changed per task.
• Your administrator can disable recurring (cron) schedules entirely, leaving only one-off runs, or turn off scheduled runs altogether.
• Your account can have up to 1,000 active scheduled tasks at once by default; an administrator can change this limit.
• Finished run history — and the conversation each run created — is kept for a year by default before an administrator's retention setting cleans it up.