[Feature]: Scheduled Prompts

[djfbryant]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

I want to be able to schedule a prompt for a later date/time so that if my agent pauses because my subscription usage has expired and the reset window is when I am asleep, I can trigger it to continue by scheduling a small prompt for a configurable date/time.

This could also be used to start an agent off on a new task while I sleep, enabling some further tokenmaxxing.

Proposed solution

Right-click on the send control and select the date and time for the scheduled message.

Why this matters

Ensures that (provider dependent) usage windows are not "wasted"

Smallest useful scope

Scheduled Prompt within an active thread, excluding a New Thread.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[dbiserov]

Was about to open a feature request for this exact thing. Same use case.

New to GitHub and not sure if commenting on this is perceived as useful or annoying, so sorry in advance if need be.

Still would be really useful though. And no other popular UI is currently doing a good job with that.

[jamesUBDau]

I'd like to throw my support behind this feature I need automated session that fire off in the morning, that I can then steer to completion once Im awake, like triaging my agency inbox (draft replies, create tasks in pm, close tickets etc).

I find claude code linux desktop app to be limited to what you can do with routines and cli is to hands off/fully automated to the point its not useful.

Would pair well with the new inbox design per project (which I love thank you!)

Routines/scheduled tasks per project would be amazing I have 50+ clients who I want to automate all their workflows and record data to Github per client folder in one repo.

[ElliotDrel]

The most important requirement for me is that scheduled prompts must not be local to the client that created them.

Cross-device use case

I may create a scheduled prompt on my laptop, then later open T3 Code on my phone and need to view, edit, reschedule, or cancel it. When the due time arrives, the prompt should still be sent to the original thread through the selected desktop or T3 Connect environment.

For example, I would like to schedule prompts for 5 hours and 10 hours from now, around when my Claude Code or Codex usage limits reset, without needing to leave the laptop UI open or return to the same device to manage them.

Expected behavior

• Scheduled prompts are stored in account-synced T3 state, not only in local browser or desktop state.
• They appear consistently across desktop, web, and mobile clients.
• A schedule can be created on one device and edited or canceled from another.
• Each scheduled prompt remains tied to its thread and intended execution environment.
• At the scheduled time, T3 routes the prompt to that environment for execution.
• If the target environment is temporarily offline, T3 clearly shows the pending/failed state and either retries when it reconnects or lets the user choose the desired behavior.
• The UI shows the scheduled time, timezone, target environment, and current status.

Without this, scheduling is much less useful because it depends on the originating device remaining available and cannot be managed from wherever the user is.

[CDVolvik]

I've been running three of these daily on Claude Code's scheduled tasks for a few months. Two failure modes that are worth designing against up front, since neither shows up until you've been running a while.

Missed runs are silent. The tasks fire only when the desktop is awake. One of mine, a daily dataset snapshot, skipped six consecutive days (7/25–7/30) and nothing surfaced it. I found it weeks later while investigating something unrelated. The daily row it writes isn't backfillable, so those six days are a permanent hole. A schedule I can't tell is broken is worse than no schedule, because I stopped checking the thing it was watching. Surfacing last-run, next-run, and an explicit missed state would have caught it on day one.

One-shots don't expire. Five of my eight tasks were one-time reminders tied to a date that has passed. They're spent and inert, so they don't fire, but they sit in the list still reading as current, and there's no way to tell freshness from correctness at a glance. One of them describes a situation that changed months ago and would produce a confidently wrong report if it were ever re-armed. An expiry date on one-shot schedules, or just marking them spent in the UI, fixes this.

The three that have held up over time share one trait: each describes a standing loop that re-reads its own state at the top of the run, rather than a dated errand. That distinction might be worth making explicit in the schedule type itself.

For what it's worth, routines are the only reason I still keep the other app open.

[eisverticker]

is it you opus?

[CDVolvik]

It was Grok.

[exaby73]

I was looking for similar stuff. For me, Codex's scheduled tasks are very powerful where the agent can create scheduled tasks for you. This is useful for having the agent work on a large piece of work, then set a polling scheduled tasks (runs veery X minutes) to send a prompt in the same chat or a new one to poll logs, etc. For me, I use this to poll for reviews on GitHub when using the Codex App.

