Tutorials / Backend integrations / Run a prompt on a schedule
📝 Written ● Intermediate Updated 2026-05-19

How do I run a LingCode prompt on a schedule?

TL;DR: /loop 5m /check-deploys runs a prompt every 5 minutes in your current session. /schedule creates a cron-style remote routine that runs on Anthropic's infrastructure when you're offline. Pick local /loop for polling, remote /schedule for background work.

LingCode ships two time-shifting tools that look similar and are not. /loop runs locally on an interval — "check the deploy every 5 minutes." /schedule runs as a remote routine on cron — "every morning at 8am, review the overnight PRs." Picking the wrong one means burning your local session context, or paying for cloud minutes you didn't need.

Two tools, two problems

0

"Run a prompt repeatedly" is two different needs disguised as one:

  • "While I'm working, keep doing this in the background." You're at your desk, LingCode should poll something every few minutes and tell you when it changes. The work has to share your session — same files, same git state, same chat history. This is /loop.
  • "While I'm asleep or on vacation, do this on my behalf." A task runs without you present, on a wall-clock schedule, possibly daily for months. It has to survive your laptop being closed. This is /schedule.

Confusing these is expensive in both directions. A scheduled task running on your laptop dies when the lid closes. A looped task running in the cloud bills you for compute while you're sitting there watching.

What /loop is

1

/loop runs a prompt or slash command on a recurring interval inside your current LingCode session. The session stays open; the work happens locally.

# Run /check-deploy every 5 minutes.
/loop 5m /check-deploy

# Run a freeform prompt every 30 seconds.
/loop 30s Check if the test suite is still green and ping me if not.

# Self-paced — LingCode decides when to re-run based on context.
/loop /watch-the-CI-and-summarize

What you get:

  • Same files, same git state. The loop runs in your project directory. If a file changed since the last iteration, the next iteration sees it.
  • Same chat history. Each iteration sees what the previous ones said. The loop can build on prior turns — "this is the third time the build failed for the same reason, alerting you."
  • Stops when you stop it. Close the tab, quit LingCode, or type "stop the loop" — it ends. No external cleanup required.
Omitting the interval is intentional. /loop /foo with no time argument lets LingCode self-pace — it re-runs when it judges there's reason to, not on a fixed clock. Good for "watch this thing until it's done" tasks where polling at a fixed rate would be wasteful.

What /schedule is

2

/schedule creates a remote routine that runs on a cron schedule. It executes on LingCode's servers, not your machine. Your laptop can be closed; the routine still fires.

# Run a routine every weekday at 8am.
/schedule create "Morning PR triage" "0 8 * * 1-5" \
  "Review every PR opened in the last 24h. Post a summary to
   #engineering in Slack with: count, blockers, anything that
   looks urgent."

# One-time scheduled run.
/schedule once "2026-05-25 09:00" \
  "Email me a summary of last week's customer support tickets."

# List, update, delete.
/schedule list
/schedule run <id>        # fire it now, manually
/schedule delete <id>

What you get:

  • Survives your laptop being off. Routines run in the cloud on their schedule, regardless of your local state.
  • Fresh context every run. Each fire is a clean slate — no chat history, no leftover local files. The routine has to be self-contained.
  • Bills cloud compute. Each run costs you. Cheap for daily routines; expensive if you confuse it with /loop and set it to fire every 30 seconds.
  • Persists across sessions. Routines exist as named entities. List them, edit them, delete them — they're not tied to a chat window.

The picker — which one for which job

3

