⏰ Timing: scheduling and loops

Many repetitive day-to-day tasks — checking email, reviewing a number, updating a spreadsheet — depend only on your memory and willingness to remember. When the day gets busy, they disappear from the list.

Recognizing this pattern is the cue to ask, “Should this run on its own?”—the core question of this entire track.

Repetitive tasks, mental load, forgetting due to overload.

Whenever you think about automating something, ask this question in three parts: do I need this now (just once)? I need to in this project (monitor it for a short time)? Or do I need to every week (forever, at a fixed pace)?

It's the compass for the entire track. Each answer points to a different technical path, and choosing the wrong one costs time—or worse, creates automation running without control.

Guiding question, time scope, decision before using the tool.

If the answer is “I only need this once, today,” the right answer isn’t to schedule anything—it’s simply to ask Claude Code directly, right then, as you’ve been doing since Track 0.

Many people automate too early something that was only going to happen once. That wastes setup effort on work that won’t be repeated.

One-time task, direct execution, no automation.

Scheduled task — new here? It's a request you configure once, at a fixed time (every day at 8 a.m., every Monday, every month), that runs on its own without you opening Claude Code again. If the answer to the guiding question is "every week" (or every day, or every month), this is the way to go.

A real routine — one that repeats forever at the same pace — is exactly what a scheduled task handles. Module 6.2 explains how it works under the hood.

Scheduled task, fixed time, indefinite repetition.

Loop — new here? It's Claude Code keeping an eye on something, checking from time to time, within the same conversation — but only for a short period, not forever. If the answer is "only while this project lasts" or "just for the next few days," this is the way to go.

Loop solves the middle ground: neither a single run nor an endless routine. It’s for keeping track of something in progress—a deploy, a reply that’s taking a while, a file that’s still on its way.

Loop, live session, temporary monitoring.

The module uses a comparison table (you’ve already seen it at the top of this page) that compares where each one runs, whether it retains memory, how long it lasts, what happens if the PC shuts down, and what each one is for.

Knowing this table by heart prevents the trail’s most common mistake: scheduling a task that should be a quick loop, or vice versa.

Structured comparison, decision reference, quick-reference table.

It’s a request configured once—with instructions, a time, and a frequency—that the Claude Code desktop app runs on its own, without you needing to open or type anything at that moment.

Understanding the mechanics behind it (not just that “it runs on its own”) helps you configure it correctly and predict when it will—or won’t—run.

One-time setup, automatic trigger, desktop app.

Scheduled tasks live inside the Claude Code desktop app — they aren’t something you configure by typing a command in the terminal, as in module 0.2. They have their own screen, with a list of tasks and schedules.

Knowing where to look saves you the frustration of trying to find this setting in the wrong place (the terminal, where it doesn’t exist).

Desktop app, its own interface, outside the terminal.

Each time the task runs, it’s as if it were the first conversation: it doesn’t remember what it did yesterday or what you discussed with Claude Code at another time. It just runs the instruction you configured.

This is the point that most confuses people coming from the loop (module 6.3): a scheduled task doesn’t accumulate context. If it needs to "remember" something, that information has to be written in a file it reads again every time.

Isolated session, no memory between runs, self-contained instruction.

Unlike the loop, a scheduled task doesn't expire on its own. Once set up to run every Monday at 9 a.m., it keeps running every Monday at 9 a.m. until you pause or delete it yourself.

This is exactly what makes a scheduled task right for a real routine—but also why it requires more care during setup: an error there repeats forever, not just once.

Without automatic expiration: perpetual repetition, and the responsibility to turn it off.

If the computer was turned off (or had no internet connection) at the scheduled time, the app won’t simply skip that run—it will catch up and run as soon as possible, when the computer becomes available again.

This is an important practical difference from the loop, which simply stops if the session closes. The scheduled task can withstand interruptions to your computer.

Missed run recovery, resilience to shutdowns, automatic rescheduling.

