How does CueCrux actually work?

CueCrux starts with the Crux Daemon: one binary, installed locally, running on CPU, with no account required. Everything else in the product is built on what that binary records.

Inside the daemon, three planes sit on a single append-only spine. The memory plane holds what your agents know: facts, sessions, decision records, work items, engrams. The retrieval plane serves it back under strict budgets. The receipts plane records every state mutation as a CROWN receipt, signed with Ed25519 and hash-chained on a BLAKE3 spine, so the history of the store is itself evidence.

Agents connect over MCP; the daemon exposes more than 100 tools. Every connection binds to a passport and every tool call carries it, so there are no anonymous writes. Every retrieval call takes a hard token_budget, and the daemon trims results to fit rather than flooding the context window.

Retrieval runs locally as BM25-class lexical search fused with graph signals. Dense retrieval is bring-your-own embedder: point the daemon at Ollama, vLLM, TEI, llama.cpp or LiteLLM. Richer hosted lanes (entity, event, navigational) run on CoreCrux for the paid tiers.

Policy is enforced per request by RCX, which issues short-lived capability tokens or refuses with a signed RefusalReceipt. You watch all of it from the local operator console at localhost:14800: canvas board, relation graph, ExecPlans kanban and live sessions.

Nothing in this pipeline requires trusting a hosted service. The receipts verify offline, on your machine, with corecruxctl.