AgentCron

Your local agent workspace.

Less juggling. More building.

Schedule your agents. Review their work. Keep the decisions yours.

See release status See the use cases Not on sale yet

Free for one project. Pro is $89, once — no subscription and no server to fund.

The AgentCron window: a schedule of five agents — two finished, one waiting on you — a review panel holding an uncommitted diff with its explanation card, pills for the three CLIs with a cost line under them, and a live terminal session along the bottom.
Illustration Your morning control room: scheduled runs, an uncommitted diff, and a question waiting for your decision.
  • You bring the CLIUse the agent subscription you already have. No AgentCron API key, account or token meter.
  • Human review is the destinationRuns return work and records for you to inspect. Where a workflow uses AgentCron's approval command, denial, timeout or an unreachable app all fail closed.
  • Runs locally, leaves receiptsYour schedules and app records stay on your Mac. Connected CLIs and services keep their own network and data policies.

Drives the agent CLIs you already pay for

  • Codex CLIcodex
  • Claude Codeclaude
  • GitHub Copilot CLIcopilot
  • Antigravityagy
  • Plain shellshell

You bring the CLI and its subscription. AgentCron schedules the run, keeps its output, and shows the command evidence that integration can capture.

What kind of work keeps returning?

Choose the closest role. Three audience packs are bundled; the other seven starting sets are assembled from the included picker templates. Every page says which is which.

Tech lead / senior IC

Every change arrives with its own explanation. You review the reasoning, not the diff.

You are the one who reads everything, and the volume of agent-written code has made that unsurvivable. This makes a change explain itself before it reaches you — and it does that on your machine, for your own review load.

See release status See pricing

Not released yet. It will need macOS 12.0 or later on Apple Silicon — and the download page says exactly what is still missing.

The review screen with an explanation card beside a hunk: what changed, why, what it means in plain English, and the one thing that would break.
Illustration One hunk, four sentences: the mechanism, the alternative it rejected, the idea underneath, and what to check. A hunk with no card shows as a gap.

The caveat, up front. Your own review load, on your own machine. Single-user by construction: no seats to buy, no team admin, and nothing of yours on anyone else's computer.

Day one: three agents, already written

  • Overnight backlog

    Every night at 2am

    By morning there is a finished, uncommitted diff in a worktree with an explanation beside every hunk — the reasoning arrives with the change, not after it.

  • CI red triage

    Every 2 hours

    A red build on the default branch becomes a queue item naming the failing test, the exact command to reproduce it locally, and — when it is small — the fix itself, uncommitted.

  • Digest

    Every evening at 6.30

    One end-of-day rollup of what your own agents did, what is waiting on you, and what stalled.

Two come from the developer pack; the third is a ready-made prompt in the agent picker. Every agent arrives switched off, with a “Run once” button — nothing fires on its own.

What has to be true first

  • You are willing to run agents on your own machine, not the team’s

And the limits, in the same breath

  • macOS only. You bring, install and authenticate one of the supported agent CLIs shown above.
  • Schedules fire while your Mac is awake — AgentCron can hold it awake through a window you set (lid open) — and there is no daemon, no wake-from-sleep and no catch-up for a run that was missed.
  • AgentCron grants none of its own commit, push, send or pay paths by default. The launched CLI remains a real networked process, so separately configured CLI tools and project credentials keep their own risk.

Plausible is the problem, not wrong

Wrong code is easy. It fails a test, or it reads badly, or something obvious is missing. Agent-written code is rarely wrong in that way — it is plausible. It compiles, it passes, it uses the right idioms, and the only way to know whether it is right is to reconstruct the reasoning that produced it. That reconstruction is the expensive part, and it is the part that does not scale.

So the requirement here is not better code. It is that the reasoning arrives with the code, written at the moment the decision was made, by the thing that made it.

Each changed hunk carries four sentences: what — the mechanism that changed, not a restatement of the diff; why — the alternative it rejected and the reason; what it means — the underlying idea in plain English, for someone who did not write this; and what to check — one concrete thing that would break if this is wrong. Plus one rollup for the whole change, with the concepts it turned on.