Objective: set up a task that runs every morning at 8 a.m. and summarizes the pending items in a notes file.
Paste into Claude Code (desktop app, scheduled tasks screen):
Todo dia às 8h, leia o arquivo <caminho do seu arquivo de notas> e me mande um resumo em 3 linhas dos itens ainda não marcados como feitos.
How to verify: wait for the next scheduled time (or use the “run now” option if the app has one) and check that the summary arrived.

Seeing the actual prompt, with the time and action written out, takes the fear out of setting up your first task on your own.

Copyable prompt, variable marked, result verification.

A loop is Claude Code repeating a check from time to time within the same conversation where you asked—for example, "keep checking this site every 10 minutes until the price drops"—without you having to reopen anything.

It's the right tool for tracking something that's “in progress” right now, without turning it into a permanent routine that you'd have to remember to turn off later.

Periodic check, same session, active monitoring.

Unlike a scheduled task (tied to the desktop app), a loop runs anywhere you’re already chatting with Claude Code: in the terminal, inside VS Code, or in the desktop app itself.

This makes it more flexible for day-to-day work—you can start a loop in the middle of a regular work session without switching tools.

Multiple platforms, same conversation interface, no separate app.

Unlike a scheduled task, the loop continues within the same session—so it remembers what you asked for and what it already checked, and can adjust its behavior based on that without you having to repeat everything.

This living memory is what makes the loop work well for situations that evolve: "keep trying until it works," "let me know if anything changes."

Context continuity, a single session, adjustments over time.

A loop has an expiration date—around three days. After that, it stops on its own, even if the condition you specified still hasn't happened.

This limit is intentional: it prevents a "keep an eye on it" instruction set in a rush from turning into a forgotten automation that runs forever without supervision.

Automatic expiration, short time limit, prevention of orphaned automation.

If you close the terminal, close VS Code, or turn off the computer before the loop finishes, it simply stops—and doesn't resume on its own like a scheduled task does.

Knowing this weakness helps you avoid using a loop for something critical that needs to survive a shutdown. For that, a scheduled task is the right approach (module 6.2).

Permanent interruption, no recovery, dependence on the session staying open.

Objective: ask Claude Code to monitor a log file and alert you if an error appears, so you don't have to check manually.
Paste into Claude Code (terminal, VS Code, or desktop app):
Fica checando o arquivo <caminho do log> a cada 15 minutos pelos próximos 2 dias. Se aparecer a palavra "ERROR", me avisa na hora com a linha completa.
How to verify: trigger a test error in the file (or wait for a real one) and check whether the alert arrives within the 15-minute window.

A real loop, with an explicit time limit and a clear trigger condition, shows how to write a request Claude Code can keep running on its own.

Copyable prompt, trigger condition, explicit time window.

"Learning" here doesn’t mean the AI getting smarter on its own — it means you (or the routine itself, following your instructions) saving what worked and what didn’t in a file, so the next run can read it and adjust its behavior.

This clarification sets realistic expectations. The routine improves because it accumulates written information, not because it "understands" you over time.

Data-driven refinements, a memory file, realistic expectations.

As we saw in module 6.2, a scheduled task doesn’t remember anything between runs—unless you give it a file to read and write. That file becomes the routine’s “memory.”

This is the trick that solves the scheduled task’s biggest limitation: giving it a fixed place to note what it needs to remember.

Preferences file, persistent read-and-write, external memory.

A practical example: if every time the routine alerts you to something, you reply, "ignore that, it's not important," you can ask it to add that kind of alert to a "don't repeat" list—and stop bothering you about it.

This cycle of correction and application makes the routine more useful (and less annoying) over time, without requiring you to reconfigure everything from scratch.

Feedback cycle, exclusion list, incremental refinement.

A traditional automation script (outside Claude Code) always does exactly the same thing, the same way, forever. A routine with file-based memory can change its behavior without you rewriting anything—just edit the file, or let the routine edit it itself.

Understanding this difference helps you decide when it’s worth adding this extra memory layer and when a simple, fixed request is enough.

