Tasks are scheduled instructions that ChatGPT runs at a time you set, and the number you can have active at once is capped per account. OpenAI publishes the current figure with its plan details, and it has changed since the feature launched, so checking there is more reliable than any number quoted elsewhere.
The cap on active tasks is rarely the real constraint, though. What limits most people is that scheduled work is only useful when the instruction is specific enough to produce something worth reading, and most tasks fail that test rather than the quota one.
Key points
- Active tasks are capped per account, with the current figure published in the plan details.
- The limit counts scheduled tasks, not runs. A daily task occupies one slot regardless of how often it fires.
- Paused tasks usually still occupy a slot, so tidying up means deleting rather than disabling.
- Each run consumes normal usage, so a frequent task draws against your ordinary allowances.
- Specificity decides value. A vague scheduled instruction produces a daily notification nobody reads.
What tasks actually are
A task is a standing instruction with a schedule attached. You describe what you want done and when, and ChatGPT runs it at that time and delivers the result, typically as a notification.
The important distinction is between a task and a conversation. A conversation is you asking now. A task is you deciding in advance that a particular question is worth asking repeatedly, and delegating the asking.
That distinction determines what belongs in one. Anything you would genuinely ask again at a predictable interval is a candidate. Anything you asked once out of curiosity is not, and scheduling it produces a recurring answer to a question you stopped caring about after the first delivery.
Tasks can be one-off as well as recurring, which is the less-used half of the feature. A single reminder at a specific future time occupies a slot until it fires, and then releases it.
What counts toward the limit
The mechanics are simple but catch people out in three specific ways.
Slots are counted by task, not by execution. A task running every weekday morning occupies one slot, the same as one running annually. Frequency does not consume additional capacity.
Paused tasks generally still count. Turning a task off stops it running but usually leaves it holding its slot. Accounts that feel full often contain several disabled tasks nobody deleted.
One-off tasks hold a slot until they fire. A reminder set for three months away occupies capacity for three months.
Separately from the slot count, every execution consumes ordinary usage. A task that runs hourly and performs a search each time draws against your normal allowances considerably more than one running weekly. The slot limit and the usage limit are different constraints, and it is possible to sit comfortably within one while pressing hard on the other.
| What you set up | Slots used | Usage cost |
|---|---|---|
| One task running hourly | 1 | High, every run draws on your allowance |
| One task running weekly | 1 | Low |
| Five paused tasks | 5 | None |
| A one-off reminder three months out | 1 until it fires | Negligible |
| Ten active daily tasks | 10 | Ten runs a day against your allowance |
The table makes the asymmetry visible. Slots are cheap to occupy and expensive to waste, since a paused task costs nothing to run and still blocks capacity. Frequency is the reverse: free in slots, and the main driver of what scheduled work actually consumes.
Why most tasks get deleted within a fortnight
This is the more useful failure to understand, because almost everyone runs into it and the quota is not what stops them.
A scheduled instruction produces output whether or not there is anything worth saying. A task asking for news in a broad area delivers something every day, and after a week it is obvious that most days contain nothing that changes what you would do. The notification becomes noise, and noise gets muted and then deleted.
The tasks that survive share a property: they answer a question where the answer genuinely varies and the variation matters to a decision. Not “summarise industry news” but “check whether the specific regulation I am tracking has moved to the next stage”. Not “give me a morning briefing” but “tell me if anything on this list of five things has changed”.
The second formulation frequently returns nothing, and that is the point. A task that reports no change is doing its job, and it is far more valuable than one that manufactures a paragraph daily to justify its existence.
Instructions that make a task worth keeping
- Name the specific thing being watched, not the topic it belongs to.
- Say what counts as worth reporting and what does not, explicitly.
- Ask for nothing when nothing changed. Permission to stay silent is the most useful instruction in a scheduled task.
- Set the frequency to match the thing, not to your enthusiasm. Most things that feel daily are weekly.
- State what you will do with the answer, which sharpens what gets included.
- Review after two weeks. If you have not acted on a single delivery, delete it rather than pausing it.
- Write the prompt as you would for a person. A scheduled instruction gets no clarifying questions, so anything ambiguous is resolved without you.
Where scheduled work genuinely earns its place
It is worth being concrete about the cases that survive, because the successful pattern is narrower than people expect and quite consistent.
Watching something specific for a change of state. A regulatory consultation that will eventually publish its response. A job listing page at an organisation you want to join. A product that is out of stock. In each case there is a definite thing, a definite change, and a clear action when it happens.
Preparing for something recurring and dated. A weekly review that pulls together the same three inputs every Friday, or a monthly summary assembled from the same sources. The value here is not the search; it is not having to remember the assembly.
Reminding you of a decision rather than a fact. Tasks that ask a question, such as whether you followed up on something, work better than tasks that deliver information, because the useful output is your response rather than the text.
What all three share is a defined trigger and a defined response. Tasks without both tend to produce output that is read once, skimmed twice, and then ignored, and the account quietly accumulates several of them.
What to know before deciding
Several practical points shape whether tasks are worth using at all.
Delivery timing is approximate. A task set for eight in the morning runs around then rather than precisely, which matters for anything genuinely time-critical.
It sees what it can access. A task can search the web where that tool is enabled, but it cannot see inside systems you have not connected, it cannot open a file you did not upload, and it does not know what happened in your other conversations or projects.
Settings live with the task, not the account. Which model runs it, what tools it may use and how the result is delivered are per-task settings, so a task created months ago may still be using an older configuration you have since updated elsewhere.
Time zones need checking. Scheduling assumes a time zone, and a task set while travelling can end up firing at an unexpected hour permanently.
Frequent tasks are not free. Each run consumes usage, so an hourly task is a meaningfully different commitment from a weekly one.
Silence is a valid result. Tasks configured to report only on change are more useful and cheaper than those that always produce output.
Tasks compared with the alternatives
Scheduled tasks sit between two other approaches, and knowing which one your need fits avoids using the wrong instrument.
At one end is simply asking when you want to know. This is underrated. For anything you check irregularly, or where the timing depends on something else happening first, a conversation costs nothing to maintain and never becomes noise. The reason people reach for scheduling is usually that they are worried about forgetting rather than that the interval matters.
At the other end is proper monitoring: a system that watches a specific data source and alerts on a defined condition. Where the thing being watched has an interface a system can read reliably, that is more dependable than a scheduled natural-language instruction, because it checks a value rather than interpreting a page.
Tasks fit the middle, where the thing you want watched has no clean interface, the interval is genuinely regular, and a rough answer delivered on time is worth more than a precise one you have to remember to seek. That is a real category, and it is smaller than the number of tasks most people create.
The practical test is whether you would notice if the task silently stopped working. If you would not, it was not doing anything, and deleting it costs you nothing at all.
Decision framework
Five questions before scheduling anything.
- Would you actually ask this again next week? If not, it is a conversation rather than a task.
- Does the answer vary? Scheduling a question with a stable answer produces a recurring restatement of something you already know.
- Would a change here alter what you do? If not, the notification is information without consequence, which is the definition of noise.
- Is the frequency matched to the subject? Most things people schedule daily change monthly.
- Have you told it to stay quiet when nothing happened? This single instruction is the difference between a task that survives and one that gets muted.
Knowing when to delegate a recurring question to a system, and how to specify it so the output is worth reading, is a skill rather than a product feature. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
Your next step
Look at any tasks you already have and ask, for each one, whether you have acted on a single delivery in the last month. Delete the ones where the answer is no, which is usually most of them.
Then rewrite one survivor to name the specific thing you are watching and to say nothing when nothing has changed. That version will still be running in six months, which is more than can be said for the daily summary it replaces.