Crowkis vs Portkey: the gateway routes, the cache remembers
Portkey is a control panel for LLM calls. Crowkis is the memory underneath them. Confusing the two costs you the savings both promise.
Portkey positions itself as an AI gateway: routing, retries, observability, and a 'semantic cache' line item on the feature grid. The pattern is familiar — when caching is one of forty features, it gets one team's sprint, not an architecture. Crowkis is the inverse: the cache is the whole product, and everything in the binary exists to make reuse safe.
Look at where the intelligence lives. A gateway cache typically embeds, compares similarity, and serves above a threshold. Crowkis runs twelve intent classes with separate reuse policies, structural template matching, a geometric-mean confidence gate, a five-stage write-trust pipeline with an append-only ledger, cost-aware eviction, and freshness policies with version pinning. That's not a longer feature list — it's the difference between matching strings-ish and understanding queries.
Router in front, memory behind — just don't confuse the roles.
There's also the deployment philosophy. Cloud gateways meter your traffic and sit between you and your provider as a service. Crowkis is a flat-priced binary on your hardware: no usage meter, no phone-home, air-gap friendly. Your cache — the thing holding your customers' answered questions — never leaves your network.
The bottom line
If you like your gateway, keep it; Crowkis happily sits behind any router as the memory layer. But let the component whose only job is safe reuse make the reuse decisions. Specialists beat feature grids in the critical path, every time.