From Suggestions to Self-Driving: yeet's Four Autonomy Modes

Every SEO tool eventually forces the same question: how much do you trust it to act without asking first? yeet answers this with four autonomy modes, plus a separate auto-merge switch that controls whether it can merge its own pull requests. These are two different dials, not one — mixing them up is the most common way people misjudge what yeet is actually doing on their site.

The four autonomy modes

Autonomy mode decides what yeet is allowed to do once it finds something worth fixing. It's a ladder, from "just tell me" to "just handle it."

Mode	What it does	Confidence bar	Scope
read_only	Watches and logs findings; nothing becomes an actionable card	n/a	n/a
propose_only (default)	Generates cards and copy-ready prompts; you apply everything yourself	n/a	All fix types
auto_apply_safe	Opens PRs on its own for low-risk fixes it's confident about	confidence ≥ 0.85	Low-risk fix types only
auto_apply_aggressive	Opens PRs across a wider set of fixes at a lower confidence bar	confidence ≥ 0.75	Any fix type

read_only

yeet watches your site — Search Console data, rankings, backlinks, AI citations — and logs findings, but nothing gets turned into an actionable card. This is the mode for evaluating yeet before trusting it with anything, or for a site you don't want automated at all, like an agency client's site sitting under a separate governance process.

propose_only, the default

This is where every newly connected site starts. yeet turns findings into optimization cards — specific, scoped fixes with a prediction attached — but you decide what happens to each one. For fixes that map to a file change (meta tags, schema markup, technical SEO, canonicals, llms.txt) you get a one-click PR or a copy-ready prompt. For content-shaped fixes — content gaps, rank-recovery work on an existing page — you get a copy-ready prompt instead, since content changes need a human voice even when the direction is clear. Nothing ships without you clicking something.

auto_apply_safe

Here yeet opens a pull request on its own, without you clicking apply first — but only under two constraints at once: the fix type has to be one of the low-risk categories, and yeet's confidence score for that specific fix has to clear 0.85. Confidence is scored per fix, not per site, so on the same day yeet might auto-open a PR for a missing meta description while a content-gap suggestion on the same site still sits in your queue — that's a different fix type, not a broken mode.

auto_apply_aggressive

Same mechanism, wider net: the confidence bar drops to 0.75 and the fix-type restriction lifts entirely. This is the mode for people who've watched yeet's suggestions long enough to trust its judgment and would rather review PRs after the fact than gate every one before it exists. It's also where you'll see the most PRs land, so it only makes sense if you or your team actually reads GitHub notifications.

The auto-merge switch is a separate setting

None of the four modes above control merging. Auto-merge is its own toggle, off by default for every user, and it only matters once yeet is already opening PRs under auto_apply_safe or auto_apply_aggressive. When it's on, yeet will merge its own PRs — but the rules are deliberately narrower than auto-apply itself:

• Only safe fix types qualify, regardless of which autonomy mode you're running
• Confidence still has to clear 0.85, even under auto_apply_aggressive's lower 0.75 bar
• CI checks on the PR have to pass
• The PR has to be at least 10 minutes old — no instant-merge, so there's always a window to notice and intervene
• If CI fails, yeet skips the merge rather than treating it as an error; the PR just sits there waiting for you
• A per-user kill switch overrides everything else immediately

In practice, auto-merge is the narrowest, most conservative layer in the whole system — narrower than auto_apply_aggressive's own thresholds — because it's the one action that removes your review entirely. It's built to be boring on purpose.

Which mode should you pick

Risk appetite	Recommended mode	Auto-merge
I want to see everything before it moves	propose_only	Off
I trust the safe stuff, not the rest	auto_apply_safe	Off, or on once you trust the PR quality
I check GitHub daily and want fewer clicks	auto_apply_safe or auto_apply_aggressive	On, if you rarely reject safe-type PRs
I want this fully hands-off across sites	auto_apply_aggressive	On
I'm evaluating yeet, or this isn't my site to automate	read_only	Off

A reasonable path for most people: start on propose_only for two or three weeks, notice how often you'd have approved a card as-is versus edited or rejected it, then move to auto_apply_safe once you trust the safe-type PRs. Save auto_apply_aggressive and auto-merge for once you've actually read a batch of yeet's PRs and found them boring in a good way.

Autonomy mode and auto-merge are both per-site, per-user settings you can change any time in the dashboard settings. Changing mode doesn't touch cards already in flight — see how yeet verifies a fix for what happens after a card ships. And if you haven't connected a repo yet, none of the auto-apply modes have anything to act on — see get indexed on Google fast for the basics of getting connected.

Quick FAQ

Does auto_apply_aggressive skip verification? No — verification (see how yeet verifies fixes) runs the same way regardless of autonomy mode. Autonomy only controls whether a PR gets opened, and possibly merged, without your click; it doesn't change how yeet checks whether the fix actually worked.

Can I set different modes for different sites? Yes — autonomy mode is set per connected site, so you can run propose_only on a client site and auto_apply_safe on your own project at the same time.

What happens to an open PR if I turn auto-merge off mid-flight? Anything already merged stays merged; anything still open just waits for you, the same as it would under propose_only.