[hirako2000]

Oh my, did Anthropic invent Cron jobs as a service?

It's a game changer.

Edit: my mistake. It's inferior to a Cron job. If my repos happen to be self hosted with Forgejo or codeberg, then it won't even work. If I concede to use GitHub though I don't have to set up any env variables. Schedules lock-in, all over the web.

[TeMPOraL]

You jest, but for some reason the industry stubbornly refuses to solve the "cron job as a service" problem for end-users, whether on the web or in the OS.

I feel this is rooted in problems that extend beyond computing. Regular people are not allowed to automate things in their life. Consider that for most people, the only devices designed to allow unattended execution off a timer are a washing machine, some ovens and dishwashers, and an alarm clock (also VCRs in the previous era). Anything else requires manual actuation and staying in a synchronous loop.

[hirako2000]

There is nothing to solve. It's already there, a VPS, a container platform, just push your script and schedule it.

Of course a provider can offer convenient shortcuts, but at the cost of getting tied into their ecosystem.

Anthropic is clearly battling an existential threat: what happens when our paying users figure out they can get a better and cheaper model elsewhere.

[TeMPOraL]

> what happens when our paying users figure out they can get a better and cheaper model elsewhere.

They solved that with subscriptions. For end-users (and developers using AI for coding), it makes no sense to go for pay-as-you-go API use, as anything interesting will burn more than the monthly subscription worth of $$$ in API costs in few hours to days.

[hirako2000]

Yes but that's anthropic API pricing, some of the highest per token.

Sure subscription is a sort of tie in, but only if users are fooled into investing in workflows bound to anthropic. That's what the company is hooking them to do with this scheduler, banning open agentic framework and the rest.

The moat, if any, will be the tooling. Token is becoming a commodity, they know it.

[talkin]

> for some reason the industry stubbornly refuses to solve the "cron job as a service" problem for end-users, whether on the web or in the OS.

Such a service will always be destroyed by the bell-ends who want to run spam or worse activities.

[TeMPOraL]

That doesn't explain lack of such functionality at the OS/platform level. It technically exists on Linux and Windows, but is heavily optimized towards sysadmin use, and essentially hidden from regular users on the "normie UI surface". Most people don't even realize their computers could do things on a timer.

(And on Android, AFAIK there's exactly nothing at all. There's not even common support for any kind of basic automation; only recent exception is Samsung. From third-party apps, there's always been Tasker - very powerful, but the UX almost makes you want to learn to write Android apps instead.)

[WJW]

What is wrong with things like the Zapier scheduler? (ie https://zapier.com/apps/schedule/integrations) For running locally, there's also a plethora of cronlikes for every OS under the sun.

I think the core problem is not so much that it is not "allowed", but that even the most basic types of automation involves programming. I mean "programming" here in the abstract sense of "methodically breaking up a problem into smaller steps and control flows". Many people are not interested in learning to automate things, or are only interested until they learn that it will involve having to learn new things.

There is no secret conspiracy stopping people from learning to automate things, rather I think it's quite the opposite: many forces in society are trying to push people to automate more and more, but most are simply not interested in learning to do so. See for example the bazillion different "learn to code" programs.

[TeMPOraL]

It's not default. People don't need courses for this, they need availability and nudges. None of the platforms people use expose such features to users, much less encourage them to try. On the contrary, they hide or remove it from base UI layer entirely, and the UI choices made clearly suggest platform vendors don't even consider the possibility of regular people being interested.

Computing isn't, and has never been, demand-driven. It's all supply-driven. People choose from what's made available by vendors, and nobody bothers listening to user feedback.

[alasano]

I built this last year because I thought it was overdue back then already.

https://imgur.com/a/apero-TWHSKmJ

Cron triggers (or specific triggers per connector like new email in Gmail, new linear issue, etc for built in connectors).

Then you can just ask in natural language when (whatever trigger+condition) happens do x,y and z with any configuration of connectors.

It creates an agentic chain to handle the events. Parent orchestrator with limited tools invoking workers who had access to only their specific MCP servers.

Official connectors are just custom MCP servers and you could add your own MCP servers.

I definitely had the most advanced MCP client on the planet at that point, supporting every single feature of the protocol.

I think that's why I wasn't blown away by OpenClaw, I had been doing my own form of it for a while.

I need to release more stuff for people to play around with.

My friends had use cases like "I get too many emails from my kids school I can't stay on top of everything".

So the automation was just asking "when I get an email from my kids school, let me know if there's anything actionable for me in it"