---
title: "Configuration"
description: "Cadence, publishing days and times, drafting limits, topic selection and how far ahead a Project may schedule."
updated: "2026-08-28"
verifiedAgainst:
  - packages/shared/src/autopilot.ts
  - packages/shared/src/free-grant.ts
  - apps/web/lib/autopilot-settings.ts
  - apps/web/app/app/settings/autopilot/page.tsx
---

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.

<PropertyList>
  <Property name="Publishing days" type="0 to 6">
    Which days of the week articles land on. Sunday is 0.
  </Property>
  <Property name="Publishing times" type="local, 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.
  </Property>
  <Property name="Time zone" type="IANA 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.
  </Property>
</PropertyList>

### 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.

<Callout variant="warning" title="A Project set up before this change">
  A Project whose target was typed rather than derived can still carry an older
  number, and Autopilot follows that number until you save the schedule again.
  The settings screen says so, in words, with the figure it is still using.
</Callout>

## Limits

<PropertyList>
  <Property name="Max drafts per run" type="1 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.
  </Property>
  <Property name="Max scheduled posts ahead" type="1 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.
  </Property>
</PropertyList>

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](/autopilot/modes) 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.