Summary
It would be helpful to have a scheduled prompt queue for situations where a user wants Mux to send a message later, especially around provider rate limits or overnight agent work.
Problem
When an agent run hits a token/rate limit, the useful next step is often already known, but the user has to come back later and manually send it. This is inconvenient for workflows such as:
- continuing work after a known reset time
- queueing a prompt for overnight execution
- sending a follow-up when rate limits are likely available again
- keeping long-running multi-agent work moving without manually watching the terminal/UI
Proposed UX
A possible design:
- Add a scheduled messages page or queue view.
- Let users compose a prompt and choose a send time.
- Let users target the prompt to a specific workspace/session/agent thread.
- Show pending, sent, skipped, failed, and canceled scheduled messages.
- Allow editing/canceling a queued message before it is sent.
- Require explicit user opt-in before any scheduled message can consume tokens.
Rate-limit-aware behavior
A later version could make this smarter:
- When a provider reports a rate-limit/reset time, Mux can offer to queue the next prompt for that reset time.
- If multiple providers/models are configured, Mux could optionally run when a suitable one becomes available.
- Users could set allowed execution windows, such as overnight-only execution.
- Backoff/retry behavior should be visible and user-configurable.
Safety and control
Because this feature can spend tokens while the user is away, I think it should be conservative by default:
- no automatic scheduling unless the user explicitly confirms it
- clear display of what will be sent, where, and when
- easy cancel/edit controls
- optional maximum retry count or maximum spend/usage guardrails
- no hidden background execution without visible queue state
MVP scope
A small first version could be:
- a local scheduled prompt queue
- manual date/time selection
- target current session/thread
- send once at the chosen time
- display queue state and allow cancelation
Rate-limit detection, provider availability checks, allowed run windows, and retry policies could be follow-up PRs.
Contribution offer
If this direction fits Mux, I would be happy to help implement it. I can start with the manual scheduled-message queue first, then split rate-limit-aware behavior into a separate follow-up if maintainers prefer.
Summary
It would be helpful to have a scheduled prompt queue for situations where a user wants Mux to send a message later, especially around provider rate limits or overnight agent work.
Problem
When an agent run hits a token/rate limit, the useful next step is often already known, but the user has to come back later and manually send it. This is inconvenient for workflows such as:
Proposed UX
A possible design:
Rate-limit-aware behavior
A later version could make this smarter:
Safety and control
Because this feature can spend tokens while the user is away, I think it should be conservative by default:
MVP scope
A small first version could be:
Rate-limit detection, provider availability checks, allowed run windows, and retry policies could be follow-up PRs.
Contribution offer
If this direction fits Mux, I would be happy to help implement it. I can start with the manual scheduled-message queue first, then split rate-limit-aware behavior into a separate follow-up if maintainers prefer.