Platform · 0. The platform
CueCrux is four systems, not one product wearing four names. One of them you install and can read the source of: the Crux Daemon, a single binary that runs on your own machine. The other three are ours to run, Crux Engine is the hosted plane, CoreCrux is the retrieval substrate underneath it, and FeatureCrux is an internal control plane you will never call.
If you already know which one you came for, skip to the router in 0.5. If you came to install something, it is the daemon.
This chapter is explanation. It draws the map. The chapters it links to carry the contracts.
0.0 In plain English
Most companies sell you one thing and give it one name. CueCrux is four things, and if you do not know which one someone is talking about, half of the documentation reads as contradictory. This chapter's whole job is to stop that happening, before you have wasted an afternoon looking for a feature in the wrong place.
Here is the shape. The Crux Daemon is a program you download and run on your own machine, with source you can read. Crux Engine is the hosted service we run, for people who would rather not run anything themselves. CoreCrux is the retrieval and storage engine that sits underneath the hosted service and does the heavy lifting. FeatureCrux is an internal control plane with no public endpoint, which you will never call and which is documented only so that you know it exists and is not something you are missing.
Why four? Because the same capability at two very different scales is two different engineering problems. A memory daemon for one developer's agents on one laptop should be small, boring and easy to inspect. A multi-tenant engine holding other people's corpora on shared hardware needs sharding, isolation, verified erasure and an operational surface that would be dead weight on a laptop. Trying to make one binary do both produces something that is bad at each.
You will read this chapter once, near the start, and then use §0.5 as a router. The most common reason to come back is §0.4, names that collide: several words in this product mean different things in different chapters, and "engine" is the worst offender.
The thing people get wrong is assuming the paid systems are the free one with a licence key. They are not, and this matters practically rather than philosophically. The daemon and CoreCrux are separate codebases that deliberately share a family of contracts, so a client written against one keeps working when pointed at the other. What you will not find is a flag in the daemon that unlocks CoreCrux behaviour, because there is no such flag and nothing in the daemon is holding it back.
0.1 The four systems
| System | Posture | What it is | Where it runs | Chapter |
|---|---|---|---|---|
| Crux Daemon | Public, open source under Apache License, Version 2.0 | One Rust binary. Agent memory kept on your own disk and served over HTTP, MCP and gRPC. CPU-only; there is no GPU code path in it. | Your machine. No account, no API key; nothing leaves the host unless you configure it to. | Crux Daemon |
| Crux Engine | Private, closed source | The hosted plane: ingest, retrieval, answers, receipts, tenancy and metering behind one versioned HTTP API. | CueCrux infrastructure, reached through an edge. | 1. Crux Engine |
| CoreCrux | Private, closed source | The substrate: an append-only, hash-sealed event spine, and GPU-accelerated multi-tenant retrieval on top of it. | A GPU host: ours, or your own hardware. | 2. CoreCrux |
| FeatureCrux | Private, internal | The control plane that decides which runtime behaviours apply to a tenant and request, and records the decision. | Inside the platform. No public endpoint, no SDK, no account reaches it. | 3. FeatureCrux |
Three relationships are worth stating outright, because earlier copy got each of them wrong.
- Crux Engine does not ship inside the Crux Daemon. They are counterparts, the same capability, hosted and local, not a component and its container.
- The daemon and CoreCrux are peers on a shared contract, not two tiers of one binary. Two separate codebases that agree on the receipt format and the query route shapes, so a client written against one keeps working against the other.
- FeatureCrux is not a customer surface. It is documented here because its decision record is part of the platform's audit story, not because you will integrate with it.
4. How they fit together draws the data flow across all four and states what stays yours in each deployment shape.
0.2 What is open, what is closed, and why
The rule is short: the trust path is inspectable, and the moat is content, operations and hardware, not secrets in the code.
| You can read the source of | You cannot |
|---|---|
| The Crux Daemon, entire, the memory substrate, the receipt format and how receipts are signed, the auth and scope model, the MCP tool surface, and every environment variable it reads | Crux Engine's implementation |
| The daemon's client SDKs, published on npm and PyPI | CoreCrux's retrieval internals: which lanes exist, how their results are fused, how a result is ranked |
| Receipt verification on the hosted side, which is a public unauthenticated endpoint: you can check a receipt without an account and without a relationship with us | FeatureCrux, entirely |
Why that line and not another. A proof you have to take our word for is not a proof, so everything needed to check our work is inspectable: the receipt format, the verifier, and the endpoint that verifies. What stays closed is not closed because publishing it would break it. It 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. A receipt is a verifiable record of what was retrieved and what an answer was built from; it is tamper-evidence, not an attestation of conduct.
- Open source, Apache-2.0. The Crux Daemon 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. See chapter 8 for the redistribution conditions.
0.3 How a claim in these chapters is grounded
The daemon chapters carry a link to the exact line of public source behind every sentence that names a file, function, flag, route, type or constant. If a link does not say what the chapter says it says, the chapter is wrong and should be reported.
The three private chapters carry no source links, because the paths would themselves be the disclosure. Every claim in them is instead grounded on something observable from outside: a route, a request field, a response field, a header, a status code or an error code. Where a guarantee has a boundary, the boundary is published beside it at the same volume, see 1.19 for what the hosted plane explicitly does not promise.
0.4 Names that collide
Three names in this platform have historically meant two things each. Each collision has produced a real integration mistake.
| The name | One thing it means | The other | How to tell |
|---|---|---|---|
| "the engine" | Crux Engine, the hosted plane you POST to | The retrieval path that runs inside the daemon binary on your machine | If it has a URL and a tenant header, it is Crux Engine. See 1.1. |
| "corecruxd" | The Crux Daemon binary | The CoreCrux engine binary | One machine and one user's memory is the daemon; many tenants' corpora on server hardware is CoreCrux. Never write the bare binary name without saying which. |
| "the feature registry" | FeatureCrux: runtime control plane, decides behaviour per tenant per request | An engineering capability catalogue that tracks which capabilities exist and how well they are covered | One governs runtime behaviour; the other describes engineering coverage. They share no data. See 3.9. |
0.5 Where to start
| I want to | Start at |
|---|---|
| Install something and run it | Crux Daemon: one binary, your machine, no account. Then 5. Configuration reference for the environment variables, and Build from source if you would rather compile it. |
| Integrate against an API | 1. Crux Engine for the hosted contracts, the envelope, every error type, auth, retrieval, answers, receipts. API reference for the daemon's own routes. SDKs for the clients. |
| Evaluate whether to trust this | 4. How they fit together for the whole picture, 1.19 and 2. CoreCrux for the guarantees with their boundaries, then 16. Known defects, the daemon's own audited defect list, published because a set that hides its defects cannot be trusted about anything else. |
| Contribute | Contributing, then Build from source and Repository tour. The daemon is the repository that takes patches. |
Next: 1. Crux Engine.