Put an AI Agent on a Cron Job: Automating Dev Chores with OpenCode

Most of what an AI coding agent does for you interactively is stuff you asked for twice this month already. Check whether the docs drifted from the code. Bump the dependency and run the tests. Summarize what changed this week. The moment a task is recurring and has a verifiable output, it does not need you in the loop - it needs a schedule.

The pattern is old and boring on purpose: cron fires, a script gives an agent one job in a fresh checkout, the output arrives as a pull request you review with your coffee. We run a version of this for parts of this site, and the mechanics below are the distilled, portable core of it. OpenCode is the agent CLI used throughout because it is open source, scriptable, and model-agnostic - swap in your harness of choice and the shape survives.

Official Sources#

This guide is a complete start-to-finish build: seven steps, from a bare machine to a small fleet of scheduled agents opening PRs. Each step ends in something you can run.

Step 1: Install OpenCode and pick a model#

Install with the official one-liner from the OpenCode docs:

curl -fsSL https://opencode.ai/install | bash

Authenticate a provider (opencode auth login), then confirm non-interactive mode works - this single capability is what makes the whole pattern possible:

opencode run --model opencode/deepseek-v4-flash "print the current directory tree, two levels deep"

If that returns and exits cleanly, you have everything the schedule needs. Re-checked against the CLI reference on November 3, 2026: opencode run and --model (in provider/model form) work as shown. Two flags matter for unattended runs: --auto auto-approves permissions that are not explicitly denied, so pair it with deny rules rather than using it bare, and --attach points a run at a long-lived opencode serve to skip MCP cold starts. The docs also now advertise OpenCode v2; the upgrade guide covers what changes. On model choice: scheduled work is where cheap models shine - narrow tasks, high volume, a gate catching misses. This week's DeepSeek V4 Flash 0731 release is the current sweet spot at $0.14/$0.28 per million tokens with agent benchmarks that pass much larger models. The fleet economics post covers when a task deserves a stronger model; rule of thumb, escalate the judge, not the worker.

Step 2: Write the runner script#

One script, four moves. Fresh clone, one prompt, a gate, a PR:

#!/bin/bash
# ~/bin/agent-chore.sh <name> "<prompt>"
set -eu
NAME="$1"; PROMPT="$2"
WORK="$(mktemp -d)"
trap 'rm -rf "$WORK"' EXIT

git clone --depth=20 git@github.com:you/your-repo.git "$WORK"
cd "$WORK"
git checkout -b "auto/${NAME}-$(date +%Y%m%d-%H%M%S)"

# One job, bounded time, no interactive session
timeout 1800 opencode run --model opencode/deepseek-v4-flash "$PROMPT"

# Nothing changed? Exit quietly - most runs should.
git diff --quiet && git diff --cached --quiet && exit 0

# Gate before anything leaves the machine
npm test

git add -A && git commit -m "auto: ${NAME}"
git push -u origin HEAD
gh pr create --fill

Save it as ~/bin/agent-chore.sh, chmod +x it, and test it once by hand with a trivial prompt before any schedule touches it. A runner you have never watched succeed interactively is not ready to run unattended.

Step 3: Put it on the schedule#

One crontab entry per chore (crontab -e; check expressions on crontab.guru):

# Every weekday at 07:10: check docs against the code they describe
10 7 * * 1-5 ~/bin/agent-chore.sh docs-drift "Read README.md and docs/. Compare every documented command and flag against the actual CLI source in src/cli/. Fix any doc that drifted. Change nothing else."

That is the whole trick working end to end: cron fires, the agent does one bounded job in a clean checkout, and the result is a PR in your queue by breakfast. Everything from here strengthens the loop.

Step 4: Pick your first chores#

Pick tasks with a verifiable output and low blast radius:

1. Docs drift (daily): compare docs to code, fix what lies. The diff is self-evidently reviewable.
2. Dependency patch bumps (weekly): bump patch versions, run the test suite, PR only if green.
3. Morning brief (daily): summarize yesterday's commits, open PRs, and failing CI into one issue. Read-only, zero risk.
4. Flaky test hunter (weekly): re-run the suite a few times, open an issue naming the tests that disagree with themselves.
5. Changelog watcher (daily): fetch the changelogs of your three most critical dependencies, open an issue when something breaking lands.

Notice the shape: three of the five produce issues, not code. Start there - an agent that files a wrong issue costs you a click; an agent that merges wrong code costs you an evening.

Step 5: Add the guardrails#