[danjdewhurst]

Scheduled tasks are a must have feature. Shocked T3 Code is missing this.

[avatarneil]

I'd be interested in helping implement this, would be very valuable.

Main use case for me is automatic ticket hygiene. I love having my agents kick off a thread to keep my Jira tickets in sync with my PRs.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Issue #7966 expands this proposal from delayed prompts to server-owned one-shot and recurring agent work.

The schedule belongs to the environment server, not the client that created it. The environment process must still be running at fire time, which the UI should state. The original proposal uses one-shot at or anchored every intervals, deterministic fire IDs for retry, one coalesced run after downtime, and explicit create, cancel, list, fired, skipped, and completed state. It can attach to an existing thread or create one, but recurring work needs a clear lifecycle policy so it does not create a new branch every night.

The unattended-run follow-up adds four requirements: pin and display the permission profile, support an optional shell guard that skips a costly no-op run, record success or failure history and notify the user, and define whether recurring work reuses a standing thread or archives successful runs. The open implementation proposal is PR #7986. This handoff does not claim it is accepted or that scheduling exists on main.

[eisverticker]

I would also love to see this feature in t3 code. I'm usually using the cheaper plans for codex and Claude and thus I'm often restricted by the session limit. That means I have to limit the number of threads as I otherwise cannot complete the work within the session.
A scheduled thread would allow me to get more things done after the session limit was reset as I do not need to remember the task I wanted to write down and with scheduled tasks I do not even need to get back on my phone or laptop for firing the request.

[7heMech]

+1 changing provider during session and scheduled prompts prompts are must haves

[marcucio]

Is this planned or not? I like using T3 but without this I will have to look elsewhere like herdr

[sgtz]

I think this belongs within scheduled prompts, but I want to call out one specific requirement that may not be explicit yet: schedules should be model-callable, including both one-shot wakes and bounded persistent timers.

[marcucio]

I'm thinking something like "Every 30 min between 7am-6pm run the email-triage skill" which wakes up the thread with the email-triage prompt. There are edge cases we need to consider such as if the thread is currently running then we should define what the expected behavior would be.

[marcucio]

or run "continue" at 5:01 when my usage resets :)

[sgtz]

I'm thinking something like "Every 30 min between 7am-6pm run the email-triage skill" which wakes up the thread with the email-triage prompt. There are edge cases we need to consider such as if the thread is currently running then we should define what the expected behavior would be.

Is that via Claude or Codex? A prompt like you describe does work on Anthropic models. OpenAI models respond with something like, "The current OpenAI documentation says the host application manages pending async work; it does not prescribe a timer API or autonomous post-turn scheduling. Your model identified a missing host capability. That distinction will make the request harder to dismiss. [Official OpenAI model guidance](https://developers.openai.com/api/docs/guides/latest-model)"

So an OpenAI path to do this is not supported by design... unless they are gaslighting me (also possible).

[CDVolvik]

For anyone asking whether this is planned: Julius already has a version of it. #3638 merged into the new orchestrator branch (#2829) back on 7/1. It isn't on main, so it's waiting on the orchestrator, and I have no idea if it lands as-is. #10706 builds on it too.

I went through the code. Agents can create and edit schedules over MCP, and each run either posts into a bound thread or starts a fresh one. @marcucio, on your edge case: if the bound thread is mid-turn when a run fires, the prompt steers the running turn instead of waiting for it to finish. For email triage every 30 min I'd rather it queued.

Two gaps:

There's no one-shot. A schedule is either an interval or a fixed time on chosen weekdays, so "send continue at 5:01" turns into a daily task you have to remember to delete.

Skipped runs are still silent. If the machine is asleep more than 10 minutes past a fixed-time slot, the server logs the skip and moves the next run forward, but the task's status doesn't change. The settings row keeps saying "succeeded" with a new next time, so a missed day looks like a good one. Same thing that bit me with the snapshot job. A "skipped" status or a missed-run count would fix it.