CSESSION: conversation buffers with semantic recall built in
Chat history is more than the last N turns. CSESSION stores a multi-turn buffer per session, bounded and TTL'd, with both recent-window reads and semantic search across the whole conversation.
Every chat app reinvents the same buffer: a list of turns, trimmed to fit the context window, stuffed back into the next prompt. CSESSION makes it a first-class object. CSESSION ADD appends a turn with its role and an optional TTL; the buffer is bounded per session so a long conversation can't grow without limit.
In plain words. Crowkis keeps a conversation's history for you and lets you both grab the last few messages and semantically search the whole thing, so the agent can recall something said long before the context window's edge.
Reading it works two ways, because conversations are queried two ways. CSESSION RECENT pulls the last N turns for the familiar sliding-window prompt. CSESSION SEARCH runs a semantic query across the entire conversation, so 'what did they say about their budget earlier?' finds the turn from forty messages ago that a recent-window read would have dropped.
flowchart TD A1["agent 1: 'what's the schema?'"] --> CK["crowkis"] A2["agent 2: 'schema for orders?'"] --> CK A3["agent 3: 'show orders schema'"] --> CK A4["agent 4: 'orders table layout?'"] --> CK CK -- "1 model call" --> LLM["provider"] CK -- "3 semantic hits · <1ms" --> DONE["answers"] style CK fill:#fbe9e8,stroke:#d62221,stroke-width:2.5px
That second mode is the one that changes what your agent can do. The sliding window forgets the start of a long conversation; semantic recall over the full buffer doesn't, which means an assistant can answer 'as I mentioned earlier' correctly instead of pretending the earlier part never happened.
The bottom line
It's the buffer you were going to build anyway, with the semantic search you probably weren't, bounded, expiring, and one command away instead of one service away.