Plans
Four plans. The local daemon is free and permanent; the three paid tiers add CueCrux-side compute, hosted tenancy, governance surfaces and, at the top, a private GPU deployment. The matrix in section 3 is the comparison; every row links to the chapter that explains it.
This page is reference. Credits covers metering separately.
1. Status, before the matrix
Read this first, because it changes how you should read everything below.
| Thing | Status |
|---|---|
| Crux Daemon | Live. Free, local, no account. Nothing on this page gates it. |
| Pro and Governance capability sets | Defined. The metered services they unlock are built. |
| Self-serve purchase | Not live. Subscription credit grants and the payment integration are behind default-off flags, and no plan can be bought self-serve today. |
| Governance-tier entitlements | Reserved, not enforced. Twelve governance capability keys are granted but inert by design. Do not plan a control on them. |
| Max | Scoped per deployment. Not a self-serve tier and never will be. |
If you need a paid tier now, that is a conversation through a commercial channel rather than a checkout page. We would rather say that than put a buy button on something that is not wired up.
2. Price
| Plan | Price | Who runs what |
|---|---|---|
| Crux Daemon | Free | You run it, on your own machine. Open source under the Apache License, Version 2.0. |
| Pro | £19 per user per month | You run the daemon. CueCrux runs the metered services and the hosted plane it calls. |
| Governance | £49 per user per month | As Pro, plus the governance and assurance surfaces. |
| Max | Scoped per deployment | CueCrux deploys the private stack, on your GPU hardware or dedicated capacity. |
Prices are per user per month, excluding tax. Max is quoted against a deployment rather than a seat count.
3. The matrix
✓ included · no not included · anything else is the qualifier that makes the row honest.
Three rows deserve a second look, because they are the ones a matrix normally lies about.
Shield enforcement is a switch you own, not a tier. Observe mode is the default posture on every plan and it blocks nothing. A deployment that has never been promoted is running a very good monitoring system and no enforcement at all. On Max we do the promotion with you as part of the deployment work; on the other plans you do it yourself. Shield §3 is the promotion path.
Governance entitlements are reserved and inert. Twelve capability keys exist and are granted to the tier. They are not enforced, by design, and marketing them as live controls would be a lie with a status column. If your approval depends on one of them, ask us for the enforcement date rather than reading this row as a yes.
The local lanes are never metered, on any plan. Lexical, graph and local dense search stay free and uncapped whatever you are paying, because we meter CueCrux-side compute only (upsell.rs:14). Moving up a tier adds services; it never withdraws something you already had.
4. Crux Daemon: who it is for
A developer running agents on one machine, or anyone who wants agent memory that does not leave the host. Everything in the first block of the matrix, for nothing, permanently. No account, no key, no telemetry you did not turn on.
What changes when you move up: nothing is taken away. Pro adds CueCrux-side compute that the daemon cannot do on a laptop, and hosted surfaces for systems that cannot embed a daemon.
5. Pro: who it is for
A team whose agents have outgrown local embeddings. Pro is the daemon plus the metered services: better embeddings, re-ranking over your fused results, and extraction over data you have already ingested, alongside hosted tenancy for the parts of the workload that need it.
What changes when you move up to Governance: the assurance surfaces and review support, and the governance capability set once it is enforced.
6. Governance: who it is for
The person who has to approve the system rather than use it. Governance is Pro plus the assurance and compliance surfaces, and the tier the governance capability keys are attached to.
Be clear-eyed about the state of this one. The evidence work is real and public: Assurance and compliance is a dated disclosure that lists controls which are built but not enforced in those words, and it is available to every reader on every plan. The tier-specific entitlements are reserved and inert. EU AI Act work is a 2027 sub-track; operational and governance evidence is what exists now.
What changes when you move up to Max: the substrate moves onto hardware you control, and the deployment stops being your problem.
7. Max: who it is for
An organisation that needs the stack inside its own boundary. Max is everything in Governance plus onsite GPU, private-stack deployment, dedicated capacity sizing, backups, runbooks and the deployment engineering to make all of it run. It is scoped per deployment and quoted per deployment.
The practical difference is where CoreCrux runs. On Pro and Governance the substrate is ours; on Max it is yours, on your hardware, with us doing the engineering. CoreCrux describes what that substrate does and what it declines to guarantee.
8. How Pro is deployed
Local is where your knowledge lives. That is not a default you can flip; it is the architecture.
- Local-first keeps the Crux daemon as the working copy and calls managed Pro services, including GPU compute, with scoped payloads for gated work. This is how Pro runs.
- Hosted access surfaces let a system that is not your daemon reach your workspace over MCP and REST, for integrations that cannot embed a daemon. It is a connection to your workspace, not a relocation of it: the daemon remains the working copy and the source of truth.
- Hybrid uses cloud-to-local mirror sync for shared tenant memory, so work continues locally during an outage of anything hosted.
Local private memory is not uploaded by default. Shared tenant memory can mirror down to local devices. Local-to-cloud writeback is an explicit promotion flow or a tenant-policy-governed collection sync.
Why there is no "cloud-only" plan. An earlier version of this page offered one, describing systems connecting to a hosted store "without running a local daemon". That is withdrawn. It contradicted the property the rest of this platform is built to provide: that the substrate runs inside your boundary, that the evidence is customer-held rather than vendor-held, and that if CueCrux disappeared tomorrow your daemon would keep working. A mode in which we hold the primary copy forfeits all three. If you need reach without a local daemon, use the hosted access surfaces above and keep the daemon as the store.
9. Tenants and offboarding
Personal and business memory should live in separate tenants, and the separation is the point rather than a filing convention: a business tenant mirror can be removed from a device when someone leaves without touching their personal tenant.
On the hosted side, tenant scoping is enforced twice, at the credential and again at the query, and a mismatch is refused rather than reconciled. Document deletion runs an erasure verification after it commits and reports the result rather than assuming it. Crux Engine §1.18 states both as guarantees, and §1.19 states the limits that sit beside them.
10. Read next
- Credits, what a credit is, what spends one, and what never will.
- The Crux family, what each system in the family is for.
- Assurance and compliance, the dated disclosure a reviewer will ask for.