[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.

[robin-liquidium]

Same here, and one step further than the status: catch up.

We moved 8 thread heartbeats from systemd to T3 scheduled tasks on an always-on Linux box, but kept 4 weekday/weekly jobs on a Mac on launchd, because the Mac is often asleep at fire time. launchd (and systemd with Persistent=true) runs a missed job once on wake. T3's isMissedFixedTimeRun drops anything more than 10 minutes late until the next occurrence, so a weekly task loses a whole week. Of our last 4 Mac runs, one started 16 minutes late and would have been skipped.

The original #7966 spec had "one coalesced run after downtime"; v0.1.0 skips instead. An opt-in per task would cover it, e.g. catchUp: "once" on fixed_time (default keeps today's skip), ideally passing the original due time into the run so the agent knows it's late. Plus the skipped status you describe for tasks that keep the skip behaviour.

[Nico-Pergande]

Usage-aware deferral, so a scheduled run doesn't fire into an exhausted window

The OP's motivation is a run landing while quota is spent and the reset happening overnight. I went through the scheduled-tasks implementation on the orchestrator branch (#3638) and I think that specific case is still open — worth naming before it lands, since it's cheap to add now and awkward to retrofit.

Reading ScheduledTaskService, a fire does markRunning → threadLaunch.launch (or sendToThread) → markCompleted, where succeeded/failed reflects the dispatch. rescheduleMissedRun only covers a fixed_time slot the server slept through, re-aiming at the next occurrence.

So if the bound provider account is out of quota at fire time, the dispatch still succeeds, the run records succeeded, and the turn fails inside the thread. For a daily fixed_time task the next attempt is 24h later, so the run is effectively lost — which is the scenario this thread opened with. Short-interval tasks self-heal; daily and weekly ones don't. (If the turn failure does propagate back into lastRunStatus, correct me — I've only read the branch, not run it.)

Proposal: before dispatching, check the bound provider instance's usage snapshot. If a window is exhausted and carries a resetsAt, set next_run_at = resetsAt (plus jitter) and skip the fire, rather than dispatching or treating it as a missed run. The data already exists — ServerProviderUsageWindow has usedPercent and resetsAt, and applyUsageLimitsUpdate keeps it current from live rate-limit events.

Details worth deciding:

• resetsAt is optional and unavailable: probeFailed is a real state, so fall back to current behaviour rather than blocking forever.
• Jitter, or every deferred task fires in the same second.
• Cap consecutive deferrals so a task can't defer indefinitely and silently.
• Make deferral visible — a distinct lastRunStatus (deferred), otherwise users see a task that "didn't run" with no explanation.
• Probably opt-in per task: "wait for quota" vs "run anyway".

Happy to implement this against the branch as a separate PR if you want it.

[borzaka]

A scheduled message feature would be really useful in T3Code.

For example, if I hit the 5-hour session limit and the reset is too late to wait for, I could schedule something like “continue where you left off” for the time the limit resets.

Would be a nice way to keep longer tasks moving without having to come back manually.

[NikitaMGrimm]

I also need it because of this reason. Sometimes my 5 hour limit resets while I sleep. If I could schedule a message, it could continue seamlessly

[shivanshPurple]

It would be a great feature. Because I need it to create new threads for me everyday for a specific task. Like for example (controlling browser -> going to a site -> process data -> wait for me if there is any input required -> otherwise the thread automatically settles itself) this loop everyday in completely new threads.

I would prefer if this new thread is implemented with a cli.
We can have a cli command like
t3 thread new --cron="* * * 1 *"
t3 thread settle <thread-id>
t3 thread delete <thread-id>

Idk. Upto the maintainaners. But something like this would be great.

[PixPMusic]

Settings should show which thread a scheduled task is connected to

When looking at a scheduled task in Settings, I cannot tell whether it sends prompts into an existing thread or creates a new thread on each run. The task list and editor hide the existing thread binding, and there is no way to jump from the task to its conversation.

