Practical questions
The things people ask that are not arguments — CLIs, cost, sleep, stopping a run, non-code work, and what happens when a CLI changes.
The five arguments people have with the idea itself are answered on the front page. These are the practical ones.
Getting it running
Which agent CLIs work? Three, plus plain shell:
| CLI | Command capture | Cost figure | Resume a conversation |
|---|---|---|---|
Claude Code (claude) | Automatic, through the CLI's own hook API | Exact, reported by the CLI itself | Yes |
GitHub Copilot CLI (copilot) | Only what the agent routes through the wrapper | Recorded but unpriced — output tokens, the model and the CLI's own credits meter are kept on the run; no dollar figure | No |
| agy (Antigravity) | Only what the agent routes through the wrapper | Exact token counts; priced only for the Claude models it serves | Yes |
A plain shell job (shell) | Only what the agent routes through the wrapper | n/a | n/a |
The choice is per agent, not per install, so two projects on two different CLIs run under one schedule, one command log, one queue and one review screen. Each is launched with the flags that CLI actually needs for an unattended run — they differ more than you would expect, and absorbing that difference is a large part of what this app is.
Gemini support was written before that CLI was discontinued upstream and is retired: a job you already saved as gemini still launches gemini, but nothing puts a new agent on it, because silently running something else in its place would be worse than a run that fails honestly.
Do I need an API key? Does it use my subscription? Your subscription. AgentCron launches your CLI as a subprocess exactly as you would from a terminal, so it authenticates however it already authenticates. The app never sees your key and never proxies your traffic.
What does it cost me in tokens? More than running the same prompt by hand. The instructions appended to every prompt are roughly a couple of thousand tokens a run, billed to you. Two of the blocks are conditional, so a run in a folder without a git repo does not pay for the diff-explanation rules.
There is a cost view per agent per day, and it prints how many of your runs it could actually price — a run whose CLI reported no usage back cannot be priced. On the machine this was built on that coverage has been low, so treat your CLI's own usage dashboard as the reliable number for now.
Why does it need Node? The tool agents use to report progress, ask questions and request approval is currently a script rather than a compiled binary. Replacing it with a native binary would remove this requirement and is the obvious thing to do; it has not been done yet.
How runs behave
Does it run while my Mac is asleep? No, and there is no catch-up. See the limits — this is the one that matters most.
Does the app have to be open? Running, but not visible. Closing the window hides it to the menu bar and the scheduler keeps going; there is an option to start at login. Quitting from the menu bar genuinely quits.
Can I stop an agent mid-run? Yes. Every run is a live terminal session you can watch, type into, pause, resume or kill. Clicking a running agent puts you in its session — the terminal is not hidden behind a debug menu.
What if an agent asks me something and I am asleep? It waits. Its process is blocked on the question, so nothing proceeds on a guess. Answer in the app in the morning or from your phone. Approval requests do expire, and an expired request counts as no.
Can two agents work on the same repo at once? Yes — separate worktrees, and separate ports and databases where your project defines a setup script. See isolation.
Do I have to understand git worktrees? To use it, no. To clean them up, a little: they accumulate and they take disk.
What if an agent keeps failing? Three consecutive failures and it disables itself and tells you, rather than burning tokens nightly on the same broken thing. An agent that gave up looks different from one you switched off.
Control
Can it commit or push? Review-gate jobs are instructed not to and normally run inside a targeted macOS owner boundary that denies repository-history and common remote-credential paths. The run says whether that boundary was enforced. You can lift it for one agent with the separate commit-and-PR policy; that setting is owner-only. A workflow can also request a blocking approval before a consequential action. Read the gates page for the exact boundary and its caveats.
Can an agent send email, post a comment, or publish something? No, and not as an oversight — there is no such verb available to agents at all. An agent drafts; you send.
What can an agent actually reach? Treat it as a real process with your local and network access. The default owner boundary protects named repository, credential and AgentCron control paths; it is not a general-purpose sandbox, and project-local credentials remain in scope. Configured MCP servers and the CLI's own web tools can add further reach.
Fit
Can I use it for work that is not code? Yes, and half the roles on the front page are exactly that. A schedule, a gate, a log and a queue are not code concepts, and a run in a folder with no repo skips the git-specific instructions entirely rather than being told not to commit to a repository it does not have.
The shape is the same as it is for code. A code agent produces a diff and leaves it uncommitted for you to read and commit; a mail or content agent produces a draft and leaves it in the queue for you to read and send. Same gate, same reason, different artefact — and the second one is the stronger of the two, because the code rule is an instruction in a prompt while *there is no send verb available to an agent at all*.
Does it work with a git host other than GitHub? No. GitHub only, through the gh CLI,
authenticated per project. There is no adapter for any other host.
Does it integrate with my helpdesk, CRM, warehouse or broker? Nothing of that kind is bundled and nothing is endorsed. AgentCron is an MCP client, so anything you can reach over a server you run becomes reachable — but you find it, host it and pay for it, and it has not been tested here.
Can several of us use it? Each on your own Mac, sharing nothing. See the limits.
How is this different from CI? CI reacts to a commit and runs a fixed script in a clean container. This starts on a schedule, runs an agent that decides what to do, works against your real local stack, and hands you something uncommitted. They are complementary — one useful agent watches CI and turns a red build into a reproduction and a candidate fix.
I only run one agent at a time. Should I get this? Probably not. Everything here exists because supervising several by watching does not work. If your bottleneck is the quality of one agent rather than how many you can keep track of, a better prompt will help more than this will.
The project
Does it phone home? No. No analytics, no crash reporter, no account. The user interface makes zero network calls of any kind. The one thing in the app that could ever reach a server on its own is the update check, and it is opt-in and switched off by default — see "How do updates work?" below. The privacy page lists every destination and the exact commands to verify it.
What happens when an agent CLI changes and breaks something? It happens, and the thing most likely to break quietly is command capture, because it depends on private hook contracts and flag shapes. Capture coverage is measured per CLI and shown, so a degradation is visible rather than silent. Keeping up with that is roughly a week a quarter, forever, and it is the real ongoing cost of this project.
How do updates work? Today, by downloading the new version. The update mechanism inside the app is written but not 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 checking anything. That is why the app makes no network call on your behalf today.
When it becomes usable it does not switch itself on. The automatic check is opt-in — the app asks once, the default is off, and the toggle lives in Settings → Updates. Checking manually is always a button you press. This answer changes on the day the first signed release ships, and the changelog is where it changes.
What is coming next? Sharper agents for the roles that people actually turn up as. Every role on the front page has three traceable starting prompts today; three packs are bundled and the other roles assemble their starting set from included picker templates. Which of those get improved first is decided by who is using them, and with no analytics in this product the only way to know is if you say so.
Some jobs are not on that list at all rather than being listed as pending — anything needing a data source or a publish path that does not exist here. There is no roadmap page for those, because a list of dated promises is a worse way to be honest than simply not claiming the job.