litespeed/update-tuning-settings changes the tuning options: which URIs and roles skip optimisation entirely, and whether optimisation applies to guests only.
These are the blunt instruments. They exempt whole sections rather than individual files.
At a glance
| Ability | litespeed/update-tuning-settings |
| Toolset | LiteSpeed Cache — toolset/litespeed |
| Group | LiteSpeed Cache › CSS, JS & HTML |
| 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 |
When a blunt instrument is right
The per-file exclusions are almost always the better tool: they keep the benefit everywhere except the one script that cannot take it. But some situations are genuinely whole-section.
An admin-facing area built as a front-end app, a checkout flow from a payment provider, a customer portal that loads its own bundle — in each case the optimisation pipeline has nothing to offer and a real chance of breaking something. Exempting the URI is correct.
Exempting a role is the same idea for people rather than pages: editors working in a front-end builder get the unoptimised site, everybody else gets the fast one.
Guests-only is the strongest version and a reasonable default on a site with a large logged-in application. Logged-in users get the site unoptimised and therefore predictable; visitors get the performance.
Each of these is a choice to stop optimising something. Before reaching for one, check whether a file-level exclusion would do.
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:
Skip optimisation on the customer portal.
It resolves to one call:
{
"ability": "litespeed/update-tuning-settings",
"parameters": {
"settings": { "optm-exc_roles": ["administrator"] }
}
}Worth knowing
- Prefer a file-level exclusion where one would work.
- Guests-only is a reasonable default on sites with a large logged-in application.
- Exempting a URI exempts everything on it, including things that were fine.
- A patch — unsent keys are untouched.
Related abilities
- Update Optimisation Exclusions — the precise tool
- Get Optimisation Settings — read the current tuning
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category