Three questions decide:

  • Do I need to be present? If yes (or "doesn't matter"), /loop is fine. If no (must run while I'm offline), /schedule.
  • Does it need access to my local files or git state? If yes, /loop. If no (all data lives in APIs, Slack, email, the cloud), /schedule is cleaner.
  • How often? If > once per minute, /loop — paying for cloud cycles on sub-minute schedules is wasteful. If <= a few times per day, /schedule — running a local loop for 24 hours just to fire once is wasteful in the other direction.
The trap: "Every 5 minutes review my PRs" sounds like a cron job. But if you only care while you're at your desk, /loop 5m is right — closing the laptop stops it, and that's the desired behavior. /schedule would fire at 2am when you don't care.

Worked example — local polling with /loop

4

You're shipping a feature behind a feature flag, and you want LingCode to watch the rollout dashboard while you do something else:

/loop 2m Check the error rate on the dashboard.json file in
this repo (re-fetched by my polling script). If the 5xx rate
goes above 1%, immediately alert me with the failing endpoint.
Otherwise summarize the trend in one sentence.

This is the right tool because:

  • You're present — the loop running while you're in another tab is fine.
  • It reads a local file (dashboard.json in the repo) — needs filesystem access.
  • 2-minute cadence — too fast for cloud cron, perfect for a local loop.
  • Each iteration builds on the prior — "the rate has been climbing for three checks in a row" is information the loop accumulates.

Worked example — overnight routine with /schedule

5

You want a digest of every PR opened overnight, in Slack, before you sit down with coffee:

/schedule create "Morning PR digest" "0 8 * * 1-5" \
  "List all PRs opened in the org repo between 6pm yesterday and
   8am today. For each, summarize: title, author, files touched,
   reviewers requested, whether CI is green. Post the digest to
   #engineering. If any PR is from an external contributor, flag
   it at the top."

This is the right tool because:

  • You're not present — fires while you're asleep.
  • No local file access needed — pulls from GitHub API, posts to Slack API.
  • Weekday-morning cadence — once per day, exactly the cron sweet spot.
  • Each run is independent — no need to know what yesterday's digest said.
Routines need credentials to talk to APIs. Configure GitHub and Slack tokens in your LingCode account before creating the routine, or it'll fail silently on its first fire. Test the routine manually with /schedule run <id> before trusting the schedule.

Mixing them — local watch that escalates to a scheduled report

6

The two tools compose. A pattern that works for production monitoring:

  • /loop 1m while shipping — local, fast, watches the deploy and tells you instantly when something breaks. Stops the moment you close the laptop.
  • /schedule daily at 6pm — remote, generates a "today's deploys" report into your team channel. Runs whether or not you were watching during the day.

The loop catches problems in real time; the schedule produces the artifact you'll read tomorrow. Different windows of attention.

Stopping things

7

Cleanup is where confused configs become billing surprises:

  • Stop a loop: type "stop the loop" in chat, or close the tab. Loops are session-local; quitting LingCode kills them.
  • Stop a routine: /schedule list to see your routines, then /schedule delete <id>. They keep firing until you delete them. A forgotten routine firing every 5 minutes for a month is a real bill.
Audit your routines monthly. Run /schedule list and delete anything you don't recognize or no longer want. Scheduled compute is the easiest cost to leak.

Use this in LingCode

8

Package the picker as a skill so LingCode reaches for the right tool the first time:

---
name: schedule-or-loop
description: Run a prompt or slash command on a recurring schedule. Two distinct tools: /loop runs locally on an interval, session-bound, fast cadence ('check the deploy every 5 minutes'). /schedule runs as a remote cron-style routine, persistent, survives laptop close ('every morning at 8am, review overnight PRs'). Triggers: 'recurring task', 'check every N minutes', 'cron job for Claude Code', 'run on a schedule', 'daily routine', 'while I'm asleep', 'set up reminder'. Actions: /loop for in-session polling, /schedule for cloud-cron tasks, list/run/delete routines. Pick by: session-bound vs survives-laptop-closed, fast-iteration vs persistent-recurring.
---

When the user asks to run a prompt repeatedly, decide between
/loop and /schedule with three questions:

1. Does the task need to keep running while the user is offline /
   laptop closed? If yes → /schedule. If no → /loop is fine.

2. Does the task need local files or git state? If yes → /loop.
   If no (data lives in APIs, Slack, email) → /schedule is
   cleaner.

3. How often? Sub-minute or every few minutes → /loop. Once a day
   or less → /schedule. Anything in between, pick by question 1.

/loop usage:
- /loop <interval> <prompt-or-slash-command>
- /loop <prompt>  (no interval = self-paced)
- Shares session: same files, same chat history.
- Stops on session close or "stop the loop".

/schedule usage:
- /schedule create "<name>" "<cron>" "<prompt>"
- /schedule once "<datetime>" "<prompt>"
- /schedule list / run <id> / delete <id>
- Each run is a fresh context. No file access, no session
  history. Self-contained prompts only.
- Test with /schedule run <id> before trusting the schedule.

Audit routines periodically with /schedule list. Forgotten
routines are the easiest cloud cost to leak.

Save as ~/.lingcode/skills/schedule-or-loop/SKILL.md — see Install a skill for the exact location and how skills get discovered.

Get LingCode →

What's next