Two ways to make AI do something every morning

Every major assistant can now run on a timer. Ask ChatGPT to summarise your news at 7am, or Gemini to send a weekly digest, or Claude to compile a Monday report, and it will. This is genuinely useful and it is not the only option — and the difference between the two options is the most consequential choice you'll make about any recurring automation.

The reason it matters isn't philosophical. It's arithmetic. One of these routes has a cost per run and the other doesn't, and the gap between them is invisible at one run a day and decisive at a thousand.

The two routes

Route A: the assistant runs. The model wakes up on a schedule and does the work, fresh, every time. Setup is a sentence of English. The model is in the loop on every single run — which means every run costs something, and every run can produce a slightly different answer.

Route B: the assistant wrote it. You use the model once, in a conversation, to produce a script. Then something dumb and free — cron, a scheduled workflow — runs that script forever. The model is out of the loop. Runs are identical, instant and cost nothing.

Both are "using AI to automate a task". They are almost opposite engineering decisions.

Side by side

What Route A is genuinely better at

It would be wrong to treat the assistant route as merely the lazy option. It wins outright in several situations.

You don't code. This is the big one. Route B has a floor of technical ability that Route A simply doesn't. "Every weekday at 8, summarise anything new about my industry" is a complete specification in Route A and a project in Route B.

The task needs judgment every time. If the work genuinely is "read this and tell me what's interesting", a model has to be in the loop, because that's the job. No script does it.

The input keeps changing shape. A scraper breaks when a site redesigns. An assistant reading the page copes, because coping is what it does.

You're still working out what you want. Iterating in English for a fortnight is much faster than iterating in code. Use Route A to discover the requirement, then decide whether to harden it.

It's low volume. Once a day is 365 runs a year. The metered cost of that is trivial. Don't build infrastructure to save pennies.

What Route B is better at

Volume. This is where the two diverge violently. Checking 200 pages hourly is 1.7 million runs a year. As code it's free. Through an assistant it isn't remotely viable — and most platforms cap you at a handful of scheduled tasks anyway.

Exactness. "Has this number changed?" has a correct answer that != gives every time. A model will mostly agree with it. Mostly isn't a great property for something you stop checking.

Anything that must not drift. Same input, same output, this year and next. Assistants re-reason each run, and the model behind them gets updated without asking you.

Things you must be able to explain. When a bot does something surprising and money is involved, "I read the code" is a much better position than "the model decided that".

Ownership. A script runs on your machine, your CI, your Pi, indefinitely. A scheduled task lives inside someone's product, subject to their limits, their pricing and their roadmap.

The arithmetic that decides it

This is the part most comparisons skip, and it's the part that matters. A model call has a marginal cost. Deterministic code has none. So the two routes don't differ by a percentage — they diverge, and the divergence is proportional to how often the thing runs.

Take a rough per-run cost and multiply it out. A short classification through a small model is a fraction of a cent; a longer job through a bigger model is a few cents. Both are nothing on their own:

Illustrative per-run costs — yours depend on the model and how much text you send. The shape of the table is the point, not the exact figures.

Read the first row and the last row together. At once a day, the cost difference between the two routes is under four dollars a year and you should not spend a minute thinking about it. At real volume, the same decision is the difference between free and a salary.

And notice the column that doesn't change. Deterministic code costs the same at 1.7 million runs as at one, because the thinking happened once, when you wrote it. That is the entire economic case for building bots rather than renting reasoning.

The ceiling nobody mentions

There's a second constraint that bites before the money does. Scheduled assistant tasks are capped per account — a handful of active tasks on most tiers, ten or fifteen at the top. So the high-volume rows in that table aren't expensive on Route A, they're unavailable. You cannot buy your way to a thousand scheduled prompts; the product isn't shaped for it.

Which means the decision usually isn't "which is cheaper" but "which can do this at all".

The trap: the demo that never graduates

The failure mode worth naming is starting on Route A, finding it works, and letting it become load-bearing infrastructure by accident. Eighteen months later something important depends on a scheduled prompt that nobody has read, whose output nobody verifies, on an account tied to one person's login.

That's not an argument against starting on Route A. It's an argument for noticing when the thing has become important, and porting it.

The hybrid, which is usually the right answer

Framing these as a binary is a simplification. Most well-built automations are Route B with a small amount of Route A inside them — deterministic code doing the fetching, delivering and storing, with a single model call at the one point that needs judgment.

code   →  fetch the data        free, exact, fast
code   →  filter the obvious    free — throws away 99%
model  →  judge what's left     costs money, earns it
code   →  act, notify, store    free, exact, fast

That's not a compromise; it's the mature version. You pay for intelligence precisely where intelligence is required and nowhere else. The longer argument for this is worth reading if the split isn't obvious yet.

How to choose, in four questions

How often does it run? This is the first question, because it's the one that decides. Daily or less, the cost difference is pennies a year and Route A is fine. Hourly or more, the cost difference compounds and the task limits start to bind — Route B, and it isn't close.

Does the output need to be identical each time? If yes, Route B. Determinism isn't something you can prompt your way to.

Would you be annoyed if it silently stopped? If yes, you want something you control, can monitor and can debug. Route B.

Can you run a script? If not, Route A, and that's a perfectly good answer — you'll get most of the value with none of the setup. Revisit when it matters enough to learn.

The platform pages

Each route has its own article with the actual setup, the real limits and the specific traps:

ChatGPT scheduled tasks — how many you get per tier, event triggers, and what tasks can't reach.

Claude scheduled tasks — recurring work with connectors, and the local-folder caveat.

Gemini scheduled actions — ten slots, and an important detail about responses being prepared in advance.

The code route — GitHub Actions and cron, the free and permanent option, with the traps that catch everyone.