Crowkis vs framework caches: your framework should not own your memory

Every LLM framework ships a caching interface, LangChain's llm_cache, LlamaIndex hooks, Semantic Kernel's memory connectors. They're conveniences: in-process, per-framework, backed by whatever store you wire in, with matching as naive as the default embedder. Switch frameworks (teams do, constantly) and your cache strategy resets to zero. That's not memory; that's a session variable with ambitions.

The deeper issue is scope. A framework cache sees one app's traffic. The same question answered in your support bot yesterday gets re-purchased by your docs assistant today, because their caches are strangers. Cache value compounds with shared scope, which is an infrastructure property, not a library import.

flowchart LR
  APP["your app<br/>redis-py · ioredis · Lettuce"] -- "RESP3 :6379" --> CK["crowkis"]
  AGENT["claude code · agents"] -- MCP --> CK
  SVC["services"] -- gRPC --> CK
  CK -- "only on a miss" --> LLM["your LLM provider"]
  style CK fill:#fbe9e8,stroke:#d62221,stroke-width:2.5px

Crowkis is framework-agnostic infrastructure: one process serving every app over RESP, gRPC, REST, and MCP, with adapters that plug into LangChain and LlamaIndex in a line. The frameworks keep doing orchestration; the cache outlives them all, accumulating value across every app, agent, and rewrite.

#The bottom line

Choose frameworks freely and abandon them guiltlessly, that's what they're for. Put the memory in a layer that doesn't care, and never pay to relearn what your stack already knew.