Tugas Terjadwal Claude Code: Loop, Cron, dan Routine

Saya meminta sebuah sesi memeriksa deployment setiap lima menit lalu kembali satu jam kemudian dan menemukan ia memeriksa sembilan kali, bukan dua belas. Tidak ada yang gagal. Scheduler-nya memang menambahkan offset deterministik pada setiap waktu penyalaan dengan sengaja, dan saya membaca jam yang memang tidak akan pernah cocok.

Penjadwalan di Claude Code lebih berpendirian daripada kelihatannya, dan pendiriannya sebagian besar bagus begitu Anda tahu ia ada. Tulisan ini membahas tiga mekanismenya dan kapan masing-masing tepat, bentuk-bentuk yang bisa diambil sebuah loop, dialek cron yang didukung dan bagian yang tidak, serta dua perilaku — jitter dan kedaluwarsa tujuh hari — yang ada untuk mencegah pekerjaan terjadwal berubah menjadi masalah.

Tiga mekanisme, tiga batasan berbeda

Pertanyaan yang membedakannya bukan seberapa sering sesuatu berjalan, melainkan apa yang harus benar supaya ia berjalan sama sekali. Loop dalam sesi butuh sesi terbuka. Tugas Desktop butuh mesin menyala. Routine di cloud tidak butuh keduanya, dengan imbalan clone segar alih-alih file lokal Anda.

Apa yang dibutuhkan dan dikorbankan masing-masing:

Loop punya tiga bentuk, dan yang kosong justru paling banyak bekerja

Baik interval maupun prompt bersifat opsional, dan mana yang Anda sertakan mengubah perilakunya sepenuhnya, bukan sekadar kadensinya.

# Three forms, and what you supply decides the behaviour.

/loop 5m check if the deployment finished and tell me what happened
#   -> fixed cron schedule. Seconds round UP to the nearest minute.
#      7m and 90m round to the nearest clean cron step, and Claude
#      tells you what it picked.

/loop check whether CI passed and address any review comments
#   -> Claude picks each delay itself, between one minute and one
#      hour, based on what it just observed. It prints the delay
#      and the reason at the end of every iteration.

/loop
#   -> the built-in maintenance prompt, at a self-chosen interval:
#      finish unfinished work, tend the branch's PR (review
#      comments, failed CI, merge conflicts), then cleanup passes.

/loop 20m /review-pr 1234
#   -> a skill as the prompt. Only skills Claude is allowed to
#      invoke on its own actually run; built-in commands such as
#      /permissions or /model arrive as PLAIN TEXT instead.

# Esc clears the pending wakeup while a loop is waiting.

Bentuk yang mengatur laju sendiri adalah yang paling sering saya pakai. Tanpa interval, Claude memilih tiap jeda antara satu menit dan satu jam berdasarkan apa yang baru saja ia amati — jeda pendek selama build hampir selesai, jeda panjang begitu sebuah PR menyepi — dan mencetak jeda beserta alasannya di akhir tiap iterasi. Itu mengubah interval dari tebakan yang Anda buat di muka menjadi keputusan yang diberi tahu oleh hasil terakhir.

loop.md mengganti prompt bawaan, bukan jadwalnya

Loop tanpa argumen menjalankan prompt pemeliharaan bawaan: melanjutkan pekerjaan yang belum selesai, mengurus pull request branch saat itu, lalu menjalankan pembersihan ketika tidak ada lagi yang tertunda. Claude sengaja tidak memulai inisiatif baru di luar cakupan itu, dan aksi tak terbalikkan seperti push hanya dijalankan bila ia melanjutkan sesuatu yang sudah diizinkan transkrip. File loop.md menggantikan prompt itu dengan milik Anda — ia mendefinisikan satu default, bukan daftar tugas, dan sepenuhnya diabaikan kapan pun Anda menyertakan prompt di baris perintah.

# .claude/loop.md — replaces the built-in maintenance prompt
# for a bare /loop. Project-level wins over ~/.claude/loop.md.
# Plain Markdown, no required structure. Keep it under 25,000
# bytes; beyond that it is truncated.

Check the release/next PR. If CI is red, pull the failing job log,
diagnose, and push a minimal fix. If new review comments have
arrived, address each one and resolve the thread. If everything is
green and quiet, say so in one line.

# Edits take effect on the NEXT iteration, so you can refine the
# instructions while the loop is still running.

