Credits
A credit is the unit CueCrux-side compute is priced in. Local work is not priced at all. Everything on this page is about the first sentence; the second sentence is the one that matters more, and section 3 states it precisely.
This page is reference. Plans covers what each tier includes.
1. Status: what is live and what is not
Stated before anything else, because a page about billing that does not say whether billing is on is worse than no page.
| Thing | Status |
|---|---|
| The metered services themselves | Built. Managed embeddings, re-ranking and extraction exist and run. |
| Daemon-side credit metering | Flag, default off. CORECRUXD_CREDIT_METER is off unless you turn it on (config.rs:1373). With it off, metered paths keep a no-burn shape. |
| Hosted-side pricing fields | Live in the contract. A hosted retrieval response carries credit_cost and cost_reason, and an empty balance is a 402 rather than a silent failure. |
| Subscription credit grants | Not live. Behind a default-off flag. |
| Payment integration | Not live. Behind a default-off flag, with no live price configuration. |
So: the meter is real, the plumbing is real, and nobody is being charged today. Read the rest of this page as a description of a contract you can build against, not as an invoice you are about to receive.
One consequence worth internalising while you test: a 200 from a metered route on a daemon with the meter off does not mean credit was checked. If you are validating your own cost handling, turn the meter on deliberately rather than inferring from a successful call. Admin and operations has the route-level detail.
2. What spends a credit
Exactly one class of thing: CueCrux-side compute you asked for. On the daemon side that is a closed list of five metered service scopes (upsell.rs:32):
| Metered service | What it does |
|---|---|
| Dense re-rank | Re-ranks your already-fused results using a hosted re-ranking model. |
| Managed dense embeddings | Produces higher-quality embeddings for your ingested data than the daemon's local embedder. |
| Entity extraction | Populates your knowledge graph with entities pulled from ingested data. |
| Relation extraction | Links those entities. |
| Fact distillation | Distils facts out of raw ingested data. |
On the hosted plane, retrieval and answer calls are priced per call. The response tells you what it cost: credit_cost alongside the results, and cost_reason, which is one of tenant_only_query, paid_tier_commons_query or free_tier_commons_rate. Including the shared commons corpus in a query affects the cost, and the field says which case applied. See Crux Engine §1.9.
When a call is refused for cost, it is refused visibly. A 402 carries the balance in the body; InsufficientCredits means the balance did not cover a priced call, and SponsorRequired means a self-registered agent principal exhausted its allowance and needs a sponsor. Neither is retryable without changing something. Crux Engine §1.5 is the full error contract.
The one code-intelligence operation that spends is an LLM-enriched dead-code verdict — the rung where a third party is asked to reason over the evidence ladder rather than the daemon computing it. It is priced at the same rate as extraction because it is the same shape of work. Everything else in chapter 18 is free, on every tier.
3. What never spends a credit
Local retrieval is never metered, on any plan, ever. Lexical search, the graph lane and local dense search carry no scope and are not routed through the metering path at all. The constraint is written into the source: we meter CueCrux-side compute only, and local retrieval is never gated through these scopes (upsell.rs:14). A denial on a local lane is not an upsell moment and the daemon does not treat it as one.
Also free, and worth naming because people assume otherwise:
- Storing and reading facts, sessions, cases and handoffs on your own daemon.
- Verifying a receipt. Verification on the hosted side is a public unauthenticated endpoint; you do not need an account, a key or a relationship with us to check our work.
- Reading this documentation, and reading WikiCrux.
- Code intelligence.
code_path,code_blast_radius,code_liveness,code_trace_diffandcode_dead_codeare deterministic and answer from your own daemon's scan and trace store, so there is no CueCrux-side compute to meter. This holds when they answer across every repository you have registered, not only for a single repo. **Repositories are not metered and there is no repo count to buy** — see chapter 18. - Retained runtime spans are bounded by a per-tenant ceiling with a counter you can read before it applies, not by a per-span charge.
Two refusal cases also cost nothing, which matters when you are handling errors. A quota 429 never spends credit: the bucket sits before any metered execution, so nothing was debited. And a poisoned credit meter fails every metered request closed with a 500 until restart, which is deliberate, because the alternative is an untracked debit or compute without a debit. Admin and operations covers both.
4. Grants and pooling
The intent, stated as intent because none of it is switched on:
- A subscription grants credits on a recurring basis, per plan.
- Pro and Governance users can hold personal and business tenants and pool credits across a team.
- Additional CueCrux compute can be bought as capacity, without changing data ownership or tenant boundaries.
- Conversion, tipping and pooled-credit surfaces are policy controlled and auditable.
Grant amounts and plan mapping are not published here, and will be published when purchase is live rather than guessed at now. If you are budgeting against this, ask for the numbers through a commercial channel and get them in writing.
5. How to read usage
Three surfaces, in increasing order of how much they tell you.
Per call. The hosted response carries credit_cost and cost_reason. This is the authoritative per-call answer and it is the one to log.
Per spend. On the daemon, POST /v1/credits/spend records a spend against a pinned quote and returns a spend receipt. A 409 means the quote is no longer valid, so re-quote rather than retry; a 404 means the meter flag is off. See Admin and operations.
Per unit of work. The daemon can attribute recorded burn to work items and ExecPlans. Read this as an indication rather than a bill. Attribution is a read-time join: where a report names its plans, burn is split evenly across them; otherwise a coarser overlap method credits every temporally overlapping plan, and the module records its own measured coarseness. Coordination and cost explains the two methods and when each applies. Cost attribution is a supporting field. It is not a headline and it is not an itemised invoice.
6. Read next
- Plans, the capability matrix and what each tier is for.
- Local versus hosted, which tools run locally and which reach CueCrux.
- Retrieval and budgets, what the free local lanes actually do.