Loops
Work that happens on a schedule, not on a trigger.
A prompt, a repository, an agent, and a time. Sweep yesterday's failing checks every weekday morning. Keep dependencies current every Monday. Draft the release notes every Friday at five. It opens a pull request when the work warrants one.
- Say when in plain terms — hourly, daily, weekdays, weekly — or a cron expression if you want one
- Runs in your timezone, so 09:00 stays 09:00 when the clocks change
- Every run is logged, including the ones skipped because the last was still going
- Start one by hand any time, without waiting for its next turn
Free plan: three loops. The cap counts schedules, not runs — each firing is an ordinary task and counts against the task limit.
Loops
Runs a prompt on a schedule, whether or not the app is open
Morning CI triage
Weekdays at 09:00 (Europe/London) · sundial/api
Keep dependencies current
Every Monday at 08:00 (Europe/London) · sundial/web
Draft the release notes
Every Friday at 17:00 (Europe/London) · sundial/api
Sweep stale branchesOff
Every day at 02:00 (Europe/London) · sundial/infra
Not everything is a reaction
A workflow fires because something happened. A loop fires because it is Monday. That sounds like a small distinction and it is the whole difference between automation that keeps up with you and automation that does the work nobody ever gets to.
The dependency bump nobody schedules. The flaky test sweep everyone agrees is worth doing. The release notes somebody writes on a Friday afternoon from the commit log. Each one is a prompt you could write in a minute and will not run consistently for a year.
Loops
Runs a prompt on a schedule, whether or not the app is open
Morning CI triage
Weekdays at 09:00 (Europe/London) · sundial/api
Keep dependencies current
Every Monday at 08:00 (Europe/London) · sundial/web
Draft the release notes
Every Friday at 17:00 (Europe/London) · sundial/api
Sweep stale branchesOff
Every day at 02:00 (Europe/London) · sundial/infra
A loop is four choices
The repository, the prompt, the agent and model, and the schedule. That is the whole editor. When it fires, it creates an ordinary cloud task — the same kind the fix button creates — so the transcript, the pull request link and the plan limits all work exactly as they do everywhere else. What loops add is the clock.
- Hourly, daily, weekdays, weekly — or a raw cron expression
- Your timezone, correctly, including across daylight saving
- Pick the agent per loop: Claude, Codex, or PostHog Code
- Choose what happens if the last run is still going — skip is the default
Missed occurrences fire once, not six times
If Talyn is down or deploying when a loop is due, it catches up — once — and then carries on from now. It does not replay every occurrence it missed, because six near-identical tasks at once is not what anybody wanted, and on a free plan it would be one run and five refusals.
Re-enabling a loop you switched off is a resume, not a backfill. It starts from the next occurrence.
The internet switch, off by default
A loop's sandbox normally reaches its repository and its agent's API and nothing else. That is not a limitation we ran into; it is deliberate. A prompt that has just read untrusted pull request text should not have a route out to post it somewhere.
Some jobs genuinely need the web — checking an upstream changelog, reading an advisory. So internet access is a per-loop switch, off unless you turn it on, and the posture travels with the task rather than the loop, so a run that is retried later gets the setting it was created with. The choice is offered as 'Repository only' or 'Allow the internet'; you never have to think about routing tables. It is available on Talyn Fleet only.
When the subscription runs out
A scheduled run that fires at 3am and hits an exhausted monthly quota should not just fail. If your Claude subscription is spent, Talyn moves that run to your Codex subscription if you have one, and then to PostHog Code. The exhaustion is remembered, so the next loop does not boot a machine to learn the same thing, and it is cleared by proof — a successful run, a fresh sign-in, or the vendor's own stated reset time.
A rate limit is treated differently and deliberately: that clears by waiting, and moving off it would spend money to avoid a short pause.
Questions, answered.
Prompts that run on a schedule instead of waiting for something to happen. Pick a repository, write what you want done, and say when — hourly, daily, weekdays, weekly, or a cron expression — and an agent runs it on its own, opening a pull request when the work warrants one.
Yes. Schedules run in your own timezone, so 09:00 daily stays 09:00 to you across daylight saving. That is the one part of scheduling nobody hand-rolls correctly, so Talyn does not.
That is a per-loop setting, and skipping is the default — the skipped occurrence is recorded in the history rather than silently dropped. It is also what makes a tight schedule self-limiting, which is why there is no minimum interval.
No, it counts schedules. Each firing creates an ordinary cloud task, which is bounded by the three-active-tasks cap instead. The two caps compose rather than overlap.
Talyn does this for you.
Mission control for your GitHub pull requests, running on the Claude or ChatGPT subscription you already pay for. Free for three tasks at a time.