Runs local
One CPU-only binary, your machine, your disk. No account to create, no data to hand over. If we vanished tomorrow the daemon keeps working and the proofs keep verifying.
Free forever · runs on your machine · no account
Your agents' reasoning, on your machine.
One free binary runs the whole Crux reasoning stack locally and signs a receipt for everything your agents do, from the first minute. No account, no lock-in.
What it gives you
Three reasons it runs on your side of the wire
Proves everything
Every state mutation is signed into a CROWN receipt on a hash-chained, append-only store. Verification is a local command, not a support ticket, and it works offline.
Talks to your agents
A built-in MCP server with 100+ tools, plus HTTP and gRPC. Claude, GPT, local models: whatever runs your agents plugs in and starts leaving receipts in the first minute.
How it works
One daemon, three planes
Your agent speaks MCP, HTTP or gRPC to one binary. Inside it, three planes (memory, retrieval, receipts) sit on an append-only spine of BLAKE3-chained sealed segments. The daemon bundles our database (CoreCrux) and the reasoning engine (Crux Engine); the deep technical story lives on vaultcrux.com.
your agent
MCP · HTTP · gRPC
corecruxd one binary, port 14800
- memoryfacts · sessions · handoffs · engrams
- retrievalBM25 + graph fusion · token budgets · code maps
- receiptsCROWN · Ed25519 · offline verify
append-only spine · BLAKE3-chained sealed segments
No cloud in this picture. That is the point.
The console
Watch the fleet from localhost
Every daemon ships a local operator console at localhost:14800: your sessions, plans, memory and gates, every action receipted. These are captures of the real thing.
Don't take our word for it
Verify it on your own machine
Every integrity claim is checkable offline, in about a minute. Export everything the daemon knows and everything it did into one signed bundle, verify it with no network, then flip a byte and watch the verifier refuse it.
That export, offline-verify, tamper-reject cycle is a release-blocking CI gate: every published build has passed its own exit test. Releases ship with cosign signatures, CycloneDX SBOMs and SLSA provenance.
Behind it: 5,000+ tests and ~87% CI-gated region coverage, with per-crate floors on the trust core. The interactive version of this experiment is on the governance page.
corecruxctl context export --data-dir <dir> \
--out ./bundle
# no network; prints ok=true
corecruxctl context verify ./bundle --jsonbash scripts/demo-receipt-tamper.sh
# seeds a receipt, verifies ok:true,
# flips one byte, asserts the failure is caughtRetrieval economics
Your context window is the scarce resource
Most memory layers measure recall. Crux also measures what recall costs: every retrieval call takes a hard token_budget and the daemon trims to fit, metadata first, content only when it earns its tokens.
On ScoreCrux, our open benchmark, that discipline holds answer quality within two points of vendor-native memory while using roughly 15% of the context tokens. Methodology, negative controls and per-model runs are public.
Tokens returned for one query
lower is better
naive top-K · no budget
18,400
token_budget=4000 · server-enforced
3,900
token_budget=2000 · server-enforced
1,940
token_budget=500 · server-enforced
480
Budgets are enforced server-side: metadata first, content only when it earns its tokens. Same corpus, far fewer tokens than top-K stuffing. Reproducible from docs/benchmarks.md.
Code economics
Write less code, measure the result
The daemon ships a code-minimalism plane: a measured discipline that has frontier agents produce roughly 60% smaller benchmark diffs, plus the services that make the discipline real. A pre-execution overlay carries the rules, a reuse lookup answers "does this already exist?" from memory instead of your context window, and a receipts-backed ledger tracks every deliberate shortcut until it's paid down.
Every measured cell produced a non-empty diff, but the current harness did not execute the patches or validate correctness: these figures measure code volume and resource use, not whether the code works. Left unconstrained, stronger models over-build more, so the ladder closes a bigger gap on better models.
Indexed to the unconstrained model
no profileFable 5Opus 4.8
code written · the durable saving
baselineunconstrained baseline: 100%
Fable 5Fable 5 with the Crux profile: 39.0% −61.0
Opus 4.8Opus 4.8 with the Crux profile: 40.1% −59.9
tokens · reads bought, lines avoided
baselineunconstrained baseline: 100%
Fable 5Fable 5 with the Crux profile: 75.9% −24.1
Opus 4.8Opus 4.8 with the Crux profile: 61.8% −38.2
modelled cost
baselineunconstrained baseline: 100%
Fable 5Fable 5 with the Crux profile: 71.0% −29.0
Opus 4.8Opus 4.8 with the Crux profile: 64.6% −35.4
wall-clock
baselineunconstrained baseline: 100%
Fable 5Fable 5 with the Crux profile: 67.6% −32.4
Opus 4.8Opus 4.8 with the Crux profile: 65.4% −34.6
Each bar is what the model produced with the profile applied, against its own same-day unconstrained run indexed to 100. Corpus ponytail-fastapi-cd83fc1, 12 real-repo feature prompts. Every measured cell produced a non-empty diff, but the pinned harness did not execute the generated tasks or their tests: this measures code volume and resource use, not correctness. The ladder also spends read tokens to avoid written lines, so tokens close less of the gap than code does.
Sixty seconds to your first receipt.
Docker or a single binary. The daemon starts signing the moment it starts running, and everything it signs stays yours.