What the free Super Agents actually cost.

Written 4 Aug 2026 · a design pass, not a measurement · revisit with real telemetry the week after launch.

Nothing is running yet, so there is no baseline to profile. Everything here comes from the check catalogue, the connector contract, and arithmetic. Figures marked measured were established earlier in this project. Everything else is an estimate and is labelled as one.

01 · The thing that will actually break

2 playbooks, free forever, on every connected site.

That is a recurring cost that grows with adoption and is paid for by nobody, which makes the whole free tier turn on one question: does a free-tier Super Agent run ever call a language model? If yes, the free tier is a liability that scales with success. If no, it is close to free.

Cost per Super Agent run

Rule based, no model
~$0.001measured
Through Sonnet
$0.068 to $0.21measured

Applied to the free tier, priced as if both ran every day

100 connected sites200 runs per day
Rules: $6/moModel: $410 to $1,260/mo
1,000 connected sites2,000 runs per day
Rules: $60/moModel: $4,100 to $12,600/mo
10,000 connected sites20,000 runs per day
Rules: $600/moModel: $41,000 to $126,000/mo
Vulnerability Watch runs every morning; Plugin Updates runs weekly. The real run count is lower than this table, which takes two runs per site per day on purpose — a ceiling is the only figure worth planning against.
Decision

The 2 free Super Agent playbooks contain zero model calls. Not a cheaper model. Zero.

02 · This is achievable, and that is the point

Walk the steps and ask which one needs judgement

Smart Safe Update is the playbook behind Plugin Updates. Every step is a connector call, a comparison or a threshold.

01
Pre-flight readiness

Decide whether to run at all. If there are no updates, or the site is already in maintenance, it exits here and does nothing.

No model
02
Smart backup

Take a fresh backup labelled for this run. It never modifies a backup that already exists.

No model
03
Verify backup integrity

Confirm the backup is actually restorable before a single file is touched. If it is not, the run stops here and nothing is updated.

No model
04
Check requirements and compatibility

Give every plugin with an update a verdict and put the queue in order. Changes nothing.

No model
05
Apply updates safely

The only step that changes anything. One plugin at a time, with a health check after each, and an immediate rollback of that plugin if the site errors.

No model
06
Visual regression

Compare the key pages before and after to catch layout breakage that returns a 200. Skipped entirely when no screenshot tool is connected.

No model
07
Smoke test critical pages

Once everything has settled, confirm the homepage, checkout and contact form still work end to end. Reports only, because step five already handled rollback.

No model
08
Final report and cleanup

One short report, then put back everything step one changed and release the run lock.

No model

Vulnerability Watch is the same shape: a version list compared against a published feed, and the question of whether it is reachable on this site is a lookup against the vulnerability record, not an inference. It reports and it alerts. It does not update, deactivate or edit anything, so there is no judgement call in it either.

Deterministic is better here. The same input produces the same action every time, it is auditable when a client asks what touched their site, and it cannot invent a plugin name into a destructive call. Models earn their cost on the paid Super Agents, where somebody is paying for the thinking.

03 · Concurrency, given the connector contract

One channel, and it shapes everything

A signed HTTPS request to the site’s own connector plugin, which exposes everything WordPress can do. No MCP, no SSH, no application passwords, no database credentials. That single constraint shapes the whole design.

01

The site is the bottleneck, not us

Concurrency limits belong per site, not global

A backup on a 4GB site takes as long as it takes, and it runs on the client's shared host. A global concurrency number tells you nothing useful and will either starve big sites or hammer small hosts.

02

One run per site, always

Two Super Agents updating the same site at once is a corrupted install

This needs a real lock, not a convention. Claim work with a row level lock so two workers can never take the same site. SKIP LOCKED is what makes this safe across many workers with no coordinator, paired with a unique partial index so a site can only ever have one run in flight.

SELECT site_id FROM agent_queue
WHERE state = 'ready' AND run_after <= now()
ORDER BY run_after
FOR UPDATE SKIP LOCKED
LIMIT 1;

CREATE UNIQUE INDEX one_run_per_site
  ON agent_runs (site_id) WHERE state IN ('running','awaiting_approval');
03

Do not run every site at 05:00

Spread deterministically, or you build your own thundering herd

Twenty thousand simultaneous outbound requests is a self inflicted spike, and it puts a herd on shared hosts that will get us blocked. Hash the site id into a slot instead. Deterministic means the same site lands in the same slot every day, so “why did this run at 04:12” is answerable, and it survives a restart without reshuffling.

slot = hash(site_id) % 720   // 720 slots across a 12 hour window
04

Verify is the expensive step in wall clock

Not the update. Budget for it.

Updating a plugin is one call. Loading the pages that matter, twice, and comparing them is many. Worker sizing should be driven by step 7, not step 5.

04 · Failure modes worth designing for now

Because designing later means designing after it hit a client

High
Backup fails or times out

Abort the run. No verified backup, no change. Never proceed.

High
Verify is ambiguous — page changed for unrelated reasons

Compare against a capture taken minutes earlier, not a stored baseline. Hash a stable subtree, not the whole body.

Medium
Site goes down mid update

Roll back on the next reachable connection, and say so loudly.

Medium
Host rate limits or blocks us

Back off per host, not per site. Several client sites often share one host.

Medium
Connector deactivated mid run

Treat as an abort, not an error. Revoking is allowed at any moment.

Low
Rollback itself fails

This is the one that ends the company. Page a human. Never let it fail silently.

That last row is why steps 2 and 3 are not negotiable, and why the rollback inside step 5 has to be tested harder than any other part of the system.

05 · What cannot be answered until there is telemetry

Three unknowns, named rather than guessed

Wall clock per run — sets how many workers are needed
unknown
Real distribution of site sizes — sets backup cost
unknown
False rollback rate — decides whether anyone trusts it
unknown

The two free playbooks launch 18 Aug 2026. See what is coming for the order everything else lands in, or the six Super Agents for what each one will do.