One signed binary. Every feature compiled in. Free to run. Install Crowkis →
← back to the Roost
featuresJuly 2, 2026· 5 min read

Why 'who wrote Hamlet' and 'today's stock price' can't share a TTL

A single time-to-live for every cached answer is a bug in disguise. Some facts are true for a decade; some are stale in minutes. Freshness has to know the difference.

Pick one TTL for your whole cache and you've guaranteed you're wrong for most of it. Set it long and you'll serve last week's price as today's. Set it short and you'll pay the model to re-derive that Shakespeare wrote Hamlet, a fact that hasn't changed since 1600. One number can't be right for both.

In plain words: Crowkis picks a freshness window based on what kind of question it is. Timeless facts get long lives; fast-moving ones expire quickly; and a source can push an update that invalidates entries the instant the underlying data changes.
sensible lifetimes by question type
settled facts (history, definitions)100 · up to a year
docs & policies40 · days
software versions12 · hours
prices & real-time2 · minutes

Relative lifetimes, the cache matches the answer's shelf life to the question.

And when freshness can't be guessed, it can be told: a data source can fire a signal that purges every entry tied to it, so a cache hit is never stale by more than the moment your source changed. Freshness stops being a gamble and becomes a rule.

The bottom line

The right TTL is not a number, it's a function of the question. Match the lifetime to the fact, and you keep the savings without ever serving something out of date.