WordPress keeps a full copy of a post every time you update it. Over a few years those copies quietly become the largest thing in your database, and nothing in the admin shows you how much of it they are.

Revision Autopilot shows you, then removes them — however you prefer to work.

A screen, when a person is deciding

Under Tools Revision Autopilot you get the total, an estimate of the space it occupies, and a breakdown by parent post type. Delete everything, or one post type at a time. Deletion runs in batches with a progress bar that reports what is left after each one, so a site with tens of thousands of revisions finishes without hitting a PHP time limit.

Every destructive action asks twice, in two different places on screen, and says exactly how many revisions it is about to remove. That confirmation works with JavaScript switched off too.

WP-CLI, when a script is deciding

wp revision-autopilot count
wp revision-autopilot delete --scope=post --limit=100
wp revision-autopilot optimize

--dry-run reports what matches without touching it. `--all` repeats a bounded batch until nothing is left.

Abilities, when something else entirely is deciding

The same operations are published as abilities — named operations with input and output schemas, permission callbacks and behavioural annotations — using the Abilities API introduced in WordPress 6.9. Anything that can discover abilities can find these, understand what they take and return, check whether it is allowed to run them, and read back a structured result.

All three surfaces sit on one set of objects, so they cannot drift apart in what they actually do.

What it exposes

Four abilities, all under the revision-autopilot/ namespace:

count-revisions — how many revisions exist, their estimated content size, and the same broken down by parent post type. Read-only.
list-revisions — one page of individual revisions with their parent post and timestamps. Read-only.
delete-revisions — deletes one bounded batch for a scope and reports how many remain. Destructive.
optimize-tables — runs OPTIMIZE TABLE on the posts and postmeta tables. Destructive.

And three WP-CLI commands over the same code:

wp revision-autopilot count
wp revision-autopilot delete --scope=post --limit=100
wp revision-autopilot optimize

How it stays safe

Deleting revisions cannot be undone, and the same operations are reachable from three directions. Each one has to be safe on its own terms.

Every ability and every CLI command checks permission itself. Neither path has a form or a nonce behind it, so authorisation is never inherited from the surrounding request. Reading needs edit_posts; deleting or optimizing needs manage_options. Both are filterable.
The screen asks twice. A destructive control opens a panel stating how many revisions it will remove, and the confirm button inside repeats that number so it cannot be clicked blind. The two steps sit in different places on screen, and the confirmation is plain HTML — it still works with JavaScript switched off. Either step can be backed out of: the panel carries a Cancel, and a deletion already running carries a Stop.
Deletion is always bounded. One call never removes more than 1000 revisions however large the scope. The result says how many remain, so both the progress bar and a script loop deliberately rather than firing one unbounded request.
Only revisions are deleted. Every candidate is checked against wp_is_post_revision() before removal, and deletion goes through wp_delete_post_revision() so related metadata is cleaned up with it. Published content is never touched.
Only two tables are ever optimized, from a fixed allowlist: posts and postmeta.
Refusals explain themselves. A caller without permission gets a WP_Error saying which capability is missing, not a bare false.

Moving here from Takahiro Revision Cleanup

The same author published Takahiro Revision Cleanup, a revision cleanup plugin with a screen under Tools. As of version 1.0.0 this plugin does everything that one did, and Takahiro Revision Cleanup is being retired.

If you are moving across: install this plugin, activate it, then deactivate and delete the old one. Nothing needs exporting — both read the same revisions straight out of wp_posts, so the figures will look the same on the first screen you open.

Two details for anyone who had integrated with the old plugin:

The tnrc_security_event action still fires, alongside this plugin’s own revision_autopilot_event. Existing audit logging keeps working.
The minimum WordPress version here is 5.9, the same as the old plugin’s, so migrating never requires a WordPress upgrade. The abilities register themselves only when the Abilities API is present (WordPress 6.9 and up); on older sites the screen and WP-CLI work exactly the same.