CueCruxVaultCrux

The Crux family

Crux is a family of systems, not one product with several names. One of them you install and can read the source of. One of them is hosted and is the commercial product. One is a public wiki anyone can use. Two more sit underneath the hosted plane and are closed. This page says what each is for and which is which.

This page is explanation. It draws the map at family level. The platform draws the same map at engineering level and carries the contracts.

1. The family in one table

SystemPostureWhat it is forRead more
Crux DaemonPublic and local. Open source, free to run.Agent memory, retrieval and receipts on your own machine.Crux Daemon internals
CueCruxCommercial. Hosted.The platform: hosted ingest, retrieval, answers, tenancy and the paid services around the daemon.The platform
WikiCruxPublic. Free to read.A public, receipted knowledge corpus and citation surface.wiki.cuecrux.com
VaultCruxPublic.The documentation and evidence plane. This site, and the published benchmark results.What is VaultCrux?
CruxEngineClosed source.The hosted plane: one service estate behind the CueCrux API.1. Crux Engine
CoreCruxClosed source.The substrate: the append-only event spine and GPU-accelerated retrieval underneath the hosted plane.2. CoreCrux
FeatureCruxInternal.The control plane that resolves which runtime behaviours apply to a tenant and request. No public endpoint.3. FeatureCrux

2. Crux Daemon: the free one, and the floor

The Crux Daemon is one Rust binary you run on your own machine. It holds facts, sessions, cases and handoffs on your own disk and serves them over HTTP, MCP and gRPC. It is CPU-only. There is no account, no API key and no network call you did not configure.

It is the permanent floor, not a trial. Local-first is the architecture rather than a starting tier: you can stay local forever and connect to the platform only when you want a service the daemon does not run itself, such as better embeddings. Local retrieval, meaning the lexical, graph and local dense lanes, is never metered and never gated behind a paid scope (upsell.rs:14).

Open source, Apache-2.0. It ships under the Apache License, Version 2.0, an OSI-approved, permissive licence with no copyleft. You can read it, build it, run it, redistribute it, and send patches.

Start at First run if you want one working, Architecture if you want to understand it, and Contributing if you want to land a change.

3. CueCrux: the hosted platform and the commercial product

CueCrux is what you buy. It is the hosted plane plus the metered services around the daemon: managed embeddings, re-ranking, extraction over data you have already ingested, multi-tenant hosting, tenancy controls and the governance surfaces.

The relationship to the daemon is deliberate and worth stating outright: they share contracts. The same receipt formats and the same capability-token scheme appear on both sides, so a workload can move between local and hosted without changing its verification story. What you will not find is a licence key in the daemon that unlocks hosted behaviour. There is no such key, and nothing in the daemon is being held back.

Plans is the capability matrix across the free daemon and the three commercial tiers, including which parts of the commercial story are defined but not yet live. Credits covers metering.

4. WikiCrux: the public corpus

WikiCrux is a public, receipted knowledge hub at wiki.cuecrux.com. It is free to read, and it is where the citation surface gets exercised in public rather than in a demo.

It matters to this documentation for two practical reasons. It is a consumer of the same receipt and capability-token contracts as everything else, through its own backend identity, so it is the same machinery rather than a separate stack; and receipt verification on the hosted side is a public unauthenticated endpoint, so nothing about checking a WikiCrux answer requires an account. And the daemon's console can search it: the Explorer surface proxies to a WikiCrux backend when engine mediation is configured, which is the default tenant for that proxy (daemon configuration reference).

5. VaultCrux: the documentation and evidence plane

VaultCrux is this site and the published benchmark results. It used to be a hosted private-RAG product; that product was retired and its code consolidated into CruxEngine, so the name now covers documentation and evidence rather than a running service.

What is VaultCrux? covers the change in full, including why old identifiers still carry the name. Bench results is the evidence half.

6. The closed systems

Two systems sit behind the hosted plane and their source is not published.

CruxEngine is the hosted plane: one service estate handling ingest, retrieval, answers, receipts, identity and tenancy behind a versioned HTTP API. Every external contract it exposes is published: the response envelope, all the error types with their retry semantics, the auth mechanisms, the request and response fields, the status codes. What is not published is how a result is computed. See 1. Crux Engine.

CoreCrux is the substrate: an append-only, hash-sealed event spine, with GPU-accelerated multi-tenant retrieval on top of it. It is described behaviourally throughout: what it does, what it guarantees, what it declines to guarantee. See 2. CoreCrux.

Why that line and not another. The trust path is inspectable and the moat is elsewhere. Everything needed to check our work is public: the receipt format, the verifier, and the endpoint that verifies, which is unauthenticated by design so you can check a receipt without an account and without a relationship with us. What stays closed is closed because it is where the work is: corpora, ranking quality earned against benchmarks and re-earned every time a corpus moves, and the operational engineering of running someone else's data on GPUs. None of that becomes safer by being secret, and none of it is what you need in order to audit us.

Two consequences we would rather state than let you infer. You cannot reproduce a hosted answer from source; you can verify the receipt for it. Those are different guarantees and the second is the one we make. And a receipt is a verifiable record of what was stored and retrieved: tamper-evidence, not an attestation of conduct. Assurance and compliance states that boundary in full, with the controls that are built but not enforced listed in those words.

7. Names that collide

Two different things in this family have been called "the engine", and the distinction decides which endpoint you call. Crux Engine is the hosted platform service. CoreCrux is the substrate it reads. Separately, the daemon has its own local retrieval path, which is neither. When you meet the word "engine" in a sentence, check which system the chapter is about before drawing a conclusion. How they fit together §4.2 is the full treatment.