This is visible when an agent creates a schedule through MCP: schedule_task defaults to binding the task to its current thread. Tasks created through Settings instead have no binding and create a fresh thread each run. Editing the agent-created task preserves its binding, but offers the same project and workspace controls as an unbound task. Changing the workspace control has no effect on bound runs. Changing the project can leave the hidden binding pointing at a thread outside that project and make subsequent runs fail.

Adding this here because #6748 is the canonical scheduling tracker. This proposal concerns the Settings presentation of behavior that already exists.

Smallest useful change

• Show the destination in the list: the connected thread's name, or “New thread each run.”
• Add “Jump to thread” beside Edit for a connected task, opening the thread on its owning environment. Use the same action in the editor.
• In the editor, show the connected thread's name and a short explanation that runs continue in that thread, using its workspace. Make the project and workspace read-only for bound tasks so those controls describe what will actually happen. Keep the task's model editable, with text explaining that the saved selection is used for scheduled runs.
• If the destination is unavailable, keep the binding visible and explain the reason. A disabled action can have a tooltip on web/desktop, but the explanation should also be readable without hover, including on mobile. A thread missing from the currently loaded sidebar should not be assumed deleted.

Cover web, desktop, and mobile, including schedules created through MCP. Keep binding changes, scheduler defaults, and execution policy outside this first change.

What happens today

I checked current main at 8ed276c246b624631e7d39241ebfd22d8314cb68:

• Settling a bound thread does not pause its schedule or create a replacement. The next scheduled message goes to the same thread and clears its settled state.
• Changing the task's model does not create another T3 thread. The task sends its saved model selection into the connected thread. Changing the thread's model later does not update that saved selection, so a later scheduled turn can switch it back. Following the thread's current model is already proposed separately in Thread-bound scheduled tasks should optionally use the thread’s current agent/model #13986.
• A bound task uses the connected thread's workspace; its saved workspace strategy is ignored. An unbound task creates a fresh thread on every run using its saved model and workspace settings.
• Archiving or deleting the destination makes bound dispatch fail; it does not fall back to creating another thread. fix(server): pause scheduled tasks bound to archived threads #11635 proposes archive/delete handling separately.

Source: scheduler dispatch, thread delivery, unsettling on message dispatch, MCP schedule creation.

Verification so far is the reported UI issue plus source inspection. The existing ScheduledTaskService, ScheduledTaskService.schedule, and ThreadManagementService suites passed (19 tests); these do not replace before/after client evidence for a future UI change. No UI or scheduler changes have been made.

Would maintainers approve this focused direction and scope for a PR, or prefer a different presentation of the connection?

[angelospk]

Scheduled tasks on nightly handle recurring work well (interval / fixed_time). What's still missing from the original ask is the one-shot case, and I think it fits better as a composer action than as a task.

Send later, like in iMessage: write the message now and pick when it goes out from a menu on the send button. It waits in the thread's queue with a clock badge ("waiting for: limits reset"), and you can edit it, cancel it or send it now like any queued message. In a new thread the same menu would say "Start later". Recurring work stays in Scheduled Tasks.

"When" doesn't have to be a time:

1. A time: tomorrow 09:00, or in 3 hours.
2. When quota is back: the 5h window reopens or a reset credit is redeemed. Auto-resume already detects this for limited threads.
3. When thread X finishes its run, e.g. an implementation thread hands off to a review thread.
4. When I settle thread X, so the next step starts once I've closed the previous one.
5. Before quota is lost: if the weekly window resets in 12h and only 40% is used, release the waiting work instead of letting the allowance go unused. This overlaps with @Nico-Pergande's usage-aware deferral point above.

Most of this already exists on the server: the message queue, deferred starts, the usage-limit recovery sweep, and the thread.unsnoozed contract, which already mentions future wake conditions. The new part is a wake condition attached to a queued message.

Smallest useful scope: one-shot by time plus "when quota is back", for queued messages in an existing thread.

Related to item 2: I'm running a small server patch locally for one edge case. Auto-resume waits for the resetAt reported with the failure, so after a reset credit is redeemed, limited threads stay stopped for hours. The patch resumes them once a fresh usage snapshot shows every window under 100%, and allows one early attempt per limit. I'm happy to open it as a focused PR, or help with Send later, if the direction sounds right.

