Smart Alarms

Hand a future action to Cola in one sentence — it remembers, fires on time, does the work, and delivers the result where you asked.

Create your first alarm

There is no configuration form. Just say it in the conversation:

There is an all-hands tomorrow (add the meeting time here); remind me one hour before to sort out the agenda

Cola works out the timing, the frequency, what to do, and where the result should go. When it succeeds you get a card in the conversation showing the title and the schedule; Open takes you to the details.

If you don't know where to start, click the alarm icon in the app bar to open the Smart Alarms page and switch to the Examples tab. It has curated real-world cases grouped by reminders, insights, and follow-ups — open one for details, then click Start and it takes you back to the conversation with a ready-to-send phrasing.

What Cola does when an alarm fires

What it reads (context). An alarm reads only what it genuinely needs, from three possible sources:

A summary of the conversation at creation time — what you had already discussed is summarized into the task at the moment of creation. Later conversation doesn't leak in. This is what "remind me tomorrow morning to confirm the quote we just discussed" uses.
Continuing the current discussion — used when the task instructions say to continue from a discussion; each run picks up what's new.
No conversation at all — for self-contained instructions like "digest the morning finance briefing every day at 9".

Your memory is readable by default, with no separate switch: writing, judgment, and communication tasks naturally draw on your preferences and history; reminders and status checks don't need it and won't read it. A task can also read its own previous output and continue from there — like the weekly mood check-in gathering the month's entries into a trend summary.

Where the result goes. Cola first decides whether anything needs to be sent. When it does, short results are appended to the conversation in Cola's own voice, or sent to an external channel if that's what you asked for. File deliverables are saved to Cola's output directory under a plainly named folder, openable from the delivery panel and from the run history. When nothing needs to be sent, only a run record is written.

Permission boundaries. Alarms don't get local write access by default. Tasks that produce files write to Cola's output directory without extra confirmation; if you need output written into a project directory or somewhere else, say so when you create the alarm. High-risk actions — deleting files, publishing or deploying, reading credentials — put a red high-risk marker and a one-line risk note on the creation card and result card, right in the conversation, so you don't have to open the alarms page to notice. But Cola will not ask for confirmation again when the alarm fires: you already stated the intent, so it doesn't interrupt you twice. Money-moving actions such as placing orders or making payments are refused outright.

When it can't. A missing working directory, a missing dependency or credential, an unreachable network — these are treated as failures. Cola records and notifies; it does not quietly substitute a different target or a different action to get something done.

Managing alarms

Click the alarm icon in the app bar to open the Smart Alarms page:

The list is grouped by state — enabled, paused, and ended — with each row showing the title and a schedule summary (for example "In progress · Daily 09:00"). The row menu has pause, resume, and delete.
The detail view slides in from the right and is itself editable — there's no separate "Edit" button. Title, instructions, enabled state, catch-up rule, and model can be changed directly, with the run history pinned at the top.
Schedule editing offers six direct controls: one-shot, interval (in minutes), daily, weekdays, weekly, monthly. Anything outside those six — "the last working day of each month", say — shows as Custom with the schedule description captured at creation; to change it, just say so in the conversation.
End time is also changed in one sentence: "make it stop at the end of the month", "remove the deadline". An alarm past its end time moves to Ended — a clean finish, not a failure. One-shot alarms end after their single run.
Model is always pinned to a tier. Cola picks it by task difficulty at creation, and it does not follow your default model. When your plan does not cover the chosen tier, the task is pinned to the baseline tier instead, with an explanation. You can change the tier in the details, but not switch it to "follow default".

You can also just say "pause the morning briefing task" or "make that check run every 30 minutes". Pausing, resuming, deleting, and editing from the page aren't rendered as chat messages, but Cola knows about them on the next turn — it won't insist a task is still running when you already stopped it.

When an alarm didn't do what you expected

The key fact first: smart alarms depend on Cola running. They are not a system-level background service.

