Someone set maxmemory-policy once, based on a hunch about a workload that has changed a dozen times since. The policy never did. CloxCache — the eviction engine inside Swytch — tunes itself to your access patterns with gradient descent, continuously, on every node. No retraining jobs, no GPU, no config.
# macOS / Linux (Homebrew)
brew tap swytchdb/tap
brew install swytchDocker: ghcr.io/swytchdb/swytch
CloxCache is CLOCK-LRU-K with learned parameters. Each node continuously measures which candidates it evicted too early and which it kept too long, then nudges its own parameters against that error. The policy converges on your workload — and keeps converging as the workload drifts.
There is no model to train, no inference service to run, no data leaving the node. It is a handful of numbers, updated constantly, that outperform any static policy you could pick.
# redis.conf — before
maxmemory-policy allkeys-lru # a guess, frozen in time
# swytch — after
#
# (there is no eviction config)
# the policy is learned per node, per workloadThe eviction policy you don’t configure.
The hit rate an engineer watching the cache all day would get you — without the engineer.
LRU versus LFU versus TTL roulette — the argument ends. The node measures what your workload rewards instead of guessing.
A launch, a viral post, a seasonal spike: access patterns shift and eviction shifts with them. No redeploy, no config change, no ticket.
No GPU, no training pipeline, no telemetry shipped anywhere. The learning runs inside the cache process, on numbers that never leave the node.
Self-host it free under AGPL. Point real traffic at it and watch the eviction settle into your workload.
Curious but not deploying? Drop your address and we’ll send the CloxCache write-up.