Fixed behavior × adjustable behavior, setup cost, flexibility gains.

It’s important to be clear: the routine doesn’t go off developing its own judgment or making decisions beyond what’s written in the instruction and memory file. Every bit of “learning” has a traceable source—a text that someone (you) chose to save.

This limit protects against two errors: trusting a routine too much because you think it "understands" context that was never written down, and being afraid it will act outside the agreement.

Traceable behavior, no autonomous judgment, predictability (see module 6.5).

Objective: a scheduled task that, in addition to notifying you, records in a file whether the notification was useful, so it can be adjusted later.
Paste into Claude Code:
Toda segunda às 8h, leia <caminho do arquivo de preferências>. Se ele tiver um item marcado "ignorar", não me avise mais sobre esse tipo de coisa. Depois de cada aviso, pergunte se foi útil e anote a resposta nesse mesmo arquivo.
How to verify: reply "wasn't useful, ignore it" in one run and confirm that the next run doesn't repeat that type of warning.

Pasting this prompt and watching the preferences file grow over time is concrete proof that “learning” here means writing and reading, not mystery.

Copyable prompt, named preferences file, verification through repetition.

Determinism — new here? It's the property of a process always producing the same result for the same input. The opposite — when the result can vary even with the same input — is called nondeterminism.

Since the entire track revolves around automation running without you watching, understanding this concept is what separates a reliable routine from one that catches you by surprise.

Determinism, nondeterminism, predictable results.

In a live conversation, if Claude Code interprets something in an unexpected way, you correct it immediately. In a scheduled task or loop, no one is watching — so an odd interpretation might repeat (in the scheduled task) or go unnoticed (in the loop) until it causes a bigger problem.

This is why vague instructions work well in a conversation but are dangerous in a routine: room for free interpretation needs to shrink when no one is checking in real time.

Missing oversight, error amplification, vague instruction vs. precise instruction.

Before letting any instruction run on its own, whether on a schedule or in a loop, ask Claude Code to run it once right away while you watch. Only after you see the correct result should you set it up to run unattended.

This simple step prevents the track’s most costly mistake: discovering that the instruction was poorly written only after it has already run on its own several times.

Test run, manual validation, before automating.

Even with the same instruction, the AI model behind Claude Code may occasionally phrase the answer slightly differently from one run to the next—not because it “changed its mind,” but because that’s the statistical nature of how the model generates text.

Knowing this helps you avoid two opposite mistakes: blindly trusting that it will always be identical, and giving up on automation because you think it’s all too random to trust.

Statistical variation in the model, probabilistic nature, acceptable level of variation.

Specific instructions (exact output format, numbered steps, examples of the expected result) reduce room for interpretation. Asking the agent to always follow a fixed response template—instead of "tell me what you think"—is a simple and effective safeguard.

These safeguards are the practical tools you have at your disposal to make a routine more reliable, even knowing that 100% determinism doesn’t exist.

Specific instruction, fixed format, example of the expected output.

Objective: manually validate an instruction before turning it into a scheduled task or a loop.
Paste into Claude Code before scheduling anything:
Antes de eu agendar isso, roda a instrução agora, uma vez, exatamente como ela vai rodar sozinha depois: <cole aqui a instrução que você quer automatizar>. Me mostra o resultado exato que você geraria.
How to verify: compare the result with what you expected. Schedule it only after running this test at least twice and seeing consistent results.

This manual testing checklist is the practical habit that underpins everything modules 6.2 and 6.3 taught about setting up scheduled tasks and loops.

Validation prompt, rerun the test, check for consistency before trusting it.

A notification is the alert a scheduled task or loop sends you when it finishes (or finds something relevant) — without it, a routine running on its own becomes a black box, and you don’t know whether it worked.

Every automation in this learning path is useful only if you know what it did. Notifications are the piece that completes this trust cycle.

Completion notification, visibility into the result, black box avoided.

Restrictive permission — new here? It's configuring Claude Code so it can only do a limited set of things — for example, only read files, never delete anything — especially when it will run without you supervising it in real time.

