Your local agent workspace.

Less juggling. More building.

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

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.

Open-source maintainer

Wake up to triaged issues, a reproduction video, and a changelog you only have to approve.

You maintain this in evenings, unpaid, and the backlog is guilt rather than a plan. An agent can read the issues before you do and draft your answers — and it posts nothing in your name.

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

A GitHub issue filed at 03:12 beside a reproduction recording captured at 03:40, with a queue item holding the drafted reply and a gh issue comment sitting unposted behind an approval gate.
Illustration Filed 03:12. Reproduced 03:40, with a recording. Reply drafted. Nothing posted — the comment is still sitting behind the gate.

Day one: three agents, already written

  • Issue triage

    Every morning at 8

    Every new issue arrives labelled, deduplicated and with a drafted reply — none of it posted.

  • Repro runner

    Every 6 hours

    A bug report becomes a yes/no reproduction with a recording attached, in the Gallery.

  • Release notes

    Fridays at 5pm

    A drafted changelog grouped by change type with contributors credited, ready to paste — and nothing tagged or published.

Installed as the oss-maintainer pack. Every agent arrives switched off, with a “Run once” button — nothing fires on its own.

What has to be true first

  • The repo is on GitHub
  • gh authenticated for that repo (per-project GH_TOKEN / GH_CONFIG_DIR)
  • A way to run the project locally, or the repro agent has nothing to run

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.

The thread that died

Somebody filed a bug at 3am with two sentences and no version number. You asked for more detail four days later. They never came back, and the issue is still open, and you are the one who feels bad about it.

The agent version of that night: it read the issue at 08:00, classified it, searched for duplicates and named the original by number, and drafted the specific request — version, OS, exact command, expected versus actual — instead of the generic please provide more information. Six hours later a second agent took the bug, built the project at the version the reporter named, followed their steps exactly, and answered one question: does it reproduce? It captured the failure state and the same state on the current default branch, side by side, into a folder named after the issue.

You open the app and there is a verdict, a recording, and a reply you only have to read.

Why this fits a maintainer specifically

Everything here already exists for the person who built it — this persona needed no new machinery, only the three prompts.

  • gh is already authenticated, per repo

    Each project carries its own GitHub token and config directory, so one machine can hold several identities without you switching anything. The agents use the gh CLI for all GitHub work rather than scraping the web UI.

    GitHub only. There is no adapter for any other git host, and none is planned.

  • Nothing is posted in your name

    Commenting, closing, labelling, editing, tagging a release, publishing — each has to come through a gate that blocks the agent's process until you decide. A timeout or an unreachable app both mean no. Drafts pile up in a queue; the actual write is the only thing that asks.

  • Reproduction as evidence, not narration

    The verification contract makes an agent leave proof a human can check without re-running anything: screenshots or a short recording, one folder per issue reference, browsable in the app. I could not reproduce this is a valid and useful finding, and the agent is told to say it rather than to speculate about a cause it never saw.

  • It remembers where it got to

    Durable per-project memory means triage resumes at the highest issue number it already handled rather than re-reading fifty issues every morning, and the reproduction agent does not answer the same bug twice.

  • Drafts batched, gates rare

    Approval fatigue kills this persona faster than anything else: if every drafted comment needs a tap, you will switch the agent off in a week. The pack batches drafts into the queue and gates only the actual write, so a morning is one read and a handful of decisions.

  • A changelog that credits people

    Grouped by change type with breaking changes first and every non-maintainer author credited by handle, drafted from the merged pull requests and the log since the last tag. It proposes a version and justifies it in one sentence. It does not tag and it does not publish.

The obvious worry

I am not letting a bot talk to my users.

It does not. Every reply lands as a draft you read and post yourself, and posting is behind a gate that fails closed. The agent's output is text in your app, not a comment on your repo.

The reason this is worth doing anyway is that the expensive part of triage was never the typing — it was reading forty issues to find the four that matter, checking whether each is a duplicate, and building the project at the reporter's version to see if the bug is even real.

I am on Linux.

Then this does not work for you, and there is no version coming. macOS on Apple Silicon only — the channel between agents and the app is a Unix socket and the whole app is full of macOS-specific assumptions. This is the single most common reason a maintainer bounces off it, and it is better said here than after a download.

My project is not on GitHub.

Then two of the three agents have nothing to talk to. All the GitHub work goes through the gh CLI and there is no adapter for any other host. The reproduction agent still works on its own, because it only needs a bug report and a build.

Which agent CLI does this use?

Whichever you already pay for — Claude Code, GitHub Copilot CLI and agy (Antigravity) are all supported, selectable per agent. AgentCron contains no model of its own, so triage quality is your CLI's, on your subscription, exactly as it is when you run it by hand.

For an unpaid side project that matters: there is no second subscription here. This schedules the one you already have.

Can it reproduce a bug in a project it cannot build?

No, and it is told to say so and stop rather than substituting a different version and calling that a reproduction. If your project needs a specific toolchain or a service running, the agent needs a documented way to bring it up — ideally the setup script your project already has.

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