skills/runtime-cache/SKILL.md (line 251 on main) states:
| Property |
Limit |
| Item size |
2 MB |
| Tags per Runtime Cache item |
64 |
| Tags per CDN item |
128 |
| Max tag length |
256 bytes |
The Runtime Cache row appears to be wrong — the limit is 128, matching the CDN row.
Evidence
Vercel documentation. vercel.com/docs/runtime-cache § Limits and usage gives Tags per item | 128 tags. The same figure appears at vercel.com/docs/caching/runtime-cache. Both fetched 2026-07-19.
Observed behavior. Two 'use cache: remote' entries deployed on Vercel, differing only in tag count:
- 121 tags — entry stored and served normally
- 131 tags — write rejected, surfacing as
Error: invalid response from cache for […]: 400
A cap of 64 would have rejected the 121-tag entry. The boundary sits between 121 and 131, consistent with 128 and inconsistent with 64.
Impact
The limit is enforced by rejecting the write, so an entry that exceeds it silently never stores while the render, the types, and every other check continue to look healthy. A threshold derived from 64 therefore misjudges the safe ceiling in the direction that hides the failure rather than surfacing it.
Because skills installed through npx skills are content-tracked in skills-lock.json, and both skills update and skills experimental_install overwrite local file changes without conflict, the figure can only be corrected here.
Suggested fix
Change the Runtime Cache row to 128. If the two rows are intended to capture a real distinction between the Runtime Cache and CDN layers, stating what that distinction is would help — as written the table implies the limits differ, while the runtime-cache documentation gives a single figure of 128 for tags per item.
skills/runtime-cache/SKILL.md(line 251 onmain) states:The Runtime Cache row appears to be wrong — the limit is 128, matching the CDN row.
Evidence
Vercel documentation. vercel.com/docs/runtime-cache § Limits and usage gives
Tags per item | 128 tags. The same figure appears at vercel.com/docs/caching/runtime-cache. Both fetched 2026-07-19.Observed behavior. Two
'use cache: remote'entries deployed on Vercel, differing only in tag count:Error: invalid response from cache for […]: 400A cap of 64 would have rejected the 121-tag entry. The boundary sits between 121 and 131, consistent with 128 and inconsistent with 64.
Impact
The limit is enforced by rejecting the write, so an entry that exceeds it silently never stores while the render, the types, and every other check continue to look healthy. A threshold derived from
64therefore misjudges the safe ceiling in the direction that hides the failure rather than surfacing it.Because skills installed through
npx skillsare content-tracked inskills-lock.json, and bothskills updateandskills experimental_installoverwrite local file changes without conflict, the figure can only be corrected here.Suggested fix
Change the Runtime Cache row to
128. If the two rows are intended to capture a real distinction between the Runtime Cache and CDN layers, stating what that distinction is would help — as written the table implies the limits differ, while the runtime-cache documentation gives a single figure of 128 for tags per item.