A hunk with no explanation renders as a visible gap. You can see what it skipped rather than assuming it was covered.

What that changes in practice

  • Review as reading, not archaeology

    Instead of inferring intent from a diff, you read a claim and check it. Most hunks resolve in seconds because the claim is obviously fine; the ones worth your attention announce themselves because the claim is doing more work than the code.

  • Coverage is visible, not assumed

    The agent can list its own explanation coverage before it declares itself done, and unexplained hunks show as gaps in the review screen. The failure mode is a visible hole, not a quiet omission.

  • Push back without leaving the screen

    When an explanation does not survive contact, you can challenge it straight into the agent's live session and make it defend or correct the claim.

    This one needs the terminal open — it types a partial line into a running session for you to finish. It is genuinely the best part of the review and it is also the part that cannot work headless.

  • Concepts, not just changes

    The rollup names the ideas the change relied on, one line of plain English each. Over a few weeks that is the difference between merging agent output and understanding the codebase it is building.

  • The first read, done before yours

    An agent can take the queue of things waiting on you and produce a first pass — what changed, what it is worried about, and what it could not verify — so that your read starts from a position rather than from nothing.

  • Turn a spec into reviewable items

    A planning agent breaks a written spec into queue items with source links attached, and a chain can hand each one to a coding agent that works it in its own worktree. What lands on you is a diff and an explanation, not a Slack thread.

What to check before you buy this

Can I use it to supervise other people's agents?

No. There is no shared view, no server, no sync and no visibility into anything happening on another Mac. One local data directory, one owner. If what you want is oversight of a group's agent output, this is not that and no future version of this architecture becomes that.

What it does supervise is your own load — your own runs, your own review queue, on your own machine.

Will the explanations be any good, or will they be filler?

The contract is written to make filler obvious: updated the code, fixed the bug and refactored are explicitly named as restating the diff and count as unexplained. What must name a mechanism, why must name a rejected alternative or be omitted, and what to check must name something concrete rather than looks good.

That is a constraint, not a guarantee. Judge it on a real change during your first week; if the cards are not carrying weight in your codebase, you will know within one review.

Does it post reviews to my pull requests?

No. It drafts, and you post. Commenting or approving on a pull request is behind a gate that blocks until you say yes to that exact action — and even then the wording is yours to send.

Is the explanation card something I have to configure per agent?

No — and that is the part worth understanding, because it is a stronger guarantee than a special agent would be.

The explanation contract is injected by the app into every run whose working directory is a git repo, whichever CLI it is and whoever wrote the prompt. So a change produced by the overnight backlog agent, by a template you edited, or by a prompt you wrote from scratch all arrive under the same rule, and the agent can list its own coverage before it declares itself done.

It is skipped for runs in a folder with no repo, deliberately — a mail-triage agent should not pay for rules about explaining a diff.

Which three agents do I actually get?

Overnight backlog, at 02:00 — one item a night carried to a reviewable state in its own worktree, tested, uncommitted, explained.

CI red triage, every two hours — a red build on your default branch becomes an item naming the failing test, the exact command to reproduce it locally, and, when the fix is small, the fix itself, uncommitted.

Digest, 18:30 on weekdays — one rollup of what every agent did today, read out of the app's own state.

All three are ready-made prompts you can read in full before switching one on. What makes them a tech lead's pack rather than a developer's is not the agents; it is that every diff they produce arrives explained.

Which agent CLI does this use?

Whichever you already pay for. Claude Code, GitHub Copilot CLI and agy (Antigravity) are all supported, and you can run different agents on different CLIs in the same project. The explanation contract, the review gate and the approval gate are the app's, so they apply identically whichever one produced the change — which is most of the argument for having this layer at all.

See release status See pricing

Not released yet. It will need macOS 12.0 or later on Apple Silicon — and the download page says exactly what is still missing.