A cache hit is not the same as a correct answer
Most caches treat every hit as equally trustworthy, a binary yes. But LLM answers are probabilistic and time-sensitive. Crowkis scores its confidence before it serves.
Traditional caches have exactly two states: hit or miss. That's fine when you're caching a database row that's simply true. It's dangerous when you're caching a language model's answer, which was probabilistic when it was generated and may have quietly gone stale since. A confident 'hit' on a wrong answer is worse than a miss.
In plain words. Before serving, Crowkis computes a confidence score from several signals, how close the match is, how fresh it is, how trusted its source was, how well it's held up historically. Below your threshold, it declines to serve and asks the model instead.
flowchart TD Q["query"] --> M["meaning match"] M --> N["nearest neighbours"] N --> C["confidence score"] C -- "high enough" --> A["serve · ~ms"] C -- "too low" --> MISS["→ ask the model"] style A fill:#fbe9e8,stroke:#d62221,stroke-width:2.5px style MISS fill:#f3eee5
This is the difference between a cache that saves you money and a cache you can actually leave on in production. The confidence gate means the failure mode is a safe miss, a slightly slower, correct answer, not a fast, confident, wrong one. In enterprise software, that asymmetry is everything.
The bottom line
Serve the hits you trust; quietly miss the ones you don't. A cache that knows the difference is one you can turn on and forget about.