agent-loop

Problem solved

Running a coding agent by hand works until you want it to run at four in the morning. Then every question you never had to answer becomes blocking: which account should this run on, what happens when that account hits its five-hour limit halfway through, how do you know whether the agent is working or has been sitting on a question nobody will answer, and what cleans up the worktree when it finishes at 03:38 instead of on the hour. Cron can start things. It cannot decide, watch, or tidy up, and an unattended agent that nobody is watching needs all three.

Value proposition

One cron line for the whole machine. Jobs are folders committed alongside the service they drive, so adding one is a pull request rather than a crontab edit. A quota-aware router picks the account with the most headroom, holds back whatever reserve each account declares so the humans sharing it keep working, and stops at a daily spawn cap. Each worker gets its own git worktree and its own terminal pane. Labels on the issue or pull request are the state machine, so the loop's memory survives a reboot and is readable in the GitHub UI. Three job kinds ship: a builder that turns issues into pull requests, a reviewer that reviews them from a different account than the one that wrote them, and a routine that runs on a schedule. When a worker is genuinely blocked and needs a human, you get one notification. That is the only thing it will interrupt you for.

Target audience

Developers and small teams already running Claude Code or Codex by hand who want the same work happening overnight, and who share provider accounts with other people, so "just let it run" has to mean "without draining the account everyone else needs in the morning".

Tech stack

• TypeScript on Bun, zero runtime dependencies, 418 tests with no network and no forge calls
• herdr for the terminal panes each agent lives in, and for the only signal that says whether a worker is working, blocked, or gone
• A git worktree and a branch per worker, so concurrent jobs never share a checkout
• GitHub labels as the state machine, reached through gh
• A dry mode that performs every read, refuses every write at the command gate, and persists nothing
• GitHub Actions for CI, release-please for conventional-commit versioning, npm publish with provenance

Status

Live and MIT-licensed, published as @tonoid/agent-loop. Code generated with Claude Code, then tested and reviewed manually, and running our own content and digest pipelines in production. It requires herdr, which is not incidental: every worker is a herdr agent, and there is no other way to run one. GitHub only, since labels are the state machine. Workers run unsandboxed with permission prompts disabled, which is what makes them autonomous and also the reason to give the loop its own account. Open to issues and PRs.