[Alb11747]

Building on the "when thread X finishes" idea, it would be nice to schedule a task or prompt that waits for multiple selected tasks/threads to complete, or for all currently running tasks to complete. For example, I could run several implementation tasks in parallel and have a follow-up review task start automatically once they have all finished.

[PixPMusic]

Building on the "when thread X finishes" idea, it would be nice to schedule a task or prompt that waits for multiple selected tasks/threads to complete, or for all currently running tasks to complete. For example, I could run several implementation tasks in parallel and have a follow-up review task start automatically once they have all finished.

That sounds like something an orchestrator thread could handle—have one parent thread spawn the parallel implementations then start the review after.

V2 also adds features to allow threads in the same project to see each other

[saphid]

Limit a recurring task to certain days and hours, and cap its runs

Problem. A scheduled task can't express "every 30 minutes, only on weekdays between 09:00 and 17:00, and stop after N runs". This is the case @marcucio raised above ("Every 30 min between 7am-6pm…"). Today a user has to choose:

• Let an interval task run all night and all weekend, spending quota and posting into threads nobody is reading.
• Delete the task by hand when the work is done.

Reproduced on current main (a1d9d72aef) in an isolated dev server, using Settings → Scheduled Tasks → New task:

• Every interval offers only "Run every N minutes". It has no weekday picker and no start/end time.
• At a time has weekdays, but only a single time of day.
• Neither mode has a run limit. The saved row reads "Every 30 min · Next run in 30m" with no way to bound it.

Interval editor	Fixed-time editor

Smallest proposed scope. Three optional fields on the existing schedule. Nothing changes for tasks that don't set them.

• weekdays: for interval tasks too, matching what fixed-time already has.
• window: { start, end }: a local time window. Start is inclusive and end is exclusive, and a window never crosses midnight.
• maxRuns: when the cap is reached the task pauses itself. Raising the cap leaves it paused until the user explicitly resumes it, so editing a number never silently restarts work.

Web, mobile and the schedule_task MCP tool would expose the same fields. Clients would hide or block them against a server that doesn't advertise support, so an older server never silently drops a restriction.

Acceptance criteria.

• An interval task with weekdays and a window fires only inside them. Its next run skips to the next opening, including across DST changes.
• A run-only-restriction edit saves without touching other fields and survives reopening the editor.
• When the cap is reached, the task shows "Run limit reached", and Run now and Resume are disabled. Raising the cap keeps it paused until an explicit resume.

Verification plan. Focused schedule and service tests (window edges, DST, cap with manual and scheduled runs), plus before/after web and iOS captures of the editor and of the cap → change cap → resume flow.

An implementation exists on my fork. It is the earlier #14354 / #14714, now replayed on #11592 and #11635 so it lands after them, and I'm finishing fixes from an independent review.

Decision needed: is this scope (weekdays and window for intervals, plus a self-pausing run cap) the direction you want for scheduled tasks? If so, I'll open one focused PR after #11592 and #11635 land.

[Jardo-51]

