When a pull request merges in one of your connected repositories, Autopilot reads it and works out what it changes for your users: the posts it completes or moves forward, the help articles it makes out of date, a new article it calls for, and its line in the changelog. This article covers its settings. Autopilot is on every plan, and it's on by default once GitHub is connected.
What Autopilot does with a merged pull request
Its changelog line. Every pull request your users would notice gets a line in your users' words, written straight into the changelog's Next release draft. You review it there, in the draft. Pull requests users wouldn't notice, like dependency updates, are taken out of the draft.
Posts. It can complete a post, or post a progress update and move the post to In progress. It can also link a post to the pull request.
Help articles. It can edit an article, or a draft, that's now wrong or missing something, and write the draft of a new one.
Updates to posts and articles either wait for your team or go out by themselves after a hold, as the settings below say. You review them in Autopilot: see Review Autopilot's updates.
Reading pull requests uses your project's AI credits. If the project runs out, the pull requests that merge meanwhile are paused, and Home's Paused card has Resume all for once there are credits again.
Open Autopilot's settings
Open Settings → Autopilot. Owners change these settings. Admins can open the page and read it, which says "Only owners change Autopilot's settings." Members can't open it.
Turn it on or off
Analyse merged pull requests turns Autopilot on or off. It's on by default.
Turned on, Autopilot sends each merged pull request's title, description, commits and changes to your AI provider, with the repository files it reads at the pull request's merge commit and your help center's articles and drafts, to find what to fix. When you check an article against your code, the files it reads are sent too. Files that hold secrets, lockfiles and generated files are left out, and anything that looks like a secret is masked.
Turned off, merged pull requests still go into the Next release draft, but nothing reads them, and What it does by itself and Who's told are hidden. Updates already waiting stay in Autopilot for your team, and none goes out by itself.
What it does by itself
Each switch saves as you flip it.

Switch | What it lets Autopilot do | Default |
|---|---|---|
Link posts by itself | Link a post to a pull request at once, when Autopilot is very sure they're related. A link changes nothing users see. Off, Autopilot makes no links. | On |
Write drafts at once | Write a new article's draft. Only your team sees it, so it doesn't wait for the hold. | On |
Publish article edits | Publish an edit to an article after the hold, if the article hasn't changed since. | On |
Post progress updates | After the hold, move the post to In progress and post Autopilot's update as a comment. | On |
Complete posts | Complete the post after the hold. Completing a post emails the people who asked for it. | Off |
With a switch off, those updates wait for someone to approve them. The changelog line doesn't have a switch: it's always written into the Next release draft.
What always waits for someone
Whatever the switches say, an update waits for your team when it's:
Less sure than (%): Autopilot is less sure of it than this. 95 by default, from 50 to 100.
About a post with this many people or more (author, voters, commenters, subscribers): 25 by default.
About an article read this often or more in 30 days: 500 by default.
An update also waits when its article is a draft (the edit goes into the draft, to approve on its review), when its article has a teammate's unpublished edit, when its post or article changed since it was written, or when the project has more published articles than its plan allows. A fix written by Verify always waits.
Set the hold
The hold (hours) is how long an update that can go out by itself waits first, so your team can stop it. It's 24 hours by default, and can be from 0 to 336 (two weeks). New articles' drafts don't wait.
When the hold is over, Autopilot checks the update again. If it no longer qualifies, for example because its article changed, it waits for your team instead and says why.
The three limits and the hold save together with Save.
Choose who's told
Who's told decides who gets Autopilot's email when a merged pull request has updates. Owners are told. Tick Admins too to tell every admin, and tick people under And these people on the team to tell them too. Each box saves as you tick it.
Each person then picks when they hear, in their own Account settings, or turns the email off. An owner who turned it off still hears when something your users see goes out by itself. See Autopilot's emails.

See how it's doing
How it's doing counts Autopilot's latest updates that went out, up to 50, and says how many were kept as Autopilot wrote them: not edited before approving, nor undone since. For example, "Kept 18 of its last 20 updates unchanged". New articles' drafts, and edits finished in the editor, aren't counted. Use it to decide whether to let more go out by itself.
Choose the AI models and tuning
Autopilot's steps, deciding, double-checking a new article and writing, each have their own model in Settings → Models, on every plan. On Business, owners can also change how sure Autopilot must be before it suggests a change, how much it looks up and how much it thinks, in Advanced tuning. See Autopilot's models and Advanced tuning.

