Scheduled AI Agent Skills Earn Their Cron: The Manual-to-Skill-to-Cron Ladder Behind GBrain
GBrain's README claims 66 autonomous cron jobs. Here is the promotion checklist a skill must pass before it gets a schedule, plus a one-page overnight job spec.
Go deeper. Build your own.
Garry Tan says 66 cron jobs run autonomously against his agent brain, and the overnight ones do not wait for him to wake up. That is the pitch in the README of GBrain, the open-source agent memory he built, and it is also the uncomfortable part: an overnight job that rewrites your knowledge base has nobody to ask when it gets confused.
Scheduled AI agent skills are worth having. The mistake is promoting a job to a schedule because it worked once in a chat window. Tan’s own method is stricter than his cron count suggests. Do the task by hand, turn it into a skill, and only then put it on a timer, with a test in between that most people skip.
A skill earns a schedule by passing a fixture run and a supervised dry run, and it loses the schedule the first time a spot-check fails. Below is the checklist for each rung, a one-page spec for the overnight memory-upkeep job that GBrain calls the dream cycle, and the demotion triggers that keep the ladder honest.
GBrain’s 66 cron jobs, and where the method actually comes from
GBrain lives at github.com/garrytan/gbrain under an MIT licence, with about 30.7k stars at 03:35 UTC on Oct 8, 2026. The repo tagline is “Garry’s Opinionated OpenClaw/Hermes Agent Brain,” and that names its primary harnesses: OpenClaw and Hermes Agent. Claude Code and Codex are supported through install sections and MCP, not the main path.
The source of truth is Markdown pages in a git repo, indexed for search, with bundled skills written as SKILL.md files. The README tells you to “treat a SKILL.md as a trainable parameter.”
The numbers are Tan’s own and nobody has audited them. In the README he describes his deployment as 155,795 pages, 24,589 people, 5,340 companies and “66 cron jobs running autonomously” (README re-read Oct 8).
The overnight upkeep has a name, and it is the README’s, not ours: “the overnight dream cycle that enriches your brain while you sleep.” Per the README text, that cycle runs “while you sleep: dedup people pages, fix citations, score salience, find contradictions, prep tomorrow’s tasks.” It is opt-in, alongside API keys, automatic capture and paid enrichment.
Screenshot: GitHub, “GitHub - garrytan/gbrain: Garry’s Opinionated OpenClaw/Hermes Agent Brain” (README as of Oct 7, 2026), captured Oct 7, 2026.
What the README does not contain is the method. “Do it by hand, make it a skill, put it on cron” comes from Tan’s X posts and his essay “Thin Harness, Fat Skills,” posted as an X article on Apr 11, 2026, with follow-up posts later that month. The full text we could read is a BlockBeats translation: the agent works three to ten real items by hand, Tan approves the results, the procedure becomes a markdown skill file, and anything that should run unattended goes on a cron. His test, paraphrased from that translation, is that an agent he has to ask a second time has failed. A later post, reportedly, adds two rungs the essay skips: check the skill is resolvable, then evals and integration tests.
There is no October launch behind this piece. The peg is cadence: GBrain shipped roughly 30 releases on Oct 6–7, reaching v0.60.106.0 (dated Oct 7 in its CHANGELOG, released on GitHub at 01:59 UTC Oct 8; latest as of 03:35 UTC Oct 8). Two entries matter here.
On Oct 6, quotes from “a dream phase” became “checked against the notes it came from.” On Oct 7, the maintenance run started repairing broken tables “with model-spend caps.” The scheduler features underneath are older. Claude Code routines and Codex automations both date from spring 2026.
## An overnight job has nobody to askA skill you invoke by hand has a supervisor by construction. You read the output, you notice the merged people page that should not have merged, and you say so. Move the same skill to 2 a.m. and every one of those corrections disappears. The agent still hits ambiguity; it just resolves it alone, and the resolution lands in the files your daytime agents read tomorrow.
That is why the ladder matters more for memory jobs than for reports. A bad nightly report is noise. A bad nightly rewrite of your notes is a fact your agents will cite next week. The rules for who wrote which memory belong in agent memory write provenance; this piece decides which jobs get to write overnight at all.
The promotion runbook for scheduled AI agent skills
Seven steps. The first three earn the rungs, the fourth is the checklist you keep, the fifth is the overnight spec, and the last two keep a scheduled job honest after it ships.
1. Run it by hand until it stops needing you
Start by choosing the right first job. A good candidate has inputs that already exist when the job wakes up, outputs you can review as a diff, and a worst case you can undo with a revert. Citation repair in a notes repo qualifies. Sending follow-up emails from meeting notes does not, because its output leaves the building before anyone reads it.
Jobs that need a fresh judgement every time, such as deciding which of two conflicting notes is right, stay manual no matter how often they run.
Then run it on real inputs, five times at minimum, with the same instructions each time. Tan’s essay says three to ten items; five is a floor that catches a lucky first run. Write down every point where the agent asked you something or you stepped in. The job is ready for the next rung when a full run finishes with no question and no correction.
Log the token cost of each run while you are there. You will need a cost per run before promotion, and the by-hand runs are the most expensive you will ever see, which makes them a useful ceiling.
2. Write the skill, then check it resolves cold
Turn the steps you actually ran into a SKILL.md in git, with an owner named in the file. The description field is the routing rule, so test it the way Tan’s resolver step implies: open a fresh session, describe the task without naming the skill, and confirm the right skill loads. If a cold request lands on the wrong skill, a scheduler firing that request at 2 a.m. will too.
Put four more lines at the top of the file, above the steps: the inputs the skill reads, the outputs it writes, the actions it must never take, and the measured cost per run. They cost a minute to write and they become the first draft of the job spec in step 5. A skill that cannot fill in “must never” in one line is not ready for an unattended hour.
3. Pass a fixture run before any schedule
A fixture is a frozen copy of inputs with known-good outputs. Run the skill against it and diff the result. Building fixtures is its own discipline, covered in synthetic company fixtures for agent evals; here the rule is only that no skill gets a schedule until it passes one, and that every edit to the SKILL.md re-runs it. Then do one supervised dry run on live inputs at the scheduled hour, with you awake and the write path pointed at a branch.
4. Keep the promotion checklist as a real table
Copy this into the repo next to the skill. Each row is a rung; the job holds the rung only while every cell in that row stays true.
| Rung | Ran by hand N times, same inputs | Outputs checked against a fixture | No human question mid-run | Cost per run known | Who signs | Evidence kept | Demotion trigger |
|---|---|---|---|---|---|---|---|
| 1. Manual run | 5+ runs, same instructions, real items | Each output read by a named human | Last full run needed no question | Logged per run (the ceiling) | The person who did the runs | Run notes listing every intervention | Not applicable: this is the floor |
| 2. Skill | Steps in SKILL.md match the runs as performed | Fixture pass on every SKILL.md edit | Cold request loads the right skill | Re-measured on the fixture | Skill owner named in the file | SKILL.md history in git, fixture diffs | A second ask on a real item drops it to rung 1 |
| 3. Cron | Inherits rungs 1–2 | Fixture pass plus one supervised dry run at the scheduled hour | Zero questions in 7 consecutive nightly transcripts | Per-run cap set at 2× the measured cost | Skill owner plus whoever owns the scheduler account | Per-run log, PR or diff, weekly spot-check note | Failed spot-check, cap hit twice in a week, or an edit without a fixture run drops it to rung 2 |
The 2× cap and the seven-night window are our defaults, not Tan’s; tune them, but write the numbers down.
5. Write the overnight memory-upkeep job spec
The dream-cycle job is the one most worth constraining, because it rewrites the store everything else reads. Here is the one-page spec, filled for an illustrative team research wiki of about 4,000 Markdown pages in a git repo.
job: nightly-wiki-upkeep # illustrative knowledge base
owner: research-ops lead (a named person, not a team alias)
inputs_it_may_read:
- wiki/people/
- wiki/companies/
- wiki/meetings/
- meeting-transcripts connector, read scope only
what_it_may_rewrite: # always as a pull request, never a direct push
- merge duplicate people pages, keeping both paths as redirects
- repair citations that point at files under wiki/sources/
- rescore the salience field in page frontmatter
- write wiki/tomorrow.md, the prep list
what_it_may_never_touch:
- delete any page
- resolve a contradiction (append it to wiki/contradictions.md for a human)
- edit wiki/sources/ (raw notes are the evidence)
- any connector write: calendar, email, chat
evidence_it_leaves:
- one PR per run with the full diff
- run log: start, end, tokens, pages read, pages changed
- every added quote with its source path, checked against that note
token_cap: 400k tokens or $1.50 per run, whichever comes first; hard stop, log, no retry
schedule_window: 01:00-04:00 local, one run; skip if last night's PR is unmerged
kill_switch: scheduler toggle (named account) plus revoke the repo token; last tested on a dated run
review: weekly transcript read, Mondays; demotion per the checklistThree lines carry most of the safety. “Never resolve a contradiction” keeps the job from picking a winner between two notes, which is exactly the judgement it cannot check. “Skip if last night’s PR is unmerged” stops a stack of unreviewed rewrites from compounding. And the token cap is yours to set: the README states no spend cap for the overnight cycle and calls the always-on OpenClaw/Hermes path “the highest-cost path,” so the Oct 7 cap on one maintenance path does not cover the whole job.
The scheduler is also a credential holder. The repo token in that kill switch is a key a cron holds for months; when a provider retires a key class, the fleet API key migration drill is how you find every copy before the job fails at 2 a.m.
6. Pick the scheduler and its off switch together
The scheduler layer is generic, and the examples here are unranked. Per the Claude Code routines docs, routines run in the cloud on a schedule (one hour minimum), from an API trigger or on GitHub events, “autonomously,” with “no permission-mode picker”; connectors are included by default and can write “without asking,” and Team and Enterprise owners get an org-wide toggle. Routines were still a research preview on Oct 8. The scheduled-tasks page adds local desktop tasks with per-task permissions and session-scoped /loop tasks that expire after seven days and switch off with CLAUDE_CODE_DISABLE_CRON=1. OpenAI’s Codex automations reportedly queue results for review and need the app open for local runs, per an OpenAI Academy explainer from April 2026 (OpenAI Academy).
Whichever you use, strip the connectors the spec does not list, and test the kill switch once before the first unattended night. Unattended desktop jobs sit on their own rung of trust, which scheduled tasks as a trust tier lays out; the schedule window itself is a pricing and quota question, and scheduling agents by the clock covers when to run.
Screenshot: Claude Code Docs, “Automate work with routines” (undated docs page), captured Oct 7, 2026.
7. Read transcripts weekly, and demote on the first miss
That callout is the reason step 7 exists. A green run means the session started and exited, not that the dedup was right. Once a week, open three random nightly transcripts and the PRs they produced, and check one change in each against its source note. One wrong merge, one quote that does not match, or one silent question the agent answered for itself, and the job drops to rung 2 until it passes the fixture again.
Write the read down, even when it passes: date, the three runs opened, the change checked in each, and the verdict. Four weeks of those notes are the evidence that the job still deserves its cron. They also answer the question a reviewer asks first after something goes wrong overnight, which is when anyone last looked.
The worked ladder: one job, thirty days
Here is the nightly-wiki-upkeep job climbing the ladder, with every number illustrative. Days 1–5 are by-hand runs at about $1.90–$2.40 each, plus roughly 25 minutes of review per run. On day 7 the SKILL.md lands and a run drops to about $1.10, because the skill stops the agent exploring. The fixture pass on day 9 costs about $0.95, and the supervised dry run on day 11 about $0.90.
The cron starts on day 12 at about $0.80 a night, under a $1.50 cap. On day 19 the Monday read finds a merged people page that should have stayed two people. The job drops to rung 2, the SKILL.md gains a rule about matching on email domain, the fixture gains that pair, and the cron resumes on day 22. Thirty nights at the cron rate is about $24, which is less than the five by-hand runs cost in review time alone.
Illustrative: cost per run falls as the job climbs, and the demotion costs three nights, not a corrupted wiki.
The loop has one exit back down. Evidence from each night decides whether the job keeps its cron.
Where overnight skills fail without waking anyone
| What breaks | Signal you would see | First action |
|---|---|---|
| Green run, wrong result | Status green, but the Monday spot-check finds a change that contradicts its source note | Demote to rung 2, add the case to the fixture, re-run before re-promoting |
| Connector writes nobody approved | A calendar entry, email draft or chat message stamped at the job’s hour | Remove every connector the spec does not list, then check the scheduler’s default connector set |
| Spend runs past the cap | Run log shows the cap hit, or the provider bill jumps on nights only | Lower the cap to 2× the fixture cost, then find the page set that made it loop |
| Cold request loads the wrong skill | A transcript shows a different SKILL.md fired, or none did | Rewrite the description field and repeat the cold-resolve test in a fresh session |
| Contradictions resolved silently | Pages change but wiki/contradictions.md stays empty for weeks | Add “never resolve” to the skill as a hard rule, revert the merged PRs, re-run the fixture |
| Unreviewed PRs stack up | Three or more open upkeep PRs, each built on the last | Pause the schedule, merge or close in order, keep the skip-if-unmerged rule on |
| The job’s key expires | Runs fail at the auth step; nightly PRs stop appearing | Rotate the key into the scheduler secret store, then run the kill-switch test again |
Sixty-six jobs and the register that watches them
Tan’s 66 is a personal setup. A team that copies the pattern ends up with the same count spread across cloud routines, desktop tasks, session loops and plain OS cron, each with its own owner and off switch. Nobody can watch that many overnight runs live, so the watching has to be written: one register row per scheduled skill with its owner, scheduler, cadence, read and write scope, spend cap, change mode, evidence, last verified good run, review date and kill switch.
That register is the overnight half of a multi-agent command center: the daytime view shows which agent is waiting on you, and the register shows which jobs ran while you slept and what they changed. A single standing job, like the standing Slack brief, is the easiest place to start; promote the second one only after the first has survived a month of Monday reads.
FAQ
How do I run Claude skills on a cron schedule?
Put the skill in git with a named owner, prove it loads from a cold request, pass a fixture run, then do one supervised dry run at the scheduled hour. Only then attach a scheduler, such as a cloud routine, a desktop task or OS cron, with connectors trimmed and a tested kill switch.
What is the GBrain dream cycle?
It is GBrain’s own name for an opt-in overnight job that, per its README, dedups people pages, fixes citations, scores salience, finds contradictions and preps tomorrow’s tasks. Treat it like any scheduled memory writer: changes as a pull request, contradictions flagged rather than resolved, and a per-run token cap you set yourself.
When should an AI agent skill be scheduled instead of run by hand?
When five or more by-hand runs on real inputs finished without a question, the skill passes a fixture run on every edit, and you know its cost per run. If you still correct its output, it stays manual. A scheduled job that needs a second ask has failed.
Sources
- garrytan/gbrain on GitHub: repo tagline, MIT licence, star count, deployment counts (read Oct 8, 2026)
- GBrain README (raw): dream-cycle wording, opt-in note, “highest-cost path”
- GBrain CHANGELOG: v0.60.77.0 through v0.60.106.0, Oct 6–7, 2026 (read Oct 8)
- Claude Code Docs, “Automate work with routines”: triggers, autonomy, connectors, org toggle, green-status warning
- Claude Code Docs, scheduled tasks: desktop tasks,
/loopexpiry,CLAUDE_CODE_DISABLE_CRON - BlockBeats translation of “Thin Harness, Fat Skills” (Binance Square): the by-hand, skill, cron method and the second-ask rule (secondary)
- OpenAI Academy: Codex automations: Codex automations explainer, April 2026