Dialek cron-nya, dan bagian yang hilang

Di balik layar Claude memakai tiga tool yang tidak pernah Anda panggil langsung — satu untuk membuat tugas, satu untuk mendaftarnya beserta ID dan jadwalnya, dan satu untuk membatalkan lewat ID. Tiap tugas mendapat ID delapan karakter, dan satu sesi menampung sampai 50 sekaligus. Ekspresinya cron lima field standar, dengan dua perilaku yang layak dipahami sebelum Anda menulis satu pun.

# CronCreate takes a standard 5-field expression:
#   minute  hour  day-of-month  month  day-of-week

*/5 * * * *      every 5 minutes
0 * * * *        every hour on the hour
7 * * * *        every hour at 7 minutes past
0 9 * * *        every day at 9am LOCAL — not UTC
0 9 * * 1-5      weekdays at 9am local
30 14 15 3 *     March 15 at 2:30pm local

# Day-of-week is 0 or 7 for Sunday through 6 for Saturday.
# Extended syntax — L, W, ? and aliases like MON or JAN — is
# NOT supported.
#
# When both day-of-month and day-of-week are constrained, a date
# matches if EITHER field matches. Standard vixie-cron semantics,
# and a reliable source of surprise.

CLAUDE_CODE_DISABLE_CRON=1     # kill the scheduler entirely

Jitter, dan kenapa tugas Anda tidak menyala tepat di menitnya

Supaya tidak semua sesi di dunia menghantam API pada saat jam dinding yang sama, scheduler menambahkan offset deterministik pada waktu penyalaan. Offset itu diturunkan dari ID tugas, jadi tugas yang sama selalu mendapat offset yang sama — ia bukan acak tiap penyalaan, melainkan pergeseran tetap yang bisa Anda siasati:

• Tugas berulang menyala sampai 30 menit setelah waktu terjadwalnya, atau sampai separuh intervalnya untuk tugas yang berjalan lebih sering dari sejam sekali. Job per jam yang dijadwalkan tepat di jam bisa menyala di mana saja dalam setengah jam berikutnya.
• Tugas sekali jalan yang dijadwalkan di awal atau tengah jam menyala sampai 90 detik lebih awal.
• Tidak satu pun berlaku untuk loop yang mengatur laju sendiri, yang memang sudah memilih jedanya sendiri.

Tujuh hari, lalu berhenti

Tugas berulang dalam sesi kedaluwarsa tujuh hari setelah dibuat. Tugasnya menyala satu kali terakhir, lalu menghapus dirinya. Ini batas yang disengaja atas berapa lama sebuah loop yang terlupakan boleh berjalan, dan itu default yang tepat — loop polling yang tak seorang pun ingat pernah dibuat adalah kebocoran token dan perhatian yang berjalan pelan. Kalau Anda butuh sesuatu yang tahan lama, itulah gunanya routine, tugas Desktop, dan pemicu terjadwal di CI.

Apa yang selamat dari restart, dan apa yang tidak

Cakupan per sesi adalah keseluruhan desainnya, jadi aturan resume-nya mengikuti dari situ:

• Memulai percakapan baru menghapus setiap tugas yang tercakup sesi.
• Melakukan resume mengembalikan tugas berulang yang belum kedaluwarsa, dan tugas sekali jalan yang waktunya belum lewat.
• Tugas background Bash dan monitor tidak pernah dipulihkan saat resume, apa pun keadaannya.
• Memindahkan sesi ke latar belakang membawa serta tugas loop-nya ke sesi background, yang terus berjalan tanpa terminal — satu-satunya cara menjaga loop sesi tetap hidup tanpa membiarkan jendela terbuka.

Aturan yang akhirnya saya pakai adalah mencocokkan mekanismenya dengan apa yang harus benar supaya pekerjaan itu berarti. Memeriksa sesuatu selagi saya memang sedang duduk di sana adalah loop sesi. Sesuatu yang harus terjadi entah saya di meja atau tidak adalah routine atau jadwal CI. Dan ketika yang saya tunggu memancarkan baris keluaran alih-alih menuntut pemeriksaan ulang, jawabannya sama sekali bukan penjadwalan — melainkan monitor, yang memberi tahu saya begitu sesuatu terjadi alih-alih bertanya tiap lima menit apakah sudah terjadi.