{
  "@context": "https://schema.org",
  "@id": "https://aggr.aymericbeaumet.com/items/jxnl-co/2026-06-28-two-kinds-of-scheduled-work-in-codex/#webpage",
  "@type": [
    "WebPage",
    "ArchiveComponent"
  ],
  "articleBody": "Most automation language is more complicated than the job.\n\nYou want Codex to do something later, or keep checking something until it changes. That sounds like one feature. It is actually two different kinds of work, and the difference is simple:\n\n- **Scheduled Tasks** create a new thread every time they run.\n- **Scheduled Messages** use the same existing thread every time they run.\n\nThat is the whole model.\n\n## Use a Scheduled Task when every run can start fresh\n\nA Scheduled Task is best when the job makes sense without the conversation that created it.\n\nFor example:\n\n```text\nEvery morning at 9 AM, summarize what I need to catch up on from my email, calendar, and team messages.\n```\n\nTomorrow's summary does not need to remember today's summary. It needs the same instructions, current information, and a fresh place to report the result.\n\nThis is also useful when one task should run across several projects, or when you want each run to appear separately in Triage. Each run is its own thread. The schedule is the thing that connects them.\n\n## Use a Scheduled Message when the next check needs the thread\n\nA Scheduled Message, sometimes called a thread automation, returns to the same existing thread each time it runs.\n\nFor example:\n\n```text\nCheck this PR every 30 minutes. If there are comments, address them and keep CI green. Stop when the PR merges.\n```\n\nThe next check depends on the work that already happened. The thread knows which PR you mean, which comments were addressed, what failed in CI, and what has changed since the last check.\n\nThis is the right shape for:\n\n- polling for updates\n- checking for a status change\n- ongoing research or triage\n- work with a clear stopping condition\n\nThe thread is the thing that connects the runs.\n\n## The decision rule is context\n\nAsk one question:\n\n> If this ran tomorrow, would it need the earlier conversation?\n\nIf no, use a Scheduled Task. Give it a durable prompt and let each run start clean.\n\nIf yes, use a Scheduled Message. Keep the work in one thread so each check can build on the decisions and results that came before it.\n\nThe schedule matters, but it is not the main decision. The main decision is where the useful context should live.\n\n## Make your own loop skill\n\nI do not want to remember the setup questions every time, so I would make a small skill that turns a rough request into the right scheduled workflow.\n\nGive Codex this prompt:\n\n```text\nCreate a reusable loop skill for scheduled work.\n\nWhen I give it a request, first decide whether each run can start fresh or whether the next check needs the current thread's context.\n\nIf each run can start fresh, help me create a Scheduled Task.\nIf the next check needs the current thread, help me create a Scheduled Message.\n\nInfer what you can from the conversation. Ask only the missing questions that materially change the workflow:\n- What should Codex do each time?\n- How often should it run?\n- What change is important enough to report?\n- When should it stop?\n- When should it ask me for input?\n\nThen create the scheduled workflow with a short, durable prompt that will still make sense on a later run.\n```\n\nThe best automations do not start with a complicated system. They start with knowing whether the next run needs a clean slate or the same thread.\n",
  "authors": [
    "Jason Liu"
  ],
  "captured_at": "2026-09-27T19:29:15.293681927+00:00",
  "category": "programming",
  "content_html": "<p>Most automation language is more complicated than the job.</p>\n<p>You want Codex to do something later, or keep checking something until it changes. That sounds like one feature. It is actually two different kinds of work, and the difference is simple:</p>\n<ul>\n<li><strong>Scheduled Tasks</strong> create a new thread every time they run.</li>\n<li><strong>Scheduled Messages</strong> use the same existing thread every time they run.</li>\n</ul>\n<p>That is the whole model.</p>\n<h2>Use a Scheduled Task when every run can start fresh</h2>\n<p>A Scheduled Task is best when the job makes sense without the conversation that created it.</p>\n<p>For example:</p>\n<pre><code class=\"language-text\"><span class=\"code-snippet\">Every morning at 9 AM, summarize what I need to catch up on from my email, calendar, and team messages.\n</span></code></pre>\n<p>Tomorrow's summary does not need to remember today's summary. It needs the same instructions, current information, and a fresh place to report the result.</p>\n<p>This is also useful when one task should run across several projects, or when you want each run to appear separately in Triage. Each run is its own thread. The schedule is the thing that connects them.</p>\n<h2>Use a Scheduled Message when the next check needs the thread</h2>\n<p>A Scheduled Message, sometimes called a thread automation, returns to the same existing thread each time it runs.</p>\n<p>For example:</p>\n<pre><code class=\"language-text\"><span class=\"code-snippet\">Check this PR every 30 minutes. If there are comments, address them and keep CI green. Stop when the PR merges.\n</span></code></pre>\n<p>The next check depends on the work that already happened. The thread knows which PR you mean, which comments were addressed, what failed in CI, and what has changed since the last check.</p>\n<p>This is the right shape for:</p>\n<ul>\n<li>polling for updates</li>\n<li>checking for a status change</li>\n<li>ongoing research or triage</li>\n<li>work with a clear stopping condition</li>\n</ul>\n<p>The thread is the thing that connects the runs.</p>\n<h2>The decision rule is context</h2>\n<p>Ask one question:</p>\n<blockquote>\n<p>If this ran tomorrow, would it need the earlier conversation?</p>\n</blockquote>\n<p>If no, use a Scheduled Task. Give it a durable prompt and let each run start clean.</p>\n<p>If yes, use a Scheduled Message. Keep the work in one thread so each check can build on the decisions and results that came before it.</p>\n<p>The schedule matters, but it is not the main decision. The main decision is where the useful context should live.</p>\n<h2>Make your own loop skill</h2>\n<p>I do not want to remember the setup questions every time, so I would make a small skill that turns a rough request into the right scheduled workflow.</p>\n<p>Give Codex this prompt:</p>\n<pre><code class=\"language-text\"><span class=\"code-snippet\">Create a reusable loop skill for scheduled work.\n\nWhen I give it a request, first decide whether each run can start fresh or whether the next check needs the current thread&#39;s context.\n\nIf each run can start fresh, help me create a Scheduled Task.\nIf the next check needs the current thread, help me create a Scheduled Message.\n\nInfer what you can from the conversation. Ask only the missing questions that materially change the workflow:\n- What should Codex do each time?\n- How often should it run?\n- What change is important enough to report?\n- When should it stop?\n- When should it ask me for input?\n\nThen create the scheduled workflow with a short, durable prompt that will still make sense on a later run.\n</span></code></pre>\n<p>The best automations do not start with a complicated system. They start with knowing whether the next run needs a clean slate or the same thread.</p>\n",
  "content_markdown": "Most automation language is more complicated than the job.\n\nYou want Codex to do something later, or keep checking something until it changes. That sounds like one feature. It is actually two different kinds of work, and the difference is simple:\n\n- **Scheduled Tasks** create a new thread every time they run.\n- **Scheduled Messages** use the same existing thread every time they run.\n\nThat is the whole model.\n\n## Use a Scheduled Task when every run can start fresh\n\nA Scheduled Task is best when the job makes sense without the conversation that created it.\n\nFor example:\n\n```text\nEvery morning at 9 AM, summarize what I need to catch up on from my email, calendar, and team messages.\n```\n\nTomorrow's summary does not need to remember today's summary. It needs the same instructions, current information, and a fresh place to report the result.\n\nThis is also useful when one task should run across several projects, or when you want each run to appear separately in Triage. Each run is its own thread. The schedule is the thing that connects them.\n\n## Use a Scheduled Message when the next check needs the thread\n\nA Scheduled Message, sometimes called a thread automation, returns to the same existing thread each time it runs.\n\nFor example:\n\n```text\nCheck this PR every 30 minutes. If there are comments, address them and keep CI green. Stop when the PR merges.\n```\n\nThe next check depends on the work that already happened. The thread knows which PR you mean, which comments were addressed, what failed in CI, and what has changed since the last check.\n\nThis is the right shape for:\n\n- polling for updates\n- checking for a status change\n- ongoing research or triage\n- work with a clear stopping condition\n\nThe thread is the thing that connects the runs.\n\n## The decision rule is context\n\nAsk one question:\n\n> If this ran tomorrow, would it need the earlier conversation?\n\nIf no, use a Scheduled Task. Give it a durable prompt and let each run start clean.\n\nIf yes, use a Scheduled Message. Keep the work in one thread so each check can build on the decisions and results that came before it.\n\nThe schedule matters, but it is not the main decision. The main decision is where the useful context should live.\n\n## Make your own loop skill\n\nI do not want to remember the setup questions every time, so I would make a small skill that turns a rough request into the right scheduled workflow.\n\nGive Codex this prompt:\n\n```text\nCreate a reusable loop skill for scheduled work.\n\nWhen I give it a request, first decide whether each run can start fresh or whether the next check needs the current thread's context.\n\nIf each run can start fresh, help me create a Scheduled Task.\nIf the next check needs the current thread, help me create a Scheduled Message.\n\nInfer what you can from the conversation. Ask only the missing questions that materially change the workflow:\n- What should Codex do each time?\n- How often should it run?\n- What change is important enough to report?\n- When should it stop?\n- When should it ask me for input?\n\nThen create the scheduled workflow with a short, durable prompt that will still make sense on a later run.\n```\n\nThe best automations do not start with a complicated system. They start with knowing whether the next run needs a clean slate or the same thread.\n",
  "dateCreated": "2026-09-27T19:29:15.293681927+00:00",
  "date_created": "2026-06-28T00:00:00+00:00",
  "date_modified": "2026-06-28T00:00:00+00:00",
  "date_published": "2026-06-28T00:00:00+00:00",
  "description": "A simple rule for choosing between Scheduled Tasks and Scheduled Messages in Codex.",
  "external_url": "https://jxnl.co/writing/2026/06/28/two-kinds-of-scheduled-work-in-codex/",
  "git": {
    "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e",
    "path": "items/jxnl-co/2026/06/2026-06-28-two-kinds-of-scheduled-work-in-codex.md",
    "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/jxnl-co/2026/06/2026-06-28-two-kinds-of-scheduled-work-in-codex.md"
  },
  "id": "urn:aggr:item:7fe0189116ee42625a9a08ff2501c462ef43e38a",
  "isBasedOn": {
    "@id": "https://jxnl.co/writing/2026/06/28/two-kinds-of-scheduled-work-in-codex/"
  },
  "mainEntity": {
    "@id": "https://jxnl.co/writing/2026/06/28/two-kinds-of-scheduled-work-in-codex/",
    "@type": "CreativeWork",
    "archivedAt": {
      "@id": "https://aggr.aymericbeaumet.com/items/jxnl-co/2026-06-28-two-kinds-of-scheduled-work-in-codex/#webpage"
    },
    "author": [
      {
        "@type": "Person",
        "name": "Jason Liu"
      }
    ],
    "dateModified": "2026-06-28T00:00:00+00:00",
    "datePublished": "2026-06-28T00:00:00+00:00",
    "headline": "Two kinds of scheduled work in Codex",
    "timeRequired": "PT3M",
    "url": "https://jxnl.co/writing/2026/06/28/two-kinds-of-scheduled-work-in-codex/",
    "wordCount": 561
  },
  "name": "Archived snapshot: Two kinds of scheduled work in Codex",
  "preview": null,
  "reading_minutes": 3,
  "replicated_at": null,
  "source": "jxnl-co",
  "source_name": "Jason Liu",
  "summary": "A simple rule for choosing between Scheduled Tasks and Scheduled Messages in Codex.",
  "tags": [
    "applied ai",
    "codex",
    "personal",
    "personal software",
    "workflows"
  ],
  "temporalCoverage": "2026-09-27T19:29:15.293681927+00:00",
  "title": "Two kinds of scheduled work in Codex",
  "url": "https://aggr.aymericbeaumet.com/items/jxnl-co/2026-06-28-two-kinds-of-scheduled-work-in-codex/",
  "word_count": 561
}