litespeed/update-cache-ttl changes how long each kind of response stays cached: public and private pages, the front page, feeds, REST responses, AJAX, and the error pages.
All values are in seconds.
At a glance
| Ability | litespeed/update-cache-ttl |
| 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 |
TTL is not the main purge mechanism
On a WordPress site the cache is mostly kept fresh by purging: publish a post and LiteSpeed purges the pages that post appears on. The TTL is the backstop for everything that changes without a purge event — a widget that renders a date, a page built from an external feed, content edited outside WordPress.
Which means a short TTL is rarely the right fix for staleness. If edits are not appearing, the purge rules are the thing to look at; shortening the TTL treats the symptom and pays for it on every page of the site.
The front page usually deserves its own, shorter value. It changes more often than any individual post and it is the page most visitors see first.
Error page TTLs are worth a thought too: caching a 404 for a day means a page that gets fixed stays broken for a day.
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 the front page for one hour instead of a day.
It resolves to one call:
{
"ability": "litespeed/update-cache-ttl",
"parameters": {
"settings": { "cache-ttl_frontpage": 3600 }
}
}Worth knowing
- Seconds, not minutes.
- Staleness is usually a purge-rule problem, not a TTL problem.
- Caching error responses for long periods keeps fixed pages broken.
- Existing cached entries keep their original TTL until they expire or are purged.
Related abilities
- Get Purge Settings — the rules that matter more than TTL
- Get Cache Settings — read the current values
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category