Honestly, the users should be able to enter a CRON. That would solve every future usecase. The users of this app are devs anyway (the current UI could still be preserved for users who don't know CRON).

[AshutoshGitMirror]

A major change which will help the t3 workflow is having a "scheduled" tab or pushing the repeating threads into working section.

[AdEx-Partners-DE]

A fourth trigger that turned out to be the one I use most: when the thread goes idle.

Interval, fixed time and webhook all fire by the clock or from outside. What I kept wanting was "when you are done, check your work and carry on". So in my fork a task bound to a thread can run every time that thread becomes idle: no active or queued run, no open approval or question, and the last turn finished after the task was switched on.

The part that makes it usable instead of scary is the brakes:

• Maximum runs is required. At the limit the task switches itself off.
• Minimum pause between runs.
• Stop phrase: if the agent's last reply contains it, the task switches itself off instead of sending. Tell the agent "say DONE-NOW when nothing is left" and the loop ends by itself.

I ran both cases for real: a loop with a goal ended after exactly one run, two seconds after the reply; a loop without a goal stopped at its maximum of two. The list shows "When idle, 2 of 5 runs used".

One more thing from the same work, because several people here asked for it: a timed task in my fork skips its slot while its previous prompt is still queued or running in the bound thread. That alone ended the pile-up I described in the pause-switch idea (#18179).

An honest open point for #11249: my idle check is a 5-second poll in the task service, not an atomic admission in the orchestrator. It has been fine for one thread; I would like to hear whether people think that is good enough.

Would you use an idle trigger? And what would your stop condition be: a phrase, a run count, a budget?

Code: c7a394e70, b8330ae15, 3ba3b2bac, ef21659c9. on stark/main.

---

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.

[AdEx-Partners-DE]

Two additions since this comment, both tried with real runs in a dev build:

• Chaining across threads. An idle task can watch one thread and send to another: "send to thread B when thread A finishes". One run gives you "first this, then that" across two threads; several tasks make a chain. In my run the task sent exactly once after the watched thread ended and then switched itself off.
• A budget as a stop condition. An idle task can carry "stop when the account has under N percent of its tightest usage window left". Below that it switches itself off and writes the reason into the task list ("Stopped at the usage budget: 38% left, the task needs 99%").

So the brakes are now: run count, minimum pause, stop phrase, usage budget.

Code: 64338a671, 4bd4c4072.

---

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.

[Joao-kouznetz]

I'd like to contribute a focused improvement to the existing Scheduled Tasks workflow. This builds on Julius's scheduler from #3638 and the orchestrator merged through #2829; scheduling, MCP task management, remote execution, and fresh/bound thread delivery already exist.

I have implemented a prototype in my personal fork: PR #1 — recurring-task shortcuts across desktop and mobile. It is a fork-local PR, not an upstream PR.

What the prototype adds:

• A "Make prompt a recurring task" clock button while composing a new thread on desktop/web and native mobile. It opens the existing editor with the prompt, project, target environment, provider/model options, modes, and workspace selection preserved.
• A shortcut from the thread list to scheduled tasks, carrying the selected environment/project filters.
• Tasks grouped by project, with the saved prompt visible and the existing management controls.
• A supporting workspace adjustment for explicitly unbound MCP tasks: use the caller's selected branch, and support folder projects without requiring a Git worktree.

The existing MCP binding default is preserved: an agent scheduling work in its current thread's project continues in that thread by default. Fresh-thread execution remains an explicit option. I am not proposing a global switch to fresh threads.

The use cases motivating this are:

1. Check dependencies regularly, report outdated/vulnerable packages, propose updates, and run compatibility tests.
2. Inspect production health, application errors, failed requests, and deployment logs on the server that hosts the site.
3. Run recurring smoke, integration, or regression tests on the machine with the required platform, services, and dependencies.
4. Produce maintenance reports per project about failed CI runs, flaky tests, or unresolved operational issues.

Choosing the environment is essential: my laptop may be off while a server connected through T3 Connect stays available. I want to create/manage the task from my phone or desktop, while execution uses that server's files, tools, and provider credentials. The target T3 server must keep running; it does not need the desktop GUI.

For independent reports I deliberately intend to read, I would use the existing fresh-thread option: each result becomes a separate unsettled thread that I can follow up on or settle myself. Standing automations can keep their bound conversation. A new conversation need not require a new branch/worktree on every run.

The PR includes before/after Electron screenshots, editor/list evidence, and a responsive phone-size browser screenshot. After retaining the original binding default, 174 focused tests pass. The original Electron verification ran a prompt-created task automatically three times with Codex. Native iOS/Android interaction and an end-to-end run through the hosted T3 Connect relay are still pending; the phone-size screenshot is not native-mobile evidence.

Would maintainers approve this direction and scope for an upstream contribution? I can start with only the composer/list shortcuts and project presentation, and separate the workspace adjustment if you prefer a narrower first PR. One-shot scheduling, skipped-run status, completion history, and overlap policy would remain separate follow-ups.

[oskarsonc]

Proposal for a monthly option (day of month) on fixed-time scheduled tasks: #19009

[nacholibre]

A PR for the monthly proposal is now open: #26001 adds days of the month and chosen months to At a time tasks. #25479 adds a single monthly date.

Written with Claude Opus 5.5 (claude-opus-5-5) in Claude Code, running inside T3 Code.

[mrksrus]

One-time "Send later" from the composer

I'd like to support the one-time Send later proposal here, especially for the five-hour usage-limit case.

When my allowance runs out and resets overnight, I want to write my next prompt before leaving and explicitly schedule it for a few minutes after the reset. The prompt might contain new instructions, rather than just "continue". I shouldn't need to ask the agent to arrange its own timer or wake up to press Send.

The current nightly documents Resume at reset and Auto-resume limited threads. Those help continue an interrupted turn. This request is for sending a user-written prompt once, directly from the composer. The current scheduled-task contract supports interval, fixed-time, and webhook triggers, without a one-time trigger.

Suggested smallest scope, in an existing thread:

• Keep ordinary Send immediate. Offer an optional Send later menu, with long press on touch and Ctrl-click on desktop as possible shortcuts. A visible menu and keyboard access would help people discover it.
• Offer "In...", "At...", and "After usage resets". For the reset option, show the provider-reported reset time and allow a small buffer, such as two to five minutes. If the reset time is unknown, allow a manually chosen time.
• Save the exact prompt and its intended environment, provider, model, and permission settings. Show the scheduled time and timezone in the thread, with Edit, Cancel, and Send now controls.
• Persist the pending message on the environment server so closing the client does not cancel it. Clearly state that the execution environment must remain running. Show an overdue state after downtime rather than silently losing the prompt.
• Send it once. If the thread is busy, queue it for when the current turn finishes. If quota still blocks it, show that state and avoid repeated blind retries. Respect pending approvals and questions.

Recurring jobs and cross-thread dependencies can stay outside this first version. Would maintainers approve this focused direction and scope for a contribution, or is equivalent work already underway?

[jzhe727]

Currently, I have been using a workaround which is a scheduled task that tells the agent to cancel the task itself after it fires. This workaround really should not be necessary.

[andrewfree]

Adding an observed account-selection case and a timestamped dispatch/outcome mismatch. Environment: macOS arm64, Orchestrator V2. The installed package reports 0.0.46-nightly.20261013.3080; the long-running backend's exact build is unconfirmed. All event timestamps below are UTC on October 14, 2026. A and B are account aliases.

A five-minute task bound to an existing thread kept its saved account B selection while manual turns used account A. All used gpt-6-astra and the default service tier. The first manual turn and the scheduled turns used ultra reasoning; later manual turns used xhigh.

Origin	Account	Requested	Started	Outcome
Manual	A	06:57:51.066	06:57:51.412	Completed 07:01:09.561
Scheduled	B	06:58:57.661	07:01:10.272	Quota failure 07:01:11.818
Scheduled	B	07:04:00.954	07:04:01.044	Quota failure 07:04:02.175
Manual	A	07:08:01.246	07:08:01.585	Completed 07:09:51.815
Scheduled	B	07:09:05.476	07:09:52.251	Quota failure 07:09:53.627
Scheduled	B	07:14:05.944	07:14:06.022	Quota failure 07:14:07.014

Origins were checked against stored message provenance and scheduled-message identifiers. The first A turn also recorded a retryable 503, then produced further output and ultimately completed. The queued B turn did not interrupt it.

At 07:40:12Z, a fresh database snapshot showed the schedule's last_run_at = 07:39:17.818Z, last_run_status = succeeded, and last_run_error = null. Its corresponding scheduled turn had already failed at 07:39:19.100Z with usageLimitExceeded. Across the observed 06:58–07:39 interval, nine scheduled B turns failed on quota; four manual A turns completed. Separate quota reads at 07:05:51Z showed A's ordinary allowance available and B's exhausted.

This adds account-selection evidence to #13986, which explicitly proposed resolving the provider instance at dispatch. Its closed status alone does not establish that behavior shipped. It also gives a concrete instance of the dispatch-success concern already raised here. The installed release's scheduler source passes the saved selection and derives succeeded from dispatch completion.

Useful changes would be showing the schedule's saved account clearly, labeling dispatch success separately from the resulting turn outcome, and supporting the explicit follow-thread selection option. Quota-aware deferral could also avoid repeatedly adding failed turns. This report does not request automatic account fallback.

[manvankaliber]

This is practically this feature in combination with using the already available Scheduled Tasks:

#20863

[t3dotgg]

just tell your agent to do this

[controlledentropy]

I tested the Scheduled Tasks UI in T3 Code 0.1.7 and noticed a significant gap between the original request in this discussion and the current implementation.

When creating a scheduled task from Settings, I can select a project, model, and execution time, but I cannot select an existing thread as the execution target. The scheduled task starts a new thread.

This is particularly surprising because the original request explicitly specified:

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

As @PixPMusic pointed out earlier, the backend already supports thread-bound schedules through the MCP schedule_task tool. However, this capability is still not directly accessible when manually creating a task in Settings.

Why this matters for Codex usage-limit recovery

My main use case is straightforward:

1. A Codex agent is working on a substantial coding task.
2. The account reaches its usage limit, interrupting the existing thread.
3. T3 Code fails to obtain or propagate resetAt, so automatic recovery is unavailable.
4. I already know the correct reset time from the Codex usage information.
5. I want to enter that time manually and have T3 Code continue the interrupted work automatically.

Unfortunately, the existing Scheduled Tasks UI cannot target that thread.

The suggested workaround of asking the agent to create a scheduled task also breaks down in this scenario: the agent has already exhausted its quota and may be unable to process the scheduling request.

Requested improvements

1. Expose existing-thread targeting in Scheduled Tasks

• Let users choose between creating a new thread and targeting an existing thread.
• Allow selecting the target thread from the chosen project.
• Add a shortcut to create a scheduled task directly from an open thread.
• Display the target thread in the scheduled task editor and task list.
• Support both one-time and recurring schedules.

2. Add manually scheduled recovery for usage-limited threads

Add a "Resume at custom time…" button to the existing usage-limit recovery UI.

• Let users specify a date and time even when failure.resetAt is null.
• Schedule a retry of the interrupted turn using the existing recovery mechanism.
• Allow editing or canceling the scheduled recovery, or resuming immediately.
• Prevent duplicate execution if automatic recovery or a manual retry has already resumed the thread.
• Report the actual execution outcome if the account is still rate-limited.

These are related but distinct capabilities: sending a new prompt to an existing thread is useful, but it does not necessarily resume the original interrupted turn.

Why I think this is a reasonable extension

The scheduler already supports one-time execution, and the backend already supports thread-bound tasks. Much of the required scheduling infrastructure therefore appears to exist.

The missing pieces are exposing thread selection to users and connecting manual scheduling to the existing usage-limit recovery flow.

Scheduled Tasks are useful for recurring independent workflows, but manually scheduling continuation of ongoing work is equally important.

Could we support both behaviors without requiring the user to ask an agent to schedule its own continuation?

Related: #6748, #16185, and the recent Codex reset-time recovery reports.

[BierDav]

This feature would be great for this usecase: I sometimes compact my session when I'm near the 5 hourly limit, but the limit is still multiple hours ahead. I want to schedule a continue prompt to the point where the limit refreshes in less than an hour so that my cache doesn't expire

[controlledentropy]

This feature would be great for this usecase: I sometimes compact my session when I'm near the 5 hourly limit, but the limit is still multiple hours ahead. I want to schedule a continue prompt to the point where the limit refreshes in less than an hour so that my cache doesn't expire

Whoa, that's actually a clever way to use scheduling! But Tibo said signed-in Codex users have caches that never expire and can jump back into a session anytime, so I never thought of using schedules like this.

That said, it's a bit hard to believe—Tibo has been messing with us lately and hasn't delivered any 28-day results that left us "dizzy and slumped in our chairs." 😂

At this point, I just hope Astra can survive more than five minutes in Codex on Plus XD