Situation	What happens
App closed, machine off or asleep	That run does not happen
After the app comes back	The alarm's catch-up rule decides: `skip` leaves only a "skipped by catch-up rule" record; `run the most recent one` replays only the last missed run — never a backlog
Previous run still going when the next is due	This one is skipped with a record; a single alarm never runs concurrently with itself
The run failed	Recorded, and you're notified according to the alarm's delivery rule. No automatic retry
App closed mid-run	The run is marked interrupted. Results already delivered are left alone; output produced but not delivered is re-delivered without re-running; external or high-risk tasks get a "run was interrupted, not automatically retried" notice
Machine sleep cuts off a run mid-flight	The run is marked interrupted and automatically retried once after wake (still counted against the original scheduled slot); external or high-risk tasks are excluded — they only notify you. A retry cut off again is not re-queued; manual retry remains available

Reminder-type alarms default to "run the most recent one" (a missed reminder shouldn't vanish silently); polling and check-type alarms default to "skip" (after recovery, only the next occurrence counts). You can change this in the details.

After a failure:

The failed run leaves a card in the conversation with the task name and a plain-language reason, plus a Retry button that re-runs it immediately.
You can also retry a failed or interrupted run from the run history in the alarm details.
If an attempt for the same scheduled slot is already in flight, the retry is refused with "a run is already in progress, try again shortly" — and that refusal does not create a run record.

The run history is the source of truth: time, status, a one-line result summary, and the entrance to any deliverables. It is never deleted, not even when the alarm itself is deleted.

Limits and boundaries

These are product decisions, not missing work:

No system-level background daemon. Execution isn't guaranteed while the app isn't running.
Tasks run on your machine's local time; there is no time zone concept.
Second-level precision isn't promised — firing is checked on a short polling interval.
No exactly-once guarantee, but every run, miss, skip, failure, cancellation, and interruption leaves a traceable record.
No backlog replay. "Run the most recent one" replays exactly one.
No automatic retry. Failed runs are retried only by you. The one exception: a run cut off by machine sleep is automatically retried once after wake (external and high-risk tasks excluded); a retry interrupted again is not retried further.
Delete means delete. No trash bin, no "deleted tasks" view — but run history and already-delivered files are not removed with it.
Commands, scripts, and raw logs are never surfaced in the UI or pushed back into the conversation.
Not a calendar system, not a replacement for your OS reminders app, and no visual workflow builder.
Money-moving actions (orders, payments) are refused.

For tasks that shouldn't be automated at all, Cola will suggest a smaller version:

What you asked for	Why it doesn't fit	Downgrade to
Find the right people and email them daily	Recipients and content aren't fixed	Draft it / remind you to confirm
Delete important files whenever you see them	"Important" isn't machine-verifiable and deletion is irreversible	A pre-check report
Place an order whenever there's an opportunity	Money-moving action	Refused / turned into a reminder
Fix and commit code whenever there's a problem	Scope and commit conditions aren't fixed	A draft patch / a pre-check

FAQ

How specific do I need to be? "What to do, when, and whether to tell you" is enough. Cola only asks back for three kinds of high-risk missing detail: who to email, which directory to clean up, where to write files.

My laptop was asleep — will it catch up? See the catch-up table above; it depends on whether that alarm is set to skip or replay the most recent run. Don't assume every missed run is replayed.

Where do results end up? Short results appear in the conversation; file deliverables live in Cola's output directory, reachable from the delivery panel or the "open deliverable" entry in the run history.

I paused a task from the page — does Cola know? Yes. Pause, resume, delete, and edit from the page all reach Cola on the next turn; they just aren't rendered as chat bubbles.

Can I schedule something like "the last working day of the month"? Yes — create it in natural language. It shows as Custom in the schedule control, and you change it by saying so.

Cola Skill — scheduled tasks can use installed skills
Tasks and permissions — what Cola may access while executing
Files, attachments, and outputs — where deliverables are stored
Troubleshooting — what to include when reporting a problem

Platforms: macOS and Windows desktop. Status: stable.