In a live conversation (Track 0.6), you see each action before it happens and can stop it immediately. In an automated routine, that safety net disappears — so permissions need to be tighter, not looser.

Permission scope, no real-time supervision, risk reduction.

Never give an automatic routine permission to delete files in bulk, change system settings, spend money (purchases, transfers), or publish anything on your behalf without your prior review.

This list exists because the cost of an unsupervised error is much higher than the cost of an error in a conversation — and a poorly configured routine can repeat the same error several times before anyone notices.

Irreversible actions, bulk deletion, publishing without review.

The most common ways to notify you: an automatic email, a message (in a chat app you already use), or, at a minimum, a log file that records each run so you can check it later, even without an active alert.

Having at least one channel configured, even the simplest one (the log file), is the minimum responsible step when you leave something running on its own.

Alert channel, log file as a minimal record, redundant alerts.

If a scheduled task or a loop does something unexpected, the first step is to pause or delete that routine immediately (in the desktop app, or by closing the loop session), then review the log to understand what happened before reconfiguring it.

Having this plan memorized—pause first, investigate later—keeps a small error from becoming a recurring one, since scheduled tasks keep running until you intervene.

Immediate pause, investigate via logs, reconfigure only after understanding.

Objective: ensure that if the routine fails for any reason, you’re notified — not just when it works.
Paste into Claude Code when configuring the task:
Toda vez que essa rotina rodar, escreva uma linha em <caminho do arquivo de log> dizendo se deu certo ou se deu erro, com data e hora. Se der erro, me avise por e-mail imediatamente com o motivo. Você só tem permissão de leitura nos arquivos, nunca de exclusão.
How to verify: deliberately trigger an error (point to a file that doesn't exist) and check whether the failure alert arrives.

This prompt combines both parts of the module — notifications and restrictive permissions — into a single request ready to use for any of your routines.

Copyable prompt, explicit permission in the text, intentional failure test.

This final module puts together a complete morning routine, step by step: something that summarizes what matters in your day (calendar, to-dos, a number you track) and delivers it ready for you, without you having to ask.

It's proof that the six previous modules—guiding question, scheduled task, loop, memory, determinism, permissions—come together in a practical result, not just isolated theory.

Capstone project, production routine, applying all the concepts in the learning path.

Applying module 6.1: a morning routine runs every day, without fail—so the answer is “every week” (every day, in this case), which points directly to a scheduled task, not a loop.

This step shows the guiding question being used for real, not just as a theoretical example — reinforcing why the loop (which expires after days) would be the wrong choice here.

Applying the guiding question, making a justified choice, scheduling the task as the right trigger.

Applying module 6.5: the routine’s instructions need to request a fixed output format (for example, always 3 topics: schedule, pending items, one specific number)—not “tell me how my day is going,” which leaves too much room for variation.

Seeing the instruction written with this level of formatting discipline is the most complete practical example of applied determinism in the entire learning path.

Instruction with a fixed format, less variation, and consistent results every day.

Applying module 6.6: the routine has read-only permission (it can never delete or change anything), and the result arrives through a fixed channel—email or message—along with a log entry you can check whenever you want.

Closing this piece ensures that the morning routine remains safe and visible, even when it runs every day without supervision.

Daily delivery channel, read-only permission, tracking log.

Before enabling the schedule for real, run the instruction manually at least twice, at different times, and check that the output format stayed the same both times.

This testing step is what separates a reliable morning routine from one that will startle you in the first week.

Repeat manual tests, verify consistency, activate only after validation.

After activating it, let the routine run on its own for seven days without touching it — but set a fixed time (for example, Sunday) to open the log and check that everything went as expected, adjusting the instruction if anything needs correcting.

This "activate, trust, review once a week" rhythm is the healthy approach to automation taught throughout the track — neither micromanaging nor forgetting it exists.

Trust with checkpoints, periodic reviews, and iterative adjustments after activation.