Crowkis vs framework caches: your framework should not own your memory
LangChain, LlamaIndex, and Semantic Kernel all offer cache hooks. Framework caches live and die with the framework. Infrastructure shouldn't.
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.
- 1your app · redis-py · ioredis · Lettuce
- 2crowkis
- 3claude code · agents
- 4services
- 5your LLM provider
Four doors in, one cache, and the model only sees genuinely new questions.
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.