litespeed/update-cache-scope changes what gets cached for whom: logged-in users, commenters, REST requests, the login page, and whether mobile gets a separate copy.
Widening the scope to logged-in users is the single setting most likely to serve one person’s page to another. Change it deliberately.
At a glance
| Ability | litespeed/update-cache-scope |
| Toolset | LiteSpeed Cache — toolset/litespeed |
| Group | LiteSpeed Cache › Page Cache |
| Requires | LiteSpeed Cache, active on the site |
| Capability | manage_options |
| Safety | Writes data |
| Repeatable | Idempotent — running it twice leaves the same result |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
Why logged-in caching is the dangerous one
A cached page is a file served to whoever asks for it. For a logged-out visitor that is fine — everybody gets the same page. For a logged-in user it is only fine if something guarantees that each user gets their own copy, and that guarantee comes from the vary rules, not from this setting.
So enabling logged-in caching without the vary configuration to match is how a dashboard greeting addressed to one user ends up on another user’s screen. The two settings are in different areas and it is entirely possible to change one and not the other.
Read litespeed/get-cache-vary before widening scope, and test with two real accounts afterwards. One account proves nothing.
REST caching has a subtler version of the same problem: REST responses frequently carry per-user data and are frequently requested by the block editor, so caching them can produce an editor showing somebody else’s draft.
The write is a patch, not a replacement. Send one key and one key changes; everything else in the area is left alone. The response names the keys that actually moved, so a payload that matched the existing values comes back with an empty list rather than a misleading success.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
settings | object | Yes | A map of setting key to new value. Keys outside this area are refused, and the refusal lists what the area accepts. |
What comes back
| Name | Type | What it is |
|---|---|---|
updated | array | The keys that actually changed. An empty array means every value you sent was already set. |
settings | array | Every setting in the area after the write, in the read shape. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Cache pages for logged-in users too.
It resolves to one call:
{
"ability": "litespeed/update-cache-scope",
"parameters": {
"settings": { "cache-priv": true }
}
}Worth knowing
- Check the vary rules before widening scope. They are what keeps copies separate.
- Test with two accounts, not one.
- REST caching can affect the block editor.
- Purge after changing scope — existing entries were cached under the old rules.
Related abilities
- Get Cache Vary Rules — read these first — they are the safety net
- Update Cache Vary Rules — change them to match
- Purge Cache — clear pages cached under the old scope
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category