Running agents unattended is a different sport from running them interactively. The failure mode is not one bad run, it is bad runs on a schedule. From production experience:

• Fresh clone every run. State accumulation is where scheduled agents rot. A clean checkout makes every run reproducible and every failure explainable.
• timeout on the agent call. An agent stuck in a loop at 3am should die at the bound you set, not at sunrise.
• A lock per chore. mkdir /tmp/lock-$NAME fails if the previous run is still going; skip instead of stacking.
• Quiet no-op exits. Most runs should find nothing to do. If your automation produces output every single run, its prompt is padded.
• PRs, never direct pushes. The schedule removes you from the loop; the PR puts you back in at the only point that matters. Keep branch protection on.
• A real gate before the PR. Tests, typecheck, lint - whatever your repo treats as green. The agent's opinion of its own work does not count.
• Watch spend like a metric. Token costs on a schedule compound quietly. We wrote up the overnight-bill failure mode separately - read it before you schedule anything hourly.

Step 6: Choose where it lives#

Your own hardware is the cheapest and simplest start: any always-on box - a mini PC, a homelab node, the old laptop in the drawer - runs cron and OpenCode happily. Full control, no egress rules, hardware cost already sunk. The tradeoffs are the obvious ones: your power, your uptime, your problem.

A cloud host buys you uptime and a clean blast radius - scheduled agents on a $5 instance stay far away from your laptop's SSH keys and your production database. Railway is the low-friction option here: it has cron jobs as a first-class feature, so a service holding your runner script plus a schedule expression replaces the crontab entirely, and logs land in the dashboard instead of a file you forget to rotate. Any VPS works the same way with plain cron if you prefer raw hardware.

Either way, treat the box as disposable: a git remote, an API key with a spend cap, and nothing else you would miss.

Step 7: Start with one, then compound#

The mistake is scheduling five agents on day one. Schedule the morning brief - read-only, useful immediately - and live with it for a week. You will learn how your prompts behave unattended, what the logs need to capture, and whether the output earns its place in your morning. Then add the second chore, and the third. The end state this guide points at: a handful of named chores, each a one-line schedule and a one-paragraph prompt, producing a short stack of reviewable PRs and issues every morning. The compounding is real, but it compounds from working loops, not from ambition.

FAQ#

Can OpenCode run non-interactively?#

Yes: opencode run --model <model> "<prompt>" executes one task and exits, which is what makes it cron-able. See the OpenCode docs for models and flags.

What does a scheduled agent cost to run?#

Task-dependent, but with a budget model like DeepSeek V4 Flash at $0.14/$0.28 per million tokens, a bounded daily chore typically lands in cents per day. The risk is not the per-run cost, it is unbounded loops - set timeouts and spend alerts.

Is it safe to let an agent commit code automatically?#

Let it commit to branches, never to main. The safety comes from the pipeline around the agent - fresh clones, test gates, PRs with review - not from trusting the model.

Do I need a server, or can I run this on my own machine?#

Either. Any always-on machine with cron works. A small cloud instance like Railway adds uptime, isolation from your personal credentials, and dashboard logs, with cron scheduling built in.

Sources#

Some links to tools above are referral links - see our affiliate disclosure.

Last updated: November 3, 2026

Continue Reading#

• OpenCode Developer Guide 2026 - the full tour of the CLI this post schedules
• DeepSeek V4 Flash 0731 in OpenCode - the budget model doing the work above
• Long-Running Agents Need Harnesses - why the script around the agent matters more than the agent
• Agent Fleet Economics - when to escalate from cheap models to strong ones
• The $400 Overnight Bill - agent FinOps, learned the hard way
• DeepSeek Super-Agent: The Always-On Router and Worker Design - the always-on alternative to a clock: event-driven agents with an observe-first mode
• Give Your Coding Agent a Voice: Dictate Prompts with Wispr Flow
• Automate Video Editing with the Descript API - a full scripted pipeline ready to run on this schedule
• OpenCode Hacked: What the Console Breach Means for Your API Keys - rotate stored provider keys before you schedule agents with them
• Put Your Coding Agent in Discord - an interactive front door for this same headless run pattern
• Run Your Coding Agent as an API - the always-on cousin: one warm server the schedule attaches to instead of a fresh process per run
• OpenCode 2: How to Upgrade From v1 - what breaks in the v2 migration and a safe checklist
• OpenCode - pricing, model support, and alternatives on one page
• Best CLI Tools for Developers - more terminal tools for scheduled agent work