Cache Rules vs Workers Cache API for conditional HTML caching on Cloudflare

We run a zone where most traffic is HTML pages generated at the origin. Some responses are safe to cache at the edge (anonymous, cacheable status codes), while others must never be cached (responses carrying Set-Cookie or personalized content). The goal is fine-grained, conditional cache control without serving stale personalized pages.

Two documented paths seem available. Cache Rules (the newer replacement for legacy Page Rules) can set cache eligibility, edge TTL, and bypass-on-cookie through dashboard configuration, with no per-request compute cost. The Workers Cache API (caches.default) plus cf properties like cacheKey and cacheTtlByStatus allow programmatic decisions per response, but add invocation cost, code to maintain, and latency on misses.

What is unclear is where the practical line sits: Cache Rules matching appears limited to URL patterns and a fixed set of request fields, so it may not express "cache only 200 responses without Set-Cookie" the way a Worker can. Feature parity between the two also seems to be evolving, and plan limits differ.

Before committing, I would check cf-cache-status on test URLs and review cache analytics hit ratio by content type to confirm misses are the real bottleneck.

1. Can Cache Rules express response-conditional logic (status code, absence of Set-Cookie), or does that require a Worker?
2. For high-traffic zones, at what hit ratio does the Worker's per-request cost outweigh the flexibility?
3. Is there a documented migration path from legacy Page Rules to Cache Rules without behavior changes?