The limits, in full
Everything that will annoy you, in one place, before you buy rather than after.
This page exists so that nothing on this site has to be discovered. If any of these is a dealbreaker, it is much cheaper to find out here.
A sleeping Mac fires nothing
The scheduler runs inside the app, on your machine. There is no daemon or wake-from-sleep. AgentCron can prevent idle sleep during a window you configure while the lid stays open, but there is no catch-up for a run that was missed while the machine slept.
Consequences worth stating separately:
- A 3am agent works if your Mac does not sleep at 3am, and quietly does nothing if it does.
- Nothing here is suitable for work that has to happen at a specific minute, whether or not you are there. Not uptime checks, not anything paging anybody, not a brief that must exist by 07:30.
- Closing the window is safe — it hides to the menu bar and the scheduler keeps running. Quitting from the menu bar genuinely quits, and then nothing is scheduled.
This is the single most important limitation on this site.
Default review policy and external-tool risk
By design, and it is the position rather than a gap.
- AgentCron's mail sender goes through its approval path; it is not published as a direct agent verb.
- Review-gate jobs normally get a macOS boundary protecting repository history, common remote credential stores and AgentCron control data. An explicit per-agent commit-and-PR policy changes the repository boundary.
- The approval command fails closed on denial, expiry and app disconnect—but only when a workflow calls it.
- The launched CLI keeps its own network tools and project-local credentials. AgentCron is not a universal interceptor, so an outside web tool or script may still send or publish under its own rules.
The consequence for non-code work is a real one: a drafted reply or a summary lands as a markdown item you copy out by hand. For two or three a morning that is a fair trade. For twenty it is a chore.
macOS on Apple Silicon only
There is no Intel build. Windows would not compile — the channel between agents and the app is a Unix socket, and there are only a handful of platform-conditional sites in the entire Rust codebase. Linux is untested and full of macOS-shaped assumptions.
No port is planned. Saying coming soon here would be a lie about the architecture.
One machine, one person
One local data directory, no server, no sync, no shared queue, no seats. Two people on two Macs share nothing and cannot see each other's agents.
There is no architecture here that quietly becomes shared later. If what you need is a group view of what everyone's agents did, this is not it.
You bring the agent CLI, and Node
AgentCron can detect an agent CLI but cannot install one or sign you in. The control tool agents talk back through is a script that needs Node on your PATH; without it agents run but cannot report progress, ask questions or request approval.
Both of these are fine for a developer and are a genuine wall for anybody else.
Scheduling is thinner than cron
One six-field cron expression per agent, in machine-local time. No retries, no backoff, no jitter, no per-job timeout, no maximum concurrency. The only failure policy in the product is that three consecutive failures disable the agent.
Chaining is real and good — a finished run can fire the next, with a cycle guard. But if your problem is scheduling, cron is better at it than this is.
Command capture is not uniform
Automatic and complete for Claude Code, through the CLI's own hook API. For GitHub Copilot CLI, agy and plain shell jobs, only what the agent routes through the wrapper command — none of those exposes a hook API for us to use.
An empty log therefore means we could not see it, not nothing ran. Coverage is measured per CLI and shown, so this is visible rather than silent — but it is a real asymmetry.
Integrations: almost nothing is bundled
| Works | Does not exist |
|---|---|
| git and worktrees | Any git host other than GitHub — there is no adapter |
GitHub, through the gh CLI, authenticated per project | Browser automation or any test harness — the repo brings its own |
| Reading mail over IMAP, and mail-triggered runs | Sending mail from an agent |
| Screenshots and recordings, browsable in the app | Financial, applicant-tracking, CRM, helpdesk, warehouse or BI integrations |
| MCP servers you run, in both directions — scoped per project, with a per-tool allowlist for agents | Any bundled or endorsed MCP server |
| A cost view per agent per day, with a coverage line | Reliable pricing of every run, or per-client billing rollups |
Nothing in the right-hand column is a roadmap promise. Each one is a thing that does not exist today, and several of them are things that would need a design decision before they could.
Two things you will hit in the first month
Disk. Worktrees, screenshots, command output and run history. The machine this was built on carries over a hundred worktrees. There is a storage view and a preview-first cleanup; set the retention in week one.
Tokens. The block of instructions appended to every prompt is roughly a couple of thousand tokens per run, billed to your own subscription. Two of the blocks are conditional so they are not always paid, but a nightly agent across four projects is a real line on your usage.
Cost tracking is thinner than it looks, and it is uneven by CLI. Claude Code reports an exact dollar figure from the CLI itself. agy reports exact token counts, which price only for the Claude models it can serve. GitHub Copilot CLI's runs are recorded but unpriced — its CLI reports measured output tokens, the model, its session id and its own credits meter, and the app keeps all of it on the run, but there is no dollar figure and no published rate to price its models with, so those runs count as unpriced in the cost view. That view therefore prints how many of your runs it could actually price, and on the machine this was built on that coverage has been low. Treat your CLI's own usage dashboard as the number to trust.
Distribution and updates
The Mac build has not been through Apple's checks, so downloading it today would produce a Gatekeeper warning rather than an app. Getting past that is described on the download page, including which of the two routes actually works for a build in this state.
The in-app update mechanism is written but not yet usable. It is not signed with a real key and there is no public release for it to fetch, so it refuses to run rather than failing at you — treat it as absent until the changelog says otherwise. When it does become usable it stays off unless you turn it on: the automatic check is opt-in, in Settings → Updates, and the app asks once rather than deciding for you.
So today a new version means downloading it again, and the app makes no network call on your behalf — not because nothing is there to make one, but because the one thing that would is switched off and inert. That is a setting and a missing key, not an architectural guarantee, and it is worth knowing which of the two you are relying on.