Quota, limits and safety
What a recurring turn consumes, the caps you can raise or lift, and exactly what an unattended agent can overwrite in your project.
Quota
Turns consume your subscription quota like any other session. There is no separate meter and no hidden cost — but there is also no magic: a job firing every 30 minutes is 48 sessions a day.
The levers live in settings, with cautious defaults you can raise, lower or lift entirely:
| Setting | Default | Note |
|---|---|---|
| Turns per day (default) | 24 | 0 = unlimited |
| Minimum interval | 300 000 ms | technical floor = the scheduling pass interval |
| Default priority | 40 | lower = runs after human work |
| Max checklist size | 262 144 bytes | the checklist is sent at every turn |
| Failed turns retained | 10 | per job, for diagnosis |
| Never take the last free slot | off | orchestrator pool only |
| Concurrent sessions | 3 | global cap on the orchestrator pool |
| Engine paused | off | nothing launches while the pause holds |
A job can override these: turns per day left empty inherits the setting, 0 means unlimited.
OFM enforces the setting and shows consumption — turns today on each row, plus the usage screen. How much you consume is your call: no upper limit is imposed. An empty checklist fires no turn at all.
Since 4.0.0, a turn started while its subscription’s window is spent can be moved to another subscription you have already used on that project, or parked rather than eat the reserve. Both behaviours, and how to choose which subscriptions a project may fall back to, are described in Quota and subscription switching.
Projects without version control
A project can be a code repository — but it can just as easily be a book, a folder of notes, a vault. Nothing in recurring work assumes git, a build or a test suite.
- The instruction never
git push, stay on the current branch is added only if the project contains a.git. It is an instruction to the CLI, not a technical constraint — an agent can ignore it. - A recurring job creates no branch. It works on the current branch, in the working tree you share with it. That is the simplest choice and the least protective one: what the agent changes lands where you are working. If you want its writes isolated, set that up on your side before letting it run.
- On a project without version control, what the agent writes is not reversible by OFM — no backup copy, no snapshot. Backups and versioning stay your responsibility.
Start by reading
For a first recurring job, one that reads and reports without modifying anything gives you an observable result while changing nothing. It is the cheapest way to find out whether your checklist says what you meant it to say.
What a recurring job cannot take from you
A session you open by hand always starts, immediately, even when every orchestrator slot is occupied by turns. The concurrent-session cap counts orchestrator workers only — your own work is never queued behind an automated job.
Frequently asked
- Does a recurring job create its own branch?
- No. It works on the current branch, in the working tree you share with it. If you want its writes isolated, do that yourself before letting it run.
- Can OFM undo what a recurring job wrote?
- No. There is no backup copy and no snapshot. On a project without version control, what the agent writes is not reversible by OFM.