Configuration
Cadence, publishing days and times, drafting limits, topic selection and how far ahead a Project may schedule.
On this page
Autopilot settings live under Project settings, and every one of them applies to the active Project alone.
Cadence
Your cadence is a grid: the weekdays a Project publishes on, and the local times it publishes at on each of those days. The grid holds one article per time per eligible day, which is its capacity rather than a promise to fill it.
- Publishing days0 to 6
Which days of the week articles land on. Sunday is 0.
- Publishing timeslocal, HH:MM
Up to four times a day, one article each. A Project publishing once a day has exactly one, which is what every schedule written before this control existed still means.
- Time zoneIANA identifier
The zone the days and times are read in, for example
Europe/Berlin. An unrecognised value falls back to UTC rather than silently shifting your schedule.
How many times a day
Your plan decides. The limit is the daily average the plan funds plus one day of
headroom, never fewer than two and never more than four, so the picker offers a
real choice on every plan without turning into a cron expression. The control
under the times reads {n} of {limit} per day on your plan.
Why an hour apart
Times must be at least an hour apart, and the reason is daylight saving. On a spring-forward day every local time inside the skipped hour resolves to the same instant, so two slots an hour apart or less would collide into a single schedule slot and one of the two articles would quietly not exist.
The grid is a shape, not a rate
Adding times does not buy you more articles. targetPostsPerPeriod is still the
funded ceiling, and the planner spreads that target across whatever grid your
days and times produce. Three times a day on Mondays publishes the same allowance
as once a day on weekdays; it just arrives in fewer, denser publishing days.
What the ceiling is measured over depends on the Project. On a paid plan it is the billing period, and it refills when that period rolls over. On a Free Project it is the one-time lifetime grant, which never refills, so a denser grid spends the same 3 posts sooner rather than earning more of them.
The target itself is now derived from the schedule rather than typed into a box beside it, and the line under the picker shows what your current grid implies.
Limits
- Max drafts per run1 to 20, default 3
A ceiling on how much one run may produce. This is what stops a single run spending a month's allowance in one afternoon.
- Max scheduled posts ahead1 to 100
How deep the queue of scheduled posts may get. A Project that is producing faster than it publishes stops drafting when it reaches this.
The scheduled-post default is five per publishing time a day, so a Project publishing once a day gets five and one publishing four times a day gets twenty. It scales because the ceiling counts scheduled posts of every kind, manual ones included, and a flat five would be consumed in a day and a half at the densest setting. A value you set yourself is honoured exactly as saved, up to 100.
Topic selection
How Autopilot chooses what to work on next:
| Mode | Behaviour |
|---|---|
priority | Highest priority approved Topics first |
oldest_approved | The Topic that has been waiting longest |
balanced | Spread across Directions according to their shares |
Topic supply
In Full mode a Project can replenish its own Topics rather than waiting for you to approve more. This is authorised on its own, separately from drafting, and it is Full only: switching a Project to Assisted turns it off, and an Assisted configuration that still carries it is refused rather than saved.
A new Project choosing Full starts with automatic refill on. The control sits on the same screen as the mode you just picked, it says that refilled Topics spend this Project's post allowance, and you can set it back to existing Topics only before you save.
A Project that has already saved an Autopilot configuration is never re-defaulted: it keeps exactly what it stored. A stored value that is missing, malformed, or written under the older schema still resolves to off, so nothing changed underneath a Project that was already running.
See Assisted and Full for what refill does once it is on.
Status
A Project's Autopilot is in one of four states: active, paused, disabled,
or error. An error state carries the reason with it. Archiving a Project
pauses Autopilot and records that the pause came from the archive.
Pausing
Pausing stops runs without losing configuration or queued work. It is the right move during a launch, a migration, or any week where you would rather nothing published on its own.